proceso unificado

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Proceso Unificado

AESM

Componentes del grupo (mircoles de 17:00 a 19:00): Laura Sirvent Collado Rmulo Espinosa Montoya Dulce Isis Segarra Lpez Contacto: Blog de grupo: http://waphilim.blogspot.com/p/contacto.html Page | 0



ndiceProceso Unificado (definicin) ------------------------------------------------------------Pgina 2 Caractersticas -------------------------------------------------------------------------------Pginas 2-5 Iterativo e incremental Dirigido en casos de uso Centrado en la arquitectura Elementos del proceso ---------------------------------------------------------------------Pgina 6 Fases Hitos Disciplinas Artefactos Fases del proceso ---------------------------------------------------------------------------Pginas 8-9 Inicio Elaboracin Construccin Transicin Disciplinas ------------------------------------------------------------------------------------Pgina 10 Modelado del negocio Requerimientos Anlisis Diseo Implementacin Pruebas Despliegue Artefactos ------------------------------------------------------------------------------------Pginas 11-12 Fase de inicio o de requisitos Fase de elaboracin Fase de implementacin Fase de transicin Refinamientos y variantes del UP---------------------------------------------------------Pginas 13-16 RUP (Proceso Unificado de Rational) AUP (Proceso Unificado gil) OpenUP EUP (Enterprise Unified Process) Otros refinamientos (EssUP, BUP, OUM) Herramientas para aplicar UP -------------------------------------------------------------------Pginas 17-18 MSF (Microsoft Solutions Framework) EPF (Eclipse Process Framework) Rational Software Bibliografa -----------------------------------------------------------------------------------Pgina 19

Page | 1



Proceso UnificadoEl Proceso Unificado de desarrollo de software es un marco de desarrollo de software caracterizado principalmente por estar centrado en la arquitectura, estar dirigido por casos de uso, ser iterativo e incremental y afrontar en primer lugar los riesgos ms significativos del diseo del sistema.

Caractersticas del Proceso Unificado (UP)Iterativo e incremental Se trata de un marco de desarrollo iterativo e incremental, compuesto por 4 fases: Inicio Elaboracin Construccin Transicin

A su vez, cada fase est dividida en iteraciones o mini proyectos que, como resultado, producen incrementos del producto o dicho de otro modo, resultados. Adems, en cada iteracin, mediante un conjunto reducido de requerimientos, se disea, implementa y se prueba una versin reducida del proyecto pero que es funcional y por lo tanto puede ser probado, integrado y ejecutado. Por ltimo, cada iteracin se divide en una serie de disciplinas. Dicho de otro modo, el proyecto se va dividiendo en proyectos ms reducidos que van siendo abordados y en los cuales se obtienen unos resultados que ayudarn en iteraciones y fases posteriores.

Page | 2



Beneficios de este enfoque: Como se van creando mini proyectos, es ms sencillo soportar los posibles costes derivados de los mismos. Gracias a que en primer lugar se atiende a los riesgos ms importantes, se reduce el riesgo del proyecto en general y, por lo tanto, es ms factible el cumplir los plazos establecidos. Los mini proyectos son proyectos ms asequibles de cumplir a corto plazo con lo que los trabajadores se sentirn mejor al poder alcanzar los objetivos y al ver una parte del proyecto funcionando. Permite obtener una visin de los requisitos globales del proyecto y poco a poco ir depurndolo, esto es muy importante porque realmente es difcil conocer todos los requisitos al principio del desarrollo del sistema. Permite al usuario ver un sistema completo a partir de una fase temprana del desarrollo, al cual poco a poco se le irn aadiendo funcionalidades y puliendo los posibles errores. Gracias a esto podemos obtener una retroalimentacin del cliente desde el principio y reducir as los riesgos debidos a malos entendidos con el cliente. Gracias al reducido tamao del problema y los requisitos que se abordan en cada iteracin, se consigue que la retroalimentacin sea rpida y los cambios que se realicen sean asimilados rpidamente. Es posible que las diferentes tareas o requisitos seleccionados para resolver no hayan podido abordarse o solucionarse en el plazo previsto para ello, en ese caso, este modelo nos posibilita el transferir dichas tareas o requisitos a una iteracin posterior y as poder entregar la iteracin en la fecha de entrega prevista. En este modelo se abordan, solucionan y prueban, en primer lugar, las decisiones de diseo ms crticas y que tengan un alto riesgo de poner en peligro el desarrollo del sistema, de esta forma se evitar tener que abordar decisiones de diseo crticas en fases avanzadas del desarrollo del sistema donde un cambio crtico supondra un volumen de trabajo considerable.

