Metodologas giles:

- FDD
- AUP
- Crystal Clear
- DSDM

lvaro Yuste Torregrosa

Carlos Sanchs Server
Javier Snchez Riquelme
Carlos Meca Lpez

Featured Driven Development (FDD)

Introduccin.

La iniciativa de Desarrollo Dirigida por Rasgos es un tipo de metodologa

gil que rige su arquitectura por las funcionalidades del programa a
implementar. Como cualquier otra metodologa de esta corriente,
quiere romper con la nocin de planea el trabajo y trabaja el plan, y
sigue un progreso ms adaptativo y dinmico. No enfatiza los
requerimientos y la generacin de documentacin previa, si no que se
centra en realizar las fases de diseo y construccin. Sin embargo se
preocupa mucho de la calidad del producto, ya que insiste en el
monitoreo constante.
De su historia podemos remarcar que fue desarrollado por Peter Coad,
Eric Lefebvre y Jeff DeLuca, siendo este ltimo en que lo llev a cabo
por primera vez en un caso real de misin crtica. Se le encomend la
tarea de rescatar un proyecto que haba durado dos aos desde su
inicio. Pero ste todava no posea ni una sola lnea de cdigo, teniendo
ya 3500 pginas de documentacin. El rescate fue un xito. Sin
embargo no comenz a utilizarse de manera considerablemente asidua
hasta finales de los 90, para implementar grandes aplicaciones
bancarias.

Caractersticas.

Como algunas otras metodologas giles, se basa en un proceso

iterativo, pero en este caso es parcial, como ya describiremos en el
apartado de Fases. Sin embargo, como hemos dicho, la principal
propiedad del FDD es la orientacin de su arquitectura dirigida los
rasgos o funcionalidades del programa a producir. As nos centraremos
en definir este concepto de feature para aclarar por extensin cmo
trabaja la metodologa.
En FDD, las funcionalidades son lo que en Extreme Programing eran las
historias de usuario, son el eje de trabajo. Se escriben utilizando el
lenguaje del dominio, de manera especfica, sin cabida a
ambigedades y usando una estructura similar a: <accin> [un|el]
<resultado>
[de|a|para|por|]
<objeto>
[con|para|de]
<parmetros>. El <objeto> identifica la clase en el modelo de dominio,
el agente que realiza la operacin, la <accin>; que es el mtodo o la
funcin encapsulada en dicha clase y que tiene como valor de salida el
<resultado>.
Cada una de las funcionalidades equivale a un requisito estipulado
previamente por el patrocinador del producto. Tiene siempre un
significado empresarial y describe algn valor de negocio.
Normalmente tambin es posible expresarlos como secuencia, cuando
existan requisitos para la disponibilidad de unos respecto de otros (el
documento que se genera en este caso, como veremos en los
artefactos es el Diagrama Secuencial UML).
El paradigma de programacin que se suele usar en esta clase de
metodologas es el FOP (Feature-Oriented Programming), o
Programacin orientada a rasgos. Este enfoque para sintetizar
productos software convierte los programas en una pila de capas, de
las cuales, cada una aporta una funcionalidad nueva al conjunto de
capas que envuelve. Siempre se trabaja aadiendo nuevo cdigo a un
programa ya existente, para que finalmente el resultado sea una
composicin de transformaciones con la superposicin de capas. Las
capas son lo que se pas a denominar features o funcionalidades,
para dar nombre al paradigma.

Fases.

Una de las principales peculiaridades de este mtodo de desarrollo de

sistemas software gil, con respecto al resto de sus anlogos, es que no
requiere la presencia del cliente todo lo asiduamente que se suele
demandar a lo largo de sus etapas. El peso de estas recae casi
ntegramente en los desarrolladores.
Las fases iniciales del progreso son secuenciales y nicas en el ciclo de
vida. La primera de todas ellas, cuando comienza el desarrollo, es la
realizacin de un modelo global. Aqu, los expertos del dominio, tienen
en cuenta el contexto y los requerimientos del sistema para, aportando
su visin, modelar el dominio dividindolo en las diferentes clases. Estas
reas seccionales se analizan detalladamente por separado
construyendo un diagrama de objetos para cada una.
A continuacin, los desarrolladores elaboran una lista de
funcionalidades (con la estructura que hemos explicado en el apartado
de caractersticas) que en conjunto engloban la funcionalidad total del
sistema. Se puede subdividir la lista en conjuntos dependiendo de la
semejanza y la dependencia entre funcionalidades. Esta lista
posteriormente se revisa por el cliente y por los encargados de
validacin. Una vez se posee la lista repasada y confirmada, se
comienza a desarrollar la planificacin por funcionalidad. En esta etapa
ya se ordenan en un diagrama, jerrquicamente los conjuntos de rasgos
segn su prioridad en el desarrollo, y se asignan a su vez a los
programadores jefes.
Una vez llegado a este punto, como algunas otras metodologas giles,
se basa en un proceso iterativo. Aunque a diferencia del resto, cada
iteracin solo engloba las dos fases finales, y no todas ellas. Estas fases
son el diseo y la construccin. En ellas, en cada iteracin, se
selecciona un subconjunto de rasgos a realizar de la lista y se despliega
primero diseando y revisando el diseo. Posteriormente se implementa
la funcionalidad y se realizan pruebas unitarias dentro de la
construccin (no hay una fase especifica y definida para las pruebas,
como ocurre en la mayora de metodologas). Para finalizar integrando
el cdigo e inspeccionndolo. As una y otra vez, en iteraciones que
pueden durar desde unos pocos das hasta un mximo de dos semanas.

Fases de FDD

Roles.

Una de las principales crticas que propinan a este tipo de metodologa

