EL PROCESO UNIFICADO

lvaro Yuste Torregrosa Carlos Sanchs Server Carlos Meca Lpez Javier Snchez Riquelme Universidad de Alicante Ingeniera Multimedia

El Proceso Unificado
0. Introduccin:
El Proceso Unificado del Software o UP es un conjunto de metodologas de desarrollo de software caracterizado por su flexibilidad, es decir, que no cuenta con pasos establecidos y por tanto es capaz de especializarse segn el problema que deseemos resolver, de ah su popularidad. Los orgenes del Proceso Unificado se remontan a 1988, cuando la empresa Objectory AB desarrolla un software como herramienta de diseo orientado a objetos. Objectory AB es comprada en 1995 por Rational Software, evolucionando dicho software y popularizndolo. Esta herramienta proporciona el lenguaje de trabajo en equipo, y mezclado con un lenguaje donde los procesos de desarrollo son el ncleo de la evolucin del desarrollo de los productos, forman el Proceso Unificado.

A da de hoy el UP es la metodologa ms utilizada para el desarrollo de software, y tambin en la que ms variaciones o refinamientos podemos encontrar en funcin de las necesidades del producto, siendo el Proceso Unificado Racional el ms conocido.

1. Caractersticas del Proceso Unificado:

Una de las caractersticas ms importantes del proceso unificado es el llamado desarrollo iterativo o incremental. Se basa en dividir el proyecto en varias repeticiones homlogas en las fases, para conseguir un avance progresivo y escalonado que mejorar y avanzar el producto en cada interaccin. Es evidente que si a la hora de desarrollar un producto nicamente necesitamos la definicin de una solo iteracin, podremos concentrar nuestros esfuerzos y simplificar de manera significativa la planificacin y el seguimiento de las tareas a realizar. Como veremos posteriormente, el proceso unificado se compone de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin, y es dentro de cada una de estas donde se realizan las dichas insistencias (aunque la de inicio nicamente se itera en procesos considerablemente grandes o de una profundidad especial). En todo caso, cada iteracin se lleva a cabo en un periodo de tiempo limitado normalmente comprendido entre dos y seis semanas, para conservar la agilidad y frescura en el avance.

A su vez, cada uno de los incremento dentro de las fases posee sus propias disciplinas, que tambin analizaremos en profundidad ms adelante, y que son el Anlisis de requisitos, el Diseo, la Implementacin y a Prueba; las cuales van representando un mayor o menor peso respecto del resto segn avanza el proyecto recorriendo las diferentes etapas de su elaboracin. As, para desarrollar el producto de una iteracin se elige un subconjunto de los requisitos globales, se disean, implementan, y prueban. Todo ello para originar un resultado susceptible a ser integrado y ejecutado con calidad de producto final, y que se proporcionar al cliente como muestra del trabajo realizado hasta el momento. Independientemente, el verdadero potencial de este tipo de desarrollo reside en la posibilidad de ofrecer de manera peridica al cliente una muestra del producto, una aplicacin con prestaciones parciales, que se completarn con nuevas funcionalidades en sucesivas fases. El cliente puede ver pasos del desarrollo, con algunos tributos limitados, mientras se desarrollan las otras. As en este tipo de progreso se llevan a cabo dos sistemas que funcionan en paralelo: oSistema Operacional: Ya en posesin y uso del cliente. Es la implementacin parcial que se entrega como muestra, en una fase intermedia del desarrollo global, para que el demandante del software se haga una idea de cual est siendo el avance llevado a cabo por el desarrollador. Puede basarse en una mejora o modificacin de versiones anteriores, o una nueva versin con partes de las versiones antiguas. oSistema en Desarrollo: El producto que se est desarrollando con el fin de mejorar el sistema operacional, y suministrrselo al cliente para sustituir a este en la futura iteracin del desarrollo. Es sobre el que verdaderamente se trabaja y se aplican las disciplinas nombradas, dado que, como hemos dicho, el otro sistema ya se encuentra en manos del cliente.

