RUP

RESUMEN
Durante mucho tiempo se ha utiliza¬do el tradicional modelo en cascada, el cual ha demostrado que no refleja adecuadamente la complejidad inhe¬rente al proceso de desarrollo de soft¬ware. Los problemas que presenta este modelo nacen de su propia estructu¬ra, al ser una secuencia de grandes etapas que requieren como hitos la documentación completa antes de con¬tinuar con la siguiente etapa.
Para solucionar este problema se debe hacer uso de métodos iterativos e incrementales, que unidos a otras prácticas claves como la orientación al man ejo de riesgos y la planeación adaptable, permiten de forma natu¬ral guiar adecuadamente el proceso
de desarrollo de software. En espe¬cial se considerará el RUP1 de IBM, basado en el modelo en espiral que organ iza las iteraciones por etapas y fases para obtener una estructura más sólida, clara y ajustable a las necesidades particulares de cada or¬ganización.
Este artículo tiene como objetivo des¬cribir en forma general el desarrollo iterativo, y las ventajas que ofrece su utilización en los procesos de desarro¬llo de software.
PALABRAS CLAVES
Modelo en espiral, desarrollo iterati¬vo, proceso unificado de rational
INTRO D U CCI ÓN
En los proyectos de tecnología se han incorporado paulatinamente los cam¬bios en los métodos de ingeniería, pero, desafortunadamente, no se ha hecho lo mismo en su administración. A continuación se mostrará una vi¬sión general de los cambios en los ci¬clos de vida de los proyectos, señalan¬do sus ventajas, desventajas y el por qué de dicha evolución.
Existe un conjunto de modelos de ci¬clo de vida en la gerencia de proyec¬tos que han evolucionado desde el tra¬dicional modelo en cascada, pasando por algunas propuestas de mejora¬miento como son el caso de cascadas con fases solapadas o cascada con subproyectos. Estos modelos no per¬miten una identificación temprana de los riesgos, los cuales pueden apare¬cer en las etapas finales del desarro¬llo o implantación, momento en que un cambio en el diseño del producto, en la arquitectura del sistema o en la infraestructura de software y hard¬ware puede llevar al fracaso comple¬to del proyecto.
Estos modelos son muy prácticos para proyectos pequeños y con muy bajos niveles de riesgos, tales como proyec¬tos de nuevas versiones de algún soft¬ware existente, donde haya requeri¬mientos claros y cuya arquitectura e infraestructura de software y hard¬ware no van a cambiar mucho respec¬to a la versión anterior.
Como respuesta al problema presen¬tado por los modelos anteriores, los ciclos de vida evolucionaron y se han presentado propuestas como el mode- lo de entrega por etapas y el de en¬trega evolutiva. Cada uno de ellos adicionó mayores niveles de comple¬jidad a la administración, pero ase¬guran poseer un marco de trabajo más sólido y ajustado para el desarro¬llo de proyectos con niveles modera¬dos de riesgo. Se requería de todas for¬mas un modelo de ciclo de vida de pro¬yectos que trabajara adecuadamente con niveles altos de riesgo, así que se desarrolló el modelo en espiral. Este modelo tiene como objetivos la identi¬ficación de los riesgos para determi¬nar la viabilidad del proyecto y defi¬nir planes de manejo para garantizar desde las fases iniciales la eliminación o mitigación de los riesgos donde es menos costoso y la entrega desde las faces iniciales de productos probados, lo que permite un proceso continuo de pruebas y retroalimentación.
PRÁCTICAS CLAVES DEL PROCESO DE DESARROLLO DE SOFTWARE
• Desarrollo iterativo
El desarrollo iterativo es un método de con strucción de productos cuyo ci¬clo de vida está compuesto por un con- junto de iteraciones, las cuales tienen como objetivo entregar versiones del software. Cada iteración se conside¬ra un subproyecto que genera produc¬tos de software y no sólo documenta¬ción, permitiendo al usuario tener puntos de verificación y control más rápidos e induciendo un proceso con¬tinuo de pruebas y de integración desde las primeras iteraciones.
Las iteraciones están compuestas por el conjunto de disciplinas o activida¬des ya conocidas en el proceso de de¬sarrollo de software. Estas son la es¬pecificación de requerimientos, el análisis y diseño, las pruebas, la ad¬ministración de la configuración y el proceso de gerencia de proyectos. En la Figura 1 se muestra gráficamente la relación existente entre las disci¬plinas o actividades y las iteraciones.
Figura 1. Disciplinas a través de las iteraciones.



