jueves, 19 de julio de 2012

SARMAQ: Sprint 4 y Conclusiones.

La presentación realizada respecto al ultimo Sprint y los resultados finales obtenidos, se puede ver en el siguiente link:

https://dl.dropbox.com/u/24633336/Sistema%20de%20Arriendo%20de%20Maquinas.pdf


Las conclusiones relacionadas con este proyecto apuntan en el sentido de las enseñanzas que su ejecución deja. Básicamente estas enseñanzas se pueden clasificar en tres grupos: primero están aquellas relacionadas con la Metodología de Desarrollo utilizada, en segundo lugar esta lo aprendido en relación al uso de un Framework y por último están las conclusiones derivadas de utilizar una Metodología Ágil, para gestionar un proyecto de desarrollo.

Metodología de Desarrollo.

En relación a este tema el proyecto sirvió para trabajar con Diseño Orientado al Objeto, enfoque que inicialmente fue difícil de abordar, pero que poco a poco nos permitió identificar las clases, con sus atributos y métodos, visualizando también algunas relaciones entre estas clases, principalmente relaciones de asociación, debido a lo pequeño del árbol de clases resultante. Asimismo fue interesante trabajar con el concepto de Casos de Uso, apoyados por UML, ya que esta diagramación contribuyó a identificar, con mayor precisión, los métodos relacionados. En síntesis el Diseño Orientado al Objeto sirve para transformar una especificación de requerimientos en un diseño de software a codificar.

Uso de Framework.

Al utilizar, en este caso, el Framework Spring Roo, es posible concentrase en los aspectos más importantes del dominio a implementar, en vez de ocupar mucho tiempo en preocuparse, por ejemplo, en programar, el look and feel de la aplicación en desarrollo. Los que nos dedicamos a la programación de software debemos ser capaces de comprender rápidamente las estructuras de un Framework, además de aprender a escribir código que sea compatible al interior de este. Estas herramientas facilitan la reusabilidad, tanto de los diseños como del código resultante.

Metodología de Gestión de Proyecto.

El uso de una Metodología Ágil, para controlar la evolución del proyecto, sirvió para aprender de que se trata este enfoque metodológico y como se aplica. En todo caso la práctica dejo entrever un problema estructural en el uso de la agilidad versus la forma de trabajo en grupo que se da en un curso universitario, situación que es difícil de modificar. El problema radica en que la agilidad requiere de reuniones frecuentes y avances concretos, también frecuentes. Pues bien reunirse todos los días para revisar el avance de cada una de las iteraciones ágiles no resulta, dado que los horarios, tanto académicos como laborales, de los integrantes de los grupos de trabajo no se pueden coordinar y la mayoría de los alumnos, de cursos superiores, concentra su dedicación a los trabajos más hacia el final del semestre que al principio del mismo. En síntesis si los grupos no pueden comportarse como un equipo ágil, con dedicación constate durante el semestre, no es posible ser consecuente con casi ninguno de los Principios LEAN.

Recomendaciones:

  • Profesores o Estudiantes con experiencia que intervengan como Scrum Masters de vez en cuando en cada grupo.
  • Hacer charlas de agilidad, motivacionales y de trabajo en equipo.
  • Motivar la lectura de libros de agilidad para reforzar la practica.
  • Recordar frecuentemente los principios LEAN.
  • Motivar el uso de pizarras de visualización de tareas.

Lecturas recomendadas de agilidad:

SARMAQ: Sprint 3.


El 25 de Junio se dio comienzo al Sprint 3 del proyecto SARMAQ, el cual contempla la revisión de lo hecho hasta ahora, y el diseño y desarrollo de los dos últimos requerimientos del proyecto:

  • Gestionar las solicitudes de arriendos de maquinarias.
  • Gestionar el cálculo de facturas, sus detalles y la información a recopilar.

En el Sprint 3 el equipo se comprometio a terminar una serie de tareas correspondientes a los 2 últimos requerimientos, en un plazo de 2 semanas.

El resultado anterior, en la pila de Sprint, se visualiza de la siguiente manera:


Durante la primera semana del Sprint 3, se presentan revisiones y correcciones del trabajo realizado hasta el momento e investigaciones respecto a los formatos de factura que se utilizan en la empresa.

De un total de 37 horas, definidas para el Sprint 3, se logró avanzar 16 horas, quedando pendientes 21 horas. Con este rendimiento por Sprint aún se esta muy lejos de alcanzar la agilidad necesaria para programar los módulos que han de satisfacer, por completo, los requerimientos planteados.

La situación existente, en relación al estado del proyecto, significa que en el Sprint 4 es necesario incluir las 21 horas que no se alcanzaron ha hacer en el Sprint 3. Además en el Sprint 4 se incorporaran casos de prueba, las cuales serán ejecutadas por los mismos integrantes del Sprint dado que por la naturaleza del proyecto el Owner también esta involucrado en la ejecución Sprint.