Otra de las ventajas que ofrece el desarrollo iterativo es la fcil retroalimentacin (ya que como hemos visto, el subproyecto de una etapa se nutre la mayora de veces del resultado des subproyecto anterior). A su vez tambin garantiza una correcta asimilacin de cambio ya que las modificaciones o retrasos pueden tratarse en la

siguiente iteracin a la actual, sin provocar cambios en la fecha de entrega del producto y agilizando el proceso. En el supuesto de que el progreso fuera secuencial, podra ser desastroso tener que modificar el plan en mitad del desarrollo. Para monitorizar los requisitos funcionales de la programacin del software y describir el contenido y el conunto de tareas de cada iteracin, se utilizan los casos de uso, de manera que cada incremento toma un conjunto de ellos. As, la definicin de un caso de uso se puede perfilar, en el contexto de la ingeniera software, como una secuencia de interacciones entre las personas o entidades y el sistema en el que participan, como respuesta a un conjunto de eventos. Son muy tiles en el caso de software desarrollado con programacin orientada a objetos, que es dode se originaron. Adems se suelen representar en diagramas deonde se describe la comunicacin entre los consumidores y el producto. Con ellos, en la extraccin de requerimientos, se consigue centrar el anlisis en las necesidades del usuario y dejar de guiar la evolucin de este en los requisitos tecnolgicos.

2. Fases del Proceso Unificado:

Un proyecto basado en UP tiene 4 fases (inicio, elaboracin, construccin, transicin) que iteran sobre 5 flujos de trabajo y en las que se distribuyen todo el proceso de desarrollo del sistema desde que se acuerda el proyecto hasta que se entrega: - Requisitos: Encontrar cual es la siguiente accin que el sistema debe implementar. - Anlisis: Conseguir un conocimiento ms preciso acerca de los requisitos del sistema. - Diseo: Comprender los requisitos no funcionales y adaptar los requisitos funcionales para que puedan ser implementados. - Implementacin: Se implementan las clases y se realizan pruebas individuales a cada una para lograr una mayor eficiencia y eficacia. Se distribuyen las funciones asignndolas a nodos. - Prueba: Se crean y ejecutan pruebas que permitan mostrar debilidades y errores en el sistema. Adems, despus de cada etapa debern de actualizarse documentos y realizar un anlisis sobre los costes, esfuerzos y beneficios de la siguiente etapa adems de analizar el trabajo de la etapa anterior, adems de seleccionar de las personas del equipo primordial a los ms capacitados para desarrollar las actividades de la actual fase. Las fases del Proceso Unificado son las siguientes:

Inicio: En este momento se produce la comunicacin con el cliente y se dejan claras

las necesidades de este, junto a los compromisos del negocio y los acuerdos tanto econmicos como de fechas.

Se buscan soluciones al problema y se crea una idea de los requisitos tendr el producto.-Se establecer de manera bsica cul ser el esfuerzo requerido para realizar el proyecto. Llevar a cabo un subproceso de planificacin que se encargue de asimilar informacin y buscar a la gente que est capacitada para llevar a cabo el proyecto y encontrar algn hueco que rellenar en caso de ser necesario. Deben de revisarse los equipos y el software para observar si cumple los requisitos necesarios adems de fuentes de informacin variadas sobre el contexto en el que se encontrar el sistema. Obtener software de ventas, programacin o que complete las necesidades de otras reas de la empresa. Analizar el contexto en el que se ejecutar la aplicacin basndose en la arquitectura de los equipos que la ejecutarn y sus recursos. Esbozar una serie de bocetos de diseo para el proyecto, junto con esquemas de como irn las cosas.

Tras analizar el proyecto se crear una lista de riegos crticos y no,

comprendiendo los niveles de prioridad, en caso de no hacerse seguramente los riesgos aparecern antes o despus y es una manera de solventarlos de manera ms eficaz.

Los riesgos pueden estar relacionados con varios factores y hay que tenerlos

