mas de metodologías agiles

1. Metodologías ágiles
Práctica 3
#AESMultimedia - aesmultimedia.blogspot.com
José Luís Contreras Martínez @DkLawis
Ana García Domene @agado92
Daniel Martínez Espadas @danielme91
Begoña Morillas Guijarro @begomori
1

2. Índice
Introducción a las metodologías ágiles
DSDM: Dynamic Systems Development Method
FDD: Feature Driven development
Crystal: (Crystal Clear)
AUP: Agile Unified Process
Análisis comparativo
Bibliografía
2

3. Introducción a las metodologías ágiles
Las metodologías ágiles surgen a principios de los 90 ante ciertos problemas de tiempo,
costo y calidad en el desarrollo de creación de software.
Este nuevo enfoque de desarrollo se dio a conocer como RAP (Rapid Application
Development). En él, el trabajo se organizaba en pequeños grupos de trabajo de alto
rendimiento.
Las metodologías ágiles se inician con la creación del eXtreme programming o XP que
impulsa el desarrollo mediante iteraciones, aunque éstas ya se utilizaban anteriormente.
También destacamos que estos ciclos son cortos intervalos de tiempo, de una a cuatro
semanas, lo que favorece la minimización de riesgos. Actualmente existen diversas
metodologías ágiles que se fueron basando en los principios de esta metodología.
Imagen 1: Desarrollo ágil de software
A continuación estudiaremos cuatro de las metodologías ágiles más destacadas del
momento: DSDM – Dynamic Systems Developmemt Method, Crystal (Crystal Clear), FDD –
Feature Driven Development y AUP: Agile Unified Process.
3

4. DSDM: Dynamic Systems Development Method
Esta metodología surge de un consorcio en Reino Unido. Su primera versión aparece en
1994, posteriormente se han realizado varias versiones.
Situada dentro de las RAD, DSDM es excelente para proyectos de sistemas de la
información con presupuestos limitados y agendas muy ocupadas y apretadas.
Características
Los proyectos tendrán las siguientes características que refieren a la aplicabilidad de
DSDM:
- Proyectos interactivos con funcionalidad visible en la interfaz de usuario
- De baja o media complejidad computacional.
- Particionables en componentes de funcionalidad más pequeños si la aplicación es de gran
tamaño, cuentan con flexibilidad en los requerimientos.
- Une técnicas de desarrollo y gestión del proyecto en una misma metodología que se
centra en conseguir un producto que funcione correctamente en los casos más críticos.
- Trabajo en equipo tanto los desarrolladores, los usuarios y los Stakeholders. Con un grupo
de usuarios bien definidos y comprometidos al proyecto.
- El equipo de desarrollo toma decisiones sin depender de autorizaciones de sus superiores
para realizar entregas, siempre cortas, de forma frecuente, siendo éstas funcionales. Ésto
es adecuado al tener el tiempo total acotado, por lo que previene que transcurra mucho
tiempo y la tecnología cambie.
- El desarrollo es iterativo e incremental.
- Todos los cambios pueden ser revertibles y son verificados durante todo el desarrollo.
Roles
Esta metodología define 15 roles para usuarios y desarrolladores, a continuación se
describen los más destacados.
● Desarrollador y desarrollador senior (developer and senior developer)
Son los únicos roles definidos para desarrolladores, por esto este rol incluye a todo
el personal de desarrollo, sean diseñadores, analistas, programadores o testers. La
diferencia entre desarrollador y desarrollador senior es que los segundos tienen gran
experiencia en las tareas que realizan, por lo que suelen dirigir el equipo.
● Coordinador técnico (Technical coordinator)
Responsable tanto de la calidad técnica como del control técnico del proyecto,
por ejemplo el uso de software de gestión de configuración y el cumplimiento de
estándares técnicos. Está encargado de mantener la arquitectura.
● Usuario embajador (Ambassador user).
4

5. Equivale al on-site customer de XP.
El usuario embajador debe ser miembro del grupo de usuarios, que espera utilizar el
sistema, pues este rol tiene como función aportar el conocimiento de este grupo al
proyecto y difundir información de los avances del proyecto al resto de usuarios. De
esta forma se asegura una correcta retroalimentación de los usuarios. se ofrece
conocimiento del negocio y define los requisitos del software.
● Asesor de usuario (Adviser user).
Consejero del usuario embajador. Este rol se emplea cuando el rol de usuario
embajador no es suficiente para expresar todas las opiniones o puntos de vista
importantes de los usuarios sobre un punto del proyecto.
● Visionario (Visionary).
El trabajo del visionario es el encargado de asegurar que se satisfacen las
necesidades de negocio, es decir, que desde el principio, los requisitos esenciales
se encuentran y que el proyecto sigue la dirección correcta para cumplir dichos
requisitos. Es el rol con la visión más precisa sobre los objetivos del negocio del
sistema y del proyecto y probablemente aquel que tiene la idea inicial de la
construcción del sistema.
● Patrocinador ejecutivo (Executive sponsor).
Es el rol de la organización de usuario que tiene la autoridad y responsabilidad
financiera relacionada al proyecto, por lo tanto tiene el máximo poder en la toma de
decisiones.
● Director de proyecto (Project Manager).
Es responsable de entregar los productos acordados de forma exitosa, al acordado
standar de calidad, a tiempo y dentro del presupuesto. Además de ser capaz de
entregar los beneficios estipulados en el PID. El director del proyecto puede venir de
IT o de la comunidad de usuarios, e informa a la Junta del Proyecto.
Artefactos
Podemos describir los artefactos obtenidos mediante la metodología DSDM a través de las
distintas fases que lo forman.
Fase 1. Estudio de viabilidad.
- Informe de viabilidad. Análisis de viabilidad del proyecto
- Esbozo del plan para el desarrollo. Planteamiento del desarrollo del proyecto a grandes
rasgos.
- Listado de riesgos. Lista con los riesgos que puede ofrecer el sistema.
- Prototipo rápido. Es un artefacto opcional, sólo aparecerá si no se conoce lo suficiente el
negocio o tecnología.
Fase 2. Estudio de la empresa.
- Descripción de los procesos de negocio y especificación de casos de uso. La
identificación de los casos de uso ayuda a involucrar al cliente.
5

