Sistema de gestión de tareas y proyectos

Transcripción

1 Sistema de gestión de tareas y proyectos Propuesta de proyecto Seminario de Informática I Luis Muñoz Enrique Viard

2 Contenido Introducción... 3 Descripción general... 3 Arquitectura propuesta... 5 Requisitos... 6 Cliente y alcances... 7

3 Introducción La presente propuesta pretende crear un sistema de gestión de proyectos y tareas basado en la metodología Kanban para reemplazar el sistema actual. Éste cuenta con un pizarrón dividido en columnas y papelitos que simulan tareas distribuidos entre las distintas columnas. Descripción general Se propone crear un sistema de gestión, seguimiento de tareas y trabajo en equipo que utilice como base la metodología conocida como "Kanban" 1 creada por Toyota, que utiliza tarjetas para crear tareas que van cambiando de ubicación según su estado. 1 Kanban proviene del japonés y su traducción al español es tablero visual, donde "kan" significa "visual" y "ban" significa "tablero".

4 La metodología Kanban proviene del mundo industrial y no necesita de sistemas informáticos para funcionar. Propone la creación de un tablero dividido en estados, dónde se pegan tarjetas, estas tarjetas representan tareas, pueden ser de diferentes colores según prioridad, tienen una descripción y una persona asignada, y según la columna dónde se encuentren representa la fase en la que se encuentra. Por ejemplo, en el siguiente tablero Kanban podemos ver un caso típico donde: - En "Pendiente" tenemos una cola de tareas sin comenzar. - En "Des" están las tareas en desarrollo. - En "Probar" las que requieren pruebas de funcionamiento. - En "Entregar" las que están listas para entregar. - En "Terminado" contamos con un archivo histórico de las tareas finalizadas. - El flujo del avance de las tareas es de izquierda a derecha. El sistema propuesto intenta informatizar la metodología, adaptándose a la forma de trabajo de INVAP. Mediante esta técnica se busca principalmente: 1- Visualizar el flujo de trabajo (por proyecto, grupo de trabajo, gerencia, personas, etc.). 2- Limitar el trabajo "en proceso" de modo de maximizar la eficiencia. 3- Medir y optimizar el trabajo. 4- Organizar y facilitar la colaboración. Cada tarjeta/tarea creada tendrá asociada la siguiente información: - Estado. - Prioridad. - Dificultad. - Fecha de creación. - Fecha de vencimiento. - Tiempo consumido y desviación con el estimado. - Usuario creador. - Tareas relacionadas: correlativas y dependientes. - Usuarios asignados. - Usuarios revisores. - Documentos adjuntos. - Tiempo estimado de realización. - Gerencia a la que pertenece. - Proyecto al que pertenece. - Centro de costo asociado. - Registro de actividades realizadas. - Notas de usuarios. - Etiquetas (para facilitar la búsqueda).

5 Arquitectura propuesta Para el presente proyecto, dado que será implementado INVAP y de ser así deberá interactuar con los sistemas existentes, es necesario utilizar una arquitectura y una infraestructura digital 2 de trabajo similar a la utilizada actualmente en el área Sistemas de Información. La arquitectura utilizada actualmente es SOA (Arquitectura Orientada al Servicio) y proviene de una evolución de la arquitectura cliente/servidor. La arquitectura orientada al servicio define la utilización de servicios (comúnmente servicios web 3 ) para dar soporte a los requisitos del negocio. Estos servicios web proponen una interfaz 4 bien definida que facilita la interacción entre sistemas propios y de terceros. La interfaz encapsula (oculta) las particularidades de una implementación y permite que los servicios web sean independientes del lenguaje de programación, fabricante y tecnología de desarrollo. La arquitectura apunta a crear interfaces altamente reutilizables, ya que se crean siguiendo un estándar. Permite la creación de sistemas de información altamente escalables. Estos servicios web son del tipo REST 5 desarrollados en Java EE 6 sobre un servidor de aplicaciones Jetty 7. Utiliza: - Eclipselink 8 como implementación JPA (interfaz de persistencia). - Weld 9 como implementación CDI 10, para inyección de dependencias y gestión del ciclo de vida. - Se conecta con una base de datos Oracle Java como lenguaje de programación. - Apache Wicket 12 como framework web. Al contrario de las arquitecturas orientado a objetos, las arquitecturas SOA están formadas por servicios de aplicación débilmente acoplados y altamente interoperables. Para comunicarse entre sí, estos servicios se basan en una definición formal independiente de la 13 plataforma subyacente y del lenguaje de programación (p.ej., WSDL ). Los beneficios que puede obtener una organización que adopte SOA son: 2 Proviene de su nombre en inglés "Framework". Propone un marco de trabajo con módulos de software concretos que ayudan al desarrollo de una nueva aplicación. 3 Los servicios web comprenden un conjunto de protocolos y estándares para intercambiar datos entre aplicaciones. 4 Contrato o conjunto de operaciones a respetar por quien la utilice. Es la mayor abstracción en la etapa de diseño. 5 Representational State Transfer. Recursos con representación única (URL) y métodos estándar (HTTP). 6 (EE: Edicion empresarial). Plataforma de programación para lenguaje Java con arquitectura de N capas distribuidas. 7 Servidor HTTP basado 100% en Java. 8 Es un servidor de persistencia para servicios de datos como bases de datos y servicios web. 9 Es un tipo de implementación para la especificación de requerimientos de Java. 10 Manejador de inyecciones y de contexto de ciclo de vida de los objetos. 11 Sistema de gestión de base de datos objeto-relacional desarrollado por Oracle Corporation. 12 Es un framework de desarrollo de aplicaciones web para la plataforma Java. 13 Lenguaje de descripción de servicios. Es utilizado para describir los servicios web.

