práctica 3 aesm metodologías Ágiles

5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com

http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 1/21



1

Índice DSDM……………………………………………………………………………………….……………………...………….. 2 ¿Qué es el DSDM? .......................................................................................................................................................... 2

Características ................................................................................................................................................................ 2Ciclo de vida del proyecto .............................................................................................................................................. 4

¿Cuándo es apropiado usar la metodología DSDM? ...................................................................................................... 5

¿Cuándo no es apropiado aplicar la metodología DSDM? ..................... ...................... ..................... ...................... ....... 5

FDD…………………………………………………………………………………………………………..…………………….6 Procesos ......................................................................................................................................................................... 6

1.- Desarrollo de un modelo global. .......................................................................................................................... 6

2.- Construcción de una lista de funcionalidades. ..................................................................................................... 7

3.- Planeación por funcionalidad. .............................................................................................................................. 7

4.- Diseño por funcionalidad. .................................................................................................................................... 7

5.- Construcción de la funcionalidad. ........................................................................................................................ 7

Roles y responsabilidades .............................................................................................................................................. 8

Roles claves ............................................................................................................................................................... 8

Roles de soporte ....................................................................................................................................................... 8

Roles adicionales ....................................................................................................................................................... 8

Herramientas ................................................................................................................................................................. 9

Conclusiones FDD: .......................................................................................................................................................... 9

Crystal Clear………………………………………………………………………………………………………………..….11 Los siete valores o propiedades de Crystal Clear son: ................................................................................................. 11

En cuanto a las técnicas, se favorecen: ........................................................................................................................ 12Conclusion: ................................................................................................................................................................... 13

AUP…………………………………………………………………………………………………………………………………14 ¿Qué es el AUP? ........................................................................................................................................................... 14

Características .............................................................................................................................................................. 14

Ciclo de vida del proyecto ............................................................................................................................................ 15

Fase de Elaboración: ............................................................................................................................................... 16

Fase de Construcción: ............................................................................................................................................. 16

Fase de Transición: .................................................................................................................................................. 17

Conclusión .................................................................................................................................................................... 17

Comparación……………………………………………………………………………………………..………………….18 Tamaño de los equipos:...................................................................................................................................... 18

Obtención de los requisitos: ............................................................................................................................... 18

Evaluación del estado del proyecto: ................................................................................................................... 18

Carga de trabajo: ................................................................................................................................................ 18

Relación con el cliente: ....................................................................................................................................... 18

Desarrollo: .......................................................................................................................................................... 19

Código fuente: .................................................................................................................................................... 19

Conocimiento sobre la arquitectura: .................................................................................................................. 19

Puntos flacos: ………………………………………………………………………………………………………………………………………..……… 19

Referencias ……………………………………………………………………………………………………………….……20



2

En esta práctica se definirán con detalle varias metodologías ágiles de desarrollo para

posteriormente hacer una comparación exhaustiva entre ellas.

De cada una de las metodologías, se estudiarán sus características, roles, artefactos prácticas y

herramientas.

DSDM (Dynamic Systems Development Method) ¿Qué es el DSDM?

El Método de Desarrollo de Sistemas Dinámicos es una metodología para el desarrollo de

software, de naturaleza iterativa e incremental y es considerada como la primera metodología

ágil. Surgió en el año 1995, como respuesta a la crisis del software.

El DSDM pretendía así solucionar los principios de la crisis del software, permitiendo llevar a

cabo proyectos de desarrollo de software en un tiempo y presupuesto específico y quecumpliese con las expectativas de los usuarios. Para ello permitía la existencia de requisitos

cambiantes que se producían en las diferentes evoluciones del producto.

Características

El Método de Desarrollo de Sistemas Dinámicos se basa en los siguientes principios:

- Es indispensable la implicación de los usuarios a los que está dirigido el producto

participen en su definición para lograr un proyecto eficiente y efectivo.

- Con el fin de evitar retrasos, el equipo de desarrollo ha de ser capaz de tomar

decisiones importantes para que el proyecto continúe sin necesidad de tener que

esperar la aprobación de niveles superiores.

- Es preferible entregar con frecuencia un producto bueno y temprano a uno perfecto

pero con retraso, ya que a partir de las diferentes iteraciones, al ser posible utilizar

tempranamente el producto, permite que desde etapas muy tempranas comience el

continuo proceso de revisión de calidad del producto y que con cada iteración, se

aproxime cada vez más a las expectativas del usuario.

- Parte de las funcionalidades más importantes que debe cumplir el producto, las más

necesarias, y a partir de ahí, mediante las diversas iteraciones, se va perfeccionando el

producto. Se rige por la regla ‘MoSCoW’ , cuyas siglas en ingles significan:

o Must have: el equipo de desarrollo se centra primero en las funcionalidades

críticas que han de llevar a cabo para el desarrollo del producto. Dichos

requisitos han de ser pactados y aceptados entre todas las partes que

participan en el proyecto, antes de que éste comience.

o Should have: una vez llevados a cabo los aspectos ‘que debe tener’ el

producto, el equipo se centra en las funcionalidades que convendría



3

incorporar al sistema, aquellas que ‘debería tener’.

o Could have: una vez logrado los aspectos más importantes del producto, se

revisa éste y se analizan nuevos aspectos y funcionalidades que el producto

‘podría incorporar’.

o Would like to have (but won’t): finalmente, se produce una última revisión

donde el equipo de desarrollo concreta aspectos que ven convenientes que

incorporara el producto final, aquello que ‘les gustaría incorporar’.

- Su estrategia de desarrollo es iterativa e incremental.

- Facilita los cambios en el producto; cualquier cambio realizado durante su desarrollo,

es reversible. Este aspecto es conveniente dado que durante la fase de especificación

del producto, el usuario podría haberse equivocado al especificar una funcionalidad oen cualquier aspecto del producto. Si esto sucede, en vez de continuar con dicho error,

