1

EL PROCESO UNIFICADORATIONAL

Lic. Espinoza Robles Armando David

2

El Proceso Unificado Dirigido por Casos de uso, centrado en la arquitectura, iterativo e

incremental

• El problema del Softw., se reduce a la dificultad de los desarrolladores de coordinar las múltiples cadenas de trabajo de un gran proyecto.

• Los desarrolladores necesitan un proceso que:– Proporcione una guía para ordenar las actividades de un

equipo– Dirija la tareas de cada desarrollador por separado y del

equipo con un todo– Especifique los artefactos a desarrollar– Ofrezca criterios para el control y medición de los

productos y actividades del proyecto

3

El Proceso Unificado

• Un proceso de desarrollo de Softw., es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema.

• El PU es mas que un simple proceso es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas.

4

• El PU, esta basado en componentes interconectados a través de interfaces bien definidas.

• EL PU, utiliza el UML, para preparar los esquemas de un Sist.Softw. UML es parte esencial del PU.

• El PU se resume en tres palabras claves:– Dirigido por casos de uso– Centrado en la arquitectura– Iterativo e incremental

5

El proceso Unificado esta dirigido por casos de Uso.

• Para construir un sistema con éxito debemos conocer las necesidades del usuario.

• El Usuario: representa alguien o algo que interactúa con el sistema que estamos desarrollando

• Un caso de Uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante, y representan los requisitos funcionales .

6

• Todos los casos de uso constituyen el modelo de casos de uso, el cual describe la funcionalidad total del sistema

• Una especificación funcional contesta a la pregunta ¿qué debe hacer el sistema? Y se añade al final ¿para cada usuario?.

• Esto nos obliga a pensar en términos de los usuarios y no solo en términos de funciones.

• Los casos de uso sirven– para especificar los requisitos – Guían el diseño, implementación y prueba del

sistema (el proceso de desarrollo)

7

• Dirigido por casos de uso: quiere decir que el proceso de desarrollo sigue un hilo : avanza a través de una serie de flujos de trabajo que parten de los caso de uso.

• Los casos de uso se desarrollan a la vez que la arquitectura del sistema. Es decir los casos de uso guían la arquitectura del sistema, y la arquitectura influye en la selección de los casos de uso. Ambos maduran según avanza el ciclo de desarrollo.

8

El Proceso Unificado esta centrado en la Arquitectura

• La arquitectura en un sistema Softw., se describe mediante diferentes vistas del sistema en construcción.

• La Arquitectura surge de las necesidades de la empresa , como las perciben los usuarios y los inversores y se refleja en los caso de uso

• También esta influenciada por la plataforma de hardware y software, las interfaces graficas, sistemas heredados y requisitos no funcionales. (rendimiento, fiabilidad)

9

• La arquitectura es una vista del diseño completo con las características mas importantes resaltadas dejando los detalles de lado.

• El valor de la arquitectura depende de las personas que se hayan responsabilizado de su creación.

• El PU ayuda al arquitecto a centrarse en los objetivos adecuados, como la comprensibilidad, la capacidad de adaptación al cambio y la reutilización.

10

• Debe existir en todo producto un equilibrio entre la función y la forma, para que sea exitoso.

• La función corresponde a los casos de uso y la forma a la arquitectura.

• La arquitectura y los casos de uso deben evolucionar en paralelo.

• Los arquitectos modelan el sistema para darle forma, esta forma debe diseñarse para que el sistema evolucione a lo largo de futuras generaciones.

• Para encontrar esta forma los arquitectos deben trabajar en la compresión de los casos de uso claves, que pueden ser entre 5 o 10 % del total

11

• De manera resumida podemos decir que el arquitecto:– El arquitecto debe tener una comprensión

general de los casos de uso antes de empezar la creación del esquema arquitectónico.

– A continuación, el arquitecto trabaja con un subconjunto de los casos de uso, aquellos que representan las funciones claves del sistema. Estos se detallan en subsistemas, clases, y componentes.

– A medida que los casos de uso maduren, se descubre mas de la arquitectura.

12

El Proceso Unificado es Iterativo e incremental

• El desarrollo de un producto software comercial puede durar varios meses o incluso años, por lo que es practico dividir el trabajo en partes mas pequeñas o miniproyectos.

• Cada miniproyecto es una iteración que resulta en un incremento

13

• Las iteraciones hacen referencia a pasos en el flujo de trabajo y los incrementos, al crecimiento del producto.

• Las iteraciones deben estar controladas, es decir, deben seleccionase y ejecutarse de una forma planificada

• la selección de lo que se implementara se base en:– la iteración trata un grupo de casos de uso que

juntos amplían la utilidad del producto.– La iteración trata los riesgos mas importantes

14

