Proceso Unificado. Captura de Requisitos

Transcripción

1 Proceso Unificado Captura de Requisitos Ejemplo: Videoclub Automático El sistema a desarrollar es un sistema software que hay que incorporar dentro de un dispensador automático de películas, un videoclub automático, como los que hay en gasolineras y tiendas abiertas 24h. Este videoclub tiene las facilidades usuales, como sacar películas, devolverlas, etc., y también otras como que se puede reservar una película notificando al usuario que ya esta disponible mediante un mensaje SMS o enviar recordatorios a los clientes que no han devuelto películas vía SMS. El pago ha de hacerse con tarjeta de crédito. El videoclub reporta a la central de la empresa vía Internet. 1

2 1. Captura de requisitos Actividades 1 Encontrar Actores y casos de uso 1.1 Identificar actores 1.2 Identificar casos de uso 1.3 Describir modelo de casos de uso 2 Detallar los casos de uso 2.1 Diseñar diagramas de estados 2.2 Descripción textual casos de uso 3 Definir prototipo de interfaz Captura de Requisitos: 1.1) Identificar Actores Ejemplo: Actores del Sistema de Videoclub Usuario Un Usuario es la persona que utilizará el sistema para buscar películas, solicitarlas, pagarlas y obtenerlas del dispensador. Operario Un Operario es la persona que realizará las tareas de mantenimiento del dispensador de películas, es decir, sustituirá viejas películas por nuevas. Para ello utilizará el sistema para dar de alta y baja las películas. Banco El Banco representa a la entidad externa con la que el sistema debe contactar para admitir y realizar los pagos con tarjeta de los clientes. Dispensador El Dispensador representa al dispositivo mecánico donde están almacenadas las películas que el sistema debe controlar para dar la película alquilada al cliente o que éste la pueda devolver. Operador Telefónico El Operador Telefónico representa la entidad externa con la que el sistema debe contactar para enviar mensajes SMS a los clientes. Sistema Contable El Sistema Contable representa el sistema informático externo de la empresa con el que el sistema videoclub debe contactar para notificar los pagos realizados en cada momento. 2

3 Captura de Requisitos: 1.2) Identificar Casos de Uso Algunos Casos de Uso identificados: Alquilar Película El Usuario utiliza este caso de uso para mirar qué películas hay, seleccionar una, pagarla y retirarla del dispensador. Debe obtener un recibo. Devolver Película El Usuario inicia este caso cuando devuelve la película. Recibe una notificación confirmándole la devolución. Si ha tenido retraso deberá abonar una penalización. Dar de Alta El Operario inicia este caso cuando introduce una nueva película en el dispensador. Dar de baja El Operario inicia este caso cuando retira una película del dispensador. Mandar Recordatorio El Operario inicia este caso cuando fija en el sistema el tiempo máximo permitido por el alquiler de cada película.... Captura de Requisitos: 1.3) Describir Modelo de Casos de Uso Alquilar Película Dispensador Iniciador Iniciador Devolver Película Banco Usuario Iniciador Alta Película Sistema Contable Operario Iniciador Iniciador Baja Película Operador Telefónico Mandar Recordatorio 3

4 Captura de Requisitos: 2) Detallar Casos de Uso 2.1) Diseñar Diagrama de Estados por caso de uso Camino Básico y Caminos Alternativos 1 Buscar Película Seleccionar Película 2 Gestionar Pago Rechazar Pago 4 Pago Rechazado Aceptar Pago 3 Despachar Película Cancelar Operación Reservar Película 5 Reservar CU: Alquilar película Captura de Requisitos: 2) Detallar Casos de Uso 2.2) Descripción del Caso de Uso "Alquilar Película" del Videoclub Precondición El usuario ha pulsado en el videoclub Alquilar Película Flujo de Eventos Camino Básico 1. El Usuario inicia el caso de uso buscando en la pantalla la película que más le gusta. El sistema le muestra la información de cada película, por orden alfabético, así como si está prestada, reservada o disponible. 2. El usuario selecciona una película en la pantalla. El sistema le pide los datos de su tarjeta de crédito y gestiona el pago con la entidad bancaria adecuada. 3. El banco emite una verificación y el pago es aceptado. El sistema ordena al dispensador que proporcione la película elegida y que le genere un recibo. Asimismo notifica al sistema contable la transacción bancaria realizada. Finalmente actualiza los datos históricos del usuario y marca la película como alquilada y no disponible si no hay más copias. Caminos Alternativos 1. En 2 puede que el pago no sea aceptado por el banco o que el usuario haya alcanzado el tope de sus alquileres por día. Hay que notificárselo al usuario y terminar. 2. En 1 puede que la película esté alquilada y el usuario quiera reservarla. En este caso hay que emitir una notificación de reserva. Poscondición El caso acaba cuando el usuario tiene la película y un recibí, o sin película y una notificación de pago rechazado, o sin película pero con la reserva hecha, o sin película por que no le gustara ninguna. Atributos del Caso de Uso Película: prestada, reservada o disponible Cliente (Usuario): datos tarjeta de crédito, número de películas alquiladas Información a mostrar: Sobre películas, sobre petición de datos, sobre resultado del alquiler realizado. 4

