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 METODOLOGA TRADICIONAL

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.
Palabras Claves Metodologa, RUP, MSF AUP, Scrum,
Metodologa Tradicional, Metodologa gil
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.
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.
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
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.

1
Roberth G. Figueroa, UTPL, Loja, rgfigueroa@utpl.edu.ec
2
Camilo J. Sols, UTPL, Loja, cjsolis@utpl.edu.ec
3
Armando Cabrera S,Docente-Investigador UTPL,Loja, aacabrera@utpl.edu.ec

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

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

Ventajas La fase de visin y alcances trata uno de los requisitos ms

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

MSF es un compendio de las mejores prcticas en cuanto a
administracin de proyectos se refiere. Ms que una
metodologa rgida de administracin de proyectos, MSF
es una serie de modelos que puede adaptarse a cualquier
proyecto de tecnologa de informacin.
Todo proyecto es separado en cinco principales fases:
Visin y Alcances.
Planificacin.
Desarrollo.
Estabilizacin.
Implantacin.
4
Microsoft Solution Framework, (en lnea),
disponible en http://www.gpicr.com/msf.aspx
construccin de los componentes (tanto documentacin
como cdigo), sin embargo, se puede realizar algn trabajo
de desarrollo durante la etapa de estabilizacin en
respuesta a los resultados de las pruebas. La
infraestructura tambin es desarrollada durante esta fase.
Estabilizacin:
En esta fase se conducen pruebas sobre la solucin, las
pruebas de esta etapa enfatizan el uso y operacin bajo
condiciones realistas. El equipo se enfoca en priorizar y
resolver errores y preparar la solucin para el lanzamiento.
Implantacin:
Durante esta fase el equipo implanta la tecnologa base y
los componentes relacionados, estabiliza la instalacin,

