Proceso Unificado de Desarrollo de Software - …mgoncalves/IS2/sd07/clase3.pdf · “El Proceso...

13 de sep de 2006

Proceso Unificado de Desarrollo de

Software

Referencias básicas

“El Proceso unificado de desarrollo de Software”I. Jacobson, G. Booch y J.RumbaughAddison Wesley - Pearson Education 1999

“Applying UML and Patterns. An Introduction to Object-OrientedAnalysis and Dessign and the Unified Process”

C. LarmanPrentice Hall. Second Edition. 2002

“Rational Unified Process. Best Practices for Software Development Teams”. A Rational Software Corporation White Paper.

Tendencias Actuales

Grandes

Complejos

Rápidos

Calidad

Sistemas

Dificultad de coordinación de los grupos de desarrollo

• Establecer una guía para ordenar las actividadesde 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

Necesidad en el desarrollo de software

Seis mejores Prácticas

1.Desarrollo Iterativo2.Administrar Requerimientos3.Usar Arquitecturas basadas en Componentes4.Modelado Visual (UML)5.Verificar Continuamente la Calidad6.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.

trabajadoresartefactosfases del procesoencadenamiento 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

¿Qué es la Arquitectura de un Sistema?

La descripción del Sistema a través de vistas

utilizando diagramas y modelos

Proyección de la organización y estructura de un sistema enfocándose en aspectos particulares

¿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

Estructura Estática

Describen un Caso de Uso

Paquete de Caso de UsoCaso de Uso

responsable para

Analista

Trabajador

Un papel jugado por un individuo o un grupo

ActividadUna unidad de trabajo

Un pedazo de información que es producido, modificado o usado por un proceso

Artefacto

Fases del Ciclo de Vida

tiempo

Inicio Elaboración Construcción Transición

Define el alcance y factibilidad del proyecto


tiempo


Planifica el proyecto, especifica las

características y la arquitectura base


tiempo


Construye el producto


tiempo


Entrega del producto a usuarios.

Ciclo de vida

tiempo


Ciclo inicial de desarrolloGeneración 1

Ciclo de vida

tiempo

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

Ciclo inicial de desarrolloGeneración 1

Ciclo de vida

tiempo


tiempo


Ciclo inicial de desarrollo

Ciclo de evolución

Generación 1

Generación 2

Hitos Principales

Visión ArquitecturaBase

CapacidadOperacional

Inicial

Liberación del Producto

tiempo


Fases e Iteraciones

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.

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

Versiones Versiones Versiones Versiones Versiones Versiones Versiones Versione


Iteraciones y Disciplinas

Modelado del Negocio

ImplementaciónPrueba

Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos

Gerencia de ProyectoAmbiente

Fases

Iteraciones

Elaboración Construcción TransiciónInicio

Gerencia de Configuración y Cambio




Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones

Elaboración Construcción Transición


Una iteración en laFase de Elaboración

Inicio

Algunos Artefactos




Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones



Inicio




Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones



Esbozar:

- Modelo de Casos de Uso

-Especificaciones

Complementarias

- Visión

- Glosario

...

Inicio




Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones



Inicio




Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones



Refinar:

- Modelo de Casos de Uso

-Especificaciones

Complementarias

- Visión

- Glosario

...

Inicio




Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones



Inicio




Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones



Esbozar:

- Modelo de Diseño

- Documento de la

Arquitectura

...

Inicio




Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones



Refinar:

- Modelo de

Diseño

...

Inicio




Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones



Esbozar:

- Modelo de

Implementación

...

Inicio




Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones



Refinar:

- Modelo de

Implementación

...

Inicio




Entrega

Análisis y Diseño

Disciplinas

Fundamentales

Requerimientos


Fases

Iteraciones


Gerencia de Configuración y Cambio Refinar:

- Modelo de

Implementación

...

Inicio

Casos de Uso en el Proceso Unificado


Requerimientos

Análisis y Diseño

Implementación

Prueba

Entrega

Disciplinas

Los Casos de Uso enlazan las disciplinas



Requerimientos

Análisis y Diseño

Implementación

Prueba

Entrega

Describen los procesos de negocio

Disciplinas



Requerimientos

Análisis y Diseño

Implementación

Prueba

Entrega

Lenguaje de comunicación común entre los clientes o usuarios y desarrolladores del sistema

Requerido para la definición de prototipos de interfaces.

Disciplinas



Requerimientos

Análisis y Diseño

Implementación

Prueba

Entrega

Unen actividades de identificación y descripción de requerimientos

Base para la realización de los Requerimientos, en término de objetos que interactúan en el Modelo de Diseño

Creación y validación de la arquitectura del sistema.

Disciplinas



Requerimientos

Análisis y Diseño

Implementación

Prueba

Entrega

El Modelo de Diseño es la especificación de la implementación.

Disciplinas



Requerimientos

Análisis y Diseño

Implementación

Prueba

Entrega

Constituyen la base para identificar los casos de prueba

Se ejecuta cada Caso de Uso, para verificar el sistema.

Disciplinas



Requerimientos

Análisis y Diseño

Implementación

Prueba

Entrega

Sirven para planificar la entrega de una fase o definir variantes del sistema

Proveen gran parte de la estructura y contenido de los manuales de usuario.

Disciplinas

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:

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


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.


• 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.


• 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.


Artefactos a producirUn 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

Lista de los requerimientos no funcionales y cualquier requerimiento que no esté asociado a un caso de uso especifico

Una descripción de la arquitectura de software

Una arquitectura ejecutablearquitectura ejecutable.


• 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 esencialesde 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

Proceso Unificado de Desarrollo de Software - …mgoncalves/IS2/sd07/clase3.pdf · “El Proceso...

Documents

Transcript of Proceso Unificado de Desarrollo de Software - …mgoncalves/IS2/sd07/clase3.pdf · “El Proceso...