You are on page 1of 7

UNIVERSIDAD GRABRIEL RENE MORENO

Metodologa gil vs Metodologa Tradicional


MODULO DE CALIDAD
LINDA LUNA TELLEZ

2012

Metodologas giles vs tradicionales 1. Historia de las metodologas y de los modelos. Desde el inicio del desarrollo masivo de software [1] se ha querido encontrar las mejores prcticas y distribuir la experiencia obtenida a travs de la prctica. Esto se ha hecho tradicionalmente mediante metodologas impulsadas por universidades y grandes empresas de tecnologa a travs de metodologas, como la programacin estructurada (1969), SSADM (1980), RAD (1991), RUP y SCRUM (1998) o XP (1999). Adems, se han generado diferentes modelos de calidad que identifican actividades del desarrollo determinadas como buenas prcticas (el QUE) pero que no prescriben la manera de realizarlas concretamente (el COMO), de manera que los equipos que los adoptan pueden elegir cul es la manera de realizar estas prcticas que mejor se adapta a sus contextos y caractersticas. Uno de los principales errores que tenemos las personas en general, es el querer aplicar un mtodo de resolucin de problemas que una vez usamos exitosamente, para resolver todos los problemas. Cuando analizamos las metodologas candidatas a implantar en nuestros lugares de trabajo, surgen, casi automticamente, dos tipificaciones de metodologas: las metodologas giles versus las metodologas duras (tradicionales). Podemos mencionar entre las primeras a XP (Extreme Programming, junto a su partner XT- Extreme Testing -) y SCRUM, en tanto que dentro de la segunda categora una de las ms conocidas es CMMI. Revisin de metodologas [1] Antes de resumir algunas metodologas giles, vamos a enumerar las principales diferencias respecto de las metodologas tradicionales (no giles). La Tabla 1 recoge esquemticamente estas diferencias que no se refieren slo al proceso en s, sino tambin al contexto de equipo y organizacin que es ms favorable a cada uno de estas filosofas de procesos de desarrollo de software. Metodologas Agiles Basadas den Heursticas provenientes de prcticas de produccin de cdigo Metodologas Tradicionales Basadas en Normas Provenientes de Estndares seguidos por el entorno de desarrollo para Cierta Resistencia a los Cambios. Proceso mucho ms controlado, numerosas polticas /normas. Existe un contrato prefijado con

Especialmente preparados cambios durante el proyecto. Proceso menos controlado, con pocos principios. No existe contrato tradicional o al menos es bastante flexible. El cliente es parte del equipo de

El cliente interacta con el equipo de

desarrollo desarrollo mediante reuniones. Grupos pequeos (<10 integrantes) y Grupos grandes y posiblemente trabajando en el mismo sitio. distribuidos. Pocos roles. Ms roles. Menos nfasis en la arquitectura del La arquitectura del software es esencial y software se expresa mediante modelos. Tabla 1. Diferencias entre metodologas giles y no giles Aunque los creadores e impulsores de las metodologas giles ms populares coinciden con los principios enunciados anteriormente, cada metodologa tiene caractersticas propias y hace hincapi en algunos aspectos ms especficos. A continuacin se resumen dichas metodologas giles.

SCRUM. Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle.


Define un marco para la gestin de proyectos, que se ha utilizado con xito durante los ltimos 10 aos. Est especialmente indicada para proyectos con un rpido cambio de requisitos. Sus principales caractersticas se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duracin de 30 das. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda caracterstica importante son las reuniones a lo largo proyecto. stas son las verdaderas protagonistas, especialmente la reunin diaria de 15 minutos del equipo de desarrollo para coordinacin e integracin.

Crystal Methodologies Se trata de un conjunto de metodologas para el desarrollo de software


caracterizadas por estar centradas en las personas que componen el equipo (de ellas depende el xito del proyecto) y la reduccin al mximo del nmero de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juego operativo de invencin y comunicacin, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, as como tener polticas de trabajo en equipo definidas. Estas polticas dependern del tamao del equipo, establecindose una clasificacin por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).

Dynamic Systems Development Method(DSDM) Define el marco para desarrollar un


