AGIL

Es la capacidad de crear y responder a los cambios con el fin de obtener ganancias en un

ambiente de negocios turbulento. Es la capacidad de equilibrar la flexibilidad y la
estabilidad. Agile es ser adaptable a los cambios, ser capaz de hacer frente al cambio.

CRYSTAL

Comunicacin cara a cara entre los miembros del equipo y aprendizaje basado en la
retroalimentacin para futuras operaciones.

SCRUM

Se centra en la realizacin de trabajo en intervalo de tiempos llamado Sprints. Adems del

sprint SCRUM tiene una serie de reuniones a intervalos regulares (timebox) para ayudar a
los stakeholders con el seguimiento del proyecto.

https://prezi.com/qxjk5edz-nj4/metodologia-agil-dynamic-system-development-method-
dsdm/

http://ingenieriadesoftware.mex.tl/52827_DSDM.html

https://es.wikiversity.org/wiki/Dynamic_Systems_Development_Method

https://es.slideshare.net/MSJara/dsdm-74296631

https://www.scrummanager.net/bok/index.php?title=DSDM
CAPITULO 7: DSDM (METODOS DINAMICOS DE DESARROLLO DE SISTEMAS)

Introducido en 1994 como una posible solucin al desarrollo rpido de aplicaciones no

estructurada (RAD). DSDM sigue de cerca un enfoque iterativo e incremental, que es el
sello distintivo de la metodologa agile.

Contrariamente a las tcnicas tradicionales de cascada. DSDM establece el costo, la

calidad y el tiempo desde el principio y ajusta lo resultados del proyecto para cumplir con
los criterios establecidos, dando prioridad a los entregables

Introducido en 2007, se centra tanto en la priorizacin de los entregables como en la

colaboracin constante entre el usuario y el cliente.

La versin ms reciente est inspirada en una ternera rtica, de la que deriva su nombre,
ya que personifica libertad, robustez y aptitud de colaboracin, por lo que es un marco de
desarrollo de software centrado en el desarrollador para la entrega a tiempo y en
presupuesto y de las caractersticas del proyecto de calidad controlada valorado por los
usuarios.

El mtodo DSDM es un mtodo de desarrollo gil que se apoya en una continua interaccin
con el usuario, consiguiendo una gran implicacin. Esto produce un sistema sensible a los
requisitos cambiantes del usuario, y que ser capaz de adaptarse mucho mejor a las
necesidades de la empresa. Fue creado para ser un sistema de resolucin sencilla de
tareas complejas, para ello se utilizan una serie de principios y valores, junto a una
organizacin de equipo especfica y con roles, y una serie de fases y etapas a seguir
durante el desarrollo del software.

El consorcio DSDM fue fundado en 1994 por un conjunto de vendedores y expertos en el

sector de la Ingeniera de Software. Se cre con el objetivo de un "Desarrollo conjunto
promocionando un entorno de trabajo de desarrollo gil", combinando las mejores
experiencias obtenidas en prctica.

Principios y Valores

Los mtodos de desarrollo giles tienen una serie de valores como son dar ms valor a
los individuos en lugar de a las herramientas, o valorar mejor un software que
funciona bien en lugar de una buena documentacin. El mtodo DSDM utiliza 9
principios para aplicar estos valores.
1.- La obligacin del usuario de implicarse:
Es considerado el ms importante de los principios. Esto es debido a que la implicacin del
usuario en el desarrollo reduce en gran parte el nmero de errores y, por consiguiente, el
dinero y tiempo utilizado para corregir los mismos. Por lo general, se trabaja con un pequeo
nmero de usuarios selectos, haciendo pequeas revisiones peridicas. Estos usuarios se
mantendrn durante el desarrollo del Software consiguiendo as una imagen ms fiel del
software deseado. La continuidad, por otra parte, es uno de los valores que se aplican en
los principios.

2.- Los equipos deben de tener el poder de tomar decisiones.

Para poder proceder de la manera ms rpida posible y sin depender de otras personas,
todos deben de tener poder para tomar decisiones independientemente de los dems
integrantes del equipo. Requerir la autorizacin de otras personas para poder proceder a
actuar segn decisiones tomadas ralentiza el proceso de creacin del software, por ello, a
todos los trabajadores se les da permiso para tomar decisiones que afectan a: Requisitos
en desarrollo. Requisitos cuya funcionalidad se necesita en futuras interacciones.
Priorizacin de requisitos y caractersticas. Detalles tcnicos.

3.- Realizacin de entregas tempranas.

Las entregas tempranas garantizan la deteccin rpida de errores para que sean corregidos
y revertidos rpidamente antes de que el coste de reparacin sea demasiado elevado.
Estas entregas afectarn tanto al software como a la documentacin que se entregar junto
al software terminado.

4.- Las entregas que se acepten han de ser adaptadas a la empresa.

