Professional Documents
Culture Documents
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
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.
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.
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
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.
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/