Metodologías Ágiles

Los métodos ágiles más conocidos yempleados son:

• Extreme Programming (XP)
• Scrum 
• Adaptive Software Development (ASD)
• Crystal Clear y otras metodologías de la familiaCrystalDSDM
• Feature Driven DevelopmentLean software development

El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte tenemos aquellas propuestas más tradicionales que se centran especialmente en el control del proceso, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y las herramientas y notaciones que se usarán. Estas propuestas han demo strado ser efectivas y necesarias en un gran número de proyectos, pero también han presentado problemas en otros muchos. Una posible mejora es incluir en los procesos de desarrollo más actividades, más artefactos y más restricciones, basándose en los puntos débiles detectados. Sin embargo, el resultado final sería un proceso de desarrollo más complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto. Otra aproximación es centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software. Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración con el cliente y al des arrollo incremental del software con iteraciones muy cortas. Este enfoque está mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías ágiles están revolucionando la manera de producir software, y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las metodologías tradicionales. En este trabajo se presenta resumidamente el contexto en el que surgen las metodologías ágiles, sus valores, principios y comparación con las metodologías tradicionales. Además se describen brevemente las principales propuestas, especialmente Programación Extrema (eXtreme Programming, XP) la metodología ágil más popular en la actualidad.

PROGRAMACIÓN EXTREMA (EXTREME PROGRAMMING, XP)

Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave
para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación 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 técnico.

Los principios y prácticas son de sentido común pero llevadas al extremo, de ahí proviene su nombre. Kent Beck, el padre de XP, describe la filosofía de XP en [2] sin cubrir los detalles técnicos y de implantación de las prácticas. Posteriormente, otras publicaciones de experiencias se han encargado de dicha tarea. A continuación presentaremos las características esenciales de XP organizadas en los tres apartados siguientes: historias de usuario, roles, proceso y prácticas. 

Roles XP
Los roles de acuerdo con la propuesta original de Beck son:
- Programador. El programador escribe las pruebas unitarias y produce el código del sistema.
- Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su} implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio.
- Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.

- Encargado de seguimiento (Tracker). Proporciona realimentación al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteración.
- Entrenador (Coach). Es responsable del proceso global. Debe proveer guías al equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente.
- Consultor. Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto, en el que puedan surgir problemas.
- Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación.

Proceso XP
El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:
1. El cliente define el valor de negocio a implementar.
2. El programador estima el esfuerzo necesario para su implementación.
3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo.
4. El programador construye ese valor de negocio.
5. Vuelve al paso 1.
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación de
manejar el ámbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración. El ciclo de vida ideal de XP consiste de seis fases : Exploración, Planificación de la Entrega (Release), Iteraciones, Producción, Mantenimiento y Muerte del Proyecto.

Prácticas XP
La principal suposición que se realiza en XP es la posibilidad de disminuir la mítica curva
exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseño
evolutivo funcione. Esto se consigue gracias a las tecnologías disponibles para ayudar en el desarrollo de software y a la aplicación disciplinada de las siguientes prácticas.
· El juego de la planificación. Hay una comunicación frecuente el cliente y los programadores. El equipo técnico realiza una estimación del esfuerzo requerido para la implementación de las historias de usuario y los clientes deciden sobre el ámbito y tiempo de las entregas y de cada iteración.
· Entregas pequeñas . Producir rápidamente versiones del sistema que sean operativas, aunque no cuenten con toda la funcionalidad del sistema. Esta versión ya constituye un resultado de valor para el negocio. Una entrega no debería tardar más 3 meses.
· Metáfora. El sistema es definido mediante una metáfora o un conjunto de metáforas compartidas por el cliente y el equipo de desarrollo. Una metáfora es una historia compartida que describe cómo debería funcionar el sistema (conjunto de nombres que actúen como vocabulario para hablar sobre el dominio del problema , ayudando a la
nomenclatura de clases y métodos del sistema).
· Diseño simple. Se debe diseñar la solución más simple que pueda funcionar y ser
implementada en un momento determinado del proyecto.
· Pruebas . La producción de código está dirigida por las pruebas unitarias. Éstas son son establecidas por el cliente antes de escribirse el código y son ejecutadas constantemente ante cada modificación del sistema.

