INSTITUTO TECNOLGICO SUPERIOR DE TEPEACA

INGENIERIA EN SISTEMAS COMPUTACIONALES

DESARROLLO DE PROYECTOS DE SOFTWARE

ALUMNA: FUENTES SALOME ROSALBA LIZBETH

ING. INES LEON FLORES

25 ABRIL 2012

"Creatividad tecnolgica y calidad educativa, pilares para la excelencia humana

INDICE UNIDAD 1 CONCEPTOS INTRODUCTORIOS ................................................................. 4 1.1 LA ARQUITECTURA DE 4+1 VISTAS ....................................................................... 4 1.1.1 La vista lgica ....................................................................................................... 5 1.1.2 La vista de procesos............................................................................................. 6 1.1.3 Vista de Desarrollo ............................................................................................... 7 1.1.4 Arquitectura Fsica ............................................................................................... 8 1.2 DESARROLLO ORIENTADO A OBJETOS ................................................................ 9 1.2.2 Ejemplos de objetos ............................................................................................. 11 1.3 DIAGRAMACIN ...................................................................................................... 11 UNIDAD 2 DISEO ORIENTADO A OBJETOS.............................................................. 14 2.1 DISEO DEL SISTEMA EN BASE A PROCESOS ................................................... 14 2.1.1 Actividades y casos de uso ................................................................................. 14 2.1.2 Interfaces de usuario ............................................................................................ 16 2.2 DISEO DE LA LGICA........................................................................................... 17 2.2.1 Clases y Objetos ................................................................................................. 17 2.2.1 Representacin visual de un objeto .................................................................. 18 2.2.2 Definicin de la clase bicicleta ....................................................................... 18 2.2.2 Interaccin........................................................................................................... 19 2.2.3 Estados y transiciones. ...................................................................................... 19 UNIDAD 3 CONSTRUCCIN ........................................................................................ 20 3.1 DESPLIEGUE DE COMPONENTES Y ARQUITECTNICO ..................................... 20 3.2 TCNICAS DE DESARROLLO DE LAS ARQUITECTURAS DE REFERENCIA EN DIFERENTES DOMINIOS. ........................................................................................... 21 3.2.1 Diagrama de componentes ................................................................................ 22 3.2.1 Modelos de componentes .................................................................................. 21 3.2.2 Arquitectura de referencia para sistemas de tiempo real fuente de alimentacin ............................................................................................................... 23 3.2.3 Arquitectura de Referencia para Sistemas Mviles con Conexin a Internet ............. 23 3.2.4 Arquitectura de referencia para sistemas de informacin ............................... 24 3.2.5 Arquitectura de referencia para ambientes virtuales de aprendizaje. ............. 25 3.2.6 Arquitectura de referencia para lneas de productos. ...................................... 26 UNIDAD 4 PRUEBAS DE SOFTWARE .......................................................................... 28 4.1 DEFINICIONES ......................................................................................................... 28 4.1.1.- Pruebas, Caso de Prueba de Defecto, Falla , Error, Verificacin y Validacin. ..................................................................................................................................... 28 4.1.2 Relacin entre defecto-falla y error. .................................................................. 29 4.1.3 Pruebas estructurales, funcionales y aleatorias. ............................................. 30 4.1.4 Documentacin del diseo de las pruebas. ...................................................... 32 4.2 PROCESO DE PRUEBAS......................................................................................... 34 4.2.1 Generar un plan de pruebas............................................................................... 35 4.2.1 Proceso de pruebas ............................................................................................ 35 4.2.2 Disear pruebas especficas. ............................................................................. 37 4.2.3 Tomar Configuracin del Software a Probar .................................................... 39 2