Dirigido en casos de uso Los casos de uso son escenarios donde se producen ciertas situaciones. Gracias al estudio de estos casos de uso se pueden establecer los requisitos funcionales y el contenido de cada iteracin o mini proyecto. Por lo tanto, cada iteracin tomar un conjunto de casos de uso o escenarios que deber atender ya que sern los que determinen la funcionalidad del sistema.Page | 3



Centrado en la arquitectura En el Proceso Unificado se emplean diferentes modelos o vistas para describir el sistema que se quiere desarrollar y no slo un punto de vista, a este conjunto de vistas o modelos se les denomina arquitectura del sistema. La arquitectura se establece mediante iteraciones donde cada una produce un resultado que forma parte de la arquitectura. Adems, la arquitectura est muy relacionada con los casos de uso ya que son tenidos en cuenta a la hora de desarrollar la misma. Tambin cabe destacar que, a la hora de desarrollar la arquitectura del sistema, se tienen en cuenta los aspectos ms significativos del mismo, tanto estticos como dinmicos. Las vistas que se tienen en cuenta a la hora de desarrollar la arquitectura son las siguientes: Vista del modelo de casos de uso Vista del modelo de anlisis Vista del modelo de diseo Vista del modelo de despliegue Vista del modelo de implementacin

Pero, por qu es tan importante definir la arquitectura? Es importante definir la arquitectura porque nos ayuda a: Entender cmo debe ser el sistema Estructurar y organizar el desarrollo del sistema Fomentar la reutilizacin Facilitar la evolucin del sistema

Page | 4



Page | 5



Elementos del procesoHay una serie de elementos asociados al Proceso Unificado (UP): Fases: el Proceso Unificado se divide en 4 fases: 1. Inicio: principalmente se estudia la viabilidad del proyecto, para ello se estudian las tareas que lleva a cabo la empresa o cliente que solicita el proyecto, se obtiene una base aproximada de lo que se pretende con el proyecto y se estiman posibles plazos y costos. 2. Elaboracin: se obtiene una visin ms concreta del proyecto, se realizan iteraciones de la parte ms interna y central del sistema, se resuelven en primer lugar aquellas tareas o requisitos que conlleven riesgos ms elevados, se identifican los posibles requerimientos que se deseen aadir y se especifican de una forma ms concreta los plazos y costos. 3. Construccin: se realizan las iteraciones de los requisitos restantes, es decir, los ms sencillos y de menor riesgo. Se prepara adems el sistema para su entrega, instalacin y configuracin. 4. Transicin: durante esta fase se realizan pruebas sobre el sistema, centrndose el personal en corregir posibles errores y en aumentar las funcionalidades del sistema desarrollado en una fase anterior. Finalmente el usuario dar el visto bueno al sistema. Hitos: cada una de las fases anteriormente expuestas finaliza con algo denominado hito. Un hito viene definido por un conjunto de documentos o artefactos que permiten a los encargados de dirigir un proyecto que puedan saber si se est realizando el trabajo de forma adecuada y en la direccin adecuada. Los hitos adems de tener objetivos como el expuesto anteriormente, tienen un objetivo crtico que es hacer que los encargados de dirigir el proyecto tomen decisiones antes de pasar a la siguiente fase del proyecto. Disciplinas: las disciplinas son un conjunto de actividades relacionadas entre s que se llevan a cabo en un rea concreta del proyecto. Por ejemplo, al comienzo de una iteracin se pueden desarrollar estas disciplinas. Adems, cada disciplina est vinculada con un conjunto de modelos y, a su vez, los modelos se componen de artefactos.

Page | 6



