INSTITUTO TECNOLGICO SUPERIOR DE ACAYUCAN

MISAEL JUREZ HERNNDEZ

MATRICULA

090BO251

803-C

INGENIERA EN SISTEMAS COMPUTACIONALES

INVESTIGACIN UNIDAD 3 4 5

MATERIA

DESARROLLO DE PROYECTOS DE SOFTWARE

DOCENTE: MTI. JESS HERNNDEZ MUNDO

ACAYUCAN,VER.,

25 / 06 /2013

Contenido
Contenido....................................................................................................... 2 INTRODUCCION.............................................................................................. 4 UNIDAD 3 CONSTRUCCIN...........................................................................5 3.1 DESPLIEGUE DE COMPONENTES Y ARQUITECTNICO..............................5 3.2 TCNICAS DE DESARROLLO DE LAS ARQUITECTURAS DE REFERENCIA EN DIFERENTES DOMINIOS.................................................................................. 6 3.2.1 Modelos de componentes .....................................................................7 3.2.2 Arquitectura de referencia para sistemas de tiempo real fuente de alimentacin................................................................................................... 8 3.2.3 Arquitectura de Referencia para Sistemas Mviles con Conexin a Internet.......................................................................................................... 9 3.2.4 Arquitectura de referencia para sistemas de informacin...................10 3.2.5 Arquitectura de referencia para ambientes virtuales de aprendizaje. 11 3.2.6 Arquitectura de referencia para lneas de productos..........................13 UNIDAD 4 PRUEBAS DE SOFTWARE..............................................................15 4.1 DEFINICIONES......................................................................................... 15 4.1.1.- Pruebas, Caso de Prueba de Defecto, Falla , Error, Verificacin y Validacin..................................................................................................... 15 ..................................................................................................................... 15 4.1.2 Relacin entre defecto-falla y error.....................................................16 4.1.3 Pruebas estructurales, funcionales y aleatorias..................................17 4.1.4 Documentacin del diseo de las pruebas..........................................20 4.2 PROCESO DE PRUEBAS...........................................................................23 4.2.1 Generar un plan de pruebas................................................................24 4.2.2 Disear pruebas especficas................................................................27 4.2.3 Tomar Configuracin del Software a Probar........................................30

4.2.4 Configurar las Pruebas........................................................................32 4.2.5 Evaluar resultados............................................................................... 33 4.2.5.1 Depuracin...................................................................................... 33 4.2.5.2 Anlisis de errores............................................................................36 4.3 TECNICAS DE DISEO DE CASOS DE PRUEBAS......................................38 4.4 ENFOQUE PRACTICO RECOMENDADO PARA EL DISEO DE CASOS........39 4.5 ESTRATEGIAS DE APLICACIN DE APLICACIN DE LAS PRUEBAS...........40 4.5.1 De unidad ........................................................................................... 41 4.5.2 De integracin..................................................................................... 42 4.5.3 De sistema.......................................................................................... 43 4.5.4 Prueba de aceptacin..........................................................................43 UNIDAD 5 IMPLANTACION E IMPLEMENTACION............................................43 5.1 Implantacin e integracin de casos de uso y componentes de software ..................................................................................................................... 43 5.2 Mantenimiento del software...................................................................45 CONCLUSIN................................................................................................ 47 GLOSARIO..................................................................................................... 48 FUENTES DE INFORMACIN..........................................................................50

INTRODUCCION
Una de las caractersticas ms destacadas de las sociedades modernas es el uso de la tecnologa en la cual en muchos de los caso se involucra el desarrollo de sistemas de software que apoyan las actividades diarias en empresa, en nuestra casa, en procesos de comunicacin donde interviene el manejo de informacin o en los sistemas de produccin donde se ha sustituido la mano del hombre por maquinas que controlan la produccin atreves de dispositivos programados y grabados en una placa de silicio. El software es algo indispensable en nuestra vida diaria que de manera general se entiende como programas de computadora; el desarrollo de software es una actividad donde se involucra la ingeniera; que es el estudio y aplicacin, por especialistas, de las diversas ramas de la tecnologa. 1 El desarrollo de sistemas de software no es el simple hecho de programar computadoras, instrucciones en una placa de circuitos integrados para que realice una determinada funcin o el realizar grandes programas que se ejecuta en una poderosa computadora que puede realizar miles de operaciones por segundo o que de igual manera se puede ejecutar en una PDA o en algn otro dispositivo electrnico; por lo que este proceso involucra a la Ingeniera de Software que comprende todos los aspectos de la produccin de software desde las etapas iniciales de la especificacin del sistema (Somerville, 2005, p.6). Desarrollar un software significa construirlo simplemente mediante su descripcin. Est es una muy buena razn para considerar la actividad de desarrollo de software como una ingeniera. Por lo que un producto de software no se limita solo a programas de computadora sino a la documentacin asociada a este en las distintas etapas que interviene desde su concepcin, anlisis, diseo, implementacin, pruebas y mantenimiento. El software no estara completo si no existiera una especificacin de requerimiento o un diseo de la arquitectura, crear software es muy similar a la creacin y diseo de muchas otras reas como la arquitectura donde podemos empezar diseando una casa o departamento hasta un gran rascacielos o el puente ms largo que comunica dos ciudades. La ingeniera de software como otras ingeniera hace uso de metodologas que involucran herramientas mtodos procedimientos y tcnicas para realizar un proyecto por eso es que en este manual se intenta dar una descripcin de los pasos que se involucran en el desarrollo de software de acuerdo los requerimientos de los diferentes dominios de su arquitectura.

UNIDAD 3

CONSTRUCCIN

3.1 DESPLIEGUE DE COMPONENTES Y ARQUITECTNICO

Se utilizan para modelar los elementos fsicos que pueden hallarse en un nodo. Ejecutables Bibliotecas Tablas Archivos Documentos Deben definir abstracciones precisas con interfaces bien definidas y

que permitan la reemplazabilidad. Representacin grfica:

Figura 3.1 Representacin grfica En muchos sentidos los componentes son como las clases: o o o o o Ambos tienen nombre Ambos pueden realizar un conjunto de interfaces Ambos pueden participar en relaciones de dependencia, generalizacin y Ambos pueden anidarse Ambos pueden participar en interacciones

asociacin

La relacin entre un componente y las clases que representa puede especificarse explcitamente.

Figura 3.2 Relacin de componentes Los nodos al igual que los componentes son un elemento fundamental en el modelado fsico de un sistema Es decir, un procesador o un dispositivo sobre el que se pueden desplegar los componentes UML proporciona una representacin grfica de un nodo genrico que se puede particularizar para representar procesadores y dispositivos especficos. Un diagrama de despliegue muestra: Los distintos dispositivos y su interconexin La asignacin de componentes (procesos, ficheros,...) a dispositivos Debe existir un slo diagrama de despliegue por modelo.

Con direcciones: in, out, inout

Figura 3.3 Direcciones.

3.2 TCNICAS DE DESARROLLO DE LAS

6

ARQUITECTURAS DE REFERENCIA EN DIFERENTES DOMINIOS.

3.2.1 Modelos de componentes
El modelo de componentes ilustra los componentes de software que se usarn para construir el sistema. Se pueden construir a partir del modelo de clases y escribir desde cero para el nuevo sistema o se pueden importar de otros proyectos y de productos de terceros. Los componentes son agregaciones de alto nivel de las piezas de software ms pequeas y proveen un enfoque de construccin de bloques de caja negra para la elaboracin de software. El Diagrama de Componentes El diagrama de componentes muestra la relacin entre componentes de software, condiciones. sus dependencias, su comunicacin su ubicacin y otras

