UNIVERSIDAD DE PANAM

CENTRO REGIONAL UNIVERSITARIO DE VERAGUAS

FACULTAD DE INFORMTICA, ELECTRNICA Y
COMUNICACIN

METODOLOGAS GILES PARA EL DESARROLLO DE

SOFTWARE

PRESENTA:
A. LEONARDO ZAMBRANO

SEPTIEMBRE 2014
 TABLA DE CONTENIDOS
1. INTRODUCCIN ......................................................................................... 4

2. METODOLOGAS GILES........................................................................... 4

2.1 DEFINICIN ............................................................................................. 4

2.2 MANIFIESTO GIL ................................................................................... 5

2.3 COMPARACIN DE LOS MTODOS TRADICIONALES DE LOS

MTODOS GILES ............................................................................................ 6

2.4 VENTAJAS ............................................................................................... 7

2.5 DESVENTAJAS ........................................................................................ 8

3. METODOLOGAS GILES........................................................................... 9

3.1 XTREME PROGRAMING/PROGRAMACIN EXTREMA (XP) ................. 9

3.1.1 ANTECEDENTES Y CONCEPTOS GENERALES ................................ 9

3.1.2 CARACTERSTICAS ........................................................................... 10

3.1.3 DIAGRAMA DE FASES DE DESARROLLO........................................ 10

3.1.4 FASES DEL CICLO DE VIDA.............................................................. 11

3.1.5 ROLES ................................................................................................ 11

3.1.6 VENTAJAS Y DESVENTAJAS ............................................................ 12

3.2 SCRUM .................................................................................................. 13

3.2.1 CONCEPTOS GENERALES ............................................................... 13

3.2.2 CARACTERSTICAS ........................................................................... 14

3.2.3 ESQUEMA SCRUM ............................................................................ 15

3.2.4 PATRONES DE DESARROLLO ......................................................... 15

3.2.5 VENTAJAS Y DESVENTAJAS ............................................................ 16

3.3 CRYSTAL METHODOLOGYES.............................................................. 16

3.3.1 GENERALIDADES .............................................................................. 16

3.3.2 CARACTERSTICAS ........................................................................... 17

3.3.3 FASES O ETAPAS DE DESARROLLO ............................................... 17

3.3.4 ROLES ................................................................................................ 18

3.3.5 VENTAJAS Y DESVENTAJAS ............................................................ 19

3.4 DYMANIC SYSTEMS DEVELOPMENT METHOD (DSDM) .................... 20

3.4.1 CONCEPTOS GENERALES ............................................................... 20

3.4.2 CARACTERSTICAS ........................................................................... 21

3.4.3 FASES DEL CICLO DE VIDA.............................................................. 21

3.4.4 ROLES ................................................................................................ 22

3.4.5 VENTAJAS Y DESVENTAJAS ............................................................ 23

3.5 ADAPTIVE SOFTWARE DEVELOPMENT (ASD) ................................... 24

3.5.1 ANTECEDENTES ............................................................................... 24

3.5.2 CARACTERSTICAS ........................................................................... 24

3.5.3 DIAGRAMA DE ETAPAS .................................................................... 25

3.5.4 ETAPAS DE DESARROLLO ............................................................... 25

3.5.5 VENTAJAS Y DESVENTAJAS ............................................................ 26

3.6 FEATURE DRIVEN DEVELOPMENT ..................................................... 27

3.6.1 GENERALIDADES .............................................................................. 27

3.6.2 CARACTERSTICAS PRINCIPALES .................................................. 27

3.6.3 FASES DE DESARROLLO ................................................................. 28

3.6.4 ROLES ................................................................................................ 29

3.6.5 VENTAJAS Y DESVENTAJAS ............................................................ 30

4. CONCLUSIONES ....................................................................................... 31

5. BIBLIOGRAFA .......................................................................................... 31
 1. INTRODUCCIN

La falta de directivas en el desarrollo de software, as como sus metodologas de

desarrollo tradicionales, donde han resultado ser efectivas en proyectos de gran
tamao, pero sin embargo este enfoque no resulta ser el ms adecuado para
muchos de los proyectos actuales donde el entorno del sistema es muy
cambiante, y en donde se exige reducir drsticamente los tiempos de desarrollo
pero manteniendo una alta calidad. Ante las dificultades para utilizar metodologas
tradicionales con estas restricciones de tiempo y flexibilidad, muchos equipos de
desarrollo se resignan a prescindir del buen hacer de la ingeniera del software,
asumiendo el riesgo que ello conlleva.

En este escenario, las metodologas giles emergen como una posible respuesta
para llenar ese vaco metodolgico. Por estar especialmente orientadas para
proyectos pequeos, las metodologas giles constituyen una solucin a medida
para ese entorno, aportando una elevada simplificacin que a pesar de ello no
renuncia a las prcticas esenciales para asegurar la calidad del producto.

2. METODOLOGAS GILES

2.1 DEFINICIN

El trmino gil en referencia a los mtodos de desarrollo de software nace en

febrero de 2001, donde participaron alrededor de 17 expertos de la industria del
software, con el objetivo era de describir valores y principios que permitieran
desarrollar software rpidamente que respondan a los cambios que surgen a lo
largo del proyecto, como alternativa de los modelos tradicionales.

Como resultado de esta reunin se crea la The Agile Alliance, organizacin

dedicada a promover los conceptos relacionados con el desarrollo gil de
software, hay que resaltar que estas metodologas son relativamente nuevas.

La metodologa gil se basa en la filosofa de satisfacer el cliente y en la entrega