Las disciplinas y los artefactos relacionados con ellas son las siguientes:Disciplinas Artefactos Modelado del negocio Modelo del dominio Requerimientos Modelo de casos de uso Visin y anlisis del Negocio Especificacin Complementaria Glosario Anlisis Modelo de anlisis Diseo Modelo de Diseo Documento de arquitectura Modelo de datos Implementacin Modelo de implementacin Pruebas Modelo de pruebas Despliegue Marco de desarrollo

En cualquier caso, para cada proyecto se debern usar aquellos artefactos que sean necesarios y tiles, no es necesario emplear todos los existentes. Adems, el nmero de artefactos que deben emplearse debe ser el necesario y suficiente ya que se podra desperdiciar mucho tiempo en su creacin cuando podra resultar que algunos de ellos aportan informacin redundante o innecesaria. Artefactos: los artefactos son un conjunto de elementos que son producidos en cada actividad, dichos artefactos son tiles para poder clarificar el desarrollo del proyecto y ayudan en las diferentes actividades, fases e iteraciones posteriores. Estos artefactos pueden ser documentos, diagramas u otros elementos. Cabe destacar que cada trabajador es propietario y responsable de un artefacto, siendo esto importante ya que el resto de trabajadores harn uso del mismo para continuar el desarrollo del proyecto o sistema.

Page | 7



Fases del proceso

Fase de inicio En esta fase se establece una vista general sobre el sistema que nos ofrece el cliente. En la vista general se determinan los puntos ms importantes del sistema, sus posibles soluciones y, a su vez, los costes y riesgos que puede conllevar. En concreto, el objetivo es conocer realmente que desea llevar a cabo el cliente. A partir de esta vista general se ha de determinar si el sistema es viable. En caso de que el sistema sea viable, se continuar el sistema y se realizar una investigacin ms profunda sobre el sistema en la siguiente fase, la fase de elaboracin. El tiempo transcurrido en la fase de inicio depende de las caractersticas del sistema, si se trata de un sistema conocido, el tiempo, en el que se determina si es viable o no, ser menor. En caso de desconocer totalmente el sistema, el tiempo ser mayor, ya que habr que analizarlo con ms detenimiento. En posteriores iteraciones, el tiempo de desarrollo de la fase de inicio ser menor, ya que se tendr un mayor conocimiento sobre el sistema, pudiendo explorar otras soluciones mejores que las rechazas en anteriores iteraciones.

Fase de elaboracin En esta fase se profundiza ms en el sistema requerido. La fase de elaboracin se centra en el diseo del ncleo del sistema, es decir, su arquitectura. Se debe establecer la interfaz (tanto interna como externa) del sistema y qu funciones y procesos va a contener la arquitectura del sistema, adems de los analizados en la fase inicial. Tambin se han de establecer los recursos necesarios para el desarrollo de los elementos anteriormente mencionados. Esta fase requiere ms tiempo de desarrollo que la fase de inicio debido a que se ha de analizar ms profundamente cada una de las funcionalidades del sistema, la calidad del mismo y el coste de desarrollo, adems de analizar y solucionar posibles riesgos. En posteriores iteraciones, el tiempo de desarrollo de la fase de elaboracin ser menor, ya que el sistema ir cumpliendo los factores de calidad (correcto, fiable, robusto) e implementando las funcionalidades que ha de incorporar.

Page | 8



Fase de construccin En esta fase se crea el producto, obteniendo al final el producto, el cual tendr las funcionalidades ya previstas en anteriores fases y las restantes, surgidas en esta fase. Despus de la creacin del producto habr que encargarse de probar el producto para corregir posibles errores. Dichas pruebas se realizarn, primero, en cada uno de los componentes del sistema por separado, y despus, en todo el sistema como un nico componente. En esta fase tenemos que en cada iteracin obtendremos una versin ejecutable del sistema en desarrollo cada vez ms completa.

Fase de transicin Durante esta fase se realiza la versin beta del producto. Se le irn aadiendo caractersticas y funcionalidades al producto mientras que el usuario puede probar la versin beta del producto. Tambin se realizarn correcciones en los elementos que los usuarios (que prueban la versin beta) nos indiquen. Cuando el producto se haya finalizado, la versin beta de los usuarios ser intercambiada por la versin final. Para esta fase habr tantas iteraciones como caractersticas se le aadan al producto.