en cuenta todos: arquitectura, tecnologa usada, requisitos del sistema y otros requisitos no funcionales como la seguridad de los datos o la fiabilidad. En caso de solicitarse incluir un pequeo proyecto que dar lugar a un prototipo que ayudar a la empresa a mostrar al cliente que el sistema podr suplir sus necesidades.

Elaboracin:
En esta fase el ncleo del sistema se desarrolla de manera iterativa. Comenzando con cada problema a resolver. Se establecen las medidas de calidad y los factores que intervienen: tiempos de ejecucin, seguridad, fiabilidad Se crea un informe sobre los datos detallados de las arquitecturas sobre las que

ejecutar y del sistema final. Se desarrollan prototipos de las interfaces del sistema. Se estructuran los modelos de los casos de uso de la aplicacin. Hay que realizar un anlisis de la arquitectura candidata, los recursos compartidos y de las clases, los mdulos y los paquetes del sistema. Implementar la mayor parte de los nodos y mdulos del sistema. La mayora de los requerimientos son identificados y, en su medida, solucionados. Los problemas que hayan ido apareciendo debern de redirigirse y se resolverse en orden de prioridad con respecto a la funcionalidad. En esta fase normalmente se realiza la mayor parte del esfuerzo. Se realizan unas nuevas estimaciones ms ajustadas junto al establecimiento de nuevos requisitos.

Construccin:
Se desarrollan el resto de elementos de menor urgencia, riesgo y necesidad del sistema. Se realiza un equilibrio de costes de desarrollo intentando dejarlo todo abierto y no cerrado para que en caso de error no hay que repetir todo el trabajo de una parte. Alcanzar niveles de calidad y versiones medianamente tiles y estables del sistema (alpha, beta) de manera rpida y eficaz. Conseguir unas condiciones de aceptacin buenas. En esta fase se crean los manuales de usuario, la descripcin de la versin actual y se evalan los posibles riesgos para el software y los usuarios.

Transicin: Beta-testing con ayuda de los usuarios. (se prueba la aplicacin en busca de posibles errores a la hora del uso). Se comprueba el nivel de autosuficiencia que alcanzan los usuarios a la hora de usar la aplicacin. Debe de realizarse una versin final del sistema de la manera ms econmica y fiable posible, atendiendo a toda la informacin adquirida en las fases anteriores y en las pruebas con los usuarios, solucionando las dificultades presentadas.

Comprobar que el producto cumple las especificaciones establecidas en la fase de inicio y que no presenta errores en su uso, en caso contrario nueva iteracin. Estimar si el consumo por parte de la aplicacin es el esperado. Despliegue del producto (entrega, instalacin y configuracin de este).

3. Disciplinas del Proceso Unificado:

Las disciplinas son un conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un rea especfica dentro del proyecto total. Se llevan a cabo en cada iteracin, pero no se tienen porque realizar todas en una misma iteracin. Por ejemplo, en esta imagen se van realizando todas conforme se suceden las iteraciones (adems en este diagrama se observa el trabajo dedicado a cada disciplina en cada iteracin) Las ms importantes son: Requisitos: Flujo de trabajo fundamental cuyo propsito es orientar al desarrollador hacia el sistema correcto. Esto se lleva a cabo mediante la descripcin de los requisitos del sistema de forma tal que se pueda llegar a un acuerdo entre el cliente (incluyendo los usuarios) y los desarrolladores del sistema, acerca de lo que el sistema debe hacer y lo que no.