es la excesiva jerarquizacin dentro de sus roles. Algunos consideran
que para conservar su carcter gil ste debera de ser ms liviana o
sencilla. An as, las responsabilidades que recaen sobre los
desarrolladores se pueden clasificar en tres grandes grupos segn su
peso en el supuesto organigrama empresarial de desarrollo.

El primer grupo lo forman los roles clave que como su nombre indica son
indispensables para el progreso del sistema. En este grupo se encuentra
el administrador de proyecto, que es quien siempre tiene la ltima
palabra en visin, cronograma y seleccin del personal. De la parte ms
tcnica est encargado el arquitecto jefe, que controla el diseo global
y la implementacin de las diferentes funcionalidades desde el nivel
ms alto. Quien se preocupa de que todas se desarrollen
correctamente es el manager de desarrollo, encargndose de los
conflictos en el equipo y de resolver problemas referentes a los recursos.

A un nivel ms bajo, pero en el mismo grupo, se encuentra el

programador jefe, quien analiza los requerimientos y tras acabar el
diseo, selecciona los rasgos que se desarrollarn en cada iteracin.
ste est al mando de los propietarios de clase, a quienes les asigna
rasgos propios para que se responsabilicen de su implementacin, y
participen en la decisin de incluirlos o no en la siguiente iteracin. Y por
ltimo, para completar los roles clave se tiene el experto de dominio,
que puede personificarse en el cliente, el patrocinador o un analista de
negocio. Su tarea es controlar los requerimientos y su correcta cobertura
en el desarrollo.

Para complementar a estos cargos, tambin son necesarios los llamados

roles de soporte. Aqu se encuentra el administrador de entrega, que es
quien se rene con el programador jefe para revisar sus reportes y
transmitrselos al manager de desarrollo. Controla en general el avance
y se lo comunica al cliente semanalmente. Por otro lado se tiene al gur
del lenguaje, que es quien conoce a la perfeccin la tecnologa de
codificacin que se est utilizando, y est a disposicin de los
desarrolladores para aclarar cualquier cuestin referente a ella.

En este grupo tambin existe el rol de manager de dominio, es quien

organiza y lidera al grupo de expertos de dominio, y resuelva sus
diferencias a la hora de concretar los requerimientos del sistema.
Adems, otro rol de soporte es el ingeniero de construccin, que se
encarga de preparar, mantener e impulsar el proceso de construccin
a la vez que controla las versiones resultado de cada iteracin y publica
la documentacin relevante. Tambin se cuenta con el rol del
herramentista para la creacin de herramientas de soporte especficas
y la gestin tanto de bases de datos como de las webs. Por ltimo el
administrador del sistema es quien controla el ambiente de trabajo y
empaqueta el producto para cada entrega.

Para finalizar, el ltimo grupo es el de roles adicionales. En l se

encuentran los verificadores (personas que pueden llegar a ser
independientes del equipo del proyecto, que testean el sistema para
comprobar que cumple los requisitos del cliente), los encargados del
despliegue (son quienes adaptan la documentacin previa a la
requerida por el nuevo sistema a desarrollar y contribuyen a su
lanzamiento) y los escritores de documentos tcnicos (que preparan la
documentacin relevante para los usuarios).

Artefactos.
A lo largo del proceso, el primero y principal documento que se genera
es en el que se definen todas las funcionalidades de la aplicacin, el
Modelo de Dominio. ste se elabora utilizando la tcnica llamada
Unifieid Modeling Languaje (UML), como diagrama de clases, aunque
posteriormente fue mejorado por Peter Coad dando lugar al Domain
Neutral Component (DNC) y arquetipos de clase. A continuacin
observamos un ejemplo que modela el dominio de un hotel y las
conferencias que se realizan en l, en formato DNC.

DNC

Como hemos dicho, cada modelo funcionalidades se puede traducir al

instante en el artefacto llamado Diagrama Secuencial UML. En el caso
del ejemplo anterior, la conversin sera la siguiente:

Conclusin

Concluimos definiendo al FDD como una metodologa de desarrollo gil

destinada a proyectos cortos y de reducido personal, pero muy
escalable por otra parte. A diferencia de otras, no define explcitamente
una fase para la obtencin de requisitos ni para la realizacin de
pruebas. Sin embargo, al dividir el proyecto en unidades pequeas
(rasgos), esta metodologa es la ms adecuada para realizar un
seguimiento y una monitorizacin del progreso.
Respecto a la carga de trabajo que recae sobre los desarrolladores,
FDD podemos decir que es un proceso intermedio, basndonos en
genera ms documentacin que algunas metodologas giles, pero no
tanta como otras, y es en la fase de diseo, con sesiones de trabajo
conjuntas donde se decide la estructura de la arquitectura. En cuanto a
la relacin con el cliente, esta es fluida y sin excesivos formalismos,
basada en controles propios y una comunicacin constante.
Como puntos flacos de este tipo de desarrollo software observamos la
necesidad de poseer expertos en el equipo de trabajo que marquen
desde el principio el camino a seguir, con el modelo global. Adems,
como ya hemos comentado, existe demasiada jerarquizacin entre los
roles. Estos hechos pueden restarle fluidez al desarrollo. Pero sus
principales puntos fuertes son que disminuye en gran medida el riesgo
de los proyectos, con la constante monitorizacin de su calidad (sencilla
gracias a la divisin en rasgos) y las peridicas entregas tangibles
(gracias a la estructura iterativa de sus fases), y que adems es muy
adaptativo y permite cambios de ltimo momento.

Agile Unified Process