6. - Documento de Especificación de Requerimientos de Software (SRS). Descripciones a
alto nivel de los requisitos que se presentan en formato correcto diagramas ER, modelos de
negocio objetivos, etc.
- Definición de la arquitectura del sistema. Es un primer borrador de la arquitectura que
puede cambiar durante el desarrollo del proyecto.
- Esbozo del plan de prototipado. Debe declarar la estrategia de prototipado para las
siguientes fases y un plan para la configuración de la administración.
Fase 3. Iteración del modelo funcional.
- Modelo funcional. Contiene el código prototipo y los modelos de análisis
- Casos de prueba. Pruebas a realizar a código.
- Funciones prioritarias. Lista de prioridades de las funciones que se entregan al final de la
iteración.
- Resumen de los documentos de prototipos funcionales. Recoge los comentarios de
los usuarios sobre el incremento actual, servirá de artefacto de entrada para las siguientes
iteraciones.
- Requisitos no funcionales. Lista de requisitos que se tratarán en la siguiente fase.
- Análisis de riesgos de desarrollo superior. Documento de gran importancia en esta
fase, pues, a partir de la siguiente fase, los errores encontrados serán más difíciles de
ubicar y dirigir.
Fase 4. Diseño e iteración de la estructura.
- Sistema probado. Debe cumplir al menos los requisitos mínimos acordados.
Fase 5. Implementación.
- Sistema entregado. Sistema finalizado y entregado al cliente.
- Manual de usuario. Instrucciones de uso del sistema.
- Informe de revisión de proyecto. Resume el resultado del proyecto. Según los
resultados, se establece el curso del desarrollo adicional.
Prácticas
Dado el enfoque hacia proyectos de características RAD, la ideología de la metodología
DSDM se define en nueve principios:
1. Involucrar al usuario es la base para obtener un proyecto eficiente y efectivo.
Cliente y desarrolladores comparten entorno de trabajo para mejorar la precisión de las
decisiones.
2. Los equipos de DSDM deben tener poder de toma de decisiones.
Es importante que se puedan tomar decisiones para el desarrollo del proyecto sin esperar la
aprobación de superiores
3. El foco está puesto en la entrega frecuente de productos.
Esto permite una verificación y revisión continua del producto desde el principio.
4. La conformidad con los propósitos del negocio es el criterio esencial para la
aceptación de los entregables.
6

7. DSDM se centra en las funcionalidades críticas del proyecto, no en todas sus posibles
necesidades.
5. El desarrollo iterativo e incremental es necesario para converger hacia una correcta
solución del negocio.
Se basa en la retroalimentación de os usuarios para dirigirse hacia una solución precisa.
6. Todos los cambios durante el desarrollo son reversibles.
Saber dónde estamos en cada momento para tener la posibilidad de deshacer y probar otro
camino si el elegido no funciona.
7. Los requerimientos están especificados a un alto nivel.
Alcance de alto nivel y requisitos deben ser „base-lined‟ desde el inicio del proyecto.
8. El testing es integrado a través del ciclo de vida.
Durante todo el ciclo de vida se realizan pruebas para evitar costes extraordinarios en
mantenimiento y arreglos del sistema.
9. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial.
La colaboración y cooperación entre el equipo, usuarios y stakeholders es esencial para un
correcto desarrollo del proyecto.
Aparte de estos principios, DSDM también se basa en una serie de consideraciones muy
importantes:
● Ningún sistema es construido a la perfección en el primer intento.
● La entrega del proyecto deberá ser a tiempo, respetando presupuesto y asegurando la
calidad.
● DSDM solo requiere que se complete cada paso que forma una iteración con la
funcionalidad suficiente como para que inicie el siguiente paso de la siguiente iteración.
● DSDM puede utilizarse en proyectos de ampliación de sistemas TI pero también podría
utilizarse para proyectos de cambio de algún sistema aunque no sea TI.
● La evaluación de riesgo debe estar enfocada en entregar funcionalidad de negocio y no
en el proceso de desarrollo.
● La estimación debe estar basada en funcionalidad del negocio no en líneas de código.
● La gestión recompensa la entrega continua de productos antes que la consecución de
tareas.
Proceso
DSDM reconoce que los proyectos son limitados por el tiempo y los recursos, y los planes
según las necesidades de la empresa. Para alcanzar sus metas, DSDM favorece el uso del
RAD con el consecuente riesgo de que demasiadas partes estén sin definir correctamente y
esto lleve a errores.
DSDM aplica algunos principios, roles, y técnicas en las 5 fases en las que define la
construcción de un sistema:
1. Estudio de viabilidad: Estudia la factibilidad del proyecto en una pequeña fase que
propone DSDM para determinar si la metodología se ajusta éste. se realiza un
estudio de los requisitos humanos materiales y financieros y los problemas de la
empresa o el cliente.
7

