UNIVERSIDAD DE MANAGUA

Seminario: Resumen Seminario RUP

Autores: Elliethe Patricia Mendoza Silvia Elena Hernndez Vega Juan Gabriel Pichardo Rodrguez.

Asesor: Msc. Ing. Patricia Prez Lorences

Septiembre 2011

Que es un proceso Unificado Es un proceso de Desarrollo de Software, basado en componentes interconectados a travs de interfaces. Que es un proceso de Desarrollo de Software Es un conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema de software. El proceso unificado utiliza lenguaje unificado de modelado para preparar todos los esquemas de un sistema de software, por tanto, UML es una parte esencial ya que sus desarrollos fueron paralelos. El proceso unificado est enfocado en tres frases claves que son: Dirigido por casos de uso Centrado en la Arquitectura Iterativo e Incremental El trmino usuario representa alguien o algo que interacta con el sistema que estamos desarrollando. Dirigido por casos de uso Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante, los casos de uso no son solo una herramienta para especificar los requerimientos de un sistema, tambin guan su diseo, implementacin y prueba. Centrado en la Arquitectura La Arquitectura en un sistema de software se describe mediante diferentes vistas del sistema en construccin. La arquitectura surge de las necesidades de la empresa La arquitectura es una vista del diseo completo con las caractersticas ms importantes resaltadas, dejando los detalles de lado. No obstante, el proceso ayuda al arquitecto a centrarse en los objetivos adecuados como la comprensibilidad, la capacidad de adaptacin al cambio y la reutilizacin. Cada producto tiene una funcin como una forma. La funcin corresponde a los casos de uso y la forma a la arquitectura. Iterativo e Incremental Las iteraciones hacen referencia a pasos en el flujo de trabajo y los incrementos al crecimiento. Al ser mini proyectos comienzan con los casos de uso y continan a travs del

trabajo de desarrollo sub-siguiente: anlisis, diseo, implementacin y prueba que termina convirtiendo en cdigo ejecutable los casos de uso que se desarrollaban en la iteracin. En cada iteracin los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseo utilizando la arquitectura seleccionada como gua, implementan el diseo mediante componentes y verifican que los componentes satisfacen los casos de uso. Si una iteracin cumple con los objetivos como suele suceder el desarrollo contina con la siguiente iteracin. Cuando no cumple con los objetivos, los desarrolladores deben revisar sus decisiones previas y probar con un nuevo enfoque. Fases del Proceso Unificado Cada ciclo se desarrolla a lo largo del tiempo. Este tiempo a su vez se divide en 4 fases: Inicio, Elaboracin, Construccin y Transicin. A travs de una secuencia de modelos los implicados visualizan lo que est sucediendo en esas fases. Dentro de cada fase, los directores o los desarrolladores pueden descomponer adicionalmente el trabajo en iteraciones con sus incrementos resultantes. Cada fase termina con un hito. Cada hito se determina por la disponibilidad de un conjunto de artefactos.

Un proceso Dirigido por Casos de Uso El objetivo del Proceso Unificado es guiar a los desarrolladores en la implementacin y distribucin eficiente de sistemas que se ajusten a las necesidades de los clientes.

