Ciclo de Vida de RUP
•En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 FASES secuenciales, cada cual concluye con un producto
intermedio.
•Al terminar cada fase se realiza una evaluación para determinar si se ha cumplido o no con los objetivos de la misma.
•Las fases son: Inicio (Inception), Elaboración, Construcción y Transición.
Diagrama General de RUP
En la representación gráfica del Modelo…
• Eje horizontal: representa el tiempo y muestra los aspectos del ciclo de vida del proceso. Es el aspecto dinámico del proceso a través de las fases, iteraciones y productos intermedios.
• Eje vertical: representa las disciplinas que agrupan actividades por su naturaleza. Aspecto estático del proceso a través de componentes, disciplinas, actividades, flujos de trabajo, artefactos y roles.
Fases de Ciclo de Vida
Inicio (Inception)
• El objetivo general de esta fase es establecer un acuerdo entre todos los interesados acerca de los objetivos del proyecto.
• Es significativamente importante para el desarrollo de nuevo software, ya que se asegura de identificar los riesgos relacionados con el negocio y requerimientos.
• Para proyectos de mejora de software existente, esta fase es más breve y se centra en asegurar la viabilidad de desarrollar el proyecto.
Elaboración
• El objetivo en esta fase es establecer la arquitectura base del sistema para proveer bases estables para el esfuerzo de diseño e implementación en la siguiente fase.
• La arquitectura debe abarcar todas las consideraciones de mayor importancia de los requerimientos y una evaluación del riesgo.
Construcción
• El objetivo de la fase de construcción es clarificar los requerimientos faltantes y completar el desarrollo del sistema basados en la arquitectura base.
• Vista de cierta forma esta fase es un proceso de manufactura, en el cual el énfasis se torna hacia la administración de recursos y control de la operaciones para optimizar costos, tiempo y calidad.
Transición
• Esta fase se enfoca en asegurar que el software esté disponible para sus usuarios.
• Se puede subdividir en varias interacciones, además incluye pruebas del producto para poder hacer el entregable del mismo, así como realizar ajuste menores de acuerdo a ajuste menores propuestos por el usuario.
• En este punto, la retroalimentación de los usuarios se centra en depurar el producto, configuraciones, instalación y aspectos sobre utilización.
Disciplinas
• Una disciplina es una colección de actividades relacionadas con un área de atención dentro de todo el proyecto.
• El grupo de actividades que se encuentran dentro de una disciplina principalmente son una ayuda para entender el proyecto desde la perspectiva clásica de cascada.
• Disciplinas
• Son un conjunto de actividades relacionadas con un área especifica dentro del proyecto.
• Están inspiradas en las etapas de un proceso de desarrollo en cascada
• Es una secuencia parcialmente ordenada de actividades que son realizadas para lograr un resultado particular, representado en un conjunto de artefactos.
• Las disciplinas son:
– Modelado de Negocios, Requerimientos, Análisis y Diseño, Implementación, Pruebas, Transición, Configuración y Administración del Cambio, Administración de Proyectos y Ambiente.
Modelado de Negocios
Los propósitos que tiene el Modelo de Negocios son:
• Entender los problemas que la organización desea solucionar e identificar mejoras potenciales.
• Medir el impacto del cambio organizacional.
• Asegurar que clientes, usuarios finales, desarrolladores y los otros participantes tengan un entendimiento compartido del problema.
• Derivar los requerimientos del sistema de software, necesarios para dar soporte a los objetivos de la organización.
• Entender como el sistema a ser desarrollado entra dentro de la organización.
Requerimientos
Esta disciplina tiene el propósito de:
• Establecer y mantener un acuerdo con los clientes y los otros interesados acerca de que debe hacer el sistema.
• Proveer a los desarrolladores del sistema de un mejor entendimiento de los requerimientos del sistema.
• Definir los límites (o delimitar) del sistema.
• Proveer un base para la planeación de los contenidos técnicos de las interacciones.
• Proveer una base para la estimación de costo y tiempo necesarios para desarrollar el sistema.
• Definir una interfaz de usuario para el sistema, enfocada en las necesidades y objetivos del usuario.
Análisis y Diseño
El propósito del Análisis y Diseño es:
• Transformar los requerimientos a diseños del sistema.
• Desarrollar una arquitectura robusta para el sistema.
• Adaptar el diseño para hacerlo corresponder con el ambiente de implementación y ajustarla para un desempeño esperado.
Implementación
El propósito de la implementación es:
• Definir la organización del código, en términos de la implementación de los subsistemas organizados en capas.
• Implementar el diseño de elementos en términos de los elementos (archivos fuente, binarios, ejecutables y otros)
• Probar los componentes desarrollados como unidades.
• Integrar los resultados individuales en un sistema ejecutable.
La disciplina de implementación limita su alcance a como las clases individuales serán probadas. Las pruebas del sistema son descritas en futuras disciplinas.
Pruebas
Actúa como un proveedor de servicios a las otras disciplinas en muchos aspectos. Se enfoca principalmente en la evaluación y aseguramiento de la calidad del producto, desarrollado a través de las siguientes prácticas:
• Encontrar fallas de calidad en el software y documentarlas.
• Recomendar sobre la calidad percibida en el software.
• Validar y probar las suposiciones hechas durante el diseño y la especificación de requerimientos de forma concreta.
• Validar que el software trabaja como fue diseñado.
• Validar que los requerimientos son implementados apropiadamente.
Transición
• Esta disciplina describe las actividades asociadas con el aseguramiento de la entrega y disponibilidad del producto de software hacia el usuario final.
• Existe un énfasis en probar el software en el sitio de desarrollo, realización de pruebas beta del sistema antes de su entrega final al cliente.
Administración y Configuración del Cambio
• Consiste en controlar los cambios y mantener la integridad de los productos que incluye el proyecto.
• Incluye:
– Identificar los elementos configurables.
– Restringir los cambios en los elementos configurables.
– Auditar los cambios hechos a estos elementos.
– Definir y mantener las configuraciones de estos elementos.
• Los métodos, procesos y herramientas usadas para proveer la administración y configuración del cambio pueden ser consideradas como el sistema de administración de la configuración.
Administración de Proyectos
El propósito de la Administración de Proyectos es:
• Proveer un marco de trabajo para administrar los proyectos intensivos de software.
• Proveer guías prácticas para la planeación, soporte, ejecución y monitoreo de proyectos.
• Proveer un marco de trabajo para la administración del riesgo.
Ambiente
• Se enfoca en las actividades necesarias para configurar el proceso al proyecto.
• Describe las actividades requeridas para desarrollar las líneas guías de apoyo al proyecto.
• El propósito de las actividades de ambiente es proveer a las organizaciones de desarrollo de software del ambiente necesario (herramientas y procesos) que den soporte al equipo de desarrollo.