Refactorización (Refactoring). Es una actividad constante de reestructuración del código con el objetivo de remover duplicación de código, mejorar su legibilidad, simplific arlo y hacerlo más flexible para facilitar los posteriores cambios. Se mejora la estructura interna del código sin alterar su comportamiento externo.
· Programación en parejas. Toda la producción de código debe realizarse con trabajo en
parejas de programadores. Esto conlleva ventajas implícitas (menor tasa de errores, mejor diseño, mayor satisfacción de los programadores, …).
· Propiedad colectiva del código. Cualquier programador puede cambiar cualquier parte del código en cualquier momento.
· Integración continua. Cada pieza de código es integrada en el sistema una vez que esté lista. Así, el sistema puede llegar a ser integrado y construido varias veces en un mismo día.
· 40 horas por semana. Se debe trabaja r un máximo de 40 horas por semana. No se trabajan horas extras en dos semanas seguidas. Si esto ocurre, probablemente está ocurriendo un problema que debe corregirse. El trabajo extra desmotiva al equipo.
· Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo para el
equipo. Éste es uno de los principales factores de éxito del proyecto XP. El cliente conduce constantemente el trabajo hacia lo que aportará mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. La comunicación oral es más efectiva que la escrita.
· Estándares de programación. XP enfatiza que la comunicación de los programadores es a través del código, con lo cual es indispensable que se sigan ciertos estándares de programación para mantener el código legible .

 

Modelos de ciclo de vida del software

Ciclo de vida lineal

Es el más sencillo de todos los modelos. Consiste en descomponer la actividad global del proyecto en etapas separadas que son realizadas de manera lineal, es decir, cada etapa se realiza una sola vez, a continuación de la etapa anterior y antes de la etapa siguiente. Con un ciclo de vida lineal es muy fácil dividir las tareas, y prever los tiempos (sumando linealmente los de cada etapa).

Las actividades de cada una de las etapas mencionadas deben ser independientes entre sí, es decir, que es condición primordial que no haya retroalimentación entre ellas, aunque sí pueden admitirse ciertos supuestos de realimentación correctiva. Desde el punto de vista de la gestión, requiere también que se conozca desde el primer momento, con excesiva rigidez, lo que va a ocurrir en cada una de las distintas etapas antes de comenzarla.

Esto ultimo minimiza, también, las posiblidades de errores durante la codificacion y reduce al mínimo la necesidad de requerir informacion del cliente o del usuario.

Se destaca como ventaja la sencillez de su gestión y administración tanto económica como temporal, ya que se acomoda perfectamente a proyectos internos de una empresa para programas muy pequeños de ABM (sistemas que realizan Altas, Bajas y Modificaciones sobre un conjunto de datos). Tiene como desventaja que no es apto para Desarrollos que superen mínimamente requerimientos de retroalimentación entre etapas, es decir, es muy costoso retomar una etapa anterior al detectar alguna falla.

Modelo de ciclo de vida en cascada puro

Este modelo de ciclo de vida fue propuesto por Winston Royce en el año 1970. Es un ciclo de vida que admite iteraciones, contrariamente a la creencia de que es un ciclo de vida secuencial como el lineal. Después de cada etapa se realiza una o varias revisiones para comprobar si se puede pasar a la siguiente. Es un modelo rígido, poco flexible, y con muchas restricciones. Aunque fue uno de los primeros, y sirvió de base para el resto de los modelos de ciclo de vida.

La necesidad de conocer los requerimientos al principio del proyecto es primordial al elegir este modelo de ciclo de vida a pesar de permitir iteraciones.

Una de sus ventajas, además de su planificación sencilla, es la de proveer un producto con un elevado grado de calidad sin necesidad de un personal altamente calificado.

Se pueden considerar como inconvenientes: la necesidad de contar con todos los requerimientos (o la mayoría) al comienzo del proyecto, y, si se han cometido errores y no se detectan en la etapa inmediata siguiente, es costoso y difícil volver atrás para realizar la corrección posterior.

Es un ciclo adecuado para los proyectos en los que se dispone de todos los requerimientos al comienzo, para el desarrollo de un producto con funcionalidades conocidas o para proyectos, que aun siendo muy complejos, se entienden perfectamente desde el principio.

Modelos de ciclo de vida en V

Este ciclo fue diseñado por Alan Davis, y contiene las mismas etapas que el ciclo de vida en cascada puro. A diferencia de aquél, a éste se le agregaron dos subetapas de retroalimentación entre las etapas de análisis y mantenimiento, y entre las de diseño y debugging.

Las ventajas y desventajas de este modelo son las mismas del ciclo anterior, con el agregado de los controles cruzados entre etapas para lograr una mayor corrección.

Podemos utilizar este modelo de ciclo de vida en aplicaciones, que si bien son simples(pequeñas transacciones sobre bases de datos por ejemplo), necesitan una confiabilidad muy alta. Un ejemplo claro en el que no nos podemos permitir el lujo de cometer errores es una aplicación de facturación, en la que si bien los procedimientos vistos individualmente son de codificación e interpretación sencilla, la aplicación en su conjunto puede tener matices complicados.

