METODOLOGAS DE DESARROLLO DE SOFTWARE

Un proceso de software detallado y completo suele denominarse Metodologa. Las metodologas se basan en una combinacin de los modelos de proceso genricos (cascada, evolutivo, incremental, etc.). Adicionalmente una metodologa debera definir con precisin los artefactos, roles y actividades involucrados, junto con prcticas y tcnicas recomendadas, guas de adaptacin de la metodologa al proyecto, guas para uso de herramientas de apoyo, etc. Habitualmente se utiliza el trmino mtodo para referirse a tcnicas, notaciones y guas asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de mtodos de anlisis y/o diseo.

La comparacin y/o clasificacin de metodologas no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, informacin disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de anlisis y diseo, podemos clasificar las metodologas en dos grupos: Metodologas Estructuradas y Metodologas Orientadas a Objetos. Por otra parte, considerando su filosofa de desarrollo, aquellas metodologas con mayor nfasis en la planificacin y control del proyecto, en especificacin precisa de requisitos y modelado, reciben el apelativo de Metodologas Tradicionales (o peyorativamente denominada Metodologas Pesadas, o Peso Pesado). Otras metodologas, denominadas Metodologas giles, estn ms orientadas a la generacin de cdigo con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeos, hacen especial hincapi en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso.Clasificacin de las Metodologas de Desarrollo de SoftwareMetodologas estructuradas

