Anda di halaman 1dari 74

Proceso Unificado de

Desarrollo de
Software

13 de sep de 2006
Referencias básicas
“El Proceso unificado de desarrollo de Software”
I. Jacobson, G. Booch y J.Rumbaugh
Addison Wesley - Pearson Education 1999

“Applying UML and Patterns. An Introduction to Object-Oriented


Analysis and Dessign and the Unified Process”
C. Larman
Prentice Hall. Second Edition. 2002

“Rational Unified Process. Best Practices for Software Development


Teams”. A Rational Software Corporation White Paper.
Tendencias Actuales
Sistemas
™ Grandes
™ Complejos
™ Rápidos
™ Calidad

Dificultad de
coordinación de los
grupos de desarrollo
Necesidad en el desarrollo de
software
• Establecer una guía para ordenar las actividades
de un equipo

• Dirigir las tareas de cada desarrollador por


separado y del equipo como un todo

• Ofrecer criterios para el control y medición de la


calidad de los productos y actividades del proyecto

• Especificar los artefactos a desarrollar


Seis mejores Prácticas

1.Desarrollo Iterativo
2.Administrar Requerimientos
3.Usar Arquitecturas basadas en Componentes
4.Modelado Visual (UML)
5.Verificar Continuamente la Calidad
6.Administrar el Cambio
¿Qué es el Proceso Unificado?
Define:
Quién está haciendo,
Qué es lo que está haciendo,
Cuándo debe hacerlo, y
Cómo obtener un cierto objetivo.
trabajadores
artefactos
fases del proceso
encadenamiento de actividades
Características
Iterativo e incremental

Permite desarrollar un sistema a través de


refinamientos sucesivos e incorporación de
nuevas funcionalidades, creando una
solución efectiva, en múltiples iteraciones.
• Alto nivel de reuso
• Apendizaje del grupo del proyecto durante el
desarrollo del software
• Adaptación a requerimientos cambiantes
• Mitigación de los riesgos y realización de las
pruebas en etapas tempranas del desarrollo del
sotware.
Características
Basado en Casos de Usos

¿Casos de Uso?
Permiten una representación gráfica
adecuada de las funcionalidades requeridas
por usuarios, clientes.

Guían el proceso de desarrollo del


software...
Características
Centrado en la Arquitectura
Proyección de la organización y
estructura de un sistema enfocándose
en aspectos particulares

¿Qué es la Arquitectura de un Sistema?


La descripción del Sistema a través de vistas
utilizando diagramas y modelos

¿Con qué notación?


Centrado en la Arquitectura
¿Por qué es importante?

• Permite una comunicación efectiva entre las


personas involucradas
(diseñador, desarrollador).
• Promueve el reuso del software.
• Permite la prueba individual e integración
gradual de los componentes.
• Permite crear sistemas flexibles y tolerantes
a cambios.
Características
Características
Estructura Estática
Un papel jugado Actividad
por un individuo o Una unidad de
un grupo trabajo

Trabajador

Describen un
Analista
Caso de Uso

responsable para
Artefacto

Un pedazo de información
que es producido,
modificado o usado por un
Caso de Uso proceso
Paquete de Caso de Uso
Fases del Ciclo de Vida

Inicio Elaboración Construcción Transición

tiempo

Define el alcance y
factibilidad del proyecto
Fases del Ciclo de Vida

Inicio Elaboración Construcción Transición

tiempo

Planifica el proyecto,
especifica las
características y la
arquitectura base
Fases del Ciclo de Vida

Inicio Elaboración Construcción Transición

tiempo

Construye el producto
Fases del Ciclo de Vida

Inicio Elaboración Construcción Transición

tiempo

Entrega del producto a


usuarios.
Ciclo de vida

Inicio Elaboración Construcción Transición

Ciclo inicial de desarrollo


Generación 1
tiempo
Ciclo de vida

Inicio Elaboración Construcción Transición Evolución

Ciclo inicial de desarrollo


Generación 1
tiempo
Ciclo de vida

Inicio Elaboración Construcción Transición Evolución

Ciclo inicial de desarrollo


Generación 1
tiempo

Inicio Elaboración Construcción Transición Evolución

Ciclo de evolución
Generación 2
tiempo
Hitos Principales

Inicio Elaboración Construcción Transición

