Contenido
Historia
Caracteristicas Principales
Proceso dirigido por Casos de Uso
Proceso centrado en la arquitectura
Proceso iterativo e incremental
Estructura del proceso
Estructura Dinámica del proceso. Fases e iteraciones
Incepción
Elaboración
Construcción
Transición
Estructura Estática del proceso. Roles, actividades, artefactos
y flujos de trabajo
Roles
Actividades
Artefactos
Workflows
Historia
El antecedente más importante se ubica en 1967 con la Metodología Ericsson (Ericsson
Approach) elaborada por Ivar Jacobson, una aproximación de desarrollo basada en
componentes, que introdujo el concepto de Caso de Uso. Entre los años de 1987 a 1995
Jacobson fundó la compañía Objectory AB y lanza el proceso de desarrollo Objectory
(abreviación de Object Factory). Posteriormente en 1995 Rational Software Corporation
adquiere Objectory AB y entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP)
a partir de Objectory 3.8 y del Enfoque Rational (Rational Approach) adoptando UML como
lenguaje de modelado.
Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh,
Rational Software desarrolló e incorporó diversos elementos para expandir ROP,
destacándose especialmente el flujo de trabajo conocido como modelado del negocio. En
junio del 1998 se lanza Rational Unified Process
Características Principales
Proceso
dirigido por
Casos de Uso
Proceso
Proceso
centrado en
iterativo e
la
incremental
arquitectura
Proceso dirigido por Casos de Uso
Proceso centrado en la arquitectura
La arquitectura de un sistema es la organización o estructura de sus
partes más relevantes, lo que permite tener una visión común entre
todos los involucrados (desarrolladores y usuarios) y una
perspectiva clara del sistema completo.
La arquitectura involucra los aspectos estáticos y dinámicos más
significativos del sistema, está relacionada con la toma de
decisiones que indican cómo tiene que ser construido el sistema y
ayuda a determinar en qué orden.
La arquitectura se ve influenciada por la plataforma, software,
sistema operativo, gestor de bases de datos, protocolos,
consideraciones de desarrollo como sistemas heredados.
Muchas de estas restricciones constituyen requisitos no funcionales
del sistema.
Proceso iterativo e incremental
La estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el
trabajo se divide en partes más pequeñas o mini proyectos. Permitiendo que el equilibrio entre
Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, así durante todo el
proceso de desarrollo. Cada mini proyecto se puede ver como una iteración (un recorrido más o
menos completo a lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene un
incremento que produce un crecimiento en el producto. Una iteración puede realizarse por medio
de una cascada como se muestra en la Figura. Se pasa por los flujos fundamentales (Requisitos,
Análisis, Diseño, Implementación y Pruebas), también existe una planificación de la iteración, un
análisis de la iteración y algunas actividades específicas de la iteración. Al finalizar se realiza una
integración de los resultados con lo obtenido de las iteraciones anteriores.
Estructura del proceso (1)
Estructura Dinámica del proceso. Fases e iteraciones
RUP Modelo Tradicional
•Incepción (Análisis de Requerimientos)
•Elaboración (Análisis y Diseño del Sistema))
•Construcción (Construcción y Pruebas)
•Transición (Implementación y Liberación)
Estructura Estática del proceso. Roles, actividades,
artefactos y flujos de trabajo
•Roles
•Actividades
•Artefactos
•Flujos de trabajo
Estructura del proceso (2)
El proceso puede ser descrito en dos dimensiones o ejes:
Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos dinámicos del proceso. Indica las
características del ciclo de vida del proceso expresado en términos de fases, iteraciones e hitos. Se puede
observar en la Figura que RUP consta de cuatro fases: Inicio, Elaboración, Construcción y Transición. Como se
mencionó anteriormente cada fase se subdivide a la vez en iteraciones.
Eje vertical: Representa los aspectos estáticos del proceso. Describe el proceso en términos de componentes
de proceso, disciplinas, flujos de trabajo, actividades, artefactos y roles.
Estructura dinámica del proceso
FASES
•Incepción
Durante esta fase se define el modelo del negocio y el alcance del proyecto. Se identifican
todos los actores y Casos de Uso, y se diseñan los Casos de Uso más esenciales
(aproximadamente el 20% del modelo completo). Se desarrolla, un plan de negocio para
determinar que recursos deben ser asignados al proyecto.
•Elaboración
El propósito de esta fase es analizar el dominio del problema, establecer los
cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los mayores
riesgos. En esta fase se construye un prototipo de la arquitectura, que debe evolucionar
en iteraciones sucesivas hasta convertirse en el sistema final. Este prototipo debe
contener los Casos de Uso críticos identificados en la fase de inicio. También debe
demostrarse que se han evitado los riesgos más graves.
•Construcción
La finalidad principal de esta fase es alcanzar la capacidad operacional del producto de
forma incremental a través de las sucesivas iteraciones. Durante esta fase todos los
componentes, características y requisitos deben ser implementados, integrados y
probados en su totalidad, obteniendo una versión aceptable del producto.
•Transición
La finalidad de esta fase es poner el producto en manos de los usuarios finales, para lo
que se requiere desarrollar nuevas versiones actualizadas del producto, completar la
documentación, entrenar al usuario en el manejo del producto, y en general tareas
relacionadas con el ajuste, configuración, instalación y facilidad de uso del producto.
Estructura dinámica del proceso
Fases e iteraciones
RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un producto. Cada ciclo concluye
con una generación del producto para los clientes. Cada ciclo consta de cuatro fases: Inicio, Elaboración,
Construcción y Transición. Cada fase se subdivide a la vez en iteraciones, el número de iteraciones en cada
fase es variable. Cada fase se concluye con un hito bien definido, un punto en el tiempo en el cual se
deben tomar ciertas decisiones críticas y alcanzar las metas clave antes de pasar a la siguiente fase
Inception Elaboration Construction Transition
Las fases y sus respectivos hitos Capacidad
Objetivos Arquitectura Release
(Vision) Operacional del Producto
Inicial
tiempo
La duración y esfuerzo dedicado en cada Inicio Elaboración Construcción Transición
fase es variable dependiendo de las
Esfuerzo 5% 20 % 65 % 10%
características del proyecto. Sin embargo,
en la Figura se ilustran los porcentajes Tiempo
10 % 30 % 50 % 10%
más frecuentes Dedicado
Distribución típica de recursos humanos
Estructura Estática del proceso
Un proceso de desarrollo de software define quién hace qué, cómo y
cuándo.
RUP define cuatro elementos los roles, que responden a la pregunta
¿Quién?, las actividades que responden a la pregunta ¿Cómo?, los
productos, que responden a la pregunta ¿Qué? y los flujos de trabajo de las
disciplinas que responde a la pregunta ¿Cuándo?
Roles
Analistas: Desarrolladores:
·Analista de procesos de ·Arquitecto de software.
negocio. ·Diseñador
·Diseñador del negocio. ·Diseñador de interfaz de
·Analista de sistema. usuario
·Especificador de requisitos. ·Diseñador de cápsulas.
·Diseñador de base de datos.
Gestores: ·Implementador.
·Jefe de proyecto ·Integrador.
·Jefe de control de cambios.
·Jefe de configuración. Apoyo:
·Jefe de pruebas ·Documentador técnico
·Jefe de despliegue ·Administrador de sistema
·Ingeniero de procesos ·Especialista en herramientas
·Revisor de gestión del ·Desarrollador de cursos
proyecto ·Artista gráfico
·Gestor de pruebas.
Otros roles:
Especialista en pruebas: ·Stakeholders.
·Especialista en Pruebas ·Revisor
(tester) ·Coordinación de revisiones
·Analista de pruebas ·Revisor técnico
·Diseñador de pruebas
Actividades, Artefactos
Actividades
Una actividad en concreto es una unidad de trabajo que una persona que
desempeñe un rol puede ser solicitado a que realice. Las actividades tienen un
objetivo concreto, normalmente expresado en términos de crear o actualizar algún
producto.
Artefactos
Un producto o artefacto es un trozo de información que es producido, modificado
o usado durante el proceso de desarrollo de software. Los productos son los
resultados tangibles del proyecto, las cosas que va creando y usando hasta
obtener el producto final.
Un artefacto puede ser cualquiera de los siguientes:
·Un documento, como el documento de la arquitectura del software.
·Un modelo, como el modelo de Casos de Uso o el modelo de diseño.
·Un elemento del modelo, un elemento que pertenece a un modelo como una
clase, un Caso de Uso o un subsistema.