5 Captura de Requisitos: 3) Definir prototipo IU Salir Pantalla Entrada password. Continuar Continuar Salir Salir Pantalla Principal.Alquilar Película.Devolver Película.Alta Película....Salir Alquilar Película Volver A lquilar Película Título. Buscar. Volver. Salir O tra Película Buscar Mensaje Información sobre recoger película y recibo Mensaje Información Error en TC. Continuar. Salir Continuar [correcto] Salir Continuar [error] Continuar Salir A lquilar Introducir T.C. Continuar.. Volver. Salir Reservar Información sobre La reserva. Continuar. Salir Volver Alquilar Reservar Continuar Datos Película Información película. Alquilar. Reservar. Otra Película. Salir CU: Alquilar película 2.1 Análisis El objetivo final del análisis es analizar los requisitos utilizando el lenguaje de los desarrolladores y producir una vista interna del sistema Modelo de Casos de Uso Se describe con el lenguaje del cliente. Presenta una vista externa del sistema. Está estructurado por los casos de uso. Se utiliza como contrato entre el cliente y los desarrolladores sobre lo que debería a o no hacer el sistema. Captura la funcionalidad del sistema. Define casos de uso. Modelo de Análisis Se describe con el lenguaje del desarrollador. Presenta una vista interna del sistema. Está estructurado por las clases de análisis. Señala cómo c incorporar esa funcionalidad en el sistema Define realizaciones de casos de uso, y cada una de ellas representa el análisis de un caso de uso. 5

6 2.1 Análisis Modelo de Análisis: Modelo conceptual, refina y estructura los requisitos Actividades: 1. Analizar los Casos de Uso (identificar clases y describir interacciones) 2. Analizar cada Clase de Análisis (identificar responsabilidades, atributos y relaciones) Análisis: 1) 1) Analizar los Casos de Uso (identificar( clases y describir interacciones) a) Clases Entidad: Información que se manipula en la realización del casos de uso. Ejemplo: Clases Entidad del Caso de Uso Alquilar Película : Ficha Película y Ficha Cliente. b) Clases Interfaz: Identificar una clase interfaz por cada: 1) Actor humano. Si dicho actor tiene ya una clase interfaz habría que estudiar la posibilidad de reutilizarla para minimizar el número de ventanas con las que interactúa el actor. 2) Clase entidad encontrada que represente información con la que el usuario humano va a interactuar. 3) Sistema externo, y hacer que esa clase interfaz sea el canal de comunicación con él. (Ej. I.Usuario; I. Banco; I. Películas; I. Sistema. Contable; I.Dispensador). c) Clases Control: c) Clases Control: Identificar una clase de control responsable de la coordinación del caso de uso. Una clase de control puede actuar para varios casos de uso y se puede encapsular en una clase interfaz, especialmente si el actor maneja gran parte del control 6