rpida de software incremental y los equipos pequeos de desarrollo, adems
debemos saber el concepto de agilidad, Ivar Jacobson hace un anlisis: La
agilidad se ha convertido en la palabra mgica de hoy para describir un proceso
del software moderno. Un equipo gil es diestro y capaz de responder de manera
apropiada a los cambios. El cambio es de lo que trata el software en gran medida.
Hay cambios en el software que se construye, en los miembros del equipo,
debidos a las nuevas tecnologas, de todas clases y que tienen un efecto en el
producto que se elabora o en el proyecto que lo crea. Deben introducirse apoyos
para el cambio en todo lo que se haga en el software; en ocasiones se hace
porque es el alma y corazn de ste. Un equipo gil reconoce que el software es
desarrollado por individuos que trabajan en equipo, y que su capacidad, su
habilidad para colaborar, es el fundamento para el xito del proyecto.

2.2 MANIFIESTO GIL

El manifiesto gil se refiere a la filosofa o la definicin cannica del desarrollo gil,

donde se valora, segn (Cans, Letelier, & Penads) a:

Al individuo y las interacciones del equipo de desarrollo sobre el

proceso y las herramientas: considera al personal como principal factor
de xito de un proyecto de software, y que se considera como ms
importante antes del entorno de desarrollo.
Desarrollar software que funciona ms que una buena
documentacin: se sigue la regla de no producir documentos a menos
que sea necesaria para tomar decisin, y deben se cortos y
fundamentales.
La colaboracin con el cliente ms que la negociacin de un contrato:
se propone na interaccin directa con el cliente que marca el xito del
proyecto.
Responder a los cambios ms que seguir un plan: exige la habilidad
de responder a los cambios que puedan surgir a lo largo del proyecto.

Esto conlleva a presentar los principios del manifiesto:

La prioridad es satisfacer al cliente mediante tempranas y continuas

entregas de software que le aporte un valor.
 Dar la bienvenida a los cambios. Se capturan los cambios para que el
cliente tenga una ventaja competitiva.
Entregar frecuentemente software que funcione desde un par de semanas
a un par de meses, con el menor intervalo de tiempo posible entre
entregas.
La gente del negocio y los desarrolladores deben trabajar juntos a lo largo
del proyecto.
Construir el proyecto en torno a individuos motivados. Darles el entorno y
el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.
El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar
informacin dentro de un equipo de desarrollo.
El software que funciona es la medida principal de progreso.
Los procesos giles promueven un desarrollo sostenible. Los promotores,
desarrolladores y usuarios deberan ser capaces de mantener una paz
constante.
La atencin continua a la calidad tcnica y al buen diseo mejora la
agilidad.
La simplicidad es esencial.
Las mejores arquitecturas, requisitos y diseos surgen de los equipos
organizados por s mismos.
En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser
ms efectivo, y segn esto ajusta su comportamiento.

Detrs del manifiesto gil se podra considerar: entrega temprana de un

software de valor, cambios bien recibidos, trabajo continuo y conjunto.

2.3 COMPARACIN DE LOS MTODOS

TRADICIONALES DE LOS MTODOS GILES

De (Cans, Letelier, & Penads) mostramos las diferencias entre las metodologas
giles y las tradicionales:
 Aspecto Metodologas giles Metodologas tradicionales

Fundamentos Se basa en la heurstica de Se basa en normas provenientes de

prcticas de produccin de estndares seguidos por el entorno
cdigo. de desarrollo.

Cambios Estn preparados Puede presentar resistencia a estos

Uso Son aplicadas Imposicin externamente

internamente por el equipo

Controles Menos control y pocos Es ms controlado con numerosas

principios polticas y normas

Flexibilidad Existencia casi nula de Se establece un contrato prefijado

contrato tradicional

Cliente Forma parte del equipo de Solo interacta con el equipo de

desarrollo desarrollo en reuniones

Grupo de Son pequeos y en un Grupos grandes y hasta distribuidos

trabajo mismo sitio

Equipos fsicos Pocos Muchos

Roles Pocos Muchos ms

Arquitectura de Hace menos nfasis Es esencial y se expresa mediante

software modelos

2.4 VENTAJAS

Como ventajas de los mtodos giles de desarrollo de software podemos

mencionar:
 Permite la interaccin directa y continua con el cliente de manera que no
haya disconformidades y malentendidos.
Las respuestas a los cambios de requisitos a lo largo del desarrollo se dan
de manera rpida, minimizando los costos.
Las entregas son continuas y en plazos cortos, manteniendo el software
funcional.
Importancia de la simplicidad, al eliminar el trabajo innecesario.
Se le presta continua atencin al uso de las tcnicas y la invencin del
diseo.
El equipo de desarrollo no malgasta el tiempo y dinero del cliente
desarrollando soluciones innecesariamente generales y complejas que en
realidad no son un requisito del cliente.
Cada componente del producto final ha sido probado y satisface los
requerimientos.

2.5 DESVENTAJAS

Como desventajas podemos mencionar:

Falta de documentacin del diseo. El cdigo no puede tomarse como una

documentacin. En sistemas de tamao grande se necesitar leer los
cientos o miles de pginas del listado de cdigo fuente.
Problemas derivados de la comunicacin oral. Este tipo de comunicacin
resulta difcil de preservar cuando pasa el tiempo y est sujeta a muchas
ambigedades.
Si probamos constantemente el cdigo da indicios de falta de anlisis y
diseo.
El desarrollo depende bsicamente de las personas, porque se evita la
documentacin y los diseos convencionales.
Falta de reusabilidad. La falta de documentacin hacen difcil que pueda
reutilizarse el cdigo gil.
La refactorizacin puede traducirse en altos costos y retrasos en el
desarrollo del software.
 Rigidez. Algunos mtodos giles son muy rgidos: deben cumplirse
