Trabajo Grado

UN ENFOQUE PARA EL DESARROLLO GIL DE APLICACIONES WEB, USANDO SCRUM, EXTREME PROGRAMMING Y HERRAMIENTAS OPENSOURCE SOBRE LA PLATAFORMA JAVA:
CASO DE ESTUDIO MEJORAMISO NEXT

Trabajo de Grado
RICARDO YEPES, RAL CHAVARRA
Facultad de Ingeniera, Universidad de Antioquia, estudiantes de pregrado {ryepes, rchavarra}@tredasolutions.com
Asesor: DIEGO ZAPATA

Universidad de Antioquia, magster en ingeniera [email protected]
RESUMEN: En este trabajo de grado se pretende presentar un enfoque para el desarrollo gil de aplicaciones web sobre
la plataforma Java, utilizando herramientas de software opensource como los frameworks Grails y ZK, la metodologa gil Scrum, las prcticas de eXtreme Programming (XP): Continuous Integration, Coding Standard, Collective Ownership, Simple design, Pair programming, Test-Driven Development y Refactoring. Dicho enfoque se validar a travs del caso de estudio Mejoramiso Next, la nueva versin que se desarrollar del software Mejoramiso, producto principal de la empresa Mejoramiso Ltda que ltimamente ha dejado de cerrar importantes negociaciones debido a que su software no cumple algunos de los requerimientos tcnicos exigidos por los clientes. Esta propuesta se presenta en el marco del desarrollo del trabajo de grado para optar al titulo de Ingenieros de Sistemas de la Universidad de Antioquia. PALABRAS CLAVE: desarrollo de aplicaciones web, java, metodologas giles, scrum, eXtreme Programming (XP), opensource, grails, zk, mejoramiso next, test-driven development (TDD), continuous integration, coding standard, collective ownership, simple design, pair programming, refactoring.
TABLA DE CONTENIDO
1. SITUACIN PROBLEMTICA.................................................................................................4 2. OBJETIVOS.................................................................................................................................6 2.1. General..................................................................................................................................6 2.2. Especficos............................................................................................................................6 3. ALCANCE....................................................................................................................................7 3.1. Restricciones exgenas.........................................................................................................7 3.2. Restricciones endgenas.......................................................................................................7 4. JUSTIFICACIN.........................................................................................................................8 5. ESTADO DEL ARTE.................................................................................................................10 6. RECURSOS................................................................................................................................13 7. ENFOQUE DE SOLUCIN......................................................................................................14 7.1. Solucin al problema y satisfaccin de la necesidad..........................................................14 7.2. Contexto tecnolgico..........................................................................................................16 7.3. Implementacin de la solucin............................................................................................18 7.3.1. Metodologa Scrum, conceptos...................................................................................19 7.3.1.1. Introduccin.........................................................................................................19 7.3.1.2. Principales actividades en Scrum .......................................................................19 7.3.1.3. Principales artefactos en Scrum ..........................................................................20 7.3.1.4. Principales roles en un equipo Scrum..................................................................21 7.3.2. Metodologa Scrum, kunagi........................................................................................22 7.3.2.1. Kunagi..................................................................................................................22 7.3.2.2. Metodologa Scrum en el proyecto Progreso de Macondo..................................23 7.3.3. El Test de Nokia para Scrum.......................................................................................40 7.3.3.1. Introduccin.........................................................................................................40 7.3.4. Prcticas XP................................................................................................................43 7.3.4.1. Introduccin.........................................................................................................43 7.3.4.2. Simple Design......................................................................................................43 7.3.4.3. Pair Programming................................................................................................44 7.3.4.4. Test-driven Development ....................................................................................44 7.3.4.5. Refactoring..........................................................................................................47 7.3.4.6. Continuos Integration..........................................................................................49 7.3.4.7. Collective Ownership..........................................................................................52 7.3.4.8. Coding Standard..................................................................................................52 7.3.5. Herramientas opensource sobre la plataforma Java....................................................53 7.3.5.1. Plataforma Java Enterprise Edition.....................................................................54 7.3.5.2. Detalle de los frameworks usados.......................................................................55 7.3.5.2.1. Grails............................................................................................................55 7.3.5.2.2. ZK................................................................................................................57 7.3.5.3. Arquitectura de los entornos de desarrollo y de servidor....................................58 7.3.5.3.1. Entorno de desarrollo...................................................................................58 7.3.5.3.2. Entorno servidor...........................................................................................61 2
7.4. Proceso de desarrollo y despliegue de Mejoramiso Next..................................................67 7.4.1. Independencia de Sistema operativo y del contenedor de servlets.............................68 7.4.2. Independencia del sistema gestor de base de datos ....................................................70 7.4.3. Independencia del navegador Web..............................................................................70 7.4.4. Cobertura y calidad del cdigo....................................................................................70 7.4.5. Internacionalizacin....................................................................................................71 7.4.6. Comparacin con la versin anterior del software......................................................71 8. ANEXOS....................................................................................................................................73 8.1. Entregables..........................................................................................................................73 8.2. Participacin en el III Saln de Inventores y de alta tecnologa.........................................73 8.3. Trabajo Futuro.....................................................................................................................74 8.4. Glosario...............................................................................................................................74 9. PRESUPUESTO Y FUENTES DE FINANCIACIN...............................................................78 REFERENCIAS..............................................................................................................................79
1. SITUACIN PROBLEMTICA
La empresa Colombiana Mejoramiso Ltda, conformada por Consultores expertos en la implementacin de normas ISO y estndares similares, tiene como producto central el software Mejoramiso, una herramienta especializada para la aplicacin de Mejoramiento Continuo*1 de procesos a los Sistemas Integrados de Gestin de Calidad (ISO 9001), Gestin Ambiental (ISO 14000), Gestin de Seguridad y Salud Ocupacional (ISO 18000), Gestin de la Seguridad de la Informacin (ISO 27000), entre otros. ltimamente Mejoramiso Ltda ha dejado de cerrar importantes negociaciones debido a que el Software Mejoramiso no cumple algunos de los requerimientos tcnicos exigidos por los clientes El software Mejoramiso es una aplicacin web, que se empez a escribir en el ao 2003 y que est desarrollada en su totalidad en la tecnologa ASP de Microsoft, obsoleta en la actualidad, tal como se explica en la seccin Enfoque de solucin. El uso de esta tecnologa hace que el software Mejoramiso est estrechamente ligado al cerrado modelo tecnolgico y de negocio de Microsoft, as mismo Mejoramiso Ltda est restringida en este modelo, debido a las limitadas posibilidades que puede ofrecer en el mercado: Slo IIS como Servidor de Aplicaciones* Slo Internet Explorer como navegador Web Slo SQL Server como gestor de bases de datos Estos son algunos de los requerimientos tcnicos exigidos por los clientes, que el software Mejoramiso no cumple: Independencia del navegador Web Independencia del Servidor de Aplicaciones Independencia del gestor de bases de datos
1. En el resto del documento, todas las palabras resaltadas en itlica y con un asterisco al final, tal como Mejoramiento Continuo*, contienen una definicin en la seccin del documento Glosario.
Software multiplataforma Mejoramiso Ltda ha encargado a Treda Solutions S.A.S resolver los problemas tcnicos que tiene actualmente con el software Mejoramiso. Treda Solutions S.A.S es una empresa Colombiana dedicada principalmente al desarrollo de aplicaciones Web sobre la plataforma Java. ltimamente ha desarrollado sus proyectos usando empricamente la metodologa Scrum, algunas prcticas de eXtreme Programming y herramientas de software opensource. Sin embargo, para afrontar este trabajo, Treda Solutions S.A.S deber resolver problemas que se le han presentado al abordar nuevos proyectos debido a que no logra transmitir eficientemente el know-how a nuevos equipos de desarrollo, lo que le genera algunos inconvenientes: Lentitud para instalar los entornos de desarrollo. Estimaciones alejadas de la realidad, lo que implica retrasos en los cronogramas de los proyectos. Demora para asimilar las practicas de eXtreme Programming usadas y sus herramientas de software asociadas.
2. OBJETIVOS
2.1. General
Plantear un enfoque para el desarrollo gil de aplicaciones web sobre la plataforma Java y validarlo a travs del caso de estudio Mejoramiso Next.
2.2. Especficos
Definir como aplicar Scrum* en el enfoque para el desarrollo gil de aplicaciones web Definir como aplicar algunas practicas eXtreme Programming (XP*) en el enfoque Integrar las herramientas para desarrollo de software a usar en el enfoque Desarrollar Mejoramiso Next siguiendo el enfoque definido Evaluar si se cumplieron los requisitos explcitos y los implcitos (como la mantenibilidad del cdigo) en el caso de estudio Determinar si el equipo de desarrollo ejecut Scrum correctamente en el caso de estudio Desplegar el software desarrollado en un entorno de produccin
3. ALCANCE
3.1. Restricciones exgenas
Entrega de los mdulos Mejoramiento Continuo y Auditoras para Mineros S.A, antes de finalizar Octubre de 2010. Sujeto a disponibilidad de dicha empresa. Se deben cumplir todos los requisitos requeridos por los clientes de Mejoramiso Ltda. descritos en la seccin del documento Requisitos de Mejoramiso Next.
3.2. Restricciones endgenas

El equipo de desarrollo2 slo cuenta con 3 personas. Cada integrante del equipo de desarrollo tiene 40 horas/semana disponibles para trabajar en el proyecto. Aunque se conoce cada herramienta a usar, no se tienen experiencias previas de usarlas en conjunto. Por poltica del equipo de desarrollo y teniendo en cuenta las caractersticas del proyecto, todas las herramientas de desarrollo a usar deben ser de cdigo abierto, no implicando. esto que Mejoramiso Next no pueda ser desplegado luego en entornos Windows, y usando gestores de base de datos como SQL Server u Oracle Server. El proyecto no contempla automatizar las pruebas de aceptacin (tambin llamadas funcionales) dentro del alcance del proyecto. No se cuenta con un espacio fijo de trabajo.
2. El equipo de desarrollo se conforma por los tres integrantes del trabajo de grado.
4. JUSTIFICACIN
Las empresas de software requieren construir productos de calidad, que satisfagan requerimientos de sus clientes, logrando a su vez minimizar recursos y capacidades invertidas, tales como tiempo, presupuesto, capital humano e infraestructura. El desarrollo de software de calidad es un proceso complejo, por lo que las mejores prcticas en ingeniera de software [Abran et al., 2004] sugieren hacer uso de metodologas, tcnicas, lenguajes y herramientas que complementen todo el proceso: desde la obtencin de requisitos hasta el despliegue de la aplicacin. Existen prcticas de ingeniera de software de muchos tipos, pero un conjunto de ellas, agrupadas bajo el nombre de prcticas giles de desarrollo de software estn, cada vez ms, siendo utilizadas a nivel mundial por empresas tan importantes como Google [Sutherland, 2006]3. Ahora bien, el uso de herramientas y lenguajes de programacin en la industria ha sufrido cambios importantes en aos recientes, donde cada vez se estn buscando mecanismos ms productivos a la hora de desarrollar software, por lo que se est empezando a mirar hacia tecnologas diferentes a las tradicionalmente enseadas incluso en universidades de alta calidad como la Universidad de Antioquia. Este hecho implica que no se estn graduando suficientes profesionales capacitados en estas nuevas tendencias de desarrollo de software, por lo que muchas empresas colombianas, que esperan que la innovacin provenga de los nuevos egresados y no de su propia inversin en innovacin tecnolgica, seguirn estando en desventaja competitiva frente a empresas en otros pases. El enfoque para desarrollo gil propuesto, as como su validacin por medio del caso de estudio, servirn como un precedente que ayude a soportar la tesis de que se puede desarrollar software de mejor calidad y de un mayor nivel de mantenibilidad bajo perspectivas diferentes a las tradicionales, optimizando recursos y capacidades. La mantenibilidad es un factor clave del que depende el tiempo de vida til de un software, por lo que se le presta importante atencin para evitar que en pocos aos Mejoramiso Next se encuentre en la situacin del software actual y as ser realmente una solucin a largo plazo para los clientes que actualmente usan Mejoramiso, tales
3. Google Tech Talks, 2006.
como TCC, Familia Sancela, la Contralora General de Antioquia, entre otros4. As mismo se espera alcanzar nuevos clientes a los que no se haba podido ofrecer una solucin por no cumplir los requisitos que exigan. Como aporte al sector de desarrollo de software en Colombia, se entrega un enfoque de desarrollo gil de aplicaciones web, compuesto por metodologas, prcticas y herramientas, que podran empezar a ser utilizadas en contextos similares evitando el trabajo de integrarlas, facilitando as la adopcin de estas nuevas tendencias en universidades y empresas del pas.
4. Puede consultarse la lista completa en: http://mejoramiso.com/index.php?
option=com_content&view=article&id=50&Itemid=75
5. ESTADO DEL ARTE