El software que entreguemos ha de ser capaz de satisfacer las necesidades de la empresa.
Por lo general, la Refactorizacin, el diseo y la mejora de las funciones son tareas que en
los sistemas de modelado de software solo realizan una vez, al comienzo como es el diseo,
o al final como es la refactorizacin o mejora de las funciones. Sin embargo, el DSDM
sostiene que estas tareas han de formar parte del ciclo de vida del software y han de ser
tareas que se deben de repetir una vez con cada una de las entregas que la empresa haya
aceptado para as conseguir una mayor adaptacin a la empresa y, como hemos dicho
antes, que los errores no se hagan mucho ms grandes y su coste de reparacin no se
eleve demasiado. Por otra parte, repitiendo estas fases una y otra vez se consigue una
mucha mejor aproximacin al software que desea la empresa.
5.- El desarrollo es Iterativo e Incremental.
El desarrollo Iterativo e Incremental es el que mejor se adapta a todos los principios
anteriores, y adems facilita la divisin de las tareas para una mejor y ms fcil organizacin
del trabajo. En este desarrollo el software se va haciendo ms grande con cada iteracin
hasta conseguir con la ltima que el software se haya adaptado completamente a lo que la
empresa necesitaba. Este principio se basa en el concepto de que todo software est sujeto
a cambios. Por ltimo, cuantas ms pequeas sean las iteraciones, ms fcil ser identificar
y realizar los cambios que hay que realizar.

6.- Todos los cambios que se hagan durante el desarrollo han de ser reversibles.
Como el propio ttulo indica, cualquier cambio que nosotros realicemos debe de poder ser
revertido con facilidad y sin suponer excesivos costes. Esto es debido a que los principios
anteriores hacen que los cambios surjan continuamente y si no se tiene un control sobre
ellos puede que el tiempo que tardemos en realizarlos sea excesivo. Por ello todos los
cambios que se realicen han de ser escritos ideando que sean sencillos de eliminar o
revertir. Es cierto que este principio pueda hacer que realicemos trabajo para nada si
nuestros cambios se revierten al final, pero sin ello, los principios que sigue el mtodo
DSDM no sera aplicable dado que generara trabajo muy grande procedente de la continua
comunicacin con usuario y cliente.

7.- Los requisitos se describen en alto nivel y tendrn una lnea base.
El DSDM hasta el momento propone que haya una gran libertad a la hora de cambiar los
requisitos. Para limitarlos se establecen una serie de requisitos en alto nivel al comenzar el
proyecto, formando una Lnea Base sobre la que desarrollar. As se forma una idea del
alcance que deben tener los requisitos y nos aseguramos que los cambios no alteran
demasiado la funcionalidad del ECS.

8.-Las pruebas se integran a lo largo del ciclo de vida.

Por lo general, las pruebas es una de las ltimas fases que forman proceso de ingeniera
del software, siendo estas las que se realizan despus de la codificacin. Sin embargo, el
modelo DSDM defiende que para conseguir una rpida correccin de los errores, las
pruebas deben integrarse dentro de las fases ms tempranas de la elaboracin y repetirse
en mltiples ocasiones durante el ciclo de vida del software.

9.- Enfoque cooperativo y colaborativo.

La programacin cooperativa es comnmente utilizada en mtodos de desarrollo gil. Estas
tcnicas aceleran la resolucin de problemas y la construccin de un software ms eficiente
y con menos errores. La ms comn es la programacin por parejas en la que, mientras
una de las dos personas codifica, la otra piensa y resuelve como realizar el algoritmo o la
clase que hay que escribir a continuacin adems de revisar y ayudar a su compaero y
viceversa.

Organizacin y Roles

Patrocinador ejecutivo: Es el rol ms alto que adopta la organizacin. Es la fuente que

proporciona fondos y recursos al proyecto. Es la posicin ms alta que toma decisiones.

Visionario: Es el que tiene la responsabilidad de iniciar el proyecto. El visionario es el que

proporciona las necesidades que tiene la empresa del software. El visionario tiene tambin
la tarea de supervisar que el proyecto se desarrolla correctamente.

Usuario Embajador: Proporciona al proyecto la informacin proveniente de la

comunidad de usuarios. Tiene la obligacin de asegurar que los desarrolladores reciben
suficiente informacin de la comunidad de usuarios durante la fase de desarrollo.

Usuario Consejero: Es cualquier usuario que proporcione al proyecto un buen punto de

vista de la aplicacin.

Jefe de Proyecto: Es la persona encargada de gestionar el proyecto en general.

Coordinador Tcnico: Es el responsable de organizar la arquitectura del proyecto y

controlar la calidad del software generado.

Lider de Equipo: Se asegura de que el equipo funciona correctamente.

Desarrollador: Interpreta los requisitos de sistema y los modela y desarrolla el cdigo.

Probador Tester. Es el encargado de comprobar que el software funciona correctamente

as como de generar la documentacin.

Escriba: Toma nota de todos los requisitos, acuerdos y cambios que se realizan.

Facilitator: Es la persona que se encarga de controlar el progreso facilitar y potenciar la

comunicacin y el desarrollo.
Fases y Etapas de DSDM

Como todo modelo de proceso de Ingeniera de software, el DSDM est dividido en fases
y etapas para organizar mejor las tareas a realizar en el desarrollo del software. El modelo
DSDM consta de 3 grandes fases, El pre-proyecto, Ciclo de vida del software, y Post-
Proyecto.

