2/10/2011

Presenta | LSCA Eric Velzquez Cruz

INSTITUTO
TECNOLGICO
DE ORIZABA
ANLISIS COMPARATIVO METODOLOGAS
GILES Y TRADICIONALES



ndice

Introduccin 3
eXtreme Programming 4
SCRUM 6
Feature Driven Model FDD 8
gil UP 10
Tabla comparativa 12
Metodologas Tradicionales VS Agiles 13
Conclusiones 15
Bibliografa 16






Introduccin


De acuerdo con lo expuesto en las ltimas clases por la Dra. Mirna Muos Mata en
la asignatura Ingeniera de Software Orientada a Objetos, en la que se examinaron los
puntos ms importantes de las metodologas giles con mayor relevancia para esta
asignatura, entre las cuales fueron elegidas las siguientes: eXtreme Programming (XP),
SCRUM, Feature Driven Development (FDD) y gil UP.

En base a esto, se propuso la creacin de una tabla comparativa entre dichas
metodologas basada en puntos estratgicos que permitan un entendimiento integral de las
mismas, adquiriendo conocimiento suficiente para la culminacin y desarrollo de un
anlisis comparativo con las metodologas tradicionales, las cuales fueron estudiadas en la
asignatura previamente estudiada titulada Ingeniera de software impartida por la M.C. Ana
Mara Chvez Trejo.




Desarrollo

Comparativa gil

eXtreme Programming
5
Individuos e interacciones
-2
Procesos y Herramientas

Debido a que se encuentra
centrado en potenciar las
relaciones interpersonales como
clave para el xito en el desarrollo
de software, as como de igual
manera promueve el trabajo en
equipo y busca el que tenga un
mejor entorno de desarrollo.

An cuando parece que XP deja
de lado este punto, tiene
relevancia e impacto, ya que a
pesar de que se puede considerar
de cierta manera simple o
sencilla, se tiene formalidad al
realizarlo; por otra parte las
herramientas son consideradas
para apoyo en partes especficas
del proceso, siendo esto
dependiente del equipo de
desarrollo.

5
Software funcionando
-3
Documentacin extensiva

Se encuentra enfocado a pequeas
entregas funcionales, las cuales
han sido sometidas a pruebas de
aceptacin y cuentan con la
aprobacin de los clientes.

Los requerimientos son
recabados en forma de Historias
de Usuarios y Metfora, con los
cuales se desarrollan los planes
de entrega y se hace la
integracin de un cronograma de
actividades, con esto se crea la
planificacin de la iteracin y con
las pruebas de aceptacin se
obtiene la documentacin mnima
indispensable.

5
Colaboracin con el cliente
-3
Negociacin contractual

El cliente se involucra a un grado
tal en que llega a ser considerando
un rol, el cual recaba los
requisitos al escribir las Historias

El cliente al realizar las historias
de usuario y fijar las pruebas de
aceptacin establece que es lo
que espera recibir del software, y


de Usuario y las pruebas de
funcionales para validar su
implementacin, prioriza y decide
cuales se implementarn, XP
propone una retroalimentacin
continua entre clientes y equipo
de desarrollo, en esta metodologa
se tienen otros roles que
complementan la colaboracin
con el cliente como es el caso del
Gerente (Big Boss) y el
Encargado de pruebas.

al momento de recibir y aceptar
las pequeas entregas acepta que
cumple con los requisitos
establecidos anteriormente.
5
Respuesta ante el cambio
-3
Seguir un plan

Al ser el cliente el que realiza las
Historias de Usuario, as como
tener la capacidad de
modificacin de ellas o que sean
admitidas nuevas en cualquier
momento del desarrollo XP,
demostrando su gran apertura ante
el cambio, esto se logra mediante
una amplia comunicacin entre el
cliente y el equipo de desarrollo.

Es cierto que la manera en que se
toma la respuesta ante el cambio
en XP no hace ms fcil el
seguimiento de un plan, pero si se
tiene una fase de planificacin en
la que se realiza el plan de accin
con el detalle de las actividades
que se van a llevar a cabo de
acuerdo con los requisitos
descritos en las Historias de
Usuario, as como tambin se
tienen los planes de iteracin que
permiten con la priorizacin de
los requisitos saber qu es lo que
se va a planear para cada
iteracin del proyecto.