3.4 Diagrama de componentes Los Componentes de Servidor Estos componentes son una mezcla de los tems construidos a medida y adquiridos que se ensamblarn para proveer la funcionalidad requerida.

Los Componentes de Seguridad El diagrama de componentes de la seguridad muestra cmo trabaja en conjunto el software de seguridad, tal como la Autoridad Certificadora (Certificate propuesto. Authority), el navegador (Browser), el servidor WEB y otros elementos del modelo para asegurar la provisin de la seguridad en el sistema

3.2.2 Arquitectura de referencia para sistemas de tiempo real fuente de alimentacin

TAREAS Los Sistemas de Tiempo Real (STR) ejecutan actividades o tareas en un intervalo de tiempo predeterminado. Tienen varios tipos de propiedades: Funcionales: qu hacen. Temporales: cundo lo hacen.

El comportamiento temporal de las tareas se especifica mediante sus atributos temporales: Cundo se ejecutan: esquema de activacin. Qu plazo tienen para ejecutar cada accin.

El diseo de arquitecturas de tiempo real involucra 2 aspectos: Nivel de Nodo Cada procesador debe proveer velocidad y predecibilidad en la ejecucin de tareas de tiempo real, manejo de interrupciones e interaccin con el mundo externo. Nivel de Sistema En este nivel las comunicaciones y la tolerancia a

fallos son 2 aspectos que hacen difcil la predecibilidad. De cualquier manera, estos aspectos son inevitables. ELEMENTOS QUE COMPONEN UN STR

Aspectos de integracin y de rendimiento. Manejo de Interrupciones. Bases de Datos de Tiempo Real. Sistemas Operativos de Tiempo Real. Lenguajes de Tiempo Real. Sincronizacin y comunicacin de tareas.

3.2.3 Arquitectura de Referencia para Sistemas Mviles con Conexin a Internet

El concepto de Internet Mvil, o conexin mvil a Internet, surge apartir de la evolucin de los sistemas de telefona mvil hacia la prestacin de nuevos servicios de datos. Dada la importancia de Internet como eje central sobre el que se desarrolla la Sociedad de la Informacin, el xito de los sistemas mviles de 2G y la llegada de la banda ancha al mundo mvil con gracias a las redes de 3G y sucesivas, Internet mvil es fruto de la convergencia del mundo Internet y la movilidad. Convergencia Internet-mvil El crecimiento espectacular de ambas tecnologas ha impulsado la convergencia entre Internet y las comunicaciones mviles: La tecnologa WAP permite el desarrollo de contenidos y servicios en Internet con acceso desde todo tipo de terminales mviles. GPRS/EDGE garantiza una transicin suave y con garantas de la segunda (GSM) a la tercera generacin (UMTS) de comunicaciones mviles y permite acceso a Internet con velocidades de hasta 170/384 Kbps. UMTS suponela fusin de las telecomunicaciones mviles e Internet, proporcionando acceso ilimitado a

contenidos y servicios multimedia con velocidades de hasta 2 Mbps. HSDPA/HSUPA ofrecen altas prestaciones de voz y datos y permitirn la creacin de un gran mercado de IP multimedia mvil Evolucin de los sistemas mviles Sistemas mviles de primera generacin (1G) Sistemas mviles de segunda generacin (2G) Sistemas mviles de generacin 2,5 ( 2.5G) Sistemas mviles de tercera generacin (3G)

3.2.4 Arquitectura de referencia para sistemas de informacin

La decisin de abordar un estudio en profundidad para definir la Arquitectura de los Sistemas de Informacin, parte de la necesidad de conseguir unos objetivos de carcter general, que pueden resumirse en los siguientes puntos: Alineamiento de la ptica de negocio con la estructura de los Sistemas de Informacin. Disponer de un modelo integral que abarque todas las aplicaciones y sistemas informticos. Determinar la estrategia general de los futuros desarrollos. Adecuar los sistemas actuales, Definir un horizonte hacia el que evolucionar a corto, medio y largo plazo. Potenciar la eficacia de los Sistemas Informticos Posibilitar la incorporacin de las tecnologas emergentes de forma eficaz. Favorecer la mejora de la calidad profesional y de la gestin interna. Reducir los costes y el plazo de disponibilidad de las aplicaciones.

10

Al trmino del estudio se dispondr de los siguientes resultados: Identificacin de los Requerimientos Estratgicos de negocio, desde la ptica de los Sistemas de Informacin. Modelos estructurados y documentados sobre las Arquitecturas: Funcional Datos Sistemas reas complementarias seleccionadas

Identificacin de los diferentes Sistemas de Informacin utilizados, Reglas de diseo para implantar nuevas tendencias tecnolgicas. Reglas de diseo para la estructuracin de las aplicaciones. Las fronteras de cada uno de los Subsistemas en que se divide el Sistema (interfaces). Un equipo formado y conocedor de los modelos diseados para enfocar la implantacin de la Arquitectura. Un soporte informtico conteniendo los modelos, cara al enlace con el desarrollo de los proyectos. Un diseo previo, no detallado, de cada Sistema, Modelo organizativo para la funcin de Administracin de la Arquitectura Un Plan Director, especificando la estrategia recomendada para la evolucin de los Sistemas.

3.2.5 Arquitectura de referencia para ambientes virtuales de aprendizaje.

Un Ambiente Virtual de Aprendizaje es el conjunto de entornos de interaccin, sincrnica y asincrnica, donde, con base en un programa curricular, se lleva a

11

cabo el proceso enseanza aprendizaje, a travs de un sistema de administracin de aprendizaje. La propuesta metodolgica para operar los modelos educativos innovadores es la de Ambientes Virtuales de Aprendizaje (AVA), ya que crear un ambiente de este tipo no es trasladar la docencia de un aula fsica a una virtual, ni cambiar el gis y el pizarrn por un medio electrnico, o concentrar el contenido de una asignatura, en un texto que se lee en el monitor de la computadora. Se requiere que quienes participan en el diseo de estos ambientes deben conocer todos los recursos tecnolgicos disponibles (infraestructura, medios, recursos de informacin, etc.), as como las ventajas y limitaciones de stos para poder relacionar los con los objetivos, los contenidos, las estrategias y actividades de aprendizaje y la evaluacin. Los entornos en los cuales opera un AVA son: Conocimiento Experimentacin Colaboracin Gestin Asesora

Elementos de un ambiente virtual de aprendizaje Usuarios . Se refiere a QUIN va a aprender, a desarrollar competencias, a generar habilidades, es decir principalmente estudiantes y facilitadores. Currcula . Es el QU se va a aprender. Son los contenidos, el sustento, los programas de estudio curriculares y cursos de formacin. Especialistas Aqu est el CMO se va a aprender. Son los encargados de disear, desarrollar y materializar todos los contenidos educativos que se utilizarn en el AVA. Se integra por un grupo multidisciplinario que consta de: Pedagogo.

12

Administrador Diseador grafico. Programador. Especialista en tecnologa educativa. Corrector de estilo.

Fases de creacin de un ambiente virtual de aprendizaje. Fase I. Planeacin. Fase II. Diseo, desarrollo de los entornos y la produccin de los contenidos digitales. Fase III. Operacin.

3.2.6 Arquitectura de referencia para lneas de productos.