Aqu podemos ver un esquema sobre las fases del proceso unificado.

Page | 9



Disciplinas Modelado del negocio: se trata de establecer una buena comunicacin entre los ingenieros del negocio y los ingenieros del software, donde los ingenieros del software deben conocer la problemtica actual y sus mejoras.

Requerimientos: la disciplina de requerimientos se desarrolla dentro de cada iteracin de una fase. Esta disciplina se basa en establecer los requerimientos que ha de tener el sistema. Anlisis: en esta disciplina se analiza cmo tiene que funcionar el sistema para despus poder implementarlo. Se describe qu acciones realiza cada uno de los componentes del sistema. Diseo: en esta disciplina se realiza un diseo en donde se plasme el funcionamiento del sistema, analizado en la disciplina de anlisis. El diseo se basa en la descomposicin del sistema, teniendo as el diseo de los subsistemas. Implementacin: esta disciplina se basa en la creacin del sistema final, donde se realizarn una serie de pruebas, al igual que en la siguiente disciplina. Prueba: se prueba el funcionamiento de cada uno de los componentes del sistema por separado y de todos ellos en conjunto como un nico sistema comprobando la correcta interaccin entre cada uno de los componentes.Despliegue: se trata del proceso en el que el producto se introduce ya en el mercado y en la sociedad.

Page | 10



ArtefactosUn artefacto es un documento, informe, modelo, diagrama u otro producto que se necesita al inicio (artefactos de entrada) de cada disciplina y/o a la finalizacin de la misma (artefactos de salida), dentro del desarrollo y produccin de software utilizando el proceso unificado. Los artefactos que van obtenindose pueden ser a su vez artefactos de entrada en las siguientes disciplinas del desarrollo, dado el carcter reutilizable de los mismos, o utilizarse como referencia a lo largo de todo el proyecto, o entregables al final del proyecto. Por otra parte, una disciplina puede producir no solo uno, sino varios artefactos de salida, e igualmente, necesitar uno o varios artefactos de entrada provenientes de fases anteriores. Algunos de los artefactos ms comunes son los modelos de casos de uso, modelo de negocio o de dominio, prototipos de la interfaz de usuario, diagramas de clases, adems de otros artefactos. Podemos clasificar los artefactos que en general se necesitan y se producen para cada una de las cuatro fases o incrementos que normalmente componen el proceso unificado (inicio, elaboracin, construccin y transicin). Aunque hay que destacar que, dependiendo del carcter del proyecto, no siempre son necesarios o no necesitan un gran nivel de profundidad todos los artefactos que pueden darse en el proceso unificado. Estos son los artefactos para cada fase del proceso: Fase de inicio o de requisitos: Los artefactos que describen qu tiene que hacer el sistema, conteniendo la informacin relativa a los requerimientos necesarios, de forma explcita y detallada, se conocen como Conjunto de Requisitos. Los artefactos de salida que van obtenindose en cada actividad de esta fase son: Modelo de casos de uso y casos de uso detallados, que adems se utilizan como artefactos de entrada en siguientes iteraciones de la fase, adems de planes para la siguiente fase (Elaboracin), que estimarn la duracin y cantidad de trabajo de la misma, llamados plan de fase, plan de elaboracin y plan de iteracin, que define la primera iteracin de la fase de elaboracin. Los artefactos de entrada que pueden necesitarse para esta fase son: Modelo de negocio, lista de caractersticas, requisitos adicionales, glosario. Fase de elaboracin: Estos artefactos dan informacin de cmo va a construirse el sistema, as como los factores que puedan variar el desarrollo del proyecto, como podra ser el presupuesto o el tiempo disponible. Se conocen como Conjunto de Diseo.

Page | 11