muchas reglas de una forma estricta para garantizar el xito del proyecto,
como el caso de Xtreme Programming (XP).
Los cambios en el modelo de datos se torna muy pesado.
El fracaso se podra tornar devastador por falta de documentacin, porque
solo podra estar en manos de los desarrolladores.

3. METODOLOGAS GILES

3.1 XTREME PROGRAMING/PROGRAMACIN

EXTREMA (XP)

3.1.1 ANTECEDENTES Y CONCEPTOS

GENERALES

Programacin extrema su equivalente traducido en espaol, un enfoque muy

utilizado en el desarrollo de software gil, las primeras ideas y mtodos asociados
al mtodo de la programacin extrema se da a finales de los 80 relacionada con
el lenguaje Smalltalk, anteriormente ya se haba escrito algo relacionado por Kent
Beck, aunque tambin hubieron variaciones como la XP industrial.

El paso hacia concebirla como una metodologa se da en 1966, y pone ms

nfasis en la adaptabilidad que en la previsibilidad. Esta metodologa de
desarrollo se orienta donde se piensa en potenciar las relaciones interpersonales
como la clave del xito para el desarrollo del software, con adecuaciones para
proyectos con requisitos imprecisos y muy cambiantes y donde existe un alto
riesgo tcnico.

Todo se lleva al extremo de ah su nombre, este mtodo adopta las mejores

metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo en el
proyecto y aplicarlo dinmicamente en el proyecto.
 3.1.2 CARACTERSTICAS

Las caractersticas fundamentales de la metodologa XP se pueden mencionar:

Desarrollo incremental e iterativo, con pequeas mejoras en cada una

de las iteraciones.
Pruebas unitarias continuas: de forma repetida y automatizada con
pruebas antes de la codificacin.
Programacin por parejas: las tareas de desarrollo pueden ser llevadas
a cabo por dos personas en un mismo puesto, permiten revisar y corregir
cdigos.
Frecuente iteracin: que relaciona al equipo con el cliente donde este
ltimo destine un representante que trabaje junto al equipo.
Correccin: de los errores antes de aadir una nueva funcionalidad.
Refactorizacin: (mencionada atrs) es rescribir ciertas partes del cdigo
para aumentar su legibilidad y mantenimiento sin modificar
comportamientos.
Propiedad del cdigo compartida: en vez de dividir la responsabilidad
en el desarrollo de cada mdulo en grupos de trabajo distintos, este
mtodo promueve el que todo el personal pueda corregir y extender
cualquier parte del proyecto.
Simplicidad en el cdigo: hacerlo sencillo de modo que funcione y se
pueda aadir funcionalidades.

3.1.3 DIAGRAMA DE FASES DE DESARROLLO

De (Pressman, 2010):
 3.1.4 FASES DEL CICLO DE VIDA

La planeacin: el juego de la planeacin comienza con recabar

requerimientos (con solo escuchar) que permiten al equipo conocer las
sensibilidades, funcionalidades, caractersticas y contextos.
Diseo: sigue el principio de mantenerlo sencillo, este diseo sencillo se
refiere sobre una representacin ms compleja, guiando lo planteado en
la planeacin. Como este modelo se orienta a objetos podemos usar
tarjetas RC.
Codificacin: despus de las actividades de planeacin y se haya el
diseo preliminar, se desarrollan pruebas unitarias de las entregas del
curso. Se debe tomar en cuenta la programacin por parejas.
Pruebas: las pruebas unitarias se desarrollan antes de la codificacin,
estas deben implementarse con estructuras que permitan automatizarlas.

3.1.5 ROLES

De acuerdo al modelo propuesto por Beck, los roles de esta metodologa son:

Programador: escribe pruebas unitarias y produce condigo de sistema.

 Cliente: se destacan en la primera fase de desarrollo de esta metodologa,
con sus historias y pruebas funcionales, e implementaciones con prioridad.
Encargado de pruebas: ayuda al cliente a describir las pruebas
funcionales, difunde resultados, etc.
Encargado de seguimiento (Tracker): Proporciona realimentacin al
equipo. Verifica el grado de acierto entre las estimaciones realizadas y el
tiempo real dedicado, para mejorar futuras estimaciones. Realiza el
seguimiento del progreso de cada iteracin.
Entrenador (Coach): Es responsable del proceso global. Debe proveer
guas al equipo de forma que se apliquen las prcticas XP y se siga el
proceso correctamente.
Consultor: Es un miembro externo del equipo con un conocimiento
especfico en algn tema necesario para el proyecto, en el que puedan
surgir problemas.
Gestor (Big boss): Es el vnculo entre clientes y programadores.

3.1.6 VENTAJAS Y DESVENTAJAS

Este modelo ofrece ciertas ventajas:

Es apropiado para los entornos voltiles.

Si se dan cambios se puede reducir los costos.
Planificacin ms transparente para los clientes, con fechas de entrega.
En cada iteracin se pueden definir los objetivos de la siguiente.
Permite la realimentacin entre los usuarios.
La presin se mantiene a lo largo del proyecto.

Y dentro de las desventajas:

Delimitar el alcance del proyecto con el cliente.

Es recomendable emplearla solo en proyectos a corto plazo.
Los fallos representan comisiones muy altas.
Requiere de un rgido ajuste a los principios de XP.
Puede no siempre ser ms fcil que el desarrollo tradicional.
 3.2 SCRUM