6 Mejora en los tiempos de realización de cambios en procesos. Facilidad para abordar modelos de negocios basados en colaboración con otros entes (socios, proveedores). Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción en el proceso de negocio. Facilidad para la integración de tecnologías disímiles. Requisitos El sistema deberá proporcionar las siguientes funcionalidades mediante un entorno web: Administración de usuarios: o (con roles y permisos, gerencia y área a la que pertenece). o Según el proyecto podrán crear tareas, y/o podrán modificarlas, asignarlas, aprobarlas o archivarlas. Administración de áreas. Administración de proyectos. o Cada proyecto pertenece a un PT, una gerencia. o Tendrá usuarios asignados con sus roles específicos. Administración de tareas. o Cada tarea tendrá una descripción. o Cada tarea tendrá una prioridad numérica del 1 al 10. o Pertenecerán a áreas / proyectos. o Podrán tener usuarios asignados. o Tendrán un estado actual, operando en el tablero Kanban virtual mediante drag & drop 14 los usuarios que tengan permiso podrán cambiarlas de fase. o Se las podrá marcar como bloqueadas (Cuando haga falta finalizar otra tarea para poder continuar con la primera). o Se podrá crear tareas dependientes, es decir tareas que dependan de otra para su ejecución y se encuentran bloqueadas hasta tanto la otra se finalice. o Se podrán ajuntar archivos. o Se podrán agregar notas. o Cada tarea tendrá un registro de actividad. o Cada tarea tendrá un tiempo estimado, un tiempo efectivo, una fecha inicial y una fecha límite. o Cada tarea podrá avisar mediante el envío de una notificación por correo electrónico de los cambios de estado a los usuarios que así lo requieran. o Al asignarse una tarea a un usuario, se le enviará una notificación informándole. o Se podrán combinar varias tareas en una sola o dividir una tarea en varias. o Se podrán crear subtareas dentro de una tarea. o Cada tarea tendrá un usuario asignado y un revisor encargado de hacer el seguimiento. o Se mostrará la cantidad de días que tiene una tarea dentro de un estado. o Se mostrará la cantidad de días que faltan o pasaron para/desde el vencimiento. 14 Arrastrar y mover de un lado al otro un elemento. En este caso se refiere a las tarjetas (tareas) del tablero.

7 El tablero Kanban contará con un estado inicial (backlog 15 ), un estado final (archivo) y estados intermedios configurables. Creación de API 16 utilizando servicios web que permita al menos la creación de tareas y la consulta del estado de las mismas a través de consultas mediante un explorador web. Cliente y alcances El cliente del proyecto es la división de Software de INVAP S.E. Gustavo Perez (responsable división de Software) designó a Ezequiel Barbarito y Gustavo Fabbri (pertenecientes a la división de Software) como clientes del proyecto. El alcance del proyecto es el desarrollo, implementación e integración del sistema con las demás aplicaciones que se encuentran actualmente en funcionamiento y utilizando los servicios web. 15 Estado donde se sitúan todas las tareas ni bien son ingresadas al sistema. 16 Especificaciones para ser usadas como interfaz por componentes de software para poder comunicarse con otros.