Metodologas Tradicionales vs.

Metodologas giles
Camilo Javier Solis lvarez Roberth Gustavo Figueroa Daz cjsolis@utpl.edu.ec rgfigueroa@utpl.edu.ec

Universidad Tcnica Particular de Loja Escuela de Ciencias de la Computacin

1. Resumen

Desarrollar un buen software depende de un sinnmero de actividades y etapas, donde el impacto de elegir la mejor metodologa para un equipo en un determinado proyecto, es trascendental, para el xito del producto. El papel preponderante de las metodologas es sin duda esencial en un proyecto y el paso inicial, que debe encajar en el equipo, guiar y organizar actividades que conlleven a las metas trazadas en el grupo. En el presente trabajo se detallan los dos grandes enfoques, tanto metodologas tradicionales y metodologas giles, las primeras recalcan el uso exhaustivo de documentacin durante todo el ciclo del proyecto, mientras que las segundas ponen vital importancia en la capacidad de respuesta a los cambios y al mantener una buena relacin con el cliente para llevar al xito el proyecto. Se vern diferencias, ventajas, desventajas y cual puede encajar en un proyecto de software, es por ello que, ofrecemos una gua dejando a libre albedrio del lector el poder juzgar y elegir la mejor metodologa que se adapte a su equipo de desarrollo y al proyecto.

2. Introduccin

Dentro del desarrollo de software y a la altiva necesidad de que los proyectos lleguen al xito y obtener un producto de gran valor y alta calidad para nuestros clientes, creemos conveniente el estudio de las metodologas de desarrollo, las cuales, permitirn potencializar los grupos de desarrollo, aprovechando al mximo el potencial de todos quienes lo integran.

Es por este motivo que, la importancia de una metodologa adecuada y robusta, ajustada a un equipo, permitir la flexibilidad apropiada para la consecucin de los objetivos y adems ofrecer satisfacer al cliente ms all de las necesidades definidas al inicio del proyecto.

El xito del producto depende, en gran parte, de la metodologa acogida por el equipo; sea tradicional o gil, donde los equipos maximicen sus capacidades. A continuacin ponemos a consideracin estos dos grandes enfoques

3. Desarrollo

METODOLOGAS TRADICIONALES.-

Al inicio el desarrollo de software era artesanal en su totalidad. La ausencia de procesos formales, lineamientos claros, determinaron que se importara la concepcin y fundamentos de metodologas existentes en otras reas , y adaptarlas al desarrollo de software. Esta nueva etapa de adaptacin contena el desarrollo dividido en etapas de manera secuencial, que de algo mejoraba la necesidad latente en el campo del software.

Entre las principales metodologas tradicionales tenemos los ya tan conocidos RUP y MSF entre otros, que centran su atencin en llevar una documentacin exhaustiva de todo el proyecto y centran su atencin en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto.

Otra de las caractersticas importantes dentro de este enfoque, son los altos costos al implementar un cambio y la falta de flexibilidad en proyectos donde el entorno es voltil.

Las metodologas tradicionales (formales) se focalizan en documentacin, planificacin y procesos (plantillas, tcnicas de administracin, revisiones, etc.), a continuacin se detalla RUP y MSF uno de los mtodos ms usados dentro de los mtodos tradicionales

Rational Unified Process (RUP)

Figura 1.Esquema de trabajo RUP

RUP es un proceso formal: Provee un acercamiento disciplinado para asignar tareas y responsabilidades dentro de una organizacin de desarrollo. Su objetivo es asegurar la produccin de software de alta calidad que satisfaga los requerimientos de los usuarios finales (respetando cronograma y presupuesto). Fue desarrollado por Rational Software, y est integrado con toda la suite Rational de herramientas .Puede ser adaptado y extendido para satisfacer las necesidades de la organizacin que lo adopte. (customizacin). Es guiado por casos de uso y centrado en la arquitectura, y utiliza UML como lenguaje de notacin.

Fases
Las cuatro fases del ciclo de vida son: Concepcin Elaboracin Construccin Transicin