3.2.1 CONCEPTOS GENERALES

Este es un modelo incremental iterativo para desarrollar cualquier producto o

gestionar cualquier trabajo, donde no solo se puede aplicar al desarrollo de
software sino tambin al mantenimiento de software con enfoque a la gestin de
programas.

En 1986, Hirotaka Takeuchi e Ikujiro Nonaka describieron un enfoque integral que

incrementaba la velocidad y flexibilidad del desarrollo de nuevos productos
comerciales. Compararon este nuevo enfoque integral, en el que las fases se
solapan fuertemente y el proceso entero es llevado a cabo por un equipo
multifuncional a travs de las diferentes fases, al rugby, donde todo el equipo trata
de ganar distancia como una unidad y pasando el baln una y otra vez.

En 1991, DeGrace y Stahl hicieron referencia a este enfoque como Scrum, un

trmino de rugby mencionado en el artculo de Takeuchi y Nonaka. A principios
de 1990s, Ken Schwaber us un enfoque que gui a Scrum a su compaa,
Mtodos de Desarrollo Avanzados. Al mismo tiempo, Jeff Sutherland desarroll
un enfoque similar en Easel Corporation y fue la primera vez que se llam Scrum.
En 1995 Sutherland y Schwaber presentaron de forma conjunta un artculo
describiendo Scrum en OOPSLA 95 en Austin, su primera aparicin pblica.
Schwaber y Sutherland colaboraron durante los siguientes aos para unir los
artculos, sus experiencias y las mejores prcticas de la industria en lo que ahora
se conoce como Scrum. En 2001, Schwaber se asoci con Mike Beedle para
poner en limpio el mtodo en el libro Agile Software Devlopment with Scrum.

Este proceso est orientado o se puede usar para para gestionar y controlar
desarrollos complejos de software usando tcnicas iterativas e incrementales,
donde una iteracin es un ciclo corto de construccin repetitivo que termina con
una pieza de software ejecutable con nueva funcionalidad.
 3.2.2 CARACTERSTICAS

Del modelo SCRUM podemos mencionar caractersticas relevantes:

El equipo se focaliza en construir software de calidad.

La gestin de SCRUM se focaliza en definir cules son las caractersticas
que debe tener el producto y la remocin de los obstculos que pudiesen
afectar durante el desarrollo.
Se basa en los principios de inspeccin continua, adaptacin, auto-gestin
e innovacin.
Cada iteracin tpicamente tiene un periodo de 2 a 4 semanas (no fija), las
caractersticas que entran a una iteracin vienen del backlog un conjunto
de requisitos prioritarios de alto nivel.
Durante la iteracin los componentes del backlog estn congelados.
Durante un proyecto los clientes pueden cambiar sus pensamientos sobre
lo que quieren y necesitan, por lo que SCRUM opta por un enfoque
emprico aceptando no entender o poder definir completamente el
problema, pero centrndose en maximizar habilidades para entregar y
responder rpidamente con los requisitos.
Se realizan reuniones diarias, de iteracin (sprint), de revisin de iteracin
y de iteracin retrospectiva.

El sprint puede tener duraciones de 30 das con un resultado de un incremento

ejecutable mostrado al cliente.
 3.2.3 ESQUEMA SCRUM

3.2.4 PATRONES DE DESARROLLO

Este modelo posee las siguientes actividades estructurales como los

requerimientos, anlisis, diseo, evolucin y entrega. Los patrones que sigue este
proceso:

Retraso: lista de prioridades de los requerimientos o caractersticas del

proyecto, donde se evalan las prioridades.
Sprints: unidades necesarias para alcanzar un requerimiento del retraso,
no se introducen cambios.
Reuniones SCRUM: son breves de 15 minutos, donde se responde Qu
se hizo desde la ltima reunin?, Obstculos encontrados?,
planeaciones hasta la prxima reunin?
Demostraciones preliminares: entregar el incremento del software de
modo que la funcionalidad que se haya implementado puede demostrarse
al cliente y pueda ser evaluada.

Las demostraciones preliminares se deben entregar dentro de sus respectivas

cajas de tiempo (tiempo para cumplir con la entrega).
 3.2.5 VENTAJAS Y DESVENTAJAS

Como ventaja:

Entrega de un producto funcional al finalizar cada Sprint.

Posibilidad de ajustar la funcionalidad en base a la necesidad de negocio
del cliente.
Visualizacin del proyecto da a da
Alcance acotado y viable.
Equipos integrados y comprometidos con el proyecto, toda vez que ellos
definieron el alcance y se auto-administran.

Y como limitaciones:

No genera toda la evidencia o documentacin de otras metodologas

No es apto para todos los proyectos.
Tal vez sea necesario complementarlo con otros procesos (XP).
El equipo puede estar tentado de tomar el camino ms corto para sumar
los puntos del sprint.
El equipo de trabajo siempre estar esprintando (Mucho tiempo sin
cambios).

3.3 CRYSTAL METHODOLOGYES

3.3.1 GENERALIDADES

La familia de metodologas Crystal es un conjunto de diferentes metodologas que

podemos seleccionar en funcin de la adecuacin al proyecto en el que nos
encontremos. Tambin incluye un conjunto de principios para adaptar las
diferentes metodologas segn las circunstancias del proyecto, donde cada una
tiene asignado un color, cuanto ms oscura sea su tonalidad, ms compleja es la
metodologa.
Estas metodologas fueron creadas por Alistair Cockburn alrededor de 1990 en un
estudio realizado en la IBM, esta familia de metodologas sigue un cdigo
gentico comn, y va dirigido a proyectos pequeos. Donde los proyectos ms
grandes necesitan ms coordinacin y metodologa ms complejas.

