RUP Rational Unified Process
Rational 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
RUP - 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 más de 1.000 empresas a nivel mundial, en grandes y pequeños proyectos.
RUP - 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.
Historia de 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 descrito por J+B+R en su libro
Elementos de Modelamiento RUP 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 RUP Cuándo Workflow de Modelamiento del negocio
Falencias del modelo Cascada 1. Los requerimientos se congelan. El problema, los usuarios, la tecnología, el mercado cambiarán. No se puede capturar requerimientos con suficiente precisión. 2. No siempre se puede lograr el diseño correctamente en papel antes de construir. 3. Manejo de riesgos: hacerlos visibles. 4. Estirar la escala de tiempo: proyectos equivalente entre 3 meses y 3 años. 5. Excesivo papeleo y poco feedback a etapas anteriores.
Enfoque RUP ITERAR para superar dificultades FASES e HITOS para ganar control.
Fases e Hitos de RUP
Las Fases de RUP 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.
Diagrama Fases en RUP
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. Inception Phase Hito de cierre de la fase (Objetivo) Stakeholders acuerdan visión conjunta entre alcances, costos y calendario estimativo. Entendimiento de los requerimientos (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.
1. Inception Phase Resultado Documento de Visión: visión general de los requerimientos 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.
1. Inception Phase
2. Elaboration Phase 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?
2. Elaboration Phase Resultado: Modelo casos de uso (al menos 80%). Requerimientos suplementarios. Descripción modelo arquitectura software. Prototipo ejecutable de la arquitectura. Listas revisadas: Riesgos y Casos de Negocio. Plan de desarrollo para el proyecto (iteraciones, hitos, criterios evaluación). Doc. Lev. Req 1.0 y Doc. de Diseño 0.8
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. Pruebas unitarias.
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.
Proceso y Documentos Algunas plantillas de documentos relevantes durante el proceso
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
Workflow de Requerimientos (1) Entendimiento de requerimientos 1. Necesidades de los stakeholders. Preguntas del tipo: cuál es el problema a resolver? cuál es el criterio de éxito? Establecen condiciones y contexto para el sistema. 2. Características del sistema. Se cambia del qué al cómo. 3. Requerimientos de software. Especifican funcionalidades entendibles por usuarios y desarrolladores.
Workflow de Requerimientos (2) Qué es un requerimiento? Condición o capacidad que la solución debe cumplir. Funcionales (comportamiento) y no-funcionales (atributos: usabilidad, desempeño). En RUP: Caso de Uso Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. Normalmente, en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso. Fuente: Wikipedia
Características de buenos reqs. Necesario: Lo que pida un requerimiento debe ser necesario para el producto. No ambiguo: El texto debe ser claro, preciso y tener una única interpretación posible. Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo técnico y especializado, aunque aún así debe referenciar los aspectos importantes Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requerimientos debe ser consistente también. Completo: Los requerimientos deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle. Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles. Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis, demostración o testeo.
En Otras Fases Elaboración: Lev. Req 1.0, Diseño Beta, Plan (Gantt) detallado actualizado. Construcción: artefactos de código, Diseño 1.0, Gantt actualizada, docum. de instalación. Transición: manuales, capacitación, etc.
Modelamiento con UML Unified Modeling Language
Casos de Uso Actores: elementos que interactúan con la solución, lo que incluye tanto a usuarios, como a elementos externos al sistema o aplicación, como son bases de datos externas, archivos, u otros sistemas. Funcionalidades o Casos de Uso, que describen una operación o un conjunto de operaciones que se pueden gatillar por parte de un usuario o de otro actor, y que producen un resultado medible. Cada actor puede activar un caso de uso (es decir, su decisión inicia el funcionamiento descrito por dicho caso de uso), o bien, el actor puede recibir la acción de un caso de uso iniciado por otro lado. Esto se representa por una flecha unidireccional, que indica quién activa a quién. Actor1 Caso de Uso
Diagrama de Casos de Uso
Diagrama de Clases Clases: con sus respectivos elementos componentes. Estas se representan por un rectángulo que interiormente describe los componentes, lo que se verá en detalle más adelante. Clase: Vehículo Relación de Herencia: identificada por una flecha de línea sólida y una punta triangular vacía, que va desde la clase derivada a la clase padre. Relación de Composición: que define que una clase contiene una o más instancias de otra clase, y se identifica por una línea sólida, que puede terminar en flecha con punta abierta, e incluye un rombo en la mitad, donde se describe la cardinalidad (o cuántas instancias de la clase referenciada están contenidas en cada instancia de la clase contenedora o compuesta). * 0..1
Diagrama de Clases Clase: Vehículo * 0..1 Clase: Automotora Clase: Motocicleta Clase: Camión