Proceso Unificado de desarrollo de software (UP)

#AESMultimedia - aesmultimedia.blogspot.comJose Lus Contreras Martnez Ana Garca Domene Daniel Martnez Espadas Begoa Morillas Guijarro @DkLawis @agado92 @danielme91 @begomori

ndice Caractersticas del proceso Elementos del proceso Fases del proceso Disciplinas Artefactos

- Bibliografa

#AESMultimedia

2

El Proceso Unificado es un marco de desarrollo de software iterativo e incremental: conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema software. Est compuesto por cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. En el siguiente trabajo vamos a explicar en detalle cada uno de los apartados que componen un Proceso Unificado de desarrollo de software y todos los elementos que participan en l.

Caractersticas del procesoEnfoque Iterativo e Incremental El Proceso Unificado tiene un desarrollo iterativo e incremental, lo que significa que se organiza mediante una serie de miniproyectos de entre 2-6 semanas de duracin (iteraciones) que se agrupan en un total de 4 fases: Inicio, Elaboracin, Construccin y Transicin; que se comentarn ms tarde. Estas iteraciones tienen como resultado una mejora del producto (incremento). Para realizar este incremento en cada iteracin se realiza un anlisis de requisitos, diseo, implementacin y prueba, con lo que el resultado de cada iteracin puede ser probado, integrado y ejecutado. Si la iteracin cumple sus objetivos, se contina con la prxima. Si no deben revisarse las decisiones previas y probar un nuevo enfoque. Los desarrolladores basan la seleccin de lo que implementarn en cada iteracin en dos cosas: el conjunto de casos de uso que amplan la funcionalidad y en los riesgos ms importantes que deben mitigarse. Los beneficios del enfoque iterativo son: Al llevar un control de cada iteracin se reduce el riesgo a los costes de un solo incremento. Reduce el riesgo de retrasos permitiendo a los desarrolladores atacar los riesgos ms importantes primero. Acelera el desarrollo. Los trabajadores trabajan de manera ms eficiente al obtener resultados a corto plazo. Tiene un enfoque ms realista al reconocer que los requisitos no pueden definirse completamente al principio.

Centrado en la arquitectura En un Proceso Unificado no existe un slo modelo vlido para resolver las necesidades y requerimientos de un sistema. Existen mltiples modelos y posibilidades para definir la arquitectura software, depender del arquitecto que se encargue de dicha tarea elegir uno u otro de entre los dems posibles analizando los requerimientos, plataforma donde debe funcionar el software o necesidades. Podemos tomar como ejemplo lo que se hace en la construccin de edificios: un arquitecto de la construccin puede visualizar cul ser el resultado final del edificio a partir de los planos que incluyen todas las partes que lo componen tanto interna como externamente. En un Proceso Unificado debemos hacer lo mismo, hacer una vista completa de las caractersticas ms importantes, para que incluso antes de empezar podamos visualizar

#AESMultimedia

3

cul ser el producto software final. La arquitectura debe ser comprensible, tener capacidad de adaptacin al cambio y poder ser reutilizable. Dirigido por los casos de uso En el Proceso Unificado se utilizan los casos de uso, estos son una secuencia de interacciones que se desarrollarn entre un sistema y sus actores (personajes o entidades que participarn en un caso de uso) en respuesta a un evento que inicia un actor principal sobre el propio sistema. Dicho de otra forma, los casos de uso son una serie de pruebas que se crean durante el anlisis de requisitos. Para posteriormente realizarse durante el anlisis y diseo, y la implementacin. Que sirven para verificar que se satisfacen los casos de uso en el momento final de pruebas. Enfocado en los riesgos Debido al funcionamiento del Proceso Unificado es necesaria una vigilancia especial de los riesgos que puede presentar el proyecto desde el primer momento. Por ello, para los resultados de cada iteracin se definen estrategias y planes de contingencia que permiten identificar y anticipar los riesgos desde los inicios del ciclo de vida. Poniendo mayor atencin en los puntos crticos de la fase de elaboracin. Inicialmente se debe describir una lista de riesgos de diseo, tcnicos, de negocio o de recursos y abordar los ms graves del proyecto, y que por lo tanto tendran mayor repercusin en el resultado final, mediante un plan de gestin de riesgo que incluye planes de contingencia, anticipacin y correccin de dificultades. Tras esto, se realizan pruebas del material que se haya producido con el fin de reducir y eliminar riesgos. Posteriormente se sigue un estructura de implementacin iterativa con los riesgos de la lista con un nivel de riesgo menor a los tratados. Tambin se prestar atencin a elementos ms sencillos.

#AESMultimedia

4

Elementos del procesoEl Proceso Unificado se repite a lo largo de una serie de ciclos que constituye la vida del sistema. Cada ciclo esta constituido por cuatro fases: Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases se divide en iteraciones que desarrollan una secuencia de disciplinas o flujos de trabajo. Estas disciplinas son un conjunto de actividades relacionadas que se vinculan a un rea especfica: Requerimientos, Anlisis, Diseo, Codificacin y Prueba. Tras cada fase se obtiene un hito. Los hitos son conjuntos de objetivos que se pretenden alcanzar para tener una base a partir de la cual desarrollar la siguiente fase. Durante todo el proceso se crean como resultado de cada fase unos artefactos.