proceso de produccin de software. Nace en 1994 con el objetivo el objetivo de crear una metodologa RAD unificada. Sus principales caractersticas son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseo y construccin, y finalmente i implementacin. Las tres ltimas son iterativas, adems de existir realimentacin a todas las fases.

Adaptive Software Development7 (ASD) Su impulsor es Jim Highsmith. Sus principales


caractersticas son: iterativo, orientado a los componentes software ms que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulacin, colaboracin y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las caractersticas del software; en la segunda desarrollan las caractersticas y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisin de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo.

Feature-Driven Development (FDD) Define un proceso iterativo que consta de 5 pasos. Las
iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseo e implementacin del

sistema partiendo de una lista de caractersticas que debe reunir el software. Sus impulsores son Jeff De Luca y Peter Coad. Lean Development (LD) Definida por Bob Charettes a partir de su experiencia en proyectos con la industria japonesa del automvil en los aos 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal caracterstica es introducir un mecanismo para implementar dichos cambios.

PROGRAMACIN EXTREMA (EXTREME PROGRAMMING, XP)


Es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico. Los principios y prcticas son de sentido comn pero llevadas al extremo, Posteriormente, otras publicaciones de experiencias se han encargado de dicha tarea.. La Tabla 2 compara las distintas aproximaciones giles en base a tres parmetros: vista del sistema como algo cambiante, tener en cuenta la colaboracin entre los miembros del equipo y caractersticas ms especficas de la propia metodologa como son simplicidad, excelencia tcnica, resultados, adaptabilidad, etc. Tambin incorpora como referencia no gil el Capability Madurity Model (CMM). CMM ASD Crystal DSDM FDD LD SCRUM 1 5 4 3 3 4 5 Sistema algo Cambiante 2 5 5 4 4 4 5 Colaboracin Caractersticas Metodologa (CM) 2 5 5 4 4 4 5 Resultados 1 4 4 3 5 3 5 Simplicidad 2 5 5 3 3 4 4 Adaptabilidad 4 3 3 4 4 4 3 Excelencia Tcnica 2 5 5 4 3 3 4 Practicas de Colaboracin 2.2 4.4 4.4 3.6 3.8 3.6 4.2 Media CM 1.7 4.8 4.5 3.6 3.6 3.9 4.7 Media Total Tabla 2. Ranking de agilidad (Los valores ms altos representan una mayor agilidad) XP 5 5

5 5 3 4 5 4.4 4.8

Como se observa en la Tabla 2, todas las metodologas giles tienen una significativa diferencia del ndice de agilidad respecto a CMM y entre ellas destacan ASD, Scrum y XP como las ms giles.