El estudio de las posibles soluciones al problema que se aborda en el caso de estudio Mejoramiso Next, se realiza teniendo en cuenta el estndar internacional ISO/IEC 14764, IEEE Std 147642006 "Software Engineering Software Life Cycle Processes Maintenance", el cual describe detalladamente la administracin del proceso de mantenimiento de software (Maintenance Process), uno de los 5 principales procesos en el ciclo de vida de un producto software, segn lo describe el estndar ISO/IEC 12207, "Information technology Software life cycle processes". El estndar ISO/IEC 14764 provee el framework, la terminologa precisa y los procesos para aplicar consistentemente la tecnologa (herramientas, tcnicas y mtodos) al mantenimiento de software; define varios tipos de mantenimiento y proporciona guas para: planear, ejecutar, controlar, revisar, evaluar y cerrar procesos de mantenimiento de software. Est escrito principalmente para proveedores de mantenimiento de software y adicionalmente, para responsables del desarrollo y el aseguramiento de la calidad de software. El principal propsito del proceso de mantenimiento es modificar un producto existente preservando su integridad. El proceso de mantenimiento soportan el producto software desde sus inicios, pasando por su migracin a nuevos entornos, hasta su retiro. Las actividades que abarcan el proceso de mantenimiento de software, tal como se ilustra en la figura 1, son: Desde el proceso de implementacin (1) debe planearse el proyecto de tal forma que el software a desarrollar sea mantenible. Una vez el software es desplegado en entornos de produccin, a menudo surgen reportes de problemas, debido a bugs5 y peticiones de modificacin para agregar funcionalidades que reflejen nuevos estados del negocio; en ambos casos, la solicitud de mantenimiento debe ser analizada (2). Una vez la solicitud de mantenimiento es aprobada, se pasa a
5. Defectos de software Figura 1: Proceso de mantenimiento de software
10
la implementacin de los cambios (3) y a la evaluacin de aceptacin (4) por parte de los usuarios del software. En ese ciclo cerrado se invierten la mayor parte de los recursos destinados al mantenimiento de un determinado software. En algunos casos, el software es migrado (5) a otros entornos, en respuesta a nuevos requerimientos del negocio o es retirado (6), cuando alcanza el final de su vida til. A partir de las diferentes actividades del proceso de mantenimiento de software, se analizan diferentes formas de implementar, modificar, migrar y retirar software: El artculoUsing the RUP to evolve a legacy system[Kruchten, 2003] describe un ciclo basado en RUP para evolucionar un sistema existente. El ciclo esta compuesto de cuatro fases: (i) Fase de inicio: Se producen documentos con la visin, las reglas de negocio y las especificaciones de la fase inicial de desarrollo, definiendo los artefactos que necesiten crearse de nuevo. En esta fase se iniciar tambin un proceso de ingeniera inversa para algunos artefactos involucrados con el fin de establecer su arquitectura y requerimientos, principalmente para elegir el tipo de evolucin a aplicar y estimar su costo. (ii) Fase de elaboracin: Se crea una base sobre la cual se definen los artefactos necesarios para evolucionar el sistema existente, incluyendo el acoplamiento de anteriores artefactos a los nuevos entornos de desarrollo. (iii) Fase de construccin: No es significativamente diferente con respecto de cualquier otro proyecto RUP. Se adicionan nuevos elementos como ingeniera inversa, rediseo y revisin de la documentacin. (iv) Fase de terminacin: Puede ser ms delicada de lo que sera para un proyecto RUP en el desarrollo de un nuevo software, ello depende de la estrategia de despliegue que se planee, la cual vara a su vez con el tipo de evolucin que se haga al sistema existente y con restricciones propias de ciertos negocios, as por ejemplo, puede darse un caso en el que el sistema a desplegar y el existente trabajen en paralelo mientras se hace un retiro gradual del segundo. EnIncubating Services in Legacy Systems for Architectural Migration [Zhang & Yang, 2004] se expone un algoritmo que aplica el clustering aglomerativo y jerrquico para reestructurar el cdigo fuente de sistemas existentes, creando componentes software que facilitan la construccin y encapsulacin de servicios web; dichos componentes software se agrupan con base en los nuevos requerimientos. Este enfoque mejora las posibilidades de mainteinance por medio de la ingeniera de software basada en componentes. 11
El artculoRefactoring as a Technique for the Reengineering of Legacy Systems[Hessellund, 2004] inicialmente explica los conceptos de la reeingenieria de software, su aplicacin sobre sistemas existente y el refactoring, y luego plantea como algunas tcnicas y herramientas de refactoring pueden ayudar en la reingeniera de software al aplicar mainteinance a sistemas existentes, cuya construccin se haya hecho siguiendo el paradigma orientado a objetos. Adicionalmente menciona el proyecto FAMOOS (Framework-based Approach for Mastering Object-Oriented Software Evolution), a partir del cual se construyen herramientas para analizar y detectar problemas de diseo con respecto a la flexibilidad de sistemas orientados a objetos existentes, para transformarlos eficientemente en arquitecturas basados en frameworks.
12
6. RECURSOS
Los recursos requeridos para llevar a termino el proyecto son6: 1. Un sistema de hardware que pueda ser destinado para efectos de servidor. Deber contar, como mnimo con 3Ghz de procesamiento, 2GB de memoria RAM y 50GB de disco duro disponible. Este sistema ser utilizado para instalar el contenedor de servlets*, el sistema gestor de bases de datos y el servidor de integracin continua. El sistema deber contar con una conexin a Internet de 1Mbps. 2. Espacio de trabajo dotado con 4 computadores, cada uno con al menos 2Ghz de procesador, 1Gb de memoria RAM, y 30 GB de espacio libre en disco. Tambin se requiere conexin a Internet para todos ellos de al menos 128Kbps. 3. Medios para imprimir.
6. Requisitos tcnicos estimados segn la experiencia del equipo de trabajo.
13
7. ENFOQUE DE SOLUCIN
7.1. Solucin al problema y satisfaccin de la necesidad
Para que Mejoramiso Ltda. pueda ofrecer una solucin que cumpla con los requerimientos tcnicos exigidos por sus clientes, el equipo de desarrollo de Treda Solutions S.A.S ha tomado la decisin de, en lugar de realizar modificaciones sobre la aplicacin actual, desarrollar una nueva aplicacin web, que se denominar Mejoramiso Next. A pesar de que el alcance del proyecto contempla nicamente el desarrollo de dos de los diez mdulos del software (Auditoras y Mejoramiento continuo), se proyecta que a largo plazo esta nueva versin del software llegue a cumplir con todas las funcionalidades del software Mejoramiso, dando paso a un proceso de retiro7 para este ltimo. Los siguientes factores se consideraron para tomar la decisin de desarrollar un nuevo software y no realizar cambios sobre el existente: El entorno de desarrollo de Mejoramiso es privativo y totalmente dependiente de Microsoft: el servidor IIS, el sistema operativo Windows en cualquiera de sus ediciones para servidor, y del IDE Visual Studio. Las desventajas no son slo evidentes desde el punto de vista econmico, sino tambin al contemplar la dependencia del proyecto a decisiones que pueda tomar una nica compaa. La tecnologa con la que fue desarrollada la versin anterior de Mejoramiso es ASP, cuyo propietario Microsoft, ha hecho esfuerzos por reemplazar a la nueva versin, ASP.NET, desde Noviembre de 2001 [Scott, 2001]. Baja mantenibilidad: Escasa documentacin del cdigo fuente, incluyendo modelos de diseo orientados a objetos UML y modelos de datos.
7. En el apartado del estado del arte se explica en que consiste cada uno de los procesos de mantenimiento de software, entre los que se encuentra el proceso de retiro.
14
El desarrollo no sigue ningn tipo de prctica relacionada a la calidad del cdigo ni ningn tipo de estndar de codificacin. No se tiene ningn tipo de pruebas automatizadas software* (nivel de cobertura de cdigo* del 0%), por lo que al realizar cualquier cambio en el cdigo fuente no se tiene certeza de no haber afectado otras partes del software. Intencin de Mejoramiso Ltda. de delegar todo lo correspondiente a asuntos tcnicos para centrarse slo en el aspecto comercial, por lo que el mantenimiento de la versin actual no es a largo plazo. Baja usabilidad: Germn Acevedo, gerente de Mejoramiso, ha manifestado que algunos usuarios se han quejado de la apariencia y de la interfaz grfica de Mejoramiso actual. Bsicamente, los requisitos tcnicos exigidos a Mejoramiso Ltda podran resumirse en ofrecer un software multiplataforma con toda la funcionalidad del software Mejoramiso. Sin embargo existe un requisito implcito: la mantenibilidad del cdigo, que permitir hacer cambios rpidamente y sin tantos riesgos al momento de desarrollar nuevas funcionalidades para cumplir requisitos futuros, lo que permitir prolongar la vida til de Mejoramiso Next. Para un mayor detalle en los requisitos remtase a la seccin del documento Requisitos de Mejoramiso Next. La hiptesis del proyecto es: Es posible aplicar los principios giles de desarrollo de software a travs de una metodologa (Scrum), unas prcticas (XP) y con soporte de un conjunto cohesionado de herramientas, para elaborar una nueva versin del software Mejoramiso, la cual cumplir con los requisitos tcnicos de los clientes actuales de Mejoramiso Ltda? Los principios giles se resumen, segn el manifiesto gil8, en: Individuos e interacciones sobre procesos y herramientas Software que funcione sobre documentacin exhaustiva Colaboracin con el cliente sobre negociacin de contratos Respuesta al cambio sobre seguimiento de un plan
8. http://agilemanifesto.org
15
7.2. Contexto tecnolgico