Los mtodos estructurados comenzaron a desarrollarse a fines de los 70s con la Programacin Estructurada, luego a mediados de los 70s aparecieron tcnicas para el Diseo (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Anlisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologas son particularmente apropiadas en proyectos que utilizan para la implementacin lenguajes de 3ra y 4ta generacin.Ejemplos de metodologas estructuradas de mbito gubernamental: MERISE (Francia), MTRICA (Espaa), SSADM (Reino Unido). Ejemplos de propuestas de mtodos estructurados en el mbito acadmico: Gane & Sarson , Ward & Mellor , Yourdon & DeMarco e Information Engineering .

Metodologas orientadas a objetos

Su historia va unida a la evolucin de los lenguajes de programacin orientada a objeto, los ms representativos: a fines de los 60s SIMULA, a fines de los 70s Smalltalk-80, la primera versin de C++ por Bjarne Stroustrup en 1981 y actualmente Java o C# de Microsoft. A fines de los 80s comenzaron a consolidarse algunos mtodos Orientadas a Objeto.En 1995 Booch y Rumbaugh proponen el Mtodo Unificado con la ambiciosa idea de conseguir una unificacin de sus mtodos y notaciones, que posteriormente se reorienta a un objetivo ms modesto, para dar lugar al Unified Modeling Language (UML) , la notacin OO ms popular en la actualidad.Algunos mtodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh).Algunas metodologas orientadas a objetos que utilizan la notacin UML son: Rational Unified Process (RUP), OPEN, MTRICA (que tambin soporta la notacin estructurada).

Metodologas tradicionales (no giles)

Las metodologas no giles son aquellas que estn guiadas por una fuerte planificacin durante todo el proceso de desarrollo; llamadas tambin metodologas tradicionales o clsicas, donde se realiza una intensa etapa de anlisis y diseo antes de la construccin del sistema.

Todas las propuestas metodolgicas antes indicadas pueden considerarse como metodologas tradicionales. Aunque en el caso particular de RUP, por el especial nfasis que presenta en cuanto a su adaptacin a las condiciones del proyecto (mediante su configuracin previa a aplicarse), realizando una configuracin adecuada, podra considerarse gil.

Metodologas giles

Un proceso es gil cuando el desarrollo de software es incremental (entregas pequeas de software, con ciclos rpidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicacin), sencillo (el mtodo en s mismo es fcil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de ltimo momento).Entre las metodologas giles identificadas en: Extreme Programming y scrum

METODOLOGAS TRADICIONALES, PESADAS O NO GILES DE DESARROLLO DE SOFTWARE

Teniendo en cuenta la filosofa de desarrollo de las metodologas, aquellas con mayor nfasis en la planificacin y control del proyecto, en especificacin precisa de requisitos y modelado, reciben el apelativo de Metodologas Tradicionales o Pesadas.

Estas metodologas tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software ms eficiente. Para ello, se hace nfasis en la planificacin total de todo el trabajo a realizar y una vez que est todo detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente en el control del proceso, mediante una rigurosa definicin de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentacin detallada. Adems, las metodologas tradicionales no se adaptan adecuadamente a los cambios, por lo que no son mtodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden predecirse o bien pueden variar.Entre las metodologas tradicionales o pesadas podemos citar:

RUP (Rational Unified Procces)

MSF (Microsoft Solution Framework)

Win-Win Spiral Model

Iconix Caractersticas Rigidez ante los cambios, de manera lentos o moderada

Los clientes interactan con el equipo de desarrollo mediante reuniones

Grupos de gran tamao y varias veces distribuidos en diferentes sitios

Dependencia de la arquitectura de software mediante modelos

Poco Feedback lo que extiende el tiempo de entrega

Mnimos roles

Basadas en normas de estndares de desarrollo

Procesos muy controlados por polticas y normas

Seguimiento estricto del plan inicial de desarrollo

METODOLOGA DE DESARROLLO:RUP

Una de las metodologas pesadas ms conocidas y utilizadas es CC: Inicio: El objetivo es determinar la visin del proyecto y definir lo que se desea realizar. Elaboracin: Etapa en la que se determina la arquitectura ptima del proyecto. Construccin: Se obtiene la capacidad operacional inicial. Transmisin: Obtener el producto acabado y definido.Filosofa RUPLa metodologa RUP tiene 6 principios claves: Adaptacin del proceso: El proceso debe adaptarse a las caractersticas de la organizacin para la que se est desarrollando el software. Balancear prioridades: Debe encontrarse un balance que satisfaga a todos los inversores del proyecto. Colaboracin entre equipos: Debe haber una comunicacin fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc.,... Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de una forma interna, en etapas iteradas. En cada iteracin se evaluar la calidad y estabilidad del producto y analizar la opinin y sugerencias de los inversores. Elevar el nivel de abstraccin: Motivar el uso de conceptos reutilizables. Enfocarse en la calidad: La calidad del producto debe verificarse en cada aspecto de la produccin.Disciplina de Desarrollo de RUP

Determina las etapas a realizar durante el proyecto de creacin delsoftware. Ingeniera o modelado del negocio: Analizar y entender las necesidades del negocio para el cual se est desarrollando el software. Requisitos: Proveer una base para estimar los costos y tiempo de desarrollo del sistema. Anlisis y diseo: Trasladar los requisitos analizados anteriormente a un sistema automatizado y desarrollar una arquitectura para el sistema. Implementacin: Crear software que se ajuste a la arquitectura diseada y que tenga el comportamiento deseado. Pruebas: Asegurarse de que el comportamiento requerido es correcto y que todo lo solicitado est presente. Despliegue: Producir distribuciones del producto y distribuirlo a los usuarios.

Disciplina de Soporte RUP

Determina la documentacin que es necesaria realizar durante elproyecto. Configuracin y administracin del cambio: Guardar todas las versiones del proyecto. Administracin del proyecto: Administrar los horarios y recursos que se deben de emplear. Ambiente: Administrar el ambiente de desarrollo del software. Distribucin: Hacer todo lo necesario para la salida del proyecto.

Elementos del RUP

Actividades: Procesos que se han de realizar en cada etapa/iteracin. Trabajadores: Personas involucradas en cada actividad del proyecto. Artefactos: Herramientas empleadas para el desarrollo del proyecto.Puede ser un documento, un modelo, un elemento del modelo, etc.,..METODOLOGAS GILES O LIGERAS

Introduccin

En la dcada de los noventa surgieron metodologas de desarrollo de software ligeras, ms adelante nombradas como metodologas giles, que buscaban reducir la probabilidadde fracaso por subestimacin de costos, tiemposy funcionalidades en los proyectos de desarrollo de software. Estas metodologas nacieron como reaccin a las metodologas existentes con el propsito de disminuir la burocracia que implica la aplicacin de las metodologas tradicionales en los proyectos de pequea y mediana escala.Las metodologas giles son adaptativas. Este hecho es de gran importancia ya que contrasta con la predictibilidad buscada por las metodologas tradicionales. Con el enfoquede las metodologas giles los cambios son eventos esperados que generan valor para el cliente.

Un modelo de desarrollo gil, generalmente es un proceso Incremental, (pequeos y frecuentes releaseso entregas con ciclos rpidos), tambin Cooperativo (Clientes y desarrolladores trabajan constantementecon una comunicacin muy fina y constante), sencillo (El mtodo es fcil de aprender y modificar para elequipo, es bien documentado por medio de libros o la Web) y finalmente adaptativo (capaz de permitircambios de ltimo momento).Las metodologas giles proporcionan una serie de pautas y principios junto a tcnicas pragmticas quepuede que no curen todos los males pero harn la entrega del proyecto menos complicada y mssatisfactoria tanto para los clientes como para los equipos de entrega.

Metodologa gil

Las metodologas giles son flexibles, pueden ser modificadaspara que se ajusten a la realidad de cada equipo y proyecto.Los proyectos giles se subdividen en proyectos ms pequeosmediante una lista ordenada de caractersticas. Cada proyecto es tratado de manera independiente y desarrolla un subconjunto de caractersticas durante un periodo de tiempo corto, de entre dos y seis semanas. La comunicacin con el cliente es constante al punto de requerirun representante de l durante el desarrollo. Los proyectos son altamente colaborativos y se adaptan mejor a los cambios; de hecho, el cambio en los requerimientos es una caracterstica esperada y deseada, al igual que las entregas constantes al cliente y la retroalimentacin por parte de l. Tanto el producto como el proceso son mejorados frecuentemente.Principales ideas de la metodologa gil:

Se encarga de valorar al individuo y las iteraciones del equipo msque a las herramientas o los procesos utilizados. Se hace mucho ms importante crear un producto software quefuncione que escribir mucha documentacin. El cliente est en todo momento colaborando en el proyecto. Es ms importante la capacidad de respuesta ante un cambiorealizado que el seguimiento estricto de un plan.Comparacin entre metodologas

La tabla 1 muestra aspectos relevantes de las metodologasde desarrollo tradicional contrastndolas con los aspectosrelevantes de las metodologas de desarrollo gil.

Tabla 1. Metodologas tradiciones vs metodologas giles

Metodologas tradicionalesMetodologas giles

PredictivosAdaptativos

Orientados a procesosOrientados a personas

Proceso rgidoProceso flexible

Se concibe como un proyectoUn proyecto es subdividido en varios proyectos ms pequeos

Poca comunicacin con el clienteComunicacin constante con el cliente

Entrega de software al finalizar el desarrolloEntregas constantes de software

Documentacin extensaPoca documentacin

Manifiesto por el desarrollo gil

Las metodologas giles son flexibles, sus proyectos son subdivididos en proyectos ms pequeos, incluyen comunicacinconstante con el cliente, son altamente colaborativosy se adaptan mejor a los cambios. De hecho, el cambio en los requerimientos es una caracterstica esperadaal igual que las entregas constantes al cliente y la retroalimentacinpor parte de l. Tanto el producto como el proceso son mejorados frecuentemente.

En 2001 se crea el Manifiesto por el desarrollo gil de software, documento en el que se acuerdan cuatro principios bsicos para el desarrollo de software, que establece prioridades y marca diferencias de fondo frente a los sistemas tradicionales:individuos e interacciones, por encima de procesosy herramientas; software funcionando, por encimade documentacin extensiva; colaboracin con el cliente, por encima de negociacin contractual; y respuesta ante el cambio, por encima de seguir un plan.El Manifiesto comienza enumerando los principales valores del desarrollo gil. Se valora: Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de xito de un proyecto software. Si se sigue un buen proceso de desarrollo, pero el equipo falla, el xito no est asegurado; sin embargo, si el equipo funciona, es ms fcil conseguir el objetivo final, aunque no se tenga un proceso bien definido. No se necesitan desarrolladores brillantes, sino desarrolladores que se adapten bien al trabajo en equipo. As mismo, las herramientas (compiladores, depuradores, control de versiones, etc.) son importantes para mejorar el rendimiento del equipo, pero el disponer ms recursos que los estrictamente necesarios tambin puede afectar negativamente. En resumen, es ms importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automticamente. Es mejor crear el equipo y que ste configure su propio entorno de desarrollo en base a sus necesidades. Desarrollar software que funciona ms que conseguir una buena documentacin. Aunque se parte de la base de que el software sin documentacin es un desastre, la regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisin importante. Estos documentos deben ser cortos y centrarse en lo fundamental. Si una vez iniciado el proyecto, un nuevo miembro se incorpora al equipo de desarrollo, se considera que los dos elementos que ms le van a servir para ponerse al da son: el propio cdigo y la interaccin con el equipo. La colaboracin con el cliente ms que la negociacin de un contrato. Las caractersticas particulares del desarrollo de software hace que muchos proyectos hayan fracasado por intentar cumplir unos plazos y unos costes preestablecidos al inicio del mismo, segn los requisitos que el cliente manifestaba en ese momento. Por ello, se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su xito. Responder a los cambios ms que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta puesto que hay muchas variables en juego, debe ser flexible para poder adaptarse a los cambios que puedan surgir. Una buena estrategia es hacer planificaciones detalladas para unas pocas semanas y planificaciones mucho ms abiertas para unos pocos meses.El manifiesto por el desarrollo gil de software es el resultadodel trabajo colaborativo de un grupo formado por diecisiete personas, entre desarrolladores de software, escritoresy consultores, quienes lo construyeron y suscribieronen 2001. La firma y publicacin del Manifiesto en ese ao no implica que esa sea la fecha de origen de las metodologas giles o que antes de ese ao no existieran, sino el reconocimiento de la necesidad y la expresin de un lineamiento comn capaz de hacer posible algn tipo de agrupacin entre ellas.

Las metodologas giles se caracterizan por el desarrollo iterativo e incremental; la simplicidad de la implementacin;las entregas frecuentes; la priorizacin de los requerimientoso caractersticas a desarrollar a cargo del cliente; y la cooperacin entre desarrolladores y clientes. Las metodologasgiles dan como un hecho que los requerimientosvan a cambiar durante el proceso de desarrollo.

Metodologas giles ms destacadas

Entre las metodologas giles ms destacadas hasta el momento se pueden nombrar: XP (Extreme Programming) Scrum Crystal Clear DSDM (Dynamic Systems Developmemt Method) FDD (Feature Driven Development) ASD (Adaptive Software Development) XBreed Extreme Modeling

SELECCIN DE METODOLOGASGILES O LIGERAS

Seleccin de Metodologas

Una primera seleccin surge del manifiesto: Scrum, ExtremeProgramming [XP], Dynamic System Development Method [DSDM], Crystal, Adaptative Software Development [ASD] y Feature- Driven Development [FDD], estn representadas en l, a travs de al menos una de las personas que lo suscribieron.

Otra aproximacin para definir las metodologas giles ms relevantes consiste en revisar las que han sido citadas y explicadas en libros de ingeniera de software. Al respecto, Sommerville indica que las metodologas giles ms conocidas son XP, Scrum, Crystal, ASD, DSDM y FDD, mientras que Pressman centra su trabajo en la explicacindel funcionamiento de XP, DSDM, ASD, Scrum, FDD y Agile Modelling [AM].

Una revisin de las investigaciones, revisiones e implementacionesreferenciadas por asociaciones como IEEE y ACM, arroja un tercer parmetro. Las metodologas ms populares en los documentos cientficos entre el 2003 y el 2007 fueron XP y Scrum. Sin embargo, cabe aclarar que la mayora de lo que se public no est relacionado con una metodologa en particular, sino con el concepto de metodologas giles en general; de hecho, el eje comn a los temas tratados con mayor frecuencia es la presentacinde experiencias exitosas de implantacin.

Otro criterio de seleccin es el reconocimiento de la alta adopcin en la industria de desarrollo de software en los ltimos aos. Segn la sptima versin de la encuesta anual del estado del desarrollo de software usando metodologasgiles, el tamao promedio de las organizaciones es de 100 empleados. De quienes contestaron la encuesta, el 84% dijo que en sus compaas se practican las metodologasgiles, lo que en algunos casos se ha venido haciendopor ms de 5 aos.

La tendencia de definir a XP y a Scrum como los mtodos de desarrollo gil ms relevantes es notoria, as se evidenciaen los trabajos de Jiang y Eberlein, Thorstein, Hannay, Pfahl, Benestad, y Langtangen, Silva, Selbach, Maurer, y Hellmann, Maurer y Hellmann, Vijayasarathyy Turk, Hoda, Kruchten, Noble, y Marshal y Szke, as como en encuestas hechas por importantesproveedores de software para la gestin de este tipo de metodologas. Thorstein et l incluso listan todas las prcticas giles existentes, tomando en cuenta solamente XP y Scrum.

La mayora de equipos giles exitosos han adaptado prcticasgiles de distintas metodologas para generar un procesode desarrollo propio que se ajusta a sus necesidades. Estas adaptaciones parecen estar centradas en mezclasde Scrum con XP. XP se enfoca en prcticas de desarrollo mientras que Scrum apunta a la administracin de proyectos.Metodologas giles Representativas

Scrum

Su nombre no corresponde a una sigla, sino a un concepto deportivo, propio del rugby, relacionado con la formacin requerida para la recuperacin rpida del juego ante una infraccin menor. Su primera referencia en el contextode desarrollo data de 1986, cuando Takeuchi y Nonaka utilizan el Rugby Approach para definir un nuevo enfoque en el desarrollo de productos, dirigido a incrementar su flexibilidad y rapidez, a partir de la integracin de untraslapanentre s.La metodologa Scrum para el desarrollo gil de software es un marco de trabajo diseado para lograr la colaboracineficaz de equipos en proyectos, que emplea un conjuntode reglas y artefactos y define roles que generan la estructura necesaria para su correcto funcionamiento.

Scrum utiliza un enfoque incremental que tiene como fundamentola teora de control emprico de procesos. Esta teora se fundamenta en transparencia, inspeccin y adaptacin;la transparencia, que garantiza la visibilidad en el proceso de las cosas que pueden afectar el resultado; la inspeccin, que ayuda a detectar variaciones indeseables en el proceso; y la adaptacin, que realiza los ajustes pertinentespara minimizar el impacto de las mismas.

Los llamados Equipos Scrum son auto-gestionados, multifuncionales y trabajan en iteraciones. La autogestin les permite elegir la mejor forma de hacer el trabajo, en vez de tener que seguir lineamientos de personas que no pertenecenal equipo y carecen de contexto. Los integrantes del equipo tienen todos los conocimientos necesarios (por ser multifuncionales) para llevar a cabo el trabajo. La entregadel producto se hace en iteraciones; cada iteracin crea nuevas funcionalidades o modifica las que el dueo del producto requiera.

Scrum define tres roles: el Scrum master, el dueo del productoy el equipo de desarrollo. El Scrum master tiene como funcin asegurar que el equipo est adoptando la metodologa, sus prcticas, valores y normas; es el lder del equipo pero no gestiona el desarrollo. El dueo del producto es una sola persona y representa a los interesados,es el responsable de maximizar el valor del productoy el trabajo del equipo de desarrollo; tiene entre sus funciones gestionar la lista ordenada de funcionalidades requeridas o Product Backlog. El equipo de desarrollo, por su parte, tiene como responsabilidad convertir lo que el cliente quiere, el Product Backlog, en iteraciones funcionales del producto; el equipo de desarrollo no tiene jerarquas,todos sus miembros tienen el mismo nivel y cargo: desarrollador. El tamao ptimo del equipo est entre tres y nueve personas.

Scrum define un evento principal o Sprint (Figura 1) que corresponde a una ventana de tiempo donde se crea una versin utilizable del producto (incremento). Cada Sprint, como en el rugby, es considerado como un proyecto independiente.Su duracin mxima es de un mes. Un Sprint se compone de los siguientes elementos: reunin de planeacin del Sprint, Daily Scrum, trabajo de desarrollo, revisindel Sprint y retrospectiva del Sprint.

En la reunin de Planeacin del Sprint se define su plan de trabajo: qu se va a entregar y cmo se lograr. Es decir, el diseo del sistema y la estimacin de cantidad de trabajo. Esta actividad dura ocho horas para un Sprint de un mes. Si el Sprint tiene una duracin menor, se asigna el tiempo de manera proporcional.

El Daily Scrum es un evento del equipo de desarrollo de quince minutos, que se realiza cada da con el fin de explicarlo que se ha alcanzado desde la ltima reunin; lo que se har antes de la siguiente; y los obstculos que se han presentado. Este evento se desarrolla mediante una reunin que normalmente es sostenida de pie con los participantesreunidos formando un crculo, esto, para evitar que la discusin se extienda.

La Revisin del Sprint ocurre al final del Sprint y su duracines de cuatro horas para un proyecto de un mes (o una proporcin de ese tiempo si la duracin es menor). En esta etapa: el dueo del proyecto revisa lo que se hizo, identifica lo que no se hizo y discute acerca del Product Backlog; el equipo de desarrollo cuenta los problemas que encontr y la manera en que fueron resueltos, y muestra el producto y su funcionamiento. Esta reunin es de gran importancia para los siguientes Sprints.

Figura 1: Metodologa Scrum: Fases de un Sprint

La Retrospectiva del Sprint es una reunin de tres horas del equipo Scrum en la que se analiza cmo fue la comunicacin,el proceso y las herramientas; qu estuvo bien, qu no, y se crea un plan de mejoras para el siguiente Sprint. El tiempo, tal como en los casos anteriores, se debe ajustar proporcionalmente en el caso de proyectos de duracin menor a un mes.

Existen tambin Artefactos de Scrum. Estos son subproductosde las actividades del marco de trabajo que le brindan direccin y transparencia al equipo. Los artefactos de Scrum son: Product Backlog, Sprint Backlog, Monitoreo de Progreso e Incremento.

El Product Backlog es una lista ordenada por valor, riesgo, prioridad y necesidad de los requerimientos que el dueodel producto define, actualiza y ordena. La lista tiene como caracterstica particular que nunca est terminada, pues evoluciona durante el desarrollo del proyecto.

El Sprint Backlog es un subconjunto de tems del Product Backlog y el plan para realizar en el Incremento del producto.Debido a que el Productbacklog est organizado por prioridad, el Sprint backlog es construido con los requerimientos ms prioritarios del Product backlog y con aquellos que quedaron por resolver en el Sprint anterior. Una vez construido, el Sprint backlog debe ser aceptado por el equipo de desarrollo, pertenece a ste y solo puede ser modificado por l. Requerimientos adicionales deben ser incluidos en el Product backlog y desarrollados en el siguiente Sprint, si su prioridad as lo indica.

El Monitoreo de Progreso consiste en la suma del trabajo que falta por realizar en el Sprint. Tiene como caracterstica que se puede dar en cualquier momento, lo que le permite al dueo del producto evaluar el progreso del desarrollo. Para que esto sea posible, los integrantes del equipo actualizanconstantemente el estado de los requerimientos que tienen asignados indicando cunto consideran que les falta por terminar.

El Incremento es la suma de todos los tems terminados en el Sprint backlog. Si hay tems incompletos deben ser devueltos al Productbacklog con una prioridad alta para que sean incluidos en el siguiente Sprint. Se considera que un tem est terminado si es funcional. La suma de tems terminados es el producto a entregar.

El ciclo de vida de este marco de trabajo est compuesto de cuatro fases: planeacin, puesta en escena, desarrollo y entrega. En la planeacin se establece la visin, se fijan las expectativas y se asegura el financiamiento. En la puesta en escena se identifican ms requerimientos y se priorizan para la primera iteracin. En la implementacin se desarrolla el sistema, y en la entrega se hace el despliegue operativo.

Crystal

La familia de metodologas Crystal se basa en los conceptos de Rational Unified Process [RUP] y est compuesta por Crystal Clear, Crystal Yellow, Crystal Orange y Crystal Red; el nivel de opacidad del color en el nombre indicaun mayor nmero de personas implicadas en el desarrollo,un mayor tamao del proyecto y, por lo tanto, la necesidad de mayor control en el proceso.

La filosofa de Crystal define el desarrollo como un juego cooperativo de invencin y comunicacin cuya meta principales entregar software til, que funcione, y su objetivo secundario, preparar el prximo juego.

Los valores compartidos por los miembros de la familia Crystal estn centrados en las personas y en la comunicacin.Sus principios indican que: el equipo puede reducir trabajo intermedio en la medida que produce cdigo con mayor frecuencia y utiliza mejores canales de comunicacinentre las personas; los proyectos evolucionan distinto con el tiempo por lo que las convenciones que el equipo adopta tienen que adecuarse y evolucionar; los cambios en el cuello de botella del sistema determinan el uso de trabajorepetido; y el afinamiento se realiza sobre la marcha.

Existen dos reglas que aplican para toda la familia Crystal. La primera indica que los ciclos donde se crean los incrementosno deben exceder cuatro meses; la segunda, que es necesario realizar un taller de reflexin despus de cada entrega para afinar la metodologa. Mtodo de desarrollo de sistemas dinmicos (Dynamic Systems Development Method - DSDM)

DSDM es un marco de trabajo creado para entregar la solucincorrecta en el momento correcto. Utiliza un ciclo de vida iterativo, fragmenta el proyecto en periodos cortosde tiempo y define entregables para cada uno de estos periodos. Tiene roles claramente definidos y especifica su trabajo dentro de periodos de tiempo.

El Consorcio DSDM es el responsable del mantenimientode esta metodologa. Su versin actual es DSDM Atern. Los principios de DSDM son: la necesidad del negocio como eje central; las entregas a tiempo; la colaboracin; nunca comprometer la calidad; construir de modo incrementalsobre una base slida; el desarrollo iterativo; la comunicacinclara y continua; y la demostracin de control.

Desarrollo adaptativo de software (Adaptative Software Development - ASD)

ASD tiene como fundamento la teora de sistemas adaptativoscomplejos. Por ello, interpreta los proyectos de softwarecomo sistemas adaptativos complejos compuestos por agentes los interesados, entornos organizacional, tecnolgico y salidas el producto desarrollado.

El ciclo de vida de ASD est orientado al cambio y se componede las fases: especulacin, colaboracin y aprendizaje. Estas fases se caracterizan por estar enfocadas en la misin, estar basadas en caractersticas, ser iterativas, tener marcos de tiempo especificados, ser orientadas por los riesgos y ser tolerantes a los cambios.

Desarrollo orientado a funcionalidades (Feature-DrivenDevelopment - FDD)

FDD tiene como rasgo caracterstico la planeacin y el diseopor adelantado. En consecuencia, el modelo de objetos,la lista de caractersticas y la planeacin se hacen al inicio del proyecto. Las iteraciones son incrementos con caractersticas identificadas.

Las prcticas que FDD pregona son: el modelado de objetos de dominio (domainobjectmodeling), el desarrollo por caractersticas, Class (code) ownership, los equipos de caractersticas o Feature Teams, las inspecciones, la construccin regular de planificacin (Regular Build Schedule), la gestin de configuraciny los reportes y visibilidad de los resultados.

Su ciclo de vida est compuesto por cinco etapas: el desarrollode un modelo general, la construccin de la lista de caractersticas, la planeacin por caracterstica, el diseo por caracterstica y la construccin por caracterstica.

FDD se enfoca en las fases de diseo diseo por caractersticay desarrollo construccin por caracterstica siendoestas las etapas del proceso que se iteran.

METODOLOGA GIL: XP

Extreme Programming [XP]XP es la metodologa gil ms conocida. Fue desarrolladapor Kent Beck buscando guiar equipos de desarrollode software pequeos o medianos, entre dos y diez desarrolladores, en ambientes de requerimientos imprecisoso cambiantes. XP tiene como base cinco valores: Simplicidad, Comunicacin, Retroalimentacin, Respeto y Coraje.Estos valores, a su vez, son la base para la definicin de sus principios. De ellos, los fundamentales son: la retroalimentacinrpida, asumir simplicidad, el cambio incremental, la aceptacin del cambio y el trabajo de calidad.Las prcticas de esta metodologa se derivan de sus valoresy principios y estn enfocadas en darle solucin a las actividades bsicas de un proceso de desarrollo, esto es: escribir cdigo, realizar pruebas, escuchar (planear) y disear.Las prcticas de XP incluyen: planninggame, pequeas entregas,diseo simple, programacin en pareja, pruebas, refactoring, integracin continua, propiedad comn del cdigo, paso sostenible, cliente en sitio, metfora y estndaresde cdigo.PlanningGame define el alcance y la fecha de cumplimientode una entrega funcional completa es decir, la fecha de entrega de un release que pueda ser puesto en funcionamiento y divide las responsabilidades entre el cliente y los desarrolladores. El cliente define, utilizando Historias de Usuario, una versin simplificada de los tradicionales Casos de Uso, los requerimientos de manera general, y precisasu importancia; Con base en ellas, los desarrolladores estiman el costo de implementarlas y se definen las caractersticasde una entrega y el nmero de iteraciones que se necesitarn para terminarla. Para cada iteracin el cliente define cules de las historias de usuario que componen la entrega funcional desea que se desarrollen. Se pueden crear o modificar historias de usuario en cualquier momentoexcepto cuando forman parte de una iteracin en curso.Entregas Pequeas se refiere al uso de ciclos cortos de desarrollo(iteraciones) que le muestran software terminado al cliente y obtienen retroalimentacin de l. La definicin de terminado est relacionada con la pruebas de aceptacin.Diseo Simple indica que el sistema debe ser tan simple como sea posible, en un momento determinado, lo cual implica que los desarrolladores deben preocuparse nicamentepor las historias de usuario planeadas para la iteracin actual, sin importar cuanto pueden cambiar por funciones futuras.

Programacin en pareja indica que todo el cdigo debe ser desarrollado por dos programadores. Las parejas deben cambiar con cierta frecuencia para que el conocimiento de todo el sistema quede en todo el equipo, una prctica que fortalece los principios de diseo simple, calidad y propiedadcolectiva del cdigo.Las Pruebas son la gua del desarrollo del producto ya que los detalles de las historias de usuario (i.e., requerimientos especficos) se obtienen en el desarrollo de la prueba de aceptacin. Las pruebas son lo primero que se desarrolla; con base en ellas, se desarrolla el cdigo que las satisfaga. A este concepto se le denomina Desarrollo orientado a las pruebas.Refactoring consiste en realizar cambios que mejoren la estructuradel sistema sin afectar su funcionamiento. Para garantizar la no afectacin, despus de cada cambio se corre la prueba unitaria, con el fin de corroborar sus beneficios.Esta prctica ayuda a mantener el cdigo simple.Integracin contina, establece que cada tarea que se completase integra al sistema, un proceso que puede darse, incluso, varias veces al da. Con cada tarea que se integraal sistema se corren las pruebas unitarias, las cuales validan si lo que ha sido agregado no perjudica las funcionalidadesexistentes. En ocasiones las pruebas unitarias fallan y es responsabilidad del desarrollador o de la parejaque integr el cdigo arreglarlo. Es comn encontrar una regla en los proyectos XP que evita que un desarrolladoro pareja se enfoque en otra cosa distinta a arreglar los errores que surgieron de la integracin de su cdigo con el del sistema. Esta regla va acompaada de otra que evita que otras partes de cdigo sean integradas en el sistema mientras no hayan superado exitosamente las pruebas. Esto pone un poco ms de presin en aquellos desarrolladorescuyo cdigo fue incapaz de superar las pruebas.Propiedad comn del cdigo implica que no hay una persona propietaria del cdigo que se est desarrollando o de una porcin del mismo, por lo que cualquier desarrollador que est participando en una iteracin puede hacer cambios en el cdigo, siempre que le agregue valor al sistema.Paso sostenible hace referencia al ritmo de trabajo del equipo.Indica que debe ser adecuado para que sea factible terminarla iteracin o la entrega sin trabajar horas extras. La metodologa establece adems que nunca se debe trabajar horas extras dos semanas consecutivas.Cliente en sitio se refiere a la necesidad de incluir un representantedel cliente trabajando a tiempo completo con el equipo de desarrollo. Su funcin es resolver oportunamentedudas en la implementacin de las historias de usuario.Metfora establece que todos los implicados en el proyectodeben tener la misma visin del sistema. Para lograrlo deben hacer abstracciones que establezcan un lenguaje comnentre el cliente y los desarrolladores. La metfora es la gua global del desarrollo.

Estndares de cdigo son las reglas que definen como se va a escribir la aplicacin. La metodologa establece que estos estndares deben estar definidos de tal forma que el cdigoen s mismo sirva como un documento. Este tema es de altsima relevancia porque tanto la programacin en pareja, como la propiedad comn del cdigo, son imposiblessin estos estndares.El ciclo de vida de esta metodologa, por su parte, est compuesto por Exploracin, Planeacin, Iteraciones hacia la primera entrega, Productionizing y Mantenimiento.En la fase de Exploracin se hace una estimacin con base en las historias de usuario requeridas para la primera entrega;en la de Planeacin, el cliente y los programadores definen las historias de usuario que se van a implementar y sus fechas; Iteraciones hacia la Primera Entrega, por su parte,se transforma en el calendario acordado con el cliente, expresado en iteraciones, donde cada una de ellas representahistorias de usuario implementadas y probadas; en Productionizing se afina el funcionamiento del programa y se despliega; y en Mantenimiento se continan realizando mejoras y arreglos, e implementando nuevas funcionalidades.En 2004 se public una versin revisada de XP en la que se modifican los principios y las prcticas. Los nuevos principios hacen ms directa la asociacin de los valores con las prcticas. Las nuevas prcticas se subdividen en dos categoras: primarias, las de mayor impacto y por lo tanto las primeras que deberan ser implementadas; y coralarias,las ms difciles de implementar y por ello las que deberan adoptarse despus de haber adoptado las primarias.Esta versin, sin embargo, no ha tenido gran acogida y la mayora de los autores siguen tomando como referenciala versin original.

Conclusiones

Las metodologas giles funcionan bien dentro de un contextoespecfico caracterizado por equipos pequeos de desarrollo, ubicados en el mismo sitio, con clientes que pueden tomar decisiones acerca de los requerimientos y su evolucin, con requerimientos que cambian con frecuencia(semanal, mensual), con alcance del proyecto o presupuesto variable, con pocas restricciones legales y con pocas restricciones en el proceso de desarrollo. Por fuera de este ambiente, es comn que se presenten inconvenientesderivados de la falta de participacin del cliente, los contratos con precio fijo, los proyectos con arquitectura o diseo intensivo o con documentacin intensiva, la tasa de cambios lenta y los equipos distribuidos.

El papel del cliente es ms notorio en el proceso de desarrollode las metodologas giles; uno de los principios del Manifiesto dice que los responsables de negocio y los desarrolladorestrabajan juntos de manera cotidiana durante todo el proyecto. Esta condicin no es fcil de satisfacer.Los clientes pueden estar separados geogrficamente o puede ser muy costoso para ellos mantener un representante con la capacidad de responder por la totalidad de losrequerimientos del sistema que se est desarrollando, de manera permanente.

Para resolver estas limitantes es posible utilizar varias estrategias.La primera, tener mltiples dueos de historias de usuario. Con esto se busca no inhabilitar a un cliente durante todo el desarrollo. Al tener cada historia de usuariosu dueo, una vez que esta termina, la siguiente se trata como una historia de usuario con un dueo distinto. La segunda estrategia consiste en nombrar un intermediario del cliente, lo que involucra a un desarrollador del equipo que coordina de manera conjunta los requerimientos.

Otra dificultad, independiente del contexto, tiene que ver con el enfoque de la documentacin en la evolucin y mantenimiento del producto. Se deriva del concepto emitido por los expertos en agilidad, quienes indican que la documentacin debe ser breve, precisa y limitada a las funciones fundamentales del sistema, porque tener el productofuncionando, es lo ms importante.

La visin de que la calidad del sistema se alcanza medianteel desarrollo iterativo y no mediante la documentacin trae problemas a largo plazo ya que la documentacin es el medio que asiste la transferencia del conocimiento y el mantenimiento y evolucin del software; una documentacinincompleta genera una rpida degradacin y envejecimientodel software.

Si se tiene en cuenta que 90% del costo total del software est relacionado con tareas de mantenimiento, es decir con modificaciones que se realizan despus de que el producto ha sido entregado, parece prudente utilizar algn mtodode documentacin que detalle el proceso de desarrollo de software, ms all de la comunicacin cara a cara.

El desconocimiento del sistema por parte del equipo de desarrollo, debido a la complejidad en el cdigo, puede generar deterioro en su arquitectura e incertidumbre en los cambios que se han realizado. La implementacin de cambios en el sistema es difcil como consecuencia de la dificultad que implica hacer cambios en cdigo que ha sido desarrollado por otra persona o incluso recordar los cambios que se han hecho.

Otras limitaciones tiene relacin con: el entrenamiento de nuevos miembros del equipo, que implica ocupar a otros miembros; el monitoreo y control del proceso, ya que no es comn que se documente; y el seguimiento del progreso.

El nfasis de Scrum es la administracin de proyectos, el de XP, la definicin de prcticas tcnicas ms especficas; por ello pueden ser combinadas en un mismo proyecto. El planninggame de XP es comnmente utilizadopara definir el esfuerzo que conlleva desarrollar determinadorequerimiento. La suma del esfuerzo de los requerimientosincluidos en un Sprint backlog ayuda al equipo a decidir si acepta o no desarrollar ese Sprint. El historial de las estimaciones de los tem desarrollados en cada Sprint ayuda al equipo a conocer su velocidad, lo que a su vez es til para hacer ms precisos los tiempos de entrega y, en ltimas, incrementa la tasa de xito en los proyectos.

La propiedad comn del cdigo, la metfora, el paso sostenibley el cliente en sitio, todas caractersticas de XP van muy de la mano con las propuestas de Scrum, su igualdad de los miembros del equipo, la ausencia de jerarqua, la constante comunicacin y retroalimentacin por parte del cliente, la gestin de expectativas y los criterios que definensi un proyecto es exitoso o no.Respecto a XP cabe recordar que aunque existe una versinpublicada en 2004 que revisa y ampla sus principiosy mtodos, la versin de referencia para la comunidadde desarrolladores sigue siendo la primera, la de 1999. Esto se aprecia en los trabajos de Sommerville, Sato et l y Sampaio et al, todos ellos publicados despus de 2004, que al referirse a XP hacen referencia a las prcticas definidas por Beck en 1999.Aunque hay diversas metodologas giles, hay dos que se han popularizado y a las que se suele hacer mayor referencia.La literatura muestra que es posible combinar varias metodologas de forma exitosa. En el caso que motiva este trabajo, se encuentra que XP es tal vez la metodologa ms cercana, pudindose utilizar en combinacin con SCRUM.