El AUP o Proceso Unificado Agil de Scott Ambler es una versin simplificada del
Proceso Unificado de Rational (RUP). Este describe de una manera simple y
fcil de entender la forma de desarrollar aplicaciones de software de negocio
usando tcnicas giles y conceptos que an se mantienen vlidos en RUP. El
AUP aplica tcnicas giles incluyendo Desarrollo Dirigido por Pruebas (test
driven development - TDD), Modelado Agil, Gestin de Cambios Agil, y
Refactorizacin de Base de Datos para mejorar la productividad. (RUP).

Disciplinas:
A diferencia del RUP, el AUP tiene tan solo 7 disciplinas:
1. Modelo. Entender el problema planteado por el proyecto e identificar
una solucin para abordar el problema.
2. Implementacin. Transformar el modelo(s) en cdigo ejecutable y
realizar pruebas de nivel bsico en concreto prueba de unidad.
3. Pruebas. Realizar una evaluacin objetiva para asegurarse la calidad.
Esto incluye encontrar defectos, asegurarse de que el sistema funciona
como debera y verificar que cumple los requisitos.
4. Desarrollo. Planificar la entrega del sistema y ejecutar el plan para
hacer que el sistema este disponible para el usuario final.
5. Administrar la Configuracin. Administrar el acceso a los artefactos del
proyecto. Esto incluye Esto incluye el seguimiento de versiones de
artefactos a travs del tiempo, asi como el control y la gestin de los
cambios a los mismos.
6. Administracin del Proyecto. Dirigir las actividades que toman parte en
el proyecto. Esto incluye la administracin de riesgos, dirigir personas
(asignarles tareas, llevar el seguimiento de su progreso, etc), y
coordinarse con personas y sistemas fuera del mbito del proyecto para
asegurarse que se entrega a tiempo y dentro del presuspuesto
7. Medio Ambiente. Apoyar el resto del esfuerzo, garantizando que el
proceso es adecuado, las guias (normas y directrices), y las
herramientas (hardware, software, etc) estn disponibles para el
equipo segn sea necesario.

Entrega de versiones incrementales con el tiempo:

En lugar del enfoque Big Bang de entregar el software todo en una
entrega en vez de entregar porciones (por ejemplo, la versin 1, versin 2, y as
sucesivamente), los equipos AUP suelen ofrecer versiones de desarrollo al final
de cada iteracin en las fases de pre-produccin. Una versin de desarrollo de

una aplicacin es algo que podra ser potencialmente lanzado si pasara los
controles de calidad de pre-produccin, pruebas y procesos de desarrollo.
En la imagen se observa que la primera versin de produccin suele
tomar mas tiempo de desarrollo que las dems; en la primera versin de un
sistema el equipo tiene que establecer las bases, lo que lleva mucho tiempo,
pero permitir que las versiones siguiente sean lanzadas mas rpido. La
entrega de la primera produccin puede tomar doce meses, la segunda
entrega, nueve meses, y luego, las siguientes versiones, se entregan cada seis
meses.

Un enfoque inicial en los problemas de implementacin no slo te

permite evitar los problemas, adems tambin te permite aprovechar la
experiencia obtenida durante el desarrollo. Por ejemplo, cuando se va a
implementar el software en tu rea de preparacin debes tomar notas de lo
que funciona y de lo que no, esas notas pueden servir como eje de las
secuencias de comandos de instalacin.

Principios:
1. Tus empleados saben que estn haciendo. Los empleados no van a
leerse los detalles de la documentacin del proceso, pero
necesitarn alguna orientacin de alto nivel y / o formacin de vez en
cuando. El producto del AUP propone enlaces para muchos de los
detalles, si estas interesados en ellos, pero no te fuerza a usarlos.
2. Simplicidad. Todo es descrito con precisin usando un puado de
paginas, pero sin pasarse.
3. Agilidad. El AUP se ajusta a los valores y principios del desarrollo gil de
software y de la Alianza gil.
4. Centrarse en actividades de alto valor. La atencin se centra en las
actividades que realmente cuentan, y no en cada cosa que pudiera
pasar a lo largo del desarrollo del proyecto.
5. Independecia de las Herramientas. Con la AUP se pueden utilizar
cualquier conjunto de herramientas que quiera el desarrolador. La
recomendacin es que utilice las herramientas que se adapten
mejor para el trabajo, que a menudo son herramientas simples.
6. Adaptar el AUP para que cumpla tus necesidades.
Bibliografa
http://www.ambysoft.com/unifiedprocess/agileUP.html
http://en.wikipedia.org/wiki/Agile_Unified_Process

Introduccin
DSDM (Dynamic System Development Method) es considerada la primera
metodologa gil y es la nica de ellas que ha sido declarada en un Consorcio
formado por 17 personas en Gran Bretaa en el ao 1994. El origen de esta
metodologa surgi como resultado de la bsqueda de una metodologa
pblica que se ajustase a cualquier herramienta de desarrollo de software y
que pudieras ser usado en proyectos RAD (Rapid Agile Development).
Creado con la experiencia de los fundadores en las prcticas que se llevaban
a cabo en la industria del software el primer modelo DSDM fue liberado en el
ao 1995. Su involucracin en la industria fue positivo por lo tanto el presidente
del Consenso decidi que sera til crear un libro sobre la aplicacin real del
mtodo a los proyectos de software.
Esta metodologa se basa en 9 principios que se apoyan en la ideologa RAD:
1. Es obligatoria la involucracin del usuario en el proyecto.
2. Los equipos de trabajo que desarrollen el proyecto deben de poder tomar
decisiones.
3. Se deben de producir entregas frecuentemente para comprobar el estado
del proyecto.
4. Las entregas deben cumplir los propsitos de modelo que se indicaron.
5. La solucin del negocio requiere un ciclo de desarrollo iterativo e
incremental.
6. Cualquier cambio en el desarrollo es posible, ya que este mtodo permite la
reversibilidad.
7. Los requerimientos del proyecto estn especificados a un alto nivel.
8. El testeo se integra en el mismo ciclo de vida.
9. La colaboracin y cooperacin entre los miembros interesados en el
proyecto es esencial.