Definiciones de Lneas de Productos de Software Consiste de una familia de sistemas de software que tienen una funcionalidad comn y alguna funcionalidad variable. La funcionalidad comn descansa en el uso recurrente de un conjunto comn de activos reutilizables (requisitos, diseos, componentes, servicios web, etc.). Los activos son reutilizados por todos los miembros de la familia.

Figura 3.2.5.1 Modelo bsico de una lnea de productos de software

13

La entrada: Activos de Software . Una coleccin de partes de software (requisitos, diseos, componentes, casos de prueba, etc.) que se configuran y componen de una manera prescrita para producir los productos de la lnea. El control: Modelos de Decisin y Decisiones de Productos Los Modelos de Decisiones describen los aspectos variables y opcionales de los productos de la lnea. Cada producto de la lnea es definido por un conjunto de decisiones (decisiones del producto). El proceso de produccin Establece los mecanismos o pasos para componer y configurar productos a partir de los activos de entrada. Las decisiones del producto se usan para determinar que activos de entrada utilizar y como configurar los puntos de variacin de esos activos. La salida: Productos de software Conjunto de todos los productos que pueden o son producidos por la lnea de Productos. Lneas de productos de software La entrega de productos de software busca una manera: Las lneas de produccin producen mejoras en: Tiempo de entrega del producto (time to market). Costos de ingeniera. Tamao del portafolio de productos. Reduccin de las tasas de defectos. Calidad de los productos. Ms rpida. Econmica. Con una mejor calidad.

14

El objetivo principal de una LPS es: Reducir el tiempo, esfuerzo, costo y complejidad de crear y mantener los productos de la lnea mediante: La capitalizacin de los aspectos comunes de la lnea de Productos, a travs de la consolidacin y reutilizacin de los activos de entrada a la lnea. El manejo de los aspectos variables de los productos de la lnea a travs de los puntos de variacin de los activos y los modelos de decisin.

UNIDAD 4 PRUEBAS DE SOFTWARE 4.1 DEFINICIONES

4.1.1.- Pruebas, Caso de Prueba de Defecto, Falla , Error, Verificacin y Validacin.

Pruebas (test): Es una actividad en la cual un sistema o uno de sus componentes se ejecutan para verificar el funcionamiento de un proceso, los resultados se observan y registran para realizar una evolucin de dicho proceso. Referente a la programacin una prueba de software, en ingls testing son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementacin. Caso de prueba (test case): Un conjunto de entradas, condiciones de ejecucin y resultados esperados desarrollados para un objetivo particular, un caso de prueba es utilizado por el analista para determinar si el requisito de una aplicacin es parcial o completamente satisfactorio. Defecto (defect, fault, bug):

15

Un defecto de software, es el resultado de un fallo o deficiencia durante el proceso de creacin de programas de ordenador o computadora u otro dispositivo. Por ejemplo, un proceso, una definicin de datos o un paso de procesamiento incorrectos en un programa. Error (error): Es una equivocacin cometida por un desarrollador. Algunos ejemplos de errores son: un error de tipeo, una malinterpretacin de un requerimiento o de la funcionalidad de un mtodo, una accin humana que conduce a un resultado incorrecto. Por ejemplo: Divisiones entre cero. Es una tipo de manifestacin del defecto en el sistema que se ejecuta. Falla (failure): Puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los ms evidentes se dan en la etapa de desarrollo y programacin. Es la incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados. Verificacin: La verificacin del software es el proceso a travs del cual se analiza y revisa que el software satisfaga los objetivos propuestos al inicio del desarrollo. Validacin: El proceso de evaluacin de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario.

4.1.2 Relacin entre defecto-falla y error.

16

Figura 4.1 Relacin entre error defecto y falla Un error puede conducir a uno o ms defectos. Un defecto se encuentra en un artefacto y puede definirse como una diferencia entre la versin correcta del artefacto y una versin incorrecta. Un defecto es haber utilizado el operador < en vez de <=. En este caso una falla es la discrepancia visible que se produce al ejecutar un programa con un defecto, respecto a la ejecucin del programa correcto. Es decir, una falla es el sntoma de un defecto. Por ejemplo: una consulta que no arroje ningn resultado.

4.1.3 Pruebas estructurales, funcionales y aleatorias.

El objetivo de las pruebas es la deteccin de defectos en el software (descubrir un error es el xito de una prueba) Existen tres enfoques principales para el diseo de casos o pruebas. A. El enfoque estructural o de caja blanca. Se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un mdulo. Las pruebas de caja blanca estn

17

dirigidas a las funciones internas. Entre las tcnicas usadas se encuentran: La cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecucin). Pruebas sobre las expresiones lgico-aritmticas. Pruebas de camino de datos (definicin-uso de variables). Comprobacin de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego para las iteraciones mximas, mximas menos uno y ms uno).

Figura 4.2 Caja blaca B. El enfoque funcional o de caja negra. Se centra en las funciones, entradas y salidas. Se centra en las funciones, entradas y salidas. Intenta encontrar errores de las siguientes categoras: Funciones Incorrecta o ausente. Errores de Interfaz. Errores en estructuras de datos o acceso a base de datos externas. Errores de rendimiento. Errores de inicializacin y de terminacin

18

