trabajo metodologias agiles y rigidas lisstttooo

Universidad Jos Faustino Snchez Carrin

Ao De La Integracin Nacional Y El Reconocimiento De Nuestra Diversidad

FACULTAD DE INGENIERAESCUELA ACADMICO PROFESIONAL DE INGENIERA E INFORMATICA

CURSO TEMA DOCENTE CICLO

: ING. SOFTWARE I : METODOLOGIAS AGILES Y RIGIDAS : ING. CIP. EDDY IVN QUISPE SOTO : VI

INTEGRANTES : BUITRN VILLAGARAY, Andy MONTEZA NUEZ, Cleiver

HUACHO PER

2012

Ing. Software I

Pgina 1


RESUMEN

Desarrollar un buen software depende de un sinnmero de actividades y etapas, donde el impacto de elegir la mejor metodologa para un equipo, en un determinado proyecto es trascendental para el xito del producto. El papel preponderante de las metodologas es sin duda esencial en un proyecto y en el paso inicial, que debe encajar en el equipo, guiar y organizar actividades que conlleven a las metas trazadas en el grupo. En el presente trabajo se detallan los dos grandes enfoques, tanto metodologas tradicionales y metodologas giles, las primeras estn pensadas para el uso exhaustivo de documentacin durante todo el ciclo del proyecto mientras que las segundas ponen vital importancia en la capacidad de respuesta a los cambios, la confianza en las habilidades del equipo y al mantener una buena relacin con el cliente. Se vern diferencias, ventajas, desventajas y cual puede encajar en un proyecto de software, es por ello que, ofrecemos una gua dejando libertad de eleccin para el lector el poder juzgar y elegir la mejor metodologa que se adapte a su equipo de desarrollo

Ing. Software I

Pgina 2


INTRODUCCIN

Dentro del desarrollo de software y a la altiva necesidad de que los proyectos lleguen al xito y obtener un producto de gran valor para nuestros clientes, generan grandes cambios en las metodologas adoptadas por los equipos para cumplir sus objetivos, puesto que, unas se adaptan mejor que otras, al contexto del proyecto brindando mejores ventajas. Es por eso de la importancia de una metodologa robusta que ajustada en un equipo cumpla con sus metas, y satisfaga mas all de las necesidades definidas al inicio del proyecto. El xito del producto depende en gran parte de la metodologa escogida por el equipo, ya sea gil o rgida, donde los equipos maximicen su potencial,

aumenten la calidad del producto con los recursos y tiempos establecidos.

Ing. Software I

Pgina 3


NDICE

Introduccin........................................................................................... ndice Historia de los Procesos de Desarrollo............................................... Las Metodologas giles...................................................................... El Manifiesto gil............................................................................... Metodologas giles versus Metodologas Tradicionales.................. Por qu usar Metodologas giles? ............................................... Metodologas giles de Desarrollo de Software.............................. XP eXtreme Programming............................................................... Scrum............................................................................................... Crystal Clear................................................................................... DSDM Dynamic Systems Development Method ........................... Conclusiones.................................................................................... Bibliografia...........................................................................................

3 4 5 15 15 17 18 19 20 25 28 32 37 38

Ing. Software I

Pgina 4


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 de cascada ya que sirvi como base para la formulacin del anlisis estructurado, el cual fue uno de los precursores en el camino hacia la aplicacin de prcticas estandarizadas dentro de la ingeniera de software. Este modelo surge como respuesta al modelo codificar y probar que era el que predominaba en la dcada de los sesenta. En esta poca ya existan modelos iterativos e incrementales pero no eran disciplinados ni estaban formalizados. A consecuencia de esta realidad, la idea de tener un modelo que ordenara el proceso de desarrollo y que pareca bastante sencillo de llevar a la prctica hizo que el modelo en cascada tuviese gran promocin. Este modelo se basaba en el desarrollo en forma de cascada ya que se requera de la finalizacin de la etapa anterior para empezar la siguiente. Esto degeneraba en un congelamiento temprano de los requerimientos, los cuales al presentar cambios requeran gran esfuerzo en re trabajo. Otra opcin era no permitir cambio alguno a los requerimientos una vez que se iniciara el desarrollo lo que traa aparejado que el usuario no vea la aplicacin hasta que ya estaba construida y una vez que interactuaba no cubra sus necesidades. Asimismo, dadas las caractersticas inherentes del modelo, la fase de implementacin del mismo requera el desarrollo de los mdulos en forma independiente con las correspondientes pruebas unitarias, y en la siguiente fase, se realizaba la integracin de los mismos. Esto traa grandes inconvenientes debido a que todo estaba probado en forma unitaria sin interaccin con los dems mdulos. Las sorpresas llegaban cuando se integraban estas piezas para formar la aplicacin; 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 del software (subsanando muchas de las falencias del modelo en cascada) mitigando los riesgos en forma temprana. Los procesos iterativos de los cuales se desprenderan diversas instancias, como son el modelo iterativo e incremental, el modelo en espiral, el modelo basado en prototipo, el modelo SLCD, el MBASE, el RUP, etc. Del modelo en espiral desarrollado por Bar ryBoehm [1] surgi una de las ideas fundamentales que las metodologas posteriores adoptaran: el temprano anlisis de riesgos. El modelo en espiral, de carcter iterativo en sus primeras fases, plantea la necesidad de realizar al principio diversas iteraciones dirigidas a mitigar los riesgos ms crticos relevados en el proyecto mediante la realizacin de Ing. Software I Pgina 5

Universidad Jos Faustino Snchez Carrinprototipos concepto. o simulaciones de tipo desechables tendientes a probar algn

Una vez que esos prototipos son validados se suceden iteraciones del tipo: determinar objetivos, evaluar, desarrollar, planear. Una vez que se tena el diseo detallado y validado por el cliente, se implementaba el software siguiendo las etapas de un modelo en cascada. Esta es una falla importante del modelo ya que no se acomoda a la posibilidad de cambios una vez que se inicia la construccin. Todas las crticas que se le hacan al modelo en cascada se aplican a estas fases del modelo en espiral. Fue el mismo Barry Boehm, quien en un artculo describe tres hitos crticos a ser utilizados en cualquier proyecto p a r a poder 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 de un proyecto de acuerdo a como ocurren las actividades de ingeniera (que componen los espirales del modelo en espiral) a las actividades de produccin (que componen la construccin en cascada del software). Su impacto en la industria del software ha sido tan importante que uno de los procesos mas utilizados en la actualidad, el RUP, los incorpora. Estos hitos Son: Objetivos del Ciclo de Vida Arquitectura del Ciclo de Vida Capacidad de Operacin Inicial

Ing. Software I

Pgina 6

Universidad Jos Faustino Snchez Carrin METODOLOGA TRADICIONAL

Al inicio el desarrollo de software era artesanal en su totalidad, la fuerte necesidad de mejorar el proceso y llevar los proyectos a la meta deseada, tuvieron que importarse la concepcin y fundamentos de metodologas existentes en otras reas y adaptarlas al desarrollo de software. Esta nueva etapa de adaptacin contena el desarrollo dividido en etapas de manera secuencial que de algo mejoraba la necesidad latente en el campo del software.

Entre las principales metodologas tradicionales tenemos los ya tan conocidos RUP y MSF entre otros, que centran su atencin en llevar una documentacin exhaustiva de todo el proyecto y centran su atencin en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto.

Otra de las caractersticas importantes dentro de este enfoque tenemos los altos costos al implementar un cambio y al no ofrecer una buena solucin para proyectos donde el entorno es voltil.

