METODOLOGAS TRADICIONALES VS.

METODOLOGAS GILES
Roberth G. Figueroa1, Camilo J. Sols2
Armando A. Cabrera3
Universidad Tcnica Particular de Loja, Escuela de Ciencias en Computacin
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 en 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 estn pensadas para 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,
la confianza en las habilidades del equipo y al mantener
una buena relacin con el cliente. Se vern diferencias,
ventajas, desventajas y cual puede encajar en un proyecto
de software, es por ello que, ofrecemos una gua dejando
libertad de eleccin para el lector el poder juzgar y elegir
la mejor metodologa que se adapte a su equipo de
desarrollo.

METODOLOGA TRADICIONAL
Al inicio el desarrollo de software era artesanal en su
totalidad, la fuerte necesidad de mejorar el proceso y
llevar los proyectos a la meta deseada, tuvieron que
importarse 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 tenemos los altos costos al implementar un
cambio y al no ofrecer una buena solucin para proyectos
donde el entorno es voltil.

Palabras Claves Metodologa, RUP, MSF AUP, Scrum,

Metodologa Tradicional, Metodologa gil

Las metodologas tradicionales (formales) se focalizan en

documentacin, planificacin y procesos. (Plantillas,
tcnicas de administracin, revisiones, etc.), a
continuacin se detalla RUP uno de los mtodos ms
usados dentro de los mtodos tradicionales

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 para nuestros clientes, generan
grandes cambios en las metodologas adoptadas por los
equipos para cumplir sus objetivos, puesto que, unas se
adaptan mejor que otras, al contexto del proyecto
brindando mejores ventajas.

RATIONAL UNIFIED PROCESS (RUP)

FIGURA1.
PROCESO UNIFICADO RATIONAL

Es por eso de la importancia de una metodologa robusta

que ajustada en un equipo cumpla con sus metas, y
satisfaga mas all de las necesidades definidas al inicio del
proyecto.

El xito del producto depende en gran parte de la

metodologa escogida por el equipo, ya sea tradicional o
gil, donde los equipos maximicen su potencial, aumenten
la calidad del producto con los recursos y tiempos
establecidos.

Roberth G. Figueroa, UTPL, Loja, rgfigueroa@utpl.edu.ec

Camilo J. Sols, UTPL, Loja, cjsolis@utpl.edu.ec
Armando Cabrera S,Docente-Investigador UTPL,Loja, aacabrera@utpl.edu.ec

2
3

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.

FIGURA 2.
MODELO DE EQUIPO DE MSF

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

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.

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.

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.

MICROSOFT SOLUTION FRAMEWORK (MSF)4

Desarrollo:

Descripcin

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.

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.

Estabilizacin:
Todo proyecto es separado en cinco principales fases:

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.

Visin y Alcances.
Planificacin.
Desarrollo.
Estabilizacin.

Microsoft Solution Framework, (en

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

Implantacin:
lnea),
2

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

generalmente se definen como reas principales

la de Diseo de Arquitectura, Pruebas de
Laboratorio, Documentacin, Logstica y
Coordinacin.
Elaboracin del Plan de Trabajo: deben marcarse
fechas y contenidos para esta fase y las
siguientes. Los mecanismos y protocolos de
intercambio de informacin y coordinacin deben
quedar suficientemente bien establecidos y
consensuados.
Elaboracin de la matriz de Riesgos y Plan de
Contingencia: los principales riesgos detectados
deben tener un plan de mitigacin y actuacin y
revisarse con periodicidad.
Para un proyecto de migracin a Windows 2000 podra
estimarse que los trabajos indicados pueden requerir en
torno a 20 jornadas de trabajo y la intervencin de un
Consultor de Microsoft junto con el equipo de trabajo que
formen El cliente y el Partner.
Fase 2 - Planificacin y Prueba de Concepto

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.

Deben alcanzarse los siguientes objetivos e hitos:

Documento de Planificacin y Diseo de
Arquitectura: es el documento principal, donde se
describen en detalle los aspectos funcionales y
operativos de la nueva plataforma. La aprobacin
de este documento es el hito principal de esta
fase, y supone la directriz ltima de todos los
trabajos tcnicos, que, a partir de ese momento,
deben ser consistentes con esta Gua. Si en el
curso de las fases sucesivas fuera necesario
revisar estos contenidos, se deber hacer por
acuerdo y conocimiento de todo el equipo de
trabajo y se llevar un registro de versiones que
permita hacer un seguimiento adecuado de estas
revisiones.
Documento de Plan de Laboratorio - Prueba de
Concepto: la descripcin del contenido del
laboratorio de prueba de concepto, los diversos
escenarios a simular, los criterios de validez, el
control de incidencias y las mtricas de calidad
son objetivos a cubrir en este documento. Es un
documento dinmico, en el que se recoge la idea
y la experiencia prctica al llevarla a cabo en
entorno controlado y aislado. La etapa de prueba
de laboratorio concluye cuando la maqueta ofrece
todos los servicios y funciones descritos en el
Documento de Alcance y Estrategia, y su grado
de estabilidad y rendimiento es considerado como
"suficiente".