7 Análisis: 1) 1) Analizar los Casos de Uso (identificar clases y describir interacciones) Diagrama de Colaboraciones: 1: Buscar Películas 2 :Mostrar Película 3: Coger Información 4: Seleccionar 5: Película Seleccionada 6: Confirma 7: Ordenar Película 8: Solicitar Datos de Pago 9: Enviar Datos de Pago 10: Ordenar Pago y Verificar 11: Proporcionar Película 12: Proporcionar Recibo 13: Actualizar F. Clientes 14: Actualizar F. Películas 15: Actualizar S. Contable 10 :I. Banco Banco 1, 6, 9 7 :Usuario 4 :I. Usuario :Gestor 15 :I. Sistema Contable Sistema Contable 14 11, 12 :I. Películas 3 :Ficha Película :Ficha Cliente :I. Dispensador Dispensador CU: Alquilar película (camino básico) Análisis: 2) Analizar cada Clase de Análisis (identificar responsab.,, atributos y relaciones) Responsabilidades de la clase Gestor La responsabilidad de esta clase en el Caso de Uso "Alquilar Película" es Ordenar Película, que implica: Solicitar Datos de Pago mediante la tarjeta de crédito. Ordenar al banco el pago y su verificación. Ordenar al dispensador la entrega al usuario de la película y del recibo. Actualizar la información sobre el cliente Actualizar la información sobre las películas Actualizar el balance de la empresa Otras responsabilidades provenientes de otros casos de uso: Gestionar el envío de recordatorios Gestionar la devolución de la Película Gestionar la carga y descarga de películas... CU: Alquilar película 7

8 Análisis: 2) Analizar cada Clase de Análisis (identificar responsab., atributos y relaciones) - El nombre de un atributo debería ser un sustantivo - Los tipos de los atributos deben ser conceptuales y, a ser posible, no restringidos por el entorno de programación. - Hay que reutilizar los tipos ya existentes. - Una instancia de un atributo no puede ser compartida por varios objetos de análisis. - Si el número de atributos hace que una clase sea difícil de entender, será mejor crear clases que los separen. - Los atributos de las clases entidad deben ser obvios. - Los atributos de clases interfaz que interactúan con actores humanos a menudo son componentes gráficos que el actor debe manipular. - Los atributos de clases interfaz que interactúan con actores que son sistemas externos, a menudo representan propiedades del protocolo o interfaz de comunicación. - Las clases de control no suelen tener atributos, salvo para representar valores que deben mantenerse durante la ejecución de un caso de uso. Ejemplo: Atributos de la clase Ficha Cliente NúmeroPelículasAlquiladas NombreApellidosCliente DatosTarjetaCrédito CU: Alquilar película Análisis: 2) Analizar cada Clase de Análisis (identificar responsab., atributos y relaciones) 1. Asociaciones 2. Agregaciones 3. Generalizaciones Ficha I. Películas 1 * CU: Alquilar película Ficha Película Generalización Ficha Cliente F. Películas Agregación 8

9 2.2 Diseño El objetivo final es producir un Modelo Lógico del sistema a implementar Modelo de Análisis Modelo de Diseño Es un modelo conceptual y genérico, es una abstracción del sistema. Es menos formal. Es un bosquejo del diseño del sistema. Puede no mantenerse durante todo el ciclo de vida del software. Define una estructura para modelar el sistema. Es un modelo físico f y concreto, es un plano de la implementación. n. Es más m s formal. Es una realización n del diseño del sistema. Debe ser mantenido durante todo el ciclo de vida del software. Da forma al sistema. 2.2 Diseño Actividades 1. Diseñar la Arquitectura (identificar nodos y configuraciones, clases relevantes) 2. Diseñar Casos de Uso (identificar clases de diseño, interacciones entre objetos) 3. Diseñar Clases de Diseño (identificar operaciones, atributos, relaciones) 9

10 Diseño: 1) 1) Diseñar la Arquitectura (identificar( nodos y configuraciones, clases relevantes) Modelo de Despliegue. Todos los actores del caso de uso interactuarán con el sistema en el mismo sitio físico? Qué requerimientos de computación necesito en cada nodo? Qué tipo de conexiones o red existe entre los nodos? Qué protocolos manejan? Cuáles son sus características? Tengo requisitos del tipo Copias Redundantes para caso de fallos? Copia de seguridad de BBDD? Usuario Banco * Internet * Sistema Local Dispensador * 1 Internet Sistema Central Modelo Despliegue Videoclub Sistema Contable Diseño: 1) 1) Diseñar la Arquitectura (identificar nodos y configuraciones, clases relevantes) Clases Activas, que necesiten estar ejecutándose concurrentemente. Se suelen identificar observando la distribución del sistema en nodos. Debe existir al menos un objeto activo por cada nodo. Clases relacionadas con las comunicaciones entre nodos Clases de Análisis Clases Activas de Diseño I. Sistema Contable Sistema Local * 1 Sistema Central I. SC. Local I. SC. Central Internet Clases Relevantes Videoclub 10