8. 2. Estudio de la empresa: Durante el estudio del negocio se involucra al cliente para
tratar de entender la operatoria que el sistema deberá automatizar. Este estudio
sienta las bases para iniciar el desarrollo, definiendo las características de alto nivel
que deberá contener el software, es decir, planifica la base de las actividades de la
empresa.
3. Iteración del modelo funcional: Se inician las iteraciones en las que se describirán
en detalle las características definidas en la fase anterior, planteando un modelo
previo que de solución aceptable a la problemática. Esta es la etapa de diseño.
4. Diseño e iteración de la estructura: Se realizará el diseño de los mismos
codificando el modelo diseñado, se construirán los componentes de software, se
prueba paralelamente la calidad del producto y se documenta el manual de usuario y
técnico.
5. Implementación: Entrega del producto al cliente o usuario final. Cuando éste de su
aprobación se implantará el sistema en producción.
La primera y segunda fase son secuenciales y, por lo tanto, realizadas una única vez al
principio del proyecto para analizar la factibilidad desde el punto de vista del negocio del
desarrollo, las demás fases presentan las características del modelo iterativo e incremental
ya tratado.
Imagen 2. Diagrama de procesos de DSDM
DSDM aproxima las iteraciones como “timeboxes”. Una “timebox” dura un periodo
predefinido de tiempo y la iteración debe finalizar dentro de la “timebox” que suele durar
desde unos días hasta unas pocas semanas.
8

9. Sin embargo, lo que diferencia a DSDM de otros modelos son los principios alrededor de los
cuales se estructura, tratados en el apartado anterior, y que hacen énfasis en los equipos de
desarrollo, en el feedback con el cliente y en las entregas frecuentes de productos.
Posibles integraciones
Es posible integrar DSDM con otros métodos para complementar el desarrollo del proyecto.
Entre ellos tenemos el Proceso Unificado de Rational (RUP), Programación Extrema (XP), y
Proyectos en ambientes controlados (PRINCE2), Otro método ágil que tiene semejanzas
proceso y concepto con DSDM es Scrum.
Entre DSDM y RUP se puede crear una fuerte unión, RUP podría considerarse una
implementación de DSDM. RUP está más orientado a la arquitectura y a la calidad y DSDM
tiene como objetivo el desarrollo rápido de aplicaciones, sin embargo, esto no impide
combinarlos, incluso se pueden relacionar todas las fases y artefactos de RUP con los de
DSDM. Al combinarse podemos obtener un sistema con una arquitectura fuertemente
definida en un tiempo récord.
9

10. FDD: Feature Driven development
Es un proceso ágil diseñado por Peter Coad, Eric Lefebvre y Jeff DeLuca. Se basa en un
proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y
la dirección de la empresa pueden ver y monitorizar. Estas iteraciones se deciden en base a
features o funcionalidades, que son pequeñas partes del software con significado para el
cliente.
A diferencia de otros procesos ágiles no cubre todo el ciclo de vida sino sólo las fases de
diseño y construcción. No requiere un modelo específico de proceso y se complementa con
otras metodologías. Enfatiza cuestiones de calidad y define claramente entregas tangibles y
formas de evaluación del progreso.
Características
FDD consiste en cinco procesos secuenciales durante los cuales se diseña y construye el
sistema. Cada fase del proceso tiene un criterio de entrada, tareas, pruebas y una salida.
Desarrollo de un modelo general: Cuando comienza el desarrollo, los expertos de dominio
están al tanto de la visón, el contexto y los requerimientos del sistema a construir. A esta
altura se espera que existan requerimientos tales como casos de uso o especificaciones
funcionales. Los expertos de dominio presentan un ensayo más en el que los miembros del
equipo y el arquitecto jefe se informan de la descripción de alto nivel del sistema.
El dominio general se subdivide en áreas más específicas y se define un ensayo más
detallado para cada uno de los miembros del dominio. Luego, un equipo de desarrollo
trabaja en pequeños grupos para producir modelos de objetos de cada área de dominio.
Simultáneamente, se construye un gran modelo general para todo el sistema.
Construcción de la lista de rasgos: Los ensayos, modelos de objeto y documentación de
requerimientos proporcionan la base para construir una amplia lista de rasgos. Estos rasgos
son pequeños ítems útiles a los ojos del cliente. La lista de rasgos es revisada por los
usuarios y patrocinadores para asegurar su validez y exhaustividad, los rasgos que
requieran de más de diez días se descomponen en otros más pequeños.
Planeamiento por rasgos: Incluye la creación de un plan de alto nivel, en el que los
conjuntos de rasgos se ponen en secuencia conforme a su prioridad y dependencia, y se
asigna a los programadores jefes.
Diseño por rasgos y Construcción por rasgos: Se selecciona un pequeño conjunto de
rasgos del conjunto, y los propietarios de clases seleccionan los correspondientes equipos
dispuestos por rasgos. Se procede luego iterativamente hasta que se producen los rasgos
seleccionados. Una iteración puede tomar de unos pocos días un máximo de dos semanas.
El proceso iterativo incluye inspección de diseño, codificación, pruebas unitarias, integración
e inspección de código.
10