3.3.2 CARACTERSTICAS

Las metodologas Crystal poseen caractersticas comunes:

Los proyectos siempre usan ciclos de desarrollo incrementales, de una

longitud mxima de 4 meses preferibles de 1 a 3 meses.
Se enfatiza en la comunicacin y la cooperacin de la gente.
Permiten el uso de prcticas y herramientas de otras metodologas como
XP o SCRUM.
Los mtodos Crystal hacen nfasis en la facetas de una gema, cada faceta
es otra versin del proceso y se sitan en un mismo ncleo.
Existen cuatro variantes Crystal Clear (<8 integrantes), Amarillo (8-20),
Naranja (20-50) y Rojo (50-100).
La ms desarrollada y documentada es la Crystal Clear, y es la
presentada.

3.3.3 FASES O ETAPAS DE DESARROLLO

No requiere de ninguna estrategia o tcnica, pero si sigue ciertos aspectos que

resultan importantes y necesarios tenerlos presentes:

Exploracin de 360. vericar o tomar una muestra del valor de negocios

del proyecto, los requerimientos, el modelo de dominio, la tecnologa, el
plan del proyecto y el proceso.
Victoria temprana. Es mejor buscar pequeos triunfos iniciales que aspirar
a una gran victoria tarda, se trabaja por partes pequeas.
Esqueleto ambulante. Es una transaccin que debe ser simple pero
completa.
 Rearquitectura incremental. Se ha demostrado que no es conveniente
interrumpir el desarrollo para corregir la arquitectura. Ms bien la
arquitectura debe evolucionar en etapas, manteniendo el sistema en
ejecucin mientras ella se modica.
Radiadores de informacin. Es una lmina pegada en algn lugar que el
equipo pueda observar mientras trabaja o camina. Tiene que ser
comprensible para el observador casual, entendida de un vistazo y
renovada peridicamente para que valga la pena visitarla.

Entonces como no especifica ningn ciclo de vida concreto, ni modelos de

procesos, en lugar usa guas de las polticas estndares, asuntos locales y otros,
veamos algunas prcticas comunes de desarrollo en estas metodologas:

Planificacin por etapas: planificacin del siguiente incremento del

sistema. La planificacin debe finalizar con una versin ejecutable cada
tres o cuatro meses como mximo. El equipo selecciona los requisitos que
sern implementados en el incremento y planifican lo que creen que sern
capaces de hacer.
Revisiones y resmenes: cada incremento consta de diferentes
iteraciones y cada iteracin incluye las siguientes actividades:
construccin, demostracin y resumen de los objetivos del incremento.
Monitorizacin: los progresos del proyecto son monitorizados a partir de
las diferentes entregas del equipo durante el proceso de desarrollo.
Paralelismo y flujo: cuando el monitor de estabilidad nos indica un estado
lo suficientemente estable para su revisin, entonces es el momento para
pasar a la siguiente tarea.

3.3.4 ROLES

Hay 8 roles existentes en la metodologa Crystal en especfico la Crystal Clear:

Patrocinador: produce la Declaracin de Misin con Prioridades de

Compromiso (Tradeoff). Consigue los recursos y dene la totalidad del
proyecto.
 Usuario Experto: Junto con el Experto en Negocios produce la Lista de
Actores-Objetivos y el Archivo de Casos de Uso y Requerimientos.
Diseador Principal: Produce la Descripcin Arquitectnica. Se supone
que debe ser al menos un profesional de Nivel 3 ser capaz de manejar
con uidez, mezclar e inventar procedimientos. Tiene roles de coordinador,
arquitecto, mentor y programador ms experto.
Diseador-Programador: produce, junto con el Diseador Principal, los
Borradores de Pantallas, el Modelo Comn de Dominio, las Notas y
Diagramas de Diseo, el Cdigo Fuente, el Cdigo de Migracin, las
Pruebas y el Sistema Empaquetado.
Experto en Negocios: Junto con el Usuario Experto produce la Lista de
Actores-Objetivos y el Archivo de Casos de Uso y Requerimientos. Debe
conocer las reglas y polticas del negocio.
Coordinador: con la ayuda del equipo, produce el Mapa de Proyecto, el
Plan de Entrega, el Estado del Proyecto, la Lista de Riesgos, el Plan y
Estado de Iteracin y la Agenda de Visualizacin.
Verificador: produce el Reporte de Bugs. Puede ser un programador en
tiempo parcial, o un equipo de varias personas.
Escritor: manuales, estructuras.

3.3.5 VENTAJAS Y DESVENTAJAS

Las ventajas que ofrece las metodologas Crystal (Clear):

Son apropiadas para entornos ligeros

Al estar diseada para el cambio experimenta reduccin de costo.
Presenta una planificacin ms transparente para los clientes.
Se definen en cada iteracin cuales son los objetivos de la siguiente.
Permite tener una muy til realimentacin de los usuarios.

Y las desventajas se referencian con:

La delimitacin del alcance del proyecto con el cliente (comunicacin,

requerimientos y malas entregas).
 La existencia de roles especficos limita las labores de los miembros del