Anlisis: Flujo de trabajo fundamental cuyo propsito principal es analizar los requisitos descritos en la captura de requisitos, mediante su refinamiento y estructuracin. El objetivo de esto es: Entender de una manera mas precisa de los requisitos Obtener una descripcin de los requisitos que sea fcil de mantener y que nos ayude a dar estructura al sistema en su conjunto incluyendo su arquitectura. Diseo: Flujo de trabajo fundamental cuyo propsito principal es la de formular modelos que se centran en los requisitos no funcionales y el dominio de la solucin y que prepara para la implementacin y pruebas del sistema. Implementacin: Flujo de trabajo fundamental cuyo propsito esencial es implementar el sistema en trminos de componentes, es decir cdigo fuente guiones, ficheros binarios, ejecutables, etc. Prueba: Flujo de trabajo fundamental cuyo propsito esencial es comprobar el resultado de la implementacin mediante las pruebas de cada construccin, incluyendo tanto construcciones internas como intermedias, as como las versiones finales del sistema que van a ser entregadas a terceras personas. Conclusin: Las disciplinas de manera reducida son: un conjunto de actividades relacionadas con un rea especifica, que todas ellas tienen en comn, dentro de un proyecto. Las disciplinas mas importantes se pueden resumir de la siguiente manera: Capturar, definir y validar los casos de uso (Requisitos) Realizar los casos de uso (Anlisis, diseo e implementacin) Verificar que se satisfacen los casos de uso (Pruebas)

4. Artefactos del Proceso Unificado

En el Proceso Unificado, un artefacto es tanto un producto final como intermedio que es producido, modificado o usado por un proceso durante el proyecto. Los artefactos se usan para captar y transportar informacin del proyecto. Son, bsicamente, los elementos que se van obteniendo y usando hasta obtener el producto final. Los distintos tipos de artefactos son los documentos, las bases de datos (u otras fuentes de informacin tabulada), los cdigos fuente y ejecutables, el modelo y el elemento modelo. Estos dos ltimos tienen una serie de informacin que puede ser extrada llamada informe, que representa un artefacto o una serie de artefactos, que a su vez tienen guas que los describen con detalle. Los artefactos se organizan en secciones segn sus disciplinas. En caso de que un artefacto tenga ms de una ser asignado a la misma que lo produjo en un principio. Los artefactos del Proceso Unificado y su relacin entre ellos.

Pasamos a enumerar y explicar los grupos de artefactos: Modelo Empresarial, que engloba a los artefactos que toman y presentan el contexto empresarial del sistema. Son la entrada y referencia para los requerimientos del sistema. Requerimientos, toma y presenta la informacin usada en la definicin de las capacidades requeridas del sistema. Anlisis y Diseo, que contienen informacin relacionada con la solucin a los problemas indicados en el conjunto de Requerimientos. Implementacin son aquellos que desarrollan la solucin proporcionada por la categora de Anlisis y Diseo. Pruebas, los que evalan los resultados de las actividades anteriores. Artefactos de Despliegue son los relacionados con la captura y presentacin de la informacin relacionada con la transicin del sistema presentada en el grupo de Implementacin dentro del entorno de produccin. Gestin de Proyecto es el grupo toma los artefactos asociados al proyecto y la planificacin y ejecucin del proceso.

Gestin de Configuracin y Cambios se encarga de tomar y presentar informacin relacionada con la disciplina de configuracin y cambios del proyecto. Grupo Ambiental de Artefactos presenta los artefactos que se utilizan como direccin en el desarrollo del sistema para asegurar el estado coherente de todos los artefactos.

Normalmente los artefactos no son documentos de texto, a diferencia de muchos de los procesos donde la documentacin suele ser incluso en papel. Obsrvese que artefacto es el trmino usado en el RUP para describir lo que denotan otros procesos usando trminos tales como producto del trabajo, unidad de trabajo, y as sucesivamente. En RUP, los productos a entregar se consideran solamente ser el subconjunto de todos los artefactos que terminen para arriba la entrega en las manos de los clientes y de los usuarios finales, generalmente como parte de una entrega.

5. Especializaciones del Proceso Unificado:

RUP (Rational Unified Process) : Es el proceso unificado que utiliza la corporacin Rational Software, una divisin de IBM originada en 2003. Realmente es lo mismo que el proceso unificado comn (UP) la nica diferencia es el nombre que es distinto para no violar los derechos de Rational Software. AUP (Agile Unified Process): Basndose en tcnicas an vlidas en RUP el AUP responde a una versin simplificada de este. Describe un enfoque de desarrollo de software ms simple y fcil de entender que en el RUP. Su base se centra en desarrollar cada iteracin del ciclo del proceso de desarrollo originando un software estable entregable, que ser entregado a los clientes para obtener su opinin y el cual se someter a otro ciclo de la iteracin y as hasta que el proyecto est acabado. Al usar menos tiempo en la fase de anlisis y establecimiento de los requisitos lo que se hace es aprovechar ese tiempo en otras fases como la construccin, traslacin y sus pruebas. Est pensado para equipos pequeos de unos 10 desarrolladores, ya que se demuestra que a ms gente en el equipo ms parece fallar este procedimiento.