Para las pruebas se considerará trabajar con el software ya construido en Spring Roo. Las pruebas en si abarcaran situaciones de usuario final, como por ejemplo arrendar una máquina, cobrar un arriendo, etc. En todo caso las pruebas serán diseñadas durante el desarrollo del Sprint 4.


Finalmente, la Pila del Producto y del Sprint 3, quedan de la siguiente forma:






Se observa que los compromisos asumidos en los sprint no se cumplen, situación que afecta los nuevos sprint pues ellos se inicializan con un exceso de carga debido al remanente del sprint anterior.

Lo anterior se debe a la poca experiencia del equipo de trabajo en lo que es el uso de una metodología ágil, sobretodo que el dedicar tiempo sin interrupciones a las tareas y reuniones de los sprints es bastante difícil, mas aún si se le suma la poca experiencia que en general se tiene del desarrollo de sistemas de información, situación que significa que las estimaciones de plazos son muy inexactas.

En base a todo esto hay que tomar las precauciones para que el Sprint 4 cumpla sus objetivos a objeto de contar al final de este con el producto que se especifico inicialmente.


SARMAQ: Sprint 2.


Tomando en cuenta las tareas pendientes que quedaron del Sprint 1, se decide llevar a cabo otro Sprint que considere estas tareas, las debilidades que se hicieron visibles en el Sprint 1 y un plazo de término de 1 semana para el nuevo Sprint.

En el Sprint 2 el equipo se compromete a terminar las mismas tareas del Sprint 1, pero en tan solo 1 semana y con una nueva estimación de horas. Esto se puede ver en la pila del Sprint 2 que se muestra a continuación:



 
El tiempo disponible del equipo para 1 semana queda de la siguiente manera:




Durante la única semana, se logran avances destacables respecto al Sprint anterior, logrando finalizar todas las tareas pendientes al finalizar la semana. Esto último, en la hoja de visualización de tareas, se ve de la siguiente forma:



 
La grafica de burndown del Sprint 2 se muestra a continuación:




Finalmente, la Pila del Producto y del Sprint 2, quedan de la siguiente forma:





Más información respecto al Sprint  1 y 2, y los avances obtenidos, se encuentran en el siguiente informe de avance:

sábado, 23 de junio de 2012

SARMAQ: Sprint 1.


El 14 de Mayo se inicia el primer Sprint de 2 semanas del proyecto SARMAQ (Sistema de Arriendo de Maquinarias), del cual comentaremos la experiencia por semana.

Semana 1.

Durante la primera semana del Sprint 1, no se presentan avances de definición, diseño y desarrollo, solo estudios respecto a los requerimientos, la metodología Scrum y las herramientas de diseño y desarrollo a utilizar. A continuación se muestra la hoja de visualización de tareas de la primera semana:


Cabe destacar, que además del estudio, se comienzan a ver los primeros impedimentos y disfunciones que impactan en la efectividad del Equipo Scrum, tales como:

  • La falta de auto-organización del equipo.
  • La falta de comunicación entre integrantes.
  • Poca asistencia a reuniones presenciales.

Estas debilidades repercuten notablemente en el Sprint 1, y esto se muestra claramente en la gráfica de burndown correspondiente, en donde el trabajo restante sigue siendo las horas definidas al principio del Sprint 1.


Sin embargo, el hecho de comenzar a ver debilidades rápidamente, es el primer paso en Scrum para comenzar a hacer un cambio.

Semana 2.

En la segunda semana y la última del Sprint 1, se comenzaron a ver los primeros avances de definición y diseño. A continuación se muestra la hoja de visualización de tareas de la última semana:

Donde se tuvo más avances, fue en el requerimiento "Definir, diseñar e implementar: Estado de Maquina", en donde se construyó la clase y el caso de uso correspondiente en Modelio, solo faltando la implementación en Spring Roo.

Tomando en cuenta los avances obtenidos, se comienza a avanzar en la disminución de horas de trabajo restante del Sprint 1. Esto ultimo se ve claramente en la gráfica de burndown correspondiente:

 
De un total de 32 horas definidas para el Sprint 1, se logra avanzar 7,5 horas, quedando pendientes 24,5 horas.

Finalmente, la Pila del Producto y del Sprint, quedan de la siguiente forma:

Pila de Producto Post Sprint 1.


Pila de Sprint 1.


Retrospectiva.