La eficiencia se mide en trmino de costo, calidad y tiempo de desarrollo. Un caso de uso es una secuencia de acciones que el sistema lleva a cabo para ofrecer algn resultado de valor para un actor. Los casos de uso proporcionan un medio sistemtico e intuitivo de capturar los requisitos funcionales, dirigen todo el proceso de desarrollo debido a que la mayora de las actividades como el anlisis, diseo y prueba se llevan a cabo partiendo de los casos de uso. Las necesidades del cliente no son fciles de discernir, esto nos obliga a que tengamos algn modo de capturar las necesidades del usuario de forma que puedan comunicarse fcilmente a todas las personas implicadas en el proyecto. Durante el flujo de trabajo de los requisitos, identificamos las necesidades de usuarios y clientes como requisitos. Los requisitos funcionales se expresan como casos de uso en un modelo de casos de uso. Durante el anlisis y el diseo, el modelo de casos de uso se transforma es un modelo de diseo a travs de un modelo de anlisis, ambos modelos son estructuras compuestas por clasificadores. El modelo de casos de uso ayuda al cliente, a los usuarios y a los desarrolladores a llegar a un acuerdo sobre cmo utilizar el sistema. Cada tipo de usuario se representa mediante un actor. Los actores utilizan el sistema al interactuar con los casos de uso. Los actores se comunican con el sistema mediante el envi y recepcin de mensajes y desde el sistema segn ste lleva a cabo los casos de uso. A medida que definimos lo que hacen los actores y los casos de uso trazaremos una clara separacin entre las responsabilidades de los actores y las del sistema. Los casos de uso ayudan a los desarrolladores a encontrar las clases. Las clases se recogen de las descripciones de los casos de uso a medida que las leen los desarrolladores buscando clases que sean adecuadas para la realizacin de los casos de uso. Un proceso centrado en la Arquitectura Los casos de usos solamente no son suficientes, se necesitan ms cosas para conseguir un sistema de trabajo. Esas Cosas son la arquitectura. La arquitectura nos da una clara perspectiva del sistema completo, necesaria para controlar el desarrollo. Necesitamos una arquitectura que describa los elementos del modelo que son ms importantes para nosotros, su importancia reside en el hecho de nos guan en nuestro trabajo con el sistema, tanto en este ciclo como a travs del ciclo de vida completo. La Arquitectura se necesita para: Comprender el sistema: Para que una organizacin desarrolle un sistema, dicho sistema debe ser comprendido por todos los que vayan a intervenir en l. Organizar el desarrollo: Cuando un proyecto es grande y complejo es necesario dividir el sistema en subsistemas con las interfaces claramente definida y con un responsable o un grupo de responsables para cada subsistema.

Fomentar la reutilizacin: Un buen arquitecto ayuda a los desarrolladores para que sepan dnde buscar elementos reutilizables de manera poco costosa y para que puedan encontrar los componentes adecuados para ser reutilizados. Hacer evolucionar un sistema: El sistema debe ser en s mismo flexible a los cambios o tolerante a los cambios, el sistema debe ser capaz de evolucionar sin problema. Casos de usos y Arquitectura Si el sistema proporciona los casos de usos correctos, casos de uso de alto rendimiento, calidad y facilidad de utilizacin, los usuarios pueden emplearlo para llevar a cabo sus objetivos, mediante la construccin de una arquitectura que nos permitan implementar los casos de uso de una forma econmica, ahora y en el futuro. Como ya hemos dicho, la arquitectura est condicionada por los casos de uso que queremos que soporte el sistema; los casos de uso son directores de la arquitectura. Despus de todo, queremos una arquitectura viable a la hora de implementar nuestros casos de uso. La arquitectura se desarrolla en iteraciones de la fase de elaboracin. La siguiente podra ser una aproximacin simplificada, de algn modo ingenua. Comenzamos determinando un diseo de alto nivel para la arquitectura, a modo de una arquitectura en capas. Despus formamos la arquitectura en un par de construcciones dentro de la primera iteracin. En la primera construccin, trabajamos con las partes generales de la aplicacin, que son generales en cuanto al dominio y que no son especficas del sistema que pensamos desarrollar, el middleware, los sistemas heredados, los estndares y las polticas de uso. Decidimos que nodos contendr nuestro modelo de desarrollo y cmo deben interactuar entre ellos. Tambin decidimos cmo manejar los requisitos generales no funcionales, as como la disponibilidad de estos requisitos. Con la primera pasada es suficiente para tener una visin general del funcionamiento de la aplicacin. En la segunda construccin trabajamos con los aspectos de la arquitectura especficos de la aplicacin. Escogemos un conjunto de casos de uso relevantes en cuanto a la arquitectura, capturamos los requisitos, los analizamos, los diseamos, los implementamos y los probamos. El resultado sern nuevos subsistemas implementados como componentes del desarrollo que soportan los casos de uso seleccionados. Pueden existir tambin algunos cambios en los componentes significativos de la arquitectura que implementamos en la primera entrega. Los componentes nuevos o cambiados se desarrollan para realizar los casos de uso, y de esta forma la arquitectura se adapta para ajustarse mejor a los casos de uso. Entonces elaboremos otra construccin, y as sucesivamente hasta terminar con las iteraciones. Si este final de las iteraciones tiene lugar en el final de la fase de elaboracin, habremos conseguido una arquitectura estable. Cuando tenemos una arquitectura estable, podemos implementar la funcionalidad completamente realizando el resto de casos de uso durante la fase de construccin. Los casos de uso implementados durante la fase de construccin se desarrollan utilizando como

