METODOLOGAS EMERGENTES

Prembulo al tema.
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.
Se pretenda ofrecer 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.
Segn el Manifiesto se valora:

AL INDIVIDUO Y LAS INTERACCIONES DEL EQUIPO DE

DESARROLLO SOBRE EL PROCESO Y LAS HERRAMIENTAS.
La gente es el principal factor de xito de un proyecto software. Es ms
importante construir un buen equipo que construir el entorno. Muchas
veces se comete el error de construir primero el entorno y esperar que el
equipo se adapte automticamente. Es mejor crear el equipo y que ste
configure su propio entorno de desarrollo en base a sus necesidades.

DESARROLLAR SOFTWARE QUE FUNCIONA MS QUE CONSEGUIR

UNA BUENA DOCUMENTACIN.
La regla a seguir es no producir documentos a menos que sean
necesarios de forma inmediata para tomar un decisin importante.
Estos documentos deben ser cortos y centrarse en lo fundamental.

LA COLABORACIN CON EL CLIENTE MS QUE LA NEGOCIACIN

DE UN CONTRATO.
Se propone que exista una interaccin constante entre el cliente y el
equipo de desarrollo. Esta colaboracin entre ambos ser la que marque
la marcha del proyecto y asegure su xito.

RESPONDER
A
LOS
CAMBIOS
ESTRICTAMENTE UN PLAN.

MS

QUE

SEGUIR

La habilidad de responder a los cambios que puedan surgir a los largo

del proyecto (cambios en los requisitos, en la tecnologa, en el equipo,
etc.) determina tambin el xito o fracaso del mismo. Por lo tanto, la
planificacin no debe ser estricta sino flexible y abierta.

Los valores anteriores inspiran los doce principios del manifiesto. Los dos
primeros principios son generales y resumen gran parte del espritu gil. El
resto tienen que ver con el proceso a seguir y con el equipo de desarrollo, en
cuanto metas a seguir y organizacin del mismo. Los principios son:
I.
La prioridad es satisfacer al cliente mediante tempranas y continuas
entregas de software que le aporte un valor.
II.

Dar la bienvenida a los cambios. Se capturan los cambios para que el

cliente tenga una ventaja competitiva.

III.

Entregar frecuentemente software que funcione desde un par de

semanas a un par de meses, con el menor intervalo de tiempo
posible entre entregas.

IV.

La gente del negocio y los desarrolladores deben trabajar juntos a lo

largo del proyecto.

V.

Construir el proyecto en torno a individuos motivados. Darles el

entorno y el apoyo que necesitan y confiar en ellos para conseguir
finalizar el trabajo.

VI.

El dilogo cara a cara es el mtodo ms eficiente y efectivo para

comunicar informacin dentro de un equipo de desarrollo.

VII.

El software que funciona es la medida principal de progreso.

VIII.

Los procesos giles promueven un desarrollo sostenible. Los

promotores, desarrolladores y usuarios deberan ser capaces de
mantener una paz constante.
La atencin continua a la calidad tcnica y al buen diseo mejora la
agilidad.

IX.
X.

La simplicidad es esencial.

XI.

Las mejores arquitecturas, requisitos y diseos surgen de los equipos

organizados por s mismos.

XII.

En intervalos regulares, el equipo reflexiona respecto a cmo llegar a

ser ms efectivo, y segn esto ajusta su comportamiento.

Cada metodologa tiene caractersticas propias y hace hincapi en algunos

aspectos ms especficos. A continuacin se resumen otras metodologas
giles. La mayora de ellas ya estaban siendo utilizadas con xito en proyectos
reales pero les faltaba una mayor difusin y reconocimiento.

SCRUM.
Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco
para la gestin de proyectos, que se ha utilizado con xito durante los ltimos
10 aos. Est especialmente indicada para proyecto s con un rpido cambio de
requisitos.
Sus principales caractersticas se pueden resumir en dos.
I.
El desarrollo de software se realiza mediante iteraciones,
denominadas sprints, con una duracin de 30 das. El resultado de
cada sprint es un incremento ejecutable que se muestra al cliente.
II.
las reuniones a lo largo proyecto, entre ellas destaca la reunin diaria
de 15 minutos del equipo de desarrollo para coordinacin e
integracin.
Es un proceso en el que se aplican de manera regular un conjunto de mejores
prcticas para trabajar colaborativamente, en equipo, y obtener el mejor
resultado posible de un proyecto. Estas prcticas se apoyan unas a otras y su
seleccin tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos.
En Scrum se realizan entregas parciales y regulares del producto final,
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 pronto, donde los requisitos son
cambiantes o poco definidos, donde la innovacin, la competitividad,
la flexibilidad y la productividad son fundamentales.
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, cuando se necesita capacidad de
reaccin ante la competencia, cuando la moral de los equipos es baja y la
rotacin alta, cuando es necesario identificar y solucionar ineficiencias
sistemticamente o cuando se quiere trabajar utilizando un proceso
especializado en el desarrollo de producto.