#AESMultimedia

5

Fases del procesoA continuacin se presenta a modo de resumen las cuatro fases principales que compone un proceso unificado, para as consultar de manera rpida y breve en qu consiste cada fase. 1. Inicio: es la primera fase donde se establecen los objetivos principales, qu es lo que el cliente desea, estimaciones aproximadas de los plazos y los costos. Es viable el proyecto? 2. Elaboracin: se ajusta mejor las estimaciones de la primera fase y se resuelven los riesgos ms altos, se implementa de forma iterativa el ncleo central del software, identificando nuevos requisitos y objetivos. 3. Construccin: se implementa iterativamente el resto de elementos ms sencillos, se resuelven los requisitos de menor riesgo. Se prepara la entrega, instalacin y configuracin del software. 4. Transicin: se trata de la fase de pruebas, correccin de bugs y puesta en escena del software en la empresa cliente.

Imagen 1 - Las estrellas entre cada fase marcan los Hitos

Ahora vamos a profundizar en cada fase:

InicioEs la fase ms breve, as que el tiempo para invertir en ella tambin lo es (una nica iteracin). Se deben desarrollar las principales funciones del software, seleccionar unas arquitecturas candidatas, identificar posibles riesgos y establecer los costos temporales y econmicos a los que nos debemos enfrentar.

#AESMultimedia

6

El objetivo es obtener una visin preliminar del proyecto y as decidir los verdaderos objetivos que se deben alcanzar. Puede darse el caso que la mayora del material realizado en esta fase se descarte o que slo se utilice una pequea parte en el proyecto final, pero lo que s ser seguro es que servir para incrementar el conocimiento del equipo encargado de realizar el software. As que podemos decir que es una fase que puede compararse con un boceto o borrador donde se exponen unas ideas y se descartan otras. Esta fase finaliza con el Hito Objetivo del Ciclo de Vida, que se llega a ella cuando se alcanza un acuerdo sobre el conjunto de necesidades a cubrir y las posibles soluciones a stas; una planificacin preliminar de las iteraciones; y la arquitectura preliminar escogida.

ElaboracinEl objetivo principal de esta fase son la resolucin de los riesgos crticos, establecer y validar el ncleo central de la arquitectura, y definir la mayora de requisitos y recursos necesarios. Se pueden descubrir nuevos requerimientos y necesidades, que se incluirn a los ya detectados en la anterior fase. Se van eliminando o reduciendo la lista de riesgos (probando soluciones). Lo ms importante de esta fase es que se construye el ncleo central de la arquitectura del sistema, que incluye los componentes principales del mismo. Se debe demostrar que este ncleo de la arquitectura satisface las necesidades clave, cumpliendo requisitos mnimos y aceptables en cuanto a rendimiento, escalabilidad y coste. Al final de esta fase se elabora un plan detallado para las siguientes iteraciones y etapas. La fase de elaboracin finaliza con el Hito Arquitectura del Ciclo de Vida, que se alcanza cuando se llega a un acuerdo sobre todo lo anterior comentado.

ConstruccinEs la fase ms larga y donde se gastan la mayora de recursos. La arquitectura, que se empez a construir en la anterior fase, se completa para construir un sistema bien cimentado y en base a lo especificado en la fase de elaboracin. Las caractersticas y funciones del sistema se implementan a travs de una serie de iteraciones cortas y determinadas en el tiempo. El resultado se convierte en un software funcional, estable y preparado para los usuarios finales. La fase de construccin finaliza con el Hito de Capacidad Operativa Inicial.

TransicinEn esta fase el software se encuentra en fase beta, aunque ya instalado en los equipos de un grupo reducido de usuarios finales. Gracias a la retroalimentacin que se recibe por

#AESMultimedia

7

parte de stos, se detectan defectos y deficiencias, y se incorporan mejoras al software para dejarlo todava ms estable y robusto en las sucesivas iteraciones. Esto tambin sirve para que los usuarios se familiaricen con el producto y sea tambin una fase de aprendizaje y de toma de contacto con el software para ellos. En esta fase tambin tienen lugar actividades como la venta, formacin de los usuarios, establecer un servicio de ayuda en lnea y correccin de bugs tras el lanzamiento del producto, que se pueden dejar para una futura versin del software. En definitiva, tras la implementacin en la empresa no se acaba el trabajo, si no que hay que seguir el rastro del producto para que el cliente est contento con el software por el que ha pagado. La fase de transicin termina con el Hito de Lanzamiento del Producto.

#AESMultimedia

8

DisciplinasUna disciplina es la instruccin sistemtica dada a discpulos para capacitarlos o para seguir un determinado cdigo de conducta u "orden". El proceso unitario se compone de diversas disciplinas. Estas son: modelado del negocio, requisitos, anlisis y diseo, implementacin, prueba, despliegue, gestin de configuraciones y cambios, gestin del proyecto y entorno.

Imagen 2 - Ejemplo de tabla de disciplinas con la carga de trabajo