Figura 4.3 Caja negra C. PRUEBAS ALEATORIAS En las pruebas aleatorias simulamos la entrada habitual del programa creando datos de entrada en la secuencia y con la frecuencia con las que podran aparecer en la Prctica (de manera repetitiva). Para ello habitualmente se utilizan generadores automticos de casos de prueba. Consiste en utilizar modelos (en muchas ocasiones estadsticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba CRITERIOS DE COBERTURA LGICA Cobertura de sentencias. Se trata de generar los casos de prueba necesarios para que cada sentencia o instruccin del programa se ejecute al menos una vez. Cobertura de decisiones. Consiste en escribir casos suficientes para que cada decisin tenga, por lo menos una vez, un resultado verdadero y, al menos una vez, uno falso. (Incluye a la cobertura de sentencias) Cobertura de condiciones. Se trata de disear tantos casos como sea necesario para que cada condicin de cada decisin adopte el valor verdadero al menos una vez y el falso al menos una vez. (No incluye cobertura de condiciones) obligando a que se cumpla tambin el criterio de decisiones. Criterio de condicin mltiple. En el caso de que se considere que la evaluacin Criterio de decisin/condicin. Consiste en exigir el criterio de cobertura de condiciones

19

de las condiciones de cada decisin no se realiza de forma simultnea, se puede considerar que cada decisin multicondicional se descompone en varias condiciones unicondicionales. Ejemplo en la siguiente diapositiva. Criterio de cobertura de caminos. Se recorren todos los caminos (impracticable).

4.1.4 Documentacin del diseo de las pruebas.

Se compone de los siguientes pasos: Plan De Pruebas Seala el enfoque, los recursos y el esquema de actividades de prueba, as como los elementos a probar, las caractersticas, las actividades de prueba, el personal responsable y los riesgos asociados. Especificacin Del Diseo De Pruebas Especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e identificar las caractersticas que se deben probar con este diseo de pruebas. Especificacin De Caso De Prueba Define uno de los casos de prueba identificando por una especificacin del diseo de las pruebas. Especificacin De Procedimiento De Prueba Especificar los pasos para la ejecucin de un conjunto de casos de prueba o, ms generalmente, los pasos utilizados para analizar un elemento software con el propsito de evaluar un conjunto de caractersticas del mismo. Estructura de los pasos fijada en el estndar

20

Plan de Pruebas 1. Identificador nico del documento 2. Introduccin y resumen de elementos y caractersticas a probar 3. Elementos software a probar 4. Caractersticas a probar 5. Caractersticas que no se probarn 6. Enfoque general de la prueba 7. Criterios de paso/fallo para cada elemento 8. Criterios de suspensin y requisitos de reanudacin 9. Documentos a entregar 10. Actividades de preparacin y ejecucin de pruebas 11. Necesidades de entorno 12. Responsabilidades en la organizacin y realizacin de las pruebas 13. Necesidades de personal y formacin 14. Esquema de tiempos 15. Riesgos asumidos por el plan y planes de contingencias Especificacin del diseo de pruebas Identificador nico para la especificacin. Proporcionar tambin una referencia del plan asociado (si existe) Caractersticas a probar de los elementos software (y combinaciones de caractersticas) Detalles sobre el plan de pruebas del que surge este diseo, incluyendo las tcnicas de prueba especfica y los mtodos de anlisis de resultados Especificacin de caso de prueba Elementos software (por ejemplo, mdulos) que se van a probar: definir dichos elementos y las caractersticas que ejercitar este caso

21

 Especificaciones de cada entrada requerida para ejecutar el caso (incluyendo las relaciones entre las diversas entradas; por ejemplo, la sincronizacin de las mismas) Especificaciones de todas las salidas y las caractersticas requeridas (por ejemplo, el tiempo respuesta) para los elementos que se van a probar Necesidades de entorno (hardware, software y otras como, por ejemplo, el personal)

Especificacin De Procedimiento De Prueba Identificador nico de la especificacin y referencia a la correspondiente especificacin de diseo de prueba Objetivo del procedimiento y lista de casos que se ejecutan con l Requisitos especiales para la ejecucin (por ejemplo, entorno especial o personal especial) Pasos en el procedimiento. Adems de la manera de registrar los resultados y los incidentes de la ejecucin, se debe especificar: La secuencia necesaria de acciones para preparar la ejecucin Acciones necesarias para empezar la ejecucin Acciones necesarias durante la ejecucin Cmo se realizarn las medidas ( por ejemplo, el tiempo de respuesta) Acciones necesarias para suspender la prueba (cuando los

acontecimientos no previstos lo obliguen) Puntos para reinicio de la ejecucin y acciones necesarias para el reinicio en estos puntos

22

 Acciones necesarias para detener ordenadamente la ejecucin Acciones necesarias para restaurar el entorno y dejarlo en la situacin existente antes de las pruebas Acciones necesarias para tratar los acontecimientos anmalos.

4.4 Especificacin

4.2 PROCESO DE PRUEBAS

23

4.2.1 Proceso de pruebas

4.2.1 Generar un plan de pruebas

El propsito del plan de pruebas es explicitar el alcance, enfoque, recursos requeridos, calendario, responsables y manejo de riesgos de un proceso de pruebas. Note que puede haber un plan global que explicite el nfasis a realizar sobre los distintos tipos de pruebas (verificacin, integracin e integracin). Un plan de pruebas incluye: 1. Identificador del plan.

Preferiblemente de alguna forma mnemnica que permita relacionarlo con su alcance, por ej. TP-Global (plan global del proceso de pruebas), TP-ReqSeguridad1 (plan de verificacin del requerimiento 1 de seguridad), TP-Contr-X (plan de verificacin del contrato asociado al evento de sistema X), TP-UnitDespachador.iniciar (plan de prueba unitario para el mtodo iniciar de la clase Despachador). Como todo artefacto del desarrollo, est sujeto a control de configuracin, por lo que debe distinguirse adicionalmente la versin y fecha del plan. 2. Alcance

24

Indica el tipo de prueba y las propiedades/elementos del software a ser probado. 3. Items a probar

Indica la configuracin a probar y las condiciones mnimas que debe cumplir para comenzar a aplicarle el plan. Por un lado, es difcil y riesgoso probar una configuracin que an reporta fallas; por otro lado, si esperamos a que todos los mdulos estn perfectos, puede que detectemos fallas graves demasiado tarde. 4. Estrategia

Describe la tcnica, patrn y/o herramientas a utilizarse en el diseo de los casos de prueba. Por ejemplo, en el caso de pruebas unitarias de un procedimiento, esta seccin podra indicar: "Se aplicar la estrategia caja-negra de fronteras de la precondicin" o "Ejercicio de los caminos ciclomticos vlidos". En lo posible la estrategia debe precisar el nmero mnimo de casos de prueba a disear, por ej. 100% de las fronteras, 60% de los caminos ciclomticos... La estrategia tambin explicita el grado de automatizacin que se exigir, tanto para la generacin de casos de prueba como para su ejecucin. 5. Categorizacin de la configuracin o Suspendido, o Repetido; o Culminado. En algunas circunstancias (las cuales deben ser explicitadas) el proceso de prueba debe suspenderse en vista de los defectos o fallas que se han detectado. Al corregirse los defectos, el proceso de prueba previsto por el plan puede continuar, pero debe explicitarse a partir de qu punto, ya que puede ser necesario repetir algunas pruebas. Los criterios de culminacin pueden ser tan

Explicita las condiciones bajo las cuales, el plan debe ser:

25

simples como aprobar el nmero mnimo de casos de prueba diseados o tan complejos como tomar en cuenta no slo el nmero mnimo, sino tambin el tiempo previsto para las pruebas y la tasa de deteccin de fallas. 6. Tangibles

Explicita los documentos a entregarse al culminar el proceso previsto por el plan p. ej. subplanes, especificacin de pruebas, casos de prueba, resumen gerencial del proceso y bitcora de pruebas. 7. Procedimientos especiales

Identifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas, as como cualquier habilidad especial que se requiere. 8. Recursos

Especifica las propiedades necesarias y deseables del ambiente de prueba, incluyendo las caractersticas del hardware, el software de sistemas (p. ej. el sistema de operacin), cualquier otro software necesario para llevar a cabo las pruebas, as como la colocacin especfica del software a probar (p. ej. qu mdulos se colocan en qu mquinas de una red local) y la configuracin del software de apoyo. La seccin incluye un estimado de los recursos humanos necesarios para el proceso. Tambin se indican cualquier requerimiento especial del proceso: actualizacin de licencias, espacio de oficina, tiempo en la mquina de produccin, seguridad. 9. Calendario

Esta seccin describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar. 10. Manejo de riesgos

Explicita los riesgos del plan, las acciones mitigantes y de contigencia.

26

11. plan.

Responsables

Especifica quin es el responsable de cada una de las tareas previstas en el El diseo de casos de prueba est

4.2.2 Disear pruebas especficas.

El diseo de caos de prueba est totalmente mediatizado por la imposibilidad de probar exhaustivamente el software. Pensemos en un programa muy sencillo que slo suma dos nmeros enteros de dos cifras (del 0 al 99). Si quisiramos probar, simplemente, todos los valores vlidos que se pueden sumar, deberamos probar 10.000 combinaciones distintas de cien posibles nmeros del primer sumando y cien del segundo. Pensemos que an quedaran por probar todas las posibilidades de error al introducir los datos (por ejemplo, teclear una letra en vez de un nmero). La conclusin es que, si para un programa tan elemental debemos realizar tantas pruebas, pensemos en lo que supondra un programa medio. En consecuencia, las tcnicas de diseo de casos de prueba tienen como objetivo conseguir una confianza aceptable en que se detectarn los defectos existentes (ya que la seguridad total slo puede obtenerse de la prueba exhaustiva, que no es practicable) sin necesidad de consumir una cantidad excesiva de recursos (por ejemplo, tiempo para probar o tiempo de ejecucin). Toda la disciplina de pruebas debe moverse, por lo tanto, en un equilibrio entre la disponibilidad de recursos y la confianza que aportan los casos para descubrir los defectos existentes. Este equilibrio no es sencillo, lo que convierte a las pruebas en una disciplina difcil que est lejos de parecerse a la imagen de actividad rutinaria que suele sugerir. Ya que no se pueden probar todas las posibilidades de funcionamiento del software, la idea fundamental para el diseo de casos de prueba consiste en

27

elegir algunas de ellas que, por sus caractersticas, se consideren representativas del resto. As, se asume que, si no se detectan defectos en el software al ejecutar dichos casos, podemos tener un cierto nivel de confianza (que depende de la eleccin de los casos) en que el programa no tiene defectos. La dificultad de esta idea es saber elegir los casos que se deben ejecutar. De hecho, una eleccin puramente aleatoria no proporciona demasiada confianza en que se puedan detectar todos los defectos existentes. Por ejemplo, en el caso del programa de suma de dos nmeros, elegir cuatro pares de sumandos al azar no aporta mucha seguridad a la prueba (una probabilidad de 4/10.000 de cobertura de posibilidades). Por eso es necesario recurrir a ciertos criterios de eleccin que veremos a continuacin. Existen tres enfoques principales para el diseo de casos: El enfoque estructural o de caja blanca El enfoque funcional o de caja negra El enfoque aleatorio. Estos enfoques no son excluyentes entre s, ya que se pueden combinar para conseguir una deteccin de defectos ms eficaz. Veremos a continuacin una presentacin de cada uno de ellos. Pruebas de caja blanca Este mtodo de casos de prueba usa los detalles procedimentales del programa. Se busca obtener casos de prueba que: Garanticen que se ejecuta por lo menos una vez todos los caminos independientes de cada mdulo. Verificar las decisiones lgicas (V/F). Ejecutar las condiciones en sus lmites. Ejecutar las estructuras internas de datos para asegurar su validez. Prueba de camino bsico

28

o Notacin de grafo de flujo o Complejidad ciclomtica o Obtencin de casos de prueba o Matrices de grafos Prueba de la estructura de control o Prueba de condicin o Prueba de flujo de datos o Prueba de bucles PRUEBA DEL CAMINO BSICO Es una tcnica de prueba de caja blanca que nos permite obtener una medida de complejidad lgica. Con la medida de complejidad se genera un conjunto bsico de caminos que se ejecutan por lo menos una vez durante la ejecucin del programa. Obtencin de casos de prueba 1) Dibujar el grafo correspondiente 2) Determinar la complejidad. 3) Determinar un conjunto bsico de caminos linealmente independientes 4) Preparar casos de prueba que forzarn a la ejecucin de cada camino bsico. PRUEBAS DE CAJA NEGRA Mtodos de prueba basados en grafos Particin equivalente Anlisis de valores lmites Prueba de comparacin Este tipo de prueba se centra en los requisitos funcionales del software y permite obtener entradas que prueben todos los requisitos funcionales del

