2/10/2011

INSTITUTO
TECNOLGICO DE ORIZABA

ANLISIS COMPARATIVO

METODOLOGAS

GILES Y TRADICIONALES

Presenta | LSCA Eric Velzquez Cruz

ndice

Introduccin eXtreme Programming SCRUM Feature Driven Model FDD gil UP Tabla comparativa Metodologas Tradicionales VS Agiles Conclusiones Bibliografa

3 4 6 8 10 12 13 15 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

Individuos e interacciones 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.

-2

Procesos y Herramientas 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.

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

-3

Documentacin extensiva 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.

Colaboracin con el cliente 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

-3

Negociacin contractual 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.

Respuesta ante el cambio 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.

-3

Seguir un plan 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

Individuos e interacciones La responsabilidad, autodisciplina 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.

-3

Procesos y Herramientas 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

Software funcionando 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.

-5

Documentacin extensiva 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.

Colaboracin con el cliente Al igual que XP, la metodologa gil SCRUM cuenta con la

-3

Negociacin contractual 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

Respuesta ante el cambio 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.

-2

Seguir un plan 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

Individuos e interacciones 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.

-4

Procesos y Herramientas 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.

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

-5

Documentacin extensiva 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.

Colaboracin con el cliente 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.

-5

Negociacin contractual 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.

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

-5

Seguir un plan 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

Individuos e interacciones 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.

-1

Procesos y Herramientas 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.

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

-2

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

Colaboracin con el cliente 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

-1

Negociacin contractual 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.

Respuesta ante el cambio 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.

-1

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

Comparativa gil
6 4 2 0 -2 -4 Individuos Procesos y Software Documenta Colaboraci Negociaci Respuesta e Seguir un Herramient funcionand cin n con el n ante el interaccion plan as o extensiva cliente contractual cambio es 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

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 requiriendo. ha ido

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