1.- El Pre-Proyecto:

En esta fase se producen varias sugerencias de proyectos candidato, entre las cuales se
elige una candidata. Adems en esta fase se realiza una estimacin de los fondos
necesarios para desarrollar el proyecto y se decide si el proyecto se va a realizar o no.

2.- El Ciclo de vida del Software:

El objetivo de esta fase es la construccin del proyecto planteado en la fase de Pre-

Proyecto. Esta fase est subdividida en fases:

2.1- Estudio de Viabilidad y de Negocio.

Los estudios que se plantean a continuacin han de ser lo ms cortos y esquemticos

posibles pero con la mayor completitud posible, dado que la creacin de un documento
demasiado complejo retrasara el proyecto, pero unos buenos estudios nos ayudarn a
enfocarlo mejor.

2.1.1- Estudio de Viabilidad:

En esta fase se realizan reuniones para determinar aquellas ideas que no tienen que ver
con el proyecto en s, sino con la gestin del proyecto. Las respuestas ayudarn a
direccionar el desarrollo del proyecto determinando sus costes, la adaptacin de este al
modelo DSDM, los riesgos que existen, etc... Produciendo un documento de Viabilidad.

2.1.2- Estudio de negocio:

Es un documento que extiende al estudio de flexibilidad y que se realiza nicamente se

haya decidido que el proyecto se puede desarrollar mediante DSDM. En esta fase se
intentarn definir caractersticas del proyecto, as como las necesidades que esperan los
usuarios de el. Al final del estudio se determinar una lista de requisitos, que se priorizarn
segn su necesidad para el desarrollo del resto de requisitos.
2.2- Iteracin de Modelo Funcional (Functional Model Iteration)

En esta fase se recogen los requisitos identificados en fases anteriores y se transforman en

Modelos Funcionales. Para ello se crean prototipos funcionales de los requisitos que dan
una idea al usuario de cmo va a funcionar la aplicacin y as satisfacer el principio nmero
1. Los prototipos funcionales son revisados por diferentes grupos de usuarios que valoran
y certifican la calidad del prototipo.

2.3- Iteracin de diseo y desarrollo (Design & Build Iteration)

La principal tarea de esta fase es transformar los Modelos funcionales obtenidos de la fase
anterior y completarlos para que satisfagan totalmente las necesidades del usuario. Para
ello, crearemos Prototipos de diseo, y al igual que en la fase anterior, los verificaremos
con los usuarios.

2.4- Implementacin

Por ltimo, en la fase de implementacin, los usuarios verifican que los prototipos cumplen
con lo deseado y se realiza la implementacin de los mismos, as como el entrenamiento
de los futuros usuarios para que sepan utilizar la aplicacin.

3.- El Post-Proyecto.

Esta fase se utiliza para comprobar que el producto funciona correcta y eficientemente. En
esta fase se realizan tareas de mantenimiento, y de mejora del software si son requeridas.
Por lo general esta fase se produce durante los 6 meses siguientes a la entrega del proyecto
al cliente.
CAPITULO 8: CRYSTAL

https://es.slideshare.net/fvalerolujano/metodologias-giles-crystal-clear

https://es.slideshare.net/mikyWatt/metodologias-agiles-15338080

https://www.youtube.com/watch?v=wdImzanLf_U

https://www.youtube.com/watch?v=p3Rv7jS6f2s&t=66s

https://www.youtube.com/watch?v=-vVF7In63TU&spfreload=5

http://www.javiergarzas.com/2012/09/metodologias-crystal.html

https://es.scribd.com/doc/211905120/Metodologias-Crystal

Es una familia de metodologas de desarrollo que son flexibles, ligeras, y que se puede
adaptar a cualquier tipo de proyecto. Crystal se introdujo en la dcada de 1990 por Alistair
Cockburn, un pionero de agile y unos de los autores del manifiesto gil.

Segn Cockburn Crystal es una familia de metodologas impulsadas por humanos, adaptivo
ultraligero.

La familia de cristal incluye Crystal Clear, Crystal Yelow, Crystal Orange y otros.

Todas estas metodologas trabajan en la idea de que cada proyecto tiene sus propias
caractersticas nicas y requiere una metodologa de desarrollo hecho a medida.

Como sucede tambin con cada metodologa agile, Crystal tambin da importancia a las
personas mayores de los procesos y herramientas.

La interaccin entre los miembros del equipo es importante y que tambin exige la
participacin activa del usuario.

Un equipo decidir en una metodologa especial de crystal en funcin de su tamao y

naturaleza del proyecto.

Crystal Clear no es una metodologa en si misma sino una familia de metodologas con un
cdigo gentico comn.

El nombre cristal deriva de la caracterizacin de los proyectos segn 2 dimensiones,

tamao y complejidad (como en los minerales color y dureza).
La metodologa cristal la cual identifica con colores diferentes cada mtodo y su eleccin
debe ser consecuencia del tamao y criticidad del proyecto, de forma que los de mayor
tamao o aquellos en los que la presencia de errores o desbordamientos de agendas
implique consecuencias graves deben adoptar metodologas ms pesadas de esta forma
se pretende obtener mayor rentabilidad en el desarrollo de proyectos de software.

