buenainformacion xp y fdd

8/6/2019 Buenainformacion Xp y Fdd

1/200

Diseo de una Metodologa gil deDesarrollo de Software.

Schenone Marcelo [email protected]

Tesis de Grado en Ingeniera en Informtica.Facultad de Ingeniera.

Universidad de Buenos Aires.

- 2004 -


2/200

Diseo de una Metodologa gil de Desarrollo de Software 1 Cuatrimestre 2004 FIUBA

Tema: Diseo de una Metodologa gil de Desarrollo de Software.

Alumno: Schenone Marcelo Hernn. Padrn: 75563.

Tutor: Villagra Sergio.

Fecha de Examen:

Informe Final Aprobado por:

Autor

Tutor


3/200


Abstract

Esta tesis tiene como propsito la construccin de una Metodologa gil deDesarrollo de Software la cual utiliza UML como notacin. Si bien podr ser empleadaen proyectos de distinto tamao y complejidad, su aplicacin tendr como objetivoproyectos de pequea escala y riesgo limitado. Tambin ser independiente del lenguajeo la arquitectura utilizada, as como del tipo de software que se est construyendo.

Para desarrollar esta metodologa se comenzar por un relevamiento de lasmetodologas y notaciones actualmente empleadas (Rational Unified Process, UML,SCRUM, OPEN, Extreme Programming, etc), un posterior refinamiento de las mismasy el desarrollo paulatino de un proceso que incorpore las mejores y ms avanzadasprcticas existentes en cada etapa del desarrollo.

Finalmente, se describe la realizacin de dos casos prcticos resueltos con lametodologa propuesta. El primer caso prctico estar basado en un sistema deintegracin de servicios para ONGs, y el segundo en un sistema de administracin derecursos de hardware y software.


4/200


Tabla de Contenidos

Diseo de una Metodologa gil de Desarrollo de Software.____________________ 1 Abstract _________________________________________________________________ 3

Tabla de Contenidos____________________________________________________ 4 Tabla de Contenidos Detallada ___________________________________________ 5 Prefacio______________________________________________________________ 8 Captulo I - Introduccin_______________________________________________ 10 Captulo II - Descripcin del Problema____________________________________ 39 Captulo III - Solucin Propuesta ________________________________________ 53

Patrones de Desarrollo Recomendados _______________________________________ 93 Enfoque Sistmico _______________________________________________________ 118

Aportes de AgEnD al Espectro Metodolgico_________________________________ 134 Capitulo IV - Resultados Experimentales de las Prcticas de AgEnD __________ 137 Capitulo V - Conclusiones _____________________________________________ 166 Anexo A - Templates de Artefactos ______________________________________ 169 Anexo B - Tabla de Lenguajes de Programacin ___________________________ 170 Anexo C - Glosario___________________________________________________ 175

Referencias Bibliogrficas_____________________________________________ 177 Links en Internet sobre Metodologas giles ______________________________ 184


5/200


Tabla de Contenidos Detallada

A. Diseo de una Metodologa gil de Desarrollo de Software

a. AbstractB. Tabla de ContenidosC. Tabla de Contenidos DetalladaD. Prefacio

a. Organizacin de la Tesisb. Agradecimientos

E. Captulo I - Introduccin

a. Breve Introduccin a la Ingeniera de Softwareb. Evolucin de los Modelos de Proceso de Desarrollo

i. Modelo en Cascadaii. Modelo en Espiral

iii. Modelo Iterativoiv. Modelo Incrementalv. Modelo Basado en Prototipos

c. Surgimiento de las Metodologas gilesi. XPii. Scrum

iii. Crystal Cleariv. DSDMv. FDD

vi. ASDvii. XBreed

d. Estandarizacin de las Metodologas gilesi. Manifesto for Agile Software Development

F. Captulo II - Descripcin del Problemaa. Por qu elegir un procesob. Orientado al proceso vs. Orientado a las personasc. Consideraciones Humanasd. Orientado a los productos vs. Orientado a las tarease. Desarrollo Iterativo


6/200


G. Captulo III - Solucin Propuestaa. Descripcin de Aspectos a Incluir en una Metodologa gil

i. Caractersticas de la Metodologaii. Roles

iii. Fases e Hitos1. Concepcin2. Elaboracin3. Construccin4. Transicin

iv. Disciplinas dentro de las Fases1. Factibilidad2. Requerimientos Anlisis3. Diseo4. Implementacin Testing5. Despliegue

v. Disciplinas de Soporte1. Administracin de Proyecto2. Administracin de la Configuracin

3. Administracin del Proceso4. Administracin de Personas5. Administracin del Conocimiento

vi. Artefactos1. Visin2. Plan de Proyecto3. Lista de Riesgos

4. Modelo de Casos de Uso y Especificaciones de Casosde Uso

5. Documento de Especificacin de Requerimientos deSoftware (SRS)

6. Descripcin de la Arquitectura7. Casos de Prueba8. Scripts de Despliegue

9. Planilla de Incidentes10. Repositorio del Proyecto


7/200


11. Nota de Entregab. Patrones de Desarrollo Recomendados

i. Mxima Comunicacinii. Comunicacin Interna al Equipo

iii. Participacin Activa del Clienteiv. Estimaciones gilesv. Enfoque en la Arquitectura

vi. Integracin Continuavii. Peopleware

c. Enfoque Sistmicoi. Ambiente del Desarrollo de Softwareii. Implementacin del Proceso

1. Adaptacin Metodolgica2. Adaptacin de las personas

a. La Organizacinb. El rea de Desarrolloc. El Individuo

d. Aportes de AgEnD al Espectro Metodolgico

H. Captulo IV - Resultados Experimentalesa. Overviewb. Experimentos de Prcticas recomendadas en AgEnD

i. Primer Ejemplo: Aplicacin en FIDoNETii. Segundo Ejemplo: Aplicacin en CONEST

I. Captulo V - ConclusionesJ. Anexo A Templates de Artefactos

K. Anexo B Tabla de Lenguajes de ProgramacinL. Anexo C GlosarioM. Referencias BibliogrficasN. Links en Internet sobre Metodologas giles


8/200


PrefacioEsta Tesis de Grado fue realizada durante el perodo que va desde Agosto de

2001 hasta Abril de 2004.La eleccin del tema surgi a partir de la investigacin del autor en relacin a los

Modelos de Proceso de Desarrollo observados en diversas materias de la carrera. Amedida que comenzaba la exploracin lleg a su conocimiento la metodologa eXtremeProgramming (XP) desarrollada por Kent Beck a las cuales se incorporaron muchascuales que conformaran el universo de metodologas giles. Dado el nfasis de lasmismas en cuestiones de Peopleware, Dinmica de Equipos, Psicologa Social, Calidad

del Proceso, el tema fue elegido como base para la construccin de una metodologa queanalizara estos aspectos, basndose en las mejores practicas de la industria eincorporando aspectos interdisciplinarios tomados de la Psicologa, Sociologa,Relaciones de Trabajo y Administracin. La idea de la misma era que pudiera serutilizada dentro de la realidad de la informtica en nuestro pas. As nace la presentetesis que describe en detalle AgEnD, la metodologa gil que es motivo del presentetrabajo.

A fines del 2000, manteniendo conversaciones con el docente Sergio Villagra en ese momento jefe de trabajos prcticos de la ctedra de Proyectos Informticos I dela FIUBA quien mostr gran inters en el tpico elegido, se plante el ofrecimiento deste de trabajar como Tutor de la Tesis. Mediante la formalizacin del trmite de iniciode la Tesis, comenz el arduo desarrollo que finalizara en el ao 2004.

Organizacin de la TesisLa Tesis est organizada de la siguiente forma. Prefacio, contiene informacin relevante a los orgenes y el desarrollo

del trabajo

Introduccin, describe brevemente los temas a los que se harreferencia durante el trabajo

Descripcin del Problema, describe sintticamente la necesidad decontar con un proceso de desarrollo y como las Metodologas giles


9/200


intentan resolver distintos problemas surgidos de la complejidadinherente al software

Solucin Propuesta, describe detalladamente la Metodologa propuesta,

AgEnD, destacando los valores propuestos y analizndola en relacinal universo de Metodologas giles

Resultados Experimentales, narra las experiencias realizadas con lasdiversas prcticas propuestas en AgEnD, junto con los resultadosderivados de estas

Conclusiones, plantea las conclusiones obtenidas del desarrollo as como futuras lneas de investigacin a seguir

Anexos, detallan temas que si bien no son centrales para la Tesis,sirven para profundizar en aspectos mencionados en esta

Bibliografa, contiene la totalidad del material utilizado paraconfeccionar el trabajo

AgradecimientosQuisiera agradecer a las siguientes personas que han contribuido de una u otra

forma durante la elaboracin de la Tesis. Mis agradecimientos son para: Anbal Calligo,Germn Boccoleri, Alejandro Oliveros, Elvio Nabot, Enrique Vetere, ngel PrezPuletti, Adriana Yecha, Pablo Sametband, Adrin Lasso, Pablo Cosso. A mi Tutor,Sergio Villagra.

Finalmente quisiera agradecer a mis padres, Olga y Jorge, quienes me ayudaron

incondicionalmente a que pudiera completar la misma. Asimismo hago extensivo elagradecimiento a toda mi familia y dems personas que olvido en este momentomencionar.


10/200


Captulo I - Introduccin

Propsito detrs de esta TesisPara empezar a hablar de Ingeniera de Software daremos una definicin

aceptada por la industria, esta ha sido tomada de la IEEE Computer Society:

(1) La aplicacin de un enfoque sistemtico, disciplinado ycuantificable al desarrollo, operacin y mantenimiento delsoftware; esto es, la aplicacin de la ingeniera al software

(2) El estudio de los enfoques como en (1)

Como podemos observar esta definicin apunta a la profesionalizacin de ladisciplina de la informtica dentro del mbito de las dems ingenieras. Al respectodebemos mencionar los constantes esfuerzos realizados por la comunidad informticapara generar este cambio. El objetivo ulterior radica en que la disciplina pase de ser unconjunto de buenas prcticas y folklore a un conjunto de patrones y estndares a seraplicados en cada situacin.

Sobre la naturaleza catica del software encontramos una importante referenciaen el artculo No Silver Bullet de Frederick Brooks [Brooks, 1987] en el cual seanalizaban las caractersticas intrnsecas del software. En el mismo, el autor tomaba larealidad de la disciplina mencionando los grandes problemas que planteaba el desarrollode software. Las caractersticas esenciales descritas en dicho paper eran las siguientes:

Complejidad, las entidades de software son ms complejas por su tamao

que cualquier construccin humana Conformidad, mucha de la complejidad deviene de la necesidad de

conformar con mltiples interfaces, heterogneas entre s ya queinvolucran a distintas personas

Maleabilidad, las entidades de software estn sujetas a cambiosconstantemente; dado que el software es materia puramente intelectual yque su cambio es percibido como algo sencillo el mismo suele sufrir esteefecto


11/200


Invisibilidad, lo que genera dificultades en la comunicacin para elmodelado de los sistemas

Teniendo en cuenta la bibliografa de las dcadas pasadas se observa que si biense han desarrollado diversos enfoques para mitigar la complejidad inherente al software,el mismo sigue presentando un gran desafo en su desarrollo. De ah la conclusin deBrooks respecto a la construccin de software que citamos en forma verbatim.

No existe ningn desarrollo, ya sea en tecnologas como enmanagement, que por si solo prometa siquiera una mejora de un

orden de magnitud en la prxima dcada en lo referido aproductividad, confiabilidad, simplicidad.

Podemos decir que la prediccin de Brooks se mantiene hasta el da de hoy,diecisiete aos despus del paper. Sin embargo podemos afirmar que se ha avanzado enmuchos frentes dentro de la informtica al punto que se est en camino de llegar a laprofesionalizacin de la disciplina.

Como en todas las dems ingenieras que han tenido un mayor tiempo demaduracin surge la necesidad de la estandarizacin. Es decir, abandonar la aplicacinde tcnicas y buenas prcticas en forma ad hoc a favor de un proceso disciplinado, queest definido por normas, que resulte predecible y provea una adecuada visibilidad paralos stakeholders. Estas ideas son las que impulsan el desarrollo de esta tesis.

Historia de los procesos de desarrolloUno de los grandes pasos dados en la industria del software fue aquel en que se

plasm el denominado modelo en cascada. Dicho modelo sirvi como base para laformulacin del anlisis estructurado, el cual fue uno de los precursores en este caminohacia la aplicacin de prcticas estandarizadas dentro de la ingeniera de software.Propuesto por Winston Royce en un controvertido paper llamado "Managing theDevelopment of Large Software Systems" [Royce, 1970] este modelo intentabaproponer una analoga de lnea de ensamblaje de manufactura para el proceso de


12/200


desarrollo de software, queriendo forzar predictibilidad en una entidad como el softwareque como fue mencionado es algo complejo y que esta ms relacionado con eldesarrollo de nuevos productos.

Se debe tener en cuenta el momento de la historia cuando aparece este modelo.El mismo surge como respuesta al modelo codificar y probar que era el quepredominaba en la dcada de los 60. En esa poca ya existan modelos iterativos eincrementales pero no eran disciplinados ni estaban formalizados. A consecuencia deesta realidad, la idea de tener un modelo que ordenara el proceso de desarrollo y quepareca bastante sencillo de llevar a la prctica y de comunicar hizo que el modelo encascada tuviera una gran promocin. Esto resulta irnico ya que como aos ms tarde

explic su hijo, Walker Royce, Winston Royce en realidad abocaba por los modelositerativos y solo propuso el modelo en cascada como la descripcin ms simple de unproceso la cual solo servira para proyectos muy predecibles y sin grandes riesgos[Larman, 2003].

Este modelo se basaba en el desarrollo de etapas las cuales tenan un input y unoutput predefinido. El proceso era desarrollado en forma de cascada ya que se requerala finalizacin de la etapa anterior para empezar la siguiente. Esto degeneraba en un

congelamiento temprano de los requerimientos, los cuales al presentar cambiosrequeran gran esfuerzo en retrabajo. Otra opcin era no permitir cambio alguno a losrequerimientos una vez que se iniciara el desarrollo lo que traa aparejado que el usuariono vea la aplicacin hasta que ya estaba construida y una vez que interactuaba nocubra sus necesidades.

Asimismo, dadas las caractersticas inherentes del modelo, la fase deimplementacin del mismo requera el desarrollo de los mdulos en forma

independiente con las correspondientes pruebas unitarias, y en la siguiente fase, serealizaba la integracin de los mismos. Esto traa aparejados grandes inconvenientesdebidos a que todo estaba probado en forma unitaria sin interaccin con los demsmdulos. Las sorpresas llegaban cuando se integraban estas piezas para formar laaplicacin; lo cual inevitablemente desembocaba en un retraso del proyecto,sacrificando la calidad del mismo.

De esta forma y en forma bastante temprana en algunos casos, fueron surgiendo

diversos procesos denominados iterativos que proponan lidiar con la impredictibilidad


13/200


del software (subsanando muchas de las falencias del modelo en cascada) mitigando losriesgos en forma temprana. Los procesos iterativos de los cuales se desprenderandiversas instancias, como son el modelo iterativo e incremental, el modelo en espiral, elmodelo basado en prototipo, el modelo SLCD, el MBASE, el RUP, etc.

Bsicamente, la postura de estos modelos es la de basar el desarrollo eniteraciones e ir construyendo la aplicacin en forma progresiva, agregandofuncionalidad sucesivamente. Las iteraciones representan un mini-proyecto auto-contenido el cual est compuesto por todas las fases del desarrollo (requerimientos,diseo, implementacin, testing). Los incrementos estn dados por la funcionalidad quese va agregando al software en forma iterativa. Gracias a estas iteraciones se logra entre

otras cosas obtener el feedback necesario del cliente que era frenado en el modelo encascada una vez se finalizaba la fase de requerimientos. Consecuentemente podemosargumentar que los modelos iterativos fomentan el cambio en forma temprana yproponen un control de cambio disciplinado que permita que el usuario ajuste sobre eldesarrollo sus requerimientos. Esto se contrapone a la intolerancia del modelo encascada para lidiar con dichos cambios.

Del modelo en espiral desarrollado por [Boehm, 1988] surgi una de las ideas

fundamentales que las metodologas posteriores adoptaran: el temprano anlisis deriesgos. Como muestra la Figura 001 este modelo de carcter iterativo en sus primerasfases, plantea la necesidad de realizar al principio diversas iteraciones dirigidas amitigar los riesgos ms crticos relevados en el proyecto mediante la realizacin deprototipos o simulaciones de tipo desechables tendientes a probar algn concepto. Unavez que esos prototipos son validados se suceden iteraciones del tipo: determinarobjetivos, evaluar, desarrollar, planear. Mediante estas iteraciones se procuraba elfeedback del que se hablaba anteriormente, en forma temprana. Una vez que se tena eldiseo detallado y validado por el cliente, se implementaba el software siguiendo lasetapas de un modelo en cascada. Esta es una falla importante del modelo ya que no seacomoda a la posibilidad de cambios una vez que se inicia la construccin. Todas lascrticas que se le hacan al modelo en cascada se aplican a estas fases del modelo enespiral.


14/200


Figura 001. Descripcin de las iteraciones del Modelo en Espiral. Tomada de [Calligo, 2003]

Fue el mismo Barry Boehm, autor de este modelo, quien en su artculo [Boehm,1995] describe tres hitos crticos a ser utilizados en cualquier proyecto de forma depoder planificar y controlar el progreso del mismo, dando visibilidad a los stakeholders.Estos hitos estn relacionados con las etapas de avance que se van dando a lo largo deun proyecto de acuerdo al pasaje que ocurre de las actividades de ingeniera (que

componen los espirales del modelo en espiral) a las actividades de produccin (quecomponen la construccin en cascada del software). Su impacto en la industria delsoftware ha sido tan importante que uno de los procesos mas utilizados en la actualidad,el [RUP, 2002], los incorpora. Estos hitos son:

Objetivos del Ciclo de Vida

Arquitectura del Ciclo de Vida

Capacidad Operacional Inicial


15/200


16/200


denominadosroadmaps que son simplemente formas de customizar el RUP pararesolver tipos de problemas especficos. Sin embargo, al intentar abarcar proyectos deenvergaduras tan dispares como podran ser la construccin de un sistema de radarespara portaviones versus la construccin de un registracin de usuarios para una pequeaconsultora, el RUP pierde la granularidad necesaria para describir en detalle uno de losfactores ms trascendentes de cualquier desarrollo de software: las personas.

Esta es una de las razones principales del advenimiento de las denominadasMetodologas giles.

Metodologas giles de DesarrolloA principios de la dcada del 90, surgi un enfoque que fue bastanterevolucionario para su momento ya que iba en contra de la creencia de que medianteprocesos altamente definidos se iba a lograr obtener software en tiempo, costo y con larequerida calidad. El enfoque fue planteado por primera vez por [Martin, 1991] y se dioa conocer en la comunidad de ingeniera de software con el mismo nombre que su libro,RAD o Rapid Application Development. RAD consista en un entorno de desarrolloaltamente productivo, en el que participaban grupos pequeos de programadoresutilizando herramientas que generaban cdigo en forma automtica tomando comoentradas sintaxis de alto nivel. En general, se considera que este fue uno de los primeroshitos en pos de la agilidad en los procesos de desarrollo como mencionaremos acontinuacin. Cabe mencionar que las metodologas giles no inventaron la nocin delos procesos iterativos e incrementales, los cuales eran usados desde dcadas pasadasinclusive en momentos en que el modelo en cascada era el estndar.

La historia de las Metodologas giles y su apreciacin como tales en lacomunidad de la ingeniera de software tiene sus inicios en la creacin de una de lasmetodologas utilizada como arquetipo: XP - eXtreme Programming. XP surge de lamente de Kent Beck, tomando ideas recopiladas junto a Ward Cunningham, y utilizandoconceptos como el de Chief Programmer creado por IBM en la dcada de los 70.

Durante 1996 Beck es llamado por Chrysler como asesor del proyectoChrysler Comprehensive Compensation (C3) payroll system. Dada la pobre calidad del sistema

1 De hecho, Rational que fue adquirida por IBM en el ao 2003 vende el RUP junto con templates y documentacin anexa para usocomercial a empresas.


17/200


que se estaba desarrollando, Beck decide tirar todo el cdigo y empezar de ceroutilizando las prcticas que l haba ido definiendo a lo largo del tiempo. El sistema, queadministra la liquidacin de aproximadamente 10.000 empleados, y consiste de 2.000clases y 30.000 mtodos, es puesto en operacin en Mayo de 1997 casi respetando elcalendario propuesto [C3, 1998] [Williams, 2000]. Como consecuencia del xito dedicho proyecto, Kent Beck dio origen a XP iniciando el movimiento de metodologasgiles al que se anexaran otras metodologas surgidas mucho antes que el propio Beckfuera convocado por Chrysler.

Entre las metodologas giles ms destacadas hasta el momento podemosnombrar:

XP Extreme Programming

Scrum Crystal Clear DSDM Dynamic Systems Developmemt Method FDD Feature Driven Development ASD Adaptive Software Development XBreed

Extreme Modeling

A continuacin, daremos un breve resumen de dichas metodologas, su origen ysus principios. La idea es poder observar las similitudes entre las mismas y aquellasbases que unifican los criterios con los que fueron creadas y desembocaron en elManifiesto descrito posteriormente.

XP Extreme ProgrammingLa primera metodologa ya ha sido comentada y es la que le dio conciencia al

movimiento actual de metodologas giles. De la mano de Kent Beck, XP haconformado un extenso grupo de seguidores en todo el mundo, disparando una grancantidad de libros a los que dio comienzo el mismo Beck en [Beck, 2000]. InclusiveAddison-Wesley ha creado una serie de libros denominadaThe XP Series. Fue la mismagente del proyecto C3 la que produjo tambin otro de los libros importantes de XP


18/200


[Jeffries, 2001] en el que se bajaban los conceptos de Beck a la puesta en prctica en unproyecto.

La imagen mental de Beck al crear XP [Beck, 2000] era la de perillas en un

tablero de control. Cada perilla representaba una prctica que de su experiencia sabaque trabajaba bien. Entonces, Beck decidi girar todas las perillas al mximo para verque ocurra. As fue como dio inicio a XP.

Los principios de XP citados verbatim de Beck: El juego de PlaneamientoRpidamente determinar el alcance del prximo

release mediante la combinacin de prioridades del negocio y estimaciones tcnicas. Amedida que la realidad va cambiando el plan, actualizar el mismo.

Pequeos ReleasesPoner un sistema simple en produccin rpidamente,luego liberar nuevas versiones en ciclos muy cortos.

MetforaGuiar todo el desarrollo con una historia simple y compartida decmo funciona todo el sistema.

Diseo SimpleEl sistema deber ser diseado tan simple como sea posible encada momento. Complejidad extra es removida apenas es descubierta.

TestingLos programadores continuamente escriben pruebas unitarias, las

cuales deben correr sin problemas para que el desarrollo contine. Los clientes escribenpruebas demostrando que las funcionalidades estn terminadas.

RefactoringLos programadores reestructuran el sistema sin cambiar sucomportamiento para remover duplicacin, mejorar la comunicacin, simplificar, oaadir flexibilidad.

Programacin de a ParesTodo el cdigo de produccin es escrito por dosprogramadores en una mquina.

Propiedad Colectiva del CdigoCualquiera puede cambiar cdigo encualquier parte del sistema en cualquier momento.

Integracin ContinuaIntegrar y hacer builds del sistema varias veces por da,cada vez que una tarea se completa.

Semana de 40-horasTrabajar no ms de 40 horas semanales como regla.Nunca trabajar horas extras durante dos semanas consecutivas.

Cliente en el lugar de DesarrolloIncluir un cliente real en el equipo,disponible de forma full-time para responder preguntas.


19/200


Estndares de CodificacinLos programadores escriben todo el cdigo deacuerdo con reglas que enfatizan la comunicacin a travs del mismo.

Como se observan, muchas de las prcticas propuestas contribuyen a maximizarla comunicacin entre las personas, permitiendo de esa forma una mayor transferenciade conocimiento entre los desarrolladores y con el cliente, quien tambin es parte delequipo. Esto es logrado en la prctica gracias a la disposicin fsica del lugar de trabajo.La idea es reunir a todas las personas en una misma oficina manteniendo unadistribucin denominada cavernas y comn ver Figura 002. En la misma seobservan escritorios dispuestos en el centro con varias computadoras, cada una con dos

sillas dispuestas de forma de permitir la programacin de a pares. En las paredes seobservan pequeos boxes o escritorios con sillas, los cuales pueden ser usados por losprogramadores en forma privada, para realizar llamados, consultar mail, o simplementedescansar la mente. Consecuentemente se logra el objetivo mencionado al inicio delprrafo de maximizar la comunicacin y la transferencia de informacin en el reacomn, mientras que se mantiene la individualidad de las personas en las mencionadascavernas.

Figura 002. Disposicin fsica de las oficinas bajo la distribucin cavernas y comn. Tomada de [Cockburn, 2001a]

Asimismo, XP impone un alto nivel de disciplina entre los programadores. Elmismo permite mantener un mnimo nivel de documentacin, lo cual a su vez se traduce


20/200


21/200


Uno de los anlisis ms importantes de la metodologa desemboc en un libroescrito por dos de sus creadores, Ken Schwaber y Mike Beedle [Schwaber, 2001]. Estelibro ser tomado para el anlisis de Scrum.

Scrum es un mtodo iterativo e incremental que enfatiza prcticas y valores deproject management por sobre las dems disciplinas del desarrollo. Al principio delproyecto se define el Product Backlog, que contiene todos los requerimientosfuncionales y no funcionales que deber satisfacer el sistema a construir. Los mismosestarn especificados de acuerdo a las convenciones de la organizacin ya sea mediante:features, casos de uso, diagramas de flujo de datos, incidentes, tareas, etc. El ProductBacklog ser definido durante reuniones de planeamiento con los stakeholders. A partir

de ah se definirn las iteraciones, conocidas como Sprint en la juerga de Scrum, en lasque se ir evolucionando la aplicacin evolutivamente. Cada Sprint tendr su propioSprint Backlog que ser un subconjunto del Product Backlog con los requerimientos aser construidos en el Sprint correspondiente. La duracin recomendada del Sprint es de1 mes.

Dentro de cada Sprint el Scrum Master (equivalente al Lder de Proyecto)llevar a cabo la gestin de la iteracin, convocando diariamente al Scrum Daily

Meeting que representa una reunin de avance diaria de no ms de 15 minutos con elpropsito de tener realimentacin sobre las tareas de los recursos y los obstculos que sepresentan. Al final de cada Sprint, se realizar un Sprint Review para evaluar losartefactos construidos y comentar el planeamiento del prximo Sprint.

Como se puede observar en la Figura 003 la metodologa resulta sencilladefiniendo algunos roles y artefactos que contribuyen a tener un proceso que maximizael feedback para mitigar cualquier riesgo que pueda presentarse.


22/200


PO

Product Owner:Set priorities

Roles

SM

ScrumMaster:Manage process,

remove blocks

T

Team: Developproduct

SH

Stakeholders:observe & advise

Key ArtifactsProduct Backlog List of requirements & issues Owned by Product Owner Anybody can add to it Only Product Owner prioritizes

Sprint Goal One-sentence summary Declared by Product Owner Accepted by team

Sprint Backlog List of tasks Owned by team Onl team modifies it

Blocks List List of blocks & unmade

decisions Owned by ScrumMaster Updated daily

Increment Version of the product Shippable functionality (tested,

documented, etc.)

Key MeetingsSprint Planning Meeting Hosted by ScrumMaster; 1 day In: Product Backlog, existing

product, business & technologyconditions

1. Select highest priority items inProduct Backlog; declare Sprint Goal2. Turn selected items into SprintBacklog Out:: Sprint Goal, Sprint Backlog

Daily Scrum Hosted by ScrumMaster Attended by all, but Stakeholders

dont speak Same time every day Answer: 1) What did you do

yesterday? 2) What will you dotoday? 3) Whats in your way?

ScrumMaster updates SprintBacklog and Blocks List

Sprint Review Meeting Hosted by ScrumMaster Attended by all Informal, 4-hour, informational Team demos Increment All discuss Hold retrospective Announce next Sprint Planning

Meeting

ProductBacklog

Development Process

Increment

Sprint Planning Meeting

Daily Scrum

Daily Work

SprintGoal

SprintBacklog

BlocksList

Product

Sprint Review Meeting

Sprint:30 days each

ProductBacklog

Increment

Figura 003. Descripcin de roles, artefactos, reuniones y proceso de desarrollo de Scrum. Cortesa deWilliam C. Wake,[email protected], www.xp123.com

La intencin de Scrum es la de maximizar la realimentacin sobre el desarrollopudiendo corregir problemas y mitigar riesgos de forma temprana. Su uso se estextendiendo cada vez ms dentro de la comunidad de Metodologas giles, siendocombinado con otras como XP para completar sus carencias. Cabe mencionar queScrum no propone el uso de ninguna prctica de desarrollo en particular; sin embargo,es habitual emplearlo como un framework gil de administracin de proyectos quepuede ser combinado con cualquiera de las metodologas mencionadas.

Crystal Clear

Alistair Cockburn es el propulsor detrs de la serie de metodologas Crystal. Lasmismas presentan un enfoque gil, con gran nfasis en la comunicacin, y con ciertatolerancia que la hace ideal en los casos en que sea inaplicable la disciplina requerida

por XP. Crystal Clear es la encarnacin ms gil de la serie y de la que msdocumentacin se dispone. La misma se define con mucho nfasis en la comunicacin,


23/200


y de forma muy liviana en relacin a los entregables [Cockburn, 2001b]. Crystal manejaiteraciones cortas con feedback frecuente por parte de los usuarios/clientes,minimizando de esta forma la necesidad de productos intermedios. Otra de lascuestiones planteadas es la necesidad de disponer de un usuario real aunque sea deforma part time para realizar validaciones sobre la Interfase del Usuario y paraparticipar en la definicin de los requerimientos funcionales y no funcionales delsoftware.

Una cuestin interesante que surge del anlisis de la serie Crystal es elpragmatismo con que se customiza el proceso. Las personas involucradas escogenaquellos principios que les resultan efectivos y mediante la aplicacin de la metodologa

en diversos proyectos agregan o remueven principios en base al consenso grupal delequipo de desarrollo.

Aunque al momento de preparar este trabajo an no se dispone de bibliografaoficial de Crystal, Cockburn reporta su uso exitoso en diversos proyectos.

DSDM Dynamic Systems Development Method

DSDM es la nica de las metodologas aqu planteadas surgida de un Consorcio,formado originalmente por 17 miembros fundadores en Enero de 1994. El objetivo delConsorcio era producir una metodologa de dominio pblico que fuera independiente delas herramientas y que pudiera ser utilizado en proyectos de tipo RAD (RapidApplication Development). El Consorcio, tomando las best practices que se conocan enla industria y la experiencia trada por sus fundadores, liber la primera versin deDSDM a principios de 1995. A partir de ese momento el mtodo fue bien acogido por laindustria, que empez a utilizarlo y a capacitar a su personal en las prcticas y valoresde DSDM. Debido a este xito, el Consorcio comision al Presidente del ComitTcnico, Jennifer Stapleton, la creacin de un libro que explorara la realidad deimplementar el mtodo. Dicho libro [Stapleton, 1997] es tomado como gua para elanlisis posterior de DSDM.

Dado el enfoque hacia proyectos de caractersticas RAD esta metodologaencuadra perfectamente en el movimiento de metodologas giles. La estructura delmtodo fue guiada por estos nueve principios:


24/200


1. El involucramiento del usuario es imperativo.

2. Los equipos de DSDM deben tener el poder de tomar decisiones.

3. El foco est puesto en la entrega frecuente de productos.

4. La conformidad con los propsitos del negocio es el criterio esencialpara la aceptacin de los entregables.

5. El desarrollo iterativo e incremental es necesario para converger haciauna correcta solucin del negocio.

6. Todos los cambios durante el desarrollo son reversibles.

7. Los requerimientos estn especificados a un alto nivel.

8. El testing es integrado a travs del ciclo de vida.

9. Un enfoque colaborativo y cooperativo entre todos los interesados esesencial.

DSDM define cinco fases en la construccin de un sistema ver Figura 004. Lasmismas son: estudio de factibilidad, estudio del negocio, iteracin del modelo funcional,

iteracin del diseo y construccin, implantacin. El estudio de factibilidad es unapequea fase que propone DSDM para determinar si la metodologa se ajusta alproyecto en cuestin. Durante el estudio del negocio se involucra al cliente de formatemprana, para tratar de entender la operatoria que el sistema deber automatizar. Esteestudio sienta las bases para iniciar el desarrollo, definiendo las features de alto nivelque deber contener el software. Posteriormente, se inician las iteraciones durante lascuales: se bajar a detalle los features identificados anteriormente, se realizar el diseo

de los mismos, se construirn los componentes de software, y se implantar el sistemaen produccin previa aceptacin del cliente.


25/200


Figura 004. Fases del proceso de desarrollo DSDM. Tomada de [Highsmith, 2002].

Descontando la primera fase que es realizada una nica vez al principio delproyecto para analizar la factibilidad desde el punto de vista del negocio del desarrollo,las dems fases presentan las caractersticas del modelo iterativo e incremental ya

tratado. Sin embargo, lo que diferencia a DSDM de dicho modelo son los principiosalrededor de los cuales se estructura y que hacen nfasis en los equipos de desarrollo, enel feedback con el cliente, en las entregas frecuentes de productos.

Para resolver la cuestin de la aplicabilidad de DSDM a un proyecto convendrresponder las siguientes preguntas:

Ser la funcionalidad razonablemente visible en la interfase del usuario?

Se pueden identificar todas las clases de usuarios finales?

Es la aplicacin computacionalmente compleja?

Es la aplicacin potencialmente grande? Si lo es, puede ser particionada encomponentes funcionales ms pequeos?

Est el proyecto realmente acotado en el tiempo?

Son los requerimientos flexibles y slo especificados a un alto nivel?


26/200


Las mismas refieren a las caractersticas que se deben cumplir en los proyectospara poder utilizar el enfoque RAD de construccin. Se observa que aquellos proyectosque califiquen afirmativamente de acuerdo a dichas preguntas tendrn las siguientescaractersticas que refieren a la aplicabilidad de DSDM:

Son proyectos interactivos con la funcionalidad visible en la interfase deusuario

De baja o media complejidad computacional

Particionables en componentes de funcionalidad ms pequeos si laaplicacin es de gran tamao

Acotados en el tiempo

Con flexibilidad en los requerimientos

Con un grupo de usuarios bien definidos y comprometidos al proyecto

De esta forma observamos que DSDM deja las bases sentadas para el anlisissobre su aplicabilidad a un espectro bien definido de proyectos de software. Sin

embargo, la metodologa no tiene ninguna prescripcin respecto a las tcnicas a serusadas en el proyecto, ni siquiera impone el desarrollo bajo un paradigma especfico funciona tanto para el modelo de orientacin a objetos como para el modeloestructurado. Algo que s sugiere el mtodo es la generacin de un conjunto mnimo demodelos necesarios para la sana progresin de la entrega del software y facilidad en elmantenimiento. Estos modelos esenciales debern ser definidos antes que comience eldesarrollo, y debern ser revisados en las sucesivas iteraciones para validad sucontenido.

El concepto de timebox es algo que est embebido en DSDM y en todas lasmetodologas giles, en las cuales tambin se conocen como iteracin, ciclo, intervalo.La consecuencia de utilizarlos es el feedback frecuente que brinda visibilidad a losstakeholders para que verifiquen el progreso y puedan tomar acciones correctivas atiempo. Tambin permiten controlar la calidad de los productos intermedios que se vangenerando, y realizar estimaciones de esfuerzo ms precisas. Asimismo, cada timebox

esta compuesta por actividades definidas en relacin a entregables en vez de tareas.


27/200


Cada entregable generado durante el mismo es testeado/revisado dentro del mismotimebox.

En DSDM, un timebox consta de tres fases que son: Investigacin, Refinamiento

y Consolidacin. Durante la Investigacin se chequean que las actividades quecomponen el timebox se condicen con la arquitectura del sistema. Esta es una fase decarcter exploratorio, en la que se fijan los objetivos de la iteracin, los entregables a serproducidos, efectundose revisiones sobre las iteraciones anteriores a la actual. Lasiguiente fase, Refinamiento, consiste en la produccin propiamente dicha de losartefactos planificados. DSDM destaca la necesidad de colocar componentes de distintaprioridad en un mismo timebox, de manera de poder posponer a futuras iteraciones

aquellos con menor prioridad, en caso que surjan imprevistos o se materialicen riesgos.Finalmente, la fase deConsolidacinconsiste en completar los entregables, verificandola calidad de los mismos. En esta fase que posee el hito de finalizacin del timebox sedemostrar que se satisficieron los requerimientos de calidad definidos durante la Investigacin.

DSDM incluye roles claves en relacin al management del proyecto. Identificaal visionario como el encargado de asegurar que se satisfacen las necesidades del

negocio; elusuario embajador que equivaldra alon-site customer de XP, que brinda elconocimiento del negocio y define los requerimientos del software; elcoordinador tcnico que es la persona encargada de mantener la arquitectura y verificar laconsistencia de los componentes construidos respecto a esta y al cumplimiento de losestndares tcnicos.

Algunas tcnicas sugeridas en DSDM son las sesiones JAD para capturar losrequerimientos del software y la realizacin de prototipos para descifrar aquellas

ambigedades que se presentan en el relevamiento y tambin para derribar las barrerascomunicacionales entre analistas y usuarios. El enfoque propuesto consiste en lautilizacin de un prototipo evolutivo, el cual se va refinando hasta tenerse la aplicacindeseada. El nfasis queda en manifiesto en los prototipos que se sugieren para cadaetapa: negocio, usabilidad, performance y capacidad, y diseo.

En resumen, encontramos en DSDM una metodologa gil creada en el ReinoUnido a partir de un consorcio con participacin de empresas de primera lnea. El

mismo contiene las caractersticas principales de las metodologas giles y contiene


28/200


prcticas tendientes al enfoque RAD. Algo que es importante de DSDM ha sido suaceptacin en la industria y su refinamiento continuo actualmente, se encuentra en suversin 4.0 lo que indica que las metodologas giles no son solo dominio depequeos grupos de desarrollo sino que estn siendo adoptadas por pesos pesados enlas industrias.

FDD Feature Driven Development

Peter Coad es considerado uno de los referentes ms importantes dentro de laingeniera de software. Coad ha sido uno de los principales pioneros detrs del

movimiento de la orientacin a objetos y empez a trabajar con Ed Yourdon (uno de loscreadores del Anlisis Estructurado) a principios de los noventa, cuando este ltimopidi ayuda a alguien de la comunidad de objetos para desarrollar una nuevametodologa, basada en el paradigma de OO. Posteriormente, Coad junto con Jeff DeLuca y otros, participara en la creacin de FDD, una metodologa desarrolladaalrededor del ao 1998 que presenta las caractersticas de un proceso gil [Coad, 1998].La misma deriv del trabajo de Coad sobre lasFeature Lists (Listas de

Funcionalidades).

FDD se estructura alrededor de la definicin de features que representan lafuncionalidad que debe contener el sistema, y tienen un alcance lo suficientemente cortocomo para ser implementadas en un par de semanas. FDD posee tambin una jerarquade features, siendo el eslabn superior el de feature set que agrupa un conjunto de featuresrelacionadas con aspectos en comn del negocio. Por ltimo, establece elmajor feature set como el ms alto nivel de agrupacin de funcionalidad que abarca diferentes

feature setsque contribuyen a proveer valor al cliente en relacin a un subdominiodentro del dominio completo de la aplicacin. Una de las ventajas de centrarse en las features del software es el poder formar un vocabulario comn que fomente que losdesarrolladores tengan un dilogo fluido con los clientes, desarrollando entre ambos unmodelo comn del negocio. Este tema ser tratado ms adelante en relacin al enfoquede las metodologas giles en los productos entregados.

La jerarqua de los featuresutiliza los siguientes formatos:


29/200


Para features: el un

Para feature sets: un

Para major feature sets: administracin de

Ejemplos:

Calcular el total de la facturacin de Noviembre (feature)

Modificar el estado de las facturas de produccin (feature)

Administrar el perfil de los proveedores (feature)

Haciendo una venta a un cliente (feature set)

Cargando la facturacin de los proveedores (feature set)

Administracin de Bancos (mayor feature set)

El ciclo de vida propuesto por FDD se puede observar en la Figura 005 y estcompuesto por cinco procesos, dos de las cuales se realizan tantas veces comoiteraciones se planifiquen en el desarrollo.

Figura 005. Los cinco procesos dentro de FDD. Tomada de [Coad, 2000].


30/200


31/200


la iteracin, el equipo de programadores liderado por el programador jefe identifica lasclases, atributos y mtodos que realizan la funcionalidad requerida. Mediante lautilizacin de diagramas de secuencia de UML, se verifica que el diseo pueda serimplementado. Se realizar tambin una inspeccin del diseo en los casos en que lacomplejidad de la funcionalidad lo requiera. Posteriormente, en la fase deConstruir por Feature, se procede a desarrollar las clases definidas en la actividad anterior. Cadaprogramador implementar los mtodos de las clases por las que este es responsable,extendiendo las clases base de prueba para construir las pruebas unitarias. Una vez quela clase pasa todas las pruebas, se inspecciona el cdigo. Esta actividad ser realizadapor el equipo asignado al feature en cuestin, y una vez que finaliza se promueve elcdigo al Build correspondiente, siendo entregado a Administracin de laConfiguracin.

En relacin a las actividades de management en FDD se recomienda una reuninsemanal entre el Lder de proyecto y los programadores jefe; la misma debe ser breve,de no ms de 30 minutos, y en la cual se reporta el status de los features que estnsiendo construidos por cada grupo. Por cada feature set que es implementado se tendrla informacin como indica la Figura 006 para medir el avance del proyecto, dndolevisibilidad al management superior y al cliente.

Figura 006. Reportando el progreso al management y al cliente en FDD. Tomada de [Coad, 2000].

En conclusin, encontramos en FDD un proceso gil orientado a lafuncionalidad del software por sobre las tareas, sobre las cuales da guas mnimas. El


32/200


proceso sugiere organizar bloques de featuresa ser construidos en forma incrementalmediante iteraciones de dos semanas; provee estrategias de planeamiento para el lderde proyecto; fomenta la colaboracin mediante la creacin de equipos dirigidos por unprogramador jefe.

ASD Adaptive Software Development

Jim Highsmith en su libro [Highsmith, 1999] es la mente detrs de este procesogil. ASD consiste en un cambio de filosofa en las organizaciones pasando de latransicin del modelo Comando-Control al modelo Liderazgo-Colaboracin. Basado enlos conceptos de losSistemas Adaptativos Complejosrelacionada con la Inteligencia

Artificial, Highsmith lleva los mismos al campo de la Ingeniera de Software enparticular. Dada la complejidad inherente al software concluye que la aplicacin de estateora es esencial para el nuevo escenario que plantea la economa global.

Comenzando por un cambio en el modelo de desarrollo determinista, tomado delciclo de Deming, en que se aplica la secuencia Planificar-Ejecutar-Evaluar. Dichoesquema es llevado a la prctica con el modelo en cascada, en que se realiza una precisaplanificacin inicial mediante el WBS, el Gantt, y el Pert definiendo las tareas a realizar

en detalle, luego se tiene las fases de construccin, y finalmente, se tiene el testing quebrinda el feedback en relacin al producto construido.

ASD propone utilizar en cambio el ciclo de vida de la Figura 007, Especular-Colaborar-Aprender. El proyecto comienza con una fase de especulacin en que en quese lleva a cabo la planificacin tentativa del proyecto en funcin de las entregas que seirn realizando. La utilizacin del verbo Especular demuestra el inters de Highsmith endemostrar la naturaleza impredecible de los sistemas complejos. En esta etapa se fija un

rumbo determinado a ser seguido en el desarrollo, sabiendo a partir de ese momento queno ser el lugar en que finalizar el proyecto. En cada iteracin, se aprendern nuevasfuncionalidades, se entendern viejas cuestiones, y cambiarn los requerimientos.Gracias a centrarse en la especulacin, ASD permite administrar estos proyectos de altocambio y rpido desarrollo que se encuentran en elborde del caos. Respecto a laespeculacin, se recomienda realizar uncomponent breakdown structureen vez delmuy conocido y tradicionalwork breakdown structure (WBS)en el cual mediante una

grilla u hoja de clculo se pueda conocer la funcionalidad a ser liberada en cada ciclo.


33/200


Sin embargo, no es ms que una especulacin ya que el carcter adaptativo del procesopermite pequeas desviaciones en un sentido por lo que Highsmith sugiere que cadaciclo se componga de un mix entre funcionalidades crticas, tiles, y opcionales,previendo los posibles retrasos que puedan existir mediante el movimiento de lasfuncionalidades de menor prioridad a futuros ciclos y grandes desviaciones en otro,las cuales son utilizadas para la exploracin del dominio y de la aplicacin, que puedellevar a cambiar el rumbo del proyecto estos desvos est representado por las flechasde divergencia en la Figura 007.

Figura 007. El ciclo de vida adaptativo. Tomada de [Highsmith, 2000].

La siguiente fase del ciclo de vida, Colaborar, es aquella en la que se construyela funcionalidad definida durante la especulacin. ASD define unComponentecomo ungrupo de funcionalidades o entregables a ser desarrollados durante un ciclo iterativo.Durante cada iteracin el equipo colabora intensamente para liberar la funcionalidadplanificada. Tambin, existe la posibilidad de explorar nuevas alternativas, realizarpruebas de concepto, pudiendo eventualmente alterar el rumbo del proyectoprofundamente. ASD no propone tcnicas ni prescribe tareas al momento de llevar acabo la construccin simplemente mencionando que todas las prcticas que sirvan parareforzar la colaboracin sern preferidas, siguiendo de esta forma la lnea de lasmetodologas giles respecto a la orientacin a componentes. El nfasis se ubica en larelaciones entre las personas que deben estar lo suficientemente lubricadas para generaruna propiedad imprescindible de los organismos complejos: emergencia. La emergencia


34/200


es una propiedad de los sistemas adaptativos complejos que crea alguna propiedad msgrande del todo (comportamiento del sistema) a partir de la interaccin entre las partes(comportamiento auto-organizativo de los agentes). Gracias a esta propiedad los gruposde desarrollo logran sacar lo mejor de si en la elborde del caos.

La fase final de ASD, Aprender, consiste en la revisin de calidad que se realizaal final de cada ciclo. En la misma se analizan cuatro categoras de cosas para aprender[Highsmith, 2000]:

Calidad del resultado de la desde la perspectiva del cliente

Calidad del resultado de la desde la perspectiva tcnica

El funcionamiento del equipo de desarrollo y las prcticas que este utiliza El status del proyecto

Para evaluar la calidad desde el punto de vista del cliente se sugieren utilizargrupos de enfoque en el cliente, mediante los cuales se explora un modelo de laaplicacin y se anotan los requerimientos de cambio del cliente.

Las revisiones al diseo, al cdigo o a las pruebas permitirn aprender sobre lacalidad de los mismos. En este caso, el nfasis estar puesto en aprender cuales han sidolos errores o desvos y poder resolverlos, y no en encontrar culpables. Asimismo, est esla etapa en que se evaluarn las exploraciones que se hayan realizado dando lacapacidad de poder modificar la arquitectura del sistema si se ha encontrado algncamino que se ajusta mejor a lo que necesita el usuario o si han cambiado losrequerimientos.

El tercer proceso de feedback est relacionado con la interaccin entre las partes,la dinmica de grupo, y las tcnicas empleadas. Para medir la performance y el grado decohesin del mismo, se podrn realizar al final de cada ciclo pequeas reuniones depostmortem. En las mismas se discuten los aspectos del proceso que contribuyen aldesarrollo y aquellos que deben ser descartados por su influencia negativa.

En relacin al status del proyecto, se realizarn revisiones para determinar elestado del mismo en relacin a lo planificado. En este momento, se detectarn posibles

diferencias que pueden surgir de la exploracin y que cambiarn el rumbo a queapuntaba el proyecto.


35/200


En la Figura 008 se puede ver el detalle interno de cada fase como ya fueexplicado, mostrndose con una flecha que trasciende las tres fases en sentido inverso,el bucle de aprendizaje. Este bucle es algo crtico para ASD ya que denota un cambio enel esquema tradicional de la vista de un sistema en que se tena un bucle de control paradetectar diferencias y corregirlas. Es decir, en las metodologas tradicionales lasdiferencias respecto a lo planificado eran vistas como errores que deban serenmendados para que cumplieran lo pautado. ASD y las metodologas giles plantean lanecesidad de que el feedback necesario sea para aprender, nos da la posibilidad deentender ms respecto al dominio y construir la aplicacin que mejor satisfaga lasnecesidades del cliente. Highsmith lo expone claramente en la siguiente frase:

En ambientes complejos, el seguir un plan al pie de la letraproduce el producto que pretendamos, pero no el producto quenecesitamos.

Figura 008. Actividades del ciclo de vida adaptativo. Tomada de [Highsmith, 2000].

En conclusin, tenemos en ASD un marco filosfico basado en la teora deSistemas Adaptativos Complejosque nos permite encarar la construccin de software enforma gil utilizando las prcticas que nos resulten convenientes en cada caso. En estesentido resulta similar a Scrum.

XBreed Scrum wrapper for XP


36/200


XBreed ofrece una de las primeras fusiones exitosas entre metodologas giles.Tomando las fuerzas en el management de Scrum y unindolas con las prcticas de XPnace una de las ms modernas metodologas alrededor del 2000. Mike Beedle es lamente detrs de XBreed y su objetivo es tomar las mejores prcticas del universo gil yunificar estas en un marco de trabajo que permita el desarrollo concurrente de mltiplesproyectos usando metodologas giles.

Al momento de escritura de esta tesis, existe muy poca informacin de XBreed,salvo el sitio web oficial del mismo.

Manifesto for Agile Software Development

El Manifiesto para el Desarrollo gil de Software es de suma importancia dentrodel movimiento de las metodologas giles. El mismo representa una iniciativa conjuntaentre los principales responsables de los procesos giles mencionados anteriormentepara lograr unificar principios compartidos por las diversas metodologas de manera de

crear un framework de trabajo que contribuya al mejoramiento del desarrollo gil.Uno de los principales objetivos del encuentro en que se gener el Manifiesto

fue el de extraer un factor comn de los principios esenciales que serviran de gua paracualquier metodologa que se identifique como gil. Esto concluy en la declaracin delo que podramos denominar el prlogo del Manifiesto [Manifesto, 2001]:

Estamos descubriendo mejores maneras de desarrollar software

mediante su construccin y ayudando a que otras personas loconstruyan.

A travs de este trabajo hemos llegado a valorar:

IInnddiivviidduuooss ee iinntteerraacccciioonneess sobre procesos y personas

SSoof f ttwwaarree f f uunncciioonnaannddoo sobre documentacin comprensiva

CCoollaabboorraacciinn ddeell cclliieennttee sobre negociacin de contrato

RReessppoonnddeerr aall ccaammbbiioo sobre seguir un plan


37/200


Esto es, mientras que existe valor en los tems de la derecha,valoramos ms los tems de la izquierda.

Analizando los factores mencionados en detalle vemos que los mismos formanparte esencial de las metodologas descriptas. En los mismos se plasman aquellasrazones que impulsaron a Beck, Highsmith, y otros, a construir metodologas giles. Elnfasis sobre las personas esta emblematizado en la primer oracin respecto a losvalores de las metodologas. El nfasis en el cdigo por sobre los documentos es una

propuesta eficaz para lograr el rpido feedback requerido por la agilidad. Laparticipacin del cliente es fundamental para el xito de los proyectos ya que ellosdefinen la funcionalidad a construir y guan el desarrollo de las pruebas funcionales. Laimportancia de responder al cambio indica que el desarrollo de software no es ms queun proceso de aprendizaje en que cada cambio nos permite conocer ms en detalle eldominio de la aplicacin.

El autor entiende que para que se pueda definir a AgEnD como una metodologa

gil, la misma deber estar completamente circunscripta a los valores detallados en elManifiesto. Es por esto que se harn continuas referencias al mismo para comentar laconformidad del proceso a los principios y valores.

Con esto, damos por concluida la introduccin de este documento. A partir deahora, nos centraremos en la descripcin de AgEnD, su aplicabilidad en el desarrollo desoftware, sus valores, principios, y toda la informacin necesaria para poder utilizarla enla prctica; posteriormente, plantearemos un caso de estudio de AgEnD en donde se

pueda observar y analizar sus fuerzas y sus debilidades; finalmente, se llevaran a caboaquellas conclusiones relevantes al desarrollo de la AgEnD, analizndose laslimitaciones y alcances de la misma, previendo posibles lneas de trabajo que se puedandesprender en relacin a las metodologas giles y el Manifiesto que las nuclea.

Presentacin de AgEnD


38/200


Como se ha mencionado en el Abstract, el propsito de esta tesis es construiruna metodologa que rena aquellas mejores prcticas del universo gil unindolas conun framework que ayude a las organizaciones a implantar este tipo de metodologas.

El nombre de la metodologa es AgEnDque significa en ingls Agility Enhanced Development (Desarrollo Mejorado Por Agilidad). En otras palabras, la idea esconfigurar un proceso de desarrollo que resulte fcil de implementar y basar el mismoen la aplicacin de prcticas giles para contribuir a la construccin del software,lidiando con la impredictibilidad de la disciplina.

En esta tesis se comentar el porqu de la necesidad de un proceso, y de cmoAgEnD llena ese hueco que surge al querer implementar una metodologa gil en una

organizacin.


39/200


Captulo II - Descripcin del ProblemaA continuacin se describirn las razones por las cuales hoy en da se debe

contar con un proceso de desarrollo. Tambin se explicar como las metodologas gilesintentan resolver distintos problemas que se plantean en el desarrollo de software.


40/200


Por qu elegir un proceso

Cuando una empresa encara proyectos de desarrollo de software, que laimpulsa a seleccionar un proceso? No alcanza con dejar que el conocimiento y el

esfuerzo de los involucrados sea aplicado en forma uniforme, y simplemente que se junten los frutos del trabajo de las personas al final del proyecto?

Estas simples preguntas no poseen una nica respuesta, pero s se puedeargumentar la siguiente afirmacin que indica las posibles opciones en relacin a laeleccin de un proceso.

La eleccin respecto a la utilizacin o no de un proceso depende

principalmente del grado de predictibilidad que se desee tener enel desarrollo.

Es decir, si una empresa est interesada en que cada proyecto sea como unaaventura, en que se desconozca el resultado y existan una gran cantidad de riesgos, nonecesitar proceso alguno. Simplemente dejar en manos de los profesionales desistemas el desarrollo de proyectos mediante las tcnicas que utilice cada individuo ensu trabajo. La aleatoriedad de cada proyecto ser una caracterstica inherente. Serealizarn planificaciones a muy corto plazo, ya que no existe visibilidad para laspersonas externas al equipo de desarrollo. En conclusin, estamos hablando de todas lasorganizaciones que se encuentran en el nivel 1 del CMM, el denominado nivel Inicial.Indudablemente, cualquier organizacin que se precie de ser tal jams elegira esteenfoque como primera instancia ya que uno de los objetivos de la misma seramaximizar ganancias a largo plazoy para esto debera mantener procesos que asegurenel xito en todos los sectores en que est compuesta. Sin embargo, como veremos msadelante la mayora de las empresas termina eligiendo esta opcin sin ser plenamenteconciente de la eleccin y de los resultados que esta acarrea.

Por otro lado, encontramos organizaciones que poseen manuales deprocedimientos para cada una de las tareas relacionadas con el desarrollo de software.Cada actividad realizada por cada persona est descripta en detalle en forma escrita y encualquier momento esta documentacin podr ser consultada si tienen dudas respecto aalgn punto del proceso. En general, estas organizaciones poseen una estructura


41/200


tradicional de management en donde el modelo Comando-Control es utilizado en todoslos niveles jerrquicos. De caractersticas deterministas, relacionadas muchas veces conla manufactura de productos de alguna clase, conducen el departamento de sistemas dela misma forma en que conducen el departamento de finanzas, utilizando rgidosprocesos que generan hitos y entregas bien definidos. Bajo esta perspectiva es lgicoconcluir que una organizacin que posee procedimientos predecibles en todas sus reas,intente llevar los mismos al desarrollo de software. Sin embargo, como hemos notadoen la introduccin esto resulta una tarea imposible dadas las caractersticas esencialesdel software mencionadas por Brooks.

Analizando estos dos enfoques de desarrollo de software nos encontramos con

dos extremos bien definidos por [Highsmith, 1999] que son el de Burocracia,representado por las organizaciones con procesos rgidos y definidos hasta el msmnimo nivel de detalles, y el de Adhocracia, que representa el desarrollo catico sinningn proceso ni visibilidad sobre el estado y el rumbo de los proyectos. En unextremo, estamos en la claridad cegante de un proceso tan pautado que termina sinsatisfacer las necesidades de los usuarios, y en el otro estamos en la oscuridad completay aleatoriedad total que deviene del caos permitiendo nicamente beneficios o prdidasa corto plazo.

Si trazramos una lnea uniendo la Burocracia con la Adhocraciapodramosutilizarla para ubicar el grado de formalidad dado por las metodologas que ya fuerontratadas en la introduccin. Es decir, si tenemos una organizacin que se identifique conuno de estos enfoques, cules seran las metodologas que elegira para el desarrollo desoftware. En la Figura 009 observamos la disposicin que surge de colocar al Modeloen Cascada, el RUP, las Metodologas giles, el Modelo en Espiral, el Modelo porPrototipos, y el Modelo Iterativo en la recta correspondiente. En la misma observamosque el Modelo en Cascada es el que ms contribuye a un rgimen burocrtico en el quelos proyectos son planificados en base a tareas a realizar por los recursos; fomenta elorden de la organizacin mediante la clara divisin en etapas con sus inputs/outputscorrespondientes. Asimismo, encontramos otro de los procesos ms utilizados en laactualidad como es el RUP, en una forma completa, construyendo todos los artefactosespecificados y realizando todas las actividades planteadas. En otras palabras, estosprocesos pretenden definir todas las actividades, roles, entregables, y dems aspectosrelacionados en un proyecto de software, para generar resultados predecibles a lo largo


42/200


del tiempo. Mediante la clara definicin de aquellas cuestiones involucradas y laposibilidad de controlar el proceso para ajustarlo ante posibles desvos, se llega a la Burocracia. El Modelo en cascada ejemplifica este enfoque al ser un modelo orientadoa documentos, en donde el progreso se mide en base a un conjunto de fases biendefinidas y al grado de avance de la documentacin correspondiente. Las personas sonpartes reemplazables en este esquema, y como tales alcanza con definir los roles y lasactividades que estas realizan para completar el marco de desarrollo.

A medida nos alejamos de la Burocracia encontramos los Modelos con unenfoque principal hacia los entregables y hacia el rpido feedback de los clientes. ElRUP Agilizado no es otra cosa que una versin del RUP customizada para grupos

pequeos y con feedback frecuente de los interesados.

Figura 009. Ubicacin de las metodologas en relacin al nivel de formalidad requerido.

Como observamos, todas estas metodologas se encuentran hacia la izquierda delpunto medio entre Burocraciay Adhocracia. Si nos movemos desde ese punto hacia elCaos nos encontramos con el tema central de esta tesis, las Metodologas giles, entrelas que encontramos todas aquellas descriptas en la Introduccin, incluidas AgEnD.

Estas metodologas reconocen las caractersticas inherentes de complejidad delsoftware, y el carcter emprico que debe tener un proceso de desarrollo del mismo. En

Burocracia~ Orden

Adhocracia~ Caos

Modelo enCascada

MetodologasgilesModelo en

Espiral

RUPCompleto

Modelo porPrototipos

RUPAgilizado

RAD

Codificary Probar


43/200


estas, las personas son de primera magnitud y se prefiere sacrificar el proceso en pos dedarles libertad a las personas. Sin embargo, esto no significa que se termina en unproceso de Codificar y Probar, liderado por programadores rebeldes que se pasan el dagenerando cdigo. Es por esto que el punto en que se ubican las mismas est bastantealejado del Caos en que la aleatoriedad es la norma. Otra cuestin que diferencia estosprocesos de los anteriores es el cambio existente entre un proceso emprico y un procesodeterminista o definido. Como mencionbamos antes, los procesos ms burocrticostienden a tener definidos todos los aspectos del desarrollo. Esto se contradice con lanaturaleza compleja del software, para lo cual se adaptara con mayor eficiencia unproceso emprico. Por esto nos referimos a un proceso en que se desconocen muchosaspectos, se reconocen a las personas como componentes de primer orden totalmenteimpredecibles, y simplemente se intenta guiar el desarrollo hacia un objetivo que puedeno permanecer constante en el tiempo a medida que aumenta el conocimiento de laaplicacin a ser construida. En los procesos empricos se conocen las buenas prcticasprobadas con la experiencia, y los resultados u outputs que surgen generalmente detomar ciertos inputs o de realizar ciertas actividades. Estos modelos surgen de laobservacin y la experiencia obtenida a lo largo de los aos, sin basarse en leyes de lanaturaleza o principios tericos fundamentados. Es por esto que se los asocia a un

enfoque pragmtico para desarrollar software.

Siguiendo por la recta nos encontramos con el enfoque RAD propuesto por[Martin, 1991] en el que se tena un lenguaje de alto nivel lo suficientemente poderosocomo para permitir generar cdigo de forma rpida, un pequeo equipo trabajando enconjunto con buenos canales de comunicacin, y un plan de entregas de funcionalidaden forma iterativa. El mismo no posea pautas claras en relacin a la calidad delproducto, la satisfaccin de los requerimientos de los usuarios, la clara definicin de laarquitectura del sistema. Por estas causas termin siendo asociado con la generacinrpida de aplicaciones con bajos niveles de calidad, y que resultaban en pesadillas demantenimiento. Sin embargo, debemos reconocer el aporte que hicieron a la ingenierade software ya que gracias a estas resurgieron las herramientas CASE y comenz el usomasivo de lenguajes de alto nivel, sirviendo como base para el posterior advenimientode las metodologas giles.

Finalmente, nos encontramos justo en las cercanas del Caos, al modeloCodificar y Probar. Esto modelo, catico por excelencia, se basa en el siguiente flujo de


44/200


actividades: un programador trabajando en su computadora, genera cdigo fuente; unavez que termina, lo compila, corrige los errores y lo vuelve a compilar; cuando ya notiene ms errores, genera el ejecutable y lo corre; ah prueba el correcto funcionamientodel mismo, debuggeando el cdigo al instante hasta corregir aquellos errores quedetecta; cuando este proceso iterativo finaliza, contina con el siguientecomponente/mdulo/programa. El mismo es totalmente impredecible y la visibilidadpara las personas involucradas en el mismo es inexistente. Es este modelo el que se tratade evitar a toda costa al formular una metodologa, incluidas las metodologas giles.

Corolarios

Del anterior anlisis deberemos tener en cuenta ciertos aspectos inherentes a losproyectos de desarrollo, que incidirn en forma directa en el grado de predictibilidad dela metodologa. Es decir, que dadas ciertas variables deberemos movernos en uno u otrosentido por la recta de la Figura 009.

Una variable muy importante a tener en cuenta es la cantidad de personasinvolucradas. Es algo natural pensar que a medida que aumenta la cantidad de personasasignadas a un proyecto deberemos contar con metodologas ms pesadas tendientes a

suplir la falta de canales anchos de comunicacin entre los integrantes del equipo dedesarrollo. Es por esto que la mayor parte de las metodologas giles dejan claro untamao mximo del equipo de desarrollo para utilizarlas exitosamente (en caso de tenerequipos de desarrollo ms grandes se recomienda particionarlos en equipos mspequeos). Alistair Cockburn [Cockburn, 2000] muestra este aspecto esencial a la horade elegir una metodologa mediante la Figura 010.


45/200


Figura 010. Relacin entre cantidad de personas, criticidad, y tamao de la metodologa. Tomada de [Cockburn, 2001a].

AgEnD en particular est enfocada a pequeos grupos de desarrollo, de no ms

de 15 personas involucradas en el proyecto, las cuales deben compartir un ambiente detrabajo comn, con mnima separacin fsica. Cabe mencionar que en caso de contarcon una mayor cantidad de recursos se debern particionar en subgrupos del tamaoantes indicado, trabajando en forma paralela.

Otra variable a tener en cuenta, es el grado de criticidad de la aplicacin. Amedida que aumenta el perjuicio para el negocio ante una posible falla en el sistema, sedeber utilizar una metodologa ms pesada, con procesos de revisin bien pautados, de

forma de asegurarse la calidad del producto. No es lo mismo construir una aplicacinempaquetada para bajar archivos de internet automticamente, que el software utilizadoen un equipo de resonancia magntica. En el primer caso, una prdida solo causa laposible prdida de informacin para un usuario ocasional. En el segundo caso, una fallapodra resultar en anomalas en los resultados obtenidos con la posibilidad de realizardiagnsticos errneos. Existe un riesgo de vida en relacin a esta aplicacin!

Aqu vemos la otra magnitud provista en la Figura 010 en la cual observamosque a medida que aumenta la criticidad, desde la prdida deComfort hasta la prdida de


46/200


Vida, debemos agregarle ms rigor a la metodologa para estar seguros de entregar unsoftware lo ms confiable posible.

Es as que se postula AgEnD como una metodologa para ser utilizada en

proyectos de caractersticas C3, C10, D3, que tienen como mximo 20 personas en elequipo de desarrollo y que presentan un grado de criticidad bajo, de prdida deComfort o prdidaEconmica Discrecional. Esta es la realidad de la mayora de las pequeasconsultoras de desarrollo localizadas en Buenos Aires, que trabajan para los sectores deIS/IT.

Orientado al proceso vs. Orientado a las personasUn par de dcadas atrs, en el campo de la Ingeniera de Software solo existan

los denominados procesos tradicionales. Comenzando por el modelo en cascada con sudivisin en etapas y roles bien definidos, continuando por el modelo en espiral, dondese mitigaban los riesgos en forma temprana, todos estos procesos proponan un enfoquesecundario en relacin a las personas. Consideraban que teniendo un proceso

predecible, con etapas y tareas bien definidas, el xito estaba garantizadoindependientemente de las personas que cubrieran los roles. Estos modelos de procesosestn orientados al proceso en si, y suponen que al seguir los principios propuestos porlos mismos en cualquier organizacin y con cualquier equipo de desarrollo, seobtendrn los resultados predichos en la teora. El resultado de aplicar un proceso decalidad, ser la calidad en el producto.

Actualmente nos encontramos con esta visin orientada al proceso en muchas

organizaciones con altos niveles de burocracia y en organizaciones basadas en elmodelo Codificar y Probar. Es decir, en ningn momento existen consideracionesrespecto a como la productividad se ve afectada por la gente que trabaja y por lascondiciones laborales existentes. Existen referencias en mltiples libros respecto a comoel factor humano es fundamental al xito del proyecto [DeMarco, 1987][Weinberg,1998][McConnell, 1996][McConnell, 2003][Glass, 2002]. Para evaluar la importanciade este elemento podemos tomar uno de los frameworks de estimacin ms importantesen la actualidad COCOMO II desarrollado por Barry Boehm entre otros [Boehm, 2000].


47/200


El mtodo en cuestin propone siete factores de personal que ajustan la estimacin deun proyecto. Los mismos estn relacionados con:

Experiencia en aplicaciones

Factores comunicacionales

Experiencia en el lenguaje y las herramientas

Continuidad del personal

Experiencia en la plataforma

Capacidad de los programadores

Capacidad de los analistas

Es decir que dependiendo de factores exclusivamente humanos nuestro proyectopuede variar en una relacin de hasta un 24,6 es decir un proyecto con todos losfactores humanos negativos puede llegar a tardar hasta 24,6 veces ms que un proyectocon un equipo de desarrollo adecuado y sin deficiencias. De ah el nfasis de lasmetodologas giles en este tipo de cuestiones.

Contando con la experiencia de Alistair Cockburn en estos temas recolectada alo largo de varios proyectos relevados en su mayora en IBM, el paper denominadoCharacterizing People as Non-Linear, First-Order Components in Software Development [Cockburn, 1999] demuestra que las personas son componentes deprimera magnitud en cualquier desarrollo. De esto surge uno de los principiosfundamentales de todas las metodologas giles que se ve plasmado en uno de losprimeros valores del [Manifesto, 2001]:

Individuos e Interaccionespor sobre procesos y herramientas

El nfasis de todas las metodologas giles esta centrado en los individuos y susinteracciones, a diferencia de las metodologas tradicionales en que impera el proceso ylas herramientas como propulsores de la calidad. AgEnD no es ninguna excepcin a

estos principios y propone destacar en cada una de sus prcticas que las personas son las


48/200


que indudablemente decidirn sobre la mejor forma de trabajo para ellas. Tambin delas personas depender la adopcin de AgEnD o cualquier proceso de desarrollo gil. Espor esto, que ms adelante se define un rol en particular, el Coordinador, que se encargade mantener las prcticas de AgEnD en armona, durante las primeras iteraciones en quese utiliza el proceso.

Consideraciones Humanas

El hecho que AgEnD base sus principios en las personas no significa que se hanresuelto todos los problemas del desarrollo y que teniendo un buen equipo el xito estgarantizado. Todo lo contrario, el nfasis propuesto requiere tomar ciertasconsideraciones en relacin a la naturaleza de las personas que no son necesarias en lasmetodologas tradicionales. Partimos de la base formulada por [Cockburn, 1999] que laspersonas son organismos vivientes impredecibles, inconsistentes pero con buenavoluntad y un sentido de hacer las cosas bien. De esto concluimos que la Figura 010extrada del [RUP, 2002]2 establece ciertas suposiciones que han sido esenciales en lasprcticas tradicionales de management basadas en la ideologa deCommand and Control.

Figura 011. Descripcin de un workflow dentro del RUP. Tomada de [RUP, 2002].

2 La seleccin de la figura del RUP y el comentario posterior no intenta realizar ninguna referencia a la naturaleza de dichoframework.


49/200


Como se observa el Desarrollador del Curso, toma como inputs laEspecificacin de Requerimientos Suplementarios, la Gua de Estilo del Manual, elPrototipo de la Interfase de Usuarioy el Build correspondiente. Con esto realiza latarea Desarrollo de Materiales de Entrenamiento, y genera el output Materiales deEntrenamiento. En el segundo caso, es elEscritor Tcnicoel que toma los mismosinputs, pero esta vez realiza la tares Desarrollo de Materiales de Soporte, generando eloutput Material de Soporte para el Usuario Final.

Es en esta figura en que se puede analizar la ideologa de las metodologastradicionales. Uno parte de ciertos artefactos como entrada, define los rolesinvolucrados, define la tarea a ser realizada, y finalmente, se obtienen los artefactos

deseados. La definicin de las tareas es realizada en bastante detalle, y se suele utilizarla tcnica del WBS para particionar un proyecto en las tareas que lo componen. Si bienlas metodologas giles parten de figuras similares, tienen en cuenta la naturaleza de laspersonas y consecuentemente analizan formas en que las personas obtienen el mejoroutput a partir de dichos inputs.

Uno de los elementos fundamentales asociados a las personas y las interaccioneses el Equipo de Desarrollo. Dado el incremento continuo en la complejidad del

software, no alcanza con esfuerzos individuales para tener xito. Se deben contar conequipos productivos que pueden construir software en forma iterativa, en los que existaun alto grado de comunicacin y donde cada integrante se sienta parte de unacomunidad de personas con un inters en comn: construir software de calidad. Estosequipos de desarrollo debern cubrir dos aspectos que segn [Royce, 1998] definen laexcelencia de un equipo:balancey cobertura.

Orientado a los productos vs. Orientado a las tareas

Otro punto de inflexin que se gener con el movimiento de las metodologasgiles parte de la importancia de los denominados timeboxes o iteraciones. Los mismosindican una clara tendencia a focalizarse en los productos a ser entregados en cadaiteracin, restando importancia a las tareas necesarias para obtener los correspondientesentregables.


50/200


Realizando una analoga con el testing, se podra considerar que AgEnD aplicalo que denominaremos desarrollo decaja negra mientras que las metodologastradicionales utilizan el desarrollo decaja blanca. El primero refiere a la nocin detomar ciertas entradas y verificar las correspondientes salidas. El segundo refiere atomar ciertas entradas, analizar el proceso interno y verificar las correspondientessalidas. Las metodologas tradicionales al considerar a las personas como partesreemplazables de un desarrollo, definen en detalle entradas, salidas y tareas necesariaspara llevar a cabo la correspondiente transformacin. Consecuentemente, estasmetodologas proponen que basta con tener una clara definicin de las tareas en unproyecto para garantizar el xito del mismo. Un WBS nos provee la seguridad necesariapara avanzar en las sucesivas etapas, en el cual describiremos que tareas son necesarias,que necesita cada una para comenzar, y con que artefactos finalizan. Considerando a laspersonas como componentes predecibles y reemplazables, engranajes de unamaquinaria, el desarrollo decaja blanca se convierte en la forma ms adecuada dellevar un proyecto al xito en organizaciones orientadas al proceso. Ejemplos de esto seobservan en los proyectos de software encarados por el departamento de defensa yaquellas grandes organizaciones en las que se tienen niveles de madurez certificados porel CMM.

Una de las razones principales por la que las metodologas giles son Orientadasa los Productos es el principio de Mxima Comunicacin descrito en ms detalle enlas Caractersticas de AgEnD. Dada la necesidad de tener un feedback continuo porparte del cliente, el nfasis de cualquier iteracin esta puesto en los artefactos que estagenera. Las actividades necesarias para la transformacin de entradas en salidas queda adiscrecin del equipo de desarrollo pudiendo utilizar las tcnicas provistas por AgEnDque proporcionan agilidad al proceso. Para lograr que el desarrollo decaja negra tengaxito deberemos tener un equipo integrado, balanceado y altamente motivado. De estostres factores, es la motivacin la que nos permitir lograr mejores resultados en laadopcin de un proceso gil. Es la motivacin la que logra sacar lo mejor de un equipode desarrollo; la que nos permite saber que las personas involucradas utilizarn lastcnicas que les sean ms efectivas para llegar al final de la iteracin con los artefactosms crticos construidos de acuerdo a las estimaciones. La motivacin es por lejos lamayor contribuyente a la productividad [Boehm, 1981].


51/200


Desarrollo Iterativo

Dado el avance de la tecnologa, los tiempos en que se manejan los negocios han

ido reducindose abismalmente. Lo que una dcada atrs demoraba una semana deprocesamiento computacional, hoy se resuelve en cuestin de minutos. Los tiempos deprocesamiento han ido disminuyendo, mientras que los sistemas han ido creciendo encomplejidad teniendo cada vez necesidades mayores de distributibilidad, seguridad,mantenibilidad, flexibilidad, etc.

En el panorama actual en que se encuentra la industria de IS/IT los sistemasdeben contar con atributos jams pensados en sistemas tiempo atrs. Palabras como:multiprocesamiento, sistemas distribuidos, middleware, web services, modelo en trescapas, tolerancia 24x7, multiplataforma, Virtual Machine, son requerimientos nofuncionales tpicos de sistemas de software/hardware en la actualidad. Los nuevosclientes de los actuales sistemas esperan tener su sistema en el menor tiempo posible,con la mxima calidad y conforme a los requerimientos no funcionales necesarios parala operatoria diaria del negocio.

Una de las tareas ms complejas en el desarrollo de sistemas representa ladeterminacin del alcance de lo que se va a construir. Es decir, qu es lo que recibir elcliente en cada release del producto. Que funcionalidad estar incluida? Cmoasegurarnos que es esa la funcionalidad que resuelve las necesidades del cliente?Existen innumerable cantidad de ejemplos en la industria de sistemas de proyectos conextensos perodos de relevamiento, que fueron seguidos por tambin extensos perodosde oscurantismo durante los que el cliente no tena feedback alguno del desarrollo. Engeneral, el resultado de estos proyectos era el fracaso ya que la aplicacin no cumpla

con las necesidades del usuario. El sndrome del IKIWISI (Ill Know It When I See It)entraba en juego, y al no tener feedback alguno del lado del cliente la construccin sellevaba a cabo sobre las especificaciones definidas en forma temprana.

Si tomamos la teora existente detrs del Modelo en Cascada, la misma no hacams que reflejar las teoras encontradas en las otras ingenieras. En estas ltimas, losproyectos comenzaban con fases de ingeniera en que se constataba la factibilidad de losproyectos, se sentaban las bases para la produccin y se mitigaban los posibles riesgosque podan ocurrir. Una vez que se tena una cierta masa crtica de conocimiento, se


52/200


realizaba una transicin a la fase de produccin. En la misma, se ejecutaban todas lastareas analizadas y diseadas en las fases anteriores, las cuales eran de carcterpredecibles y contaban con mayor cantidad de RRHH de menor nivel de capacitacin, ymenores ingresos.

Dadas las caractersticas de dichas ingenieras (Civil, Industrial, Hidrulica,Qumica, etc.) las mismas se prestaban a procesos de desarrollo de caractersticaspredecibles. Tenan un conjunto de requerimientos, los cuales se mantenan estticosdurante la ejecucin y no se modificaban en forma considerable hasta el ltimo da deproduccin. En

buenainformacion xp y fdd

Documents