REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR

PARA LA EDUCACIÓN SUPERIOR
ALDEA UNIVERSITARIA “CIUDAD ANGOSTURA”
TRAYECTO III, PERIODO I
INGENIERA DE SISTEMAS E INFORMÁTICA
VII TRIMESTRE
CIUDAD BOLÍVAR – ESTADO BOLÍVAR

Facilitador: Participantes:
Ana, Carrasco
Ing. Eric Escobar Jessica, Medina
José, Meneses
Nadiuska, Villasana
Siudy, Infante
Ysmelia, Sánchez

CIUDAD BOLÍVAR, OCTUBRE DE 2010

_________________________________________________________________Proceso Unificado

Proceso Unificado
El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es
un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso,
centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido
y documentado del Proceso Unificado es el Proceso Unificado de Rational o
simplemente RUP.
El Proceso Unificado es un proceso de desarrollo de software: “conjunto de
actividades necesarias para transformar los requisitos del usuario en un sistema software”.

RUP es un marco genérico que puede especializarse para una variedad de tipos de
sistemas, diferentes áreas de aplicación, tipos de organizaciones, niveles de aptitud y
diferentes tamaños de proyectos.
El Proceso Unificado es un marco de trabajo extensible que puede ser adaptado a
organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado Rational,
también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir
si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del
RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo
concepto.
Características del proceso unificado
 Dirigido por Casos de Uso

 Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un

resultado de valor a un usuario. Los casos de uso modelan los requerimientos
funcionales del sistema.
 Todos los casos de uso juntos constituyen el modelo de casos de uso.
 Los casos de uso también guían el proceso de desarrollo (diseño, implementación, y
prueba). Basándose en los casos de uso los desarrolladores crean una serie de
modelos de diseño e implementación que llevan a cabo los casos de uso. De este
modo los casos de uso no solo inician el proceso de desarrollo sino que le
proporcionan un hilo conductor, avanza a través de una serie de flujos de trabajo
que parten de los casos de uso.

El Modelo de Caso de Usos representa los requisitos funcionales

La primera disciplina que se desarrolla dentro de cada iteración es la de

requerimientos (posiblemente luego de realizar un modelado del dominio o del negocio). El
objetivo de esta fase es determinar los requerimientos del sistema. Los requerimientos
funcionales son plasmados a través de casos de uso en un Modelo de Casos de Uso. El
modelo de casos de uso ayuda al cliente, a los usuarios, y a los desarrolladores a llegar a un
_________________________________________________________________Proceso Unificado

acuerdo sobre cómo utilizar el sistema. Cada tipo de usuario del sistema se representa
mediante un actor que define un rol de utilización del sistema.
Los actores modelan el entorno del sistema, y los casos de uso especifican el sistema.
Un diagrama de casos de uso describe parte del modelo de casos de uso y muestra un
conjunto de casos de uso y actores asociados.

Ej.: Modelo de Casos de Uso para el sistema Cajero Automático

Sacar dinero

Cliente de banco Transferencias entre cuentas

Ingresar dinero

Para cada caso de uso debe especificarse sus caminos o secuencias de acciones posibles.

Ej.: Secuencia de acciones para un camino del caso de uso Sacar Dinero (simplificada)
- El cliente del banco se identifica.
- El cliente elige de que cuenta sacar dinero y especifica cantidad.
- El sistema deduce la cantidad de la cuenta y entrega el dinero.

 Centrado en la Arquitectura

La arquitectura de un sistema software se describe mediante diferentes vistas del

sistema en construcción. El concepto de arquitectura software incluye los aspectos estáticos
y dinámicos más significativos del sistema.
La arquitectura es una vista del diseño completo con las características más importantes
resaltadas, dejando los detalles de lado.

Los casos de uso y la arquitectura están profundamente relacionados. Los casos de

uso deben encajar en la arquitectura, y a su vez la arquitectura debe permitir el desarrollo
de todos los casos de uso requeridos, actualmente y a futuro.
El arquitecto desarrolla la forma o arquitectura a partir de la comprensión de un conjunto
reducido de casos de uso fundamentales o críticos (usualmente no más del
10 % del total).
_________________________________________________________________Proceso Unificado

Importancia y necesidad de una arquitectura

Se necesita una arquitectura para:

- Comprender el sistema
- Organizar el desarrollo
- Fomentar la reutilización
- Hacer evolucionar el sistema

Desarrollo de la arquitectura

La arquitectura se desarrolla mediante iteraciones, principalmente en la etapa de

elaboración. El resultado de la fase de elaboración es la línea base de la arquitectura un
esqueleto del sistema con pocos músculos de software.
Los casos de uso que son relevantes para la arquitectura son resumidamente aquellos que
mitigan los mayores riesgos del proyecto, aquellos que son más importantes para el usuario,
y aquellos que nos ayudan a cubrir todas las funcionalidades significativas.

