Вы находитесь на странице: 1из 14

Mxico, D. F.

Daniel Lujan Espino

Contenido
y Historia y Caracteristicas Principales
y Proceso dirigido por Casos de Uso y Proceso centrado en la arquitectura y Proceso iterativo e incremental

y Estructura del proceso


y Estructura Dinmica del proceso. Fases e iteraciones
y y y y

Incepcin Elaboracin Construccin Transicin

y Estructura Esttica del proceso. Roles, actividades, artefactos

y flujos de trabajo
y y y y

Roles Actividades Artefactos Workflows

Historia

El antecedente ms importante se ubica en 1967 con la Metodologa Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, una aproximacin de desarrollo basada en componentes, que introdujo el concepto de Caso de Uso. Entre los aos de 1987 a 1995 Jacobson fund la compaa Objectory AB y lanza el proceso de desarrollo Objectory (abreviacin 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, destacndose especialmente el flujo de trabajo conocido como modelado del negocio. En junio del 1998 se lanza Rational Unified Process

Caractersticas Principales

Proceso dirigido por Casos de Uso

Proceso iterativo e incremental

Proceso centrado en la arquitectura

Proceso dirigido por Casos de Uso

Proceso centrado en la arquitectura


La arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes, lo que permite tener una visin comn entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo. La arquitectura involucra los aspectos estticos y dinmicos ms significativos del sistema, est relacionada con la toma de decisiones que indican cmo 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 ms pequeas 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 iteracin (un recorrido ms 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 iteracin puede realizarse por medio de una cascada como se muestra en la Figura. Se pasa por los flujos fundamentales (Requisitos, Anlisis, Diseo, Implementacin y Pruebas), tambin existe una planificacin de la iteracin, un anlisis de la iteracin y algunas actividades especficas de la iteracin. Al finalizar se realiza una integracin de los resultados con lo obtenido de las iteraciones anteriores.

Estructura del proceso (1)


Estructura Dinmica del proceso. Fases e iteraciones Incepcin Elaboracin Construccin Transicin Estructura Esttica del proceso. Roles, actividades, artefactos y flujos de trabajo Roles Actividades Artefactos 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 dinmicos del proceso. Indica las caractersticas del ciclo de vida del proceso expresado en trminos de fases, iteraciones e hitos. Se puede observar en la Figura que RUP consta de cuatro fases: Inicio, Elaboracin, Construccin y Transicin. Como se mencion anteriormente cada fase se subdivide a la vez en iteraciones. Eje vertical: Representa los aspectos estticos del proceso. Describe el proceso en trminos de componentes de proceso, disciplinas, flujos de trabajo, actividades, artefactos y roles.

Estructura dinmica del proceso


FASES Incepcin 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 disean los Casos de Uso ms esenciales (aproximadamente el 20% del modelo completo). Se desarrolla, un plan de negocio para determinar que recursos deben ser asignados al proyecto. Elaboracin El propsito 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 crticos identificados en la fase de inicio. Tambin debe demostrarse que se han evitado los riesgos ms graves. Construccin La finalidad principal de esta fase es alcanzar la capacidad operacional del producto de forma incremental a travs de las sucesivas iteraciones. Durante esta fase todos los componentes, caractersticas y requisitos deben ser implementados, integrados y probados en su totalidad, obteniendo una versin aceptable del producto. Transicin 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 documentacin, entrenar al usuario en el manejo del producto, y en general tareas relacionadas con el ajuste, configuracin, instalacin y facilidad de uso del producto.

Estructura dinmica 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 generacin del producto para los clientes. Cada ciclo consta de cuatro fases: Inicio, Elaboracin, Construccin y Transicin. Cada fase se subdivide a la vez en iteraciones, el nmero 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 crticas y alcanzar las metas clave antes de pasar a la siguiente fase
Inception Elaboration Construction Transition

Ob etivos Vision

tiempo

La duracin y esfuerzo dedicado en cada fase es variable dependiendo de las caractersticas del proyecto. Sin embargo, en la Figura se ilustran los porcenta es ms frecuentes

Inicio Esfuerzo Tiempo Dedicado 5% 10 %

Distribucin tpica de recursos humanos

Las fases y sus respectivos hitos

rquitectura

Capacidad Operacional Inicial

Release del Producto

Elaboracin Construccin Transicin 20 % 30 % 65 % 50 % 10% 10%

Estr

t r Est ti

l r

Un proceso de desarrollo de software define quin hace qu, cmo y cundo. RUP define cuatro elementos los roles, que responden a la pregunta roles Quin?, Quin? las actividades que responden a la pregunta Cmo?, los Cmo? productos, productos que responden a la pregunta Qu? y los flujos de trabajo de las disciplinas que responde a la pregunta Cundo?

Roles Actividades

Artefactos

Rol s
Analistas: Analista de procesos de negocio. Diseador del negocio. Analista de sistema. Especificador de requisitos. Gestores: Jefe de proyecto Jefe de control de cambios. Jefe de configuracin. Jefe de pruebas Jefe de despliegue Ingeniero de procesos Revisor de gestin del proyecto Gestor de pruebas. Especialista en pruebas: Especialista en Pruebas (tester) Analista de pruebas Diseador de pruebas Desarrolladores: Arquitecto de software. Diseador Diseador de interfaz de usuario Diseador de cpsulas. Diseador de base de datos. Implementador. Integrador. Apoyo: Documentador tcnico Administrador de sistema Especialista en herramientas Desarrollador de cursos Artista grfico Otros roles: Stakeholders. Revisor Coordinacin de revisiones Revisor tcnico

Actividades, Artefactos
Actividades
Una actividad en concreto es una unidad de trabajo que una persona que desempee un rol puede ser solicitado a que realice. Las actividades tienen un objetivo concreto, normalmente expresado en trminos de crear o actualizar algn producto.

Artefactos
Un producto o artefacto es un trozo de informacin 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 diseo. Un elemento del modelo, un elemento que pertenece a un modelo como una clase, un Caso de Uso o un subsistema.

Вам также может понравиться