Ingeniería de Software I Proceso Racional Unificado (RUP)

¿Qué es el RUP? RUP es un proceso de desarrollo de software: Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y cómo). Objetivos: Asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles. Dirigido por casos de uso, centrado en la arquitectura, iterativo (mini-proyectos) e incremental (versiones).

Beneficios del RUP Aumenta la productividad de los desarrolladores mediante acceso a: Base de conocimiento, plantillas y herramientas. Se centra en la producción y mantenimiento de modelos del sistema más que en producir documentos. RUP es una guía de cómo usar UML de la forma más efectiva.

Fases y Flujos de Trabajo

Fase de Inicio Su objetivo Lo que deberá hacer el producto Reducción de los peores riesgos Preparación para el análisis del negocio inicial

Fase de Inicio Un documento de visión general: Caso de negocio: Requerimientos generales del proyecto Características principales Restricciones Caso de negocio: Contexto Criterios de éxito Pronóstico financiero Identificación inicial de riesgos. Plan de proyecto. Uno o más prototipos.

Fase de Inicio Modelo inicial de casos de uso (10% a 20 % listos). Glosario.

Fase de Elaboración Objetivos: Obtener la línea base de la arquitectura Capturar la mayoría de los requisitos Reducir los peores riesgos Estimar costos y fechas Planificar la fase de construcción con algún detalle

Fase de Elaboración Modelo de casos de uso (80% completo) con descripciones detalladas. Otros requerimientos no funcionales o no asociados a casos de uso. Descripción de la Arquitectura del Software. Un prototipo ejecutable de la arquitectura. Lista revisada de riesgos y del caso de negocio. Plan de desarrollo para el resto del proyecto. Un manual de usuario preliminar.

Fase de Construcción Objetivos: El desarrollo del sistema Garantía de que el producto puede comenzar su transición a los clientes

Fase de Construcción El producto de software integrado y corriendo en la plataforma adecuada. Manuales de usuario. Una descripción del “release” actual.

Fase de Transición Objetivos: Garantizar que se tiene el producto preparado para su entrega (versión del producto) Entrenar a los usuarios a utilizar el sistema.

Fase de Transición Pruebas Beta para validar el producto con las expectativas del cliente Ejecución paralela con sistemas antiguos Conversión de datos Entrenamiento de usuarios Distribuir el producto

Fases e Hitos (Milestones) Inicio Elaboración Construción Transición Objetivos (Visión) Arquitectura Capacidad Operacional Inicial Release del Producto tiempo Hito: Punto de terminación de la iteración cuando se toma alguna decisión o evaluación importante

Proceso de Ingeniería de Software Workflows (Disciplinas)

Proceso de Ingeniería de Software Workflows (Disciplinas) Workflows Primarios Business Modeling (Modado del Negocio) Requirements (Requisitos) Analysis & Design (Análisis y Diseño) Implementation (Implementación) Test (Pruebas) Deployment (Despliegue) Workflows de Apoyo Environment (Entorno) Project Management (Gestión del Proyecto) Configuration & Change Management (Gestión de Configuración y Cambios)

Artefactos Resultado parcial o final que es producido y usado durante el proyecto. Son las entradas y salidas de las actividades Un artefacto puede ser un documento, un modelo o un elemento de modelo Conjuntos de Artefactos Business Modeling Set Requirements Set Analysis & Design Set Implementation Set Test Set Deployment Set Project Management Set Configuration & Change Management Set Environment Set

Proceso Iterativo e Incremental El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran a los usuarios y clientes (mini-proyectos) En el ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida en cascada a menor escala Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes

Proceso Iterativo e Incremental Las actividades se encadenan en una mini-cascada con un alcance limitado por los objetivos de la iteración Req. Análisis Diseño Imple. Pruebas e Integración n veces

Proceso Iterativo e Incremental Cada iteración comprende: Planificar la iteración (estudio de riesgos) Análisis de los Casos de Uso y escenarios Diseño de opciones arquitectónicas Codificación y pruebas. La integración del nuevo código con el existente de iteraciones anteriores se hace gradualmente durante la construcción Evaluación de la entrega ejecutable (evaluación del prototipo en función de las pruebas y de los criterios definidos) Preparación de la entrega (documentación e instalación del prototipo)

Las iteraciones sobre el ciclo de vida Cada una de las cuatro fases termina con hito principal.

Plan de iteraciones El número de iteraciones planeado para cada fase depende, básicamente de la complejidad del sistema propuesto. Un proyecto simple puede realizarse con una sola iteración por fase. Un proyecto mas complejo podría comprender el siguiente numero de iteraciones.

Plan de iteraciones Fase de Inicio: una iteración, principalmente dedicada a definir el ámbito del sistema Fase de elaboración: dos iteraciones, la primera para esbozar la arquitectura y la segunda para completar la línea base de la arquitectura

Plan de iteraciones Fase de construcción: dos iteraciones, para asegurar que los incrementos resultantes funcionan satisfactoriamente Fase de transición: una iteración

Proceso Iterativo e Incremental Enfoque Secuencial Enfoque Iterativo e Incremental

Iteraciones Cada fase consiste en las iteraciones del desarrollo en las cuales un subconjunto del sistema se desarrolla. En general, estas iteraciones: Reducen los riesgos técnicos; Proporcionan versiones tempranas; Permiten mayor flexibilidad para el lanzamiento de cada característica; y Permiten controlar los cambios con respecto al alcance de manera efectiva con las iteraciones durante los ciclos.

Proceso Centrado en la Arquitectura Arquitectura de un sistema es la organización o estructura de sus partes más relevantes Un arquitectura ejecutable es una implementación parcial del sistema, construida para demostrar algunas funciones y propiedades RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo Inception Elaboration Construction Transition Architecture

