EL PROCESO UNIFICADO
· Álvaro Ál varo Yuste Yuste Torregrosa · · Carlos Sanchís Server · · Carlos Meca López · · Javier Sánchez Riquelme · Universidad de Alicante – Ingeniería Multimedia
El Proceso Unificado 0. Introducción: Introducción: El Proceso Unificado del Software o UP es un conjunto de metodologías de desarrollo de software caracterizado por su flexibilidad, fl exibilidad, es decir, que no cuenta con pasos establecidos y por tanto es capaz de especializarse según el problema que deseemos resolver, resolver, de ahí su popularidad. Los orígenes del Proceso Unificado se remontan a 1988, cuando la empresa Objectory AB desarrolla un software como herramienta de diseño orientado a objetos. Objectory AB es comprada en 1995 por Rational Software, evolucionando dicho software y popularizándolo. Esta herramienta proporciona el lenguaje de trabajo en equipo, y mezclado con un lenguaje donde los procesos de desarrollo son el núcleo de la evolución del desarrollo de los productos, forman el Proceso Unificado.
A día de hoy el UP es la metodología más utilizada para el desarrollo de software, y también en la que más variaciones o refinamientos podemos encontrar en función de las necesidades del producto, siendo el Proceso Unificado Racional el más conocido.
1. Características del Proceso Unificado: Una de las características más importantes del proceso unificado es el llamado desarrollo desarrollo iterativo iterativo o incr increm emen enta tal. l. Se basa basa en divi dividi dirr el proy proyec ecto to en vari varias as repet repeticio iciones nes homólo homólogas gas en las fases, fases, para para conseg consegui uirr un avance avance progre progresiv sivo o y escalonado que mejorará y avanzará el producto en cada interacción. Es evidente que si a la hora de desarrollar un producto únicamente necesitamos la definición de una solo iteración, podremos concentrar nuestros esfuerzos y simplificar de manera significativa la planificación y el seguimiento de las tareas a realizar. Como veremos posteriormente, el proceso unificado se compone de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición, Transición, 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 todo caso caso,, cada cada itera iteraci ción ón se llev lleva a a cabo cabo en un peri period odo o de tiem tiempo po limi limita tado do 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, disciplinas, que también analizaremos en profundidad más adelante, y que son el Análisis de requisitos, el Diseño, la Implementación y a Prueba; las cuales van representando un mayor o menor peso respecto del resto según avanza el proyecto recorriendo las diferentes etapas de su elaboración. Así, para desarrollar el producto de una iteración se elige un subconjunto de los requisitos globales, se diseñan, implem implemen entan tan,, y prueba prueban. n. Todo ello ello para para origin originar ar un result resultado ado suscep susceptib tible le 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 periódica al cliente una “muestra” del producto, una apli aplic caci ación con pres restaci tacion ones es parc arciale iales s, que que se com completa letará rán n con con nuev uevas 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: Sistema Operacional: Ya en posesión y uso del cliente. Es la implementación 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 mejora o modificac modificación ión de versiones versiones anteriores, anteriores, o una nueva versión con partes partes de las versiones antiguas.
o
Sistema Sistema en Desarrollo: Desarrollo: El prod produc ucto to que que se está está desa desarro rrolla lland ndo o con con el fin fin de mejorar el sistema operacional, y suministrárselo al cliente para sustituir a este en la futura iteración 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.
o
Otra de las ventajas que ofrece el desarrollo iterativo es la fácil retroalimentación (ya que como hemos visto, el subproyecto de una etapa se nutre la mayoría de veces del resultado des subproyecto anterior). A su vez también garantiza una correcta asimilación de cambio ya que las modificaciones o retrasos pueden tratarse en la
siguiente iteración a la actual, sin provocar cambios en la fecha de entrega del prod produc ucto to y agil agiliz izan ando do el proc proces eso. o. En el supu supues esto to de que que el prog progre res so fuer fuera a secuencial, podría ser desastroso tener que modificar el plan en mitad del desarrollo. Para Para monit monitori orizar zar los requis requisito itos s funcio funciona nales les de la progra programa mació ción n del softwa software re y describir el contenido y el conunto de tareas de cada iteración, se utilizan los casos de uso, de manera que cada incremento toma un conjunto de ellos. Así, la definición de un caso de uso se puede perfilar, en el contexto de la ingeniería 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 programación orientada a objetos, que es dode se origin originaro aron. n. Ademá Además s se suelen suelen repres represent entar ar en diagra diagramas mas deond deonde e se describ describe e la comunicación entre los consumidores y el producto. Con ellos, en la extracción de requerimientos, se consigue centrar el análisis en las necesidades del usuario y dejar de guiar la evolución de este en los requisitos tecnológicos.
2. Fases del Proceso Unificado: Un proy proyec ecto to basa basado do en UP tien tiene e 4 fase fases s (inic (inicio io,, elab elabor orac ació ión, n, cons constr truc ucci ción ón,, transición) 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 acción que el sistema debe implementar. - Análisis: Conseguir un conocimiento más preciso acerca de los requisitos del sistema. - Diseño: Comprender los requisitos no funcionales y adaptar los requisitos funcionales para que puedan ser implementados. - Implementación: Se implementan las clases y se realizan pruebas individuales a cada una para lograr una mayor eficiencia y eficacia. Se distribuyen las funciones asignándolas a nodos. - Prueba: Se crean y ejecutan pruebas que permitan mostrar debilidades y errores en el sistema. Además, después de cada etapa deberán de actualizarse documentos y realizar un análisis sobre los costes, esfuerzos y beneficios de la siguiente etapa además de analizar el trabajo de la etapa anterior, además de seleccionar de las personas del equipo equipo primordial primordial a los más capacitad capacitados os para desarrollar desarrollar las actividad actividades es de la actual fase. Las fases del Proceso Unificado son las siguientes:
Inicio: •
•
•
•
•
•
•
•
•
•
En este momento se produce la comunicación con el cliente y se dejan claras las necesidades de este, junto a los compromisos del negocio y los acuerdos tanto económicos como de fechas. Se buscan soluciones al problema y se crea una idea de los requisitos tendrá el producto.producto.-Se Se establece establecerá rá de manera manera básica básica cuál cuál será el esfuerzo esfuerzo requerido para realizar el proyecto. Llevar a cabo un subproceso de planificación que se encargue de asimilar información y buscar a la gente que está capacitada para llevar a cabo el proyecto y encontrar algún hueco que rellenar en caso de ser necesario. Deben de revisarse los equipos y el software para observar si cumple los requis requisito itos s necesa necesario rios s ademá además s de fuente fuentes s de informa informació ción n variad variadas as sobre sobre el contexto en el que se encontrará el sistema. Obtener software de ventas, programación o que complete las necesidades de otras áreas de la empresa. Analiz Analizar ar el contex contexto to en el que que se ejecut ejecutará ará la aplica aplicació ción n basán basándo dose se en la arquitectura de los equipos que la ejecutarán y sus recursos. Esbozar una serie de bocetos de diseño para el proyecto, junto con esquemas de como irán las cosas. Tras ras anal analiz izar ar el proy proyec ecto to se crea creará rá una una list lista a de rieg riegos os crít crític icos os y no, no, comprendiendo los niveles de prioridad, en caso de no hacerse seguramente los riesgos aparecerán antes o después y es una manera de solventarlos de manera más eficaz. Los riesgos pueden estar relacionados con varios factores y hay que tenerlos en cuenta todos: arquitectura, tecnología usada, requisitos del sistema y otros requisitos no funcionales como la seguridad de los datos o la fiabilidad. En caso caso de soli solici cita tarse rse incl inclui uirá rá un pequ pequeñ eño o proy proyec ecto to que que dará dará luga lugarr a un prototipo que ayudará a la empresa a mostrar al cliente que el sistema podrá suplir sus necesidades.
Elaboración: •
•
•
En esta esta fase fase el núcl núcleo eo del del sist sistem ema a se desa desarr rrol olla la de mane manera ra iter itera ativa tiva.. Comenzando con cada problema a resolver. Se establecen las medidas de calidad y los factores que intervienen: tiempos de ejecución, seguridad, fiabilidad… Se crea un informe sobre los l os 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 aplicación.
•
•
•
•
•
•
Hay Hay que que real realiz izar ar un anál anális isis is de la arqu arquite itect ctur ura a cand candid idat ata, a, los los recu recurs rsos os compartidos y de las clases, los módulos y los paquetes del sistema. Implementar la mayor parte de los nodos y módulos del sistema. La mayor ayoría ía de los los requ requer erim imie ient ntos os son son iden identi tifi fica cado dos s y, en su medid edida, a, solucionados. Los Los prob proble lema mas s que que haya hayan n ido ido apar aparec ecie iend ndo o debe deberá rán n de redi redirig rigirs irse e 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 más ajustadas junto al establecimiento de nuevos requisitos.
Construcción: •
•
•
•
•
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 rápida y eficaz. Conseguir unas condiciones de aceptación buenas. En esta fase se crean los manuales de usuario, la descripción de la versión actual y se evalúan los posibles riesgos para el software y los usuarios.
Transición: •
•
•
Beta-testing con ayuda de los usuarios. (se prueba la aplicación en busca de posibles errores a la hora del uso). Se comprueba el nivel de autosuficiencia que alcanzan los usuarios a la hora de de usar la aplicación. Debe de realizarse una versión final del sistema de la manera más económica y fiable posible, atendiendo a toda la información 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 iteración.
•
Estimar si el consumo por parte de la aplicación es el esperado.
•
Despliegue del producto (entrega, instalación y configuración de este).
3. Disciplinas del Proceso Unificado: Las disciplinas disciplinas son un conjunto conjunto de actividade actividades s relacionad relacionadas as (flujos (flujos de trabajo) trabajo) vinculadas a un área específica dentro del proyecto total. Se llevan a cabo en cada iteración, pero no se tienen porque realizar todas en una misma iteración. Por ejempl ejemplo, o, en esta esta imagen imagen se van realiz realizand ando o todas todas confor conforme me se sucede suceden n las iteraciones (además en este diagrama se observa el trabajo dedicado a cada disciplina en cada iteración) Las más importantes son: Requisitos: Fluj Flujo o de trab trabaj ajo o fund fundam amen enta tall cuyo cuyo prop propós ósit ito o es orie orient ntar ar al desa desarro rroll llad ador or haci hacia a el sistem sistema a corr correc ecto to.. Esto Esto se llev lleva a a cabo cabo medi median ante te la descripción 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.
Análisis: Flujo de trabajo trabajo fundament fundamental al cuyo propósito propósito principal principal es analizar analizar los requis requisito itos s descrit descritos os en la captura captura de requisi requisitos tos,, median mediante te su refina refinamie miento nto y estructuración. El objetivo de esto es: Entender de una manera mas precisa de los requisitos r equisitos Obtener una descripción de los requisitos que sea fácil de mantener y que nos nos ayud ayude e a dar dar estr estruc uctu tura ra al sist sistem ema a en su conj conjun unto to incl incluy uyen endo do su arquitectura. • •
Diseño: Flujo de trabajo fundamental cuyo propósito principal es la de formular modelos que se centran en los requisitos no funcionales y el dominio de la solución y que prepara para la implementación y pruebas del sistema. Implementación: Fluj Flujo o de trab trabaj ajo o funda fundame ment ntal al cuyo cuyo prop propós ósito ito esen esenci cial al es implem implemen entar tar el sistem sistema a en términ términos os de compo componen nentes tes,, es decir decir código código fuente fuente guiones, ficheros binarios, ejecutables, etc. Prueba: Flujo de trabajo fundamental cuyo propósito esencial es comprobar el resulta resultado do de la implem implement entaci ación ón media mediante nte las prueb pruebas as de cada cada constr construcc ucción ión,, incluyendo tanto construcciones internas como intermedias, así como las versiones finales del sistema que van a ser entregadas a terceras personas. Conclusión: Las disciplinas de manera reducida son: un conjunto de actividades relacionadas con un área especifica, que todas ellas tienen en común, dentro de un proyecto. Las disciplinas mas importantes se pueden resumir de la siguiente manera: • • •
Capturar, Capturar, definir y validar los casos de uso (Requisitos) Realizar los casos de uso (Análisis, diseño e implementación) 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 artefa artefacto ctos s se usan usan para para captar captar y transp transporta ortarr inform informaci ación ón del del proye proyecto cto.. Son, Son, básicamente, 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 información tabulada), los códigos fuente y ejecutables, el modelo y el elemento modelo. Estos dos últimos tienen una serie de información que puede ser extraída llamada informe, que representa un artefacto o una serie de artefactos, que a su vez tienen guías que los describen con detalle. Los artefactos se organizan en secciones según sus disciplinas. En caso de que un artefacto tenga más de una será asignado a la misma que lo produjo en un principio. Los artefactos del Proceso Unificado y su relación r elación entre ellos.
Pasamos a enumerar y explicar los grupos de artefactos: •
•
•
•
•
•
•
Modelo Empresarial, Empresarial, que engloba a los artefactos que toman y presentan el cont contex exto to empr empres esar aria iall del del sist sistem ema. a. Son Son la entr entrad ada a y refe refere renc ncia ia para para los los requerimientos del sistema. Requerimientos, Requerimientos, toma y presenta la información usada en la definición de las capacidades requeridas del sistema. Análisis y Diseño, Diseño , que contienen información relacionada con la solución a los problemas indicados en el conjunto de Requerimientos. Implementación son aquellos que desarrollan la solución proporcionada por la categoría de Análisis y Diseño. Pruebas, Pruebas, los que evalúan los resultados de las actividades anteriores. Artefactos de Despliegue son los relacionados con la captura y presentación de la información relacionada con la transición del sistema presentada en el grupo de Implementación dentro del entorno de producción. Gestión de Proyecto es el grupo toma los artefactos asociados al proyecto y la planificación y ejecución del proceso.
•
•
Gestió Gestión n de Confi Configur guraci ación ón y Cambio Cambios s se enca encarg rga a de toma tomarr y pres presen enta tar r inform informaci ación ón relaci relaciona onada da con la discip disciplin lina a de config configura uració ción n y cambio cambios s del proyecto. Grupo Ambiental de Artefactos presenta los artefactos que se utilizan como dirección 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 documentación suele ser incluso en papel. Obsérvese Obsérvese que “artefacto” “artefacto” es el término usado en el RUP para describir describir lo que denotan otros procesos usando términos 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 corporación Rational Software, una división de IBM originada en 2003. Realmente es lo mismo que el proceso unificado común (UP) la única diferencia es el nombre que es distinto para no violar los derechos de Rational Software. AUP (Agile Unified Process): Basándose en técnicas aún válidas en RUP el AUP responde a una versión simplificada de este. Describe un enfoque de desarrollo de software más simple y fácil de entender que en el RUP. Su base se centra en desarrollar cada iteración del ciclo del proceso de desarrollo originando un software estable entregable, que será entregado a los clientes para obtener su opinión y el cual se someterá a otro ciclo de la iteración y así hasta que el proyecto esté acabado. Al usar menos tiempo en la fase de análisis y establecimiento de los requisitos lo que se hace es aprovechar ese tiempo en otras fases como la construcción, traslación y sus pruebas. Está pensado para equipos pequeños de unos 10 desarrolladores, ya que se demuestra que a más gente en el equipo más parece fallar este procedimiento.
Open UP (Open Unified Process): Es un Framework de procesos de desarrollo de software de código abierto. Se basa en el RUP creado por IBM, pero no coincide en todos los puntos. Está pensado para pequeños equipos de desarrollo que valoran los beneficios de la colaboración colaboración y de los involucrados con el resultado del del proyecto que prefieren olvidarse de formalidades innecesarias. Provee de un simple conjunto de contenidos, fundamentalmente relacionados con orientación, puestos de trabajo, roles y tareas. Que simplifican el reparto de los l os esfuerzos. El Open UP se basa en cuatro principios interrelacionados: - Colaboración 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 articulación de la arquitectura. - Desarrollo continuo para obtener realimentación y, de esta manera, realizar las mejoras necesarias. Al articular la arquitectura se produce una mejora de la colaboración técnica, reducir el riesgo y minimizar los sobresfuerzos durante el desarrollo. OpenUP desarrolla un ciclo de vida interactivo i nteractivo 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 más más simple y ligera es el Open UP/Basic UP/Basic también llamado Basic Unified Process o BUP donado por IBM.
EssUP (Essential Unified Process): Creado por Ivar Jacobson Solutions es una colección 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 más simple haciendo más fácil la tarea de repartir repartir y adaptar el proyecto proyecto ajustándolo a las prioridades temporales y a las necesidades de la empresa. Según 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 más simple y mucho más flexible y extensible que las anteriores definiciones del UP. UP. Se presenta como ligero y amigable haciéndose fácil de aprender. aprender. Según fuentes varias parece ser que IBM, Microsoft Visual y Eclipse lo aceptarán.
6. Bibliografía: http://www.utim.edu.mx/~pmendoza/ftp/rup.pdf http://en.wikipedia.org/wiki/Unified_Process http://iie.fing.edu.uy/ense/asign/desasoft/T http://iie.fing.edu.uy/ense/asign /desasoft/Teorico2/ProcesoUnificado.pdf eorico2/ProcesoUnificado.pdf http://es.wikipedia.org/wiki/Proceso_Unificado http://www.rodolfoquispe.or http://www .rodolfoquispe.org/blog/que-es-el-proceso-unificado-de-desarrollo-deg/blog/que-es-el-proceso-unificado-de-desarrollo-desoftware.php http://www.slideshare.net/Sofylutqm/el-proceso-u http://www .slideshare.net/Sofylutqm/el-proceso-unificado-3943047 nificado-3943047 http://audiemangt.blogspot.com/2010/05/metod http://audiemangt.blogsp ot.com/2010/05/metodologia-agil-proceso-unificado-de.html ologia-agil-proceso-unificado-de.html http://www.ambysoft.com/unifiedprocess http://www .ambysoft.com/unifiedprocess/agileUP /agileUP.html .html http://www.info-ab.uclm.es/asignaturas/425 http://www .info-ab.uclm.es/asignaturas/42541/pdf/m1tema4.pdf 41/pdf/m1tema4.pdf http://ccollins.wordpress.com/2008/06/1 http://ccollins.wordpress.com/2 008/06/11/unified-process-vs-agile-processes/ 1/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/R http://students.mimuw .edu.pl/~zbyszek/posi/ibm/RUP_Eval/manuals/intro/kc_artifact.htm UP_Eval/manuals/intro/kc_artifact.htm