Descripción de la arquitectura

La línea base de la arquitectura, es la versión interna del sistema al final de la fase

de elaboración. El conjunto de modelos que describen esta línea base se denomina
descripción de la arquitectura.
El papel de la descripción de la arquitectura es guiar al equipo de desarrollo a través del
ciclo de vida del sistema. La descripción de la arquitectura puede adoptar diferentes formas.
Puede ser un extracto de los modelos que son parte de la línea base de la arquitectura, o
puede ser una reescritura de los extractos de forma que sea más fácil leerlos.

La vista de la arquitectura del modelo de casos de uso

Presenta los actores y casos de uso más importantes.

Ej. Vista de la arquitectura del modelo de casos de uso del sistema cajero automático.
En el ejemplo del CA el caso de uso más importante es Sacar Dinero. Sin él, no tendría
sentido el CA.
Para definir la arquitectura por tanto, el arquitecto sugiere que el caso de uso Sacar
Dinero se implemente en su totalidad durante la fase de elaboración.
_________________________________________________________________Proceso Unificado

Iterativo e Incremental

Es práctico dividir el esfuerzo de desarrollo de un proyecto de software en partes

más pequeñas o mini proyectos. Cada mini proyecto es una iteración que resulta en un
incremento.
Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos a
crecimientos en el producto. Las iteraciones deben estar controladas. Esto significa que
deben seleccionarse y ejecutarse de una forma planificada. Los desarrolladores basan la
selección de lo que implementarán en cada iteración en dos cosas: el conjunto de casos de
uso que amplían la funcionalidad, y en los riesgos más importantes que deben mitigarse.
En cada iteración los desarrolladores identifican y especifican los casos de uso
relevantes, crean un diseño utilizando la arquitectura seleccionada como guía, para
implementar dichos casos de uso. Si la iteración cumple sus objetivos, se continúa con la
próxima. Si no deben revisarse las decisiones previas y probar un nuevo enfoque.
El incremental es un modelo de tipo evolutivo que está basado en varios ciclos
Cascada realimentados aplicados repetidamente, con una filosofía iterativa. En la figura s,
se muestra un refino del diagrama previo, bajo un esquema temporal, para obtener
finalmente el esquema del Modelo de ciclo de vida Iterativo Incremental, con sus
actividades genéricas asociadas. Aquí se observa claramente cada ciclo cascada que es
aplicado para la obtención de un incremento; estos últimos se van integrando para obtener
el producto final completo. Cada incremento es un ciclo Cascada Realimentado, aunque,
por simplicidad, en la figura s se muestra como secuencial puro.

Fig. s - Modelo iterativo incremental para el ciclo de vida del software

_________________________________________________________________Proceso Unificado

Se observa que existen actividades de desarrollo (para cada incremento) que son
realizadas en paralelo o concurrentemente, así por ejemplo, en la figura, mientras se realiza
el diseño detalle del primer incremento ya se está realizando en análisis del segundo. La
figura s, es sólo esquemática, un incremento no necesariamente se iniciará durante la fase
de diseño del anterior, puede ser posterior (incluso antes), en cualquier tiempo de la etapa
previa. Cada incremento concluye con la actividad de “Operación y Mantenimiento”
(indicada "Operación" en la figura), que es donde se produce la entrega del producto parcial
al cliente. El momento de inicio de cada incremento es dependiente de varios factores: tipo
de sistema; independencia o dependencia entre incrementos (dos de ellos totalmente
independientes pueden ser fácilmente iniciados al mismo tiempo si se dispone de personal
suficiente); capacidad y cantidad de profesionales involucrados en el desarrollo; etc.

Bajo este modelo se entrega software “por partes funcionales más pequeñas”, pero
reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel
que ya fue entregado.
Como se muestra en la figura s, se aplican secuencias Cascada en forma escalonada,
mientras progresa el tiempo calendario. Cada secuencia lineal o Cascada produce un
incremento y a menudo el primer incremento es un sistema básico, con muchas funciones
suplementarias (conocidas o no) sin entregar.
El cliente utiliza inicialmente ese sistema básico intertanto, el resultado de su uso y
evaluación puede aportar al plan para el desarrollo del/los siguientes incrementos (o
versiones). Además también aportan a ese plan otros factores, como lo es la priorización
(mayor o menor urgencia en la necesidad de cada incremento) y la dependencia entre
incrementos (o independencia).
Luego de cada integración se entrega un producto con mayor funcionalidad que el
previo. El proceso se repite hasta alcanzar el software final completo.
Siendo iterativo, con el modelo incremental se entrega un producto parcial pero
completamente operacional en cada incremento, y no una parte que sea usada para reajustar
los requerimientos (como si ocurre en el modelo de construcción de prototipos, MCP).
El enfoque incremental resulta muy útil con baja dotación de personal para el
desarrollo; también si no hay disponible fecha límite del proyecto por lo que se entregan
versiones incompletas pero que proporcionan al usuario funcionalidad básica (y cada vez
mayor). También es un modelo útil a los fines de evaluación.