11 Diseño: 2) 2) Diseñar Casos de Uso (identificar( clases de diseño, interacciones entre objetos) Identificar Clases de Diseño: Identificar clases de diseño que permitan implementar las clases de análisis (tener en cuenta el modelo de despliegue). Estudiar los requisitos especiales (de rendimiento, de memoria, de diseño) de las clases de análisis, e identificar clases de diseño necesarias. Crear Tabla de Correspondencias Crear el Diagrama de Clases de Diseño Diseño: : 2) Diseñar Casos de Uso ( Diseñar Casos de Uso (identificar clases de diseño, interacciones entre objetos) Requisito especial sobre las Clases de Análisis Ficha de Película y Ficha de Cliente del caso de uso Alquilar Película. Ficha de película y Ficha de Cliente que se generalizaron en el Análisis a la clase Ficha deben poder manejarse de una manera organizada y eficiente, por lo que es necesario crear Clases de Diseños que manejen Listas de cada tipo de Ficha. Requisito especial sobre la Clase de Análisis I. Usuario I. Usuario debe ser una clase activa ya que debe estar lista para responder a cualquier petición del usuario en cualquier momento (como cancelar un alquilar mientras se procesa o salir del sistema mientras éste busca la información de una película). Unificación de las Clases de Análisis I. Usuario e I. Películas I. Películas se absorbe en la clase de diseño I. Usuario con objeto de reunir en una sola clase todas las interfaces gráficas. 11

12 Diseño: 2) 2) Diseñar Casos de Uso (identificar( clases de diseño, interacciones entre objetos) Clase de Análisis I. Usuario Gestor I. Películas Ficha Película Ficha Cliente I. Dispensador I. Sistema Contable (1) I. Sistema Contable (2) I. Banco Clase de Diseño I. Usuario Gestor Lista Fichas Clientes Lista Fichas Películas Ficha Película Ficha Cliente I. Dispensador I. SC. Local I. SC. Central I. Banco Requisito de Diseño Activa Absorbida en I. Usuario Incluida para manejar Clientes Incluida para manejar Películas Del Modelo de Despliegue Del Modelo de Despliegue. Activa Diseño: 2) 2) Diseñar Casos de Uso (identificar( clases de diseño, interacciones entre objetos) Diagrama de Clases de Diseño I. Banco Banco I. Usuario Gestor * 1 I. SC. Local I. SC. Central Usuario Sistema Contable Lista Fichas Pelicul Lista de Fichas Client 1 * Ficha películas 1 * Ficha Cliente I. Dispensador Dispensador 12

13 Diseño: 2) 2) Diseñar Casos de Uso (identificar clases de diseño, interacciones entre objetos) Diagramas de Secuencia: Incorpora instancias de los actores participantes, objetos de diseño y la transmisión de mensajes entre ellos. Ejemplo de Diagrama de Secuencia para la primera parte de la realización del Caso de Uso Alquilar Película :U suario :I. Usuario :Lista de F ichas :F ich a P e lícu la :G estor :I. Banco :Banco Buscar Buscar() ObtenerInfo() S e le c c io na r OrdenarPeli() Ordenar Pago() OrdenarPago() Diseño: 3) 3) Diseñar Clases de Diseño (identificar( operaciones,, atributos, relaciones) Identificar las Operaciones Identificando los mensajes a los que debe responder en el Diagrama de Secuencia. Analizando las responsabilidades de la clase de análisis de la que deriva. A menudo implican una o varias operaciones. Contemplando los requisitos especiales de la clase de análisis de la que deriva, por ejemplo el acceso a un gestor de BBDD. Añadir la visibilidad de cada operación. Usar la sintaxis del lenguaje de implementación a utilizar. Las operaciones de la clase de diseño necesitan soportar todos los roles que la clase desempeña en las diferentes realizaciones de casos de uso. Gestor I. Banco +solicitard atosp ago(): D atostc +ordenarpeli(): RetornoOperación +entregarpelícularecibo() +actualizarbalance() +actualizarcliente() +actualizarpelículas() +recordatorios() +devolverpelícula(): RetornoOperacion +cargarpelícula() +descargarpelícula +ordenar Pago(): RetornoPago 13

14 Diseño: 3) 3) Diseñar Clases de Diseño (identificar operaciones, atributos, relaciones) Identificar Atributo Los atributos deben ser los requeridos para realizar sus operaciones. Hay que tener en cuenta los atributos obtenidos en la fase de Análisis. Los tipos de atributos se restringen a los tipos disponibles en el lenguaje de programación a usar. Hay que reutilizar tipos de atributos. Si una clase de diseño resulta compleja por culpa de sus atributos, se pueden agrupa atributos en clases independientes. FichaCliente -DatosTarjetaCredito: TarjetaCredito -NombreApellidos: String -NumeroAlquiladas: int TarjetaCredito -NombreApellidos: String -NumeroTarjeta: int[10] -FechaCaducidad: Date Diseño: 3) 3) Diseñar Clases de Diseño (identificar operaciones, atributos, relaciones) Identificar Asociaciones, Agregaciones y Generalizaciones. Estudiar el diagrama de secuencias y ver qué asociaciones o agregaciones son necesarias. Agrupar objetos en agregaciones para mandarles mensajes a todos ellos. Estudiar asociaciones creadas en la fase de análisis. Si el lenguaje de programación no soporta el mecanismo de generalización o herencia se deben emplear los mecanismos de asociación y agregación. Gestor +solicitardatospago(): DatosTC +ordenarpeli(): RetornoOperación +entregarpelícularecibo() +actualizarbalance() +actualizarcliente() +actualizarpelículas() +recordatorios() +devolverpelícula(): RetornoOperacion +cargarpelícula() +descargarpelícula Lista Ficha Peliculas Lista Ficha Clientes 1 * 1 * Ficha Películas 0.. M 0.. N Ficha Clientes En la operación devolverpelicula() se ha estimado que es mejor que exista esta agregación entre las clases Ficha Película y Ficha Cliente, para evitar el tener que recorrer las dos listas buscando primero la película y después al cliente. 14