entradas los requisitos de los clientes y de los usuarios, pero los casos de uso estn tambin influenciados por la arquitectura elegida en la fase de elaboracin. Segn vayamos capturando nuevos casos de uso, vamos utilizando el conocimiento que ya tenemos de la arquitectura existente para hacer mejor nuestro trabajo. Cuando calculamos el valor y el coste de los casos de uso que se sugieren, lo hacemos a la luz de la arquitectura que tenemos. Qu es la lnea base de la arquitectura: Es un sistema pequeo y flaco, tiene las versiones de todos los modelos que un sistema terminado contiene al final de la fase de construccin. Incluye el mismo esqueleto de subsistemas, componentes y nodos que un sistema definitivo, pero no existe toda la musculatura. No obstante, la lnea base de la arquitectura, esto es, la versin interna del sistema al final de la fase de elaboracin, se representa por algo ms que los artefactos del modelo. Tambin se incluye la descripcin de la arquitectura. El papel de la descripcin de la arquitectura es guiar al equipo de desarrollo a travs del ciclo de vida del sistema, no solo por las iteraciones del ciclo actual, sino por todos los ciclos que vengan. ste es el estndar a seguir por todos los desarrolladores, ahora y en el futuro. Como la arquitectura debera ser estable, el estndar debera ser estable tambin. Descripcin de la arquitectura La descripcin de la arquitectura es un extracto o, en nuestro trmino, un conjunto de vistas, quizs con una reescritura cuidada para hacerlo ms legible de los modelos que estn en la lnea base de la arquitectura. Estas vistas incluyen los elementos arquitectnicamente significativos. La descripcin de la arquitectura debe mantenerse actualizado a lo largo de la vida del sistema para reflejar los cambios y las adiciones que son relevantes para la arquitectura. Estos cambios son normalmente secundarios y pueden incluir: * La identificacin de nuevas clases abstractas e interfaces. * La adicin de nueva funcionalidad a los subsistemas existentes. * La actualizacin a nuevas versiones de los componentes reutilizables. * La reordenacin de la estructura de procesos. La arquitectura de software: Se centra tanto en los elementos estructurales significativos del sistema, como subsistemas, clases, componentes y nodos, como en las colaboraciones que tienen lugar entre estos elementos a travs de las interfaces. La arquitectura se desarrolla de forma iterativa durante la fase de elaboracin pasando por los requisitos, el anlisis, el diseo, la implementacin y las pruebas. Utilizamos los casos de uso significativos para la arquitectura y un conjunto de otras entradas para implementar la lnea base de la arquitectura del sistema. Ese conjunto de entradas incluye requisitos del software del sistema, middleware, que sistemas heredados deben utilizarse, requisitos no funcionales, y dems.

La descripcin de la arquitectura es una vista de los modelos del sistema, de los modelos de casos de uso, anlisis, diseo, implementacin y despliegue. La descripcin de la arquitectura describe las partes del sistema que es importante que comprendan todos los desarrolladores y otros interesados.

Un proceso iterativo e incremental Un proceso de desarrollo de software debe tener una secuencia de hitos claramente articulados para ser eficaz, que proporcionen a los directores y al resto del equipo del proyecto los criterios que necesitan para autorizar el paso de una fase a la siguiente dentro del ciclo del producto. Dentro de cada fase, el proceso pasa por una serie de iteraciones e incrementos que nos conducen a esos criterios. En la fase de inicio el criterio esencial es la viabilidad, que llevamos a cabo mediante: La identificacin y la reduccin de riesgos, crticos para la viabilidad del sistema. La creacin de una arquitectura candidata a partir del desarrollo de un subconjunto clave de los requisitos, pasando por el modelo de casos de uso. La realizacin de una estimacin inicial de coste, esfuerzo, calendario y calidad del producto con lmites amplios. El inicio del anlisis del negocio por el cual el proyecto parece que merece la pena econmicamente, una vez ms con lmites amplio.

En la fase de elaboracin, el criterio esencial es la capacidad de construir el sistema dentro de un marco de trabajo econmico, que llevamos a cabo mediante: La identificacin y reduccin de los riesgos que afectan de manera significativa a la construccin del sistema. La especificacin de la mayora de los casos de uso que representan la funcionalidad que ha de desarrollarse. La extensin de la arquitectura candidata hasta las proporciones de una lnea base. La preparacin del plan de proyecto con suficiente detalle como para guiar la fase de construccin. La realizacin de una estimacin con unos lmites suficientemente ajustados como para justificar la inversin. La terminacin del anlisis del negocio, el proyecto merece la pena.