Ventajas
Evaluacin en cada fase que permite cambios de objetivos Funciona bien en proyectos de innovacin. Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software. Seguimiento detallado en cada una de las fases.

Desventajas
La evaluacin de riesgos es compleja

Excesiva flexibilidad para algunos proyectos Estamos poniendo a nuestro cliente en una situacin que puede ser muy incmoda para l. Nuestro cliente deber ser capaz de describir y entender a un gran nivel de detalle para poder acordar un alcance del proyecto con l.

Microsoft Solution Framework (MSF1)

MSF es un compendio de las mejores prcticas en cuanto a administracin de proyectos se refiere. Ms que una metodologa rgida de administracin de proyectos, MSF es una serie de modelos que puede adaptarse a cualquier proyecto de tecnologa de informacin.

Todo proyecto es separado en cinco principales fases:

Visin y Alcances. Planificacin. Desarrollo. Estabilizacin. Implantacin.

Visin y Alcances:
La fase de visin y alcances trata uno de los requisitos ms fundamentales para el xito del proyecto, la unificacin del equipo detrs de una visin comn. El equipo debe tener una visin clara de lo que quisiera lograr para el cliente y ser capaz de indicarlo en trminos que motivarn a todo el equipo y al cliente. Se definen los lderes y responsables del proyecto, adicionalmente se identifican las metas y objetivos a alcanzar; estas ltimas se deben respetar durante la ejecucin del proyecto en su totalidad, y se realiza la evaluacin inicial de riesgos del proyecto.
1

http://www.gpicr.com/msf.aspx

Planificacin:
Es en esta fase es cuando la mayor parte de la planeacin para el proyecto es terminada. El equipo prepara las especificaciones funcionales, realiza el proceso de diseo de la solucin, y prepara los planes de trabajo, estimaciones de costos y cronogramas de los diferentes entregables del proyecto.

Desarrollo:
Durante esta fase el equipo realice la mayor parte de la construccin de los componentes (tanto documentacin como cdigo), sin embargo, se puede realizar algn trabajo de desarrollo durante la etapa de estabilizacin en respuesta a los resultados de las pruebas. La infraestructura tambin es desarrollada durante esta fase.

Estabilizacin:
En esta fase se conducen pruebas sobre la solucin, las pruebas de esta etapa enfatizan el uso y operacin bajo condiciones realistas. El equipo se enfoca en priorizar y resolver errores y preparar la solucin para el lanzamiento.

Implantacin:
Durante esta fase el equipo implanta la tecnologa base y los componentes relacionados, estabiliza la instalacin, traspasa el proyecto al personal soporte y operaciones, y obtiene la aprobacin final del cliente.

Modelo de roles
El modelo de equipos de MSF (MSF team model) fue desarrollado para compensar algunas de las desventajas impuestas por las estructuras jerrquicas de los equipos en los proyectos tradicionales.

Los equipos organizados bajo este modelo son pequeos y multidisciplinarios, en los cuales los miembros comparten responsabilidades y balancean las destrezas del equipo para mantenerse enfocados en el proyecto que estn desarrollando. Comparten una visin comn del proyecto y se enfocan en implementar la solucin, con altos estndares de calidad y deseos de aprender.

El modelo de equipos de MSF tiene seis roles que corresponden a las metas principales de un proyecto y son responsables por las mismas. Cada rol puede estar compuestos por una o ms personas, la estructura circular del modelo, con valos del mismo tamao para todos los roles, muestra que no es un modelo jerrquico y que cada todos los roles son igualmente importantes en su aporte al proyecto. Aunque los roles pueden tener diferentes niveles de actividad durante las diversas etapas del proyecto, ninguno puede ser omitido. La comunicacin se pone en el centro del crculo para mostrar que esta integrada en la estructura y fluye en todas direcciones. El modelo apoya la comunicacin efectiva y es esencial para el funcionamiento del mismo

METODOLOGAS GILES.-

Luego de varias opiniones tanto a favor como en contra de las metodologas tradicionales se genera un nuevo enfoque denominado, mtodos giles, que nace como respuesta a los problemas detallados anteriormente y se basa en dos aspectos puntuales, el retrasar las decisiones y la planificacin adaptativa; permitiendo potenciar an ms el desarrollo de software a gran escala.