15 Diseño: 3) 3) Diseñar Clases de Diseño (identificar operaciones, atributos, relaciones) Describir Estados de Objetos: Diagrama de Estados de la clase FichaCliente Ficha Cliente -DatosTarjetaCredito: TarjetaCredito -NombreApellidos: String -NumeroAlquiladas: Int -MaximoAlquiler: Int +Devuelve() [número =1] Sin Película +Alquila() +Devuelve() [número>1] +Devuelve(codigoPelicula) +Alquila(codigoPelicula) -Bool MaximoAlcanzado(); Con Película +Alquila() [número < n] +Devuelve() +Alquila() [número = n] Describir los Métodos Máximo Alcanzado Descripción del Método ActualizarPelícula de la clase Gestor /* En el diagrama de colaboraciones del caso de uso AlquilarPelícula, se observa que la operación Actualizar F. Películas se realiza después de Acualizar F. Cliente, por lo que se puede pasar al método el cliente que la ha alquilado */ void ActualizarPelicula(Cliente, codigopeli){ Película = BuscaPelicula en listafichapelículas (codigopeli); Película <- es alquilada por Cliente; Película <- es alquilada en esta fecha y Hora } 3. Implementación Codificar los resultados del Diseño en términos de componentes tales como ficheros fuente, ejecutables, scripts, etc. Los objetivos de la implementación son: Implementar las clases encontradas durante el diseño. En concreto, se implementan dentro de componentes (ficheros) que contienen código fuente. Asignar los componentes ejecutables a los nodos del diagrama de despliegue. Probar los componentes individualmente e integrarlos en uno o más ejecutables. Integrar los componentes en el sistema siguiendo un enfoque incremental 15

16 3. Implementación Actividades 1. Implementar Arquitectura (Identificar Componentes y Asignarlos a los nodos) 2. Implementar las Clases de Diseño ( Generar Código, Implementar Operaciones, Realizar Pruebas de unidad e Integrar el Sistema) Implementación: 1) Implementar la arquitectura A) Identificar Componentes e Incorporarlos al Modelo. Ficha Agrupar clases por tipos en un componente (ficheros.h y.cpp en el lenguaje C++) A cada clase activa se le asignará un componente ejecutable. Diagrama de componentes: Las cajas representan módulos y las flechas indican una relación de utilización (el módulo que es origen de la flecha utiliza al módulo que es destinatario de la misma). B) Asignar Componentes a los nodos: FichaPelículas ListaFichaPelículas FichaCliente ListaFichaCliente De acuerdo con el Modelo de Despliegue. Clases activas asignadas a nodos independientes. ListaFicha Diagrama de Componentes para las clases Ficha, ListaFichas, FichaPeliculas y Ficha Clientes 16