11. Miremos una representación gráfica del proceso iterativo que involucran estas dos últimas
fases:
Imagen 3. Flujo de los procesos en FDD
Roles
Key Roles / Roles claves
○ Project Manager / Director del Proyecto: Es el líder administrativo y financiero del
proyecto. También protege al equipo de situaciones externas.
○ Chief Architect / Arquitecto jefe: Se encarga del diseño global del sistema y de la
ejecución de todas las etapas.
○ Development Manager / Director de desarrollo: Lleva diariamente las actividades
de desarrollo, resuelve conflictos en el equipo y resuelve problemas referentes a
recursos.
○ Chief Programmer / Programador Jefe: Analiza los requerimientos, diseña el
proyecto y selecciona las funcionalidades a desarrollar de la última fase del FDD.
○ Class Owner / Propietario de clases: Responsable del desarrollo de las clases
que se le asignaron como propias. Participa en la decisión de que clase será
incluida en la lista de funcionalidades de la próxima iteración.
○ Expertos de dominio: Puede ser un usuario, un cliente, analista o una mezcla de
estos. También poseen el conocimiento de los requerimientos del sistema. Y pasa
el conocimiento a los desarrolladores para que se asegure la entrega de un sistema
completo.
Supporting Roles / Roles de soporte
○ Domain Manager: Lidera al grupo de expertos del dominio y resuelve sus
diferencias de opinión concernientes a los requerimientos del sistema.
11

12. ○ Release Manager: Controla el avance del proceso mediante la revisión de los
reportes del Chief Programmer. Y reporta resultados obtenidos semanalmente al
gerente, al cliente donde incluye el porcentaje de avance de cada feature.
○ Language Lawyer / Guru del Lenguaje: Es el responsable de poseer un vasto
conocimiento en, por ejemplo, un lenguaje específico de programación o
tecnología. Este rol es fundamental cuando se trabaja una nueva tecnología.
○ Build Engineer / Ingeniero de construcción: Es el responsable de preparar,
mantener y correr el proceso de construcción. También realiza el mantenimiento de
las versiones y la publicación de la documentación.
○ Toolsmith / Herramentista: Construye herramientas específicas para el desarrollo,
conversión de datos y testeo. Puede trabajar en la preparación y mantenimiento
tanto de bases de datos o sitios web destinados al proyecto.
○ System Administrator / Administrador del sistema: Configura, administra y
repara los servidores, estaciones de trabajo y equipos de desarrollo y testeo
utilizados por el equipo.
Additional Roles / Roles adicionales
○ Tester: Verifica que el sistema recién creado cumpla con los requerimientos del
cliente. Y puede llegar a ser una persona independiente del equipo del proyecto.
○ Deployer: Es el encargado de convertir la información existente requerida por el
nuevo sistema. Participa en el lanzamiento de los nuevos productos.
○ Technical Writer / Escritor de documentos técnicos: Prepara documentación
para los usuarios, que pueden formar parte o no del equipo del proyecto.
Artefactos
El Release Manager se reúne con los Chief Programmers para que éstos reporten como es
el avance de las tareas. En esta reunión, que tiene una duración de 30 minutos o menos,
cada Chief Programmer informa de manera verbal el avance de sus features. Hacer esto de
forma verbal es bueno para que cada uno de los Chief Programmers se tome el tiempo de
escuchar a los otros y saber dónde están situados los demás en el proceso de desarrollo.
Al final de la entrevista, el release manager anota los resultados, actualiza la base de datos
y genera los reportes.
El release manager reporta los resultados obtenidos semanalmente, tanto para el equipo,
para el cliente y para el Project Manager. Para los clientes y los gerentes, el reporte debe
incluir el porcentaje de avance de cada feature. Para el equipo se informa cual es el
desempeño del mismo.
Prácticas
FDD consiste en establecer "mejores prácticas" y los desarrolladores del método
argumentan que a pesar de que las prácticas seleccionadas no son nuevas, la mezcla
específica de estos ingredientes hacen a los cinco procesos FDD únicos para cada caso.
Palmer y Felsing también argumentan que todas las prácticas disponibles deben ser
utilizadas para obtener el mayor beneficio del método y no que una única práctica domine
todo el proceso (2002). FDD consiste en las siguientes prácticas:
12

13. ● Dominio de modelado de objetos: exploración y explicación del dominio del
problema. Los resultados se dan en un marco donde las características se añaden.
● El desarrollo por función: El cliente valora las funciones, desarrollando y siguiendo
los progresos a través de una lista de pequeñas funcionalidades descompuestas.
● Propiedad de clase individual (código): Cada clase tiene una sola persona elegida
para ser la responsable de la consistencia, rendimiento e integridad conceptual de la
clase.
● Características de los equipos: Se refiere a pequeños equipos formados
dinámicamente.
● Inspección: Se refiere a la utilización de los mecanismos de detección de defectos
más conocidos.
● Construcciones regulares: se refiere a asegurar que siempre hay un sistema en
funcionamiento, demostrable y disponible. Las construcciones regulares forman la
línea base a la que se añaden nuevas funciones.
● Gestión de la configuración: Permite la identificación y el seguimiento histórico de las
últimas versiones de cada archivo de código fuente completo.
● Los informes de progreso: Se informa del progreso basado en el trabajo completado
a todos los niveles organizativos necesarios.
El equipo del proyecto debe poner todas las prácticas anteriores en uso con el fin de cumplir
con las normas de desarrollo del FDD. Sin embargo, al equipo se le permite adaptarlas de
acuerdo a su nivel de experiencia.
13