Fuente: IBM RUP Rational Unified Process® Versión 2002.05.00. Rational Software Corporation.









A través del tiempo se han formali¬zado algunos métodos de desarrollo iterativo, tales como Evo, Microsoft Solution Framework, modelo en es¬piral WinWin y UP. Este artículo se centrará en el método de desarrollo iterativo conocido como Proceso Uni¬ficado o UP.
• Orientación al manejo del riesgo Cada proyecto tiene asociado intrín¬secamente un conjunto de riesgos que requieren un plan de manejo clara¬mente establecido, documentado y con una implementación eficaz. De esta manera se pretende evitar posi¬bles retrasos en los tiempos de entre¬ga, problemas de calidad en el pro¬ducto o en el peor de los casos, que puedan afectar la culminación del proyecto. Estos procesos pueden ser tan complejos y elaborados como la importancia del proyecto lo requiera.
En las etapas iniciales se implemen¬tan las funcionalidades con mayor exposición al riesgo y las de mayor complejidad, mejorando la posibilidad de éxito del proyecto.
Figura 2. Perfiles de riesgo.

Fuente: Principles of Managing Iterative Development v.2.0 Rational Software Cor¬poration.
En la fase inicial del proyecto, el ni¬vel de exposición al riesgo en ambos modelos es casi igual, pero en las fa¬ses siguientes es completamente di¬ferente para cada modelo (Ver Figu¬ra 2). Este comportamiento se debe al período de exploración de riesgos del modelo en espiral, donde se iden¬tifican los riesgos, se priorizan y se define un plan de man ejo para miti¬garlos. Se procede a la fase de elabo¬ración donde se implementan aque¬llos casos de uso que atacan los ries¬gos de más alta prioridad, lo cual se denomina período de resolución de riesgos. Al final de esta fase se debe tener definida la arquitectura del sis¬tema, así como la infraestructura en la que se soportará.
• Orientación al cliente
Cuando se inicia un proyecto de desarrollo de software se conoce la im¬portancia de la participación del cliente para lograr su terminación exitosa, pero usualmente cometemos el error de olvidar esta norma bási¬ca, lo que implica que la participación del cliente se restringe al inicio y fi¬nalización del proyecto, lo que en la mayoría de los casos produce un alto grado de insatisfacción en el usuario, al no obtener el producto con las especificaciones esperadas.
El cliente es quien realmente con oce el valor que aportará el producto que está siendo desarrollado y puede de¬finir las prioridades desde la perspec¬tiva organizacional. Esto quiere de cir que es necesario contar con su participación en el proceso de plani¬ficación de las fases y de las iteracio¬nes. Posteriormente se requiere su participación en cada iteración para proveer retroalimentación temprana al equipo de desarrolladores, garan¬tizando el cumplimiento de las expec¬tativas que tiene, además de ofrecer¬le una visibilidad permanente del estado del proyecto, asegurando su compromiso para terminarlo exitosa¬m ent e.
Se debe tener en cuenta que el clien¬te no se interesa por los aspectos téc¬nicos de alta complejidad y riesgo, razón por la cual se debe combinar esta práctica con una orientación al manejo del riesgo.
• Desarrollo evolutivo
Cuando se trabaja con una especifi¬cación de requerimientos monolítica, se cae en el error de creer que se com¬prende completamente el concepto del producto sin haberlo validado con el cliente con algo más que documen¬tos y modelos abstractos. Este proce¬so inicia con un concepto poco claro del producto a construir, y sólo se tie¬ne claridad en la medida que se vaya desarrollando y verificando el produc¬to con el cliente. Este tipo de proyec¬tos se asemejan más al patrón que siguen los proyectos de investigación y desarrollo de nuevos productos.
Estas prácticas claves en el desarro¬llo de software son implementadas en algunos métodos tales como Evo2, el modelo en espiral y el proceso unifi¬cado (UP), siendo los dos últimos los que mayor trascendencia han tenido y serán explicados a continuación.

