Upload
cristian-vazquez
View
372
Download
0
Embed Size (px)
Citation preview
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 1/21
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 2/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
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 3/21
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
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 4/21
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.
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 5/21
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/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 6/21
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)).
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 7/21
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
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 8/21
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.
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 9/21
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.
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 10/21
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.
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 11/21
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.
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 12/21
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
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 13/21
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.
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 14/21
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.
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 15/21
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.
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 16/21
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.
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 17/21
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
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 18/21
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.
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 19/21
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.
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 20/21
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.
5/14/2018 Práctica 3 AESM Metodologías Ágiles - slidepdf.com
http://slidepdf.com/reader/full/practica-3-aesm-metodologias-agiles 21/21
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