CONCLUSIONES
No existe una metodologa universal para hacer frente con xito a cualquier proyecto de desarrollo de software. Toda metodologa debe ser adaptada al contexto del proyecto (recursos tcnicos y humanos, tiempo de desarrollo, tipo de sistema, etc.

Histricamente, las metodologas tradicionales han intentado abordar la mayor cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeos y con requisitos muy cambiantes. Las metodologas giles ofrecen una solucin casi a medida para una gran cantidad de proyectos que tienen estas caractersticas. Una de las cualidades ms destacables en una metodologa gil es su sencillez, tanto en su aprendizaje como en su aplicacin, reducindose as los costos de implantacin en un equipo de desarrollo. Esto ha llevado hacia un inters creciente en las metodologas giles. Sin embargo, hay que tener presente una serie de inconvenientes y restricciones para su aplicacin, tales como: estn dirigidas a equipos pequeos o medianos, el entorno fsico debe ser un ambiente que permita la comunicacin y colaboracin entre todos los miembros del equipo durante todo el tiempo, cualquier resistencia del cliente o del equipo de desarrollo hacia las prcticas y principios puede llevar al proceso al fracaso (el clima de trabajo, la colaboracin y la relacin contractual son claves), el uso de tecnologas que no tengan un ciclo rpido de realimentacin o que no soporten fcilmente el cambio, etc.

REFERENCIAS BIBLIOGRFICAS
[1]

http://www.willydev.net/descargas/masyxp.pdf

CUADRO COMPARATIVO DE LOS MODELOS DE PROCESO DE SOFTWARE [1]


MODELO PROCESO Se define como una secuencia de actividades donde la estrategia principal es seguir el proceso del desarrollo de SW hacia checkpoints o mediante entregas calendarizadas VENTAJAS DESVENTAJAS

CASCADA

Los documentos tcnicos son comprensibles para usuarios y administradores no tcnicos. Cada detalle de los requisitos se conoce de antemano antes de desarrollar el SW, y los detalles son estables durante el desarrollo. Las pruebas y evaluaciones se realizan eficientemente al final del desarrollo. Las metas se logran mejor cuando se tiene puntos de revisin bien preestablecidos y documentados.

Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicacin del paradigma.

INCREMENTAL

EVOLUTIVO

ESPIRAL

UP

Es una extensin del modelo de cascada. A diferencio del modelo de cascada, que es dirigido por documentos, el modelo espiral se basa en una estrategia para reducir el riesgo del proyecto en reas de incertidumbre, como requerimientos inestables e incompletos. Al igual que el modelo revolucionario, el modelo de espiral incorpora una estrategia de uso de prototipos como parte del manejo del riesgo. Con algunas variantes este es el proceso ms importante en la actualidad Es una extensin del modelo de cascada. A diferencio del modelo de cascada, que es dirigido por documentos, el modelo espiral se basa en una estrategia para reducir el riesgo del proyecto en reas de incertidumbre, como requerimientos inestables e incompletos. Al igual que el modelo revolucionario, el modelo de espiral incorpora una estrategia de uso de prototipos como parte del manejo del riesgo. Con algunas variantes este es el proceso ms importante en la actualidad Es una extensin al modelo incremental, donde los incrementos de hacen de manera secuencial en lugar de en paralelo; es tambin conocido como desarrollo rpido de aplicaciones (RAD, Rapid Application Development), que se basa en el uso de prototipo. Es un desarrollo inicial de la arquitectura completa del sistema, seguido de

La administracin de proyectos es ms fcil de lograr en incrementos ms pequeos. Es ms fcil comprender y probar incrementos de funcionalidad ms pequeos. La funcionalidad inicial de desarrolla ms temprano, logrando resultados de inversin en menor tiempo. Hay ms probabilidad de satisfacer el cambio en los requisitos de usuario mediante incrementos del SW en el tiempo que si fueran planeados todos a la vez en un mismo periodo.

Difcil de evaluar el coste total. Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. Requiere gestores experimentados. Los errores en los requisitos se detectan tarde.

Se entrega temprano parte del sistema, aunque no estn completos todos los requerimientos. Se permite entregar parte del sistema como herramienta para la generacin de requerimientos faltantes. Se obtienen beneficios para el sistema mediante entregas inciales mientras las entregas posteriores estn en desarrollo.

Una actividad comienza cuando es entienden los objetivos y riesgos involucrados. Basado en la evaluacin de soluciones alternas, se usan las herramientas que mejor reduzcan los riesgos. Todo el personal relacionado debe involucrarse en una revisin que determine cada actividad. El desarrollo se incrementa en cada etapa, permitiendo prototipos sucesivos del producto. Para construir un programa exitoso se deben conocer qu quieren y necesitan los usuarios potenciales.

Genera mucho tiempo en el desarrollo del sistema Modelo costoso Requiere experiencia en la identificacin de riesgos.

El desarrollo de un producto comercial puede significar un gran esfuerzo durante meses, e

incrementos y versiones parciales del mismo. Cada incremento tiene si propio ciclo de vida. Cada incremento agrega funcionalidad adicional o mejorada sobre el sistema. Conforme se completa cada etapa se verifica e integra la versin con las dems versiones ya completadas del sistema. Para que la secuencia de desarrollo sea exitosa es esencial definir etapas que no requieran cambiar los resultados anteriores al agregar nuevas

incluso aos.

REFERENCIAS BIBLIOGRFICAS
[1] [2]

http://es.scribd.com/doc/21938147/CUADRO-COMPARATIVO http://www.flickr.com/photos/48425423@N06/4433776469/in/photostream/

You might also like