29

programa. Con este tipo de pruebas se intenta encontrar: 1) Funciones incorrectas o ausentes. 2) Errores de interfaz 3) Errores en estructuras de datos o en accesos a bases de datos externas. 4) Errores de rendimiento. 5) Errores de inicializacin y terminacin Con la aplicacin de esta tcnica se obtiene un conjunto de pruebas que: a. Reduce el nmero de casos de pruebas b. Nos dicen algo sobre la presencia o ausencia de errores. PRUEBA DE COMPARACIN Esta tcnica consiste en la comparacin de salidas de un mismo software pero de sus diferentes versiones. Cuando se han producido mltiples implementaciones de la misma especificacin, a cada versin del software se le proporciona como entrada los casos de prueba diseados para la otra. Si las salidas de distintas versiones son idnticas entonces todas las implementaciones son correctas. Si la salida es diferente, se revisan las aplicaciones para determinar el defecto. Esta prueba no es infalible

4.2.3 Tomar Configuracin del Software a Probar

Los cambios dentro del desarrollo del software pueden ocurrir en cualquier momento por lo tanto debemos estar preparados, las actividades de CGS sirven para: Identificar el cambio de nuestro software. Controlar ese cambio. Garantizar que el cambio quede bien implantado. Informar el cambio.

30

La gestin de configuracin del software no es un mantenimiento del software, el mantenimiento es la etapa final de la ingeniera hasta que se retire el producto del equipo, la CGS es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de desarrollo del software y termina slo una vez que el software queda fuera de circulacin. Desgraciadamente, en el proceso de ingeniera del software existe una variable importantsima que entra en juego, el cambio. La primera Ley de la ingeniera de sistemas establece: Sin importar en que momento del ciclo de vida del sistema nos encontremos, el sistema cambiar y el deseo de cambiarlo persistir a lo largo de todo el ciclo de vida. Entonces nos hacemos diferentes preguntas: Por qu cambiar el sistema? Que produce los en el sistema cambios? La respuesta a estas interrogantes se puede encontrar en cuatro aspectos fundamentales y a menudo muy tradicionales dentro del desarrollo del software: Nuevos requisitos del negocio o condiciones que dictan los cambios en las condiciones del producto o en las normas comerciales. Nuevas necesidades del los clientes que demandan la modificacin de los datos producidos por un sistema basado en computadora. Reorganizacin y/o reduccin del volumen comercial que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniera del software. Restricciones presupuestarias o de planificaciones que provocan una redefinicin del sistema o del producto. La gestin de configuracin del software realiza un conjunto de actividades desarrolladas para gestionar y registrar los cambios a lo largo del ciclo de vida del software de computadora. La GCS es una actividad de garanta de calidad del software que se aplica en todas las fases del proceso de ingeniera del software.

31

4.2.4 Configurar las Pruebas

Pruebas de carga Este es el tipo ms sencillo de pruebas de rendimiento. Una prueba de carga se realiza generalmente para observar el comportamiento de una aplicacin bajo una cantidad de peticiones esperada. Esta carga puede ser el nmero esperado de usuarios concurrentes utilizando la aplicacin y que realizan un nmero especfico de transacciones durante el tiempo que dura la carga. Esta prueba puede mostrar los tiempos de respuesta de todas las transacciones importantes de la aplicacin. Si la base de datos, el servidor de aplicaciones, etc tambin se monitorizan, entonces esta prueba puede mostrar el cuello de botella en la aplicacin. Prueba de estrs Esta prueba se utiliza normalmente para romper la aplicacin. Se va doblando el nmero de usuarios que se agregan a la aplicacin y se ejecuta una prueba de carga hasta que se rompe. Este tipo de prueba se realiza para determinar la solidez de la aplicacin en los momentos de carga extrema y ayuda a los administradores para determinar si la aplicacin rendir lo suficiente en caso de que la carga real supere a la carga esperada. Prueba de estabilidad (soak testing) Esta prueba normalmente se hace para determinar si la aplicacin puede aguantar una carga esperada continuada. Generalmente esta prueba se realiza para determinar si hay alguna fuga de memoria en la aplicacin. Pruebas de picos (spike testing) La prueba de picos, como el nombre sugiere, trata de observar el comportamiento del sistema variando el nmero de usuarios, tanto cuando bajan, como cuando tiene cambios drsticos en su carga. Esta prueba se

