CAPITULO II Proceso Unificado Rational

2.1 UN PROCESO DIRIGIDO POR CASOS DE USO

La captura de requisitos tiene dos objetivos: Encontrar los verdaderos requisitos Representarlos de un modo adecuado

Un verdadero requisito es aquel que cuando se implementa aadir el valor esperado para los usuarios.

Por qu casos de uso? Por que proporcionan un medio sistemtico e intuitivo de capturar requisitos. Dirigen todo el proceso de desarrollo debido a que la mayora de las actividades (Anlisis, diseo e implementacin) se llevan a cabo partiendo de los casos de uso.

tems a considerar: Los usuarios y los clientes son los expertos en los requisitos. Los casos de uso enlazan los flujos de trabajo fundamentales. Los casos de uso ayudan a los jefes de proyecto a planificar, asignar y controlar muchas de las tareas que los desarrolladores realizan. Los casos de uso ayudan a llevar a cabo el desarrollo iterativo. En cada iteracin se identifican e implementan unos cuantos casos de uso. Se utilizan diagramas de casos de uso, donde cada actor representa un usuario y estos se comunican con el sistema mediante el envo y recepcin de mensajes.

2.2 UN PROCESO CENTRADO EN LA ARQUITECTURA

La arquitectura nos da una clara perspectiva del sistema completo, es necesaria la arquitectura para poder controlar el desarrollo. Describe los elementos ms importantes del modelo, estos elementos nos guan en nuestro trabajo con el sistema. Los elementos arquitectnicamente significativos son los siguientes: Algunos de los subsistemas.

Dependencias. Interfaces. Colaboraciones. Nodos y clases activas.

Estas ideas de arquitectura, es desarrollada por los arquitectos iterando repetidas veces durante la fase de inicio y colaboracin. El primer objetivo de la fase de elaboracin es establecer una arquitectura.

Recordar siempre que:

La idea de la arquitectura es lo que se encuentra en la mente del autor

La arquitectura abarca decisiones importantes sobre: La organizacin del sistema software. Los elementos estructurales que compondran el sistema y sus interfaces. La composicin de los elementos estructurales y del comportamiento en subsistemas. El estilo de la arquitectura.

La arquitectura software est afectada por: Estructura. Comportamiento. Uso. Funcionalidad. Rendimiento. Flexibilidad Reutilizacin. Facilidad de comprensin. Restricciones. Compromisos econmicos, tecnolgicos y la esttica.

La arquitectura se representa mediante vistas, las cuales se basan en los modelos existentes, por ejemplo: modelo de casos de uso, modelos de anlisis, etc.

Para una arquitectura se necesita: Comprender el sistema. Organizar el desarrollo. Fomentar la reutilizacin. Hacer evolucionar el sistema.

Debemos crear una arquitectura que nos permita implementar los casos de uso de una forma econmica, ahora y en el futuro.

Casos de uso ARQUITECTURA Software del sistema Capa intermedia (marcos de trabajo) Sistemas heredados Estndares y polticas corporativas (Lenguaje de definicin de interfaces) Requisitos no funcionales (disponibilidad, recuperacin, memoria, etc.) Necesidades de distribucin

Experiencia: - arquitecturas anteriores. - Patrones de arquitectura.

CASOS DE USO

Gua

Conduce

ARQUITECTURA

Capa intermedia (middleware): capa que ofrece bloques de construccin reutilizables (paquetes o subsistemas) a marcos de trabajo o servicios independientes de la plataforma, para cosas como computacin con objetos distribuidos, o interoperabilidad en entornos heterogneos. Cualquier producto que lleva a cabo mecanismos de diseo genricos. (Investigas capas de software del sistema)

La descripcin de la arquitectura es un conjunto de vistas del sistema, incluyen elementos arquitectnicamente significativos (que son parte de la lnea base de la arquitectura). La lnea base de la arquitectura no solo se usa para desarrollar una arquitectura, sino que especifica los requisitos del sistema en un nivel que permita el desarrollo de un plan detallado. La descripcin de la arquitectura se debe mantener actualizada a lo largo de la vida del sistema para reflejar los cambios y las adiciones que son relevantes para la arquitectura. Vistas de arquitectura:

Vista del modelo de casos de uso: define los actores y los casos de uso ms importantes, o escenarios de esos casos de uso.

Vista del modelo de anlisis: abarca clases, paquete y realizaciones de casos de uso de anlisis. Fundamentalmente aborda el refinamiento y estructuracin de los requisitos del sistema.

Vista de modelo de diseo: presenta los clasificadores ms importantes para la arquitectura en el diseo: subsistemas e interfaces ms importantes, y algunas pocas clases muy importantes.

Vista de modelo de despliegue: define la arquitectura fsica del sistema por medio de nodos interconectados. Estos nodos son elementos hardware sobre los cuales

pueden ejecutarse elementos software. Nodos que forman la topologa hardware sobre la que se ejecuta el sistema. Vista del modelo de implementacin: correspondencia directa de los modelos de diseo y despliegue. Cada subsistema acaba sendo un componente por cada tipo de nodo en el que deba instalarse, pudindose en algunos casos ejecutarse sobre varios nodos el mismo componente.

2.3 UN PROCESO ITERATIVO E INCREMENTAL

Un proceso debe tener en cuenta una secuencia de hitos. Las fases del proceso son: Fase de inicio: identificacin y reduccin de riesgos. Idea inicial para el desarrollo la cual se refina hasta quedar lo suficientemente bien establecida como para garantizar la entrada en la fase de elaboracin. Fase de elaboracin: preparacin del plan de proyecto. Se define la arquitectura (Lnea base de la arquitectura) Fase de construccin: incrementos y entregas peridicas. El software es desarrollado a partir de una lnea base de arquitectura ejecutable, hasta que est lista para ser transmitido a la comunidad de usuarios. Fase de transicin: correccin de defectos. El software es puesto a la comunidad de usuarios.

El desarrollo iterativo se hace teniendo en cuenta un desarrollo en pequeos pasos: Planificar un poco. Especificar, disear e implementar un poco. Integrar, probar y ejecutar un poco en cada iteracin.

En las primeras fases vamos reduciendo gradualmente los riesgos e implementando los componentes. El ciclo de vida iterativo produce resultados tangibles en forma de versiones internas y cada una de ellas aporta un incremento y reduce riesgos.