Serie Cientfica de la Universidad de las Ciencias Informticas

http://publicaciones.uci.cu/index.php/SC| seriecientifica@uci.cu
No. 10, Vo l. 4, Ao: 2011
ISSN: | RNPS:

Tipo de artculo: Artculo original

Temtica: Ingeniera de software
Recibido: 4/10/2010 | Aceptado: 3/10/2011 | Publicado: 19/10/2011

Comparacin y tendencias entre metodologas giles y formales.

Metodologa utilizada en el Centro de Informatizacin para la Gestin de
Entidades
Comparison and tendencies among agile and formal. Methodologies used in
the Center of Informatization for the Management Entities
Javier Heredia Ruiz1*, Lilin lvarez Almanza2 , Naryana Linares Pons 3
Ceige, Centro de Informatizacin para la Gestin de Entidades. Facultad 3. Universidad de las Ciencias Informticas,
km 2 , Torrens, Boyeros, La Habana. CP. 19370
*Autor para la correspondencia: jheredia@uci.cu

Resumen
En la presente investigacin se realiza una comparacin entre las tendencias de las metodologas giles y formales, se
lleva a cabo atendiendo a los principales autores y revistas fundamentalmente. Se enuncian las principales metodologas tanto giles como tradicionales utilizadas en el mundo del desarrollo de software actualmente, como el caso de
XP, RUP respectivamente. Se realiza un detallado anlisis de cada una de las metodologas principales sealadas,
teniendo en cuenta como se desarrolla su proceso, las actividades que se llevan a cabo en cada una de estas, prioridades, principios, sus estrategias, las tcnicas que utilizan, en que se basan, las fases por las cuales estn compuestas.
Adems del anlisis de la Metodologa que se utiliza en el Centro de Informatizacin para la Gestin de Entidades, el
cual es encargado de enfrentar proyectos grandes y complejos como lo es el desarrollo en s, de un ERP; donde se
pretende lograr una solucin altamente parametrizable y modular de alcance nacional para la gestin integral de los
procesos contables financieros de las entidades cubanas, brindando de este modo un impulso decisivo a la informatizacin de la sociedad, se siguen las buenas prcticas que propone la metodologa RUP. Con esta metodologa implantada en el Centro existe una forma disciplinada de asignar tareas y responsabilidades, existe un desarrollo iterativo e
incremental en cuanto a que la construccin del producto se ha dividido en mdulos y cada mdulo se ve como una
iteracin del cual se obtiene un incremento que produce un crecimiento en el producto final.

Palabras clave: Centro de informatizacin de entidades, metodologas giles, metodologas tradicionales, metodologa, proceso unificado de desarrollo.

Abstract
In the present investigation will be carried out a comparison among the tendencies of the agile and formal methodologies, assisting fundamentally to the main authors and magazines. The main methodologies are enunciated so much
agile as traditional used in the world of the development of sof tware currently, as the case of XP, RUP respectively. A
detailed analysis is realized of each one of the methodologies main views previously, keeping in mind like the process
is developed, the activities that are carried out in each one of them, priorities, principles, their strategies, the techniques that use, in that are based, the phases for which are compound. Then an analysis of the Methodology is taken
that are used in the Center of Informatization for the Management of Entities, as the center is in charge of facing big
and complex projects like development itself, of an ERP; where can achieve a solution with high parameters and to
modulate of national reach for the integral management of the countable financial processes of the Cuban entities,
bringing a decisive impulse this way to the Informatization of the society, the good practices are continued and that
propose the methodology RUP. With this methodology implanted in Center a disciplined form it exists of assigning
tasks and responsibilities, an incremental and iterative development exists, as for that the construction of the product
has been divided in modules and each module seem to be like an iteration of which an increment is obtained that pr oduce a growth in the final product.

Keywords: Agile methodologies, center of informatization of entities, methodology, traditional methodologies, unified process of development.

Introduccin
En el presente trabajo se realizar una comparacin entre las tendencias de las metodologas giles y formales, se har
atendiendo a principales autores y revistas fundamentalmente. Entre los autores que ms se destacan y que se analizaron se encuentran: Hirotaka Takeuchi e Ikujijo Nonaka, Grady Booch, Ivar Jacobson y James Rumbaugh.
Al finalizar el estudio del arte que se propone sobre las metodologas de desarrollo, se explica brevemente la metodologa que se sigue en el Centro de Informatizacin para la Gestin de Entidades (CEIGE), atendiendo a las buenas
prcticas que proponen cada una de las analizadas mundialmente. El concepto de metodologa, dentro de la Ingeniera
del Software es uno de los ms polmicos y que ms debate produce tanto en estudiantes como en profesionales involucrados en procesos de desarrollo de software.
La constante innovacin tecnolgica hace que cada vez sea ms necesaria la aplicacin de nuevas metodologas adaptadas a los nuevos tiempos, esto sin embargo descuida el estudio de las metodologas ms antiguas y que sin lugar a
dudas constituyen la base de la Ingeniera de Software porque exhiben buenas prcticas que pudieran ser utilizadas.