En esta fase finalmente lo que se obtiene es el modelo de diseo (el diseo lgico, sin implementar), el modelo de dominio y los requisitos totalmente refinados al acabar la fase, refina la arquitectura, que es la relacin que guardan los componentes que forman el sistema con los requisitos, as como el modelo de datos, de implementacin, de riesgos y de pruebas. Se obtiene adems la planificacin para el resto de fases que quedan por cumplir. Por ltimo, tambin se empiezan a obtener prototipos de interfaz de usuario y de navegacin. Fase de implementacin: En esta fase los artefactos que se van a obtener son documentos que podran servir como entregables o como una primera versin del sistema implementado. Se producen todos los artefactos ejecutables en una primera versin, o versin beta, preparada para pasar pruebas, y unos primeros manuales de usuario y otros manuales, como las instrucciones de cmo ensamblar el sistema o descripciones sobre su configuracin. Por otra parte, se van a refinar los documentos de la arquitectura del sistema, la lista de riesgos, y la planificacin para el resto del recorrido del proceso unificado. A este conjunto de artefactos se le conoce como Conjunto de Implementacin. Fase de transicin: Por ltimo, en esta fase lo que va a obtenerse es ya una versin final de todos los artefactos entregables, es decir, tanto los ejecutables del sistema creado, como los manuales completos sobre su funcionamiento, adems de un refinamiento del modelo de implementacin y del plan de desarrollo.

Page | 12



Refinamientos y variantes del UPExisten algunas variantes del proceso unificado, cuyas diferencias las encontramos en cmo se categorizan las disciplinas que forman el proceso, y el nmero que son. Adems de estas variaciones, otras diferencias residen en el nmero de artefactos que se producen en cada fase del proceso, aunque hay que comentar que en la realidad, el proceso unificado y sus variantes no se siguen al pie de la letra, creando la empresa u organizacin desarrolladora sus propias variaciones, en funcin del carcter del proyecto que se est realizando. Podemos destacar algunas variantes y refinamientos del proceso unificado: RUP (Proceso Unificado de Rational) El proceso unificado de Rational es un refinamiento del UP propuesto por IBM y cuya primera versin fue lanzada al mercado en el ao 1998. Comparte la metodologa del UP, es decir, es igualmente dirigido por casos de usos, centrado en la arquitectura, iterativo e incremental. Su plan de desarrollo tiene las mismas cuatro fases, pero destacamos ciertas diferencias con el UP: El RUP define nueve disciplinas en el marco de desarrollo, a diferencia del UP, en el que son siete disciplinas. Estas nueve disciplinas son: Modelado de negocio, requisitos, anlisis y diseo, implementacin, pruebas, despliegue, que forman los flujos de trabajo del proceso, siendo las disciplinas restantes: Gestin del cambio y configuraciones, gestin del proyecto y entorno, que forman los flujos de trabajo de soporte. Adems de esto, se reduce el nmero de artefactos que se producen, otra diferencia notable con el UP.

Page | 13



AUP (Proceso Unificado gil) El proceso unificado gil es una versin simplificada del RUP, que mezcla este sistema con tcnicas giles. Se consigue una simplificacin de flujo de trabajo y de cantidad de artefactos en comparacin con el RUP, adems de un menor nmero de disciplinas, siete, que en algunas ocasiones son mezcla de dos o ms disciplinas en RUP. Las disciplinas con las que cuenta AUP son: Modelo, implementacin, prueba, despliegue, gestin de configuracin, gestin del proyecto y ambiente.

Los principios sobre los que se asientan las bases del proceso unificado gil son: Simplicidad, por medio de documentos cortos, de pocas pginas y concisos. Agilidad, ya que se ajusta a los principios de la Agile Alliance. Adaptable a las necesidades del proyecto. Independiente de las herramientas que se usen para su gestin.

OpenUP OpenUP es un refinamiento del proceso unificado formulado a partir de este y del RUP, conservando sus caractersticas esenciales, es decir, dirigido por casos de uso, iterativo e incremental y centrado en la arquitectura. Fue propuesto por empresas de tecnologa y donado a la Fundacin Eclipse, quien lo mantiene bajo una licencia libre. El ciclo de vida de OpenUP est formado por siete disciplinas: Gestin del Proyecto, requisitos, diseo, implementacin, prueba, despliegue y configuracin y gestin de cambios. Podemos decir que las caractersticas de OpenUP son: Mnimo, en el sentido en que slo el contenido esencial y fundamental es incluido. Completo, refirindose a que con todo el proceso puede construirse el sistema sin ms. Extensible, en el sentido en el que el contenido del proceso puede ser extendido o adaptado segn las caractersticas y necesidades del proyecto.

