Documentacion referente al diseño de la herramienta Integral Issue Tracker

Online Mockup Integral Issue Tracker tool

1. Introducción

1.1. Situación Actual de los sistemas de issue tracking

Actualmente existen issue trackers que proveen soluciones avanzadas sobre Project Management que permiten relacionamiento rapido de mensajes y tareas pero funcionan de manera que se reciben los mensajes en el cliente de email y luego uno debe ingresar al otro sistema para modificar los detalles de la tarea.

También proveen integración con SCM (principalmente SVN y CVS) pero estos solo permiten ver los historiales de cambios del código y el referenciamiento de estos a un issue es manual. Aunque existen clientes SVN, por ejemplo, que permiten integrarlo a un issue Tracker para tener directo relacionamieno del commit con un issue, esto implica trabajar con dos herramientas por separado nuevamente.

La solución propuesta ha de paliar esta insuficiencia de integración entre estos sistemas, que en realidad deben trabajar como uno solo.

La herramienta es entonces, un issue Tracker avanzado que permite realizar tareas de 3 sistemas en uno solo.

1.2. Objetivo:

Se desea minimizar el overhead del desarrollador para la administración de tareas en su entorno de manejo de proyectos. Para esto se necesita una herramienta que maneje las conversaciones de email del usuario y a su vez, automáticamente, poder relacionar estos emails directamente a un issue.

La herramienta también debe automatizar el proceso de checkin de código fuente al repositorio de manera que se evite el referenciamiento manual del issue con el checkin y viceversa.

También, para los administradores de proyecto, se desea obtener una medición sobre si el proyecto se encuentra a tiempo para la fecha de entrega, y si la asignación de tareas/recursos se encuentra balanceada.

1.3. Requisitos

La herramienta debe cumplir con los siguientes requisitos:

Manejar conversaciones de email entre los usuarios (crear, recibir, ver y responder emails).
Convertir una conversación de email a un issue.
Permitir un checkin de svn en una actualizacion de un issue.
Realizar tareas de update code, log y administración de configuración de svn.
Recaudar datos automáticamente sobre los cambios de estado, duración y prioridad de los issues para el registro y visualización del estado del proyecto.
Visualizar en forma gráfica el estado del proyecto a través de su línea de tiempo estimada para el desarrollo.
Visualizar en forma gráfica la distribución de tareas por usuarios en el proyecto.
Realizar búsquedas de issues y conversaciones, con la posibilidad de guardar estas configuraciones de búsqueda.

2. Módulos del sistema

2.1. Comunicaciones

2.1.1. Crear una conversación de email

2.1.2. Inbox de emails

2.1.3. Responder un email

2.1.4. Crear un issue en base a un email

2.1.5. Responder a un issue (actualizar el estado de un issue)

2.1.6. Commit svn al responder a un issue

2.1.7. Diff svn antes de hacer commit SVN

2.1.8. Inbox de issues

2.2. Gestión

2.2.1. Crear un proyecto

2.2.2. Crear usuarios

2.2.3. Configurar un proyecto. (parámetros de un proyecto)

2.2.4. Deshabilitar un proyecto. ( marcar como finalizado)

2.2.5. Agregar custom fields a proyecto. (campos personalizados)

2.2.6. Configuración de Servicio de cuentas de gmail, svn y jtrac

2.2.7. SVN checkout

2.2.8. SVN Update

2.3. Análisis

2.3.1. Búsquedas con configuración guardable

2.3.2. Configuración de charts en base a métricas (custom fields o valores precalculados)

2.3.3. Dashboard

3. Casos de uso

3.1. Comunicaciones

3.1.1. Crear una conversación de email

El usuario crea un email, y rellena los campos de subject, destinatarios y mensaje.

Mockup

3.1.2. Inbox de emails

El usuario recibe un email y lo ve disponible en su lista de Inbox.

El usuario hace click en el subject y ve los detalles del mensaje.

Mockup

3.1.3. Responder un email

El usuario responde a un email recibido.

Mockup

3.1.4. Crear un issue en base a un email

El usuario crea un issue con el boton reply as issue cuando responde a un mensaje de email.

Mockup

3.1.5. Responder a un issue (actualizar el estado de un issue)