Beneficios
Los principales beneficios que proporciona Scrum son:

Entrega mensual (o quincenal) de resultados (los requisitos ms

prioritarios en ese momento, ya completados) lo cual proporciona las
siguientes ventajas:
Gestin regular de las expectativas del cliente y basada en
resultados tangibles.
Resultados anticipados (time to market).
Flexibilidad y adaptacin respecto a las necesidades del cliente,
cambios en el mercado, etc.
Gestin sistemtica del Retorno de Inversin (ROI).
Mitigacin sistemtica de los riesgos del proyecto.
Productividad y calidad.
Alineamiento entre el cliente y el equipo de desarrollo.
Equipo motivado.

Cmo funciona
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 de producto final que sea
susceptible de ser entregado con el mnimo esfuerzo al cliente cuando lo solicite.
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.
Planificacin de la iteracin
El primer da de la iteracin se realiza la reunin de planificacin de la iteracin. Tiene
dos partes:
1. Seleccin de requisitos (4 horas mximo). El cliente presenta al equipo la
lista de requisitos priorizada 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.
2. Planificacin de la iteracin (4 horas mximo). El equipo elabora la lista de

tareas de la iteracin 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.

Ejecucin de la iteracin
Cada da el equipo realiza una reunin de sincronizacin (15 minutos mximo).
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 se merme su productividad.

Elimina los obstculos que el equipo no puede resolver por s mismo.

Protege 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. Tiene dos
partes:
1. Demostracin (4 horas mximo). 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, replanificando el proyecto.
2. Retrospectiva (4 horas mximo). El equipo analiza cmo ha sido su manera
de trabajar y cules son los problemas que podran impedirle progresar
adecuadamente, mejorando de manera continua su productividad. El Facilitador
se encargar de ir eliminando los obstculos identificados.

MODEL DRIVEN ARCHITECTURE

En los ltimos meses muchas organizaciones han empezado a centrar la
atencin en Model Driven Architecture (MDA) como una aproximacin al diseo
e implementacin de aplicaciones. Este es un hecho muy positivo por varias
razones. MDA fomenta el uso eficiente de los modelos de sistemas en el
proceso de desarrollo de software, y es compatible con la reutilizacin de las
mejores prcticas al crear familias de sistemas. Tal como se define por el
Object Management Group (OMG), MDA es una forma de organizar y gestionar
arquitecturas empresariales apoyadas por herramientas y servicios
automatizados, tanto para la definicin de los modelos y facilitar
transformaciones entre diferentes tipos de modelos.
Si bien las normas de MDA definidos OMG y terminologa para la creacin y
evolucin de los sistemas de software a escala de empresa se estn
ampliamente referenciados en la industria, slo recientemente la OMG y sus
miembros, incluyendo IBM Rational, ha sido capaz de ofrecer una orientacin
clara sobre lo que significa la MDA, donde nos encontramos en su evolucin,
qu aspectos de la MDA son posibles con la tecnologa actual, y cmo tomar
ventaja de la MDA en la prctica.
El concepto de MDA del OMG proporciona un enfoque abierto y neutral a la
interoperabilidad del sistema a travs de estndares de modelado establecidos
de OMG: Unified Modeling Language (UML), Meta-Object Facility (MOF), XML
Metadata Interchange (XMI), y Common Almacn Meta-modelo (CWM). Las
descripciones de las soluciones empresariales pueden ser construidas usando
estos estndares de modelado y se transforma en una plataforma abierta o
propietaria importante, incluyendo CORBA, J2EE, .NET y plataformas basadas
en la Web.
Antes de profundizar ms en MDA, vamos a considerar los conceptos
fundamentales y los beneficios del modelado en desarrollo de software.

LA JUSTIFICACIN PARA EL MODELADO

