El documento describe el Proceso Unificado Racional (PU), un marco de trabajo para el desarrollo de software. El PU es dirigido por casos de uso, centrado en la arquitectura e iterativo e incremental. Los casos de uso guían el desarrollo y la arquitectura, la cual evoluciona a lo largo de iteraciones para entregar incrementos del producto. El PU consta de ciclos con fases de inicio, elaboración, construcción y transición para desarrollar versiones del producto.

1. EL PROCESO UNIFICADO RATIONAL 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 f unción y la form a, 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.