En la fase de construccin, el criterio esencial, es un sistema capaz de operatividad inicial en el entorno del usuario, y lo llevaremos a cabo mediante:

Una serie de iteraciones, que llevan a incrementos y entregas peridicos, de forma que a lo largo de esta fase, la viabilidad del sistema siempre es evidente en la forma de ejecutables.

En la fase de transicin, el criterio esencial es un sistema que alcanza una operatividad final, llevado a cabo mediante: La modificacin del producto para subsanar problemas que no se identificaron en fases anteriores. La correccin de defectos

Uno de los objetivos del proceso unificado es hacer que los arquitectos, desarrolladores e interesados en general comprendan la importancia de las primeras fases. El estar centrado en la arquitectura, significa que el trabajo se centra en obtener el patrn de la arquitectura que dirigir la construccin del sistema en las primeras fases, garantizando un proceso continuo no solo para la versin en curso del producto, sino para la vida entera del mismo. La tercera clave proporciona la estrategia para desarrollar un producto software en pasos pequeos manejables: Planificar un poco Especificar, disear, e implementar un poco Integrar, probar, y ejecutar un poco cada iteracin

Si estamos contentos con un paso, continuamos con el siguiente. En cada paso obtenemos retroalimentacin que nos permita ajustar nuestros objetivos para el siguiente paso. Despus se da el siguiente paso, y despus otro. Cuando se han dado todos los pasos que habamos planificado, tenemos un producto desarrollado que podemos distribuir a nuestros clientes y usuarios. Las iteraciones en las primeras fases, tratan en su mayor parte con la determinacin del mbito del proyecto, la eliminacin de riesgos crticos, y la creacin de lnea base de la arquitectura. Despus a medida que avanzamos a lo largo del proyecto y vamos reduciendo gradualmente los riesgos restantes e implementando los componentes, la forma de las iteraciones cambia, dando incrementos como los resultados. En resumen, un ciclo de vida se compone de una secuencia de iteraciones. Algunas de ellas, especialmente las primeras, nos ayudan a comprender los riesgos, determinar la viabilidad, construir el ncleo interno del software, y realizar el anlisis del negocio. Otras, en especial las ltimas, incorporan incremento hasta conseguir un producto preparado para su entrega. Por qu un desarrollo iterativo e incremental?

Para obtener un software mejor Para cumplir los hitos principales y secundarios con los cuales controlamos el desarrollo. Para tomar las riendas de los riesgos crticos y significativos desde el principio Para poner en marcha una arquitectura que guie el desarrollo del software Para proporcionar un marco de trabajo, que gestione de mejor forma los inevitables cambios en los requisitos y en otros aspectos. Para construir el sistema a lo largo del tiempo, en lugar de hacerlo de una sola vez cerca del final, cuando el cambiar algo se ha vuelto costoso. Para proporcionar un proceso de desarrollo a travs del cual el personal puede trabajar de manera ms eficaz.

Requerimientos Los requerimientos para un producto o sistema de software determinan lo que har el sistema y definen las restricciones de su operacin o implantacin. Los requerimientos se pueden dividir en dos: Funcionales: Son declaraciones de los servicios que el sistema debe proveer o de cmo se debe llevar a cabo el procesamiento. No Funcionales: Son restricciones de los servicios o funciones ofrecidas por el sistema. Las restricciones son tecnologa a aplicar, tiempo de respuesta, adopcin de estndares. Capacidad, es decir, no se refiere directamente a las funciones especificas del sistema. Los requerimientos de manera tpica son dados por el usuario, y son conocidos como los requerimientos del usuario. Normalmente especifican el comportamiento externo del sistema y evitan las caractersticas de diseo del sistema. Se redactan utilizando el lenguaje natural, tablas y diagramas con el fin de que sean comprensibles. Cuando los requerimientos del usuario son detallados se conocen como requerimientos del sistema. Se enuncian de una manera precisa y libre de interpretaciones incorrectas. Se redacta en un lenguaje estructurado, o de programacin de alto nivel o uno especial para especificar requerimientos. El documento de requerimientos de software son la declaracin acordada de los requerimientos de los sistemas. Se estructuran de tal forma que puedan ser utilizados tanto por los clientes del sistema como por los desarrolladores del software. El administrar los requerimientos, saber identificar entre funcionales y no funcionales, entender los requerimientos de usuario y detallarlos para obtener requerimientos del sistema se identifica como el proceso de la ingeniera de requerimientos. Dicho proceso es parte del Proceso Unificado de Desarrollo de Software y consiste en capturar los requisitos como casos de uso.