se realizan cambios para solventarlo.

- Se realizan pruebas del producto a lo largo de todo el ciclo de vida del proyecto, no

únicamente entre iteración e iteración. Esto permite una temprana detección y

solución de los errores.

- La cooperación y comunicación entre todas las partes implicadas en el desarrollo del

proyecto es vital.

Además de estos principios, el DSDM se basa también en los siguientes, denominados

asunciones:

1. Ningún sistema es construido a la perfección en el primer intento; siguiendo el

denominado ‘Principio del Pareto’, con el 20% del esfuerzo total para realizar una

actividad se alcanza el 80% de la misma. Por lo tanto, el proceso de desarrollo ha de

centrarse en priorizar las funcionalidades más importantes del sistema. Construir un

sistema perfecto es imposible, e intentar aproximarse demasiado a la perfección

supone una pérdida de energía.

2. Hay que conseguir proyectos de calidad dentro de los plazos establecidos.

3. Es necesario que cada paso del desarrollo se complete lo suficiente para que pueda

continuar el siguiente, aunque no finalice el anterior. Es decir, pueden realizarse a la

vez varios incrementos, siempre y cuando no se obstaculicen entre sí. Esto

proporciona una reducción del tiempo de desarrollo.

4. Es posible aplicar el DSDM a proyectos de ampliación o a proyectos inacabados.



4

Ciclo de vida del proyecto

El Método de Desarrollo de Sistemas Dinámicos se divide en tres fases, el Pre-proyecto, el Ciclo

de la vida del proyecto, y el Post-proyecto:

-

Pre-proyecto: en él se especifica el alcance del proyecto, se identifican losdepartamentos, los compromisos y los objetivos de cada parte, las personas

implicadas en el proyecto y quién financiará el proyecto.

- Ciclo de vida del proyecto. Se compone por las siguientes fases:

o Estudio de la viabilidad: Se estudian los riesgos y se identifica el grado de

adecuación de la metodología del DSDM al proyecto. De esta fase surge un

informe de viabilidad y un plan general del proyecto donde se redacta el plan

de desarrollo del proyecto y un registro de riesgos.

o Estudio del negocio: Una vez se ha determinado si el DSDM es propicio parallevar a cabo el proyecto, se lleva a cabo un análisis en profundidad de los

procesos de negocio que se van a informatizar. Es esencial la participación del

usuario en esta fase para el correcto funcionamiento del sistema.

Esta fase produce un modelo de procesos, un catálogo de requisitos priorizado

y la arquitectura del sistema.

o Iteración del modelo funcional: Se divide en cuatro fases; la Identificación del

prototipo funcional (donde se define las funcionalidades básicas que

implementara el prototipo), la Definición del calendario (donde se acuerda el

plan de trabajo), la Obtención del prototipo funcional y la Revisión de éste,

donde se compara el prototipo obtenido al ideado inicialmente mediante

diversas pruebas realizadas por el usuario.

Es esencial conocer la opinión del usuario tras la prueba para poder conocer

los aspectos en los que se puede mejorar o solucionar los problemas que

presente el prototipo con las distintas iteraciones, con tal de que se adecúe a

sus necesidades.

o Iteración del diseño y de la construcción: Se divide en cuatro fases;

Identificación del prototipo de diseño (donde se determinan lasfuncionalidades que cubrirá el proyecto y las que no), la Definición del

calendario, la Construcción del prototipo de diseño (el cual debe de ser un

producto utilizable para los usuarios)y la Revisión del prototipo de diseño.

o Implementación: Se divide de nuevo en cuatro fases; Aprobación del usuario

(donde éste da su veredicto sobre el producto), Formación (se instruye a los

usuarios finales de la aplicación/producto para que realicen un correcto uso de

éste), Implementación (se instala el producto en las instalaciones del cliente),

Revisión de negocio (se revisa la adecuación del sistema a las necesidades del

negocio y a los objetivos iniciales que se habían planteado). En función de esta

última revisión, se decidirá si se continúa con la fase del Post-proyecto o se



5

retrocede a algunas de las anteriores del ciclo de vida (con el objetivo de

mejorar el producto).

- Post-Proyecto: Es el correcto mantenimiento del producto llevado a cabo con tal de

que éste siga siendo útil con el paso del tiempo a los usuarios.

¿Cuándo es apropiado usar la metodología DSDM?

Existen diversos factores para averiguar si el Método de Desarrollo de Sistemas Dinámicos se

adecúa o no a un proyecto concreto. El DSDM es apropiado cuando:

- Se trata de un proyecto que puede verse mejorado a través de las interacciones

- Existe un grupo de desarrollo perfectamente definido y en el que existe una buena

comunicación con el usuario. Cabe destacar este último aspecto, ya que el usuario ha

de participar activamente en el desarrollo del producto, aportando su opinión, sussugerencias, etc.

- Se trata de un proyecto complejo o de gran dimensión pero que puede

descomponerse en diversas partes funcionales más sencillas.

- Existe un límite de tiempo específico en el que el producto ha de ser entregado.

- Se trata de un proyecto con unos requisitos perfectamente priorizados.

- El proyecto sea dinámico y se preste a realizar cambios durante su desarrollo.

¿Cuándo no es apropiado aplicar la metodología DSDM?

El DSDM no apropiado cuando:

- Se trata de un sistema en tiempo real y/o crítico.

- Se trata de un proyecto computacionalmente complejo que impida desglosarlo en

distintas partes más sencillas.

- Todas las exigencias que ha de cubrir el proyecto estén perfectamente predefinidas

desde un principio, antes de la construcción. Esto va totalmente en contra de la

metodología del DSDM, las cual únicamente fija unos requisitos prioritarios (must

have) que el producto ha de cumplir y a partir de ahí, de forma dinámica, se van