MODELO EN ESPIRAL
El modelo en espiral se centra en al¬gunas prácticas fundamentales del desarrollo de software, tales como la orientación al manejo de riesgos, la orientación al cliente y el desarrollo iterativo (Ver Figura 3). El modelo se organiza en un conjunto de iteracio¬nes que pueden con siderarse a sí mis¬mas como pequeños proyectos que siguen el ciclo de vida completo. Las primeras iteraciones tienen como ob¬jetivo identificar los riesgos del pro¬yecto para determinar su viabilidad, y en caso de seguir adelante, definir un plan de manejo para mitigarlos o eliminarlos. Adicionalmente, el usua¬rio participa activamente en la prio¬rización de los casos de uso a desa¬rrollar y en el proceso de pruebas, con lo cual se logra obtener una funcio¬nalidad estable y operativa desde las primeras iteraciones del proyecto.





Figura 3. Mapa conceptual del modelo en espiral.



Fuente: Barry Boehm, “A Spiral Model of Software Development and Enhancement
El modelo en espiral tiene muchas ventajas respecto a los modelos ante¬riores por su orientación a la resolu¬ción temprana de riesgos, por la defi¬nición de la








En términos generales este mo¬delo tiene un nivel alto de compleji¬dad y requiere mucha destreza admi¬nistrativa y experiencia por parte del gerente del proyecto y su grupo de trabajo para manejarlo adecuada¬m ent e.
Este modelo es ideal para manejar proyectos que requieran la incorporación de nuevas tecnologías, o para desarrollar productos completamen¬te nuevos o con un nivel alto de ines¬tabilidad de los requerimientos. Tí¬picamente se maneja una iteración inicial donde se define el alcance del proyecto, se identifican y priorizan los riesgos y se realiza el modelo de ca¬sos de uso inicial para determinar qué casos de uso definirán la arquitectu¬ra del sistema. Con la información anterior se procede a definir el plan de manejo de riesgos según su priori- dad, así como los casos de uso que serán implementados en las siguien¬tes iteraciones (Ver Figura 4).

Figura 4. Modelo en espiral.



















