METODOLOGAS TRADICIONALES VS.

METODOLOGAS GILES
Roberth G. Figueroa
1
, Camilo J. Sols
2
Armando A. Cabrera
3
Universidad Tcnica Particular de Loja, Escuela de Ciencias en Computacin
Resumen Desarrollar un buen softare de!ende de un
sinn"mero de a#ti$idades % eta!as, donde el im!a#to de
elegir la me&or metodologa !ara un e'ui!o, en un
determinado !ro%e#to es tras#endental !ara el ()ito del
!rodu#to. *l !a!el !re!onderante de las metodologas es
sin duda esen#ial en un !ro%e#to % en el !aso ini#ial, 'ue
debe en#a&ar en el e'ui!o, guiar % organi+ar a#ti$idades
'ue #onlle$en a las metas tra+adas en el gru!o.
*n el !resente traba&o se detallan los dos grandes
enfo'ues, tanto metodologas tradi#ionales %
metodologas ,giles, las !rimeras est,n !ensadas !ara el
uso e)hausti$o de do#umenta#i-n durante todo el #i#lo del
!ro%e#to mientras 'ue las segundas !onen $ital
im!ortan#ia en la #a!a#idad de res!uesta a los #ambios,
la #onfian+a en las habilidades del e'ui!o % al mantener
una buena rela#i-n #on el #liente. Se $er,n diferen#ias,
$enta&as, des$enta&as % #ual !uede en#a&ar en un !ro%e#to
de softare, es !or ello 'ue, ofre#emos una gua de&ando
libertad de ele##i-n !ara el le#tor el !oder &u+gar % elegir
la me&or metodologa 'ue se ada!te a su e'ui!o de
desarrollo.
Palabras Claves .etodologa, R/0, .SF A/0,
S#rum, .etodologa 1radi#ional, .etodologa 2gil
INTRODUCCIN
Dentro del desarrollo de software y a la altiva necesidad
de que los proyectos lleuen al !ito y o"tener un
producto de ran valor para nuestros clientes, eneran
randes cam"ios en las metodolo#as adoptadas por los
equipos para cumplir sus o"jetivos, puesto que, unas se
adaptan mejor que otras, al conte!to del proyecto
"rindando mejores ventajas$
Es por eso de la importancia de una metodolo#a ro"usta
que ajustada en un equipo cumpla con sus metas, y
satisfaa mas all% de las necesidades definidas al inicio del
proyecto$
El !ito del producto depende en ran parte de la
metodolo#a escoida por el equipo, ya sea tradicional o
%il, donde los equipos ma!imicen su potencial, aumenten
la calidad del producto con los recursos y tiempos
esta"lecidos$
METODOLOGA TRADICIONAL
&l 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 metodolo#as
e!istentes en otras %reas y adaptarlas al desarrollo de
software$ Esta nueva etapa de adaptacin conten#a el
desarrollo dividido en etapas de manera secuencial que de
alo mejora"a la necesidad latente en el campo del
software$
Entre las principales metodolo#as tradicionales tenemos
los ya tan conocidos 'UP y ()* entre otros, que centran
su atencin en llevar una documentacin e!+austiva 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$
,tra de las caracter#sticas importantes dentro de este
enfoque tenemos los altos costos al implementar un
cam"io y al no ofrecer una "uena solucin para proyectos
donde el entorno es vol%til$
Las metodolo#as tradicionales -formales. se focali/an en
documentacin, planificacin y procesos$ -Plantillas,
tcnicas de administracin, revisiones, etc$., a
continuacin se detalla 'UP uno de los mtodos m%s
usados dentro de los mtodos tradicionales
RATIONAL UNIFIED PROCESS (RUP)
*01U'&2$
P',CE), U30*0C&D, '&T0,3&L
2
'o"ert+ 1$ *iueroa, UTPL, Loja, rfiueroa4utpl$edu$ec
5
Camilo 6$ )ol#s, UTPL, Loja, cjsolis4utpl$edu$ec
7
&rmando Ca"rera ),Docente80nvestiador UTPL,Loja, aaca"rera4utpl$edu$ec
2
'UP es un proceso formal9 Provee un acercamiento
disciplinado para asinar tareas y responsa"ilidades dentro
de una orani/acin de desarrollo$ )u o"jetivo es aseurar
la produccin de software de alta calidad que satisfaa los
requerimientos de los usuarios finales -respetando
cronorama y presupuesto.$ *ue desarrollado por 'ational
)oftware, y est% interado con toda la suite 'ational de
+erramientas$ Puede ser adaptado y e!tendido para
satisfacer las necesidades de la orani/acin que lo adopte$
-Customi/acin.$ Es uiado por casos de uso y centrado en
la arquitectura, y utili/a U(L como lenuaje de notacin$
Fases
Las cuatro fases del ciclo de vida son9
Concepcin
Ela"oracin
Construccin
Transicin
Ventajas
Evaluacin en cada fase que permite cam"ios
de o"jetivos
*unciona "ien en proyectos de innovacin$
Es sencillo, ya que siue los pasos intuitivos
necesarios a la +ora de desarrollar el
software$
)euimiento detallado en cada una de las
fases$
Desventajas
La evaluacin de riesos es compleja
E!cesiva fle!i"ilidad para alunos proyectos
Estamos poniendo a nuestro cliente en una
situacin que puede ser muy incmoda para l$
3uestro cliente de"er% ser capa/ de descri"ir y
entender a un ran nivel de detalle para poder
acordar un alcance del proyecto con l$
MICROSOFT SOLUTION FRAMEOR! (MSF)
"
Des#$%&#%'n
()* es un compendio de las mejores pr%cticas en cuanto a
administracin de proyectos se refiere$ (%s que una
metodolo#a r#ida de administracin de proyectos, ()*
es una serie de modelos que puede adaptarse a cualquier
proyecto de tecnolo#a de informacin$
T()( &$(*e#t( es se&a$a)( en #%n#( &$%n#%&a+es ,ases-
:isin y &lcances$
Planificacin$
Desarrollo$
Esta"ili/acin$
;
(icrosoft )olution *ramewor<, -en l#nea.,
disponi"le en +ttp9==www$picr$com=msf$asp!
0mplantacin$
*01U'& 5$
(,DEL, DE E>U0P, DE ()*
V%s%'n * A+#an#es-
La fase de visin y alcances trata uno de los requisitos m%s
fundamentales para el !ito del proyecto, la unificacin
del equipo detr%s de una visin com?n$ El equipo de"e
tener una visin clara de lo que quisiera lorar para el
cliente y ser capa/ de indicarlo en trminos que motivar%n
a todo el equipo y al cliente$ )e definen los l#deres y
responsa"les del proyecto, adicionalmente se identifican
las metas y o"jetivos a alcan/ar@ estas ?ltimas se de"en
respetar durante la ejecucin del proyecto en su totalidad,
y se reali/a la evaluacin inicial de riesos del proyecto$
P+an%,%#a#%'n-
Es en esta fase es cuando la mayor parte de la planeacin
para el proyecto es terminada$ El equipo prepara las
especificaciones funcionales, reali/a el proceso de diseAo
de la solucin, y prepara los planes de tra"ajo,
estimaciones de costos y cronoramas de los diferentes
entrea"les del proyecto$
Desa$$(++(-
Durante esta fase el equipo realice la mayor parte de la
construccin de los componentes -tanto documentacin
como cdio., sin em"aro, se puede reali/ar al?n
tra"ajo de desarrollo durante la etapa de esta"ili/acin en
respuesta a los resultados de las prue"as$ La
infraestructura tam"in es desarrollada durante esta fase$
Esta.%+%/a#%'n-
En esta fase se conducen prue"as so"re la solucin, las
prue"as de esta etapa enfati/an el uso y operacin "ajo
condiciones realistas$ El equipo se enfoca en priori/ar y
resolver errores y preparar la solucin para el lan/amiento$
I0&+anta#%'n-
5
Durante esta fase el equipo implanta la tecnolo#a "ase y
los componentes relacionados, esta"ili/a la instalacin,
traspasa el proyecto al personal soporte y operaciones, y
o"tiene la apro"acin final del cliente$
M()e+( )e $(+es
El modelo de equipos de ()* -()* team model. fue
desarrollado para compensar alunas de las desventajas
impuestas por las estructuras jer%rquicas de los equipos en
los proyectos tradicionales$
Los equipos orani/ados "ajo este modelo son pequeAos y
multidisciplinarios, en los cuales los miem"ros comparten
responsa"ilidades y "alancean las destre/as del equipo
para mantenerse enfocados en el proyecto que est%n
desarrollando$ Comparten una visin com?n del proyecto
y se enfocan en implementar la solucin, con altos
est%ndares de calidad y deseos de aprender$
El modelo de equipos de ()* tiene seis roles que
corresponden a las metas principales de un proyecto y son
responsa"les por las mismas$ Cada rol puede estar
compuestos por una o m%s personas, la estructura circular
del modelo, con valos del mismo tamaAo para todos los
roles, muestra que no es un modelo jer%rquico y que cada
todos los roles son iualmente importantes en su aporte al
proyecto$ &unque los roles pueden tener diferentes niveles
de actividad durante las diversas etapas del proyecto,
ninuno puede ser omitido$
La comunicacin se pone en el centro del c#rculo para
mostrar que est% interada en la estructura y fluye en todas
direcciones$ El modelo apoya la comunicacin efectiva y
es esencial para el funcionamiento del mismo
Eje0&+( )e 0et()(+(12a MSF a&+%#a)a

Como ejemplo de una aplicacin de metodolo#a ()* a
un proyecto, a continuacin se descri"e el contenido de
cada una de las fases y, en la medida de lo posi"le, un
detalle de acciones concretas y estimacin de cara de
tra"ajo en trminos de jornadas, n?mero de personas
implicadas y perfil de las mismas$ El proyecto ejemplo se
trata de una implantacin de infraestructuras, en concreto,
miracin a Bindows 5CCC de una red de servidores$
Fase 3 4 Est$ate1%a * a+#an#e
En esta fase de"er#an tener luar los siuientes tra"ajos9
Ela"oracin y apro"acin del Documento de
&lcance y Estrateia definitivo9 de"e ser un
documento de consenso con la participacin del
mayor n?mero de aentes implicados en el
proyecto$ En este documento quedar%n
definitivamente reflejadas las funcionalidades y
servicios que, ineludi"lemente, de"e ofrecer la
solucin a implantar$
*ormacin del Equipo de Tra"ajo y distri"ucin
de competencias y responsa"ilidades9
eneralmente se definen como %reas principales
la de DiseAo de &rquitectura, Prue"as de
La"oratorio, Documentacin, Lo#stica y
Coordinacin$
Ela"oracin del Plan de Tra"ajo9 de"en marcarse
fec+as y contenidos para esta fase y las
siuientes$ Los mecanismos y protocolos de
intercam"io de informacin y coordinacin de"en
quedar suficientemente "ien esta"lecidos y
consensuados$
Ela"oracin de la matri/ de 'iesos y Plan de
Continencia9 los principales riesos detectados
de"en tener un plan de mitiacin y actuacin y
revisarse con periodicidad$
Para un proyecto de miracin a Bindows 5CCC podr#a
estimarse que los tra"ajos indicados pueden requerir en
torno a 5C jornadas de tra"ajo y la intervencin de un
Consultor de (icrosoft junto con el equipo de tra"ajo que
formen El cliente y el Partner$
Fase 5 4 P+an%,%#a#%'n * P$6e.a )e C(n#e&t(
De"en alcan/arse los siuientes o"jetivos e +itos9
Documento de Planificacin y DiseAo de
&rquitectura9 es el documento principal, donde se
descri"en en detalle los aspectos funcionales y
operativos de la nueva plataforma$ La apro"acin
de este documento es el +ito principal de esta
fase, y supone la directri/ ?ltima de todos los
tra"ajos tcnicos, que, a partir de ese momento,
de"en ser consistentes con esta 1u#a$ )i en el
curso de las fases sucesivas fuera necesario
revisar estos contenidos, se de"er% +acer por
acuerdo y conocimiento de todo el equipo de
tra"ajo y se llevar% un reistro de versiones que
permita +acer un seuimiento adecuado de estas
revisiones$
Documento de Plan de La"oratorio 8 Prue"a de
Concepto9 la descripcin del contenido del
la"oratorio de prue"a de concepto, los diversos
escenarios a simular, los criterios de valide/, el
control de incidencias y las mtricas de calidad
son o"jetivos a cu"rir en este documento$ Es un
documento din%mico, en el que se recoe la idea
y la e!periencia pr%ctica al llevarla a ca"o en
entorno controlado y aislado$ La etapa de prue"a
de la"oratorio concluye cuando la maqueta ofrece
todos los servicios y funciones descritos en el
Documento de &lcance y Estrateia, y su rado
de esta"ilidad y rendimiento es considerado como
DsuficienteD$
Ea"itualmente, en las propuestas de preventa no se pueden
indicar con precisin par%metros como el esfuer/o tcnico,
tiempo o coste definitivo que puede suponer esta fase$ De
otras e!periencias anteriores se puede o"tener una relacin
de tra"ajos slo a t#tulo orientativo, y que de"e ser
revisado y acordado por todas las partes9
7
El cmputo de jornadas para la relacin de actividades
descritas -que como se o"serva slo recoen las relativas a
la Planificacin y DiseAo, y deja aparte las necesarias para
ela"orar el plan de (iracin., ofrecer#a este resultado9
6ornadas totales9 FC -apro!$ ; meses.
6ornadas = tcnico del P&'T3E'9 2GC jornadas -5
personas.
6ornadas = tcnico del CL0E3TE9 22C jornadas -(a!$ 5
personas.
Fase 7 8 Esta.%+%/a#%'n
La solucin implantada en la maqueta se pasa a un entorno
real de e!plotacin, restrinido en n?mero de usuarios y
en condiciones tales que se pueda llevar un control
efectivo de la situacin$ Los +itos y o"jetivos
fundamentales de esta fase son9
Se+e##%'n )e+ ent($n( )e &$6e.a &%+(t(- se
acordar% la composicin y u"icacin del conjunto
de m%quinas y usuarios que entrar%n en la prue"a$
Esta seleccin se recomienda que se +aa
atendiendo a la mayor variedad posi"le de casos,
de manera que puedan aflorar el m%!imo de
incidentes potenciales en el menor tiempo
posi"le$ La dimensin de la muestra tiene
tam"in que calcularse, sin perder de vista que la
prue"a piloto no es el desplieue propiamente,
sino una fase de o"servacin en la que es
a"solutamente cr#tico esta"lecer unos cauces
efectivos de tratamiento de los errores$
Gest%'n )e In#%)en#%as- aunque esta la"or se
+a"r% iniciado en la fase anterior, el !ito de la
prue"a piloto depender% de que se forme un
sistema de recoida de incidentes -+elpdes< o
similar., de atencin al usuario -formacin,
consultas. y de resolucin de pro"lemas y
documentacin de los mismos -versionado de la
plataforma.$
Rev%s%'n )e +a )(#60enta#%'n ,%na+ )e
A$96%te#t6$a- el documento de Planificacin y
DiseAo de &rquitectura se puede ver alterado
parcialmente como resultado de esta fase$ El
documento final, apro"ado por consenso, supone
el principal documento del Proyecto y la
culminacin de los tra"ajos de diseAo, al menos
en sus l#neas principales$ Este documento se
considerar% definitivo cuando la solucin puesta
en marc+a se muestre esta"le y el n?mero de
incidencias raves -de intervencin o de
resolucin. sea nulo y la cantidad de las
consideradas leves quede por de"ajo de un l#mite
esta"lecido en las (tricas de Calidad$
E+a.($a#%'n )e +a )(#60enta#%'n )e
F($0a#%'n * O&e$a#%(nes- con vistas al soporte
post proyecto y los proramas de formacin a
usuarios y administradores, en esta fase de"en
ela"orarse las 1u#as de Usuario, de
&dministracin, las Dpaso8a8pasoD, y otros cuyos
contenidos de"en acordarse previamente$
E+a.($a#%'n )e+ P+an )e Des&+%e16e- se de"e
consensuar la fec+a de finali/acin de la fase
Piloto, y las condiciones de calidad que de"e
cumplir la solucin final para iniciar el
desplieue$ En el Plan de"en identificarse las
fases, estrateia de implantacin, fec+as, tareas a
reali/ar, procedimientos de validacin y mtodo
de control de incidencias$
E+a.($a#%'n )e+ P+an )e F($0a#%'n- con
anterioridad al desplieue definitivo, de"e
+a"erse apro"ado el Plan de *ormacin orientado
a usuarios finales y administradores, y de"e
+acerse compati"le con los ritmos acordados en
el Plan de Desplieue$
El tiempo necesario para a"ordar esta fase es varia"le y
depende en parte de factores ajenos a la complejidad de la
propia solucin, como es la adecuada seleccin del
entorno de prue"a y el momento del aAo en que tena
luar -evitando que coincida con periodos de vacaciones o
puntas de tra"ajo cr#ticas como *in de &Ao.$ En proyectos
de similar enveradura se +a lleado al momento DError
*ree :ersinD en 7C jornadas de tra"ajo -apro!imadamente
mes y medio. con una muestra de GC usuarios$
Fase " 8 Des&+%e16e
)e llevar%n a ca"o en esta fase los planes diseAados en la
anterior, principalmente el de desplieue y el de
formacin$ Los principales tra"ajos e +itos a conseuir
son, en este caso, adem%s de los o"vios -implantacin de
la plataforma, puesta en servicio de todas las funciones,
formacin a los usuarios y administradores., los
siuientes9
Continuacin con las la"ores de recepcin de
incidencias, clasificacin, tratamiento, resolucin
y distri"ucin de fa!es o intervencin on8site$
'eistro de mejoras y suerencias,
funcionalidades no cu"iertas y novedades a
incorporar en sucesivas versiones de la
plataforma, incluyendo mejoras aportadas por los
fa"ricantes de software -nuevas versiones o
)ervice Pac<s, por ejemplo.
'evisin de las 1u#as y manuales de usuario,
rectificacin de errores y o"tencin de los
documentos de formacin definitivos$
Entrea de los documentos definitivos acordados
como Ddelivera"lesD en la fase de :ision )cope$
'evisin -si procede. de la matri/ de riesos, las
mtricas de calidad y esta"lecimiento de los
est%ndares de calidad y )L& definitivos$
*inalmente, entrea del Proyecto y cierre del
mismo, con o sin apertura de nuevo proyecto en
"ase a la informacin y e!periencia o"tenidas$
La duracin fase de desplieue, puesto que de"e
planificarse, no puede esta"lecerse a priori$ Depende de
numerosos factores e!ternos al propio proyecto
-incluyendo factores de oportunidad pol#tica o de neocio.
que pueden retardar o acelerar la conclusin$
;
La e!periencia demuestra que no +ay una relacin directa
entre n?mero de m%quinas y tiempo necesario para el
desplieue$ Los factores m%s relevantes en el c%lculo
suelen ser la dispersin o concentracin eor%fica, la
complejidad del proceso de miracin, el rado de
automati/acin alcan/ado, la e!periencia y nivel de los
tcnicos que reali/an la operacin y condicionantes de
calendario, a menudo con restricciones no tcnicas, sino
de otros tipos -las fec+as8o"jetivo suelen marcarse por
criterios de oportunidad de neocio.$
METODOLOGAS GILES.
Lueo de varias opiniones tanto a favor como en contra de
las metodolo#as tradicionales se enera un nuevo
enfoque denominado, mtodos %iles, que nace como
respuesta a los pro"lemas detallados anteriormente y se
"asa en dos aspectos puntuales, el retrasar las decisiones y
la planificacin adaptativa@ permitiendo potencia a?n m%s
el desarrollo de software a ran escala$
Como resultado de esta nueva teor#a se crea un .anifiesto
2gil
3
cuyas principales ideas son9
Los individuos y las interacciones entre ellos son
m%s importantes que las +erramientas y los
procesos empleados$
Es m%s importante crear un producto software
que funcione que escri"ir documentacin
e!+austiva$
La cola"oracin con el cliente de"e prevalecer
so"re la neociacin de contratos$
La capacidad de respuesta ante un cam"io es m%s
importante que el seuimiento estricto de un plan$
Entre los principales mtodos %iles tenemos el HP
-eHtreme Prorammin., )crum, 0coni!, Cristal (et+ods,
&UP entre otras$
Estas metodolo#as ponen de relevancia que la capacidad
de respuesta a un cam"io es m%s importante que el
seuimiento estricto de un plan$ 3os lo proponen porque
para muc+os clientes esta fle!i"ilidad ser% una ventaja
competitiva y porque estar preparados para el cam"io
sinificar reducir su coste$
Ret$asa$ +as )e#%s%(nes * P+an%,%#a#%'n A)a&tat%va
Es el eje en cual ira la metodolo#a %il, el retrasar las
decisiones tan como sea posi"le de manera responsa"le
ser% ventajoso tanto para el cliente como para la empresa,
lo cual permite siempre mantener una satisfaccin en el
cliente y por ende el !ito del producto, las principales
ventajas de retrasar las decisiones son9
G
Pires, Donald, I(anifiesto JilK, UCL&, -en l#nea., disponi"le en
+ttp9==www$manifiestoaile$com
'educe el n?mero de decisiones de alta
inversin que se toman$
'educe el n?mero de cam"ios necesario
en el proyecto$
'educe el coste del cam"io
La planificacin adaptativa permite estar preparados para
el cam"io ya que lo +emos introducido en nuestro proceso
de desarrollo, adem%s +acer una planificacin adaptativa
consiste en tomar decisiones a lo laro del proyecto,
estaremos transformando el proyecto en un conjunto de
proyectos pequeAos$
Esta planificacin a corto pla/o nos permitir% tener
software disponi"le para nuestros clientes y adem%s ir
aprendiendo del feed"ac< para +acer nuestra planificacin
m%s sensi"le, sea ante inconvenientes que aceleren o
retrasen nuestro producto$ & continuacin se detalla el HP
que es el m%s aceptado dentro del desarrollo de )B
E:TREME PROGRAMMING (:P)
*01U'& 7
L
$
(,DEL, DE EHT'E(E P',1'&((031
Es la m%s destacada de los procesos %iles de desarrollo de
software formulada por Ment Nec<$ La proramacin
e!trema se diferencia de las metodolo#as tradicionales
principalmente en que pone m%s nfasis en la
adapta"ilidad que en la previsi"ilidad$
Los defensores de HP consideran que los cam"ios de
requisitos so"re la marc+a son un aspecto natural,
inevita"le e incluso desea"le del desarrollo de proyectos$
Creen que ser capa/ de adaptarse a los cam"ios de
requisitos en cualquier punto de la vida del proyecto es
una apro!imacin mejor y m%s realista que intentar definir
todos los requisitos al comien/o del proyecto e invertir
esfuer/os despus en controlar los cam"ios en los
requisitos$
L
E!trem Porrammin-HP.$ Disponi"le en www$HProrammin$com
G
Las caracter#sticas fundamentales del mtodo son9
Desa$$(++( %te$at%v( e %n#$e0enta+- pequeAas
mejoras, unas tras otras$
P$6e.as 6n%ta$%as #(nt%n6as, frecuentemente
repetidas y automati/adas, incluyendo prue"as de
reresin$ )e aconseja escri"ir el cdio de la
prue"a antes de la codificacin$
P$(1$a0a#%'n &($ &a$ejas9 se recomienda que
las tareas de desarrollo se lleven a ca"o por dos
personas en un mismo puesto$ )e supone que la
mayor calidad del cdio escrito de esta manera
8el cdio es revisado y discutido mientras se
escri"e8 es m%s importante que la posi"le prdida
de productividad inmediata$
F$e#6ente %nte$a##%'n del equipo de
proramacin con el cliente o usuario$ )e
recomienda que un representante del cliente
tra"aje junto al equipo de desarrollo$
C($$e##%'n de todos los errores antes de aAadir
nueva funcionalidad$ Eacer entreas frecuentes$
Re,a#t($%/a#%'n del cdio, es decir, reescri"ir
ciertas partes del cdio para aumentar su
lei"ilidad y manteni"ilidad pero sin modificar su
comportamiento$ Las prue"as +an de aranti/ar
que en la refactori/acin no se +a introducido
nin?n fallo$
P$(&%e)a) )e+ #')%1( #(0&a$t%)a9 en ve/ de
dividir la responsa"ilidad en el desarrollo de cada
mdulo en rupos de tra"ajo distintos, este
mtodo promueve el que todo el personal pueda
correir y e!tender cualquier parte del proyecto$
Las frecuentes prue"as de reresin aranti/an
que los posi"les errores ser%n detectados$
S%0&+%#%)a) en e+ #')%1(9 es la mejor manera de
que las cosas funcionen$ Cuando todo funcione se
podr% aAadir funcionalidad si es necesario$ La
proramacin e!trema apuesta que en m%s
sencillo +acer alo simple y tener un poco de
tra"ajo e!tra para cam"iarlo si se requiere, que
reali/ar alo complicado y qui/%s nunca
utili/arlo$
La simplicidad y la comunicacin son e!traordinariamente
complementarias$ Con m%s comunicacin resulta m%s f%cil
identificar qu se de"e y qu no se de"e +acer$ (ientras
m%s simple es el sistema, menos tendr% que comunicar
so"re este, lo que lleva a una comunicacin m%s completa,
especialmente si se puede reducir el equipo de
proramadores$
Ventajas
&propiado para entornos vol%tiles
Estar preparados para el cam"io, sinifica
reducir su coste$
Planificacin m%s transparente para nuestros
clientes, conocen las fec+as de entrea de
funcionalidades$ :ital para su neocio
Permitir% definir en cada iteracin cuales son
los o"jetivos de la siuiente
Permite tener realimentacin de los usuarios
muy ?til$
La presin esta a lo laro de todo el proyecto
y no en una entrea final
Desventajas
Delimitar el alcance del proyecto con nuestro
cliente
Para mitiar esta desventaja se plantea definir un alcance a
alto nivel "asado en la e!periencia$
AUP (AGIL UNIFIED PROCESS)
*01U'& ;$
E)>UE(& DE T'&N&6, &UP
El &UP es un acercamiento aerodin%mico a desarrollo
del software "asado en el Proceso Unificado 'ational
de 0N( -'UP., "asado en disciplinas y entrea"les
incrementales con el tiempo$ El ciclo de vida en
proyectos randes es serial mientras que en los
pequeAos es iterativo$ Las disciplinas de &up son9
(odel ado
0mplementacin
Prue"a
Desplieue
&dministracin de la confiuracin
&dministracin o erencia del Proyecto
Entorno
SCRUM
*01U'& G$
E)>UE(& DE T'&N&6, )C'U(
L
)crum es un proceso %il y liviano que sirve para
administrar y controlar el desarrollo de software$ El
desarrollo se reali/a en forma iterativa e incremental -una
iteracin es un ciclo corto de construccin repetitivo.$
Cada ciclo o iteracin termina con una pie/a de software
ejecuta"le que incorpora nueva funcionalidad$ Las
iteraciones en eneral tienen una duracin entre 5 y ;
semanas$ )crum se utili/a como marco para otras pr%cticas
de inenier#a de software como 'UP o E!treme
Prorammin$
)crum se focali/a en priori/ar el tra"ajo en funcin del
valor que tena para el neocio, ma!imi/ando la utilidad
de lo que se construye y el retorno de inversin$ Est%
diseAado especialmente para adaptarse a los cam"ios 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 reulares$ De esta forma se puede adaptar en
tiempo real el producto que se est% construyendo a las
necesidades del cliente$ )e "usca entrear software que
realmente resuelva las necesidades, aumentando la
satisfaccin del cliente$
En )crum, el equipo se focali/a en una ?nica cosa9
construir software de calidad$ Por el otro lado, la estin
de un proyecto )crum se focali/a en definir cuales son las
caracter#sticas que de"e tener el producto a construir -qu
construir, qu no y en qu orden. y en remover cualquier
o"st%culo que pudiera entorpecer la tarea del equipo de
desarrollo$ )e "usca que los equipos sean lo m%s efectivos
y productivos posi"le$
)crum tiene un conjunto de relas muy pequeAo y muy
simple y est% "asado en los principios de inspeccin
continua, adaptacin, auto8estin e innovacin$ El cliente
se entusiasma y se compromete con el proyecto dado que
ve crecer el producto iteracin a iteracin y encuentra las
+erramientas para alinear el desarrollo con los o"jetivos de
neocio de su empresa$
Por otro lado, los desarrolladores encuentran un %m"ito
propicio para desarrollar sus capacidades profesionales y
esto resulta en un incremento en la motivacin de los
interantes del equipo$
ICONI:
El proceso de 0C,30H maneja casos de uso, como el
'UP, pero le falta muc+o para llear al nivel del 'UP$
Tam"in es relativamente pequeAo y firme, como HP,
pero no desec+a el an%lisis y diseAo que +ace HP$ Este
proceso tam"in +ace uso aerodin%mico del U(L mientras
uarda un enfoque afilado en el seuimiento de requisitos$
*01U'& L$
E)>UE(& DE T'&N&6, 0C,30H
O, el proceso se queda iual a la visin oriinal de
6aco"son del manejo de casos de uso, esto produce un
resultado concreto, espec#fico y casos de uso f%cilmente
entendi"le, que un equipo de un proyecto puede usar para
conducir el esfuer/o +acia un desarrollo real$ La *iura L
muestra el cuadro del proceso$ El diarama retrata la
esencia del enfoque aerodin%mico al desarrollo del
software, que incluye un jueo m#nimo de diaramas de
U(L y alunas valiosas tcnicas que se toman de los
casos del uso para codificar r%pida y efica/mente$ El
enfoque es fle!i"le y a"ierto@ siempre se puede seleccionar
de los otros aspectos del U(L para complementar los
materiales "%sicos$
3. D%,e$en#%as-
T&NL& 2$
D0*E'E3C0&) E3T'E (ET,D,L,1P& T'&D0C0,3&LE) O J10LE)
Met()(+(12as
T$a)%#%(na+es
Met()(+(12as A1%+es
Nasadas en normas provenientes
de est%ndares seuidos por el
entorno de desarrollo
Nasadas en +eur#sticas
provenientes de pr%cticas de
produccin de cdio
Cierta resistencia a los cam"ios Especialmente preparados para
cam"ios durante el proyecto
0mpuestas e!ternamente 0mpuestas internamente -por el
equipo.
Proceso muc+o m%s controlado,
con numerosas pol#ticas=normas
Proceso menos controlado, con
pocos principios$
Q
El cliente interact?a con el
equipo de desarrollo mediante
reuniones
El cliente es parte del equipo de
desarrollo
(%s artefactos Pocos artefactos
(%s roles Pocos roles
1rupos randes y posi"lemente
distri"uidos
1rupos pequeAos -R2C
interantes. y tra"ajando en el
mismo sitio
La arquitectura del software es
esencial y se
e!presa mediante modelos
(enos nfasis en la arquitectura
del software
E!iste un contrato prefijado 3o e!iste contrato tradicional o
al menos es "astante fle!i"le
,frecemos una comparativa entre cada uno de las etapas
m%s comunes del desarrollo de )B y los enfoques de
metodolo#as revisados$
T&NL& 5$
D0*E'E3C0&) P,' ET&P&) O E3*,>UE (ET,D,L,10C,
MODELOS
RIGUROSOS
ETAPA MODELOS
AGILES
Planificacin
predictiva y
aislada
Anlisis de
requerimientos Planificacin
adpatativa:Entregas
frecuentes +
colaboracin del
cliente
Planificacin
Diseo fle!ible y
E!tensible +
modelos +
Documentacin
e!"austiva
Diseo Diseo #imple:
Documentacin
$%nima +
&ocali'ado en la
comunicacin
Desarrollo
individual con
(oles y
responsabilidades
estrictas
)odificacin *ransferencia de
conocimiento:
Programacin en
pares +
conocimiento
colectivo
Actividades de
control+: ,rientado
a los "itos +
-estin
miniproyectos
Pruebas .idera'go/
)olaboracin:
empoderamiento
+auto/organi'acin
Puesta en
Produccin
&dem%s presentamos un cuadro de comparacin por cada
aspecto anali/ado y lo ponemos a consideracin9
Por las caracter#sticas del Proyecto
En este cuadro se presenta una comparativa de las modelos
de proceso en cuanto a las caracter#sticas del proyecto,
anali/amos el tamaAo del proceso, del equipo y la
complejidad del pro"lema para cada uno de los modelos$
Podemos resaltar que9 con un pequeAo equipo de
desarrollo se puede reali/ar randes proyectos, de alta
complejidad@ es el caso de HP y )C'U($

Por la curva de &prendi/aje
M()e+(
)e
P$(#es(
C6$va )e
a&$en)%/aje
;e$$a0%enta
)e %nte1$a#%'n
S(&($te
E<te$n(
'UP Lenta A+t( S(&($te A+t(
S(&($te
0C,30H R=&%)a &l?n )oporte
Disponi"le
&l?n
)oporte
Disponi"le
HP '%pida 3o mencionado &l?n
)oporte
Disponi"le
)C'U( '%pida 3o mencionado &l?n
)oporte
Disponi"le
Con respecto a la curva de aprendi/aje, vemos que los
modelos %iles, nos ofrecen una mayor ventaja pero con
ciertas limitaciones, ya que aun no +ay sido e!plotadas a
ran escala como lo es 'UP que posee alto soporte y
+erramientas interales que nos u#an a travs del mismo,
facilitando aplicar con mayor efectividad esta
metodolo#a, permitiendo aprovec+arla al m%!imo
CONCLUSIONES
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 rupo de desarrollo adopte una
metodolo#a %il de"e poseer e!periencia tra"ajando
con metodolo#as tradicionales, ya que la e!periencia
es la que predomina en los mementos cruciales del
proyecto, adem%s de"e tener la capacidad de ser
equipos auto8estionados, altamente motivados y con
ran innovacin
Las metodolo#as %iles permiten disminuir costos y
"rindar fle!i"ilidad a los proyectos de software donde
la incertidum"re est% presente
El uso de metodolo#as tradicionales es esencial al
inicio en un equipo de desarrollo de software
Las metodolo#as %iles se de"er#an aplicar en
proyectos donde e!ista muc+a incertidum"re donde el
entorno es vol%til, donde los requisitos no se conocen
con e!actitud, mientras que las metodolo#as
F
M()e+(
)e
P$(#es(
Ta0a>(
)e+
P$(#es(
Ta0a>(
)e+
E96%&(
C(0&+ej%)a)
)e+ P$(.+e0a
'UP (edio =
E!tenso
(edio =
E!tenso
(edio = &lto
0C,30H PequeAo =
(edio
PequeAo =
(edio
PequeAo = (edio
HP Pe96e>( ?
Me)%(
Pe96e>( (edio = &lto
)C'U( Pe96e>( ?
Me)%(
Pe96e>( (edio = &lto
tradicionales o"lian al cliente a tomar las decisiones
al inicio del proyecto$
REFLE:IN
@A+16na $e#(0en)a#%'n &a$a +(s +e#t($es )e este
A$t2#6+(A
Primero, que cono/can y apliquen las tcnicas de
inenier#a de software$ )eundo, que se incorporen de
lleno mtodos de calidad en sus procesos y que la
forma m%s eficiente y efectiva de +acer las cosas, es
+acerlas "ien a la primera ve/ y con ello daremos un
ran iro a la industria del software$ Por ?ltimo, que
entiendan la importancia de la ente$ Con este fin voy a +acer
una ?ltima analo#a9 el dueAo de una f%"rica de coc+es sale a
las L de la tarde, y a+# tiene su f%"rica, con su valor intacto@
puede venderla y recuperar su inversin$ En cam"io, el dueAo
de una f%"rica de software, a las F de la noc+e que sus
empleados ya se fueron a su casa, est% descapitali/ado$ Lo
?nico que tiene son escritorios y unas m%quinas depreciadas$
Como industria, de"emos reconocer que estamos +ec+os de
personas, y que stas son nuestro principal activo$ &s# que
de"emos tenerlas "ien IaceitadasK -a travs de capacitacin y
motivacin. para o"tener su m%!imo rendimiento$
BIBLIOGRAFA
C 3 D (etodolo#as Jiles9 La ventaja competitiva de
estar preparado para tomar decisiones lo m%s tarde
posi"le y cam"iarlas en cualquier momento$ -En
l#nea., Disponi"le en9 EEE.s&%ne#.($1?E&4
#(ntent?0et()(+(1%asa1%+esFG3.&),
C 5 D (etodolo#as %iles -En l#nea. ,Disponi"le en9
Htt&-??EEE.a1%+e4s&a%n.#(0
C 7 D 0C,30H -En l#nea., Disponi"le en9
EEE.s&%ne#.($1?E&4#(ntent?ICONI:.&),
C " D E!treme Prorammin 'efactored9 T+e Case
&ainst HP, (&TT )tep+ens and D,U1
'osen"er, Disponi"le en *ormato c+m
C I D 0ntroduccin a 0coni! -En l#nea., Disponi"le en9
Htt&-??EEE.%n,($0%t.#(0?a$t%#+es?a$t%#+e.as&A
&J3KLMG5N$+J3
S