Fases
El DSDM tiene un ciclo de desarrollo dividido en 5 fases:
Estudio de factibilidad: en esta fase se comprueba que la metodologa se
ajuste al proyecto que se va a llevar a cabo.
Estudio de negocio: Se establece la temprana comunicacin con el cliente
para llegar a las bases del sistema que deber de desarrollarse y como
debern de operarse. Se encuentran las necesidades de ms alto nivel del
software y se sientan las bases del desarrollo a su alrededor, junto a los costes
de tiempo y capital
Iteracin del modelo funcional: como su nombre indica es la primera iteracin
que se lleva a cabo en ella se deben de crear prototipos que puedan ser
usados y vaya supliendo necesidades del sistema a desarrollar en cada
iteracin. Esta iteracin se divide en 4 subfases principales: Acordar Plan, Crear
Prototipo, Revisar Prototipo e Identificar Prototipo funcional.
Iteracin de Diseo y Construccin: Crea el diseo de la aplicacin y se
construir atendiendo a este empleando el prototipo generado en la fase
anterior. Tambin est dividido en 4 subfases principales: Acordar plan, Crear
prototipos de diseo, Revisar los prototipos de diseo e Identificar estos
prototipos.
Implementacin e implantacin: En esta fase se produce el beta-testing
adems de ensear a los usuarios a usarla, se crean los manuales de uso de la
aplicacin, se encuentran errores en el uso si es que existen, se restablecen los
criterios del negocio y si hay errores se vuelve a comenzar el ciclo de vida, en
caso contrario se implantar el software entregndoselo al cliente (empresa o
usuarios).

El creador del modelo de desarrollo XP ha aceptado que la imagen

corporativa de DSDM es mejor que la de su modelo y se ha creado una
especie de fusin entre ambos llamada EnterpriseXP.

Roles de trabajo
La gente que trabaja junta de manera efectiva son el fundamento de un
proyecto exitoso. El DSDM reconoce esta necesidad y asigna papeles y
responsabilidades claros a cada persona en el proyecto, ya sean clientes o
proveedores. Estas dos comunidades deben trabajar hombro con hombro en
los proyectos DSDM rompiendo toda barrera que impida la comunicacin.
Los principales roles a desempear son:

Patrocinador de negocio:
Es el nivel ms alto en la parte del proyecto. Se encarga de resolver las dudas
de negocio a cualquier persona y decidir las decisiones financieras. Tiene la
gran responsabilidad de que el proyecto se desarrolle a la velocidad
adecuada y eficazmente.
Sus responsabilidades son:

Se encarga del caso de negocio del proyecto.

Asegura la viabilidad del proyecto con respecto al plan establecido.
Regula los fondos y otros recursos disponibles conforme a las
necesidades.
Controla que las tomas de decisiones de proceso solucionan las dudas
de manera efectiva y rpida.
Responde rpidamente ante problemas de tamao considerable y
encuentra soluciones eficaces.

Visionario de Negocio
Uno de los niveles ms altos del proyecto. Est involucrado de manera ms
activa que el Patrocinador, es el responsable de interpretar las necesidades
del Patrocinador y comunicar estas necesidades al equipo intentando
fielmente el plan de proyecto. Adems, aprovisionar al equipo de desarrollo
con una direccin estratgica y asegurndose de que la solucin escogida a
la hora de solucionar un problema conseguir los beneficios estimados.

Sus responsabilidades son:

Posee la mayor implicacin en el proceso de desarrollo de los papeles

organizativos.
Define la visin de proyecto.
Comunica y promueve la visin de negocio a todas las partes
interesadas.
Monitoriza el progreso del proyecto en la lnea de la visin de progreso.
Contribuye a los requerimientos, diseo y reseas clave.
Provee cambios a los requisitos de alto nivel.
Asegura la colaboracin entre los clientes y el rea de trabajo.
Comprueba que existan los recursos necesario.
Promociona la traduccin de la visin de negocio al mbito del trabajo.
Acta como rbitro definitivo entre desacuerdos de los miembros del
equipo.

Analista de Negocio
Est ntegramente integrado con el equipo de desarrollo de soluciones y es el
centro de las relaciones entre los encargados de gestionar el negocio y los
tcnicos, proveyendo una direccin acertada y decisiva provista por el equipo
de desarrollo de soluciones en una base diaria. Es el encargado de
comprobar que todas las necesidades se analizan correctamente y se reflejan
en el plan de desarrollo.
Otras de sus responsabilidades son:

Asegura la implicacin da a da de las decisiones de negocio en el

proyecto de manera fiel.
Controla el desarrollo, distribucin y base de la documentacin y
productos que tienen relacin con los requerimientos de negocio y su
interpretacin.

Desarrollador de soluciones
Interpreta los requerimientos de negocio y los traduce a una posible solucin
que logra solucionar las necesidades funcionales y no funcionales. Debera de
estar a tiempo completo desarrollndose en un nico proyecto.
Sus responsabilidades son:

Trabaja con los encargados del negocio y el equipo de pruebas de

soluciones con el fin de desarrollar iterativamente:

Una solucin desplegable.

Modelos requeridos para el apropiado control del desarrollo de
soluciones.
Modelos y documentacin requerida para el fin de sostener la
solucin en tiempo real de uso.

Escucha e interpreta los detalles de cambios en requerimientos,

