METODOLOGIA CRYSTAL

HISTORIA DE LOS PROCESOS DE DESARROLLO

Uno de los grandes pasos dados en la industria del software fue aquel en que
se plasm
o el denominado modelo de cascada ya que sirvio como base para la
formulaci
on del an
alisis estructurado, el cual fue uno de los precursores en
el camino hacia la aplicaci
on de practicas estandarizadas dentro de la ingeniera de software. Este modelo surge como respuesta al modelo codificar y
probar que era el que predominaba en la decada de los sesenta. En esta epoca
ya existan modelos iterativos e incremental espero no eran disciplinados ni
estaban formalizados. A consecuencia de esta realidad, la idea de tener un
modelo que ordenara el proceso de desarrollo y que pareca bastante sencillo
de llevar a la pr
actica hizo que el modelo en cascada tuviese gran promocion.
Este modelo se basaba en el desarrollo en forma de cascada ya que se requera
de la finalizaci
on de la etapa anterior para empezar la siguiente. Esto degeneraba en un congelamiento temprano de los requerimientos, los cuales
al presentar cambios requeran gran esfuerzo en retrabajo. Otra opcion era
no permitir cambio alguno a los requerimientos una vez que se iniciara el
desarrollo lo que traa aparejado que el usuario no vea la aplicacion hasta
que ya estaba construida y una vez que interactuaba no cubra sus necesidades. Asimismo, dadas las caractersticas inherentes del modelo, la fase de
implementaci
on del mismo requera el desarrollo de los modulos en forma
independiente con las correspondientes pruebas unitarias, y en la siguiente
fase, se realizaba la integraci
on de los mismos. Esto traa grandes inconvenientes debido a que todo estaba probado en forma unitaria sin interaccion
con los dem
as m
odulos. Las sorpresas llegaban cuando se integraban estas
piezas para formar la aplicaci
on; lo cual inevitablemente desembocaba en un
retraso del proyecto, sacrificando la calidad del mismo. De esta forma y en
forma bastante temprana en algunos casos, fueron surgiendo diversos procesos denominados iterativos que proponan lidiar con la impredictibilidad
del software (subsanando muchas de las falencias del modelo en cascada)
mitigando los riesgos en forma temprana. Los procesos iterativos de los
cuales se desprenderan diversas instancias, como son el modelo iterativo e
incremental, el modelo en espiral, el modelo basado en prototipo, el modelo
SLCD, el MBASE, el RUP, etc. Del modelo en espiral desarrollado por Bar
ry Boehm surgi
o una de las ideas fundamentales que las metodologas posteriores adoptaran: el temprano analisis de riesgos. El modelo en espiral,
de car
acter iterativo en sus primeras fases, plantea la necesidad de realizar
al principio diversas iteraciones dirigidas a mitigar los riesgos mas crticos
relevados en el proyecto mediante la realizacion de prototipos o simulaciones
de tipo desechables tendientes a probar alg
un concepto. Una vez que esos
prototipos son validados se suceden iteraciones del tipo: determinar objetivos, evaluar, desarrollar, planear. Una vez que se tena el dise
no detallado
1

y validado por el cliente, se implementaba el software siguiendo las etapas de