Clear: Para equipos de hasta 8 personas o menos.

Amarillo: Para equipos entre 10 a 20 personas.
Naranja: Para equipos entre 20 a 50 personas.
Roja: Para equipos entre 50 a 100 personas.
Azul: Para equipos entre 100 a 200 personas.

Crystal da vital importancia a las personas que componen el equipo de un proyecto y por lo
tanto sus puntos de estudio son:

Aspecto humano del equipo

Tamao del equipo
Comunicacin entre los componentes
Distintas polticas a seguir
Espacio fsico de trabajo

Roles:

Sponsor Ejecutivo: (Patrocinador Ejecutivo): Produce la declaracin de misin con

prioridades de compromiso. Es la persona que finalmente permite la realizacin del
proyecto. Esta persona provee el dinero necesario para la ejecucin inicial del proyecto y
suministra la gua indispensable para el resto del equipo, logstica y suporte emocional,
deber ser una persona experta sobre el proyecto. Produce la declaracin de misin con
prioridades de compromiso.
Coordinador: Con la ayuda del equipo produce el mapa de proyecto, el plan de entrega, el
estado del proyecto. Suele ser una ocupacin parcial para los integrantes del equipo, es un
papel que muchos podran desempear, un patrocinador ejecutivo o un desarrollador lder
por lo general cumplen con estas funciones. La persona ocupando el cargo de coordinador
deber como mnimo tomar nota de cmo va el proyecto, planeando y verificando estado
de cada sesin, combinando toda esta informacin para posteriormente publicarla. El
coordinador es responsable de mantener el orden, reducir conflictos y facilitar discusiones.
Experto en Negocio: Debe conocer las reglas y polticas de la empresa, junto con el
usuario experto produce la lista de actores objetivos. Deber permanecer en contacto con
los desarrolladores, realizando preguntas frecuentes sobre la ejecucin del sistema. Es el
experto en materia de negocio y verifica su estado.
Usuario Experto: Debe familiarizarse con el uso del software sugerir mejoras e ideas, en
definitiva, implementar una buena interfaz de cara a los usuarios finales. El sistema en
desarrollo debera responder mejor, cuando el equipo de desarrollo se encuentra en
contacto con usuarios expertos del sistema. El valor que un sistema puede aportar a la
organizacin es muy importante de acuerdo a la informacin que los desarrolladores
lograron obtener de este tipo de usuarios.
Diseador Jefe o Principal: Produce la descripcin arquitectnica. Se supone que es un
profesional de nivel. Esta persona deber ser el mejor desarrollador del equipo, y quien en
principio lograra desarrollar el sistema por completo. Esta persona ayudara a los dems
miembros del equipo y servir como un modelo para los integrantes ms jvenes.
Mantendr contacto permanente con el patrocinador ejecutivo y los usuarios finales,
diseara el plan del proyecto y coordinara a otros desarrolladores.
Designer Programmer (Programador Diseador): Produce, junto con el Diseador
Principal los borradores de pantalla. Es muy importante fusionar estos dos conceptos un
programador y sin diseo, solo lograra obtener un cdigo lleno de errores, es importante
que esta persona del equipo presente estas caractersticas. Este produce junto con el
diseador principal el cdigo necesario para la ejecucin del sistema.
Tester (Realizador de Pruebas): Se encargar de producir informes de errores de ltima
hora. Este papel, en grupos pequeos de trabajo por lo general son alternados entre los
diferentes miembros del equipo, cualquier miembro del equipo est en la facultad de
producir los reportes, sobre el estado del proyecto o del sistema en desarrollo.
Escritor: Producir el manual de ayuda para el usuario. Al igual que el verificador, este
suele ser alternador por los diferentes miembros del equipo, por lo general el papel que
desempea es de plasmar el manual de usuario del sistema

Estas metodologas dependen de dos factores importantes como lo son: el nmero de

personas en el proyecto y las consecuencias de los errores.

Principios:

Documentar los requerimientos

Imposible eliminar toda la documentacin
Ajuste a la forma de trabajo

Alistair Cockburn defini los siguientes principios dentro de sus metodologas:

Las personas son seres comunicativos, hacindolo mejor cara a cara, en persona, con
preguntas y respuestas en tiempo real.

Las personas tienen problemas para actuar de manera consistente todo el tiempo

Las personas son altamente variables (cambiantes), varan de un da a otro y de un lugar a

otro.

Las personas generalmente quieren ser buenos ciudadanos, son buenos observando,
tomando iniciativas y haciendo todo lo que sea necesario para el proyecto funcione.

Propiedades o caractersticas de la metodologa Crystal

1 Entregas frecuentes, en base a un ciclo de vida iterativo e incremental. En funcin del