La comunicacin se pone en el centro del crculo para

mostrar que est integrada en la estructura y fluye en todas
direcciones. El modelo apoya la comunicacin efectiva y
es esencial para el funcionamiento del mismo
Ejemplo de metodologa MSF aplicada
Como ejemplo de una aplicacin de metodologa MSF a
un proyecto, a continuacin se describe el contenido de
cada una de las fases y, en la medida de lo posible, un
detalle de acciones concretas y estimacin de carga de
trabajo en trminos de jornadas, nmero de personas
implicadas y perfil de las mismas. El proyecto ejemplo se
trata de una implantacin de infraestructuras, en concreto,
migracin a Windows 2000 de una red de servidores.
Fase 1 - Estrategia y alcance
En esta fase deberan tener lugar los siguientes trabajos:
Elaboracin y aprobacin del Documento de
Alcance y Estrategia definitivo: debe ser un
documento de consenso con la participacin del
mayor nmero de agentes implicados en el
proyecto. En este documento quedarn
definitivamente reflejadas las funcionalidades y
servicios que, ineludiblemente, debe ofrecer la
solucin a implantar.
Formacin del Equipo de Trabajo y distribucin
de
competencias
y
responsabilidades:

Habitualmente, en las propuestas de preventa no se pueden

indicar con precisin parmetros como el esfuerzo tcnico,
tiempo o coste definitivo que puede suponer esta fase. De
otras experiencias anteriores se puede obtener una relacin
de trabajos slo a ttulo orientativo, y que debe ser
revisado y acordado por todas las partes:

El cmputo de jornadas para la relacin de actividades

descritas (que como se observa slo recogen las relativas a
la Planificacin y Diseo, y deja aparte las necesarias para
elaborar el plan de Migracin), ofrecera este resultado:
Jornadas
totales:
80
(aprox.
4
meses)
Jornadas / tcnico del PARTNER: 150 jornadas (2
personas)
Jornadas / tcnico del CLIENTE: 110 jornadas (Max. 2
personas)

Elaboracin del Plan de Despliegue: se debe

consensuar la fecha de finalizacin de la fase
Piloto, y las condiciones de calidad que debe
cumplir la solucin final para iniciar el
despliegue. En el Plan deben identificarse las
fases, estrategia de implantacin, fechas, tareas a
realizar, procedimientos de validacin y mtodo
de control de incidencias.
Elaboracin del Plan de Formacin: con
anterioridad al despliegue definitivo, debe
haberse aprobado el Plan de Formacin orientado
a usuarios finales y administradores, y debe
hacerse compatible con los ritmos acordados en
el Plan de Despliegue.
El tiempo necesario para abordar esta fase es variable y
depende en parte de factores ajenos a la complejidad de la
propia solucin, como es la adecuada seleccin del
entorno de prueba y el momento del ao en que tenga
lugar (evitando que coincida con periodos de vacaciones o
puntas de trabajo crticas como Fin de Ao). En proyectos
de similar envergadura se ha llegado al momento "Error
Free Versin" en 30 jornadas de trabajo (aproximadamente
mes y medio) con una muestra de 50 usuarios.

