07/03/2011. Lo mejor es enemigo de lo bueno (Voltaire)

Transcripción

1 Captura de Requisitos Informática Industrial A/DOO EUITI UPM Lo mejor es enemigo de lo bueno (Voltaire) Índice Fase de Inicio Comprensión de los requisitos Requisitos Modelo de Casos de Uso Identificarlos Formatos UML Especificaciones complementarias Vision Glosario 1

2 Comprensión de los requisitos Gestión de requisitos No se refiere al ciclo en cascada, congelar requisitos RUP: Encontrar, documentar, organizar y seguir la pista a los requisitos cambiantes Talleres de requisitos Casos de uso Costes proyecto Tipos de requisitos FURPS+ Functional: Características Usability (Facilidad de uso): Factores humanos, documentación Reliability (Fiabilidad): Fallos, recuperación. Performance (Rendimiento): tiempos, carga, productividad, uso de recursos Supportability (Soporte): Adaptabilidad, mantenimiento, internacionalización, configurabilidad + Implementación: lenguajes, herramientas, hardware Interfaz: relación con sistemas externos Operaciones: Gestión del sistema en puesta en marcha Empaquetamiento Legales: Licencia EJEMPLO: Maquina de refrescos 2

3 Clasificación y artefactos Funcionales (que) Artefacto: Modelo de Casos de Uso No Funcionales, requisitos de calidad (como) Artefactos: Casos de Uso relacionados Especificación complementaria Influyen fuertemente en el diseño de la arquitectura del sistema Artefactos comunes a Funcionales y Calidad: Visión: Resume los requisitos anteriores a alto nivel Glosario: diccionario con la terminología del dominio, valores aceptables Bibliografía: Bibliografía existente Condicionado al ciclo en cascada Casos de uso como complementario 3

4 Índice Fase de Inicio Comprensión de los requisitos Requisitos Modelo de Casos de Uso Identificarlos Formatos UML Visión Glosario Especificaciones complementarias Modelo de Casos de Uso Escritura de los requisitos en un contexto. En contraposición a la lista de la compra Qué son los casos de Uso? Historias del uso de un sistema Dónde se ubican? En la disciplina de Requisitos Requisitos funcionales Modelo de Casos de Uso: El conjunto de todos los casos de uso, es un modelo de la funcionalidad y entorno del sistema 4

5 Objetivos e Historias Los clientes tienen objetivos (necesidades) y quieren que el sistema les ayude a conseguirlos Ej: Aplicación PDV (Punto de Venta) Terminal, lector de código de barras. Conexión a otros sistemas: inventario, pago con tarjeta Formato breve: Procesar Venta: Un cliente llega a la caja con artículos. El cajero utiliza el sistema PDV para registrar los artículos. El sistema presenta una suma parcial y detalles de los productos. El cliente introduce los datos del pago que el sistema valida y registra. El sistema actualiza el inventario. El cliente recibe un recibo y se va con los artículos. A menudo requieren mayor descripción, pero la esencia es esta: historias del uso del sistema que ayudan a cumplir los objetivos de las personas involucradas Actores Actor: algo con comportamiento, como una persona, un sistema informatizado u organización. Principales (Cajero) Apoyo (Servicio autorización de pago) Pasivos (Hacienda) 5

6 Escenarios Escenario: Una secuencia especifica de acciones entre los actores y el sistema = Instancia de caso de uso. Dentro del mismo caso de uso hay escenarios de éxito y escenarios de fallo. Un Caso de Uso es una colección de escenarios de éxito y fallo relacionados Ej. PDV: Gestionar Devoluciones (Formato Informal) Escenario principal de éxito: Cliente llega a caja con articulos para devolver. El cajero utiliza el sistema PDV para registrar los articulos. Se actualiza el inventario. El cajero devuelve el dinero al cliente. Escenarios alternativos Si se pago con tarjeta, y el sistema rechaza el reembolso, informar al cliente y pagar en efectivo. Si el identificador del articulo no se lee correctamente, introducirlo a mano. Valor añadido Cómo puedo, utilizando el sistema, proporcionar un valor añadido al usuario o cumplir sus objetivos? Valor añadido parece obvio, pero la industria del software esta plagada de fracasos por este motivo. El enfoque lista de la compra lo acentua, mientras que los casos de uso lo evitan Casos de uso = Requisitos funcionales Aunque no todos 6