Los modelos proporcionan abstracciones de un sistema fsico que permiten a
los ingenieros de razonar acerca de ese sistema, ignorando detalles superfluos
mientras se centra en los relevantes. Todas las formas de ingeniera se basan
en modelos para entender los sistemas complejos, en el mundo real. Los
modelos se utilizan de muchas maneras: para predecir las cualidades del
sistema, razn acerca de las propiedades especficas cuando se cambian los
aspectos del sistema, y comunicar las caractersticas clave del sistema para las
distintas partes interesadas. Los modelos pueden ser desarrollados como un
precursor de la aplicacin del sistema fsico, o pueden ser derivados de un

sistema existente o un sistema en el desarrollo como una ayuda para la

comprensin de su comportamiento.

PUNTOS DE VISTA Y LA TRANSFORMACIN DEL MODELO

Debido a que muchos aspectos de un sistema pueden ser de su inters, puede
utilizar varios conceptos de modelado y anotaciones para resaltar una o ms
perspectivas particulares, o puntos de vista, de ese sistema, dependiendo de lo
que es relevante en cualquier punto en el tiempo. Por otra parte, en algunos
casos, puede aumentar los modelos con indirectas, o reglas, que ayudan a
transformarlos de una representacin a otra. A menudo es necesario convertir
a diferentes vistas del sistema a un nivel equivalente de abstraccin (por
ejemplo, a partir de una vista estructural de una vista de comportamiento), y
una transformacin de modelos facilita esto. En otros casos, una
transformacin convierte los modelos que ofrecen una perspectiva particular
de un nivel de abstraccin a otro, por lo general a partir de un punto de vista
ms abstracto a menos abstracto, aadiendo ms detalle suministrado por las
reglas de transformacin.

MODELOS, MODELADO, Y MDA

Modelos y dirigido por el modelo de desarrollo de software estn en el corazn
del enfoque MDA. As que para entender mejor la MDA, es conveniente primer
vistazo a cmo los desarrolladores de aplicaciones empresariales se
aprovechan de modelado.
En el mundo de la ingeniera de software, modelado tiene una rica tradicin,
que se remonta a los primeros das de programacin. Las innovaciones ms
recientes se han centrado en las notaciones y herramientas que permiten a los
usuarios a expresar puntos de vista del sistema de valor a los arquitectos y
desarrolladores de software de manera que se asignan fcilmente en el cdigo
de lenguaje de programacin que puede ser compilado para una plataforma de
sistema operativo en particular. El estado actual de esta prctica emplea el
Unified Modeling Language (UML) como la notacin de modelado primario. El
UML permite a los equipos de desarrollo para capturar una variedad de
caractersticas
importantes
de
un
sistema
en
los
modelos
correspondientes. Transformaciones entre estos modelos son principalmente
manuales.

Herramientas de modelado UML suelen apoyar las relaciones requisitos de

trazabilidad y de dependencia entre los elementos de modelado, con los
justificantes y ofertas de consultora complementarios orientados a la gua de
mejores prcticas sobre cmo mantener sincronizados los modelos como parte
de un esfuerzo de desarrollo a gran escala.
Una forma til para caracterizar la prctica actual es mirar a las diferentes
formas en que los modelos estn sincronizados con el cdigo fuente que
ayudan a describir. que muestra el espectro de mtodos de modelizacin en
uso por los profesionales de software hoy en da. Cada categora identifica un
uso particular de los modelos en la asistencia a los profesionales de software
para crear aplicaciones en ejecucin (cdigo) para una plataforma de ejecucin
especfica, y la relacin entre los modelos y el cdigo.

LOS PRINCIPIOS DE MDA

Modelado ha tenido un impacto importante en la ingeniera de software, y es
fundamental para el xito de todas las soluciones a escala empresarial. Sin
embargo, hay una gran variedad en lo que los modelos representan y cmo se
utilizan. Una pregunta interesante es: cul de estos enfoques podemos
describir como "modelo-driven"? Si se crea una visualizacin de una parte de
un sistema, significa que estoy practicando MDA? Desafortunadamente, no
hay una respuesta definitiva. Por el contrario, existe un consenso creciente de
que la MDA est ms estrechamente asociado con enfoques en los que el
cdigo es (semi) generada automticamente a partir de los modelos ms
abstractos, y que emplean lenguajes de especificacin estndar para la
descripcin de esos modelos.
Hay cuatro principios subyacentes de la vista de OMG de MDA:
Modelos expresados en una notacin bien definida son una piedra
angular para la comprensin de sistemas para soluciones de escala
empresarial.
2. La construccin de sistemas puede ser organizada en torno a un
conjunto de modelos mediante la imposicin de una serie de
transformaciones
entre
modelos,
organizados
en
un
marco
arquitectnico de capas y transformaciones.
1.