Fuente: Desarrollo y Gestión de Proyectos Informáticos. Steve McConnell, McGraw
ITERACION ES
Una iteración es una secuencia de actividades dentro de un plan esta¬blecido, con unos criterios claros de evaluación, que se organiza con el propósito de entregar parte de la fun¬cionalidad del producto. En las pri¬meras iteraciones se desarrollan o implementan los casos de uso que tie¬nen mayor complejidad y que llevan inherente un alto nivel de riesgo que puede afectar el éxito del proyecto. De esta forma, con cada iteración que se realiza, los riesgos del proyecto se re¬ducen acorde con el plan establecido, el cual está en permanente revisión para monitorear la posible aparición de nuevos riesgos y ajustarlo si es necesario.
La selección de los casos de uso para cada iteración se hace teniendo en cuenta cuál es el mínimo conjunto de ellos que se requiere para implemen¬tar la funcionalidad que mayor ries¬go tenga. Se debe realizar este proce¬so hasta que la lista de riesgos haya sido cubierta completamente.
Cada iteración puede tener uno o va¬rios propósitos, lo cual determina la duración de la misma; a su vez se eje¬cutan varios procesos que van desde
la especificación de requerimientos hasta las pruebas de unidad e inte¬gración, lo cual se asimila a un ciclo de vida en cascada. Adicionalmente, al final de cada iteración se deben evaluar los resultados del trabajo y se planea detalladamente la siguien¬te iteración.
INCORPORANDO EL PROCESO UNIFICADO DE DESARROLLO DE RATIONAL
La concepción de un sistema de infor¬mación va mucho más allá de levan¬tar los requerimientos, elaborar un conjunto de modelos y comenzar a pro¬gramar. Esta concepción limitada ha permitido que durante años no poda¬mos hacer uso adecuado de los concep¬tos y las herramientas con los que con¬tamos. En este punto podemos consi¬derar que la definición de la arquitec¬tura del software se convierte en el eje orientador que permite controlar el desarrollo iterativo e incremental del sistema, a través de su ciclo de vida. Esta arquitectura se define en las pri¬meras fases del proyecto, básicamen¬te en la de elaboración, y se refina a través de todo el proyecto.
El RUP se fundamenta en seis prác¬ticas: el desarrollo iterativo, la admi¬nistración de requerimientos, la ar¬quitectura basada en componentes, en el modelamiento visual, en la ve¬rificación continua de la calidad y la administración del cambio. Estas seis prácticas orientan el modelo y con ellas se pretende solucionar muchos de los problemas asociados al soft¬ware. Adicionalmente hay muchos aspectos de diseño que son bien co¬nocidos, pero que en realidad han sido muy poco implementados en los pro¬yectos de software; estos son: facili dad de uso, modularidad, encapsu¬lamiento y facilidad de manteni¬miento. Es necesario entonces defi¬nir una arquitectura sólida basada en componentes, para construir me¬jores y más flexibles soluciones de software para las necesidades orga¬nizacionales.
Los cambios en un proyecto no pue¬den ser detenidos dado que la evolu¬ción del entorno de cada organización es continua, pero sí pueden ser ad¬ministrados de manera que su impac¬to pueda ser estimado para determi¬nar si dicho cambio se incluye o no y si el proyecto debe ser reajustado. Cada cambio en el proyecto debe te¬ner especificado cuándo y cómo se va a realizar, quién lo va a hacer y qué productos se ven involucrados en ese cambio. En ese punto es donde el con¬trol de cambios y la trazabilidad de los componentes a través de los di- versos modelos adquieren una gran importancia.
Existen algunos aspectos que se de- ben tener en cuenta para desarrollar exitosamente un proyecto. A conti¬nuación se enumeran algunos de ellos:
1. Se debe tener definida claramen¬te la metodología de trabajo de cada fase del proceso del desarro¬llo de software, en especial las fa¬ses de administración de requeri¬mientos y control de cambios, los cuales son los eslabones más dé¬biles del proceso de desarrollo de software en nuestras organizacio¬nes. La responsabilidad de defi¬nir, documentar y velar que se cumpla a cabalidad la metodolo¬gía de trabajo es del grupo de in¬geniería de procesos.
2. La participación activa de los usuarios y los acuerdos en los tiem¬pos pactados, teniendo en cuenta los datos generados de los proce¬sos de estimación y planificación, son responsabilidad del jefe del proyecto, pero deben ser elabora¬dos con integrantes claves del equi¬po del proyecto.
3. El Grupo SQA3 debe definir, docu¬mentar y actualizar el proceso de aseguramiento de la calidad del software, gestionar los recursos ne¬cesarios para que sea operativo desde el comienzo del proyecto, entregar el plan de calidad y velar por su cumplimiento a lo largo del ciclo de vida del proyecto.
El proceso de incorporación y uti¬lización de nuevas tecnologías es quizás uno de los aspectos más críticos dentro del proyecto y de ma¬yores riesgos. La definición de una metodología de administración del cambio tecnológico, clara y muy práctica, facilitaría considerable¬mente el trabajo realizado en la fase de elaboración, lo cual permi¬tiría determinar la viabilidad de la incorporación de dicha tecnología en el proyecto.
Teniendo en cuenta los aspectos men¬cionados previamente, Rational que recientemente fue comprada por IBM, elaboró un marco de referencia para el proceso de desarrollo de software basado en el modelo en espiral. Este método se conoce como RUP “Ratio¬nal Unified Process”. Para una mejor organización, el RUP agrupa las ite¬raciones en etapas y fases que facili¬tan facili¬tan la administración del proyecto.
1. Etapa de ingeniería
Esta etapa agrupa las fases de con¬cepción y de elaboración, lo que bá¬sicamente le da por objetivos la con¬ceptualización del sistema y el di¬seño inicial de la solución del pro¬blema.
Se inicia el proceso de administración de los requerimientos con la identifi¬cación y especificación de casos de usos, así como el proceso de asegura¬miento de la calidad a través de los casos de prueba.
Se identifican los riesgos y se esta¬blece su plan de manejo, se ajusta ese plan según la tabla de priorización de riesgos y la de casos de usos vs. ries¬gos, para determinar en qué orden y en qué iteraciones se desarrollarán los artefactos de software que son la solución a los casos de uso.
Se identifican los recursos necesa¬rios, tanto económicos como huma¬nos, acordes con las necesidades del proyecto. Se da comienzo al proceso de estimación y planificación inicial a un nivel macro para todo el pro¬yecto y posteriormente se realiza una estimación detallada de tiempos y recursos de las fases de concepción y elaboración.
1.1. Fase de concepción
Esta fase tiene como propósito defi¬nir y acordar el alcance del proyec¬to con los patrocinadores, identifi¬car los riesgos asociados al proyec¬to, proponer una visión muy gene¬ral de la arquitectura de software y producir el plan de las fases y el de iteraciones.
A partir del modelo de casos de uso y de la lista de riesgos, se puede deter¬minar qué casos de uso deben imple¬mentarse primero para atacar los riesgos de mayor exposición. Con base en la información previa se realiza el proceso de planificación general y un plan de trabajo detallado para la si¬guiente fase, así como el plan para la siguiente iteración.
Se debe establecer una relación cla¬ra y directa entre los casos de uso y los casos de prueba para facilitar que el proceso de aseguramiento de la calidad del software se ejecute ade¬cuadamente. El plan de pruebas debe planearse en esta fase, ejecutarse desde la primera iteración de la fase de elaboración y refinarse sucesiva¬mente durante el ciclo de vida del proyecto.
1.2. Fase de elaboración
Los casos de uso seleccionados para desarrollarse en esta fase permiten definir la arquitectura del sistema, se realiza la especificación de los casos de uso seleccionados y el primer aná¬lisis del dominio del problema, se di¬seña la solución preliminar del pro¬blema y comienza la ejecución del plan de manejo de riesgos, según las prioridades definidas en él.
Al final de la fase se determina la via¬bilidad de continuar el proyecto y si se decide proseguir, dado que la ma¬yor parte de los riesgos han sido mi¬tigados, se escriben los planes de tra¬bajo de las etapas de con strucción y transición y se detalla el plan de tra¬bajo de la primera iteración de la fase de construcción.
2. Etapa de producción
En esta etapa se realiza un proceso de refinamiento de las estimaciones de tiempos y recursos para las fases de construcción y transición, se de¬fine un plan de mantenimiento para los productos entregados en la eta- pa de ingeniería, se implementan los casos de uso pendientes y se entre¬ga el producto al cliente, garantizan¬do la capacitación y el soporte ade¬cu a dos.
2.1. Fase de construcción
El propósito de esta fase es comple¬tar la funcionalidad del sistema, para ello se deben clarificar los requeri¬mientos pendientes, administrar el cambio de los art efactos con struidos, ejecutar el plan de administración de recursos y mejoras en el proceso de desarrollo para el proyecto.
2.2. Fase de transición
El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, aju star los erro¬res y defectos encontrados, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las espe¬cificaciones entregadas por las perso¬nas involucradas en el proyecto al inicio del mismo.
CONCLUSION ES
En este artículo se presenta una vi¬sión general de algunos métodos orientados por las prácticas de desa¬rrollo iterativo y manejo del riesgo.
Este tipo de métodos no han sido apli¬cados en muchas de las empresas lo¬cales, probablemente por su comple¬jidad de administración, desaprove¬ desaprove¬chando sus considerables ventajas respecto a los métodos tradicionales. Es necesario entonces desarrollar mecanismos de apropiación tecnoló¬gica más eficaces, que permitan man¬tener actualizadas nuestras prácticas organ iza cion ales.
Los marcos de referencia aquí men¬cionados definen qué debe hacerse y en algunos casos cómo hacerlo. El tra¬bajo del gerente de proyectos con sis¬te en identificar cuál marco de refe¬rencia se ajusta a su organización y realizar el proceso de apropiación de la metodología y asimilación de las guías de trabajo al interior del equi¬po del proyecto y del área de infor¬mát ica.
BIBLIOGRAFÍA
Craig Larman. Agile and iterative development: a manager’s guide. Addison Wesley, 2004.
Ivar Jacobson, Grady Booch y James Rumbaugh. The Unified Software Development Process. Rational Soft¬ware Corporation. Addison-Wesley, 1999.
Steve McConnell. Desarrollo y Ges¬tión de Proyectos Inform áticos. McGraw Hill, 1996.
Rational Software Corporation. Prin¬ciples of Managing Iterative Develo¬pm ent v.2.0. 2001.
Project Management Institute PMI. A Guide to the Project Management Body of Knowledge PMB OK® Guide. 2000 Edition.
Rational Software Corporation. RUP Rational Unified Process® Version 2002.05.00, 2002.
Sandra Victoria Hurtado Gil. Representación de la arquitectura de software usando UML. Revista Sistemas & Telemática No. 1 - Enero-Junio 2003. Universidad ICE SI.
Robin Alberto Castro Gil es Inge¬niero de la Universidad Icesi, realizó la especialización en Gerencia de la Producción en la Universidad Icesi. Actualmente es Jefe de la Oficina de Desarro¬llo de Sistemas de la Universi¬dad Icesi y presidente de la Aso¬ciación de Usuarios de Oracle de Colombia-ASUOC.