un modelo en cascada. Esta es una falla importante del modelo ya que no se
acomoda a la posibilidad de cambios una vez que se inicia la construccion.
Todas las crticas que se le hacan al modelo en cascada se aplican a estas fases del modelo en espiral. Fue el mismo Barry Boehm, quien en un
artculo describe tres hitos crticos a ser utilizados en cualquier proyecto
para poder planificar y controlar el progreso del mismo, dando visibilidad
a los stakeholders. Estos hitos estan relacionados con las etapas de avance
que se van dando a lo largo de un proyecto de acuerdo a como ocurren las
actividades de ingeniera (que componen los espirales del modelo en espiral)
a las actividades de produccion (que componen la construccion en cascada
del software). Su impacto en la industria del software ha sido tan importante que uno de los procesos mas utilizados en la actualidad, el RUP, los
incorpora. Estos hitos son: - Objetivos del Ciclo de Vida - Arquitectura
del Ciclo de Vida - Capacidad de Operacion Inicial El primer hito finaliza
con la definici
on del alcance del software a construir, la identificacion de los
stakeholders, y el delineamiento del plan de desarrollo del sistema. El mismo
ocurre al final de la fase de Concepcion seg
un el RUP. El segundo hito finaliza con el delineamiento de la arquitectura del sistema, la resolucion de todos
los riesgos crticos del proyecto, y el refinamiento de los objetivos y el alcance
del sistema. A partir de este hito, se comienza la construccion en forma masiva del sistema, lleg
andose a utilizar el maximo de recursos en el proyecto.
Asimismo, comienzan las fases mas predecibles en cierta medida del desarrollo. El mismo corresponde al hito final de la fase de Elaboracion seg
un
el RUP. El u
ltimo de los hitos corresponde a la entrega del primer release
del software, que incorpora la funcionalidad definida en la correspondiente
iteraci
on. Tambien se espera el tener material de entrenamiento, como un
Manual del Usuario y Manual de Operaciones. Este hito se corresponde
con el hito final de la fase de Construccion seg
un el RUP. Lo que resulto
interesante de estos hitos propuestos por Boehm es que los mismos son independientes del proceso de desarrollo elegido. Como se ha mencionado,
uno de los procesos con m
as influencia en la comunidad del software ha
sido el RUP, el cual, es uno de los primeros procesos que es vendido como
un producto. La idea de los creadores del RUP es que el mismo fuera un
repositorio de todas las ideas vigentes y las denominadas buenas practicas
de la Ingeniera de Software. Sin embargo, al intentar abarcar proyectos
de envergaduras tan dispares como podran ser la construccion de un sistema de radares para portaviones versus la construccion de una registracion
de usuarios para una peque
na consultora, el RUP pierde la granularidad
necesaria para describir en detalle uno de los factores mas trascendentes
de cualquier desarrollo de software: las personas. Esta es una de las ra
zones principales del advenimiento de las denominadas Metodologas Agiles.


LAS METODOLOG
IAS AGILES
A principios de la decada del 90, surgio un enfoque que fue bastante
revolucionario para su momento ya que iba en contra de toda creencia de
que mediante procesos altamente definidos se iba a lograr obtener software
en tiempo, costo y con la requerida calidad. El enfoque fue planteado por
primera vez por Martin y se dio a conocer en la comunidad de Ingeniera de
Software con el nombre de RAD o Rapid Application Development. RAD
consista en un entorno de desarrollo altamente productivo, en el que participaban grupos peque
nos de programadores utilizando herramientas que
generaban c
odigo en forma automatica tomando como entradas sintaxis de
alto nivel. En general, se considera que este fue uno de los primeros hitos en pos de la agilidad en los procesos de desarrollo. La historia de las

Metodologas Agiles
y su apreciacion como tales en la comunidad de la Ingeniera de Software tiene sus inicios en la creacion de una de las metodologas
utilizada como arquetipo: XP - eXtreme Programming, que nace de la mente
de Kent Beck, tomando ideas recopiladas junto a Ward Cunningham. Durante 1996, Beck es llamado por Chrysler como asesor del proyecto Chrysler
Comprehensive Compensation (C3) payroll system. Dada la poca calidad
del sistema que se estaba desarrollando, Beck decide tirar todo el codigo
y empezar de cero utilizando las practicas que el haba ido definiendo a lo
largo del tiempo. El sistema, que administra la liquidacion de aproximadamente 10.000 empleados, y consiste de 2.000 clases y 30.000 metodos, es
puesto en operaci
on en Mayo de 1997 casi respetando el calendario propuesto. Como consecuencia del exito de dicho proyecto, Kent Beck dio origen
a XP iniciando el movimiento de metodologas agiles al que se anexaran
otras metodologas surgidas mucho antes que el propio Beck fuera convocado
por Chrysler. Es as como que este tipo de metodologas fueron inicialmente
llamadas metodologas livianas, sin embargo, a
un no contaban con una
aprobaci
on pues se le consideraba por muchos desarrolladores como meramente intuitiva. Luego, con el pasar de los a
nos, en febrero de 2001, tras
una reuni
on celebrada en Utah-EEUU, nace formalmente el termino agil
aplicado al desarrollo de software. En esta misma reunion participan un
grupo de 17 expertos de la industria del software, incluyendo algunos de los
creadores o impulsores de metodologas de software con el objetivo de esbozar los valores y principios que deberan permitir a los equipos desarrollar
software r
apidamente y respondiendo a los cambios que puedan surgir a lo
largo del proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rgidos y dirigidos
por la documentaci
on que se genera en cada una de las actividades desarrolladas. Tras esta reuni
on se creo The Agile Alliance, una organizacion,
sin
animo de lucro, dedicada a promover los conceptos relacionados con el
desarrollo
agil de software y ayudar a las organizaciones para que adopten
3