2
traspasa el proyecto al personal soporte y operaciones, y
obtiene la aprobacin final del cliente.
Modelo de roles
El modelo de equipos de MSF (MSF team model) fue
desarrollado para compensar algunas de las desventajas
impuestas por las estructuras jerrquicas de los equipos en
los proyectos tradicionales.
Los equipos organizados bajo este modelo son pequeos y
multidisciplinarios, en los cuales los miembros comparten
responsabilidades y balancean las destrezas del equipo
para mantenerse enfocados en el proyecto que estn
desarrollando. Comparten una visin comn del proyecto
y se enfocan en implementar la solucin, con altos
estndares de calidad y deseos de aprender.
El modelo de equipos de MSF tiene seis roles que
corresponden a las metas principales de un proyecto y son
responsables por las mismas. Cada rol puede estar
compuestos por una o ms personas, la estructura circular
del modelo, con valos del mismo tamao para todos los
roles, muestra que no es un modelo jerrquico y que cada
todos los roles son igualmente importantes en su aporte al
proyecto. Aunque los roles pueden tener diferentes niveles
de actividad durante las diversas etapas del proyecto,
ninguno puede ser omitido.
La comunicacin se pone en el centro del crculo para
mostrar que 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:
generalmente se definen como reas principales
la de Diseo de Arquitectura, Pruebas de
3
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
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".
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)
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.
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
4
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 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).
METODOLOGAS GILES.
Luego de varias opiniones tanto a favor como en contra de
las metodologas tradicionales se genera un nuevo
enfoque denominado, mtodos giles, que nace como
respuesta a los problemas detallados anteriormente y se
basa en dos aspectos puntuales, el retrasar las decisiones y
la planificacin adaptativa; permitiendo potencia an ms
el desarrollo de software a gran escala.
Como resultado de esta nueva teora se crea un Manifiesto
gil5 cuyas principales ideas son:
Los individuos y las interacciones entre ellos son
ms importantes que las herramientas y los
procesos empleados.
Es ms importante crear un producto software
que funcione que escribir documentacin
exhaustiva.
La colaboracin con el cliente debe prevalecer
sobre la negociacin de contratos.
La capacidad de respuesta ante un cambio es ms
importante que el seguimiento estricto de un plan.
Entre los principales mtodos giles tenemos el XP
(eXtreme Programming), Scrum, Iconix, Cristal Methods,
AUP entre otras.
Estas metodologas ponen de relevancia que la capacidad
de respuesta a un cambio es ms importante que el
seguimiento estricto de un plan. Nos lo proponen porque
para muchos clientes esta flexibilidad ser una ventaja
competitiva y porque estar preparados para el cambio
significar reducir su coste.
Retrasar las decisiones y Planificacin Adaptativa
Es el eje en cual gira la metodologa gil, el retrasar las
decisiones 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:
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
5 6
Pires, Donald, Manifiesto gil, UCLA, (en lnea), disponible en
http://www.manifiestoagile.com
5
La planificacin adaptativa permite estar preparados para
el cambio ya que lo hemos introducido en nuestro proceso
de desarrollo, adems hacer una planificacin adaptativa
consiste en tomar decisiones a lo largo del proyecto,
estaremos transformando el proyecto en un conjunto de
proyectos pequeos.
Esta planificacin a corto plazo nos permitir tener
software disponible para nuestros clientes y adems ir
aprendiendo del feedback para hacer nuestra planificacin
ms sensible, sea ante inconvenientes que aceleren o
retrasen nuestro producto. A continuacin se detalla el XP
que es el ms aceptado dentro del desarrollo de SW
EXTREME PROGRAMMING (XP)
FIGURA 36.
MODELO DE EXTREME PROGRAMMING
Es la ms destacada de los procesos giles de desarrollo de
software formulada por Kent Beck. La programacin
extrema se diferencia de las metodologas tradicionales
principalmente en que pone ms nfasis en la
adaptabilidad que en la previsibilidad.
Los defensores de XP consideran que los cambios de
requisitos sobre la marcha son un aspecto natural,
inevitable e incluso deseable del desarrollo de proyectos.
Creen que ser capaz de adaptarse a los cambios de
requisitos en cualquier punto de la vida del proyecto es
una aproximacin mejor y ms realista que intentar definir
todos los requisitos al comienzo del proyecto e invertir
esfuerzos despus en controlar los cambios en los
requisitos.
Las caractersticas fundamentales del mtodo son:
Desarrollo iterativo e incremental: pequeas
mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente
repetidas y automatizadas, incluyendo pruebas de
Extrem Porgramming(XP). Disponible en www.XProgramming.com
 regresin. Se aconseja escribir el cdigo de la La presin esta a lo largo de todo el proyecto
prueba antes de la codificacin. y no en una entrega final
Programacin por parejas: se recomienda que Desventajas
las tareas de desarrollo se lleven a cabo por dos Delimitar el alcance del proyecto con nuestro
personas en un mismo puesto. Se supone que la cliente
mayor calidad del cdigo escrito de esta manera -
el cdigo es revisado y discutido mientras se Para mitigar esta desventaja se plantea definir un alcance a
escribe- es ms importante que la posible prdida alto nivel basado en la experiencia.
de productividad inmediata.
Frecuente interaccin del equipo de AUP (AGIL UNIFIED PROCESS)
programacin con el cliente o usuario. Se
recomienda que un representante del cliente FIGURA 4.
trabaje junto al equipo de desarrollo. ESQUEMA DE TRABAJO AUP
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 El AUP es un acercamiento aerodinmico a desarrollo
que los posibles errores sern detectados. del software basado en el Proceso Unificado Rational
Simplicidad en el cdigo: es la mejor manera de de IBM (RUP), basado en disciplinas y entregables
que las cosas funcionen. Cuando todo funcione se incrementales con el tiempo. El ciclo de vida en
podr aadir funcionalidad si es necesario. La proyectos grandes es serial mientras que en los
programacin extrema apuesta que en ms pequeos es iterativo. Las disciplinas de Aup son:
sencillo hacer algo simple y tener un poco de Modelado
trabajo extra para cambiarlo si se requiere, que Implementacin
realizar algo complicado y quizs nunca Prueba
utilizarlo. Despliegue
Administracin de la configuracin
La simplicidad y la comunicacin son extraordinariamente Administracin o gerencia del Proyecto
complementarias. Con ms comunicacin resulta ms fcil Entorno
identificar qu se debe y qu no se debe hacer. Mientras
ms simple es el sistema, menos tendr que comunicar
SCRUM
sobre este, lo que lleva a una comunicacin ms completa,
FIGURA 5.
especialmente si se puede reducir el equipo de ESQUEMA DE TRABAJO SCRUM
programadores.