tiempo

Visión Arquitectura Capacidad Liberación


Base Operacional del Producto
Inicial
Fases e Iteraciones
Inicio Elaboración Construcción Transición

Iteración ... Iteración Iteración ... Iteración ...

Versiones Versiones Versiones Versiones Versiones Versiones Versiones Versione

Una iteración es una secuencia de actividades con un


plan establecido y criterio de evaluación, la cual resulta en
una versión del producto.
Iteraciones y Disciplinas
Disciplinas Fases
Fundamentales
Inicio Elaboración Construcción Transición

Modelado del Negocio

Requerimientos

Análisis y Diseño

Implementación
Prueba
Entrega

Gerencia de Configuración y Cambio


Gerencia de Proyecto
Ambiente
Iteraciones
Iteraciones y Disciplinas
Disciplinas Fases
Fundamentales
Inicio Elaboración Construcción Transición

Modelado del Negocio Una iteración


Requerimientos en la
Análisis y Diseño Fase de
Implementación Elaboración
Prueba
Entrega

Gerencia de Configuración y Cambio


Gerencia de Proyecto
Ambiente
Iteraciones
Algunos Artefactos
Iteraciones y Disciplinas
Disciplinas Fases
Fundamentales
Inicio Elaboración Construcción Transición

Modelado del Negocio

Requerimientos

Análisis y Diseño

Implementación
Prueba
Entrega

Gerencia de Configuración y Cambio


Gerencia de Proyecto
Ambiente
Iteraciones
Iteraciones y Disciplinas
Disciplinas Fases
Fundamentales
Inicio Elaboración Construcción Transición

Modelado del Negocio

Requerimientos
Esbozar:
Análisis y Diseño
- Modelo de Casos de Uso
Implementación
Prueba -Especificaciones
Entrega
Complementarias
Gerencia de Configuración y Cambio
Gerencia de Proyecto - Visión
Ambiente
Iteraciones - Glosario
...
Iteraciones y Disciplinas
Disciplinas Fases
Fundamentales
Inicio Elaboración Construcción Transición

Modelado del Negocio

Requerimientos

Análisis y Diseño

Implementación
Prueba
Entrega

Gerencia de Configuración y Cambio


Gerencia de Proyecto
Ambiente
Iteraciones
Iteraciones y Disciplinas
Disciplinas Fases
Fundamentales
Inicio Elaboración Construcción Transición

Modelado del Negocio

Requerimientos Refinar:
Análisis y Diseño
- Modelo de Casos de Uso
Implementación
Prueba -Especificaciones
Entrega
Complementarias
Gerencia de Configuración y Cambio
Gerencia de Proyecto - Visión
Ambiente
Iteraciones - Glosario
...
Iteraciones y Disciplinas
Disciplinas Fases
Fundamentales
Inicio Elaboración Construcción Transición

Modelado del Negocio

Requerimientos

Análisis y Diseño

Implementación
Prueba
Entrega

Gerencia de Configuración y Cambio


Gerencia de Proyecto
Ambiente
Iteraciones
Iteraciones y Disciplinas
Disciplinas Fases
Fundamentales
Inicio Elaboración Construcción Transición

Modelado del Negocio

Requerimientos

Análisis y Diseño
Esbozar:
Implementación
Prueba - Modelo de Diseño
Entrega
- Documento de la
Gerencia de Configuración y Cambio
Gerencia de Proyecto
Arquitectura
Ambiente
Iteraciones
...
Iteraciones y Disciplinas
Disciplinas Fases
Fundamentales
Inicio Elaboración Construcción Transición

Modelado del Negocio Refinar:


Requerimientos - Modelo de
Análisis y Diseño
Diseño
Implementación
Prueba ...
Entrega

Gerencia de Configuración y Cambio


Gerencia de Proyecto
Ambiente
Iteraciones
Iteraciones y Disciplinas
Disciplinas Fases
Fundamentales
Inicio Elaboración Construcción Transición

Modelado del Negocio

Requerimientos
Esbozar:
Análisis y Diseño
- Modelo de
Implementación
Prueba
Implementación
Entrega

...
Gerencia de Configuración y Cambio
Gerencia de Proyecto
Ambiente
Iteraciones
Iteraciones y Disciplinas
Disciplinas Fases
Fundamentales
Inicio Elaboración Construcción Transición