14. Crystal: (Crystal Clear)
Crystal es una metodología de desarrollo de software ágil, aunque más bien se la considera
un conjunto de metodologías para el desarrollo de software caracterizadas por estar
centradas en las personas que forman parte del equipo y en la reducción al máximo
del número de artefactos producidos.
El equipo de desarrollo se considera un factor clave en esta metodología, por lo que se
deben invertir esfuerzos en mejorar las habilidades y destrezas, así como tener políticas
de trabajo en equipo bien definidas. Estas políticas dependerán del número de personas
que formen el equipo, estableciéndose una clasificación por colores, por ejemplo Crystal
Clear (3 a 8 personas, es decir proyectos pequeños) y Crystal Orange (25 a 50 personas).
En este trabajo se hablará en concreto de Crystal Clear.
Características
Las seis características o propiedades de Crystal Clear son las siguientes:
1. Entrega frecuente. Se trata de entregar software a los clientes de forma frecuente,
no solamente cuando el proyecto está acabado. La frecuencia dependerá del
proyecto, puede ser diaria, semanal o mensual. Lo importante es mantener
informado al cliente del estado del sistema.
2. Comunicación osmótica. Todos los miembros del proyecto deben estar juntos en
la misma habitación.
3. Mejora reflexiva. Disponer de un tiempo breve (unas pocas horas cada ciertas
semanas o una vez al mes) para observar bien el progreso, cotejar ideas y notas,
reflexionar y discutir.
4. Seguridad personal. Cuando hay alguna inquietud o problema en el equipo,
hablarlo para solucionarlo.
5. Foco. Siempre se debe tener claro lo que se está haciendo en cada momento del
proyecto, tener el tiempo y la tranquilidad necesaria para llevarlo a cabo.
6. Fácil acceso a usuarios expertos. Disponer de ayuda y consejo de desarrolladores
expertos y con experiencia en proyectos similares.
Roles y artefactos
● El patrocinador se encarga de conseguir recursos y de definir el proyecto general.
Produce un sólo artefacto: la Misión con Prioridades de Compromiso.
● El equipo como Grupo es responsable de producir dos artefactos:
○ Estructura y los Convenios del Equipo
○ Resultados del Taller de Reflexión
● El coordinador, junto con el equipo, es responsable de la producción de:
○ Mapa de proyecto.
○ Plan de Lanzamiento
○ Estado del proyecto
○ Lista de riesgos
14

15. ○ Plan de Iteración y Estado
○ Visualización del Calendario
● El experto en negocios y el usuario experto; el primero debe conocer las reglas y
políticas de la empresa; el segundo debe familiarizarse con el uso del software,
sugerir mejoras e ideas, en definitiva, implementar una buena interfaz de cara a los
usuarios finales. Juntos son responsables de producir los siguientes artefactos:
○ Lista de Actores-Objetivos
○ Archivos de Casos de Uso y Requerimientos
○ Modelo del Rol de Usuario
● El diseñador jefe es el responsable de producir la Descripción de la Arquitectura.
● El diseñador-programador, junto con el diseñador jefe, son los responsables de los
siguientes artefactos:
○ Borradores de Pantallas
○ Modelo Común de Dominio
○ Bocetos de Diseño y Notas
○ Código Fuente
○ Código de Migraciones
○ Pruebas
○ Empaquetación del Sistema
Como curiosidad, en la metodología Crystal Clear no tiene cabida un diseñador que
no programe.
● El verificador (tester) se encargará de producir Informes de Errores de última
hora.
● Por último, el escritor producirá el Manual de Ayuda para el Usuario.
Proceso
En lugar de la interpretación lineal de los modelos clásicos, que es interpretada en muchos
casos como inconvenientes, Cristal Clear enfatiza el proceso como un conjunto de ciclos
anidados.
En la mayoría de los proyectos se perciben siete ciclos:
1. El proyecto en sí.
2. El ciclo de entrega de una unidad.
3. La iteración (nótese que CC requiere múltiples entregas por proyecto pero no
muchas iteraciones por entrega).
4. La semana laboral.
5. El período de integración, de 30 minutos a tres días.
6. El día de trabajo.
7. El fragmento de desarrollo de una sección de código, de pocos minutos a pocas
horas.
15

