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
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.
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
y 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
Visin y Alcances:
Transicin
La fase de visin y alcances trata uno de los requisitos ms
Ventajas fundamentales para el xito del proyecto, la unificacin
Evaluacin en cada fase que permite cambios del equipo detrs de una visin comn. El equipo debe
de objetivos tener una visin clara de lo que quisiera lograr para el
Funciona bien en proyectos de innovacin. cliente y ser capaz de indicarlo en trminos que motivarn
Es sencillo, ya que sigue los pasos intuitivos a todo el equipo y al cliente. Se definen los lderes y
necesarios a la hora de desarrollar el responsables del proyecto, adicionalmente se identifican
software. las metas y objetivos a alcanzar; estas ltimas se deben
Seguimiento detallado en cada una de las respetar durante la ejecucin del proyecto en su totalidad,
fases. y se realiza la evaluacin inicial de riesgos del proyecto.

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:

Durante esta fase el equipo realice la mayor parte de la

Descripcin
construccin de los componentes (tanto documentacin
como cdigo), sin embargo, se puede realizar algn trabajo
MSF es un compendio de las mejores prcticas en cuanto a
de desarrollo durante la etapa de estabilizacin en
administracin de proyectos se refiere. Ms que una
respuesta a los resultados de las pruebas. La
metodologa rgida de administracin de proyectos, MSF
infraestructura tambin es desarrollada durante esta fase.
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
Visin y Alcances.
condiciones realistas. El equipo se enfoca en priorizar y
Planificacin. resolver errores y preparar la solucin para el lanzamiento.
Desarrollo.
Estabilizacin. Implantacin:
Implantacin.
Durante esta fase el equipo implanta la tecnologa base y
4
Microsoft Solution Framework, (en lnea), los componentes relacionados, estabiliza la instalacin,
disponible en http://www.gpicr.com/msf.aspx

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
La planificacin adaptativa permite estar preparados para
el cambio ya que lo hemos introducido en nuestro proceso
5 6
Pires, Donald, Manifiesto gil, UCLA, (en lnea), disponible en
http://www.manifiestoagile.com
5
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
regresin. Se aconseja escribir el cdigo de la
prueba antes de la codificacin.
Extrem Porgramming(XP). Disponible en www.XProgramming.com
 Programacin por parejas: se recomienda que Delimitar el alcance del proyecto con nuestro
