METODOLOGÍAS DE DESARROLLO ÁGILES VS METODOLOGÍAS

TRADICIONALES
Metodologías de Desarrollo:

Para el desarrollo de software, se requiere de diversos elementos que agrupados hacen

que el desarrollo de software sea o no exitoso.

Para esto existen las metodologías tradicionales que se modificaron para poder
aplicarlas al desarrollo de software, aunque durante mucho tiempo fueron la única
solución al desarrollo, hizo estas metodologías poco flexibles y muy cuadriculadas. Estas
consistían en una serie fundamentos y conceptos aplicados al desarrollo de software,
documentación, planificación y procesos. (Plantillas, técnicas de administración,
revisiones, etc.)

Ante las dificultades de las metodologías tradicionales referentes al tiempo y flexibilidad,

aparecen las metodologías ágiles como una respuesta metodológica, especialmente
porque están orientadas a proyectos pequeños, constituyen una solución a la medida del
entorno, simplificando las prácticas y asegurando la calidad del producto.

El término ágil, nace en febrero de 2001 en una reunión en Utah (EEUU), aplicado al
desarrollo de software, su objetivo era idear los valores y principios que permitirían a los
equipos de desarrollo crear software rápidamente, respondiendo a los cambios surgidos a
lo largo del proyecto, ofreciendo una alternativa a los procesos tradicionales. En dicha
reunión se creó The Agile Alliance, organización, sin ánimo de lucro, que promueve los
conceptos relacionados con el desarrollo ágil de software, apoyando las organizaciones
para que adopten dichos conceptos.

Según el Manifiesto ágil, se valora al individuo y las interacciones del equipo de desarrollo
sobre el proceso y las herramientas, desarrollar software que funciona (más que conseguir
una buena documentación), la colaboración con el cliente (más que la negociación
mediante contrato), respuesta a los cambios (más que seguir rigurosamente algún plan).

Cuadro comparativo: Metodologías tradicionales y ágiles:

Metodologías Tradicionales Metodologías Ágiles

- Rigidez ante los cambios, de manera - Flexibilidad ante los cambios del proyecto
lentos o moderada de forma moderada a rápida

- Los clientes interactúan con el equipo de - Los clientes hacen parte del equipo de
desarrollo mediante reuniones desarrollo

- Grupos de gran tamaño y varias veces - Grupos pequeños (promedio 10

distribuidos en diferentes sitios participantes in situ) en el mismo lugar.

- Dependencia de la arquitectura de - Menor dependencia de la arquitectura de

software mediante modelos software

- Poco Feedback lo que extiende el tiempo - Continuo Feedback acortando el tiempo

de entrega de entrega

- Mínimos roles - Diversidad de roles

- Basadas en normas de estándares de - Basadas en heurísticas a partir de

desarrollo prácticas de producción de código

- Procesos muy controlados por políticas y - Procesos menos controlados,

normas pocas políticas y normas

- Seguimiento estricto del plan inicial de - Capacidad de respuesta ante los cambios
desarrollo

Estas diferencias, no solo afectan el proceso en sí, sino también el contexto del equipo de
trabajo y su organización

LA METODOLOGÍA ÁGIL XP:

Una de las metodologías que más esta difundiéndose en la actualidad, es la Programación

Extrema (XP[2], Extreme Programming). Esta metodología ágil está enfocada a fortalecer
las relaciones interpersonales como clave para el éxito en desarrollo de software,
promoviendo el trabajo en equipo, un buen clima laboral y preocupándose por el
aprendizaje de los desarrolladores. Kent Beck, es el padre de XP (1999), esta metodología
se basa en la retroalimentación continua entre el equipo de desarrollo y el cliente,
simplificando las soluciones implementadas y disposición para los cambios; Adecuada para
proyectos con requisitos imprecisos, cambiantes y con alto riesgo técnico.

Los roles de acuerdo con la propuesta original de Kent Beck son:

- Programador: Escribe las pruebas unitarias y produce el código del sistema, se

recomienda la programación por parejas para minimizar los errores ya que se revisa el
código y se discute durante su programación.

- Cliente: Escribe las historias de usuario y las pruebas funcionales para validar su
implementación, también 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.

- Tester o Delegado de pruebas: Ayuda al cliente a escribir las pruebas funcionales;

Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es el responsable
de las herramientas de soporte para las pruebas.

- Tracker o Encargado de seguimiento: Proporciona retroalimentación al equipo, verifica

el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado para
mejorar estimaciones futuras, también hace seguimiento del progreso de cada iteración.

- Entrenador o Coach: Responsable del proceso global, provee guías al equipo de manera
que se apliquen las prácticas XP y se siga el proceso correctamente.

