Ingeniería del Software II

Transcripción

1 Bloque III: Proceso Unificado Simona Bernardi Dipartimento di Informatica Università di Torino (Italia) Duración: 4 horas Objetivo: Conocer un proceso de desarrollo de software diferente a OMT Simona Bernardi 1 Bibliografía Teoría Proceso Unificado Jacobson, I.Booch, G.; Rumbaugh, J.: El Proceso Unificado de Desarrollo de Software Addison Wesley ISBN: Larman C.: Applying UML and patterns: An introduction to O-O design and iterative development Prentice Hall, 3rd edition. ISBN: Simona Bernardi 2

2 Lección 1 Introducción UP Primera fase: Ideación Disciplina: Requerimientos Casos de uso Otros artefactos para capturar requerimientos Caso de estudio VolBank Simona Bernardi 3 Proceso Unificado Booch, Rumbaugh, Jacobson UML (Unified Modeling Language) notación para representar sistemas software estándar OMG (Object Management Group) desde 1997 UP (Unified Process) no es un estándar es un proceso de desarrollo del sw que utiliza UML versión comercial (IBM- Rational): RUP (Rational Unified Process) Simona Bernardi 4

3 Proceso Unificado (II) Es un esquema general de proceso (framework) que tiene que ser adaptado a tipos diferentes de proyectos Características Iterativo e incremental Iteraciones iniciales guiadas por el riesgo, los clientes y la arquitectura Flexible y puede ser aplicado utilizando una aproximación ágil Simona Bernardi 5 UP: Iterativo e incremental Requerimientos Diseño Implementación & Test & Integración & Más diseño Integración final & Test de sistema tiempo Requerimientos Diseño Implementación & Test & Integración & Más diseño Integración final & Test de sistema El feedback de la iteración N lleva al refinamiento y adaptación de requerimientos y diseño en la iteración N+1 3 semanas (por ejemplo) duración fija de las iteraciones (timeboxed) El sistema crece en manera incremental Simona Bernardi 6

4 UP: iteraciones iniciales Los objetivos primarios de las iteraciones iniciales son elegidos Para identificar y reducir los riesgos mayores Para construir y hacer visible las características más imporantes para el cliente Para estabilizar el núcleo de la arquitectura sw Simona Bernardi 7 UP ágil UP anima el uso de prácticas ágiles introducidas por otros métodos: Iteraciones cortas y timeboxed Refinamiento de planes, de requerimientos, del proyecto Grupos de trabajo auto-organizados que se coordinan en reuniones diarias (Scrum) Programación en parejas y desarrollo guiado por test (XP=eXtremeProgramming) Modelación ágil: el objetivo es la comprensión del sw no la documentación del mismo Simona Bernardi 8

5 Fases de UP (I) Ideación (Inception) Visión aproximada, estudio económico, alcance, estimaciones aproximadas de gastos y tiempos Lifecycle objective milestone (hito) Elaboración (Elaboration) Visión refinada, implementación iterativa del núcleo de la arquitectura, solución de los riesgos mayores, identificación de la mayoría de requerimientos y del alcance, estimaciones más realistas Lifecycle architectural milestone Simona Bernardi 9 Fases de UP (II) Construcción (Construction) Implementación iterativa de los elementos que quedan, más fáciles y con menor riesgo, preparación entrega Initial operational capability milestone Transición (Transition) Beta test, entrega producto, adiestramiento de usuarios Product release milestone Simona Bernardi 10

6 UP: fases e iteraciones Ciclo de desarrollo iteración fase ideación. elaboracíón costrucción transición milestone final de una iteracción cuando se verifica una decisión o evaluación significativa release un subconjunto estable y ejecutable del producto final. El final de cada iteracción produce una release minor incremento la diferencia (delta) entre las releases de dos iteracciones consecutivas.. producción final release en este punto el sistema viene entregado al cliente Simona Bernardi 11 Disciplinas UP Las actividades en UP se ejecutan en el ámbito de disciplinas Una disciplina es un conjunto de actividades y artefactos (work product, en RUP) - como por ejemplo, código, esquema DB, documentos, modelos - en una área específica Simona Bernardi 12