equipo, es decir no se aprovecha el mximo de sus conocimientos, (esto
podra verse como un desperdicio de recursos). Adems el hecho de
cumplir una funcin especfica limita su campo de visin acerca del
proyecto.
Y Si el nmero de miembros aumenta se deber escalar en la clasificacin
de colores de Crystal, cada color establece polticas y mtodos nuevos,
por lo tanto si el equipo crece el proceso puede verse afectado por el
cambio de las reglas de juego.

3.4 DYMANIC SYSTEMS DEVELOPMENT METHOD

(DSDM)

3.4.1 CONCEPTOS GENERALES

El Dymanic systems Development Method o mtodo de desarrollo de Sistemas

dinmicos, es un enfoque gil de software que proporciona una estructura para
construir y dar mantenimiento a sistemas que cumplan restricciones apretadas de
tiempo mediante la realizacin de prototipos incrementales en un ambiente
controlado de proyectos.

Este modelo se basa en la filosofa siguiente (versin modificada de Pareto): El

80% de una aplicacin puede entregarse en 20% del tiempo que tomara
entregarla al 100%, este proceso iterativo incluye en cada iteracin la regla del
80% donde solo se hace lo necesario para cada incremento.

Este modelo se basa originalmente en la metodologa RAD, su objetivo es

entregar sistemas software en tiempo y presupuesto ajustndose a los cambios
de requisitos durante el proceso de desarrollo. Este modelo nace en 1994 en Gran
Bretaa como un consorcio de compaas del Reino Unido que queran construir
sobre RAD (Rapid Applications Development) Desarrollo Rpido de Aplicaciones
y desarrollo iterativo.

.
 3.4.2 CARACTERSTICAS

Como principales caractersticas podemos mencionar:

Es un proceso iterativo e incremental.

El equipo de desarrollo y el usuario trabajan juntos.
Son apropiadas para entornos ligeros
Al estar diseada para el cambio experimenta reduccin de costo.
Presenta una planificacin ms transparente para los clientes.
Se definen en cada iteracin cuales son los objetivos de la siguiente.
Permite tener una muy til realimentacin de los usuarios.
Est desarrollado por el grupo DSDM Consorcio.
Permite tener una muy til realimentacin de los usuarios.

3.4.3 FASES DEL CICLO DE VIDA

(Pressman, 2010) Dice que el DSDM Consortium lo define con tres ciclos iterativos
distintos junto con dos actividades adicionales del ciclo de vida:

Estudio de factibilidad: establece los requerimientos y restricciones

bsicas asociados con la aplicacin que se va a construir, para finalmente
evaluar su viabilidad de desarrollo por DSDM.
Estudio del negocio: los requerimientos e informacin funcionales que
permiten a la aplicacin dar valor y adems de definir la arquitectura bsica
de la aplicacin e identifica sus requerimientos.
Iteracin del modelo funcional: produce un conjunto de prototipos
incrementales que demuestran al cliente la funcionalidad.(No todos los
DSDM), el objetivo de este ciclo iterativo es recabar requerimientos
adicionales por medio de la obtencin de retroalimentacin de los usuarios
cuando practican con el prototipo.

Y las dos actividades adicionales:

Diseo e iteracin de la construccin: revisita los prototipos construidos

durante la iteracin del modelo funcional a fin de garantizar que en cada
 iteracin se ha hecho ingeniera en forma que permita dar valor operativo
del negocio a los usuarios finales, se da en paralelo con el modelo
funcional.
Implementacin: coloca el incremento ms reciente del software en un
ambiente de operacin.

3.4.4 ROLES

Segn (Villamarin Zambrano, s.f.) Se enuncia los siguientes roles:

Patrocinador Ejecutivo As que llam el "Proyecto de Campen". Un papel

importante de la organizacin de usuarios que tiene la capacidad y la
responsabilidad de comprometer fondos y recursos apropiados. Esta
funcin tiene un mximo poder para tomar decisiones.

Visionario El que tiene la responsabilidad de inicializar el proyecto,

asegurando que los requisitos esenciales se encuentran desde el principio.
Visionario tiene la percepcin ms precisa de los objetivos de negocio del
sistema y el proyecto. Otra tarea es supervisar y mantener el proceso de
desarrollo en el camino correcto.

Embajador del usuario Trae el conocimiento de la comunidad de usuarios

en el proyecto, asegura que los desarrolladores reciben la cantidad
suficiente de comentarios del usuario durante el proceso de desarrollo.

Asesor del usuario Puede ser cualquier usuario que representa un punto
de vista importante y aporta el conocimiento diario del proyecto.

Gerente de Proyecto Puede ser cualquier persona de la comunidad de

usuarios o al personal de TI que gestiona el proyecto en general.

Coordinador Tcnico Responsable en el diseo de la arquitectura del

sistema y el control de la calidad tcnica en el proyecto.
 Jefe de equipo Lleva a su equipo y asegura que el equipo funciona de
manera efectiva en su conjunto.

Desarrollador Interpretar los requisitos del sistema y el modelo que

incluyendo el desarrollo de los cdigos de entrega y construir los
prototipos.
Probador Comprueba la correccin en un extensiones tcnica mediante la
realizacin de algunas pruebas. Probador tendr que dar algunos
comentarios y documentacin.

Facilitador Responsable en la gestin de los progresos talleres, acta

como un motor para la preparacin y la comunicacin.

Especialista en funciones Business Architect, Director de Calidad,

integradores de sistemas, etc.

3.4.5 VENTAJAS Y DESVENTAJAS

Las ventajas de esta metodologa:

La calidad del producto es mejorada a travs de la participacin de los