A continuación se muestra una estructuración de la retrospectiva del Sprint 1:

  • Lo que anduvo mal:
    • La auto-organización del equipo Scrum.
    • La comunicación entre los integrantes del equipo.
    • La comprensión de los requerimientos.
    • La organización del tiempo.
    • El apoyo entre los integrantes del equipo.
    • El avance en las tareas.
 
  • Lo que ha andado bien:
    • Actualización constante de todos los documentos.
    • Visibilidad de los impedimentos y disfunciones que estan impactando en la efectividad del equipo.


  • Lo que hay que agregar o cambiar:
    • Aumentar la comunicación en el equipo, que no sea solo con el ScrumMaster, sino que, se produzca entre todos los integrantes.
    • Como equipo deben aprender a auto-organizarse (auto-gestionarse). En Scrum los equipos se auto-organizan en vez de ser dirigidos por un jefe de proyecto.
    • Si se tienen dudas respecto a los requerimientos, no dudar en preguntar y pedir apoyo.
    • Aprender a organizarse con los tiempos, es decir, con otras actividades durante la semana.
    • Agilizar el avance en las tareas.

Scrum no es solamente un conjunto concreto de prácticas, más bien es un marco de trabajo que proporciona visibilidad al equipo y un mecanismo que les permite “inspeccionar y adaptar” en consecuencia. Scrum hace visible los impedimentos y disfunciones que están impactando en la efectividad del Dueño de Producto y del Equipo, a fin de que se puedan ser abordados.

Scrum revela debilidades rápidamente, pero no las soluciona, sino que, las hace dolorosamente visibles, y proporciona un marco de trabajo que explore nuevas formas de resolver problemas en ciclos cortos y con pequeñas mejoras.

La experiencia de no entregar lo comprometido al finalizar un Sprint, es el primer paso necesario para ser más realistas y reflexivos en los compromisos.

Bibliografía:

miércoles, 30 de mayo de 2012

Desarrollo Rápido con Spring Roo.


Spring Roo es una herramienta de desarrollo rápido de aplicaciones (RAD), que permite el desarrollo de aplicaciones Java EE de manera más productiva y cómoda para el desarrollador.

Tecnologias Utilizadas.

  • Spring Framework: framework de Java cuya principal caracteristicas es brindar una fabrica de objetos basado en la Inyeccion de Depedencias.
  • Spring MVC: modulo del framework Spring, que implementa una arquitectura Modelo-Vista-Controlador para desarrollar una aplicación web.
  • Spring Security: modulo del framework Spring, que permite gestionar completamente la seguridad de las aplicaciones Java.
  • Spring Web Flow: modulo del framework Spring, que define y gestiona los flujos de paginas dentro de una aplicación web.
  • Selenium: herramienta para hacer pruebas de aplicaciones web.
  • Maven: herramienta de software para la gestión y construcción de proyectos Java, basado en un formato XML.
  • Log4j: biblioteca desarrollada en Java que permite a los desarrolladores de software elegir la salida y el nivel de granularidad de los logs a tiempo de ejecución.
  • JUnit: conjunto de bibliotecas utilizadas para hacer pruebas unitarias de aplicaciones Java y llevar un desarrollo guiado por pruebas (TDD).
  • JavaServer Pages.
  • Java Persistence Api (JPA): framework de java que maneja datos relacionales en aplicaciones, no perdiendo las ventajas de la orientación a objetos al interactuar con una base de datos (mapeo objeto-relacional), y permitiendo usar objetos regulares (POJOs)
  • AspectJ: lenguaje de programación orientado a aspectos construido como una extensión del lenguaje Java.

Caracteristicas.

  • Genera código (de forma activa y pasiva) para aplicaciones Java con Spring.
  • Eliminar el trabajo tedioso centrando el desarrollo en la lógica de negocio.
  • Se basa en el paradigma Convencion sobre Configuración (CoC).
  • Posee un enfoque de diseño guiado por el dominio (DDD).

    • Está dirigido por un modelo de entidades.
    • Se centra en la logica de las entidades y elimina las capas redundantes.
    • Utiliza el patron de diseño "Active Record" en oposicion al anti-patrón de diseño "Anemic Domain Model (ADM)".

  • Crea un proyecto en minutos.
  • Añade valor durante todo el ciclo de vida (Retroalimentación).
  • Las aplicaciones siguen las mejores práticas de diseño.
  • Permite auto-generar test unitarios y de integración.
  • No incorpora elementos adicionales al entorno de ejecución, por lo que no penaliza la velocidad de aplicación.
  • Se puede integrar con IDEs como Spring Tool Suite o Eclipse.
  • Recibe instrucciones a través de una consola interactiva con auto-completado y ayuda en línea.
  • Es extensible usando modulos OSGI (ficheros JAR con un conjunto de metadatos que especifican la caracteristicas del modulo).
  • Se puede eliminar un proyecto en minutos.

Interfaz de Linea de Comandos (CLI)

Spring Roo es una herramienta de Linea de Comandos (CLI) de fácil uso, que proporciona auto-completado "Tab" de comandos y argumentos, y ayuda en linea mediante "help" y "hint".