7 Disciplinas UP e iteraciones Veremos estas Disciplinas UP Modelación Business Requerimiento Diseño Implementación Test Una iteración de 4 semanas, por ejemplo. Un mini-proyecto que incluye trabajo en muchas de las disciplinas y termina con un ejecutable estable. Aunque una iteración incluya trabajos en (casi) todas las disciplinas, el esfuerzo cambia en el tiempo. Este es solo un ejemplo. Desarrollo Gestion de la configuración y cambio Gestion proyecto Infraestructura Iteración Simona Bernardi 13 Fases y disciplinas Atención! Las fases son secuenciales y el final de una fase corresponde en una milestone Las disciplinas (tipologías de actividades) no son secuenciales y se ejecutan en el proyecto en cada iteración El número de iteraciones depende de las decisiones del manager de proyecto y de los riesgos del proyecto Simona Bernardi 14

8 Uso de UML en UP UP usa sólo UML como lenguaje de modelado (por ejemplo, no se usan DFD) Los diagramas UML se usan con variabilidad: si un diagrama no es necesario no se usa, pero tal elección se indica explícitamente. Hay que personalizar UP antes de usarlo Los diagramas se usan en UP siguiendo las características de iteración e incremento (incrementos definidos sobre un mismo diagrama) UP indica cuando usar un diagrama Simona Bernardi 15 Personalización del proceso En UP casi todo (entre artefactos y prácticas) es opcional, excepto el desarrollo iterativo y guiado por el riesgo, la verificación continua de la calidad y naturalmente el código La elección de las prácticas y artefactos UP para un proyecto se resume en un documento llamado Escenario de Desarrollo (artefacto de la disciplina Infraestructura) Simona Bernardi 16

9 Escenario de desarrollo (ejemplo) Disciplina Modelado del negocio Práctica Modelado ágil, workshop requerimientos Artefacto Iteraciones Modelo de dominio Id. (I1) Elabor. (E1..Ei) Inicio Constr. (C1..Cj) Trans. (T1..Tk) Requerimientos Diseño Implementación Gestión proyecto Workshop requerimientos, ejercicio sobre visión Modelado ágil, desarrollo guiado por test Desarrollo guiado por test, programación en parejas, integración continua, estandar de códificación Gestión proyecto ágil, reuniones Scrum diarias Modelos UC Visión Especif. Supl. Glosario Modelo proyecto Doc. Arqu. SW Modelo de datos In. In. In. In. Inicio Inicio Inicio Simona Bernardi 17 No se ha comprendido el desarrollo iterativo o UP si... Se intenta definir todos los requerimientos antes de empezar el diseño o implementación Se dedican dias/semanas a modelar con UML antes de empezar a programar Se piensa: ideación = requerimientos, elaboración = diseño, construcción = implementación (o sea, se adopta el pensamiento en cascada ) Se piensa que el objetivo de la elaboración es definir de manera completa y detallada los modelos, que serán traducidos a código durante la construcción Se piensa que la duración adecuada para una iteración es 3 meses, en lugar de 3 semanas Se intenta planear un proyecto en detalle desde el comienzo hasta el final, y prever de manera especulativa todas las iteraciones y qué tiene que ocurrir en cada una Simona Bernardi 18

10 Lección 1 Introducción UP Primera fase: Ideación Disciplina: Requerimientos Casos de uso Otros artefactos para capturar requerimientos Caso de estudio VolBank Simona Bernardi 19 Ideación (Inception) Permite establecer una visión común y el alcance del proyecto (estudio de viabilidad) Durante la ideación: Se analizan el 10% de los casos de uso en detalle aprox. Se analizan los requerimientos no funcionales más críticos Se hace un estudio económico (se establece el orden de magnitud de la estimación de los gastos) Se prepara el ambiente de desarrollo Duración: normalmente breve (primer workshop de requerimientos y planificación de la primera iteración de la elaboración) Simona Bernardi 20