Las metodologas tradicionales (formales) se focalizan en documentacin, planificacin y procesos. (Plantillas, tcnicas de administracin, revisiones, etc.), a continuacin se detalla RUP uno de los mtodos ms usados dentro de los mtodos tradicionalesRATIONAL UNIFIED PROCESS (RUP)FIGURA1. PROCESO UNIFICADO RATIONAL

Ing. Software I

Pgina 7

Universidad Jos Faustino Snchez CarrinRUP es un proceso formal: Provee un acercamiento disciplinado para asignar tareas y responsabilidades dentro de una organizacin de desarrollo. Su objetivo es asegurar la produccin de software de alta calidad que satisfaga los requerimientos de los usuarios finales (respetando cronograma y presupuesto). Fue desarrollado por

Rational Software, y est integrado con toda la suite Rational de herramientas. Puede ser adaptado y extendido para satisfacer las necesidades de la organizacin que lo adopte. (Customizacin). Es guiado por casos de uso y centrado en la arquitectura, y utiliza UML como lenguaje de notacin. Fases Las cuatro fases del ciclo de vida son: Ventajas Evaluacin en cada fase que permite cambios de objetivos Funciona bien en proyectos de innovacin. Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software. Seguimiento detallado en cada una de las fases. Concepcin Elaboracin Construccin Transicin

Desventajas La evaluacin de riesgos es compleja Excesiva flexibilidad para algunos proyectos Estamos poniendo a nuestro cliente en una situacin que puede ser muy incmoda para l. Nuestro cliente deber ser capaz de describir y entender a un gran nivel de detalle para poder acordar un alcance del proyecto con l.

MICROSOFT SOLUTION FRAMEWORK (MSF) Descripcin

MSF es un compendio de las mejores prcticas en cuanto a administracin de proyectos se refiere. Ms que una metodologa rgida de administracin de proyectos, Ing. Software I Pgina 8

Universidad Jos Faustino Snchez CarrinMSF es una serie de modelos que puede adaptarse a cualquier proyecto de tecnologa de informacin. Todo proyecto es separado en cinco principales fases:

Visin y Alcances. Planificacin. Desarrollo. Estabilizacin. Implantacin.

FIGURA 2. MODELO DE EQUIPO DE MSF

Visin y Alcances:

La fase de visin y alcances trata uno de los requisitos ms fundamentales para el xito del proyecto, la unificacin del equipo detrs de una visin comn. El equipo debe tener una visin clara de lo que quisiera lograr para el cliente y ser capaz de indicarlo en trminos que motivarn a todo el equipo y al cliente. Se definen los lderes y responsables del proyecto, adicionalmente se identifican las metas y objetivos a alcanzar; estas ltimas se deben respetar durante la ejecucin del proyecto en su totalidad, y se realiza la evaluacin inicial de riesgos del proyecto.

Planificacin: Es en esta fase es cuando la mayor parte de la planeacin para el proyecto es terminada. El equipo prepara las especificaciones funcionales, realiza el proceso de diseo de la solucin, y prepara los planes de trabajo, estimaciones de costos y cronogramas de los diferentes entregables del proyecto. Desarrollo: Durante esta fase el equipo realice la mayor parte de la construccin de los componentes (tanto documentacin como cdigo), sin embargo, se puede realizar algn trabajo de desarrollo durante la etapa de estabilizacin en respuesta a los resultados de las pruebas. La infraestructura tambin es desarrollada durante esta fase. Ing. Software I Pgina 9

Universidad Jos Faustino Snchez CarrinEstabilizacin: En esta fase se conducen pruebas sobre la solucin, las pruebas de esta etapa enfatizan el uso y operacin bajo condiciones realistas. El equipo se enfoca en priorizar y resolver errores y preparar la solucin para el lanzamiento. Implantacin: Durante esta fase el equipo implanta la tecnologa base y los componentes relacionados, estabiliza la instalacin, traspasa el proyecto al personal soporte y operaciones, y obtiene la aprobacin final del cliente.

Modelo de rolesalgunas de las desventajas impuestas por las estructuras jerrquicas de los equipos en los proyectos tradicionales.

Los equipos organizados bajo este modelo son pequeos y multidisciplinarios, en los cuales los miembros comparten responsabilidades y balancean las destrezas del equipo para mantenerse enfocados en el proyecto que estn desarrollando. Comparten una visin comn del proyecto y se enfocan en implementar la solucin, con altos estndares de calidad y deseos de aprender.

El modelo de equipos de MSF tiene seis roles que corresponden a las metas principales de un proyecto y son responsables por las mismas. Cada rol puede estar compuestos por una o ms personas, la estructura circular del modelo, con valos del mismo tamao para todos los roles, muestra que no es un modelo jerrquico y que cada todos los roles son igualmente importantes en su aporte al proyecto. Aunque los roles pueden tener diferentes niveles de actividad durante las diversas etapas del proyecto, ninguno puede ser omitido.

La comunicacin se pone en el centro del crculo para mostrar que est integrada en la estructura y fluye en todas direcciones. El modelo apoya la comunicacin efectiva y es esencial para el funcionamiento del mismo

Ing. Software I

Pgina 10

Universidad Jos Faustino Snchez CarrinEjemplo de metodologa MSF aplicada

Como ejemplo de una aplicacin de metodologa MSF a un proyecto, a continuacin se describe el contenido de cada una de las fases y, en la medida de lo posible, un detalle de acciones concretas y estimacin de carga de trabajo en trminos de jornadas, nmero de personas implicadas y perfil de las mismas. El proyecto ejemplo se trata de una implantacin de infraestructuras, en concreto, migracin a Windows 2000 de una red de servidores. Fase 1 - Estrategia y alcance

En esta fase deberan tener lugar los siguientes trabajos: Elaboracin y aprobacin del Documento de Alcance y Estrategia definitivo: debe ser un documento de consenso con la participacin del mayor nmero de agentes implicados en el proyecto. En este documento quedarn

definitivamente reflejadas las funcionalidades y servicios que, ineludiblemente, debe ofrecer la solucin a implantar. Formacin del Equipo de Trabajo y distribucin de competencias y responsabilidades: generalmente se definen como reas principales la de Diseo de Arquitectura, Pruebas de Laboratorio, Documentacin, Logstica y Coordinacin. Elaboracin del Plan de Trabajo: deben marcarse fechas y contenidos para esta fase y las siguientes. Los mecanismos y protocolos de intercambio de informacin y coordinacin deben quedar suficientemente bien establecidos y consensuados. Elaboracin de la matriz de Riesgos y Plan de Contingencia: los principales riesgos detectados deben tener un plan de mitigacin y actuacin y revisarse con periodicidad. Para un proyecto de migracin a Windows 2000 podra estimarse que los trabajos indicados pueden requerir en torno a 20 jornadas de trabajo y la intervencin de un Consultor de Microsoft junto con el equipo de trabajo que formen El cliente y el Partner. Fase 2 - Planificacin y Prueba de Concepto

Deben alcanzarse los siguientes objetivos e hitos: Documento de Planificacin y Diseo de Arquitectura: es el documento principal, donde se describen en detalle los aspectos funcionales y operativos Ing. Software I Pgina 11