Page | 14



EUP (Enterprise Unified Process) Es un refinamiento de RUP, diseado por Scott Ambler, y que adems de las cuatro fases comunes a todos los refinamientos de UP, en EUP encontramos dos fases ms adicionales: produccin, que define la parte del ciclo de vida una vez el sistema ha salido al mercado, y retirada, la parte en el ciclo de vida en el que el sistema es retirado del mercado.

Page | 15



Otros refinamientos (EssUP, BUP, OUM) Existen adems otros refinamientos que tambin son utilizados por las empresas, adems de los explicados anteriormente. Por ejemplo, el Proceso Unificado Esencial (EssUP), creado por Ivar Jacobson como una mejora del proceso unificado de Rational, siendo ms ligero y gil que su predecesor. Por otra parte, el Proceso Unificado Bsico, BUP, optimizado a partir del RUP para proyectos pequeos, manteniendo los principios esenciales de RUP, eliminando las partes opcionales y unificando algunos de sus elementos, teniendo como resultado un proceso mucho ms simple pero atendiendo a los mismos principios. Por ltimo, el Mtodo Unificado de Oracle (OUM, Oracle Unified Method), creado por Oracle a partir del Proceso Unificado.

Page | 16



Herramientas para aplicar UPMSF (Microsoft Solutions Framework)

Se trata de un software que nos proporciona las herramientas para que una organizacin pueda estructurar los recursos, el personal y las tcnicas necesarias para cumplir los objetivos de la organizacin y proporcionar una infraestructura tecnolgica segura. MSF considera que hay cuatro perspectivas de arquitectura: Arquitectura de Negocios: describe el funcionamiento del negocio y las tecnologas para ello. Arquitectura de Aplicacin: en base a un modelo de aplicacin de toda la empresa se podrn desarrollar y disear sistemas de negocio. Arquitectura de Informacin: define la documentacin necesaria para el buen funcionamiento del negocio y a quin est dirigida dicha informacin. Arquitectura Tecnolgica: se define cmo obtener y utilizar cada una de las herramientas o tecnologas necesarias para el funcionamiento del negocio.

Beneficios: Asegura que la solucin al negocio sea realmente la que el usuario desea. Proporciona informacin sobre qu elementos van con el cliente y cuales con el servidor. Permite reutilizar los elementos creados en el desarrollo de anteriores negocios. Permite saber en cada momento en qu punto del desarrollo del negocio se encuentra el usuario, teniendo siempre bien definidos las tareas y objetivos cumplidos.

Page | 17



EPF (Eclipse Process Framework)

EPF se trata de un framework que nos provee de herramientas, modelos y contenido para aplicar gran variedad de procesos. Uno de los procesos que nos permite aplicar es el proceso unificado UP y una de las variantes del proceso unificado OpenUP. EPF se basa en varios principios: El framework puede contener subframeworks. Permite una rpida conexin entre un conjunto de procesos. Los elementos se mantienen unidos sin el framework.

Beneficios: Contiene un gran nmero de extensiones (plug-ins): aade procesos y mtodos de contenido adicionales. Contiene contenido estndar: principios, roles, tareas, productos de trabajo, etc.

Rational Software

Conjunto de software de IBM centrado en la aplicacin del Proceso Racional Unificado. Uno de los software que proporciona IBM es Rational Application Developer (RAD). RAD nos permite un diseo visual, construccin, pruebas de servicios web, portales y aplicaciones. Beneficios: Instalacin flexible. Ofrece trucos para el desarrollo de esquemas comunes. Ofrece tutoriales sobre cmo funciona el entorno de desarrollo. Proporciona una gua de cmo instalar e iniciarte en RAD. Contiene un asistente de contenido. Ofrece herramientas para la depuracin y la prueba del cdigo

Page | 18



BibliografaProceso unificado (definicin, caractersticas, disciplinas, artefactos) Proceso Unificado Proceso Unificado (UP) Proceso Unificado de desarrollo de software Disciplinas Refinamientos del UP AUP EUP Resumen de algunos modelos RUP Herramientas para UP y sus variantes MSF EPF Rational Software Rational Application Developer RAP

Page | 19

proceso unificado

Documents