4.2.4 Configurar las Pruebas....................................................................................... 40 4.2.5 Evaluar resultados .............................................................................................. 41 4.2.5.1 Depuracin. ................................................................................................... 41 4.2.5.2 Anlisis de errores. ....................................................................................... 43 4.3 TECNICAS DE DISEO DE CASOS DE PRUEBAS ................................................ 45 4.4 ENFOQUE PRACTICO RECOMENDADO PARA EL DISEO DE CASOS .............. 46 4.5 ESTRATEGIAS DE APLICACIN DE APLICACIN DE LAS PRUEBAS ............... 47 4.5.1 De unidad ............................................................................................................ 47 4.5.3 DE SISTEMA ........................................................................................................ 48 4.5.4 PRUEBA DE ACEPTACIN ................................................................................ 49 UNIDAD 5 IMPLANTACION E IMPLEMENTACION ....................................................... 49 5.1 Implantacin e integracin de casos de uso y componentes de software .......... 49 5.2 Mantenimiento del software .................................................................................... 50 GLOSARIO ..................................................................................................................... 52 FUENTES DE INFORMACIN........................................................................................ 54
NDICE DE IMGENES Figura 1.1 Modelo de 4+1 vistas................................................................................................... 5 Figura 1.1.1 Notacin para la vista lgica....................................................................................... 6 Figura 1.1.2 Notacin para el diagrama de procesos. ................................................................... 7 Figura 1.1.3 Diagrama parcial de procesos .................................................................................... 8 Figura 1.1.4 Notacin para el diagrama de desarrollo .................................................................. 9 Figura 1.1.5 Notacin para el diagrama fsico. ......................................................................... 9, 10 Figura 1.2.1 Notacin para clases a distintos niveles de detalle. .............................................. 11 Figura 1.3.1 Formato ....................................................................................................................... 13 Figura 1.3.2 Mrgenes..................................................................................................................... 13 Figura 1.3.3 Caja .............................................................................................................................. 13

Figura 2.1.1 Casos de uso .............................................................................................................. 15 Figura 2.1.2 Ventajas de casos de uso ......................................................................................... 16 Figura 2.2.3 Transiciones ............................................................................................................... 20

Figura 3.1.1 Representacin grfica ............................................................................................. 20 Figura 3.1.2 Relacin de componentes ......................................................................................... 21 Figura 3.1.3 Direcciones ................................................................................................................. 21 Figura 3.2.5.1 Modelo bsico de una lnea de productos de software ...................................... 27

Figura 4.1.2 Relacion entre error defecto y falla .......................................................................... 30 Figura 4.1.3.1 Caja blaca................................................................................................................. 30 Figura 4.1.3.1 Caja negra ................................................................................................................ 31 Figura 4.2 pruebas de aceptacion ................................................................................................. 49 Figura 4.2.5.1 Corrige el error de la manera ms obvia .............................................................. 43 Figura 4.3.1 Clases de prueba ....................................................................................................... 46

UNIDAD 1 CONCEPTOS INTRODUCTORIOS

1.1 LA ARQUITECTURA DE 4+1 VISTAS

La arquitectura del software se trata de abstracciones, de descomposicin y composicin, de estilos y esttica. Tambin tiene relacin con el diseo y la implementacin de la estructura de alto nivel del software. Los diseadores construyen la arquitectura usando varios elementos arquitectnicos elegidos apropiadamente. Estos elementos satisfacen la mayor parte de los requisitos de funcionalidad y performance del sistema, as como tambin otros requisitos no funcionales tales como conabilidad, escalabilidad, portabilidad y disponibilidad del sistema. A continuacin en la figura 1.1 se presentan las 4 + 1 vistas que se usan para el diseo y la implementacin de la estructura de alto nivel de software

Figura 1.1 Modelo de 4+1 vistas

1.1.1 La vista lgica

Es aquella que trata de clases y subsistemas, tiene las siguientes particularidades: soporta los requerimientos funcionales (estos son asignados por el usuario final), identifica mecanismos y disea elementos comunes atraves del sistema; utiliza los diagramas de clases y la notacin de Booch; adems de utilizar el estilo arquitectnico orientado a objetos

Notacin: La notacin para la vista lgica se deriva de la notacin de Booch. Esta se simplifica considerablemente de tal modo de tener en cuenta solamente los items relevantes para la arquitectura. En particular, los numerosos adornos disponibles son bastante intiles a este nivel de diseo. Usamos Rational Rose para apoyar el diseo lgico de la arquitectura. (Ver figura 1.2)

Figura 1.2 Notacin para la vista lgica.

1.1.2 La vista de procesos

La arquitectura de procesos toma en cuenta algunos requisitos no funcionales tales como la performance y la disponibilidad. Se enfoca en asuntos de concurrencia y distribucin, integridad del sistema, de tolerancia a fallas. La vista de procesos tambin especifica en cual hilo de control se ejecuta efectivamente una operacin de una clase identificada en la vista lgica. La arquitectura de procesos se describe en varios niveles de abstraccin, donde cada nivel se refiere a distintos intereses. El nivel ms alto la arquitectura de procesos puede verse como un conjunto de redes lgicas de programas comunicantes (llamados procesos) ejecutndose en forma independiente, y distribuidos a lo largo de un conjunto de recursos de hardware conectados mediante un bus, una LAN o WAN. Mltiples redes lgicas pueden usarse para apoyar la separacin de la operacin del sistema en lnea del sistema fuera de lnea, as como tambin para apoyar la coexistencia de versiones de software de simulacin o de prueba.