las tareas de desarrollo se lleven a cabo por dos cliente
personas en un mismo puesto. Se supone que la
mayor calidad del cdigo escrito de esta manera Para mitigar esta desventaja se plantea definir un alcance a
-el cdigo es revisado y discutido mientras se alto nivel basado en la experiencia.
escribe- es ms importante que la posible prdida
de productividad inmediata. AUP (AGIL UNIFIED PROCESS)
Frecuente interaccin del equipo de
programacin con el cliente o usuario. Se FIGURA 4.
recomienda que un representante del cliente ESQUEMA DE TRABAJO AUP
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 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.
La presin esta a lo largo de todo el proyecto
y no en una entrega final Scrum es un proceso gil y liviano que sirve para
Desventajas administrar y controlar el desarrollo de software. El
desarrollo se realiza en forma iterativa e incremental (una

6
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 Y, el proceso se queda igual a la visin original de
cortos y regulares. De esta forma se puede adaptar en Jacobson del manejo de casos de uso, esto produce un
tiempo real el producto que se est construyendo a las resultado concreto, especfico y casos de uso fcilmente
necesidades del cliente. Se busca entregar software que entendible, que un equipo de un proyecto puede usar para
realmente resuelva las necesidades, aumentando la conducir el esfuerzo hacia un desarrollo real. La Figura 6
satisfaccin del cliente. muestra el cuadro del proceso. El diagrama retrata la
esencia del enfoque aerodinmico al desarrollo del
En Scrum, el equipo se focaliza en una nica cosa: software, que incluye un juego mnimo de diagramas de
construir software de calidad. Por el otro lado, la gestin UML y algunas valiosas tcnicas que se toman de los
de un proyecto Scrum se focaliza en definir cuales son las casos del uso para codificar rpida y eficazmente. El
caractersticas que debe tener el producto a construir (qu enfoque es flexible y abierto; siempre se puede seleccionar
construir, qu no y en qu orden) y en remover cualquier de los otros aspectos del UML para complementar los
obstculo que pudiera entorpecer la tarea del equipo de materiales bsicos.
desarrollo. Se busca que los equipos sean lo ms efectivos
y productivos posible. 1. Diferencias:
TABLA 1.
Scrum tiene un conjunto de reglas muy pequeo y muy 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
cambios durante el proyecto
Por otro lado, los desarrolladores encuentran un mbito 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 RUP, Grupos grandes y posiblemente Grupos pequeos (<10
pero le falta mucho para llegar al nivel del RUP. Tambin distribuidos integrantes) y trabajando en el
es relativamente pequeo y firme, como XP, pero no mismo sitio
La arquitectura del software es Menos nfasis en la arquitectura
desecha el anlisis y diseo que hace XP. Este proceso
esencial y se del software
tambin hace uso aerodinmico del UML mientras guarda 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

Ofrecemos una comparativa entre cada uno de las etapas

ms comunes del desarrollo de SW y los enfoques de
FIGURA 6. metodologas revisados.
ESQUEMA DE TRABAJO ICONIX
TABLA 2.

7
 DIFERENCIAS POR ETAPAS Y ENFOQUE METODOLOGICO Modelo Curva de Herramienta Soporte
de aprendizaje de integracin Externo
MODELOS ETAPA MODELOS Proceso
RIGUROSOS AGILES RUP Lenta Alto Soporte Alto
Soporte
Anlisis de ICONIX Rpida Algn Soporte Algn
requerimientos Planificacin
Planificacin adpatativa:Entregas
Disponible Soporte
predictiva y frecuentes + Disponible
aislada colaboracin del XP Rpida No mencionado Algn
cliente Soporte
Planificacin Disponible
SCRUM Rpida No mencionado Algn
Soporte
Diseo flexible y Diseo Diseo Simple: Disponible
Extensible + Documentacin
modelos + Mnima +
Documentacin Focalizado en la Con respecto a la curva de aprendizaje, vemos que los
exhaustiva comunicacin modelos giles, nos ofrecen una mayor ventaja pero con
Desarrollo Codificacin Transferencia de
ciertas limitaciones, ya que aun no hay sido explotadas a
individual con conocimiento: gran escala como lo es RUP que posee alto soporte y
Roles y Programacin en herramientas integrales que nos guan a travs del mismo,
responsabilidades pares + facilitando aplicar con mayor efectividad esta
estrictas conocimiento
colectivo
metodologa, permitiendo aprovecharla al mximo

Actividades de Pruebas Liderazgo- CONCLUSIONES

control]: Orientado Colaboracin:
a los hitos + Puesta en empoderamiento
Gestin Produccin +auto-organizacin El retrasar las decisiones en un proyecto de software
miniproyectos 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
Adems presentamos un cuadro de comparacin por cada metodologa gil debe poseer experiencia trabajando
aspecto analizado y lo ponemos a consideracin: con metodologas tradicionales, ya que la experiencia
es la que predomina en los mementos cruciales del
Por las caractersticas del Proyecto proyecto, adems debe tener la capacidad de ser
Modelo Tamao Tamao Complejidad equipos auto-gestionados, altamente motivados y con
de del del del Problema gran innovacin
Proceso Proceso Equipo
RUP Medio / Medio / Medio / Alto Las metodologas giles permiten disminuir costos y
Extenso Extenso brindar flexibilidad a los proyectos de software donde
ICONIX Pequeo / Pequeo / Pequeo / Medio la incertidumbre est presente
Medio Medio El uso de metodologas tradicionales es esencial al
XP Pequeo / Pequeo Medio / Alto inicio en un equipo de desarrollo de software
Medio Las metodologas giles se deberan aplicar en
SCRUM Pequeo / Pequeo Medio / Alto proyectos donde exista mucha incertidumbre donde el
Medio entorno es voltil, donde los requisitos no se conocen
con exactitud, mientras que las metodologas
tradicionales obligan al cliente a tomar las decisiones
En este cuadro se presenta una comparativa de las modelos al inicio del proyecto.
de proceso en cuanto a las caractersticas del proyecto,
analizamos el tamao del proceso, del equipo y la REFLEXIN
complejidad del problema para cada uno de los modelos.
Alguna recomendacin para los lectores de este
Podemos resaltar que: con un pequeo equipo de
Artculo?
desarrollo se puede realizar grandes proyectos, de alta
complejidad; es el caso de XP y SCRUM.
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
Por la curva de Aprendizaje
hacerlas bien a la primera vez y con ello daremos un
gran giro a la industria del software. Por ltimo, que
entiendan la importancia de la gente. Con este fin voy a hacer

8
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=167902&rl=1