Universidad Jos Faustino Snchez Carrinde la nueva plataforma. La aprobacin de este documento es el hito principal de esta fase, y supone la directriz ltima de todos los trabajos tcnicos, que, a partir de ese momento, deben ser consistentes con esta Gua. Si en el curso de las fases sucesivas fuera necesario revisar estos contenidos, se deber hacer por acuerdo y conocimiento de todo el equipo de trabajo y se llevar un registro de versiones que permita hacer un seguimiento adecuado de estas revisiones. Documento de Plan de Laboratorio - Prueba de Concepto: la descripcin del contenido del laboratorio de prueba de concepto, los diversos escenarios a simular, los criterios de validez, el control de incidencias y las mtricas de calidad son objetivos a cubrir en este documento. Es un documento dinmico, en el que se recoge la idea y la experiencia prctica al llevarla a cabo en entorno controlado y aislado. La etapa de prueba de laboratorio concluye cuando la maqueta ofrece todos los servicios y funciones descritos en el Documento de Alcance y Estrategia, y su grado de estabilidad y rendimiento es considerado como "suficiente".

Habitualmente, en las propuestas de preventa no se pueden indicar con precisin parmetros como el esfuerzo tcnico, tiempo o coste definitivo que puede suponer esta fase. De otras experiencias anteriores se puede obtener una relacin de trabajos slo a ttulo orientativo, y que debe ser revisado y acordado por todas las partes:

El cmputo de jornadas para la relacin de actividades descritas (que como se observa slo recogen las relativas a la Planificacin y Diseo, y deja aparte las necesarias para elaborar el plan de Migracin), ofrecera este resultado: Jornadas totales: 80 (aprox. 4 meses) Jornadas / tcnico del PARTNER: 150 jornadas (2 personas) Jornadas / tcnico del CLIENTE: 110 jornadas (Max. 2 personas) Fase 3 Estabilizacin

La solucin implantada en la maqueta se pasa a un entorno real de explotacin, restringido en nmero de usuarios y en condiciones tales que se pueda llevar un control efectivo de la situacin. Los hitos y objetivos fundamentales de esta fase son: Seleccin del entorno de prueba piloto: se acordar la composicin y ubicacin del conjunto de mquinas y usuarios que entrarn en la prueba. Esta seleccin se recomienda que se haga atendiendo a la mayor variedad posible Ing. Software I Pgina 12

Universidad Jos Faustino Snchez Carrinde casos, de manera que puedan aflorar el mximo de incidentes potenciales en el menor tiempo posible. La dimensin de la muestra tiene tambin que calcularse, sin perder de vista que la prueba piloto no es el despliegue propiamente, sino una fase de observacin en la que es absolutamente crtico establecer unos cauces efectivos de tratamiento de los errores. Gestin de Incidencias: aunque esta labor se habr iniciado en la fase anterior, el xito de la prueba piloto depender de que se forme un sistema de recogida de incidentes (helpdesk o similar), de atencin al usuario (formacin, consultas) y de resolucin de problemas y documentacin de los mismos (versionado de la plataforma). Revisin de la documentacin final de Arquitectura: el documento de Planificacin y Diseo de Arquitectura se puede ver alterado parcialmente como resultado de esta fase. El documento final, aprobado por consenso, supone el principal documento del Proyecto y la culminacin de los trabajos de diseo, al menos en sus lneas principales. Este documento se considerar definitivo cuando la solucin puesta en marcha se muestre estable y el nmero de incidencias graves (de intervencin o de resolucin) sea nulo y la cantidad de las consideradas leves quede por debajo de un lmite establecido en las Mtricas de Calidad. Elaboracin de la documentacin de Formacin y Operaciones: con vistas al soporte post proyecto y los programas de formacin a usuarios y administradores, en esta fase deben elaborarse las Guas de Usuario, de Administracin, las "paso-a-paso", y otros cuyos contenidos deben acordarse previamente. Elaboracin del Plan de Despliegue: se debe consensuar la fecha de finalizacin de la fase Piloto, y las condiciones de calidad que debe cumplir la solucin final para iniciar el despliegue. En el Plan deben identificarse las fases, estrategia de implantacin, fechas, tareas a realizar, procedimientos de validacin y mtodo de control de incidencias. Elaboracin del Plan de Formacin: con anterioridad al despliegue definitivo, debe haberse aprobado el Plan de Formacin orientado a usuarios finales y administradores, y debe hacerse compatible con los ritmos acordados en el Plan de Despliegue. El tiempo necesario para abordar esta fase es variable y depende en parte de factores ajenos a la complejidad de la propia solucin, como es la adecuada seleccin del entorno de prueba y el momento del ao en que tenga lugar (evitando que coincida con periodos de vacaciones o puntas de trabajo crticas como Fin de Ao). En Ing. Software I Pgina 13

Universidad Jos Faustino Snchez Carrinproyectos de similar envergadura se ha llegado al momento "Error Free Versin" en 30 jornadas de trabajo (aproximadamente mes y medio) con una muestra de 50 usuarios. Fase 4 Despliegue

Se llevarn a cabo en esta fase los planes diseados en la anterior, principalmente el de despliegue y el de formacin. Los principales trabajos e hitos a conseguir son, en este caso, adems de los obvios (implantacin de la plataforma, puesta en servicio de todas las funciones, formacin a los usuarios y administradores), los siguientes: Continuacin con las labores de recepcin de incidencias, clasificacin, tratamiento, resolucin y distribucin de faxes o intervencin on-site. Registro de mejoras y sugerencias, funcionalidades no cubiertas y novedades a incorporar en sucesivas versiones de la plataforma, incluyendo mejoras aportadas por los fabricantes de software (nuevas versiones o Service Packs, por ejemplo) Revisin de las Guas y manuales de usuario, rectificacin de errores y obtencin de los documentos de formacin definitivos. Entrega de los documentos definitivos acordados como "deliverables" en la fase de VisionScope. Revisin (si procede) de la matriz de riesgos, las mtricas de calidad y establecimiento de los estndares de calidad y SLA definitivos. Finalmente, entrega del Proyecto y cierre del mismo, con o sin apertura de nuevo proyecto en base a la informacin y experiencia obtenidas. La duracin fase de despliegue, puesto que debe planificarse, no puede establecerse a priori. Depende de numerosos factores externos al propio proyecto (incluyendo factores de oportunidad poltica o de negocio) que pueden retardar o acelerar la conclusin. La experiencia demuestra que no hay una relacin directa entre nmero de mquinas y tiempo necesario para el despliegue. Los factores ms relevantes en el clculo suelen ser la dispersin o concentracin geogrfica, la complejidad del proceso de migracin, el grado de automatizacin alcanzado, la experiencia y nivel de los tcnicos que realizan la operacin y condicionantes de calendario, a menudo con restricciones no tcnicas, sino de otros tipos (las fechas-objetivo suelen marcarse por criterios de oportunidad de negocio).

Ing. Software I

Pgina 14

Universidad Jos Faustino Snchez Carrin LAS METODOLOGAS GILES

A principios de la dcada del 90, surgi un enfoque que fue bastante revolucionario para su momento ya que iba en contra de toda creencia de que mediante procesos altamente definidos se iba a lograr obtener software en tiempo, costo y con la requerida calidad. El enfoque fue planteado por primera vez por Martin[2] y se dio a conocer en la comunidad de Ingeniera de Software con el nombre de RAD o Rapid ApplicationDevelopment. RAD consista en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeos de programadores utilizando herramientas que generaban cdigo en forma Automtica tomando como entradas sintaxis de alto nivel. En general, se considera que este fue uno de los primeros hitos en pos de la agilidad en los procesos de desarrollo. La historia de las Metodologas giles y su apreciacin como tales en la comunidad de la Ingeniera de Software tiene sus inicios en la creacin de una de las metodologas utilizada como arquetipo: XP - eXtremeProgramming, que nace de la mente de Kent Beck, tomando ideas recopiladas junto a Ward Cunningham.

EL MANIFIESTO GIL El Manifiesto gil comienza enumerando los principales valores del desarrollogil. Segn el Manifiesto se valora: Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de xito de un proyecto software. Es ms importante construir un buen equipoque construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automticamente. Es mejor crear el equipo y que ste configure su propio entorno de desarrollo en base a sus necesidades. Desarrollar software que funciona ms que conseguir una buena documentacin. La regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar una decisin importante. Estos documentos deben ser cortos y centrarse en lo fundamental. La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su xito. Responder a los cambios ms que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.)

Ing. Software I

Pgina 15

Universidad Jos Faustino Snchez CarrinDetermina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible y abierta. Los valores anteriores inspiran los doce principios del manifiesto. Son caractersticas que diferencian un proceso gil de uno tradicional. Los dos primeros principios son generales y resumen gran parte del espritu gil. El resto tienen que ver con el proceso a seguir y con el equipo de desarrollo, en cuanto metas a seguir y organizacin del mismo. Los principios son:

I. La prioridad es satisfacer al cliente entregas de software que le aporte un valor.

mediante

tempranas

y

continuas

II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. III. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. VI. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo. VII. El software que funciona es la medida principal de progreso. VIII. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante. IX. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. X. La simplicidad es esencial. XI. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos. XII. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento.

Ing. Software I

Pgina 16


METODOLOGAS GILES VERSUS METODOLOGAS TRADICIONALES La Tabla N 1 recoge esquemticamente las principales diferencias de las metodologas giles con respecto a las tradicionales (no giles). Estas diferencias que afectan no slo al proceso en s, sino tambin al contexto del equipo as como a su organizacin.

Tabla N1. Diferencias entre Metodologas giles y no giles.

Tener metodologas diferentes para aplicar de acuerdo con el proyecto que se desarrolle resulta una idea interesante. Estas metodologas pueden involucrar prcticas tanto de metodologas giles como de metodologas tradicionales. De esta manera podramos tener una metodologa para cada proyecto, la problemtica sera definir cada una de las prcticas, y en el momento preciso definir parmetros para saber cual usar. Es importante tener en cuenta que el uso de un mtodo gil no es para todos. Sin embargo, una de las principales ventajas de los mtodos giles es su peso Ing. Software I Pgina 17

Universidad Jos Faustino Snchez Carrininicialmente ligero y por eso las personas que no estn acostumbradas a seguir procesos encuentran estas metodologas bastante agradables.

POR QU USAR METODOLOGAS GILES? Tomando las ideas de la Tabla N 1 podemos decir que las metodologas Tradicionales presentan los siguientes problemas a la hora de abordar proyectos: Existen unas costosas fases previas de especificacin de requisitos, anlisis y Diseo. La correccin durante el desarrollo de errores introducidos en estas fases ser costosa, es decir, se pierde flexibilidad ante los cambios. El proceso de desarrollo est encorsetado por documentos firmados. El desarrollo es ms lento. Es difcil para los desarrolladores entender un sistema complejo en su globalidad.

Las metodologas giles de desarrollo estn especialmente indicadas en proyectos con requisitos poco definidos o cambiantes. Estas metodologas se aplican bien en equipos pequeos que resuelven problemas concretos, lo que no est reido con su aplicacin en el desarrollo de grandes sistemas, ya que una correcta modularizacin de los mismos es fundamental para su exitosa implantacin. Dividir el trabajo en mdulos abordables minimiza los fallos y el coste. Las metodologas giles presentan diversas ventajas, entre las que podemos destacar:

Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo Entrega continua y en plazos breves de software funcional Trabajo conjunto entre el cliente y el equipo de desarrollo Importancia de la simplicidad, eliminado el trabajo innecesario Atencin contina a la excelencia tcnica y al buen diseo Mejora continua de los procesos y el equipo de desarrollo

Ing. Software I

Pgina 18

Universidad Jos Faustino Snchez CarrinMETODOLOGAS GILES DE DESARROLLO DE SOFTWARE En la Tabla N2 apreciamos las convergencias y divergencias en la definicin de las metodologas giles ms importantes.

Ing. Software I

Pgina 19


Tabla N2. Tabla de convergencias y divergencias entre las principales metodologas giles.

A continuacin describir brevemente algunas de las destacadas hasta el momento.

metodologas giles ms

XP- eXtremeProgramming XP es la primera metodologa gil y la que le dio conciencia al movimiento actual de metodologas giles. De la mano de Kent Beck, XP ha conformado un extenso grupo de seguidores en todo el mundo, disparando una gran cantidad de libros a los que dio comienzo el mismo Beck en [3]. Inclusive Addison-Wesley ha creado una serie de libros denominada The XP Series. La imagen mental de Beck al crear XP [3] era la de perillas en un tablero de control. Cada perilla representaba una prctica que de su experiencia saba que trabajaba bien. Entonces, Beck decidi girar todas las perillas al mximo para ver que ocurra. As fue como dio inicio a XP.

Figura N1. Evolucin de los largos ciclos de desarrollo en cascada (a) a ciclos iterativos ms cortos (b) y a la mezcla que hace XP.

Ing. Software I

Pgina 20

Universidad Jos Faustino Snchez CarrinXP es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en el desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico. A continuacin presentaremos las caractersticas esenciales de XP organizadas en los tres apartados siguientes: historias de usuario, roles, proceso y prcticas.

A. Las Historias de Usuario Son la tcnica utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las caractersticas que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento delas historias de usuario es muy dinmico y flexible. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas. Beck en su libro [3] presenta un ejemplo de ficha ( customerstory and taskcard) en la cual pueden reconocerse los siguientes contenidos: fecha, tipo de actividad (nueva, correccin, mejora), prueba funcional, nmero de historia, prioridad tcnica y del cliente, referencia a otra historia previa, riesgo, estimacin tcnica, descripcin, notas y una lista de seguimiento con la fecha, estado cosas por terminar y comentarios. A efectos de planificacin, las historias pueden ser de una a tres semanas de tiempo de programacin (para no superar el tamao deuna iteracin). Las historias de usuario son descompuestas en tareas de programacin (taskcard) y asignadas a los programadores para ser implementadas durante una iteracin.

B. Roles XP Los roles de acuerdo con la propuesta original de Beck son: - Programador. El programador escribe las pruebas unitarias y produce el cdigo del sistema. - Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar mayor valor al negocio.

Ing. Software I

Pgina 21

Universidad Jos Faustino Snchez Carrin- Encargado de pruebas (Tester ). Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. - Encargado de seguimiento ( Tracker ). Proporciona realimentacin al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteracin. - Entrenador (Coach). Es responsable del proceso global. Debe proveer guas al equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente. - Consultor. Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto, en el que puedan surgir problemas. - Gestor (B igboss). Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin.

C. Proceso XP El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos: 1. El cliente define el valor de negocio a implementar. 2. El programador estima el esfuerzo necesario para su implementacin. 3. El cliente selecciona qu construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4. El programador construye ese valor de negocio. 5. Vuelve al paso 1.

En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar ms trabajo que el estimado, ya que se perder calidad en el software o no se cumplirn los plazos. De la misma forma el cliente tiene la obligacin de manejar el mbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteracin. El ciclo de vida ideal de XP consiste de seis fases: Exploracin, Planificacin de la Entrega (Release), Iteraciones, Produccin, Mantenimiento y Muerte del Proyecto.

Ing. Software I

Pgina 22

Universidad Jos Faustino Snchez CarrinD. Prcticas XP La principal suposicin que se realiza en XP es la posibilidad de disminuir la mtica curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseo evolutivo funcione. Esto se consigue gracias a las tecnologas disponibles para ayudar en el desarrollo de software y a la aplicacin disciplinada de las siguientes prcticas.

El juego de la planificacin. Hay una comunicacin frecuenteel cliente y los programadores. El equipo tcnico realiza una estimacin del esfuerzo requerido para la implementacin de las historias de usuario y los clientes deciden sobre el mbito y tiempo de las entregas y de cada iteracin. Entregas pequeas. Producir rpidamente versiones del sistema que sean operativas, aunque no cuenten con toda la funcionalidad del sistema. Esta versin ya constituye un resultado de valor para el negocio. Una entrega no debera tardar ms 3 meses. Metfora. El sistema es definido mediante una metfora o un conjunto de metforas compartidas por el cliente y el equipo de desarrollo. Una metfora es una historia compartida que describe cmo debera funcionar el sistema (conjunto de nombres que acten como vocabulario para hablar sobre el dominio del problema , ayudando a la nomenclatura de clases y mtodos del sistema). Diseo simple. Se debe disear la solucin ms simple que pueda funcionar y ser implementada en un momento determinado del proyecto. Pruebas. La produccin de cdigo est dirigida por las pruebas unitarias. stas son establecidas por el cliente antes de escribirse el cdigo y son ejecutadas constantemente ante cada modificacin del sistema. Refactorizacin (Refactoring). Es una actividad constante de reestructuracin del cdigo con el objetivo de remover duplicacin de cdigo, mejorar su legibilidad, simplificarlo y hacerlo ms flexible para facilitar los posteriores cambios. Se mejora la estructura interna del cdigo sin alterar su comportamiento externo. Programacin en parejas. Toda la produccin de cdigo debe realizarse con trabajo en parejas de programadores. Esto conlleva ventajas implcitas (menor tasa de errores, mejor diseo, mayor satisfaccin de los programadores, etc.). Propiedad colectiva del cdigo. Cualquier programador puede cambiar cualquier parte del cdigo en cualquier momento. Integracin continua. Cada pieza de cdigo es integrada en el sistema una vez que est lista. As, el sistema puede llegar a ser integrado y construido varias veces en un mismo da. 40 horas por semana. Se debe trabajar un mximo de 40 horas por semana. No se trabajan horas extras en dos semanas seguidas. Si esto ocurre, Ing. Software I Pgina 23

Universidad Jos Faustino Snchez Carrinprobablemente est ocurriendo un problema que debe corregirse. El trabajo extra desmotiva al equipo. Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo para el equipo. ste es uno de los principales factores de xito del proyecto XP. El cliente conduce constantemente el trabajo hacia lo que aportar mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. La comunicacin oral es ms efectiva que la escrita. Estndares de programacin. XP enfatiza que la comunicacin de los programadores es a travs del cdigo, con lo cual es indispensable que se sigan ciertos estndares de programacin para mantener el cdigo legible.

Figura N2. Las prcticas se refuerzan entre s.

El mayor beneficio de las prcticas se consigue con su aplicacin conjunta y equilibrada puesto que se apoyan unas en otras. Esto se ilustra en la Figura N 2, donde una lnea entre dos prcticas significa que las dos prcticas se refuerzan entre s. La mayora de las prcticas propuestas por XP no son novedosas sino que en alguna forma ya haban sido propuestas en ingeniera del software e incluso demostrado su valor en la prctica El mrito de XP es integrarlas de una forma y complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo. Si bien XP es la metodologa gil de ms renombre en la actualidad, se diferencia de las dems metodologas que forman este grupo en un aspecto en particular: el alto nivel de disciplina de las personas que participan en el proyecto. Ing. Software I Pgina 24


Figura N3. Encuesta de IBM (octubre de 2000): Qu opina de eXtremeProgramming?

SCRUM Scrum define un proceso emprico, iterativo e incremental de desarrolloque intenta obtener ventajas respecto a los procesos definidos (cascada, espiral, prototipos, etc.) mediante la aceptacin de la naturaleza catica del desarrollo de software, y la utilizacin de prcticas tendientes a manejar la impredictibilidad y el riesgo a niveles aceptables. El mismo surge e n 1 9 8 6 , de un artculo de la Harvard Business Review titulado The New NewProductDevelopmentGame de HirotakaTakeuchi e IkujiroNonaka, que introduca las mejores prcticas ms utilizadas en 10 compaas japonesas altamente innovadoras. A partir de ah y tomando referencias al juego de rugby, Ken Scwaber y Jeff Sutherland formalizan el proceso conocido como Scrum en el ao 1995. Scrum es un mtodo iterativo e incremental que enfatiza prcticas y valores de projectmanagement por sobre las dems disciplinas del desarrollo. Al principio del proyecto se define el ProductBacklog, que contiene todos los requerimientos funcionales y no funcionales que deber satisfacer el sistema a construir. Los mismos estarn 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 las que se ir evolucionando la aplicacin evolutivamente. Cada Sprint tendr su propio Sprint Backlog que ser un subconjunto del ProductBacklog con los requerimientos a ser construidos en el Sprint correspondiente. La duracin recomendada del Sprint es de un mes. Dentro de cada Sprint el Scrum Master (equivalente al Lder de Proyecto) llevar a cabo la gestin de la iteracin, convocando diariamente al ScrumDaily Meeting que representa una reunin de avance diaria de no ms de 15 minutos con el propsito de tener realimentacin sobre las tareas de los recursos y los obstculos que se presentan. Al final de cada Sprint, se realizar un Sprint Ing. Software I Pgina 25

Universidad Jos Faustino Snchez CarrinReview para evaluar los artefactos construidos y comentar el planeamiento del prximo Sprint. Como se puede observar en la Figura N4 la metodologa resulta sencilla definiendo algunos roles y artefactos que contribuyen a tener un proceso que maximiza el feedback para mitigar cualquier riesgo que pueda presentarse.