- Consultor: Miembro externo del equipo, con conocimiento específico en algún tema
necesario para el proyecto, ayuda a resolver problemas que puedan surgir.
 - Gestor o Big Boss: Es el vínculo entre clientes y programadores, encargado de que el
equipo trabaje efectivamente creando condiciones adecuadas. Su labor principalmente es
coordinación.

El ciclo de vida de XP consiste de seis fases:

- Exploración

- Planificación de la Entrega (Release)

- Iteraciones,

- Producción

- Mantenimiento

- Muerte del Proyecto

SOFTWARE LIBRE OSS

Es un modelo de desarrollo donde no hay un orden estricto de creación, tiene flexibilidad

y diversidad en el desarrollo, interactúan diferentes actores y no es controlada por ningún
tipo de persona o entidad, sino que prima una gran cantidad de intereses e intercambios,
los desarrolladores son de clientes y desarrolladores a la vez, de forma colaborativa se
desarrolla software de calidad con pequeños y frecuentes incrementos, tiene una
decremento de costos mientras se incrementan la seguridad y la estabilidad, los detalles
del diseño se revisan en línea, el código es escrito por pequeños grupos de desarrolladores
agiles y las pruebas son procesos rápidos y colaborativos teniendo una retroalimentación
es abundante y rápida con pruebas testeadas y pequeñas entregas frecuentes por la
comunidad de desarrollo
 MODELOS DE DESARROLLO DE SOFTWARE

1. MODELO SECUENCIAL LINEAL

Este es también llamado "Modelo Clásico", "Modelo Tradicional" o "Modelo en

Cascada".
Este es el más básico de todos los modelos, y sirve como bloque de construcción
para los demás modelos de ciclo de vida. La visión del modelo cascada del
desarrollo de software es muy simple; dice que el desarrollo de software puede ser
a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas
bien definidas, y las actividades dentro de una fase contribuyen a la satisfacción
de metas de esa fase o quizás a una subsecuencia de metas de la fase. Las
flechas muestran el flujo de información entre las fases. La flecha de avance
muestra el flujo normal. Las flechas hacia atrás representan la retroalimentación.
Características:

 Planear un proyecto antes de embarcarse en él.

 Definir el comportamiento externo deseado del sistema antes de diseñar su

arquitectura interna.

 Documentar los resultados de cada actividad.

 Diseñar un sistema antes de codificarlo.

 Testear un sistema después de construirlo.

Ventaja:
  Una de las contribuciones más importantes del modelo cascada es para los
administradores, posibilitándoles avanzar en el desarrollo, aunque en una
escala muy bruta.

Desventajas:

 Los cambios introducidos durante el desarrollo pueden confundir al equipo

profesional en las etapas tempranas del proyecto. Si los cambios se
producen en etapa madura (codificación o prueba) pueden ser catastróficos
para un proyecto grande.
 No es frecuente que el cliente o usuario final explicite clara y
completamente los requisitos (etapa de inicio); y el modelo lineal lo
requiere. La incertidumbre natural en los comienzos es luego difícil de
acomodar.
 El cliente debe tener paciencia ya que el software no estará disponible
hasta muy avanzado el proyecto. Un error detectado por el cliente (en fase
de operación) puede ser desastroso, implicando reinicio del proyecto con
altos costos.

Critica:

Este es un modelo en el cual se debe usar cuando todos los requerimientos han
sido establecidos claramente de entrada.

2. MODELO DE CONSTRUCCION DE PROTOTIPOS

El prototipado de requerimientos es la creación de una implementación parcial de

un sistema, para el propósito explícito de aprender sobre los requerimientos del
sistema. Un prototipo es construido de una manera rápida tal como sea posible.
Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que
ellos experimenten con el prototipo. Estos individuos luego proveen la
retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo
proporcionado, quienes capturan en la documentación actual de la especificación
de requerimientos la información entregada por los usuarios para el desarrollo del
sistema real. El prototipado puede ser usado como parte de la fase de
requerimientos (determinar requerimientos) o justo antes de la fase de
requerimientos (como predecesor de requerimientos). En otro caso, el prototipado
puede servir su papel inmediatamente antes de algún o todo el desarrollo
incremental en modelos incremental o evolutivo.

El Prototipado ha sido usado frecuentemente en los 90, porque la especificación

de requerimientos para sistemas complejos tienden a ser relativamente dificultoso
de cursar. Muchos usuarios y clientes encuentran que es mucho más fácil proveer
retroalimentación convenientemente basada en la manipulación, leer una
especificación de requerimientos potencialmente ambigua y extensa.

Escuchar al Con
cliente prot

Validar
prototipo
Diferente del modelo evolutivo donde los requerimientos mejor entendidos están
incorporados, un prototipo generalmente se construye con los requerimientos
entendidos más pobremente.

Desventajas:

 Cliente cree que es el sistema.

 Peligro de familiarización con malas elecciones iniciales (quick and dirty).