Un respaldo formal para describir los modelos en un conjunto de

metamodelos facilita la integracin y transformacin significativa entre
los modelos, y es la base para la automatizacin a travs de
herramientas.
4. La aceptacin y la amplia adopcin de este enfoque basado en el
modelo requiere de estndares de la industria para proporcionar la
apertura a los consumidores, y fomentar la competencia entre los
proveedores.
3.

Para apoyar estos principios, la OMG ha definido un conjunto especfico de

capas y transformaciones que proporcionan un marco conceptual y el
vocabulario para la MDA. En particular, OMG identifica cuatro tipos de modelos:
Computacin Independiente Model (CIM), Plataforma Modelo Independiente
(PIM), Plataforma modelo especfico (PSM) descritos por un modelo de
plataforma (PM), y un modelo especfico de implementacin (ISM).
Para MDA, una "plataforma" slo tiene sentido en relacin con un punto de
vista particular - en otras palabras, PIM de una persona es PSM de otra
persona. Por ejemplo, un modelo puede ser un PIM con respecto a la eleccin
de middleware de comunicacin si ese modelo no prescribe una eleccin
particular de la tecnologa middleware. Sin embargo, cuando se toma la
decisin de usar particular, middleware tales como CORBA, el modelo se
transforma en un PSM-CORBA especfico.

Tres ideas son importantes aqu con respecto a la naturaleza abstracta de un

modelo y la aplicacin detallada que representa:
Modelo de clasificacin.
Podemos clasificar los modelos de software y del sistema en trminos
de cmo de manera explcita que representan aspectos de las
plataformas como objetivo. En todo el desarrollo de software y el sistema
existen limitaciones importantes que implica la seleccin de idiomas, el
hardware, la topologa de red, protocolos de comunicacin y la
infraestructura, y as sucesivamente. Cada uno de estos se pueden
considerar elementos de una solucin "plataforma". Un enfoque MDA nos
ayuda a centrarse en lo que es esencial para los aspectos del negocio de
una solucin que est siendo diseado, separado de los detalles de esa
"plataforma".
Independencia de la plataforma.

La nocin de una "plataforma" es bastante complejo y altamente

dependiente del contexto. Por ejemplo, en algunas situaciones, la
plataforma puede ser el sistema operativo y utilidades asociadas; en
algunas situaciones puede ser una infraestructura de tecnologa
representada por un modelo de programacin bien definido como J2EE
o .Net; en otras situaciones, es un caso particular de una topologa de
hardware. En cualquier caso, es ms importante pensar en trminos de
lo que los modelos a diferentes niveles de abstraccin se utilizan para
diferentes propsitos qu, en lugar de ser distrado con la definicin de
la "plataforma".
Transformacin de modelos y refinamiento.
Al pensar en el desarrollo de software y sistema como un conjunto de
refinamientos modelo, las transformaciones entre modelos se convierten
en elementos de primer nivel del proceso de desarrollo. Esto es
importante debido a que una gran cantidad de trabajo tiene lugar en la
definicin de estas transformaciones, a menudo requieren un
conocimiento especializado del dominio de negocio, las tecnologas que
estn siendo utilizados para la ejecucin, o ambos. Podemos mejorar la
eficiencia y la calidad de los sistemas mediante la captura de estas
transformaciones de forma explcita y de volver a utilizar
constantemente a travs de soluciones. Si estn bien definidos los
diferentes modelos abstractos, podemos utilizar transformaciones
estndar. Por ejemplo, entre los modelos de diseo expresados en UML e
implementaciones en J2EE, podemos, en muchos casos, utilizar patrones
de transformacin de UML a J2EE bien entendidos que pueden ser
aplicadas consistentemente, validados y automatizados.

Bibliografa
https://www.ibm.com/developerworks/community/wikis/home?
lang=en#!/wiki/Rational+Team+Concert+for+Scrum+Projects/page/SCRUM+c
omo+metodolog%C3%ADa
,
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/apr0
5/brown/
Metodologas giles en el
Desarrollo de Software
Alicante, 12 de Noviembre de 2003
Taller realizado en el marco de las VIII Jornadas de Ingeniera del
Software y Bases de Datos, JISBD 2003.
Alicante, del 12 al 14 de Noviembre de 2003