proyecto puede haber desde entregas semanales hasta trimestrales. Para los que conozcan
Scrum: en Scrum las entregas son, mximo, cada 4 semanas, en las Crystal se contemplan
muchas ms opciones.
2 Mejora reflexiva. Que viene a ser mejora continua. Las iteraciones ayudan a ir
ajustando el proyecto, a ir mejorndolo.
3 Comunicacin osmtica. Traducido al castellano, que el equipo est en una misma
ubicacin fsica, para lograr la comunicacin cara a cara.
4 Seguridad personal. Todo el mundo puede expresar su opinin sin miedos,
tenindosele en cuenta, considerndose su opinin, etc.
5- Enfoque. Perodos de no interrupcin al equipo (2h horas), objetivos y prioridades claros,
definiendo as tareas concretas. Si llevas desde hace tiempo pasando por este blog,
recordars ya comentbamos, tiempo a, aquello de que el entorno fsico afecta al
rendimiento del desarrollador software (te dejo aquel post).
6 Fcil acceso a usuarios expertos. Las Crystal (a diferencia de otras como XP) no
exigen que los usuarios estn continuamente junto al equipo de proyecto (no todas las
organizaciones pueden hacerlo), s que, como mnimo, semanalmente debe haber
reuniones y los usuarios deben estar accesibles.
7 Entorno tcnico con pruebas automatizadas, gestin de la configuracin e
integracin continua. Prcticas comunes en casi todas las metodologas giles, te dejo un
post sobre la integracin continua y el smoke test.

https://www.agilebusiness.org/content/roles-and-responsibilities
https://es.slideshare.net/PacoGarat/crystal-clear-11805930

https://es.scribd.com/doc/211905120/Metodologias-Crystal

https://es.scribd.com/doc/84488342/Practica-3-Otras-metodologias-Agiles

https://en.wikipedia.org/wiki/Dynamic_systems_development_method

http://osl2.uca.es/wikiCE/index.php/Dynamic_Systems_Development

https://es.slideshare.net/MSJara/metodologia-dsdm-74297619

http://www.javiergarzas.com/2012/09/metodologias-crystal.html

https://github.com/mxabierto/hackea-el-sistema/wiki/E2E-Testing-con-Protractor

FDD

Es una metodologa gil diseada para el desarrollo de software, basada en la calidad y el

monitoreo constante del proyecto. Fue desarrollada por Jeff De Luca y Peter Coad a
mediados de los aos 90. Esta metodologa se enfoca en iteraciones cortas, que permiten
entregas tangibles del producto en un periodo corto de tiempo, de como mximo dos
semanas.

FDD, es un mtodo gil, iterativo y adaptativo. A diferencia de otros ms, no cubre todo el
ciclo de vida sino solo las fases de diseo y construccin y se considera adecuado para
proyectos mayores y de misin crtica.

Principios de FDD

1.- Se requiere un sistema para construir sistemas si se pretende escalar a proyectos

grandes.
2.- Un proceso simple y bien definido trabaja mejor.
3.- Los pasos de un proceso deben ser lgicos y su mrito inmediatamente obvio para cada
miembro del equipo.
4.- Vanagloriarse del proceso puede impedir el trabajo real.
5.- Los buenos procesos van hasta el fondo del asunto, de modo que los miembros del
equipo se puedan concentrar en los resultados.
6.- Los ciclos cortos, iterativos, orientados por funciones son mejores.

Roles de FDD
Roles Claves: El equipo de trabajo est estructurado en jerarquas, siempre debe haber
un jefe de proyecto y aunque es un proceso considerado ligero tambin incluye
documentacin (la mnima necesaria para que algn nuevo integrante pueda entender el
desarrollo de inmediato).
Gerente del Proyecto: Es el lder de, proyecto. Se encarga de la administracin, direccin
y financiamiento del proyecto.
Arquitecto Jefe: Realiza el diseo global del sistema. Ejecucin 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, disea el proyecto, selecciona las
funcionalidades a desarrollar.
Propietario de Clases: Responsable del Desarrollo de las clases que se le asignaron como
propias.
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 los
desarrolladores para que se asegure la entrega de un sistema completo.

Roles de Soporte:

Administrador de Entrega: Controla el avance del proyecto. Reporta resultados al gerente

de proyecto y al cliente donde se aprecia el porcentaje de avance de cada funcionalidad.

Abogado Gur de Lenguaje: Experto especialista en un tipo de lenguaje de programacin

o tecnologa

Ingeniero de Construccin: que se encarga del control de versiones de los builds y publica
la documentacin.
Herramientista (toolsmith): Es el encargado de administrar y mantener los servidores,
conexiones, comunicaciones, etc

Administrador del Sistema: que controla el ambiente de trabajo o productiza el sistema

cuando se lo entrega.

Roles adicionales

Tester: Es el encargado de ir probando las funcionalidades del sistema y verificar que estas
cumplan con los requerimientos del cliente.

Tcnico de documentacin: Son los responsables de elaborar documentacin para los

usuarios finales del sistema.

Fases de FDD

Un proyecto que aplica FDD se basa en las siguientes 5 fases:

a) Desarrollo de un modelo general

b) Construccin de la lista de funcionalidades
c) Planeacin por funcionalidad
d) Diseo por funcionalidad
e) Construccin por funcionalidad

Caractersticas

No hace nfasis en la obtencin de los requerimientos sino en cmo se realizan las fases
de diseo y construccin.

Se preocupa por la calidad, por lo que incluye un monitoreo constante del proyecto.