Fase 3 Estabilizacin
La solucin implantada en la maqueta se pasa a un entorno
real de explotacin, restringido en nmero de usuarios y
en condiciones tales que se pueda llevar un control
efectivo de la situacin. Los hitos y objetivos
fundamentales de esta fase son:
Seleccin del entorno de prueba piloto: se
acordar la composicin y ubicacin del conjunto
de mquinas y usuarios que entrarn en la prueba.
Esta seleccin se recomienda que se haga
atendiendo a la mayor variedad posible de casos,
de manera que puedan aflorar el mximo de
incidentes potenciales en el menor tiempo
posible. La dimensin de la muestra tiene
tambin que calcularse, sin perder de vista que la
prueba piloto no es el despliegue propiamente,
sino una fase de observacin en la que es
absolutamente crtico establecer unos cauces
efectivos de tratamiento de los errores.
Gestin de Incidencias: aunque esta labor se
habr iniciado en la fase anterior, el xito de la
prueba piloto depender de que se forme un
sistema de recogida de incidentes (helpdesk o
similar), de atencin al usuario (formacin,
consultas) y de resolucin de problemas y
documentacin de los mismos (versionado de la
plataforma).
Revisin de la documentacin final de
Arquitectura: el documento de Planificacin y
Diseo de Arquitectura se puede ver alterado
parcialmente como resultado de esta fase. El
documento final, aprobado por consenso, supone
el principal documento del Proyecto y la
culminacin de los trabajos de diseo, al menos
en sus lneas principales. Este documento se
considerar definitivo cuando la solucin puesta
en marcha se muestre estable y el nmero de
incidencias graves (de intervencin o de
resolucin) sea nulo y la cantidad de las
consideradas leves quede por debajo de un lmite
establecido en las Mtricas de Calidad.
Elaboracin de la documentacin de
Formacin y Operaciones: con vistas al soporte
post proyecto y los programas de formacin a
usuarios y administradores, en esta fase deben
elaborarse las Guas de Usuario, de
Administracin, las "paso-a-paso", y otros cuyos
contenidos deben acordarse previamente.

Fase 4 Despliegue
Se llevarn a cabo en esta fase los planes diseados en la
anterior, principalmente el de despliegue y el de
formacin. Los principales trabajos e hitos a conseguir
son, en este caso, adems de los obvios (implantacin de
la plataforma, puesta en servicio de todas las funciones,
formacin a los usuarios y administradores), los
siguientes:
Continuacin con las labores de recepcin de
incidencias, clasificacin, tratamiento, resolucin
y distribucin de faxes o intervencin on-site.
Registro
de
mejoras
y
sugerencias,
funcionalidades no cubiertas y novedades a
incorporar en sucesivas versiones de la
plataforma, incluyendo mejoras aportadas por los
fabricantes de software (nuevas versiones o
Service Packs, por ejemplo)
Revisin de las Guas y manuales de usuario,
rectificacin de errores y obtencin de los
documentos de formacin definitivos.
Entrega de los documentos definitivos acordados
como "deliverables" en la fase de Vision Scope.
Revisin (si procede) de la matriz de riesgos, las
mtricas de calidad y establecimiento de los
estndares de calidad y SLA definitivos.
Finalmente, entrega del Proyecto y cierre del
mismo, con o sin apertura de nuevo proyecto en
base a la informacin y experiencia obtenidas.
La duracin fase de despliegue, puesto que debe
planificarse, no puede establecerse a priori. Depende de
numerosos factores externos al propio proyecto
(incluyendo factores de oportunidad poltica o de negocio)
que pueden retardar o acelerar la conclusin.

La experiencia demuestra que no hay una relacin directa

entre nmero de mquinas y tiempo necesario para el
despliegue. Los factores ms relevantes en el clculo
suelen ser la dispersin o concentracin geogrfica, la
complejidad del proceso de migracin, el grado de
automatizacin alcanzado, la experiencia y nivel de los
tcnicos que realizan la operacin y condicionantes de
calendario, a menudo con restricciones no tcnicas, sino
de otros tipos (las fechas-objetivo suelen marcarse por
criterios de oportunidad de negocio).

Reduce el nmero de decisiones de alta

inversin que se toman.
Reduce el nmero de cambios necesario
en el proyecto.
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.

METODOLOGAS GILES.

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
que es el ms aceptado dentro del desarrollo de SW

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 potencia an ms
el desarrollo de software a gran escala.

EXTREME PROGRAMMING (XP)

Como resultado de esta nueva teora se crea un Manifiesto

gil5 cuyas principales ideas son:

FIGURA 36.
MODELO DE EXTREME PROGRAMMING

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.

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.

Retrasar las decisiones y Planificacin Adaptativa

Es el eje en cual gira la metodologa gil, el retrasar las
decisiones tan 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:

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.

Pires, Donald, Manifiesto gil, UCLA, (en lnea), disponible en

http://www.manifiestoagile.com

Extrem Porgramming(XP). Disponible en www.XProgramming.com

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.

Desventajas
Delimitar el alcance del proyecto con nuestro
cliente
Para mitigar esta desventaja se plantea definir un alcance a
alto nivel basado en la experiencia.

AUP (AGIL UNIFIED PROCESS)

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

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.

SCRUM
FIGURA 5.
ESQUEMA DE TRABAJO SCRUM