aportando nuevas características y funcionalidades al producto (should have, could

have y what we want to have (MoSCoW)).



6

FDD (en Íngles Feature Driven Development) FDD se traduce como Desarrollo Basado en Funcionalidades. Se trata de un enfoque ágil para

el desarrollo de sistemas. La metodología fue desarrollada por Jeff De Luca y Peter Coad,

conocido por ser el gurú de la Orientación a Objetos. Sigue una estructura como la del restometodologías adaptables, pero con algunas diferencias:

No hace énfasis en la obtención de los requerimientos sino en cómo se realizan las fases de

diseño y construcción. Sin embargo, fue diseñado para trabajar con otras actividades de

desarrollo de software y no requiere la utilización de ningún modelo de proceso específico. Por

otro lado hace énfasis en aspectos de calidad durante todo el proceso e incluye un monitoreo

permanente del avance del proyecto, es decir, 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 monitorear.

Además se caracteriza por permitir contrarrestar situaciones como el exceso en el

presupuesto, fallas en el programa o el hecho de entregar menos de lo deseado. Las etapas de

las que se compone, tratan de cerrarse cada dos semanas, obteniendo así un resultado

periódico y tangible.

Procesos

El proceso consta de cinco pasos secuénciales durante los cuales se diseña y se construye el

sistema:

1. Desarrollo de un modelo global.2. Construcción de una lista de funcionalidades.

3. Planeación por funcionalidad.

4. Diseño por funcionalidad.

5. Construcción por funcionalidad.

1.- Desarrollo de un modelo global.

En esta primera fase, los expertos del dominio ya tienen una idea aproximada del contexto y

conocen los requerimientos del sistema. Puede que el documento de especificación de

requerimientos ya exista. Como ya se ha comentado, FDD no se centra en la recolección yadministración de los requerimientos. Los expertos presentan un informe llamado

Modelo global

Lista de

funcionalidadesPlaneación por

funcionalidad

Diseño y

Construcción por

funcionalidad

1

2

3

45



7

walkthrough en el cual los miembros del equipo y el Chief Arquitect son informados a través

de una descripción de alto nivel del sistema.

El dominio global se divide en diferentes áreas, y posteriormente se realiza un walkthrough

detallado para cada una de dichas áreas, más tarde, de cada walkthrough, un grupo de

desarrolladores realizan un modelo de objetos para el área del dominio. Además, el equipo dedesarrollo discute y decide cual es el modelo de objetos más apropiado para cada área del

dominio. Trabajando de este modo, el modelo global del sistema es construido

simultáneamente

2.- Construcción de una lista de funcionalidades.

Una funcionalidad es un ítem útil a los ojos del cliente. En esta fase, se toman los

walkthroughs, el modelo de objetos y los requerimientos existentes para construir una lista

que resuma las funcionalidades del sistema que va a ser desarrollado. En dicha lista, el equipo

de desarrolladores presenta cada una de las funcionalidades evaluadas por el cliente. Lasfuncionalidades son presentadas por cada área del dominio y éstas forman una lista con las

mejores funcionalidades, después, dicha lista de divide en subconjuntos según la afinidad y la

dependencia de las funcionalidades. Éstos representan diferentes actividades con un área

específica del dominio.

Por último, la lista es revisada por los usuarios y sponsors del sistema para su validación y

aprobación.

3.- Planeación por funcionalidad.

Durante esta etapa se incluye la creación de un plan de alto nivel, esto quiere decir que, la listade funcionalidades es ordenada en base a la prioridad y a la dependencia entre otras

funcionalidades. Además, las clases identificadas en la primera etapa son asignadas a cada

programador.

4.- Diseño por funcionalidad.

Hasta la fase tres, la metodología se centraba en selección, selección y organización de las

funcionalidades, pero en la cuarta fase se selecciona unos de esos conjuntos para proceder a

diseñar dicha funcionalidad. Para el diseño, se crea un diagrama de secuencia que contiene la

descripción de las clases y los métodos y notas del equipo, y más tarde se inspecciona y

verifican los diagramas.

5.- Construcción de la funcionalidad.

Una vez tenemos el diseño y la estructura a seguir, se procede a construir la funcionalidad

mediante un proceso iterativo. Una iteración puede durar varios días o incluso dos semanas, y

dicho proceso incluye revisiones de diseño. Codificación, pruebas unitarias e inspección de

código. Cuando todo se ha verificado y está correcto, el sistema está terminado y se procede a

una reunión con el cliente.



8

Roles y responsabilidades

Roles claves

Director del Proyecto: Líder administrativo y financiero del proyecto. Protege al equipo

de situaciones externas.

Arquitecto jefe: Diseño global del sistema. Ejecución de todas las etapas.

Director de desarrollo: Lleva diariamente las actividades de desarrollo. Resuelve

conflictos en el equipo. Resuelve problemas referentes a recursos.

Programador Jefe: Analiza los requerimientos. Diseña el proyecto. Selecciona las

funcionalidades a desarrollar de la última fase del FDD.

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.

Poseen el conocimiento de los requerimientos del sistema. Pasa el conocimiento a losdesarrolladores para que se asegure la entrega de un sistema completo.

Roles de soporte

Domain Manager: Lidera al grupo de expertos del dominio. Resuelve sus diferencias deopinión concernientes a los requerimientos del sistema.

Release Manager: Controla el avance del proceso mediante la revisión de los reportesdel Chief Programmer. Reporta resultados obtenidos semanalmente al gerente, alcliente donde incluye el porcentaje de avance de cada funcionalidad.

Gurú del Lenguaje: Responsable de poseer un vasto conocimiento en, por ejemplo, unlenguaje específico de programación o tecnología. Es muy importante cuando setrabaja una nueva tecnología.

Ingeniero de construcción: Responsable de preparar, mantener y correr el proceso deconstrucción. Realiza el mantenimiento de las versiones y la publicación de ladocumentación.