32

recomienda que sea realizada con un software automatizado que permita realizar cambios en el nmero de usuarios mientras que los administradores llevan un registro de los valores a ser monitorizados.

Pre-requisitos para las pruebas de carga Un desarrollo estable de la aplicacin instalado en un entorno lo ms parecido al de produccin. El entorno de pruebas de rendimiento no debe cruzarse con pruebas de aceptacin de usuarios ni con el entorno de desarrollo. Esto es tan peligroso que si las pruebas de aceptacin de usuarios, o las pruebas de integracin o cualquier otra prueba se ejecutan en el mismo entorno, entonces los resultados no son fiables. Como buena prctica, siempre es aconsejable disponer de un entorno de pruebas de rendimiento lo ms parecido como se pueda al entorno de produccin.

4.2.5 Evaluar resultados

Mediante esta evaluacin se miden los resultados del programa para ver si tuvo xito. Usan ahora el casco ms personas que antes?? La medicin de un cambio en los resultados es probablemente la forma ms comn de evaluacin, ya que permite conocer si el programa hacer. hace lo que tiene que

4.2.5.1 Depuracin.
La depuracin es el proceso de identificar la raz de un error y corregirlo. Difiere de la prueba, la cual es el proceso mediante el cual se detecta inicialmente el error.

La depuracin puede representar hasta el 50% del tiempo de desarrollo de un programa. Para muchos programadores -especialmente para los principiantes -

33

es la parte ms difcil de la programacin. Pero la depuracin no tiene que ser la parte ms difcil. Si sigues las guas y consejos de este documento, tendrs menos errores que depurar. La mayora de los que tendrs sern olvidos o fallas mecanogrficas, fcilmente detectables mediante la observacin del cdigo o su seguimiento con un depurador. Para el resto que queden, los ms serios, los tips y tcnicas que se describen en este documento sern suficientes para que su depuracin resulte ms fcil. El Rol de la Depuracin en la Calidad del Software Como la prueba, la depuracin no es en s una forma de mejorar la calidad de tu software; es una manera de diagnosticar errores. La calidad del software debe integrarse desde el inicio del proceso de programacin. La mejor manera de construir software de calidad es desarrollar cuidadosamente los requerimientos, disear bien, y usar prcticas de codificacin de alta calidad. La depuracin es el ltimo recurso. Por Qu es Importante la Depuracin? Desafortunadamente la depuracin es un rea a la que se da poca importancia en los cursos y libros de programacin. Se nos ensea teora y tcnicas para a crear cosas, pero no a asegurar su calidad. El problema principal del software actual en el mundo entero es que los programas no son 100% confiables por contener demasiados bugs, lo que habla de su mala calidad. Esta calidad no se garantiza en parte por el stress del mundo competitivo de hoy, pero principalmente por el poco nfasis que se pone en la enseanza, donde no se presta la suficiente atencin o no se cubren tpicos como el diseo, el estilo de codificacin, la documentacin, y en particular tcnicas y herramientas para la realizacin eficiente y efectiva de la depuracin.

Gua de Cmo *NO* Debes Depurar

34

En los siguientes prrafos se mencionan las cosas que nunca deben hacer al depurar. A partir de ellas construiremos la lista de tips y tcnicas para realizar eficazmente el proceso de la depuracin

Encuentra los errores adivinando Para encontrar el error, disemina sentencias de impresin aleatoriamente por todo el programa. Examina la salida para ver dnde est el error. Si no puedes encontrarlos de este modo, intenta cambiar cosas hasta que algo parezca funcionar. No respaldes la versin original del programa, y no guardes registro de los cambios que hagas. La programacin es ms excitante si no ests muy seguro de lo que el programa est haciendo. No pierdas tiempo intentando comprender el problema Es probable que el problema sea trivial, y no necesites comprenderlo. Simplemente encontrarlo bastar. Adems, es probable que desaparezca por si solo. Corrige el error de la manera ms obvia Usualmente es bueno solo corregir el problema especfico que observas en vez de perder tiempo haciendo una modificacin grande y ambiciosa que vaya a afectar a todo el programa.

35

Figura 4.1 Corrige el error de la manera ms obvia

La depuracin consta de dos fases: encontrar el error y corregirlo. Encontrar el error (y comprenderlo) es usualmente el 90 porciento del trabajo.

4.2.5.2 Anlisis de errores.

Sirve para realizar predicciones de la fiabilidad del software y para detectar las causas ms habituales de error y por tanto mejorar los procesos de desarrollo. El objetivo del anlisis causal es proporcionar informacin sobre la naturaleza de los defectos. Para ello es fundamental recoger para cada defecto detectado esta informacin:

36

Figura 4.2.5.2 Los Errores Son Oportunidades de Mejorar Como Programador Asumiendo que no deseas que tus programas tengan errores, tenerlos significa que no comprendes por completo el problema que intentas resolver o lo que hace tu programa. Y esto es desconcertante (unsettling). Despus de todo, si t creaste el programa, l debera hacer lo que deseas que haga. Si no sabes exactamente qu problema ests solucionando o qu le ests diciendo a la computadora que haga, resta poco para que pruebes diferentes cosas hasta que algo funcione. Esto es programar por prueba y error y ello garantiza ms errores. No necesitas aprender cmo corregir errores; necesitas aprender cmo evitarlos oportunidad para: Aprender sobre el problema o programa en que ests trabajando Si comprendieras por completo el problema o programa no tendras ese error. Ya lo hubieras corregido. Aprender sobre los tipos de errores que cometes Si t escribiste el programa, t insertaste el error. Una vez que lo encuentras pregntate por qu lo cometiste? Cmo lo hubieras encontrado ms rpido? Cmo lo hubieras prevenido? Existen en el cdigo otros errores como se? Puedes tiene corregirlos antes de que que causen problemas? leerlo Aprender sobre la calidad de tu cdigo desde el punto de vista de quien Tendrs que leer el cdigo para encontrar el error. Esta es una oportunidad de oro para ver con sentido crtico si tiene calidad. Es fcil leerlo? Cmo puedes mejorarlo? Usa tus descubrimientos para refactorizar el cdigo o para mejorar el que escribas en el futuro. Aprender sobre cmo resolver problemas en primera instancia. En cualquier caso, un error en tu programa representa una excelente

37

Tu tcnica de depuracin te da confianza? Funciona? Encuentras el error rpidamente? O es una debilidad tuya como programador? Sientes angustia y frustracin? Adivinas al azar dnde pueden estar los errores? Necesitas mejorar? Considerando la gran cantidad de tiempo que inviertes en la depuracin, definitivamente no desperdiciars tiempo si observas cmo depuras. Tomarte el tiempo para analizar y cambiar la forma en que depuras puede ser la forma ms rpida de reducir la cantidad total de tiempo que te toma desarrollar un programa. Aprender sobre cmo corriges los errores Adems de aprender cmo encuentras los errores, puedes aprender cmo corregirlos. Realizas las correcciones ms rpidas parchando el cdigo con sentencias goto y cdigo para casos especiales que cambian los sntomas pero no el problema? O haces correcciones sistemticas, que demandan un diagnstico exacto y un tratamiento que va directo al ncleo del problema?

4.3 TECNICAS DE DISEO DE CASOS DE PRUEBAS

Un producto puede probarse siguiendo dos criterios: Conocimiento del funcionamiento del producto (Caja blanca). El conocimiento de la funcin especfica para la que fue diseado el producto (Caja negra). CRITERIOS DE REALIZACIN DE PRUEBAS Para llevar a cabo la verificacin del comportamiento de un sistema pueden servirse 2 criterios: Descendente Ascendente