El usuario modifica los atributos de un issue con el botón reply.

Mockup

3.1.6. Commit svn al responder a un issue

El usuario modifica los atributos del issue y además realiza un commit de svn relacionado al mismo seleccionando los archivos con el boton ‘checkin code: select files’

Mockup

3.1.7. Diff svn antes de hacer commit SVN

El usuario mira el diff de sus cambios antes de realizar el commit svn. Esto se logra con hacer click en el nombre del archivo a agregar en Select files popup.

Mockup

3.1.8. Inbox de issues

El usuario mira el listado de solo los issues.

El usuario filtra el listado a solo sus issues, o todos los issues.

Mockup

3.2. Gestion

3.2.1. Crear un proyecto

3.2.2. Configurar un proyecto (parámetros de un proyecto)

3.2.3. Deshabilitar un proyecto. ( marcar como finalizado)

3.2.4. Agregar custom fields a proyecto

3.2.5. Configuracion de Servicio de cuentas de gmail, svn y jtrac

Configuración inicial de un proyecto SVN

Desde este menú se puede crear el proyecto SVN y procesar el check out en un directorio determinado.

También se puede editar o borrar el proyecto SVN creado.

Figura 1: Pantalla principal de Gestión de repositorio SVN.

Figura 2: Completar los datos requeridos para crear un proyecto SVN.

(Nombre del proyecto SVN, la dirección del SVN, el directorio donde se va a guardar el proyecto, el nombre de usuario y contraseña para SVN)

Figura 3: Luego de completar todos los datos requeridos presionar el botón ‘OK’.

Esto verifica la conexión a SVN, si falla la conexión muestra una ventana con un mensaje de error.

3.2.6. SVN checkout

Figura 4: Si la conexión a SVN se establece correctamente, entonces muestra una ventana preguntando si desea proceder al check out de este proyecto SVN. Si cancela el check out vuelve a la pantalla anterior.

Figura 5: Si acepta proceder al check out, (mientras procesa el check out) muestra una ventana donde puede cancelar este proceso. Si cancela vuelve a la pantalla anterior.

Figura 6: Luego de finalizar el check out, el proyecto queda agregado en las tablas de los proyectos SVN. Para editar o borrar, debe seleccionar un proyecto de esta tabla. Para editar el proyecto debe seguir casi el mismo proceso que crear el proyecto. Para borrar el proyecto, debe presionar el botón ‘Delete’.

Figura 7: Al presionar el botón ‘Delete’, muestra una ventana con un mensaje de advertencia. Si cancela este proceso vuelve a la pantalla anterior. Si acepta borrar el proyecto vuelve a la pantalla principal luego de borrar el proyecto.

3.2.7. SVN Update

Actualización de un proyecto SVN

Desde este menú se puede actualizar un proyecto SVN.

[Limitaciones]

* Cuando en un archivo ocurre conflicto, el programa no tendrá soluciones desde su interfaz, solamente hará una copia del archivo modificado por usuario. Es decir, el usuario debe solucionar el conflicto manualmente usando esos archivos.

Figura 1: Pantalla principal para la actualización de un proyecto SVN.

Figura 2: Seleccionar el nombre del proyecto SVN para listar los directorios, archivos y las transacciones históricas. (los archivos modificados se muestran en color verde)

Completar el número de revisión en que desea actualizar, si no se completa este campo, entonces se actualiza a la revisión más nueva disponible.

Figura 3: Presionar el botón ‘Update’, entonces muestra una ventana con detalles de actualizaciones. (los archivos en conflicto se muestran en color rojo)

3.3. Análisis

3.3.1. Búsquedas con configuración guardable

El usuario realiza una búsqueda en base al tema de conversación, texto del mensaje, destinatarios o filtrar issues por todos los campos (custom fields)

Esta configuración se guarda con un nombre y aparece como opción en el menú de la izquierda.
Mockup

Resultados

3.3.2. Dashboard

El usuario ve los charts en la pantalla de dashboard.

Mockup

4. Opciones de Implementación

4.1. Arquitectura de plataforma

Lenguaje	Java 1.6
Web Framework	GWT 1.6
Web Server	Apache Tomcat 6.0.18
ORM	Hibernate
DB	Postgresql 8.4
Middleware Framework	Spring 3.0.x
Chart Library	Open Flash Chart GWT Widget Library 1.3 (no definido)
IDE	Eclipse 3.4