Herramientista: Rol para la construcción de herramientas específicas para eldesarrollo, conversión de datos y testeo. Puede trabajar en la preparación ymantenimiento tanto de bases de datos o sitios web destinados al proyecto.

Administrador del sistema: Configura, administra y repara los servidores, estaciones detrabajo y equipos de desarrollo y testeo utilizados por el equipo.

Roles adicionales

Tester: Verifica que el sistema recién creado cumpla con los requerimientos del

cliente.

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.

Escritores de documentos técnicos: Prepara la documentación para los usuarios, que

pueden formar parte o no del equipo del proyecto.



9

Herramientas

Como herramienta para manejar y organizar esta metodología, encontramos FDDTools . Dicho

software nos ofrece una sencilla para producir gráficos de seguimiento de proyectos,

detallando fechas de entrega, revisiones y funcionalidades completadas. Por tanto, podemos

compartirlo con nuestro equipo de trabajo.

Conclusiones FDD:

Se implementan mejor para proyectos cortos y equipos más pequeños

no define explícitamente la parte del proyecto sobre la adquisición de requisitos.

Más adecuado para definir métricas que definan el estado del proyecto, puesto que al

dividirlos en unidades pequeñas es bastante sencillo hacer un seguimiento de las

mismas.

FDD es por su parte un proceso intermedio, en el sentido de que genera una

documentación que no es muy extensa ni muy corta.

No se basa en formalismos en la documentación, si no en controles propios y una

comunicación fluida con el cliente.

Se usan las sesiones de trabajo conjuntas en fase de diseño para conseguir una

arquitectura sencilla y sin errores.

http://fddtools.sourceforge.net/






10

CRÍSTAL CLEAR Crystal es una metodología de desarrollo de Software ágil. Más que una metodología se la

considera una familia de metodologías, debido a que se subdivide en varios tipos de

metodologías en función a la cantidad de persona que vayan a estar en el proyecto. Alistair

Cockburn es el propulsor detrás de la serie de metodologías Crystal.

Presentan un enfoque ágil, con gran énfasis en la comunicación y con cierta tolerancia que la

hace ideal en los casos en que sea inaplicable la disciplina requerida por XP.

Crystal “Clear” es la encarnación más ágil de la serie y de la que más documentación se

dispone. Además, Crystal maneja iteraciones cortas con feedback frecuente por parte de

los usuarios/clientes, minimizando de esta forma la necesidad de productos intermedios.

La familia Crystal dispone un código de color para marcar la complejidad de una metodología:

cuanto más oscuro un color, más “pesado” es el método.

Cuanto más crítico es un sistema, más rigor se requiere. El código cromático se aplica a una

forma tabular elaborada por Cockburn que se usa en muchas metodologías ágiles para situar

el rango de complejidad al cual se aplica una metodología.

En la siguiente figura se muestra una evaluación de las pérdidas que puede ocasionar la falla

de un sistema y el método requerido según este criterio. Los parámetros son:

Comodidad (C)

Dinero Discrecional (D) Dinero Esencial (E)

Vidas (L).

La caída de un sistema que ocasione incomodidades indica que su nivel de criticalidad es C,

mientras que si causa pérdidas de vidas su nivel es L.

Los números del cuadro indican el número de personas afectadas a un proyecto.



11

Cuando el número de personas aumenta, también aumenta la necesidad de coordinar.

Cuando el potencial de daños se incrementa, la tolerancia a variaciones se ve afectada.

La sensibilidad del tiempo en que se debe estar en el mercado varía: a veces este

tiempo debe acortarse al máximo y se toleran defectos, otras se enfatiza la auditoria,

confiabilidad, protección legal, entre otros.

Las personas se comunican mejor cara a cara, con la pregunta y la respuesta en el

mismo espacio de tiempo.

El factor más significativo es “comunicación”.

Los métodos se llaman Crystal evocando las facetas de una gema: cada faceta es otra versión

del proceso, y todas se sitúan en torno a un núcleo idéntico.

Hay cuatro variantes de metodologías:

- Crystal Clear (“Claro como el cristal”) para equipos de 8 o menos integrantes

- Amarillo, para 8 a 20- Naranja, para 20 a 50

- Rojo, para 50 a 100.

Se promete seguir con Marrón, Azul y Violeta. La más exhaustivamente documentada es

Crystal Clear (CC), la misma que puede ser usada en proyectos pequeños de categoría D6,

aunque con alguna extensión se aplica también a niveles E8 a D10.

Como casi todos los otros métodos, CC consiste en valores, técnicas y procesos.

Los siete valores o propiedades de Crystal Clear son:

- 1. Entrega frecuente. Consiste en entregar software a los clientes con frecuencia, no

solamente en compilar el código. La frecuencia dependerá del proyecto, pero puede

ser diaria, semanal, mensual o lo que fuere. La entrega puede hacerse sin despliegue,

si es que se consigue algún usuario cortés o curioso que suministre feedback .

- 2. Comunicación osmótica. Todos juntos en el mismo cuarto. Una variante especial es

disponer en la sala de un diseñador senior; eso se llama Experto al Alcance de la Oreja.

- 3. Mejora reflexiva. Tomarse un pequeño tiempo (unas pocas horas durante algunas

semanas o una vez al mes) para pensar bien qué se está haciendo, cotejar notas,

reflexionar, discutir.

-

4. Seguridad personal. Hablar cuando algo molesta: decirle amigablemente almanager que la agenda no es realista, o a un colega que su código necesita mejorarse,

o que sería conveniente que se bañase más seguido. Esto es importante porque el

equipo puede descubrir y reparar sus debilidades. No es provechoso encubrir los

desacuerdos con gentileza y conciliación. Técnicamente, estas cuestiones se han

caracterizado como una importante variable de confianza y han sido estudiadas con

seriedad en la literatura.

