Serie Cientfica de la Universidad de las Ciencias Informticas

http://publicaciones.uci.cu/index.php/SC| seriecientifica@uci.cu

No. 10, Vol. 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 Ruiz

1*, Lilin lvarez Almanza

2, 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 metodo-

logas 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, priorida-

des, 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 informati-

zacin de la sociedad, se siguen las buenas prcticas que propone la metodologa RUP. Con esta metodologa implan-

tada 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, metodolog-

a, proceso unificado de desarrollo.

Abstract

In the present investigation will be carried out a comparison among the tendencies of the agile and formal methodo-

logies, 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 techni-

ques 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 pro-

duce a growth in the final product.

Keywords: Agile methodologies, center of informatization of entities, methodology, traditional methodologies, uni-

fied 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 analiza-

ron 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 metodo-

loga 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 invo-

lucrados en procesos de desarrollo de software.

La constante innovacin tecnolgica hace que cada vez sea ms necesaria la aplicacin de nuevas metodologas adap-

tadas 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 soft-

ware. En esta reunin participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los crea-

dores o impulsores de metodologas de software. Su objetivo fue esbozar los valores y principios que deberan permi-

tir 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 mxi-

mo, 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 equi-

po 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 proce-

sos, actividades, roles y flujos de trabajo, para ello se realiz un levantamiento, el cual arroj los resultados siguien-

tes:

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 nuevo 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 em-

pleados

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 com-

petitividad 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 especia-

lizado 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 ca-

da 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 pregun-

tas:

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 concen-

trar 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 proyec-

to 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 desarro-

llo, que puede combinarse con arquitecto jefe o manager de proyecto; (4) programador jefe, que participa en el anli-

sis 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 cuestio-

nes 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 proyectos agregan o re-

mueven 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 esta-

blecidas por el equipo mismo.

Propiedades establecidas por Crystal Clear

Frecuencia en las entregas: entregar al usuario funcionalidad "usable" con una frecuencia de entre 2 se-

manas 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 proyec-

to.

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 equipo.

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 toman-

do 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 abierta-

mente, para revisar el trabajo hecho y evaluar los elementos que dan resultados y cules no o sencillamente el co-

mienzo 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 recomendable 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 Extrema (XP)

La Programacin Extrema, es una metodologa ligera de desarrollo de software que se basa en la simplicidad, la co-

municacin 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 retroa-

limentacin 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 Framework (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 adminis-

tracin de proyectos, MSF es una serie de modelos que puede adaptarse a cualquier proyecto de tecnologa de infor-

macin. 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 requie-

ren 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 pro-

yecto, 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 documen-

tacin 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 opera-

cin bajo condiciones realistas. El equipo se enfoca en priorizar y resolver errores y preparar la solucin para el lan-

zamiento.

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 desarro-

llando. 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 respon-

sables 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 (abre-

viacin 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 Mo-

delado 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 pro-

ceso 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 proceso 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 ca-

sos 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 iteracio-

nes 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 necesario es in-

cluido. 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 impul-

san un ambiente de equipo saludable, facilitan la colaboracin y desarrollan un conocimiento compartido del

proyecto.

Equilibrar las prioridades para maximizar el beneficio obtenido por los interesados en el proyecto. Este prin-

cipio 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 parti-

cipantes 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 significati-

vos para la arquitectura. El propsito de esta fase es establecer la base la elaboracin de la arquitectura del

sistema.

3. Construccin: Esta fase est enfocada al diseo, implementacin y prueba de las funcionalidades para des-

arrollar un sistema completo. El propsito de esta fase es completar el desarrollo del sistema basado en la Ar-

quitectura 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 aplica-

ble 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 informati-

zacin 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 dividi-

do 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 fundamental-

mente, 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 expe-

riencia 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].