Framework tecnológico para el desarrollo de aplicaciones en la Universitat Jaume I Ricardo Borillo Domenech
[email protected] Índice de contenido Framework tecnológico para el desarrollo de aplicaciones en la Universitat Jaume I.....................................1 Introducción y objetivos...................................................................................................................................3 Metodología.....................................................................................................................................................3 Desarrollo ágil en la Universitat Jaume I....................................................................................................5 Arquitectura básica del sistema.......................................................................................................................6 Capa de servidor........................................................................................................................................7 Frameworks básicos:.............................................................................................................................7 Tests unitarios:......................................................................................................................................8 Documentación adicional:......................................................................................................................9 Capa de cliente o interfaz gráfico de usuario............................................................................................11 Frameworks básicos:...........................................................................................................................11 Tests unitarios.....................................................................................................................................12 Documentación adicional:....................................................................................................................12 Entorno de desarrollo.....................................................................................................................................13 Gestión de proyectos e incidencias..........................................................................................................13 Requisitos iniciales:.............................................................................................................................13 Herramientas disponibles:...................................................................................................................13 Documentación adicional:....................................................................................................................14 Herramientas de documentación y gestión del conocimiento...................................................................15 Requisitos iniciales:.............................................................................................................................15 Herramientas disponibles:...................................................................................................................15 Sistema de control de versiones...............................................................................................................16 Requisitos iniciales:.............................................................................................................................16 Herramientas disponibles:...................................................................................................................16 Documentación adicional:....................................................................................................................16 Herramientas de construcción..................................................................................................................17 Requisitos iniciales:.............................................................................................................................17 Herramientas disponibles:...................................................................................................................17 Documentación adicional:....................................................................................................................17 Integración contínua.................................................................................................................................18 Requisitos iniciales:.............................................................................................................................18 Herramientas disponibles:...................................................................................................................18 Documentación adicional:....................................................................................................................20 Pruebas unitarias......................................................................................................................................20 Requisitos iniciales:.............................................................................................................................20 Herramientas disponibles:...................................................................................................................20 Documentación adicional:....................................................................................................................21 Repositorio de artefactos..........................................................................................................................21 Requisitos iniciales:.............................................................................................................................22 Herramientas disponibles:...................................................................................................................22 Documentación adicional:....................................................................................................................22 Herramientas de análisis estático del código............................................................................................23 Requisitos iniciales:.............................................................................................................................23 Herramientas disponibles:...................................................................................................................23 Documentación adicional:....................................................................................................................23 IDE para el desarrollo...............................................................................................................................23 Requisitos iniciales:.............................................................................................................................23 Herramientas disponibles:...................................................................................................................24 Generadores de código............................................................................................................................24 Requisitos iniciales:.............................................................................................................................24 Herramientas disponibles:...................................................................................................................24 Documentación adicional:....................................................................................................................25 Resumen de herramientas seleccionadas................................................................................................25 Introducción y objetivos A la hora de desarrollar aplicaciones, es tan importante considerar el conjunto de herramientas que componen el entorno de desarrollo, como el de las tecnologías empleadas, las metodologías adoptadas para la gestión de los equipos o la definición del posterior proceso de explotación. Con las metodologías ágiles como aspecto clave y diferenciador, se han definido toda una serie de herramientas y tecnologías que permitan alcanzar los objetivos de flexibilidad, facilidad de adaptación al cambio y posicionamiento a futuro de los desarrollos realizados. Así pues, el presente documento tiene como objetivo examinar qué metodologías serían más adecuadas, cómo deberíamos configurar el entorno sobre el cual poder trabajar y qué tecnologías se deberían adoptar dentro del marco de trabajo de la Universitat Jaume I. Con todo esto, la organización pretende: A nivel interno: Alineamiento con los objetivos estratégicos de la institución, de forma que este nuevo modelo sea una herramienta más de gestión del cambio en el camino hacia el Gobierno IT. Mejorar el nivel de satisfacción de la comunidad universitaria con respecto a los aplicativos disponibles. Posicionarse en nuevas tecnologías de desarrollo, más concretamente en metodologías ágiles. Conseguir para el área una metodología de trabajo ágil, eficiente y efectiva. Minimizar, en la medida de lo posible, en número de errores que llegan al usuario, anticipando estos. A nivel externo: Ser un referente, al menos a nivel universitario, en el desarrollo de aplicaciones. Sentar las bases para el desarrollo de un ERP universitario modular y abierto. Metodología Uno de los objetivos principales de las organizaciones es la mejora continua. Cuando hablamos de equipos técnicos dedicados al desarrollo de software, esta visión de mejora continua se traduce en la necesidad de obtener unos niveles de satisfacción más altos en cuanto a la experiencia de los usuarios finales se refiere (estudiantes, profesores y trabajadores) y en conseguir reducir el tiempo final de puesta en explotación de los nuevos servicios (time to market). La mejora continua aplicada a cómo se desarrolla software, pasa por cuestionarse todos y cada uno de los aspectos implicados en el ciclo de vida del software. Desde la arquitectura de las aplicaciones, pasando por el conjunto de tecnologías empleadas, hasta cómo trabaja y qué herramientas utiliza el propio equipo de desarrollo. Hasta ahora, las metodologías clásicas como RUP, Métrica v3 o CMMI han impuesto ciclos de desarrollo muy estrictos y pesados en los que las pruebas en los sistemas se realizaban en fases muy avanzadas del desarrollo, provocando que los errores fueran detectados muy tarde o incluso no hubiera tiempo para realizar unas pruebas exhaustivas. Esto provoca que se tenga poca reacción ante cualquier cambio en la definición del sistema. Por otra parte, en este tipo de metodologías, la intervención del usuario se limitaba a la fase de toma de requisitos del sistema, no teniendo un feedback real del mismos hasta la entrega del producto final. Esto provoca que el desarrollo muchas veces no coincida con la visión que el usuario final del mismo tenía inicialmente. Si no podemos realizar unos controles de calidad en el software mediante pruebas de distintos tipos y el usuario no nos da feedback hasta el final del proyecto, estamos incumpliendo el primer principio que buscamos para la mejora continua: Calidad del software y satisfacción de los usuario. Igualmente, si tenemos que seguir una metodología estricta y pesada con muchas fases y en la que no se tiene una versión operativa del producto hasta el final del desarrollo, estamos incumpliendo el segundo principio que buscamos para la mejora continua: Acelerar el ciclo de desarrollo y puesta en explotación de las aplicaciones En definitiva, podemos concluir que esta forma de desarrollo en cascada no va alineada con los objetivos propuestos, por lo que se impone un cambio de paradigma a la hora de gestionar los ciclos de desarrollo y la interacción con el usuario final que es al fin y al cabo el dueño del producto. En contraposición con las metodologías clásicas, las metodologías ágiles se centran en conseguir versiones operativas del producto que estamos desarrollando al final de cada ciclo de desarrollo propuesto y en conseguir que el usuario final se integre en el proyecto como parte del equipo de desarrollo. De esta forma, se va añadiendo valor al producto de forma constante en cada iteración y no se espera al final del desarrollo para realizar pruebas a todos los niveles, aumentando la calidad del producto y garantizando el feedback de los usuarios involucrados en el desarrollo. Desarrollo ágil en la Universitat Jaume I Hay que tener en cuenta que un cambio metodológico de estas características, y más en una universidad, impone también un cambio interno muy fuerte en los equipos de desarrollo en los que se implanta. Es por ello que para la implantación de una metodología ágil de trabajo como Scrum1 o Kanban2, o el seguimiento de un conjunto de buenas prácticas como las definidas por eXtreme Programming3, necesitaremos una formación exhaustiva del equipo de desarrollo y ciertas herramientas de apoyo que ayuden a tener estos ciclos iterativos bajo control y que saquen el máximo rendimiento de nuestro entorno y de nuestro equipo. 1 http://en.wikipedia.org/wiki/Scrum_%28development%29 2 http://en.wikipedia.org/wiki/Kanban 3 http://en.wikipedia.org/wiki/Extreme_Programming En cuanto a la formación, se debe tener en cuenta de que estamos planteando un entorno muy dinámico y con mucha interacción entre todos los miembros del equipo, por lo que al margen de la formación en metodologías ágiles, será necesaria una formación técnica adicional en conceptos como compartición del código, integración continua o pruebas unitarias. Hay que tener en mente que la formación no es algo puntual que se tenga que realizar únicamente al principio de la creación de un equipo ágil. Este tipo de equipos necesitan estar formados y motivados continuamente, por lo que el papel de un facilitador o un coach dentro de la organización, será de vital importancia. En cuanto a las herramientas de apoyo, el objetivo es conseguir un ecosistema de herramientas que nos ayude a garantizar la correcta interacción del equipo para producir software de mayor calidad y en el menor tiempo posible. Para ello, en el presente artículo analizaremos varias áreas de acción como la gestión compartida del código, la integración continua, el desarrollo dirigido por tests a todos los niveles (unitario, de integración, funcional, de aceptación o de carga), el análisis estático del código para la detección temprana de posibles bugs o malos diseños y la definición y gestión de los artefactos generados y de sus versiones. Arquitectura básica del sistema Las nuevas aplicaciones se diseñarán en base a una serie de capas que permitan una correcta gestión de los modelos de datos y de las reglas de negocio en las aplicaciones. Para ello se estructurarán en base a cuatro capas lógicas: Capa del modelo: Encargada de mantener la coherencia de la aplicación mediante la implementación de las reglas de negocio necesarias. Esta capa será la encargada de interactuar con la de persistencias cuando sea necesario. Capa de persistencia: Encargada de "mapear" los modelos relaciones y de proporcionar una serie de clases de acceso a las entidades gestionadas. En ella se deberá dar soporte a todas las necesidades del negocio en cuanto inserción, consulta y procesamiento de información de cada uno de los ámbitos universitarios. Capa de servicios: Encargada de proporcionar acceso a la capa del modelo de una forma abierta e interoperable. Deberá permitir la comunicación vía HTTP y en base a formatos estándar de intercambio de información como XML (ATOM, RSS, RDF, OData u otros) o JSON. Esta capa de servicios permitirá: ◦ Un acceso flexible de cualquier tipo de tecnología cliente a la información y los procesos de negocio. Un separación de conceptos que permita mantener una base coherente, testeable y altamente estable. ◦ Capa de interfaz gráfico de usuario: Proporcionará un acceso de calidad a los servicios expuestos y estará basada en tecnologías de cliente rico. Deberá ser diseñada para cumplir con los requisitos impuestos de eficiencia, usabilidad y accesibilidad. Con esta división entre un interfaz de usuario rico y una capa de servicios, se pretende que el equipo de desarrollo se centre en el diseño de una API consistente, estándar e interoperable que permita la integración o implementación de cualquier interfaz en cualquier plataforma. Esta arquitectura permite alcanzar dos objetivos principales: Diseño de un API de servicios que exponga los recursos clave de la organización, gracias al conocimiento del negocio de los desarrolladores de la universidad que lo han diseñado, eliminando inicialmente la carga adicional de desarrollar aplicaciones gráficas para su explotación (aunque se ofrezca un interfaz rico de referencia para su uso). Desacoplamiento de la capa gráfica con el fin de que terceros puedan desarrollar interfaces alternativos de cara a su explotación en entornos tanto de escritorio, como web o móviles. Capa de servidor El análisis actual se basa en la elección de Java como lenguaje base de desarrollo en la parte del sevidor y JavaScript en la parte cliente. Motivaciones para el uso de Java: Actualmente ya se cuenta con una base de aplicaciones desarrolladas en Java (portal corporativo, publicación de contenidos con Apache Cocoon4, Web Services, pasarelas de envío SMS, etc). Recientemente, el equipo de desarrollo ha completado una formación básica en Java. Ya existen varios desarrolladores que tienen experiencia en este tipo de entornos y tecnologías. Las APIs proporcionadas por muchas de las aplicaciones que se utilizan en la actualidad están basadas en Java (DSpace, Bonita Workflow, firma digital con CryptoApplet, etc). 4 http://cocoon.apache.org/ Frameworks básicos: Para el desarrollo en la capa del servidor, se utilizarán frameworks que ayuden a reducir la complejidad en el desarrollo y aporten flexibilidad y simplicidad de uso. Una de las bases de este tipos de desarrollo es la utilización de frameworks como Spring Framework5, el cual permite: Gestión integral de la configuración. Toda la configuración e interacción de los distintos componentes se gestiona en un mismo lugar. Integración con las APIs estándar que proporciona Java: JPA, JAXB, JXM, JMS, etc. Integración con las APIs de uso más común en el mercado. Soporte para la inyección de dependencias. Otro de los frameworks básicos a utlizar en la implementación de la capa de servicios basada en REST, será Jersey6. Este framework implementa el estándar JAX-RS para poder exponer esta serie de servicios, integrándose perfectamente con Spring Framework, JAXB y otras tecnologías relacionadas (JSON, ATOM, OData, etc). Tests unitarios: La presencia de unidades de testeo a todos los niveles debe ser básica para el éxito de este nuevo sistema de desarrollo. En próximos apartados, se analizarán soluciones de testeo enfocadas a las distintas capas del desarrollo, cubriendo desde los aspectos funcionales de los interfaces gráficos, hasta los unitarios de las reglas de negocio codificadas. 5 http://www.springsource.org 6 http://wikis.sun.com/display/Jersey/Main Documentación adicional: Spring in Action third edition: Documentación oficial de Spring Framework 3.X: http://static.springsource.org/spring/docs/3.1.0.M2/spring-framework-reference/html/ RESTful Web Services: Tutorial: REST with Java (JAX-RS) using Jersey http://www.vogella.de/articles/REST/article.html Capa de cliente o interfaz gráfico de usuario Se realizará un diseño de las aplicaciones en base a tecnologías de cliente rico, cuyo objetivo será: Buscar una mejor experiencia de usuario. Reducir la heterogeneidad actual de interfaces, siguiendo unas pautas básicas de diseño y usabilidad, obteniendo un diseño uniforme. Generar aplicaciones más dinámicas y flexibles. Frameworks básicos: Para el diseño de la capa cliente, se utilizarán frameworks como ExtJS7. Estos frameworks son especialmente interesantes, ya que ofrecen: Gran cantidad de componentes gráficos de gran potencia y fáciles de extender. Soporte independiente del navegador. Integración con tecnologías REST. 7 http://www.sencha.com/products/extjs/ Disponibilidad de herramientas de diseño visual (como ExtJS Designer). Soporte para internacionalización de interfaces, aspecto gráficos configurable en base a temas y layouts flexibles.Tests unitarios La implementación de tests unitarios será una constante en todas las capas del desarrollo. En la capa de interfaz de usuario se contará con herramientas de automatización de las pruebas como Selenium8 o phatomJS9, las cuales permiten la reproducción de los flujos de navegación que realizará el usuario y su testeo en distintos navegadores de forma automatizada. 8 http://seleniumhq.org/ 9 http://code.google.com/p/phantomjs/ Documentación adicional: ExtJS in Action: Documentación oficial de Sencha ExtJS: http://www.sencha.com/learn/legacy/Tutorials Videos canal vimeo ExtJS: http://vimeo.com/tdgi/videos Entorno de desarrollo Gestión de proyectos e incidencias Requisitos iniciales: Gestión integrada de bugs, tareas y mejoras. Definición de los productos, módulos y componentes de las aplicaciones desarrolladas. Versionado de los distintos productos. Planificación de iteraciones y soporte a las metodologías empleadas. Herramientas disponibles: Atlassian JIRA: http://www.atlassian.com/software/jira/ RedMine: http://www.redmine.org/ Bugzilla: http://www.bugzilla.org/ Trac: http://trac.edgewall.org/ Se recomienda el uso de JIRA por su potencia, flexibilidad y capacidad de integración con las herramientas existentes. Se puede complementar su uso con el módulo de gestión ágil de proyectos GreenHopper. Documentación adicional: JIRA Essentials: Practical JIRA Administration: Documentación oficial de JIRA: http://confluence.atlassian.com/display/JIRA/Home Herramientas de documentación y gestión del conocimiento Requisitos iniciales: Formato estándar de representación. Documentación accesible online, estructurada y buscable (base de datos de conocimiento). Facilidad de modificación y mantenimiento. Posibilidad de exportación a otros formatos de presentación como PDF o ODT. Herramientas disponibles: Confluence: http://www.atlassian.com/software/confluence/ MediaWiki: http://www.mediawiki.org/wiki/MediaWiki/es xWiki: http://www.xwiki.org/xwiki/bin/view/Main/ Se recomienda el uso de Confluence por su integración con JIRA y por la potencia que ofrecen sus herramientas de exportación de la documentación en un formato PDF enriquecido. Sistema de control de versiones Requisitos iniciales: Repositorio unificado para todo el código desarrollado que permita su compartición. Soporte para el versionado de los proyectos. Disponibilidad de herramientas que permitan el acceso, gestión, revisión, comparación y trazabilidad de cambios. Herramientas disponibles: Subversion: http://subversion.tigris.org/ Mercurial: http://subversion.tigris.org/ Git: http://git-scm.com/ Se recomienda el uso inicial de un sistema de control de versiones centralizado como Subversion para facilitar la adaptación del equipo de desarrollo, planteándose en un futuro próximo el paso a un sistema distribuido basado en Git o Mercurial. En el caso de optar por JIRA en el apartado de gestión de proyectos, se recomienda la adopción de los módulos de acceso al código del Subversion Fisheye10 y de revisión del código Crucible11. Documentación adicional: Control de versiones con Subversion: http://svnbook.red-bean.com/ Pragmatic Version Control Using Git: Mercurial: The Definitive Guide: http://hgbook.red-bean.com/read/ Herramientas de construcción Requisitos iniciales: Evitar la compilación, construcción y despliegue manual del código. De esta forma se intenta evitar errores a la hora de ejecutar este proceso. Facilitar el despliegue de cualquier aplicación por parte de cualquier persona. Mantener la independencia del IDE. Gestionar de forma automática las dependencias. Integración de herramientas auxiliares en el proceso de construcción (despliegue, documentación, análisis estático del código, tests unitarios, etc). Herramientas disponibles: Maven: http://maven.apache.org/ Ant: http://ant.apache.org/ Gradle: http://www.gradle.org/ Se propone el uso de Maven por su integración con las herramientas de gestión de artefactos y de integración contínua, por la gestión integrada de dependencias y por ser uno de los más utilizados en proyectos multimódulo. 10 http://www.atlassian.com/software/fisheye/ 11 http://www.atlassian.com/software/crucible/ Documentación adicional: Maven: The Complete Reference: http://www.sonatype.com/books/mvnref-book/reference/ Ant in Action: Integración contínua Requisitos iniciales: Construcción, revisión e integración contínua de los módulos desarrollados. Independiente del lenguaje de programación. Existencia de plugins que permitan adaptarse a cualquier requisito de despliegue. Punto único de generación de artefactos, documentación, informes de test, despliegues de preproducción, etc. Herramientas disponibles: Jenkins: http://jenkins-ci.org/ Bamboo: http://www.atlassian.com/software/bamboo/ CruiseControl: http://cruisecontrol.sourceforge.net/ Se propone el uso de Jenkins por su gran adopción y por su extensísima colección de plugins. Documentación adicional: Jenkins: The Definitive Guide: Pruebas unitarias Requisitos iniciales: Comprobar la integridad del software desarrollado y favorecer la detección de bugs en fases tempranas del desarrollo. Facilitar el refactoring y la realización de cambios que puedan afectar a otros módulos (tests de regresión). Favorecer el diseño modular. Documentar las funcionalidades y bugs. Herramientas disponibles: jUnit: http://www.junit.org/ TestNG: http://testng.org/doc/index.html Se propone el uso de jUnit como base para el desarrollo de tests unitarios. Esta herramienta se completará con otras posibles para cubrir los distintos ámbitos de testeo: Selenium. Test de interfaz de usuario: http://seleniumhq.org/ Hamcrest. Matchers específicos para jUnit: http://code.google.com/p/hamcrest/ DbUnit. Test de base de datos: http://www.dbunit.org/ jMeter. Test de rendimiento y carga: http://jakarta.apache.org/jmeter/ Mockito. Implementación de mock objects y stubs: http://mockito.org/ Cobertura. Análisis del conjunto de código del proyecto que está respaldado por tests unitarios. Suele expresarse en % y su valor mínimo dependerá del tipo de proyecto y de la cantidad de código autogenerado con que cuente nuestro proyecto: http://cobertura.sourceforge.net/ Documentación adicional: XUnit Test Patterns: JUnit in Action: JUnit Recipes: Growing Object-Oriented Software Guided by Tests: Repositorio de artefactos Requisitos iniciales: Contar con un repositorio centralizado de cualquier librería utilizada en el desarrollo. Controlar las librerías utilizadas y sus versiones. Tener un punto único de publicación de las distintas versiones de nuestros desarrollos que vayamos generando. Control del acceso a los artefactos generados, gestión sencilla web y backup centralizado. Herramientas disponibles: Nexus: http://nexus.sonatype.org/ Artifactory: http://www.jfrog.com/products.php Archiva: http://archiva.apache.org/ Se propone el uso de Nexus por su simplicidad de instalación y uso, y su gran rendimiento. Documentación adicional: Repository Management with Nexus: http://www.sonatype.com/books/nexus-book/reference/ Herramientas de análisis estático del código Requisitos iniciales: Estas herramientas nos permitirán el análisis centrado en el código fuente del proyecto para la detección de potenciales bugs, porciones de código ineficientes, procedimientos con excesiva complejidad (complejidad ciclomática), problemas de seguridad, etc. Herramientas disponibles: Sonar. Integra PMD, CPD, CheckStyle, Cobertura, FindBugs y otras: http://www.sonarsource.org/ Se propone el uso de Sonar como herramienta integradora en lugar del uso de herramientas individuales desde el proyecto. Maven será el responsable de la exportación de las métricas y de su registro en Sonar (este proceso se puede realizar desde el servidor de integración contínua). Documentación adicional: Documentación oficial de Sonar: http://docs.codehaus.org/display/SONAR/Documentation IDE para el desarrollo Requisitos iniciales: Entorno integrado de desarrollo que permita el acceso al resto de componentes del entorno y facilite el trabajo con los mismos sin tener que abandonar el propio IDE. Herramientas disponibles: Eclipse: http://www.eclipse.org/ Netbeans: http://netbeans.org/ IntelliJ: http://www.jetbrains.com/idea/ Se propone Eclipse como herramienta básica debido a la gran integración que permite de todas las herramientas del entorno. Se recomienda el uso de alguna de las distribuciones de Eclipse existentes como SpringSource Tool Suite12, la cual dispone en su configuración básica de todos los plugins necesarios para iniciar el desarrollo tanto a nivel de construcción con Maven, como de complementos para el trabajo con Spring Framework. 12 http://www.springsource.com/developer/sts Generadores de código Requisitos iniciales: Generación automática de código para mejorar la eficiencia en el desarrollo, prevenir errores en la codificación y facilitar el mantenimiento en las distintas capas. Herramientas disponibles: JPA. Generación de código de persistencia con Hibernate+Maven. Spring Roo. Creación y mantenimiento de proyectos de forma automatizada: http://www.springsource.org/roo ExtJS Designer. Creación de interfaces de forma visual: http://www.sencha.com/products/designer/ Documentación adicional: Java Persistence with Hibernate: Spring Roo in Action: Resumen de herramientas seleccionadas JIRA: Gestión de proyectos e incidencias. Confluence: Documentación y gestión del conocimiento. Subversion: Control de versiones. Maven: Herramienta de construcción. Jenkins: Herramienta de integración continua. jUnit: Pruebas unitarias. Nexus: Repositorio de artefactos. Sonar: Análisis estático del código. ExtJS Designer: Creación de interfaces de forma visual. Eclipse (SpringSource Tool Suite): Herramienta integradora del resto de herramientas.