- 5. Foco. Saber lo que se está haciendo y tener la tranquilidad y el tiempo para hacerlo.

Lo primero debe venir de la comunicación sobre dirección y prioridades, típicamente

con el Patrocinador Ejecutivo.

- 6. Fácil acceso a usuarios expertos. Es muy importante el contacto directo conexpertos en el desarrollo de un proyecto. No hay un dogma de vida o muerte sobre



12

esto, como sí lo hay en XP. Un encuentro semanal o semi-semanal con llamados

telefónicos adicionales parece ser una buena pauta. Otra variante es que los

programadores se entrenen para ser usuarios durante un tiempo. El equipo de

desarrollo, de todas maneras, incluye un Experto en Negocios.

- 7. Ambiente técnico con prueba automatizada, management de configuración e

integración frecuente. Microsoft estableció la idea de los builds cotidianos, y no es una

mala práctica. Muchos equipos ágiles compilan e integran varias veces al día.

En cuanto a las técnicas, se favorecen:

a) Entrevistas de proyectos. Se suele entrevistar a más de un responsable para tener

visiones más ricas

b) Talleres de refl exión. El equipo debe detenerse treinta minutos o una hora para

reflexionar sobre sus convenciones de trabajo, discutir inconvenientes y mejoras y

planear para el período siguiente.

c) Planeamiento Blitz. Una técnica puede ser el Juego de Planeamiento de XP. En este

juego se ponen tarjetas indexadas en una mesa, con una historia de usuario o función

visible de cada una.

El grupo finge que no hay dependencias entre tarjetas, y las alinea en secuencias de

desarrollo preferidas. Los programadores escriben en cada tarjeta el tiempo estimado

para desarrollar cada función. El patrocinador del usuario escribe la secuencia de

prioridades, teniendo en cuenta los tiempos referidos y el valor de negocio de cada

función. Las tarjetas se agrupan en períodos de tres semanas llamados iteraciones que

se agrupan en entregas, usualmente no más largas de tres meses.

d) Estimación Delphi con estimaciones de pericia. En el proceso Delphi se reúnen los

expertos responsables y proceden a proponer el tamaño del sistema, su tiempo de

ejecución, la fecha de las entregas según dependencias técnicas y de negocios, y

equilibrar las entregas en paquetes de igual tamaño.

e) Encuentros diarios de pie. La palabra clave es “brevedad”, cinco a diez minutos como

máximo. No se trata de discutir problemas, sino de identificarlos.

f) Miniatura de procesos. Una forma de presentar Crystal Clear puede consumir entre 90

minutos y un día. La idea es que la gente pueda “degustar” la nueva metodología.

g) Gráficos de quemado. Su nombre viene de los gráficos de quemado de calorías de losregímenes dietéticos, se usan también en Scrum. Se trata de una técnica gráfica para

descubrir demoras y problemas lo antes posible en el proceso evitando que se

descubran demasiado tarde.

h) Programación lado a lado. Mucha gente siente que la programación en pares de XP

Involucra una presión excesiva; la versión de Crystal Clear establece proximidad, pero

cada quien se enfoca a su trabajo asignado, prestando un ojo a lo que hace su

compañero, quien tiene su propia máquina. Esta es una ampliación de la

Comunicación Osmótica al contexto de la programación.



13

El proceso de Cristal Clear se basa en una exploración refinada de los inconvenientes de los

modelos clásicos. Dice Cockburn que la mayoría de los modelos de proceso propuestos entre

1970 y 2000 se describían como secuencias de pasos.

Cristal Clear enfatiza el proceso como un conjunto de ciclos anidados. En la mayoría de los

proyectos se perciben siete ciclos:

- El proyecto

- El ciclo de entrega de una unidad

- La iteración (nótese que CC requiere múltiples entregas por proyecto pero no muchas

iteraciones por entrega)

- La semana laboral

- El período de integración, de 30 minutos a tres días

- El día de trabajo

- El episodio de desarrollo de una sección de código, de pocos minutos a pocas horas.

Conclusion:

Los métodos Crystal no prescriben las prácticas de desarrollo, las herramientas o los productos

que pueden usarse, pudiendo combinarse con otros métodos como Scrum, XP y Microsoft

Solutions Framework. En un comentario Cockburn confiesa que cuando imaginó a Crystal Clear

pensaba proporcionar un método ligero; comparado con XP, sin embargo, Cristal Clear resultó

muy pesado pero es más fácil de aprender e implementar.

A pesar de su jerga chocante XP es más disciplinado, piensa Cockburn, pero si un equipo ligero

puede tolerar sus rigores, lo mejor será que se mude a XP.



14

AUP (Agile Unified Process) ¿Qué es el AUP?

Esta metodología es una versión más simplificada del Proceso Unificado de Racional (RUP).

Éste lo que hace es coger las mejores prácticas del RUP y la Metodología Ágil. Pero la RUP no

tiene nada que ver con la forma de trabajar de la AUP. El AUP está basada en que de una

manera simple y fácil se puede llegar a una forma de aplicar técnicas para desarrollar

aplicaciones de software dirigidas a los negocios utilizando cómo he dicho antes, técnicas

ágiles. Esto ayuda para entender la forma de desarrollar aplicaciones de software de negocio

usando estas técnicas .Esto último es lo que caracteriza al AUP.

El AUP utiliza además del uso de técnicas ágiles utiliza un Desarrollo Dirigido por Pruebas

(TDD), un modelado Ágil, un gestión de Cambios Ágil, y una refactorización de Base de Datos

para mejorar la productividad.

Características

La metodología AUP es una versión simplificada de la metodología RUP.

Se le caracteriza porque contiene 4 ingenieriles,3 de apoyo y 7 flujos de trabajos. (Modelado,

Implementación, Prueba, Despliegue, Gestión de configuración, Gestión de proyectos y

Ambiente).

Además, el modelo sintetiza los tres primeros flujos de la metodología RUP : Modelamientos,