Como resultado de esta nueva teora se crea un Manifiesto gil2 cuyas principales ideas son: Los individuos y las interacciones entre ellos son ms importantes que las herramientas y los procesos empleados Es ms importante crear un producto software que funcione que escribir documentacin exhaustiva La colaboracin con el cliente debe prevalecer sobre la negociacin de contratos La capacidad de respuesta ante un cambio es ms importante que el seguimiento estricto de un plan

Entre los principales mtodos giles tenemos el XP (eXtreme Programming), Scrum, Iconix, Cristal Methods, AUP entre otras.

Estas metodologas ponen de relevancia que la capacidad de respuesta a un cambio es ms importante que el seguimiento estricto de un plan. Nos lo proponen porque para muchos clientes esta flexibilidad ser una ventaja competitiva y porque estar preparados para el cambio significar reducir su coste.

Retrasar las decisiones y Planificacin Adaptativa

Es el eje en cual gira la metodologa gil, el retrasar las decisiones tanto como sea posible de manera responsable ser ventajoso tanto para el cliente como para la empresa, lo cual permite siempre mantener una satisfaccin en el cliente y por ende el xito del producto, las principales ventajas de retrasar las decisiones son:

Reduce el nmero de decisiones de alta inversin que se toman. Reduce el nmero de cambios necesario en el proyecto.

http://www.manifiestoagile.com

Reduce el coste del cambio

La planificacin adaptativa permite estar preparados para el cambio ya que lo hemos introducido en nuestro proceso de desarrollo, adems hacer una planificacin adaptativa consiste en tomar decisiones a lo largo del proyecto, estaremos transformando el proyecto en un conjunto de proyectos pequeos.

Esta planificacin a corto plazo nos permitir tener software disponible para nuestros clientes y adems ir aprendiendo del feedback para hacer nuestra planificacin ms sensible, sea ante inconvenientes que aceleren o retrasen nuestro producto. A continuacin se detalla el XP, SCRUM, ICONIX , AUP, que son las ms aceptadas dentro de los mtodos giles

Extreme Programming (XP)

Figura 2.Esquema de trabajo XP

Es la ms destacada de los procesos giles de desarrollo de software formulada por Kent Beck. La programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad.

Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos.

Las caractersticas fundamentales del mtodo son: Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras. Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresin. Se aconseja escribir el cdigo de la prueba antes de la codificacin. Programacin por parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del cdigo escrito de esta manera el cdigo es revisado y discutido mientras se escribe- es ms importante que la posible prdida de productividad inmediata. Frecuente interaccin del equipo de programacin con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas frecuentes. Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorizacin no se ha introducido ningn fallo. 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. Las frecuentes pruebas de regresin garantizan que los posibles errores sern detectados. Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podr aadir funcionalidad si es necesario. La programacin extrema apuesta que en ms sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca utilizarlo.

La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms comunicacin resulta ms fcil identificar qu se debe y qu no se debe hacer. Mientras ms simple es el sistema, menos tendr que comunicar sobre este, lo que lleva a una comunicacin ms completa, especialmente si se puede reducir el equipo de programadores.

Ventajas
Apropiado para entornos voltiles Estar preparados para el cambio, significa reducir su coste. Planificacin ms transparente para nuestros clientes, conocen las fechas de entrega de funcionalidades vitales para su negocio Permitir definir en cada iteracin cuales son los objetivos de la siguiente Permite tener realimentacin de los usuarios muy til. La presin esta a lo largo de todo el proyecto y no en una entrega final

Desventajas
Delimitar el alcance del proyecto con nuestro cliente

Para mitigar esta desventaja se plantea definirunalcanceaaltonivelbasado en la experiencia.

Scrum

Figura 3. Esquema de trabajo SCRUM