17 Implementación: 2) Implementar las Clases de Diseño A) Generar código fuente desde la descripción de la clase de diseño. En este paso sólo se genera la signatura de las operaciones. Las operaciones en sí se implementan más adelante. En cuanto a las asociaciones y agregaciones, su generación es delicada. Lo normal es que una asociación que se recorre en una dirección se implemente con una referencia, representada con un atributo en el objeto que referencia y el nombre del atributo será el rol del extremo opuesto. La multiplicidad del extremo opuesto indicará si la referencia será un puntero simple o una colección de punteros. Declaración de la clase FichaCliente en C++ Class FichaCliente { private: TarjetaCredito datostarjetacredito; String NombreApellidos; int NumeroAlquiladas; int MaximoAlquiler; public: void devuelve(int codigopelicula); void alquila(int codigopelicula); bool maximoalcanzado(); }; Implementación: 2) Implementar las Clases de Diseño B) Implementar las operaciones. Cada operación definida por la clase de diseño ha de implementarse mediante métodos. Implementación del Método ActualizarPelícula de la clase Gestor /* En el diagrama de colaboraciones del caso de uso Alquilar Película, la operación Actualizar F. Películas se realiza después de Acualizar F. Cliente, por lo que se puede pasar al método el cliente que la ha alquilado */ void Gestor::ActualizarPelicula(Ficha Cliente *ptrfc, int codigopeli){ FichaPelicula *ptrfp; try { //Se busca la película ptrfp=listafichapelículas.buscapelicula(codigopeli); } catch (ErrorNoEncontrada) { // No debería pasar en ejecución real pero sirve para depurar cerr<< Error A: llamada a Gestor::ActualizarPelicula no valida <<endl; } catch (ErrorYaAlquilada) { // No deberia pasar en ejecución real pero sirve para depurar cerr<< Error B: llamada a Gestor::ActualizarPelicula no valida <<endl; } catch (ErrorYaReservada) { // No deberia pasar en ejecución real pero sirve para depurar cerr<< Error C: llamada a Gestor::ActualizarPelicula no valida <<endl; } ptrfp->alquiladapor(ptrfc); //Se notifica quién la alquiló ptrfp->alquiladahoy(); //Se estampa fecha de alquiler } 17

18 Implementación: 2) Implementar las Clases de Diseño C) Realizar Pruebas de Unidad (de los Componentes Individuales) Pruebas de especificación (pruebas de caja negra), que verifican el comportamiento de la unidad observable externamente. Pruebas de estructura (prueba de caja blanca), que verifica la implementación interna de la unidad. Para cada componente se estudiará su implementación interna y se tratará de verificar su correcto comportamiento algorítmico. D) Integrar el Sistema Los objetivos de la integración del sistema son dos: Crear un plan de integración de los componentes en el sistema. Integrar cada componente antes de que sea sometido a las pruebas de integración. Será necesario incluir algunos componentes como stubs para poder desarrollar las pruebas de integración. Es importante implementar casos de uso completos y a ser posible los más importantes. Probablemente la implementación de cada caso de uso podrá requerir varios componentes. 4. Pruebas El objetivo de esta fase es realizar pruebas sobre la estructura del sistema que se va formando con los módulos implementados. Las pruebas que deben hacerse son de dos tipos: de integración y del sistema. Artefactos: A) Casos de Prueba. Un caso de prueba indica una manera de probar el sistema. Incluye qué probar junto con su entrada o salida y bajo qué condiciones probar. Los casos de prueba pueden ser: Parecidos o Similares, diferenciándose únicamente en algún dato de entrada y/o salida. De Instalación en una plataforma: verifican que el sistema puede ser instalado en la plataforma del cliente. De Configuración, sobre distintas plataformas: verifican que el sistema funciona correctamente en diferentes configuraciones. Negativos, intentando que el sistema falle, por ejemplo utilizando datos no esperados. De Tensión o Stress, probando el sistema cuando los recursos son insuficientes o hay competencias por ellos. B) Procedimientos de Prueba.. Un procedimiento de prueba especifica cómo realizar uno o varios casos de prueba. Son las instrucciones que los probadores deben seguir para realizar las pruebas. C) Modelo de Pruebas. Es la colección formada por los casos de prueba y procedimientos de prueba. D) Evaluación de Prueba. Es una evaluación de los resultados de la prueba realzada. 18