Modelado del Negocio

Requerimientos Refinar:
Análisis y Diseño
- Modelo de
Implementación
Prueba Implementación
Entrega
...
Gerencia de Configuración y Cambio
Gerencia de Proyecto
Ambiente
Iteraciones
Iteraciones y Disciplinas
Disciplinas Fases
Fundamentales
Inicio Elaboración Construcción Transición

Modelado del Negocio

Requerimientos

Análisis y Diseño

Implementación
Prueba
Entrega

Gerencia de Configuración y Cambio Refinar:


Gerencia de Proyecto
Ambiente - Modelo de
Iteraciones
Implementación
...
Casos de Uso en el
Proceso Unificado
Disciplinas
Modelado del Negocio

Requerimientos

Análisis y Diseño
Los Casos de Uso
Implementación enlazan las disciplinas

Prueba

Entrega
Casos de Uso en el
Proceso Unificado
Disciplinas
Modelado del Negocio

Requerimientos

Análisis y Diseño

Implementación

Prueba
Describen los procesos de negocio
Entrega
Casos de Uso en el
Proceso Unificado
Disciplinas
Modelado del Negocio
Lenguaje de comunicación
Requerimientos común entre los clientes o
usuarios y desarrolladores
Análisis y Diseño
del sistema

Implementación Requerido para la definición


de prototipos de interfaces.
Prueba

Entrega
Casos de Uso en el
Proceso Unificado
Disciplinas
Modelado del Negocio Unen actividades de
identificación y descripción
Requerimientos
de requerimientos
Análisis y Diseño Base para la realización de
los Requerimientos, en
Implementación término de objetos que
Prueba
interactúan en el Modelo de
Diseño
Entrega
Creación y validación de la
arquitectura del sistema.
Casos de Uso en el
Proceso Unificado
Disciplinas
Modelado del Negocio
El Modelo de Diseño es la
especificación de la
Requerimientos
implementación.
Análisis y Diseño

Implementación

Prueba

Entrega
Casos de Uso en el
Proceso Unificado
Disciplinas
Modelado del Negocio
Constituyen la base para
identificar los casos de
Requerimientos
prueba
Análisis y Diseño Se ejecuta cada Caso de
Uso, para verificar el
Implementación sistema.
Prueba

Entrega
Casos de Uso en el
Proceso Unificado
Disciplinas
Modelado del Negocio
Sirven para planificar la
Requerimientos entrega de una fase o
definir variantes del
Análisis y Diseño sistema

Implementación Proveen gran parte de la


estructura y contenido de
Prueba
los manuales de usuario.
Entrega
Características
Características
Framework: RUP

NO hay un Proceso Universal!


• El Proceso Unificado es diseñado para flexibilidad y
extensibilidad
» permite una variedad de estrategias de ciclo de vida
» seleccciona qué artefactos producir
» define las actividades y trabajadores y métodos.
Las herramientas en el proceso

• Soportan los procesos de desarrollo de software


modernos

• Automatizan los procesos repetitivos

• Mantienen la información estructurada

• Gestionan grandes cantidades de información

• Guían a los desarrolladores a lo largo de un


camino de desarrollo concreto.
NO se ha entendido el Proceso
Unificado cuando piensa que:
No se ha entendido el Proceso
Unificado cuando piensa que:
No se ha entendido el Proceso
Unificado cuando piensa que:
No se ha entendido el Proceso
Unificado cuando piensa que:
No se ha entendido el Proceso
Unificado cuando piensa que:
No se ha entendido el Proceso
Unificado cuando piensa que:
No se ha entendido el Proceso
Unificado cuando piensa que:
No se ha entendido el Proceso
Unificado cuando piensa que:
No se ha entendido el Proceso
Unificado cuando piensa que:
No se ha entendido el Proceso
Unificado cuando piensa que:
Fase de Inicio

• Delimitar el problema que se desea resolver para


tener confianza de que es posible y deseable
desarrollar el sistema.
• Objetivos
– Establecer el alcance y las condiciones límites del proyecto
– Discriminar los casos de uso críticos del sistema
– Definir al menos una arquitectura inicial apoyada sobre los
escenarios principales
– Estimar el costo total del proyecto y planificar su desarrollo
– Estimar los riesgos.
Fase de Inicio