16. Imagen 4. Ciclos anidados de Crystal Clear
Prácticas
En cuanto a las prácticas o técnicas que se favorecen dentro de esta metodología, podemos
mencionar las siguientes:
1. Entrevistas de proyectos. Es costumbre entrevistar a más de un responsable para
tener visiones más enriquecedoras y variadas.
2. Talleres de reflexión. El equipo debe descansar de treinta minutos a una hora para
reflexionar, discutir sobre posibles problemas y mejoras y organizarse de cara a la
siguiente etapa.
3. Planeamiento „Blitz‟. Técnica equivalente al Juego de Planeamiento de XP. Se
ponen tarjetas enumeradas en la mesa, con una historia de usuario o función visible
en cada una. El grupo simula que no hay dependencias entre ellas, y se alinean en
secuencias de desarrollo preferidas. Los programadores escriben en cada tarjeta el
tiempo estimado para desarrollar cada función. El patrocinador escribe el orden de
prioridades, teniendo en cuenta los tiempos y el valor de negocio de cada función.
Las tarjetas se agrupan en iteraciones que se agrupan a su vez en entregas,
normalmente no más largas de tres meses.
4. Estimación Delphi con estimaciones de pericia. Se reúnen los expertos y
proponen el tamaño del sistema, su tiempo de ejecución, la fecha de entregas y
equilibrarlas entregas en paquetes de igual tamaño.
5. Encuentros diarios de pie. Deben ser muy breves, de 5 a 10 minutos. Se trata
únicamente de identificar problemas y no de debatir.
6. Miniatura de procesos. Para que así la gente pueda disfrutar de esta metodología
sin que les resulte muy pesada.
7. Gráficos de quemado. Se usan también en Scrum. Es una técnica de graficación
para descubrir retardos y problemas en el proceso a tiempo, evitando que se
descubran demasiado tarde o cuando ya no tengan solución. Para ello se hace una
estimación del tiempo que falta para programar lo que queda al ritmo actual. Esta
técnica se asocia con la Lista Témpana, llamada así porque se refiere al agregado
de tareas u objetos de alta prioridad al principio de las listas de trabajos pendientes,
esperando que los demás se hundan debajo de la línea de flotación; los elementos
16

17. que están sobre la línea se entregarán en la iteración siguiente, los que están por
debajo en las restantes. Los gráficos de quemado muestran gráficamente la
velocidad del proceso.
8. Programación lado a lado. Crystal Clear establece proximidad con los miembros
del equipo. Cada persona se enfoca a su propia tarea asignada pero echando un ojo
a lo que hace su compañero. Es una ampliación de la Comunicación Osmótica al
contexto de la programación, y un contraste a la presión extrema que muchos
consideran a la programación en pares de XP.
17

18. AUP: Agile Unified Process
Características
Es un enfoque al desarrollo de software basado en el Rational Unified Process (RUP) de
IBM. El ciclo de vida de AUP es en serie a lo grande e iterativo en lo pequeño, liberando
artefactos incrementales en el tiempo.
El AUP consta de 7 flujos de trabajo o disciplinas: Modelado, Implementación, Prueba,
Despliegue, Gestión de configuración, Gestión de proyectos y Ambiente.
- Modelado: Tiene como objetivo entender el negocio, entender cuál es el problema
que se va a abordar e identificar las posibles soluciones viables para dicho
problema.
- Implementación: El objetivo de esta disciplina es transformar el modelo en código
y realizar pruebas básicas sobre él.
- Prueba: Tiene como meta evaluar una evaluación de los objetivos y encontrar
defectos para mejorar la calidad. Se encarga también de verificar si el sistema
funciona correctamente.
- Despliegue: Su objetivo es ejecutar un plan para que el sistema esté a disposición
de los usuarios.
- Administración de la configuración: Su meta es administrar el acceso a los
artefactos del proyecto. Lleva un registro de las versiones del producto y controla los
cambios que ocurran.
- Administración del proyecto: Tiene el objetivo de administrar los riesgos, la
asignación de tareas, el seguimiento de los procesos y coordinar con las personas
fuera del proyecto para facilitar que acabe a tiempo y sin pasar el presupuesto.
- Entorno: Apoya los esfuerzos para garantizar la disponibilidad de los procesos,
normas y herramientas cuando sea necesario.
También consta de 4 fases del ciclo de desarrollo:
- Inicio: se trata de identificar el alcance y dimensión del proyecto, su arquitectura y el
presupuesto junto con su aprobación por parte de aquellos que pertenecen al proyecto.
Como hito de esta fase obtenemos los objetivos de ciclo de vida.
- Elaboración: en esta fase se prueba y se confirma la arquitectura del sistema. Como hito
obtenemos la arquitectura del ciclo de vida.
- Construcción: esta fase consiste en la construcción del software sobre la base
incremental siguiendo unas prioridades impuestas por los implicados en el proyecto o por
los propios usuarios. Como hito obtenemos la capacidad operacional inicial.
- Transición: esta fase tiene el objetivo de validar e implantar el sistema en el entorno de
producción. Como hito tenemos la liberación del producto.
18

19. Roles
- Administrador de bases de datos: trabaja con los miembros del equipo del proyecto para
diseñar, probar y dar soporte a los esquemas de datos. Trabaja dentro de la disciplina de
implementación.
- Modelador: se encarga de crear modelos (dibujos, archivos, etc) de manera colaborativa y
evolutiva. Trabaja dentro de las disciplinas de modelado e implementación.
- Administrador de la configuración: se encarga de la infraestructura del medio donde
trabaja el equipo de desarrollo. Forma parte de la disciplina de administración de
configuración.
- Implementador: es el encargado de poner el software a punto para la preproducción. Su
parte se desarrolla dentro de la disciplina de desarrollo.
- Desarrollador: escribe el código, lo prueba y construye el software. Trabaja en las
disciplinas de modelado, implementación y desarrollo.
- Especialista del proceso: desarrolla, adapta y apoya el material de los procesos de
organización. Trabaja en la disciplina de entorno.
- Administrador del proyecto: se encarga de administrar los miembros de los equipos de
trabajo, maneja las interacciones entre los involucrados en el proyecto y también se encarga
de administrar los recursos y las prioridades. Trabaja dentro de las disciplinas de modelado,
pruebas, desarrollo y administración del proyecto.
- Examinador: es el miembro que se encarga de someter a evaluación los productos del
proyecto. Su trabajo forma parte de la disciplina de pruebas.
- Documentador técnico: se encarga de la documentación sobre los materiales,
operaciones, mantenimiento y del usuario. Forma parte de la disciplina de desarrollo.
- Administrador de pruebas: se encarga de que las pruebas a las que se somete el
producto tengan éxito. Forma parte de la disciplina de pruebas.
- Equipo de pruebas: son los miembros que se encargan de ejecutar las pruebas y
documentar las. Pertenecen a la disciplina de pruebas.
- Especialista en herramientas: son los responsables de la elección, adquisición,
configuración y mantenimiento de los equipos que se utilizaran durante el proceso. Forma
parte de la disciplina de entorno.
Artefactos
- Sistema: el sistema es el software, hardware y documentación que será liberado a la
producción.
- Código fuente: es el código de programación para los sistemas.
19

