Date post: | 10-Mar-2016 |
Category: |
Documents |
Upload: | karen-manzanarez |
View: | 238 times |
Download: | 2 times |
Rational Unified Process (RUP)
¿Qué es RUP?• Es un proceso de ingeniería de
software, que hace una propuesta orientada por disciplinas para lograr las tareas y responsabilidades de una organización que desarrolla software.
• Su meta principal es asegurar la asegurar la producción de software de alta producción de software de alta calidadcalidad que cumpla con las necesidades de los usuarios, con una planeación y presupuesto predecible.
¿Para quién es RUP?• Diseñado para
– Profesionales en el desarrollo de software
– Interesados en productos de software– Profesionales en la ingeniería y
administración de procesos de software
• Estos participantes se involucran con RUP cumpliendo roles
¿Por qué usar RUP?• Porque:
– Provee un entorno de proceso de desarrollo configurable, basado en estándares
– Permite tener claro y accesible el proceso de desarrollo que se sigue
– Permite ser configurado a las necesidades de la organización y del proyecto
– Provee a cada participante con la parte del proceso que le compete directamente, filtrando el resto
Características• Dirigido por Casos de Uso
– Los casos de uso son los artefactos primarios para establecer el comportamiento deseado del sistema
• Centrado en la Arquitectura– La arquitectura es utilizada para
conceptualizar, construir, administrar y evolucionar el sistema en desarrollo
• Iterativo e Incremental– Maneja una serie de entregas ejecutables– Integra continuamente la arquitectura para
producir nuevas versiones mejoradas
Características (2)• Conceptualmente amplio y diverso• Enfoque orientado a objetos• En evolución continua• Adaptable• Repetible• Permite mediciones
– Estimación de costos y tiempo, nivel de avance, etc.
Conc
epto
s
Ciclo de vida
Diagrama General de RUPDiagrama 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ámicoaspecto 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áticoAspecto estático del proceso a través de componentes, disciplinas, actividades, flujos de trabajo, artefactos y roles.
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.
Fases de Ciclo de VidaFases de Ciclo de Vida
Inicio Elaboración Construcción Transición
Esfuerzo 5% 20% 65% 10%
Tiempo 10% 30% 50% 10%
Inicio (Inception)Inicio (Inception)• El objetivo general de esta fase es
establecer un acuerdo entre todos los establecer un acuerdo entre todos los interesados acerca de los objetivos del interesados acerca de los objetivos del proyectoproyecto.
• Es significativamente importante para el desarrollo de nuevo software, ya que se se asegura de identificar los riesgos asegura de identificar los riesgos relacionados con el negocio y relacionados con el negocio y requerimientosrequerimientos.
• 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ónElaboración• El objetivo en esta fase es
establecer la arquitectura base establecer la arquitectura base del sistemadel 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ónConstrucción• El objetivo de la fase de construcción es
clarificar los requerimientos faltantes y clarificar los requerimientos faltantes y completar el desarrollo del sistemacompletar 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ónTransición• Esta fase se enfoca en asegurar que el asegurar que el
software esté disponible para sus software esté disponible para sus usuariosusuarios.
• Se puede subdividir en varias iteraciones, 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.
DisciplinasDisciplinas• Una disciplina es una colección de es una colección de
actividades relacionadas con un actividades relacionadas con un área de atención dentro de todo área de atención dentro de todo el proyecto.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 NegociosModelado 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.
RequerimientosRequerimientos
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 iteraciones.• 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ñoAná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ónImplementació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.
PruebasPruebas
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ónTransició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 Administración y Configuración del CambioCambio• 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 ProyectosAdministració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.
AmbienteAmbiente
• 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.
Disciplinas• Workflow
– Detalles del workflow
• Actividades• Artefactos• Guías de
aplicación
Roles• Definen el comportamiento y
responsabilidades de individuos o grupos de individuos– Un individuo puede jugar más de un rol
• Son descripciones abstractas de– Conjuntos de actividades realizadas– Responsabilidad sobre artefactos
• Ejemplos de roles– Software Architect– Architecture Reviewer
Actividades• Una actividad es algo que un rol hace
y que provee un resultado de interés en el contexto del proyecto.
• Es una unidad de trabajo que individuos jugando cierto rol pueden ser llamados a realizar.
• Son utilizadas para detallar los workflows.
• Toman artefactos como entrada y producen artefactos (o nuevas versiones) como salida.
ArtefactosUnidades de información creadas, producidas, cambiadas o utilizadas en el proceso de desarrollo.
¿Cuándo usar RUP?Alta complejidad técnica - embebidos, tiempo real, distribuidos, tolerancia a fallas - alta performance - personalizado, sin precedentes, re-ingeniería arquitectónica
Baja complejidad técnica - 4GL, basado en componentes - re-ingeniería de aplicaciones
Alta complejidad gerencial - gran escala - contractual - muchos stakeholders
Baja complejidad gerencial - pequeña escala - informal - pocos stakeholders
Mayor necesidad de seguir un proceso definido
¿Cuándo usar RUP? (2)• RUP puede utilizarse
– En proyectos de nuevos productos de software
– En ciclos de desarrollo subsecuentes• Consideraciones que alteran cuándo
y cómo usar partes de RUP– El ciclo de vida del proyecto– Los objetivos del negocio, la visión, el
alcance y los riesgos– El tamaño del esfuerzo de desarrollo
Conclusiones• Es un modelo de proceso de
desarrollo de software– Es una base para procesos particulares
• El objetivo es asegurar el desarrollo– De productos de software de alta
calidad– Que satisfagan los requerimientos– En tiempo y presupuesto predecible
• Permite un vocabulario común entre equipos de desarrollo