Ventajas

Apropiado para entornos voltiles

Estar preparados para el cambio, significa
reducir su coste.
Planificacin ms transparente para nuestros
clientes, conocen las fechas de entrega de
funcionalidades. Vital para su negocio
Permitir definir en cada iteracin cuales son
los objetivos de la siguiente
Permite tener realimentacin de los usuarios
muy til.

6
Scrum es un proceso gil y liviano que sirve para FIGURA 6.
administrar y controlar el desarrollo de software. El ESQUEMA DE TRABAJO ICONIX
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 Y, el proceso se queda igual a la visin original de
tiempo real el producto que se est construyendo a las Jacobson del manejo de casos de uso, esto produce un
necesidades del cliente. Se busca entregar software que resultado concreto, especfico y casos de uso fcilmente
realmente resuelva las necesidades, aumentando la entendible, que un equipo de un proyecto puede usar para
satisfaccin del cliente. conducir el esfuerzo hacia un desarrollo real. La Figura 6
muestra el cuadro del proceso. El diagrama retrata la
En Scrum, el equipo se focaliza en una nica cosa: esencia del enfoque aerodinmico al desarrollo del
construir software de calidad. Por el otro lado, la gestin software, que incluye un juego mnimo de diagramas de
de un proyecto Scrum se focaliza en definir cuales son las UML y algunas valiosas tcnicas que se toman de los
caractersticas que debe tener el producto a construir (qu casos del uso para codificar rpida y eficazmente. El
construir, qu no y en qu orden) y en remover cualquier enfoque es flexible y abierto; siempre se puede seleccionar
obstculo que pudiera entorpecer la tarea del equipo de de los otros aspectos del UML para complementar los
desarrollo. Se busca que los equipos sean lo ms efectivos materiales bsicos.
y productivos posible.
1. Diferencias:
Scrum tiene un conjunto de reglas muy pequeo y muy TABLA 1.
DIFERENCIAS ENTRE METODOLOGA TRADICIONALES Y GILES
simple y est basado en los principios de inspeccin
continua, adaptacin, auto-gestin e innovacin. El cliente
Metodologas Metodologas Agiles
se entusiasma y se compromete con el proyecto dado que
Tradicionales
ve crecer el producto iteracin a iteracin y encuentra las
Basadas en normas provenientes Basadas en heursticas
herramientas para alinear el desarrollo con los objetivos de de estndares seguidos por el provenientes de prcticas de
negocio de su empresa. entorno de desarrollo produccin de cdigo
Cierta resistencia a los cambios Especialmente preparados para
Por otro lado, los desarrolladores encuentran un mbito cambios durante el proyecto
Impuestas externamente Impuestas internamente (por el
propicio para desarrollar sus capacidades profesionales y equipo)
esto resulta en un incremento en la motivacin de los Proceso mucho ms controlado, Proceso menos controlado, con
integrantes del equipo. con numerosas polticas/normas pocos principios.
El cliente interacta con el El cliente es parte del equipo de
equipo de desarrollo mediante desarrollo
ICONIX reuniones
Ms artefactos Pocos artefactos
Ms roles Pocos roles
El proceso de ICONIX maneja casos de uso, como el
Grupos grandes y posiblemente Grupos pequeos (<10
RUP, pero le falta mucho para llegar al nivel del RUP. distribuidos integrantes) y trabajando en el
Tambin es relativamente pequeo y firme, como XP, pero mismo sitio
no desecha el anlisis y diseo que hace XP. Este proceso La arquitectura del software es Menos nfasis en la arquitectura
tambin hace uso aerodinmico del UML mientras guarda esencial y se del software
expresa mediante modelos
un enfoque afilado en el seguimiento de requisitos.
Existe un contrato prefijado No existe contrato tradicional o
al menos es bastante flexible