SCRUM
5
Individuos e interacciones
-3
Procesos y Herramientas

La responsabilidad, auto-
disciplina y el respeto son
caractersticas en los miembros de
un equipo, lo cual les permite
trabajar eficientemente,
llevndolos a la obtencin de
productos complejos y
sofisticados. En SCRUM forma
parte de su filosofa lo siguiente:
Cada miembro del equipo debe
colaborar de forma abierta con
los dems, segn sus habilidades
y no segn su rol o puesto esto
demuestra que este punto es muy
importante en esta metodologa
gil.


El proceso aplicado en la
metodologa SCRUM es muy
sencillo siendo el sprint el
ncleo central que proporciona la
base de desarrollo iterativo e
incremental, haciendo uso se de
buenas prcticas, as como un
conjunto de herramientas
gratuitas como es scrumworks,
icescrum y scrum for team
system
5
Software funcionando
-5
Documentacin extensiva

SCRUM adapta su proceso para la
gestin y control del producto
para quitarle complejidad a estas
reas, para as poder centrarse en
la construccin de software que
satisfaga las necesidades del
negocio, esto basado en un
desarrollo iterativo e incremental,
y se tienen sprints de corta
duracin.




No maneja documentacin
extensiva, considera que la
documentacin de las historias de
usuario y planeacin para cada
sprint, pueda ser llevada a cabo
mediante imgenes, o
documentos informales.
5
Colaboracin con el cliente
-3
Negociacin contractual

Al igual que XP, la metodologa
gil SCRUM cuenta con la

Al ser manejados los requisitos
mediante historias de usuario


inclusin del cliente como un rol
ms, dentro de su proceso de
desarrollo, adems de contar
tambin con Historias de Usuario,
para SCRUM la participacin del
cliente es imprescindible y est
implicada durante todo el ciclo de
vida del producto, observando los
progresos, aportando ideas,
sugerencias o necesidades.

realizadas entre el equipo de
desarrollo y el cliente, la
negociacin queda de manera
implcita dentro de ellas con las
pruebas de aceptacin y
declaracin de los requisitos
5
Respuesta ante el cambio
-2
Seguir un plan

Tiene gran respuesta ante el
cambio debido a las buenas
prcticas que realiza, tales como
el uso de Historias de Usuario e
involucracin del cliente dentro
de todo el ciclo de vida. A
primera vista parece que
congelar las HU mientras est
realizndose el sprint no cumple
al 100% este punto, sin embargo,
este proceso es para tener un
mejor control de estas y agilizar el
desarrollo.

En SCRUM la parte ms fuerte
de la planeacin es llevada a cabo
durante la priorizacin y
planeacin de los sprints, los
cuales gracias a que las historias
de usuario son congeladas cuando
es llevado a cabo un sprint se
permite llevar una mejor
continuidad de planes que en XP.






Feature Driven Development
1
Individuos e interacciones
-4
Procesos y Herramientas

Al estar enfocado ms en el
desarrollo del producto que en el
equipo deja un poco de lado este
punto, pero al estar enfocado solo
a las fases de diseo y
construccin se puede
complementar con otras prcticas
que ayuden a este punto, sin
embargo, FDD por s solo deja
este punto muy abandonado.


Los procesos son sencillos y
generales enfocados a ser
iterativos, admite procesos ms
especficos en las fases que no
realiza FDD y contempla para la
parte de herramientas un rol de
soporte herramientista el cual
se encarga de los builds y publica
la documentacin.
5
Software funcionando
-5
Documentacin extensiva

El proceso de FDD se encuentra
basado en iteraciones cortas, que
producen un software que se
decide en base a su funcionalidad.


Tiene un rol para la publicacin
de la documentacin y un rol
adicional Escritores de
documentos tcnicos el cual
complementa en FDD este punto
en especfico.

3
Colaboracin con el cliente
-5
Negociacin contractual

No exige la presencia del cliente,
pero incluye entre los roles el de
experto de dominio, lo cual
muestra que FDD da importancia
a este punto especifico.