Artefactos. Los artefactos son las entradas y salidas del Proceso Unificado de Desarrollo de Software (PUDS). Para el caso de la captura de requisitos, los artefactos fundamentales son el modelo de casos de uso, que incluye los casos de uso y los actores y opcionalmente los prototipos de interfaz de usuario. Documentacin de los requerimientos El documento de requerimientos expresa de manera informal los alcances del sistema. Un documento de requerimientos plasma el modelo del dominio o del negocio. Un modelo del dominio captura los tipos de entidades MAS importantes en el contexto del problema a resolver. Una manera ms completa de indicar los requerimientos es el modelo del negocio. Permite entender los procesos del negocio de la organizacin que requiere el sistema. (Esta manera es aplicable para sistemas de informacin, para otro tipo de sistemas se tiene que encontrar otra manera de modelar) El objetivo de dichos modelos es dejar en una manera clara los procesos que tiene la organizacin y as integrar a los desarrolladores a la problemtica a resolver, aunque ellos no sean expertos en el negocio, pueden entender su comportamiento Modelos de caso de uso El modelo de caso de uso plasma el acuerdo entre clientes y desarrolladores, y es un modelo del sistema desde la perspectiva de la manera como se utiliza el sistema por los usuarios. En un modelo de caso de uso se incluyen los casos de uso y actores, adems de sus relaciones. En UML queda representado como un paquete que se compone de un sistema de caso de uso, que a su vez agrega a un conjunto de actores y casos de uso.

Actor El modelo de caso de uso describe lo que hace el sistema por cada tipo de usuario. Cada usuario se representa por uno o ms actores. Los actores representan terceros que interactan con el sistema. Un actor es un tipo de usuario, y la instancia de ese tipo, el usuario real. En UML se representa de la siguiente manera: Caso de uso Con un actor es posible identificar las entidades externas al sistema. Para definir las funcionalidades internas al sistema se especifican casos de uso. Un caso de uso es una manera especfica de utilizar al sistema mediante la ejecucin de una funcionalidad del mismo De manera ms precisa, un caso de uso especifica una secuencia de acciones que el sistema puede llevar a cabo interactuando con sus actores, incluyendo alternativas dentro de la secuencia Un caso de uso es una especificacin, que indica el comportamiento de "cosas" dinmicas o instancias de los casos de uso. En UML se representa como: Cuando el sistema obedece un caso de uso est creando una instancia del mismo. Un caso de uso tiene un flujo de sucesos, que es una descripcin textual de la secuencia de acciones del caso de uso. En dicha descripcin se incluyen los actores y su relacin con los casos de uso. Si se desea incluir requisitos no funcionales, se puede indicar en una descripcin textual que agrupe este tipo de requisitos

Prototipo de interfaz de usuario Se puede desarrollar un sistema inicial que permita aterrizar los conceptos expuestos en los casos de uso y glosario. Tpicamente el prototipo es una interfaz visual o de comandos que permite expresar los flujos bsicos para lograr que el sistema implante su funcionalidad En UML se representa como un icono de clase estereotipada, en este caso, con estereotipo de entidad Arquitectura desde la perspectiva de casos de uso Tambin conocida como la vista del modelo de casos de uso. La Arquitectura debe incluir los casos de uso describan una funcionalidad importante y crtica o requisitos importantes que deben desarrollarse de manera inmediata en el ciclo de vida. Funciones del analista de sistemas, especificador de caso de uso, diseador de interfaces de usuarios y prototipos, Arquitecto.

En una fase de PUDS existen trabajadores, que son los roles que toman las personas en el proceso El analista del sistema es el responsable del conjunto de requisitos que estn modelados en los casos de uso, incluyendo requisitos funcionales y no funcionales. Esto implica que l es el gua para ver como atacar los requerimientos, pero sin llegar al detalle. El especificador de casos de uso dan la descripcin detallada de los casos de uso, incluyendo los flujos de sucesos. Diseador de interfaz de usuario dan forma visual a las interfaces grficas, y luego entonces auxilian en el desarrollo del prototipo de interfaces de usuario. El arquitecto del sistema ayuda a identificar la vista del modelo de casos de uso. En el siguiente diagrama se muestra la relacin entre los artefactos y los trabajadores: