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 soft are 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 soft are, 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

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 al o 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

INTRODUCCIN
Dentro del desarrollo de software y a la altiva necesidad de que los proyectos lle uen 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 satisfa a mas all% de las necesidades definidas al inicio del proyecto$

RATIONAL UNIFIED PROCESS (RUP)

*01U'&2$
P',CE), U30*0C&D, '&T0,3&L

El !ito del producto depende en ran parte de la metodolo #a esco ida 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$
2 5 7

'o"ert+ 1$ *i ueroa, UTPL, Loja, r fi ueroa4utpl$edu$ec Camilo 6$ )ol#s, UTPL, Loja, cjsolis4utpl$edu$ec &rmando Ca"rera ),Docente80nvesti ador UTPL,Loja, aaca"rera4utpl$edu$ec

'UP es un proceso formal9 Provee un acercamiento disciplinado para asi nar tareas y responsa"ilidades dentro de una or ani/acin de desarrollo$ )u o"jetivo es ase urar la produccin de software de alta calidad que satisfa a los requerimientos de los usuarios finales -respetando crono rama y presupuesto.$ *ue desarrollado por 'ational )oftware, y est% inte rado con toda la suite 'ational de +erramientas$ Puede ser adaptado y e!tendido para satisfacer las necesidades de la or ani/acin que lo adopte$ -Customi/acin.$ Es uiado por casos de uso y centrado en la arquitectura, y utili/a U(L como len uaje 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 si ue los pasos intuitivos necesarios a la +ora de desarrollar el software$ )e uimiento detallado en cada una de las fases$

0mplantacin$ *01U'& 5$
(,DEL, DE E>U0P, DE ()*

V%s%'n * A+#an#esLa 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 lo rar 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 ries os del proyecto$ P+an%,%#a#%'nEs 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 crono ramas de los diferentes entre a"les del proyecto$ Desa$$(++(Durante esta fase el equipo realice la mayor parte de la construccin de los componentes -tanto documentacin como cdi o., sin em"ar o, 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-

Desventajas La evaluacin de ries os es compleja E!cesiva fle!i"ilidad para al unos 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 FRAME

Des#$%&#%'n

OR!

(MSF)"

()* 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$ l#nea., 5

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-

(icrosoft )olution *ramewor<, -en disponi"le en +ttp9==www$ picr$com=msf$asp!

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 al unas de las desventajas impuestas por las estructuras jer%rquicas de los equipos en los proyectos tradicionales$ Los equipos or ani/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 i ualmente importantes en su aporte al proyecto$ &unque los roles pueden tener diferentes niveles de actividad durante las diversas etapas del proyecto, nin uno puede ser omitido$ La comunicacin se pone en el centro del c#rculo para mostrar que est% inte rada 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 car a 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, mi racin a Bindows 5CCC de una red de servidores$ Fase 3 4 Est$ate1%a * a+#an#e En esta fase de"er#an tener lu ar los si uientes tra"ajos9 Ela"oracin y apro"acin del Documento de &lcance y Estrate ia definitivo9 de"e ser un documento de consenso con la participacin del mayor n?mero de a entes 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 7

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 si uientes$ 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 'ies os y Plan de Contin encia9 los principales ries os detectados de"en tener un plan de miti acin y actuacin y revisarse con periodicidad$ Para un proyecto de mi racin 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 si uientes 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 re istro de versiones que permita +acer un se uimiento 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 reco e 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 Estrate ia, 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

El cmputo de jornadas para la relacin de actividades descritas -que como se o"serva slo reco en las relativas a la Planificacin y DiseAo, y deja aparte las necesarias para ela"orar el plan de (i racin., 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, restrin ido 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 +a a 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 desplie ue 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 reco ida 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 pro ramas 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 desplie ue$ En el Plan de"en identificarse las fases, estrate ia 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 desplie ue 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 Desplie ue$ 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 ten a lu ar -evitando que coincida con periodos de vacaciones o puntas de tra"ajo cr#ticas como *in de &Ao.$ En proyectos de similar enver adura se +a lle ado 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 desplie ue y el de formacin$ Los principales tra"ajos e +itos a conse uir 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 si uientes9 Continuacin con las la"ores de recepcin de incidencias, clasificacin, tratamiento, resolucin y distri"ucin de fa!es o intervencin on8site$ 'e istro de mejoras y su erencias, 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$ Entre a de los documentos definitivos acordados como Ddelivera"lesD en la fase de :ision )cope$ 'evisin -si procede. de la matri/ de ries os, las mtricas de calidad y esta"lecimiento de los est%ndares de calidad y )L& definitivos$ *inalmente, entre a 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 desplie ue, 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 ne ocio. 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 desplie ue$ Los factores m%s relevantes en el c%lculo suelen ser la dispersin o concentracin eo r%fica, la complejidad del proceso de mi racin, 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 ne ocio.$ METODOLOGAS GILES. Lue o 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 2gil3 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 ne ociacin de contratos$ La capacidad de respuesta ante un cam"io es m%s importante que el se uimiento estricto de un plan$

'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 lar o 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'& 7L$
(,DEL, DE EHT'E(E P',1'&((031

Entre los principales mtodos % iles tenemos el HP -eHtreme Pro rammin ., )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 se uimiento 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 si nificar 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

Es la m%s destacada de los procesos % iles de desarrollo de software formulada por Ment Nec<$ La pro ramacin 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

Pires, Donald, I(anifiesto J ilK, UCL&, -en l#nea., disponi"le en +ttp9==www$manifiestoa ile$com

E!trem Por rammin -HP.$ Disponi"le en www$HPro rammin $com

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 re resin$ )e aconseja escri"ir el cdi o 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 cdi o escrito de esta manera 8el cdi o 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 pro ramacin 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 entre as frecuentes$ Re,a#t($%/a#%'n del cdi o, es decir, reescri"ir ciertas partes del cdi o para aumentar su le i"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 corre ir y e!tender cualquier parte del proyecto$ Las frecuentes prue"as de re resin 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 pro ramacin e!trema apuesta que en m%s sencillo +acer al o simple y tener un poco de tra"ajo e!tra para cam"iarlo si se requiere, que reali/ar al o 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 pro ramadores$ Ventajas &propiado para entornos vol%tiles Estar preparados para el cam"io, si nifica reducir su coste$ Planificacin m%s transparente para nuestros clientes, conocen las fec+as de entre a de funcionalidades$ :ital para su ne ocio L

Permitir% definir en cada iteracin cuales son los o"jetivos de la si uiente Permite tener realimentacin de los usuarios muy ?til$ La presin esta a lo lar o de todo el proyecto y no en una entre a final

Desventajas Delimitar el alcance del proyecto con nuestro cliente Para miti ar 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 entre a"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 (odelado 0mplementacin Prue"a Desplie ue &dministracin de la confi uracin &dministracin o erencia del Proyecto Entorno

SCRUM
*01U'& G$
E)>UE(& DE T'&N&6, )C'U(

ICONI:
El proceso de 0C,30H maneja casos de uso, como el 'UP, pero le falta muc+o para lle ar 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 se uimiento de requisitos$

)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 in enier#a de software como 'UP o E!treme Pro rammin $ )crum se focali/a en priori/ar el tra"ajo en funcin del valor que ten a para el ne ocio, 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 re ulares$ De esta forma se puede adaptar en tiempo real el producto que se est% construyendo a las necesidades del cliente$ )e "usca entre ar 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 re las muy pequeAo y muy simple y est% "asado en los principios de inspeccin continua, adaptacin, auto8 estin 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 ne ocio 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 inte rantes del equipo$ Q

*01U'& L$ E)>UE(& DE T'&N&6, 0C,30H

O, el proceso se queda i ual a la visin ori inal 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 *i ura L muestra el cuadro del proceso$ El dia rama retrata la esencia del enfoque aerodin%mico al desarrollo del software, que incluye un jue o m#nimo de dia ramas de U(L y al unas 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#%asT&NL& 2$
D0*E'E3C0&) E3T'E (ET,D,L,1P& T'&D0C0,3&LE) O J10LE)

Met()(+(12as T$a)%#%(na+es
Nasadas en normas provenientes de est%ndares se uidos por el entorno de desarrollo Cierta resistencia a los cam"ios 0mpuestas e!ternamente Proceso muc+o m%s controlado, con numerosas pol#ticas=normas

Met()(+(12as A1%+es
Nasadas en +eur#sticas provenientes de pr%cticas de produccin de cdi o Especialmente preparados para cam"ios durante el proyecto 0mpuestas internamente -por el equipo. Proceso menos controlado, con pocos principios$

El cliente interact?a con el equipo de desarrollo mediante reuniones (%s artefactos (%s roles 1rupos randes y posi"lemente distri"uidos La arquitectura del software es esencial y se e!presa mediante modelos E!iste un contrato prefijado

El cliente es parte del equipo de desarrollo Pocos artefactos Pocos roles 1rupos pequeAos -R2C inte rantes. y tra"ajando en el mismo sitio (enos nfasis en la arquitectura del software 3o e!iste contrato tradicional o al menos es "astante fle!i"le

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($

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

Por la curva de &prendi/aje C6$va )e a&$en)%/aje

Lenta R=&%)a '%pida '%pida

M()e+( )e P$(#es(
'UP 0C,30H HP )C'U(

;e$$a0%enta )e %nte1$a#%'n
A+t( S(&($te &l ?n )oporte Disponi"le 3o mencionado 3o mencionado

S(&($te E<te$n(
A+t( S(&($te &l ?n )oporte Disponi"le &l ?n )oporte Disponi"le &l ?n )oporte Disponi"le

MODELOS RIGUROSOS

ETAPA
Anlisis de requerimientos

MODELOS AGILES
Planificacin adpatativa:Entregas frecuentes + colaboracin del cliente

Planificacin predictiva y aislada Planificacin Dise o fle!ible y E!tensible + modelos + Documentacin e!"austiva Desarrollo individual con (oles y responsabilidades estrictas Actividades de control+: ,rientado a los "itos + -estin miniproyectos Dise o

Dise o #imple: Documentacin $%nima + &ocali'ado en la comunicacin *ransferencia de conocimiento: Programacin en pares + conocimiento colectivo .idera'go/ )olaboracin: empoderamiento +auto/organi'acin

)odificacin

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 inte rales 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 auto8 estionados, 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

Pruebas 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 Ta0a>( )e+ P$(#es(
(edio = E!tenso PequeAo = (edio Pe96e>( ? Me)%( Pe96e>( ? Me)%(

M()e+( )e P$(#es(
'UP 0C,30H HP )C'U(

Ta0a>( )e+ E96%&(

(edio = E!tenso PequeAo = (edio Pe96e>( Pe96e>(

C(0&+ej%)a) )e+ P$(.+e0a

(edio = &lto PequeAo = (edio (edio = &lto (edio = &lto

tradicionales o"li an 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 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$

Primero, que cono/can y apliquen las tcnicas de in enier#a de software$ )e undo, 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

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 J iles9 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 Pro rammin '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