Ayuda a contrarrestar situaciones como el exceso en el presupuesto, fallas en el programa

o el hecho de entregar menos de lo deseado.

Propone tener etapas de cierre cada dos semanas.

Se obtienen resultados peridicos y tangibles.

Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional
que el cliente y la direccin de la empresa pueden ver y monitoriar.

Define claramente entregas tangibles y formas de evaluacin del progreso del proyecto.
https://prezi.com/j3qymffr2zvu/metodologia-fdd/

https://es.scribd.com/document/227319136/metodologia-FDD

https://www.ecured.cu/Metodolog%C3%ADa_FDD

https://prezi.com/1k5pu8arfhnu/metodologia-fdd-feature-driven-development-desarrollo-
bas/

https://sites.google.com/site/ingsoportelogico/home/feature-driven-development-fdd

TDD

Desarrollo guiado por pruebas de software, o Test-driven development (TDD) es una

prctica de ingeniera de software que involucra otras dos prcticas: Escribir las pruebas
primero (Test First Development) y Refactorizacin (Refactoring). Para escribir las pruebas
generalmente se utilizan las pruebas unitarias (unit test en ingls). En primer lugar, se
escribe una prueba y se verifica que las pruebas fallan. A continuacin, se implementa el
cdigo que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el
cdigo escrito. El propsito del desarrollo guiado por pruebas es lograr un cdigo limpio que
funcione. La idea es que los requisitos sean traducidos a pruebas, de este modo, cuando
las pruebas pasen se garantizar que el software cumple con los requisitos que se han
establecido.

Requisitos
Para que funcione el desarrollo guiado por pruebas, el sistema que se programa tiene que
ser lo suficientemente flexible como para permitir que sea probado automticamente. Cada
prueba ser suficientemente pequea como para que permita determinar unvocamente si
el cdigo probado pasa o no la verificacin que sta le impone. El diseo se ve favorecido
ya que se evita el indeseado "sobre diseo" de las aplicaciones y se logran interfaces ms
claras y un cdigo ms cohesivo. Frameworks como JUnit proveen de un mecanismo para
manejar y ejecutar conjuntos de pruebas automatizadas.

Ciclo de desarrollo conducido por pruebas

En primer lugar se debe definir una lista de requisitos y despus se ejecuta el siguiente
ciclo:

1.- Elegir un requisito: Se elige de una lista el requisito que se cree que nos dar mayor
conocimiento del problema y que a la vez sea fcilmente implementable.

2.- Escribir una prueba: Se comienza escribiendo una prueba para el requisito. Para ello
el programador debe entender claramente las especificaciones y los requisitos de la
funcionalidad que est por implementar. Este paso fuerza al programador a tomar la
perspectiva de un cliente considerando el cdigo a travs de sus interfaces.

3.- Verificar que la prueba falla: Si la prueba no falla es porque el requisito ya estaba
implementado o porque la prueba es errnea.

4.- Escribir la implementacin: Escribir el cdigo ms sencillo que haga que la prueba
funcione. Se usa la expresin "Djelo simple" ("Keep It Simple, Stupid!"), conocida como
principio_KISS.

5.- Ejecutar las pruebas automatizadas: Verificar si todo el conjunto de pruebas funciona
correctamente.

6.- Eliminacin de duplicacin: El paso final es la refactorizacin, que se utilizar

principalmente para eliminar cdigo duplicado. Se hace un pequeo cambio cada vez y
luego se corren las pruebas hasta que funcionen.
7.- Actualizacin de la lista de requisitos: Se actualiza la lista de requisitos tachando el
requisito implementado. Asimismo se agregan requisitos que se hayan visto como
necesarios durante este ciclo y se agregan requisitos de diseo (P. ej que una funcionalidad
est desacoplada de otra).

Tener un nico repositorio universal de pruebas facilita complementar TDD con otra prctica
recomendada por los procesos giles de desarrollo, la "Integracin Continua". Integrar
continuamente nuestro trabajo con el del resto del equipo de desarrollo permite ejecutar
toda batera de pruebas y as descubrir si nuestra ltima versin es compatible con el resto
del sistema. Es recomendable y menos costoso corregir pequeos problemas cada pocas
horas que enfrentarse a problemas enormes cerca de la fecha de entrega fijada.

Caractersticas
Una caracterstica de esta forma de programacin es el evitar escribir cdigo innecesario
("You Ain't Gonna Need It" (YAGNI)). Se intenta escribir el mnimo cdigo posible, y si el
cdigo pasa una prueba aunque sepamos que es incorrecto nos da una idea de que
tenemos que modificar nuestra lista de requisitos agregando uno nuevo.

La generacin de pruebas para cada funcionalidad hace que el programador confe en el

cdigo escrito. Esto permite hacer modificaciones profundas del cdigo (posiblemente en
una etapa de mantenimiento del programa) pues sabemos que si luego logramos hacer
pasar todas las pruebas tendremos un cdigo que funcione correctamente.

Otra caracterstica del Test Driven Development es que requiere que el programador
primero haga fallar los casos de prueba. La idea es asegurarse de que los casos de prueba
realmente funcionen y puedan recoger un error.

Ventajas