38

 Prueba Descendente empieza a nivel de sistema, prueba los mdulos y por ultimo las funciones que conforman. Utiliza un programa esclavo. Prueba Ascendente da inicio la verificacin de funciones hasta llegar al nivel superior del sistema. Utiliza un programa conductor para cada modulo a probar. Datos de prueba: Representativos (datos comunes) Incorrectos, incompletos e incongruentes

CLASES DE PRUEBA
Tipos de prueba lgico-simulado Estocsticos Real Controlada Consideraciones Costo de preparacin muy baja bajo medio alto Nivel de confiabilidad Bajo bajo medio medio-alto

Figura 4.2 Clases de prueba

4.4 ENFOQUE PRACTICO RECOMENDADO PARA EL DISEO DE CASOS

Se propone un uso ms apropiado de cada tcnica (caja blanca y negra) para obtener un conjunto de casos tiles: Si la especificacin contiene combinaciones de condiciones de entrada, comenzar formando sus grafos de causa-efecto(ayudan a la comprensin de dichas combinaciones)

39

En todos los casos, usar el anlisis de valores lmites para aadir casos de prueba: elegir lmites para dar valores a las causas en los casos generados asumiendo que cada causa es una clase de equivalencia.

Identificar las clases vlidas y no vlidas de equivalencia para la entrada y la salida, y aadir los casos no incluidos anteriormente

Utilizar la tcnica de conjetura de errores para aadir nuevos casos, referidos a valores especiales

Ejecutar los casos generados hasta el momento y analizar la cobertura obtenida

Examinar la lgica del programa para aadir los casos precisos (de caja blanca) para cumplir el criterio de cobertura elegido si los resultados de la ejecucin del punto anterior indican que no se ha satisfecho el criterio de cobertura elegido.

4.5 ESTRATEGIAS DE APLICACIN DE APLICACIN DE LAS PRUEBAS

Proporcionan un plano o gua para el desarrollador del software, para la organizacin de control de calidad y para el cliente. Es una gua que describe los pasos a llevar a cabo como parte de la prueba, cundo se deben planificar y realizar esos pasos, y cunto esfuerzo, tiempo y recursos se van a requerir. Por lo tanto, cualquier estrategia de prueba debe incorporar la planificacin de la prueba, el diseo de los casos de prueba, la ejecucin de las pruebas y la agrupacin y evaluacin de los datos resultantes.

40

Estrategias de prueba del software: Prueba de unidad, Prueba de integracin, Prueba de validacin, Prueba del sistema

4.5.1 De unidad
Centra el proceso de verificacin en la menor unidad del diseo del software - el mdulo. Usando la descripcin del diseo detallado como gua, se prueban caminos de control importantes, con el fin de descubrir errores dentro del mbito del mdulo. Est orientada a la caja blanca Puede llevarse a cabo en paralelo para mltiples mdulos.

CONSIDERACIONES SOBRE LA PRUEBA DE UNIDAD Las pruebas que se dan como parte de la prueba de unidad son: Se prueba la interfaz del mdulo. Se examinan las estructuras de datos locales. Se prueban las condiciones lmites. Se ejercitan todos los caminos independientes de la estructura de control. Y finalmente, se prueban todos los caminos de manejo de errores. Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la interfaz del mdulo.

41

4.5.2 De integracin
Es una tcnica sistemtica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interaccin. El objetivo es tomar los mdulos probados en unidad y construir una estructura de programa que est de acuerdo con lo que dicta el diseo. La integracin incremental, El programa se construye y se prueba en pequeos segmentos en los que los errores son ms fciles de aislar y de corregir, de esta forma es ms probable que se puedan probar completamente los interfaces y se puede aplicar un enfoque de prueba sistemtica. Hay estrategias de integracin incremental denominadas: Integracin descendente, Integracin ascendente.

A continuacin se deben ensamblar o integrar los mdulos para formar el paquete del software completo. La prueba de integracin se dirige a todos los aspectos asociados con el doble problema de verificacin y de construccin del programa. Las tcnicas que ms prevalecen son las de diseo de casos de prueba de caja negra La especificacin de prueba incluye un plan general para la integracin del software y una descripcin de las pruebas especficas. Es un resultado del proceso de ingeniera del software y forma parte de la configuracin del software. El alcance de la prueba resume las caractersticas funcionales, de rendimiento y de diseo interno especficas que van a a ser probadas. Se limita el esfuerzo de prueba, se describen los criterios de terminacin de cada fase de prueba y se documentan las limitaciones del plan.

42

4.5.3 De sistema
La prueba del sistema, realmente est constituida por una serie de pruebas diferentes cuyo propsito principal es ejercitar profundamente el sistema basado en computadora. Aunque cada prueba tiene un propsito distinto, todas trabajan para verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas

4.5.4 Prueba de aceptacin

se refiere principalmente a las fallas que puedan generarse en la implementacin del sistema

Figura 4.2 pruebas de aceptacin

UNIDAD 5 IMPLANTACION E IMPLEMENTACION 5.1 Implantacin e integracin de casos de uso y componentes de software
Modelos de calidad Segn el estndar ISO 8402 (1986), un modelo de calidad puede definirse

43

como el conjunto de factores de calidad, y de relaciones entre ellos, que proporciona una base para la especificacin de requisitos de calidad y para la evaluacin de la calidad de los componentes software. Los modelos de calidad se estructuran generalmente como una jerarqua (ya sea un rbol, ya sea un grafo dirigido), donde factores de calidad ms genricos, como eficiencia o usabilidad, se descomponen en otros ms particulares, como tiempo de respuesta o facilidad de aprendizaje, probablemente en diversos niveles de descomposicin. Los modelos de calidad pueden aplicarse en diversas actividades propias del DBSC: establecer los requisitos de calidad para la seleccin de un componente en base a los factores de calidad del modelo; evaluar la calidad de un componente para cada uno de los factores de calidad del modelo; comparar la calidad de distintos componentes respecto a los requisitos establecidos para un proceso de seleccin; y redactar contratos formales, donde aparezcan explcitamente las evaluaciones de calidad de los componentes que el proveedor certifica. Normalmente, los factores de calidad que aparecen en el modelo pueden utilizarse como checklist para todas aquellas cuestiones relacionadas con la calidad de los componentes. Desde que se formul el concepto de modelo de calidad, se han presentado mltiples propuestas. Dichas propuestas intentan resolver entre otros los interrogantes siguientes: Cules son los factores de calidad que deberan formar parte de un modelo de calidad de componentes software?; Cules son los tipos de factores de calidad en los que tiene sentido estructurar los modelos?; Cmo se estructuran los modelos?; Qu tipo de relaciones pueden existir entre los factores de calidad?; Cmo se evalan los factores de calidad? A continuacin se presenta una clasificacin de los tipos de modelos de

44

calidad, las propuestas de estndares de modelos de calidad ms usadas, y una descripcin y comparacin de las propiedades de las distintas propuestas

Propiedades de los modelos de calidad Del estudio de las diferentes propuestas de modelos de calidad existentes, se desprenden algunas propiedades estructurales importantes Nmero de capas En general, el nmero de capas de un modelo de calidad puede ser utilizado como una medida para determinar el nivel de detalle con el que el dominio de software para el cual ha sido construido: a ms niveles, mayor descomposicin y por tanto, una descripcin ms detallada del tipo de componente a evaluar. Los modelos a la medida tienden a estructurarse en jerarquas con ms niveles de descomposicin que los modelos fijos.