Critica:

Se debe usar cuando inicialmente no están claros los requerimientos. Para así
definir claramente de entrada las reglas con el cliente.

3. MODELOS EVOLUTIVOS
 Se adaptan más fácilmente a los cambios introducidos a lo largo del
desarrollo.
 Iterativos
 En cada iteración se obtienen versiones más completas del SW.

3.1. MODELO INCREMENTAL

Los riesgos asociados con el desarrollo de sistemas largos y complejos son

enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema,
reservando otros aspectos para niveles posteriores. El desarrollo incremental es el
proceso de construcción siempre incrementando subconjuntos de requerimientos
del sistema. Típicamente, un documento de requerimientos es escrito al capturar
todos los requerimientos para el sistema completo.

Note que el desarrollo incremental es 100% compatible con el modelo cascada. El

desarrollo incremental no demanda una forma específica de observar el desarrollo
de algún otro incremento. Así, el modelo cascada puede ser usado para
administrar cada esfuerzo de desarrollo, como se muestra en la figura.
El modelo de desarrollo incremental provee algunos beneficios significativos para
los proyectos:

 Construir un sistema pequeño es siempre menos riesgoso que construir un

sistema grande.

 Al ir desarrollando parte de las funcionalidades, es más fácil determinar si

los requerimientos planeados para los niveles subsiguientes son correctos.

 Si un error importante es realizado, sólo la última iteración necesita ser

descartada.

 Reduciendo el tiempo de desarrollo de un sistema (en este caso en

incremento del sistema) decrecen las probabilidades que esos
requerimientos de usuarios puedan cambiar durante el desarrollo.

 Si un error importante es realizado, el incremento previo puede ser usado.

 Los errores de desarrollo realizados en un incremento, pueden ser

arreglados antes del comienzo del próximo incremento.

En la figura se muestra un refino del diagrama previo, bajo un esquema temporal,

para obtener finalmente el esquema del Modelo de ciclo de vida Iterativo
Incremental, con sus actividades genéricas asociadas. Aquí se observa
claramente cada ciclo cascada que es aplicado para la obtención de un
incremento; estos últimos se van integrando para obtener el producto final
completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por
simplicidad, en la figura 5 se muestra como secuencial puro.

Se observa que existen actividades de desarrollo (para cada incremento) que son
realizadas en paralelo o concurrentemente, así por ejemplo, en la figura, mientras
se realiza el diseño detalle del primer incremento ya se está realizando en análisis
del segundo.

Ventajas:

El modelo proporciona todas las ventajas del modelo en cascada realimentado,

reduciendo sus desventajas sólo al ámbito de cada incremento.

Desventajas:

El modelo Incremental no es recomendable para casos de sistemas de tiempo

real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de
riesgos.

Critica:

En este modelo se debe especificar con precisión todo lo que el sistema va a

hacer antes de desarrollarlo. Lo cual lo hace manejable y disminuiría los costos.

3.2. MODELO EN ESPIRAL

Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza

iterativa de la construcción de prototipos, pero conservado aquellas propiedades
del modelo en cascada.

El modelo en espiral fue desarrollado por Boehm, quien lo describe así:

El modelo de desarrollo en espiral es un generador de modelo de proceso guiado
por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de
software concurrente y a la vez con muchos usuarios.

Características:

 Un enfoque cíclico para el crecimiento incremental del grado de definición e

implementación de un sistema, mientras que disminuye su grado de riesgo.

 Un conjunto de puntos de fijación para asegurar el compromiso del usuario

con soluciones de sistema que sean factibles y mutuamente satisfactorias.

El modelo espiral no es una alternativa del modelo cascada, ellos son

completamente compatibles.

Funcionamiento del modelo Espiral

En cada vuelta tomamos en cuenta:

 Los Objetivos: Que necesidad debe envolver el programa.

 Alternativas: Los varios métodos de alcanzar los objetivos de manera
exitosa, a través de diferentes puntos como son:
o Características: experiencia del personal, exigencias a efectuar.
o Formas de gestión del programa.
o Riesgo tomado con cada alternativa.
 Desarrollar y Verificar: Programar y probar el programa .
 Se planificaran los siguientes pasos y se volverá a empezar la espiral.
La espiral tiene una forma de caracola y se dice que mantiene dos
dimensiones la radial y la angular:

o Angular=Avance del proyecto Software, dentro de un ciclo.

o Radial=Aumento del coste del proyecto, ya que con cada nueva
iteración se pasa más tiempo desarrollando.

Este sistema es muy utilizado en proyectos largos como pueden ser la creación de
un Sistema Operativo. Y que necesitan constantes cambios.