7 Porque casos de uso Casos de Uso no son POO Pero son útiles como entrada al proceso Son conocidos, extendidos y entendidos (historias) por personal no técnico Tienen notación en UML Ayudan a poner en contexto las cosas Vs. Lista de la compra Índice Fase de Inicio Comprensión de los requisitos Requisitos Modelo de Casos de Uso Identificarlos Formatos UML Especificaciones complementarias Vision Glosario 7

8 Descubrir actores principales, objetivos y casos de uso 1. Elegir los limites del sistema Software, hardware, etc. Ej. Se encuentra el sistema de autorización de pagos dentro del sistema? No, es un actor externo 2. Identificar actores principales y objetivos Complicado: Talleres de requisitos, tormentas de ideas, etc. Preguntas útiles: Quién arranca y para el sistema? Quién gestiona los usuarios y la seguridad? Quién se encarga de administrar el sistema? Quién evalúa la actividad o rendimiento del sistema? Cómo se gestionan las actualizaciones? El actor principal y los objetivos dependen del limite del sistema 3. Definir los casos de uso Comenzar los casos de uso por un verbo Actores dependen del limite del sistema Enterprise Selling Things Goal: Collect taxes on sales Sales Tax Agency Sales Activity System Cashier Checkout Service POS System Customer Goal: Buy items Goal: Analyze sales and performance data Goal: Process sales 8

9 Listas actor-objetivo objetivo Identificar casos de uso Difícil identificar casos de uso Ej: Cuáles son casos de uso? Negociar un contrato con suministrador Identificarse en el sistema Procesar una venta Arrancar el sistema Parar el sistema 9

10 Identificar casos de uso Respuesta: Todos: Grano muy fino, demasiados, poco útil para A/DOO Arrancar el sistema son siempre casos de uso. Quizás triviales Quizás críticos (avionica) Podemos acabar con un único caso de uso grande: Manejar el sistema, tampoco util Elementary Business Processes: EBP Una tarea realizada por una persona en un lugar, en un instante, como respuesta a un evento del negocio, que le añade valor cuantificable y deja los datos en un estado consistente Prueba del jefe: Qué has hecho hoy? Me he identificado en el sistema He iniciado el negociado de un contrato EBP: Generalmente involucran a 1 persona Están formados por varios pasos 5-10 (con posibles alternativas) Se realizan en una sesión Ej: Procesar una venta. Los otros se pueden, pero es mejor enfocarse en EBP Identificar casos de uso Algunas preguntas rutinarias de comprobación: Existe un administrador? Existe un caso de uso ConfigurarSistema? Existen casos de uso Arrancar y Parar? 10

11 Índice Fase de Inicio Comprensión de los requisitos Requisitos Modelo de Casos de Uso Identificarlos Formatos UML Especificaciones complementarias Vision Glosario Tipos de formalidad Breve Informal Completo 11

12 Formato completo PROCESAR VENTA Actor principal Cajero Personal involucrado e intereses: Cajero: quiere entradas rápidas y sin errores Vendedor: que las comisiones estén actualizadas Agencia tributaria: tener conocimiento de los impuestos Precondiciones: El cajero se identifica Postcondiciones: Se registra la venta, se registra el impuesto, se registran las comisiones, se genera recibo, se actualizan la contabilidad y el inventario. Escenario principal de éxito. (Sin bifurcaciones!) 1. El cliente llega con mercancías al PDV 2. El cajero comienza una venta 3. El cajero introduce el identificador del articulo 4. El sistema presenta la descripción y la suma parcial Extensiones A. En cualquier momento el sistema falla El cajero reinicia el sistema El sistema recupera los datos 3.a El sistema no reconoce el identificador. El cajero introduce a mano el identificador Requisitos especiales: El cajero utiliza una pantalla táctil El tiempo de respuesta de reconocer una tarjeta inferior a 30 segundos Lista de tecnología y variaciones de datos: La firma del cliente se hace en papel, pero se pronostica que en dos años será una firma digital Frecuencia: Podría ser casi continuo Temas abiertos: Cuáles son las variaciones de la ley de impuestos? Puede el cliente utilizar el lector de tarjetas o lo tiene que hacer el cajero? Se le puede pedir al cliente el DNI? Formato completo Pagina web de la asignatura Flujos alternativos X.Y Excepciones X.Y.E.Z Excepciones 12