Modelo de ciclo de vida tipo Sashimi

Este ciclo de vida es parecido al ciclo de vida en cascada puro, con la diferencia de que en el ciclo de vida en cascada no se pueden solapar las etapas, y en éste sí. Esto suele, en muchos casos, aumentar su eficiencia ya que la retroalimentación entre etapas se encuentra implícitamente en el modelo.

Se hace notar como ventajas la ganancia de calidad en lo que respecta al producto final, la falta de necesidad de una documentación detallada (el ahorro proviene por el solapado de las etapas). Sus desventajas también se refieren al solapamiento de las etapas: es muy difícil gestionar el comienzo y fin de cada etapa y los problemas de comunicación, si aparecen, generan inconsistencias en el proyecto.

Modelo de ciclo de vida en cascada con subproyectos

Sigue el modelo de ciclo de vida en cascada. Cada una de las cascadas se dividen en subetapas independientes que se pueden desarrollar en paralelo.

MODELO DE TRES CAPAS

Es un modelo de programación para aplicaciones de acceso a datos en que se busca separar la arquitectura del programa en tres capas. En la capa de datos solo nos preocupamos del almacenamiento de éstos, en la capa de negocios situamos todas las transacciones y validaciones y en la capa de presentación sólo encontraremos las rutinas de visualización e interacción con el usuario.

Modelo de ciclo de vida iterativo

También derivado del ciclo de vida en cascada puro, este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de solicitud de requerimientos.

Es la iteración de varios ciclos de vida en cascada. Al final de cada iteración se le entrega al cliente una versión mejorada o con mayores funcionalidades del producto. El cliente es quien luego de cada iteración, evalúa el producto y lo corrige o propone mejoras.

Estas iteraciones se repetirán hasta obtener un producto que satisfaga al cliente.

Se suele utilizar en proyectos en los que los requerimientos no están claros de parte del usuario, por lo que se hace necesaria la creación de distintos prototipos para presentarlos y conseguir la conformidad del cliente.

Modelo de ciclo de vida por prototipos

El uso de programas prototipo no es exclusivo del ciclo de vida iterativo. En la práctica los prototipos se utilizan para validar los requerimientos de los usuarios en cualquier ciclo de vida.

Si no se conoce exactamente cómo desarrollar un determinado producto o cuáles son las especificaciones de forma precisa, suele recurrirse a definir especificaciones iniciales para hacer un prototipo, o sea, un producto parcial y provisional. En este modelo, el objetivo es lograr un producto intermedio, antes de realizar el producto final, para conocer mediante el prototipo cómo responderán las funcionalidades previstas para el producto final.

Antes de adoptar este modelo de ciclo debemos evaluar si el esfuerzo por crear un prototipo vale realmente la pena adoptarlo.

La ventaja de este ciclo se basa en que es el único apto para desarrollos en los que no se conoce a prioridad sus especificaciones o la tecnología a utilizar. Como contrapartida, por este desconocimiento, tiene la desventaja de ser altamente costoso y difícil para la administración temporal.

Si deseamos migrar aplicaciones de tecnología para adoptar sus nuevas funcionalidades o simplemente para estar en la cresta de la ola, este modelo es ideal. Un claro ejemplo son las llegadas de Java y la tecnología .NET que si bien contaban con respaldo y material de ayuda, implantaron nuevas tendencias.

Modelo de ciclo de vida evolutivo

Este modelo acepta que los requerimientos del usuario pueden cambiar en cualquier momento.

La práctica nos demuestra que obtener todos los requerimientos al comienzo del proyecto es extremadamente difícil, no sólo por la dificultad del usuario de transmitir su idea, sino porque estos requerimientos evolucionan durante el desarrollo y de esta manera, surgen nuevos requerimientos a cumplir. El modelo de ciclo de vida evolutivo afronta este problema mediante una iteración de ciclos requerimientos–desarrollo–evaluación.

Resulta ser un modelo muy útil cuando desconocemos la mayoría de los requerimientos iniciales, o estos requerimientos no están completos.

Modelo de ciclo de vida incremental

Este modelo de ciclo de vida se basa en la filosofía de construir incrementando las funcionalidades del programa.

Se realiza construyendo por módulos que cumplen las diferentes funciones del sistema.

Esto permite ir aumentando gradualmente las capacidades del software.

Este ciclo de vida facilita la tarea del desarrollo permitiendo a cada miembro del equipo desarrollar un modulo particular en el caso de que el proyecto sea realizado por un equipo de programadores.

Es una repetición del ciclo de vida en cascada, aplicándose este ciclo en cada funcionalidad del programa a construir. Al final de cada ciclo le entregamos una versión al cliente que contiene una nueva funcionalidad. Este ciclo de vida nos permite realizar una entrega al cliente antes de terminar el proyecto.