7
Ofrecemos una comparativa entre cada uno de las etapas
ms comunes del desarrollo de SW y los enfoques de Por la curva de Aprendizaje
metodologas revisados.
Modelo Curva de Herramienta Soporte
TABLA 2. de aprendizaje de integracin Externo
DIFERENCIAS POR ETAPAS Y ENFOQUE METODOLOGICO Proceso
RUP Lenta Alto Soporte Alto
MODELOS ETAPA MODELOS Soporte
RIGUROSOS AGILES ICONIX Rpida Algn Soporte Algn
Disponible Soporte
Anlisis de Disponible
requerimientos Planificacin XP Rpida No mencionado Algn
Planificacin adpatativa:Entregas
predictiva y frecuentes +
Soporte
aislada colaboracin del Disponible
cliente SCRUM Rpida No mencionado Algn
Soporte
Planificacin
Disponible

Diseo flexible y Diseo Diseo Simple: Con respecto a la curva de aprendizaje, vemos que los
Extensible + Documentacin
modelos + Mnima + modelos giles, nos ofrecen una mayor ventaja pero con
Documentacin Focalizado en la ciertas limitaciones, ya que aun no hay sido explotadas a
exhaustiva comunicacin gran escala como lo es RUP que posee alto soporte y
herramientas integrales que nos guan a travs del mismo,
Desarrollo Codificacin Transferencia de
individual con conocimiento:
facilitando aplicar con mayor efectividad esta
Roles y Programacin en metodologa, permitiendo aprovecharla al mximo
responsabilidades pares +
estrictas conocimiento
colectivo CONCLUSIONES
Actividades de Pruebas Liderazgo- El retrasar las decisiones en un proyecto de software
control]: Orientado Colaboracin:
a los hitos + empoderamiento
permite potenciar el valor del producto tanto para el
Puesta en cliente como al equipo o empresa que desarrolla
Gestin Produccin +auto-organizacin
miniproyectos Para que un grupo de desarrollo adopte una
metodologa gil debe poseer experiencia trabajando
con metodologas tradicionales, ya que la experiencia
Adems presentamos un cuadro de comparacin por cada es la que predomina en los mementos cruciales del
aspecto analizado y lo ponemos a consideracin: proyecto, adems debe tener la capacidad de ser
equipos auto-gestionados, altamente motivados y con
Por las caractersticas del Proyecto gran innovacin
Modelo Tamao Tamao Complejidad
de del del del Problema Las metodologas giles permiten disminuir costos y
Proceso Proceso Equipo brindar flexibilidad a los proyectos de software donde
RUP Medio / Medio / Medio / Alto la incertidumbre est presente
Extenso Extenso El uso de metodologas tradicionales es esencial al
ICONIX Pequeo / Pequeo / Pequeo / Medio inicio en un equipo de desarrollo de software
Medio Medio Las metodologas giles se deberan aplicar en
XP Pequeo / Pequeo Medio / Alto proyectos donde exista mucha incertidumbre donde el
Medio entorno es voltil, donde los requisitos no se conocen
SCRUM Pequeo / Pequeo Medio / Alto con exactitud, mientras que las metodologas
Medio tradicionales obligan al cliente a tomar las decisiones
al inicio del proyecto.

En este cuadro se presenta una comparativa de las modelos REFLEXIN

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.
Alguna recomendacin para los lectores de este
Artculo?
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

8
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/wp-
content/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=1
67902&rl=1