Unidad 7 Ingeniería de Requisitos y Análisis OO M.C. Martín Olguín
Conceptos Requisitos del Software Es la descripción de los servicios y restricciones de un sistema de software, es decir, lo que el software debe hacer y bajo qué circunstancias debe hacerlo.
Conceptos Ingeniería de Requisitos del Software Es el proceso de descubrir, analizar, documentar y verificar los requisitos del software. Captura de Requisitos Es el proceso de descubrir, normalmente en circunstancias difíciles, lo que se debe construir. Es tan difícil hacerlo, que es una práctica común comenzar a escribir código (lo fácil) antes de formalizar el qué debe hacer este código.
Conceptos Stakeholders Este término se utiliza para referirse a cualquier persona que tiene influencia directa o indirecta sobre los requisitos del sistema. Entre los stakeholders se encuentran los usuarios finales que interactúan con el sistema y todos aquellos en la organización se que verán afectados por dicho sistema. Los stakeholders también son los ingenieros que desarrollan o dan mantenimiento a otros sistemas relacionados, los administradores del negocio, los expertos en el dominio del sistema, los representantes de los trabajadores, etc.
El Proceso y su contexto
La Visión del Proyecto El proceso de ingeniería de requisitos inicia con una visión del proyecto. El documento de Visión debe capturar los requisitos y restricciones de diseño de alto nivel para dar una idea del sistema a desarrollar. Será la guía de todo el proyecto. Sirve como base para un contrato de desarrollo.
Formatos de Visión de Proyecto RUP Process Impact
Actividades principales La ingeniería de requisitos incluye dos actividades principales: la obtención de requisitos, que da como resultado una especificación del sistema que el cliente comprende, y el análisis, que da como resultado un modelo de análisis que los desarrolladores pueden interpretar sin ambigüedad. [BRUEGGE, 2002]
Contexto de las Actividades Principales Obtención de Requisitos Especificación del sistema (SRS) Análisis Modelo de análisis
Actividades del Proceso de Obtención y Análisis de Requisitos 1. Comprensión del dominio 2. Recolección de requisitos 3. Clasificación 4. Resolución de conflictos 5. Priorización 6. Verificación de requisitos 7. Especificación de requisitos
Comprensión del Dominio Los ingenieros de requisitos deben desarrollar su propia comprensión del dominio de la aplicación. Por ejemplo, si se requiere un sistema para supermercados, deben averiguar cómo operan éstos.
Recolección de requerimientos Es el proceso de interactuar con los stakeholders del sistema para descubrir sus requisitos. En esta actividad se profundiza la comprensión del dominio.
Clasificación Esta actividad considera la recolección no estructurada de requisitos y los organiza en grupos coherentes. En esta etapa se empiezan a definir los casos de uso.
Resolución de conflictos De forma inevitable, cuando existen muchos stakeholders involucrados, los requerimientos entrarán en conflicto. Esta actividad se refiere a encontrar y resolver los conflictos. Es probable que se determine hacer primero actividades de ingeniería de sistemas.
Priorización En cualquier conjunto de requisitos, algunos de ellos serán más importantes que otros. Esta etapa comprende la interacción con los stakeholders para descubrir los requisitos más importantes.
Verificación de requisitos Los requisitos se verifican para descubrir si están completos, son consistentes y acordes con lo que realmente quieren los stakeholders del sistema.
Actividades de la Ingeniería de Requisitos
Tipos de Requisitos Requisitos funcionales: Describen las interacciones entre el sistema y su ambiente, en forma independiente a su implementación. El ambiente incluye al usuario y cualquier otro sistema externo con el cual interactúe el sistema. Requisitos no funcionales: Describen atributos sólo del sistema o del ambiente del sistema que no están relacionados directamente con los requisitos funcionales. Los requisitos no funcionales incluyen restricciones cuantitativas, como el tiempo de respuesta o precisión, tipo de plataforma (lenguajes de programación y/o sistemas operativos, etc.)
Técnicas para la obtención de requisitos Tormenta de ideas Storyboarding Role playing CRC cards Entrevistas Observación directa
Características de una buena SRS [IEEE Std 830-1998] 1. Correcta 2. No ambigua 3. Completa 4. Consistente 5. Calificada de acuerdo a la importancia y/o estabilidad 6. Verificable 7. Modificable 8. Rastreable
IEEE Std 830-1998 Correcta Una SRS es correcta, sí y solo sí, cada requisito especificado es un requisito que el software debe cumplir. No ambigua Una SRS no es ambigua sí y solo sí cada requisito especificado tiene sólo una interpretación.
...IEEE Std 830-1998 Completa Una SRS es completa, sí y solo sí, incluye los siguientes elementos: Todos los requisitos significativos Definición de las respuestas del software a todos los tipos posibles de clases de datos de entrada en todos los tipos posibles de clases de situaciones. Etiquetas y referencias completas a todas las figuras, tablas y diagramas en la SRS así como la definición de todos los términos y unidades de medida.
...IEEE Std 830-1998 Consistente Uns SRS es consistente, sí y solo sí, no se contradice a sí misma, es decir, si ningún subconjunto de requisitos ahí descritos se contradicen o entran en conflicto. Jerarquizada de acuerdo a la importancia y/o estabilidad Si cada requisito tiene un identificador que indique la importancia o estabilidad del requisito.
...IEEE Std 830-1998 Verificable Una SRS es verificable, sí y solo sí, cada requisito especificado es verificable. Un requisito es verificable sí y solo sí existe un proceso finito de costo-efectivo con el cual una persona o una máquina puede verificar que el producto de software cumple con el requisito. En general cualquier requisito ambiguo no es verificable.
...IEEE Std 830-1998 Modificable Una SRS es modificable, sí y solo sí, su estructura y estilo son tales que, cualquier cambio a los requisitos pueden ser hechos fácil, completa y consistentemente sin perder la estructura y el estilo. La modificabilidad generalmente requiere que una SRS: a) Tenga una organización coherente y fácil de usar con una tabla de contenido, un índice y referencias cruzadas explícitas. b) No sea redundante (esto es, el mismo requisito no debe aparecer en más de una parte en la SRS). c) Expresa cada requisito de manera separada, en vez de hacerlo mezclado con otros requisitos.
...IEEE Std 830-1998 Rastreable Una SRS es rastreable si el origen de cada uno de sus requisitos es clara y si facilita la referencia de cada requisito en el desarrollo futuro o mejora de la documentación. Tipos de rastreabilidad: Hacia enfrente Hacia atrás
Formatos para SRS RUP Process Impact
Modelo de Casos de Uso Una forma de construir la SRS es basada en casos de uso. Cada caso de uso puede agrupar a uno o varios requisitos. Cada caso de uso se debe documentar.
Documentación de Caso de Uso X. Flujo de Eventos para el Caso de Uso <nombre> X.1 Precondiciones X.2 Flujo principal X.3 Subflujos X.4 Flujos alternos X.5 Postcondiciones
Formatos para documentación de Casos de Uso RUP Process Impact
Modelo de Análisis Una vez especificados los requisitos y definidos los casos de uso, se procede a la construcción del modelo de análisis. Los modelos de análisis OO contienen: Realizaciones de casos de uso. Clases de análisis con sus responsabilidades, atributos y relaciones. Paquetes. La vista de la arquitectura.
Realización de casos de uso Colaboración Consultar Kardex ConsultarKardex Realización del caso de uso
Colaboración Es una descripción de una colección de objetos que interactúan para implementar algún comportamiento dentro de un contexto. Una colaboración tiene aspectos estructurales y aspectos de comportamiento. El aspecto estructural es una vista estática. El aspecto de comportamiento es el conjunto de mensajes intercambiados por los objetos.
Escenarios Son utilizados para describir una colaboración. Un escenario es una instancia de un caso de uso. Constituye un camino a través del flujo de eventos del caso de uso.
Escenarios y Casos de Uso Un caso de uso está compuesto de varios escenarios. Escenarios primarios: El flujo normal del caso de uso. Escenarios secundarios: La lógica si-entonces del caso de uso. Las fases tempranas del análisis se concentran en los escenarios primarios.
Interacción Es el conjunto de mensajes dentro de una colaboración. Es decir, una interacción define el aspecto de comportamiento de una colaboración. El UML provee dos tipos de diagramas para documentar las interacciones: Diagrama de Secuencia Diagrama de Colaboración
Realización de casos de uso Flujo Básico 1. El sistema solicita usuario y password 2. El maestro introduce la información 3. El sistema la valida 4. El sistema otorga acceso Flujos Alternos 3. 1 Si el usuario o password es incorrecto, el sistema despliega mensaje de error. 3.2 Si es el tercer intento bloquea la cuenta del usuario profesor : Maestro Escenario: Flujo Básico controlacceso pantallalogin validador usuarios:tabla menuprincipal captura datos crea despliega FormaAcceso valida crea despliega Menu busca TablaUsuarios ControlAcceso consulta consulta Validador
Clases de Análisis Una clase de análisis representa una abstracción de una o varias clases y/o subsistemas del diseño del sistema. Se centra en el tratamiento de los requisistos funcionales. Raramente define u ofrece una interfaz en términos de operaciones y sus firmas. Define atributos de alto nivel. Las relaciones que se definen para estas clases son más conceptuales que las de las clases del diseño.
Clases Estereotipadas Interfaz Control Entidad
Clases Interfaz Se utilizan para modelar la interacción entre el sistema y sus actores. Esta interacción regularmente implica recibir (y presentar) información y peticiones de (y hacia) los usuarios y los sistemas externos. Representan abstracciones de ventanas, formularios, paneles, interfaces de comunicación, de impresoras, sensores, etc.
Clases Entidad Se utilizan para modelar información que posee una vida larga y que comúnmente es persistente. Modelan la información y el comportamiento asociado de algún fenómeno o concepto, como una persona, objeto del mundo real, o un suceso del mundo real. Suelen mostrar una estructura de datos lógica y contribuyen a comprender de qué información depende el sistema.
Clases de Control Representan coordinación, secuencia, transacciones y control de otros objetos. Se usan para encapsular el control de un caso de uso en concreto. También se usan para representar lógica de negocios que no puede asociarse a una clase entidad. Modelan los aspectos dinámicos del sistema.
Clases Estereotipadas 2: captura datos 3: profesor : Maestro pantallalogin : FormaAcceso 7: 1: despliega controlacceso : ControlAcceso 4: valida 8: despliega validador : Validador menuprincipal : Menu 6: 5: busca usuarios : TablaUsuarios
Identificación de Clases No existe una receta de cocina para encontrar las clases en el dominio de un problema. Un buen comienzo para encontrar las clases del sistema en desarrollo es buscando las clases límite, entidad y control. Ya que el proceso de análisis y diseño es iterativo, la lista de clases se modificará conforme avance el tiempo.
Buenas clases Una buena clase captura una y sólo una abstracción, deberá tener un sólo tema principal. Las clases deberán ser nombradas utilizando el vocabulario del dominio. El nombre deberá ser el sustantivo singular que mejor caracterice la abstracción.
Documentación de Clases Conforme las clases se van creando, deben ser documentadas. La documentación deberá enunciar el propósito de la clase y no la estructura de la clase. Si se tiene dificultad para nombrar o documentar una clase, puede ser un indicador de que no es una buena abstracción.
Formatos para Documentar Clases Formato del RUP
Organización en Paquetes Los artefactos que se van generando requieren ser organizados, esto se hace mediante paquetes. Los paquetes deben ser altamente cohesivos y débilmente acoplados. Deben crearse basándose en requisitos funcionales y en el dominio del problema.
Ejemplo de paquetes Compras Ventas Inventario
Vista de la Arquitectura Muestra los artefactos significativos para la arquitectura: Descomposición del modelo de análisis en paquetes y sus dependencias. Clases fundamentales del análisis Realizaciones de casos de uso que describen la funcionalidad importante. Formato del RUP