Un proceso es una agrupacin de tareas que forman una unidad ejecutable. Los procesos representan el nivel al que la arquitectura de procesos puede ser controlada tcticamente (comenzar, recuperar, reconfigurar, y detener). Adems, los procesos pueden replicarse para aumentar la distribucin de la carga de procesamiento, o para mejorar la disponibilidad.

Notacin: La notacin que usamos para la vista de procesos se expande de la notacin originalmente propuesta por Booch para las tareas de Ada y se centra solamente en los elementos arquitectnicamente relevantes. En la Figura 1.3 se muestra la notacin para la vista de procesos.

Figura 1.3 Notacin para el diagrama de procesos.

1.1.3 Vista de Desarrollo

La vista de desarrollo se centra en la organizacin real de los mdulos de software en el ambiente de desarrollo del software. El software se empaqueta en partes pequeas: bibliotecas de programas o subsistemas, que pueden ser desarrollados por uno o un grupo pequeo de desarrolladores. Los subsistemas se organizan en una jerarqua de capas, cada una de las cuales brinda una interfaz estrecha y bien definida hacia las capas superiores. (ver figura 1.4)

Figura 1.4 Diagrama parcial de procesos

Notacin. Tal como se muestra en la Figura 6, usamos una variante de la notacin de Booch limitndonos a aquellos items relevantes para la arquitectura. (Figura 1.5)

Figura 1.5 Notacin para el diagrama de desarrollo.

1.1.4 Arquitectura Fsica

Mapeando el software al hardware La arquitectura fsica toma en cuenta primeramente los requisitos no funcionales del sistema tales como la disponibilidad, confiabilidad (tolerancia a fallas), performance (throughput), y escalabilidad. El software ejecuta sobre una red de computadores o nodos de procesamiento (o tan solo nodos).

Los variados elementos identificadosredes, procesos, tareas y objetos requieren ser mapeados sobre los variados nodos. Esperamos que diferentes configuraciones puedan usarse: algunas para desarrollo y pruebas, otras para emplazar el sistema en varios sitios para distintos usuarios. Por lo tanto, el mapeo del software en los nodos requiere ser altamente flexible y tener un impacto mnimo sobre el cdigo fuente.

Notacin: para la arquitectura fsica. Los diagramas fsicos pueden tornarse muy confusos en grandes sistemas, y por lo tanto toman diversas formas, con o sin el mapeo de la vista de procesos. La figura 1.6 presenta la notacin para el diagrama fsico.

Figura 1.6 Notacin para el diagrama fsico.

1.2 DESARROLLO ORIENTADO A OBJETOS

Modelos
Un modelo representa a un sistema software desde una perspectiva especfica. Al igual que la planta y el alzado de una figura en dibujo tcnico nos muestran la misma figura vista desde distintos ngulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema.

Los modelos de UML que se tratan en esta parte son los siguientes: Diagrama de Estructura Esttica. Diagrama de Casos de Uso. Diagrama de Secuencia. Diagrama de Colaboracin. Diagrama de Estados.

Dependencias
La relacin de dependencia entre dos elementos de un diagrama significa que un cambio en el elemento destino puede implicar un cambio en el elemento origen (por tanto, si cambia el elemento destino habra que revisar el elemento origen).

Una dependencia se representa por medio de una lnea de trazo discontinuo entre los dos elementos con una flecha en su extremo. El elemento dependiente es el origen de la flecha y el elemento del que depende es el destino (junto a l est la flecha).

Clases
Una clase se representa mediante una caja subdividida en tres partes: En la superior se muestra el nombre de la clase, en la media los atributos y en la inferior las operaciones. Una clase puede representarse de forma esquemtica (plegada), con los detalles como atributos y

operaciones suprimidos, siendo entonces tan solo un rectngulo con el nombre de la clase. En la Figura 5 se ve cmo una misma clase puede representarse a distinto nivel de detalle segn interese, y segn la fase en la que se est. A continuacin se presenta la figura 1.7 Notacin para clases a distintos niveles de detalle.