dichos conceptos. El punto de partida fue el Manifiesto Agil,
un documento
que resume la filosofa
agil.
USAR METODOLOG

POR QUE
IAS AGILES?

Tomando las ideas de la Tabla No 1 podemos decir que las metodologas

tradicionales presentan los siguientes problemas a la hora de abordar proyectos:
- Existen unas costosas fases previas de especificacion de requisitos, analisis
y dise
no. La correcci
on durante el desarrollo de errores introducidos en
estas fases ser
a costosa, es decir, se pierde flexibilidad ante los cambios.
- El proceso de desarrollo esta encorsetado por documentos firmados.
- El desarrollo es m
as lento. Es difcil para los desarrolladores entender un
sistema
complejo
en
su
globalidad.
Las metodologas
agiles de desarrollo estan especialmente indicadas en proyectos con requisitos poco definidos o cambiantes. Estas metodologas se aplican bien en equipos peque
nos que resuelven problemas concretos, lo que no
est
a re
nido con su aplicaci
on en el desarrollo de grandes sistemas, ya que
una correcta modularizaci
on de los mismos es fundamental para su exitosa
implantaci
on. Dividir el trabajo en modulos abordables minimiza los fallos
y el coste. Las metodologas
agiles presentan diversas ventajas, entre las que
podemos
destacar:
- Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo
- Entrega continua y en plazos breves de software funcional
- Trabajo conjunto entre el cliente y el equipo de desarrollo
- Importancia de la simplicidad, eliminado el trabajo innecesario.
- Atenci
on continua a la excelencia tecnica y al buen dise
no
- Mejora continua de los procesos y el equipo de desarrollo.

METODOLOG
IA AGIL
DE DESARROLLO DE SOFTWARE
CRYSTAL

En los inicios de 1990, en un estudio realizado en IBM se llego a los siguientes acuerdos (Cockburn, 2001). Los equipos exitosos enfatizaban que no
haban seguido metodos formales ni herramientas CASE y que haban estimulado la comunicaci
on y los test. Los equipos con problemas no entendan
sus fallas o si haban cumplido con los metodos formales.

Qu
e es Crystal Clear

Crystal Clear no es una metodologa en si misma sino una familia de

metodologas con un c
odigo genetico com
un. El nombre Crystal deriva
de la caracterizaci
on de los proyectos seg
un 2 dimensiones, tama
no y
complejidad (como en los minerales, color y dureza).

Por ejemplo.
- Clear es para equipos de hasta 8 personas o menos.
- Amarillo para equipos entre 10 a 20 personas.
- Naranja para equipos entre 20 a 50 persona.
- Roja para equipos entre 50 a 100 personas.
- Azul para equipos entre 100 a 200 personas.

CC puede ser usado en proyectos peque

nos y como casi todos los otros
metodos, CC consiste en valores, tecnicas y procesos.
La familia de metodologas Crystal comparten con la XP una orientacion
humana, pero esta centralizacion en la gente se hace de una manera
diferente. Alistair considera que las personas encuentran difcil seguir un
proceso disciplinado, as que mas que seguir la alta disciplina de la XP,
Alistair explora la metodologa menos disciplinada que a
un podra tener
exito, intercambiando conscientemente productividad por facilidad de
considera que aunque Crystal es menos productivo que la
ejecuci
on. El
XP, m
as personas ser
an capaces de seguirlo.
Se trata de un conjunto de metodologas para el desarrollo de software
caracterizadas por estar centradas en las personas que componen el equipo
y la reducci
on al m
aximo del n
umero de artefactos producidos.
ESCALA COCKBURN DE CLASIFICACION DE
PROYECTOS
Esta escala tiene como objetivo realizar una clasificacion de los proyectos
de desarrollo de software en funcion del grado de formalidad que requeran
a lo largo de su ciclo de vida. Esta escala tiene una vocacion generalista y
por tanto enfocada exclusivamente al desarrollo mediante metodologas
agiles. Pone de manifiesto que no todos los proyectos son iguales y cada
uno requiere dedicarle esfuerzos desde su punto de vista metodologico
acorde a su naturaleza, con el objetivo de optimizar su coste y duracion.
La clasificaci
on de los proyectos se realiza en funcion de su tama
no y
5