11 Artefactos en la ideación (I) Modelo de casos de uso Requerimientos funcionales. Identificación de la mayoría de los nombres de los casos de uso, 10% descripción detallada Especificaciones suplementares Otros requerimientos (no funcionales) Visión y estudio económico Objetivos y vínculos de alto nivel, estudio económico, resumen del proyecto Glosario Diccionario de datos y terminología del dominio Simona Bernardi 21 Artefactos en la ideación (II) Lista de riesgos y plan de gestión de riesgos Riesgos e ideas para encararlos Prototipos y proof-of-concept No son demasiados? Aclarar la visión y verificar las ideas técnicas Se eligen los que añaden valor al proyecto Plan de la iteración Se completan parcialmente Qué hacer en la 1 a iteración de la elaboración Son preliminares y aproximativos Plan de las fases plan de desarrollo del sw Hipótesis sobre la duración y esfuerzo de la elaboración Escenario de desarrollo Personalización de UP (pasos y artefactos) Simona Bernardi 22

12 Lección 1 Introducción UP Primera fase: Ideación Disciplina: Requerimientos Casos de uso Otros artefactos para capturar requerimientos Caso de estudio VolBank Simona Bernardi 23 Requerimientos que progresan Capacidades y condiciones a las que el sistema (y el proyecto) tiene que ser conforme UP propone un conjunto de best practice para gestionar los requerimientos que cambian Modelo FURPS+ Functional: características de comportamiento, capacidad Usability: factores humanos, help, documentación Reliability: frecuencia fallos, capacidad de reparación Performance: tiempo de respuesta, throughput, uso recursos Supportability: adaptación, manutención, configurabilidad +: requerimientos complementarios y secundarios (limitación recursos, lenguajes y hw, de interfaz, legales) Simona Bernardi 24

13 Relaciones entre artefactos UP Modelo de dominio Modelado del negocio... Perfil ofrece Tiempo cantidad Requerimientos Voluntario Depositar tiempo Diagrama de casos de uso Operación: InsertaTiempo(..) Pre-condiciones:. Post-condiciones:.. Contratos de operaciones Requerimientos Objetos, atributos,asociaciones Modelo de casos de uso Nombres de casos de uso Operaciones sistema Depositar Tiempo 1.El Voluntario inserta. 2. El sistema actualiza 3. Texto de casos de uso Eventos de sistema :Sistema :Voluntario Diseño InsertaTiempo() InsertaTiempo (desde,a,horas) Alcance, objetivos, actores Términos, atributos, verificación Requerimientos no funcionales, Atributos de calidad Vision Glosario Diagrama de secuencia de sistema :SecciónUsuario Modelo de diseño :ArchivoTiempos SalvaTiempoPerfil(idperfil, desde,a,horas): t InsertaTiempo(t) Especificaciones suplementares :Perfil Simona Bernardi 25 Casos de uso y UP (I) UP es una metodología use-case driven Los requerimientos funcionales se describen con casos de uso Los casos de uso se usan para planear las iteraciones El diseño se basa sobre los casos de uso a realizar Los test se basan sobre los casos de uso realizados Los casos de uso influyen en la redacción de manuales usuario y en la definición de la visión del proyecto Son descripciones (textuales) interesantes de escenarios de uso del sistema sw Actores: algo o alguien con comportamiento Escenario: secuencia de acciones e interacciones entre el sistema y actores Caso de uso: colección de escenario correlados (de exíto y de fallo) que describen un actor que usa el sistema para alcanzar un objetivo Simona Bernardi 26

14 Casos de uso y UP (II) Modelo de casos de uso modelo de las funcionalidades del sistema NO es un diagrama UML: es un modelo textual! Puede incluir un diagrama UML de casos de uso que sirve como modelo de contexto del sistema y como índice de los nombres de casos de uso Los casos de uso no son una práctica del OOA/D clásica pero son útiles para representar los requerimientos como input del OOA/D Los casos de uso definen contratos en relación al comportamiento del sistema Simona Bernardi 27 Casos de uso y UP (III) Actores Identifican papeles Tres tipos: principales, de soporte, fuera escena Casos de uso Tres formatos: breve, informal, detallado Durante la ideación se describen el 10% aprox. de los casos de uso entre los más criticos en formato detallado Se usan template de formato (detallado) Simona Bernardi 28