Figura 1.7 Notacin para clases a distintos niveles de detalle.

Objetos
Un objeto se representa de la misma forma que una clase. En el compartimento superior aparecen el nombre del objeto junto con el nombre de la clase subrayados, segn la siguiente sintaxis: nombre_del_objeto: nombre_de_la_clase Puede representarse un objeto sin un nombre especfico, entonces slo aparece el nombre de la clase. Ejemplo de objetos en la figura 1.8

1.8 Ejemplos de objetos

10

1.3 DIAGRAMACIN
Consiste en tratar de equilibrar elementos a travs de las pginas; organizar las masas de texto, las ilustraciones, los espacios en blanco, los ttulos y las fotografas, procurando encontrar la armona de las partes con el todo. Podemos resumirlo esencialmente, en el orden y la direccin que retoma la vista cuando apreciamos un documento impreso: Si los elementos aparecen ante nosotros como un verdadero caos grfico, sencilla-mente se obvia la lectura. Si por el contrario, faltan elementos que unifiquen la armona del impreso, nos quedar una vaga idea y poco concisa, de lo que deseaba comunicar su emisor.

El formato Es el tamao o rea de la hoja de papel, donde va a ser impreso nuestro diseo. Existen muchos formatos de acuerdo a la necesidad del usuario como libros, revistas, peridicos, manuales, afiches, broshures, etc. Por lo general, se denominan tambin en pulgadas: por ejemplo 8.5" x 11" si es formato carta que se presenta en la figura 1.9

Figura 1.9 Formato

Los mrgenes Son los espacios circundantes que se respetan entre la caja y el borde de la hoja de papel. Pueden variarse de acuerdo al diseo, pero siempre respetando la continuidad del impreso. Tcnicamente estos espacios reciben el nombre de: Cabeza, Lomo, Corte y Pie. Como ejemplo la figura 1.10

11

Figura 1.10 Mrgenes La caja Es el espacio real y limitante, donde se diagrama y se acomodan los elementos de la pgina. En Microsoft Publisher, aparece la caja del documento delineada por un cuadro azul dentro de la pgina. Ejemplo figura 1.11

Figura 1.11 Caja Las 7 reglas de la diagramacin La mejor forma de aprender a diagramar, es observando y emulando otros impresos tales como revistas, diarios, plegables, etc. Pero existen 7 reglas de oro que se deben tomar en cuenta al disear sus documentos:

1. Tenga presente el nmero de columnas a usar, para que planifique la cantidad de texto. 2. Una vez ubicados los textos, no olvide dejar espacio para los elementos grficos. 3. NO recargue la pgina con textos, imgenes y/o blancos. Sea conciso para no distraer del tema central. 4. Los espacios pequeos en blanco, ayudan a descansar la vista. 5. Cuando diagrame una doble pgina, deje un espacio prudente en el centro de ambas, para evitar que las imgenes o el texto queden atrapados en el engrape o pegue del lomo. 6. Se recomienda no utilizar ms de 2 o 3 familias tipogrficas por documento diagramado. Unifquelas por ttulos, subttulos y prrafos. 7. Si trabaja en equipo con un ilustrador, indquele siempre en sus borradores el espacio y los detalles de la ilustracin que necesita, con tinta roja o marcador destacable.

12

UNIDAD 2 DISEO ORIENTADO A OBJETOS 2.1 DISEO DEL SISTEMA EN BASE A PROCESOS
El diseo del sistema se representa a travs de dos fases: a) El diseo lgico b) El diseo fsico

Cuando los analistas formulan un diseo lgico escriben las especificaciones detalladas del nuevo sistema, esto es, describen sus caractersticas como son: las salidas, entradas, archivos, bases de datos y procedimientos; todas de manera que cubran los requerimientos del proyecto.

