El documento describe el Proceso Unificado de Desarrollo (UP), un marco de trabajo genérico para el desarrollo de software que utiliza modelos UML. El UP es un proceso iterativo e incremental dirigido por casos de uso y centrado en la arquitectura. Se compone de fases como requisitos, análisis, diseño, implementación y pruebas, las cuales se dividen en iteraciones que producen incrementos en el producto de software. El UP reduce el riesgo al permitir la pérdida solo de lo realizado en una iteración.

1. PROCESO UNIFICADO DE
DESARROLLO
(UP del Ingles Unified Process)
YESID LINARES PALOMINO
LUIS CARLOS OVALLE DIAZ
LUZ MARILIN DIAZ PEREZ
ANDREA GARCIA GARCIA

2. Es más que un simple proceso, es un
marco de trabajo genérico que puede
especializarse para una variedad de
sistemas de software.
El proceso unificado utiliza el lenguaje
de modelado para preparar todos los
esquemas de un sistema de software.
UML es una parte esencial de este
proceso.
EL PROCESO UNIFICADO DE DESARROLLO SOFTWARE O
SIMPLEMENTE PROCESO UNIFICADO

3. Es un marco de desarrollo de
software que se caracteriza por estar
dirigido por casos de uso, centrado en la
arquitectura, por ser iterativo e
incremental y está enfocado en los
riesgos.
El refinamiento más conocido y
documentado del Proceso Unificado es
el Proceso Unificado de Rational o
simplemente RUP
EL PROCESO UNIFICADO DE DESARROLLO SOFTWARE O
SIMPLEMENTE PROCESO UNIFICADO

4. •Un ciclo de vida se repite
lo largo del tiempo.
•Tras cada ciclo de vida -->
versión nueva del producto.
•Un ciclo de vida se divide
en fases.
•Cada fase se divide en
iteraciones.
•En cada iteración se
realizan flujos de trabajo.
CICLO DE VIDA DEL PROCESO UNIFICADO

5. FASES DENTRO DEL CICLO DE VIDA DEL PROCESO
UNIFICADO

6. ITERACIONES DE CADA FASE DEL CV
- Cada fase se divide en
iteraciones.
Cada iteración:
- miniproyecto (en cascada)
que ejecuta flujos de trabajo.
-produce un incremento en
producto.
Se reduce el riesgo:
-se puede perder sólo lo
realizado en esa iteración.

7. FLUJOS DE TRABAJO EN CADA ITERACION
Captura de requisitos:
-identificar requisitos del sistema
-construir un modelo del mismo
--modelo de casos de uso
--modelo del dominio (0 negocio)
Análisis:
- especificar requisitos
- construir modelo del análisis
Diseño:
-encontrar la forma del sistema (solución)
-construir modelo del diseño
Implementación:
-codificar el diseño (solución)
-construir modelo de implementación
Pruebas:
-verificar la implementación
-construir modelo de pruebas

8. ROLES
• Las personas llegan a ocupar muchos puestos diferentes en
una organización de desarrollo de software.
• Se conoce como roles a los puestos a los cuales se pueden
asignar personas y los cuales esas personas aceptan.
• Un rol puede representar a un conjunto de personas que
trabajan juntas. Ej: Grupo de arquitectura - arquitecto.
Como podremos ver a continuación encontraremos los diferentes
roles en cada una de las fases.

9. Requisitos
– Analista de sistemas: Responsable del conjunto de
requisitos modelados en los casos de uso y de delimitar
el sistema.
– Especificador de casos de uso: Ayudan a los analistas de
sistemas en el trabajo de capturar los requisitos. Deben
trabajar estrechamente con los usuarios de los casos de
uso.
– Diseñador de Interfaz de Usuario: Dan forma visual a las
interfaces de usuario.
– Arquitecto: Describe la vista de la arquitectura del
modelo de casos de uso. Esta vista es una entrada
importante para planificar las iteraciones.

10. Análisis
– Arquitecto: Responsable de la integridad del modelo de análisis,
garantizando que éste sea correcto, consistente y legible como un
todo. También es responsable de la arquitectura del modelo de
análisis.
– Ingeniero de casos de uso: Responsable de la integridad de una o
más realizaciones de casos de uso.
– Ingeniero de componentes: Define y mantiene las relaciones,
atributos, relaciones y requisitos especiales de una o varias clases
del análisis.

11. Diseño
– Arquitecto: Responsable de la integridad de los modelos de diseño y
de despliegue, garantizando que son correctos, consistentes y legibles
en su totalidad.
– Ingeniero de casos de uso: Responsable de la integridad de una o más
realizaciones de casos de uso-diseño.
– Ingeniero de componentes: Define y mantiene las operaciones,
métodos, atributos, relaciones y requisitos de implementación de una o
más clases del diseño.

12. Implementación
– Arquitecto: Responsable de la integridad del modelo de implementación y
asegura que el modelo como un todo es correcto, completo y legible.
– Ingeniero de componentes: define y mantiene el código fuente de uno o varios
componentes, garantizando que cada componente implementa la funcionalidad
correcta.
– Integrador de sistemas: Entre sus responsabilidades se incluye el planificar la
secuencia de construcciones necesarias en cada iteración y la integración de
cada construcción cuando sus partes han sido implementadas. La planificación da
lugar a un plan de integración de construcciones.

13. Prueba
– Ingeniero de componentes: son responsables de los componentes de prueba
que automatizan algunos de los procedimientos de prueba.
– Ingeniero de pruebas de integración: son los responsables de realizar las
pruebas de integración que se necesitan para cada construcción producida en
el flujo de trabajo de la implementación. Las pruebas de integración se
realizan para verificar que los componentes integrados en una construcción
funcionan correctamente juntos.
– Ingeniero de pruebas de sistema: Es responsable de realizar las pruebas de
sistema necesarias sobre una construcción que muestra el resultado de una
iteración completa. Las pruebas de sistema se llevan a cabo principalmente
para verificar las interacciones entre los actores y el sistema.

14.  Coste del Riesgo a un solo
incremento.
 Reduce el riesgo de no sacar el
producto en el calendario previsto.
 Acelera el ritmo de desarrollo.
 Se adapta mejor a las necesidades
del cliente.
VENTAJAS DE UP DESVENTAJAS DE UP
 Requiere costos de dedicación altos
por lo que no es conveniente usarlo
en procesos pequeños.
 Si el proceso no se inicia bien desde
el principio, se puede volver muy
grande y difícil.
 Se basa mucho en la documentación.
 Proceso pesado