13 Ejemplo Ejemplo 13

14 Formato completo (2 col) Escenario de éxito Acción (intención) del actor 1. El cliente llega con artículos al PDV 2. El cajero comienza una venta 3. El cajero introduce el identificador del articulo Responsabilidad del sistema 4. Registra el articulo, muestra la descripción y la suma parcial Recordar: No son perfectos! Necesidad de comunicación y participación: Conexión directa entre programadores y cajeros Desarrollo iterativo Comunicación personal continua y directa (diaria) 14

15 Reglas de escritura No considerar la interfaz de usuario: centrarse en la intención. NO: El usuario teclea su login y contraseña con el teclado en un cuadro de dialogo SI: El usuario se autentica en el sistema Por qué? Objetivos del usuario (Cajero): Que la venta quede registrada como suya. Que sea seguro y antirobo. A veces es inevitable, cuando se detallan los casos de uso. Si falla la autenticacion, introducir por teclado Poner los actores y casos de uso con Mayusculas Concretos, compactos, simples. A la gente no le gusta leer requisitos Índice Fase de Inicio Comprensión de los requisitos Requisitos Modelo de Casos de Uso Identificarlos Formatos UML Especificaciones complementarias Vision Glosario 15

16 Casos de Uso en UML Secundarios Lo importante es el texto (mas tiempo) UML (menos tiempo): Identificar nombres Crear un contexto visual Representación Actores: Muñeco (personas) Caja (<actor>) sistemas Casos de uso: Elipse Ejemplo EBP system boundary NextGen POS communication Actores primarios en la izquierda Customer actor Cashier Process Sale Handle Returns Payment Authorization Service «actor» Tax Calculator alternate notation for a computer system actor Actores apoyo en la derecha Manager Cash In «actor» Accounting System «actor» Sales Activity System Analyze Activity «actor» HR System Manage Security System Administrator Manage Users... use case 16

17 Ejemplo Ejemplo 17

18 Inclusión y extensión Ejemplo maquina de refrescos Abrir puerta, relacion <<include>> Generalización Los casos de uso admiten generalización y herencia Relacion <<extend>> Los actores también 18

19 Índice Fase de Inicio Comprensión de los requisitos Requisitos Modelo de Casos de Uso Identificarlos Formatos UML Visión Glosario Especificaciones complementarias Visión del proyecto Es viable? Comprar o construir? 1000 o Seguimos o no? Vislumbrar el alcance del producto, visión y análisis del negocio Responder la pregunta: Esta de acuerdo el personal en la visión del proyecto y merece la pena invertir en un estudio mas serio? -Es necesaria una exploración de los requisitos (preliminar) -Puede ser una etapa muy breve (1-2 semanas), especialmente si se tiene experiencia; obvio 19

20 Visión del proyecto Grandes ideas Porque se propone el proyecto Cuales son los problemas Que personas hay involucradas y que necesitan Apariencia de la solución propuesta Visión: Ejemplo PDV Historia de revisiones Borrador #, fecha, descripcion, autor Introducción Una aplicación PDV, tolerante a fallos, múltiples interfaces, integracion con sistemas de terceros Orientación Oportunidad del negocio Lo que existe no es adaptable, no extensible Enunciado del problema Los sistemas son inflexibles, dando problemas a los cajeros Posición en el mercado A quien esta dirigido Alternativas, competencia, y en que se diferencia Descripción del personal involucrado Demografía de mercado, no usuarios Resumen de usuarios Objetivos de alto nivel: procesar ventas rapida y robustamente Objetivos de usuarios: Listas de actor-objetivos objetivos Cajero-Procesar ventas Administrador-Gestionar usuarios Visión general del producto Perspectiva: Estará en las tiendas o en terminales móviles cercanos a las tiendas Resumen de beneficios Licencia e instalación Etc. 20

21 Visión: Plantilla No confundir con características 21