Requerimientos y Análisis & diseño).

AUP contiene cuatro fases como las contiene el RUP. Éstas son : Incepción o Creación,

Elaboración, Construcción y Transición.

La AUP también se caracteriza por ser iterativa y además incremental. Esto quiere decir que en

el desarrollo de un proyecto importante, éste se divide en pequeños proyectos derivados. Esto

sirve para tener el control de las pequeñas partes y si sale cualquier problema solucionarlo lo

antes posible. A cada pequeña parte de la división del proyecto es una iteración. Esto hace que

vaya poco a poco, y todo vaya saliendo bien como he explicado antes. Cada parte además,

trata un conjunto de casos de uso. Esto lo que hace es que le da importancia a la funcionalidadque el sistema tiene que tener para satisfaces todo lo que el usuario necesite en un futuro. Los

casos de Uso es el que orienta todas las actividades del desarrollo del producto software.

Las ventajas de que ésta metodología se iterativa es que existe una detección de los riesgos y

peligros con anterioridad. Además de una buena administración del cambio en el transcurro de

cada iteración. Todas estas características hacen que exista un grado mayor de reutilización a

parte de la experiencia para el grupo del desarrollo.

La arquitectura que sigue esta metodología es muy parecida a la que contiene una

construcción. Esto se refiere a que existen varios planos de éste, y esto sirve para tener unaimagen global del proyecto antes de que empiece el desarrollo de éste.

http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational



15

Además existe una arquitectura en el software. El cual tiene diferentes modos dentro del

sistema, éstos son por ejemplo : funcional, dinámico, estructural .. etc. Esta arquitectura del

software es la base dónde se realiza el proyecto. Y además, un punto importante, es la que

define la forma del sistema.

Ciclo de vida del proyecto

El AUP se divide en cuatro fases, Incepción, Elaboración, Construcción y por último Transición.

Fase de Incepción: Esta es la fase de inicio del desarrollo del producto. El objetivo de ésta es

establecer un consenso entre los interesados sobre el proyecto en relación a los objetivos de

éste para conseguir el dinero que financiará el proyecto. Las actividades principales son:

1. Definir el alcance del proyecto. Esto quiere decir qué se hará en el sistema y lo que no

se hará, que también es muy importante. Además, se realiza una lista decaracterísticas del nivel o de puntos de casos de uso, donde se establecerán los límitesdesde los cuales trabajarán el equipo. Esto suele tomar la forma de una lista decaracterísticas de alto nivel y / o el punto de casos de uso.

2. Estimación de costos y calendario. En un nivel importante del proyecto, existe unas

estimaciones en el calendario y en el costo del proyecto. Las estimaciones principalesse realizan en fases posteriores, y se implementarán en la fase de Elaboración. Lastareas que van a ser realizadas en el futuro son especificadas con más precisión y conbastante confianza mientras que las tareas bajo la línea son estimadas y que no esposible programar todo en un proyecto, en la salida con cualquier grado aceptable deconfianza con un margen de error mayor. Normalmente, se planifican para corto plazoy precisar a lo largo plazo.

3. Definición de Riegos. Los riesgos que pueden aparecer en el transcurro del desarrollo

se definen en esta parte. La administración del riego es importante en proyectos deAUP. La lista de riegos se modifica cuando los riesgos son identificados, evitados,exterminados, solucionados… El control de riegos del proyecto son los que llevan a

cabo la programación de las iteraciones. Los riegos más altos son dirigidos eniteraciones anteriores que los riegos de menor prioridad.



16

4. Determinar la factibilidad del proyecto. El proyecto tiene que ser capaz de crear un

sentido desde la perspectiva operacional técnica y del negocio, y tiene que ser dellevarlo a cabo. Si el proyecto no es viable, será suspendido.

5. Preparar el entorno del proyecto. Aquí se prepara el área de trabajo. Conseguir al

personal, obtener todo el material ( hardware y software). Además, deberá ajustar

AUP para completar las necesidades de su equipo.

La fase de Iniciación acaba con el hijo de Objetivos del Ciclo de Vida.El objetivo principal es queel equipo de desarrollo tenga claro el alcance del proyecto y todo el esfuerzo que conlleva. Sino finaliza esto, el proyecto tendrá que ser cancelado o suspendido.

Los Artefactos (Pieza de información producida, modificada y utilizada en un Proceso) es eldocumento que define todo el proyecto.

Fase de Elaboración:

En esta fase, el objetivo es probar la arquitectura del sistema que se desarrollará. La cosa esque el equipo sea capaz de desarrollar un sistema que cumpla con los requisitos, y para ello esnecesario construir una especia de esqueleto que recorra todo el sistema del trabajo(prototipode la arquitectura).Esto un concepto pobre pero su significado es software funcional de altonivel, el cual incluye varias casos de uso de alto riegos para demostrar que el sistema estécnicamente factible.

No todos los requisitos se especifican en esta fase. Se especifican lo justo como paracomprender los riesgos de la arquitectura y asegurar que haya un entendimiento de losalcances de cada requerimiento para que la fase siguiente se lleve a cabo. Los riegos de laArquitectura son identificados y priorizados durante la Elaboración. El nivel de la arquitectura

del sistema tiene que reflejar la arquitectura general de la empresa también.

Durante la Elaboración, el equipo también piensa en la Fase de Construcción, y se prepara paraello. Una vez con todo el material necesario de Hardware y de Software, el equipo crea elambiente de trabajo según la arquitectura del sistema establecido. Desde la Administración delProyecto se dirige a todas las personas del proyecto.

La fase de Elaboración termina con el hito de la Arquitectura del Ciclo de Vida. Con esto, se vesi el equipo contiene un prototipo viable para empezar con la producción, y que la financiaciónsigue adelante. Si por cualquier circunstancia, el equipo no pasa esta prueba, el proyecto secancelará.