El diseo lgico de un sistema de informacin es como el plano de un ingeniero para armar un automvil: muestra las caractersticas principales (motor, transmisin y rea para los pasajeros) y cmo se relacionan unas caractersticas con otras (dnde se conectan entre s los componentes del sistema, o por ejemplo, cun separadas estn las puertas.

El diseo fsico, actividad que sigue al diseo lgico, produce programas de software, archivos y un sistema en marcha, las especificaciones del diseo indican a los programadores qu debe hacer el sistema. Los programadores a su vez escriben los programas que aceptan entradas por parte de los usuarios, procesan los datos, producen los informes y almacenan estos datos en los archivos. A dems en el diseo fsico se especifican las caractersticas de los componentes del sistema requerido en prcticas del diseo lgico. En el diseo fsico deben delinearse las caractersticas de cada uno de los componentes que se enumeran a continuacin: Diseo de hardware Diseo de software Diseo de base de datos

2.1.1 Actividades y casos de uso

Los Casos de Uso son requerimientos funcionales que describen de una manera detallada el comportamiento del sistema con los distintos Actores que interactan con l. No definen todos los requerimientos (por ej. los tipos de datos, interfaces externas, niveles de rendimiento esperado, etc.), pero representan el hilo conductor que vincula a todos los requerimientos posibles (actuales y futuros) de una aplicacin. A continuacin se presenta en la figura 2.1 los requerimientos de los casos de uso.

13

Figura 2.1 Casos de uso Ventajas: 1. Lenguaje de comunicacin entre usuarios y desarrolladores. 2. Comprensin detallada de la funcionalidad del sistema. 3. Acotacin precisa de las habilitaciones de los usuarios. 4. Gestin de riesgo ms eficiente para gobernar la complejidad. 5. Estimacin ms exacta para determinar tiempo, recursos y prioridades en la dosificacin de esfuerzo de desarrollo. 6. Fiel trazabilidad para verificar la traduccin de requerimientos en cdigo ejecutable. 7. Mayor control para mantener las sucesivas revisiones de los programas. 8. Certificacin contractual Cliente-Desarrollador. 9. Documentacin orientada al usuario: Helps- Manual de Procedimientos - Reglas de Negocio. 10. Documentacin orientada al administrador del sistema: Soporte de Mantenimiento.

14

Ventajas de casos de uso.

Figura 2.2 Ventajas de casos de uso

2.1.2 Interfaces de usuario

Son los dispositivos tecnolgicos que transforman una herramienta no humana en una herramienta convivencial.

Las tendencias son hacia interfaces ms potentes considerando: a) El aumento de la capacidad de los sistemas. b) El aumento de la complejidad (segn la ley de la tecnologa, a mayor potencia, mayor complejidad): surge la necesidad por parte del usuario de contar con algo que se la oculte.

Gracias a las interfaces, los usuarios no necesitan comprender la mquina fsica. Se crea la ilusin de que el ordenador es muy sencillo. Este conjunto de mecanismos de dialogo hombre-mquina que ocultan al usuario la complejidad de la mquina y del sistema ofimtico se conoce como Ilusin de usuario. De esta manera se da la paradoja de que los ordenadores, siendo cada vez ms complejos, parecen ser cada vez mas simples. Es porque el usuario solo ve una mquina virtual hecha a medida de la complejidad que el comprende. Caractersticas de una interfaz Una interfaz debe cumplir las condiciones: Naturalidad. El nuevo sistema automatizado debe tender a ser lo ms similar al antiguo. Facilidad de aprendizaje y uso, dos aspectos que no siempre van unidos. Consistencia. La interfaz debe mantener uniformidad en cuanto a estilo, vocabulario, etc.

15

Naturalidad Una interfaz es natural, cuando provoca al usuario sentimientos de estar como en casa. Todo trabajador tiene: Una forma de actuar Una forma de organizarse Un vocabulario propio para las tareas habituales Un entorno que ya domina, al que est acostumbrado y del que, tal vez, le sea difcil de salir.

Facilidad de aprendizaje y uso Proporcionar al usuario un sistema de ayuda potente. Pero, cuidado! El sistema de ayuda puede ser un obstculo una vez que se domine el producto (esta ayuda no debe ser automtica). Para disfrutar de esta caracterstica, la interfaz debe incorporar: Administracin de perfiles de usuario. Segn el grado de perfil, la interfaz ejecutar unas acciones u otras. Mecanismos de realimentacin que proporcione al usuario informacin sobre la ejecucin actual del trabajo. Mecanismos de prevencin de desastres.

2.2 DISEO DE LA LGICA

2.2.1 Clases y Objetos

QU ES UN OBJETO? Un objeto no es ms que un conjunto de variables (o datos) y mtodos (o funciones) relacionados entre s. Los objetos en programacin se usan para modelar objetos o entidades del mundo real (el objeto hijo, madre, o farmacutica, por ejemplo). Un objeto es, por tanto, la representacin en un programa de un concepto, y contiene toda la informacin necesaria para abstraerlo: datos que describen sus atributos y operaciones que pueden realizarse sobre los mismos. La siguiente figura muestra una representacin visual de un objeto. En la siguiente imagen (Figura 2.3) se observa una presentacin visual de un objeto