El modelo de ciclo de vida incremental nos genera algunos beneficios tales como los que se describen a continuacion:

• Construir un sistema pequeño siempre es menos riesgoso que construir un sistema grande.

• Como desarrollamos independientemente las funcionalidades, es más fácil relevar los requerimientos del usuario.

• Si se detecta un error grave, sólo desechamos la última iteración.

No es necesario disponer de los requerimientos de todas las funcionalidades en el comienzo del proyecto y además facilita la labor del desarrollo con la conocida filosofía de divide & vencerás.

Modelo de ciclo de vida en espiral

Este ciclo puede considerarse una variación del modelo con prototipado, fue diseñado por Boehm en el año 1988. El modelo se basa en una serie de ciclos repetitivos para ir ganando madurez en el producto final. Toma los beneficios de los ciclos de vida incremental y por prototipos, pero se tiene más en cuenta el concepto de riesgo que aparece debido a las incertidumbres e ignorancias de los requerimientos proporcionados al principio del proyecto o que surgirán durante el desarrollo. A medida que el ciclo se cumple (el avance del espiral), se van obteniendo prototipos sucesivos que van ganando la satisfacción del cliente o usuario.

A menudo, la fuente de incertidumbres es el propio cliente o usuario, que en la mayoría de las oportunidades no sabe con perfección todas las funcionalidades que debe tener el producto.

En este modelo hay cuatro actividades que envuelven a las etapas.

Planificación: Relevamiento de requerimientos iniciales o luego de una iteración.

• Análisis de riesgo: De acuerdo con el relevamiento de requerimientos decidimos

si continuamos con el desarrollo.

• Implementación: desarrollamos un prototipo basado en los requerimientos.

• Evaluación: El cliente evalúa el prototipo, si da su conformidad, termina el proyecto. En caso contrario, incluimos los nuevos requerimientos solicitados por el cliente en la siguiente iteración.

La ventaja más notoria de este modelo de desarrollo de software es que puede comenzarse el proyecto con un alto grado de incertidumbre, se entiende también como ventaja el bajo riesgo de retraso en caso de detección de errores, ya que se puede solucionar en la próxima rama del espiral.

Algunas de las las desventajas son: el costo temporal que suma cada vuelta del espiral, la dificultad para evaluar los riesgos y la necesidad de la presencia o la comunicación continua con el cliente o usuario.

Se observa que es un modelo adecuado para grandes proyectos internos de una empresa, en donde no es posible contar con todos los requerimientos desde el comienzo y el usuario está en nuestro mismo ambiente laboral.

Modelo de ciclo de vida orientado a objetos

Esta técnica fue presentada en la década del 90, tal vez como una de las mejores metodologías a seguir para la creación de productos software.

Puede considerarse como un modelo pleno a seguir, como así también una alternativa dentro de los modelos anteriores.

Al igual que la filosofía del paradigma de la programación orientada a objetos, en esta metodología cada funcionalidad, o requerimiento solicitado por el usuario, es considerado un objeto. Los objetos están representados por un conjunto de propiedades, a los cuales denominamos atributos, por otra parte, al comportamiento que

tendrán estos objetos los denominamos métodos.

La característica principal de este modelo es la abstracción de los requerimientos de usuario, por lo que este modelo es mucho más flexible que los restantes, que son rígidos en requerimientos y definición, soportando mejor la incertidumbre que los anteriores, aunque sin garantizar la ausencia de riesgos. La abstracción es lo que nos permite analizar y desarrollar las características esenciales de un objeto (requerimiento), despreocupándonos de las menos relevantes.

Favorece la reducción de la complejidad del problema que deseamos abordar y permite el perfeccionamiento del producto.

En este modelo se utilizan las llamadas fichas CRC (clase–responsabilidades–colaboración) como herramienta para obtener las abstracciones y mecanismos clave de un sistema analizando los requerimientos del usuario. En la ficha CRC se escribe el nombre de la clase u objeto, sus responsabilidades (los métodos) y sus colaboradores (otras clases u objetos de los cuales necesita). Estas fichas, además, nos ayudan a confeccionar los denominados casos de uso.

Conclusiones

• El ciclo de vida del software no es mas que las etapas por la cual pasa la concepción, desarrollo y puesta en marcha un sistema o una implementación de un software.
• el ciclo de vida del software debe cumplir con ciertas características y especificaciones para el cual fue construido, para esto se basa en medidas de rendimientos , pruebas y otras técnicas para la evaluación de la aplicación.
• un ciclo de vida del software esta constituido por técnicas, actividades y herramientas que ayudan a la construcción de un proyecto especifico.