Los programadores que utilizan el desarrollo guiado por pruebas en un proyecto virgen
encuentran que en raras ocasiones tienen la necesidad de utilizar el depurador o debugger.

A pesar de los elevados requisitos iniciales de aplicar esta metodologa, el desarrollo guiado
por pruebas (TDD) puede proporcionar un gran valor aadido en la creacin de software,
produciendo aplicaciones de ms calidad y en menos tiempo. Ofrece ms que una simple
validacin del cumplimiento de los requisitos, tambin puede guiar el diseo de un
programa. Centrndose en primer lugar en los casos de prueba uno debe imaginarse cmo
los clientes utilizarn la funcionalidad (en este caso, los casos de prueba). Por lo tanto, al
programador solo le importa la interfaz y no la implementacin. Esta ventaja es similar al
diseo por convenio pero se parece a l por los casos de prueba ms que por las aserciones
matemticas.

El poder del TDD radica en la capacidad de avanzar en pequeos pasos cuando se

necesita. Permite que un programador se centre en la tarea actual y la primera meta es, a
menudo, hacer que la prueba pase. Inicialmente no se consideran los casos excepcionales
y el manejo de errores. Estos, se implementan despus de que se haya alcanzado la
funcionalidad principal. Otra ventaja es que, cuando es utilizada correctamente, se asegura
de que todo el cdigo escrito est cubierto por una prueba. Esto puede dar al programador
un mayor nivel de confianza en el cdigo.

Limitaciones

El desarrollo guiado por pruebas requiere que las pruebas puedan automatizarse. Esto
resulta complejo en los siguientes dominios:

Interfaces Grfica de usuario (GUIs), aunque hay soluciones parciales propuestas.

Objetos distribuidos, aunque los objetos simulados (MockObjects) pueden ayudar.

Bases de datos. Hacer pruebas de cdigo que trabaja con base de datos es complejo
porque requiere poner en la base de datos unos datos conocidos antes de hacer las pruebas
y verificar que el contenido de la base de datos es el esperado despus de la prueba. Todo
esto hace que la prueba sea costosa de codificar, aparte de tener disponible una base de
datos que se pueda modificar libremente.
PROGRAMACION EXTREMA (XP)

Es una metodologa ligera de bajo riesgo, flexible y previsible para el desarrollo de software,
hace uso de lanzamientos frecuentes en ciclos de desarrollo corto para mejorar la
productividad y proporciona puntos de control para la comunicacin de resultados y
cambios.

XP propone que los costes de los cambios no tienen por qu aumentar con el tiempo.

Sabemos que la versin de software es el elemento ms importante de cualquier proyecto.

Qu sucede despus de una iteracin? a menudo despus de una iteracin el cliente tiene
varias opciones con respecto al producto, se puede poner el software en produccin
inmediatamente especialmente cuando el software se conecta a un sitio web, el cliente
tambin puede optar por esperar a implementar caractersticas hasta que un mdulo se
complete o hasta que todo el proyecto est terminado Esta es tambin una oportunidad
para aprender de una iteracin actual y aplicar conocimientos a la siguiente. Tenga en
cuenta que de versiones de software sirven como un enlace de retroalimentacin entre la
solicitud y la entrega.

Regla 80-20: originalmente llamada principio de Pareto esta norma establece que para
dichos eventos aproximadamente el 80% de los efectos resultantes de 20% causas. Regla
de negocio que los estados que el 80% de las ventas de una empresa da como resultado
la actividad del 20% de su base total de clientes. La mayora de los programas de software
y los programadores son conscientes de esta regla, el 80% de los resultados vienen de
20% de los que han realizado. Segn XP poner la ms esencial y valiosa 20% funcionalidad
en produccin

VALORES

XP tiene un conjunto de 4 valores principales: comunicacin, sencillez, retroalimentacin y

coraje.

Comunicacin: Es fundamental para el xito de cualquier proyecto, es necesaria para

crear un buen producto, los desarrolladores deben saber lo que se debe hacer y los clientes
deben saber cundo se deben llevar a cabo, a pesar de que ambos grupos son una parte
de un mismo equipo, XP requiere que cada grupo asuma responsabilidad de sus propias
decisiones.

Retroalimentacin:
Sencillez: Este valor hace hincapi en mantener todo simple, sencillez y comunicacin no
son mutuamente excluyentes ms comunicacin, ms clara la comprensin, simplicidad
significa construir nicamente lo esencial hoy en da y no predecir las necesidades del
maana, esto maximiza el valor de la inversin. Simplicidad significa tomar pasos pequeos
y sencillos para alcanzar la meta y mitigar los daos que puedan ocurrir.

Coraje: Es una virtud difcil de aplicar. Esto significa tomar decisiones difciles cuando sea
necesario, valenta fomenta confianza y la confianza promueve comunicacin eficaz. Si hay
algo que no funciona, entonces puede dar por hecho que es necesario corregir. Si no hay
retrasos, a continuacin, comunicarlas al cliente. La nica forma de recuperarse de los
errores es el de admitir y a continuacin llevar a cabo acciones correctivas esto requiere
coraje.

PRACTICAS