Fases, Base Line, Versión, Release ciclo de desarrollo ciclo de evolución El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versión del producto Las fases son: Cada ciclo está compuesto por fases y cada una de estas fases está compuesta por un número de iteraciones Inicio o Estudio de oportunidad Elaboración Construcción Transición Inicio o Estudio de oportunidad (inception) Define el ámbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define una arquitectura básica Se planifica el proyecto considerando recursos disponibles El producto se desarrolla a través de iteraciones donde cada iteración involucra tareas de análisis, diseño e implementación Las fases de estudio y análisis sólo dieron una arquitectura básica que es aquí refinada de manera incremental conforme se construye (se permiten cambios en la estructura) Gran parte del trabajo es programación y pruebas Se documenta tanto el sistema construido como el manejo del mismo Esta fase proporciona un producto construido junto con la documentación Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de marketing, empaquetado atractivo, instalación, configuración, entrenamiento, soporte, mantenimiento, etc. Los manuales de usuario se completan y refinan con la información anterior Estas tareas se realizan también en iteraciones versión (subconjunto de artefactos estable y ejecutable) release (producto al final de una iteración, lanzado para su puesta en producción) base line (release asociada a un hito)

Base Line Conjunto de artefactos revisados y aprobados que constituyen una base convenida para la evolución y desarrollo adicional y que se puede cambiar solamente a través de la administración de cambios. Asegurarse qué subsistemas, cuándo alcanzan un nivel especifico de la madurez, son la línea base para que esté disponible para el release (“liberación), o la reutilización en iteraciones subsecuentes del proyecto y/o otros proyectos.

Base Line Se considera como candidato para una Línea Base el conjunto de archivos y directorios bajo control de versión que son desarrollados, integrados y puestos juntos en un release. Una línea base se crea al final de cada iteración

Versiones Identifican el estado de un elemento de configuración o una configuración en un punto definido en el tiempo Conjunto de artefactos relativamente completo y consistente –que incluye posiblemente una construcción- entregado a un usuario interno o externo;

Versiones La mayoría de los programas grandes se desarrollan en release evolutivos. Un release podría estar en uso del cliente, mientras que otro está en prueba, y el tercero todavía está en el desarrollo. Si se encuentran problemas en cualquiera de las versiones, los arreglos necesitan ser propagados entre ellas. La confusión puede acrecentarse conduciendo a arreglos costosos y retrabajo a menos de que los cambios sean cuidadosamente controlados y supervisados.

Release Es una versión que se ha puesto disponible a los usuarios. La frecuencia y la formalidad de los releases son descritos en el plan del CM (Configuration Management ). El grado de la formalidad es claramente mucho más alto para un producto que es liberado a un cliente, que el que es generado para la estructura o la revisión siguiente de la iteración.

Release Regularmente está asociado a un baseline de una configuración

Esfuerzo y dedicación por Fases en RUP Inicio Elaboración Construcción Transición Esfuerzo 5 % 20 % 65 % 10% Tiempo Dedicado 10 % 30 % 50 %

Distribución de Recursos por Fases en RUP

Roles: Analista de Sistemas El papel del analista de sistemas conduce y coordina la captura de requisitos y el modelado de casos de uso que definiendo la funcionalidad del sistema y delimitando el sistema.

Roles: Diseñador El diseñador define las responsabilidades, operaciones, atributos y relaciones entre las clases y determina cómo éstas deben ajustarse a el ambiente de implantación. Además el diseñador puede tener la responsabilidad de uno o más paquetes de diseño o diseño de susbsistemas.

Roles: Diseñador de pruebas El Diseñador de pruebas es el responsable de definir los métodos de prueba y asegurarse del éxito de su implementación. Debe identificar las técnicas apropiadas, herramientas y guías para implementar las pruebas requeridas, y brindar dirección en los requisitos correspondientes al esfuerzo de las pruebas.

Roles: Programador (Implementador) El programador es responsable de desarrollar y probar los componentes, de acuerdo a los estándares adoptados para el proyecto, y la integración de los subsistemas.

Roles: Integrador Los desarrolladores entregan sus componentes probados en un espacio de trabajo de la integración, mientras que los integradores los combinan para producir una estructura. Un integrador es también responsable de planear la integración, que ocurre en los niveles del subsistema y de sistema, con cada uno teniendo un espacio de trabajo separado de la integración. Los componentes probados se entregan del espacio de trabajo privado del desarrollo de un ejecutor en un espacio de trabajo de la integración del subsistema,

Roles: Administrador de proyecto El Administrador de Proyecto asigna recursos, asigna prioridades, coordina interacciones con los clientes y usuarios, y generalmente mantiene al equipo de proyecto centrado en la meta. Además establece un conjunto de prácticas que aseguran la integridad y calidad de los artefactos del proyecto.

Roles: Administrador de proyecto

Roles: Administrador de la Configuración El Administrador de la Configuración proporciona toda la infraestructura y el ambiente la administración de la configuración (CM) al equipo del desarrollo de producto. La función del CM apoya la actividad del desarrollo de producto de modo que los desarrolladores y los integradores tengan espacios de trabajo apropiados para construir y para probar su trabajo, y de modo que todos los artefactos estén disponibles para la inclusión en la unidad del despliegue según lo requerido. El encargado de la configuración también tiene que asegurarse de que el ambiente del CM facilite la revisión del producto, y las actividades que siguen del cambio y del defecto. El encargado de la configuración es también responsable de escribir el plan del CM y de dar a conocer la estadística del progreso basada en peticiones del cambio.

Roles: Administrador de la Configuración

Referencias El Proceso Unificado de Desarrollo de Software, Ivar Jacobson, Grady Booch, James Rumbaugh RUP 2001 UML y Patrones, Craig Larman