Al ser un modelo de Ciclo de Vida orientado al riesgo se dice que uno de los
aspectos fundamentales de su éxito radica en que el equipo que lo aplique sea
capaz de detectar y catalogar correctamente dicho riesgo.

Desventajas:

 Requiere mucha experiencia y habilidad para la evaluación de los riesgos,

lo cual es requisito para el éxito del proyecto.
 Es difícil convencer a los grandes clientes que se podrá controlar este
enfoque evolutivo.

Critica:
Este modelo es útil para grandes proyectos pero no ha sido utilizado tanto como el
lineal secuencial o el de prototipos. Tiene similitud con el modelo en cascada, pero
aquí lo enfoca en un sistema más real.

3.3. MODELO WINWIN

Una variante interesante del Modelo Espiral previamente visto es el "Modelo

Espiral Win-Win" (Barry Boehm). El Modelo Espiral previo (clásico) sugiere la
comunicación con el cliente para fijar los requisitos, en que simplemente se
pregunta al cliente qué necesita y él proporciona la información para continuar;
pero esto es en un contexto ideal que rara vez ocurre. Normalmente cliente y
desarrollador entran en una negociación, se negocia coste frente a funcionalidad,
rendimiento, calidad, etc.

"Es así que la obtención de requisitos requiere una negociación, que tiene éxito
cuando ambas partes ganan".

Las mejores negociaciones se fuerzan en obtener "Victoria & Victoria" (Win &
Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el
desarrollador también gane consiguiendo presupuesto y fecha de entrega realista.
Evidentemente, este modelo requiere fuertes habilidades de negociación.

El modelo Win-Win define un conjunto de actividades de negociación al principio

de cada paso alrededor de la espiral; se definen las siguientes actividades:

1 - Identificación del sistema o subsistemas clave de los directivos(*) (saber

qué quieren).

2 - Determinación de "condiciones de victoria" de los directivos (saber qué

necesitan y los satisface)
 3 - Negociación de las condiciones "victoria" de los directivos para obtener
condiciones "Victoria & Victoria" (negociar para que ambos ganen).

(*) Directivo: Cliente escogido con interés directo en el producto, que puede ser
premiado por la organización si tiene éxito o criticado si no.

El modelo WinWin hace énfasis en la negociación inicial, también introduce 3 hitos

en el proceso llamados "puntos de fijación", que ayudan a establecer la
completitud de un ciclo de la espiral, y proporcionan hitos de decisión antes de
continuar el proyecto de desarrollo del software.

Critica:

En este modelo las actividades que se definen son importantes como lo son: la
identificación del sistema, la determinación de las condiciones y la negociación de
estas.

3.4. MODELO DE DESARROLLO CONCURRENTE

Como el modelo espiral, el modelo concurrente provee una meta-descripción del

proceso software. Mientras que la contribución primaria del modelo espiral es en
realidad que esas actividades del software ocurran repetidamente, la contribución
del modelo concurrente es su capacidad de describir las múltiples actividades del
software ocurriendo simultáneamente.

Esto no sorprende a nadie que ha estado involucrado con las diversas actividades
que ocurren en algún tiempo del proceso de desarrollo de software.

Los requerimientos son usualmente "líneas de base", cuando una mayoría de los
requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un
esfuerzo considerable al diseño. Sin embargo, una vez que comienza el diseño,
cambios a los requerimientos son comunes y frecuentes (después de todo, los
problemas reales cambian, y nuestro entendimiento de los problemas
desarrollados también). Es desaconsejado detener el diseño en este camino
cuando los requerimientos cambian; en su lugar, existe una necesidad de
modificar y rehacer líneas de base de los requerimientos mientras progresa el
diseño. Por supuesto, dependiendo del impacto de los cambios de los
requerimientos el diseño puede no ser afectado, medianamente afectado o se
requerirá comenzar todo de nuevo.

Durante el diseño de arquitectura, es posible que algunos componentes

comiencen a ser bien definidos antes que la arquitectura completa sea
estabilizada. En tales casos, puede ser posible comenzar el diseño detallado en
esos componentes estables. Similarmente, durante el diseño detallado, puede ser
posible proceder con la codificación y quizás regular testeando en forma unitaria o
realizando testeo de integración previo a llevar a cabo el diseño detallado de todos
los componentes.

En algunos proyectos, múltiples etapas de un producto se han desarrollado

concurrentemente. Por ejemplo, no es inusual estar haciendo mantención de la
etapa 1 de un producto, y al mismo tiempo estar haciendo mantención sobre un
componente 2, mientras que se está haciendo codificación sobre un componente
3, mientras se realiza diseño sobre una etapa 4, y especificación de requisitos
sobre un componente 5.

Critica:

Este modelo se utiliza cuando las actividades están ocurriendo simultáneamente

así, se posibilita el conocimiento del estado real en el que se encuentra el
proyecto.