soluciones, definiciones
Hacen sus propias pruebas y les dan ms prioridad que a las pruebas de
otros equipos.
Participa en cualquier trabajo de estimacin de calidad para asegurar
que los productos desarrollados se ajustan al plan.

Probador de soluciones
El probador de soluciones est totalmente integrado con el equipo de
desarrollo de soluciones y ejerce pruebas en relacin a la estrategia de
pruebas tcnicas plasmadas en el proyecto.
Sus responsabilidades son:

Trabaja con los encargados del negocio para definir los escenarios y
casos de prueba para la solucin propuesta.
En compromiso con la Estrategia Tcnica de Pruebas:
-

Visiona todos los tipos de soluciones como uno.

Crea productos de pruebas.
Reporta los resultados de las actividades de prueba al
coordinador tcnico de propsitos de calidad y seguridad.
Mantiene al lder del equipo informado de los resultados de las
pruebas.
Ayuda al Embajador y al Consejero de Negocio a asegurar que
pueden planear y llevar a cabo sus pruebas lo suficientemente
bien como para asegurar algunos puntos para asegurar que
ciertas reas estn cubiertas.

Consejero de Negocio:
Acta como compaero del Embajador de Negocio, el consejero es quien
provee de ayudas especficas y especialistas al desarrollo de soluciones o a la
prueba de estas. Normalmente ser un usuario con buenos conocimientos o
un beneficiario de la solucin, aunque quizs simplemente ofrece un apoyo a
las bases legales del proyecto.

Sus responsabilidades son:

Provee ayudas y aportes especialistas campos relevantes como el

entrenamiento de usuarios, decisiones da a da en proyectos,
organizando y controlando la aceptacin de los resultados de las
pruebas en el negocio.

Facilitador de Taller
Es el responsable de controlar el proceso de taller y el catalizador en la
preparacin y comunicacin. Tambin es el responsable del proceso en el
taller, aunque no del contenido de este.
Sus responsabilidades son:
Para cada taller:

Acepta el campo del que se ocupar el taller con el propietario de

este.
Planea el uso del taller.
Familiariza a los sujetos con el rea de trabajo.
Comprueba las capacidades de los trabajadores en el campo.
Asegura que comprender los objetivos del trabajo.
Anima a lo largo del proceso de trabajo.

Coach
El papel de Coach es una ayuda para el equipo con limitada experiencia que
usa DSDM para obtener todo el provecho del equipo posible. Debera de ser
una persona con certificacin acreditada para estar capacitado para llevar a
cabo el trabajo y tener los conocimientos necesarios.
Sus responsabilidades son:

Provee detallado conocimiento y experiencia sobre la metodologa y el

tema a tratar.
Confecciona el proceso de trabajo para adaptarlo a las necesidades
individuales del proyecto y el ambiente en el que se est operando.
Ayuda al equipo a usar tcnicas de la metodologa y prcticas, y
ayuda a aquellos fuera del equipo a apreciar la filosofa DSDM y su
valor.
Ayuda al equipo de trabajo a adentrarse en la colaboracin y la
cooperacin demandada por la metodologa DSDM y gil.
Mejora las aptitudes del equipo en DSDM.

Roles de especialistas:
Se encargan de aportar todo lo posible al campo de conocimiento del
proyecto en el cual son expertos e intentar trabajar con total eficacia
siguiendo las indicaciones de las capas superiores y adaptndose al plan de
desarrollo. La decisin de que todo acabe bien es suya al ser la mano de obra
principal el proyecto. Si su forma de trabajo no es la correcta sufren en mayor
medida la capacidad de ser sustituidos.

Esquema de Roles de Atern (ltimo DSDM)

Conclusin:
Como hemos podido comprobar en este trabajo el DSDM es una metodologa
que tiene en mente la limitacin de recursos y que la velocidad es importante.
Adems, se preocupa en gran medida por la colaboracin entre la empresa
de desarrollo y el cliente. Se interesa mucho por la coordinacin y el control
sobre la comunicacin colocndola en el centro de la metodologa.
En el DSDM se mezclan las bases para el desarrollo gil y una organizacin
estricta del equipo y la planificacin. Debera ser utilizado en proyectos que
puedan tener especificaciones cambiantes o que necesiten desarrollarse en
poco tiempo.
Y lo ms importante es que fue creado en un consenso de expertos lo que
hace que sea una metodologa ideal y de utilidad bien demostrada, adems
puede ser utilizada junto con otras metodologas.
La metodologa sufri una importante atencin debido a los beneficios del
feedback que se obtena de los usuarios que trabajaban codo con codo en el
proyecto.

Metodologa Crystal:
Introduccin:
La familia de metodologas Crystal nace a principios de los 90 por uno
desarrollador de software llamado Alistair Cockburn en base a sus
distintos proyectos y experiencia. Es un tipo de metodologa gil cuyo
nombre viene de su comparacin de los grupos con los minerales segn
su color o dureza. Se caracteriza por su gran nfasis en la comunicacin
y su tolerancia, que la hace ideal en casos en los que XP es inaplicable
o para proyectos pequeos.
Crystal se define con mucho nfasis en la comunicacin y de forma muy
ligera en relacin a los productos peridicos entregables. Aneja
interacciones cortas con feedback frecuente por parte del cliente,
minimizando los productos intermedios. Tambin cuenta con usuarios
reales que participan en la definicin del producto como tal.
Esta familia dispone de unos cdigos de color para marcar la
complejidad de cada una de las metodologas que la componen: de
ms oscuro y pesado a ms claro y ligero; y de mayor criticidad y rigor a
menor. Situadas en una grfica, estas metodologas siguen los
parmetros de Comodidad, Dinero Discrecional y Esencial y Vidas.
Segn este cdigo de colores, el Clear es para equipos de 8 o menos
personas, el Amarillo para equipos de entre 10 y 20 personas, el Naranja
para equipos de entre 20 y 50 personas, el Rojo de 50 a 100 y el Azul de
100 a 200.
Valores o Propiedades:
Como casi todos los mtodos, Crystal Clear consiste en valores, tcnicas
y procesos. Los siete valores o propiedades de esta metodologa son:

Entrega frecuente a los clientes, lo cual no consiste tan solo en

compilar, sino en evaluarlo. La frecuencia de esto depender de la
complicacin del proyecto. Al hacer esto aseguramos que el proyecto
cumple las condiciones que espera el cliente, evitando malentendidos
en el anlisis del sistema.

Comunicacin osmtica, es decir, todos los integrantes del grupo

debern estar desarrollando en la misma sala, con peridicas reuniones
separadas para que los concurrentes se concentren mejor.


Mejora reflexiva, es decir, periodos de reflexin para que los
desarrolladores puedan pensar, tomar notas, reflexionar, relajarse,
discutir... Se obtienen as una serie de hbitos o prcticas de desarrollo
que nos gustara mantener, una lista de lo que nos gustara intentar y de
lo que queremos evitar, generando as una mejora continua en nuestro
proyecto.

Comunicacin Osmtica, es decir, todos juntos en el mismo

cuarto. La posicin fsica de los desarrolladores es muy importante en
Crystal, ya que nos permite no tomarnos demasiado tiempo en
solucionar las dudas y contrastarlas con otros miembros del equipo.

Seguridad personal y buena comunicacin entre los integrantes

cuando algo molesta o no est bien, en lugar de encubrirlo, para as
poder mejorarlo y desarrollar un software libre de errores.

Foco, saber lo que se est haciendo y tener la tranquilidad y el

tiempo para hacerlo. Lo primero debe venir de la comunicacin sobre
direccin y prioridades con el Patrocinador Ejecutivo; lo segundo de un
ambiente en el que la gente no se vea compelida a hacer otras cosas
incompatibles.

Fcil acceso a usuarios expertos, ya que es muy importante el

contacto directo con expertos en el desarrollo de un proyecto, y un
encuentro semanal y llamadas telefnicas adicionales o el
entrenamiento de los desarrolladores como usuarios pueden resultar
muy beneficiosos.

Ambiente tcnico con pruebas automatizadas, management de

configuracin e integracin frecuente. Debern integrarseun mnimo de
dos veces por semana.
Tcnicas:
Adems comparte algunas tcnicas con el resto de metodologas
giles, que a pesar de no ser obligatorias como en otras como el XP, si
es conveniente utilizarlas. Estas son:

Exploracin de 360, tomando muestras del valor de negocio del

proyecto, sus requerimientos, su modelo de dominio, tecnologa, plan
de proyecto y proceso entre otros.

Victoria temprana, ya que es mejor tener pequeos entregables

peridicos cada poco tiempo que entregar el producto terminado al
cabo de mucho.


Esqueleto ambulante, una transaccin debe ser simple pero estar
completa, no dejarla a medio programar, ya que al volver a mejorarla
al cabo de un tiempo puede habrsenos olvidado el cdigo y ser
incapaces de mejorarla sin mermar sus funcionalidades.

Rearquitectura incremental, es decir, la arquitectura del proyecto

debe mejorar en etapas, manteniendo el sistema en ejecucin mientras
se modifica.

Radiadores de informacin, unos paneles con la evolucin del

proyecto y sus requisitos para que los integrantes del grupo puedan
tenerlo disponible en cualquier momento para ser observado y
recordado o modificado.
Crystal sigue una serie de tcnicas para completar el proyecto. Estas
son:

Entrevistas de proyectos a ms de un responsable para tener

varias visiones del software que se va a desarrollar.

Talleres de reflexin para que el equipo discuta sobre el trabajo,

pros y contras, mejoras, planes para las siguientes interacciones, etc.

Planeamiento relmpago o Poker, tal y como se utiliza en XP, con

tarjetas con valores segn la dificultad de las tareas a realizar.
Estimaciones de pericia mediante el proceso Delphi.

Encuentros diarios breves para la identificacin de problemas o

fallos.
Programacin por parejas, que establece proximidad.

Procesos:
Esta metodologa no especifica ningn ciclo ciclo de vida o modelo de
procesos, pero determina una gua estndar de las prcticas ms
utilizadas. Estas son:
-

Planificacin por etapas del siguiente incremento del sistema.

Debe finalizar con una versin ejecutable cada tres o cuatro
meses. El equipo selecciona los requisitos que sern
implementados en cada incremento y planifican lo que harn.

Revisiones y resmenes de cada iteracin de cada incremento

segn sus actividades: construccin, demostracin y resmenes

de los objetivos del incremento.
-

Monitorizacin de los progresos a partir de las entregas del equip

durante el desarrollo. Se mide con los hitos clave y la estabilidad
de las fases.

Paralelismo y flujo. Cuando el monitor de estabilidad nos indica un

estado estable para su revisin se pasa a la siguiente tarea. Los
equipos de seguimiento y arquitectura deben revisar sus planes
de trabajo, su estabilidad y su sincronizacin para llevar esto a
cabo.

Roles:
En Crystal se establecen unos roles bien definidos para cada integrante
del grupo. Estos son:
-

Patrocinador, que consigue recursos y define el proyecto y