Arquitectura.

Roo genera código que se puede dividir en dos categorías:

  1. Código gestionado por Spring Roo => Ficheros AspectJ ITD (.aj)
  2. Código gestionado por el programador => Fuentes Java.



En tiempo de compilación, el código de los ficheros .aj, es tejido en el código de los fuentes Java.


Ejemplo: Aplicacion de Inventario.


Se tiene una clase "Producto" con sus respectivos atributos: numero identificador (id_producto), nombre, descripcion y precio.


Se procede a crear la carpeta "Inventario" donde se almacenara el proyecto, y dentro de esta, se ingresa a la consola del Roo.


A continuación se comienza a desarrollar la aplicación:

// Se Crea el Proyecto
roo> project --topLevelPackage com.curso.inventario
// Se Define la herramienta de persistencia y la base de datos a utilizar
roo> jpa setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY
// Se Crea la entidad "Producto"
roo> entity jpa --class ~.domain.Producto --testAutomatically
// Se crean los antributos de la entidad "Producto" con sus respectivas restricciones
roo> field number --fieldName id_Producto --type int --notnull
roo> field string --fieldName nombre --notNull
roo> field string --fieldName descripcion
roo> field number --fieldName precio --type double
// Se genera la capa de presentacion
roo> web mvc setup
roo> web mvc all --package ~.web
// Se ejecutan las pruebas respectivas
roo> perform tests
// Se empaqueta el proyecto
roo> perform package
// Se estructura el proyecto para ser usado y modificado en eclipse
roo> perform eclipse
// Se sale de Roo
roo> exit
// Se despliega la aplicación en un contenedor web
C:\Users\Arak\Roo\Inventario> mvn tomcat:run

A traves de estos simples pasos, se genero la siguiente aplicación web:



Desarrollo en MQ Arriendos.

Se propone desarrollar la aplicación del "Sistema de Inventario" para MQ Arriendo utilizando Spring Roo, donde cada tarea asociada a un requerimiento, tendra un script con todos los comandos utilizados en el desarrollo de la aplicacion de esa tarea. Luego estos script se uniran para formar solo uno, y por ende, solo una aplicación que integre todas las tareas y finalmente todos los requerimientos planteados por el Product Owner.


Fuente y más información:

Desarrollo en Java EE.



Java es un lenguaje de programación que como plataforma integra tres componentes:

  • Lenguaje: lenguaje de alto nivel que utiliza el paradigma POO.
  • Maquina Virtual: permite que los programas ejecutables sean compilados como archivos ejecutables de la Java Virtual Machine (JVM), y que sean ejecutados en distintas arquitecturas.
  • Bibliotecas: tambien conocidas como Java Aplication Programming Interface (Java API) que es un conjunto de componentes que proporcionan diferentes herramientas para el desarrollo.

Ediciones.


  1. Java Micro Edition (Java ME): se enfoca en el manejo de java en dispositivos móviles y portátiles.
  2. Java Standart Edition (Java SE): define las caracteristicas basicas para trabajar en ambientes de escritorio y servidores.
  3. Java Enterprise Edition (Java EE): define las características necesarias para desarrollar aplicaciones empresariales que se ejecuten de forma portable a través de servidores de aplicaciones.


La plataforma Java EE permite crear aplicaciones empresariales basado en un modelo de multicapas, que divide a la aplicación en diferentes niveles, cada uno con una tarea especifica.

Componentes.


De los elementos aqui nombrados, los principales son:

  • Java Servlet: programas que permiten generar páginas web de forma dinámica, a partir de los parámetros de petición que envíe el navegador web.
  • JavaServer Pages (JSP): tecnologia Java que permite generar contenido dinámico para web, en forma de documentos HTML, XML o de otro tipo.
  • JavaServer Faces (JSF): tecnología Java basada en web que simplifica el desarrollo de interfaces de usuario.
  • Enterprise Java Bean (EJB): modulos encargados de manejar toda la logica de programación detras de la aplicación.

La utilización en niveles de la logica de programación, permite separar los elementos de las aplicaciones en partes explicitamente definidas, como por ejemplo, dejar los procesos en un lugar, los datos en otro y mostrar las interfaces en otro.

Aplicaciones en Multicapas.

En la programación por capas, la idea es buscar la forma de separar lo que ve el usuario de los procesos creados por el desarrollador. En la siguiente figura se muestran las diferentes capas que posee una aplicación Java EE:


Enfoque Java EE en MQ Arriendos.

Para llevar a cabo el desarrollo del Sistema de Inventario en MQ Arriendos, se utilizara una herramienta llamada Spring Roo, la cual se enfoca en el desarrollo rapido de aplicaciones Java EE de manera más productiva y cómoda para el desarrollador. En el siguiente articulo hablaremos sobre esta herramienta.

Fuente y más información: