Tesis de Master Desarrollo de un módulo para la gestión gráfica de workflows para procesos software Javier Casal Ruiz Índice Capítulo 1 Introducción y motivación 1.1 – Introducción 1.2 – Objetivo 1.3 - Motivación 1.4 - Estructura 5 5 6 6 Capítulo 2 Workflows 2.1 – Introducción 2.1 – Workflow 2.3 – BPMN 2.3.1 – Introducción 2.3.2 – Fundamentos 2.3.2.1 – Objetos de flujo 2.3.2.2 – Objetos conectores 2.3.2.3 -Swimlanes 2.3.2.4 - Artefactos 2.3.3 – Uso general de BPMN 2.3.4 – Diferentes niveles de precisión 2.3.5 – Valor de modelar en BPMN 2.3.6 – Mapear un diagrama BPMN a BPEL4WS 2.1.7 – Futuro de BPMN 2.4 – Herramientas 21 21 21 21 21 21 21 21 21 24 24 24 24 24 21 Capítulo 3 Workflows para el proceso de desarrollo de software 3.1 – Introducción 3.2 – Introducción a TuneUp 3.3 – TuneUp Process Tool 6 6 6 Capítulo 4 Librerías para desarrollo de editores gráficos 4.1 – Comparativa de componentes de diagramas 4.2 – Componentes a comparar 4.2.1 – AddFlow for .NET 4.2.2 – Syncfusion Essential Diagram 6 6 6 6 4.2.3 – Nevron Diagram 4.2.4 – GoDiagram 4.2.5 – Netron 4.2.6 – Open Diagram 4.2.7 – yFiles 4.3 – Conclusiones 6 6 6 6 6 6 Capítulo 5 Módulo para especificación de Workflows 5.1 – Descripción del sistema actual 5.2 – Arquitectura propuesta 5.3 – Pruebas de aceptación 6 6 6 Capítulo 6 Resultados de la implantación del módulo 6.1 – Introducción Anexo – Bibliografía 6 216 Capítulo 1: Introducción 1.1 Introducción En este apartado se resume el objetivo principal de la tesis, la motivación de la misma y la estructura que contiene esta memoria. Esta tesis se ha llevado a cabo en colaboración con una empresa dedicada al desarrollo de software, bajo la tutela y supervisión del profesorado de la Escuela Técnica Superior de Informática Aplicada. El presente documento pretende realizar una descripción del problema a resolver propuesto por la empresa. Esta empresa utiliza un software de gestión de proyectos implementado por la propia empresa de tipo Win32, desarrollado en la plataforma .NET con el lenguaje C#. Como motor de base de datos utiliza Microsoft SQL Server. La aplicación se rige por un motor de workflows que se encarga de coordinar las distintas actividades, incidencias y programadores. En este momento la definición de los distintos workflows en el sistema se hace manualmente sobre las tablas de la base de datos. La realización de una aplicación que gestione y edite de forma visual los workflows es el problema a abordar por la presente tesis. 1.2 Objetivo Esta empresa utiliza un software de gestión de proyectos implementado por la propia empresa de tipo Win32, desarrollado en la plataforma .NET con el lenguaje C#. Como motor de base de datos utiliza Microsoft SQL Server. 1.3 Motivación En este apartado se resume el objetivo principal de la tesis, la motivación de la misma y la estructura que contiene esta memoria. 1.4 Estructura En este apartado se resume el objetivo principal de la tesis, la motivación de la misma y la estructura que contiene esta memoria. Capítulo 2: Workflows 2.1 Introducción Un proceso de negocio es un conjunto de tareas lógicamente relacionadas, ejecutadas para obtener un resultado de negocio. Los procesos de negocio pueden ser controlados y administrados por un sistema basado en software. Los procesos de negocio automatizados de esta manera se denominan workflow. Esta automatización resulta en una importante potenciación de las virtudes de dicho proceso. Se obtienen mejoras en cuanto a rendimiento, eficiencia y productividad de la organización. El caso particular de la industria del desarrollo de software, no es diferente al del resto de las industrias. Dentro de ella, se encuentran los procesos de negocios tendientes a la construcción o generación de un producto (software) de calidad en un tiempo determinado. El proceso de negocio más importante dentro de la industria de desarrollo de software es conocido como “metodologías de desarrollo”, encargadas de guiar la producción. Este trabajo aporta a la optimización del proceso de producción de software mediante la automatización de las metodologías de desarrollo. Para esto se trabajo sobre la hipótesis de que el proceso de desarrollo de software es un tipo de proceso de negocio particular, y los procesos de negocio pueden ser automatizados en todo o en parte a través de un motor de workflow, el objetivo es transformar el proceso de desarrollo de software en un proceso de un workflow para poder lograr su automatización en todo o en parte. El paradigma workflow ofrece interoperabilidad con otros sistemas, ejecución en ambientes distribuidos, facilidades para el monitoreo y manejo de recursos humanos. 2.2 Workflow Un workflow se define como la automatización total o parcial de un proceso de negocio, durante la cual documentos, información o tareas son intercambiadas entre los participantes conforme a un conjunto de reglas procedimentales preestablecidas. Un workflow comprende un número de pasos lógicos, conocidos como actividades. Una actividad puede involucrar la interacción manual o automática con el usuario. Un motor workflow es un sistema de software que controla la ejecución de las actividades definidas en el workflow. La WfMC ha definido un Modelo de Referencia Workflow (Workflow Reference Model). Este modelo define 5 interfaces para la interoperabilidad de diferentes productos con un motor workflow. La interfaz 1 especifica el formato de intercambio común para soportar la transferencia de definiciones de procesos entre productos diferentes, utilizando un lenguaje de definición de procesos como el XML Process Definition Language (XPDL) definido por la WfMC o el Business Process Execution Language for Web Services (BPEL4WS) adoptado por OASIS. XPDL permite escribir especificaciones de procesos workflow de manera estandarizada. Esto significa que cualquier definición de proceso que cumpla con todos los requisitos establecidos en la interfaz 1 podrá ser tomada como entrada por cualquier motor workflow que respete el estándar establecido por la WfMC, por ejemplo OFBiz Workflow Engine o Open Business Engine. BPEL4WS es un lenguaje para la especificación de procesos de negocio, el cual permite especificar procesos de negocio basados en servicios Web, esto es, que sólo pueden importar y exportar funcionalidad mediante servicios Web. La especificación inicial (BPEL4WS 1.0) fue desarrollada por IBM, Microsoft y BEA. WebSphere Process Server de IBM y BPEL Process Manager de Oracle son ejemplos de motores de workflow que implementan BPEL4WS. Es importante a la hora de modelar un proceso de negocio poder utilizar una herramienta independiente de la implementación, así, de esta manera, poder utilizar la especificación del proceso de negocio para diferentes plataformas. Una herramienta de estas características que esta siendo muy utilizada por grandes empresas es BPMN. La OMG junto con la Bussines Process Modeling Initiative(BPMI) han desarrollado una notación para el modelado de procesos de negocio. Esta notación se denomina Bussines Process Modeling Notation(BPMN). BPMN define una notación para la definición de procesos de negocio, lo que es una plataforma independiente con respecto a definiciones específicas (por ejemplo XPDL o BPEL4WS) de procesos de negocio. Esta notación define una representación abstracta para la especificación de procesos ejecutables de negocio que se ejecutan dentro de una empresa (con o sin intervención humana); y puede colaborar con otro proceso de negocio independiente ejecutado en otra unidad de negocio o empresa. Partiendo de un modelo especificado en BPMN se puede obtener, mediante un mapping, la definición de un proceso de negocio en un lenguaje especifico como ser XPDL o BPEL4WS. En está definido el mapping de BPMN a BPEL4WS. Los elementos de la notación se pueden clasificar en elementos de flujo, de conexión, swinlanes y artefactos. Estos elementos que forman parte de la notación están especificados en el metamodelo BPMN. Este metamodelo está definido en el nivel M2 de la OMG y está basado en MOF. 2.3 BPMN 2.3.1 Introducción Business Process Modeling Notation (BPMN) es una notación estándar desarrollada por la Business Process Management Initiative (BPMI). La especificación de la versión 1.0 salió al público en mayo del 2004. El objetivo principal de los esfuerzos de BPMN es dar una notación rápidamente comprensible por toda persona implicada en un proyecto, independientemente de su preparación. Desde el analista de negocio que hace el borrador inicial de los procesos, pasando por los desarrolladores técnicos responsables de implementar la tecnología que llevarán a cabo dichos procesos, llegando finalmente al cliente del negocio que gestionará y monitorizará esos procesos. Además, BPMN está apoyado en un modelo interno que genera el ejecutable BPEL4WS. Así, BPMN crea un puente estandarizado para el hueco entre el diseño de los procesos de negocio y la implementación de procesos. BPMN define el Business Process Diagram (BPD), que se basa en una técnica de grafos de flujo para crear modelos gráficos de operaciones de procesos de negocio. Un modelo de procesos de negocio, es una red de objetos gráficos, que son actividades (trabajo) y controles de flujo que definen su orden de rendimiento. 2.3.2 Fundamentos Un BPD está formado por un conjunto de elementos gráficos. Estos elementos habilitan el fácil desarrollo de diagramas simples que serán familiares para la mayoría de analistas de negocio (diagrama de flujo). Los elementos fueron elegidos para ser distinguibles los unos de los otros y para usar formas familiares para la mayoría de modeladores. Por ejemplo, las actividades son rectángulos y las decisiones son diamantes. Debe notarse que uno de los objetivos del desarrollo de BPMN es crear un mecanismo simple para crear modelos de procesos de negocio, y al mismo tiempo que sea posible gestionar la complejidad inherente en dichos procesos. El método elegido para manejar estos dos conflictivos requisitos fue organizar los aspectos gráficos de la notación en categorías específicas. Esto da un pequeño grupo categorías que alguien que lea un BPD pueda reconocer fácilmente los tipos básicos de elementos y pueda entender el diagrama. Dentro de las categorías básicas de elementos, se puede añadir información y variaciones adicionales para dar soporte a los requerimientos complejos sin cambiar dramáticamente el look-and-feel básico del diagrama. Las cuatro categorías básicas de elementos son: Objetos de flujo Objetos conectores Artefactos Swimlanes 2.3.2.1 Objetos de flujo Un BPD es un pequeño conjunto (tres) de elementos básicos, que son los Objetos de Flujo, de modo que los modeladores no tienen que aprender y reconocer un gran número de formas diferentes. Los tres objetos de flujo son: Evento: un evento se representa con un círculo. Es algo que ocurre durante el curso del proceso de negocio. Estos eventos afectan al flujo del proceso y suelen tener una causa (trigger) o un impacto (resultado). Los eventos representados con un círculo con centro abierto permiten a los marcadores internos diferenciar diferentes triggers y resultados. Hay tres tipos de eventos, basados en cuando afectan al flujo: Start, Intermediate, y End. Start Event Intermediate Event End Event Actividad: una actividad se representa con un rectángulo redondeado y es un término genérico para el trabajo que hace una compañía. Una actividad puede ser atómica o compuesta. Los tipos que hay son: Task y Sub-Process. El Sub-Process se distingue por una pequeña marca de suma en la parte central inferior de la figura. Gateway (compuerta): una gateway se representa por la típica figura de diamante y se usa para controlar la divergencia o convergencia de la secuencia de flujo. Así, esto determina las tradicionales decisiones, así como la creación de nuevos caminos, la fusión de estos o la unión. Los marcadores internos indicarán el tipo de control de comportamiento. 2.3.2.2 Objetos conectores Los objetos de flujo se conectan entre ellos en un diagrama para crear el esqueleto básico de la estructura de un proceso de negocio. Hay tres objetos conectores que hacen esta función. Estos conectores son: Sequence Flow: el flujo de secuencia se representa por una linea sólida con una cabeza de flecha sólida y se usa para mostrar el orden (la secuencia) en el que las diferentes actividades se ejecutarán en el Proceso. El término “control flow” normalmente no se usa en BPMN. Message Flow: el flujo de mensaje se representa por un linea discontinua con una punta de flecha hueca y se usa para mostrar el flujo de mensajes entre dos participantes del proceso separados (entidades de negocio o roles de negocio). En BPMN, dos pools separadas en el diagrama representan los dos participantes. Association: una asociación se representa por una línea de puntos con una punta de flecha de líneas y se usa para asociar datos, texto, y otros artefactos con los objetos de flujo. Las asociaciones se usan para mostrar entradas y salidas de las actividades. Para los modeladores que requieren o desean más precisión para crear modelos de proceso por motivos de documentación y comunicación, los elementos básicos más los conectores dan la posibilidad de crear fácilmente diagramas comprensibles. Para los diseñadores que necesiten un nivel más alto de precisión, para análisis detallado o que sean manejados por un Business Process Management System (BPMS), existen detalles adicionales que se pueden añadir a los elementos básicos. 2.3.2.3 Swimlanes (canales) Muchas metodologías de modelado de procesos usan el concepto de swimlanes como un mecanismo para organizar actividades en categorías separadas visualmente para ilustrar diferentes capacidades funcionales o responsabilidades. BPMN soporta los swimlanes con dos constructores principales. Los dos tipos de objetos swimlanes son: Pool: una pool representa un Participante de un Proceso. Además actúa como un contenedor gráfico para particionar un conjunto de actividades desde otros pools, normalmente en el contexto de B2B. Lane: una lane es una sub-partición dentro de un pool y extiende la longitud del pool, verticalmente u horizontalmente. Las lanes se usan para organizar y categorizar actividades. Las pools se usan cuando un diagrama implica dos entidades de negocio o participantes separados y están físicamente separados en el diagrama. Las actividades dentro de pools separadas se consideran procesos autocontenidos. Así, el flujo de secuencia no debe cruzar el límite de un pool. El flujo de mensajes se define como el mecanismo para mostrar las comunicaciones entre dos participantes, y, de este modo debe conectar dos pools (o los objetos dentro de las pools). Las pistas (lanes) están más estrechamente relacionadas con las metodologías tradicionales de las swimlanes. Las pistas se suelen usar para separar las actividades asociadas con la función o rol de una compañía específica. El flujo de secuencia puede cruzar los límites de las pistas dentro de un pool, pero el flujo de mensajes no puede ser usado entre objetos de flujo en pistas de mismo pool. 2.3.2.4 Artefactos BPMN fue diseñado para permitir a los modeladores y las herramientas de modelado un poco de flexibilidad a la hora de extender la notación básica y a la hora de habilitar un contexto apropiado adicional según una situación específica, como para un mercado vertical (por ejemplo, seguros o banca). Se puede añadir cualquier número de artefactos a un diagrama como sea apropiado para un contexto de proceso de negocio específico. La versión actual de la especificación de BPMN sólo tiene tres tipos de artefactos BPD predefinidos, los cuales son: Data Object: los objetos de datos son un mecanismo para mostrar como los datos son requeridos o producidos por las actividades. Están conectados a las actividades a través de asociaciones. Group: un grupo es representado por un rectángulo redondeado con línea discontinua. El agrupamiento se puede usar documentación o análisis, pero no afecta al flujo de secuencia. Annotation: las anotaciones son mecanismos para que un modelador pueda dar información textual adicional. Los modeladores pueden crear sus propios tipos de artefactos, que añaden más detalle sobre cómo se ejecuta el proceso – bastante a menudo para mostrar las entradas y las salidas de las actividades del Proceso. Sin embargo, la estructura básica del proceso, determinada por las actividades, gateways, y flujos de secuencia, no se cambia por añadir artefactos al diagrama. 2.3.3 Uso general de BPMN El modelado de procesos de negocio se usa para comunicar una amplia variedad de información a diferentes audiencias. BPMN está diseñado para cubrir muchos tipos de modelados y para permitir la creación de segmentos de proceso así como procesos de negocio end-to-end, con diferentes niveles de fidelidad. Dentro de la variedad de objetivos de modelado de procesos, hay dos tipos de modelos básicos que se pueden crear con un BPD: Procesos B2B colaborativos (públicos) Procesos de negocio internos (privados) 2.3.3.1 Procesos B2B colaborativos Un proceso B2B colaborativo ilustra las interacciones entre dos o más entidades de negocio. Los diagramas para estos tipos de procesos están generalmente desde un punto de vista global. Esto es, no toman la visión de un participante en particular, pero muestra las interacciones entre los participantes. Las interacciones están ilustradas como una secuencia de actividades y los patrones de intercambio de mensajes entre participantes. Las actividades para los participantes son los “touch-points” entre participantes; el proceso define las interacciones que son visibles al público para cada participante. Cuando miramos un proceso en un solo Pool (por ejemplo, para un participante), un proceso público también se llama proceso abstracto. Los procesos reales (internos) son como tener más actividades y detalle que lo que se enseña en los procesos B2B colaborativos. 2.3.3.2 Procesos de negocio internos Un proceso de negocio interno se enfocará generalmente en el punto de vista de una única organización de negocio. Aunque los procesos internos suelen mostrar interacciones con participantes externos, definen las actividades que generalmente no están visibles para el público, esto es, privadas. Si se usan swimlanes entonces un proceso interno estará contenido dentro de un solo Pool. El flujo de secuencia del proceso está por lo tanto contenido dentro de un Pool y no puede cruzar los límites del Pool. El flujo de mensajes puede cruzar los límites del Pool para mostrar las interacciones que existen entre procesos de negocios internos separados. Así, un solo diagrama de procesos de negocio puede mostrar múltiples procesos de negocio privados. 2.3.4 Diferentes niveles de precisión El modelado de procesos de negocio suele empezar capturando actividades de alto nivel para luego ir bajando de nivel de detalle dentro de diferentes diagramas. Pueden haber múltiples niveles de diagramas, dependiendo de la metodología usada para desarrollar los modelos. De todas formas, BPMN es independiente de cualquier metodología. A continuación tenemos un ejemplo de procesos de alto nivel, capturados para un caso de estudio de BPMN. Se trata de una serie de sub procesos con tres puntos de decisión A continuación se baja de nivel para mostrar en detalle el primer sub proceso: dos pools, una para los clientes y otra para la compañía suministradora Este diagrama muestra un proceso de negocio interno para la compañía y un proceso abstracto para el cliente. Las actividades de la compañía están particionadas con pistas o lanes para mostrar los roles/departamentos responsables de su rendimiento. 2.3.5 Valor de modelar en BPMN Los miembros del BPMI Notation Working Group representan un gran segmento de la comunidad de modelado de procesos de negocio y han llegado a un consenso y presentan BPMN como la notación de modelado de procesos de negocio estándar. El desarrollo de BPMN es un paso importante para reducir la fragmentación que existe con la gran cantidad de herramientas de modelado de procesos y notaciones. El BPMI Notation Working Group tienen una gran experiencia con muchas de las notaciones existentes y trabajan para consolidar las mejores ideas de todas estas notaciones para crear una sola notación estándar. Ejemplos de otras notaciones o metodologías que fueron revisadas son: diagramas de actividades de UML, UML EDOC Business Processes, IDEF, ebXML BPSS, Diagrama de flujo de actividades-decisiones (ADF), RosettaNet, LOVeM, Cadenas de Eventos-Procesos (EPCs). Una única notación bien definida reduce la confusión entre los usuarios IT y de negocios. Otro factor del desarrollo de BPMN es que, históricamente, los modelos de procesos de negocio desarrollados por la gente de negocios han estado técnicamente separados de las representaciones de procesos requeridas por los sistemas diseñados para implementar y ejecutar dichos procesos. Así, era necesario traducir manualmente los modelos de procesos de negocio originales a los modelos de ejecución. Esas traducciones están sujetas a errores y dificultan a los dueños del proceso entender la evolución y el rendimiento de los procesos desarrollados. 2.3.6 Mapear un diagrama BPMN a BPEL4WS Para ayudar a aliviar el vacío técnico de modelado, un objetivo clave para el desarrollo de BPMN era crear un puente entre la notación de modelado de procesos de negocios y los lenguajes de ejecución respecto a las Tecnologías de la Información que implementan los procesos que hay dentro de un sistema. Los objetos gráficos de BPMN, más un buen número de atributos de estos objetos, se han mapeado al Business Process Execution Language para Web Services (BPEL4WS v1.1), el estándar de facto para la ejecución de procesos. A continuación tenemos un segmento de un proceso de negocio que marca el mapeo con BPEL4WS. 2.3.7 El futuro de BPMN Aunque la especificación de BPMN se encuentra en su versión 1.1, muchas compañías la soportan e implementan dicha especificación. El futuro inmediato dará un punto de experiencia entre usuarios y vendedores que permitirá, mediante feedback, afinar detalles de la especificación, en concreto con BPEL4WS. En las siguientes versiones de mantenimiento es de esperar un esfuerzo en estandarización de los artefactos para que soporten modelado de negocios generales y dominios de negocios verticales (seguros, manufacturación, finanzas). Además, se está intentando encajar BPMN en un mayor contexto de modelado de negocios de alto nivel (incluyendo reglas de negocio y estrategias de negocio). Capítulo 3: Workflows para el proceso de desarrollo de software 3.1 Introducción En la última década hemos visto un creciente interés por metodologías y estándares asociados a procesos de producción de software. El modelo de referencia CMMI (Capability Maturity Model Integrated, 2009) y los estándares SPICE (ISO, 1998) e ISO 90003 (ISO, 2004) han logrado reconocimiento y atraído el interés de empresas desarrolladoras de software. Metodologías Ágiles (p.ej. XP (Beck, 2000), Scrum (Schwaber y Beedle, 2001)), Tradicionales (p.ej. RUP (Kroll et al., 2003), Métrica 3 (MAP, 2005)) han animado una interesante discusión respecto de las estrategias para desarrollar software y su efectividad en diferentes contextos. Un proyecto de desarrollo o mantenimiento de software conlleva todas las dificultades de cualquier proyecto, pero además incluye otras derivadas de su naturaleza; los desafíos asociados a nuevas tecnologías (que conllevan falta de experiencia en su utilización), cambios en los objetivos y requisitos durante la realización del proyecto (para adecuarlos a la oportunidad de mercado y estrategias del cliente), y estrecha colaboración entre los participantes del proyecto. Por otra parte, cada vez se exigen plazos de entrega más cortos y presupuestos más ajustados, conservando altas exigencias en cuanto a calidad. Las técnicas y herramientas genéricas para planificación y seguimiento de proyectos resultan claramente ineficaces para enfrentar los desafíos comentados antes. Las metodologías ágiles destacan esta situación pero la resuelven de una manera excesivamente simplista, utilizando roles muy genéricos (reduciendo así la comunicación necesaria entre diferentes roles) y confiando en la habilidad de cada uno de los miembros del equipo para que, verbalmente y/o con soportes no informatizados, realicen el seguimiento del proyecto. Por otra parte, las herramientas tradicionales usadas para planificación de proyectos y la guía PMBOK (Project Management Book of Knowledge) (PMI, 2008) no ofrecen pautas ni soporte específico para la gestión de un proyecto cuando se sigue un proceso iterativo e incremental. TUNE-UP es una metodología desarrollada en el trabajo día a día en una PYME de desarrollo de software y con una vocación de mejora continua del proceso. En tres años de aplicación y refinamiento TUNE-UP ha conseguido una madurez suficiente para ser presentada como una alternativa interesante, al menos en contextos de desarrollo con equipos pequeños. TUNE-UP incorpora elementos de metodologías ágiles y también del ámbito más tradicional. TUNE-UP se inspira en la esencia de PSP (Personal Software Process) (Watts, 2001), donde se destaca que la base del éxito radica en una disciplina de trabajo y productividad individual centrada en la gestión de los compromisos. TUNE-UP ayuda en cada momento del proyecto a responder a la pregunta: ¿conseguiré cumplir con los plazos de entrega de mis tareas? o ¿seremos capaces de cumplir con los plazos de entrega al cliente? Estas simples preguntas inquietan a cualquier gestor o participante de un proyecto. No contar con una respuesta acertada, y sobre todo oportuna, conlleva en la mayoría de los casos graves complicaciones en el proyecto. El objetivo de este trabajo es ilustrar cómo TUNE-UP permite abordar de forma pragmática la gestión de proyectos de desarrollo y mantenimiento de software. En la sección siguiente se describe brevemente la metodología TUNE-UP. En la sección 3 se presenta TUNE-UP Process Tool, una herramienta de apoyo a la metodología. 3.2 Introducción a TUNE-UP Un proyecto de desarrollo o mantenimiento de software tiene por objetivo el conseguir una entrega del producto, es decir, una versión operacional que puede explotar el cliente. En un proceso iterativo e incremental el trabajo asociado a una entrega del producto se divide en varias versiones (resultantes de cada iteración) siendo la última aquella que coincide con la entrega del producto. TUNE-UP se caracteriza fundamentalmente por combinar los siguientes elementos: Modelo de proceso iterativo e incremental para el desarrollo y mantenimiento del software. El trabajo se divide en unidades de trabajo que son asignadas a versiones. Las versiones son frecuentes y de corta duración, entre 3 y 6 semanas dependiendo del producto. Proceso de desarrollo dirigido por las pruebas (Test-Driven). La definición de una unidad de trabajo es básicamente la especificación de sus pruebas de aceptación acordadas con el cliente. A partir de allí, todo el proceso gira en torno a ellas, se estima el esfuerzo de implementar el comportamiento asociado y de aplicar las pruebas, se diseñan las pruebas e implementa dicho comportamiento, y finalmente, se aplican las pruebas sobre el producto para garantizar su correcta implementación. Workflows flexibles para la coordinación del trabajo asociado a cada unidad de trabajo. Los productos, según sus características, tienen asociados un conjunto de workflows que son utilizados para realizar cada unidad de trabajo. Cada unidad de trabajo sigue el flujo de actividades del workflow. Bajo ciertas condiciones se permite saltar hacia adelante o hacia atrás en el workflow, así como cambios de agentes asignados e incluso cambio de workflow. Por ejemplo, las típicas situaciones de re-trabajo en desarrollo de software ocasionadas por detección de defectos se abordan con saltos atrás no explícitos en el workflow. Planificación y seguimiento continuo. En todo momento debe estar actualizado el estado de las versiones, de las unidades de trabajo, y del trabajo asignado a los agentes. El jefe del proyecto puede actuar oportunamente con dicha información, tomando decisiones tales como: redistribuir carga de trabajo entre agentes, cambiar los plazos de la versión, mover unidades de trabajo entre versiones, etc. Control de tiempos. Los agentes registran el tiempo que dedican a la realización de las actividades, el cual se compara con los tiempos estimados en cada una de ellas, detectando oportunamente desviaciones significativas. Esto permite a los agentes gestionar más efectivamente su tiempo, mejorar sus estimaciones y ofrecer al jefe del proyecto información actualizada del estado de la versión. TUNE-UP es una metodología que incorpora aspectos de metodologías ágiles y de metodologías tradicionales. Las dos primeras características (proceso iterativo e incremental, y proceso centrado en las pruebas de aceptación) clasifican a TUNE-UP como metodología ágil, sin embargo, las otras características están más próximas de lo que sería una metodología tradicional. Figura 1. Un workflow de desarrollo simple para unidades de trabajo La Figura 1 ilustra un workflow mínimo para el desarrollo de una unidad de trabajo. Un workflow, en general, incluye actividades asociadas a tres fases: Pre-Asignación: actividades hasta la asignación de los RRHH y versión. La unidad de trabajo ha sido identificada pero aún no tiene una prioridad como para asignarle RRHH y versión. Preparación: la unidad de trabajo ha alcanzado cierta prioridad y se le han asignado RRHH y versión, se comienza a trabajar en su preparación y ésta debería concluirse antes del inicio de la versión objetivo en la cual se implementará. Incluye el análisis, las revisiones y estimaciones para su implementación. Implementación: se realizan durante la versión objetivo. Incluye la implementación y aplicación de pruebas de la unidad de trabajo. Las actividades de cada workflow pueden variar significativamente dependiendo de factores tales como: cantidad y especialización de agentes participantes, validaciones o negociaciones predeterminadas con el cliente, características del producto (necesidad de migración, traducción, etc.), niveles y actividades de pruebas (unitarias, de integración, de aceptación, pruebas de regresión, automatización de pruebas), etc. Cada unidad de trabajo en una versión podría tener su propio workflow. Desde el punto de vista del agente responsable, el estado en el que se puede encontrar una unidad de trabajo asociada a la actividad que debe realizar puede ser: Por Llegar: el agente está asignado a la actividad pero aún no ha recibido la unidad de trabajo pues está en alguna actividad anterior en el workflow. Pendiente: el agente ha recibido la unidad de trabajo en la actividad pero aún no ha comenzado a trabajar en ella. Activa: el agente está trabajando en la actividad (y el sistema está registrando tiempo dedicado a ella). Pausada: el agente ha interrumpido su trabajo en la actividad (y se ha detenido el registro de tiempo. Finalizada: el agente ha terminado la actividad (la unidad de trabajo ha pasado automáticamente a las actividades siguientes en el workflow asociado). Omitida: la actividad ha sido omitida, es decir, se ha decidido no realizarla (se ha saltado hacia adelante en el workflow). A menos que la unidad de trabajo dé un salto hacia atrás, la unidad de trabajo no pasará por la actividad. La Figura 2 muestra los cambios de estados posibles de una unidad de trabajo en una actividad. Salto hacia adelante sin haber sido finalizada antes Asignación al agente Omitida Por Llegar Finalización de actividad previa Comenzar Se produce salto atrás hacia actividad previa Pendiente Finalizar Se produce salto atrás hacia actividad previa Continuar Activa Salto hacia adelante habiendo sido finalizada antes Pausada Pausar Finalizar Finalizada Figura 2. Posibles estados de una unidad de trabajo en una actividad 3.3 TUNE-UP Process Tool TUNE-UP Process Tool es una herramienta de apoyo para la aplicación efectiva de la metodología TUNE-UP. La herramienta está formada por tres módulos principales: Planificador Personal, Gestor de Unidades de Trabajo, y Planificador de Versiones. A continuación se describe cada uno de estos módulos. El Planificador Personal (PP) presenta el trabajo que tiene un agente. Cuando un agente inicia su jornada laboral, accede al PP (Figura 3) para ver el trabajo que tiene asignado actualmente, y seleccionar qué va a realizar. Un aspecto clave para el proyecto es que los agentes se dediquen a las actividades acertadas de acuerdo a sus prioridades. El PP ofrece una variedad de facilidades de filtrado y ordenamiento de información, además de datos de tiempos, para que el agente pueda determinar las prioridades de su trabajo y facilitar su elección. La tabla de la izquierda de la Figura 3 resume las contabilizaciones de las unidades de trabajo según la actividad y estado en el que se encuentran, y la tabla de la derecha, muestra información de dichas unidades de trabajo incluyendo: producto, versión, descripción de la unidad de trabajo, tiempos calculados, estado de la actividad actual dentro del workflow, etc. Con los tiempos calculados el agente puede conocer el tiempo que lleva registrado en cada actividad (T.Real), los tiempos que ha estimado (T.Est y T.Est.A, estimado y estimado ajustado), el porcentaje completado con respecto el estimado (%Com.) y las horas restantes (H. Res) que le quedan para finalizar la actividad. En la Figura 3, al seleccionar una celda de la tabla de la izquierda, se muestran las respectivas unidades de trabajo en la tabla de la derecha. Figura 3. Fragmento de interfaz del Planificador Personal Cuando el agente decide la actividad y la unidad de trabajo que va a realizar, accede con ella al Gestor de Unidades de Trabajo (GUT) (ver Figura 4) como apoyo esencial para realizar su tarea. En la parte superior de la Figura 4 se observan los datos generales de la unidad de trabajo, y en la parte inferior, un conjunto de pestañas con la funcionalidad que ofrece el GUT. En la pestaña Seguimiento (Figura 4) se observa el conjunto de actividades del workflow por las que ha pasado la unidad de trabajo. Cada actividad está asociada a un registro de seguimiento que incluye la actividad, el agente que la desarrolla, el estado en el que se encuentra, veces que se ha realizado la actividad (indicación del retrabajo), etc. En esta pestaña además, con los botones Empezar/Pausar/Continuar (es el mismo botón que cambia de nombre según el estado de la actividad) y Finalizar Actividad, el agente puede controlar el registro de tiempo, activando, pausando o finalizando la actividad. Al finalizar una actividad, la unidad de trabajo pasa automáticamente a la siguiente actividad del workflow. El motor de workflows que incorpora TUNE-UP Process Tool permite realizar saltos a cualquier actividad del workflow, y soporta el paralelismo, secuenciación y bifurcación de las actividades. Figura 4. Gestor de Unidades de Trabajo – Pestaña Seguimiento La pestaña Tiempos (Figura 5) ofrece funcionalidad específica de tiempos para la unidad de trabajo. En la parte superior los agentes establecen las estimaciones de las actividades que van a desarrollar. En la tabla inferior se muestran todos los registros de tiempo producidos automáticamente por los pares de acciones Comenzar/Continuar – Pausar/Finalizar, correspondientes a las actividades ejecutadas en la unidad de trabajo. Tanto en las estimaciones como en los registros de tiempo el agente puede realizar ajustes cuando, por ejemplo, prevea que la estimación no se va a cumplir, o cuando haya olvidado Activar, Pausar o Finalizar la actividad. Figura 5. Gestor de Unidades de Trabajo – Pestaña Tiempos La Pestaña Documentación (Figura 6) incluye una biblioteca de documentos (especificaciones y material complementario) compartida entre los agentes que trabajan con la unidad de trabajo. En ella se ofrecen plantillas específicas y facilidades para llevar un control de versiones de los documentos. Figura 6. Gestor de Unidades de Trabajo – Pestaña Documentación El Gestor de Unidades de Trabajo ofrece además otras pestañas entre las que destacan: Peticiones (mecanismo sencillo de comunicación entre los agentes para comentar respecto de la unidad de trabajo), Relaciones (relaciones de dependencia de la unidad de trabajo con respecto de otras) y Planificación (asignación de agentes a actividades de la unidad de trabajo y asignación a una versión). El Planificador de Versiones (PV) permite gestionar los productos, sus versiones, los workflows disponibles para cada producto, los agentes por defecto asignados a las actividades de los workflows y realizar el seguimiento continuo del estado actual de las versiones. Figura 7. Planificador de Versiones – Pestaña Incidencias La ventana de la Figura 7 muestra la lista de unidades de trabajo que están asignadas a una versión de un determinado producto. El jefe de proyecto puede consultar los datos resumidos de cada unidad de trabajo en la versión, en particular, puede conocer la actividad actual en que se encuentra, el orden de prioridad, el esfuerzo que implica elaborar la unidad de trabajo, el agente asignado a las actividades principales del workflow, etc. Además, cuenta con potentes mecanismos que ayudan a explotar esa información: filtros, ordenamiento, agrupamiento de información, etc. Con toda esta información, el jefe de proyecto puede planificar las versiones, cambiando de versión las unidades de trabajo y asignando las prioridades a cada una de ellas de acuerdo con sus compromisos. La pestaña Carga de Agentes (Figura 8) permite a cualquier miembro del equipo conocer el trabajo que tiene asignado en la versión y el estado en el que se encuentra. Por otro lado, el jefe del proyecto puede realizar un seguimiento continuo del estado de la versión. La información está agrupada por Agente y Actividad. La columna Estado indica el estado en que se encuentra la unidad de trabajo en la actividad. Además, se muestra el tiempo que el agente ha registrado en la actividad hasta el momento (T.Real), el tiempo estimado (T.Estim), el tiempo estimado ajustado que corrige al anterior (T.Est.Aju), el porcentaje de completado de la actividad (%Comple) y las horas restantes que le quedan al agente para completar la actividad (H. Rest). Para que este último dato sea fiable, las horas registradas del agente no pueden sobrepasar el tiempo estimado, en este caso, el sistema indicaría al agente que debe realizar un ajuste en su estimación coloreando la celda de rojo. Figura 8. Planificador de Versiones – Pestaña Carga de Agentes TUNE-UP trabaja con lo que denominamos “Holgura Simple” del agente, la cual considera el tiempo restante (T.Rest.) con respecto el tiempo que dispone el agente para terminar su trabajo. Así, cuando la holgura simple de algún agente es negativa, puesto que no dispone de tiempo para terminar su trabajo, podemos asegurar que la carga del agente en la versión está desbalanceada, y por lo tanto, esto afectará a toda la versión. Gracias a esta información el jefe de proyecto puede tomar las acciones correctivas oportunas, como por ejemplo, cambiar la unidad de trabajo de versión, dividir la unidad de trabajo, pasar parte del trabajo a otro agente, modificar los plazos de entrega de la versión, negociar tiempo extra con el agente, etc. La holgura simple nos ha resultado útil como indicador de sobrecarga del agente y síntoma de riesgo en los compromisos de una versión. Capítulo 4: Librerías para desarrollo de editores gráficos 4.1 Comparativa de componentes de diagramas En este apartado hablaremos sobre la investigación previa de búsqueda de un componente de edición de diagramas de workflow. El componente buscado debía ser de tipo Windows Forms para .NET, para poder integrarlo con el resto de la aplicación. Esto supone que no entran en la comparativa los componentes para WPF o Silverlight. Los requisitos que el componente debía cumplir son los siguientes: Edición de diagramas. Edición de los tipos de nodos. Representación de swim lanes. Gestión de layout. Coste económico. Soporte y comunidad. Complejidad. 4.2 Componentes a comparar Dentro de la oferta de componentes destinados a la creación de diagramas, se encuentran varias opciones tanto de software comercial como de software de código abierto. 4.2.1 AddFlow for .NET Software comercial de Lassalle Technologies de gestión de diagramas y workflows para .NET 2.0. No incluye gestión de layout, se vende aparte o en un pack con Addflow por 699$. Los controles para .NET se han creado a partir de la versión para ActiveX, no como en otros casos. Cabe destacar lo simple que es, con una pequeña interfaz y una gran flexibilidad. Además es muy ligero, siendo la librería de un tamaño de 316Kb. También es posible introducirlo en una página web mediante ActiveX. En cuanto al soporte, la página carece de foro donde consultar dudas y que a la vez sirva de base de conocimiento, todo el soporte es vía mail. Como documentación incluye numerosos ejemplos pero la mayoría sólo muestran soluciones simples. Precio: 499$ 4.2.2 Syncfusion Essential Diagram Software comercial que incluye una gran cantidad de controles de edición de diagramas. En este caso incluye gestión de layout y un editor de paletas de figuras, e incluso es posible importar figuras directamente desde Visio. También incluye la posibilidad de crear scripts. Es uno de los más completos en cuanto a posibilidades tanto de funcionalidad como de presentación. La documentación es otro de los puntos fuertes de los componentes de Syncfusion, con gran documentación en la web, con ejemplos incluidos, y con un foro dedicado especialmente a cada tipo de componente. Por otro lado son considerablemente más complejos que en el caso de AddFlow y superan en exceso las necesidades que tenemos. Precio: 495$ 4.2.3 Nevron Diagram Software de tipo comercial que incluye controles para ASP.NET tanto con AJAX como sin él. Incluye gestión de layout. Comparte los pros y contras de Syncfusion, una herramienta muy potente pero excesiva para el problema que nos atañe. Además, la parte web de la herramienta está más descuidada en cuanto a documentación. Precio: 589$ 4.2.4 GoDiagram Software comercial cuya mayor ventaja es la existencia de una versión reducida, la cual es suficiente para la edición de diagramas simples. La funcionalidad básica que incluye permite construir diagramas con nodos y conexiones. El otro punto fuerte son los numerosos ejemplos con soluciones complejas que ayudan a superar el salto de los ejemplos simples a la solución real. No incluye gestión de layout ni soporte para swimlanes. Precio: 199$ versión Express y 899$ la versión completa. 4.2.5 Netron Software de código abierto en un estado avanzado de desarrollo, pero finalmente fue abandonado. Se creó un nuevo proyecto como continuación llamado Netron Reloaded, pero no tiene un ritmo constante de actualizaciones. Esto hace que tenga un soporte nulo como contrapartida de los beneficios de que sea código abierto. Como documentación incluye un IDE de diagramas que sirve como ejemplo de la utilización de la librería. 4.2.6 Open Diagram Software de código abierto que peca de los mismos fallos que Netron, la falta de documentación e inestabilidad del producto. Este componente no incluye gestión de layout. La presentación destaca sobre la media pero sigue siendo un producto incompleto con el que se hace difícil trabajar. 4.2.7 yFiles Software comercial que consta de una completa suite de componentes para tratamiento de gráficos. Con diferencia es el producto más completo de todos y por ello está muy por encima de las necesidades del proyecto y del presupuesto. Precio: 3600€ 4.3 Conclusiones Como primera elección había que considerar la utilización de un componente comercial o uno de software libre. En este caso, adquirir un software comercial suponía tener un soporte y sobre todo una fiabilidad de la cual carecían todas las opciones de tipo software libre. Los criterios de elección cambiaron durante las distintas pruebas de componentes, dejando las swimlanes fuera de los requisitos y la parte web en un segundo plano. La gestión de layout también se descartó porque la complejidad que añadía no suponía un gran beneficio. Después de revisar y probar todos estos componentes se llegó a las siguientes conclusiones: Resultaba más interesante elegir una opción de tipo comercial sobre todo por la documentación. La herramienta elegida debía ser concisa, evitando así tener más funcionalidad de la necesaria. Los ejemplos suministrados debían ser suficientemente complejos como para poder utilizarlos como base. Siguiendo estos criterios la opción elegida fue GoDiagram, ya que ofrece una versión “express” con funcionalidad reducida, incluye ejemplos similares al problema a resolver y tiene una API potente y sencilla. Capítulo 5: Módulo para especificación de Workflows 5.1 Descripción del sistema actual El sistema al que se le va a añadir la nueva aplicación es un software de gestión de tareas guiado por workflows, cuyo núcleo es un motor de workflows que se encarga del correcto orden de las tareas, el flujo de las incidencias, la asignación de los recuros, etc. Los workflows están definidos en la base de datos por las siguientes tablas: Actividades: IdActividad IdRol NombreActividad Activa Orden TienePeso TieneSourceSafe EsReunion PermiteSalto Tipo Conexiones: IdConexion IdActividadOrigen IdActividadDestino IdTransicion IdTipoWorkflow Descripcion Activa Transiciones: IdTransicion EsPuntoSincronizacion Roles: IdRol NombreRol Activo Seguimientos: IdSeguimiento IdIncidencia IdAgente IdTipoSeguimiento FechaPendiente FechaInicio FechaCierre NumReintentos BloqueaContinuar Observaciones CerradaPor FechaUltModificacion Incidencias: IdIncidencia IdAgenteIntroduccion FechaIntroduccion IdPrograma IdArea IdSubArea IdProyecto IdVersion IdTipoIncidencia IdTipoWorkflow Descripcion FechaLimite TiempoRealTotal TiempoEstimadoTotal Comprometida VariableCompilacion TraduccionResiPlus TraduccionReports TraduccionDisenadorDocs TraduccionSecurity TiposWorkflow: IdTipoWorkflow NombreTipoWorkflow Descripcion El modo actual de ver los workflows es mediante imágenes generadas por Microsoft Visio. 5.2 Arquitectura propuesta La herramienta tiene como finalidad permitir la modificación de los workflows desde un entorno visual pero a su vez es necesario implementar una solución que cubra la visualización de los mismos. Por ello se desarrolló un visor de workflows que sustituyera el sistema de imágenes anterior que estaba incluido en la aplicación. Además, el visor debía ofrecer información tanto de las actividades como del propio workflow. Para guardar los diagramas generados por la aplicación se añaden los campos DiagramaXml y Borrador a la tabla TiposWorkflow. 5.3 Pruebas de aceptación Las pruebas de aceptación son las siguientes: Abrir workflow: Debe preguntar si queremos ver el borrador en caso de que el workflow tenga uno. Comprobar que muestra un cartel en el que pone “Borrador” cuando el workflow abierto es un borrador. Comprobar que las actividades que no están activas se muestran de otro color. Selección de actividades por rol: Comprobar que el listado de roles son todos los que están en el workflow y si el workflow no está en la base de datos lista todos los roles. Comprobar que al seleccionar un rol se colorean todas las actividades del workflow que tienen ese tipo de rol. Comprobar que al modificar el color de las actividades no cuente como modificación del documento. Guardar workflow: Comprobar que no se guardan datos en las tablas hasta que no se publique el borrador. Comprobar que es necesario escribir un nombre para el workflow. Comprobar que se guarda el borrador en xml. Comprobar que no pueda guardar un workflow con el mismo nombre. Eliminar workflow: Comprobar que no se puede eliminar un workflow con incidencias asociadas. Comprobar que se eliminan las conexiones y transiciones del workflow. Publicar workflow: Comprobar que no impida publicar si se ha modificado o eliminado una actividad con incidencias. Comprobar que si se acepta se eliminan los diagramas de los workflows que contienen esa actividad. Modificar actividad: Comprobar que al modificar una actividad avisa de que se eliminarán todos los workflows con la misma actividad al publicar el workflow. Comprobar que no se quede vacío el campo nombre. Comprobar que no se puede modificar el rol. Comprobar que al cancelar no realice ninguna modificación. Nueva actividad: Comprobar que se puede seleccionar el rol. Comprobar que no puede crear una actividad con nombre duplicado. Anexo: Bibliografía Anexo – Bibliografía BPMN [White 06] Introduction to BPMN, Stephen A. White, IBM Corporation AddFlow for .NET Web http://www.lassalle.com Syncfusion Essential Diagram Web http://www.syncfusion.com Nevron Diagram Web http://www.nevron.com GoDiagram Web Web: http://www.northwoods.com Netron Web http://www.orbifold.net/default/?page_id=1272 Open Diagram Web http://www.codeplex.com/opendiagram yFiles Web http://www.yworks.com Referencias del artículo deTUNE UP del capítulo 3 Beck K. Extreme Programming Explained: Embrace Change. Addison Wesley. 2000. CMMI v1.2. Capability Maturity Model Integrated. SEI–Software Engineering Institute, Carnegie Mellon. 2009. www.sei.cmu.edu/cmmi/models/ (visitado junio de 2009). ISO-International Organization for Standardization. ISO/IEC 15504, SPICE: Software Process Improvement and Capability dEtermination. 1998. ISO-International Organization for Standardization. ISO/IEC 90003, Software engineering- Guidelines for the application of ISO 9001:2000 to computer software. 2004. Kroll P., Kruchten P. Booch G. The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. Addison-Wesley Professional. 2003. MAP-Ministerio de Administraciones Públicas de España. Métrica Versión 3, Metodología de planificación, desarrollo y mantenimiento de sistemas de información. 2005. www.csi.map.es/csi/metrica3/ (visitado en junio de 2009) PMI-Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide) - Fourth Edition. 2008. Schwaber K., Beedle M. Agile Software Development with Scrum. Prentice Hall, Series in Agile Software Development. 2001. Watts, H. Introducción al proceso de software personal. Addison-Wesley Iberoamericana. 2001.