Scrum es un proceso gil y liviano que sirve para administrar y controlar el desarrollo de software. El desarrollo se realiza en forma iterativa e incremental (una iteracin es un ciclo corto de construccin repetitivo). Cada ciclo o iteracin termina con una pieza de software ejecutable que incorpora nueva funcionalidad. Las iteraciones en general tienen una duracin entre 2 y 4 semanas. Scrum se utiliza como marco para otras prcticas de ingeniera de software como RUP o Extreme Programming. Scrum se focaliza en priorizar el trabajo en funcin del valor que tenga para el negocio, maximizando la utilidad de lo que se construye y el retorno de inversin. Est diseado especialmente para adaptarse a los cambios en los requerimientos, por ejemplo en un mercado de alta competitividad. Los requerimientos y las prioridades se revisan y ajustan durante el proyecto en intervalos muy cortos y regulares. De esta forma se puede adaptar en tiempo real el producto que se est construyendo a las necesidades del cliente. Se busca entregar software que realmente resuelva las necesidades, aumentando la satisfaccin del cliente. En Scrum, el equipo se focaliza en una nica cosa: construir software de calidad. Por el otro lado, la gestin de un proyecto Scrum se focaliza en definir cuales son las caractersticas que debe tener el producto a construir (qu construir, qu no y en qu orden) y en remover cualquier obstculo que pudiera entorpecer la tarea del equipo de desarrollo. Se busca que los equipos sean lo ms efectivos y productivos que sea posible.

Scrum tiene un conjunto de reglas muy pequeo y muy simple y est basado en los principios de inspeccin continua, adaptacin, auto-gestin e innovacin. El cliente se entusiasma y se compromete con el proyecto dado que ve crecer el producto iteracin a iteracin y encuentra las herramientas para alinear el desarrollo con los objetivos de negocio de su empresa. Por otro lado, los desarrolladores encuentran un mbito propicio para desarrollar sus capacidades profesionales y esto resulta en un incremento en la motivacin de los integrantes del equipo.

Iconix3

Figura 4. Esquema de trabajo ICONIX

El proceso de ICONIX maneja casos de uso, como el RUP, pero le falta mucho para llegar al nivel del RUP. Tambin es relativamente pequeo y firme, como XP, pero no desecha el anlisis y diseo que hace XP. Este proceso tambin hace uso aerodinmico del UML mientras guarda un enfoque afilado en el seguimiento de requisitos. Y, el proceso se queda igual a la visin original de Jacobson del manejo de casos de uso, esto produce un resultado concreto, especfico y casos de uso fcilmente entendible, que un equipo de un proyecto puede usar para conducir el esfuerzo hacia un desarrollo real. La Figura 4 muestra el cuadro del proceso. El diagrama retrata la esencia del enfoque aerodinmico al desarrollo del software, que incluye un juego mnimo de diagramas de UML y algunas valiosas tcnicas que se toman de los casos del uso para codificar rpida y eficazmente. El enfoque es flexible y abierto; siempre se puede seleccionar de los otros aspectos del UML para complementar los materiales bsicos.

Aup (Agil Unified Process)

ICONIX

Figura 4. Esquema de trabajo AUP

El Aup es un acercamiento aerodinmico a desarrollo del software basado en el Proceso Unificado Rational de IBM (RUP), basado en disciplinas y entregables incrementales con el tiempo. El ciclo de vida en proyectos grandes es serial mientras que en los pequeos es iterativo. Las disciplinas de Aup son: Modelado Implementacin Prueba Despliegue Administracin de la configuracin Administracin o gerencia del Proyecto Entorno

4. Resultado

Como resultado de la investigacin realizada y adicional el debate establecido con nuestros compaeros en clase, se pudo afianzar los puntos claves sobre los dos enfoques de las metodologas de desarrollo de software (importancia, ventajas y desventajas, entre otros). Adicional a esto se obtuvo:

La importancia y el rol fundamental que posee una metodologa dentro del desarrollo de software Capacitar al estudiante en dar respuesta a la pregunta Qu metodologa se acoge para un determinado proyecto? , valindose del entorno ya sea voltil o no Tener un enfoque general de las mtodos ms empleadas en el campo del desarrollo de software y poder describir claramente a cada una dentro del contexto