FDD no toma en cuenta este tema
en particular al no estar enfocado
en las fases en las que hace
nfasis pero propone utilizar otras
tcnicas y/o buenas prcticas que
ayuden a resolver este punto
especifico.





3
Respuesta ante el cambio
-5
Seguir un plan

Su proceso es iterativo lo cual
permite tener respuesta ante el
cambio entre cada iteracin

No requiere un modelo especifico
de proceso, expone entre sus
principios que un proceso simple
y bien definido trabaja mejor, y
sus pasos deben ser lgicos con
merito obvio para cada miembro.






gil UP
5
Individuos e interacciones
-1
Procesos y Herramientas

El Administrador de la
configuracin est involucrado
con este punto en particular,
debido a que est encargado de
crear el medio ambiente para el
equipo de desarrollo, aunque el
Administrador de proyecto es el
rol ms relevante ya que tiene a su
cargo las siguientes actividades:
administracin de miembros de
los equipos de trabajo, creacin
de relaciones con los
involucrados, coordinar las
interacciones con stos as como
enmarcar las prioridades y
mantener al equipo enfocado.


Al ser una adaptacin de una
metodologa tradicional gil UP
tiene procesos y herramientas
bien definidos, los cuales han
sido adaptados para coincidir con
el enfoque que se tiene en las
metodologas agiles.
4
Software funcionando
-2
Documentacin extensiva

El objetivo de la fase de
construccin es desarrollar
software funcional en una base
regular e incremental.

La documentacin entregada es
definida por los artefactos, los
cuales estn bien definidos de
acuerdo a las fases e iteraciones
necesarias.

3
Colaboracin con el cliente
-1
Negociacin contractual

La colaboracin es con los
involucrados que son un rol en
gil UP, sin embargo este puede
ser usuario directo, usuario
indirecto, administrador de
usuarios, administrador, miembro
de equipo de operacin o soporte,
desarrolladores que trabajan en
otros sistemas que se integran o
interactan con el sistema
implementado; por lo cual a veces
hace un poco ms difcil la

En el modelado se tiene como
meta entender el negocio de la
organizacin, el dominio del
problema que el proyecto aborda
e identificar una solucin viable
para abordar el dominio del
problema; lo cual ayuda la
negociacin.


colaboracin. Pero este rol se
encuentra presente en varias
disciplinas, modelado,
implementacin, pruebas,
desarrollo y administracin del
proyecto.

3
Respuesta ante el cambio
-1
Seguir un plan

La aceptacin de los cambios de
requisito solo se puede hacer
despus de generar los artefactos
especficos en cada entrega, lo
cual le resta puntos en
comparacin con otras
metodologas agiles, pero a
comparacin de su contraparte
tradicional es mucho mayor su
respuesta ante el cambio.


Tiene un plan bien definido, al
hacer la conversin a una
metodologa gil, se conservo
muy bien su planeacin.















Individuos
e
interaccion
es
Procesos y
Herramient
as
Software
funcionand
o
Documenta
cin
extensiva
Colaboraci
n con el
cliente
Negociaci
n
contractual
Respuesta
ante el
cambio
Seguir un
plan
XP 5 -2 5 -3 5 -3 5 -3
SCRUM 5 -3 5 -5 5 -3 5 -2
FDD 1 -4 5 -5 3 -5 0 0
gil UP 5 -1 4 -2 3 -1 3 -1
-6
-4
-2
0
2
4
6
Comparativa gil


Metodologas

Agiles vs Tradicionales