En el entorno empresarial actual, donde la informacin es el activo ms valorado, el software juega un papel protagnico. De ah la importancia que las empresas requieran software de calidad, con entregas a tiempo y sin incurrir en costos no estimados. Lamentablemente son muy pocos los proyectos de software que llegan a lograrlo [Charette, 2005], debido a la complejidad implcita en el desarrollo de una aplicacin empresarial, la cual requiere un estricto proceso de Ingeniera de Software, que segn el SWEBoK (Software Engineering Body of Knowledge) implica 5 aspectos: mtodos, metodologas, tcnicas, lenguajes y herramientas. Las empresas de software se esfuerzan mucho en los dos primeros aspectos, mtodos y metodologas, preocupndose cada vez ms por temas como RUP*, CMMI* o ITIL*, e incluso empiezan a mencionarse modelos en los que se integren procesos tradicionales con metodologas giles en Colombia [Arboleda, 2005]. En lo referente a tcnicas, el paradigma de programacin casi universal es OOP* y en cuanto a arquitecturas centradas en servicios, SOA* es la regla, pero an se estn dejando de lado tcnicas tan importantes como TDD*. Pero donde realmente se hace ms evidente el problema es en cuanto a lenguajes y herramientas. Si bien se ha avanzado mucho en cuanto la estandarizacin de modelado con UML, la industria del software pareciera no mirar ms all de lenguajes de programacin clsicos (Java y C#) y de herramientas como los frameworks* tradicionales (Hibernate, IceFaces o ASP.NET MVC). Sin embargo la realidad es que, hablando slo de la plataforma Java, existe un rico entorno tanto de lenguajes como de herramientas que pueden acelerar el proceso de desarrollo. Java y .NET son las dos plataformas ms usadas a nivel empresarial, no slo por su riqueza tcnica sino tambin porque cuentan con el respaldo de empresas tan reconocidas como Oracle y Microsoft respectivamente. Java tiene un enfoque ms abierto, por lo que es ms atractiva para que terceras partes hagan desarrollos sobre ella, adems cuenta con una edicin diseada para la creacin de aplicaciones web empresariales, llamada JEE (Java Enterprise Edition)9, razones por las cuales se ha elegido como la plataforma base para el desarrollo de Mejoramiso Next.
9. Para mayor informacin consulte la seccin del documento Plataforma Java Enterprise Edition
16
El termino Java engloba dos conceptos relacionados pero distintos: plataforma y lenguaje. La plataforma Java es un entorno capaz de ejecutar aplicaciones escritas en el lenguaje Java. Sin embargo, la plataforma Java ha demostrado ser capaz de ejecutar tambin programas escritos en lenguajes alternativos, que al da de hoy suman ms de trecientos10, de los cuales slo unos pocos han logrado sobresalir y estn siendo ampliamente utilizados hoy en da: JRuby (2001), Groovy (2003), Scala (2004) y Clojure (2007), todos con principios de diseo y objetivos diferentes, pero pudiendo convivir y competir con el lenguaje Java al ofrecer una forma de programar mucho ms concisa y gil. La principal ventaja de estos lenguajes es que combinan todo el prestigio y madurez de la plataforma Java, con la verdadera innovacin dejada a un lado hace tiempo por el lenguaje Java por aferrarse a la idea de no romper compatibilidad hacia atrs11 con cada nueva versin del lenguaje. Mediante el uso de estos lenguajes se sigue teniendo acceso al enorme ecosistema Java, conformado por libreras de muy alta calidad, muchas de ellas de cdigo abierto, que se han desarrollado durante mucho tiempo, empezando por la misma JDK liberada por Sun Microsystems y pasando por aportes de otras empresas como Apache, Google, RedHat o SpringSource. Del mismo modo, en cuanto al tema de herramientas, tambin ha habido en estos ltimos aos avances acelerados que han permitido mirar el desarrollo de software desde una nueva perspectiva. Hoy en da existen excelentes herramientas que facilitan la adopcin de buenas prcticas como control de versiones*, pruebas de software (testing)*, integracin continua* o calidad del cdigo*. An resolviendo el problema de los lenguajes y herramientas, las habilidades para desarrollar software de calidad van mucho ms all. Ya se mencion que Java ha sido elegida como la plataforma de desarrollo ms adecuada para este proyecto. Partiendo de que en el medio se pueden encontrar talentosos desarrolladores Java, qu otros elementos son necesarios para que las empresas desarrolladoras de software puedan elaborar eficientemente software empresarial de calidad? Con el presente proyecto se pretende mostrar un enfoque de desarrollo web para
10. Puede encontrarse una lista de ellos en: http://www.is-research.de/info/vmlanguages 11. No se est siendo compatible hacia atrs cuando los programas escritos para la versin anterior del lenguaje dejarn de funcionar en la nueva versin.
17
contestar esta pregunta.
7.3. Implementacin de la solucin

Existen varios factores importantes que caracterizan a este proyecto: 1. Aplicacin Web: La naturaleza de los requisitos para Mejoramiso Next hacen que la aplicacin deba ser de este tipo, lo cual trae consigo mltiples beneficios adicionales como la facilidad de despliegue y actualizacin. 2. Desarrollo gil: Es la opcin elegida para el proyecto debido principalmente a que el equipo de desarrollo es pequeo y cuenta con poco tiempo para realizar el proyecto, por lo que evita lidiar con el pesado andamiaje de procesos que establecen las metodologas tradicionales de desarrollo de software. 3. Herramientas opensource: Dan mayor libertad al desarrollador al no atarlo a las decisiones de una nica empresa y al permitirle explorar el cdigo fuente para entenderlo y modificarlo de ser necesario. Adems evitan costos de licencias y en muchos casos son herramientas de calidad superior a las privativas. 4. Java: Tal como se mencion en el contexto tecnolgico, Java es una plataforma con las caractersticas suficientes como para soportar el desarrollo de aplicaciones web empresariales, tal como lo es Mejoramiso Next. El equipo de desarrollo de Treda Solutions S.A.S crear un enfoque de desarrollo teniendo en cuenta las caractersticas anteriores, para facilitar la construccin del software Mejoramiso Next. Dicho enfoque consistir en usar la metodologa Scrum en combinacin con algunas de las prcticas de eXtreme Programming y haciendo uso de un conjunto de herramientas de software opensource relacionadas entre s, seleccionadas a partir de investigaciones y experiencias del equipo de desarrollo.
18
7.3.1.
7.3.1.1.
Metodologa Scrum, conceptos

Introduccin
Scrum est soportado en equipos de trabajo autorganizados, dado que que no hay un lder que decida cual persona har determinada tarea o como sern resueltos los problemas, esos asuntos sern decididos por el propio equipo. Los equipos de trabajo son soportados por dos individuos especficos: El ScrumMaster y el Product Owner. El ScrumMaster puede entenderse como un entrenador para el equipo, ayudando a sus miembros a practicar Scrum de la mejor forma posible. El Product Owner representa a la parte del negocio, a los clientes o usuarios finales del software y se encarga de guiar al equipo para que construya el producto correcto. Los proyectos Scrum progresan a travs de una serie de iteraciones denominadas sprints, de periodos fijos y que normalmente duran menos de un mes. Al inicio de cada Sprint, los miembros del equipo se renen para seleccionar un determinado numero de caractersticas a desarrollar durante el sprint y que han sido definidas previamente por el Product Owner en un documento denominado Product Backlog. Al final de cada sprint se lleva a cabo una reunin denominada sprint review, durante la cul los miembros del equipo demuestran las nuevas funcionalidades al Product Owner y a otros Stakeholders12, quienes proveen un valioso feedback que puede influenciar el prximo sprint.
7.3.1.2.
Principales actividades en Scrum
Los sprints son la principal actividad. Scrum es una metodologa iterativa e incremental en la que el proyecto es dividido en una serie de sprints consecutivos. Cada sprint tiene un tiempo fijo, usualmente entre una semana y un mes de duracin.
La primera actividad de cada sprint es una reunin denominada sprint planning meeting. Durante dicha reunin el Product Owner y el equipo hablan a cerca de los tems con mayor prioridad en el Product Backlog. Los miembros del equipo estiman con cuantos
12. Accionistas, Inversionistas, Usuarios y otros individuos vinculados de alguna forma con el proyecto
19
items pueden comprometerse y crean el Sprint Backlog, que es una lista de tareas a desarrollar durante el sprint. Al principio de cada da del sprint se lleva a cabo una corta reunin, usualmente de 15 minutos de duracin, denominada daily scrum meeting y a la que deben asistir todos los miembros del equipo incluidos el ScrumMaster y el Product Owner. Durante la reunin cada uno de los miembros del equipo explica lo que hizo el da anterior y lo que har el presente da, e identifica posibles impedimentos para progresar. Al final de cada sprint, el equipo de trabajo conduce una reunin denominada sprint review. Durante la reunin el equipo demuestra las funcionalidades agregadas al producto durante el sprint. El propsito de la reunin es obtener feedback por parte del Product Owner u otros usuarios y Stackeholders que hayan sido invitados. Otra actividad realizada al final de cada sprint es una reunin denominada sprint retrospective. El equipo completo participa en dicha reunin, incluyendo el ScrumMaster y el Product Owner. La reunin es una oportunidad para reflexionar sobre el sprint que est terminando e identificar oportunidades para mejorar en el siguiente sprint.
7.3.1.3.
Principales artefactos en Scrum
El principal artefacto de un proyecto Scrum es el producto. El equipo espera llevar el producto o sistema a estados potencialmente entregables al final de cada sprint.
El Product Backlog es una lista completa de funcionalidades que se deseen agregar al producto. Cada una de las funcionalidades es priorizada por el Product Owner de tal forma que el equipo siempre este trabajando en las funcionalidades de mayor valor para el negocio.
El primer da de cada Sprint y durante la reunin sprint planning meeting, los miembros del equipo crean el sprint backlog, el cual puede entenderse como una lista de tareas para el equipo durante el sprint. Mientras que el Product Backlog es una lista de caractersticas por construir, el Sprint Backlog es la lista de tareas que el equipo necesita realizar durante el sprint para entregar las funcionalidades prometidas. 20
Otros dos artefactos importantes dentro de Scrum son el Sprint Burndown Chart y el Release Burndown Chart. Los grficos Burndown muestran la cantidad de trabajo que falta por hacer para completar el sprint o release.
7.3.1.4.
Principales roles en un equipo Scrum
El ScrumMaster es el lder del equipo y su principal funcin es ayudar a sus miembros a practicar Scrum de la mejor forma posible. El ScrumMaster difiere de un Gerente de Proyectos en muchos aspectos clave, incluyendo que el ScrumMaster no dirige el da a da del equipo y no asigna tareas individuales. Un buen ScrumMaster aleja al equipo de cualquier tipo de distracciones, logrando que sus miembros se enfoquen maniaticamente durante el sprint en el objetivo que se hayan trazado.
El Product Owner trabaja para dirigir el equipo por el camino correcto, creando una completa visin del producto y transimitiendola al equipo a traces del Product Backlog. El Product owner es adems responsable de mantener el Product Backlog priorizado, a medida que adquiere ms conocimientos sobre el sistema, sus usuarios y el equipo.
El tercero y ultimo rol en un proyecto Scrum es el equipo. Si bien los individuos que lo conforman puedes tener varios ttulos de trabajo, dentro de Scrum esos ttulos sern insignificantes. Cada persona contribuye de la mejor forma posible para completar el trabajo de cada sprint. Eso no significa por ejemplo que el tester estar elaborando la arquitectura del sistema; cada individuo gastar la mayor parte de su tiempo trabajando en la disciplina en la que trabajaba antes de adoptar Scrum, pero en un equipo Scrum, sus integrantes dejarn sus disciplinas preferidas en cualquier momento y harn lo mejor para el equipo. Algunos de los conceptos antes mencionados se entienden con ms claridad en el siguiente diagrama ilustrado en la Figura 31, tomada de Mountain Goat Software13.
13. http://www.mountaingoatsoftware.com/system/asset/file/17/ScrumLargeLabelled.png
21
Figura 1: Ciclo de Scrum
7.3.2.
7.3.2.1.
Metodologa Scrum, kunagi

Kunagi
Es una aplicacin Web open source para la gestin de proyectos basados en Scrum. Kunagi no slo soporta los principios bsicos de Scrum (Product Backlog, Sprint Backlog, los roles de ScrumMaster, Product Owner y los dems miembros del equipo, y dems), tambin permite gestionar informacin adicional de los proyectos (requerimientos no funcionales, riesgos, archivos, issues y bugs), agrega otras caractersticas adicionales (Project dashboard, un tablero interactivo para el Sprint actual y las posibilidad de estimar las historias de usuario con planning poker) y alienta el trabajo colaborativo (comentarios para cada entidad, wikis y foros). Kunagi est protegido por los trminos de la licencia GNU Affero General Public License versin 3 y superiores. Para ms informacin del proyecto, ir a su sitio Web oficial14.
14. Kunagi - Agile project management based on Scrum, http://kunagi.org/
22
7.3.2.2.
Metodologa Scrum en el proyecto Progreso de Macondo
El enfoque para el desarrollo gil de aplicaciones Web, que se propone en este Trabajo de grado, se apoya en Kunagi para implementar la metodologa Scrum en el desarrollo de proyectos. Para ensear el uso de Kunagi, se definir un pequeo proyecto que acompae la explicacin: En la Universidad de Macondo, el profesor Aureliano Buenda desea que sus estudiantes le propongan ideas que generen progreso para el pueblo. El profesor tomar dichas ideas y las clasificar de acuerdo al grado de innovacin, en una escala numrica, donde los nmeros ms elevados implican ideas ms innovadoras. Jos Raquel Moncada, el Alcalde de Macondo, a prometido destinar el 50% de las regalas que obtiene de las Compaas bananeras, para implementar las 10 ideas ms innovadoras que seleccione el catedrtico Aureliano Buenda. Los estudiantes le sugieren al profesor el desarrollo de una aplicacin Web, desde la que ellos puedan ingresar sus ideas y ver el grado de innovacin asignado a cada una de ellas. Aureliano Buenda asiente y contrata a Treda Solutions, la primera empresa de desarrollo gil de aplicaciones Web del pueblo, para que lleve a cabo dicha hazaa. De acuerdo con Treda Solutions, Aureliando Buenda har parte del equipo de desarrollo y su perfil ser el de Product Owner. 1. Creaccin del proyecto Progreso de Macondo Inicialmente, Mauricio Babilonia <mbabilonia>, el ScrumMaster del equipo, ingresa a Kunagi. user/passwd: mbabilonia/[email protected]
Figura 2: mbabilonia el ScrumMaster accede a Kunagi
23
Crea el proyecto Progreso de Macondo, asignando el perfil a cada miembro del equipo: Aureliando Buenda <abuendia> como Product Owner user/passwd: abuendia/[email protected]
Figura 3: mbabilonia crea el proyecto Progreso de Macondo
Pietro Crespi <pcrespi> y Gerineldo Marquez <gmarquez> como desarrolladores. user/passwd: pcrespi/[email protected] user/passwd: gmarquez/[email protected]
2. Registro de historias de usuario en el Product Backlog Aureliano Buenda accede a Kunagi y abre el proyecto, Progreso de Macondo
Figura 4: abuendia, el Product Owner, abre el proyecto Progreso de Macondo
Luego va al Product Backlog e ingresa cada una de las historias de usuario o caractersticas deseadas para el producto, en su lenguaje, sin ceirse a tecnicismos:
Figura 5: abuendia accede al Product Backlog
24
Aureliado Buenda requiere registrar a sus estudiantes.
Figura 6: abuendia crea la historia de usuario Registrar estudiantes
Aureliano Buenda necesita que haya una funcionalidad desde las que sus estudiantes puedan registrar las ideas que tienen.
Figura 7: abuendia crea la historia de usuario Registrar ideas
25
Ahora, Aureliano Buenda necesita crear los diferentes grados de innovacin con los que calificar a cada idea.
Figura 8: abuendia crea la historia de usuario Registrar grados de innovacin
Finalmente, Aureliando Buenda requiere una funcionalidad que le permita calificar cada una de las ideas y saber en todo momento cules son las 10 ideas ms innovadoras.
Figura 9: abuendia crea la historia de usuario Calificar ideas
26
3. El Product Owner prioriza el Product Backlog Una vez Aureliano Buenda ha escrito las historias de usuario que desea que se implementen en la aplicacin Web, las prioriza en el Product Backlog, es decir, fija el orden en el que desea que sean desarrolladas por el equipo; para ello usa el drag and drop que provee Kunagi y las ordena a su amao. Las historias que estn en el tope, sern las que se estimarn primero en el prximo Sprint.
Figura 10: abuendia prioriza el Product Backlog
Como se puede ver en la figura, Aureliano Buenda desea que se desarrolle primero la historia de usuario Registrar grados de innovacin para ir adelantando su trabajo mientras el equipo desarrolla y libera las otras historias de usuario, que le permitirn registrar los estudiantes y sus ideas, para proceder a calificar. 4. Sprint Planning Meeting y las estimaciones con Planning Poker Una vez el Product Backlog est priorizado, Mauricio Babilonia, el ScrumMaster del proyecto, cita a los miembros del equipo, incluyendo al Product Owner, a la reunin Sprint Planning Meeting. El propsito de la reunin es estimar el tiempo que tomar el desarrollo de cada una de las historias que estn en el tope del Product Backlog, fijar el objetivo del Sprint, el nmero de das que durar el Sprint, el factor de dedicacin del equipo, determinar la fecha en la que se har el demo del Sprint y crear el Sprint Backlog con base en las historias estimadas y la velocidad estimada para el equipo en el Sprint. La velocidad del equipo de desarrollo se mide en puntos de historia, que pueden significar das, semanas, horas u otros periodos de tiempo de acuerdo con las preferencias del equipo y las caractersticas del proyecto. En el proyecto Progreso de Macondo, Pietro Crespi y Gerineldo Marquez, los dos desarrolladores del equipo tienen en 15 das, 50 horas disponibles cada uno y 27
cada punto de historia equivale a una hora, el equipo tiene entonces un total de 100 horas o puntos de historia. Pero en esa cantidad hay que tener en cuenta el factor de dedicacin de ambos desarrolladores, es decir, determinar cual ser el tiempo en el que realmente estarn dedicados desarrollando software y no haciendo otras actividades, como tomar caf, ir al bao, hacer una llamada, cerrar los ojos por un momento, entre otras cotidianidades de los desarrolladores. El factor de dedicacin puede expresarse como un porcentaje, determinado en 60% para el equipo que as, tiene un total de 60 horas o puntos de historia, esa es la velocidad estimada para el Sprint que durar 15 das. Con la velocidad estimada para el equipo, ahora se estiman, en puntos de historia, las historias de usuario que se incluirn en el Sprint Backlog. Para la estimacin de historias de usuario, se usa el mtodo Planning Poker, en el que cada uno de los desarrolladores tiene una baraja de cartas que representan ciertos valores en puntos de historia. El mtodo consiste en que, para cada una de las historias de usuario del Product Backlog, cada desarrollador hace una estimacin personal en puntos de historia del tiempo que considera que puede tardarse en realizarla seleccionando una carta de la baraja, cuando todos los desarrolladores han hecho esto, Kunagi hace visibles las estimaciones. Las estimaciones empiezan desde la historia de usuario con ms prioridad, que est en el tope del Product Backlog. El equipo solo estima hasta que haya alcanzado un total de historias que no sobrepasen los 60 puntos, correspondientes a la velocidad estimada para el Sprint.
28
Historia: Registrar grados de innovacin
Pietro Crespi estima 13 puntos
Figura 11: pcrespi estima 13 puntos para la historia de usuario Registrar grados de innovacin
Gerineldo Marquez estima 20 puntos
Figura 12: gmarquez estima 20 puntos para la historia de usuario Registrar grados de innovacin
29
Puntos estimados: 13
Figura 13: puntos estimados para la historia de usuario Registrar grados de innovacin
Historia: Registrar estudiantes
Figura 14: pcrespi estima 40 puntos para la historia de usuario Registrar estudiantes
30
Figura 15: gmarquez estima 40 puntos para la historia de usuario Registrar estudiantes
Puntos estimados: 40
Figura 16: puntos estimados para la historia de usuario Registrar estudiantes
31
Historia: Registrar ideas
Figura 17: pcrespi estima 8 puntos para la historia de usuario Registrar ideas
Figura 18: gmarquez estima 5 puntos para la historia de usuario Registrar ideas
32
Puntos estimados: 5
Figura 19: puntos estimados para la historia de usuario Registrar ideas
Al estimar la historia de usuario Registrar grados de innovacin, pcrespi considera que puede realizarse en 13 puntos de historia, pero gmarquez considera que son necesarios 20 puntos. Cuando se presentan situaciones como esta, cada uno expone sus razones y argumenta la estimacin. En caso de que hayan dudas con la especificacin de la historia de usuario, estas son resueltas por abuendia, el Product Owner. En este caso, la estimacin para la historia de usuario fue de 13 puntos de historia, ya que gmarquez cambi de parecer y acept los argumentos que le expuso pcrespi. En la segunda historia de usuario ambos estuvieron de acuerdo y en la tercera historia la situacin se resolvi de una forma similar al primer caso. El mtodo de estimacin Planning Poker presenta una serie de beneficios para el proyecto: Para poder proporcionar una estimacin, cada desarrollador necesita comprender de que se trata la historia de usuario, dado que todos los desarrolladores participan en las estimaciones, se asegura de alguna manera que cada uno comprende las historias que se desarrollarn en el Sprint, esto incrementa las posibilidades de que se ayuden durante el desarrollo y los obliga a entender bien cada historia con la ayuda del Product Owner. El hecho de que la estimacin sea personal y se conozcan las estimaciones de todos los
33
desarrolladores al mismo tiempo, ayuda a evitar de alguna forma que las estimaciones hechas por desarrolladores ms experimentados o por desarrolladores que por alguna razn creen entender mejor la historia de usuario que se est estimando, influyan en las estimaciones de los dems desarrolladores. Despus de que se han estimado las historias que se incluirn en el Sprint 1, Gerineldo Marquez las lleva al Sprint Backlog para empezar a desarrollarlas:
Figura 20: gmarquez lleva las historias de usuario estimadas del Product Backlog al Sprint Backlog
Ahora que las historias de usuario para el Sprint 1 se han llevado al Sprint Backlog, Aureliano Buenda acuerda con el equipo que el demo del Sprint, la reunin Sprint Review, se llevar a cabo el da 17; al mismo tiempo determina el objetivo del Sprint: "Este primer entregable del Software debe permitirme ingresar los grados de innovacin y todos los estudiantes" y finaliza configurando dichos parmetros del Sprint 1 en Kunagi.
Figura 21: abuendia configura los parmetros del Sprint 1
34
5. El Whiteboard y las Daily Scrum Meetings El Whiteboard es un tablero virtual que tiene Kunagi, en el que agrega todas las historias de usuario que se lleven al Sprint Backlog.
Figura 22: El Whiteboard sin programacin de tareas
Cuando el equipo se rene para realizar los Daily Scrum Meeting, los desarrolladores dividen cada una de las historias de usuario en tareas que harn para desarrollarlas.
35
En el Daily Scrum Meeting, Gerineldo Marquez se apropia de la historia de usuario Registrar grados de innovacin, crea la tarea Modelo y estima cuantas horas le tomar desarrollarla.
Figura 23: gmarquez crea la tarea Modelo
De igual forma, Pietro Crespi se apropia de la historia de usuario Registrar estudiantes, crea la tarea Vista y estima cuantas horas le tomar desarrollarla.
Figura 24: pcrespi crea la tarea Vista
36
Las tareas en el Whiteboard se clasifican en 3 columnas: Tareas disponibles (Free Tasks): Tareas que se han programado pero que no se han empezado a desarrollar Tareas solicitadas (Claimed Tasks): Tareas que ya se estn desarrollado Tareas completadas(Completed Tasks): Tareas que ya se han terminado de desarrollar
A medida que avanza el Sprint, ambos desarrolladores van reportando horas en sus respectivas tareas.
Figura 25: gmarquez reporta 3 horas para la tarea Modelo
37
Figura 26: pcrespi reporta 2 horas para la tarea Vista
El Whiteboard permite visualizar en todo momento las tareas que estn pendientes por hacer en cada historia de usuario, las horas que le faltan a determinadas tareas, entre otras variantes que le permiten ver al equipo el estado del Sprint y tomar decisiones, en las reuniones Daily Scrum Meeting, que ayuden a completarlo con xito. Gerineldo Marquez logra terminar las 3 tareas que haba planeado para la historia de usuario Registrar grados de innovacin. Una vez las tareas de una historia de usuario se terminan, Aureliano Buenda, el Product Owner, determina si acepta o no como terminada la historia, o si la reabre para que se termine.
Figura 27: abuendia determina si acepta, como terminada, la historia de usuario Registrar grados de innovacin
Despus de ver su funcionamiento, Aureliano Buendia decide aceptar la historia.
Figura 28: abuendia acepta como terminada, la historia de usuario Registrar grados de innovacin
38
6. El Dashboard y el Sprint Burndown El Dashboard es el tablero de mando del Sprint actual, un lugar desde el que el equipo puede, a travs del Sprint Burndown Chart, conocer en todo momento el estado real del Sprint.
Figura 29: Sprint Burndown Chart
En el grfico Sprint Burndown se ven los puntos de historia estimados por el equipo para el Sprint actual (eje vertical), y el nmero de das programados como duracin del Sprint (eje horizontal). La linea recta con pendiente negativa, indica un rendimiento aceptable para el cumplimiento del Sprint, empieza a decaer desde el inicio del Sprint indicando que el equipo debera, desde el primer instante, empezar a desarrollar software usando bien los puntos de historia estimados, el seguimiento de esa linea garantizara que el equipo desarrolle las historias de usuario con las que se comprometi, aunque tenga que invertir en ello hasta el ultimo instante del Sprint. La linea quebrada, es una medida del rendimiento real del equipo a lo largo del Scrum, al final muestra que el equipo no pudo cumplir 30 puntos de historia con los que se comprometi en el Sprint Planning Meeting. Adems del Sprint Burndown Chart, el Dashboard presenta un resumen con links, de otros importantes elementos del proyecto: Open Impediments, High Priority Risks, Latest Events y Teams work, para hacer referencia a los ltimos impedimentos expresados por el equipo, las ltimos riesgos de alta prioridad ingresados, los ltimos eventos a lo largo de Kunagi y las ultimas novedades de trabajo en el equipo, respectivamente.
39
7. Herramientas colaborativas de Kunagi Kunagi tiene adems otras funcionalidades colaborativas de gran utilidad en la gestin de proyectos software: Issues (feedback, bugs e ideas), Risks (con sus impactos y probabilidades de ocurrencia asociados), wiki, foros, chat, Calendar, File Repository y Courtroom (como una medida didctica y divertida para controlar reglas mnimas dentro del equipo, como la puntualidad a las reuniones, el cumplimiento a tiempo de los compromisos adquiridos, entre otras cotidianidades similares).
7.3.3.
7.3.3.1.
El Test de Nokia para Scrum

Introduccin
Nokia tiene cientos de equipos Scrum. En 2005 Bas Vodde, uno de los pioneros de la cultura gil y coach en Nokia, empez a desarrollar un test con el cul se pudiera evaluar rpidamente si un equipo estaba desarrollando software iterativamente de acuerdo con los principios giles. En el 2008, l creo un test de 8 preguntas tipo Yes/No questions, en el que incluy las practicas de Scrum. En 2008, Jeff Sutherland, uno de los co-creadores de Scrum extendi el test con un sistema de puntajes, calificado con un rating entre 0 y 10 puntos; y en 2009, agreg una pregunta para el equipo en el test. La ultima versin del test de Nokia, publicada el 25 de Marzo de 200915, por Jeff Sutherland. El documento fue escrito con la ayuda de lideres de equipos Scrum en Google, Yahoo, Microsoft, IBM, Oracle, Adobe, BellSouth, Palm, Disney Animation, entre otras compaas.
Aplicacin del test de Nokia a la implementacin del caso de estudio Mejoramiso Next En el sitio Web de Cedur, una compaa de consultores Sueca, expertos en agile coaching, administracin de proyectos de software, arquitectura de software, entre otros, hay una aplicacin que permite realizar el test de Nokia en lnea16. Haciendo uso de la aplicacin de Cedur, se evalu el equipo Scrum que desarroll el caso de
15. Nokia Test, "aka the ScrumButt test", http://jeffsutherland.com/nokiatest.pdf 16. The Nokia Test, extended with scoring by Jeff Sutherland; http://www.cedur.se/nokia_test2.html
40
estudio: Mejoramiso Next, siguiendo el enfoque para el desarrollo gil de aplicaciones Web propuesto. Ests son las respuestas a las 9 preguntas del test:
Pregunta 1. Describe your iterations
Respuesta or less
Comentario tienen una duracin de 3 semanas cada uno
Fixed iteration length 4 weeks Los sprints en el proyecto
2. Describe your testing
Features are tested as soon as they are completed (during iteration)
El equipo emplea la tcnica Test-driven development, as, para cada una de las caractersticas que se agregan al software, se desarrollan primero sus tests
3. Describe your requirements We have just enough, just in at the time an iteration starts time specifications
El Product Owner del proyecto mantiene las historias de usuario bien especificadas en el Product Backlog de Kunagi
4. What about your Product Owner?
We have a Product Owner with a clear Product Backlog estimated by team before Sprint Planning meeting
5. What about your Product Backlog? 6. How about your estimates?
We have a single Product Backlog The Product Backlog has estimates produced by planning poker by Team A travs de Kunagi se hacen las estimaciones con el mtodo Planning Poker en cada una de las reuniones Sprint Planning Meeting 41
7. How about your burndown charts?
The sprint burndown chart done
A travs de Kunagi el equipo siempre actualizado El equipo tiene muy bien definidos los roles de ScrumMaster, Product Owner y desarrolladores
only burns down when a task is mantiene el Burndown chart
8. Team disruption
We have both Project Leader and Scrum roles
9. Team
Team commits collectively to Sprint goal and backlog
El equipo desarrolla cada una de las historias de usuario colectivamente, dividindolas en tareas en las reuniones Daily Scrum Meeting
El anlisis automtico, hecho por la aplicacin de Cedur, para las respuestas dadas al test es:
Figura 30: Resultados del test de Nokia
A partir de la anlisis se puede ver que el equipo Scrum, tiene que mejorar an en aspectos importantes para aumentar su puntaje. 42
7.3.4.
7.3.4.1.
Prcticas XP
Introduccin
XP (eXtreme Programming) es una metodologa gil de desarrollo de software, de la cul se tomarn para el Enfoque las tcnicas: Continuous Integration, Coding Standard, Collective Ownership, Simple design, Pair programming, Test-Driven Development y Refactoring. Dichas tcnicas, en combinacin con los principios de la metodologa Scrum, define la forma como se desarroll el Software Mejoramiso Next.
7.3.4.2.
Simple Design
Los equipos XP desarrollan software con diseos simples. Los diseos en XP no son one-time thing (creados en un momento determinado), o up-front thing (creados por anticipado), son allthe-time thing (creados todo el tiempo). Hay fases de diseo al planear cada una de las iteraciones (Scrum Planning Meeting), adems, los equipos se renen en cortas sesiones, a veces en los Daily Scrum Meeting, para crear y revisar los diseos y hacer refactoring. La simplicidad es algo subjetivo difcil de medir. Algo simple para una persona, puede ser muy complejo para otra. Dentro de los proyectos, el equipo decide que es simple, unidos juzgan el cdigo subjetivamente tratando de garantizar 4 aspectos propuestos por eXtreme Programming: testability, browsability, understandability y explainabilty, referidos tambin como TUBE. Testability: Se escriben pruebas unitarias, de integracin y dems, para examinar automticamente posibles problemas. Browsability: Es fcil encontrar cualquier elemento del proyecto que se est buscando. Crear bien el nombre de todos los elementos del software, las dems practicas de Coding Standard, el uso de polimorfismo, la delegacin y la herencia, ayudan a crear software explorable. Understandability: Se verifica que cada trozo de cdigo escrito haga lo que se espera de l. Explainabilty: El cdigo escrito debe ser fcilmente interpretado por un desarrollador qu, 43
conociendo las tecnologas involucradas, sea ajeno al proyecto. Una vez el equipo verifica los 4 aspectos, hace commit del cdigo escrito.
7.3.4.3.
Pair Programming
El software desarrollado es construido por pares de desarrolladores, sentados juntos en el mismo computador. Esta prctica asegura que el cdigo escrito es revisado por al menos un desarrollador ms, lo que resulta en mejores diseos, mejor testing y mejor cdigo. Adems de las ventajas citadas, sirve tambin para difundir conocimiento entre los miembros del equipo. Dado que los pares se intercambian entre s con frecuencia, cualquiera puede recibir el conocimiento especializado que tienen los dems, lo que reduce riesgos para el xito del proyecto en cada de que uno de los desarrolladores abandone el equipo. Laurie Williams17, de la Universidad de Utah en Salt Lake City ha mostrado que 2 desarrolladores haciendo Pair Programming son 15% ms lentos que trabajando de forma independiente, pero producen 15% menos de bugs. Dado que la depuracin de cdigo existente es a menudo ms costosa que escribir el cdigo inicial, esa leve disminucin de la velocidad se hace justificable. En el enfoque de trabajo, los miembros del equipo hacen Pair Programming cada que se llega a partes del software cuyo grado de complejidad as lo requiere; tambin se hace Pair Programming cuando hay un nuevo integrante en el equipo, quin es rotado por los desarrolladores de los diferentes aspectos y tecnologas involucradas en el proyecto, con lo que adquiere rpidamente una visin global del sistema. Los desarrolladores trabajan slos en tareas cuya complejidad hara ineficiente e innecesario el par acompaante, de esta manera, el uso de Pair Programming vara con la complejidad de los proyectos.
7.3.4.4.
Test-driven Development
Los equipos eXtreme Programming son obsesionados con el feedback y en el desarrollo de software, buen feedback requiere buenas practicas de testing. Los equipos XP practican Testdriven Development en pequeos ciclos en los que agregan un test y luego escriben el cdigo fuente necesario para pasar dicho test. De esta manera los equipos producen cdigo fuente con
17. The costs and benefits of pair programming, http://portal.acm.org/citation.cfm?id=377531
44
cerca del 100% de cobertura. El siguiente esquema ayuda a entender el concepto: Todos los tests son ejecutados de forma conjunta. Cuando los desarrolladores liberan cdigo al repositorio, cada uno de los test deben pasar satisfactoriamente, lo que significa que los desarrolladores tendrn un feedback inmediato a cerca de cmo estn haciendo su trabajo. Todo software siempre debe probarse de algn modo para verificar que ste se comporte de acuerdo a lo esperado. Esta comprobacin puede realizarse de forma manual o automatizada, interesando la segunda en lo que respecta a TDD (Test Driven Figura 31: Flujo para aplicar TDD Development). Una frecuente controversia respecto a los tests automatizados es el trabajo que cuesta programarlos, en algunos casos incluso equivalente al necesario para escribir el cdigo de produccin (cdigo de produccin se refiere al que realmente conformar la aplicacin, diferente al cdigo de los tests). Pero si se piensa detenidamente, se encontrar que de igual modo los tests manuales demandan algo de tiempo, que as sea mnimo, si se cuentan la veces que es necesario hacerlos durante el tiempo de vida del proyecto, se encontrar que el tiempo que demandarn sera mayor en una proporcin muy superior. Lo que ocurre generalmente con los equipos de desarrollo que no usan tests automatizados es que al momento de introducir cualquier cambio en la aplicacin, dado que no pueden probarla por completo, manualmente comprueban la nueva funcionalidad que ingresaron y no se dan cuenta si existe algn efecto colateral sobre otras partes del software. Evidentemente este enfoque es mucho menos profesional y a largo plazo solo puede traer como resultado un software de baja calidad. Segn Sommerville18, los costos de mantenimiento del software pueden llegar a exceder a los de desarrollo en un factor de hasta 4. Al realizar tests automatizados se est contribuyendo a que el trabajo requerido durante esta etapa de mantenimiento sea mucho ms efectivo. Existen muchos tipos y clasificaciones de tests automatizados de software, sin embargo los usados en la implementacin del caso de estudio fueron:
18. Sommerville, Ian. Ingeniera del Software. Pearson Addison Wesley 7 ed, pgina 10.
45
Pruebas unitarias: Son las realizadas a un componente individual de software. Generalmente son dirigidas a probar un solo mtodo de una clase, buscando exactitud a la hora de identificar rpidamente cuales instrucciones estn fallando en un momento determinado. Uno de los problemas que surgen es lo difcil de probar un componente aislado, dado que generalmente puede depender de muchos otros (ya sean estos otros mtodos, bases de datos, servicios web, entre otros) para su funcionamiento. Esta situacin se resuelve usando una tcnica conocida como mocking, la cual consiste en crear componentes que simulan el comportamiento de otros (mocks). A cada mock, se le puede indicar exactamente como queremos que se comporte, de tal modo que se rompen las dependencias entre componentes y se logra hacer la prueba enfocada exactamente en lo que interesa probar y de este modo se est seguro de que el componente est correctamente probado, sin importar que se modifiquen aquellos otros de los que l depende. Esta caracterstica tambin implica que este tipo de tests pueden ser ejecutados con una gran velocidad. Pruebas de integracin: Son aquellas en las que interesa comprobar los componentes de un software como un todo. Aunque los test unitarios pueden dar la certeza de que cada componente por separado pueda estar funcionando correctamente, es muy probable que durante la interaccin real con sus dependencias hayan problemas que nicamente son detectados con los test de integracin. En este tipo de test, a diferencia de los unitarios, pueden tardar mucho tiempo en ejecutarse, dado que posiblemente sea necesario que requieran iniciar un servidor de bases de datos o consumir un servicio web por poner algunos ejemplos. Independientemente de los tipos de tests que se empleen, la forma tradicional de programarlos consiste en escribir el cdigo fuente de produccin y slo despus comprobar que este sea correcto. La tcnica de TDD consiste precisamente en lo contrario; primero escribir los tests y luego el cdigo fuente de produccin. Hay dos premisas que se deben seguir para cumplir a cabalidad con la tcnica: No se debe escribir ninguna lnea de cdigo fuente de produccin hasta que no haya un test que as lo requiera. Escribir nicamente el cdigo que sea necesario para que el test pase, ni una lnea ms.
46
De estas se deriva por ejemplo que en caso de detectar un bug en el software, no debe corregirse de inmediato sino que antes se debe programar un test que demuestre el fallo, y slo entonces corregirlo. Esto garantiza que nunca en una versin futura del software se cometer de nuevo el mismo error, lo que tambin es llamado una regresin de un bug. Seguir al pie de la letra las recomendaciones de TDD requiere no slo un equipo de desarrollo con mucha experiencia en esta tcnica sino tambin un esfuerzo que en algunos casos, segn las circunstancias del proyecto, pueden llegar a ser imprcticas dadas las restricciones de tiempo con las que generalmente cuentan los desarrollos de software. En el caso concreto de Mejoramiso Next, teniendo en cuenta que el equipo no llega a tener dos aos de experiencia con la tcnica y que adems los tiempos de entrega eran tan ajustados, en algunas ocasiones se opt por escribir cdigo de produccin aunque no tuviera los tests asociados, sopesando el riesgo que esto implica con la necesidad de la funcionalidad esperada a tiempo. En la mayor parte de los casos, sin embargo, el enfoque usado fue realizar primero los tests y posteriormente el cdigo de produccin.
7.3.4.5.
Refactoring
XP usa un proceso de mejoramiento continuo de los diseos denominado Refactoring, enfocado en remover la duplicacin del cdigo (una seal de diseos pobres), e incrementar la cohesin del cdigo, reduciendo as el acoplamiento. Altos niveles de cohesin y bajos niveles de acoplamiento se traducen en cdigo bien diseado. Refactoring est fuertemente soportado por el testing exhaustivo, para asegurar que ante la evolucin de los diseos todo funcione correctamente. El Refactoring es entonces una prctica que consiste en cambiar el cdigo fuente sin alterar su funcionalidad, con el propsito de hacerlo ms legible, mejorar su organizacin o en general con el propsito de mejorar su calidad. Es una prctica que en combinacin de TDD ofrece resultados muy importantes. En primer lugar, al realizar cdigo de produccin cuyo objetivo es nicamente pasar un test, es posible que inicialmente no quede un diseo ideal y que queden faltando muchos aspectos no funcionales por mejorar, que no podran ser medidos por los tests. Por otro lado, es muy alto el riesgo de hacer refactoring sin tener tests de soporte que informen rpidamente si el cambio realizado realmente afect otras partes del proyecto o no. Es por esto que ambas practicas se complementan muy bien. 47
El beneficio de aplicar refactoring durante el proceso de desarrollo, si bien no es inmediato, a largo plazo produce un cdigo con un nivel de mantenibilidad muy superior, permitiendo realizar cambios futuros de un modo ms rpido. Realizar diseos excelentes al primero intento es una habilidad que se desarrolla con el pasar de muchos aos de experiencia, sin embargo el enfoque de un diseo con mejoras incrementales que ofrece esta prctica es algo que puede empezar a aplicar cualquier desarrollador en cualquier momento. En el libro llamado Refactoring19, se explican una serie de bad smell code (cdigo mal oliente), cdigo que generalmente posee errores que deberan ser refactorizados. A continuacin se describen los ms significativos vividos durante el desarrollo del proyecto: Mtodos muy largos: Muchos de los mtodos de ms de veinte lneas se descompusieron en dos o tres mtodos, lo cual no slo permita hacer un testing ms especfico sino que adems facilitaba la reutilizacin. Cdigo duplicado: Si un mismo cdigo es usado en mltiples partes, lo preferible es extraer el comportamiento comn en un slo mtodo de tal forma que cuando sea necesario hacer un cambio slo se tengan que realizar modificaciones en un nico sitio. Mtodos con lista de parmetros muy larga: En vista de que a menudo los parmetros tienen relacin entre si, en muchos casos se opt por agruparlos en una clase y poder as pasar al mtodo un slo parmetro. Sentencias switch: Se encontr que muchas de las sentencias switch usadas era posible substituirlas por polimorfismo, evitando as la repeticin de cdigo relacionada con este tipo de sentencias.
19. Fowler, Martin. Refactoring: Improving the Design of Existing Code. Addison-Wesley Professional; 1 edition (July 8, 1999).
48
7.3.4.6.
Continuos Integration
Los equipos XP mantienen el sistema completamente integrado, Continuos Integration, en todo momento. Infrequent Integration, la integracin infrecuente del cdigo crea serios problemas en los proyectos de software: 1. Si bien la integracin es algo critico para lograr cdigo de calidad, muchos equipos de desarrollo no la practican y a menudo delegan esa importante tarea a personas que no estn familiarizados con el sistema completo. 2. El cdigo que no es integrado frecuentemente tiende a tener bugs. Problemas que no fueron detectados al hacer testing a las partes del sistema por separado, se hacen evidentes al hacer la integracin. 3. Poca efectividad en la integracin lleva a periodos en los que los desarrolladores no pueden estar trabajando en requerimientos que deben entregar al final de cada iteracin, ya que gastan la mayor parte de su tiempo identificando y corrigiendo bugs. Integrar un software de un tamao considerable, compuesto por mdulos desarrollados por diferentes personas, puede demandar un esfuerzo incalculable. Mientras ms tiempo pase entre integraciones, mayor ser este esfuerzo. Cuando minimizamos esa cantidad de tiempo al mnimo es cuando logramos la integracin continua. Un caso que se presenta a menudo en los proyectos de desarrollo de software, y que tambin se vivi durante el desarrollo de Mejoramiso Next, ser explicado a travs de un ejemplo, pero antes se describirn unos conceptos relacionados con el manejo del sistema de control de versiones usado en el proyecto, mercurial [para una descripcin ms detallada visitar mercurial.selenic.com]: Change set: Un conjunto de cambios hechos en un repositorio en un momento dado. Repositorio de cdigo: Espacio, ya sea en disco duro o accesible a travs de red en el que se almacenan todos los archivos del proyecto y que contiene los archivos de gestin de cambios requeridos por mercurial. Repositorio central: Repositorio de cdigo en el cual se unifican los change set realizados 49
por todos los desarrolladores. Repositorio local: Copia del repositorio central sobre el cual est trabajando un desarrollador en un momento dado. Check-in: Descargar todo el cdigo fuente de un repositorio de cdigo. Commit: Asentar un change set en el repositorio local. Pull: Traer los change set realizados en otro repositorio hacia el repositorio local. Push: Enviar los change set realizados en el repositorio local hacia otro repositorio.
Inicialmente un desarrollador hace un check-in del proyecto, y empieza a realizar cambios en l y los asienta por medio de uno o varios commits hasta que se termina de desarrollar la funcionalidad en la que estaba trabajando y se comprueba que no se ha daado otras partes del software (dado que todos los test automatizados estn pasando satisfactoriamente). En este momento el desarrollador realiza un pull sobre el repositorio central para mirar cuales cambios fueron hechos en el proyecto durante el tiempo que el estuvo desarrollando su funcionalidad, y se de cuenta que ahora sus tests no pasan por completo, lo que significa que hay incompatibilidades entre los cambios que l realizo y el proyecto actual. Pues ser responsabilidad del desarrollador la de modificar su cdigo teniendo en cuenta los cambios que realizaron y que pasen de nuevo todos los test sucesivamente hasta que pueda hacer un push que no de ningn resultado errneo al ejecutar la pruebas. Este conflicto puede resolverse rpidamente porque el programador tiene en la mente los cambios recientes y puede identificar rpidamente posibles causas del conflicto. Adems al ser intervalos tan pequeos entre integraciones, la probabilidad de que hayan conflictos es muy pequea. En comparacin con un proyecto en el que pueden pasar semanas e incluso meses antes de las integraciones, esta estrategia resulta ser altamente efectiva y por eso es que es una de las principales prcticas recomendadas por XP. Del ejemplo anterior puede inferirse que tener cdigo que se autovlida es necesario antes de hacer uso de la integracin continua. La forma seguida en el proyecto para contar siempre con tests automatizados es siguiendo TDD, por la efectividad que ha demostrado. El servidor de integracin continua facilita por una parte que se corran todos los tests automticamente con cada
50
nuevo push y adems est en la capacidad de generar un resultado ejecutable del proyecto completo de software. El beneficio principal de emplear la integracin continua consiste en disminuir el riesgo de no conocer exactamente cuanto tiempo tardar en integrarse todos los mdulos de un software antes de que se pueda desplegar la aplicacin. Esto se debe a que se sabe con exactitud cuales fueron las regiones de cdigo modificadas antes de que alguno de los test dejara de funcionar, dado que fue el ltimo cambio hecho. Por otro lado se logra evitar el problema que se sufri al principio del proyecto, que por diferencias en las configuraciones del servidor de produccin en comparacin con las maquinas de los desarrolladores, se descubran bugs en el entorno de produccin antes de desplegar el software, lo que retrasaba la entrega al cliente y restaba agilidad al proyecto en general. Martin Fowler20 recomienda una serie de prcticas que facilitan aplicar integracin continua de un modo efectivo. Una de ellas consiste en que cada desarrollador debe enviar sus cambios al repositorio central cada da de trabajo. En el caso de Mejoramiso Next, la frecuencia era en algunos casos incluso superior, tal como puede apreciarse en el video que ilustra los cambios realizados en el proyecto. Otra recomendacin es mantener el tiempo de creacin del build (resultado ejecutable del proyecto) lo ms rpido posible (idealmente por debajo de 10 minutos): Es claro que si cada vez que se hiciera un nuevo build se ejecutaran todos los tests y se generaran todos los reportes de calidad del cdigo, el proceso podra tardar mucho como para tener una retroalimentacin lo suficientemente rpida que muestre si el cambio realizado afect o no a otras partes de la aplicacin. En el proyecto se dividi el build en dos etapas, inicialmente slo se ejecutan los test unitarios que ofrecen un rpido feedback, para que el desarrollador tenga cierto nivel de confianza y acto seguido se dispara un segundo proceso de build que ejecuta todos los test de integracin seguidos del proceso de generacin de mtricas del cdigo.
20. http://martinfowler.com/articles/continuousIntegration.html
51
7.3.4.7.
Collective Ownership
En el proyecto cualquier miembro del equipo puede mejorar el cdigo en cualquier momento, lo que significa que todo el cdigo recibir la atencin de muchas personas, incrementando la calidad y reduciendo los defectos. Cuando el cdigo es responsabilidad de un nico desarrollador, los nuevos requerimientos son a menudo desarrollados de forma inadecuada. Dado que no siempre el propietario del cdigo esta disponible, nuevas caractersticas son agregadas al software de la forma en la que otros desarrolladores consideran que est bien, lo que se traduce en cdigo difcil de mantener, con muchas duplicaciones y baja cohesin.
7.3.4.8.
Coding Standard
El equipo sigue un estndar de codificacin comn, de tal forma que todo el cdigo del sistema luce como si estuviese escrito por un nico desarrollador, algo que aporta a mejorar el Collective ownership. Los estndares de cdigo mantienen el cdigo consistente para el equipo, facilitando con ello el Refactoring. Para mantener una codificacin comn, en el enfoque se usan las convenciones del lenguaje de programacin Java21, pero adaptadas por el equipo a las particularidades de los lenguajes Groovy y Zuml, usados en la implementacin del caso de estudio Mejoramiso Next.
21. http://www.oracle.com/technetwork/java/codeconventions-150003.pdf
52
7.3.5.
Herramientas opensource sobre la plataforma Java
Una vez se tienen claras tanto la metodologa como las prcticas a usar en el enfoque, es necesario soportarlas en un nivel ms concreto: las herramientas de programacin. Configurar cada entorno de trabajo para construir aplicaciones web de un modo gil demanda un esfuerzo considerable, as que se ha seleccionado un conjunto cohesionado de herramientas para integrarlas en maquinas virtuales, con el fin de facilitar su instalacin y proveer un entorno de productividad que permita desarrollar de una forma eficiente; dichos entornos podrn ser llevados de un computador a otro con facilidad de tal modo que cada nueva instalacin requiera menos de 5 minutos. Se crearn dos tipos de entornos, uno de desarrollo y otro para servidores. Para consultar el detalle de ambos entornos, dirjase a la seccin del documento Arquitectura de los entornos de desarrollo y de servidor. A continuacin se presentan las herramientas que dentro de la experiencia del equipo han resultado ser las ms efectivas en cuanto a desarrollo de software web bajo la plataforma Java: 1. Framework full-stack: Grails 2. Lenguaje de programacin de baja ceremonia: Groovy 3. Framework para la vista: ZK 4. Testing: 1. Unit: JUnit 2. Integration: JUnit 3. Cobertura: Cobertura 5. Control de versiones: Mercurial 6. Integracin continua: Hudson 7. Calidad del codigo: Codenarc, Gmetrics
Todas ellas comparten caractersticas que las hacen idneas para ser utilizadas durante la construccin de Mejoramiso Next, tales como: Ser software opensource. 53
Estar soportadas por comunidades activas de usuarios y desarrolladores. Poseer una riqueza tcnica que las hace sobresalir frente otras herramientas de su misma naturaleza.
7.3.5.1.
Plataforma Java Enterprise Edition
La plataforma Java presenta distintas ediciones, entre ellas JEE (Java Entreprise Edition) que es usada para la creacin de aplicaciones web. JEE es una especificacin que engloba distintos estndares, entre ellos dos de los ms conocidos son JPA (Java Persistence API) para acceso a datos y EJB (Enterprise Java Beans) para la lgica de negocio. La plataforma JEE consiste en una maquina virtual y un API* (Application Programming Interface). Las aplicaciones Java en general, pueden ser ejecutadas en cualquier sistema compatible con Java (se cuenta con una maquina virtual Java para casi todos los sistemas operativos), ofreciendo independencia de plataforma, versatilidad, estabilidad, facilidad de desarrollo y seguridad. La plataforma JEE se apoya en la plataforma JSE (Java Standard Edition) y provee un API para el lenguaje Java y un entorno de ejecucin para desarrollar y ejecutar aplicaciones, denominado JDK (Java Development Kit). La plataforma de desarrollo Java se caracteriza por permitir la creacin de aplicaciones empresariales, termino que agrupa caractersticas como ser a gran escala, multi-capa, escalables, confiables, seguras y que funcionan en redes [Oracle, 2010]. Un servidor de aplicaciones JEE es aquel que implementa la especificacin por completo, un ejemplo de ellos es Glassfish. Por otro lado estn los contenedores de servlets*, tal como Tomcat o Jetty, que slo implementan una parte de la especificacin, pero pueden ser complementados con frameworks como Spring (el cual provee una alternativa a EJB) para ofrecer funcionalidades similares a las de los servidores de aplicaciones. Esta es la razn por la que aplicaciones basadas en Spring, como las creadas en Grails, pueden ser desplegadas tanto en servidores de aplicaciones como en contenedores de servlets.
54
7.3.5.2.
7.3.5.2.1.
Detalle de los frameworks usados

Grails
Grails es un framework web full-stack22 para la plataforma Java que ofrece una alta productividad para el desarrollador gracias al empleo de un verstil lenguaje de programacin (Groovy), filosofas giles como CoC23 y DRY24, un selecto grupo de herramientas con probado xito en el entorno Java. Grails innova con lo mejor de los nuevos paradigmas emergentes de desarrollo web como el hecho de proveer soluciones prediseadas (scaffolding) y fcilmente adaptables (templating) [Smith & Ledbrook, 2009]. Al mismo tiempo Grails cuenta con una enorme cantidad de documentacin, desde una completa API en el sitio oficial25, hasta audiograbaciones (podcasts), libros, blogs y foros26. Grails posee una solida fundamentacin en cuanto a tecnologas subyacentes, soportado por algunas de las ms populares tecnologas opensource en sus respectivas categoras, tal como lo ilustra Figura 32 tomada del libro The Definitive Guide to Grails escrito por el creador de Grails [Rocher & Brown, 2009]: As, Grails hereda toda la robustez de
herramientas que ya han probado su efectividad, a la vez que simplifica su uso, permitiendo as que el programador invierta menos tiempo en archivos de configuracin y escribiendo cdigo fuente innecesario (boilerplate), una de las principales razones por las cuales el desarrollo
Figura 32: Infraestructura de Grails
aplicaciones web Java es tan tedioso.
Grails est compuesto por muchas partes. Hibernate es uno de los mapeadores objeto
22. Un framework full-stack es aquel que presta soporte completo desde el modelo de datos hasta la vista. 23. Convencin sobre configuracin (convention over configuration) significa que slo es necesario configurar aquello de carcter especial, todo lo dems se comporta implcitamente de una forma coherente. 24. No te repitas (Don't repeat Yourself) consiste en tratar de evitar al mximo tareas repetitivas e innecesarias. 25. http://www.grails.org 26. http://www.grails.org/Tutorials
55
relacionales (ORM27) ms utilizado sobre Java y a partir del cual se desarroll el estndar de persistencia JPA. Spring es un framework para Java ampliamente utilizado en lo que se refiere a soluciones para internacionalizacin (multiples idiomas), seguridad, invesin de control (IoC28) entre muchas otras ms. Groovy un lenguaje dinmico de programacin29 que puede ejecutarse en la JVM (Java Virtual Machine)*, que cuenta con una gran facilidad de aprendizaje para programadores Java por la similitud sintctica entre ambos lenguajes. Groovy ofrece grandes facilidades para construir lenguajes especficos de dominio (DSL30), una de las razones de la flexibilidad de Grails. Adicionalmente Grails incluye un framework para la creacin de pruebas automatizadas de software denominado JUnit, el cual facilita la practica TDD en la cual se deben hacer primero las pruebas antes de intentar escribir el cdigo de la aplicacin [Beck, 2002]. Grails tambin est compuesto por un framework llamado SiteMesh, el cual permite presentar contenido web a partir de plantillas (layout-rendering). Grails provee una abstraccin sobre este para facilitar el uso y lo combina con un nuevo lenguaje de etiquetas denominado GSP. Sin embargo, este aspecto no se usar en el enfoque de solucin dado que toda su funcionalidad es superada por el framework ZK, que es el usado para la creacin de la vista. Grails tambin cuenta con un sistema de plugins (componentes de software que pueden ser fcilmente agregados o removidos), que hace supremamente extensible al framework, ya que de una forma muy sencilla se le puede agregar funcionalidades adicionales. Finalmente, Grails permite desplegar fcilmente las aplicaciones en un entorno de desarrollo conformado por Tomcat como contenedor de servlets y HSQLDB como base de datos embebida que puede ejecutarse directamente desde memoria, lo que la hace muy rpida para desarrollar.
27. Un ORM (Object Relational Mapping) se encarga de traducir modelos de objetos en modelos relacionales, es decir que permite programar la persistencia en trminos orientados a objetos independientemente que la base de datos trabaje con tablas. 28. IoC (Inversion of Control) es una forma de conectar objetos, de tal modo que sus dependencias estn disponibles en tiempo de ejecucin, lo cual favorece la cohesin mientras que disminuye el acoplamiento. 29. Un lenguaje de programacin es dinmico si el tipo de dato de los objetos se determina durante la ejecucin del programa y no durante la compilacin. 30. Un lenguaje de especifico (Domain Specific Language) de domino es aquel que se disea para un contexto en particular, diferente a un lenguaje de propsito general.
56
7.3.5.2.2.
ZK
ZK es un framework AJAX (Asynchronous JavaScript And XML)* basado en componentes, dirigido por eventos y cuenta con el lenguaje de etiquetas ZUML (ZK User Interface Markup Language)* [Stuble & Schumacher, 2008]. ZUML permite definir componentes, y adems se basa, en XUL (XML User Interface Markup Language)*. Tambin permite que sus componentes sean desarrollados directamente en XHTML (Extensible HyperText Markup Language)*. ZUML permite embeber mltiples lenguajes de programacin31 para definir el comportamiento de los componentes. Tambin posee un gran cantidad de componentes que permiten una rpida construccin de interfaces de usuario. El ser ZK dirigido por eventos, le permite ofrecer una abstraccin sobre el paradigma peticinrespuesta de las aplicaciones web para lograr un comportamiento similar al de una aplicacin de escritorio ante la percepcin del usuario y el desarrollador. ZK, a diferencia de muchos otros frameworks AJAX, permite que el programador elabore toda la funcionalidad del lado cliente de la aplicacin32 sin escribir una sola linea de Javascript, pues el framework cuenta con un motor que traduce independiente del lenguaje de programacin usado al escribir el ZUML. ZK es un framework que cuenta con aliados estratgicos del prestigio de IBM y Redhat 33. Adems cuenta con clientes como DreamWorks, Ebay y Sony entre muchos otros34.
31. ZK es configurable para trabajar con cualquier lenguaje de programacin, por defecto soporta a Java, Python, Ruby, Javascript y Groovy. 32. Las aplicaciones web cuentan con un lado cliente que es la porcin de cdigo ejecutada ejecutada por el navegador web del usuario (generalmente es cdigo Javascript) y otra parte denominada servidor que es la que se ejecuta por ejemplo en el contenedor de servlets. 33. http://www.zkoss.org/partner/ 34. http://www.zkoss.org/whosusingzk/
57
7.3.5.3.
7.3.5.3.1.
Arquitectura de los entornos de desarrollo y de servidor

Entorno de desarrollo
Entorno de virtualizacin: Entre las ventajas de usar la virtualizacin se encuentra la independencia del hardware y del sistema operativo. La herramienta de virtualizacin elegida es VirtualBox, debido a las facilidad de uso que representa para el usuario final, a su extendido uso en el medio
Figura 33: Arquitectura del entorno de desarrollo
y al hecho de que cuenta con
una versin opensource. Por ejemplo en las salas de computo Telemtica y LIS, las usadas por estudiantes de Ingeniera de Sistemas de la Universidad de Antioquia, est ya instalado en la mayora de los equipos. Sistema operativo: Sobre el entorno de virtualizacin se realizar una instalacin de GNU/Linux, especficamente la distribucin Archlinux, primero por su carcter minimalista que permite instalar exclusivamente lo necesario sin paquetes preinstalados por defecto. Por otro lado, en cuanto a su cantidad de paquetes de software y nivel de actualizacin de estos, prcticamente no tiene rivales, lo que permite una rpida instalacin de los dems programas requeridos y garantizar que estos se actualicen constantemente. Maquina virtual java cliente (JVM client): Se utilizar la implementacin de Oracle llamada Hot-Spot, por su alto rendimiento y por ser la de uso ms extendido. Entre las dos posibilidades de mquina virtual: servidor o cliente, se usar la ltima por el hecho de iniciar ms rpidamente, lo que la hace ms productiva para el desarrollador. Est maquina virtual es la encargada de ofrecer las condiciones de ejecucin para los
58
lenguajes de programacin Java y Groovy, tales como el cargador de clases, el interprete de bytecode, recolector de basura o libreras de soporte de ejecucin. Kit de desarrollo Java (JDK): Se compone de un conjunto de herramientas indispensables para desarrollar en el lenguaje Java, tal como el compilador, el depurador o la interfaz de programacin (API). Lenguaje Java: Adems de que Grails est desarrollado principalmente en Java y depende de este para poder ejecutarse, Grails en si mismo tambin ofrece la posibilidad de programar clases complementarias en dicho lenguaje. Lenguaje Groovy: Este lenguaje juega un papel fundamental en el framework Grails; por ejemplo algunos archivos de configuracin y la definicin de clases de dominio se deben escribir en Groovy. Adicionalmente es el lenguaje que se utilizar para programar la lgica de la vista para el framework ZK. Grails: Es el framework de desarrollo utilizado para desarrollar Mejoramiso Next, que provee una abstraccin que facilita el uso de otros frameworks subyacentes como Hibernate, Spring o JUnit, gracias a una flexible capa de Groovy. Adicionalmente, permite desplegar fcilmente las aplicaciones en un entorno de desarrollo conformado por Tomcat como contenedor de servlets y HSQLDB como base de datos embebida que puede ejecutarse directamente desde memoria, lo que la hace muy rpida para desarrollar. Grails permite desplegar las aplicaciones en servidores compatibles con el estndar Java Enterprise Edition (JEE), pese a no utilizar EJB (Entreprise Java Beans) en favor de Spring. La instalacin de Grails adicionalmente contar con cuatro plugins35 fundamentales: Codenarc para realizar anlisis esttico de cdigo, Gmetrics para elaborar mtricas de cdigo, Cobertura para realizar pruebas de cobertura del cdigo y finalmente ZK como framework para la vista. Para ms informacin dirjase a la seccin del documento Detalle de los frameworks usados. Mercurial: Escrito en Python y C, no necesita de la mquina virtual Java para ejecutarse. Es un sistema de control de versiones de cdigo distribuido que permite llevar un
35. Un plugin es un complemento de software que puede ser agregado o retirado con facilidad.
59
seguimiento de cada uno de los cambios hechos en un software, de tal modo que sea posible deshacer un cambio (tan antiguo como este sea) muy fcilmente [Mackall, 2006]. Proyectos de software tan grandes como Python estn en proceso de transicin a l 36 y Google lo usa para alojar los proyectos de su servicio Google Code37. A nivel del proyecto se utilizar para administrar todos los archivos de programacin. Mercurial estar configurado para utilizar como repositorio de cdigo en linea* a BitBucket, el cual adems ofrece herramientas como un issue tracker38, un wiki39 y un analizador visual de diferencias entre fragmentos de cdigo. Codenarc: Es la herramienta para controlar la calidad del cdigo elegida para el proyecto. Almacena un conjunto de regals predefinidas que indican errores de programacin frecuentes que se pueden llegar a cometer al hacer uso de Groovy, el lenguaje usado para el desarrollo del proyecto. Codenarc es un analizador esttico de cdigo automatizable, que si bien no es tan efectivo como lo sera la revisin de una persona con experiencia, lo cierto es que con l se pueden analizar cientos de clases en segundos. Codenarc posee un plugin para Grails. Gmetrics: Es una herramienta similar a Codenarc, pero que se centra ms en mtricas del cdigo tales como complejidad de los mtodos y clases. Usndola en conjunto con Codenarc, ambas herramientas se complementa y permiten generar informes sobre el estado del cdigo de un modo ms detallado. Tambin posee un plugin para Grails. Cobertura: Cuando se escriben pruebas para comprobar la validez del cdigo que se est programando, uno de los indicadores usados en la industria del software es el anlisis de cobertura del proyecto, lo cual indica que porcentaje de ste tiene asociado tests automatizados. La herramienta usada es Cobertura, la cual se integra por medio de un plugin con Grails. La tcnica TDD permite aumentar en gran medida los ndices de cobertura, ya que se espera que antes de escribir el cdigo de produccin se tengan ya
36. http://www.python.org/dev/peps/pep-0385 37. http://code.google.com/p/support/wiki/MercurialFAQ 38. Un Issue tracker es un sistema que permite llevar un registro organizado de reportes de errores y sugerencias de mejora. 39. Un wiki es un sito web que permite ser fcil y rpidamente modificado por mltiples usuarios que colaboran para crear contenido.
60
programados los test asociados. Sin embargo lograr un nivel del 100% de cobertura es imprctico porque evidentemente hay regiones que requieren un test de mayor profundidad y otras que con unos tests ms superficiales puede ser suficiente.
7.3.5.3.2.
Entorno servidor
Entorno de virtualizacin: Igualmente se utilizar Virtualbox por las caractersticas descritas en el apartado de Entorno de desarrollo. Sistema operativo: Se
usar el sistema operativo Debian, una distribucin de GNU/Linux en la que, si bien sus paquetes no son
Figura 34: Arquitectura del entorno para servidores
tan
frecuentemente
actualizados como en Archlinux, es una distribucin reconocida por su estabilidad, caracterstica fundamental para cualquier servidor. Maquina virtual Java servidor: As como para el entorno de desarrollo, se utilizar la implementacin Hot-Spot de Oracle, pero est vez en forma servidor, que si bien requiere ms tiempo para iniciarse, posee un mejor desempeo en la compilacin justo a tiempo (JIT compiler), lo que redunda en un mayor rendimiento de las aplicaciones. Tomcat: Es un contenedor de servlets desarrollado por la fundacin Apache y que ha probado ser una excelente combinacin con el framework Spring [Laddad & Hanik, 2008], uno de los pilares de Grails. PostgreSQL: Es un sistemas gestor de bases de datos con caractersticas altamente avanzadas, que adems se destaca por su alta robustez y tolerancia a fallos 40. Actualmente representa toda una tendencia en cuanto a alternativas opensource de almacenamiento de datos para empresas [Yuhanna, 2010].
40. PostgreSQL Global Development Group. Advantages. http://www.postgresql.org/about/advantages
61
Hudson: Servidor de integracin continua muy popular en entornos Java, ganador en los premios 2008 Duke's Choice en la categoria Developer Solutions41. Su funcin ser descargar el cdigo fuente del proyecto, desplegar la aplicacin sobre Tomcat, ejecutar todas las pruebas contra el software (unitarias, de integracin y de cobertura) y finalmente generar informes, incluyendo los relacionados a la calidad del cdigo. Para ello se utilizarn los plugins de Mercurial y Grails (lo cual permite ejecutar tambin los plugins de este ltimo: Codenarc, Gmetrics y Cobertura). Es un servidor de integracin continua que se destaca por su versatilidad, en el sentido de que ofrece una gran cantidad de plugins que permiten extenderlo en muchas direcciones para abarcar distintas necesidades. Tambin permite crear el build del proyecto de modo automatizado, es decir, crear el archivo war y desplegarlo en un contenedor de servlets y adems, tiene la capacidad de ejecutar todos los tests automatizados contra el proyecto para determinar el estado del mismo. Al ser este proceso automatizado, puede hacerse tan a menudo como se requiera. Par el enfoque propuesto, hudson hace este proceso cada vez que un usuario hace un cambio en el cdigo fuente del proyecto y lo sube al repositorio (push). De este modo se puede determinar de manera inmediata si los cambios realizados por un desarrollador entraron en conflicto con los hechos por los dems, de tal modo que sea una prioridad tener el proyecto pasando todos los tests antes de poder decir que se hizo un push satisfactorio. Se ha configurado para que en cada ejecucin, lance los plugins de Grails Cobertura, Codenarc y Gmetrics, para que cada vez que se realice el proceso de build, se incluyan todos los reportes generados por stos y as, se pueda identificar de manera inmediata cuales zonas del proyecto se estn descuidando en cuanto a testing y en cuanto a calidad del cdigo.
A continuacin se incluye una muestra del Hudson y de los reportes generados mediante los plugins antes descritos en el proyecto Progreso de Macondo descrito en la seccin Metodologa Scrum en el proyecto Progreso de Macondo, e implementado en las mquinas virtuales.
41. Premiacin, a los proyectos ms innovadores sobre la plataforma Java, que se otorgan durante uno de los principales eventos anuales de tecnologa Java llamado JavaOne. http://www.java.com/en/dukeschoice/08winners.jsp
62
Figura 35: Ejecutando los tests desde Hudson
Figura 37: Contraste entre cdigo con pruebas (verde) y cdigo sin pruebas (rojo)
Figura 36: Anlisis de cobertura mediante Hudson
63
Figura 38: Contraste entre cdigo con pruebas (verde) y cdigo sin pruebas (rojo)
Figura 39: Modo de configuracin de Hudson para generar builds automticos al detectar cambios en el cdigo fuente
Figura 40: Reporte de Codenarc
64
Figura 41: Reporte de Gmetrics
Como se puede apreciar en la dos figuras anteriores, el formato de Codenarc y Gmetrics se presenta sin mucho cuidado esttico. Existe un software llamado Sonar que se estuvo probando, el cual soluciona este inconveniente, pero la integracin con Groovy es muy limitada (apenas se cuenta con la versin 0.2 del plugin para Sonar) en el momento y no se obtuvieron resultados satisfactorios. Sin embargo se presentan dos capturas de pantalla tomadas al proyecto para ilustrar la apariencia de Sonar:
65
Figura 42: Sonar Dashboard
Figura 43: Sonar Components
66
7.4. Proceso de desarrollo y despliegue de Mejoramiso
Next
El proceso seguido, desde que uno de los desarrolladores escribe una linea de cdigo fuente hasta que se despliega una nueva revisin que incluye el cambio realizado, es generalmente corto en comparacin a la forma tradicional de desarrollo de software. En primera instancia, cada desarrollador usa la tcnica TDD, escribiendo siempre los test antes del cdigo que habr de pasarlos, con lo que se cuenta con una base de testing generalmente suficiente para probar el impacto de cada cambio en todo el software. Una vez el desarrollador comprueba que despus de adicionar su cdigo, todas las pruebas siguen pasando en su entorno de prueba, procede a enviar el cdigo al repositorio de cdigo. Segn se haya configurado el servidor de integracin continua, variar el momento en que este inicie el siguiente proceso42: 1. Tomar el cdigo fuente del repositorio. 2. Ejecutar todas las pruebas y verificar que todas ellas sean superadas en el entorno de produccin. 3. Desplegar la aplicacin en el contenedor de servlets, el cual est configurado para utilizar la base de datos que est corriendo idealmente en otro servidor, pero que en un caso determinado podra ser el mismo. La Figura 44 ilustra como encajan los dos entornos virtualizados en el proceso de desarrollo y despliegue. Se puede observar como hay mltiples instancias del entorno de desarrollo, cada una de ellas pudiendo enviar cdigo al repositorio. Del entorno para servidores, existen dos instancias, una ejecutando Tomcat y Hudson y otra ejecutando PostgresSQL.
Figura 44: Interconexin de los entornos(desarrollo y servidores) con el repositorio de cdigo
Para el despliegue del software Mejoramiso Next, desarrollado en el caso de estudio, se siguen los
42. La costumbre del equipo de desarrollo de Treda Solutions S.A.S es hacerlo mnimo una vez al da, idealmente cada vez que se enva un nuevo cambio.
67
siguientes pasos:
1. A travs de Grails se genera un archivo .WAR (Web-Archive) que agrupa los binarios,
archivos de configuracin y libreras necesarias para que un contenedor de servlets pueda publicar la aplicacin.
2. Se crea la base de datos y la credencial de autenticacin al servidor de bases de datos, de

acuerdo la especificacin de dichos valores en el .WAR generado.
3. Se lleva el .WAR generado al contenedor de servlets y desde all se despliega el software.
7.4.1.
Independencia de Sistema operativo y del contenedor de servlets
Teniendo en cuenta que el despliegue del .WAR depende en primera instancia del contenedor de servlets, se dice que Mejoramiso Next es una aplicacin Web multiplataforma, o independiente del Sistema operativo, s los contenedores de servlets lo son. Los contenedores de servlets, a su vez, dependen de la versin de la JVM y de su disponibilidad en los Sistemas operativos. En la siguiente tabla se muestra esa disponibilidad para los contenedores de servlets JBoss, Apache Tomcat y Jetty, en sus ultimas versiones estables. Contenedor de servlets JBoss 1 Sistema operativo Red Hat Enterprise Linux 5 JVM Sun JDK 1.6 Update 18 OpenJDK 1.6.0-b09 IBM JDK 1.6.0 SR6 Sun JDK 1.6 Update 18 IBM JDK 1.6.0 SR6 Sun JDK 1.6 Update 18 Sun JDK 1.6 Update 18 Sun JDK 1.6 Update 18 Sun JDK 1.6 Update 18
JBoss 1 JBoss 1 JBoss 1 JBoss 1 JBoss 1 Jetty 7 y Apache Tomcat 6.0.29
Red Hat Enterprise Linux 4 Solaris 10 Solaris 9 Windows Server 2008 R2 Windows Server 2003 SP2
Solaris SPARC, Solaris x86, Sun JDK 1.5.0_XX Windows Server 2008 Standard, Windows Server 2008 Enterprise, Windows Server 2008 Datacenter, 68
Windows Web Server 2008, Windows 2000 Professional, Windows 2000 Server, Oracle Enterprise Linux 5.5, Red Hat Enterprise Linux 5.5, SUSE 10, entre otros.
Tabla 1: Entornos de despligue
Los sistemas operativos para Jetty 7 y Apache Tomcat 6.0.29, versiones estables de ambos contendores de servlets, son los mismos teniendo en cuenta que ambos dependen de la JVM 1.5 segn sus sitios Web oficiales43 44, cuyo soporte a Sistemas operativos se especifica en el sitio oficial de Oracle45. Para el caso de JBoss 1.0, su sitio Web oficial46 despliega las configuraciones certificadas y completamente soportadas, fully supported configurations. Dado que un servidor de aplicaciones es a su vez un contenedor de servlets, le aplica lo antes descrito. Para el software Mejoramiso Next, desarrollado en el caso de estudio, se ejecutaron las pruebas unitarias y de integracin creadas a lo largo del desarrollo, en las siguientes configuraciones de despliegue. Sistema Operativo Debian Lenny JVM JVM 1.6.0_22 Contenedor de servlets Servidor de bases de datos
Apache Tomcat 6.0.26 MySQL Server Jetty-7 SQL Server 2008
Windows Server JVM 1.5.0_18 Standard Edition 2008
Tabla 2: Configuraciones de despliegue para testing
Como era de esperarse, dado que ambas configuraciones estn comprendidas en la Tabla 2, las pruebas se ejecutaron satisfactoriamente y despliegue se hizo sin contratiempos.
43. What are the Jetty dependencies?; http://docs.codehaus.org/display/JETTY/What+are+the+Jetty+dependencies 44. Apache Tomcat Version 6.0.29; Release Notes; http://tomcat.apache.org/tomcat-6.0-doc/RELEASE-NOTES.txt 45. Java 2 Platform 5.0 and Java for Business 5.0; http://www.oracle.com/technetwork/java/javase/systemconfigurations-139801.html 46. JBoss Enterprise Web Server Supported Configurations; http://www.jboss.com/products/platforms/webserver/supportedconfigurations/
69
7.4.2.
Independencia del sistema gestor de base de datos
El .WAR generado por Grails, tiene el soporte de Hibernate para el mapeo objeto-relacional del Modelo de Mejoramiso Next. De acuerdo con el diseo de Hibernate, el esquema de la base de datos del software debera poderse desplegar sobre cualquier motor de bases de datos que tenga un driver JDBC, sin embargo, algunos de ellos ya han sido probados por la comunidad de usuarios de Hibernate, como se lista en su sitio Web oficial47. Algunos son: Oracle (8i, 9i, 10g), DB2 (7.1, 7.2, 8.1, 9.1), Microsoft SQL Server 2000, Sybase 12.5, MySQL (3.23, 4.0, 4.1, 5.0), PostgreSQL (7.1.2, 7.2, 7.3, 7.4, 8.0, 8.1) y SAP DB 7.3.
7.4.3.
Independencia del navegador Web
Teniendo en cuenta que la tecnologa RIA para la interfaz del software es Zk y asumiendo que el usuario tiene JavaScript activado en el navegador Web, Mejoramiso Next es soportado para los navegadores Web: Internet Explorer 6/7/8, Firefox 2+, Google Chrome 2+, Safari 2+, Mozilla 1+, Opera 9+ y Camino 1+. Tal y como se manifiesta en el sitio Web oficial48 del framework. La compatibilidad del software desarrollado en el caso de estudio, con los navegadores Web mencionados, puede comprobarse en http://www.mejoramisonext.com.
7.4.4.
Cobertura y calidad del cdigo
Los acuerdos con la empresa Mejoramiso Ltda. impidieron la posibilidad de mostrar parcialmente el cdigo fuente de la aplicacin con el fin de ensear los reportes de anlisis de cobertura, los cuales se estabilizaron al rededor del 65%, y los anlisis estticos de cdigo, de los cuales se corrigi la mayora de problemas indicados por Codenarc. Sin embargo, se logr obtener la posibilidad de ensear una representacin grfica del proyecto por medio de un video. En el sitio http://academic.mejoramisonext.com/ puede encontrase el video evolucionMejoramisoNext.avi en el cual muestra la evolucin del proyecto generada automticamente a partir de los cambios hechos mediante mercurial en el proyecto. En dicho vdeo, se puede observar claramente una ramificacin completa de testing que era constantemente actualizada, lo cual es una muestra de los tests usados en el proyecto.
47. Supported Databases - JBoss Community; http://community.jboss.org/wiki/SupportedDatabases 48. ZK faq; What browsers are supported?; http://www.zkoss.org/faq/#Browsers
70
7.4.5.
Internacionalizacin
Dado que Zk tiene soporte para i18 49, Mejoramiso Next puede ser traducido fcilmente a varios lenguajes, as mismo, su terminologa puede ser fcilmente modificada para adecuarse mejor a determinada jerga especializada que puedan manejar ciertas Organizaciones. El software desarrollado en el caso de estudio tiene su interfaz en espaol e ingls, como puede comprobarse en http://www.mejoramisonext.com
7.4.6.
Comparacin con la versin anterior del software
La versin anterior de Mejoramiso se encuentra disponible en: http://mejoramiso.com/index.php? option=com_content&view=article&id=80&Itemid=89 , mientras que Mejoramiso Next en: http://mejoramisonext.com Dadas las variables a usar en la mtrica: Ht = Nmero de historias de usuario50 totales definidas en los requerimientos Hn = Nmero de historias de usuario cumplidas por el software nuevo Ca = Caractersticas tcnicas del software anterior Cn = Caractersticas tcnicas del software nuevo
Las historias de usuario descritas en los requerimientos son 32 en total. Las que an no se han desarrollado son 3: Gestin del conocimiento Contacte Soporte Control de tiempos y atrasos de acciones
Es as como nuestras variables relacionadas al nmero de historias toman los siguientes valores: Ht = 32 y Hn = 29. Sobre las caractersticas tcnicas, no se encontr ninguna en el software anterior51 que superara a
49. Zk Small Talks; I18N Implementation in ZK; Minjie Zha, Nanjing University, China; http://www.zkoss.org/smalltalks/i18n/i18n.dsp 50. Una historia de usuario, hablando en trminos de Scrum, se refiere a un requerimiento de software expresado en lenguaje de usuario, es decir sin usar trminos tcnicos. 51. http://mejoramiso.com/index.php?option=com_content&view=article&id=83&Itemid=88 para mayor informacin
71
Mejoramiso Next: Caractersticas tcnicas del software anterior: Aplicacin Web
Caractersticas tcnicas del software nuevo: Aplicacin Web Soporta configuracin para ms de un idioma Soporta ms de un navegador web Soporta ms de un tipo de sistema gestor de bases de datos Puede ser desplegada en ms de un sistema operativo Soporta ms de un servidor de aplicaciones/contenedor de servlets Usabilidad mejorada por medio de AJAX Cdigo fuente documentado y con estndares de codificacin No requiere JVM en el cliente para mostrar los grficos No requiere que el cliente tenga ventanas emergentes activadas en el navegador No impone restricciones en cuanto a servidor SMTP
Por lo tanto los valores para las variables relacionadas a las caractersticas tcnicas adquieren los siguientes valores: Ca = 1 y Cn = 11 Ahora aplicando las mtricas, podemos observar que las tres se sobrepasan con xito: Hn/Ht + Cn/Ca > 2 29/32 + 11/1 > 2 11.90625 > 2 Hn/Ht > 0.9 29/32 > 0.9 0.90625 > 0.9 Cn/Ca > 0.9 11/1 > 0.9 11 > 0.9
72
8. ANEXOS
8.1. Entregables
En el sitio web http://academic.mejoramisonext.com/ pueden encontrarse todos los entregables mencionados en el presente trabajo, entre los que se encuentran: Las mquinas virtuales de los entornos de trabajo: Cliente: archlinux-2009.02-x86.vdi Servidor: debian-5.0-x86.vdi Video que ensea la evolucin del cdigo fuente de Mejoramiso Next: evolucionMejoramisoNext.avi Manual de usuario de Mejoramiso Next: manualUsuario.pdf Especificacin maquinas virtuales: especificacionVMs.pdf Resumen del trabajo: resumenTrabajoGrado.pdf Software Mejoramiso Next: http://mejoramisonext.com
8.2. Participacin en el III Saln de Inventores y de alta tecnologa

El Saln de Inventores y de Alta Tecnologa es un evento que hace tres aos viene organizando la SAI, Sociedad Antioquea de Ingenieros y Arquitectos, en compaa del SENA, el IDEA y las Gobernacin de Antioquia. Con el evento se busca permitir a los inventores y creadores nacionales e internacionales, divulgar sus creaciones y contactar al sector productivo y acadmico local y nacional, o que estn interesados en patentar, realizar innovaciones, comercializar o simplemente promocionar sus inventos, proyectos y desarrollos tecnolgicos52. Mejoramiso Next, el software resultado del caso de estudio, fue expuesto en el III el Saln de Inventores y de Alta Tecnologa, los das 10 y 11 de Septiembre de 2010, en Plaza Mayor, Medelln. En http://www.facebook.com/album.php?aid=25003&id=147400951966923&ref=mf, se pueden ver algunas fotografas del evento. Puede verse una copia del certificado de ponencia o
52. http://eventos.sai.org.co/convocatoria_evento2.htm
73
puede descargarse desde http://academic.mejoramisonext.com/, seleccionando el archivo "certificadoPonenciaIIISalonInventores.pdf".
8.3. Trabajo Futuro

Las tecnologas expuestas en el proyectos son muy recientes. En ciertas ocasiones esto representa un inconveniente, tal como se coment al hablar del plugin de Sonar para Groovy y tambin cuando fue el caso de un bug en la integracin de Hudson con Codenarc, la cual llevo a reportar el siguiente incidente: http://issues.hudson-ci.org/browse/HUDSON-7902. Es conveniente tener en cuenta para las estimaciones este hecho, y enfatizar an ms en el testing, precisamente para encontrar rpidamente fallos en las herramientas que se estn usando. Respecto al testing, como trabajo futuro se recomienda la investigacin de otros tipos de test diferentes a unitarios y de integracin, como lo son por ejemplo los de estress y los funcionales.
8.4. Glosario
AJAX (Asynchronous JavaScript And XML): Javascript y XML asncronos, es una combinacin de tecnologas que permiten transmitir informacin desde el servidor hacia el cliente de forma asncrona, de tal modo que no sea necesario refrescar las pginas en el navegador web para mostrar nueva informacin. API (Application Programming Interface): Interfaz de programacin de aplicaciones, es el medio por el cual es posible hacer uso de libreras y programas a travs de programacin. Calidad de cdigo: Cualidad de un fragmento de cdigo fuente de evitar malas prcticas de programacin. CMMI (Capability Madurity Model Integration): Integracin de modelos de madurez de capacidades, es un modelo internacional que permite clasificar a las empresas de software en niveles, de acuerdo a la capacidad que estas tengan de desarrollar, mantener y operar sistemas de software con la intencin de mejorar y evaluar sus procesos.
74
Contenedor de servlets: Servidor web que adicionalmente es capaz de interactuar con servlets para dar respuesta a las peticiones hechas por el cliente web. Control de versiones: Mecanismo mediante el cual se lleva un registro de todos los cambios hechos en el cdigo fuente de un software, de tal manera que sea posible deshacerlos en caso de ser necesario. Framework: Marco de trabajo, es una estructura conceptual y tecnolgica que ayuda a resolver problemas de caractersticas comunes. En el contexto de software un framework brinda una plataforma que facilita el desarrollo de aplicaciones al incluir ciertas soluciones prediseadas a problemas recurrentes. Integracin continua: Tcnica mediante la cual permanentemente se genera software ejecutable resultante a partir del cdigo fuente de la aplicacin, de tal forma que se anticipen la mayora de los problemas relacionados al despliegue de software en entornos de produccin. ITIL (Information Technology Infrastructure Library): Marco de trabajo que rene un conjunto de buenas practicas para lograr calidad y eficiencia en entrega de servicios de tecnologa de informacin. JavaScript: Lenguaje utilizado para programar la parte de una aplicacin que se ejecutar en el navegador del usuario y no en el servidor. JVM (Java Virtual Machine): Mquina virtual Java, plataforma de ejecucin que permite abstraer al programador del sistema operativo donde sern usados sus programas. Mejoramiento Continuo: Filosofa de mejora constante mediante pequeos cambios, para mejorar, realizados en todas los procesos de la Organizacin. Nivel de cobertura del cdigo: Se refiere al porcentaje de cdigo fuente de una aplicacin que tiene al menos una prueba automatizada de software asociada. OOP (Object Oriented Programming): Programacin orientada a objetos, es una tcnica o paradigma de programacin en la que se agrupan datos y funciones en entidades denominadas 75
objetos. Pruebas automatizadas de software: Consiste en realizar pruebas de software mediante programacin, de tal modo que estas puedan ser ejecutadas automticamente. Pruebas de software (Testing): Consiste en probar el correcto funcionamiento de una aplicacin. Repositorio de cdigo en linea: Sitio centralizado que permite almacenar y versionar cdigo fuente, lo que significa un respaldo externo diferente a los computadores usados para desarrollar y desplegar el software, permitiendo que cualquier desarrollador con autorizacin pueda realizar cambios en el proyecto independientemente del computador que use. RUP (Rational Unified Process): Proceso de desarrollo de software, muy popular en la actualidad, cuyas principales caractersticas son ser iterativo e incremental. Define un conjunto de disciplinas que se realizan con diferente intensidad segn cada una de las fases. Scrum: Metodologa gil para el desarrollo de software. Con Scrum, los proyectos progresan a travs de una serie de iteraciones denominadas sprints. Cada sprint dura normalmente de 2 a 4 semanas. Scrum es una metodologa ideal para proyectos con requerimientos muy cambiantes. Servidor de aplicaciones: Servidor que a adems de incluir las funcionalidades de un contenedor de servlets*, tambin cumple con la especificacin JEE (Java Enterprise Edition). El termino puede usarse tambin para describir servidores bajo plataformas diferentes a Java, pero es poco comn. Servlet: Clase Java que sigue el API Java para Servlets, la cual define cmo la clase debe responder a peticiones HTTP. SOA (Service Oriented Arquitecture): Arquitectura de software en la que el elemento principal son los servicios, los cuales facilitan la comunicacin entre aplicaciones independientemente del lenguaje en el cual estn escritas. TDD (Test-driven Development): Tcnica que consiste en siempre desarrollar el test antes que el cdigo fuente de la aplicacin encargado de superarlo. 76
XHTML (Extensible HyperText Markup Language): Lenguaje de etiquetas de hipertexto, es similar a HTML pero en sintaxis XML y con reglas ms estrictas. XML (Extensible Markup Language): Lenguaje de etiquetas extensible, es un metalenguaje utilizado para construir nuevos lenguajes que pueden ser entendidos tanto por computadores como por seres humanos. XP (eXtreme Programming): Conjunto de valores, principios y practicas para el desarrollo gil de software de alta calidad, que entrega valor al cliente en la forma ms rpida posible. XUL (XML User Interface Markup Language): Lenguaje de etiquetas para definicin de interfaces de usuario en XML, creado por Mozilla con la intencin de tener un lenguaje independiente de la plataforma para definir interfaces de usuario. ZUML (ZK User Interface Markup Language): Lenguaje de etiquetas utilizado por ZK para definir las interfaces de usuario.
77
9. PRESUPUESTO Y FUENTES DE FINANCIACIN

FUENTES RUBROS Estudiantes PERSONAL $0,00 EQUIPO $0,00 53 SOFTWARE $0,00 MATERIALES $0,00 BIBLIOGRAFA $0,00 PUBLICACIONES $0,00 TOTAL $0,00 Treda Solutions S.A.S $10.800.000,00 $8.600.000,00 $0,00 $0,00 $0,00 $0,00 $10.800.000,00 U de A $0,00 $0,00 $0,00 $0,00 $0,00 $0,00 $0,00 $10.800.000,00 $8.600.000,00 $0,00 $0,00 $0,00 $0,00 $19.400.000,00 TOTAL
COSTO PERSONAL FUNCIN (HORA) Ral ScrumMaster $5.625,00 Chavarra , Investigador Ricardo Yepes Desarrollador $5.625,00 , Investigador Diego Zapata Asesor $16.000,00
FUENTES Treda Solutions DEDICACIN Estudia S.A.S U de A SEMANAL ntes 40 horas por $0,00 $5.400.000,00 $0,00 semana 40 horas por semana 2 horas por semana $0,00 $0,00 $5.400.000,00 $0,00 $0,00
TOTAL (24 SEMANAS) $5.400.000,00 $5.400.000,00
$768.000,00 $768.000,00
FUENTES EQUIPO JUSTIFICACIN TOTAL Treda Solutions Estudiantes S.A.S U de A $0,00 $5.900.000,00 $0,00 $5.900.000,00
Computadoras Puestos de trabajo para (en uso) investigadores, desarrollo de software e implementacin de prototipos Servidor (en $0,00 uso) Impresora (en Impresin de documentos, artculos, $0,00 uso) informes, etc.
$1.800.000,00 $900.000,00
$0,00 $0,00
$1.800.000,00 $900.000,00
53. Todo el software usado en el proyecto es gratuito, a excepcin de Microsoft Windows Server y Microsoft SQL Server usados para probar las caractersticas de multiplataforma que tendr Mejoramiso Next. Mejoramiso Ltda. posee licencias para ambos software, por lo que tampoco se cuentan entre los costos.
78
REFERENCIAS
Abran, A., Moore, J., Bourque, P. & Dupuis, R. (2004). Software Engineering Body of Knowledge. IEEE Computer Society, Angela Burgess. Arboleda, H. (2005). Modelos de Ciclo de Vida de Desarrollo de Software en el Contexto de la Industria Colombiana de Software. ACIS. Revista Sistemas No 93. Beck K. (2002). Test-Driven Development By Example. Three Rivers Institute. Charette, R. (2005). Why Software Fails. [documento electrnico]. IEEE Spectrum. (Cita: julio 7 de 2010) http://spectrum.ieee.org/computing/software/why-software-fails/0 Hessellund, A. (2004). Refactoring as a Technique for the Reengineering of Legacy Systems. ITU, Kbenhavn Kruchten, P. (2003). Using the RUP to evolve a legacy system. IBM, DeveloperWorks Laddad, R. & Hanik, F. (2008). Spring and Tomcat: The Perfect Match. [documento electrnico]. SpringSource Inc. (Cita: julio4) http://www.springsource.com/files/uploads/all/pdf_files/news_event/Spring-and-Tomcat-ThePerfect-Match.pdf Mackall, M. (2006). Towards a Better SCM: Revlog and Mercurial. Selenic Consulting, Ottawa Linux Symposium Proceedings. Oracle Corporation (2010). Introduction to Java Platform, Enterprise Edition 6. World Headquarters Rocher, G. & Brown J. (2009). The Definitive Guide to Grails. Berkeley, Estados Unidos: Apress, 2ed. Scott, M. (2001). Converting ASP to ASP.NET. [documento electrnico]. Microsoft. (Cita: julio 1 de 2010) http://msdn.microsoft.com/en-us/library/ms973813.aspx Smith G. & Ledbrook P. (2009). Grails in Action. Greenwich, Inglaterra: Manning. Stuble M. & Schumacher H. (2008). ZK Developers Guide. Birmingham, Inglaterra: Packt Publishing. Sutherland, J. (2006). Scrum Tuning: Lessons learned from Scrum implementation at Google. [video]. Google Tech Talks. (Cita: julio 2 de 2010) http://video.google.com/videoplay? docid=8795214308797356840 Yuhanna, N. (2010). 2010 Trends for Corporate IT and RDBMS: How PostgreSQL Meets the Needs of Today's Enterprises. [video]. Forrester Research. (Cita: julio 5 de 2010) 79
http://www.enterprisedb.com/learning/forrester_trends_2010_1.do Zhang, Z. & Yang, H. (2004). Incubating Services in Legacy Systems for Architectural Migration. 11th Asia-Pacific Software Engineering Conference
80

Trabajo Grado

Cargado por

Copyright:

Formatos disponibles

Trabajo Grado

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Trabajo Grado

Cargado por

Copyright:

Formatos disponibles

UN ENFOQUE PARA EL DESARROLLO GIL DE APLICACIONES WEB, USANDO SCRUM, EXTREME PROGRAMMING Y HERRAMIENTAS OPENSOURCE SOBRE LA PLATAFORMA JAVA:

CASO DE ESTUDIO MEJORAMISO NEXT

Asesor: DIEGO ZAPATA

3.2. Restricciones endgenas

4. Puede consultarse la lista completa en: http://mejoramiso.com/index.php?

5. ESTADO DEL ARTE

6. Requisitos tcnicos estimados segn la experiencia del equipo de trabajo.

7.2. Contexto tecnolgico

contestar esta pregunta.

7.3. Implementacin de la solucin

Metodologa Scrum, conceptos

Principales actividades en Scrum

Principales artefactos en Scrum

Principales roles en un equipo Scrum

Figura 1: Ciclo de Scrum

Metodologa Scrum, kunagi

Metodologa Scrum en el proyecto Progreso de Macondo

Figura 2: mbabilonia el ScrumMaster accede a Kunagi

Figura 3: mbabilonia crea el proyecto Progreso de Macondo

Figura 4: abuendia, el Product Owner, abre el proyecto Progreso de Macondo

Figura 5: abuendia accede al Product Backlog

Aureliado Buenda requiere registrar a sus estudiantes.

Figura 6: abuendia crea la historia de usuario Registrar estudiantes

Figura 7: abuendia crea la historia de usuario Registrar ideas

Figura 8: abuendia crea la historia de usuario Registrar grados de innovacin

Figura 9: abuendia crea la historia de usuario Calificar ideas

Figura 10: abuendia prioriza el Product Backlog

Historia: Registrar grados de innovacin

Pietro Crespi estima 13 puntos

Gerineldo Marquez estima 20 puntos

Historia: Registrar estudiantes

Pietro Crespi estima 40 puntos

Gerineldo Marquez estima 40 puntos

Figura 16: puntos estimados para la historia de usuario Registrar estudiantes

Historia: Registrar ideas

Pietro Crespi estima 8 puntos

Gerineldo Marquez estima 5 puntos

Figura 19: puntos estimados para la historia de usuario Registrar ideas

Figura 21: abuendia configura los parmetros del Sprint 1

Figura 22: El Whiteboard sin programacin de tareas

Figura 23: gmarquez crea la tarea Modelo

Figura 24: pcrespi crea la tarea Vista

Figura 25: gmarquez reporta 3 horas para la tarea Modelo

Figura 26: pcrespi reporta 2 horas para la tarea Vista

Despus de ver su funcionamiento, Aureliano Buendia decide aceptar la historia.

Figura 29: Sprint Burndown Chart

El Test de Nokia para Scrum

Pregunta 1. Describe your iterations

Comentario tienen una duracin de 3 semanas cada uno

Fixed iteration length 4 weeks Los sprints en el proyecto

2. Describe your testing

Features are tested as soon as they are completed (during iteration)

4. What about your Product Owner?

5. What about your Product Backlog? 6. How about your estimates?

7. How about your burndown charts?

The sprint burndown chart done

only burns down when a task is mantiene el Burndown chart

We have both Project Leader and Scrum roles

Team commits collectively to Sprint goal and backlog