usuarios a lo largo del ciclo de vida del proyecto y la naturaleza iterativa
del desarrollo.
DSDM asegura desarrollos rpidos.
Reduce los costos de proyectos a travs de las ventajas mencionadas
anteriormente
Permite realizar cambios de forma fcil.
Permite la reutilizacin de aplicacin a travs de los mdulos existentes.

Y como desventaja:

Se necesita una alta participacin de los usuarios en el desarrollo, para

evitar que los desarrolladores asuman criterios que no son ciertos.
 No es una metodologa de desarrollo comn. El proceso es un tanto difcil
de comprender

3.5 ADAPTIVE SOFTWARE DEVELOPMENT (ASD)

3.5.1 ANTECEDENTES

La metodologa de desarrollo adaptivo de software fue propuesto por Jim

Highsmith en 1998 como una tcnica para elaborar software y sistemas
complejos, y se basa en la filosofa de la colaboracin humana y la organizacin
propia del equipo.

Esta metodologa no proporciona el tipo de prcticas detalladas como lo hace XP,

pero proporciona la base fundamental de por qu el desarrollo adaptable es
importante y las consecuencias a los ms profundos niveles de la organizacin y
la gerencia.

Es un modelo dirigido a la construccin de software y sistemas complejos, incluye

tres fases que son: especulacin, colaboracin y aprendizaje, cada una de estas
fases son fundamental para el desarrollo de la otra. Es adaptativo, se hace uso de
la reutilizacin del cdigo para adaptarlo a lo que se desea.

3.5.2 CARACTERSTICAS

Sus principales caractersticas:

Es iterativo.
Est orientado ms a los componentes de software que a las tareas y
susceptible a cambios.
Considera la colaboracin como fuente de orden de complejas
interacciones ya sea de disciplina e ingeniera.
Los equipos de desarrollo de DAS aprenden de tres maneras: grupos de
enfoques, revisiones tcnicas y anlisis postmorten (etapa final) del
proyecto.
 El nfasis general que hace el DAS en la dinmica de los equipos con
organizacin propia, la colaboracin interpersonal y el aprendizaje
individual y del equipo generan equipos para proyectos de software que
tienen una probabilidad de xito mucho mayor. (Pressman, 2010).

3.5.3 DIAGRAMA DE ETAPAS

Se inicia por la especulacin (restricciones del proyecto y requerimientos bsicos),

pasa a la colaboracin donde se incluye la comunicacin y el trabajo en equipo
tambin como individual para su paso al aprendizaje que hace referencia al nivel
de entendimiento real.

3.5.4 ETAPAS DE DESARROLLO

Tres etapas significativas en el mtodo DAS:

Fase de especulacin: es la primera de las fases esta inicia en el

desarrollo del proyecto. Se utiliza informacin como la visin del cliente,
las restricciones del proyecto y los requisitos bsicos para definir el
conjunto de ciclos en el que se harn los incrementos del software. En esta
 fase es donde se lleva a cabo la planificacin tentativa del proyecto en
funcin de las entregas que se irn realizando

Fase de colaboracin: se busca que el equipo colabore inmensamente

para lograr la funcionalidad planeada, se comunique o se encuentre
completamente integrados, se desea que exista confianza, donde se
puedan realizar crticas constructivas y ayudar si resentimientos, as como
tambin comunicar de una forma oportuna los problemas que se presenten
para tomar acciones efectivas y poseer un conjunto de actitudes que
contribuyan al trabajo que se encuentran realizando.
Se resalta ciertos aspectos personales de colaboracin como: 1) criticarse
sin enojo, 2) ayudarse sin resentimiento, 3) trabajar tan duro, o ms, que
como de costumbre, 4) tener el conjunto de aptitudes para contribuir al
trabajo, y 5) comunicar los problemas o preocupaciones de manera que
conduzcan a la accin efectiva.

Fase del aprendizaje: consiste en la revisin de calidad que se realiza al

final de cada ciclo, esto permite mejorar el entendimiento real sobre la
tecnologa, los procesos utilizados y el proyecto. El aprendizaje individual
permite al equipo tener mayor posibilidad de xito.

3.5.5 VENTAJAS Y DESVENTAJAS

Ventajas:

Se utiliza para poder aprender de los errores e iniciar nuevamente el ciclo

de desarrollo.
Utiliza informacin disponible acerca de todos los cambios para poder
mejorar el comportamiento del Software.
Difunde la colaboracin de distintas personas.

Desventajas:
 Los errores y cambios que no son detectados con anterioridad afectan la
calidad del producto y su costo total.
Ya que esta es una metodologa gil, no permite realizar procesos que son
requeridos en las metodologas tradicionales.

3.6 FEATURE DRIVEN DEVELOPMENT

3.6.1 GENERALIDADES

De (Bolivariana, 2014) , Desarrollo basado en funcionalidades, FDD con sus siglas

en ingls Feature Driven Development es un enfoque gil para el desarrollo de
sistemas. Fue desarrollado por Jeff De Luca y el viejo gur de la Orientacin a
Objetos Peter Coad. Como las otras metodologas adaptables, se enfoca en
iteraciones cortas que entregan funcionalidad tangible, dicho enfoque no hace
nfasis en la obtencin de los requerimientos sino en cmo se realizan las fases
de diseo y construccin. Sin embargo, fue diseado para trabajar con otras
actividades de desarrollo de software y no requiere la utilizacin de ningn modelo
de proceso especfico. Adems, hace nfasis en aspectos de calidad durante todo
el proceso e incluye un monitoreo permanente del avance del proyecto. Al
contrario de otras metodologas, FDD afirma ser conveniente para el desarrollo
de sistemas crticos.