• En cada iteración los desarrolladores identifican los caso de uso relevantes, crean un diseño usando la arquitectura seleccionada como guía, implementan el diseño mediante componentes y verifican que los componentes satisfacen los casos de uso.

• Si una iteración cumple sus objetivos el desarrollo continua con la siguiente iteración.

15

• Los beneficios de un proceso iterativo controlado:– la iteración controlada reduce el costo del riesgo

a los costes de un solo incremento.– La iteración controlada reduce el riesgo de no

sacar al mercado el producto en el calendario previsto.

– La iteración controlada acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los desarrolladores trabajan de manera mas eficiente.

– La iteración controlada reconoce una realidad que a menudo se ignora. Los requerimientos del usuario

16

• La vida del Proceso Unificado:• el PU se repite a lo largo de una serie de

ciclos que constituye la vida de un sistema • cada ciclo concluye con una versión del

producto para los clientes.• Cada ciclo consta de 4 fases :

– inicio o fase de comienzo– elaboración – construcción y transición.

• Cada fase a su vez se subdivide en iteraciones.

17

Nacimiento muerte

Los ciclos concluyen con una versión

tiempo

inicio elaboración construcción transición

It 1 It 2 It n-1 It n

Versiones

18

• El Producto

• cada ciclo produce una nueva versión del sistema y cada versión es un producto preparado para su entrega.

• Consta de un código fuente incluido en componentes que puede compilarse y ejecutare.

• Además de los manuales y otros productos asociados..

19

• El producto terminado incluye los requisitos, casos de uso, especificaciones no funcionales, y casos de prueba. Incluye el modelo de arquitectura y el modelo visual., artefactos modelados en UML.

• Los componentes ejecutables son los artefactos mas importantes desde la perspectiva del usuario, sin embargo no son suficientes por si solos. Ya que el entorno cambia.

20

• Para llevar a cabo el siguiente ciclo de manera eficiente los desarrolladores necesitan todas las representaciones del producto:– un modelo de casos de uso– un modelo de análisis– un modelo de diseño que defina

• la estructura estática del sistema

• los casos de uso reflejados como colaboraciones

– un modelo de implementación– un modelo de despliegue– un modelo de prueba– una representación de la arquitectura

21

• El sistema también debe tener un modelo de dominio o modelo de negocios que describa el contexto del negocio en el que halla el sistema.

• Todos estos modelos están relacionados representan el sistema como un todo.

• Los elementos de un modelo poseen dependencias de Traza, hacia atrás y adelante. Por lo que se puede hacer un seguimiento de un elemento.

22

• Fases dentro del un Ciclo.

• Cada ciclo se desarrolla a lo largo del tiempo.

• El tiempo a su vez se divide en cuatro fases:– Inicio, elaboración, construcción, transición.

• A través de una secuencia de modelos, los implicados visualizan lo que esta sucediendo en las fases. Cada fase termina en un hito.

23

• La fase de Inicio: se desarrolla una descripción del producto final, y se presenta el análisis del negocio. Esta fase responde a la pregunta:– ¿ Cuales son las principales funciones del

sistema para sus usuarios mas importantes?– ¿Como podría ser la arquitectura del sistema?– ¿Cual es el Plan del Proyecto y cuanto costara el

producto?

• La respuesta a la primera pregunta esta en un modelo de casos mas críticos

24

• La arquitectura es provisional y es una simple esbozo que muestra los subsistemas mas importantes

• En esta fase se identifican y priorizan los riesgos, se planifica en detalle la fase de elaboración y se estima el costo del proyecto de manera aproximada

• La fase de Elaboración: se especifica en detalle la mayoría de los casos de uso y se diseña la arquitectura del sistema.

• La arquitectura se expresa en forma de vistas de todos los modelos del sistema

25

• Lo que implica que hay vista arquitectónica del modelo de, casos de uso, análisis, diseño, implementación, y de despliegue.

• El resultado de esta fase es una línea base de la arquitectura .

• Al final de la fase de elaboración, el director del proyecto esta en disposición de planificar actividades y estimar los recursos necesarios para terminar el proyecto.

26

• La fase de Construcción: se crea el producto, la línea base de la arquitectura crece hasta convertirse sistema completo. La descripción evoluciona hasta convertirse en producto para ser entregado a usuarios.

• El grueso de los recursos se usan en esta fase

• los defectos que queden se corrigen en la fase de transición

• la pregunta es: ¿cubre el producto las necesidades de los usurarios de manera suficiente como para hacer una entrega?

27

• La fase de Transición: cubre el periodo durante el cual el producto se convierte en versión beta donde un numero reducido de usuarios prueban el producto, e informan los defectos.

• La fase de transición conlleva actividades formación del cliente, proporcionar una línea de ayuda y la corrección de defectos.

• Los defectos pueden ser de dos categorías:– los de gran impacto justifican versión nueva– los que puedan corregirse en la siguiente versión

normal.