Lo expuesto anteriormente permite tener una idea ms clara acerca de las metodologas
agiles, las metodologas tradicionales han tenido gran trascendencia en los desarrollos.
A primera vista las metodologas agiles no parecen estar muy enfocadas a los procesos en
comparacin con las tradicionales, sin embargo, algunas metodologas agiles tienen
procesos establecidos, para abordar cada fase del ciclo de desarrollo; las metodologas
tradicionales llevan ventaja en este punto contra las metodologas giles por su amplia
trayectoria y que algunas metodologas tradicionales son enfocadas a los procesos ms que
al individuo y/o al producto final.
En cuanto a los roles y responsabilidades tanto las metodologas tradicionales como las
agiles abordan este punto, ya que al tenerlo definido correctamente facilita la
comunicacin, permite abordar de una mejor manera el desarrollo y cierra la brecha entre el
cliente y el equipo de desarrolladores; en cuanto a las practicas las metodologas agiles
proponen la utilizacin de estas para atacar problemas especficos y son mas abiertas a
incluir nuevas y algunas incluso se enfocan a partes del ciclo de vida dejando a criterio del
equipo como abarcar aquellas que no son tomadas en cuenta por la metodologa, dando al
equipo de desarrollo a la vez una gran responsabilidad y una versatilidad que las
metodologas tradicionales no suelen dar.
Viendo desde las experiencias y la adaptacin las metodologas tradicionales y las
metodologas agiles tienen una meta en comn, el utilizarlas como apoyo a la hora de que
se van a realizar nuevos proyectos e inclusive para no cometer errores que se tuvieron de
desarrollos del mismo dominio o de dominios similares, obteniendo con esto un gran
soporte y retroalimentndolas a la vez.
El entorno de uso vara dependiendo de cada una de las metodologas ya sean tradicionales
o agiles, pero principalmente las metodologas agiles son adoptadas para desarrollos
pequeos o medianos, sin embargo han sido adoptadas para proyectos de gran envergadura
obteniendo resultados impresionante como es el caso de XP, SCRUM y CRYSTAL.
Teniendo en cuenta el ciclo de vida tanto las metodologas tradicionales como giles han
ido apostando por ser iterativas e incrementales.


Tanto las metodologas agiles como las tradicionales se encuentran de manera activa y con
soporte inclusive algunas siguen en desarrollo para abarcar fases que no incluyen en este
momento.


Conclusiones
De acuerdo con lo expuesto en este trabajo podemos llegar a varias conclusiones entre las
cuales destacan las siguientes:

En la primera parte donde se expusieron las metodologas agiles haciendo una comparativa
enfocada a las partes del manifiesto gil a las cuales dan mayor importancia y que fases son
las que principalmente son realizadas, as como algunos roles principales en estas
metodologas. Se pudo observar que no es necesario que una metodologa gil intente
abarcar todas las fases del ciclo de desarrollo como lo es el caso del Modelado Dirigido por
Caractersticas (FDD por sus siglas en ingles), y que inclusive las metodologas
tradicionales pueden ser adaptadas y enfocadas a un desarrollo gil como vimos con gil
UP que retoma lo bueno de dos mundos teniendo todo un proceso definido y teniendo una
visin ms fresca del desarrollo como lo es el Manifiesto gil, dndole la versatilidad de la
configuracin obteniendo as un soporte impresionante para desarrollos muy grandes con su
versin tradicional y ajustado para proyecto medianos e incluso pequeos con
caractersticas que solo una metodologa gil podra abordar de una manera tan veloz.

En la segunda parte podemos observar que aun cuando surgen en tiempos diferentes y
enfocados a desarrollos distintivos las metodologas agiles y tradicionales tienen sus
ventajas y desventajas, dependiendo de los equipos de desarrollo, el tamao del proyecto e
inclusive las caractersticas del mismo.

Expuesto lo anterior podemos concluir de manera general que aun cuando las metodologas
tradicionales puedan parecer a algunos una solucin obsoleta, estas pueden adaptarse o
configurarse para tener un enfoque ms gil como pudimos observar con gil UP, ya que
estas metodologas han tenido gran trascendencia a lo largo del tiempo recabando buenas
prcticas y ajustndose o mejorndose conforme el desarrollo de software lo ha ido
requiriendo.


REFERENCIAS BIBLIOGRAFICAS

Palmer, S.R. A Practical Guide to Feature-Driven Development. Prentice Hall.




REFERENCIAS ELECTRNICAS


Metodologa gil UP tomado de: http://cgi.una.ac.cr/AUP/index.html

Metodologa gil SCRUM apoyado en :
http://www.unbugalavez.net/2008/03/herramientas-para-scrum.html




MEMORIAS DEL CURSO INGENIERIA DE SW ORIENTADA A OBJETOS


Metodologas giles, Dra. Mirna Ariadna Muoz Mata, Agosto del 2011