Este modelo define un proceso iterativo que consta de 5 pasos, donde cada
iteracin puede abarcar hasta dos semanas.

3.6.2 CARACTERSTICAS PRINCIPALES

De (EcuRed, 2014) enuncia las principales 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 monitorear.
Define claramente entregas tangibles y formas de evaluacin del progreso
del proyecto.

3.6.3 FASES DE DESARROLLO

El proceso de desarrollo se lleva a cabo en cinco fases secuenciales, de

(Bolivariana, 2014) describe las fases:

Desarrollar modelo general (Develop an Overall Modell): cuando esta

fase comienza, los expertos del dominio ya tienen una idea del contexto y
los requerimientos del sistema. Es probable que el documento de
especificacin de requerimientos ya exista. Sin embargo, FDD no hace
nfasis en la recoleccin y administracin de los requerimientos. Los
expertos del dominio presentan un informe llamado walkthrough en el cual
los miembros del equipo, el dominio global es dividido en diferentes reas
y se realiza un walkthrough detallado para cada una de dichas reas por
parte de los expertos del dominio. Luego de cada walkthrough, un grupo
de desarrolladores realizan un modelo de objetos para el rea del dominio.

Construir lista de rasgos (Build a Features List): Los walkthroughs, el

modelo de objetos y los requerimientos existentes ofrecen una buena base
para construir una Lista de rasgos que resuma la funcionalidad del sistema
a ser desarrollado. En dicha lista, el equipo de desarrolladores presenta
cada una de las funcionalidades evaluadas por el cliente. Las
funcionalidades son presentadas por cada rea del dominio y stas forman
 un Mejor List Sets. Dicha lista es divida en subconjuntos en base a la
funcionalidad.

Planear rasgos (Plan by Feature): en esta etapa se incluye la creacin de

un plan de alto nivel, en el cual la lista de rasgos es ordenada en base a la
prioridad y a la dependencia entre cada rasgo. Adems, las clases
identificadas en la primera etapa son asignadas a cada programador.

Disear y construir por rasgos: el diseo y construccin de la

funcionalidad es un proceso iterativo durante el cual los lineamientos
seleccionados son producidos. Una iteracin puede llevar desde unos
pocos das a un mximo de dos semanas. Este proceso iterativo incluye
tareas como inspeccin del diseo, codificacin, testing unitario,
integracin e inspeccin del cdigo.

3.6.4 ROLES

De (EcuRed, 2014) :

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):
 Director del Proyecto: Lder administrativo y financiero del proyecto.
Protege al equipo de situaciones externas.

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 de la ltima fase del FDD.

Propietario de clases: Responsable del desarrollo de las clases que se le

asignaron como propias. Participa en la decisin de que clase ser incluida
en la lista de funcionalidades de la prxima iteracin.

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.

3.6.5 VENTAJAS Y DESVENTAJAS

Ventajas

El objetivo es la entrega concreta, desarrollo de software en repetidas

ocasiones, en el momento oportuno.
Provee estrategias de planteamiento para el lder del proyecto.
Una de las ventajas de centrarse en las features del software es el poder
formar un vocabulario comn que fomente que los desarrolladores tengan
 un dilogo fluido con los clientes, desarrollando entre ambos un modelo
comn del negocio.

Desventajas

Demasiado jerrquico, demanda un programador jefe quien manda sobre

los propietarios de clases quienes dirigen los equipos de rasgos.
Necesita un equipo de miembros con experiencia que definan los pasos a
seguir a lo largo del proyecto.
Pocos detalles sobre las pruebas.

4. CONCLUSIONES

De lo anterior planteado podemos enunciar las siguientes conclusiones:

Las metodologas giles se fundamentan en el recurso humano y la

comunicacin, pensados en tiempos cortos, nuevas tecnologas y
requisitos voltiles.
En los mtodos cristalizados las metodologas aumentan de acuerdo a la
cantidad de personas implicadas.
Las metodologas giles se preocupan ms por el software que por su
documentacin.
No existe una especificacin y efectividad de los mtodos giles de
desarrollo, solo hay que adaptarla al proyecto.
Las metodologas tradicionales siempre han tratado de abarcar todos los
aspectos de contexto, pero las giles se centran en la sencillez y facilidad
de aplicacin e implantacin.

5. BIBLIOGRAFA

Bolivariana, U. U. (2014). Ingenieria de Software. Obtenido de

http://ingenieriadesoftware.mex.tl/61162_FDD.html
Cans, J., Letelier, P., & Penads, C. (s.f.). Metodologas giles en el desarrollo
de Software. Universidad Politcnica de Valencia.

Desconocido. (2012). WikiUDO. Obtenido de WikiUDO:

http://wiki.monagas.udo.edu.ve/index.php/Metodolog%C3%ADas_para_e
l_desarrollo_de_software#Modelo_en_Espiral

EcuRed. (2014). Metodologa FDD. Obtenido de

http://www.ecured.cu/index.php/Metodolog%C3%ADa_FDD

O'Neill, M. (1980). The Managemente of Software Engineering.

Pressman S, R. (2002). Ingeniera de Software. Espaa: McGRAW-HILL.

Pressman, R. (2010). Ingeniera de Software. Un enfoque practico. Mxico:

McGRAW-HILL INTERAMERICANA EDITORES.

SOMMERVILLE, I. (2005). Ingeniera de Software. Madrid: PEARSON

EDUCACION S.A.

Villamarin Zambrano, C. (s.f.). Google Sites. Obtenido de Metodos de desarrollo

de sistemas dinmicos: https://sites.google.com/site/utmfci/home