Nota: Puede ser considerado y útil, en cualquier momento o incremento incorporar

temporalmente el paradigma MCP como complemento, teniendo así una mixtura de
modelos que mejoran el esquema y desarrollo general.
_________________________________________________________________Proceso Unificado

Por qué un desarrollo iterativo e incremental.

 Para tomar las riendas de los riesgos críticos y significativos desde el principio.
 Para poner en marcha una arquitectura que guíe el desarrollo del software.
 Para proporcionar un marco de trabajo que gestione de mejor forma los inevitables
cambios en los requisitos y en otros aspectos.
 Para construir el sistema a lo largo del tiempo en lugar de hacerlo de una sola vez
cerca del final, cuando el cambiar algo se ha vuelto costoso.
 Para proporcionar un proceso de desarrollo a través del cual el personal puede
trabajar de manera más eficaz.

El Ciclo de Vida del Proceso Unificado

El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la
vida de un sistema. Al final de cada uno de ellos se obtiene una versión final del producto,
que no sólo satisface ciertos casos de uso, sino que está lista para ser entregada y puesta en
producción. En caso de que fuese necesario publicar otra versión, deberían repetirse los
mismos pasos a lo largo de otro ciclo.
Cada ciclo constas de cuatro fases, cada fase se subdivide en iteraciones y en cada
iteración se desarrolla en secuencia un conjunto de disciplinas o flujos de trabajos.

Disciplinas o flujo de trabajos

Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo)
vinculadas a un área específica dentro de un proyecto total.
_________________________________________________________________Proceso Unificado

Flujo de trabajo

 Modelado de negocio: El objetivo es establecer un canal de comunicación entre los

ingenieros del negocio y los ingenieros del software.

 Requisitos: El objetivo es describir que es lo que tiene que hacer el sistema y poner
a los desarrolladores y al cliente de acuerdo en esta descripción.

 Análisis y diseño: Describe como el software será realizado en la fase de

implementación. Se plasma en un modelo de diseño que consiste en una serie de
clases agrupadas en paquetes y subsistemas con interfaces bien definidos.

 Implementación: Se implementan las clases y objetos en términos de componentes.

 Prueba: Se comprueba que el funcionamiento es correcto analizado en diversos

aspectos: los objetos como unidades, la integración entre objetos.

 Despliegue: Se crea la versión externa del producto, se empaqueta, se distribuye y

se instala en el lugar de trabajo. También seda asistencia y ayuda a los usuarios.

Flujo de trabajo de soporte

 Gestión de configuraciones y cambios: Gestiona aspectos como los sistemas de

control de versiones. Controla las peticiones de cambios clasificándolas según su
estado (nueva, registrada, aprobada, asignada, completa.)

 Gestión del proyecto: Encargada de definir los planes del proyecto global, los
planes de fases y los planes de iteración.

 Entorno: Se centra en las actividades necesarias para configurar el proceso de un

proyecto.
_________________________________________________________________Proceso Unificado

Fases del ciclo de vida

Fase de Inicio
Durante la fase de inicio se desarrolla una descripción del producto final, y se presenta
el análisis del negocio. Esta fase responde las siguientes preguntas:

 Cuáles son las principales funciones del sistema para los usuarios más importantes.
 Cómo podría ser la mejor arquitectura del sistema.
 Cuál es el plan del proyecto y cuanto costará desarrollar el producto.

El objetivo de esta fase es ayudar al equipo de proyecto a decidir cuáles son los verdaderos
objetivos del proyecto.

Fase de Elaboración
Durante la fase de elaboración se especifican en detalle la mayoría de los casos de
uso del producto y se diseña la arquitectura.

Las iteraciones en la fase de elaboración:

 Establecen una firme comprensión del problema a solucionar.

 Establece la fundación arquitectural para el software.
 Establece un plan detallado para las siguientes iteraciones.
 Elimina los mayores riesgos.
_________________________________________________________________Proceso Unificado

Fase de Construcción
Durante la fase de construcción se crea el producto. La línea base de la arquitectura
crece hasta convertirse en el sistema completo. Al final de esta fase, el producto contiene
todos los casos de uso implementados, sin embargo puede que no esté libre de defectos.

Los artefactos producidos durante esta fase son:

 El sistema software
 Los casos de prueba
 Los manuales de usuario

Fase de Transición
La fase de transición cubre el período durante el cual el producto se convierte en la
versión beta. Las iteraciones en esta fase continúan agregando características al software.
Sin embargo las características se agregan a un sistema que el usuario se encuentra
utilizando activamente. Los artefactos construidos en esta fase son los mismos que en la
fase de construcción. El equipo se encuentra ocupado fundamentalmente en corregir y
extender la funcionalidad del sistema desarrollado en la fase anterior.