produce la Declaracin de Misin con Prioridades de Compromis
o (Tradeoff). Pone y defiende su inversin en el proyecto. Tiene en
mente la visin a largo plazo del mismo. Crea la visibilidad externa
para el producto y provee al equipo de decisiones cruciales para
el negocio. Tambin puede tomar la decisin de si seguir o no con
el proyecto si no lo ve una inversin rentable y, de continuar,
deber replantear las funciones restantes para recuperar la
inversin. EN Crystalse hace mucho incapi en dar buena
informacin al sponsor para que pueda tomar sus decisiones
correctamente.

Usuario Experto, que produce la Lista de Objetivos y el Archivo de

Casos de Uso y Requerimientos. Tambin sugiere maneras de
optimizar su uso con macros, modos de visualizacin y
navegacin y cualquier otra sugerencia. Es una base de
conocimiento para el Experto de Negocio. Se espera que
conozca las reglas del negocio necesarias para el sistema, las
polticas que son estables y las propensas al cambio.

Experto de Negocios, que componen la Lista de Objetivos del

proyecto, Archivos de Casos de Uso y Requerimientos. Debe
conocer las reglas y polticas del negocio. Es experto en indicar
cmo va el negocio. Responder a varias preguntas de los
desarrolladores acerca del sistema. Provee informacin diferente
de la entrega el Usuario Experto, e incluso puede suceder que el
mismo Usuario sea el Experto de Negocios.

Diseador Principal, que produce la arquitectura del producto,

llamada Descripcin Arquitectnica. Debe manejar con fluidez,
mezclar e inventar procedimientos. Tiene los roles de
coordinacin, arquitecto, maestro y programador ms experto. Es
por tanto el lder tcnico del equipo.

Diseador-Programador, que produce unos borradores de

pantallas y el modelo comn, al igual que otra serie de
documentos de diseo de software como notas, diagramas de
diseo, cdigo fuente, cdigo de migracin, pruebas y sistema de
empaquetado. Dado que un programa desarrollado en Crystal es
diseo y programa, sus desarrolladores harn las veces tanto de
programador como de diseador, por tanto cualquier individuo
que no cumpla ambos requisitos no tiene cabida en este tipo de
desarrollo de software.

Coordinador, que junto con el equipo produce el Mapa del

Proyecto y su Plan de Entrega, Lista de Riesgos, el Plan y Estado de
Iteracin y la Agenda de Visualizacin. Suele ser una ocupacin
parcial en alguno de los dems miembros del equipo.
Alternativamente, el Patrocinador o Diseador Principal pueden
asumir este rol.

Verificador, que produce los reportes de fallos y bugs. Puede ser

tanto una sola persona como todo un equipo de programadores.

Escritor, que produce el manual para el usuario.

Desarrollo de un proyecto:
En el desarrollo de un proyecto en Crystal se deben tener en cuenta
para empezar las personas que componen un equipo, el aspecto
humano del mismo, la comunicacin entre los componentes, las
distintas polticas a seguir y el espacio fsico de trabajo. Especial
importancia tiene el tamao del equipo, ya que si es elevado produce
una metodologa ms pesada. Tambin es importante una
comunicacin cercana para que sea ms barata y efectiva,
recomendando el cara a cara. Dado que Crystal no es una
metodologa concreta sino ms bien una familia de ellas, todas
comparten una serie de caractersticas llamadas cdigo gentico. Estas
son:
1.
Modelo de Juego Cooperativo, dividiendo a los integrantes del
equipo en grupos o partidos cuyos objetivos consisten en inventar y
comunicar para mejorar su concentracin. Cada partido es diferente y

tiene como objetivo la entrega de software y preparacin para el

siguiente juego.
2.

Prioridades, que son

- Eficiencia en el desarrollo, para que los proyectos sean
rentables econmicamente hablando.
- Seguridad en lo que se entrega.
- Habilidad para hacer que todos los miembros del equipo
adopten las convenciones de trabajo establecidas por el
equipo.

3.

Propiedades, que son:

- Frecuencia de las entregas usables de entre 2 semanas y
un mes.
- Comunicacin, que es uno de los pilares de esta familia de
metodologas. Por eso el suo de pizarras u otros espacios
destinados a la comunicacin y la notificacin del estado del
proyecto son prcticas frecuentes.
- Creciminento reflexivo, utilizando periodos de reflexin y
reuniones entre los integrantes del equipo para mejorar la
eficiencia de estos.
- Seguridad personal con un equipo en el que todos sus
miembros se sientan cmodos con el trabajo y el entorno.
- Concentracin
- Fcil acceso a los usuarios clave haciendo que sean parte
del desarrollo
- Entorno tcnico especializado.
Mientras que las 3 primeras son obligatorias, Crystal es ms flexible
con el resto.
4.
Principios, el grado de detalle necesario en la documentacin y
ajuste en la forma de trabajo acorde con la personalidad para encajar
con los miembros del equipo.
5.
Estrategias, ya comentadas anteriormente: Victorias Tempranas,
Exploracin de 360, Esqueleto ambulante, Rearquitectura Incremental y
Radiadores de Informacin.
6.
Tcnicas, tambin comentadas con anterioridad, como las
Reuniones Periodicas o las de Reflexin.

Conclusin:
Como conclusin podemos remarcar que las metodologas Crystal son
altamente recomendables para equipos pequeos. Son flexibles y
priorizan la parte humana, apuntando a lograr eficiencia, habitabilidad
y confianza entre los integrantes del grupo. Los requisitos se obtienen
mediante programacin por parejas. Tambin presta especial atencin
al espacio fsico donde se sita el equipo y a la comunicacin. La
necesidad de las entregas peridicas, adems, estimulan la
concentracin y resalta la importancia de la comunicacin con el
cliente junto con las reuniones. Por ltimo, el equipo elige que tcnicas
aplicar segn las caractersticas del proyecto.