16

2.3 Representacin visual de un objeto QU ES UNA CLASE? Normalmente en el mundo real existen varios objetos de un mismo tipo, o como diremos enseguida, de una misma clase. Por ejemplo, mi bicicleta es una de las muchas bicicletas que existen en el mundo. Usando la terminologa de la programacin orientada a objetos, diremos que mi bicicleta es una instancia de la clase de objetos conocida como bicicletas. Todas las bicicletas tienen algunos estados o atributos (color, marcha actual, cadencia actual, dos ruedas) y algunos mtodos (cambiar de marcha, frenar) en comn. Sin embargo, el estado particular de cada bicicleta es independiente del estado de las dems bicicletas. La particularizacin de estos atributos puede ser diferente. Es decir, una bicicleta podr ser azul, y otra roja, pero ambas tienen en comn el hecho de tener una variable color. De este modo podemos definir una plantilla de variables y mtodos para todas las bicicletas. Las plantillas para crear objetos son denominadas clases. Una clase es una plantilla que define las variables y los mtodos que son comunes para todos los objetos de un cierto tipo. (Figura 2.4)

2.4 Definicin de la clase bicicleta

17

2.2.2 Interaccin
En los diagramas de interaccin se muestra un patrn de interaccin entre objetos. Hay dos tipos de diagrama de interaccin, cada ambos basados en la misma informacin, pero

uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas de

Colaboracin.

En un diagrama de secuencia se indicarn los mdulos o clases que forman parte del programa y las llamadas que se hacen en cada uno de ellos para realizar una tarea determinada.

El diagrama de colaboracin Muestra cmo las instancias especficas de las clases trabajan juntas para conseguir un objetivo comn. Consiste especificar un contrato entre objetos Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementacin es llamada "enlace".

2.2.3 Estados y transiciones.

Estado es la condicin de un objeto en un momento determinado: el tiempo que transcurre entre los eventos.

Transiciones Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de accin. Esta transicin se produce como resultado de la finalizacin del estado del que parte el arco dirigido que marca la transicin. Como todo flujo de control debe empezar y terminar en algn momento, podemos indicar esto utilizando dos disparadores de inicio y fin tal y como queda reflejado en el ejemplo de la Figura 2.5

Figura 2.5 Transiciones

18

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 asociacin Ambos pueden anidarse Ambos pueden participar en interacciones

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

19

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 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

20

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, sus dependencias, su comunicacin su ubicacin y otras condiciones.

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 Authority), el navegador (Browser), el servidor WEB y otros elementos del modelo para asegurar la provisin de la seguridad en el sistema propuesto.

21

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,

22

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.

Al trmino del estudio se dispondr de los siguientes resultados:

23

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 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.

24

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. 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.

25

Figura 3.2.5.1 Modelo bsico de una lnea de productos de software

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.

26

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): 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.

27

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.

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.

28

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 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

29

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) Criterio de decisin/condicin. Consiste en exigir el criterio de 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 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).

30

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

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

31

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 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 Acciones necesarias para detener ordenadamente la ejecucin

32

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

33

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. TPGlobal (plan global del proceso de pruebas), TP-Req-Seguridad1 (plan de verificacin del requerimiento 1 de seguridad), TP-Contr-X (plan de verificacin del contrato asociado al evento de sistema X), TP-Unit-Despachador.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

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

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

34

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 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.

11.

Responsables

Especifica quin es el responsable de cada una de las tareas previstas en el plan.

35

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 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.

36

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 o o o o Notacin de grafo de flujo Complejidad ciclomtica Obtencin de casos de prueba Matrices de grafos

Prueba de la estructura de control o o o Prueba de condicin Prueba de flujo de datos 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

37

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 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.

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.

38

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.

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.

39

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 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 hace lo que tiene que hacer.

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.

40

La depuracin puede representar hasta el 50% del tiempo de desarrollo de un programa. Para muchos programadores -especialmente para los principiantes - 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 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

41

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.

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:

42

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 en primera instancia.

En cualquier caso, un error en tu programa representa una excelente 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 corregirlos antes de que causen problemas? Aprender sobre la calidad de tu cdigo desde el punto de vista de quien tiene que leerlo 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 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.

