Introducción al Unified Process Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010
Unified Process - UP Un framework de Proceso de Desarrollo de Software, una de cuyas versiones es el más documentado y comercializado: RUP. Primera descripción: The Unified Development Process, 1999, por Booch, Jacobson, Rumbaugh. Base conceptual: Definición del proceso (cómo ocurren las cosas), con foco iterativo e incremental. Use Case Driven, Architecture Centric, Risk Focused.
Unified Process Basado en 6 mejores prácticas de la industria de software: Desarrollo incremental Administración de requisitos Uso de arquitecturas basadas en componentes Modelamiento visual Verificación continua de la calidad Control de cambios Rational Unified Process: la versión originalcomercial de Rational/IBM.
Historia de UP-RUP 1995 1996 1997 1998 Rational Approach OMT Booch Requirements College Business Engineering Config and change mngmt Performance Testing Proc. Iterativo Use Case Rational Objectory Process 4.0 Rational Objectory Process 4.1 Rational Unified Process 5.0 Booch Jacobson Rumbaugh Objectory Process 3.8 1987 Suecia I. Jacobson UML 0.8 UML 1.0 UML 1.2 SQA Process Data Engineering Objectory UI Design RUP es una instancia específica y detallada de un proceso más genérico UP descrito por J+B+R en su libro
UP - Características Principales (1) Entrega una forma disciplinada de asignar tareas y responsabilidades. Su meta es asegurar la producción de software de alta calidad, que cumpla las necesidades de los usuarios, dentro de las restricciones. Utiliza el desarrollo iterativo para enfrentar el riesgo. Utilizado por miles de empresas a nivel mundial, en grandes y pequeños proyectos.
UP - Características Principales (2) El desarrollo se guía por casos de uso. Caso de uso: secuencia de acciones realizada por un sistema que produce un resultado observable de valor para un actor particular. Actor: alguien o algo fuera del sistema que interactúa con el sistema. Artefacto: cualquier entregable resultante del proceso de desarrollo. Puede ser un documento, código fuente, otros.
Elementos de Modelamiento UP Quién Trabajador Actividades Cómo Diseñador Análisis de Caso de Uso Diseño de Caso de Uso Qué Artefacto Responsable de Realización del Caso de Uso Trabajador, actividades y artefacto
Elementos de Modelamiento UP Cuándo Workflow de Modelamiento del Caso
Fases e Hitos de UP
Las Fases de RUP A diferencia de Cascada, los nombres de las fases RUP reflejan el estado y no las actividades. Concepción: especificación de la visión del producto final y su caso de negocio, definiendo el alcance del proyecto. Elaboración: planificación de las actividades y recursos necesarios, especificación de las características y el diseño de la arquitectura. Construcción: del producto y la evolución de la visión, la arquitectura y los planos, hasta que el producto esté listo para la entrega a la comunidad de usuarios. Transición: traspasar el producto a los usuarios, lo que incluye manufacturar, entregar, entrenar, dar soporte y mantener el producto hasta que los usuarios estén satisfechos.
ciclo de desarrollo iteración fase Inicio Elaboración Construcción Transición hito Objetivos del proyecto hito Arquitectura para el proyecto hito Capacidad operativa inicial hito Entrega del producto 11
Actividades de Cascada Diagrama Fases en UP
Los Recursos en el Tiempo
Roles RUP principales Cliente: Stakeholder Cliente Usuario Project Manager Deployment Manager Desarrollo: Business-process analyst/designers. Architect. Developer (Implementer + System Integrator) CM Manager Tester (Code reviewer + Test Designer + System Tester + Integration Tester + Performance Tester) Technical Writer + Course Developer
1. Fase de Concepción Análisis de Factibilidad Hito de cierre de la fase (Objetivo) Stakeholders acuerdan visión conjunta entre alcances, costos y calendario estimativo. Entendimiento de los requisitos (casos de uso primarios). Credibilidad de los costos (actuales y planificados), plazos, prioridades, riesgos y procesos de desarrollo. Arquitectura: profundidad y validez del prototipo arquitectural.
Resultado 1. Fase de Concepción Análisis de Factibilidad Documento de Visión 1.0: visión general de los requisitos centrales del proyecto, aspectos principales y restricciones. Modelo Casos de Uso: general. Glosario. Caso de Negocio inicial. Análisis de Riesgo inicial. Plan de proyecto, con fases e iteraciones.
2. Fase de Elaboración Mitigación de Riesgos Hito de cierre de la fase (Objetivo), responder las preguntas: La visión del producto está estable? La arquitectura está estable? Demo ejecutable resuelve los principales riesgos? Próxima fase está suficientemente detallada? Están todos los stakeholders de acuerdo? Estructura de costos aceptable?
Resultado: 2. Fase de Elaboración Mitigación de Riesgos Modelo casos de uso (al menos 80% detalle). Requisitos suplementarios. ( Doc. Requisitos 0.9) Descripción modelo arquitectura software. Prototipo ejecutable de la arquitectura. Listas revisadas: Riesgos y Casos de Negocio. ( Doc. Diseño 0.5) Plan de desarrollo para el proyecto (iteraciones, hitos, criterios evaluación). ( Carta Gantt o equiv. 1.0) se sigue ajustando
3. Construcción Desarrollo de los componentes definidos. Optimizar recursos de desarrollo. Lograr calidad rápidamente. Versiones útiles y reales. Hitos Producto estable y utilizable. Stakeholder listos para la transición. Costos reales vs. planeados aún aceptables.
3. Construcción Código Fuente. Componentes Ejecutables. Manual de Instalación inicial. Manual de Usuario inicial. Documentación de Diseño. Pruebas unitarias. ( Doc. de Diseño 1.0)
4. Estabilización El producto ya está instalado y los usuarios finales encuentran observaciones que requieren ser atendidas. Hitos Aceptación. Cierre formal. Inicio de periodos de garantía y/o de procesos de corrección de bugs. (Inicio proyecto nueva versión.) Entregables Doc. Diseño Final, Manual de Usuario y Administración en versiones definitivas.
Algunas plantillas de documentos relevantes durante el proceso PROCESO Y DOCUMENTOS
Fase: Concepción Documento de Visión y Alcances Especificación de Casos de Uso principales Análisis de Riesgo Plan (o Carta Gantt) de nivel general Minutas de Reunión
Consideraciones a la Documentación Todos los documentos se manejan con un formato estándar. Se usa un cuadro de versiones, con autores claramente indicados. Idealmente se manejan en un sistema colaborativo, donde los participantes aportan a la versión centralizada.
Documento Visión y Alcances Lograr acuerdo entre todos los interesados (stakeholders): 1. Introducción 4 1.1 Propósito 4 1.2 Ambito 4 1.3 Definiciones, Siglas, y Abreviaciones 4 1.4 Referencias 4 1.5 Resumen Ejecutivo 4 2. Posicionamiento 5 2.1 Oportunidad de negocio 5 2.2 Declaración del Problema 5 2.3 Declaración de Posicionamiento del Producto 5 Cuál es el problema? Cuáles serían criterios de éxito? Tener una idea general de la solución. Confirmar factibilidad y posible plan de trabajo (recursos, tiempo, costos). 3. Descripción de Clientes, Stakeholders y Usuarios 5 3.1 Demografía del Mercado 5 3.2 Resumen de Stakeholders 6 3.3 Resumen de usuarios 6 3.4 Alternativas y Competencia 6 4. Descripción Global de la Solución 6 4.1 Modelo de Negocios 6 4.2 Perspectiva del Producto de software 7 4.3 Resumen de capacidades 7 4.4 Supuestos y Dependencias 7 5. Restricciones 7 6. Rangos de Calidad 7
Doc. Casos de Uso Generales Contexto Diagrama de Contexto Actores Lista de Casos de Uso Caso de Uso N Nombre Descripción Flujo de Eventos Flujos Alternativos Diagrama Caso de Uso N+1 Nombre Descripción Flujo de Eventos Flujos Alternativos Diagrama Se incluye una descripción de contexto y lista general de casos de uso. Cada uso (de nivel general) se describe con el nivel de detalle adecuado a esta altura de la conversación (no requiere detalle técnico).
Análisis de Riesgo Importante hacerse la siguientes preguntas What are the assumptions and constraints for risk management? How will the risk management process be implemented? What are the steps in the process? What are the activities, roles, responsibilities, and deliverables for each step? Who will perform risk activities? What are the skill requirements? Is there any additional training? How does risk management at the project relate to enterprise level efforts? What kinds of tools or methods will be used? What definitions are used to classify and estimate risk? How will risks be prioritized? How will contingency and risk plans be created and executed? How will risk control activities be integrated into the overall project plan? What activities will team members be doing to manage risk? How will status be communicated among the team and project stakeholders? How will progress be monitored? What kind of infrastructure will be used (databases, tools, repositories) to support the risk management process? What are the risks of risk management? What resources are available for risk management? What are the critical dates in the schedule for implementing risk management? Who is the sponsor and who are the stakeholders?
Análisis de Riesgo El riesgo es inherente a todo proceso. La administración proactiva es más efectiva. Identificación en positivo. Verificación contínua. Mantener comunicación abierta. Especificar primero, luego administrar.
Análisis de Riesgo
Plan de proyecto / Gantt Puede usarse el formato Carta Gantt, o bien otro formato más simple (p.ej. Sprint Plan de Scrum). En este momento, sólo debe incluir información de las actividades relevantes y una estimación gruesa del tiempo de estas actividades, organizadas en las 4 fases de UP. Ejemplo Sprint Plan de Scrum
Minutas de Reunión En contextos en los que la comunicación verbal y acuerdos son simples: usar un e-mail con resumen. En contextos más formales, utilizar un documento oficial. Contenido general: Fecha, Hora reunión. Asistentes (y datos contacto). Revisión de compromisos pendientes. Temas tratados. Nuevos compromisos con fecha entrega y responsable explícito.
Minutas de Reunión