Todas las metodologas son, en esencia, bien intencionadas. Obviamente, las ms modernas responden a problemas,
necesidades y tendencias actuales.

Desarrollo
En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino gil aplicado al desarrollo de software. En esta reunin participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologas de software. Su objetivo fue esbozar los valores y principios que deberan permitir a los equipos desarrollar software rpidamente y responder a los cambios que puedan surgir a lo largo del proyecto.
Se pretenda ofrecer entonces, una alternativa a los procesos de desarrollo de software tradicionales, caracterizados
por ser rgidos y dirigidos por la documentacin que se genera en cada una de las actividades desarrolladas.
Sin embargo, hay que tener presente una serie de inconvenientes y restricciones para su aplicacin, tales como: estn
dirigidas a equipos pequeos o medianos (Beck sugiere que el tamao de los equipos se limite de 3 a 20 como mximo, otros dicen no ms de 10 participantes), el entorno fsico debe ser un ambiente que permita la comunicacin y
colaboracin entre todos los miembros del equipo durante todo el tiempo, cualquier resistencia del cliente o del equipo de desarrollo hacia las prcticas y principios puede llevar al proceso al fracaso (el clima de trabajo, la colaboracin
y la relacin contractual son claves), el uso de tecnologas que no tengan un ciclo rpido de realimentacin o que no
soporten fcilmente el cambio.
En esta investigacin se estudian las tendencias de las metodologas giles y formales as como sus principales procesos, actividades, roles y flujos de trabajo, para ello se realiz un levantamiento, el cual arroj los resultados siguientes:

Metodologas giles principales:

Scrum
FDD
Crystal Clear
XP
MSF
Metodologas tradicionales:
RUP
Open Up
Finalmente, se puede encontrar la metodologa que se sigue en el Centro de Informatizacin de Ent idades (CEIGE),

con las buenas prcticas que ha proporcionado y algunas experiencias de su uso.

Luego de varias opiniones tanto a favor como en contra de las metodologas tradicionales se genera un nue vo enfoque
denominado mtodos giles, que nace como respuesta a los problemas existentes en las metodologas tradicionales
(que posteriormente se abordarn) y se basa en dos aspectos puntuales, el retrasar las decisiones y la planificacin
adaptativa; permitiendo potenciar an ms el desarrollo de software a gran escala.
Como resultado de esta nueva teora se crea un Manifiesto gil cuyas principales ideas son:
Los individuos y las interacciones entre ellos son ms importantes que las herramientas y los procesos empleados
Es ms importante crear un producto software que funcione que escribir documentacin exhaustiva
La colaboracin con el cliente debe prevalecer sobre la negociacin de contratos
La capacidad de respuesta ante un cambio es ms importante que el seguimiento estricto de un plan.
A continuacin se propone el resultado de la bsqueda en detalles realizada y para comenzar, se har por el grupo de
metodologas giles donde se pueden encontrar las siguientes:

Metodologa Scrum:
Scrum es una metodologa gil de desarrollo de proyectos que toma su nombre y principios de los estudios realizados
sobre nuevas prcticas de produccin por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80.
En Scrum se realizan entregas parciales del resultado final del proyecto, priorizadas por el beneficio que aportan al
receptor del proyecto. Por ello, Scrum est especialmente indicado para proyectos en entornos complejos, donde se
necesita obtener resultados en breve tiempo, los requisitos son cambiantes o poco definidos y la innovacin, la competitividad y la productividad es fundamental.
Segn el propio autor, Scrum tambin se utiliza para resolver situaciones en que no se est entregando al cliente lo
que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, se necesita
capacidad de reaccin ante la competencia, cuando la moral de los equipos es baja y la rotacin alta, adems cuando
es necesario identificar y solucionar ineficiencias sistemticamente o se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.
Scrum es un mtodo adaptativo de gestin de proyectos que se basa en los principios giles:
Colaboracin estrecha con el cliente.
Predisposicin y respuesta al cambio.
Conocimiento tcito de las personas al explcito de los procesos.
Desarrollo incremental con entregas funcionales frecuentes.
Comunicacin verbal directa entre los implicados en el proyecto.

Motivacin y responsabilidad de los equipos por la auto-gestin, auto-organizacin y compromiso.

Simplicidad o supresin de artefactos innecesarios en la gestin del proyecto.