Scrum aplicado al Desarrollo de Software Aunque surgi como modelo para el desarrollo de productos tecnolgicos, tambin se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software. Jeff Sutherland aplic el modelo Scrum al desarrollo de software en 1993 en EaselCorporation (Empresa que en los macro-juegos de compras y fusiones se integrara en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo present junto con Ken Schwaber como proceso formal,tambin para gestin del desarrollo de software en OOPSLA 96. En el desarrollo de software Scrum est considerado como modelo gil por la Agile Alliance

Figura N4. Descripcin de Roles, artefactos, reuniones y proceso de desarrollo de Scrum.

La intencin de Scrum es la de maximizar la realimentacin sobre el desarrollo pudiendo corregir problemas y mitigar riesgos de forma temprana. Su uso se est extendiendo cada vez ms dentro de la comunidad de Metodologas giles, siendo combinado con otras como XP para completar sus carencias. Cabe mencionar que Scrum no propone el uso de ninguna prctica de desarrollo en Ing. Software I Pgina 26

Universidad Jos Faustino Snchez Carrinparticular; sin embargo, es habitual emplearlo como un framework gil de administracin de proyectos que puede ser combinado con cualquiera de las metodologas mencionadas.

Ciclo de Vida de Scrum El ciclo de vida de Scrum es el siguiente: 1. Pre-Juego: Planeamiento. El propsito es establecer la visin, definir expectativas y asegurarse la financiacin. Las actividades son la escritura de la visin, el presupuesto, el registro de acumulacin o retraso (backlog) del producto inicial y los tems estimados, as como la arquitectura de alto nivel, el diseo exploratorio y los prototipos. El registro de acumulacin es de alto nivel de abstraccin. 2. Pre-Juego: Montaje (Staging). El propsito es identificar ms requerimientos y priorizar las tareas para la primera iteracin. Las actividades son planificacin, diseo exploratorio y prototipos. 3. Juego o Desarrollo. El propsito es implementar un sistema listo para entrega en una serie de iteraciones de treinta das llamadas corridas (sprints). Las actividades son un encuentro de planeamiento de corridas en cada iteracin, la definicin del registro de acumulacin de corridas y los estimados, y encuentros diarios de Scrum. 4. Pos-Juego: Liberacin. El propsito es el despliegue actividades, documentacin, entrenamiento, mercadeo y venta. operacional. Las

Usualmente los registros de acumulacin se llevan en planillas de clculo comunes, antes que en una herramienta sofisticada de gestin de proyectos. Los elementos del registro pueden ser prestaciones del software, funciones, correccin de bugs, mejoras requeridas y actualizaciones de tecnologa. Hay un registro total del producto y otro especfico para cada corrida de 30 das. En la jerga de Scrum se llaman paquetes a los objetos o componentes que necesitan cambiarse en la siguiente iteracin.

Ing. Software I

Pgina 27


Figura N5. Ciclo de Carrera o de Vida (Sprint) de Scrum.

La lista de Acumulacin del Producto contiene todos los rasgos, tecnologa, mejoras y lista de bugs que, a medida que se desenvuelven, constituyen las futuras entregas del producto. Los rasgos ms urgentes merecern mayor detalle, los que pueden esperar se tratarn de manera ms sumaria. La lista se origina a partir de una variedad de fuentes. El grupo de mercadeo genera los rasgos y la funcin; la gente de ventas genera elementos que harn que el producto sea ms competitivo; los de ingeniera aportarn paquetes que lo harn ms robusto; el cliente ingresar debilidades o problemas que debern resolverse. El propietario de la administracin y el control del backlog en productos comerciales bien puede ser el product manager; para desarrollos in-house podra ser el project manager, o alguien designado por l. Serecomienda que una sola persona defina la prioridad de una tarea; si alguien tiene otra opinin, deber convencer al responsable. Se estima que priorizar adecuadamente una lista de producto puede resultar dificultosa al principio del desarrollo, pero deviene ms fcil con el correr del tiempo. Al fin de cada iteracin de treinta das hay una demostracin a cargo del Scrum Master. Las presentaciones en PowerPoint estn prohibidas. En los encuentros diarios, las gallinas deben estar fuera del crculo. Todos tienen que ser puntuales; si alguien llega tarde, se le cobra una multa que se destinar a obras de caridad. Es permitido usar artefactos de los mtodos a los que Scrum acompae, por ejemplo Listas de Riesgos si se utiliza UP, Planguage si el mtodo es Evo, o los Planes de Proyecto sugeridos en la disciplina de Gestin de Proyectos de Microsoft Solutions Framework. No es legal, en cambio, el uso de instrumentos tales como diagramas PERT, porque stos parten del supuesto de que las tareas de un proyecto se pueden identificar y ordenar; en Scrum el supuesto dominante es que el desarrollo es semi-catico, cambiante y tiene demasiado ruido como para que se le aplique un proceso definido. Algunos textos sobre Scrum establecen una arquitectura global en la fase de pre-juego; otros dicen que no hay una arquitectura global en Scrum, sino que la arquitectura y el diseo emanan de mltiples corridas. No hay una ingeniera del software prescripta para Scrum; cada quien puede escoger entonces las prcticas de automatizacin, inspeccin de cdigo, prueba Ing. Software I Pgina 28

Universidad Jos Faustino Snchez Carrinunitaria, anlisis o programacin en pares que le resulten adecuadas. Como ya se ha mencionado antes, es muy habitual que Scrum se complemente con XP; en estos casos, Scrum suministra un marco de management basado en patrones organizacionales, mientras XP constituye la prctica de programacin, usualmente orientada a objetos y con fuerte uso de patrones de diseo. Uno de los nombres que se utiliza para esta alianza es XP@Scrum. Tambin son viables los hbridos con otras metodologas giles.

CRYSTAL CLEAR AlistairCockburn es el propulsor detrs de la serie de metodologas Crystal. Las mismas presentan un enfoque gil, con gran nfasis en la comunicacin, y con cierta tolerancia 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 ms documentacin se dispone. La misma se define con mucho nfasis en la comunicacin y de forma muy liviana en relacin a los entregables. Crystal maneja iteraciones cortas con feedback frecuente por parte de los usuarios/clientes, minimizando de esta forma la necesidad de productos intermedios. Otra de las cuestiones planteadas es la necesidad de disponer de un usuario real aunque sea de forma parte time para realizar validaciones sobre la Interface del Usuario y para participar en la definicin de los requerimientos funcionales y no funcionales del software. Comparar el software con la ingeniera nos conduce a preguntarnos sobre especificaciones y modelos del software, sobre su completitud, correccin y vigencia. Esas preguntas son inconducentes, porque cuando pasa cierto tiempo no nos interesa que los modelos sean completos, que coincidan con el mundo real (sea ello lo que fuere) o que estn al da con la versin actual del lenguaje. Intentar que as sea es una prdida de tiempo [4]. En contra de esa visin ingenieril a la manera de un Bertrand Meyer, Cockburn ha alternado diversas visiones despreocupadamente contradictorias que alternativamente lo condujeron a adoptar XP en el sentido ms radical, a sinergizarse con DSDM o LSD, a concebir el desarrollo de software como una forma comunitaria de poesa o a elaborar su propia familia de Metodologas Crystal. La familia Crystal dispone un cdigo de color para marcar la complejidad de una metodologa: cuanto ms oscuro un color, ms pesado es el mtodo. Cuanto ms crtico es un sistema, ms rigor se requiere. El cdigo cromtico se aplica a una forma tabular elaborada por Cockburn que se usa en muchas metodologas giles para situar el rango de complejidad al cual se aplica una metodologa. En la Figura N6 se muestra una evaluacin de las prdidas que puede ocasionar la falla de un sistema y el mtodorequerido segn este criterio. Los parmetros son Comodidad (C), Dinero Discrecional (D), Dinero Esencial (E) y Vidas (L). En otras palabras, la cada de un sistema que ocasione incomodidades indica que su nivel de criticalidad es C, mientras que si causa prdidas de vidas su nivel es L. Los nmeros del cuadro indican el nmero de personas afectadas a un proyecto.

Ing. Software I

Pgina 29


Figura N6. Familia de CrystalMethods

Los mtodos se llaman Crystal evocando las facetas de una gema: cada faceta es otra versin del proceso, y todas se sitan en torno a un ncleo idntico. Hay cuatro variantes de metodologas: Crystal Clear (Claro como el cristal) para equipos de 8 o menos integrantes; Amarillo, para 8 a 20; Naranja, para 20 a 50; Rojo, para 50 a 100. Se promete seguir con Marrn, Azul y Violeta. La ms exhaustivamente documentada es Crystal Clear (CC), la misma que puede ser usada en proyectos pequeos de categora D6, aunque con alguna extensin se aplica tambin a niveles E8 a D10. El otro mtodo elaborado en profundidad es el Naranja, apto para proyectos de duracin estimada en 2 aos. Los otros dos an se estn desarrollando. Como casi todos los otros mtodos, CC consiste en valores, tcnicas y procesos. Los siete valores o propiedades de Crystal Clear son: 1. Entrega frecuente. Consiste en entregar software a los clientes con frecuencia, no solamente en compilar el cdigo. La frecuencia depender del proyecto, pero puede ser diaria, semanal, mensual o lo que fuere. La entrega puede hacerse sin despliegue, si es que se consigue algn usuario corts o curioso que suministre feedback. 2. Comunicacin osmtica. Todos juntos en el mismo cuarto. Una varianteespecial es disponer en la sala de un diseador senior; eso se llama Experto al Alcance de la Oreja. Una reunin separada para que los concurrentes se concentren mejor es descripta como El Cono del Silencio.

Ing. Software I

Pgina 30

Universidad Jos Faustino Snchez Carrin3. Mejora reflexiva. Tomarse un pequeo tiempo (unas pocas horas por algunas semanas o una vez al mes) para pensar bien qu se est haciendo, cotejar notas, reflexionar, discutir. 4. Seguridad personal. Hablar cuando algo molesta: decirle amigablemente al manager que la agenda no es realista, o a un colega que su cdigo necesita mejorarse, o que sera conveniente que se baase ms seguido. Esto es importante porque el equipo puede descubrir y reparar sus debilidades. No es provechoso encubrir los desacuerdos con gentileza y conciliacin. Tcnicamente, estas cuestiones se han caracterizado como una importante variable de confianza y han sido estudiadas con seriedad en la literatura. 5. Foco. Saber lo que se est haciendo y tener la tranquilidad y el tiempo para hacerlo. Lo primero debe venir de la comunicacin sobre direccin y prioridades, tpicamente con el Patrocinador Ejecutivo. Lo segundo, de un ambiente en que la gente no se vea compelida a hacer otras cosas incompatibles. 6. Fcil acceso a usuarios expertos. Una comunicacin de Keil a la ACM demostr hace tiempo, sobre una amplia muestra estadstica, la importancia del contacto directo con expertos en el desarrollo de un proyecto. No hay un dogma de vida o muerte sobre esto, como s lo hay en XP. Un encuentro semanal o semisemanal con llamados telefnicos adicionales parece ser una buena pauta. Otra variante es que los programadores se entrenen para ser usuarios durante un tiempo. El equipo de desarrollo, de todas maneras, incluye un Experto en Negocios. 7. Ambiente tcnico con prueba automatizada, management de configuracin e integracin frecuente. Microsoft estableci la idea de los builds cotidianos, y no es una mala prctica. Muchos equipos giles compilan e integran varias veces al da. El proceso de Cristal Clear se basa en una exploracin refinada de los inconvenientes de los modelos clsicos. Dice Cockburn que la mayora de los modelos de proceso propuestos entre 1970 y 2000 se describan como secuencias de pasos. An cuando se recomendaran iteraciones e incrementos (que no hacan ms que agregar confusin a la interpretacin) los modelos parecan dictar un proceso en cascada, por ms que los autores aseguraran que no era as. El problema con estos procesos es que realmente estn describiendo un workflow requerido, un grafo de dependencia: el equipo no puede entregar un sistema hasta que est integrado y corre. No puede integrar y verificar hasta que el cdigo no est escrito y corriendo. Y no puede disear y escribir el cdigo hasta que se le dice cules son los requerimientos. Un grafo de dependencia se interpreta necesariamente en ese sentido, aunque no haya sido la intencin original.

Ing. Software I

Pgina 31


Figura N7. Ciclos anidados de Crystal Clear

En lugar de esta interpretacin lineal, Cristal Clear enfatiza el proceso como un conjunto de ciclos anidados. En la mayora de los proyectos se perciben siete ciclos: (1) el proyecto, (2) el ciclo de entrega de una unidad, (3) la iteracin (ntese que CC requiere mltiples entregas por proyecto pero no muchas iteraciones por entrega), (4) la semana laboral, (5) el perodo de integracin, de 30 minutos a tres das, (6) el da de trabajo, (7) el episodio de desarrollo de una seccin de cdigo, de pocos minutos a pocas horas. Los mtodos Crystal no prescriben las prcticas de desarrollo, las herramientas o los productos que pueden usarse, pudiendo combinarse con otros mtodos como Scrum, XP y Microsoft Solutions Framework. En un comentario Cockburn confiesa que cuando imagin a Crystal Clear pensaba proporcionar un mtodo ligero; comparado con XP, sin embargo, Cristal Clear resulto muy pesado, sin embargo es ms fcil de aprender e implementar; a pesar de su jerga chocante XP es ms disciplinado, piensa Cockburn; pero si un equipo ligero puede tolerar sus rigores, lo mejor ser que se mude a XP.

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 del Consorcio era producir una metodologa de dominio pblico que fuera independiente de las herramientas y que pudiera ser utilizado en proyectos de tipo RAD (Rapid ApplicationDevelopment). El Consorcio, tomando las bestpractices que se conocan en la industria y la experiencia trada por sus fundadores, liber la primera versin de DSDM a principios de 1995. A partir de ese momento el mtodo fue bien acogido por la industria, que empez a utilizarlo y a capacitar a su personal en las prcticas y valores de DSDM. Debido a este xito, el Consorcio comision al Presidente del Comit Tcnico, Jennifer Stapleton, la creacin de un libro que explorara la realidad de implementar el mtodo. Dado el Ing. Software I Pgina 32

Universidad Jos Faustino Snchez Carrinenfoque hacia proyectos de caractersticas RAD esta metodologa encuadra perfectamente en el movimiento de metodologas giles. La del mtodo fue guiada por estos nueve principios: 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 esencial para la aceptacin de los entregables. 5. El desarrollo iterativo e incremental es necesario para converger hacia una 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 esencial. interesados es

DSDM define cinco fases en la construccin de un sistema ver Figura N8. Las mismas son: estudio de factibilidad, estudio del negocio, iteracin del modelo funcional, iteracin del diseo y construccin, implantacin. El estudio de factibilidad es una pequea fase que propone DSDM para determinar si la metodologa se ajusta al proyecto en cuestin. Durante el estudio del negocio se involucra al cliente de forma temprana, para tratar de entender la operatoria que el sistema deber automatizar. Este estudio sienta las bases para iniciar el desarrollo, definiendo las features de alto nivel que deber contener el software. Posteriormente, se inician las iteraciones durante las cuales: 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 sistema en produccin previa aceptacin del cliente. Desde mediados de la dcada de 1990 hay abundantes estudios de casos, sobre todo en Gran Bretaa, y la adecuacin de DSDM para desarrollo rpido est suficientemente probada. El equipo mnimo de DSDM es de dos personas y puede llegar a seis, pero puede haber varios equipos en un proyecto. El mnimo de dos personas involucra que un equipo consiste de un programador y un usuario. El mximo de seis es el valor que se encuentra en la prctica. DSDM se ha aplicado aproyectos grandes y pequeos. La precondicin para su uso en sistemas grandes es su particin en componentes que pueden ser desarrollados por equipos normales.

Ing. Software I

Pgina 33


Figura N8. Fases del Proceso de Desarrollo de DSDM

Se ha elaborado en particular la combinacin de DSDM con XP y se ha llamado a esta mixtura EnterpriseXP, trmino acuado por Mike Griffiths de QuadrusDevelopments . Se atribuye a Kent Beck haber afirmado que la comunidad de DSDM ha construido una imagen corporativa mejor que la del mundo XP y que sera conveniente aprender de esa experiencia. Tambin hay documentos conjuntos de DSDM y Rational, con participacin de Jennifer Stapleton, que demuestran la compatibilidad del modelo DSDM con RUP, a despecho de sus fuertes diferencias terminolgicas. Tambin hay casos de xito (particularmente el de Fujitsu EuropeanRepair Centre) en que se emplearon Visual Basic como lenguaje, SQL Server como base de datos y Windows como plataforma de desarrollo e implementacin.

FDD FEATURE DRIVEN DEVELOPMENT FeatureOrientedProgramming (FOP) es una tcnica de programacin guiada por rasgos o caractersticas (features) y centrada en el usuario, no en el programador; su objetivo es sintetizar un programa conforme a los rasgos requeridos. En un desarrollo en trminos de FOP, los objetos se organizan en mdulos o capas conforme a rasgos. FDD, en cambio, es un mtodo gil, iterativo y adaptativo. A diferencia de otras metodologas giles no cubre todo el ciclo de vida sino slo las fases de diseo y construccin y se considera adecuado para proyectos mayores y de misin crtica. FDD es, adems, marca registrada de una empresa, NebulonPty. Aunque hay coincidencias entre la programacin orientada por rasgos y el desarrollo guidado por rasgos, FDD no necesariamente implementa FOP. FDD no requiere un modelo especfico de proceso y se complementa con otras metodologas. Enfatiza cuestiones de calidad y define claramente entregas tangibles y Ing. Software I Pgina 34

Universidad Jos Faustino Snchez Carrinformas de evaluacin del progreso. Se lo report por primera vez en un libro de Peter Coad, Eric Lefebvre y Jeff De Luca: Java Modeling in Color with UML; luego fue desarrollado con amplitud en un proyecto mayor de desarrollo por DeLuca, Coad y Stephen Palmer. Su implementacin de referencia, anlogo al C3 de XP, fue el Singapore Project; DeLuca haba sido contratado para salvar un sistema muy complicado para el cual el contratista anterior haba producido, luego de dos aos, 3500 pginas de documentacin y ninguna lnea de cdigo. Naturalmente, el proyecto basado en FDD fue todo un xito, y permiti fundar el mtodo en un caso real de misin crtica.

Los principios de FDD son pocos y simples: Se requiere un sistema para construir sistemas si se pretende escalar a proyectos grandes. Un proceso simple y bien definido trabaja mejor. Los pasos de un proceso deben ser lgicos y su mrito inmediatamente obvio para cada miembro del equipo. Vanagloriarse del proceso puede impedir el trabajo real. Los buenos procesos van hasta el fondo del asunto, de modo que los miembros del equipo se puedan concentrar en los resultados. Los ciclos cortos, iterativos, orientados por rasgos (features) son mejores. Hay tres categoras de rol en FDD: roles claves, roles de soporte y roles adicionales. Los seis roles claves de un proyecto son: (1) administrador del royecto, quien tiene la ltima palabra en materia de visin, cronograma y asignacin del personal; (2) arquitecto jefe (puede dividirse en arquitecto de dominio y arquitecto tcnico); (3) manager de desarrollo, que puede combinarse con arquitecto jefe o manager de proyecto; (4) programador jefe, que participa en el anlisis del requerimiento y selecciona rasgos del conjunto a desarrollar en la siguiente iteracin; (5) propietarios de clases, que trabajan bajo la gua del programador jefe en diseo, codificacin, prueba y documentacin, repartidos por rasgos y (6) experto de dominio, que puede ser un cliente, patrocinador, analista de negocios o una mezcla de todo eso. Los cinco roles de soporte comprenden (1) administrador de entrega, que controla el progreso del proceso revisando los reportes del programador jefe y manteniendo reuniones breves con l; reporta al manager del proyecto; (2) abogado/guru de lenguaje, que conoce a la perfeccin el lenguaje y la tecnologa; (3) ingeniero de construccin, que se encarga del control de versiones de los builds y publica la documentacin; (4) herramientista (toolsmith), que construye herramientas ad hoc o mantiene bases de datos y sitios Web y (5) administrador del sistema, que controla el ambiente de trabajo o productiza el sistema cuando se lo entrega.

Ing. Software I

Pgina 35


Figura N9. Proceso FDD

Los tres roles adicionales son los de verificadores, encargados del despliegue y escritores tcnicos. Un miembro de un equipo puede tener otros roles a cargo, y n solo rol puede ser compartido por varias personas. Algunos agilistas sienten que FDD es demasiado jerrquico para ser un mtodo gil, porque demanda un programador jefe, quien dirige a los propietarios de clases, quienes dirigen equipos de rasgos. Otros crticos sienten que la ausencia de procedimientos detallados de prueba en FDD es llamativa e impropia. Los promotores del mtodo aducen que las empresas ya tienen implementadas sus herramientas de prueba, pero subsiste el problema de su adecuacin a FDD. Un rasgo llamativo de FDD es que no exige la presencia del cliente.

FDD se utiliz por primera vez en grandes aplicaciones bancarias a fines de la dcada de 1990. Los autores sugieren su uso para proyectos nuevos o actualizaciones de sistemas existentes, y recomiendan adoptarlo en forma gradual.

Ing. Software I

Pgina 36


CONCLUSIONES No existe una metodologa universal para hacer frente con xito a cualquier Proyecto de desarrollo de software. Las metodologas tradicionales histricamente han intentado abordar la mayor cantidad de situaciones del contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeos y de Requisitos cambiantes. Las metodologas giles ofrecen una solucin casi a medida para una gran cantidad de proyectos. Las metodologas giles se caracterizan por su sencillez, tanto en su aprendizaje como en su aplicacin; sin embargo, gozan tanto de ventajas como de inconvenientes. Las metodologas giles permiten a los pequeos grupos de desarrollo concentrarse en la tarea de construir software fomentando prcticas de fcil adopcin y en un entorno ordenado que permiten que los proyectos finalicen exitosamente. Se pueden distinguir dos rangos distintos de conjuntos de metodologas giles. Por un lado estn las metodologas ms declarativas y programaticas como XP, Scrum, LD, entre otras; y por otro lado se encuentran las metodologas finamente elaboradas como DSDM, Cristal, etc. XP es una de las metodologas giles ms extendidas y populares, adems es considerada como una metodologa posmoderna cuyas grandes capacidades se generan a travs de procesos emergentes. Scrum implementa en sus prcticas de desarrollo una estrategia de caos controlado, permitiendo maximizar la realimentacin sobre el desarrollo pudiendo corregir problemas y mitigar riesgos de forma temprana. A pesar de las continuas criticas que las metodologas giles sufren, son usadas por muchas grandes empresas y se han utilizado en grandes sistemas, lo que hace prever que estas metodologas han llegado para quedarse.

Ing. Software I

Pgina 37


BIBLIOGRAFA

http://www.spinec.org/wp-content/metodologiasagiles_01.pdf http://issi.dsic.upv.es/tallerma/actas.pdf

http://www.willydev.net/descargas/masyxp.pdfhttp://www.ati.es/novatica/2002/156/156-8.pdf

http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/heterodox.asp#12 http://www.enterprisexp.org http://www.dsdm.org

Ing. Software I

Pgina 38

trabajo metodologias agiles y rigidas lisstttooo

Documents