Ventajas

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

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. Vital para su negocio

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.

FIGURA 6.
ESQUEMA DE TRABAJO ICONIX

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.

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 6
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.

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 posible.

1.

Diferencias:
TABLA 1.
DIFERENCIAS ENTRE METODOLOGA TRADICIONALES Y GILES

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.

Metodologas
Tradicionales

Metodologas Agiles

Basadas en normas provenientes

de estndares seguidos por el
entorno de desarrollo
Cierta resistencia a los cambios

Basadas
en
heursticas
provenientes de prcticas de
produccin de cdigo
Especialmente preparados para
cambios durante el proyecto
Impuestas internamente (por el
equipo)
Proceso menos controlado, con
pocos principios.

Impuestas externamente
Proceso mucho ms controlado,
con numerosas polticas/normas

El cliente interacta con el

equipo de desarrollo mediante
reuniones
Ms artefactos
Ms roles
Grupos grandes y posiblemente
distribuidos
La arquitectura del software es
esencial y se
expresa mediante modelos
Existe un contrato prefijado

El cliente es parte del equipo de

desarrollo

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.

Pocos artefactos
Pocos roles
Grupos
pequeos
(<10
integrantes) y trabajando en el
mismo sitio
Menos nfasis en la arquitectura
del software
No existe contrato tradicional o
al menos es bastante flexible

Ofrecemos una comparativa entre cada uno de las etapas

ms comunes del desarrollo de SW y los enfoques de
metodologas revisados.

Modelo
de
Proceso

TABLA 2.
DIFERENCIAS POR ETAPAS Y ENFOQUE METODOLOGICO

MODELOS
RIGUROSOS

ETAPA
Anlisis de
requerimientos

Planificacin
predictiva y
aislada

MODELOS
AGILES
Planificacin
adpatativa:Entregas
frecuentes +
colaboracin del
cliente

Planificacin
Diseo flexible y
Extensible +
modelos +
Documentacin
exhaustiva

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

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

Pruebas
Puesta en
Produccin

Curva de
aprendizaje

Herramienta
de integracin

RUP

Lenta

Alto Soporte

ICONIX

Rpida

Algn Soporte
Disponible

XP

Rpida

No mencionado

SCRUM

Rpida

No mencionado

RUP
ICONIX
XP
SCRUM

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

Tamao
del
Equipo

LiderazgoColaboracin:
empoderamiento
+auto-organizacin

Complejidad
del Problema

Medio /
Extenso
Pequeo /
Medio
Pequeo

Medio / Alto

Pequeo

Medio / Alto

Alto
Soporte
Algn
Soporte
Disponible
Algn
Soporte
Disponible
Algn
Soporte
Disponible

CONCLUSIONES

Por las caractersticas del Proyecto

Modelo
de
Proceso

Soporte
Externo

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

Adems presentamos un cuadro de comparacin por cada

aspecto analizado y lo ponemos a consideracin:

Por la curva de Aprendizaje

Pequeo / Medio
Medio / Alto

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 mementos cruciales del
proyecto, adems debe tener la capacidad de ser
equipos auto-gestionados, 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
Las metodologas giles se deberan aplicar en
proyectos donde exista mucha incertidumbre donde el
entorno es voltil, donde los requisitos no se conocen
con exactitud, mientras que las metodologas

tradicionales obligan al cliente a tomar las decisiones

al inicio del proyecto.
REFLEXIN
Alguna recomendacin para los lectores de este
Artculo?
gran giro a la industria del software. Por ltimo, que
entiendan la importancia de la gente. Con este fin voy a hacer
una ltima analoga: el dueo de una fbrica de coches sale a
las 6 de la tarde, y ah tiene su fbrica, con su valor intacto;
puede venderla y recuperar su inversin. En cambio, el dueo
de una fbrica de software, a las 8 de la noche que sus
empleados ya se fueron a su casa, est descapitalizado. Lo
nico que tiene son escritorios y unas mquinas depreciadas.

Como industria, debemos reconocer que estamos hechos de

personas, y que stas son nuestro principal activo. As que
debemos tenerlas bien aceitadas (a travs de capacitacin y
motivacin) para obtener su mximo rendimiento.

BIBLIOGRAFA
[ 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

Primero, que conozcan y apliquen las tcnicas de

ingeniera de software. Segundo, que se incorporen de
lleno mtodos de calidad en sus procesos y que la
forma ms eficiente y efectiva de hacer las cosas, es
hacerlas bien a la primera vez y con ello daremos un