20. - Suite de pruebas de regresión: son casos de prueba con sus respectivos códigos listos
para ser ejecutados en un orden predefinido.
- Scripts de instalación: código necesario para instalar el sistema en el entorno de
preproducción.
- Documentación del sistema: es la documentación que fluye junto con el sistema para
ayudar a los desarrolladores a mantenerlo actualizado. Contiene las operaciones, soportes
y documentación general del sistema.
- Notas: son resúmenes que se pasan sobre aquellas modificaciones que se realizan en el
proceso de construcción.
- Modelado de requerimientos: contiene los requisitos a cumplir, junto con pruebas de
aceptación, automatización, modelos de procesos de negocio, reglas, modelos de dominio y
organización, glosarios, requisitos técnicos y modelos de UI.
- Modelo de diseño: es una descripción del diseño del sistema que contiene modelos de
despliegue, objetos, datos físicos y seguridad, así como un resumen del sistema y un
modelo de UI.
20

21. Análisis comparativo
Similitudes y diferencias
Las metodologías ágiles pueden seguir una guía rígida y concreta de la que no hay que
salirse, con técnicas muy específicas, como sucede con las metodologías FDD y XP, o por
el contrario, seguir una guía flexible y abstracta, con métodos que nos ayudan a obtener
el mismo resultado de una manera más eficiente, como es el caso de Crystal.
Una de las similitudes que comparten prácticamente todas las metodologías ágiles es que
presentan guías ajustables y adaptables ante cambios una vez empezado el proyecto.
Crystal es la única excepción.
En cuanto a los roles que intervienen en las diferentes metodologías comentadas en los
anteriores apartados, se puede decir que no difieren prácticamente, y que en su mayoría
los mismos papeles se repiten en todas. Siempre hay un representante del cliente, que
normalmente es el que se encarga de comprobar que se van cumpliendo todos los
requisitos; un experto en la metodología para guiar al equipo; un gestor del proyecto; y
el equipo de desarrolladores (con mayor o menor grado de subdivisiones dentro de esta
unidad).
En conclusión podemos decir que la asignación de los roles es independiente de la
metodología y que tan sólo se van adaptando según el estilo que tenga cada una.
Las herramientas usadas por las metodologías ágiles son en general muy comunes, XP es
de las pocas que se desvían de esta norma y han introducido novedades, especialmente en
lo que se refiere a herramientas en las fases de pruebas (aunque en este trabajo no se
habla de XP).
La familia de las metodologías Crystal es la única que sugiere explícitamente principios del
método de diseño para permitir la adaptación en función del tamaño del proyecto y la
criticidad.
DSDM se diferencia por usar prototipos y presenta algunos roles no considerados por el
resto: ambassador, visionary y advisor (representan diferentes puntos de vista del cliente).
FDD no cubre las primeras fases de un proyecto, pues presupone que se ha realizado
trabajo anteriormente
Ventajas y desventajas
DSDM une técnicas de desarrollo y gestión del proyecto en una misma metodología que se
centra en conseguir un producto que funcione correctamente en los casos más
críticos, por lo que crea un producto en un plazo corto que sólo cubre casos de uso
básicos.
El equipo de desarrollo toma decisiones sin depender de autorizaciones de sus
superiores evitando tiempos de espera y su consecuente pérdida de tiempo, en el
21