COMPARATIVA:
- Tamao de los equipos
FDD: Pensado para proyectos cortos y equipos pequeos, pero
muy escalable.
Crystal: Preferiblemente para equipos de tamao reducido, pero
modificable segn el peso del proyecto.
DSDM:Pensado para proyectos que deben desarrollarse de
manera rpida con un equipo ajustado y dirigido.
AUP: Preferiblemente
aumentar el tamao.

pequeos,

pero

con

posibilidad

de

- Obtencin de requisitos
FDD: No define explicitamente esta parte del proyecto, sino que
propone proceder a partir de un momento en el que ya se han
recogido de la manera que se quiera, en las 3 primeras fases.
Crystal: El equipo elige la manera en la que obtendrn los
requisitos, si bien debe haber comunicacin suficiente para debatrilo y
que todos los integrantes trabajen a gusto.
DSDM: Se definen los requisitos en dos fases iniciales llamadas
estudio de factibilidad y estudio de negocio.
AUP: Se produce en la primera fase, que est destinada
especficamente para ello, y condiciona la siguiente iteracin.
- Carga de trabajo
FDD: A medio camino entre la documentacin y el desarrollo,
bastante libre para los desarrolladores auque con orden, porque estos
estn muy jerarquizados.
Crystal: Cada componente del equipo tiene su papel,
especificando uno concreto para la docuemntacin (Escritor), para la
arquitectura (Diseador Principal), la programacin (ProgramadorDiseador), etc.
DSDM: El trabajo est muy organizado en niveles muy claros y con
funciones definidas, la carga se reparte en la medida de lo posible entre
todos los niveles.

AUP: Se centra totalmente hacia el desarrollo colocando las

cuestiones de documentacin o planificacin en segundo plano.

- Relacin con el cliente

FDD: No tiene formalismos en la documentacion, realiza controles
propios y una comunicacin fluida con el cliente. ste recibe una
muestra al final de ca da iteracion corta. El feedback del cliente ya no
marca el progreso, porque ste queda restringido por el modelo de
dominio creado en las primeras fases.
Crystal: Mucha relacin con el cliente en forma de entregas
peridicas y reuniones diarias.
DSDM: Trabaja codo con codo con el cliente o los usuarios finales
obteniendo el beneficio de un feedback que ayudaban a mejorar el
proyecto. Se hacen entregas frecuentes al cliente para comprobar el
estado del desarrollo.
AUP: El cliente recibe pequeas entregas cada poco tiempo y
entregas ms complejas, por lo general, cada 12, o cada 9 meses.
- Desarrollo
FDD: Proceso iterativo. Se centra en la organizacin global. Y
cada iteracin acaba con un producto totalmente completo (con
manual de instrucciones, nota..)
Crystal: Se realizan gran cantidad de iteraciones con productos
completos y usables.
DSDM: Tres fases principales con subfases que se ejecutan de
manera iterativa. Se integran pruebas durante todo el ciclo de vida del
proyecto.
AUP: Tambin es iterativo y cada iteracin acaba con un
microproducto efectivo que se entrega al cliente.
- Cdigos fuente
FDD: Es propietario, cada programador trabaja por su cuenta.
Aunque definen grupos y sesiones de trabajo, con los propietarios de
clases relacionadas.

Crystal: Utiliza la programacin por parejas para trabajar ms

dinmicamente y potenciar la comunicacin.
DSDM: Cada uno desarrolla su trabajo designado, no se utiliza el
Pair Programming normalmente.
AUP: Fomenta el trabajo en grupos pequeos cuyos miembros
interactan entre s para mejorar el resultado final.

- Conocimiento sobre la arquitectura

FDD: Se concreta en la fase de diseo con reuniones conjuntas,
para conseguir una arquitectura sencilla y sin errores.
Crystal: Existe un papel dentro del equipo llamado Diseador
principal que se encarga de la arquitectura, y a la vez todos los
programadores son diseadores en si mismos.
DSDM: En las fases cada campo decide como se van a organizar,
lo aceptan y se sigue el plan creado.
AUP: Se decide al principio de cada iteracin, en la fase de
diseo.

- Evaluacin del estado del proyecto

FDD: Es el mas adecuado para la monitorizacion del progreso,
porque se divide en unidades muy peueas (los rasgos).
Crystal: Son flexibles y priorizan la parte humana, apuntando a
lograr eficiencia, habitabilidad y confianza entre los integrantes del
grupo. Tambin presta especial atencin al espacio fsico donde se sita
el equipo y a la comunicacin
DSDM: Durante todo el ciclo de vida se desarrollan pruebas que
comprueban como se va desarrollando, hay un equipo destinado a
desarrollar y probar esos tests.
AUP: Muy rpido, pero contraindicado para grupos grandes o
proyectos que por sus caractersticas no sean de fcil evaluacin.

- Punto fuertes y puntos flacos

FDD: Divisin del software pequea y manejable, pero excesiva
jerarquizacin del personal.
Crystal: Muy eficiente si el equipo tiene buen ambiente de
comunicacin y es escalable, pero restringe la ubicacin del grupo a un
nico espacio fsico.
DSDM: Al ser propuesto por un consenso de expertos es una de las
metodologas ms recomendadas, adems se puede utilizar junto con
otras metodologas como XP o no giles como RUP, el feedback y la
ntima relacin con el cliente le dan seguridad y calidad al proyecto. Su
punto flojo puede ser que en proyectos muy cortos puede complicarse
la organizacin ya que es medianamente compleja.
AUP: Garantiza un rpido progreso de produccin y se centra ms
en el cdigo como tal que en el diseo previo de ste.