Cmo se desarrolla el proceso de Scrum?

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos
semanas, si as se necesita). Cada iteracin tiene que proporcionar un resultado completo, un incremento del producto
final que sea susceptible de ser entregado con el mnimo esfuerzo al cliente cuando lo solicite.

Figura1. Proceso en Scrum.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que acta como plan del proyecto. En esta
lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en
iteraciones y entregas. De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla y el retorno de
inversin mediante la re-planificacin de objetivos que realiza al inicio de cada iteracin.
Las actividades que se llevan a cabo en Scrum son las siguientes:
Planificacin de la iteracin: El primer da de la iteracin se realiza la reunin de planificacin de la iteracin. Esta
tiene dos partes:
Seleccin de requisitos (4 horas mximo). El cliente presenta al equipo la lista de requisitos pr iorizada del
producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos ms prioritarios
que se compromete a completar en la iteracin, de manera que puedan ser entregados si el cliente lo solicita.
Planificacin de la iteracin (4 horas mximas): El equipo elabora la lista de tareas de las iteraciones necesarias
para desarrollar los requisitos a que se ha comprometido. La estimacin de esfuerzo se hace de manera conjunta y los
miembros del equipo se auto asignan las tareas. (Grupo ISSI, 2003)

Ejecucin de la iteracin: Cada da el equipo realiza una reunin de sincronizacin (15 minutos mximo) donde cada miembro del equipo inspecciona el trabajo que el resto est realizando (dependencias entre tareas, progreso hacia
el objetivo de la iteracin, obstculos que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias
que permitan cumplir con el compromiso adquirido. En la reunin cada miembro del equipo responde a tres preguntas:
Qu he hecho desde la ltima reunin de sincronizacin?
Qu voy a hacer a partir de este momento?
Qu impedimentos tengo o voy a tener?
Durante la iteracin el facilitador se encarga de que el equipo pueda cumplir con su compromiso y de que no merme
su productividad, esto lo hace:
Eliminando los obstculos que el equipo no puede resolver por s mismo.
Protegiendo al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.
Inspeccin y adaptacin: el ltimo da de la iteracin se realiza la reunin de revisin de la iteracin. Esta reunin
tiene dos partes:
Demostracin (4 horas mximas): el equipo presenta al cliente los requisitos completados en la iteracin, en forma
de incremento de producto preparado para ser entregado con el mnimo esfuerzo. En funcin de los resultados
mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias
de manera objetiva, ya desde la primera iteracin, re-planificando el proyecto.
Retrospectiva (4 horas mxima): el equipo analiza cmo ha sido su manera de trabajar y cules son los problemas
que podran impedirle progresar adecuadamente, mejorando de manera seguida su productividad. El facilitador se
encargar de ir eliminando los obstculos identif icados. (Reynoso, 2004), (International Journal of Web Engineering
and Technology, 2009).

Feature Driven Development (FDD)

Feature Oriented Programming (FOP) es una tcnica de programacin guiada por rasgos o caractersticas (features) y
centrada en el usuario, no en el programador; su objetivo es sintetizar un programa conforme a los rasgos requeridos.
En un desarrollo partiendo de FOP, los objetos se organizan en mdulos o capas conforme a rasgos. FDD, en cambio,
es un mtodo gil, iterativo y adaptativo. A diferencia de otras metodologas giles no cubre todo el ciclo de vida sino
slo las fases de diseo y construccin y se considera adecuado para proyectos mayores y de misin crtica. FDD es,
adems, marca registrada de una empresa, Nebulon Pty. Aunque hay coincidencias entre la programacin orientada
por rasgos y el desarrollo guidado por rasgos, FDD no necesariamente implementa FOP.
FDD no requiere un modelo especfico de proceso y se complementa con otras metodologas. Enfat iza cuestiones de

calidad y define claramente entregas tangibles y formas de evaluacin del progreso.

Los principios de FDD son pocos y simples:

Se requiere un sistema para construir sistemas si se pretende escalar a proyectos grandes.
Un proceso simple y bien definido trabaja mejor.
Los pasos de un proceso deben ser lgicos y su mrito inmediatamente obvio para cada miembro del equipo.
Vanagloriarse del proceso puede impedir el trabajo real.
Los buenos procesos van hasta el fondo del asunto, de modo que los miembros del equipo se puedan concentrar en los resultados.
Los ciclos cortos, iterativos, orientados por rasgos (features) son mejores.
Hay tres categoras de rol en FDD: roles clave, roles de soporte y roles adicionales. Los seis roles clave de un proye cto son: (1) administrador del proyecto, quien tiene la ltima palabra en materia de visin, cronograma y asignacin del
personal; (2) arquitecto jefe (puede dividirse en arquitecto de dominio y arquitecto tcnico); (3) manager de desarrollo, que puede combinarse con arquitecto jefe o manager de proyecto; (4) programador jefe, que participa en el anlisis del requerimiento y selecciona rasgos del conjunto a desarrollar en la siguiente iteracin; (5) propietarios de clases,
que trabajan bajo la gua del programador jefe en diseo, codificacin, prueba y documentacin, repartidos por rasgos
y (6) experto de dominio, que puede ser un cliente, patrocinador, analista de negocios o una mezcla de todo eso.

Figura 2. Proceso en FDD.

FDD se utiliz por primera vez en grandes aplicaciones bancarias a fines de la dcada de 1990. Los autores sugieren
su uso para proyectos nuevos o actualizaciones de sistemas existentes, y recomiendan adoptarlo en forma gradual.

Metodologa Crystal Clear

Crystal Clear no es una metodologa en s misma s ino una familia de metodologas con un cdigo gentico comn.
Las mismas presentan un enfoque gil, con gran nfasis en la comunicacin, y con cierta tolerancia que la hace ideal
en los casos en que sea inaplicable la disciplina requerida. La misma se define con mucho nfasis en la comunicacin,
y de forma muy liviana en relacin con los entregables. Crystal maneja iteraciones cortas con feedback frecuente por
parte de los usuarios/clientes, minimizando de esta forma la necesidad de productos intermedios. Otra de las cuestiones planteadas es la necesidad de disponer de un usuario real aunque sea de forma de tiempo parcial para realizar
validaciones sobre la interfaz de usuario y para participarse en la definicin de los requerimientos funcionales y no
funcionales del software.
Una cuestin interesante que surge del anlisis de la serie Crystal es que las personas involucradas escogen aquellos
principios que les resultan efectivos y mediante la aplicacin de la metodologa en diversos proye ctos agregan o remueven principios en base al consenso grupal del equipo de desarrollo.

Prioridades establecidas por Crystal Clear

Crystal Clear establece un conjunto de prioridades y principios que sirven de gua para la toma de decisiones, como lo
es:
Eficiencia en el desarrollo: para hacer que los proyectos sean econmicamente rentables
Seguridad en lo que se entrega.
Habitabilidad: hacer que todos los miembros del equipo adopten y sigan las convenciones de trabajo establecidas por el equipo mismo.
Propiedades establecidas por Crystal Clear
Frecuencia en las entregas: entregar al usuario funcionalidad "usable" con una frecuencia de entre 2 semanas y no ms de un mes.
Comunicacin: Crystal Clear toma como uno de sus pilares a la comunicacin. Promueve prcticas como
el uso de pizarrones, pizarras y espacios destinados a que todos (miembros del equipo y visitas) puedan
ver claramente el progreso del trabajo.
Crecimiento reflexivo: Es necesario que el equipo lleve a cabo reuniones peridicas de reflexin que
permitan crecer y hacerse ms eficientes.
Principios establecidos por Crystal Clear
El grado de detalle necesario en documentar requerimientos, diseo, planeamiento, vara segn el proye cto.
Es imposible eliminar toda documentacin pero puede ser reducida logrando un modo de comunicacin
ms accesible, informal y precisa que pueda ser accedido por todos los miembros del equ ipo.

El equipo ajusta constantemente su forma de trabajo para lograr que cada personalidad encaje con los
otros miembros, con el entorno y las particularidades de cada asignacin.
Estrategias establecidas por Crystal Clear: El poder arrancar el proceso a partir de un esqueleto sobre el cual se ir
agregando funcionalidad en cada una de las entregas ayuda a que se vean los avances desde el comienzo. A medida
que se avanza en el proceso, la re arquitectura permitir ir agregando ms "cuerpo" al esqueleto in icial.

Figura 3. Estrategias establecidas por Crystal Clear.

Tcnicas propuestas por Crystal Clear

Igual que con las estrategias, hay una lista de tcnicas propuestas por Crystal Clear, de las cuales se pueden ir tomando las ms convenientes segn el momento en que se encuentra el proceso de desarrollo del proyecto.
Las reuniones que diariamente se llevan a cabo (metodologa Scrum) acompaan el seguimiento y mantenimiento del
foco en el prximo paso a seguir, adems de permitir la discusin productiva de las lneas a seguir.
Las reuniones de reflexin peridicas son fundamentalmente para que los miembros del equipo se expresen abiertamente, para revisar el trabajo hecho y evaluar los elementos que dan resultados y cules no o sencillamente el comienzo de un nuevo trabajo. Todo esto permite ir armando una metodologa de trabajo que se adecue al equipo, el
proyecto y los tiempos que se manejen.
De manera general Crystal da vital importancia a las personas que componen el equipo de un proyecto, y por tanto sus
puntos de estudio son:
Aspecto humano del equipo.
Tamao de un equipo (nmero de componentes).
Comunicacin entre los componentes.
Distintas polticas a seguir.
Espacio fsico de trabajo.

De manera general y resumiendo, la gua de trabajo que presenta Crystal Clear es altamente rec omendable para equi-

pos pequeos, da flexibilidad y prioriza la parte humana (como todas las Metodologas giles), apuntando a lograr
eficiencia, habitabilidad y confianza en los miembros del equipo. Presta especial importancia a la ubicacin fsica del
grupo, donde la comunicacin cumple el rol principal. La entrega frecuente de cdigo confiable y "funcionando"
mantiene el foco y evita distracciones. (Word Press, 2010)

Metodologa Programacin Extre ma (XP)

La Programacin Extrema, es una metodologa ligera de desarrollo de software que se basa en la simplicidad, la comunicacin y la realimentacin o reutilizacin del cdigo desarrollado. La metodologa consiste en una programacin
rpida o extrema, utilizadas para proyectos de corto plazo.

La metodologa se basa en:

Pruebas Unitarias: Se traduce en las pruebas realizadas a los principales procesos, de tal manera que se puede
adelantar en algo hacia el futuro, se pueden hacer pruebas de las fallas que pudieran ocurrir obteniendo los
posibles errores.
Refabricacin: Proceso mediante el cual se puede modificar el cdigo de un sistema de software, teniendo en
cuenta que no se altere la interfaz, pero se mejore su estructura interna.
Programacin en pares: Una particularidad de esta metodologa es que propone la programacin en pares, la
cual consiste en que dos desarrolladores participen en un proyecto en una misma estacin de trabajo.

Caractersticas del desarrollo de la metodologa XP

Los diseadores y programadores se comunican efectivamente con el cliente y entre ellos mismos.
Los diseos del software se mantienen sencillos y libres de complejidad o pretensiones excesivas.
Se obtiene retroalimentacin de usuarios y clientes desde el primer da gracias a las bateras de pruebas.
El software es liberado en entregas frecuentes tan pronto como sea posible.
Los cambios se implementan rpidamente tal y como fueron sugeridos.
Las metas en caractersticas, tiempos y costos son reajustadas, permanentemente en funcin del avance real
obtenido. (Highsmith, 2006)

Concretamente, qu es lo que propone XP?, esta metodologa empieza en pequeo y aade funcionalidad con retroalimentacin continua. Propicia que el manejo del cambio se convierta en parte sustancial del proceso. Define que el
costo del cambio no depende de la fase o etapa de desarrollo en que se encuentre. Como metodologa no introduce
funcionalidades antes que sean necesarias. El cliente o usuario se convierte en miembro del equipo.
Histricamente, las metodologas tradicionales han intentado abordar la mayor cantidad de situaciones de contexto del
proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeos y con requisitos

muy cambiantes.
Por otra parte, las metodologas tradicionales (formales) se focalizan en documentacin, planificacin y procesos
(plantillas, tcnicas de administracin, revisiones, etc.), a continuacin se detalla RUP y MSF uno de los mtodos ms
usados dentro de los mtodos tradicionales.

Metodologa Microsoft Solution Frame work (MSF)

La metodologa MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el
desarrollo de un proyecto: Modelo de Arquitectura del Proyecto, Modelo de Equipo, Modelo de Proceso, Modelo de
Gestin del Riesgo, Modelo de Diseo de Proceso y finalmente el modelo de Aplicacin. MSF es un compendio de
las mejores prcticas en cuanto a administracin de proyectos se refiere. Ms que una metodologa rgida de administracin de proyectos, MSF es una serie de modelos que puede adaptarse a cualquier proyecto de tecnologa de informacin. Entre sus principales caractersticas se encuentran:
Adaptable: usado en cualquier parte como un mapa, del cual su uso es limitado a un lugar especfico.
Escalable: Puede organizar equipos pequeos de 3 4 personas, as como tambin, proyectos que requieren 50 personas a ms.
Flexible: Es utilizada en el ambiente de desarrollo de cualquier cliente. (Ambler, 2010).
Tecnologa Agnstica: Puede ser usada para desarrollar soluciones basadas sobre cualquier tecnologa.

Figura4. Fases que componen la metodologa MSF .

Visin y Alcances: La fase de visin y alcances trata uno de los requisitos ms fundamentales para el xito del proyecto, la unificacin del equipo detrs de una visin comn. El equipo debe tener una visin clara de lo que quisiera
lograr para el cliente y ser capaz de indicarlo en trminos que mot ivarn a todo el equipo y al cliente. Se definen los
lderes y responsables del proyecto, adicionalmente se identifican las metas y objetivos a alcanzar; estas ltimas se
deben respetar durante la ejecucin del proyecto en su totalidad, y se realiza la evaluacin inicial de riesgos del pro-

yecto.
Planificacin: Es en esta fase es cuando la mayor parte de la planeacin para el proyecto es terminada. El equipo
prepara las especificaciones funcionales, realiza el proceso de diseo de la solucin, y prepara los planes de trabajo,
estimaciones de costos y cronogramas de los diferentes entregables del proyecto.
Desarrollo: Durante esta fase el equipo realiza la mayor parte de la construccin de los componentes (tanto documentacin como cdigo), sin embargo, se puede realizar algn trabajo de desarrollo durante la etapa de estabilizacin en
respuesta a los resultados de las pruebas. La infraestructura tambin es desarrollada durante esta fase.
Estabilizacin: En esta fase se conducen pruebas sobre la solucin, las pruebas de esta etapa enfatizan el uso y operacin bajo condiciones realistas. El equipo se enfoca en priorizar y resolver errores y preparar la solucin para el la nzamiento.
Implantacin: Durante esta fase el equipo implanta la tecnologa base y los componentes relacionados, estabiliza la
instalacin, traspasa el proyecto al personal soporte y operaciones, y obtiene la aprobacin final del cliente.
Los equipos organizados bajo este modelo son pequeos y multidisciplinarios, en los cuales los miembros comparten
responsabilidades y balancean las destrezas del equipo para mantenerse enfocados en el proyecto que estn desarrollando. Comparten una visin comn del proyecto y se enfocan en implementar la solucin, con altos estndares de
calidad y deseos de aprender.
El modelo de equipos de MSF tiene seis roles que corresponden a las metas principales de un proyecto y son responsables por las mismas. Cada rol puede estar compuesto por una o ms personas, no es un modelo jerrquico y cada
uno de los roles es igualmente importantes en su aporte al proyecto. Aunque los roles pueden tener diferentes niveles
de actividad durante las diversas etapas del proyecto, ninguno puede ser omitido.
La comunicacin se pone en el centro del modelo evidenciando que est integrada en la estructura y fluye. El modelo
apoya la comunicacin efectiva y es esencial para el funcionamiento del mismo. (Agile Spain, 2010).

Metodologa Proceso Unificado de Desarrollo (RUP)

El antecedente ms importante se ubica en 1967 con la Metodologa Ericsson (Ericsson Approach) elaborada por Ivar
Jacobson, una aproximacin de desarrollo basada en componentes, que introdujo el concepto de Caso de Uso. Entre
los aos de 1987 a 1995 Jacobson fund la compaa Objectory AB y lanza el proceso de desarrollo Objectory (abreviacin de Object Factory).
Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB y entre 1995 y 1997 se desarrolla
Rational Objectory Process (ROP) a partir de Objectory 3.8 y del Enfoque Rational (Rational Approach) adoptando
UML como lenguaje de modelado.

RUP es el resultado de varios aos de desarrollo y uso prctico en el que se han unificado tcnicas de desarrollo, a
travs del UML, y trabajo de muchas metodologas utilizadas por los clientes. La versin que se ha estandarizado vio
la luz en 1998 y se conoci en sus inicios como Proceso Unificado de Rational 5.0; de ah las siglas con las que se
identifica a este proceso de desarrollo.
Desde ese entonces al mando de Grady Booch, Ivar Jacobson y James Rumbaugh, Rational Software desarroll e
incorpor diversos elementos para expandir RUP, destacndose especialmente el flujo de trabajo conoc ido como Modelado del Negocio. En junio del 1998 se lanza Rational Unified Process.
El Proceso Unificado de Desarrollo, es una metodologa para el desarrollo de software orientado a objetos. Es un proceso de desarrollo de software, definido como un conjunto de actividades necesarias para transformar los requisitos de
un usuario en un sistema software. Sin embargo, el proceso unificado es ms que un proceso de trabajo, es un marco
de trabajo genrico que puede especializarse para una gran variedad de sistemas software, para diferentes reas de
aplicacin, diferentes tipos de organizaciones y diferentes niveles de aptitud. Est constituido por 5 flujos de trabajo
fundamentales: requisitos, anlisis, diseo, implementacin y prueba, los cuales tienen lugar sobre 4 etapas o fases:
inicio, elaboracin, construccin y transicin. Esta metodologa es adaptable para proyectos a largo plazo y establece
refinamientos sucesivos de una arquitectura ejecutable.

Caractersticas especficas de RUP:

Dirigido por casos de uso: Esto significa que el pr oceso de desarrollo sigue una trayectoria que avanza a
travs de los flujos de trabajo generados por los casos de uso. Los casos de uso se especifican y disean al
principio de cada iteracin, y son la fuente a partir de la cual los ingenieros de prueba construyen sus casos de prueba. Estos describen la funcionalidad total del sistema.
Centrado en la arquitectura: Los casos de uso guan a la arquitectura del sistema y sta influye en la seleccin
de los casos de uso. La arquitectura involucra los elementos ms significativos del sistema y est influenciada
entre otros por las plataformas de software, sistemas operativos, sistemas de gestin de bases de datos,
adems de otros como sistemas heredados y requerimientos no funcionales.
Iterativo e incremental: RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y las cuales se definen segn el nivel de madurez que a lcanzan los
productos que se van obteniendo con cada actividad ejecutada. La terminacin de cada fase ocurre en el hito
correspondiente a cada una, donde se evala que se hayan cumplido los objetivos de la fase en cuestin.
RUP est basado en componentes y utiliza UML para visualizar, especificar y documentar cada una de las partes que
comprende el desarrollo de software.

Metodologa OpenUp
OpenUP es un proceso de desarrollo iterativo del software que es mnimo, completo, y extensible, significando cada
uno:
Mnimo: Solo incluye el contenido del proceso fundamental.
Completo: Puede ser manifestado como proceso entero para construir un sistema.
Extensible: Puede ser utilizado como base para agregar o para adaptar ms procesos.
El OpenUP es un proceso mnimo y suficiente, lo que significa que solo el contenido fundamental y nec esario es incluido. Por lo tanto, no provee lineamientos para todos los elementos que se manejan en un proyecto pero tiene los
componentes bsicos que pueden servir de base a procesos especficos. La mayora de los elementos de OpenUP estn
declarados para fomentar el intercambio de informacin entre los equipos de desarrollo y mantener un entendimiento
compartido del proyecto, sus objetivos, alcance y avances.
Entre los principales beneficios en el uso del OpenUP se encuentran:
Es apropiado para proyectos pequeos y de bajos recursos, permite disminuir las probabilidades de fracaso en
los proyectos pequeos e incrementar las probabilidades de xito.
Permite detectar errores tempranos a travs de un ciclo iterativo.
Evita la elaboracin de documentacin, diagramas e iteraciones innecesarias requeridos en la metodologa
RUP.
Por ser una metodologa gil tiene un enfoque centrado al cliente y con iteraciones cortas.
Los principios fundamentales de la metodologa OpenUP son:
Colaborar para sincronizar intereses y compartir conocimiento. Este principio promueve prcticas que impulsan un ambiente de equipo saludable, facilitan la colaboracin y desarrollan un conocimiento co mpartido del
proyecto.
Equilibrar las prioridades para maximizar el beneficio obtenido por los interesados en el proyecto. Este principio promueve prcticas que permiten a los participantes de los proyectos desarrollar una solucin que
maximice los beneficios obtenidos por los participantes y que cumple con los requisitos y restricciones del
proyecto.
Centrarse en la arquitectura de forma temprana para minimizar el riesgo y organizar el desarrollo.
Desarrollo evolutivo para obtener retroalimentacin y mejoramiento continuo. Este principio promueve
prcticas que permiten a los equipos de desarrollo obtener retroalimentacin temprana y continua de los participantes del proyecto, permitiendo demostrar incrementos progresivos en la funcionalidad.
Fases que propone la metodologa OpenUP:

1. Concepcin: Primera de las 4 fases en el proyecto del ciclo de vida, acerca del entendimiento del propsito y
objetivos y obteniendo suficiente informacin para confirmar que el proyecto debe hacer. El objetivo de sta
fase es capturar las necesidades de los stakeholder en los objetivos del ciclo de vida para el proyecto.
2.

Elaboracin: Es el segundo de las 4 fases del ciclo de vida del OpenUP donde se trata los riesgos significativos para la arquitectura. El propsito de esta fase es establecer la base la elaboracin de la arquite ctura del
sistema.

3. Construccin: Esta fase est enfocada al diseo, implementacin y prueba de las funcionalidades para desarrollar un sistema completo. El propsito de esta fase es completar el desarrollo del sistema basado en la Arquitectura definida.
4. Transicin: Es la ltima fase, cuyo propsito es asegurar que el sistema es entregado a los usuarios, y evala
la funcionalidad y performance del ltimo entregable de la fase de construccin. (DSDM Consortium, 2009)

Finalmente el OpenUp es un proceso modelo y extensible, dirigido a gestin y desarrollo de proyectos de software
basados en desarrollo iterativo, gil e incremental apropiado para proyectos pequeos y de bajos recursos; y es aplic able a un conjunto amplio de plataformas y aplicaciones de desarrollo.

Metodologa utilizada en el CEIGE

En el Centro de Informatizacin de Entidades de Gestin (CEIGE), se siguen las buenas prcticas que propone la
metodologa RUP y que anteriormente fueron enunciadas. Esta metodologa se ha implementado atendiendo a que el
centro es el encargado de enfrentar proyectos grandes y complejos como lo es el desarrollo en s, de un ERP; donde se
pretende lograr una solucin altamente parametrizable y modular de alcance nacional para la gestin integral de los
procesos contables financieros de las entidades cubanas, brindando de este modo un impulso decisivo a la informatizacin de la sociedad.
Con RUP en el CEIGE, existe una forma disciplinada de asignar tareas y responsabilidades, esto es: quin hace qu,
cundo y cmo, existe un desarrollo iterativo e incremental en cuanto a que la construccin del producto se ha dividido en mdulos y cada mdulo se ve como una iteracin (un recorrido ms o menos completo a lo largo de todos los
flujos de trabajo fundamentales de RUP) del cual se obtiene un incremento que produce un crecimiento en el producto
final.
Existe adems Administracin de requisitos en el Centro, para ello los analistas han implementado varios mtodos
que le permiten una buena y exitosa gestin de requisitos. La arquitectura est basada en componentes fundamentalmente, se cuenta con un repositorio disponible las 24 horas y del cual el equipo de proyecto puede obtener toda la
informacin que necesite, ya sea en documentacin o en cdigo fuente.
El control de cambios es otra de las buenas prcticas que se ha heredado de RUP, en el CEIGE existen roles a nivel

de mdulo de desarrollo encargados de la gestin temprana y oportuna de los cambios que se llevan a cabo. Al igual
que la verificacin de la calidad del software para el cual existe un equipo que estudia las normas y estndares ms
recientes y por los cuales se debe guiar el desarrollo de los productos terminados. En este sentido, es preciso aadir
que se encuentra dentro de los centros a los que se les est aplicando el proceso de mejora.

Conclusiones
No existe una metodologa universal para hacer frente con xito a cualquier proyecto de desarrollo de software. Toda
metodologa debe ser adaptada al contexto del proyecto, teniendo en cuenta los recursos tcnicos y humanos, tiempo
de desarrollo y tipo de sistema.
Histricamente, las metodologas tradicionales han intentado abordar la mayor cantidad de situaciones de contexto del
proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeos y con requisitos
muy cambiantes. Las metodologas giles ofrecen una solucin casi a medida para una gran cantidad de proyectos que
tengan estas caractersticas. Una de las cualidades ms destacables en una metodologa gil es su sencillez, tanto en su
aprendizaje como en su aplicacin, reduciendo as los costos de implantacin en un equipo de desarrollo, lo cual ha
llevado hacia un inters creciente en las metodologas giles. Sin embargo, teniendo en cuenta el anlisis de estas
metodologas y en especial la que se utiliza en el CEIGE se puede decir que para que un equipo de desarrollo adopte
una metodologa gil especfica debe poseer experiencia trabajando con metodologas tradicionales, ya que la experiencia es la que predomina en los momentos cruciales del proyecto, adems debe tener la capacidad de ser equipos
auto-gestionados y altamente motivados.

Referencias
Highsmith, Jim. Agile Project Management. [en lnea] 2006. [Consultado el: 12 de julio de 2010]. Disponible en:
[http://www.adaptivesd.com].
Agile Spain. 2010. [en lnea] 2010. [Consultado el: 15 de julio de 2010]. Disponible en: [www.agile-spain.com].
DSDM Consortium. 2009. [en lnea] 2009. [Consultado el: 11 de julio de 2010]. Disponible en:
[http://www.dsdm.org].
Enterprisexp. [en lnea] [Consultado el: 14 de julio de 2010]. Disponible en: [http://www.enterprisexp.org].
2009. International Journal of Web Engineering and Technology. 2, 2009, Vol. Volume 2.
Grupo ISSI. Metodologas giles en el desarrollo de software. Alicante: Patricio Letelier Torres, Emilio A. Snchez
Lpez, 2003, Vol. 1.
Reynoso, C. Mtodos Heterodoxos en desarrollo de software. Buenos Aires: s.n., 2004.

Scott W, Ambler. Agile Modeling (AM). [en lnea] 2010. [Consultado el: 17 de julio de 2010]. Disponible en:
[http://www.agilemodeling.com/].
Word Press. Spinec Blog. [en lnea] 2010. [Consultado el: 24 de julio de 2010]. Disponible en:
[http://www.spinec.org/wpcontent/metodologias%C3%81giles_01.pdf].