15 Ejemplo de template [Cockburn] Sección Nombre UC Alcance Nivel Actor principal Partes interesadas Pre-condiciones Garantías de exíto Escenario principal de exíto Extensiones Requerimientos especiales Otras info. Comentario Empieza con un verbo El sistema Objetivo usuario/sub-función Pide al sistema un servicio A quien interesa este UC Qué tiene que ser verdadero al comienzo de este UC Qué tiene que ser verdadero si el UC viene ejecutado con éxito Escenario común de éxito (sin condiciones) Escenarios alternativos (de éxito y fallo) Requerimientos no funcionales correlados Problemas abiertos, etc Simona Bernardi 29 Casos de uso: iteración e incremento Iteración Elección de los casos de uso a detallar y su realización en código: la implementación provee el feedback Incremento de la descripción: de formato breve, informal al detallado, finalización de alguna sección del template nuevos casos de uso Simona Bernardi 30

16 Como escribir los casos de uso (ideación y elaboración) Siempre hay soluciones mejores alternativas al escenario principal Estilo esencial y conciso Ignorar las interfaces, concentrarse en el objetivo usuario Estilo caja negra Indicar qué hace el sistema, no cómo lo hace Concentrarse sobre el resultado de interés que el UC produce para el actor principal Elegir entre los formatos breve, informal, detallado Simona Bernardi 31 Cómo identificar los casos de uso (ideación y elaboración) Identificar los actores principales y sus objetivos siempre son externos al sistema y ayudan en definir los confines del mismo Se puede usar una check-list para identificarlos Definir un diagrama de casos de uso UML que contiene los que cumplen los objetivos de los actores principales (diagrama de contexto) Verificar la utilidad de los casos de uso identificados Pidiendo a otros (test del jefe) Añaden valor? (test EBP - proceso elemental de business) Evaluando la dimensión de los casos de uso Simona Bernardi 32

17 Lección 1 Introducción UP Primera fase: Ideación Disciplina: Requerimientos Casos de uso Otros artefactos para capturar requerimientos Caso de estudio VolBank Simona Bernardi 33 Ideación en Volbank: actores y objectivos Necesitado Organización VolBank Registrar pedido ayuda Sistema VolBank Objetivo: Obtener ayuda Registrar perfil Servicio Social Objetivo: Controlar los voluntarios para trabajos particulares Asociación Voluntariado Objetivo: Poner en contacto voluntarios y necesitados Organización Voluntarios Objetivos: Registrar pedidos y ofertas ayuda, Asociar necesitados y voluntarios Confín sistema Volbank Depositar oferta ayuda Combinar ofertas y pedidos... Voluntario Objetivo: Ofrecer ayuda Simona Bernardi 34

18 Ideación en VolBank: descripción casos de uso Dos ejemplos: Registrar pedido ayuda (formato breve) Combinar ofertas y pedidos (formato detallado) Ejercicio (para casa): Escribir en formato breve o informal los otros casos de usos: Registrar perfil Depositar oferta ayuda Falta algun caso de uso importante? Simona Bernardi 35 Lección 1 Introducción UP Primera fase: Ideación Disciplina: Requerimientos Casos de uso Otros artefactos para capturar requerimientos Caso de estudio VolBank Simona Bernardi 36

19 Otros artefactos Los casos de uso no permiten capturar todos los requerimientos Especificaciones Complementarias Capturan e identifican otros tipos de requerimientos (URPS+) Glosario Captura términos y definiciones, puede jugar el papel de diccionario de datos Visión Resumen del proyecto, sirve para comunicar las ideas de alto nivel Reglas de negocio (o dominio) Captura las reglas que trascienden del proyecto en particular (ejemplo, leyes de impuestos) Simona Bernardi 37 Ideación y otros artefactos Disciplina Artefacto Ideac. Elabor. Iteraciones (I1) (E1..Ei) Modelado del negocio Modelo de dominio Inicio Constr. (C1..Cj) Trans. (T1..Tk) Requerimientos Diseño Modelo casos de uso Visión Especif. Complementarias Glosario Reglas de dominio Modelo proyecto Doc. Arqu. SW Modelo de datos Recordar: UP es un metodo iterativo e incremental, los requerimientos evolucionan con el proyecto, los artefactos se crean durante la ideación, se detallan durante la elaboración In. In. In. In. In. Inicio Inicio Inicio Simona Bernardi 38

20 Lección 1 Introducción UP Primera fase: Ideación Disciplina: Requerimientos Casos de uso Otros artefactos para capturar requerimientos Caso de estudio VolBank Simona Bernardi 39