• ¿Para qué?
– ¿Cuál es la visión y caso del negocio?
– ¿Es factible el proyecto?
– ¿Comprar o Construir el software?
– ¿Orden de precio?
– ¿Seguir adelante?
Fase de Inicio

• Actividades principales
– Determinar el alcance del proyecto
• Capturar los requerimientos y restricciones mas
importantes, de los cuales pueda depender la finalización
del producto
– Preparar un caso del negocio que permita evaluar
alternativas para el manejo de riesgos,
contratación de personal, compromisos entre los
costos, planificación y beneficios
– Diseñar un esquema de arquitectura para estimar
y evaluar costos.
Fase de Inicio

• Artefactos a producir
– Un documento de visión
• requerimientos centrales del proyecto, características
claves y restricciones principales
– Un modelo de casos de uso preliminar que
muestre los casos de uso y los actores
identificados en las etapas iniciales
• Describe los requerimientos funcionales y aquellos no
funcionales relacionados
– Un modelo del dominio que represente los
conceptos más importantes del contexto del
dominio y relaciones entre ellos
Fase de Inicio

• Artefactos a producir
– Un modelo del negocio que muestre:
• contexto del negocio
• criterios para determinar el éxito del proyecto
• previsión financiera
– Glosario
• Describe la terminología clave
– Lista de Riesgos y Plan de Manejo
• Describe y prioriza los riesgos
• Describe cómo mitigar los riesgos
– Plan de Iteración
• Describe qué hacer en la primera iteración de la Fase de
Elaboración
Fase de Inicio

• Artefactos a producir
– Especificaciones Suplementarias
• Describe otros requerimientos
– Prototipo
• del comportamiento del sistema
• de la estructura del sistema
Fase de Elaboración

• Línea base de una arquitectura


ejecutable
– Construir el corazón de la arquitectura
– Resolver los elementos de alto riesgo
– Definir los principales requerimientos
– Estimar cronograma y recursos
Fase de Elaboración

Asegurar que la arquitectura, los


requerimientos y el proyecto son lo
suficientemente estables y que los
riesgos están lo suficientemente
mitigados como para estimar el costo y
la planificación globales del desarrollo.
Fase de Elaboración

• Objetivos
– Capturar la mayoría de los requerimientos
remanentes especificando los funcionales en
términos de casos de uso
– Establecer una base arquitectural estable, para
guiar el trabajo en las fases de construcción y
transición
– Continuar la supervisión de los riesgos críticos
remanentes e identificar los riesgos significativos y
estimar su impacto en el proceso
– Completar los detalles relacionados con el plan del
proyecto.
Fase de Elaboración

• Actividades principales
– Mejorar la visión y establecer una comprensión
sólida de la mayoría de los casos de uso críticos
– Definir los procesos, infraestructura y ambiente de
desarrollo
– Poner en práctica las herramientas y los soportes
de automatización
– Mejorar la arquitectura y seleccionar los
componentes.
Fase de Elaboración

Artefactos a producir
9 Un modelo de casos de uso donde todos los casos de
uso han sido identificados, todos los actores han sido
identificados y la mayoría de los casos de uso han
sido descritos
9 Lista de los requerimientos no funcionales y cualquier
requerimiento que no esté asociado a un caso de uso
especifico
9 Una descripción de la arquitectura de software
9 Una arquitectura ejecutable.
ejecutable
Fase de Elaboración

• Artefactos a producir
– Una lista de riesgos revisada
– Un plan de desarrollo global del proyecto,
el cual muestre las iteraciones y los
criterios de evaluación de cada iteración
– Un manual de usuarios preliminar.
Ejemplo de artefactos y momento de
su concepción
BUP (Basic Unified Process)

• Versión compacta del RUP


• Optimizada para procesos pequeños
– 3 ó 4 personas
– 3 ó 6 meses en desarrollo
• Mantiene características esenciales
de RUP
• Es mínimo, completo y expansible
BUP (Basic Unified Process)

• Disciplinas:
– Incluye requerimientos, arquitectura,
desarrollo, prueba, administración de
proyectos y gestión de cambios.
– Omite modelado de negocio, ambiente,
manejo avanzado de requerimientos,
administración de configuraciones, etc.
• Reduce el número de artefactos

Anda mungkin juga menyukai