5.2 Mantenimiento del software

El Servicio de mantenimiento de software es una de las actividades en la Ingeniera de Software y es el proceso de mejorar y optimizar el software desplegado (revisin del programa), as como tambin remediar los defectos. El mantenimiento de software es tambin una de las fases en el Ciclo de Vida de Desarrollo de Sistemas (SDLC System Development Life Cycle), que se aplica al desarrollo de software. La fase de mantenimiento es la fase que viene despus del despliegue (implementacin) del software en el campo. La fase de mantenimiento de software involucra cambios al software en orden de corregir defectos y dependencias encontradas durante su uso tanto como la

45

adicin de nueva funcionalidad para mejorar la usabilidad y aplicabilidad del software

Tipos de mantenimiento A continuacin se sealan los tipos servicio de mantenimientos existentes, y entre parntesis el porcentaje aproximado respecto al total de operaciones de mantenimiento: Perfectivo (60%): Mejora del software ( rendimiento , flexibilidad , reusabilidad) o implementacin de nuevos requisitos. Tambin se conoce como mantenimiento evolutivo. Adaptativo (18%): Adaptacin del software a cambios en su entorno tecnolgico (nuevo hardware, otro sistema de gestin de bases de datos , otro sistema operativo ...) Correctivo (17%): Correccin de fallos detectados durante la explotacin. Preventivo (5%): Facilitar el mantenimiento futuro del sistema (verificar precondiciones, mejorar legibilidad...).

46

CONCLUSIN
Con los temas planteados en esta investigacin med cuenta que el desarrollo del software y la programacin es uno de los pilares fundamentales de la informtica y al cual se dedican muchas horas de esfuerzos en empresas, colegios, academias y universidades. Conforme a la tecnologa va avanzando, van apareciendo nuevas soluciones, nuevas formas de programacin, nuevos lenguajes y un sin fin de herramientas que intentan realizar el trabajo del desarrollador un poco mas fcil. La programacin orientadas a objetos o los compiladores basados en maquinas virtuales (en muchos casos, multiplataforma), tambin a sus puestos unas renovacin en la manera de programar. As hacer mencin de Microsoft como empresa desarrolladora se software, es consciente de lo importante que es hacer buenos desarrollos y lo complicado que es; por eso, intenta aportar las mejores soluciones al mercado. En la actualidad la sociedad se encuentra en una poca de transicin, que se encamina hacia un nuevo estilo de programacin basada en estndares y para ello Microsoft propone la plataforma .NET.

47

GLOSARIO
Unidad 3 Transicin: es una relacin entre dos estados, indica que, cuando ocurre un evento el objeto pasa del estado anterior al siguiente. (Cuando ocurre el evento levantar el auricular, el telfono realiza la transicin el estado ocioso al estado activo.) Interaccin: Podramos decir que es la disciplina que estudia el intercambio de informacin mediante software entre las personas y las computadoras. Componente: es una parte fsica y implementa un conjunto de interfaces. reemplazable de un sistema que

Nodo: es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional Sistemas de tiempo real: Es un sistema informtico que interacciona rpidamente con su entorno fsico y realiza funciones de supervisin y control. Diagrama Una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices conectados por arcos. Requisitos Los componentes pueden tener requisitos adjuntos para indicar sus obligaciones contractuales; esto es, qu servicios proveen en el modelo los requisitos ayudan a documentar el comportamiento Funcional de los elementos de software. Restricciones: Los componentes pueden restricciones asignadas que indican el entorno en el que operan. Nodo: un nodo es un punto de interseccin , conexin o unin de varios elementos que confluyen en el mismo lugar. Sincronizacion: Sincronizacin (del griego (sn), "unido" y

48

(chrnos), "tiempo", describe el ajuste temporal de eventos. Se habla de sincronizacin cuando determinados fenmenos ocurran en un orden predefinido o a la vez. WAP Wireless Application Protocol o WAP (protocolo de aplicaciones inalmbricas) es un estndar abierto internacional para aplicaciones que utilizan las comunicaciones inalmbricas, p.ej. acceso a servicios de Internet desde un telfono mvil. GSM La localizacin GSM es un servicio ofrecido por las empresas operadoras de telefona mvil que permite determinar, con una cierta precisin, donde se encuentra fsicamente un terminal mvil determinado. UMTS Sistema universal de telecomunicaciones mviles (Universal Mobile Telecommunications System o UMTS) es una de las tecnologas usadas por los mviles de tercera generacin, sucesora de GSM, debido a que la tecnologa GSM propiamente dicha no poda seguir un camino evolutivo para llegar a brindar servicios considerados de tercera generacin. Unidad 4 Solapamiento: un factor de calidad participa en la descomposicin jerrquica de varios otros de niveles superiores. Cabe citar que dicho factor puede evaluarse con mtricas diferentes para cada uno los factores que descompone. Transversalidad: es una relacin de solapamiento donde no slo cambia la mtrica, sino tambin la definicin. Este es el caso de las seis subcaractersticas de Cumplimiento asociadas a cada una de las caractersticas incluidas en el modelo de calidad del estndar ISO/IEC 9126-1 (2001). Dependencia: un factor de calidad se relaciona con otros factores, generalmente del mismo nivel. Por ejemplo, Chung et al. (2000) identifican diversos tipos de dependencia (makes, breaks, etc.) dependiendo del tipo de relacin (favorecer vs. perjudicar) y del grado de intensidad de la misma (total o parcial). El nmero de dependencias puede llegar a ser muy elevado, aunque como sealan Egyed y Grnbacher (2004), muchas de ellas pueden no ser relevantes.

49

Funcionalidad: Capacidad del producto software para proporcionar las funcionalidades que satisfacen las necesidades explicitas e implcitas cuando el software se usa bajo unas ciertas condiciones Adecuacin: Capacidad del producto software para proporcionar un conjunto de funciones apropiado para unas ciertas tareas y objetivos de usuario Exactitud: Capacidad del producto software para proporcionar los resultados o efectos correctos o acordados, con el grado necesario de precisin Interoperabilidad: Capacidad del producto software para interactuar con uno o ms sistemas Seguridad: Capacidad del producto software para proteger informacin y datos de manera que las personas o sistemas no autorizados no puedan leerlos o modificarlos, al tiempo que no se deniega el acceso a las personas o sistemas autorizados Cumplimiento funcional: Capacidad del producto software para adherirse a normas, convenciones o regulaciones en leyes y prescripciones similares relacionadas con la funcionalidad Fiabilidad: Capacidad del producto software para mantener un nivel especificado de prestaciones cuando se usa bajo unas cierta condiciones Madurez: Capacidad del producto software para evitar fallar como resultado de fallos en el software

FUENTES DE INFORMACIN
http://adimen.si.ehu.es/~rigau/teaching/EHU/ISHAS/Curs2007-

50

2008/Apunts/IS.14.pdf http://lsi.ugr.es/~ig1/docis/pruso.pdf www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r67850.PPT http://fcqi.tij.uabc.mx/usuarios/luisgmo/data/8.3%20prb-cal-mant.pdf Anlisis y diseo de sistemas de informacin (James A. Senn) Anlisis y diseo de sistemas (Kendall&Kendall) Ingeniera de Software (Roger S. Pressman) Diseo de sistemas de informacin Teora y Practica (John G. Burch)

51