Los artefactos que contiene esta fase cuenta con un modelo del dominio, un modelo deprocesos, un modelo funcionas del alto nivel, y una arquitectura básica del proyecto.

Fase de Construcción:

Esta fase de Construcción tiene como objetivo el desarrollo del sistema hasta la pre-

producción de éste en diferentes pruebas. En fases anteriores, los requisitos generalmente

eran identificados y ahora, la arquitectura del sistema se ha establecido. Lo más importante es

dar prioridad y entender todos los requerimientos que conlleva esta fase, el modelado que

ataca una solución, y más tarde sería la codificación y todas las pruebas para el software. El

http://cgi.una.ac.cr/AUP/html/environment.html

http://www.agiledata.org/essays/enterpriseArchitecture.html

http://cgi.una.ac.cr/AUP/html/construction.html

http://cgi.una.ac.cr/AUP/html/construction.html

http://www.agiledata.org/essays/enterpriseArchitecture.html

http://cgi.una.ac.cr/AUP/html/environment.html



17

hecho es que, existen unas versiones para que se obtengan unos comentarios de los usuarios

sobre el proyecto.

La fase de Construcción finaliza con el hito de la Capacidad Operativa Inicial. En esta fase, elequipo se plantea si la versión que tiene actualmente es la buena, ya que ésta es la que tiene

que ir ahora a la fase de pre-producción y pasar todas las pruebas. Si el equipo, no pasa estafase, el proyecto se debe cancelar o suspender. Si no, el quipo para a la fase de Transición.

Fase de Transición:

El objetivo de esta fase es la de llevar el sistema a producción. Para ello existen un tipo de

pruebas en el transcurro de esta fase. Una peculiaridad de esta fase es el retrabajo que

consiste en que si el usuario ve algún defecto importante en la versión actual del proyecto.

El tiempo y esfuerzo que conlleva esta fase cambia de un proyecto a otro. Shrink-wrappedsoftware supone la fabricación y distribución de software y documentación. Los sistemas

internos son más simples de desplegar que sistemas externos generalmente. Los sistemas queconllevan un alto nivel pueden requerir pruebas betas extensivas por grupos pequeños antesde entregársela a los usuarios. La liberación de un nuevo sistema de marca puede traerconsigo la compra y configuración de hardware mientras se actualiza un sistema existente quetambién puede traer una conversión de datos y una coordinación exhaustiva con la comunidadde usuarios. Cada proyecto comparado con otros es diferente. Cada proyecto se desarrollasegún sus necesidades.

Esta fase de Transición acaba con el hito de la Liberación del producto. Un problema que surgeen esta fase, que es bastante importante, es declara que el sistema está preparado para unaproducción segura y eficiente. Si el proyecto no sale como se pensaba ,y fracasa el proyecto

tiene dos opciones o ser redirigido dándole otro enfoque o utilizando otros recursos o sercancelados. Si el equipo pasa este hito el proyecto se mueve a producción.

Conclusión

Esta metodología hace realmente hincapié en la gestión de riesgos. Para solucionar, explica

que cuando surgen problemas con un alto riesgo, se le tienen quedar prioridad en el proceso

de desarrollo, y así solucionarlas lo antes posible.

El Modelo, objetivo de esta disciplina que es la de entender el negocio de organización, es

mucho más simple que la de RUP.Y con esto, agrupa en una sola disciplina todas las disciplinas

de Modelado de Negocio, Requisitos, Análisis y diseño. Las demás disciplinas restantes que

lleva esta metodología son las mismas que las de RUP.

http://www.agiledata.org/essays/legacyDatabases.html

http://www.agiledata.org/essays/legacyDatabases.html



18

Comparaciones Para realizar la comparación entra las diferentes metodologías, trataremos los siguientes

aspectos:

Tamaño de los equipos:Por un lado, tenemos DSDM y FDD, que son más adecuados para equipos pequeños con el

motivo de asegurar una buena comunicación, Crystal divide por colores según el tamaño del

grupo: 3 a 8 integrantes; Amarillo, de 8 a 20; Naranja, 20 a 50; Rojo, 50 a 100; por último, el

tamaño del equipo en AUP es relativo, ya que se puede probar con proyectos de nivel.

Obtención de los requisitos:

Los principales requisitos DSDM se definen durante la fase del Pre-Proyecto, donde se estudia

la viabilidad y la financiación de éste. Al contrario, FDD no define explícitamente la parte del

proyecto sobre la adquisición de requisitos. En AUP de definen de forma detallada al principio

del desarrollo del producto.

Evaluación del estado del proyecto:

En la metodología AUP y DSDM se realizan pruebas durante todas las fases del ciclo de vida, lo

cual permite una temprana detección y solución de errores. También el uso de FDD es

adecuado si se desea conocer correctamente el estado del proyecto, puesto que al dividirlos

en unidades pequeñas es bastante sencillo hacer un seguimiento de las mismas.

Carga de trabajo:

La carga del trabajo en DSDM depende del integrante del grupo, que debe asumir su rol y ser

capaz de gestionar las actividades que se le han asignado. Luego, CC maneja iteraciones cortas

con feedback frecuente por parte de los usuarios/clientes, minimizando de esta forma la

necesidad de productos intermedios. Hablando de cantidad de documentación, FDD genera

una cantidad intermedia, es decir, algo más que AUP, donde existe una gran simplicidad,

haciendo que todo se escriba en pocas páginas, y no en miles de ellas.

Relación con el cliente:

En DSDM es vital. El cliente, que sigue de cerca el desarrollo del producto, aporta sugerencias

para la mejora de éste tras cada prueba. El equipo de desarrollo ha de estar constantemente

en contacto con el cliente para asegurar la creación de un producto de calidad y que se adapte

a sus exigencias. FDD y Crystal destacan por una comunicación fluida con el cliente. La