criticidad.
a. De acuerdo a su tama
no
Se le asigna un valor en funcion del n
umero de personas que participaran.
Por regla general se eligen valores de la siguiente secuencia:
- 6 (proyectos entre 3 y 6 personas)
- 20 (proyectos entre 7 y 20 personas)
- 40 (proyectos entre 21 y 40 personas)
- 100 (proyectos entre 41 y 100 personas)
- 200 (proyectos entre 101 y 200)
b. De acuerdo a su Criticidad: Se le asigna una de las siguientes opciones
en funci
on del peor de los casos que se pueda producir en el caso de un
fallo del sistema.
- L: Perdida de una Vida
- E: Importante perdida economica que puede poner en riesgo la
continuidad de la organizaci
on. (Dinero Esencial)
- D: Perdida econ
omica no significativa (Dinero Discrecional)
- C: Comodidad.
C
odigo de Colores
La familia cristal dispone de un codigo de color para marcar la complejidad
de una metodologa: cuanto mas oscuro un color, mas pesado es el metodo.
Cuanto m
as crtico es un sistema, mas rigor se requiere. El cromatico se
aplica a una forma tabular elaborada por Cockburn que se usa en muchas
metodologas agiles para situar el rango de complejidad. Caractersticas
1) Entrega frecuente. Consiste en entregar software a los clientes con
frecuencia, no solamente en compilar el codigo. La frecuencia dependera
del proyecto, pero puede ser diaria, semanal o mensual.
2) Comunicaci
on osm
otica. Todos juntos en el mismo cuarto. Una variante
especial es disponer en la sala de un experto dise
nador senior y discutir
respecto del tema que se trate.
3) Seguridad personal. Hablar con los compa
neros cuando algo molesta
dentro del grupo.
4) Foco. Saber lo que se est
a haciendo y tener la tranquilidad y el tiempo
para hacerlo.
5) F
acil acceso a usuarios expertos. Tener alguna comunicacion con
expertos desarrolladores.

El C
odigo Gen
etico

Consisten en: - Un modelo de juegos cooperativos Este modelo ve al

desarrollo de software como una serie de partidos que consisten en inventar
y comunicar. Cada partido es diferente y tiene como objetivo entregar
software y prepararse para el siguiente juego. Esto permite al equipo
trabajar concentrado y en forma efectiva con un objetivo claro cada vez.
- Prioridades
Crystal Clear establece un conjunto de prioridades y principios que sirven
de gua para la toma de decisiones.
Eficiencia en el desarrollo: para hacer que los proyectos sean
econ
omicamente 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
Frecuencia en las entregas: entregar al usuario funcionalidad usable
con una frecuencia de entre 2 semanas y no mas de un mes.
Comunicaci
on: Crystal Clear toma como uno de sus pilares a la
comunicaci
on. Promueve pr
acticas 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
peri
odicas de reflexi
on que permitan crecer y hacernos mas eficientes.
Estas tres propiedades son obligatorias para Crystal Clear, las siguientes
pueden agregarse en la medida de las necesidades de cada grupo y proyecto.
Seguridad personal: lograr que cada miembro del team pueda sentirse
comodo con el trabajo y el entorno.
Concentraci
on: las entregas frecuentes permiten que cada desarrollador
puede enfocar de a un problema evitando dispersiones.
F
acil acceso a usuarios clave: tratar de hacer que el usuario sea una
parte m
as del equipo es fundamental para ir depurando errores de manera
temprana.
Entorno tecnico con: i - Testing automatizado (incorporacion, por
ejemplo, de UnitTest) - ii. Integracion frecuente (uso de herramientas
especficas como Cruise Control).
- Principios
El grado de detalle necesario en documentar requerimientos, dise
no,
planeamiento, etc, vara seg
un el proyecto.
Es imposible eliminar toda documentacion pero puede ser reducida
logrando un modo de comunicacion mas accesible, informal y preciso que
7

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 asignacion.
-Estrategias
Ni las estrategias ni las tecnicas son mandatorias para Crystal Clear. Pero
es bueno tener en cuenta alguna de ellas al momento de empezar a
trabajar.
Tres de las estrategias que estan mas relacionadas son las de apuntar a
tener Victorias Tempranas, arrancar el desarrollo de lo que se denomina
un Esqueleto que Camine y pensar siempre en hacer Rearquitectura
Incremental van de la mano.
El poder arrancar el proceso a partir de un esqueleto sobre el cual se ira
agregando funcionalidad en cada una de las entregas ayuda a que se vean
los avances desde el comienzo (aunque sea una simple pantalla de ABM
que se conecta con la base de datos y muestra un solo dato). A medida que
se avanza en el proceso, la rearquitectura permitira ir agregando mas
cuerpo al esqueleto inicial.
Todas describen una forma de tomar ventaja del desarrollo incremental
para establecer valor desde el principio.