Tesis de Master Desarrollo de un módulo para la

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.