22 Índice Fase de Inicio Comprensión de los requisitos Requisitos Modelo de Casos de Uso Identificarlos Formatos UML Vision Glosario Especificaciones complementarias Glosario: Ejemplo 22

23 Glosario: Ejemplo Glosario Comenzarlo cuanto antes Palabras que tienen distinto significado Historia de revisiones Borrador #, fecha, descripcion, autor Termino Definicion Alias. Formato: Tipo, longitud, unidad Relaciones con otros elementos Rango de valores Reglas de validacion 23

24 Índice Fase de Inicio Comprensión de los requisitos Requisitos Modelo de Casos de Uso Identificarlos Formatos UML Vision Glosario Especificaciones complementarias Especificación complementaria Introducción Funcionalidad Funcionalidad básica común a muchos casos de uso Registro y gestión de errores Todos los errores se registraran en almacenamiento persistente Seguridad Lo referente a la autenticación de usuarios (claves, protocolos) Facilidad de uso Factores humanos Legibilidad y visibilidad del texto Ergonomía, salud Utilizar sonidos, ya que el cajero mira al cliente Fiabilidad Capacidad de recuperación. (Mucho analisis) Rendimiento Cuellos de botella potenciales. Soporte Adaptabilidad Configurabilidad Restricciones de implementación Java, C++ 24

25 Especificación complementaria Componentes adquiridos Componentes de libre distribución Intentar maximizarlos Interfaces y hardware Pantalla táctil Escaner laser Impresora de recibos Interfaces software Reglas del dominio Ej: Reglas de descuento del comprador, empleado 20%. Variabilidad: alta. Fuente: politica de tienda. Cuestiones legales Licencias propias y ajenas. Especificacion complementaria 25

26 Relacion con otros componentes Sample UP Artifact Relationships Domain Model Business Modeling Sale date * Sales... LineItem... quantity objects, attributes, associations Use-Case Model Process Sale scope, goals, actors, features Vision Requirements Process Sale Cashier Use Case Diagram use case names 1. Customer arrives Cashier makes new sale Use Case Text system events terms, attributes, validation Glossary : System Operation: : Cashier enteritem( ) make system NewSale() Post-conditions: operations enteritem -... (id, quantity) Operation Contracts System Sequence Diagrams Supplementary Specification non-functional reqs, quality attributes requirements : Register Design Model : ProductCatalog : Sale Design enteritem (itemid, quantity) spec = getproductspec( itemid ) addlineitem( spec, quantity ) Secuencia de captura Por donde empezamos? No estricto Borrador breve de la Visión del proyecto Identificar los objetivos de usuario Escribir algunos casos de uso y comenzar el documento de especificaciones complementarias Refinar la Visión, resumiendo a partir de la informacion de casos de uso. 26

27 Esfuerzo Gestión de documentos Artefactos recogidos solo digitalmente, online y accesibles. No se trata de poner información duplicada: gestionar correctamente la información mediante enlaces o hipervínculos. 27

28 Índice Fase de Inicio Comprensión de los requisitos Requisitos Modelo de Casos de Uso Identificarlos Formatos UML Especificaciones complementarias Vision Glosario Artefactos Fase Inicio Modelo de Casos de Uso Mucha documentación? Guía Solo se completan parcialmente en esta fase Lo importante no es el documento, sino pensar los problemas y luego Registrar esos pensamientos On-Line No si no aportan valor añadido Ej. Casos de Uso Lista general 10% en detalle Reutilización de documentación Orden, nomenclatura Programación Algunas pruebas de conceptos (Interfaz) y experimentación critica 28

29 Recordar: Fase de Inicio Completo Procesar Venta Gestionar devoluciones Informal Procesar Alquiler Analizar actividad de ventas Breve Abrir caja Cerrar caja Gestionar usuarios Poner en marcha Etc. No se entiende Fase Inicio si: La duración > pocas semanas Se intenta definir la mayoría de los requisitos Se piensa que las estimación son fiables Se define la arquitectura Se cree que la secuencia es Definición de requisitos Diseño arquitectura Implementación No hay artefacto de Visión y Análisis del Negocio No se identificaron la mayoría de los casos de uso Se escribieron con detalle la mayoría de los casos de uso Ninguno de los casos de uso se escribió con detalle 29

30 Ejercicios Juego 30