widget library (Opcional)	Smart gwt
Svn api	Svnkit
Gmail api	Java mail

4.2. Sistemas a integrar

4.2.1. Gmail: servicio de cuentas de email de gmail utilizando los protocolos imap4 y pop3 para el envio/recepcion de emails respectivamente.

Ventajas: permite el manejo de los mensajes via protocolos imap4 y pop3

Desventajas: no se tiene manipulación completa del servicio. Se limita a los terminos/condiciones de uso del servicio de gmail.

4.2.2. Jtrac: issue Tracker basico desarrollado en java utilizando Spring, hibernate y Apache wicket. Provee la funcionalidad basica de un issue Tracker configurable a las exigencias del uso.

Ventajas: desarrollado bajo licencia GPL, utiliza Spring, lo que permite poder reutilizar completamente su modelo de clases, y donde podemos reemplazar su UI por una nueva hecha en GWT.

Desventajas:

4.2.3. SVN: servidor de gestion de repositorio de archivos. Permite comunicacion via protocolo http, https y svn (configurable).

Ventajas: tiene librerias que soportan un api de comunicación en java.

Desventajas:

5. Detalles de Integración de Jtrac + Gmail + SVN

5.1. Integracion Jtrac + Gmail

5.1.1. Cambios en la arquitectura de Jtrac para soportar mensajes de Gmail (No)

5.1.2. Cambios en la IU (GWT)

5.1.3. Cambios en la Persistencia (se agregan datos

5.2. Integración Jtrac + SVN

5.2.1. Cambios en la arquitectura de Jtrac para soportar commits SVN (nueva funcionalidad)

5.2.2. Cambios en la UI (GWT)

5.2.3. Cambios en la persistencia (nueva funcionalidad)

6. Detalles de Analisis del proyecto.

6.1. Datos cargados por los usuarios

6.1.1. Duración: cantidad de días estimados por el usuario para realizar la tarea

6.1.2. Prioridad: nivel de importancia para realizar la tarea

6.2. Datos obtenidos en base a historiales de cambios.

6.2.1. Duración Real: es el tiempo en días en que el dueño de la tarea abrió el issue hasta cuando lo marcó como fixed.

La duración real se obtiene desde el momento que el usuario actualiza el issue de open a fixed. Si el user pone de open a paused y de paused a open, se utiliza solo este rango (o sea si lo pospuso por un momento, esto no cuenta)

En caso de que el usuario nunca haya cambiado el estado de open a fixed, o sea, de notstarted a fixed. Se toma como la duración estimada es la correcta, si era 1 día de duración, se utiliza ese directamente (no sabemos en realidad cuanto tiempo el usuario ha trabajado en esto, pero se considera que el usuario, si es pequeño el task, lo hace en 1 hora o dos, y luego ya lo marca como completed.)

También se tienen en cuenta si el tester lo vuelve a reabrir, porque esto significa mayor tiempo sobre el desarrollo.

6.2.2. sumatoria de campo duration

6.2.3. sumatoria de tiempo desde que se abrio el issue hasta que fue arreglado

6.2.4. conteo de issues fuera del estimated duration

6.2.5. cant de horas sobrepasadas

6.2.6. conteo de issues terminados a tiempo

6.2.7. tiempo total utilizado para issues terminado a tiempo

6.2.8. numero de issues fallados / issues arreglados a tiempo

6.2.9. tiempo perdido - tiempo ganado

6.3. Datos calculados en base a métricas

6.3.1. Confiabilidad de estimativa: es la suma de todas las horas reales sobre las estimadas nos dan un % de confiabilidad del cumplimiento de estimaciones del usuario (estimated / real)

6.3.2. Tiempo de los issues abiertos sobre en la línea de tiempo(Open Issues time Over timeline): Es la cantidad de horas en issues abiertos a medida que se acerca el Release date. Si el valor es mayor al tiempo disponible para el release date, esta retrasado. Si es menor al tiempo esta adelantado (calculo en base a la duración real completada en cada issue). O sea, total completados reales – total abiertos estimados = Tiempo estimado necesitado.