19 4. Pruebas El objetivo de esta fase es realizar pruebas sobre la estructura del sistema que se va formando con los módulos implementados. Las pruebas que deben hacerse son de dos tipos: de integración y del sistema. Actividades 1. Planificar y Diseñar las Pruebas de Integración y de Sistema. 2. Realizar las Pruebas de Integración y de Sistema Pruebas: 1) Planificar y Diseñar las Pruebas Principios generales: 1) Diseñar las pruebas de Integración de Componentes. Se utilizan para verificar que los componentes interaccionan entre sí de un modo apropiado después de haber sido integrados en el sistema. Se toman como Casos de Prueba los casos de uso del diseño. Para ello se utiliza el Diagrama de Secuencia correspondiente y se diseñan combinaciones de entrada y salida del sistema que lleven a distintas utilizaciones de las clases, y en consecuencia de los componentes, que participan en el diagrama. 1) Diseñar las pruebas del Sistema. Se usa para probar que el sistema funciona globalmente de forma correcta. Cada prueba del sistema prueba combinaciones de casos de uso bajo condiciones diferentes. Se prueba el sistema como un todo probando casos de uso unos detrás de otros y, si es posible, en paralelo. Se trata de ver que cada caso de uso funciona adecuadamente en distintas configuraciones hardware, de carga, con varios actores a la vez, en distinto orden, etc. 19

20 Diseño de Prueba 32 de Caso de uso Alquilar Película] Precondición: el sistema tiene todas las películas cargadas, ninguna alquilada 1. Introducir usuario Fulanito Prueba32 (usuario admitido por el banco sin limite de crédito) 2. Seleccionar segunda película (hay 3 copias) 3. Alquilarla 4. Recoger Película y Recibo 5. Salir del sistema 6. Introducir usuario Fulanito Prueba32 7. Seleccionar segunda película (hay 2 copias) 8. Alquilarla 9. Recoger Película y Recibo 10.Salir del sistema 11.Introducir usuario Fulanito Prueba32 12.Seleccionar segunda película (hay 1 copias) 13.Alquilarla 14.Recoger Película y Recibo 15.Salir del sistema 16.Introducir usuario Fulanito Prueba32 17.Seleccionar segunda película (no debe haber copias) 18.El sistema debe ofrecer la posibilidad de reservar 19.Reservar 20.Salir del sistema Pruebas: 2) Realizar Pruebas de Integración y Sistema Realizar las Pruebas de Integración: Ejecutar las pruebas. Comparar los resultados de las pruebas con los resultados esperados y ver las diferencias. Analizar los componentes y las pruebas diseñadas que presentaron esas discrepancias para un posible rediseño del componente o cambios en la prueba. Realizar la Prueba del Sistema La prueba del sistema puede empezar cuando las pruebas de integración indican que el sistema satisface los requisitos de calidad fijados durante las pruebas. Por ejemplo, el 90% de las pruebas de integración se realizan con el resultado esperado. La prueba del sistema se lleva a cabo de forma similar que las pruebas de integración. Los diseñadores de las pruebas evalúan los resultados de la prueba, fundamentalmente a partir de dos métricas: 1. Completitud de la prueba: indica el porcentaje de casos de prueba que han sido ejecutados correctamente y el porcentaje de código que ha sido probado. 2. Fiabilidad: se basa en el análisis de la tendencia en los errores detectados y de los resultados esperados. Lo usual es que el número de errores se incremente rápidamente al inicio de las pruebas, se mantenga estable posteriormente durante un tiempo y finalmente empiece a decrecer.basándose en el análisis de la tendencia de los errores detectados se puede sugerir realizar pruebas adicionales, relajar el criterio de pruebas si los objetivos de calidad se pusieron muy altos, o revisar la parte del sistema que no cumple los requisitos de calidad. 20