Adems ofrecer el siguiente esquema que globaliza estos dos grandes enfoques

Modelos Rigurosos
Anlisis de requerimientos Planificacin
Diseo flexible y Extensible + modelos + Documentacin exhaustiva

Modelos giles
Planificacin adpatativa:Entregas frecuentes + colaboracin del cliente

Planificacin predictiva y aislada

Diseo

Diseo Simple: Documentacin Mnima + Focalizado en la comunicacin

Desarrollo individual con Roles y responsabilidades estrictas

Codificacin

Transferencia de conocimiento: Programacin en pares + conocimiento colectivo

Pruebas
Actividades de control]: Orientado a los hitos + Gestin miniproyectos

Puesta en Produccin

Liderazgo-Colaboracion: empoderamiento +autoorganizacin

5. Consideraciones Adicionales

De acuerdo a lo tratado en este trabajo, presentamos un cuadro de comparacin por cada aspecto analizado y lo ponemos a consideracin:

Por las caractersticas del Proyecto

Modelo de Proceso RUP ICONIX XP SCRUM

Tamao del Proceso Medio / Extenso Pequeo / Medio Pequeo / Medio Pequeo / Medio

Tamao del Equipo Medio / Extenso Pequeo / Medio Pequeo Pequeo

Complejidad del Problema Medio / Alto Pequeo / Medio Medio / Alto Medio / Alto

En este cuadro se presenta una comparativa de las modelos de proceso en cuanto a las caractersticas del proyecto, analizamos el tamao del proceso, del equipo y la complejidad del problema para cada uno de los modelos. Podemos resaltar que: con un pequeo equipo de desarrollo se puede realizar grandes proyectos, de alta complejidad; es el caso de XP y SCRUM.

Por la curva de aprendizaje

Modelo de Proceso RUP ICONIX XP SCRUM

Curva de aprendizaje Lenta Rpida Rpida Rpida

Herramienta de integracin Alto Soporte Algn Soporte Disponible No mencionado No mencionado

Soporte Externo Alto Soporte Algn Soporte Disponible Algn Soporte Disponible Algn Soporte Disponible

Con respecto a la curva de aprendizaje, vemos que los modelos giles, nos ofrecen una mayor ventaja pero con ciertas limitaciones, ya que aun no hay sido explotadas a gran escala como lo es RUP que posee alto soporte y herramientas integrales que nos guan a travs del mismo, facilitando aplicar con mayor efectividad esta metodologa, permitiendo aprovecharla al mximo

6. Conclusiones

El retrasar las decisiones en un proyecto de software permite potenciar el valor del producto tanto para el cliente como al equipo o empresa que desarrolla Para que un grupo de desarrollo adopte una metodologa gil debe poseer experiencia trabajando con metodologas tradicionales, ya que la experiencia es la que predomina en los momentos cruciales del proyecto, adems debe tener la capacidad de ser equipos autogestionados , altamente motivados y con gran innovacin

Las metodologas giles permiten disminuir costos y brindar flexibilidad a los proyectos de software donde la incertidumbre est presente El uso de metodologas tradicionales es esencial al inicio en un equipo de desarrollo de software

La metodologas giles se deberan aplicar en proyectos donde exista mucha incertidumbre, donde el entorno es voltil, cuando los requisitos no se conocen con exactitud, mientras que las metodologas tradicionales obligan al cliente a tomar las decisiones al inicio del proyecto

7. Referencias

[1] Metodologas giles: La ventaja competitiva de estar preparado para tomar decisiones lo ms tarde posible y cambiarlas en cualquier momento. (En lnea), Disponible en: www.spinec.org/wpcontent/metodologiasagiles_01.pdf

[2] Metodologas giles (En lnea) ,Disponible en: http://www.agile-spain.com [3] ICONIX (En lnea), Disponible en: www.spinec.org/wp-content/ICONIX.pdf [4] Extreme Programming Refactored: The Case Against XP, MATT Stephens and DOUG Rosenberg, Disponible en Formato chm [5] Introduccin a Iconix (En lnea), Disponible en: http://www.informit.com/articles/article.asp?p=167902&rl=1