frecuencia dependerá del proyecto, pero puede ser diaria, semanal, mensual o lo que fuere.

En cambio, en AUP, el cliente se muestra activo al final de cada se para dar la aprobación de si

el proyecto puede llegar a ser factible.



19

Desarrollo:

El desarrollo en DSDM es muy dinámico, ya que a menudo se están realizando pruebas,

solventando errores y cambiando los requisitos según la marcha. FDD también se centra más

en la organización global y en la ejecución de pruebas, asumiéndolas como obligatorias. Es

posible utilizar programación por parejas en partes complejas.

En Crystal, el desarrollo se produce con todo el equipo junto en el mismo cuarto. Una variante

especial es disponer en la sala de un diseñador senior.

En AUP hay un claro seguimiento del producto a cada paso, se fija un objetivo y es de analizar

cualquier posible error y solucionarlo lo antes posible.

Código fuente:

FDD se diferencia del resto en que, al ser funcionalidades independientes, el código es

propietario, aunque hay puesta en común, sobretodo cuando se trabajan en clasesrelacionadas. Muchos equipos ágiles compilan e integran varias veces al día.

En AUP Las distintas funcionalidades se trabajan por separado, y más tarde se solapan.

Conocimiento sobre la arquitectura:

En FDD se usan las sesiones de trabajo conjuntas en fase de diseño para conseguir una

arquitectura sencilla y sin errores. DSDM cada departamento se encarga de organizar su

estructura y en AUP la arquitectura se establece en la fase de Elaboración, no se modificará, y

se establecerá ya en las próximas fases.

Puntos flacos:

En DSDM es totalmente inviable para sistemas críticos que supongan algún riesgo para el

exterior (por ejemplo aquellos que traten con productos tóxicos, radioactivos, etc.). Además

requiere una fuerte participación por parte del usuario y la organización puede ser dificultosa

en equipos sin mucha experiencia.

El talón de Aquiles de FDD es la necesidad de tener miembros con experiencia que marquen el

camino a seguir desde el principio, además que, debido a que existen jerarquías, puede

provocar grandes dependencias de la gente experimentada.

Cristal Clear resulta muy pesado pero es más fácil de aprender e implementar. Si un equipo

ligero puede tolerar sus rigores, lo mejor será que se mude a XP. Resulta que XP es más

disciplinado.

Por último, de AUP puede resultar un proyecto muy pesado y complejo. Ya que está mucho

más detallado. Hay que cumplir los alcances estimados en cada fase, si no el proyecto será

cancelado y la exigencia del nivel técnico del personal es alto, ya que se necesita exprimir

todas las ventajas posibles y proporcionar un buen producto.



20

Referencias DSDM

Explicación del DSDM

Transparencias Wikipedia

FDD

Transparencias FDD

Documento FDD

Definición y comparación con XP y RUP

Crystal Clear

Blog Tercer Planeta, Capacidades Técnicas

SECCPERU, Metodologías Ágiles

Documentación Crystal Clear

AUP

AUP ecured Documentación AUP

WIKI AUP

http://jummp.wordpress.com/2011/04/13/desarrollo-de-software-metodo-de-desarrollo-de-sistemas-dinamicos-dsdm-i/


http://www.agilexp.com/presentations/DSDMexplained.pdf


http://es.wikipedia.org/wiki/M%C3%A9todo_de_desarrollo_de_sistemas_din%C3%A1micos


http://www.google.es/url?sa=t&rct=j&q=feature-driven%20development%20(fdd)&source=web&cd=1&ved=0CDoQFjAA&url=http%3A%2F%2Fpisis.unalmed.edu.co%2Fcursos%2Fmaterial%2F3004582%2F1%2FPresentacionFDD.ppt&ctbs=lr%3Alang_1es&ei=7YJUT_3RNoSn8QP46N3wBQ&usg=AFQjCNGnuLoYyVDareAQYeyBpZQojqH0Xg&sig2=5_h2wKqBxeRMRuJhNq_CGg


http://www.google.es/url?sa=t&rct=j&q=feature-driven%20development%20(fdd)&source=web&cd=16&ved=0CFwQFjAFOAo&url=http%3A%2F%2Ftaller281.wikispaces.com%2Ffile%2Fview%2FFeature%2BDriven%2BDevelopment.doc&ctbs=lr%3Alang_1es&ei=e4NUT43SIIjd8gOSntHwBQ&usg=AFQjCNH6Am5AS6nI9RxFvhpVr4_9SsnWig&sig2=heMa_7P_AAAph71J7W_AzQ


http://www.willydev.net/descargas/Articulos/General/cualxpfddrup.PDF


http://blog.tercerplaneta.com/2007/02/ms-all-de-las-capacidades-tcnicas-que.html


http://seccperu.org/files/Metodologias%20Agiles.pdf


http://www.google.es/url?sa=t&rct=j&q=crystal%20clear%20metodologia%20agiles&source=web&cd=6&ved=0CEsQFjAF&url=http%3A%2F%2Fwww.cs.umss.edu.bo%2Fdoc%2Fmaterial%2Fmat_gral_130%2FMetodologia%2520Crystal.doc&ei=lNdYT8ekFaWr0QXyv-XNDQ&usg=AFQjCNGSNk8rFOnMjkBl9sUYztUbB2qnxQ&sig2=uP31FoR0mLni7Z5tVAsVNQ


http://www.ecured.cu/index.php/Agile_Unified_Process#Caracter.C3.ADstica_de_AUP


http://www.test2008.in/Test2008/pdf/Sidd%20Prabhudas%20-%20Agile%20Unified%20Process.pdf

http://cgi.una.ac.cr/AUP/html/milestones.html#LCA



http://www.test2008.in/Test2008/pdf/Sidd%20Prabhudas%20-%20Agile%20Unified%20Process.pdf











práctica 3 aesm metodologías Ágiles

Documents