22. desarrollo al esperar una aprobación. Sobre todo teniendo en cuenta que los plazos de
desarrollo y las iteraciones son cortos períodos de tiempo, punto que tiene la ventaja de
prevenir que transcurra mucho tiempo y la tecnología cambie, además de permitir una
revisión continua del producto a través de entregas frecuentes de productos.
Llegados aquí, gracias a que los cambios son revertibles y verificados es posible volver
a un punto anterior y corregir errores detectados. Otra ventaja es la continua
realimentación (feedback) entre cliente y desarrolladores que ayuda a obtener un proyecto
eficiente y efectivo aunque el desarrollo sea rápido y en tiempo reducido.
Como ventajas, FDD tiene que es una metodología de desarrollo ágil, que disminuye el
riesgo de los proyectos, pues gracias a sus entregas tangibles cada dos semanas y al
constante monitoreo de su calidad, se asegura el firme avance del mismo.
Esta metodología utiliza pequeños bloques que contienen la funcionalidad del sistema,
llamados features. Estos bloques, que están relacionados entre sí, son organizados en una
lista llamada feature set.
También permite dejar satisfechos a los desarrolladores, gerentes y clientes sin afectar el
proyecto. Esto gracias a un buen manejo de las actividades, a la disminución del riesgo
del proyecto y al aseguramiento de la calidad del mismo, respectivamente.
FDD presenta su talón de Aquiles en la necesidad de tener en el equipo miembros con
experiencia que marquen el camino a seguir desde el principio, con la elaboración del
modelo global, puesto que no es tan ágil como otras metodologías.
Algunos “agilistas” sienten que FDD es demasiado jerárquico para ser un método ágil,
porque demanda un programador jefe, quien dirige a los propietarios de clases, quienes
dirigen equipos de rasgos.
Otros críticos sienten que la ausencia de procedimientos detallados de prueba en FDD
es llamativa e impropia.
Los promotores del método aducen que las empresas ya tienen implementadas sus
herramientas de prueba, pero subsiste el problema de su adecuación.
En cuanto a Crystal Clear podríamos meter en el saco de ventajas que es una de las
metodologías más ágiles y flexibles, con gran énfasis en la comunicación (de hecho es
lo más importante y crucial) y a los individuos que forman parte del proyecto. Otro punto
que se puede considerar ventaja es que se dispone de la figura del “usuario real”, que
realiza validaciones sobre la interfaz de usuario, propone ideas para una mejor
implementación de cara a los usuarios finales de primera mano y participa en la definición
de requerimientos funcionales y no funcionales del software, lo cual implica que se consigue
un sistema totalmente preparado y adaptado a los usuarios finales. Este hecho muchas
metodologías no lo integran.
Como inconveniente podríamos decir que es una metodología que no se puede aplicar a
grandes proyectos donde absolutamente todo se debe controlar y donde se deben seguir
22

23. por necesidad instrucciones más disciplinadas y concretas, Crystal Clear es demasiado
ágil y abstracta en sus métodos, lo que hace que esta metodología por sí sola sea
aplicable en la práctica en casos muy concretos.
Adecuación para distinto tipo de aplicaciones
DSDM es excelente para proyectos de sistemas de la información con presupuestos
limitados y agendas muy ocupadas y apretadas. Puede usarse en proyectos de ampliación
de sistemas TI pero también podría utilizarse para proyectos de cambio de algún sistema
aunque no sea TI. Proyectos interactivos con funcionalidad visible en la interfaz de usuario
FDD se utilizó por primera vez en grandes aplicaciones bancarias a fines de la década de
1990. Los autores sugieren su uso para proyectos nuevos o actualizaciones de sistemas
existentes y recomiendan adoptarlo en forma gradual. Un rasgo llamativo de FDD es que no
exige la presencia del cliente.
Crystal Clear al darle más importancia a los individuos y basarse fundamentalmente el
éxito del proyecto en la comunicación cara a cara, es una metodología que únicamente se
puede aplicar a proyectos pequeños, de equipos reducidos y menos a 10 personas, pues en
proyectos más ambiciosos es fácil que se pase algo por algo, lo que puede ser fatal. En
cambio en proyectos menores, donde la gente se conoce más y todos están apoyados unos
en otros, es posible llegar a buen puerto con este método tan flexible y menos estresante en
comparación con otras metodologías. Esto último en proyectos más grandes y de más
importancia es necesario que así sean para poder controlar, por ejemplo, los riesgos críticos
a los que se debe enfrentar, algo que Crystal Clear no contempla. Más bien Crystal Clear
está pensada para combinarse junto a otras metodologías como XP o Scum.
AUP es un método ágil entre XP y RUP que incluye las actividades y herramientas
tradicionales. El AUP resulta ser un proceso muy pesado pero en comparación con el RUP
es muy simple.
23

24. Bibliografía
Introducción
Diseño de una Metodología Ágil de Desarrollo de Software - Marcelo Schenone
Desarrollo ágil de software - Wikipedia [Imagen 1]
DSDM: Dynamic Systems Development Method
Método de desarrollo de sistemas dinámicos - Wikipedia
Metodología ágil DSDM - Bitácora de Audieman [Imagen 2]
Diseño de una Metodología Ágil de Desarrollo de Software - Marcelo Schenone
Agile Software Development Methods: Review and Analysis - Abrahamsson, Pekka; Salo,
Outi; Ronkainen, Jussi; Warsta, Juhani (PDF/ENG)
FDD: Feature Driven development
FDD - Wikipedia(Traducido)
Presentación FDD (PPT)
Procesos ágiles (MSWord)
Metodología FDD - Luis Calabria (cátedra)
Diseño de una Metodología Ágil de Desarrollo de Software - Marcelo Schenone
Agile Software Development Methods: Review and Analysis - Abrahamsson, Pekka; Salo,
Outi; Ronkainen, Jussi; Warsta, Juhani (PDF/ENG)
Crystal: (Crystal Clear)
Diseño de una Metodología Ágil de Desarrollo de Software - Marcelo Schenone
Documento sobre la metodología Crystal
Crystal Clear Roles and Work Products (ENG)
Metodologías ágiles [Imagen 4]
Presentación sobre Crystal Clear
AUP: Agile Unified Process
Gestion de proyectos ágil: Conceptos básicos (PDF)
http://www.ecured.cu/index.php/Agile_Unified_Process
http://www.ambysoft.com/unifiedprocess/agileUP.html
http://wikis.uca.es/wikiCE/index.php/Agile_unified_process
http://www.ambysoft.com/downloads/agileUP.zip
http://www.adolfo.mex.tl/images/18149/METODOLOGIAS%20AGILES.pdf
Análisis comparativo
Metodologías ágiles, tesis de master
24