43

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

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

44

CLASES DE PRUEBA

Tipos de prueba lgico-simulado Estocsticos Real Controlada muy baja bajo medio alto

Consideraciones Costo de preparacin 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) 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.

45

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.

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.

46

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.

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.

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

47

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 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.

48

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 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.

49

La fase de mantenimiento de software involucra cambios al software en orden de corregir defectos y dependencias encontradas durante su uso tanto como la 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...).

50

GLOSARIO Unidad 1
1.- Fiabilidad: probabilidad de buen funcionamiento de algo". Por tanto, extendiendo el significado a sistemas, se dice que la fiabilidad de un sistema es la probabilidad de que ese sistema funcione o desarrolle una cierta funcin, bajo condiciones fijadas y durante un perodo determinado. 2.- Escalabilidad: es la propiedad deseable de un sistema, una red o un proceso, que indica su habilidad para extender el margen de operaciones sin perder calidad, o bien manejar el crecimiento continuo de trabajo de manera fluida, o bien para estar preparado para hacerse ms grande sin perder calidad en los servicios ofrecidos. 3.- Portabilidad: Se define como la caracterstica que posee un software para ejecutarse en diferentes plataformas, el cdigo fuente del software es capaz de reutilizarse en vez de crearse un nuevo cdigo cuando el software pasa de una plataforma a otra. 4.- Disponibilidad: El concepto de disponibilidad se utiliza en diversos mbitos y esferas para hacer referencia a la posibilidad de que algo, un producto o un fenmeno, est disponible de ser realizado, encontrado o utilizado. 5.- Requisito no funcional: Un requisito no funcional o atributo de calidad es, un requisito que especifica criterios que pueden usarse para juzgar la operacin de un sistema en lugar de sus comportamientos especficos, ya que stos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que ni describen informacin a guardar, ni funciones a realizar. 6.- Proceso: Un proceso es un conjunto de actividades o eventos (coordinados u organizados) que se realizan o suceden (alternativa o simultneamente) bajo ciertas circunstancias con un fin determinado.

Interfaz En software, parte de un programa que permite el flujo de informacin entre un usuario y la aplicacin, o entre la aplicacin y otros programas o perifricos. Esa parte de un programa est constituida por un conjunto de comandos y mtodos que permiten estas intercomunicaciones

Mapeo es una tcnica de programacin para convertir datos entre el sistema de tipos utilizado en un lenguaje de programacin orientado a objetos y el utilizado en una base de datos relacional, utilizando un motor de persistencia.

51

Emular Imitar las acciones de otro procurando igualarlo o superarlo

Unidad 2
Abstracciones: En programacin, el trmino se refiere al nfasis en el "qu hace?" ms que en el "cmo lo hace?" (caracterstica decana). Taxonoma: ordenamiento Trazabilidad: Se entiende trazabilidad como el conjunto de aquellos procedimientos

preestablecidos y autosuficientes que permiten conocer el histrico, Implementacin: Una implementacin o implantacin es la realizacin de una aplicacin.

Iterativos: trata de resolver un problema (como una ecuacin o un sistema de ecuaciones) mediante aproximaciones sucesivas a la solucin, empezando desde una estimacin inicial.

Estado: es la condicin de un objeto en un momento determinado: el tiempo que transcurre entre eventos. (Un telfono se encuentra en estado ocioso una vez que el auricular es puesto en su sitio y mientras no lo levantemos.)

OFIMATICA Se llama ofimtica el conjunto de tcnicas, aplicaciones y herramientas informticas que se utilizan en funciones de oficina para optimizar, automatizar y mejorar los procedimientos o tareas relacionados.

INSTANCIA Una instancia de un programa es una copia de una versin ejecutable del programa que ha sido escrito en la memoria del computador.

interaccion La interaccin es una accin recproca entre dos o ms objetos, sustancias, personas o agentes.

diagramas de interaccin

52

Los diagramas de interaccin explican grficamente cmo losobjetos interactan a travs de mensajes para realizar las tareas.

Transiciones Las transiciones reflejan el paso de un estado a otro,

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 reemplazable de un sistema que implementa un conjunto de interfaces. 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 (chrnos), "tiempo", describe el ajuste temporal de eventos. Se habla de sincronizacin cuando determinados fenmenos ocurran en un orden predefinido o a la vez.

53

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.
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

54

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-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)

55