1. El juego de la planificacin
2. Pequeas entregas
3. Metfora
4. Diseo Simple
5. Pruebas
6. Refactorizacin
7. Programacin por parejas
8. Propiedad Colectiva
9. Integracin contina
10. 40 horas semanales
11. Cliente en casa
12. Estndares de codificacin

ROLES

Cliente:

Escribe historias de usuario y especfica pruebas funcionales

Establece prioridades, explica las historias

Puede ser o no un usuario final

Tiene autoridad para decidir cuestiones relativas a las historias.

Programador:
Hace estimaciones sobre las Historias.

Define tareas a partir de las historias y hace estimaciones

Implementa las historias y las pruebas unitarias

Tutor:

Observa todo, identifica seales de peligro, se asegura que el proyecto se mantenga en

curso.

Perseguidor (Calidad)

Monitoriza el progreso de los programadores, toma accin si las cosas tienden a salirse de
su senda. Las acciones incluyen reuniones con el cliente

Verificador: Implementa y corre las pruebas funcionales (no pruebas unitarias)

Agorero: se asegura que todos conocen el riesgo que existen

Gestor: Planifica las reuniones se asegura que el proceso de reuniones se sigue anota el
resultados de la reunin para futuros informes y los pasa al perseguidor. Posiblemente
responsable ante el Propietario de Oro.

Propietario de Oro: Persona que paga el proyecto que puede ser o no la misma del cliente.

ARTEFACTOS
Historias de Usuario
Tareas de Ingeniera
Pruebas de aceptacin
Pruebas Unitarias y de Integracin
Plan de Entrega
Cdigo

FASES

Planificacin

Diseo

Codificacin

Prueba
EVENTOS

METODOLOGIA KANBAN (XP)

En kanban todo el equipo es responsable de la mejora de los sistemas y procesos en curso.

Lean Kanban es un conjunto de valores y principios que resumen la manera de tener xito
en el desarrollo de productos.

Limite Work in Progress (WIP): Mapa de flujo de valor

VALORES

Kaisen: Mejora continua, kai= idea de cambio o una accin para rectificar algo, zen=
significa simplemente bueno, el concepto de kaizen se basa en la filosofa japonesa de los
negocios que hace hincapi en la mejora continua. Kaizen cree que toda persona
involucrada en un negocio es una valiosa contribucin a la organizacin. Kaizen es una
estructura de adaptacin de los valores humanos que mantiene a los empleados motivados
para lograr cero defectos en su trabajo. El mtodo kaizen cree que cada persona
involucrada en un negocio es una valiosa contribucin a la organizacin, kaiken promueve
un ambiente de reconocimiento y respeto, lo cual es importante para la comunicacin clara.

Ciclo de Kaizen: Ciclo de kaizen tiene 4 segmentos:

Planificar
Ejecucin
Observacin
Evaluar

PRACTICAS

1.- Optimizar el conjunto: Optimizacin de una parte del sistema, optimizar el conjunto del
sistema

2.- Eliminar los residuos: Se describe como muda en sistema de produccin Toyota
(TPS), los sistemas es algo en el sistema que no agrega valor al cliente, los residuos en el
desarrollo de software se clasifican en tres grandes categoras: Los residuos de
construccin: los residuos de incapacidad para aprender; Los residuos de basura: es decir
las prcticas que impiden el proceso.
3.- Construir en calidad: Encontrar demasiados defectos en el sistema con regularidad
significa que hay defectos en el proceso en su conjunto.

4.- Aprender constantemente: Mejora continua, se dice que nada es perfecto y siempre
hay espacio para mejorar

5.- Involucrar a todos: Las organizaciones obtienen su ventaja competitiva a travs de los
recursos humanos a su disposicin

COMPARACION DE METODOLOGIAS AGILES

Principio: La ms alta prioridad es satisfacer a los clientes a travs de la entrega temprana

y continua de software valioso

En Kanban o el mtodo lean la visualizacin de los principales temas prioritarios se utiliza

un sistema de asignacin de trabajo.

En Scrum hay una priorizacin basada en el valor de la produccin de software entregable

con cada sprint, las reuniones de revisin se llevan a cabo para mostrar las caractersticas
a los clientes.

En XP los clientes y desarrolladores trabajan juntos para planificar lanzamientos.

DSDM se basa en comentarios de los clientes para cada iteracin para converger en una
solucin de negocio eficaz.

Crystal emplea victoria temprana, esqueleto caminando y comentarios de los clientes

frecuentes para ofrecer software de gran utilidad

FDD Desarrolla caractersticas de valor basadas en el cliente y utiliza una aceleracin corta
para el modelado.

Principio: Principal medida de progreso

En Kanban el trabajo se limita a ello (LIMIT WIP)

En Scrum el software de trabajo se produce al final de cada sprint.

XP utiliza las ideas de ninguna deuda tcnica

TDD software sin ego

DSDM cree en la entrega de lo suficientemente bueno temprano en lugar de perfecto

demasiado tarde
Esqueleto caminando, pruebas automatizadas, la integracin frecuente de todas las
herramientas utilizadas en cristal.

FDD utiliza inspecciones y pruebas unitarias