Open UP (Open Unified Process): Es un Framework de procesos de desarrollo de software de cdigo abierto. Se basa en el RUP creado por IBM, pero no coincide en todos los puntos. Est pensado para pequeos equipos de desarrollo que valoran los beneficios de la colaboracin y de los involucrados con el resultado del proyecto que prefieren olvidarse de formalidades innecesarias. Provee de un simple conjunto de contenidos, fundamentalmente relacionados con orientacin, puestos de trabajo, roles y tareas. Que simplifican el reparto de los esfuerzos. El Open UP se basa en cuatro principios interrelacionados: - Colaboracin para unificar intereses y compartir conocimientos. - Equilibrio de prioridades competentes con el fin de maximizar el valor de los involucrados con el desarrollo del proyecto. - Enfoque de la articulacin de la arquitectura. - Desarrollo continuo para obtener realimentacin y, de esta manera, realizar las mejoras necesarias. Al articular la arquitectura se produce una mejora de la colaboracin tcnica, reducir el riesgo y minimizar los sobresfuerzos durante el desarrollo. OpenUP desarrolla un ciclo de vida interactivo que reduce el riesgo a tiempo y permite mostrar resultados al cliente durante el curso del proyecto. Forma parte del Eclipse Process Framework desarrollado por Eclipse Foundation. Su forma ms simple y ligera es el Open UP/Basic tambin llamado Basic Unified Process o BUP donado por IBM.

EssUP (Essential Unified Process): Creado por Ivar Jacobson Solutions es una coleccin de practicas que juntas forman un conocimiento esencial del ciclo de vida del proceso de desarrollo de software. Integra satisfactoriamente principios del proceso unificado, gil y campos de madurez de procesos, aprovechando sus diferentes propiedades y capacidades como la estructura, la agilidad y la mejora de los procesos. Se basa en diferencias los problemas de manera ms simple haciendo ms fcil la tarea de repartir y adaptar el proyecto ajustndolo a las prioridades temporales y a las necesidades de la empresa. Segn el experto de desarrollo gil de software Dave Thomas EssUP provee de una nueva forma de aproximarse a la mejora del desarrollo de software. Es mucho ms simple y mucho ms flexible y extensible que las anteriores definiciones del UP. Se presenta como ligero y amigable hacindose fcil de aprender. Segn fuentes varias parece ser que IBM, Microsoft Visual y Eclipse lo aceptarn.

6. Bibliografa:
http://www.utim.edu.mx/~pmendoza/ftp/rup.pdf http://en.wikipedia.org/wiki/Unified_Process http://iie.fing.edu.uy/ense/asign/desasoft/Teorico2/ProcesoUnificado.pdf http://es.wikipedia.org/wiki/Proceso_Unificado http://www.rodolfoquispe.org/blog/que-es-el-proceso-unificado-de-desarrollo-desoftware.php http://www.slideshare.net/Sofylutqm/el-proceso-unificado-3943047 http://audiemangt.blogspot.com/2010/05/metodologia-agil-proceso-unificado-de.html http://www.ambysoft.com/unifiedprocess/agileUP.html http://www.info-ab.uclm.es/asignaturas/42541/pdf/m1tema4.pdf http://ccollins.wordpress.com/2008/06/11/unified-process-vs-agile-processes/ http://cbasqa.wordpress.com/2008/09/02/proceso-de-desarrollo-openu https://sites.google.com/site/ingsoportelogico/home/essential-unified-process-essup http://students.mimuw.edu.pl/~zbyszek/posi/ibm/RUP_Eval/manuals/intro/kc_artifact.htm