El modelado del negocio tiene como objetivo establecer un canal de comunicacin entre los ingenieros del negocio y los ingenieros del software. Estos ltimos, deben conocer la estructura y dinmica de la organizacin objetivo (el cliente), los problemas actuales y sus posibles mejoras. Todo esto se plasma en la identificacin del modelo del dominio en el que se visualizan los aspectos bsicos del dominio de aplicacin. Los requisitos consisten en describir qu es lo que debe hacer el sistema y poner a los desarrolladores y al cliente de acuerdo en esta descripcin. Tanto el anlisis como el diseo, describen como el software ser realizado en la fase siguiente de implementacin. Para ello se plasma en un modelo de diseo que consiste en una serie de clases (agrupadas en paquetes y subsistemas) con interfaces bien definidas. La implementacin se basa en programar las clases y objetos en trminos de componentes, creando los ficheros fuente y binarios, y compilndolos y enlazndolos para originar los ejecutables.

#AESMultimedia

9

La disciplina de prueba lo que hace es comprobar que el funcionamiento es correcto analizando diversos aspectos: los objetos como unidades, la integracin entre objetos, la implementacin de todos los requisitos, etc. El despliegue crea la versin externa del producto, empaquetndose, distribuyndose e instalndose en el lugar de trabajo. Dndose tambin ayuda a los usuarios mediante manuales y asistentes. La gestin de configuraciones y cambios gestiona aspectos como los sistemas de control de versiones. Controla las peticiones de cambios clasificndolas segn su estado (nueva, registrada, aprobada, asignada, completa, etc.). Almacenan los datos en una base de datos para poder posteriormente obtener informes peridicos. Para todo esto, se utilizan herramientas como Rational ClearQuest o Bugzilla, estas hacen un seguimiento de errores basado en actividad de cambios y defectos. La gestin del proyecto se encargada de definir los planes del proyecto global, los planes de fase y los planes de iteracin. Y por ltimo el entorno se centra en las actividades necesarias para configurar el proceso de un proyecto. Tiene como objetivo proveer a la organizacin de desarrollo software de un entorno de trabajo (que incluye procedimientos y herramientas) que soporten al equipo de desarrollo.

#AESMultimedia

10

ArtefactosEl trmino artefacto es una forma general para referirse a los productos de trabajo. Estos elementos, fruto de los procesos realizados, pueden ser tanto documentos de texto como fragmentos de cdigo en lenguaje de programacin, diagramas, esquemas de base de datos o cualquier otro material utilizado en cualquier actividad. En las distintas actividades que forman el desarrollo del proyecto encontramos artefactos de entrada y de salida. Al ser algunos artefactos de salida artefactos de entrada de otras actividades diferentes a la de origen, se crea un flujo de informacin que permite el avance del proyecto.

Imagen 3 - Ejemplo de flujo de artefactos en la fase de diseo de un proyecto.

Cada artefacto es responsabilidad de un trabajador, es el propietario, sin embargo, otros trabajadores lo podrn usar para sus tareas si lo tienen asignado y si es necesario podrn modificar dicho artefacto. Con el fin de regular la creacin y uso de los artefactos por los diferentes trabajadores, el Proceso Unificado utiliza un lenguaje estndar para visualizar, especificar, documentar y construir los artefactos llamado Lenguaje Unificado de modelado (UML). Este lenguaje se ayuda de esquemas o diagramas estandarizados para posibilitar a los desarrolladores la visualizacin del artefacto obtenido por su trabajo.

#AESMultimedia

11

Imagen 4 - Ejemplo de diagrama de flujo sintetizado de un proyecto.

#AESMultimedia

12

Bibliografa: Los siguientes enlaces y bibliografas se han usado en los puntos que se indican del trabajo: Caractersticas del proceso: Wikipedia - Proceso Unificado Presentacin sobre el Proceso Unificado Justificacin del uso de UP Eduardo Mosqueira Rey - El Proceso Unificado de Desarrollo de Software Instituto de ingeniera elctrica - Trabajo sobre UP Elementos del proceso: A.U.S. Gustavo Torossi - El Proceso Unificado de Desarrollo de Software Fases del proceso: El proceso unificado de desarrollo de software (presentacin) Presentacin sobre el Proceso Unificado La Imagen 1 insertada en el trabajo tambin se ha sacado de este enlace. Eduardo Mosqueira Rey - El Proceso Unificado de Desarrollo de Software Instituto de ingeniera elctrica - Trabajo sobre UP Disciplinas: Eduardo Mosqueira Rey - El Proceso Unificado de Desarrollo de Software Imagen 2 explicativa de las disciplinas del proceso unificado Para la descripcin de Bugzilla y Rational ClearQuest se han ledo las primeras lneas. Artefactos: Eduardo Mosqueira Rey - El Proceso Unificado de Desarrollo de Software A.U.S. Gustavo Torossi - El Proceso Unificado de Desarrollo de Software Tambin fuente de las imagenes 3 y 4 Instituto de ingeniera elctrica - Trabajo sobre UP Computacin e informtica - Qu es el proceso unificado de software

#AESMultimedia

13