0

Metodologa de Gestin
de los Procesos de Negocio
Sustentada en el uso de Patrones





Tesis Doctoral Presentada a la
Universidad Central de Venezuela
Por
M. Sc. Pedro Nolasco Bonillo Ramos
Como requisito parcial para optar al ttulo de
DOCTOR EN CIENCIAS DE LA COMPUTACIN
Tutora
Dra. Nancy Zambrano
Mayo, 2008
Universidad Central de Venezuela
Facultad de Ciencias
Escuela de Computacin
Postgrado en Ciencias de la Computacin
i

Prolegmenos

Dedicatoria

A mi Creador, Hermano y Fuego de mi Espritu, por habitar cada da en mi corazn,
fortalecindolo con sus dones y acrecentndolo con su sabidura.
A mi gua Espiritual, mi Amor y Compaa. Virgen Mara, tus oraciones y
bendiciones da a da en mi corazn.
A mi Madre, Amiga incondicional, Instrumento divino de Dios en la formacin de
mi vida, a ti Lourdes, a quien dedico especialmente mi trabajo con gran honor y especial
aprecio.
A Doris mi Esposa, Amiga, Compaera, Confidente. Por tu apoyo, paciencia,
fortaleza y comprensin.
A Francelis, Doris Daniela y Pedro Jess mis Hijos, Por ser mis fuentes de orgullo e
impulso en la vida, todo mi amor es de ustedes hijos, todo lo que soy y hago.






ii
Agradecimiento

Agradezco con todo mi corazn a mi Madre, quien con sacrificios y esperanzas ha
logrado hacer de m un Hombre Sabio. Lourdes, te amo, este triunfo es realmente tuyo, te lo
agradecer toda mi vida.
Agradezco a todos mis Docentes y Formadores. En especial a la Profesora Nancy
Zambrano, por su apoyo y Fe.
Agradezco a mi tutora por su dedicacin, empeo y amistad en la realizacin de este
trabajo, Gracias Profesora Nancy Zambrano.



















iii
Resumen

El principal objetivo de este trabajo de tesis doctoral es formular una propuesta
metodolgica que permita la gerencia de los procesos del negocio (BPM), sustentada en el
uso de patrones. En este trabajo se propone una taxonoma de patrones y su representacin
a travs de una arquitectura de procesos, componentes y aplicaciones en el dominio BPM.
Adems se extiende la especificacin de los patrones propuesta por Acosta y Zambrano en
el 2004, obteniendo un nuevo meta-patrn acorde con la taxonoma, con elementos que
permiten medir la calidad de los patrones en el proceso y el producto de software, a travs
del uso de Estilos de Arquitectura Basados en Atributos (ABAS) y los modelos de calidad
ISO14-598 e ISO-9126. Tomando en cuenta esta combinacin de mtodos, herramientas y
tcnicas, se propone un conjunto de pasos que en el mbito de BPM, permiten identificar
los procesos claves, modelarlos y analizarlos, simularlos, implantarlos de forma asistida
(tanto los nuevos procesos como sus versiones), evaluarlos, monitorearlos y mejorarlos.
Con la finalidad de poner en practica la metodologa se presenta un caso de estudio con el
proceso de Gestin de Versiones de la Librera de Infraestructura de Tecnologa de la
Informacin (ITIL).

Palabras Claves: Ingenieria de Software, Taxonomia de Patrones, BPM, Metodologa
BPM, Proceso de Gestin de Versiones, ITIL.

Abstract

The main objective of this work is to propose a methodology that allow the Business
Processes Management (BPM), based in the use of patterns. This Work propose a
taxonomy of patterns and its representation through of an architecture of processes,
components, and applications in the BPM scope. In addition, it opens out the pattern
especifications propose for Acosta and Zambrano in 2004, obtain a new meta-pattern
according with taxonomy, with elements that permit measurement that quality of patterns in
the proccess and product of software, through of Attribute-Based into Architectural Styles
(ABAS) and quality models ISO14-598 and ISO-9126. Considering this combination from
methods, tools and techniques, its propose a whole of steps that in the BPM scope, allows
identify the key processes, model and analyze, simulate, implant in a assisted way (such as
new processes as their versions); evaluate, monitore them and improve. With the purpose of
verify in practices the methodology show a case of study with the Release Management
process of Library Infrastructure Technology Information (ITIL).

Keywords: Software Engineer, Pattern Taxonomy, BPM, BPM Methodology, Release
Management Process, ITIL.
iv
ndice

Prolegmenos ....................................................................................................................................................... i
Dedicatoria ..................................................................................................................................................... i
Agradecimiento ............................................................................................................................................. ii
Resumen............................................................................................................................................................. iii
ndice.................................................................................................................................................................. iv
ndice Tablas.................................................................................................................................................. v
ndice Figuras ................................................................................................................................................ v
Introduccin ........................................................................................................................................................ 1
Captulo I El Problema ........................................................................................................................................ 4
1.1 Contexto .................................................................................................................................................. 4
1.2 Formulacin del Problema....................................................................................................................... 9
1.2.1 El Problema .................................................................................................................................. 9
1.2.2 Manifestaciones del Problema.....................................................................................................10
1.2.3 Evidencias del Problema .............................................................................................................11
1.3 Objetivos.................................................................................................................................................12
1.3.1 Objetivo General .........................................................................................................................12
1.3.2 Objetivos Especficos ..................................................................................................................12
1.4 Justificacin............................................................................................................................................13
1.5 Delimitacin ...........................................................................................................................................14
1.6 Limitaciones ...........................................................................................................................................14
Captulo II Marco Terico..................................................................................................................................15
2.1 Antecedentes de la Investigacin............................................................................................................15
2.2 Bases Tericas ........................................................................................................................................18
2.2.1 Procesos de Desarrollo ................................................................................................................19
2.2.2 Construccin de Software Basado en Componentes ...................................................................20
2.2.3 Taxonomas de Patrones..............................................................................................................22
2.2.4 Gerencia de los Procesos del Negocio.........................................................................................26
2.2.5 Relacin entre el Uso de patrones y BPM...................................................................................32
2.2.6 Librera de Tecnologa de la Informacin (ITIL) ........................................................................33
Captulo III Metodologa....................................................................................................................................37
3.1 Tipo de Investigacin .............................................................................................................................37
3.2 Diseo de Investigacin..........................................................................................................................37
3.3 Poblacin y Muestra ...............................................................................................................................38
3.4 Tcnicas e Instrumentos de Recoleccin de Datos .................................................................................39
3.5 Procedimiento de Anlisis de Datos .......................................................................................................40
3.6 Metodologa a utilizar en funcin de los objetivos especficos de la investigacin (SESL)...................41
3.6.1. Determinar la naturaleza del sistema..........................................................................................42
3.6.2. Decidir el tipo de evaluacin......................................................................................................42
3.6.3. Identificar los individuos (Stakeholder) que afectan el sistema .................................................43
3.6.4. Estudiar y Analizar: Preguntas Claves .......................................................................................43
3.6.5. Retroalimentacin de los resultados ...........................................................................................43
Captulo IV Formulacin de la Metodologa de Gerencia de Procesos de Negocio Sustentada en el Uso de
Patrones ..............................................................................................................................................................44
4.1. Naturaleza del Sistema ..........................................................................................................................44
4.1.1 Entidades .....................................................................................................................................45
4.1.2 Relaciones ...................................................................................................................................47
4.1.3 Ambiente .....................................................................................................................................47
4.1.4 Objetivos .....................................................................................................................................48
4.1.5 Caractersticas .............................................................................................................................50
4.1.6 Principios.....................................................................................................................................51
4.1.7 Sub-Sistema de Control ...............................................................................................................51
v
4.2 Tipo de Evaluacin.................................................................................................................................52
4.3 Stakeholders............................................................................................................................................53
4.4 Preguntas Claves.....................................................................................................................................54
4.5 Diseo de la Metodologa de Gerencia de Procesos de Negocio Sustentada en el Uso de Patrones ......54
4.6. Retroalimentacin..................................................................................................................................64
4.7. Propuesta de Automatizacin de la Metodologa ..................................................................................65
Captulo V Caso de Estudio ...............................................................................................................................86
5.1. Crear Proceso.........................................................................................................................................86
5.1.1 Analizar...............................................................................................................................................86
5.1.1 Disear Proceso...................................................................................................................................89
5.1.3 Modelar................................................................................................................................................91
5.1.4 Configurar............................................................................................................................................93
Captulo VI Conclusiones y Recomendaciones..................................................................................................95
Referencias Bibliogrficas................................................................................................................................100
Anexo 1 Descripcin Taxonoma de Patrones..................................................................................................103
A1.1 Patrn de Anlisis. .............................................................................................................................103
A1.2 Patrn Arquitectural...........................................................................................................................105
A1.3 Patrones de Diseo.............................................................................................................................107
A1.4 Patrn de Interaccin .........................................................................................................................112
A1.5 Patrn de Flujo de Trabajo.................................................................................................................113
Anexo 2 Formato de Solicitud de Requerimiento ............................................................................................122
Anexo 3 Cartelera de Actividades Propuestas..................................................................................................124
Anexo 4 Escenario Proceso de Gestin de Versiones ITIL en base al Patrn de Anlisis de Produccin .......125
Anexo 5 Artculos Arbitrados Publicados ........................................................................................................127

ndice Tablas
Tabla 1 Fases del Proceso versus Objetivos de la Construccin de Software Basado en Componentes.
(Gamma et al., 1995) .........................................................................................................................................21
Tabla 2 Metapatrn adaptado de Acosta, Zambrano (2004) y Kazman, Klein (2004) ......................................26
Tabla 3 Caso de uso General Prototipo BPMS Metodologa Gerencia de Procesos de Negocio Sustentada en
el Uso de Patrones. ............................................................................................................................................67
Tabla 4 Caso de Uso Administrador Modelo ....................................................................................................70
Tabla 5 Caso de Uso Administrador Patrones...................................................................................................76
Tabla 6 Caso de Uso Administrador Interfaz ....................................................................................................78
Tabla 7 Caso de Uso Administrador de Tareas .................................................................................................79
Tabla 8 Caso de Uso Administrador de Eventos Tarea.....................................................................................81
Tabla 9 Caso de Uso Administrador de Identidad.............................................................................................83
Tabla 10 Caso de Uso Administrador de Estado Transicin .............................................................................85
Tabla 11 Relacin Procesos ITIL con el Mapa de Procesos ETOM. Adaptado de TMF..................................88

ndice Figuras
Figura 1: Tecnologas relacionadas en el Desarrollo OO Actual. (Tepfenhart et al., 1997)..............................16
Figura 2. Diferentes tipos de Patrones y su Relacin ........................................................................................24
Figura 3. Relacin entre las bases tericas ........................................................................................................25
Figura 4: La evolucin de EAI/BPM. (Vollmer et al., 2004) ............................................................................27
Figura 5: Arquitectura BPM. (Vollmer et al., 2004) .........................................................................................28
Figura 6: estndares BPM segn BPMI ............................................................................................................30
Figura 7: Marco Referencial para BPM sustentada en el uso de Patrones. (Bonillo, 2005) ..............................32
Figura 8: Organizacin de Soporte Interno en trminos de Sistemas. ...............................................................48
Figura 9: Sistema de Control de la Organizacin de Soporte Interna................................................................52
vi
Figura 10: Estructura de la Metodologa de Gerencia de Procesos Sustentada en el Uso de Patrones Process
Management. ...................................................................................................................................................54
Figura 11: Sub-Proceso Analizar de la Metodologa Gerencia de Procesos......................................................55
Figura 12: Sub-Proceso Analizar de la Metodologa Gerencia de Procesos (continuacin). ............................55
Figura 13: Sub-Proceso Analizar de la Metodologa Gerencia de Procesos (continuacin). ............................56
Figura 14: Sub-Proceso Disear de la Metodologa Gerencia de Procesos. ......................................................57
Figura 15: Sub-Proceso Modelar de la Metodologa Gerencia de Procesos (continuacin)..............................58
Figura 16: Sub-Proceso Configurar de la Metodologa Gerencia de Procesos. .................................................59
Figura 17: Sub-Proceso.Configurar de la Metodologa Gerencia de Procesos (continuacin)..........................60
Figura 18: Sub-Proceso Mantenimiento de la Metodologa Gerencia de Procesos. ..........................................61
Figura 19: Sub-Proceso Mantener Configuraciones de la Metodologa Gerencia de Procesos (continuacin).62
Figura 20: Sub-Proceso Mantener Configuraciones de la Metodologa Gerencia de Proceso (mantenimiento de
plataforma). .......................................................................................................................................................62
Figura 21: Sub-Proceso Monitorear de la Metodologa Gerencia de Procesos. ................................................63
Figura 22. Caso de uso General Prototipo BPMS Metodologa Gerencia de Procesos de Negocio Sustentada
en el Uso de Patrones. .......................................................................................................................................66
Figura 23. Caso de uso Administrador Modelo.................................................................................................68
Figura 24 Caso de uso Administrador Patrones. ...............................................................................................70
Figura 25 Caso de uso Administrador Interfaz..................................................................................................76
Figura 26 Caso de uso Administrador de Tareas. ..............................................................................................78
Figura 27 Caso de uso Administrador de Eventos Tarea...................................................................................80
Figura 28 Caso de uso Administrador de Identidad. .........................................................................................82
Figura 29 Caso de uso Administrador de Estado Transicin.............................................................................84
1

Introduccin

El ambiente de los negocios ha empezado a ser ms y ms turbulento que en
las dcadas pasadas, la tecnologa de la informacin comienza a ser un
riesgo, un impedimento para el motor del progreso. (Shael, 1999)
Las empresas actuales requieren de modelos de negocios complejos con una estructura
organizacional, procesos y sistemas que deben ser diseados explcitamente. El trabajo de
disear estos modelos de negocio es claramente interdisciplinario, ya que requiere
conocimientos de desarrollo del negocio, los diferentes procesos que ocurren en la empresa
y de la gerencia de los procesos y las aplicaciones tecnolgicas.
En el mbito de la ingeniera de software sera conveniente poder contar con un sistema de
mtodos, herramientas y tcnicas que permitan reutilizar las mejores prcticas, hacer
seguimiento sobre la combinacin de estas mejores prcticas y medir la calidad del proceso
y producto de software que se obtiene, segn cada uno de los procesos que se implementen
en cada dominio.
En base a esto, el propsito de este trabajo es Disear e Implementar una metodologa que
permita la gestin de los procesos de negocio, sustentada en el uso de patrones.
Este trabajo se fundamenta en las siguiente lneas de investigacin del rea de Ingeniera de
Software: Metodologas orientadas a objeto de desarrollo de software, Modelos, Mtodos,
Tcnicas y Herramientas de desarrollo de software, Interaccin Humano Computador,
Patrones de diseo, Componentes y reutilizacin de software, Desarrollo de aplicaciones
basadas en Internet, Arquitectura de software, Calidad de software e Ingeniera orientada a
modelos.
La gerencia de los procesos del negocio y el uso de patrones en la ingeniera de software
son ambos, problemas de vieja data, en este trabajo, se trata de estudiarlos segn las nuevas
tecnologas, considerando las potencialidades de un modelo que incluya componentes
reutilizables.
En el mbito de los procesos de negocio, la solucin tecnolgica por excelencia se refiere al
trmino Flujo de Trabajo o workflow, que es el proceso a travs del cual las tareas de los
individuos son coordinadas para completar una transaccin (usando los procesos del
negocio definidos) dentro de una organizacin. El workflow es un conjunto de
mecanismos que automatizan los procesos de trabajo. Estos mecanismos relacionan entre s
los aspectos de la administracin, establecen prioridades entre las diversas tareas de cada
empleado y optimizan las comunicaciones entre las distintas unidades operativas.
Para que eso se logre es necesario definir cules son las distintas tareas que se realizan en
una organizacin; quines participan en su ejecucin; quines son responsables de las

2
mismas; cul es la secuencia de procesos de cada tarea y cules son las acciones que inician
cada proceso.
Aunque la contribucin de los Flujos de Trabajo tradicionales modelados por la WFMC
(Workflow Management Coalition), es an notable, hay una nueva generacin que quizs
sea un hbrido que rene lo mejor de todos los sistemas de workflow y otras tecnologas:
los Sistemas de Gerencia de Procesos de Negocio (BPMS).
Los BMPS incorporan amplias capacidades de integracin con modernas arquitecturas
Java, .Net y XML. Adicionalmente, suman otras tecnologas como Web Services, Motores
de Reglas de Negocio y de Monitoreo de las Actividades del Negocio (BAM). De acuerdo
con Howard Smith y Peter Fingar (2003), avalados por la BPMI (Business Process
Management Initiative) y la WFMC, hoy en da se puede afirmar que los BPMS permiten
a las empresas modelar, implementar y gestionar los procesos de negocio, que abarcan
mltiples aplicaciones empresariales, departamentos, y proveedores, pero sin un marco
referencial integrado.
Los BPMS han evolucionado desde la integracin de arquitecturas de negocio, donde se
contempla la transformacin y enrutamientos de los datos, administracin de eventos,
automatizacin de procesos y el uso de adaptadores en los aos 90; a la integracin en el
2000 de los procesos de negocio a travs del modelaje bsico de los procesos, la gerencia
de los proveedores, conectividad entre empresas a travs del comercio electrnico y
formacin de ciertas plantillas de procesos para industrias verticales; hasta llegar al
concepto que actualmente se maneja (a partir del 2004) que involucra: aplicaciones de flujo
de trabajo, modelaje sofisticado de procesos, monitoreo de las actividades asociadas a los
procesos de negocio (Bussines Activity Monitoring, BAM por sus siglas en ingls),
exposicin de las funcionalidades de las aplicaciones a travs de servicios web, utilizacin
de manejadores de reglas de negocio, soporte a mltiples dispositivos de acceso a la
informacin en cualquier lugar y desde cualquier posicin (aware-contex) a travs del
uso de portales, utilizacin de herramientas para la gerencia del ciclo de vida del desarrollo
asistido de las aplicaciones de software que apoyan los procesos, soporte mvil de los
procesos y las interfaces, extraccin, transformacin y carga de datos que son utilizados por
los procesos y la capacidad de simulacin sobre los procesos y versionamiento de los
mismos (optimizacin de procesos Bussines Process Optimization, por sus siglas en ingls
BPO).
A pesar de todas las caractersticas antes mencionadas, los BPMS adolecen de un marco
referencial global e integral que establezca metodolgicamente su implementacin y
utilizacin. En lo que respecta a su implementacin, la mayora de los patrones de software
no estn soportados de forma precisa. El mercado de las arquitecturas de BPM tiende a
concentrarse en flujos de sistema a sistema y est emergiendo lentamente en cuanto al flujo
humano-humano asistido por el computador. Con base en lo anterior, BPMI es la
organizacin que asume la elaboracin de los estndares (BPA, BPMN y BPMS; anlisis,
notacin y semntica respectivamente) que sustentan el concepto de BPM enfocndose

3
sobre el proceso del negocio como el punto de partida entre el ambiente del mismo y su
puesta en prctica a travs de la tecnologa. Actualmente workflow Management
Coalition se est unificando con el BPMI.
Con la finalidad de alcanzar el objetivo planteado, este documento se estructura de la
siguiente manera:
En el Captulo I, El Problema, se inicia con la contextualizacin en espacio y tiempo del
problema de investigacin, sus manifestaciones y evidencias, luego se presentan los
objetivos, la justificacin, delimitacin y las limitaciones.
En el Captulo II, Marco Terico, se establece a partir de estudios anteriores, cmo se han
utilizado los procesos de desarrollo de software actuales y su relacin con la construccin
de software basado en componentes, se especifica la necesidad de utilizar las mejores
practicas en cada dominio a travs de una taxonoma de patrones y sus relaciones, se
estudia tericamente el sistema social de la gerencia de los procesos de negocio
ignorando el hecho que la tecnologa cambia la estructura organizacional y la cultura,
enfocndose en el estudio inicial del sistema social o tcnico. Definiendo a partir de la
investigacin documental y bibliogrfica el estudio de la naturaleza del sistema abordando
los temas de patrones de software, necesidad de medir la calidad de los patrones de
software en el proceso de construccin de software y la relacin entre el uso de patrones,
ITIL y el dominio de estudio BPM especficamente en lo relativo al caso de estudio
(procesos de Gestin de Versiones).
En el Captulo III, Metodologa, se describen las unidades de anlisis, o de investigacin,
las tcnicas de observacin y recoleccin de datos, los instrumentos, los procedimientos y
las tcnicas de anlisis de la instanciacin de la metodologa Systemic Evaluation for
Stakeholder Learning (SESL) que es utilizada para llevar a cabo la presente investigacin.
En el Captulo IV, Formulacin de la Metodologa de Gerencia de Procesos de Negocio
sustentada en el Uso de Patrones, se realiza la formulacin de la metodologa, tomando en
cuenta los elementos referentes al dominio del caso de estudio BPM y los instrumentos
metodolgicos utilizados.
En el Captulo V, Caso de Estudio, se detallan los pasos utilizados en la aplicacin de la
metodologa al caso de estudio del proceso de Gestin de Versiones de ITIL, se exponen
los detalles del modelado de los procesos, su puesta en produccin y la evaluacin y mejora
de los mismos.
Finalmente en el Captulo VI, Conclusiones y Recomendaciones, se detallan las
conclusiones y recomendaciones que se obtienen de la aplicacin de la metodologa al caso
de estudio, y de los resultados finales.
A continuacin se inicia con el planteamiento del objeto de estudio o contexto.

4
Captulo I El Problema

Para iniciar este capitulo a continuacin se describe, en espacio y tiempo el contexto en el
cual esta inmersa la investigacin doctoral, para luego formular el problema, describir sus
manifestaciones y evidencias, formular el objetivo general y los objetivos especficos,
describir la justificacin de la investigacin su delimitacin y sus limitaciones.
1.1 Contexto
La nueva economa, denominada digital e inteligencia en red por Tapscott (1998), se
mueve en un mundo cada vez ms voltil, global y competitivo, en las ltimas dcadas se
puede apreciar cmo han surgido distintas modas gerenciales para afrontar los problemas
de las organizaciones en funcin de sus entornos (interno/externo), pero fundamentalmente
en pro de mejorar el manejo de la informacin, la cual cada da es, en todas sus formas, ms
gestionada a travs de Internet y en las propias redes internas de las organizaciones.
(Bonillo, 2005d).
Las empresas actuales, requieren de modelos de negocios complejos con una estructura
organizacional, procesos y sistemas que deben ser diseados explcitamente, incluyendo:
(1) Diseo del modelo de negocio: estructura del negocio y diseo del producto y el valor
agregado en relacin a soluciones tradicionales- que ste aportar, estrategia de captura de
mercado y distribucin; (2) Diseo del sitio Web a travs del cual se canalizar la oferta;
(3) Diseo de los procesos de negocios -procesamiento de pedidos, generacin del producto
o servicio, logstica, etc. que implementen la oferta, a travs de una cierta estructura y
funcionamiento organizacional; (4) Diseo de los sistemas computacionales que manejen
las transacciones que se capturan del sitio, mantienen las bases de datos (clientes,
productos, contable/financieras) necesarias para procesar eficientemente tales transacciones
y automatizar/apoyar con informacin apropiada los procesos mencionados en el punto tres
(Barros, 2002).
El trabajo de disear estos modelos de negocio es claramente interdisciplinario, ya que
requiere conocimientos de: desarrollo de negocios, los diferentes procesos que ocurren en
la empresa, las Tecnologas de la Informacin y la Comunicacin (TIC), diseo
organizacional, manejo de recursos humanos, habilidades de innovacin entre otros. Por lo
tanto, sera difcil que una sola persona pudiera tener todo el conocimiento y formacin
para hacer tal trabajo.
Esto genera la necesidad de trabajar con equipos de diseo en los cuales se encuentren los
talentos enunciados. Sin embargo, los profesionales que puedan facilitar el trabajo de un
equipo de este tipo deben tener conocimientos profundos de una metodologa de diseo que
oriente todo el trabajo y conocimientos apropiados en todos los otros temas que son
relevantes. Lo anterior confirma la necesidad y conveniencia de realizar diseos explcitos

5
de los negocios en base a los procesos, sus prcticas de gestin y a las TIC disponible, es
decir realizar una Ingeniera de Negocio (Barros, 2002).
Los cambios producidos en las organizaciones para lograr esta adaptacin han sido
acciones continuas y rpidas, a travs del desarrollo de nuevas interrelaciones entre las TIC,
con base en los casos de xito surgidos en cada uno de los dominios especficos. A partir de
la dcada de los ochenta se presenta en las ciencias de la computacin un cambio de
paradigma hacia la computacin centrada en red, surgiendo un conjunto de tcnicas, en la
Ingeniera de Software, que enfocan al software como un producto de ingeniera que debe
definir, crear y aplicar: (1) una metodologa bien definida dirigida a un ciclo de vida de
planeamiento, desarrollo, y mantenimiento; (2) un conjunto establecido de componentes de
software que documenta cada paso en el ciclo de vida y muestra un seguimiento, y (3) un
conjunto de hitos predecibles que pueden ser revisados a intervalos regulares a travs del
ciclo de vida del software. (Pressman, 1997).
La Ingeniera de Software ha evolucionado en todas sus reas: anlisis de requisitos,
procesos de desarrollo de software, interaccin humano-humano asistida por el
computador, estrategias de implementacin, modelos de costos, etc. Sin embargo, an est
por debajo de las necesidades de calidad demandadas por las organizaciones y los sistemas
cada vez ms complejos; adems estos esfuerzos han surgido de forma independiente y no
se integran (en muchos casos se oponen y se complementan a la vez, pretendiendo crear el
software desde varias perspectivas al mismo tiempo), demostrando as la ausencia de un
marco referencial que las una y que facilite el seguimiento y la evaluacin necesaria para
garantizar su eficacia, desde una perspectiva integral.
En este contexto, existen considerables esfuerzos de investigacin y desarrollo con el
objetivo de perfeccionar el proceso de produccin de software unificado, tanto a travs de
estudios tericos, como de estudios aplicados.
La construccin de aplicaciones ha sido siempre una tarea compleja, pero esta complejidad,
lejos de reducirse, es cada vez mayor: la aparicin de nuevos y sofisticados dispositivos
perifricos, la computacin sin cable, los grupos de usuarios cada vez ms heterogneos y
exigentes, la velocidad con que se deben construir los productos debido a la competencia y
exigencias del mercado; son todos factores que conllevan a la necesidad de definir nuevos
mtodos o adaptaciones de mtodos existentes (reflexin sobre los mtodos hasta lograr
una metodologa), a fin de abordar de manera integrada, clara y precisa la construccin de
software centrado en los usuarios.
En muchos casos la complejidad tecnolgica provoca que el ingeniero de software dedique
un mayor esfuerzo a conocer aspectos tcnicos, que a entender el problema que debe
resolver el software a desarrollar. Una de las tareas crticas en la Ingeniera del Software y
que tiene una mayor repercusin sobre la productividad y la calidad final del software es el
modelado conceptual. (Bonillo, 2004b)
Estudios relacionados con la construccin de software en ambientes Cliente/Servidor y
Orientados a Objetos sostienen la tesis de que las tareas ms crticas siguen estando en la

6
especificacin y en el anlisis de requisitos, y que los errores introducidos en esta etapa del
proceso de produccin de software pueden tener un impacto considerable en la fiabilidad, el
costo y la seguridad del sistema, de tal forma que se evidencia la necesidad de herramientas
de desarrollo que proporcionen construcciones de alto nivel que permitan especificar
sistemas, usando conceptos prximos al espacio del problema y no al de la solucin.
La falta de rigor que presentan los mtodos y entornos actuales en la definicin de los
elementos de modelado dificultan la obtencin de software que sea funcionalmente
equivalente a la descripcin capturada en el esquema conceptual.
Si se analizan los mtodos de desarrollo ms utilizados en la industria del software, se
puede observar que muchas veces el esfuerzo invertido en la realizacin de algunas tareas
(como puede ser el modelado conceptual) y en la produccin de documentacin, no tiene
ningn reflejo directo en el producto final.
Estos problemas invitan a replantearse la forma de abordar los procesos de desarrollo de
software. Estos procesos necesitan mtodos y herramientas que: (1) aborden el proceso de
desarrollo con rigor y de forma sistmica, proporcionando los modelos y las etapas
exclusivamente necesarias para la produccin de software; (2) se centren en la
especificacin precisa del espacio del problema; (3) ayuden al analista a tomar decisiones
en el proceso de modelado conceptual; (4) faciliten la generacin asistida de cdigo tanto
de estructura como de comportamiento a partir de esquemas conceptuales; (5) ofrezcan
independencia tecnolgica, ocultando la tecnologa subyacente a los desarrolladores; y (6)
produzcan software de calidad funcionalmente equivalente a su especificacin.
El paradigma de la orientacin a objetos promulga desde sus inicios una orientacin hacia
el modelado de estndares conceptuales expresivos, con una semntica bien definida basada
en un modelo formal. Actualmente la orientacin a objetos (y en general la mayora de
mtodos de modelado orientado a objetos OO-) carece de guas precisas que ayuden al
analista en la etapa de modelado a detectar los estndares que estn presentes en el esquema
conceptual del sistema (Douglas et al., 1996).
Uno de los esfuerzos asociados al tratamiento de este problema es presentado en noviembre
de 2000, cuando el OMG (Object Management Group) hizo pblica la iniciativa MDA
(Model Driven Architecture), una variante de una nueva tendencia extendida por todo el
mundo denominada Ingeniera de Modelos. Las ideas bsicas de la ingeniera de modelos
estn relacionadas con otras propuestas como la programacin generativa, lenguajes para
dominios concretos, computacin integrada con modelos, factoras de software, etc.
MDA puede definirse como la consecucin de los principios de la Ingeniera de Modelos
haciendo uso de un conjunto de estndares del OMG como MOF (Meta Object Facility),
XMI (XML Metadata Interchange), OCL (Object Constraint Languaje), UML (Unified
Modeling Languaje), CWM (Commond Warehouse Metamodel), SPEM (Software Process
Engineering Metamodel), etc.

7
De un modo similar a cmo el principio bsico todo es un objeto result fundamental
para establecer la tecnologa orientada a objetos durante la dcada de los 80, MDA en la
actualidad se concentra en los modelos, sin embargo esta iniciativa aun no ha producido los
resultados esperados.
Los mtodos de desarrollo han proliferado pero lo nico que proporciona la mayora son
lenguajes para describir esquemas conceptuales y diseos; adems de esto, deberan
proporcionar diseos prcticos y efectivos. Una alternativa para esto es la utilizacin de los
patrones de software, los patrones de software han surgido y evolucionado a partir de varias
iniciativas: la de Kent Beck y Ward Cunningham, dos de los pioneros de Smalltalk,
tambin a partir de las ideas de Christopher Alexander, que desarroll una teora y una
coleccin de patrones para el mundo de la arquitectura urbanstica (Alexander et al., 1977),
y de las ideas de Peter Coad (Coad et al., 1999) en las cuales presenta distintos patrones de
anlisis y diseo como una serie de relaciones entre elementos (dos o tres) de bajo nivel
(clases).
Bruce Anderson lider talleres en OOPSLA (Object-Oriented Programming, Systems,
Languages & Applications) a principios de los 90 en los cuales se investig y se desarroll
un libro sobre arquitecturas software. Jim Coplien en su libro (Coplien et al., 1995)
describi modismos tiles en C++. Basados en la mayora de estos trabajos se constituy el
grupo de Hillside para investigar estas ideas en un futuro. El empuje ms grande para su
conocimiento pblico fue la publicacin del libro Design Patterns, Elements of Reusable
Object-Oriented Software (Gamma et al., 1995) de la banda o grupo de los cuatro Gand or
Group of Four (GoF), y la conferencia PLoP (Pattern Language of Programming) que
inici en 1994 el grupo de Hillside.
Todava existen discrepancias entre los investigadores a la hora de definir qu es un patrn,
por lo que es bastante difcil encontrar definiciones de patrn que sean idnticas. En el libro
de Fowler (1997) se encuentra una definicin genrica interesante: Un patrn es una idea
que ha sido utilizada en un contexto prctico y que probablemente ser til en otros. El
trmino idea expresa que un patrn puede ser cualquier cosa. La expresin contexto
prctico refleja el hecho de que se desarrollan (algunos autores prefieren: descubren)
gracias a la experiencia prctica en proyectos reales.
Por otro lado, los patrones de software no son ms que un conjunto de soluciones a
problemas habituales en el diseo de software orientado a objetos. Una definicin ms
formal podra ser: Un patrn es una solucin a un problema, aceptada como correcta, a la
que se ha dado un nombre y que puede ser aplicada en otros contextos.
El concepto de patrn en la ingeniera de software, desde sus inicios fue planteado de forma
general para todas las disciplinas, sin embargo inicialmente surgieron como patrones de
diseo (patrones de un nivel de abstraccin menor y estn por lo tanto ms prximos a lo
que sera el cdigo fuente final), pero actualmente los patrones constituyen un concepto
ms general, representando estructuras conceptuales aplicables durante las fases de anlisis,
diseo, construccin de la interfaz de usuario e implantacin.

8
La aplicacin de patrones a los mtodos de desarrollo de software aporta beneficios
interesantes ya que, entre otras muchas aplicaciones, permiten: (1) definir guas de
modelado mediante lenguajes de patrones (Coplien et al., 1995); (2) estructurar el proceso
de generacin asistida de cdigo, y; (3) ofrecer soluciones reutilizables y probadas, que
sean lo suficientemente abstractas cmo para ser utilizadas en cualquier lenguaje de
programacin.
La utilizacin de patrones en las nuevas tecnologas est evolucionando a pasos
agigantados gracias a los estndares y las aplicaciones surgidas en estos ltimos aos.
Aunque la contribucin de las aplicaciones tradicionales de flujo de trabajo, ad hoc,
administrativos y colaborativos, es an notable, hay una nueva generacin que quizs sea
un hbrido que rene lo mejor de todos los sistemas de flujo de trabajo y otras tecnologas
basadas en patrones.
Como las empresas cada vez ms se estn orientando hacia los procesos, destacndose
principalmente por el e-Business, esta nueva generacin de tecnologa BPMS (Business
Process Management System) est siendo actualmente ms investigada y perfeccionada.
"La gerencia de los procesos del negocio se refiere a disear, ejecutar y optimizar los
procesos funcionales del negocio a travs de toda la organizacin incorporando los
sistemas, a los procesos y a la gente" (Vollmer, 2004).
BPM es la "integracin caracterizada por flujo de trabajo orquestado, orientado a
aplicaciones a travs de usos internos mltiples y/o entre los socios externos" (Harris,
2003). La puesta en prctica de las soluciones de BPM ha emergido como estrategia
dominante, que las organizaciones estn adoptando para mejorar la eficacia de sus procesos
del negocio. Las herramientas de BPM son capaces de apoyar este tipo de actividad debido
a su capacidad de coordinar interacciones entre: (1) los sistemas de informacin; (2) los
procesos del negocio, y; (3) la gente que los utiliza. Esto da visibilidad de las empresas en
el estado de los procesos y tiende a permitir cambios de los procesos sobre una base en uso.
Los esfuerzos han tendido a la integracin temprana de aplicaciones empresariales (IAE) y
la tecnologa de la Extraccin, Transformacin y Carga (ETC o ETL por sus siglas en
ingls Extraction-Transformation-Load) que permite la generacin de reportes
operacionales y multidimensionales sin afectar el desempeo de las aplicaciones, que han
sido fortalecidas con nuevas caractersticas que proporcionan la integracin de la
informacin de la empresa (EII), el flujo de trabajo, la gerencia de los procesos del negocio
(GPN o BPM por sus siglas en ingls), la integracin a travs de un modelo de objetos
nico para todos los sistemas (cannico), la utilizacin de portales y la ubicuidad por medio
de los dispositivos mviles.
Sin embargo esta tecnologa, adolece de un marco referencial global que identifique las
caractersticas esenciales a nivel estructural y de comportamiento de las relaciones
taxonmicas desde el anlisis hasta el cdigo pasando por la interfaz. En lo que respecta a
su implementacin, no se ofrecen pautas claras para obtener la representacin de los
patrones conceptuales en el producto de software e insertarlos en el proceso de

9
construccin (Bell, 2003). No existe una propuesta metodolgica que indique como
implementarla en la industria, tal como se propone en esta investigacin doctoral.
1.2 Formulacin del Problema
A continuacin se describe el problema de investigacin, sus manifestaciones y evidencias.
1.2.1 El Problema
En base a todo lo expuesto anteriormente, surgen las siguientes interrogantes:
Es posible crear un marco referencial que permita verificar la relacin y trazabilidad
sobre la combinacin de los diferentes patrones (anlisis, arquitectural, diseo, interfaz
e implementacin) a lo largo del ciclo de vida del proceso de desarrollo de software en
el dominio de la gestin de los procesos del negocio?,
Cmo dotar a estos patrones de especificaciones que van mucho ms all de su
utilizacin, relacionndolos en un marco referencial y asocindolos con el dominio de
la gerencia de los procesos de negocio?,
Qu tan ventajoso sera esto de cara a la ingeniera de software y en cuanto a la
trazabilidad (auditoria de utilizacin y combinacin de los mismos) entre los diferentes
patrones?,
Si se consigue capturar y representar estos patrones de forma no ambigua, Se podran
construir procesos de desarrollo asistidos que traduzcan correctamente los patrones
modelados al espacio de la solucin?,
Cmo representar los patrones conceptuales que resulten en el espacio de la solucin,
mediante estructuras software de calidad que permitan implementar correctamente la
semntica de los mismos en distintos entornos de produccin de software?,
El paradigma de BPM puede ser utilizado para verificar aspectos de desarrollo de
software basado en patrones?, y
Cmo verificar, de manera esttica y asequible, hasta dnde nos es posible asegurar
con el conocimiento disponible, que al combinar ciertos patrones no se han violado las
condiciones de funcionamiento correcto de ninguno de ellos, garantizando su eficacia
en el dominio de implementacin (BPM)?
La bsqueda de respuestas a estas preguntas permite plantear un problema de investigacin
fundamentado en la hiptesis de que las organizaciones en general fallan en la gestin de
los procesos del negocio, principalmente por factores como:
1. Retorno de Inversin (ROI) negativo a pesar de las grandes inversiones en TIC;
2. La nueva economa digital del conocimiento, centrada en la computacin en red sin
lmites espaciales, fundamentada en la multidisciplinaridad,
3. Los modelos de negocio complejos:

10
- Sin un marco referencial, en los cuales la ingeniera de software est por debajo de
las necesidades de calidad del proceso y el producto de software (no siendo este el
nico factor que influye en la calidad del software),
- Presentando esfuerzos independientes, sin capacidad de seguimiento y evaluacin,
- Donde la mayora de los mtodos de modelado orientados a objeto (OO) carecen
de guas precisas que ayuden al analista en la etapa de modelado a detectar los
patrones que estn presentes en el esquema conceptual, lo que repercute
directamente sobre la calidad del proceso y el producto final;
4. La utilizacin de patrones en las nuevas tecnologas tales como BMP adolece de un
marco referencial global que identifique las caractersticas esenciales a nivel
estructural y de comportamiento de las relaciones taxonmicas, desde el anlisis hasta
el cdigo pasando por la interfaz,
5. En su implementacin la mayora de los patrones conceptuales utilizados en el
dominio de BPM no estn soportados de forma precisa:
- Concentrndose en flujos de sistema a sistema y emergiendo lentamente en cuanto
al flujo humano-humano asistido por el computador,
- Proporcionando soluciones propietarias de tecnologas y no estndares las cuales
carecen generalmente de la agilidad ofrecida por la utilizacin de lenguajes de
procesos y patrones,
- Intentando crear flujos de trabajo pequeos que se pueden utilizar en contextos
ms generalizados, pero dejando a un lado la usabilidad;
Finalmente no existe una propuesta metodolgica que indique como implementar en el
dominio de BPM esta nueva tecnologa sustentada en el uso de patrones.
1.2.2 Manifestaciones del Problema
Las expectativas de reduccin de costos o de aumento de productividad, posibilitadas por la
adopcin de TIC han llevado a las empresas occidentales a aumentar progresivamente sus
inversiones en las mismas. As, mientras las inversiones en tecnologas de la informacin
que las empresas realizaron en los aos sesenta representaban tan slo el 3% del total de
inversiones en equipo, en 1996 la cifra aumento hasta representar el 45%. Ms an, en
algunos sectores, como en telecomunicaciones o seguros, las inversiones en TIC
constituyen ms de las partes del total de inversiones en equipo (MacDonald, 1998).
Estos estudios se han repetido para los aos 2000-2008, arrojando resultados similares que
se orientan ms bien a una mayor inversin en TIC.
En una lnea similar, Strassmann (2007), conocido consultor norteamericano que ha
estudiado con profundidad el impacto de las tecnologas de la informacin en las
organizaciones, seala que no hay una relacin directa entre la inversin de las empresas en

11
TIC y el retorno que consiguen de esa inversin. No existe tal correlacin, y lo que hace
rentable las TIC en una empresa no es el mero hecho de tenerlas, sino "cmo" se utilizan.
En este sentido, es ampliamente conocida la demanda por buenos instrumentos de gestin
del negocio dentro del contexto de la ingeniera de software. En general, los criterios que se
utilizan para evaluar un producto de software, son ms bien cualitativos, sin presentar una
estandarizacin que permita a los especialistas valorar aspectos y evidenciar criterios
mnimos de confiabilidad.
Al respecto, cabe sealar que, aunque este es un problema ampliamente reconocido, existen
escasas instancias de propuestas para la gestin de los procesos del negocio, que permitan
determinar su influencia positiva sobre la Organizacin. Algunas de las iniciativas
principales provienen a partir del ao 2000, de los esfuerzos del Instituto de Ingeniera e
Software (SEI) y en los modelos de Capacidad y Madurez Organizacional en bsqueda de
garantizar una relacin entre el retorno de inversin positivo y los procesos de desarrollo de
software.
1.2.3 Evidencias del Problema
A pesar que los anlisis econmicos indican que las TIC deben tener un claro impacto
positivo en el aumento de la eficiencia de las empresas, la verdad es que algunas cifras
ponen este hipottico impacto en duda. Quizs el ejemplo ms conocido sea el de la
denominada Paradoja de la Productividad (Cornella, 1996): Cmo poda explicarse que a
pesar de la continua inversin en tecnologa, y en especial en TIC, durante los aos 70 y 80,
no se consigui un crecimiento de la productividad similar al que se haba conseguido en
los aos 50 y 60, cuando tales tecnologas apenas existan?.
En los pases subdesarrollados (como es el caso de Venezuela) se requiere de esfuerzos
para la gestin de los procesos del negocio, orientados a obtener un equilibrio adecuado
entre la adquisicin de la tecnologa del exterior, el desarrollo y utilizacin de la capacidad
tecnolgica de la propia empresa y, la seleccin, adaptacin y generacin de la tecnologa
que se demanda para producir; ya que, en estos pases, las empresas no poseen capacidad,
ni tradicin suficientes en el desarrollo de tecnologas, siendo la principal opcin el recurrir
a la transferencia de tecnologa, provenientes stas de pases desarrollados (Paredes, 2004).
Estos modelos son comnmente difciles de adoptar y es la organizacin la que debe
adaptarse a las TIC. Existen otras causas que influyen en la productividad (puesto de
trabajo, ambiente, etc.) sin embargo esta investigacin se concentra en los relativos a la
ingeniera de software, en la que se han utilizado diferentes tcnicas tradicionales como
observacin, protocolos verbales, opiniones de los usuarios (entrevistas, discusiones
grupales, cuestionarios), grupos de enfoque especfico, etc., para obtener datos con la
finalidad de satisfacer mejor las necesidades y requerimientos del usuario (Navasa et. Al,
1999).
Adems de la variable costo, al analizar el entorno en el que se desenvuelven estas
tecnologas resulta importante observar otros indicadores de evaluacin, estos indicadores

12
pueden clasificarse en cuatro tipos: (1) Complejidad de la gerencia de tecnologa de
informacin (madurez en los procesos, dispersin de los usuarios finales, disponibilidad de
los servicios de TIC, niveles de servicio); (2) Complejidad del software (nmero de
plataformas de software diferentes, nmero de aplicaciones cliente servidor, porcentaje
total de software de aplicacin critico, porcentaje de aplicaciones de oficina); (3)
Complejidad del hardware (nmero de arquitecturas de hardware distintas, retorno anual de
una computadora personal, niveles de redundancia, porcentajes de usuarios con dispositivos
mviles), y; (4) Indicadores financieros (Valor Econmico Agregado EVA -, Valor de
Mercado Agregado MVA -, Valor Actual Neto VAN -, Valor Presente Neto VPN -,
Tasa Interna de Retorno TIR -, etc.) (Strassman, 1997).
A pesar de los grandes cambios tecnolgicos ocurridos en los ltimos 10 aos esta situacin
sigue siendo la misma, observndose ms bien un crecimiento en la complejidad de las
organizaciones y en la dificultad de poder determinar como afecta de manera positiva en el
negocio la TIC. (Strassman, 2007).
1.3 Objetivos
Seguidamente se presenta el objetivo general y los objetivos especficos de esta
investigacin.
1.3.1 Objetivo General
El objetivo general de esta investigacin es Disear e Implementar una metodologa que
permita la gestin de los procesos de negocio sustentada en el uso de Patrones.
1.3.2 Objetivos Especficos
Para lograr el objetivo general es necesario cumplir con los siguientes objetivos especficos:
1. Caracterizar las organizaciones como un sistema complejo (en el mbito de las
ciencias gerenciales y las ciencias de la computacin, con especial nfasis en la
ingeniera de software) que tiene como objetivo gerenciar los procesos del negocio a
travs de las TIC, a fin de definir sus procesos de: desarrollo de software, uso de
patrones y gerencia de los procesos de negocio;
2. Analizar algunos mtodos de: construccin de software, modelado orientado a
objetos, especificacin de patrones, definicin de arquitecturas de software,
evaluacin de arquitecturas de software, evaluacin de la calidad del proceso y el
producto de software y gestin de los procesos del negocio. A fin de seleccionar
mediante el anlisis los elementos importantes que sern incorporados en la
metodologa a proponer;
3. Establecer los lineamientos tericos, gerenciales, tcnicos y financieros, implcitos la
propuesta metodolgica;

13
4. Definir un marco referencial integrado, claro y eficaz, con base en el uso de los
patrones, su taxonoma, organizacin, combinacin, especificacin, trazabilidad e
implementacin en el dominio de la gerencia de los procesos del negocio;
5. Proponer una metodologa sustentada en la gerencia de los procesos del negocio y el
uso de los patrones haciendo especial nfasis en la trazabilidad, seguimiento y
evaluacin de herramientas y mtodos que:
- aborden el proceso de desarrollo con formalidad y de forma sistmica,
proporcionando los modelos y las etapas exclusivamente necesarias para la
produccin de software;
- se centren en la especificacin precisa del espacio del problema;
- ayuden al analista a tomar decisiones en el proceso de modelado conceptual;
- faciliten la generacin asistida de cdigo tanto en estructura como en
funcionalidad a partir de esquemas conceptuales;
- ofrezcan libertad tecnolgica, independiente de la tecnologa subyacente a los
desarrolladores; y
- promuevan software de calidad funcionalmente equivalente a su especificacin;
6. Especificar una propuesta de desarrollo de un prototipo de bajo nivel que exprese la
metodologa en trminos de las TIC disponible.
A continuacin se presenta la justificacin de la investigacin doctoral.
1.4 Justificacin
En esta tesis doctoral se plantea la definicin de la metodologa para la gestin de los
procesos del negocio sustentada en el uso de patrones, buscando establecer las relaciones y
condiciones necesarias entre la multidisciplinaridad, el modelo de negocio complejo de las
organizaciones actuales y la ingeniera de software, a fin de obtener una buena gestin de
los procesos con apoyo de las TIC y una forma de evaluar exitosamente la gerencia de los
proceso en el marco de los intereses del negocio. Lo que corresponde con la justificacin
terica de la investigacin.

Como justificacin metodolgica de la investigacin, el proceso de Gestin Tecnolgica
requiere de esfuerzos en cualquier organizacin para buscar un cambio en condiciones
favorables y as poder realizar transferencia de tecnologas e innovaciones tecnolgicas, en
funcin de los recursos financieros y de las necesidades econmicas de cada organizacin y
pas. Esta investigacin ofrecer un conjunto de normas, estndares, lineamientos, mtodos,
herramientas y tcnicas a seguir para la gerencia de los procesos de negocio, en estas
organizaciones.

14
Desde la perspectiva institucional y social, las empresas en Venezuela toman decisiones
referentes a la tecnologa que utilizan y la gerencia de los procesos de negocio, pero sin
tener mucha conciencia de ello; se utilizan enfoques que tienden a subestimar o ignorar
aspectos importantes de la seleccin y uso de la tecnologa que compran y de los procesos
que se administran. En el marco de esta aseveracin, la justificacin institucin y social de
esta investigacin se refiere a los aportes y beneficios que tendr la empresa en cuanto a un
modelo formal a seguir para la gestin de los procesos del negocio sustentada en el uso de
patrones.
1.5 Delimitacin
Este estudio est circunscrito al rea de gerencia de procesos de negocio y los patrones de
software, dentro del contexto mundial de la realidad legal, sociopoltica, jurdica,
econmica y tecnolgica existente en las ciencias computacionales y la ingeniera de
software para el ao 2007: software libre, software abierto, computacin en red, interaccin
humano-humano asistida por el computador. Especficamente de los procesos de negocio
existentes, se toma como caso de estudio el proceso de gestin de versiones de ITIL.
Por otro lado, los resultados que arrojar la presente investigacin doctoral sern
alternativas de soluciones generales, de all que su aplicacin en reas especficas de la
ingeniera de software requerirn un estudio previo para ajustar apropiadamente estas
soluciones a las particularidades y singularidades de un dominio en especfico.
1.6 Limitaciones
Se puede apreciar, que la tecnologa aun no esta totalmente preparada para afrontar el
concepto general de gerencia de los procesos de negocio, sin embargo se inician los
esfuerzos por garantizar la disponibilidad de repositorios de informacin de patrones, pero
no una relacin taxonmica y de auditoria entre los mismos.
De tal forma que la limitacin fundamental de este estudio de investigacin doctoral es la
disponibilidad de un software que permita aplicar todo el concepto en el cual se expone la
propuesta metodolgica. En este sentido durante la ejecucin de la investigacin se realizo
la especificacin de los Casos de Uso de un Prototipo de Sistema de Gerencia de Procesos
de Negocio sustentado en el uso de Patrones, lo que permitira aplicar la metodologa
propuesta.

15
Captulo II Marco Terico

2.1 Antecedentes de la Investigacin
Para iniciar el marco terico resulta conveniente citar algunos estudios preexistentes
vinculados al tema de investigacin desde la perspectiva de la paradoja de la productividad:
1. A inicio del 2002, Win Van Grembergen, en el captulo uno de su libro:
Information Technology Evaluation Methods and Management (Win, 2002), cita
los resultados obtenidos en 2002 de un estudio realizado a diecisiete (17) pases
desarrollados durante los aos 1995 y 1999. En estos pases, los retornos de la
inversin en TIC aumentan considerablemente. Lo anterior, se produce, segn el
estudio, porque se han reconocido dos tipos de beneficios: Complementarios
Macroeconmicos y Complementarios Personales. Estos beneficios se conjugan y
contribuyen al aumento del retorno de la inversin. Sin embargo, no existe una
relacin directa entre la inversin en TIC para la gerencia de los procesos del
negocio y su retorno de inversin positivo;
2. En el mes de Septiembre del 2007, Paul Strassmann publica un artculo referente a
la importancia del retorno de inversin en las inversiones de TIC "Why ROI ratios
are now crucial to IT investment", destacando el problema planteado;
3. Para Diciembre del 2007 Alinean presenta su metodologa: "Alineans ROI
Dashboard Methodology" asociada al clculo de retorno de inversin de TIC
como una mejora asociada a los activos intangibles e indicadores de impacto
estratgico en la organizacin.
En cuanto a los antecedentes de la investigacin en el mbito de la ingeniera de software,
esta tesis se sita en el rea de trabajo de los entornos de modelado y produccin de
software orientado a objetos (OO), entre los cuales destaca el artculo A Unified Object
Topology (Tepfenhart et al., 1997).
En este artculo se propone un mapa (ver, Figura 1) sobre el cual se proyecta una serie de
tcnicas utilizadas en el desarrollo de software OO, como son: el Modelado del Dominio,
los Patrones de Diseo, los Estilos Arquitectnicos, los Marcos de Trabajo ("Frameworks")
y los Componentes de Software ("Kits") .
Los procesos de produccin de software actuales hacen uso de estas tcnicas y de las
relaciones inherentes entre ellas. Estas relaciones inducen una serie de caminos a recorrer
para la construccin de sistemas de software. Estas tcnicas se han medido y distribuido
en el mapa con relacin a los atributos de Implementacin (nivel concreto o abstracto de
programacin) y Dependencia del Dominio (independiente del dominio o especfico para
un caso particular), relacionndose unas con otras.

16
Cuando se desarrolla un sistema de software existe una gran diversidad de problemas en los
que el desarrollador debe centrarse. De forma simplificada debe: (1) analizar el dominio de
la aplicacin; (2) definir una arquitectura; (3) implementar las clases del dominio; (4)
construir un software de calidad; y (5) crear un sistema cohesivo con los elementos
obtenidos.
Este proceso puede verse como el recorrido de una serie de caminos a travs del mapa
presentado en la Figura 1. Se puede observar que en las propuestas de desarrollo de
software actuales los Patrones de Diseo actan como puente entre los Patrones
Conceptuales de los Modelos del Dominio (Elementos de Modelado) y su implementacin
(lo que en el artculo se denomina Kits).
Si se analizan los caminos existentes (a travs de los elementos que integran la Figura 1),
surge una serie de problemas con las tcnicas y las rutas que las unen. Por ejemplo, de las
rutas introducidas, el camino que une los modelos del dominio con su implementacin a
travs de los patrones de diseo presenta algunos problemas: (1) los mtodos OO existentes
no describen los dominios de forma clara y sin ambigedades; (2) la caracterizacin del
dominio del problema para el desarrollo de aplicaciones es extremadamente compleja; (3)
no se proporcionan guas precisas para el modelado del dominio; (4) los patrones de diseo
son demasiado generales y no son directamente aplicables a problemas especficos; (5) no
existe una correspondencia precisa entre los modelos del dominio, los patrones de diseo y
su implementacin (kits); (6) en la mayora de los procesos de produccin de software, la
transicin entre los modelos del dominio, los patrones de diseo y los kits se realiza de
forma manual; y (7) la estructura y el comportamiento de los patrones conceptuales se
implementa de forma ad hoc por lo que la calidad del producto de software final
depender del implementador.

Figura 1: Tecnologas relacionadas en el Desarrollo OO Actual. (Tepfenhart et al., 1997)

En la Ingeniera del Software, los patrones intentan describir soluciones que han resuelto de
forma exitosa problemas comunes del proceso de produccin de software. Algunos

17
ejemplos de patrones arquitecturales son: capas, filtros y conexiones, modelado vistas y
controles (MVC).
Los patrones (Schmidt, 1996) reflejan las estructuras conceptuales comunes a dichas
soluciones, que pueden aplicarse de forma repetida cuando se est produciendo software
(analizando, diseando, e implementando) en un contexto particular.
Representan el conocimiento y la experiencia que subyacen en muchos esfuerzos de diseo
y reingeniera de los desarrolladores, consiguiendo mayor flexibilidad y capacidad de
reutilizacin en su software. Adems, proporcionan modelos tiles, especificaciones de
cmo utilizarlos, y asunciones y restricciones sobre su utilizacin.
Facilitan la reutilizacin y el acto de compartir y re-usar el conocimiento, de forma eficaz
permitiendo a los desarrolladores aprovechar soluciones previas y adaptarlas a sus
problemas especficos. Los patrones existen en las diversas fases del desarrollo de software.
Los desarrolladores no los inventan, sino que los descubren debido a su experiencia en la
construccin de sistemas.
En cuanto a los antecedentes de la investigacin desde la perspectiva de los procesos de
negocio, existen diversas definiciones del trmino en la literatura, las cuales entran en
conflicto a menudo, as solamente se consideraran en esta investigacin las ms
influyentes:
Moore y Whinston (1996) proponen una visin de procesos como colecciones de
modelos de decisin. Segn estos autores, los procesos son identificados por los tipos
de decisiones implicadas en ellas y contienen una secuencia de tareas. Estas tareas son
las unidades identificables ms pequeas del anlisis. Es preciso citar que su
configuracin ptima es el factor de diseo crtico que afecta la eficacia de las
organizaciones en funcin de estos procesos,
En 1998 Davenport define un proceso de negocio como "la organizacin lgica de la
gente, materiales, energa, equipo y procedimientos en las actividades del trabajo
diseadas para producir un resultado final especifico",
Por otra parte, Hammer y Champy (1996), definen proceso de negocio como un
"sistema de actividades que, juntas, producen un resultado que da valor a un cliente",
Alternativamente, Earl (1996) define proceso de negocio como una "forma lateral u
horizontal que encapsula la interdependencia de las tareas, de los papeles, de la gente,
de los departamentos y de las funciones requeridas para proveer a un cliente un
producto o un servicio".
En el mbito de los procesos de negocio la solucin tecnolgica por excelencia se refiere al
trmino flujo de trabajo o workflow, proceso a travs del cual las tareas de los individuos
son coordinadas para completar una transaccin (usando los procesos del negocio
definidos) dentro de una organizacin (Davenport, 1998).

18
El workflow es un conjunto de mecanismos que automatizan ciertos procesos de trabajo.
Estos mecanismos relacionan entre s los aspectos de la administracin, establecen
prioridades entre las diversas tareas de cada empleado y optimizan las comunicaciones
entre las distintas unidades operativas. (White, 1996).
Para que eso se logre es necesario definir cules son las distintas tareas que se realizan en
una organizacin; quienes participan en su ejecucin; quines son responsables de las
mismas; cul es la secuencia de procesos de cada tarea y cules son las acciones que inician
cada proceso (Shcmidt, 1990).
Aunque la contribucin de los flujos de trabajo tradicionales de produccin, ad hoc,
administrativos y colaborativos, es an notable, hay una nueva generacin que quizs sea
un hbrido que rene lo mejor de todos los sistemas de workflow y otras tecnologas: los
BPMS, los cuales son sistemas que integran las facilidades de flujo de trabajo en una
arquitectura orientada a servicios, con modelaje y simulacin de procesos y generacin
asistida de aplicaciones.
Como las empresas cada vez ms se estn orientando hacia los procesos, destacndose
principalmente por el e-Business, esta nueva generacin de aplicaciones supera las
limitaciones anteriores, conocidas en los 90, incorporando amplias capacidades de
integracin con modernas arquitecturas Java, .Net y XML, principalmente. (Bonillo,
2007b)
Adicionalmente, se les estn sumando otras tecnologas como Servicios Web, Motores de
Reglas de Negocio y Monitoreo de las Actividades del Negocio (BAM-Business Activity
Monitoring). De acuerdo con Howard Smith y Peter Fingar, avalados por la BPMI
(Business Process Management Initiative) y el WFMC (WorkFlow Management Coalition),
hoy en da se puede sealar que los BPMS permiten a las empresas modelar, implementar
y gestionar los procesos de negocio, que abarcan mltiples aplicaciones empresariales,
departamentos, y proveedores partners, detrs de los cortafuegos y sobre Internet.
Cada vez ms los BPMS, van adquiriendo mayor importancia en las empresas de todos los
sectores. Principalmente porque las empresas saben que todos los recursos bien integrados
y orquestados permiten una verdadera agilidad. Las empresas se han dado cuenta que
aunque han hecho grandes inversiones en Sistemas, Aplicaciones y Tecnologas, an no
han alcanzado la flexibilidad y agilidad que se requiere hoy en da. Mirando un poco el
avance de esta tecnologa, el desarrollo y uso de los sistemas de workflow ha
evolucionado desde simplemente automatizar el enrutamiento de actividades entre
personas, a coordinar los procesos de negocio utilizando todos los recursos. (Hayward,
2003).
2.2 Bases Tericas
A continuacin se presentan los fundamentos para la investigacin, donde tendrn
relevancia los procesos de desarrollo de software, la construccin de software basado en

19
componentes, taxonoma de patrones y su relacin con la calidad de software y gestin de
los procesos del negocio e ITIL.
2.2.1 Procesos de Desarrollo
En los ltimos aos se han estudiado entre otras, dos corrientes en lo referente a los
procesos de desarrollo de software, los llamados mtodos pesados y los mtodos giles. La
diferencia fundamental entre ambos es que mientras los mtodos pesados intentan
conseguir el objetivo comn por medio de orden y documentacin, los mtodos giles lo
hacen mejorando los procesos de comunicacin directa e inmediata entre las personas que
intervienen en el proceso. Los mtodos de desarrollo de software considerados en esta
investigacin, son: Unified Processs (UP) como mtodo pesado, XP (eXtreme
Programming Project) y FDD (Feature Driven Development) en el caso de los mtodos
giles.
En cuanto a estos procesos de desarrollo de software, se tiene que si el proyecto es
suficientemente grande como para compensar la adaptacin, se puede decir que UP es una
buena base, ya que permite conseguir una mayor y mejor estructura y disciplina del proceso
de desarrollo. Una buena posibilidad de reducir el trabajo a realizar es la reutilizacin de
modelos, procesos, etc. ya definidos en implementaciones previas de UP en distintos
mbitos.
Con relacin a la arquitectura, XP con las metforas del sistema, intenta determinar una
arquitectura ptima en etapas tempranas del desarrollo. FDD, an cuando se centra en la
calidad, deja todo el peso de las decisiones arquitecturales al arquitecto principal, pero no
especifica como estas decisiones tienen relacin con la calidad del sistema en desarrollo.
Por otra parte, se tiene un problema generalizado para todos estos procesos de desarrollo: la
seleccin de la arquitectura adecuada o combinacin de diferentes estilos arquitecturales
para un sistema de software es un problema que an no ha sido resuelto y que se ha tratado
ampliamente en la literatura. El crecimiento de la complejidad de los sistemas, construidos
usualmente a travs de la integracin de componentes, incrementa la necesidad de obtener
enfoques ms rigurosos que conduzcan este proceso de decisin.
Todos los procesos de desarrollo, tienen ausencia de una clara relacin entre los patrones,
los componentes, la arquitectura y las caractersticas de calidad asociadas a la misma, UP
por su parte, no tiene una asociacin de los requerimientos no funcionales con los casos de
uso, una mala seleccin de los principales casos de uso afecta la arquitectura del sistema, el
modelo de prueba utilizado para evaluar la arquitectura no tiene guas precisas para
determinar esta relacin. (Losavio et al., 2004).
Una vez especificado el contexto de uso de la metodologa, seguidamente se aborda el tema
de la construccin de software basado en componentes.

20
2.2.2 Construccin de Software Basado en Componentes
Cuando se habla de componentes, se pueden encontrar algunas definiciones relacionadas
con la implementacin, donde estn aquellas que entienden por componente un paquete
coherente de cdigo que: (i) puede ser desarrollado y distribuido independientemente, (ii)
tiene interfaces explcitas y bien especificadas para el servicio que ofrece, (iii) tiene
interfaces explcitas y bien especificadas para el servicio que espera de otros componentes,
y (iv) puede ser compuesto junto con otros componentes, quizs extendiendo alguna de sus
propiedades, pero sin modificar al componente propiamente dicho (Dsousa et al., 1999).
Una definicin ms general la ofrecen Jacobson, Griss y Jonsson (1997) y que es la que se
considera para esta investigacin, quienes lo definen como un artefacto que ha sido
desarrollado especficamente para ser reutilizado. En este caso un componente podra ser
tanto un caso de uso como cualquier otra entidad reutilizable que surja durante el proceso
de desarrollo y que sea utilizado en cualquier actividad, siempre que no requiera
conocimiento del software que lo utiliza.
Los objetos COM y los JavaBeans son ejemplo de tecnologas de componentes. Los
componentes pueden ser objetos en el sentido usual de OO, excepto que satisfacen guas
adicionales dirigidas a hacerlos auto-contenidas. Usan otras componentes mediante
agregacin y por lo general interactan con otras componentes a travs de los eventos
(Braude, 2003).
La construccin de software basado en componentes persigue tres objetivos principales: la
reutilizacin, la adaptacin y la extensin (la reutilizacin implica la adaptacin y la
extensin):
1. Un componente es reutilizable en la medida en que sus servicios pueden ser utilizados
por otro componente.
2. Un componente es adaptable si su proveedor ha previsto los posibles cambios que
puede sufrir dicho componente.
3. Un componente es extensible si su proveedor proporciona los mecanismos para
modificar los servicios que ofrece el componente.
De acuerdo con el objetivo que se persiga, los componentes en las diferentes fases del
proceso de desarrollo de software pueden ser desarrollados de acuerdo con los aspectos que
se mencionan en la Tabla 1.
Con relacin a la obtencin de requisitos, tres son los aspectos principales:
1. El anlisis vertical, centrado en un dominio o un rea de negocio concreta; cuyo
objetivo es que los componentes resultantes puedan convertirse en estndares para
cualquier aplicacin desarrollada posteriormente en ese dominio y que apunte hacia
su reutilizacin (Szyperski, 1997);
2. El anlisis horizontal, realizado de forma genrica para dar servicio a un amplio
rango de aplicaciones, sin restringirse a un dominio de negocio dado; y

21
3. Anlisis especfico, realizado en un dominio concreto (Allen et al., 1998), para
obtener componentes ad hoc donde el nfasis no se hace tanto en la reutilizacin
sino ms bien en la extensin.
Objetivo
Fase
Reutilizacin Extensin Adaptacin
Obtencin de
Requisitos
- anlisis vertical
- anlisis horizontal
- anlisis especfico


Particin en
componentes

- casos de uso
- patrones
- entidades del
dominio
- componentes
Existentes
- previsin de cambios


Interaccin de
Componentes
- empaquetar

- herencia
- interfaces
- agregacin

- parametrizacin
- patrones de
diseo
- programacin
adaptativa
- relacin/clase de contexto
Tabla 1 Fases del Proceso versus Objetivos de la Construccin de Software Basado
en Componentes. (Gamma et al., 1995)

La utilizacin de los enfoques depende de lo que se desea realizar con el diseo del
componente dentro del dominio, si se busca la extensin se debe utilizar el anlisis
especifico, si se desea la reutilizacin se debe integrar el enfoque vertical para los
elementos especficos del dominio y el aspecto horizontal en relacin al comportamiento
del componente con el resto de las aplicaciones del dominio, teniendo en cuenta la
particularidad del diseo sin perder de vista las interacciones del componente con otras
aplicaciones, finalmente si se desea observar la extensin y la reutilizacin se debe realizar
una integracin sistmica entre el enfoque especifico, vertical y horizontal.
Durante la obtencin de requisitos se han identificado todas las funcionalidades que deben
ser soportadas, pero la distribucin de dichas funcionalidades puede darse de inmediato, o
puede construirse adaptando los componentes existentes. La particin de componentes
puede realizarse a travs de: los casos de uso, los patrones de diseo, las entidades del
dominio, la evolucin prevista del sistema; y, los componentes ya existentes.
Con relacin a la interaccin de componentes, se dice que es directa (interaccin simple)
cuando el servicio ofrecido se ajusta a las formas y necesidades del servicio requerido. Si
las formas no son las adecuadas, es necesario realizar previamente un proceso de
empaquetamiento (wrapper). Esta situacin se presenta, por ejemplo, cuando se quiere
reutilizar la funcionalidad soportada por sistemas legacy donde la forma de interactuar no
es la ms adecuada. En este caso, el sistema "legacy" se empaqueta dentro de un software
que le da apariencia de componente (Allen et al., 1998).

22
Por otro lado, si el problema es cierto desajuste entre las necesidades solicitadas y las
necesidades ofrecidas, se tendr que recurrir a la adaptacin o a la extensin del
componente; para esto, los mecanismos ms comunes son: (i) Herencia cuando una clase o
un caso de uso del componente define un comportamiento que quien reutiliza dicho
componente hereda, y adems aumenta aadindole sus propias caractersticas especficas
(Jacobson et al., 1997); (ii) Interfaces, cuando se definen interfaces sin implementar o con
una implementacin por defecto, y quien reutiliza el componente define su propia
implementacin (Larsen, 1999); (iii) Agregacin, el componente a reutilizar ofrece una
clase que puede ser extendida creando una nueva clase que contiene instancias de la
primera; y, (iv) Glue Component, este componente acta como intermediario de un
conjunto de componentes con el resto del sistema, extendiendo la funcionalidad del grupo
de componentes (Dsousa et al. 1999).
En el caso de la adaptacin los mecanismos ms utilizados son: (1) parametrizacin, en los
casos ms comunes, se definen parmetros o macro expresiones, el componente
parametrizado ser especializado asignando un valor real al parmetro (Jacobson et al.,
1997); (2) patrones de diseo, utilizar patrones para resolver problemas de diseo
recurrentes al disear lgica de negocio extensible; (3) programacin adaptativa, aqu el
comportamiento no est implementado de forma exhaustiva y adems se define un patrn
de propagacin que proporciona un conjunto de restricciones que deben cumplir los
programas de la familia denotada por el programa adaptativo; y, (4) relaciones y clases de
contexto, en una relacin de contexto se relaciona una clase base con varias clases de
contexto. Estas no heredan de la clase base, ni se consideran subclases, sino que definen
atributos y mtodos para sus instancias.
Seguidamente se estudian los diferentes tipos de patrones que han surgido a travs de la
Ingeniera de Software a fin de establecer sus relaciones y una clasificacin general.
2.2.3 Taxonomas de Patrones
Actualmente, el uso de patrones en el proceso de produccin de software es uno de los
temas ms tratados, generando un gran inters entre investigadores y desarrolladores. Un
patrn captura la experiencia y conocimiento de expertos, quienes han producido
soluciones exitosas a problemas, a fin de que esas soluciones queden a disposicin de
personas con menos experiencia; sin embargo, los patrones no proveen siempre las
soluciones definitivas, algunas veces, los usuarios de patrones deben tener creatividad para
utilizar, instanciar o implementar un patrn.
Los patrones pueden aplicarse a nivel del: anlisis de requisitos, el diseo de la
arquitectura, el diseo detallado, la interaccin con el usuario, el flujo de trabajo y el
cdigo. Con lo que puede establecerse la siguiente clasificacin:
Patrones de anlisis: Los patrones de anlisis son grupos de conceptos que representan
una construccin comn en el mundo del modelado conceptual. Pueden ser relevantes a
un dominio o ser adaptados a muchos dominios. La idea central es la construccin de

23
escenarios utilizando patrones. Se pretende tener una visin ms conceptual y
estructural de las situaciones, con el fin de identificar la naturaleza intrnseca de las
mismas. Con esa visin, es posible determinar el tipo de escenario correspondiente a
cada situacin y as, elegir un patrn de un catlogo, re-usando su estructura con el fin
de derivar el escenario ms fcil y directamente. Los patrones de anlisis consisten en
un texto gua, que para cada componente del escenario incluye pautas acerca del
contenido que deber tener dicho componente. Por ejemplo el patrn de anlisis para
realizar una actividad productiva es aplicado al escenario de diseo de una agenda de
reuniones de tal forma de reutilizar las caractersticas de una actividad productiva en el
dominio especfico de una agenda de reuniones. Los patrones de Flujo de Trabajo
(Bonillo, 2005c) son escenarios de los patrones de anlisis descritos en el Anexo 1.1,
por lo que no se mencionan en la taxonoma.
Patrones de arquitectura (Arquitecturales): Son esquemas fundamentales de
organizacin de un sistema software. Especifican una serie de subsistemas y sus
responsabilidades respectivas e incluyen las reglas y criterios para organizar las
relaciones existentes entre ellos. Algunos ejemplos son: capas, filtros y conexiones;
modelos, vistas y controles (MVC).
Estilos Arquitectnicos: representan una generalizacin de los patrones de arquitectura,
dado que expresan los componentes y las relaciones del esqueleto estructural y general
de una aplicacin independiente del contexto y de otros estilos, son una categorizacin
de sistemas. Algunos estilos tpicos son las arquitecturas basadas en flujos de datos, las
de invocacin implcita, las jerrquicas, las centradas en datos o en intrprete-maquina
virtual.
Patrones de diseo: Son patrones de un nivel de abstraccin menor que los patrones de
arquitectura. Estn por lo tanto ms prximos a lo que sera el cdigo fuente final. Su
uso no se refleja en la estructura global del sistema. Por ejemplo: abstract factory,
constructor y chain responsability.
Patrones de Interaccin: tambin conocidos como Patrn de Interfaz, describe una
solucin exitosa a un problema recurrente concerniente a la interfaz de usuario, en un
contexto dado. Un Patrn de Interaccin es un medio de comunicacin que se expresa
en una notacin sencilla, a fin de ser entendida por las personas del equipo de diseo de
la interaccin que generalmente es multidisciplinario. Algunos ejemplos son: formatos
de datos de fechas y representacin visual jerrquica del estado del sistema.
Patrones de Implementacin: Se refieren a la forma de programar o implementar una
solucin en un lenguaje especfico, se asocia con los trminos en ingls kit e Idiom.

En el Anexo 1, se describen con mayor detalle cada uno de los patrones antes mencionados.
A partir de esta descripcin, es preciso notar que lo que diferencia a los tipos de patrones
entre s, est relacionado con su nivel de abstraccin (patrones aislados versus familias

24
lenguajes o catlogos de patrones). Esta clasificacin, basada en lo planteado por
Bushmann et al. (1996), se resume en la Figura 2 que se muestra a continuacin.



Figura 2. Diferentes tipos de Patrones y su Relacin (Bonillo, 2008)

En general los patrones tienen una limitacin: son difciles de especificar y evaluar en base
a un modelo de calidad particular, por lo que el estudio de los temas de ADL (Architecture
Definition Language) y ABAS (Atribute-Based Architecture Styles), como estructuras que
extiende la representacin dada por el Grupo de los Cuatro (GoF) con la finalidad de
especificar la informacin sobre los patrones y las caractersticas de calidad relativas, se
consideran relevantes y fueron especificados para esta investigacin doctoral inicialmente
como anexo y luego como un articulo de investigacin. (Bonillo, 2006a)
De acuerdo a todo lo anterior, las descripciones de GoF pueden ser extendidas utilizando
ABAS como un estilo y no una tcnica (forma eficiente y eficaz de utilizar una
herramienta), de tal forma de expresar las caractersticas relacionadas con la calidad. La
relacin entre los aspectos tericos desarrollados se puede resumir como se muestra en la
Figura 3.

25


Figura 3. Relacin entre las bases tericas (Bonillo, 2008)
Con la finalidad de incorporar el concepto de ABAS en la taxonoma de patrones expuesta
con anterioridad y tomando como referencia la representacin de patrones de interaccin en
base a un metapatrn propuesto por Acosta y Zambrano (2004), a continuacin se obtiene
la siguiente representacin extendida:

Nombre (ttulo), autor
clasificacin, dominio
(usos conocidos) y rango.
Nombre: Idea Central por la cual se identifica el patrn.
Autor: Nombre de la persona que cre el patrn.
Clasificacin: Se refiere al tipo de patrn de acuerdo a la taxonoma antes
mencionada.
Dominio: Indica el o los dominios en los cuales el patrn ha sido
implementado.
Rango: es el grado de confiabilidad de este patrn con respecto a los
dominios en los cuales ha sido implementado.
Problema Describe el problema que ser resuelto, desde el punto de vista del usuario.
Solucin Describe, en una forma narrativa y grfica, la solucin al problema. Con base
en: Objetivo, Intencin, Motivacin, Actores o Participantes, Recursos,
Estructura, Episodios, Colaboraciones e Implementacin.
Atributos de Calidad Atributos de calidad de inters, el contexto de uso, contrastes y atributos
relevantes (requerimientos especficos).

26
Medidas de atributos de
Calidad
Un resumen de lo que es discutido en la descripcin del problema, usando
trminos especficos relacionados con aspectos medibles de los atributos del
modelo de calidad. Esto incluye una discusin de los eventos que pudieran
hacer que la arquitectura responda o cambie.
Parmetros de atributos de
Calidad
Un resumen de lo que ser discutido en la seccin de solucin, pero
especificando trminos relevantes a los parmetros de los atributos
especificados en el modelo de calidad.
Anlisis del Modelo de
Calidad
Una descripcin de cmo los atributos del modelo de calidad sern
relacionados formalmente con los elementos del patrn y las conclusiones
sobre la conducta arquitectural que se obtiene con el modelo.
Contexto Presenta las condiciones bajo las cuales el patrn es utilizado.
Fuerza Conflictos que pudiesen restringir la solucin. Incluyendo las excepciones.
Consecuencias Describe el resultado de aplicar el patrn.
Ejemplos/Contra-ejemplos Muestra ejemplos y contraejemplos de la solucin propuesta.
Patrn Relacionado Otros patrones que se relacionan con el patrn descrito.

Tabla 2 Metapatrn adaptado de Acosta, Zambrano (2004) y Kazman, Klein (2004)
Es importante citar que la usabilidad del patrn indicada en la representacin de Acosta y
Zambrano (2004) es, en este caso, un atributo de calidad. Adems un patrn no requiere,
generalmente, todos los elementos antes mencionados, a fin de cumplir su objetivo, un
patrn debe tener como mnimo los siguientes elementos: Nombre, Problema, Solucin,
Contexto y Fuerzas.
2.2.4 Gerencia de los Procesos del Negocio
La Gerencia de Procesos del Negocio es el trmino general para los servicios Web y las
herramientas que apoyan los procesos de forma explcita (tales como el anlisis, definicin,
ejecucin, supervisin y administracin de procesos), incluyendo la interaccin humano-
humano asistida por el computador.
El desarrollo de servicios Web y los lenguajes de integracin basados en XML ha permitido
el desarrollo de patrones para los procesos de negocio. En consecuencia, la Gerencia de los
Procesos del Negocio (por sus siglas en ingles Business Process Management) abarca la
Integracin de los Procesos de Negocios (BPI) y por lo tanto la Integracin de las
Aplicaciones Empresariales (EAI). (Ver, Figura 4).

27

Figura 4: La evolucin de EAI/BPM. (Vollmer et al., 2004)
Los usos de BPM permiten a las compaas implementar y administrar procesos a travs de
unidades de negocio tanto internas como externas y sus relaciones. Segn Giga (Vollmer et
al., 2004) "La gerencia de proceso del negocio se refiere a disear, ejecutar y optimizar los
procesos funcionales del negocio a travs de toda la organizacin incorporando los
sistemas, a los procesos y a la gente". Forrester (Harris et al., 2003) definen BPM como
"integracin caracterizada por flujo de trabajo orquestado, orientado a aplicaciones a travs
de usos internos mltiples y/o entre los socios externos". Los BPMS consisten en dos
elementos: (1) el diseador de procesos; (2) y el motor de proceso.
Las capacidades de los Servicios Web permiten a las herramientas de BPM apoyar la
ejecucin del proceso de forma automatizada. Vollmer et al. (2004) discuten que la puesta
en prctica de las soluciones de BPM ha emergido como estrategia dominante, que las
organizaciones estn adoptando para mejorar la eficacia de sus procesos del negocio.
Las herramientas de BPM son capaces de apoyar este tipo de actividad debido a su
capacidad de coordinar interacciones entre: (1) los sistemas de informacin; (2) los
procesos del negocio, y; (3) la gente que los utiliza. Esto da visibilidad de las empresas en
el estado de los procesos y tiende a permitir cambios de los procesos sobre una base en uso.
En la Figura 5 se presenta la arquitectura que soporta los BPMS, en la base inferior se
encuentra la capa de integracin de datos (bases de datos distribuidas, replicacin de datos,
extraccin transformacin y carga de datos, integracin de la informacin de la empresa,
intercambio electrnico de datos y los elementos de dato como tal), a continuacin la capa
de integracin de aplicaciones (modelo de objetos cannico y distribuido, integracin de
aplicaciones empresariales y las aplicaciones), seguidamente la capa de integracin de la
presentacin (portales, dispositivos de presentacin y adaptacin de aplicaciones a

28
dispositivos mviles) y finalmente la capa de integracin de los procesos (BPM y flujo de
trabajo)


Figura 5: Arquitectura BPM. (Vollmer et al., 2004)
En la Iniciativa para la Gerencia de los Procesos de Negocio (BPMI, hoy por hoy unida a la
OMG), se definen especificaciones estndares y abiertas, tales como la notacin en la que
se modelan los procesos del negocio (BPMN) y el lenguaje de consulta de procesos
(BPQL), que permite la gerencia estndar del anlisis del proceso, basada en el negocio y a
travs de los BPMS. Los estndares en los cuales se enfoca BPMI son los siguientes (ver,
Figura 6):
1. BPML: Es el lenguaje en el que se modelan los procesos de negocio, se puede definir
como un metalenguaje para modelar los procesos. BPML proporciona un modelo
abstracto de ejecucin para los procesos de colaboracin y transaccionales, basado en
el concepto de una mquina transaccional de estado. Se ha definido como medio para
dar convergencia al uso del proceso dentro de las empresas, tanto de las transacciones
distribuidas sncronas como asncronas.
2. BPMN: Una notacin estndar para el modelaje de los procesos de negocio (BPMN),
la cual permite entender los procedimientos internos a travs de una notacin grfica
Integracin Basada en Procesos
Gerencia de Procesos de Negocio Flujos de Trabajos
Presentacin de Integracin
Anfitrin (Host): Presentacin Adaptadores Moviles Portales
Integracin de Aplicaciones
Objetos Distribuidos
Integracin de las Aplicaciones Empresariales
Anfitrion (Host): Aplicacin
Integracin de Datos
Bases de Datos
Distribuidas
Integracin de
Informacin Empresarial
Extraccin , Carga
y Trasformacin
Replica de Datos Anfitrin (Host):
Datos
Integracin de Datos
Empresariales

29
(Business Process Diagram-BPD-) permitiendo la comunicacin de estos en una
forma estndar. Esta notacin facilita adems el entendimiento de las colaboraciones,
del rendimiento y de las transacciones, permitiendo la reutilizacin. Establece una
relacin entre los elementos grficos y los constructores de los bloques estructurados
del lenguaje de ejecucin de procesos (BPEL), incluyendo BPML y BPEL4WS
(BPEL para servicios Web).
3. BPSM: Es un "framework" conceptual que incluye patrones arquitecturales y de flujo
de trabajo para BPM.
4. BPXL: Es un estndar del BPMI para extender BPEL4WS a fin de que pueda
manipular transacciones, reglas de negocio, administracin de tareas e interaccin
humano-humano asistida por el computador.
5. BPQL: Es una interface para administrar la infraestructura de los procesos de negocio
que incluye facilidades de ejecucin de procesos (Process Server) y facilidades para
el desarrollo de procesos (Process Repository). Esta interface permite a los
analistas de proceso revisar el estado de los mismos y controlar su ejecucin, se basa
en el protocolo simple de acceso a objetos (SOAP). La utilidad correspondiente al
repositorio permite implementar procesos desde el administrador de modelos y est
basada en el protocolo de autorizacin de versionamiento distribuido (WebDAV). La
administracin de las interfaces BPQL puede ser expuesta a travs de servicios UDDI
(Universal Description, Discovery and Integration) a fin de registrar los procesos,
adquirir y descubrir los mismos en un catlogo de servicios web.
6. BPEL: (Business Process Execution Language) es un lenguaje basado en XML
diseado para compartir tareas en ambientes distribuidos incluso a travs de
mltiples organizaciones- usando una combinacin de servicios Web. Escrito por
desarrolladores de BEA Systems, IBM y Microsoft, BPEL combina y substituye
IBM's WebServices Flow Language (WSFL) y la especificacin Microsoft's XLANG.
(BPEL es tambin conocido como BPELWS o BPEL4WS). Usando BPEL, un
programador describe formalmente un proceso del negocio que ocurre a travs de la
Web de tal forma que cualquier entidad pueda realizar unos o ms pasos en el proceso
de la misma manera.
7. WS-CDL: Es un lenguaje de descripcin de coreografa de servicios, este lenguaje
est basado en XML y describe las colaboraciones entre las entidades a travs de un
punto focal con un comportamiento comn y complementario, donde el orden del
intercambio de mensajes se determina a partir de los objetivos del negocio. Esta
especificacin de servicios Web ofrece un puente de comunicacin entre los
ambientes computacionales heterogneos.

30


Figura 6: estndares BPM segn BPMI
Gartner (2005), propone un conjunto de criterio que permiten evaluar las arquitecturas de
BPM, estos son: (1) Herramientas grficas diseo, anlisis, modelado y definicin de
procesos.; (2) Motor de la ejecucin (run-time), mquina de estado que ejecuta el flujo de
proceso definido. El motor puede invocar los servicios o las tareas automatizadas que el ser
humano tiene que terminar. Los servicios se pueden proporcionar a travs de la arquitectura
de servicios y por otros proveedores (outsourcers); (3) Agilidad, implica la disponibilidad
de realizar cambios a los procesos en ejecucin, la administracin de la lista de tareas y las
prioridades del trabajo; (4) Herramientas para supervisar y para administrar flujos, incluye
el funcionamiento de los procesos, el grado de terminacin o las condiciones de
finalizacin. Puede tambin cubrir los elementos que produjeron la finalizacin del
proceso, compensacin, balanceo de carga y transferencia, y; (5) Herramientas para el
control de gestin a travs de los datos almacenados que permiten las mediciones y los
ajustes (control de proceso estadstico BAM) del negocio.
De acuerdo a esto, los requisitos funcionales con los que debe cumplir una aplicacin de
BPM, son los siguientes:
1. Anlisis de procesos de negocio (BPA): se refiere a cuales procesos deben ejecutarse
y cmo estos estn estructurados, lo que implica las actividades de administracin del
modelo de procesos, actualizacin de formas, modelo organizacional (roles, grupos,

31
usuarios, departamentos, localidades, etc.), especificacin de flujos, interfaz grfica
amigable y manejo estructurado de procesos.
2. Business Rule Engine (BRE): incluye las actividades de configuracin de usuarios,
configuracin de reas y localidades, asignacin de responsables, tipos de casos y
tipificaciones, reglas de notificacin y escalamientos, deteccin de solapamientos,
configuracin de mecanismos de notificacin, manejo de soluciones, modelos de
acuerdos de servicio y capacidad para el manejo de excepciones.
3. Generacin de cdigos: se refieres las actividades de especificacin de estndares,
integracin con tecnologas EAI, integracin con herramientas de anlisis,
arquitectura WEB, soporte de arquitectura de servicios, compilacin de procesos,
soporte a procesos de larga duracin, compensacin y reverso de transacciones,
manejo de colas, manejo de versiones, generacin del flujo de trabajo, optimizacin
de lista de trabajo y soporte e interaccin.
4. Integracin y Colaboracin: incluye las actividades de actualizacin y modificacin
de procesos, control de configuraciones, desactivacin y activacin de procesos,
exportacin de datos, exportacin de procesos, gestin de histricos, gestin de
procesos, importacin de datos, importacin de procesos, migracin de flujos de
trabajo, administracin de usuarios, facilidades de comunicacin, reportes y
administracin.
5. Monitoreo de las Actividades del Negocio (BAM): incluye las actividades de
monitoreo de procesos en ejecucin, consola flexible de presentacin grfica
(Dashboard), manejo de eventos y capacidad de anlisis.
6. Interfaz de Aplicacin: incluye las actividades de administracin de patrones de
eventos de interaccin, administracin de patrones de interfaz, mantenibilidad de la
interfaz y usabilidad de la interfaz.
7. Optimizacin: incluye las actividades de manejo de escenarios, administracin y
manejo de servicios y administracin y manejo de interfaces.
Segn Gartner (Bell y Sinur, 2003), los vendedores principales estn proporcionando
soluciones propietarias de tecnologas y no estndares las cuales carecen generalmente de la
agilidad ofrecida por la utilizacin de lenguajes de patrones y procesos tales como BPEL,
estos vendedores intentan crear los flujos de trabajo pequeos que se pueden utilizar en
contextos ms generalizados, pero dejando a un lado la usabilidad.
Esto conlleva a la necesidad un marco referencial que integre estos conceptos, relacin que
se describe a continuacin.



32
2.2.5 Relacin entre el Uso de patrones y BPM

En base a todo lo antes descrito, sobre BPM, y los aspectos tericos resumidos a travs de
la Figura 3, se propone un marco referencial integrado (ver, Figura 7) a fin de sortear todos
los problemas planteados a travs de esta investigacin.
La Figura 7 muestra, segn el nivel de abstraccin cmo los estndares propuestos por el
BPMI y OMG se relacionan con la taxonoma de patrones. Adems de la representacin de
la arquitectura BPM integrada a travs de un ADL (una arquitectura en que los patrones se
expresan a travs de componentes, las aplicaciones a travs de componentes y patrones y
los procesos a travs de las aplicaciones y los patrones; todo esto en el marco de una
metodologa de desarrollo de software). La medicin y trazabilidad se logra a travs de la
posibilidad de dotar a los patrones de especificaciones de calidad con el uso de ABAS, en
el marco de un modelo de calidad (ISO9126 para la calidad del producto e ISO14598 para
la calidad del proceso).

Figura 7: Marco Referencial para BPM sustentada en el uso de Patrones. (Bonillo, 2008)


33
Para la implementacin de la metodologa que se propone a travs de esta tesis doctoral, es
necesario la seleccin de un proceso caso de estudio, el cual en este caso se corresponde
con el proceso de Gestin de Versiones de ITIL, por lo que a continuacin se describen los
procesos principales de ITIL.
2.2.6 Librera de Tecnologa de la Informacin (ITIL)
ITIL son las siglas en ingls para Librera de Infraestructura de Tecnologas de
Informacin, que no es ms que una serie de documentos que definen un marco de trabajo
de las mejores prcticas que permiten ofrecer servicios de Tecnologas de Informacin y
Comunicacin de mayor calidad, en cualquier empresa que utilice la tecnologa. Este marco
de trabajo cubre diferentes reas, pero su principal enfoque est en la Gerencia de los
Servicios de Tecnologa de Informacin.
ITIL separa la Gerencia de los Servicios de Tecnologa de Informacin en 2 sub-reas:
Entrega de Servicio (Services Delivery) y Soporte de Servicio (Services Support).
Dentro de cada una de estas sub-reas ITIL define los procesos relacionados a ellas de la
siguiente forma:
Entrega de los Servicios (Services Delivery):
Gestin de Nivel de Servicio (Service Level Management): El objetivo ltimo de la
Gestin de Niveles de Servicio es poner la tecnologa al servicio del cliente. La
tecnologa, al menos en lo que respecta a la gestin de servicios de TI, no es un fin en s
misma sino un medio para aportar valor a los usuarios y clientes. La Gestin de Niveles
de Servicio debe velar por la calidad de los servicios de TI alineando tecnologa con
procesos de negocio y todo ello a unos costos razonables. Para cumplir sus objetivos es
imprescindible que la Gestin de Niveles de Servicio: Conozca las necesidades de sus
clientes. Defina correctamente los servicios ofrecidos. Monitoree la calidad del servicio
respecto a los objetivos establecidos en los Niveles de Acuerdo de Servicio (SLA).
Gestin de Disponibilidad (Availability Management): El objetivo del proceso de
Gestin de la Disponibilidad es optimizar la capacidad de la infraestructura de TI y la
organizacin de soporte para la entrega de un nivel sostenido de disponibilidad que
permita al negocio satisfacer sus objetivos. Esto se alcanza determinando los requisitos
de disponibilidad del negocio y equipando estos a la capacidad de la infraestructura de
TI y a la organizacin de soporte, adems se debe asegurar que se proporcione el
servicio acordado de disponibilidad.
Gestin de Capacidad (Capacity Management): La Gestin de la Capacidad es la
encargada de que todos los servicios de TI se vean respaldados por una capacidad de
proceso y almacenamiento suficiente y correctamente dimensionada. Sin una correcta
Gestin de la Capacidad los recursos no se aprovechan adecuadamente y se realizan
inversiones innecesarias que acarrean gastos adicionales de mantenimiento y
administracin, o an peor, los recursos son insuficientes con la consecuente

34
degradacin de la calidad del servicio. Entre las responsabilidades de la Gestin de la
Capacidad se encuentran: Asegurar que se cubran las necesidades de capacidad de TI
tanto presentes como futuras. Controlar el rendimiento de la infraestructura de TI.
Desarrollar planes de capacidad asociados a los niveles de servicio acordados.
Gestionar y racionalizar la demanda de servicios de TI.
Gestin Financiera (Financial Management): Aunque casi todas las empresas y
organizaciones utilizan las tecnologas de la informacin en prcticamente todos sus
procesos de negocio es comn que no exista una conciencia real de los costos que esta
tecnologa supone. Esto conlleva a serias desventajas: Se desperdician recursos
tecnolgicos; No se presupuestan correctamente los gastos asociados, y; Es
prcticamente imposible establecer una poltica consistente de precios. El principal
objetivo de la Gestin Financiera es el de evaluar y controlar los costos asociados a los
servicios de TI de forma que se ofrezca un servicio de calidad a los clientes con un uso
eficiente de los recursos necesarios. Si la organizacin de TI y/o sus clientes no son
conscientes de los costos asociados a los servicios no podrn evaluar el retorno a la
inversin ni podrn establecer planes consistentes de inversin tecnolgica.
Gestin de Continuidad de Servicios (IT Services Continuity Management): La
misin de la Gestin de Continuidad de Servicios de TI es soportar el proceso general
de Gestin de Continuidad de Negocio asegurndose de que las facilidades de TI
tcnicas y de servicio (incluidos sistemas informticos, redes, aplicaciones,
telecomunicaciones, soporte tcnico y escritorio de servicio) se puedan recuperar dentro
de los mrgenes de tiempo de negocio requeridos y acordados.
Soporte a los Servicios (Services Support):
Escritorio de Servicio (Service Desk): El objetivo primordial, aunque no nico, del
Centro de Servicios es servir de punto de contacto entre los usuarios y la Gestin de
Servicios de TI. Un Centro de Servicios, en su concepcin ms moderna, debe
funcionar como centro neurlgico de todos los procesos de soporte al servicio: (1)
registrando y monitorizando incidentes; (2) aplicando soluciones temporales a errores
conocidos en colaboracin con la Gestin de Problemas; (3) colaborando con la Gestin
de Configuraciones para asegurar la actualizacin de las bases de datos
correspondientes, y; (4) gestionando cambios solicitados por los clientes mediante
peticiones de servicio en colaboracin con la Gestin de Cambios y Versiones. Pero
tambin debe jugar un papel importante dando soporte al negocio identificando nuevas
oportunidades en sus contactos con usuarios y clientes.
Gestin de Incidentes (Incident Management): La Gestin de Incidentes tiene como
objetivo resolver cualquier incidente que cause una interrupcin en el servicio de la
manera ms rpida y eficaz posible. La Gestin de Incidentes no debe confundirse con
la Gestin de Problemas, pues a diferencia de esta ltima, no se preocupa de encontrar y
analizar las causas subyacentes a un determinado incidente sino exclusivamente a

35
restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelacin entre
ambas.
Gestin de Problemas (Problem Management): Las funciones principales de la
Gestin de Problemas son: (1) investigar las causas subyacentes a toda alteracin, real o
potencial, del servicio de TI; (2) determinar posibles soluciones a las mismas; (3)
proponer las peticiones de cambio (RFC) al proceso de Gestin de Cambios, necesarias
para restablecer la calidad del servicio, y; (4) realizar Revisiones Post Implementacin
(PIR) para asegurar que los cambios han surtido los efectos buscados sin crear
problemas de carcter secundario. La Gestin de Problemas puede ser: (a) reactiva:
analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los
mismos, y; (b) proactiva: monitorear la calidad de la infraestructura de TI y analiza su
configuracin con el objetivo de prevenir incidentes incluso antes de que estos ocurran.
Gestin de Configuracin (Configuration Management): Las cuatro principales
funciones de la Gestin de Configuraciones pueden resumirse en: (1) llevar el control
de todos los elementos de configuracin de la infraestructura de TI (CI) con el
adecuado nivel de detalle y gestionar dicha informacin a travs de la Base de Datos
Centralizada de Configuracin (CMDB); (2) proporcionar informacin precisa sobre la
configuracin de TI a todos los diferentes procesos de gestin; (3) interactuar con las
Gestiones de Incidentes, Problemas, Cambios y Versiones de manera que estas puedan
resolver ms eficientemente las incidencias, encontrar rpidamente la causa de los
problemas, realizar los cambios necesarios para su resolucin y mantener actualizada en
todo momento la CMDB, y; (4) monitorear peridicamente la configuracin de los
sistemas en el entorno de produccin y contrastarla con la almacenada en la CMDB
para subsanar discrepancias.
Gestin de Cambios (Change Management): El principal objetivo de la Gestin de
Cambios es la evaluacin y planificacin del proceso de cambio para asegurar que, si
ste se lleva a cabo, se haga de la forma ms eficiente, siguiendo los procedimientos
establecidos y asegurando en todo momento la calidad y continuidad del servicio de TI.
Las principales razones para la realizacin de cambios en la infraestructura de TI son:
(a) solucin de errores conocidos; (b) desarrollo de nuevos servicios; (c) mejora de los
servicios existentes, y; (d) normativa legal.
Gestin de Versiones (Release Management): La Gestin de Versiones es la
encargada de la implementacin y control de calidad de todo el software y hardware
instalado en el entorno de produccin. La Gestin de Versiones debe colaborar
estrechamente con la Gestin de Cambios y de Configuraciones para asegurar que toda
la informacin relativa a las nuevas versiones se integre adecuadamente en la CMDB
de forma que sta se halle correctamente actualizada y ofrezca una imagen real de la
configuracin de la infraestructura de TI. La Gestin de Versiones tambin debe
mantener actualizada la Biblioteca de Software Definitivo (DSL), donde se guardan
copias de todo el software en produccin, y el Depsito de Hardware Definitivo (DHS),

36
donde se almacenan piezas de repuesto y documentacin para la rpida reparacin de
problemas de hardware en el entorno de produccin.
Una vez descrito el marco terico que integra la tesis doctoral, a continuacin se
describe la metodologa a travs de la cual se propondr en el mbito de la gerencia de
procesos de negocio con el uso de patrones, el logro de los objetivos especficos de esta
investigacin.









37
Captulo III Metodologa

En este Captulo se describen las bases metodolgicas utilizadas para realizar el trabajo de
tesis doctoral, la metodologa constituye la mdula del plan, se refiere a la descripcin de
las unidades de anlisis, o de investigacin, las tcnicas de observacin y recoleccin de
datos, los instrumentos, los procedimientos y las tcnicas de anlisis. (Tamayo, 2000).
3.1 Tipo de Investigacin
De acuerdo al problema planteado, referido a la necesidad de proponer en las ciencias de la
computacin, en el rea especifica de la ingeniera de software una metodologa para la
gerencia de los procesos de negocio sustentada en el uso de patrones, esta investigacin
doctoral se define del tipo Proyecto Factible. La misma consiste segn la Universidad
Experimental Simn Rodrguez (1999) en: una proposicin sustentada en un Modelo
Operativo factible, orientada a resolver un problema planteado o a satisfacer necesidades en
una institucin o campo de inters nacional (p. 79).
En atencin a esta modalidad de investigacin, se introducirn tres grandes fases en el
estudio, a fin de cumplir con los requisitos involucrados en un Proyecto Factible. En la
primera de ellas, inicialmente se desarrolla un diagnstico de la situacin existente en la
realidad objeto de estudio a travs del marco terico, a fin de determinar la utilidad del uso
de la metodologa. En la segunda fase del proyecto y atendiendo a los resultados del
diagnstico, se formula un conjunto de propuestas conducentes al diseo de la
metodologa. En la tercera fase se aplica la metodologa diseada a un caso de estudio.
En esta investigacin ser necesario realizar una exploracin prctica expresada a travs de
un caso de estudio, revisando el proceso de Gestin de Versiones en el dominio de los
procesos de Soporte de Servicio de ITIL, estableciendo la realidad del fenmeno a estudiar,
recopilando informacin sobre el proceso y la factibilidad de aplicar la metodologa en el
mismo.
3.2 Diseo de Investigacin
El diseo de la investigacin que sustenta este proyecto de tesis doctoral ser el de Campo,
ya que se recolectarn datos obtenidos directamente de la realidad, lo que permitir que la
investigacin adquiera gran valor debido a la posibilidad de levantar la informacin
necesaria para el diseo de la metodologa. En la Investigacin de Campo los datos de
inters para este trabajo se reunirn en forma directa de la realidad, es decir, el fenmeno
ser estudiado en la situacin real donde se produce. Sabino, C. (2000).
El diseo de esta investigacin doctoral tambin es denominado documental, dado que se
sustentara en investigaciones de otros autores cuya fuente de informacin siempre procede

38
de documentos escritos, pues esa es la forma uniforme en que se emiten los informes
cientficos.
3.3 Poblacin y Muestra
Para Tamayo y Tamayo, una poblacin est determinada por sus caractersticas definitorias,
por tanto, el conjunto de elementos que posea esta caractersticas se denominar poblacin,
la cual es la totalidad del fenmeno a estudiar, en donde las unidades poseen una
caracterstica comn, que se estudia y da origen a los datos de la investigacin. (Tamayo,
2000).
Dado que la investigacin pretende presentar una metodologa, la muestra deber ser
definida de tal forma de poder abstraer caractersticas que permitan su aplicacin y estudio
a otras organizaciones ofreciendo conclusiones pertinentes.
La poblacin de esta investigacin doctoral se corresponde con los procesos de negocio de
las empresas actuales en diferentes dominios. Dado que esta poblacin es muy amplia es
necesario reconocer un dominio especifico como los son los procesos de Gerencia de TI
que se aplican segn el estndar internacional ITIL a cualquier organizacin.
La unidad de anlisis para esta investigacin doctoral ser un proceso en especfico de
ITIL: el proceso de Gestin de Versiones propuestos, el cual representa el caso de estudio y
la muestra de la investigacin doctoral.
Bsicamente las muestran se dividen en dos grandes ramas: las muestras no probabilsticas
y las muestras probabilsticas. En esta ltima todos los elementos de la poblacin tienen la
misma posibilidad de ser seleccionados. En las muestras no probabilsticas, la eleccin no
depende de la probabilidad, sino de las causas relacionadas con las caractersticas del
investigador o del que hace la muestra. Aqu el procedimiento no es mecnico, ni en base a
frmulas de probabilidad, sino que depende del proceso de toma de decisiones de una
persona o grupo de personas.
En particular, esta investigacin doctoral busca muestras no probabilsticas, debido a que
suponen un procedimiento de seleccin informal y un proceso arbitrario. La ventaja de este
tipo de muestra es su utilidad para un determinado diseo de estudio, que requiere no tanto
de una representatividad de los elementos de la poblacin, sino de una cuidadosa y
controlada seleccin de sujetos con ciertas caractersticas especificadas previamente en el
planteamiento del problema.
Sin embargo, hay diversas clases de muestras no probabilsticas tales como:
Muestras de sujetos voluntarios: la eleccin de los individuos que sern sujetos
dependen de circunstancias fortuitas.
Muestras de expertos: es utilizada en estudios que requieren la opinin de sujetos
expertos.

39
Sujetos tipos o Stakeholders: se utilizan en investigaciones de tipo exploratorio, donde
el objetivo es la riqueza, profundidad y calidad de la informacin, y no la cantidad y
estandarizacin.
Muestras por cuota: se utilizan en estudios de opinin y de mercadotecnia.
Para identificar todos estos factores el estudio tomara una muestra no probabilstica de la
clase de sujeto tipo o stakeholders, del proceso de Gestin de Versiones de ITIL.
El termino Stakeholders es utilizado para referirse a un grupo de individuos identificables
quienes pueden ser afectados o son afectados por un sistema.
Ciertas investigaciones sobre el uso de stakeholders describen algunos mtodos para
identificarlos: (1) realizando grupos demogrficos (sexo, edad, cargo, etc.); (2)
preguntndole a las personas, quines de ellas piensan que deben ser considerados como
principales stakeholders; (3) estudiando (o creando) cuentas etnogrficas para encontrar
quines expresan intereses pertinentes.
3.4 Tcnicas e Instrumentos de Recoleccin de Datos
Dado que el diseo de investigacin documental depende fundamentalmente de la
informacin que se recoge o consulta en documentos, entendindose este trmino, en
sentido amplio, como todo material de ndole permanente, es decir, al que se puede acudir
como fuente o referencia en cualquier momento o lugar, sin que se altere su naturaleza o
sentido, para que aporte informacin o rinda cuentas de una realidad o acontecimiento, la
tcnica e instrumento de recoleccin de datos de datos empleada en esta investigacin
doctoral ser: la revisin bibliogrfica, la encuesta, le entrevista y la observacin
descriptiva, las cuales se describen a continuacin:
Revisin Bibliogrfica: Se debe recurrir a la tcnica de revisin bibliogrfica; tanto de
libros, folletos, documentos, revistas, artculos y seminarios, los cuales vienen a
brindarle al investigador todo el soporte del marco terico, lo que significa que se
percata de todo lo escrito o que est relacionado con el tema que escogi como
investigacin. La Revisin Bibliogrfica, se utiliza como base complementaria a la
investigacin central, con el fin de recopilar y revisar todos aquellos documentos que
permitan confrontar el aspecto terico con la situacin real o prctica dentro del modelo
de evaluacin de las capacidades tecnolgicas necesarias en el mercado de la gerencia
de procesos de negocio a travs del uso de patrones. Es importante sealar que esta
revisin se efecta antes y durante la investigacin, con el objetivo de cotejar
informacin, obtener nuevas ideas, indagar la naturaleza de los datos y realizar nuevas
conclusiones.
Encuesta: Entendindose sta, como un conjunto de preguntas recogidas en un
cuestionario para conocer la opinin del pblico sobre un asunto determinado
(Encarta, 1998, p. 85). La Encuesta, ser dirigida a la poblacin seleccionada de manera
intencionada. Este instrumento sirve para obtener informacin acerca de los principales

40
aspectos que contendr la metodologa de gerencia de los procesos de negocio
sustentada en el uso de patrones, precisando los aspectos a considerar para la
elaboracin de dicha metodologa. Este tipo de instrumento, permite obtener
informacin que por lo general el individuo no suministra durante una entrevista, y que
puede ser relevante para la investigacin a desarrollar.
Entrevista: la cual consiste en la obtencin de los datos de manera verbal por parte de
un sujeto informante. Esta se caracteriza por establecer una relacin directa con el
entrevistado, quien deber suministrar la informacin solicitada en forma verbal. La
ventaja de utilizar esta tcnica, es que la persona entrevistada conversa libremente,
proporciona la informacin de manera directa y espontnea.
Observacin Descriptiva: La observacin descriptiva es la ms comn entre las tcnicas
de investigacin; la observacin sugiere y motiva los problemas y conduce a la
necesidad de la sistematizacin de los datos (Tamayo, 2000, p. 55). Esta tcnica se
utiliza en este estudio sin necesidad de contar con un instrumento de registro lo que
facilita su aplicacin en el lugar donde ocurren los hechos. En esta etapa se toman en
cuenta todos los elementos, que de una u otra forman guardan relacin con la
investigacin. Se efecta una observacin de tipo participante directa, ya que el autor
durante sus 11 aos de carrera profesional ha pertenecido a diferentes organizaciones de
gerencia de sistemas tecnolgicos y posee una certificacin formal en los procesos de
soporte de servicio de ITIL, adems de la experiencia de 6 aos en el rea de gerencia
de procesos de negocio.
3.5 Procedimiento de Anlisis de Datos
Con respecto a la medicin de los instrumentos se utilizar el juicio de expertos, sta
actividad se realiza durante todas las fases de la investigacin, a fin de someter la
metodologa, a la consideracin de Profesionales de Ingeniera de Software para facilitar el
montaje tcnico y metodolgico de los instrumentos, tanto en sus aspectos de estructura
como de contenido, con la finalidad que lo evalen pedaggicamente, de tal forma de tomar
como base sus observaciones, para hacer las correcciones que tuvieran lugar, garantizando
de esta forma la calidad y efectividad de la metodologa.
En relacin a la presentacin y anlisis de los datos se tabulan los mismos, donde cada
respuesta se expresar en trminos de frecuencias absolutas y relativas representadas en
porcentajes (%) y para aquellas preguntas de opinin se tomar en cuenta el criterio de
repeticin de contenido, con el objeto de determinar su frecuencia. Por ltimo, se elaboran
cuadros estadsticos y grficos para su mejor visualizacin, a fin de obtener informacin
para formular conclusiones y recomendaciones.

41
3.6 Metodologa a utilizar en funcin de los objetivos especficos de la investigacin
(SESL)
El procedimiento metodolgico a seguir para lograr los objetivos especficos, se constituir
en la aplicacin de una instanciacin de la metodologa Systemic Evaluation for
Stakeholder Learning (SESL) propuesta por Magnus Ramage en 1997, para los sistemas de
trabajo cooperativo (Cooperative Work): La combinacin de la tecnologa, personas, y la
organizacin que facilita la comunicacin y coordinacin necesaria para que un grupo
trabaje efectivamente con la finalidad de alcanzar un objetivo comn.
Segn SESL la construccin de una metodologa es una tarea compleja, metodolgicamente
difcil (debido a que los mtodos comnmente utilizados en los dominios son imprecisos al
ser generalizados en mltiples problemas), prcticamente confusa (los efectos del cambio
pueden verse slo despus de un largo perodo de tiempo y en diferentes sitios),
psicolgicamente compleja (los diseadores y usuarios de la metodologa deben adoptar un
estilo coprnico, cambiando desde la tecnologa en uso, hasta la organizacin) y
polticamente frustrante (al iniciar la utilizacin de la metodologa en la organizacin
empieza a verse la poca prioridad que tiene y se inician los conflictos de inters).
Debido a la complejidad de la tarea, el diseo de una metodologa depender de los
diferentes significados que tiene el trmino para diferentes personas. En el ambiente de
computacin, suele utilizarse el trmino metodologa como el estudio de un conjunto de
mtodos, herramientas y tcnicas que se asocian a la utilizacin de un sistema de
computacin con la finalidad de hacerlo mejor o los mtodos, herramientas y tcnicas
para determinar donde el sistema de computacin cumple con un conjunto de criterios o
requerimientos.
El criterio o las acciones para mejorar, pueden referirse a cuestiones de la ingeniera de
software (eficacia, el funcionamiento del sistema, en los cuales la metodologa y sus
mtodos son ms asociada como una prueba cerrada); o se puede relacionar con las mejoras
de uso, el logro de las especificaciones y requerimientos. Es por esto que el trmino
metodologa puede ser visto dependiendo del objetivo del evaluador, pero usualmente,
aislado del mundo real.
De esta forma la relacin entre la metodologa y el mundo real es poca, omitiendo los
diferentes puntos de vistas y perspectivas, y no involucrando un aprendizaje real. Una
metodologa que propone cmo sortear estas deficiencias es la SESL, para los sistemas de
trabajo cooperativo, con la finalidad de evaluar un dominio a fin de utilizar una
herramienta, implementar un mtodo o proponer una nueva metodologa, entre los cuales se
enmarca este trabajo de investigacin doctoral.
Esta metodologa propone los siguientes pasos dentro de un flujo de estados:
1. Determinar la Naturaleza del Sistema.
2. Determinar el tipo de evaluacin.

42
3. Identificar grupo de individuos que pueden ser afectados o que afectan al sistema.
4. Estudiar y Analizar preguntas claves.
5. Obtener la retroalimentacin de los resultados.
Los pasos propuestos por la metodologa SESL, se relacionan con las fases que rigen un
Proyecto Factible de la siguiente forma:
1. Diagnostico de necesidades, lo cual se realizara a travs del paso de determinacin de
la naturaleza del sistema de la metodologa SESL;
2. La Formulacin de la propuesta metodolgica, a travs de los pasos de determinacin
del tipo de evaluacin, la identificacin de los stakeholders y el estudio de las
preguntas claves de SESL, y
3. El anlisis de la factibilidad de la aplicacin de la metodologa a los procesos de
Soporte a los Servicios de ITIL como caso de estudio, lo que se corresponde con el
paso de obtencin de retroalimentacin de los resultados de la metodologa SESL.
Estos pasos se describen con detalle a continuacin:
3.6.1. Determinar la naturaleza del sistema
Como SESL es una metodologa para evaluar sistemas cooperativos (CSCW), es de vital
importancia decidir cul es el sistema a evaluar, a fin de utilizar una herramienta,
implementar un mtodo o proponer una metodologa en este dominio.
Se puede establecer a partir de estudios anteriores cmo estos sistemas son utilizados
dependiendo del contexto, la organizacin y la situacin cultural. Se debe estudiar
tericamente el sistema social el contexto dentro del cual la tecnologa se encuentra, sin
referenciar a la tecnologa como tal, ignorando el hecho de que la tecnologa cambia la
estructura organizacional y la cultura, enfocndose en el estudio inicial del sistema social o
tcnico, que es lo que el autor determina como el estudio de la naturaleza del sistema. Para
este estudio se representa el sistema del cual se quiere inferir la metodologa utilizando la
teora general de sistemas.
3.6.2. Decidir el tipo de evaluacin
Es de mucha ayuda considerar que tipo de evaluacin se va a conducir. No tener esto claro
puede invalidar los criterios del evaluador. Ramage propone seis tipos de evaluacin:
1. Evaluacin de los efectos del sistema.
2. Evaluacin formativa.
3. Evaluacin de conceptos (en proyectos de investigacin doctoral).
4. Evaluacin exclusivamente de los efectos organizacionales y partes psicolgicas del
sistema.
5. Evaluacin para la compra de nuevos productos.

43
6. Evaluacin de los efectos de un sistema CSCW en la Organizacin.
Las siguientes preguntas simbolizan la forma clsica de evaluacin: Qu pasa cuando un
nuevo sistema de computacin es introducido dentro de una organizacin?, Cmo ste
cambia el trabajo de la organizacin, sus miembros y los resultados? (tales como las
ganancias), Cmo estas tecnologas cambian de acuerdo a las necesidades de la
organizacin?.
Algunos modelos tpicos de estos estudios de evaluacin son: la investigacin de cada
pregunta y, como realizar sta dentro de la organizacin; se estudia que es lo que se esta
haciendo, y se realizan entrevistas; se estructuran las ideas en trminos de la teora
preferida y; se presenta una conclusin a los miembros de la organizacin. De esta forma se
realiza algo muy parecido a una investigacin cualitativa. Es usual que en este tipo de
investigacin el investigador/evaluador sea alguien externo a la Organizacin, normalmente
denominado consultor.
De igual forma los miembros de la organizacin realizan sus propias evaluaciones sobre el
efecto de los sistemas: los gerentes y supervisores necesitan saber que est sucediendo, para
decidir si deben realizar algn tipo de cambio.
3.6.3. Identificar los individuos (Stakeholder) que afectan el sistema
La prxima pregunta a realizar es, quines son los stakeholders y en que estn interesados.
Una simple regla es buscar a quienes afecta, dependen de o pueden influenciar al sistema, y
en que forma son afectados o influenciados por el sistema. Otra forma, es tener un grupo
representativo que en conjunto construyen un mapa de stakeholders.
3.6.4. Estudiar y Analizar: Preguntas Claves
El anlisis del sistema podra depender del estudio exacto de los mtodos utilizados y el
tipo de evaluacin realizada. Un experimento de laboratorio podra tener diferentes tipos de
relaciones entre el estudio y el anlisis etnogrfico. Nuevamente esto podra depender del
conocimiento terico del evaluador.
Una vez establecidas y analizadas las preguntas claves es necesario obtener la informacin
asociada a estas preguntas en la Organizacin, la metodologa no sugiere una tcnica en
especial sin embargo las que se utilizaran sern las indicadas como tcnicas e instrumentos
de recoleccin de datos.
3.6.5. Retroalimentacin de los resultados
La comunicacin es de vital importancia en la evaluacin: al menos indicarle a las personas
los resultados de la evaluacin y qu es lo que se ha determinado a travs de la misma. La
siguiente parte es realizar el proceso de construir la decisin con la finalidad de utilizar una
herramienta, implementar un mtodo o proponer una metodologa.
A continuacin a partir de SESL se formula la nueva metodologa.

44

Captulo IV Formulacin de la Metodologa de Gerencia
de Procesos de Negocio Sustentada en el Uso de Patrones

En este Captulo se formula la metodologa de gerencia de procesos de negocio sustentada
en el uso de patrones, aplicando los pasos propuestos por la metodologa SESL planteada
en el Captulo anterior.
4.1. Naturaleza del Sistema
Inicialmente la metodologa SESL resea que es de vital importancia decidir cual es el
sistema a evaluar o medir a fin de formular una metodologa. De acuerdo como se ha
descrito en el Captulo II Marco Terico, la presente investigacin plantea una metodologa
para la gerencia de los procesos de negocio sustentada en el uso de patrones. De tal forma
que el sistema objeto de estudio es descrito en el marco terico de esta investigacin
doctoral.
Dado que la metodologa se especificar en el dominio particular de un caso de estudio
representado por los procesos de Soporte a los Servicios propuesto por ITIL, a continuacin
se describir la naturaleza del dominio donde se ejecutan estos procesos: la organizacin de
soporte interno, la cual enmarca a la gerencia de tecnologa de la informacin y se asocia a
los procesos de soporte que brindan los operadores a los empleados de la compaa a travs
de un escritorio de ayuda (service desk, helpdesk o call center), directamente desde el
centro de atencin (utilizando las herramientas de control remoto de fallas y / o el soporte
telefnico) o en sitio enviando a un tcnico de servicio de campo, con la finalidad de
reparar tanto fallas en los computadoras personales, as como tambin en los dispositivos
asociados a la red que los empleados utilizan (servidores, impresoras de red, etc.).
Utilizando la teora general de sistemas como marco referencial para determinar la
naturaleza del sistema del dominio en el cual se propondr el caso de estudio de la
metodologa puede describirse como un conjunto de ENTIDADES caracterizadas por
poseer ciertos ATRIBUTOS, los cuales mantienen RELACIONES entre s y estn
localizados en un determinado AMBIENTE de acuerdo a un cierto OBJETIVO.
La representacin del sistema de estudio utilizando la teora general de sistemas, presenta
una utilidad prctica, ligada a la sencillez, proponiendo un enfoque top-down en su
descripcin. La metodologa que se propone en esta investigacin doctoral, est basada en
una conjuncin de los conceptos relativos a la gerencia de los procesos de negocio y los
patrones de software, la organizacin de soporte interno, los objetivos del evaluador y la
teora general de sistemas. (Bonillo, 2004a).

45
La Gerencia de los Procesos de Negocio de Soporte a los servicios propuesto por ITIL
(GPNSOP) puede ser representado en trminos de la teora general de sistemas de la
siguiente manera:
GPNSOP= <Entidades, Atributos, Relaciones, Ambiente, Objetivos, Control, Mtodos> (e.q. 1)
GPNSOP= <Entidades ={Usuarios, Escritorio de Ayuda, Servicio de Campo, Gerencia de TI},
Atributos ={Propiedades distinguibles de la entidades},
Relaciones ={ Usuarios-Helpdesk (atencin telefnica o remota) M:1,
Usuarios-Servicio de Campo (soporte en sitio) M:1,
Usuarios-Gerencia de TI (acuerdo de servicio) M:1,
Helpdesk-Servicio de Campo (asignacin de reporte) M:1,
Helpdesk-Gerencia de TI (gestin soporte telefnico o remoto y
acuerdo de servicio) 1:1,
Servicio de Campo-Gerencia de TI (gestin soporte en sitio y
acuerdo de servicio) 1:1},
Ambiente ={organizacin de soporte interno}
={Usuarios, Escritorio de Ayuda, Servicio de Campo, Gerencia de TI},
Objetivos ={sistema, ambiente, observador, consultor},
Control ={Sensores, Dispositivos, Unidades activadoras}
Mtodos ={Ecuaciones y Procesos} >


Seguidamente se describen cada uno de estos componentes.
4.1.1 Entidades
Representan la esencia del sistema con los ATRIBUTOS que determinan las propiedades
cuantitativas (dimensional) y cualitativas (no dimensional) de cada una de estas
ENTIDADES. Como se muestra a continuacin:
Entidades = {Grupo de Personas Stakeholders bsicos de la Metodologa}
{Usuarios, Escritorio de Ayuda, Servicio de Campo, Gerencia de TI}
(e.q. 2)

Usuarios: personas que por su definicin de negocio, establecen una relacin laboral y / o
administrativa con la empresa con la finalidad de obtener un salario, y que realizan labores
que involucran la utilizacin de un medio fsico tecnolgico, el cual puede ser monitoreado
y reparado en forma remota o local, y poseen los siguientes atributos: realizan su trabajo a
travs de computadores personales de escritorio o porttiles, (las cuales deben adaptarse a
la gran cantidad de posibilidades de conexin, ancho de banda, actualizaciones de software,
etc.) dentro o fuera de la empresa (desde sus oficinas, hogares u otras localidades). Acceden

46
los sistemas de informacin de la Organizacin que sustentan el negocio y que se ejecutan
en una computadora que tambin puede ser monitoreado en forma local o remota.
Escritorio de Ayuda (Service Desk): Conjunto de empleados que por su condicin
profesional aseguran telefnicamente o por control remoto, en primer nivel de soporte, la
continuidad de los sistemas de hardware y software que apoyan el logro de los objetivos de
los usuarios. Los atributos principales del Escritorio de Ayuda son: los empleados son
organizados de acuerdo a su perfil de soporte en grupos y en la misma localidad fsica, lo
cual define un call center, la atencin se realiza normalmente en forma telefnica (a travs
de una central que puede direccionar las llamadas, segn el perfil del empleado ACD - e
inclusive, direccionar las llamadas y la informacin del cliente contenida en los sistemas de
informacin existentes CTI), y actualmente a travs de contactos por Web, correo
electrnico y salas de Chat (Contact Center), con un perfil de comunicacin verbal y un
nivel de comprensin del negocio alto, desarrollando la capacidad de clasificar el incidente
del usuario dentro de una taxonoma que permita resolverlo segn los estndares de calidad
y los acuerdos de servicio, la consulta a bases de datos de conocimientos y el uso de otras
herramientas tecnolgicas que permiten dar respuesta efectiva al usuario segn el flujo de
trabajo establecido en el negocio.
Servicio de Campo: Conjunto de empleados que por su condicin profesional aseguran en
sitio (en segundo nivel de soporte), la continuidad de los sistemas de hardware y software
que apoyan el logro de los objetivos de los usuarios (a travs de los procesos de gestin de
problemas, cambios, versiones, configuraciones y acuerdos de servicio).
Con los siguientes atributos: poseen los conocimientos y habilidades especficas asociadas
a resolver problemas complejos de soporte (especialistas), garantizando la operatividad de
la tecnologa de informacin, adems, de los mecanismos que le permiten trasladarse hasta
el usuario y resolver el problema en sitio. Instalan y configuran las computadoras
personales de escritorio y porttiles, as como los servidores, las redes, los servicios de
telefona, y las aplicaciones de software, adems, del control de los activos y los cambios
realizados sobre los mismos, y las plataformas tecnolgicas para garantizar la continuidad
del negocio. No necesariamente pertenecen a la misma organizacin a la cual se presta el
soporte, pueden ser empleados de un outsourcing externo de soporte de segundo nivel
(proveedores).
Gerencia de Tecnologa de la Informacin: Conjunto de empleados que por su condicin
profesional garantizan la excelencia y continuidad efectiva del negocio de TI, a travs de la
gerencia de todos los componentes de TI, orientados a la consolidacin y crecimiento de la
organizacin, mediante la exitosa consecucin, implantacin, integracin de productos y
servicios tecnolgicos para apoyar el logro de los objetivos de los usuarios. Con atributos
de: gerencia de la TI, toma de decisiones en los procesos operacionales y de entrega de
servicios, aseguramiento y negociacin de los acuerdos de servicio y la calidad en el
servicio, con capacidades de auditar al Escritorio de Ayuda y a Servicio de Campo, para
gestionar la continuidad del negocio.

47
Estas entidades establecen las relaciones que se muestra a continuacin.
4.1.2 Relaciones
Entre las ENTIDADES anteriormente citadas se producen las siguientes relaciones (ver,
Figura 8):
Relaciones ={ Usuarios-Helpdesk (atencin telefnica o remota) M:1,
Usuarios-Servicio de Campo (soporte en sitio) M:1,
Usuarios-Gerencia de TI (acuerdo de servicio) M:1,
Helpdesk-Servicio de Campo (asignacin de reporte) M:1,
Helpdesk-Gerencia de TI (gestin soporte telefnico o remoto y
acuerdo de servicio) 1:1,
Servicio de Campo-Gerencia de TI (gestin soporte en sitio y
acuerdo de servicio) 1:1}
(e.q. 3)
Estas relaciones se desarrollan y desenvuelven en el marco del ambiente del sistema que se
describe seguidamente.
4.1.3 Ambiente
Est constituido por todas las entidades que al determinarse un cambio en sus atributos o
relaciones pueden modificar el sistema, de esta forma el ambiente es el conjunto
determinado por las entidades: Usuarios, Escritorio de Ayuda, Servicio de Campo y
Gerencia de TI.
Ambiente = {Entidades y su sinergia}
= {Usuarios, Escritorio de Ayuda, Servicio de Campo, Gerencia de TI y las relaciones}
(e.q. 4)
Todas estas entidades se enmarcan en lo que se denominar la Organizacin de soporte
interna, y que definen un sistema abierto: conjunto de partes en constante interaccin (lo
cual resalta la caracterstica de interdependencia de las partes) constituyendo un todo
sinrgico (el todo es mayor que la suma de las partes), orientado hacia determinados
propsitos (con comportamiento teleolgico, es decir, orientado hacia los fines) y en
permanente relacin de interdependencia con el ambiente externo (interdependencia que
debe entenderse como la doble capacidad de influenciar el medio externo y de ser
influenciado por l), y con controles por retroalimentacin positiva y negativa
En la siguiente figura, se presenta la organizacin de soporte interno en trminos de la
teora general de sistemas.


48

Empresa
Organizacin de Soporte Interno
USUARIOS HELPDESK
CAMPO
GERENCIA
TI
Soporte Telefnico o Remoto
S
o
p
o
r
t
e

e
n
S
itio
A
s
i
g
n
a
c
i

n

d
e

S
o
p
o
r
t
e
Gerencia Soporte Telefnico o remoto y Acuerdos de Servicio
Gerencia Soporte en Sitio y
Acuerdos de Servicio
A
c
u
e
r
d
o
s

d
e

S
e
r
v
i
c
i
o
1 M
M
1
M
1
1
1
1
1
1
M
Figura 8: Organizacin de Soporte Interno en trminos de Sistemas.

4.1.4 Objetivos
Entre los objetivos de la Organizacin de Soporte Interno en trminos de Sistemas, pueden
representarse como:
Objetivo = sistema, ambiente, observador, consultor (e.q. 5)
Objetivo del Sistema: Brindar a las organizaciones la posibilidad de detectar y resolver
incidentes en forma remota o en sitio, asegurando los niveles de servicio establecidos a
travs de la gerencia de tecnologa de la informacin, reparando los componentes de
hardware y software del usuario, configurando los valores de las aplicaciones y del
software de sistema, transfiriendo soluciones de software a la computadora personal,
configurando software, proporcionando formacin a los usuarios (o incluso a otros
miembros del Helpdesk), con un enfoque basado en ejemplos, reduciendo al mnimo la
necesidad de enviar al personal de Servicio de Campo a otras ubicaciones, acelerando la

49
identificacin de las fallas en primer nivel, y el aumento de la productividad del Escritorio
de Ayuda y Servicio de Campo, tanto en la cantidad de llamadas como en la velocidad de
respuesta, atencin y calidad de servicio.
Objetivo del Ambiente: Sustentar y Controlar de manera eficiente la atencin de los
usuarios a travs de la organizacin de soporte y de acuerdo a la gerencia de los procesos y
los intereses del negocio.
Objetivo del Observador: Verificar a travs de un caso de estudio (procesos de gestin de
versiones de ITIL) la eficacia de la metodologa para la gerencia de los procesos de negocio
sustentada en el uso de patrones.
Objetivo del Consultor: Anlisis, diseo, construccin, y mejora de la metodologa de
gerencia de procesos de negocio sustentada en el uso de patrones.
En forma general el macro objetivo de la metodologa de gerencia de procesos de negocio
sustentada en el uso de patrones, puede expresarse a travs de la maximizacin de la
eficacia (relacin entre eficiencia y efectividad) de la organizacin de soporte interno a
travs de los procesos de negocio de soporte a los servicios es los cuales ITIL ofrece
estndares internacionales.
La efectividad se puede definir como la relacin entre los resultados logrados y los
objetivos propuestos por la organizacin.

Efectividad =
Objetivos
Salidas


(e.q. 5.1)
La efectividad se vincula con la productividad, a travs del impacto en el logro de mayores
y mejores productos, sin embargo adolece de la nocin de uso de recursos.
Por su parte, la eficiencia es la relacin entre el qu y el cmo; en consecuencia es la
relacin entre la causa formal y la causa eficiente [CAL 96].
Eficiencia =
Entradas
Salidas

(e.q. 5.2)
Al considerar la efectividad y la eficiencia por separado, se obtienen dos dimensiones
diferentes, la primera caracterizada por un estilo efectivista ya que considera la efectividad
como nico criterio donde lo importante es el resultado sin importar el costo; y la segunda
caracterizada por una preocupacin exagerada de la eficiencia que lleva a poner nfasis en
la administracin, descuidando el cumplimiento de los objetivos, de los resultados de la
calidad y de la productividad.
Finalmente la relacin necesaria entre la eficiencia y la efectividad se logra a travs de la
eficacia, es decir la relacin existente entre los recursos usados, los objetivos de la
organizacin y el uso de insumos para lograr estos objetivos:

50
Eficacia =
d Efectivida
Eficiencia
=
Entradas
Objetivos

(e.q. 5.3)
Si el ambiente es dinmico, la eficacia estar determinada por un balance entre la eficiencia
y la efectividad. En cambio, si se est en presencia de ambientes estables se procura
maximizar tanto la eficiencia como la efectividad.
En el caso particular de la metodologa, se busca maximizar en la gerencia de los procesos
de negocio, la ecuacin:
Max(
Entradas
Objetivos
)= Max(
Costos
SLA
)
(e.q. 5.4)
Tanto la eficacia como la eficiencia y efectividad permiten medir y conocer en cualquier
momento el grado en que se estn satisfaciendo los atributos que los clientes o usuarios
valoran de los productos o servicios recibidos.
A continuacin se presentan las caractersticas y los principios que dictan el
comportamiento del sistema.
4.1.5 Caractersticas
Las caractersticas del Sistema son las siguientes:
Adaptable: Este sistema se adapta a las exigencias del entorno, lo que implica cambios
estructurales o de proceso. Por ejemplo, cundo debe afrontar a ms de un tipo o clase de
usuarios (usuarios internos y usuarios de otras compaas en calidad de outsourcing), el
Escritorio de Ayuda, Servicio de Campo y la Gerencia de TI se extienden y cambian su
estructura hasta el punto de ofrecer en outsourcing los propios servicios de la
organizacin de soporte a otros proveedores brindado igualmente el servicio de atencin
remota.
Estable: Se evidencia en el sistema efectividad ante cambios externos, adems, de un
equilibrio temporal durante estos cambios hacia la estabilidad del sistema. Por ejemplo, se
pueden modificar los acuerdos de servicio segn el tipo de cliente, su ubicacin fsica o su
dependencia estructural con la finalidad de garantizar un soporte especifico en un momento
determinado y de acuerdo a las necesidades de la organizacin, como confirmacin del
soporte remoto para las computadoras personales, o control remoto automtico en el caso
de los servidores, e igualmente el Escritorio de Ayuda y Servicio de Campo pueden adaptar
sus turnos y formas de atencin con la finalidad de tener en cuenta eventos especiales y
fallas generales como la cada de un troncal de red.


51
Eficiente: El sistema atiende los objetivos con economa de medios, maximizando la
rentabilidad de la organizacin de soporte. Por ejemplo, gracias a los beneficios de las
herramientas de control remoto se disminuyen los costos a todo lo largo del ciclo de
atencin del cliente.
Sinergia: El sistema es mayor que la suma de sus partes y amplia sus capacidades
individuales, gracias a las propiedades emergentes. La organizacin de soporte interno
sustenta el negocio de soporte propio y el de outsourcing.
4.1.6 Principios
Principios de los sub-sistemas y sus elementos:
Interaccin: Los elementos del sistema intercambian datos e informacin entre sus sub-
sistemas, sus elementos y tambin con el ambiente externo e interno del sistema. Toda la
Informacin de los clientes es almacenada con la finalidad de acelerar el proceso de control
remoto y llevar un registro de auditoria. Dentro de este mismo registro se definen los
perfiles que permiten determinar que tipo de servicio se presta al cliente.
Determinismo: Comportamiento esperado de acuerdo a las entradas y salidas (intercambio
controlado y no controlado). La Gerencia de TI establece los acuerdos de servicio que
permiten a travs de un reporte de actividades o desempeo medir la satisfaccin de los
usuarios, la evaluacin del Escritorio de Ayuda y de Servicio de Campo y las medidas
correctivas de la organizacin de soporte.
Subsidiaridad: Es la propiedad de los sistemas de formar parte de otros de mayor nivel y
de estar conformados por otros de menor nivel. La Organizacin de soporte interno
pertenece a la Organizacin total de la empresa y enmarca al Escritorio de Ayuda, a
Servicio de Campo y a la Gerencia de TI la cual a su vez tiene empleados que pueden ser
atendidos en forma local o a travs de las herramientas de control remoto.
Equifinalidad: Lograr el mismo objetivo de diferentes maneras: El soporte remoto puede
ser local en la computadora personal o remota del cliente o puede ser en sitio, a pesar que el
contacto con el cliente sea en forma telefnica, por Web, correo electrnico o por Chat. La
regulacin del comportamiento del sistema se realiza a travs del sub-sistema de control, el
cual acta como un sistema dinmico diseado para interactuar con el sistema a controlar,
logrando un sistema con caractersticas propias.
4.1.7 Sub-Sistema de Control
Puede describirse el sistema en trminos de control de acuerdo a la ley de variedad de
requisitos, como un conjunto de sensores, dispositivos de control y unidades activadoras
que se relacionan entre s para garantizar la eficiencia del sistema objeto, determinar
desviaciones, e indicando las acciones correctivas.
Control ={Sensores, Dispositivos, Unidades activadoras} (e.q. 6)


52
A travs del Sistema de Administracin y Medicin y los constantes ciclos de
retroalimentacin de la organizacin de soporte interno, se capturan las medidas de
rendimiento de los procesos, se realiza un control comparativo con los registros histricos
de las medidas esperadas y se crea un plan de ajuste para los procesos como se muestra en
la Figura 9. Si se presentan medidas de rendimiento alejadas de las esperadas o que no
representen una mejora considerable al proceso anterior, se crea un plan de ajuste
(Retroalimentacin Negativa Feedback-). Si ocurre alguna eventualidad, se participa para
afrontar la contingencia (Feedback). Si antes de implantar el proceso, se somete a una
simulacin, ste podr ser ajustado con mayor precisin a los datos reales
(Retroalimentacin Positiva: Feedforward).










Figura 9: Sistema de Control de la Organizacin de Soporte Interna.

Una vez descrito el sistema a evaluar utilizando la teora general de sistemas, el siguiente
paso de la metodologa SESL, consiste en determinar el tipo de evaluacin a conducir.
4.2 Tipo de Evaluacin
La metodologa SESL, sugiere la existencia de cinco tipos de evaluacin:
Evaluacin formativa.
Evaluacin de los efectos del sistema.
Evaluacin de los efectos organizacionales y partes psicolgicas del sistema.
Reporte de Falla del
Usuario
Soporte Telefnico, Remoto o en Sitio Resolucin de
Falla
Medidas de
Rendimiento
Control Comparati vo
Por fases
Medidas de rendimiento
esperadas
Plan de Ajuste

53
Evaluacin de conceptos (en proyectos de investigacin doctoral), y
Evaluacin para la compra de nuevos productos.
El tipo de evaluacin que se realizara al sistema objeto de estudio, ser la evaluacin de los
conceptos presentes en la Propuesta de Metodologa para la Gerencia de los Procesos de
Negocio Sustentada en el Uso de Patrones. Esta investigacin doctoral busca validar y
relacionar conceptos de las ciencias de la computacin, especficamente en el rea de la
ingeniera de software a fin de administrar procesos de negocio a travs de la utilizacin de
patrones, permitiendo la reutilizacin de mejores prcticas, estableciendo relaciones
inexistentes en la actualidad y auspiciando la calidad del proceso y el producto de software
a travs de la revisin del uso y la relacin de los diversos patrones en el dominio BPM.
4.3 Stakeholders
La prxima pregunta a realizar es, quines son los stakeholders y en qu estn interesados.
Una simple regla es buscar a quines afecta, dependen de o pueden influenciar al sistema; y
en que forma son afectados o influenciados por el sistema.
En el sistema objeto de estudio, los stakeholders pueden ser definidos a travs de las
entidades que segn la teora general de sistemas integran la organizacin de soporte
interno: Usuarios, Escritorio de Ayuda, Servicio de Campo y Gerencia de TI.

Stakeholders = {Entidades} (e.q. 2)
Los intereses a considerar por cada uno de estos stakeholders son los siguientes:
Usuarios: Maximizar la eficiencia de la resolucin.
Escritorio de Ayuda: Minimizar el tiempo de atencin. Maximizar el cumplimiento del
acuerdo de servicio de primer nivel de soporte (porcentaje de llamadas que deben ser
resueltas en primer nivel de soporte). Maximizar la resolucin de problemas remotos.
Maximizar el nivel de experticia del usuario a travs de un enfoque basado en aprendizaje.
Minimizar los costos de soporte. Minimizar el tiempo de conexin del control remoto.
Maximizar las capacidades de interaccin personal durante el control remoto (voz, Chat,
etc.).
Servicio de Campo: Minimizar los costos de servicio, minimizar la cantidad de problemas
en sitio.
Gerencia de TI: Minimizar los costos de planeacin, adquisicin, implantacin, operacin
y reemplazo de las TI que apoyan a la organizacin de soporte interno, Maximizar el
retorno de inversin de las aplicaciones de TI.

54
4.4 Preguntas Claves
De acuerdo a los intereses establecidos para los stakeholders, a continuacin es necesario
establecer las preguntas claves, en el estudio del sistema a evaluar al describir las entidades
en trminos de sistemas, se determin, cules son las reas principales de estudio y cules
son los principales objetivos de cada uno de ellos.
Se construyeron las preguntas claves, se realizo un cuestionario por stakeholder, se
realizaron entrevistas y observacin descriptiva sobre cada uno de ellos y se obtuvo la
informacin necesaria de acuerdo a las tcnicas de recoleccin de datos descritas en el
marco metodolgico de esta investigacin doctoral. Esta informacin esta disponible y
puede ser solicitada al investigador.
4.5 Diseo de la Metodologa de Gerencia de Procesos de Negocio Sustentada en el Uso
de Patrones
Una vez establecidas las preguntas asociadas a los intereses de los stakeholders y obtenidos
los valores a travs de una herramienta de recopilacin de informacin, se procedi al
diseo de la metodologa.
La propuesta metodolgica para la gerencia de los procesos de negocio sustentada en el uso
de patrones (Bonillo, 2005b) est conformada por dos macro-procesos (ver, Figura 10):
(4.5.1) Creacin de los procesos de negocio; y (4.5.2) Administracin de los procesos de
negocio en ejecucin.
Figura 10: Estructura de la Metodologa de Gerencia de Procesos Sustentada en el Uso de Patrones
Process Management.
El primer macro-proceso 4.5.1 incluye los siguientes sub-procesos:
4.5.1.1 Anlisis y evaluacin de los requerimientos tomando en cuenta el tipo de prioridad
y en base a las prcticas de elicitacin de requisitos de la ingeniera de software.
4.5.1 CREAR
PROCESO
4.5.1.1 Analizar 4.5.1.2 Disear
4.5.1.3 Modelar 4.5.1.4
Configurar
4.5.2 ADMINISTRAR
PROCESO
4.5.2.1 Mantener
Configuracin
4.5.2.2
Monitorear

55
En este subproceso, el Cliente solicita un requerimiento sobre un proceso existente o uno
nuevo a un Escritorio de Servicio (Service Desk), el analista del negocio (Custodio del
Proceso) identifica el requerimiento de acuerdo a las prcticas de elicitacin de requisitos
de la ingeniera de software: describe el requerimiento en termino de los requisitos
funcionales y no funcionales, le asigna una prioridad y evala una cartelera de las posibles
actividades a realizar en el tiempo. (ver, Figuras 11 y 12)

Figura 11: Sub-Proceso Analizar de la Metodologa Gerencia de Procesos.

Figura 12: Sub-Proceso Analizar de la Metodologa Gerencia de Procesos (continuacin).


Se evala el requerimiento
definido y se le asigna
prioridad segn su nivel de
impacto y urgencia.
Sub-Proceso: 4.5.1.1 Analizar
1.1.1 .1
Describir
Requerimiento
1.1.1.2
Definir
Prioridad

1.1.1.3
Evaluar
Cartelera de
Actividades

Requerimiento
Requerimiento
Definido
Prioridad
Asignada
Cliente Custodio
Proceso
Cliente Custodio
Proceso
Se evala el requerimiento y se
define como funcional o no
funcional segn sus
especificaciones
Se definen las actividades y el
tiempo para realizarse segn el
impacto y urgencia del
requerimiento.

Sub-Proceso: 4.5.1.1 Analizar
1.1.1
Identificar
Requerimientos
Cliente
Requerimiento
1.1.1 .1
Describir
Requerimiento
1.1.1.2
Definir
Prioridad



Requerimiento
1.1.1.3
Evaluar Cartelera
de Actividades

Requerimiento
Definido
1.1.2
Levantar
Informacin
ServiceDesk
Cliente Custodio
Se identifica claramente el
alcance inicial del proceso.
Requerimiento

56
A continuacin el analista del negocio, consulta los patrones de anlisis disponibles en el
domino y los relaciona con el requerimiento. Finalmente se levanta cualquier otra
informacin que sea necesaria para determina la situacin actual de cmo funciona el
proceso y se invoca a un proceso de gestin de cambio a fin de introducir el nuevo
requerimiento (RFC) en la arquitectura de procesos existente. (ver, Figura 13).


Figura 13: Sub-Proceso Analizar de la Metodologa Gerencia de Procesos (continuacin).

4.5.1.2 Diseo de un modelo estandarizado del proceso tomando en cuenta los patrones de
anlisis en el dominio. En este subproceso el analista del negocio (custodio del proceso)
compara el proceso segn los requerimientos del usuario, con los patrones de anlisis
(mejores practicas del dominio) a fin de identificar las brechas existentes y los riesgos
organizacionales de asumir los mismos. (ver, Figura 14).
A continuacin negocia con el cliente los riesgos, seguidamente el Analista del Negocio
con el Arquitecto de Sistemas realiza un diseo en papel del modelo del proceso de acuerdo
a los estilos arquitecturales y los patrones arquitecturales que se asocien a los patrones de
anlisis seleccionados o a los requerimientos especficos del usuario. (Esto es slo un
esqueleto de la aplicacin y la seleccin de los posibles componentes que se puedan incluir
en el mismo, se puede utilizar una herramienta de diagramacin).
Para finalizar este subproceso el analista del negocio con el cliente define un cronograma
definitivo de actividades en el tiempo e invoca a un proceso de desarrollo de software, en el
cual el analista del negocio consulta a un arquitecto de sistema a fin de selecciona un
Sub-Proceso: 4.5.1.1 Analizar
1.1.2
Levantar
Informacin
1.1.2.1 Mapear al
Marco Referencial
del Proceso

1.1.2.2 Levantar
Situacin Actual

Requerimiento
Definido
1.1.1
Identificar
Requerimientos
Cliente Custodio
Se documenta toda la informacin
necesaria para dar inicio al
modelado
Requerimiento
Definidobajo el
marcodereferencia
Gestin de
Cambios
RFC
Mapa de Procesos
(Patrones de Anlisis)
Ubicacin en
el mapa de
procesos
Se ubica el requerimiento en el mapa de
procesos bajo el marco referencial.
(Patrnes de Anlisis)
Se remite el requerimiento al
personal de procesos quien debe
evaluarlo y generar un formato de
recoleccin de informacin.

57
proceso de desarrollo (UP, XP o FDD) segn el caso y configurar un ambiente de
desarrollo (hardware y software).


Figura 14: Sub-Proceso Disear de la Metodologa Gerencia de Procesos.

4.5.1.3 Modelado, diagramacin y simulacin. En este subproceso el analista del negocio
realiza un diagrama del proceso de acuerdo al modelo realizado en la fase anterior, en una
herramienta de anlisis de proceso BPA (seleccionado los diagramas ya existentes para los
patrones de anlisis, estilos arquitecturales y patrones arquitecturales elegidos en el
subproceso de diseo).
Seguidamente el analista del negocio realiza una simulacin en la herramienta de BPA a fin
de detectar tendencias (cuellos de botellas, ciclos, etc.) y solicita la aprobacin de la
simulacin del proceso al cliente.
A continuacin el Analista del Negocio con el Arquitecto de Sistemas integra el diagrama
del proceso actual con el diagrama general existente para la arquitectura de todos los
procesos y realiza nuevamente una simulacin a fin de verificar las tendencias con respecto
a la arquitectura general de procesos, solicita la aprobacin del usuario, realiza un informe
final del diseo y el modelado del proceso e indica al Arquitecto de Sistemas que coloque

Sub-Proceso: 4.5.1.2 Disear
1.2.1
Estandarizar
Procesos
1.2.2
Evaluar
Riesgo
Analista de
Negocio
Analista
de
Proceso
Estandarizado
Modelo de
Objetos
Cannico (Estilos
Arquitecturales y
Patrones de Diseo)
Objeto
Educativo Cannico
1.2.3
Realizar
Modelo
Propuesto
Proceso con
Riesgos
Definidos
1.2.4
Efectuar
Setup del
Laboratorio
Proceso
Modelado
Se analizan los riesgos y las brechas
basado en el concepto de mejores
prcticas
Se estandariza la propuesta
aplicando mejores prcticas
Implica el levantamiento de
informacin para el diseo del
proceso y el llenado de las tablas de
configuracin de la Herramienta de
Analisis de Procesos (BPA)
Arquitectode
Sistema

58
en produccin el proceso, o lo que es lo mismo que exporte desde la herramienta de BPA al
motor de Ejecucin del Proceso el BPEL (Lenguaje de Ejecucin de Procesos propuesto
por el BPMI) y el UML (Lenguaje de Modelacin Unificado) que sern insumos para el
proceso de desarrollo de software. (ver, Figura 15).

Figura 15: Sub-Proceso Modelar de la Metodologa Gerencia de Procesos (continuacin).

4.5.1.4 Configuracin e implementacin de la lgica de integracin, de negocios y de
presentacin del proceso a travs de la orquestacin de servicios, objetos, el uso de patrones
de diseo y de interfaz con base en la fase de modelado. (ver, Figura 16).
En este subproceso, el arquitecto toma los diagramas UML creados por la herramienta de
BPA y los requerimientos funcionales y no funcionales del anlisis de requisitos del
proceso y completa los diagramas UML segn el proceso de desarrollo seleccionado (UP,
XP o FDD).
A continuacin a partir de los diagramas UML, el BPEL y los patrones de diseo
relacionados con los patrones de anlisis, estilos arquitecturales y patrones arquitecturales
seleccionados en los subprocesos anteriores, el arquitecto solicita al desarrollador que
construya la lgica de negocio de la aplicacin que sustentar al proceso (el desarrollador
adems de seleccionar los patrones de diseo tambin seleccionara el idiom en el cual

Sub-Proceso: 4.5.1.3 Modelar
1.3.1
Diagramar
1.3.2
Simular
Prueba
Funcional
1.3.3
Integrar
Arquitectura
1.3.4
Simular
Prueba
Integral
Modelo Objeto
(Estilos Arquitecturales
Patrones de Diseo
Patrones Arquitecturales)
Cliente
Custodio
Proceso
Procesos
Modelados
Simulacin
Aprobada
Procesos
Integrados
Se construye el proceso
bajo la herramienta BPA la
cual genera un documento
BPMN.
Se integra el proceso con la
Malla de Macro Procesos

Se configura el ambiente integrado para su
simulacin final,, la cual debe generar los
archivos BPEL y UML, as como el informe de
modelado y el informe de simulacin para luego
ser validado con el cliente.
Se configura el ambiente
funcional y se realiza la
simulacin, los resultados de
la misma deben ser
aprobados por el cliente
Arquitecto
de Sistemas

59
realizara el desarrollo de la lgica de negocio, por ejemplo Enterprise Java Bean EJB y el
Contenedor de Aplicaciones Java EAR).
De igual forma de acuerdo a los patrones de interaccin relacionados con los patrones de
anlisis, los estilos arquitecturales y patrones arquitecturales seleccionados en los
subprocesos anteriores, el BPEL y las interfaces asociadas automticamente con el BPEL a
travs de la herramienta de BPA, el arquitecto solicita al desarrollador que construya la
interfaz de la herramienta que soportar al proceso (el desarrollador adems de seleccionar
los patrones de interaccin, tambin seleccionar los patrones de flujo de trabajo y el idiom
en el cual realizar el desarrollo de la interfaz, por ejemplo Java Server Page JSP).



Figura 16: Sub-Proceso Configurar de la Metodologa Gerencia de Procesos.
Seguidamente el arquitecto solicita al especialista de integracin (desarrollador) que realice
las integraciones entre el BPEL, la interfaz y la lgica de negocio. Teniendo el BPEL, la
lgica de negocio y la interfaz integrada el arquitecto procede a colocar en el BPEL los
indicadores de gestin que se medirn para el proceso, para esto selecciona de un conjunto


Sub-Proceso: 4.5.1.4 Configurar
1.4.4
Construir los
reportes
1.4.5
Configurar el
BPEL
Tablas
del Sistema
Generador
de Reportes
JSPGenerados por
AplicacinBPM
UML Generadoo
ExportadoBPA
1.4.3
Construir
Interfaz
1.4.2
Construir
Lgica de
Negocios
1.4.1
Completar UML
UML
o BPA
Arquitecto
Se le da completitud al
ambiente de configuracin
en el archivo BPEL; Se le
dan configuraciones
completas al UML.
Se generan las tablas de la
base de datos, los servicios
y lgica de negocios (EJB)
patrones de workflow.

UML
Completo
Desarrollador


JSP
Desarrollador
Se construye la interfaz del
usuario a partir de los JSP
generados por el configurador de
aplicacin a fin de darle
usabilidad (patrones de interfaz y
flujo de trabajo).
Tablas de
Requerimientos

Requerimiento
1.4.6
Realizar
Pruebas
Unitarias
Paginas
Opcional
JSPPortal
EAR
Completos
EJB
Crear Tablas
Arquitectura
Descripcion del
servicio (wsdl)
Servicioexpuestoy
disponible
Arquitecto

60
previamente definido de acuerdo al patrn de anlisis, los indicadores necesarios y a su vez
solicita al desarrollador que construya los reportes necesarios para desplegar los
indicadores, el BPMS contiene normalmente un modulo de BAM el cual almacena estos
indicadores en el tiempo de acuerdo a estructuras de inteligencia de negocio.
Finalmente el Arquitecto solicita al Analista del Negocio la certificacin del producto de
software que sustenta el proceso, para luego culminar el proceso de gestin de cambio de la
arquitectura de procesos y solicitar un pase a produccin (ver, Figura 17).


Figura 17: Sub-Proceso. Configurar de la Metodologa Gerencia de Procesos (continuacin).


Sub-Proceso: 4.5.1.4 Configurar (Continuacin)
1.4.4
Construir los
reportes
1.4.5
Configurar el
BPEL
Generador
de Reportes
Se configura el BPEL, la lgica de
negocios, los reportes, la interfaz, las
excepciones, los mensajes,
notificaciones, compensaciones y se
integra al proceso de la aplicacin
integrado en un contenedor.
JSPGeneradospor
AplicacinBPM
UML Generadoo
ExportadoBPA
1.4.3
Construir
Interfaz
1.4.2
Construir
Lgica de
Negocios
1.4.1
Completar UML
UML
y BPA
Arquitecto
UML
Completo

JSP
Desarrollador
Se construye la interfaz del
usuario a partir de los JSP
generados por el configurador de
aplicacin a fin de darle
usabilidad (patrones de interfaz y
evento).
Tablas de
Requerimientos

Requerimiento
1.4.6
Realizar
Pruebas
Unitarias
Paginas
Opcional
JSPPortal
EAR
Completos
EJB
Gestin de
Cambios
Administrador
de Cambios

UML Generadoo
ExportadoBPA
Pase a
Produccin
Se realizan las pruebas
funcionales y pruebas integrales,
cuyos resultados son validados
por los clientes para proceder a
su implantacin.



61
El otro macro-proceso 4.5.2 corresponde a la administracin de los procesos en ejecucin y
comprende:
4.5.2.1.1 Mantenimiento de las aplicaciones (procesos en produccin), a travs de este
subproceso los clientes solicitan las modificaciones menores a 40 horas de desarrollo sobre
la interfaz de usuario y los reportes y que no implique un cambio en el flujo del proceso, de
esta forma el rea de mantenimiento de aplicaciones analiza y valida el requerimiento,
disea el cambio y realiza pruebas, para finalmente solicitar un control de cambio y un pase
a produccin de los cambios solicitados. (ver, Figura 18)


Figura 18: Sub-Proceso Mantenimiento de la Metodologa Gerencia de Procesos.
4.5.2.1.2 Mantenimiento de variables del proceso, en este subproceso el cliente solicita
cambios puntuales sobre las variables de configuracin del proceso en produccin, el rea
de mantenimiento de aplicaciones realiza los cambios y solicita igualmente que los mismos
sean pasados a produccin. (ver, Figura 19).

Sub-Proceso: 4.5.2.1 Mantener de Aplicaciones
2.1.2
Mantenimiento de
Variables del
Proceso

Cliente
2.1.1.1
Analizar y Validar tipo
de requerimiento
2.1.1.2
Disear

Solicitud

FOR-0069
2.1.1.3
Aplicar Prueba

Validacinpor
proyecto
ProcessWare
2.1.3
Mantenimiento de
la Plataforma
Lder
Mantenimiento
de Aplicaciones
Se verifican los datos y su
funcionalidad a travs de las
pruebas validadas por el
cliente.
2.1.1
Mantenimiento de
Aplicaciones
Prototipo de la
Aplicacin
Gestin de
Cambios
Pase a
Produccin

RFC
Se realizan las modificaciones en las
aplicaciones que estn en
produccin para solicitudes que sean
menores a 40 horas.
Se identifica,
disgrega y valida con
el cliente el
requerimiento
solicitado.
Se construye el
requerimiento solicitado
con fecha de compromiso y
se valida con el cliente.


62

Figura 19: Sub-Proceso Mantener Configuraciones de la Metodologa Gerencia de Procesos
(continuacin).
4.5.2.1.3 Mantenimiento de Plataforma, a travs de este subproceso ese configura la
plataforma de hardware y software donde se ejecutan los procesos en produccin,
incluyendo los posibles cambios. (ver, Figura 20).


Figura 20: Sub-Proceso Mantener Configuraciones de la Metodologa Gerencia de Proceso
(mantenimiento de plataforma).

Sub-Proceso: 4.5.2.1 Mantener Configuraciones
Cliente
Solicitud
2.1.3
Mantenimiento de
la Plataforma
Lder
Mantenimiento
deAplicaciones
2.1.1
Mantenimiento de
Aplicaciones
Se realizan las modificaciones en las
aplicaciones que estn en produccin
para solicitudes que sean menores a 40
horas.
2.1.2
Mantenimiento de
Variables de
Procesos
Datos del Proceso
Actualizado
Sub-Proceso: 4.5.2.1 Mantenimiento de Plataforma
2.1.3
Mantenimiento de
Variables de
Procesos
2.1.1
Mantenimiento de
Aplicaciones
Se configura la plataforma de hardware, software, parmetros de WAS,
bases de datos, sistema operativo, servidor Web y BPM para el respectivo
pase a produccin de la RFC.
2.1.2
Mantenimiento de
la Plataforma
Hosting de
Base de
Datos
Hosting
SO
Hosting
Aplicaciones
BPM
Configurado
Hardware
Configurado
Software
Configurado
WAS
Configurado
BaseDatos
Configurado
S.O.
Configurado
Servidor Web
Configurado
RFC
Gestin de
Cambios
Administrador
Pase a
Produccin

63
4.5.2.2 Monitoreo de la Plataforma, en este subproceso el Gerente del proceso solicita al
especialista de aplicaciones los indicadores, reportes y mediciones en tiempo real
(Dashboard) sobre los procesos, igualmente se monitorean las variables correspondientes al
funcionamiento del hardware y software (variables MIBS).



Figura 21: Sub-Proceso Monitorear de la Metodologa Gerencia de Procesos.

En cada uno de los subprocesos antes mencionados se tienen un conjunto de roles de
usuarios los cuales se describen a continuacin:

Escritorio de Servicios Service Desk: Ser el punto nico de contacto entre los Clientes y
Usuarios, responsable de la recepcin de todas las solicitudes que tengan vinculacin con la
Plataforma de Procesos. Por otra parte, mantiene informado al Cliente acerca del status del
requerimiento emitido.

Cliente: Cualquier persona de la Empresa que requiera emitir un incidente, llamada o
solicitud de servicio sobre la Plataforma de Procesos.

Analista de Negocio o Custodio de Procesos: Recibe la solicitud, la analiza disgregando la
informacin de acuerdo a su funcionalidad, calidad, impacto, urgencia, riesgo, brechas,
entre otros. Hasta llegar a la diagramacin, modelado y simulacin del requerimiento
solicitado por un cliente. Se apoya en el Arquitecto a fin de Bajar las especificaciones de
negocio al rea de ingeniera de software.

Sub-Proceso: 4.5.2.2 Monitorear
2.2.2
Monitorear
Plataforma
Especialista
Mantenimiento
de Aplicaciones
Gerente de
Proceso
TablaBPA
Definicinde
Indicadores
Dashboard
Se refiere al monitoreo de
todas las variables
asociadas al
funcionamiento de la
plataforma.
2.2.1
Monitorear
Funciones
Especialista
en Monitoreo
y Control
Hosting de
Aplicaciones
Tablas BPA
Variables
MIBS
Se refiere a las mediciones
que los gerentes de los
procesos desean tener en
tiempo real (dashboard).

Dashboard
Medicion
Software
Monitoreo

64
Administrador de Cambios: Recibe todas las peticiones de cambio emitido dentro de la
Gestin de Procesos para realizar los respectivos cambios requeridos en la solucin de un
requerimiento.

Arquitecto: Especialista en procesos y en la herramienta de Modelamiento (BPA) que se
encarga de verificar, darle asesora y validar los diagramas modelados por el Custodio de
Procesos dentro del Centro de Modelado para luego remitirlos al Configurador. Prepara el
ambiente en la plataforma para darle completitud a la simulacin a travs del
enriquecimiento de datos necesarios en la emisin de los archivos UML y BPEL. Se apoya
en los desarrolladores a fin de construir la lgica de negocio, la interfaz, los reportes.

Lder Mantenimiento Aplicaciones: Gestiona la distribucin y asignacin de las solicitudes
emitidas para el mantenimiento en las aplicaciones de los procesos que se encuentran en
produccin.

Especialista Mantenimiento Aplicaciones: Ejecuta las modificaciones, carga y
configuracin de los datos, usuarios y grupos de aplicaciones de los procesos que se
encuentran en produccin.

Lder Mantenimiento Operativo: Dirigir, supervisar y gestionar todo requerimiento que
supera las 40 horas.

Hosting Aplicaciones: Grupo de Operaciones que mantiene la Plataforma de Aplicaciones
que se encuentran en produccin.

Hosting Sistema Operativo: Grupo de Operaciones que mantiene el Sistema Operativo de
las aplicaciones que se encuentran en produccin.

Hosting Base de Datos: Grupo de Operaciones que mantiene las base de Datos de las
aplicaciones que se encuentran en produccin.

Gerente Proceso: Emite la informacin necesaria para la emisin del panel de control de
medicin de mtricas (Dashboard).

Especialista Monitoreo y Control: Grupo que evala las variables de plataforma de
hardware y software de aplicaciones monitoreando su funcionamiento.
4.6. Retroalimentacin
Esta es la etapa final de la metodologa, una vez puestos en produccin los procesos, stos
son analizados con el objetivo de obtener resultados que conduzcan a conclusiones
relevantes en cuanto al comportamiento de los mismos.
Con este anlisis se puede determinar la forma en que la metodologa beneficia o no a la
organizacin, y al mismo tiempo realizar refinamientos del uso de la misma segn los casos

65
particulares, o el estudio de otros agentes que ayuden a aumentar el impacto de los
procesos.
De esta forma la metodologa no slo permite comunicar los resultados, sino que, adems
ofrece la posibilidad de variar ciertos factores relevantes en el impacto, para validar
nuevamente su influencia principalmente con respecto al uso de los patrones y la medicin
de la calidad en el proceso de desarrollo de software. Sin embargo muchos son los factores
que directa e indirectamente debe tomarse en cuenta como restricciones que se anidan y que
facilitan o no la implementacin de la metodologa, basadas todas en los diferentes
intereses planteados para cada stakeholder. (Bonillo, 2006b)
Es importante citar que durante el desarrollo de la investigacin se evaluaron aplicaciones
propietarias y de software libre que permitieran la automatizacin de los conceptos
expuestos, sin embargo no se encontr una herramienta que permitieran ejecutar las
funciones descritas, es por esto que en el siguiente capitulo se expone el anlisis de un
prototipo de aplicacin que permita la automatizacin integral de la metodologa descrita.
4.7. Propuesta de Automatizacin de la Metodologa
En este aparte se especifican los casos de uso del prototipo de bajo nivel de BPMS
sustentado en el uso de Patrones que permitir implementar la administracin de los
patrones en base a la taxonoma y las relaciones tericas establecidas en esta investigacin
(ver, Figura 7), para esto se realiza el modelaje del sistema a travs de los casos de usos y
se propone un sistema de generacin asistida de aplicaciones en base al uso de los patrones.

A continuacin se muestra la especificacin de los casos de uso ms significativos (se
desarrollaron todos los casos de usos y estn disponibles en caso de que se deseen
consultar, se pueden solicitar enviando un correo electrnico al autor pbonillo@cantv.net).

Es importante mencionar que los mismos surgen del anlisis de los requerimientos
funcionales del cliente y del diseador. Para la especificacin de los casos de uso, se utiliz
la plantilla propuesta por Daz y Matteo (2002).

Se presenta el caso de uso general y a continuacin se explica cada uno de los casos de uso
a travs de una tabla.

A continuacin se presenta el caso de uso general y su descripcin y sucesivamente se
presenta la informacin del resto de los casos de uso.


66


Figura 22. Caso de uso General Prototipo BPMS Metodologa Gerencia de Procesos de Negocio
Sustentada en el Uso de Patrones.


Caso de Uso General
Resumen Recibe las solicitudes de los Modeladores, Administradores, Usuarios y Procesos
Externos o Procesos de Negocio y administra el modelo de proceso, los patrones
(anlisis-proceso, interfaz, interaccin y flujo de trabajo), la interfaz, los eventos de
las tareas, las tareas, la identificacin de los entes involucrados en las tareas, los
datos asociados al sistema (identificacin de proceso tarea, etc.), las notificaciones y
los reportes tanto del sistema como del monitoreo de la actividad de los procesos y
las tareas
Actor Modelador, Administrador, Usuario, Proceso Externo o Negocio
Precondicin
Descripcin INICIA CUANDO <Modelador><Administrador><Usuario><Proceso Externo o
Negocio><invoca a Administrador de Modelo><invoca Administrador de

67
Patrones><invoca Administrador Interfaz>
1. <Modelador><invoca Administrador Modelo>
2. <Administrador><invoca Administrador Modelo>
3. <Administrador><Usuario><Proceso Externo o Negocio>
<invoca Administrador Interfaz>
<Administrador Interfaz>
<recibeparametros><parmetros de Interfaz deben ser correctos>
<Administrador Interfaz><invoca Administrador Eventos Tarea>
<Administrador Eventos Tarea><invoca Administrador Tarea>
<Administrador Tarea><invoca Administrador Identidad>
<Administrador Tarea><invoca Administrador Sistema>
<Administrador Tarea><invoca Administrador Notificaciones>
<Administrador Tarea><invoca Administrador Reportes>
4. <Administrador><invoca Administrador Reportes>

Trayectorias Alternati vas
<parmetros Interfaz incorrectos>
1. <Modelador><Administrador><Usuario><Proceso Externo o
Negocio><vuelve a enviar los parmetros de Interfaz><parmetros
de Interfaz deben ser correctos>
Poscondicin El Modelador, Administrador, Usuario, Proceso Externo o Negocio recibe respuesta
del requerimiento si los parmetros inciales son correctos, en caso contrario recibe
un error.
Requisito No
Funcional

Comentario
Tabla 3 Caso de uso General Prototipo BPMS Metodologa Gerencia de Procesos de
Negocio Sustentada en el Uso de Patrones.


A continuacin se inicia la explicacin especfica de cada uno de estos casos de
uso que conforman el caso de uso general.

68

Figura 23. Caso de uso Administrador Modelo.

Caso de Uso Administrador Modelo
Resumen Recibe las solicitudes del Modelador a travs del servicio de administracin de
Modelo, procesa las solicitudes y enva la respuesta.
Actor Administrador Modelo, Administrador Patrones y Administrador Identidad
Precondicin
Descripcin <Administrador Modelo>INICIA CUANDO <Modelador><invoca al Servicio de
Administracin de Modelos>
1. <Administrador><interfaz de invocacin del Servicio de Administracin de
Modelos><introduce parmetros inciales de modelo><parmetros de modelo
deben ser correctos>
2. <Administrador Modelo>
<recibeparametros><parmetros de modelo deben ser correctos>
3. <Administrador Modelo><procesa modelo>
SI <consultar Modelo>ENTONCES
4. <Administrador Modelo><Consulta Modelo>
FIN SI

SI <crear Modelo>ENTONCES
5. <Administrador Modelo><crear modelo>
<interfaz de invocacin del Servicio Administracin Identidad>
<Consultar Identidad><Crear Identidad><Modificar Identidad>
SI <Patrn Anlisis>ENTONCES

69
<interfaz de invocacin del Servicio Administracin Patrones anlisis>
<recuperarPatron>
FIN SI
SI <PatronInterfaz>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Interfaz>
<recuperarPatron>
FIN SI
SI <PatronEventosInteraccion>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Eventos>
<recuperarPatron>
FIN SI
SI <PatronFlujoTrabajo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Flujo Trabajo>
<recuperarPatron>
FIN SI
FIN SI
SI <modificarModelo>ENTONCES
6. <Administrador Modelo><modifica modelo>
<interfaz de invocacin del Servicio Administracin Identidad>
<Consultar Identidad><Crear Identidad><Modificar Identidad>
SI <PatronAnalisis>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones anlisis>
<recuperarPatron>
FIN SI
SI <PatronInterfaz>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Interfaz>
<recuperarPatron>
FIN SI
SI <PatronEventosInteraccion>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Eventos>
<recuperarPatron>
FIN SI
SI <PatronFlujoTrabajo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Flujo Trabajo>
<recuperarPatron>
FIN SI
FIN SI
SI <validarModelo>ENTONCES
7. <Administrador Modelo><valida modelo>
<interfaz de invocacin del Servicio Administracin Identidad>
<validar Identidad>
SI <simularModelo>ENTONCES
8. <Administrador Modelo><simula modelo>
<interfaz de invocacin del Servicio Administracin Identidad>
<validar Identidad>
SI <eliminarModelo>ENTONCES
9. <Administrador Modelo><elimina modelo>
SI <capturarError> ENTONCES
10. <Administrador Modelo><capturaError>
FIN SI
11. <Administrador Modelo><enviaRespuesta>
END < Administrador Modelo>

Trayectorias Alternati vas
<parmetros modelo incorrectos>
1. <Administrador><pantalla de invocacin del servicio de
Administracin de Modelo><vuelve a enviar los parmetros de
modelo><parmetros de modelo deben ser correctos>
Poscondicin El Proceso Externo recibe respuesta del requerimiento de administracin de modelo
si los parmetros inciales son correctos, en caso contrario recibe un error.

70
Requisito No
Funcional

Comentario
Tabla 4 Caso de Uso Administrador Modelo



Figura 24 Caso de uso Administrador Patrones.

Caso de Uso Administrador Patrones
Resumen Recibe las solicitudes del Administrador a travs del servicio de administracin de
Patrones, procesa las solicitudes y enva la respuesta.
Actor Proceso Externo, Administrador Interfaz, Administrador Patrones interaccin,
Administrador Identidad, Administrador Eventos Interfaz, Administrador Tarea
Precondicin
Descripcin <Administrador Patrones>INICIA CUANDO <Administrador><invoca al Servicio de
Administracin de Patrones>

71

1. <Administrador><interfaz de invocacin del Servicio de Administracin de
Patrones><introduce parmetros inciales de patrones><parmetros de
patrones deben ser correctos>
2. <Administrador Patrones>
<recibeparametros><parmetros de patrn deben ser correctos><interfaz de
invocacin del Servicio de Administracin de Identidad><verificarPermisologia>
3. <Administrador Patrones><procesapatron>
SI <configurarPatron>ENTONCES
4. <Administrador Patrones>
<interfaz de invocacin del Servicio de Administracin Identidad>
<seleccionarPermisologia><configurarPermisologiaPatron>
SI <ConfigurarPatronAnalisis>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones anlisis>
<configurarPatronAnalisis>
FIN SI
SI <ConfigurarEstiloArquitectural>ENTONCES
<interfaz de invocacin del Servicio Administracin Estilo Arquitectural>
<configurarEstiloArquitectural>
FIN SI
SI <ConfigurarPatronDiseo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Diseo>
<configurarPatronDiseo>
FIN SI
SI <ConfigurarPatronInterfaz>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Interfaz>
<configurarPatronInterfaz>
FIN SI
SI <ConfigurarPatronEventosInteraccion>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Eventos>
<configurarPatronEventosInteraccion>
FIN SI
SI <ConfigurarPatronFlujoTrabajo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Flujo Trabajo>
<configurarPatronFlujoTrabajo>
FIN SI
FIN SI
SI <EliminarPatron> ENTONCES
5. <Administrador Patrones>
<verificaRelaciones><eliminaRelaciones>
SI <EliminarPatronAnalisis>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones anlisis>
<eliminarPatronAnalisis>
FIN SI
SI <EliminarEstiloArquitectural>ENTONCES
<interfaz de invocacin del Servicio Administracin Estilo Arquitectural>
<eliminarEstiloArquitectural>
FIN SI
SI <EliminarPatronDiseo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Diseo>
<eliminarPatronDiseo>
FIN SI
SI <EliminarPatronInterfaz>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Interfaz>
<eliminarPatronInterfaz>
FIN SI
SI <EliminarPatronEventosInteraccion>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Eventos>
<eliminarPatronEventosInteraccion>
FIN SI
SI <EliminarPatronFlujoTrabajo>ENTONCES

72
<interfaz de invocacin del Servicio Administracin Patrones Flujo Trabajo>
<eliminarPatronFlujoTrabajo>
FIN SI
FIN SI
SI <validarPatron>ENTONCES
6. <Administrador Patrones>
SI <ValidarPatronAnalisis>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones anlisis>
<validarPatronAnalisis>
FIN SI
SI <ValidarEstiloArquitectural>ENTONCES
<interfaz de invocacin del Servicio Administracin Estilo Arquitectural>
<validarEstiloArquitectural>
FIN SI
SI <ValidarPatronDiseo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Diseo>
<validarPatronDiseo>
FIN SI
SI <ValidarPatronInterfaz>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Interfaz>
<validarPatronInterfaz>
FIN SI
SI <ValidarPatronEventosInteraccion>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Eventos>
<validarPatronEventosInteraccion>
FIN SI
SI <ValidarPatronFlujoTrabajo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Flujo Trabajo>
<validarPatronFlujoTrabajo>
FIN SI
FIN SI
SI <aplicarPatron>ENTONCES
7. <Administrador Patrones>
SI <AplicarPatronAnalisis>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones anlisis>
<aplicarPatronAnalisis>
FIN SI
SI <AplicarEstiloArquitectural>ENTONCES
<interfaz de invocacin del Servicio Administracin Estilo Arquitectural>
<aplicarEstiloArquitectural>
FIN SI
SI <AplicarPatronDiseo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Diseo>
<aplicarPatronDiseo>
FIN SI
SI <AplicarPatronInterfaz>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Interfaz>
<aplicarPatronInterfaz>
FIN SI
SI <AplicarPatronEventosInteraccion>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Eventos>
<aplicarPatronEventosInteraccion>
FIN SI
SI <AplicarPatronFlujoTrabajo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Flujo Trabajo>
<aplicarPatronFlujoTrabajo>
FIN SI
FIN SI
SI <recuperarPatron>ENTONCES
8. <Administrador patrn>
SI <RecuperarPatronAnalisis>ENTONCES

73
<interfaz de invocacin del Servicio Administracin Patrones anlisis>
<recuperarPatronAnalisis>
FIN SI
SI <RecuperarEstiloArquitectural>ENTONCES
<interfaz de invocacin del Servicio Administracin Estilo Arquitectural>
<recuperarEstiloArquitectural>
FIN SI
SI <RecuperarPatronDiseo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Diseo>
<recuperarPatronDiseo>
FIN SI
SI <RecuperarPatronInterfaz>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Interfaz>
<recuperarPatronInterfaz>
FIN SI
SI <RecuperarPatronEventosInteraccion>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Eventos>
<recuperarPatronEventosInteraccion>
FIN SI
SI <RecuperarPatronFlujoTrabajo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Flujo Trabajo>
<recuperarPatronFlujoTrabajo>
FIN SI
FIN SI
SI <crearPatron>ENTONCES
9. <Administrador patrn>
SI <CrearPatronAnalisis>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones anlisis>
<crearPatronAnalisis>
FIN SI
SI <CrearEstiloArquitectural>ENTONCES
<interfaz de invocacin del Servicio Administracin Estilo Arquitectural>
<crearEstiloArquitectural>
FIN SI
SI <CrearPatronDiseo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Diseo>
<crearPatronDiseo>
FIN SI
SI <CrearPatronInterfaz>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Interfaz>
<crearPatronInterfaz>
FIN SI
SI <CrearPatronEventosInteraccion>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Eventos>
<crearPatronEventosInteraccion>
FIN SI
SI <CrearPatronFlujoTrabajo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Flujo Trabajo>
<crearPatronFlujoTrabajo>
FIN SI
FIN SI
SI <modificarPatron>ENTONCES
10. <Administrador patrn>
SI <adaptarPatron>ENTONCES
SI <AdaptarPatronAnalisis>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones anlisis>
<adaptarPatronAnalisis>
FIN SI
SI <AdaptarEstiloArquitectural>ENTONCES
<interfaz de invocacin del Servicio Administracin Estilo Arquitectural>
<adaptarEstiloArquitectural>

74
FIN SI
SI <AdaptarPatronDiseo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Diseo>
<adaptarPatronDiseo>
FIN SI
SI <AdaptarPatronInterfaz>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Interfaz>
<adaptarPatronInterfaz>
FIN SI
SI <AdaptarPatronEventosInteraccion>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Eventos>
<adaptarPatronEventosInteraccion>
FIN SI
SI <AdaptarPatronFlujoTrabajo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Flujo Trabajo>
<adaptarPatronFlujoTrabajo>
FIN SI
FIN SI
SI <evaluarPatron>ENTONCES
SI <EvaluarPatronAnalisis>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones anlisis>
<evaluarPatronAnalisis>
FIN SI
SI <EvaluarEstiloArquitectural>ENTONCES
<interfaz de invocacin del Servicio Administracin Estilo Arquitectural>
<evaluarEstiloArquitectural>
FIN SI
SI <EvaluarPatronDiseo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Diseo>
<evaluarPatronDiseo>
FIN SI
SI <EvaluarPatronInterfaz>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Interfaz>
<evaluarPatronInterfaz>
FIN SI
SI <EvaluarPatronEventosInteraccion>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Eventos>
<evaluarPatronEventosInteraccion>
FIN SI
SI <EvaluarPatronFlujoTrabajo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Flujo Trabajo>
<evaluarPatronFlujoTrabajo>
FIN SI
FIN SI
SI <calificarPatron>ENTONCES
SI <CalificarPatronAnalisis>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones anlisis>
<calificarPatronAnalisis>
FIN SI
SI <CalificarEstiloArquitectural>ENTONCES
<interfaz de invocacin del Servicio Administracin Estilo Arquitectural>
<calificarEstiloArquitectural>
FIN SI
SI <CalificarPatronDiseo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Diseo>
<calificarPatronDiseo>
FIN SI
SI <CalificarPatronInterfaz>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Interfaz>
<calificarPatronInterfaz>
FIN SI

75
SI <CalificarPatronEventosInteraccion>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Eventos>
<calificarPatronEventosInteraccion>
FIN SI
SI <CalificarPatronFlujoTrabajo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Flujo Trabajo>
<CalificarPatronFlujoTrabajo>
FIN SI
FIN SI
SI <clasificarPatron>ENTONCES
SI <ClasificarPatronAnalisis>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones anlisis>
<clasificarPatronAnalisis>
FIN SI
SI <ClasificarEstiloArquitectural>ENTONCES
<interfaz de invocacin del Servicio Administracin Estilo Arquitectural>
<clasificarEstiloArquitectural>
FIN SI
SI <ClasificarPatronDiseo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Diseo>
<clasificarPatronDiseo>
FIN SI
SI <ClasificarPatronInterfaz>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Interfaz>
<clasificarPatronInterfaz>
FIN SI
SI <ClasificarPatronEventosInteraccion>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Eventos>
<clasificarPatronEventosInteraccion>
FIN SI
SI <ClasificarPatronFlujoTrabajo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Flujo Trabajo>
<clasificarPatronFlujoTrabajo>
FIN SI
FIN SI
SI <reingenieriaPatron>ENTONCES
SI <ReingenieriaPatronAnalisis>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones anlisis>
<reingenieria<PatronAnalisis>
FIN SI
SI <ReingenieriaEstiloArquitectural>ENTONCES
<interfaz de invocacin del Servicio Administracin Estilo Arquitectural>
<reingenieriaEstiloArquitectural>
FIN SI
SI <ReingenieriaPatronDiseo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Diseo>
<reingenieriaPatronDiseo>
FIN SI
SI <ReingenieriaPatronInterfaz>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Interfaz>
<reingenieriaPatronInterfaz>
FIN SI
SI <ReingenieriaPatronEventosInteraccion>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Eventos>
<reigenieriaPatronEventosInteraccion>
FIN SI
SI <ReingenieriaPatronFlujoTrabajo>ENTONCES
<interfaz de invocacin del Servicio Administracin Patrones Flujo Trabajo>
<reingenieriaPatronFlujoTrabajo>
FIN SI
FIN SI

76
FIN SI
SI <capturarError> ENTONCES
11. <Administrador Patrones><capturaError>
FIN SI
12. <Administrador Patrones><enviaRespuesta>
END < Administrador Patrones>
Trayectorias Alternati vas
<parmetros patrn incorrectos>
1. <Proceso Externo><pantalla de invocacin del servicio de
Administracin de Patrones><vuelve a enviar los parmetros de
patrn><parmetros de patrn deben ser correctos>
Poscondicin El Proceso Externo recibe respuesta del requerimiento de administracin de patrn
si los parmetros inciales son correctos, en caso contrario recibe un error.
Requisito No
Funcional

Comentario
Tabla 5 Caso de Uso Administrador Patrones

Figura 25 Caso de uso Administrador Interfaz.


77
Caso de Uso Administrador Interfaz
Resumen Recibe las solicitudes de procesos externos a travs del servicio de administracin
de Interfaz, procesa las solicitudes y enva la respuesta.
Actor Proceso Externo, Administrador Interfaz, Administrador Patrones interaccin,
Administrador Identidad, Administrador Eventos Interfaz, Administrador Tarea
Precondicin
Descripcin <Administrador patrn interaccin>INICIA CUANDO <Proceso Externo><invoca al
Servicio de Administracin de Interfaz>

13. <Proceso Externo><interfaz de invocacin del Servicio de Administracin de
Interfaz><introduce parmetros inciales de Interfaz><parmetros de Interfaz
deben ser correctos>
14. <Administrador Interfaz>
<recibeparametros><parmetros de Interfaz deben ser correctos><interfaz de
invocacin del Servicio de Administracin de Identidad><verificarPermisologia>
15. <Administrador Interfaz><procesaInterfaz>
SI <crearInterfaz>ENTONCES
16. <Administrador Interfaz>
<interfaz de invocacin del Servicio de Administracin Patrones Interaccin>
<seleccionarPatron><configurarPatron><aplicarPatron>
FIN SI
SI <modificarInterfaz>ENTONCES
17. <Administrador Interfaz>
<interfaz de invocacin del Servicio de Administracin Patrones Interaccin>
<seleccionarPatron><configurarPatron><aplicarPatron>
FIN SI
SI <validarInterfaz>ENTONCES
18. <Administrador Interfaz>
<interfaz de invocacin del Servicio de Administracin Patrones Interaccin>
<seleccionarPatron><validarPatron>
FIN SI
SI <mostrarInterfaz>ENTONCES
19. <Administrador Interfaz><mostrarInterfaz>
FIN SI
SI <eliminarInterfaz>ENTONCES
20. <Administrador Interfaz><eliminarInterfaz>
FIN SI
SI <capturarEventoInterfaz>ENTONCES
21. <Administrador Interfaz>
<interfaz de invocacin del Servicio de Administracin Evento Interfaz>
<validarEventoInterfaz>
FIN SI
SI <capturarOperacionInterfaz>ENTONCES
22. <Administrador Interfaz>
<interfaz de invocacin del Servicio de Administracin Tarea>
<ejecutarTarea>
FIN SI
SI <capturarError> ENTONCES
23. <Administrador Interfaz><capturaError>
FIN SI
24. <Administrador Interfaz><enviaRespuesta>
END < Administrador Interfaz>

Trayectorias Alternati vas
<parmetros Interfaz incorrectos>
2. <Proceso Externo><pantalla de invocacin del servicio de
Administracin de Interfaz><vuelve a enviar los parmetros de
Interfaz><parmetros de Interfaz deben ser correctos>
Poscondicin El Proceso Externo recibe respuesta del requerimiento de administracin de Interfaz
si los parmetros inciales son correctos, en caso contrario recibe un error.

78
Requisito No
Funcional

Comentario
Tabla 6 Caso de Uso Administrador Interfaz



Figura 26 Caso de uso Administrador de Tareas.
Caso de Uso Administrador de Tareas
Resumen Recibe las solicitudes de procesos externos a travs del servicio de administracin
de la tarea, procesa la tarea y enva la respuesta.
Actor Proceso Externo, Administrador de Tareas, Administrador Identidad, Administrador
Estado Transicin, Administrador Documentacin, Administrador Acuerdos de
Servicio, Administrador
Precondicin Administrador Interfaz, Administrador Eventos
Descripcin <Administrador de Tareas> INICIA CUANDO <Proceso Externo><invoca al Servicio
de Administracin de Tareas>
1. <Proceso Externo><interfaz de invocacin del Servicio de Administracin de
Tareas><introduce parmetros inciales para la tarea><parmetros de la
tarea deben ser correctos>
2. <Administrador de Tareas>

79
a. <recibeRequerimiento>
b. <asignaParametrosIniciales>
c. <creaInstancia>
d. <asignaParametrosNuevaInstacia>
<parmetros de la tarea deben ser correctos>
3. <Administrador de Tareas><procesaRequerimiento>
SI <modificar> ENTONCES
4. <Administrador de Tareas><interfaz de invocacin del Servicio del
Administrador de Identidad ><verificaPermisologa>
5. <Administrador de Tareas><interfaz de invocacin del Servicio del
Administrador de EstadoTransicion><verificaEstadoTransicion>
6. <Administrador de Tareas><interfaz de invocacin del Servicio del
Administrador de Documentacion><verificaDocumentacion>
7. <Administrador de Tareas><interfaz de invocacin del Servicio del
Administrador de Acuerdos de Servicio><verificaAcuerdodeServicio>
8. <Administrador de Tareas><interfaz de invocacin del Servicio del
Administrador de Calendario><calculaTiempos>
9. <Administrador de Tareas><asignaAuditoria>
10. <Administrador de Tareas><interfaz de invocacin del Servicio del
Administrador de Notificaciones><verificaNotificacion>
FIN SI
SI <completar> ENTONCES
11. <Administrador de Tareas><interfaz de invocacin del Servicio del
Administrador de Identidad ><verificaPermisologa>
12. <Administrador de Tareas><interfaz de invocacin del Servicio del
Administrador de EstadoTransicion><verificaEstadoTransicion>
13. <Administrador de Tareas><interfaz de invocacin del Servicio del
Administrador de Documentacion><verificaDocumentacion>
14. <Administrador de Tareas><interfaz de invocacin del Servicio del
Administrador de Acuerdos de Servicio><verificaAcuerdodeServicio>
15. <Administrador de Tareas><interfaz de invocacin del Servicio del
Administrador de Calendario><calculaTiempos>
16. <Administrador de Tareas><asignaAuditoria>
17. <Administrador de Tareas><interfaz de invocacin del Servicio del
Administrador de Notificaciones><verificaNotificacion>
18. <Administrador de Tareas><interfaz de invocacin del Servicio del
Administrador de Encuesta><verificaEncuesta>
19. <Administrador de Tareas><interfaz de invocacin del Servicio del
Administrador de Soluciones><verificaSolucion>
FIN SI
SI <eliminar> ENTONCES
20. <Administrador de Tareas><eliminaTarea>
FIN SI
21. <Administrador de Tareas><interfaz de invocacin del Servicio del
Administrador de Notificacion><verificaExpiracion>
22. <Administrador de Tareas><enviaRespuesta>
END < Administrador de Tareas>
Trayectorias Alternati vas
<parmetros de la tarea incorrectos>
1. <Proceso Externo><pantalla de invocacin del servicio de
Administracin de Tareas><vuelve a enviar los parmetros de la
tarea><parmetros de la tarea deben ser correctos>
Poscondicin El Proceso Externo recibe respuesta de la operacin o el error asociado a la
ejecucin del requerimiento a travs del administrador de tareas si los parmetros
inciales son correctos, en caso contrario recibe un error.
Requisito No
Funcional

Comentario
Tabla 7 Caso de Uso Administrador de Tareas

80




Figura 27 Caso de uso Administrador de Eventos Tarea

Caso de Uso Administrador de Eventos
Resumen Recibe las solicitudes de procesos externos a travs del servicio de administracin
de eventos de tarea, procesa los eventos y enva la respuesta.
Actor Proceso Externo, Administrador Eventos, Administrador Notificaciones,
Administrador Tarea
Precondicin Administrador Interfaz
Descripcin <Administrador de Eventos> INICIA CUANDO <Proceso Externo><Administrador de
Interfaz><Administrador de Tareas><invoca al Servicio de Administracin de
Eventos>

1. <Proceso Externo><Administrador de Interfaz><Administrador de
Tareas><interfaz de invocacin del Servicio de Administracin de
Eventos><introduce parmetros inciales para el evento><parmetros del
evento deben ser correctos>
2. <Administrador de Eventos><recibeEvento><parmetros del evento deben
ser correctos>
3. <Administrador de Eventos><procesaEvento>
SI <verificarRecordatorio> ENTONCES

81
4. <Administrador de Eventos><interfaz de invocacin del Servicio del
Administrador de Notificaciones><verificaRecordatorio>
FIN SI
SI <verificarExpiracion> ENTONCES
5. <Administrador de Eventos><interfaz de invocacin del Servicio del
Administrador de Notificaciones><verificaExpiracion>
FIN SI
SI <verificarEliminacion> ENTONCES
6. <Administrador de Eventos><interfaz de invocacin del Servicio del
Administrador de Tareas><verificaEliminacion(comounamodificacion)>
FIN SI
SI <reanudarTarea> ENTONCES
7. <Administrador de Eventos><reanudaTarea>
FIN SI
SI <suspenderTarea> ENTONCES
8. <Administrador de Eventos><suspendeTarea>
FIN SI
SI <capturarError> ENTONCES
9. <Administrador de Eventos><capturaError>
FIN SI
10. <Administrador de Eventos><enviaRespuesta>
END < Administrador de Eventos>

Trayectorias Alternati vas
<parmetros evento incorrectos>
1. <Proceso Externo><Administrador de Interfaz><Administrador de
Tareas><pantalla de invocacin del servicio de Administracin de
Eventos><vuelve a enviar los parmetros del evento><parmetros del
evento deben ser correctos>
Poscondicin El Proceso Externo, Administrador de Interfaz, Administrador de Tareas recibe
respuesta del evento o el error asociado a la ejecucin del requerimiento de evento
a travs del administrador de eventos si los parmetros inciales son correctos, en
caso contrario recibe un error.
Requisito No
Funcional

Comentario
Tabla 8 Caso de Uso Administrador de Eventos Tarea


82

Figura 28 Caso de uso Administrador de Identidad.

Caso de Uso Administrador de Identidad
Resumen Recibe las solicitudes de procesos externos a travs del servicio de administracin
de identidad, procesa las solicitudes contra un LPAD, meta directorio, o base de
datos de identificacin de usuarios y enva la respuesta. Tomando en cuenta una
jerarqua donde una persona o grupo de personas tienen asociada una ubicacin
geogrfica (localidad) y pertenecen a una estructura organizacional (organigrama);
las personas estn asociadas a los grupo funcionales; las personas y los grupos
tiene asociados roles y los roles tienen asociadas permisologas corresponden con
el mayor nivel de la jerarqua.
Actor Proceso Externo, Administrador de Tareas

83
Precondicin Administrador de Tareas
Descripcin <Administrador de Identidad> INICIA CUANDO <Proceso Externo><Administrador
de Tareas><invoca al Servicio de Administracin de Identidad>

<Proceso Externo><Administrador de Tareas><interfaz de invocacin del
Servicio de Administracin de Identidad><introduce parmetros inciales de
identidad><parmetros de identidad deben ser correctos>
<Administrador de Identidad><recibeIdentidad><parmetros de identidad
deben ser correctos>
<Administrador de Identidad><procesaIdentidad>
SI <consultarIdentidad> ENTONCES
<Administrador de Identidad><consultaIdentidad>
FIN SI
SI <crearIdentidad> ENTONCES
<Administrador de Identidad><crearIdentidad>
FIN SI
SI <modificarIdentidad> ENTONCES
<Administrador de Identidad><modificarIdentidad>
FIN SI
SI <eliminarIdentidad> ENTONCES
<Administrador de Identidad><eliminarIdentidad>
FIN SI
SI <asociarIdentidad> ENTONCES
<Administrador de Identidad><asociarIdentidad(roles a
permisologia;personas o grupos a roles;personas a grupos;localidades a
personas o grupos; estructura organizacional a persas o grupos>
FIN SI
SI <validarIdentidad> ENTONCES
<Administrador de Identidad><validarIdentidad>
FIN SI
SI <capturarError> ENTONCES
<Administrador de Identidad><capturaError>
FIN SI
<Administrador de Identidad><enviaRespuesta>
END < Administrador de Identidad>

Trayectorias Alternati vas
<parmetros identidad incorrectos>
1. <Proceso Externo><Administrador de Tareas><pantalla de
invocacin del servicio de Administracin de Identidad><vuelve a
enviar los parmetros de Identidad><parmetros de Identidad deben
ser correctos>
Poscondicin El Proceso Externo, Administrador de Tareas recibe respuesta del requerimiento de
identidad o el error asociado a la ejecucin a travs del administrador de identidad si
los parmetros inciales son correctos, en caso contrario recibe un error.
Requisito No
Funcional

Comentario
Tabla 9 Caso de Uso Administrador de Identidad



84

Figura 29 Caso de uso Administrador de Estado Transicin.

Caso de Uso Administrador de Estado Transicin
Resumen Recibe las solicitudes de procesos externos a travs del servicio de administracin
de estado transicin, procesa las solicitudes y enva la respuesta.
Actor Proceso Externo, Administrador de Tareas
Precondicin Administrador de Tareas
Descripcin <Administrador de Estado Transicin> INICIA CUANDO <Proceso
Externo><Administrador de Tareas><invoca al Servicio de Administracin de Estado
Transicin>

1. <Proceso Externo><Administrador de Tareas><interfaz de invocacin del
Servicio de Administracin de Estado Transicin><introduce parmetros
inciales de estado transicion><parmetros de estado transicin deben ser
correctos>
2. <Administrador de Estado Transicin><recibeestadotransicion><parmetros

85
de estado transicin deben ser correctos>
3. <Administrador de Estado Transicin><procesaEstadoTransicion>
SI <consultarEstadoTransicion> ENTONCES
4. <Administrador de Estado Transicin><consultaEstadoTransicion>
FIN SI
SI <crearEstadoTransicion> ENTONCES
5. <Administrador de Estado Transicin><crearestado><creartransicion>
FIN SI
SI <modificarEstadoTransicion> ENTONCES
6. <Administrador de Estado
Transicin><modificarestado><modificartransicion>
FIN SI
SI <eliminarEstadoTransicion> ENTONCES
7. <Administrador Estado Transicin><eliminarEstado><eliminarTransicion>
FIN SI
SI <validarEstadoTransicion> ENTONCES
8. <Administrador Estado Transicin><validarEstado><validarTransicion>
FIN SI
SI <asociarCalculoTiempo> ENTONCES
9. <Administrador Estado
Transicin><asociaCalculoTiempoEstadoTransicion>
FIN SI
SI <capturarError> ENTONCES
10. <Administrador Estado Transicin><capturaError>
FIN SI
11. <Administrador Estado Transicin><enviaRespuesta>
END < Administrador Estado Transicin>

Trayectorias Alternati vas
<parmetros estado transicin incorrectos>
1. <Proceso Externo><Administrador de Tareas><pantalla de
invocacin del servicio de Administracin de Estado
Transicin><vuelve a enviar los parmetros de Estado
Transicin><parmetros de Estado Transicin deben ser correctos>
Poscondicin El Proceso Externo, Administrador de Tareas recibe respuesta del requerimiento de
Estado Transicin o el error asociado a la ejecucin a travs del administrador de
Estado Transicin si los parmetros inciales son correctos, en caso contrario recibe
un error.
Requisito No
Funcional

Comentario
Tabla 10 Caso de Uso Administrador de Estado Transicin
Durante la especificacin de estos casos de uso se evidencia la necesidad del concepto de
patrones de flujo de trabajo como escenarios de los patrones de anlisis, en el Anexo A1.5,
se proponen los mismos.
Una vez finalizada la especificacin de los casos de uso se sugiere la incorporacin de estos
conceptos a un BPMS existente, para los efectos de la investigacin se seleccion a travs
de una matriz de evaluacin para BPMS (Bonillo, 2005a), el software libre Uengine y se
inicio la incorporacin de los conceptos en esta herramienta, los resultados estn
disponibles y pueden ser consultados, al investigador.
El prximo captulo versar sobre el anlisis de los resultados obtenidos de la aplicacin de
esta metodologa en el Proceso de Gestin de Versiones de ITIL.

86
Captulo V Caso de Estudio

Este Captulo consiste en la aplicacin de la metodologa a un caso del mundo real
utilizando como dominio el proceso de Gestin de Versiones de ITIL. A continuacin para
este proceso se proceder a aplicar cada uno de los pasos propuestos en el capitulo anterior:
5.1. Crear Proceso:
En esta fase de la metodologa se analiza, disea, modela y configura el proceso de Gestin
de Versiones de ITIL, lo cual se describe a continuacin:
5.1.1 Analizar:
Consiste en la evaluacin de los requerimientos tomando en cuenta el tipo de prioridad, se
identifica el proceso y se le asigna prioridad dentro de la organizacin.
De acuerdo a lo establecido en la metodologa una persona de la organizacin solicita la
creacin o modificacin de un proceso a travs de un formato de solicitud (Ver Anexo, 2), a
continuacin se identifica el requerimiento.
Para los efectos del caso de estudio, se asumir que se requiere en una organizacin dada la
creacin del proceso sin que el mismo haya sido analizado o modelado con anterioridad,
por lo que se dar por sentado la fase 5.1.1.1 Identificacin del Requerimiento, que
incluye:
La descripcin del requerimiento: En este caso la descripcin del requerimiento
concuerda con la necesidad de crear un proceso de Gestin de Versiones.
Definir prioridad: La prioridad ser la mayor dado que el proceso que constituye el
caso de estudio, no compite con otros procesos para el anlisis en la organizacin, y ;
Evaluar cartelera de actividades: Las actividades principales se corresponden con 2
grandes fases (meta-procesos de la metodologa) y en ellas se indica la descripcin de
los pasos sugeridos. (Ver, Anexo 3).
Seguidamente se inicia la fase 1.1.2 de Levantamiento de Informacin:
5.1.1.2.1 Mapear al Marco Referencial del Proceso y establecer los Patrones de
Anlisis: Para el caso de estudio, el marco referencial de procesos ser ITIL. Es preciso
citar que estos procesos de soporte a los servicios de ITIL, forman parte de un proceso
mayor el cual varia dependiendo del dominio, por ejemplo en el rea de
Telecomunicaciones existe un mapa de procesos definido por el Foro Mundial de Gestin
de Empresas de Telecomunicaciones (TeleManagementForum) el cual define un marco de
procesos denominado ETOM (de las siglas en ingls Enhanced Telecom Operations Map),
en el que los procesos de soporte a los servicios sugeridos por ITIL se relacionan con los
procesos de ETOM segn como se muestra a continuacin.

87
Proceso ITIL Procesos ETOM Nivel 2 Relacionados
Escritorio de Ayuda
(Service Desk)
CRM Support & Readiness
Customer Interface Management
Selling
Order Handling
Retention & Loyalty
S/P Interface Management
Supply Chain development & Change Management
Gerencia de Incidentes (Incident
Management)
Customer Interface Management
Selling
Order Handling
Problem Handling
Customer QoS/SLA Management
Retention & Loyalty
Service Configuration & Activation
Service Problem Management
Resource Provisioning
Resource Trouble Management
Resource Performance Management
S/P Support & Readiness
S/P Requisition Management
S/P Problem Reporting & Management
S/P Interface Management
Supply Chain Development & Change Management
Gerencia de Problemas
(Problem Management)
SM&O Support & Readiness
Service Problem Management
RM&O Support & Readiness
Resource Trouble Management
S/P Problem Reporting and Management
S/P Performance Management
Supply Chain Development & Change Management
Gerencia de Configuracin
(Configuration Management)
CRM Readiness & Support
Customer QoS/SLA Management
SM&O Support & Readiness
Service Configuration and Activation
Service Problem Management
Service Quality Management
RM&O Support & Readiness
Resource Provisioning
Resource Trouble Management
Resource Performance Management
Resource Data Collection & Processing
S/P Requisition Management
Product & Offer Capability Delivery
Product & Offer Development & Retirement
Service Strategy & Planning
Service Capability Delivery
Resource Development & Retirement
Supply Chain Strategy & Management
Supply Chain Development & Change Management
Group Enterprise Management
Asset Management
Gerencia de Cambios (Change
Management)
SM&O Support & Readiness
RM&O Support and Readiness

88
Resource Provisioning
Resource Trouble Management
Product & Offer Development & Retirement
Service Development & Retirement
Resource Development & Retirement
Supply Chain Development & Change Management
Gerencia de Versiones (Release
Management).
SM&O Support & Readiness
Service Configuration and Activation
Service Problem Management
RM&O Support & Readiness
Product & Offer Capability Delivery
Product & Offer Development & Retirement
Service Capability & Delivery
Service Development & Retirement
Resource Capability Delivery
Resource Development & Retirement
Tabla 11 Relacin Procesos ITIL con el Mapa de Procesos ETOM. Adaptado de TMF
Una vez relacionados los procesos con el marco referencial ITIL a continuacin es
necesario especificar los mismos en base a un Patrn de Anlisis, en el caso del proceso de
Gestin de Versiones, el mismo puede ser especificados como escenario del Patrn de
Anlisis Produccin Propuesto por Ridao en el 2001 (descrito en el Anexo A1.1).
Una vez que se ha estipulado segn un marco referencial cual es la mejor prctica para el
proceso (lo que para los efectos de esta investigacin doctoral a su vez se especifica como
un conjunto de escenarios del Patrn de Anlisis de Produccin), se procede con el
siguiente paso.
5.1.1.2.2. Levantar la situacin actual del proceso, esto es estudiar como se ejecuta el
proceso actualmente en la organizacin, con respecto al caso de estudio se asume que el
proceso se est ejecutando a travs del intercambio de correos electrnicos, sin una base de
datos especifica y sin seguimiento y auditoria, por lo que ser necesario implementarlo de
acuerdo a una mejor prctica, sin embargo es preciso aclarar que este paso de la
metodologa lo que permite es identificar brechas entre como se ejecuta el proceso
actualmente en la organizacin y como debera ejecutarse segn el patrn de anlisis, a fin
que se pueda determinar como ser modelado el procesos y si se asumir la implementacin
de las diferencias encontradas y los riesgos.
Es importante citar que una vez estudiado el proceso desde la mejor prctica y de acuerdo a
cmo se ejecuta en la actualidad en la organizacin, se decidir la forma como se
implementar el mismo y sus diferencias, lo que significara que se requiere realizar un
cambio en la organizacin, es por esto que en este punto de la metodologa se enva un
requerimiento de cambio (RFC) al proceso de gestin de cambio (si el mismo existe), con
la finalidad de indicar que se inicia el cambio en un nuevo proceso o en un proceso
existente (es decir la metodologa a su vez da por sentado que debe existir un proceso de
gestin de cambio en la organizacin y que se debe invocar al mismo), seguidamente se
procede con la siguiente fase.

89
5.1.1 Disear Proceso
Esta fase se inicia con la Estandarizacin de los Procesos (Paso 5.1.2.1) esta
estandarizacin se refiere a indicar en base al anlisis de brecha como se implementar el
proceso tomando en cuenta su situacin actual y la mejor prctica (para el caso de estudio
se implementar el proceso de acuerdo a la mejor prctica).
Seguidamente en 5.1.2.2 se evala el riesgo de implementar las diferencias encontradas en
el anlisis de brechas, para el caso de estudio no se tendrn brechas, pues se implementar
el proceso de acuerdo al patrn de anlisis.
A continuacin se realiza 5.1.2.3 Modelo propuesto de los procesos. Este modelo se
realiza utilizando cualquier herramienta que permita realizar un diagrama en un lenguaje de
modelado de procesos (IDEF, BPMN, BPA, UML, etc.), en el caso del proceso de Gestin
de Versiones esto se realiza a travs de los dibujos incluidos en la descripcin de los
escenarios presentados en el Anexo 4.
Es importante citar en este punto, que la metodologa sugiere, que para poder modelar
adecuadamente los procesos es necesario nombrar los objetos, las clases y sus relaciones a
partir de un modelo cannico o nico de objetos de la organizacin (MOC).
El MOC es el esquema terico que define los objetos pertenecientes a la arquitectura,
indica su amplitud, estructura y los estandariza para lograr un idioma de comunicacin
claro y preciso. El MOC al ser el elemento modelador de la arquitectura, define
fundamentalmente la estructura de los datos y servicios que viajan a travs de la capa de
integracin. (Bonillo, 2007a)
El MOC define en primer lugar, a los objetos que representan los datos corporativos (por
ejemplo: cliente, facturacin, etc.) definiendo el tipo, cantidad y estructura de los campos
que los componen. De esta forma, una de las funciones que cumple el MOC es la de ser un
diccionario de datos evolutivo que garantiza unicidad y claridad en las integraciones entre
las aplicaciones.
El segundo elemento que define el MOC y probablemente el de mayor relevancia, es la
infraestructura de servicios que arropa y reagrupa lgicamente a las funcionalidades de la
organizacin de acuerdo a estndares para el soporte a los servicios, como es el caso de la
iniciativa de java OSS/J (OSS/J, 2005).
El MOC es entonces tambin un diccionario de servicios corporativos que basado en el
universo de funcionalidades disponibles y deseadas, construye agrupaciones lgicas
alineadas con el Mapa ideal de Aplicaciones. La importancia de los servicios (y del
esquema generado por el MOC) se deriva de la utilidad que los mismos tienen como
herramienta indispensable para el modelado de los procesos de negocio a partir de la
implementacin que de ellos se hace en arquitectura de una forma nica estndar orientada
a la reutilizacin.

90
Ya existen esfuerzos significativos para proporcionar en cada dominio un modelo de
objetos cannicos, en el caso de las empresas de telecomunicaciones, TMF basado en
ETOM sugiere un SID (Modelo Compartido de Datos e Informacin).
5.1.2.4 Diseo de la configuracin de laboratorio de hardware y software en el cual se
modelarn e implementarn los procesos, como consecuencia de aplicar la metodologa,
para el caso de estudio se sugiere la siguiente arquitectura:
1. Centro de Modelado de Procesos (CMP): El centro de modelado es la unidad
encargada de generar (modelar) los distintos procesos de la organizacin y de
administrar todos los modelos existentes, para modificacin y actualizacin de los
mismos. Este CMP consta de equipos para el personal encargado de modelar y de
administrar los procesos.
En base al caso de estudio, El CMP sugerido posee una computadora tipo Desktops
para el modelado particular y aislado de los procesos y otra computadora tipo
servidor como equipo para la Integracin y Pruebas de todos los procesos y sus
relaciones.
De acuerdo al caso de estudio se realizo una seleccin de la herramienta BPMS que
se utilizara en la organizacin, resultando seleccionado el BPMS de Software libre
Uengine de acuerdo a los 95 criterios especificados para un BPMS y el mtodo
DESMET. De tal forma que en estos Desktops se tendr la distribucin libre del
sistema operativo Linux Centus OS, la Base de Datos de distribucin libre Hypersonic
(con la finalidad de almacenar las variables que utiliza el modelador de procesos de
Uengine), la herramienta de escritorio de distribucin libre OpenOffice para el diseo
de los procesos y Uengine para el modelado de los procesos, adems del sistema
controlador de versiones (CSV) y la herramienta de conexin remota (VNC). El
Equipo de integracin de todos los procesos, necesariamente necesitar un hardware
de mayor capacidad a fin de lograr la integracin de todos los procesos el cual es el
servidor de desarrollo, parte del CCP.
2. Centro de Coreografa de Procesos (CCP): El centro de coreografa es la unidad
encargada de generar la aplicacin correspondiente por cada proceso que se haya
modelado, uniendo los servicios, objetos, notificaciones, mensajes y excepciones con
todas las aplicaciones que soportan los distintos procesos de la organizacin.
Adicionalmente y en apoyo con la unidad de soporte de aplicaciones, se administran
(mantenimiento adaptativo, correctivo y preventivo) todas las aplicaciones en
produccin.
Este CCP consta de servidores y equipos para el personal encargado de generar la
completitud para la creacin de las aplicaciones y de administrar las aplicaciones
existentes, as como, de permitir la conexin de usuarios.
El CCP posee tres servidores para su operacin. El servidor de desarrollo, al cual se
conectan los consultores del CCP para generar la completitud de los modelos (UML,

91
WSDL y BPEL), realizar la coreografa para cada proceso y para la creacin de la
aplicacin final, as como administrar las aplicaciones de los distintos procesos
existentes en la organizacin realizando tambin las pruebas unitarias. El servidor de
calidad (QA) el cual contiene una muestra real (lo ms cercana posible al sistema
en produccin) del mapa de aplicaciones para cada proceso de la organizacin y en el
que se realizan las pruebas integrales y el servidor de Produccin, donde se
encuentran todas las aplicaciones en ambiente productivo y donde debe existir una
instancia del BPMS por cada aplicacin existente con otra para la alta disponibilidad.
En estos Servidores se sugiere la distribucin libre del sistema operativo Linux Red
Hat 4 Application Server, la Base de Datos de distribucin libre Hypersonic (con la
finalidad de almacenar las variables que utiliza el administrador de procesos de
Uengine), y Uengine para la administracin de los procesos, adems del sistema
controlador de versiones CSV y la herramientas de conexin remota VNC y Secure
Shell.
A continuacin se describe el siguiente paso de la metodologa.
5.1.3 Modelar
Consiste en: 5.1.3.1 Diagramar los procesos en un ambiente local con la herramienta de
modelado de procesos del CMP (Uengine para el caso de estudio) tomado en cuenta
adems el MOC. En este paso adems se decide cual ser el estilo arquitectural, el patrn
arquitectural y los patrones de diseo, interaccin y cdigo que se asociaran al proceso.
Para los procesos del caso de estudio se seleccionaron los siguientes patrones:
Estilos arquitectnicos:
Estilos de Flujo de Datos: Esta familia de estilos enfatiza la reutilizacin y la
modificabilidad. Es apropiada para sistemas que implementan transformaciones de
datos en pasos sucesivos. El proceso de Gestin de Versiones de ITIL aplica este estilo
ya que para hacer el manejo de una nueva versin de un producto se debe hacer
transformaciones de datos de manera sucesiva actualizando la CMDB.
Sistemas de control de procesos: Se caracterizan no slo por los tipos de componentes,
sino por las relaciones que mantienen entre ellos. En el caso de del proceso de Gestin
de Versiones de de ITIL, se observa que el estilo arquitectnico Sistemas de control de
procesos esta presente ya que se tiene una relacin entre diferentes componentes como
Gestin de Cambios y Gestin de Configuraciones.
Patrones arquitectnicos:
Tubera y filtros: Una tubera (pipeline) es una arquitectura que conecta componentes
computacionales (filtros) a travs de conectores (pipes), de modo que las
comunicaciones se ejecutan como un flujo. El sistema tubera-filtros se percibe como
una serie de transformaciones sobre sucesivas piezas de los datos de entrada. Los datos
entran al sistema y fluyen a travs de los componentes. De esta manera para que una

92
nueva versin sea aceptada debe pasar por un procedimiento aplicando los Estilos
arquitectnicos Tubera y filtros (pipe&filter).
Arquitecturas de Pizarra o Repositorio: En este estilo arquitectnico hay dos
componentes principales; una estructura de datos que representa el estado actual y una
coleccin de componentes independientes que operan sobre l. Haciendo la analoga
con respecto a este estilo y al proceso de gestin de Versiones de ITIL, se tiene que la
estructura de datos es la conocida como CMDB y los diferentes componentes que
operan sobre la CMDB son Gestin de versiones, Gestin de Cambios y Gestin de
Configuraciones.
Patrones de diseo:
Command: Este patrn permite solicitar una operacin a un objeto sin conocer realmente el
contenido de la operacin, ni el receptor real de la misma. Para ello se encapsula la
peticin como un objeto, con lo que adems se facilita la parametrizacin de los
mtodos. En el caso del Proceso de Gestin de Versiones de ITIL se aplica este patrn,
ya que debe "deshacer" un versionamiento no exitoso.
Memento: Tiene como finalidad almacenar el estado de un objeto (o del sistema completo)
en un momento dado de manera que se pueda restaurar en ese punto de manera sencilla.
Para ello se mantiene almacenado el estado del objeto para un instante de tiempo en una
clase independiente de aquella a la que pertenece el objeto (pero sin romper la
encapsulacin), de forma que ese recuerdo permita que el objeto sea modificado y
pueda volver a su estado anterior. En el proceso de Gestin de Versiones de ITIL, se
puede ver la aplicacin de este patrn ya que si una versin no es exitosa y se debe
regresar, la versin anterior del mismo se encuentra almacenada.
Fotografa (Snapshot): Este patrn captura una fotografa del estado de un objeto para
que este estado pueda luego ser restaurado. El objeto que inicia la captura o
restauracin del estado no necesita conocer nada acerca de la informacin del estado.
Slo necesita saber que el objeto cuyo estado est siendo capturado o restaurado,
implementa una interfaz particular. En el proceso de Gestin de Versiones de ITIL se
puede ir a una versin especfica del proceso.
Patrones de Interaccin:
Portal: Se utilizaron todos los patrones de interaccin disponibles en Liferay que es el
portal de manejo de contenido, en el que se construyo el motor de procesos de Uengine,
el cual permite tomar cualquier pantalla y aplicar patrones de interaccin ms atmicos
como calendarios, botones de seleccin, etc.
Idiom:
El idiom seleccionado es Java, ya que Uengine esta est desarrollada bajo ste lenguaje
de programacin.

93
Es importante citar que al realizar la seleccin de estos patrones y considerar los mismos en
la elaboracin del caso de estudio, adems de utilizar las mejores prcticas se obtuvo un
menor tiempo de diseo de los procesos comparado con un proceso de la misma
complejidad que se realiz en el modelador de procesos Uengine sin aplicar los patrones,
fundamentalmente dada la capacidad de reutilizar el conocimiento ya existente tanto para
su adaptacin como para su extensin.
Para modelar los procesos segn las mejores prcticas la metodologa sugiere que los
patrones de anlisis y sus escenarios se expresen a travs de los patrones de flujo de trabajo
descritos en el Anexo A1.5.
Lo que sugiere entonces la metodologa, es que al modelar el proceso se utilicen de forma
automtica estos patrones de flujo de trabajo, con la finalidad de cumplir con esto en el
caso de estudio, se realizaron en la herramienta Uengine, estos procesos correspondientes a
los patrones de flujo de trabajo y se incluyeron de tal forma que puedan ser utilizados
automticamente en el modelado de los procesos del caso de estudio.
5.1.3.2 Simular Prueba Funcional, se realiza una simulacin de la funcionalidad del
proceso en la herramienta de modelado (las herramientas de modelado de procesos,
comnmente contienen la funcionalidad de realizar una simulacin a fin de detectar
tendencias, cuellos de botella en los procesos modelados).
5.1.3.3 Integrar Arquitectura de Procesos y 5.1.3.4 Simular Prueba Integral.
Para finalizar el subproceso de modelar, se realizar una simulacin integral de todos los
procesos, esto con la finalidad de detectar problemas sobre la sinergia de los procesos y sus
consecuencias.
5.1.4 Configurar
En este paso, se tomo el proceso de Gestin de Versiones de ITIL y se realiz una
Implementacin en el Motor de Ejecucin de Procesos de Uengine, de tal forma que se
realizaron las siguientes acciones:
5.1.4.1 Completar los diagramas UML, se realizaron todos los diagramas UML del caso
de estudio, y se verificaron los mismos de acuerdo al resultado obtenido en el diseador de
procesos Uengine;
5.1.4.2 Construir la Lgica de Negocio, en este paso se utilizaron las bondades del
diseador de procesos de Uengine y se construyeron las reglas de negocio, las tablas, las
interacciones, los servicios locales, servicios Web (en este caso la metodologa contempla
que si es necesario realizar servicios Web y alguna otra lgica de negocio especial, se
contacte a un proceso de Arquitectura el cual construir estos servicios, en este caso no fue
necesario dado que los procesos se modelaron de forma local) y las tablas de acuerdo a los
estilos arquitecturales, patrones arquitectnicos y patrones de diseo seleccionados en el
paso 5.1.3;

94
5.1.4.3 Construir Interfaz, en este paso se utilizaron los patrones de interfaz disponibles
en Uengine al realizar la accin de mejorar customize las ventanas del objeto Trabajo
Humano Human Work de Uengine;
5.1.4.4 Construir Reportes, para la creacin de los reportes se utilizo la propiedad de
anlisis multidimensional que incluye a travs de creacin de cubos la aplicacin Uengine,
se aplicaron costos a las actividades y se configuraron los tiempos, teniendo todos estos
datos disponibles en el momento de generar los reportes.
5.1.4.5 Configurar el BPEL, se procedi a la revisin del BPEL y su implementacin en el
Motor de Ejecucin de procesos de Uengine;
5.1.4.6 Realizar Pruebas Unitarias, finalmente en esta fase se realiz la prueba unitaria en
el motor de ejecucin, simulando a travs de ejemplos todas las alternativas posibles para
los diferentes flujos de trabajos modelados para el Proceso de Gestin de Versiones de
ITIL.
El resto de los pasos de la metodologa (5.2.1 Mantener configuraciones y 5.2.2
Monitoreo) no se realizaron dado que se llego solo a la configuracin de los procesos de
acuerdo al alcance contemplado en el caso de estudio. Sin embargo los mismos se refieren a
las tareas de mantenimiento una vez que los procesos sean colocados en produccin.
A continuacin se describen las conclusiones y recomendaciones de la investigacin.

95
Captulo VI Conclusiones y Recomendaciones

En la caracterizacin de las organizaciones como sistema complejo, fue de gran utilidad la
representacin de las mismas a travs de la teora general de los sistemas, permitiendo as
seleccionar los procesos de desarrollo de software UP, XP y FDD, los diferentes patrones
de software, lo que condujo al planteamiento de una nueva taxonoma de patrones, con su
representacin a travs de un metapatrn (incluyendo su medicin de calidad con ABAS e
ISO-9126 e ISO-1458) y la posterior relacin de todos estos conceptos en el dominio de
gerencia de procesos de negocio.
Es importante citar que con base en todo lo discutido hasta este momento de la
investigacin, no existe en la actualidad un tratamiento lo suficientemente exhaustivo y
consolidado de los temas de gerencia de los procesos del negocio sustentada en el uso de
patrones, tomando en cuenta la trazabilidad y la calidad del proceso y el producto de
software. Mediante esta investigacin se atacan estas deficiencias, proponiendo la
construccin de:
1. Una tecnologa de patrones para la metodologa de gerencia de procesos de negocio
con base en la construccin sustentada en componentes de software: un estudio de las
alternativas existentes para la seleccin, aplicacin y verificacin de patrones y de la
composicin de componentes de software desde el punto de vista de los
condicionantes planteados aqu (trazabilidad, medicin de calidad, verificacin
esttica, automtica y asequible).
2. Una definicin de patrn abierta y aplicable en muy diversos mbitos del diseo,
desarrollo y mantenimiento del software sin perder de vista que el software es uno
slo a pesar de los diversos enfoques de patrones y construccin que existen en la
ingeniera de software, y que debe existir un marco referencial que integre estos
enfoques en pro de una sola actividad de elaboracin de software.
3. Un mtodo de modelado de patrones que permita la trazabilidad, y que puede ser
aplicado sobre entidades de muy diferentes tipos y en etapas diversas del ciclo de
vida del software. Este mtodo de modelado y verificacin tiene adems
caractersticas especiales:
- Puede ser utilizado con facilidad por una organizacin de desarrollo, sin necesidad
de conocimientos sobre mtodos formales.
- Fomenta la coleccin y uso de conocimiento que habitualmente se pierde.
- Permite gestionar este conocimiento sin necesidad de integrarlo en el cdigo
fuente de los programas desarrollados.
- No est ligado a ningn lenguaje de desarrollo especfico ni a ningn propsito
especfico.

96
4. Un sistema de verificacin de componentes plenamente viable en la prctica:
- Las herramientas pueden desarrollarse en base a tecnologas en red.
- Los conocimientos bsicos necesarios encajan en el perfil tpico de los
profesionales del desarrollo de software, no planteando un gran choque de
mentalidad en su adquisicin en el caso que sea necesario.
5. Diversos prototipos que apoyan la viabilidad de los mtodos propuestos.
El uso de los patrones en la construccin de software basado en componentes suele recurrir
a descripciones de las interfaces de los componentes, entendidas (con las variaciones
procedentes en cada caso) como una coleccin de mtodos y de parmetros que reciben las
denominadas signaturas. Cuando se combinan patrones y componentes, es frecuente que se
verifique que dichas signaturas encajan correctamente, y existen medios (que han alcanzado
plena difusin) para detectar esto en etapas tempranas de ese proceso de combinacin. Sin
embargo, existen defectos que no tienen relacin alguna con las signaturas de los
componentes, y que surgen tambin de su combinacin. Y estos defectos no suelen
detectarse de forma automatizada; no parece haber alcanzado amplia difusin algn mtodo
encaminado a tener en cuenta las restricciones de funcionamiento de los componentes y a
poner en relacin esas restricciones, sean del tipo que sean (funcionales, de rendimiento, de
propsito y de dominios). La experiencia profesional demuestra que en muchas ocasiones
estos defectos se detectan en la fase de prueba, o peor an, en la fase de explotacin, la
metodologa propuesta permite detectar en las etapas tempranas estas consistencias con un
menor impacto en las ltimas etapas del desarrollo.
Muchos de estos defectos podran detectarse en etapas tempranas, tales como las
incongruencias de signaturas. Slo se necesitara un mtodo que permitiese adjuntar a cada
componente una descripcin de las restricciones conocidas respecto a su funcionamiento, y
utilizar esas restricciones en un sistema de verificacin. Tal como se propone en el
metapatrn utilizado a travs de la metodologa expuesta en este trabajo.
Este mtodo debera presentar ciertas propiedades importantes. La verificacin debera ser
esttica en el sentido descrito; no se trata de probar el sistema en ejecucin, sino de llegar a
conclusiones mediante el anlisis a priori de la informacin disponible, es decir ver el
resultado de la calidad del patrn en el proceso y el producto de software. La verificacin
debe tambin ser automtica porque eso es lo que posibilita que sea realizada
repetidamente, a un bajo costo y que ofrezca resultados no ambiguos, esto en especial se
permite bajo el paradigma BPM.
Algunos mtodos formales (u otras tcnicas) podran ser utilizados para propsitos
similares a los planteados aqu; pero la percepcin que se tiene de los mtodos formales y
su dificultad de adopcin impiden en la prctica una difusin a gran escala. La metodologa
propuesta observa en todo momento como prioritario la simplicidad, viabilidad tcnica,
flexibilidad de aplicacin y facilidad de adopcin que otras tcnicas no contemplan.

97
Durante la elaboracin de esta tesis doctoral se han logrado avances no slo en cuanto a la
definicin de las bases tericas y metodolgicas, sino tambin en el sentido prctico, se
realizo un proceso de evaluacin de un BPMS en software libre, siendo seleccionado
Uengine, se realizaron seis tesis de pregrado en ciencias de la computacin, en las cuales,
se utiliz Uengine y se aplico la metodologa de gestin de procesos de negocio sustentada
en el uso de patrones en los procesos de soporte a los Servicios de ITIL: Escritorio de
Servicio, Gestin de Incidentes, Gestin de Problemas, Gestin de Cambio, Gestin de
Versiones, Gestin de Configuracin; en relacin a la taxonoma de patrones, se realizo una
tesis de pregrado en ciencias de la computacin, donde se automatizo un proceso de
utilizacin del metapatrn, se relacionaron algunos patrones y se midieron sus atributos de
calidad para un caso de estudio.
La propuesta de tesis aqu planteada es que es posible dotar a la tecnologa de patrones de
esos mtodos. Y la demostracin de esta tesis se ha basado en la construccin de un marco
referencial integrado, una propuesta metodolgica y su aplicacin en seis casos de estudio.
La validacin de la metodologa desarrollada se basa en la implementacin de prototipos
del sistema de verificacin a travs de los casos de estudio en el dominio de la gerencia de
los procesos de negocio (BPM), la aplicacin de esos prototipos a diferentes tipos de
problemas, y el sometimiento de la metodologa al dictamen de expertos en los diferentes
mbitos involucrados.
El proceso de desarrollo de prototipos mediante el caso de estudio, siempre mediante
tcnicas fiables y ampliamente disponibles, sirvi para constatar que el desarrollo de
herramientas que soporten la metodologa es tcnicamente viable.
En la realizacin del arqueo bibliogrfico y dems consultas hechas a las diferentes fuentes
documentales para la realizacin de la presente investigacin, y en el tiempo mismo de
recoleccin de toda la data necesaria para la misma, no se hicieron presente situaciones
emergentes no solucionables que impidiesen la consecucin de los objetivos planteados.
Especficamente, result complicado establecer las diferencias entre estilos arquitecturales,
patrones de arquitectura y patrones de diseo, eso sin mencionar los patrones de anlisis,
cdigo (o "idioms"). Por esa razn, inicialmente se utilizaron indiscriminadamente, luego
se establecieron las diferencias entre ellos y se aclar que no slo se habla de patrones de
diseo al nivel de diseo detallado, sino que tambin se puede hablar de patrones de
diseo al nivel de arquitecturas. Es por esto que algunos autores lo tratan como sinnimos;
adems, hay mtodos y tcnicas que pueden ser aplicados, tanto en estilos como en
patrones arquitecturales, por lo que su diferenciacin, quizs, no sea necesaria.
Es importante explicitar los problemas para la seleccin y aplicacin de patrones. Y no es
de extraar que la mayora de estos problemas estn relacionados con la seleccin de los
mismos. No es extrao, pues, a veces, las diferencias entre unos y otros son muy sutiles, lo
que puede ser factor determinante en desarrolladores con poca experiencia.
Tambin se observa que los patrones de diseo tienen una limitacin: es difcil evaluarlos
con base en un modelo de calidad particular, por lo que el estudio del tema ABAS, una

98
estructura que extiende la representacin dada por GoF con la finalidad de especificar la
informacin sobre las caractersticas de calidad relativas a cada patrn, fue pertinente para
profundizar en el tema de patrones.
Con relacin a los ADLs, vale mencionar que todos los elementos constitutivos que se
mencionaron en el texto, son deseables; pues, Vestal (1996), en sus investigaciones sobre el
tema, concluye que todos los ADLs deben soportarlos en algn grado.
El enfoque de diseo arquitectural de UP encaja como un "framework" de procesos
genrico que puede ser fcilmente modificado para el mtodo J. Bosch o el mtodo ABD o
cualquier combinacin de los metidos expuestos.
Por otra parte, el mtodo UP y el mtodo Bosch coinciden en el hecho de que la
arquitectura inicial debe ser seleccionada sobre la funcionalidad bsica, por ejemplo a partir
de las abstracciones principales del sistema. Esta arquitectura inicial es entonces
transformada en el proceso de diseo arquitectural.
Por otra parte, UP considera la revisin, que son los puntos principales de ATAM, en el
modelo de prueba.
Los siguientes principios generales de diseo arquitectural son propuestos para sintetizar
las principales actividades de los mtodos de diseo discutidos (Losavio et al., 2004):
1. Iniciar con los requisitos funcionales.
2. Capturar los requisitos no funcionales (calidad y negocio)
3. Disear estrategias que pueden basarse o reutilizar estilos arquitecturales o patrones
4. Diseo de la arquitectura por transformaciones sucesivas.
Se puede concluir la investigacin, determinando que no existe actualmente un tratamiento
lo suficientemente exhaustivo y consolidado de los temas de gerencia de los procesos de
negocio sustentada en el uso de Patrones basados en componentes y su calidad, a pesar de
su gran importancia.
Sin mtricas para evaluar el diseo basado en componentes reutilizable no se puede realizar
una verdadera ingeniera del software. Para resolver este conflicto, una posible solucin a
largo plazo puede basarse en dos ideas principales. En primer lugar, no puede haber
consenso sobre temas demasiado genricos. Por ello, es preciso definir y consensuar
modelos de calidad para productos muy especficos. Y en segundo lugar, la evaluacin de
la calidad del diseo basado en componentes (es decir, las medidas que se realizan sobre
sus atributos de calidad) debiera hacerse por entidades independientes, al menos hasta que
los desarrolladores y arquitectos de software adquieran la madurez del tema de calidad,
todo esto dentro de un paradigma sistmico como lo es BPM y bajo una metodologa que
permita la gestin de los patrones de forma auto asistida y por conocimiento previo para la
reutilizacin en base a la extensin y la adaptacin de componentes.

99
Como una recomendacin importante resalta la aplicacin de esos prototipos a problemas
muy diferentes permitiendo comprobar la flexibilidad y amplitud de la propuesta
metodolgica. Deliberadamente, se debern elegir casos de estudio variados, no
relacionados entre s, representativos de diversos aspectos del desarrollo del software, y
sobre todo se deber tratar de casos de estudio que no se haban tenido en cuenta a la hora
de formular el modelo o las herramientas.
Como trabajo futuro, se recomienda la automatizacin de la metodologa a travs de un
BPMS, esto es incluir el sistema de administracin de patrones dentro del BPMS y utilizar
la metadata resultante en los diferentes pasos a fin de agilizar el proceso de desarrollo
teniendo disponible la medicin de calidad de los patrones de forma automatizada.

100
Referencias Bibliogrficas
Acosta, E. y Zambrano, N. Patrones de Interfaces: un concepto integrador en el desarrollo de aplicaciones.
XXVII Conferencia Latinoamericana de Informtica CLEI2001. Mrida, 2001.
Acosta, E. y Zambrano N. Patterns and Objects for User Interface Construction, in Journal of Object
Technology, vol. 3 no. 3 March-April 2004 pp. 75-90
Alexander, C. The Timeless Way of Building. Oxford University Press, 1979.
Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fidsdahl-King, I., Angel, Sh. A Pattern Language.
Oxford University Press, New York, 1977.
Allen, P. y Frost, S. Component-Based Development for Enterprise Systems. Applying the SELECT
PerspectiveTM. Cambridge University Press. 1998.
Barros, O. Arquitectura de Aplicaciones en e-Business. Documento de Trabajo N 26, CEGES, Dpto. de
Ingeniera Industrial, U. de Chile. 2002.
Bell, T. BPM Taxonomy: Creating Clarity in a Confusing Market, Gartner Research Note, Technology, T-18-
9669. 2003.
Bonillo, P. Modelo Sistmico de Evaluacin de Software de Control Remoto. ARTICULO ARBITRADO.
Revista Tecnica de la Universidad del Zulia, 2004.
Bonillo, P. Modelo de Calidad de Software Educativo. Jornadas de Postgrado de la UPEL. Caracas. Distrito
Capital, 2004
Bonillo, P. Evaluacin de Arquitecturas de Gerencia de Procesos de Negocio. LV Convencin Anual de
ASOVAC. Caracas. Distrito Capital, 2005.
Bonillo, P. Propuesta Metodolgica para la Gerencia de Procesos de Negocio. LV Convencin Anual de
ASOVAC. Caracas. Distrito Capital, 2005.
Bonillo, P. Patrones de Flujo de Trabajo para la Gerencia de Procesos de Negocio. LV Convencin Anual
de ASOVAC. Caracas. Distrito Capital, 2005.
Bonillo, P. Gerencia de la Tecnologia de Informacion y Comunicacin en Organizaciones Transcomplejas en
la Posmodernidad. Caso de Estudio: Compaa Anonima Nacional de Telefonos de Venezuela (CANTV).
Jornadas de Investigacin en Gerencia Universidad Yacamb. Barquisimeto. Estado Lara, 2005.
Bonillo, P. Propuesta de un Meta-Patrn para la Evaluacin de la Calidad en los Patrones de Software. LVI
Convencin Anual ASOVAC. Cumana. Estado Sucre, 2006.
Bonillo, P. Propuesta Metodolgica para la Gerencia de los Procesos de Negocio. ARTICULO
ARBITRADO. Revista de Gesto da Tecnologia e Sistemas de Informao Journal of Information Systems
and Technology Management. Vol. 3, No. 2, 2006, p. 143-162. ISSN online: 1807-1775. Sao Paulo.
BRASIL, 2006.
Bonillo, P. Propuesta de un Marco de Arquitectura Empresarial para la Gestin de Tecnologa y Sistemas de
Informacin. CONTECTSI. Sao Paulo. BRASIL, 2007.

101
Bonillo, P. Propuesta de una Arquitectura de Software Empresarial Orientada a Servicios. CONTECTSI Sao
Paulo. BRASIL, 2007.
Bonillo, P. Methodological Proposal for Business Process Management sustained in the use of Patterns.
Journal Object Technology, Vol 7. No. 5. Sep-Oct 2008.
Bosch, J. Design & Use of Software Architectures. Addison Wesley, 2000.
Braude, E. Ingeniera de software. Una perspectiva orientada a objetos. Mxico: Alfaomega. 2003.
Coad, P. y May, M. JAVA Design: Building Better Apps and Applets 2
nd
Edition. Yourdon Press, Upper
Saddle River, 1999.
Coplien, J. y Schmidt, D. Pattern Languages of Program Design. Addsion- Wesley, Reading, MA, 1995.
Cornella, A. Los Recursos de Informacin, McGrall-Hill S.A., Espaa, p. 76,27. 1996
Davenport, T. Process Innovation Reengineering Work through Information Technology. Harvard Business
School Press, Boston, Massachusetts, 1998.
Douglas, P., Alliger G. y Goldberg R. Client-Server and Object-Oriented Training. En Computer, pginas
8084. June, 1996.
Earl M.J.: The New and the Old of Business Process Redesign. Journal of Strategic Information Systems, Vol.
3, No. 1, 1996, pp. 5 22.
Fowler, M. Analysis Patterns: Reusable Object Models. Addison-Wesley, 1997.
Gamma, E., Helm, R., Johnson, R., y Vlissides, J. Design Patterns. Addison Wesley. 1995
Hammer M., Champy J.: Reengineering the Corporation: A Manifesto for Business Revolution. N. Brealey,
London, 1996.
Harris, K. The Re-emergence of Business Process Design, Gartner Research Note, Strategic Planning, SPA-
21-1352. 2003
Hayward, S. BPM: A Key Ingredient in Business Process Fusion, Gartner Research Note, Markets, M-19-
8201.2003.
ISO/IEC 9126. Information Technology-Software Product Evaluation-Quality Characteristics and Guideline
for Use.2001
ISO/IEC 9126-1, Software Engineering-Product Quality. Part 1: Quality Model, 2001.
ISO/IEC: FCD 9126-1.2: Information Technology - Software Product Quality. Part 1: Quality Model, 1998.
ISO/IEC14598-3. Information Technology - Software Product Evaluation - Part 3: Process for Developers.
Software Engineering, June 1999.
Jacobson, I., Griss, M., y Jonsson, P. Software Reuse. Architecture, Process and Organization for Business
Success. Addison-Wesley. 1997.
Kazman R., y Klein, M. Attribute-Based Architectural Styles. [Documento en lnea]. Disponible en:
http://www.sei.cmu.edu/publications/documents/99.reports/99tr022/99tr022abstract.html. 2004.

102
Larsen, G. Designing component-based frameworks using patterns in the UML. Communications of the
ACM, 42(10):38-45. 1999.
Losavio F., Chirinos L., Matteo A., Lvy Nicole y Ramdane A. 2004. Designing Quality Architecture:
Incorporate ISO Standards into the Unified Process. Information Systems Management, Winter 2004, pg.:
27-44.
MacDonald, S. Information for Innovation. New York, Oxford University Press. 1998.
Magnus, R. Developing a Methodology for the Evaluation Cooperative Systems. Computing Department
Lancaster University. 1997.
Moore T.C., Whinston A.B.: A Model of Decision Making with Sequential Information Acquisition. Decision
Support Systems, Vol. 2, No. 4, 1986, pp. 289 308.
Navasa, A., Prez, M., Murillo, J., y Hernndez, J. Aspect oriented software architecture: A structural
perspective. Reporte del proyecto CICYT, TIC 99-1083-C2-02. 1999.
Paredes, L. Gestin Tecnolgica y reconversin industrial. Revista Espacios, Vol 12. Num. 3. p. 59-77. 2004
Pressman, R. (1997) Managing Change for Rapid Development. IEEE Software. p. 120-122 1997.
Ridao, M. Uso de Patrones en el Proceso de Construccin de Escenarios. Tesis Maestra en Ingeniera de
Software, 2001.
Schmidt, D.Fayad, M y Jonson, R. Software Patterns. Communications of the ACM, 39(10):3739, 1996.
Shael, T. Workflow Management System for Process Organizations. Springer-Verlag Berlin Heidelberg. New
York. 1999.
Strassmann, P. Getting a glimpse, through numbers, of whos using technology well. Baseline 500. 2007
Szyperski, C. Component Software Beyond Object-Oriented Programming. Addison-Wesley, 1997
(reimpreso en 1998). ISBN: 0-201-17888-5
Tamayo, M. El Proceso de Investigacin Cientfica. Limusa Noriega Editores. Mxico. 2000.
Tapscott, D. (1998) La Economa Digital, McGraw-Hill S.A., Bogot. p 4.
Tepfenhart W. y Cusick J. A Unfied Object Topology. IEEE Software, pginas 3135, May/June 1997.
Vestal, S. A cursory overview and comparison of four Architecture Description Languages. Technical Report,
Honeywell Technology Center. 1996.
Vollmer, K. Market Overview: Business Process Management, Giga Research, Planning Assumption, RPA-
022004-00001. 2004.
White, T. New Tools for New Times: The Workflow Paradigm. Future Strategies Inc. Alameda California.
1996.
Win Van Grembergen. Published in Information Technology Evaluation Methods and Management. Idea
Group Publishing, pp. 185-197. 2002


103
Anexo 1 Descripcin Taxonoma de Patrones

A continuacin, en este anexo se explican con mayor detalle cada uno de los patrones que
integran la taxonoma propuesta: anlisis, arquitectural, diseo e interaccin. Al final, se
presentan los patrones de flujo de trabajo como escenarios de los patrones de anlisis, por
lo que no se incluyen los mismos dentro de la taxonoma. De igual forma no se incluye el
tema particular de los idioms, dado que son especficos por tecnologa, sin embargo es
conveniente mencionar que para la mayora de los BPMS, el idiom es JAVA.
A1.1 Patrn de Anlisis.
Segn Alexander, Cada patrn describe un problema que ocurre una y otra vez, y describe la solucin a ese
problema, de tal manera que dicha solucin pueda ser usada un milln de veces ms, sin hacerlo
necesariamente dos veces del mismo modo (Alexander et al., 1997)
La idea central de la construccin de escenarios utilizando patrones consiste en estudiar las situaciones desde
un punto de vista diferente al utilizado por otras tcnicas de elaboracin de escenarios. Se pretende tener una
visin ms conceptual y estructural de las situaciones, con el fin de identificar la naturaleza intrnseca de las
mismas. Con esa visin, ser posible determinar el tipo de escenario correspondiente a cada situacin y as,
elegir un patrn de un catlogo, rehusando su estructura con el fin de derivar el escenario ms fcil y
directamente.

Los patrones son presentados como escenarios descritos a los que se ha agregado un reducido nmero de
reglas de conformacin como meta componentes del escenario. Cada componente del escenario, segn la
estructura definida en (Leite et al., 2000), ha sido completado con un texto nominal que se espera sea
reemplazado en el escenario real generado al usar el patrn pero que a su vez gue en la redaccin del
componente. (Ridao, 2001). En la figura A1.1 se presenta el patrn de Produccin y en la figura A1.2 el
escenario DISEAR LA AGENDA DE REUNIONES correspondiente al caso de estudio Sistema de Agenda
de Reuniones.

Figura A1.1: Descripcin del Patrn Produccin. (Ridao, 2001)


104
Figura A1.2: Ejemplo de un Escenario de Tipo Produccin. (Ridao, 2001)


En cada uno de los ejemplos se puede observar que todos los componentes, adems de los episodios, se
ajustan a la descripcin de los mismos en el patrn correspondiente. Analizando los episodios del escenario de
la Figura A1.2 puede verse que se trata de producciones. Los episodios 2, 4 y 8 corresponden a sub-
escenarios, que fueron analizados en forma independiente y resultaron ser tambin casos de produccin. Por
ello es posible determinar que se trata de un ejemplo puro de Produccin.

A continuacin un listado de los patrones de Anlisis:

1. Produccin
2. Servicio
3. Colaboracin
4. Negociacin Inconclusa
5. Negociacin Inconclusa con Disparador de Escenarios
6. Fin de Negociacin
7. Etapa de Negociacin
8. Etapa de Negociacin con Disparador de Escenarios
9. Negociacin Terminada
10. Produccin + Servicio + Colaboracin
11. Negociacin inconclusa con produccin o servicio o colaboracin
12. Fin de Negociacin con produccin o servicio o colaboracin
13. Etapa de Negociacin con produccin o servicio o colaboracin
14. Negociacin terminada con produccin o servicio o colaboracin

105
15. Negociacin inconclusa con Disparador de Escenarios y produccin o servicio o
colaboracin
16. Etapa de Negociacin con Disparador de Escenarios y produccin o servicio o
colaboracin
17. A Simple Pinboard
18. Structured Pinboard
19. Virtual Library
20. Virtual Library with Active Agents
21. Administrador de sub. Tarea
22. Asignacin Automtica Secuencial con Escalacin
23. Asignacin Automtica Secuencial
24. Asignacin con Escalacin
25. Asignacin Paralela Revisin Final con Escalacin
26. Asignacin Paralela
27. Asignacin sin Notificacin
28. Asignacin
29. Basic Control Patterns
30. Sequence
31. Parallel Split
32. Synchronization
33. Exclusive Choice
34. Simple Merge
35. Advanced Branching and Synchronization Patterns
36. Multiple Choice
37. Synchronizing Merge
38. Multiple Merge
39. Discriminator
40. N-out-of-M Join
41. Structural Patterns
42. Arbitrary Cycles
43. Implicit Termination
44. Cancellation Patterns
45. Cancel Activity
46. Cancel Case
47. Patterns Involving Multiple Instances
48. MI with a priori known design time knowledge
49. MI with a priori known runtime knowledge
50. MI with no a priori runtime knowledge
51. MI without synchronization
52. State-based patterns
53. Deferred Choice
54. Interleaved Parallel Routing

A1.2 Patrn Arquitectural
Es frecuente que se confundan los trminos: estilo y patrn arquitectural; a continuacin se profundizara en el
trmino patrn arquitectural, a fin de establecer las diferencias (Tabla A1.1).

Patrn arquitectural. Buschmann et al. (1996) lo define como una regla que consta de tres partes, la cual
expresa una relacin entre un contexto, un problema y una solucin:
- Contexto. Es una situacin de diseo en la que aparece un problema de diseo.
- Problema. Es un conjunto de fuerzas que aparecen repetidamente en el contexto.
- Solucin. Es una configuracin que equilibra estas fuerzas.

106

Estilo Arquitectnico Patrn Arquitectnico
Slo describe el esqueleto estructural y general para
aplicaciones
Existen en varios rangos de escala,
comenzando con patrones que definen la
estructura bsica de una aplicacin
Son independientes del contexto al que puedan ser
aplicados
Partiendo de la definicin de patrn,
requieren de la especificacin de un
contexto del problema
Cada estilo es independiente de los otros Depende de patrones ms pequeos que
contiene, patrones con los que interacta, o
de patrones que lo contengan
Expresan tcnicas de diseo desde una perspectiva que
es independiente de la situacin actual de diseo
Expresa un problema recurrente de diseo
muy especfico, y presenta una solucin para
l, desde el punto de vista del contexto en el
que se presenta
Son una categorizacin de sistemas Son soluciones generales a problemas
comunes
Tabla A1.1 Diferencias entre estilo y patrn arquitectnico

Para Buschmann et al. (1996) son plantillas para arquitecturas de software concretas, que especifican las
propiedades estructurales de una aplicacin y tienen un impacto en la arquitectura de subsistemas.

La seleccin de un patrn arquitectnico es, por tanto, una decisin fundamental de diseo en el desarrollo de
un sistema de software. Algunos patrones arquitecturales se muestran en la Tabla A1.2.

Patrn Arquitectnico Descripcin
Layers Consiste en estructurar aplicaciones, las cuales pueden ser descompuestas en
grupos o sub-tareas y se clasifican de acuerdo con un nivel particular de
abstraccin.
Pipes and Filters Provee una estructura para los sistemas que procesan un flujo de datos. Cada
paso de procesamiento est encapsulado en un componente filtro (filter). El
dato pasa a travs de conexiones (pipes), entre filtros adyacentes.
Blackboard Aplica para problemas cuya solucin utiliza estrategias no determinsticas.
Varios subsistemas ensamblan su conocimiento para construir una posible
solucin parcial aproximada.
Broker Puede ser usado para estructurar sistemas de software distribuido con
componentes desacoplados que interactan por invocaciones a servicios
remotos. Un componente broker es responsable de coordinar la comunicacin,
el reenvo de solicitudes y la transmisin de resultados y excepciones.
Model-View-Controler Divide una aplicacin interactiva en tres componentes. El modelo (model)
contiene la informacin central y los datos. Las vistas (view) despliegan
informacin al usuario. Los controladores (controlers) capturan la entrada del
usuario. Las vistas y los controladores constituyen la interfaz del usuario.
Presentation-
Abstraction-Control
Define una estructura para sistemas de software interactivos de agentes de
cooperacin, organizados de forma jerrquica. Cada agente es responsable de
un aspecto especfico de la funcionalidad de la aplicacin y consiste en tres
componentes: presentacin, abstraccin y control.

107
Microkernel Aplica para sistemas de software que deben estar en capacidad de adaptar los
requerimientos de cambio del sistema. Separa un ncleo funcional mnimo del
resto de la funcionalidad y de partes especficas pertenecientes al cliente.
Reflection Provee un mecanismo para sistemas cuya estructura y comportamiento cambia
dinmicamente. Soporta la modificacin de aspectos fundamentales como
estructuras, tipos y mecanismos de llamadas a funciones.
Tabla A1.2 Patrones Arquitecturales

A continuacin un listado de los estilos arquitecturales:

1. Estilos de Flujo de Datos
2. Tubera y filtros
3. Estilos Centrados en Datos
4. Arquitecturas de Pizarra o Repositorio
5. Estilos de Llamada y Retorno
6. Model-View-Controller (MVC)
7. Arquitecturas en Capas
8. Arquitecturas Orientadas a Objetos
9. Arquitecturas Basadas en Componentes
10. Estilos de Cdigo Mvil
11. Arquitectura de Mquinas Virtuales
12. Estilos heterogneos
13. Sistemas de control de procesos
14. Arquitecturas Basadas en Atributos
15. Estilos Peer-to-Peer
16. Arquitecturas Basadas en Eventos
17. Arquitecturas Orientadas a Servicios
18. Arquitecturas Basadas en Recursos

Seguidamente un listado de los patrones arquitecturales:

1. Capas
2. Tubera-filtros
3. Pizarra
4. Broker
5. Model-View-Controller
6. Presentation-Abstraction-Control
7. Reflection (metanivel que hace al software consciente de s mismo)
8. Microkernel (ncleo de funcionalidad mnima)
A1.3 Patrones de Diseo
Los patrones de diseo, se ubican en el nivel de diseo detallado, estos describen un problema a ser resuelto,
una solucin y el contexto en el cual la solucin trabaja. Nominan una tcnica y describen su costo y su
beneficio.

Segn Gamma et al. (1995) un patrn de diseo tiene cuatro elementos esenciales:

- El nombre: a cada patrn, se le ha asignado una denominacin que permite que los entendidos en el
tema, puedan conversar usando un diccionario comn. Permite un mayor grado de abstraccin y
permite la comunicacin entre colegas, construyendo un lenguaje compartido. Segn GoF, uno de los
problemas que tuvieron, fue encontrar un nombre apropiado para cada patrn que catalogaron.

108
- El problema: se explica el problema original, y su contexto. Puede describir desde detalles especficos,
como algoritmos, o clases y estructuras que se han encontrado inflexibles a la hora de implementarse.
Todo patrn nace de un problema a solucionar.
- La solucin: cada patrn puede tener una solucin a un problema. Un mismo problema real, puede
tener dos soluciones parecidas, correspondientes a dos patrones (muchas veces pasa esto con el
Abstract Factory, versus el Factory Method, por ejemplo). Pero la eleccin seguramente recaer en el
patrn que mejor se adapte al contexto particular del problema que se tenga. La solucin que un patrn
describe, no necesariamente es detallada al nivel de implementacin, sino que provee una descripcin
abstracta, una enumeracin de elementos y sus relaciones, para solucionar el problema planteado.
- Las consecuencias: son los resultados de aplicar el patrn, los trade-off, compromisos, que se tienen
que aceptar al adoptar el mismo.

Las Propiedades de los patrones de diseo son: (Buschmann et al., 1996)

- Tratan los problemas del diseo que se presentan en situaciones especficas y se repite de manera
recurrente, mostrando una solucin.
- Documentan la experiencia de soluciones probadas a problemas existentes.
- Identifican y especifican las abstracciones sobre el nivel, separndolos en objetos, casos o
componentes.
- Proveen un vocabulario comn y la comprensin de los principios del diseo.
- Son los medios para documentar arquitecturas de software.
- Apoya la creacin de software con propiedades definidas.
- Ayudan en la construccin de arquitecturas complejas y heterogneas.
- Ayudan en el manejo de software complejo.

Gamma y otros (Gamma et al., 1995), consideran que para describir patrones se debe especificar:

- Nombre del patrn y clasificacin. Cada patrn tiene un nombre, y una categora a la que pertenece. El
GoF los clasifica en creacionales, estructurales y de conducta. Ms adelante se profundizar sobre esta
clasificacin.
- Intencin. Depende del contexto. Cada patrn tiene una intencin, una razn, una justificacin.
- Otros nombres. Los patrones haban surgido en distintos proyectos y tecnologas. Los primeros autores
les dieron un nombre que no siempre coincida. Estos otros nombres pueden ser enumerados en la
descripcin del patrn.
- Motivacin. Ms que la intencin, esta parte describe un escenario, un problema en particular que
aparece, y que ayuda a entender la descripcin algo ms abstracta del patrn genrico.
- Aplicacin. En qu situaciones puede ser aplicado un patrn. Pueden darse ejemplos de malos diseos,
que pueden beneficiarse de la aplicacin de este patrn en particular.
- Estructura. La parte ms conocida, luego del nombre. Se adopta un diagrama casi siempre basado en
UML.
- Participantes. La lista de las clases y objetos que participan del patrn de diseo, y las
responsabilidades que tienen.
- Colaboraciones. Descripcin de cmo los participantes colaboran para llevar a cabo sus
responsabilidades en el patrn
- Consecuencias. Explica cmo el patrn cumple con sus objetivos, y que compromisos se asumen.
- Implementacin. Esta es la parte que ms puede variar, porque para cada patrn puede haber varias
posibles implementaciones, incluso, diferentes implementaciones segn la tecnologa adoptada.
- Cdigo de ejemplo. Es recomendable dar cdigo de ejemplo de cada patrn, por ejemplo, en Smalltalk
o en C++.
- Usos conocidos. Un patrn no es tal, si no ha sido ya empleado en algn caso real. Se debe incluir por
lo menos dos ejemplos conocidos de diferentes mbitos.
- Patrones relacionados. Puede que haya problemas parecidos, que tengan ms de una solucin. De ah
que muchos patrones estn relacionados entre s: como el caso del Proxy y del Adapter. Se trata de
explicar cules son las similitudes y (no menos importante) las diferencias, entre patrones
relacionados.

109

Gamma et al. (1995), clasifican los patrones de diseo en tres categoras: patrones creacionales, estructurales
y de conducta:

- Patrones Creacionales (Creational Patterns). Abstraen el proceso de instanciacin. En general, tratan
de ocultar las clases y mtodos concretos de creacin, de tal forma que al variar su implementacin, no
se vea afectado el resto del sistema. Es comn encontrar "competencia" entre estos patrones: hay ms
de un patrn a adoptar ante una situacin: Abstract Factory, Builder, Factory Method, Prototype,
Singleton.
- Estructurales (Structural Patterns). Se ocupan de cmo se agrupan las clases y los objetos para formar
estructuras ms grandes. Aqu se puede nombrar al patrn Composite, que permite agrupar varios
objetos como si fueran uno solo, y tratar al objeto compuesto de una forma similar al simple: Adapter,
Bridge, Composite, Decorator, Facade, Flyweight, Proxy.
- De Conducta (Behavioral Patterns). Centrados en la comunicacin entre objetos y clases.
Frecuentemente, describen las colaboraciones entre distintos elementos, para conseguir un objetivo:
Chain of Responsability, Command, Interpreter, Iterator, Mediator, Memento, Observer, State,
Strategy, Template Method, Visitor.
- Por otro lado, Buschmann et al. (1996), clasifican los patrones de diseo como: descomposicin de
estructura, organizacin de trabajo, control de acceso, gerencia y comunicacin:
- Descomposicin de la estructura (Structure Decomposition). Descomposicin de los subsistemas y
componentes complejos en piezas interrelacionadas: Whole-Part.
- Organizacin de trabajo (Organization of Work). Los componentes colaboran para solucionar
problemas complejos: Master-Slave.
- Control de acceso (Access Control). Guarda y controla el acceso a los servicios y a los componentes:
Proxy.
- Gerencia (Management). Maneja la totalidad de las colecciones homogneas de objetos, servicios y
componentes: Command Processor, View Handler.
- Comunicacin (Communication). Organiza la comunicacin entre componentes: Forward-Receive,
Client-Dispatcher-Server, Publisher-Subscriber.

En la Tabla A1.3 que se muestra a continuacin, se resumen algunos patrones (de arquitectura, diseo e
idiom) propuestos por Buschmann et al. (1996) y su relacin con los patrones de Gamma et al. (1995). En
negrillas, se muestra la clasificacin de Gamma et al. (1995).

Patrn arquitectural Patrn de diseo Idioms
Del fango a la
estructura
Layers
Pipes and Filters
Blackboard
Interpreter
Sistemas
distribuidos
Broker
Pipes-and-Filters
Microkernel

Sistemas
interactivos
MVC
PAC

Sistemas
adaptativos
Microkernel
Reflection

Creacin Abstract Factory
Prototype
Builder
Singleton
Factory Method
Descomposicin
estructural
Whole-Part
Composite

Organizacin de
trabajo
Master-Slave
Chain-of-Responsibility
Command
Mediator

Control de acceso Proxy
Facade
Iterator

Variacin de
servicio
Bridge
Strategy
State
Template Method

Extensin de
servicio
Decorator
Visitor

Gerencia CommandProcessor
ViewHandler
Memento

Adaptacin Adapter
Comunicacin Publisher-Subscriber
Forward-Reciever
Client-Dispatcher-
Server
Observer

Manejo de recursos Flyweight Counted Pointer
Tabla A1.3 Resumen de patrones

110

La Tabla A1.4, muestra algunos patrones de diseo acompaados de sus autores y su propsito. A manera de
conclusin se tiene que existe una estrecha relacin entre los estilos arquitectnicos y los patrones
arquitecturales y de diseo.

N Patrn de diseo Autores Propsito
1

Abstract Factory

Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Proporcionar interfaces para crear objetos de
alguna familia, sin especificar una clase en
particular.
2 Adapter Class Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Convertir interfaces de una clase, en otra, que es
la esperada por algn cliente.
3 Bridge Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Desacoplar una abstraccin de su
implementacin en concreto. Luego, podemos
cambiar la implementacin, o la abstraccin, sin
cambiar la otra.
4 Builder Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Separa la construccin de un objeto complejo,
de su representacin. De esa manera, el mismo
proceso de construccin puede crear diferentes
resultados.
5 Chain of Responsability Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Desacoplar el mensaje enviado de su receptor,
permitiendo que haya varios objetos que tengan
la oportunidad de manejar el requerimiento. Eso
se consigue pasando el requerimiento por la
cadena de objetos hasta llegar al encargado de
atenderlo.
6 Client-Dispatcher-
Server
Frank Buschmann, Regine Meunier, Hans
Rohnert, Peter Sommerlad, and Michael
Stal
Un despachador acta como capa intermedia
entre los clientes y el servidor.
7 Command Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Encapsular el requerimiento a un objeto,
permitiendo incluso el "undo" de la operacin
8 Command-Processor Frank Buschmann, Regine Meunier, Hans
Rohnert, Peter Sommerlad, and Michael
Stal
Extiende el patrn command de Gamma, y
aade un procesador del comando explcito
9 Composite Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Componer objetos en una estructura de rbol,
donde los objetos compuestos se tratan de forma
similar a los objetos simples.
10 Decorador Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Agregar responsabilidad a un objeto
dinmicamente, dndonos una alternativa a la
extensin de una clase, en lugar de usar
subclases.
11 Facade Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Proveer una interface unificada a un conjunto de
funciones de un subsistema. Es una interface de
alto nivel, para facilitar el uso del subsistema.
12 Factory Method Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Definir interfaces para crear objetos, como en el
Abstract Factory, pero se delega a las subclases
implementar la creacin en concreto.
13 Flyweight Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Compartir objetos eficientemente, sin repetirlos
en el sistema.
14 Forward-Receiver Frank Buschmann, Regine Meunier, Hans
Rohnert, Peter Sommerlad, and Michael
Stal
Contiene toda la funcionalidad de comunicacin
especificada en el sistema, separada en pares de
componentes que pueden comunicarse sin
afectar la portabilidad.
15 Interpreter Erich Gamma, Richard Helm,
Ralph Johnson, and John
Vlissides
Construir una representacin de la gramtica de
un lenguaje, junto con su intrprete.
16 Iterator Erich Gamma, Richard Helm,
Ralph Johnson, and John
Vlissides
Acceder a los elementos de un objeto coleccin
o similar, sin exponer su estructura interna

111
17 Master-Slave Frank Buschmann, Regine Meunier, Hans
Rohnert, Peter Sommerlad, and Michael
Stal
El master divide una tarea entre los slave
idnticos (pero independientes), la combinacin
de los resultados parciales de cada slave, resulta
ser la solucin
18 Mediator Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Permitir la interaccin de varios objetos, sin
generar acoples fuertes en esas relaciones.
19 Memento Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Permite capturar el estado de un objeto sin entrar
en su estructura interna, para, por ejemplo,
restaurarlo ms adelante.
20 Observer Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Definir una relacin uno a muchos, entre un
objetos y otros que estn interesados en sus
cambios, sin realizar el acople entre los mismos.
21 Prototype Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Conseguir otras instancias del objeto, mediante
una instancia prototpica.
22 Proxy Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Proveer un subrogado a otro objeto, para
controlar el acceso al mismo.
23 Publisher-Subscriber Frank Buschmann, Regine Meunier, Hans
Rohnert, Peter Sommerlad, and Michael
Stal
Es similar al patrn Observer de Gamma.
24 Singleton Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Consigue dar un solo objeto de la clase, en
cualquier momento de la aplicacin
25 State Erich Gamma, Richard Helm, Ralph
Johnson, and John
Vlissides
Permite a un objeto cambiar su conducta cuando
cambia su estado interno, simulando que cambia
de clase.
26 Strategy Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Definir una familia de algoritmos, y los hace
intercambiables.
27 Template-Method Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Definir la estructura de una operacin, cuyas
operaciones ms bsicas, quedan delegadas en
subclases.
28 View-Handler Frank Buschmann, Regine Meunier, Hans
Rohnert, Peter Sommerlad, and Michael
Stal
Separar el manejo de opiniones de los cdigos
requeridos para presentar o para controlar vistas
especficas. Es similar a los patrones Abstract
Factor y Mediator de Gamma et al
29 Visitor Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides
Recorrer una estructura (un rbol, por ejemplo),
aplicando una operacin
30 Whole-Part Frank Buschmann, Regine Meunier, Hans
Rohnert, Peter Sommerlad, and Michael
Stal
Definir un componente que encapsule objetos
pequeos. Evita que los clientes tengan acceso
directo al contenedor de objetos, pero
proporciona una interfaz para la agregacin.
Tabla A1.4 Algunos patrones de diseo
La Tabla A1.5 muestra que los patrones de diseo pueden aplicarse al nivel de marco de trabajo, dentro de las
clases de diseo al nivel de arquitectura y tambin dentro del diseo detallado [Bra2003].

Arquitectura (Garlan y Shaw)
Categora Sub-categora Patrones de diseo ms aplicados
Flujo de datos Secuencial por lote Puede aplicarse decorador
Componentes
independientes
Pipes and filter
Procesos de comunicacin
paralela
Sistema Cliente-Servidor
Sistema de eventos
Observer
Facade
State
Observer

112
Mquinas virtuales Intrpretes
Sistemas basados en reglas
Interpreter
Arquitecturas de
almacenamiento
Bases de datos
Sistemas de hipertextos
Pizarrones
Observer, iterator
Decorator
Blackboard
Arquitecturas por
capas
Muchos patrones de diseo consisten en capas
abstractas y no abstractas.
Tabla A1.5 Arquitecturas alternativas (Braude, 2003)

A continuacin un listado de los patrones de Diseo:

1. Abstract Factory
2. Adapter - Class
3. Adapter - Object
4. Blackboard
5. Bridge
6. Broker
7. Builder
8. Chain Of Responsibility
9. Client-Dispatcher-Server
10. Command
11. Command Processor
12. Composite
13. Decorator
14. Facade
15. Factory Method
16. Flyweight
17. Forwarder-Receiver
18. Interpreter
19. Iterator
20. Layers
21. Master-Slave
22. Mediator
23. Memento
24. Microkernel
25. Model-View-Controller
26. Observer
27. Pipes and Filtres

28. Presentation-Abstraction-Control
29. Prototype
30. Proxy
31. Publisher-Subscriber
32. Reflection
33. Singleton
34. State
35. Strategy
36. Template Method
37. View Handler
38. Visitor
39. Whole-Part
40. Administracin de Cach
41. Caja de Objetos (Object Pool)
42. Delegacin (Delegation)
43. Ejecucin de un nico Thread
44. El patrn Controlador
45. El patrn Creador
46. El patrn Experto
47. Enlace Dinmico (Dynamic Linkage)
48. Fotografa (Snapshot)
49. Inicializacin de capas (Layered Initialization)
50. Inmutable (Immutable)
51. Interfaz (Interface)
52. Marker Interface
53. Pequeo Lenguaje (Little Language)
54. Proxy Virtual (Virtual Proxy)
55. Trmino en dos fases (Two-Phase Termination)

A1.4 Patrn de Interaccin
Un patrn de diseo de interfaces, o de interaccin, modela un aspecto referente a la interfaz de una
aplicacin. Estos patrones sirven para describir un problema, su contexto y la solucin; para generalizar una
solucin; para facilitar la comunicacin entre disciplinas; para registrar el conocimiento y la experiencia y
facilitar las metodologas de diseo de interfaces.

Los patrones de interaccin deben ser legibles y entendibles por todos los integrantes del equipo de desarrollo
de un proyecto, incluyendo a los expertos en el dominio de la aplicacin y los usuarios del sistema. Para
lograr alcanzar esas caractersticas, estos patrones deben estar expresados haciendo uso de una notacin clara,
sencilla y bien definida; adicionalmente, los patrones deben estar organizados de tal forma que se facilite su
utilizacin. Entonces, la estructura de los patrones debe facilitar la comunicacin. A fin de cumplir su
objetivo, existe aceptacin en que un patrn tenga, como mnimo, cinco componentes principales: (Acosta et
al., 2001).

- Nombre de patrn, el cual debe ser mnemotcnico con respecto al problema de diseo que resuelve.
Un nombre de patrn nuevo incrementa el vocabulario de diseo. Este vocabulario permite disear a

113
un alto nivel de abstraccin y facilita la comunicacin entre colegas y dentro de la documentacin del
diseo.
- Problema, describe una situacin en la cual se debe aplicar el patrn; ste explica el problema en s y
su contexto. Algunas veces, el problema puede incluir condiciones que deben ser satisfechas antes de
que tenga sentido aplicar el patrn.
- Solucin, describe los elementos que conforman el diseo. Provee una descripcin abstracta de un
ordenamiento general de los elementos que resuelven un problema particular en un contexto dado.
- Contexto, condicin(es) en la(s) cual(es) se puede usar el patrn.
- Fuerzas, complementan la definicin del problema, debido a que son aspectos del contexto de diseo
que deben ser optimizados; en general, estos aspectos son contradictorios y es necesario establecer un
equilibrio entre estos.

Uno de los resultados del workshop ChiliPLoP99 fue el establecimiento de una taxonoma, propuesta
inicialmente por Borchers, que agrupa a los patrones con base en tres dimensiones: nivel de abstraccin,
funcionalidad y dimensin fsica. Dentro de cada dimensin, se clasifican los patrones de la siguiente manera:

- Segn el nivel de abstraccin, se puede tener patrones de muy alto nivel que describen una tarea
completa que realiza el usuario; luego, en un segundo nivel de abstraccin se tienen patrones ms
concretos que describen el estilo de cierta parte de la interaccin, y, por ltimo, patrones que describen
objetos de la interfaz de usuarios.
- En lo que respecta a la funcionalidad de los patrones, estos se agrupan en las siguientes categoras:
aquellos orientados a describir la percepcin (auditiva, visual, etc.) de los usuarios; los patrones que
expresan la manipulacin de los datos de entrada o salida y aquellos dirigidos a mostrar la navegacin
a travs de la aplicacin.
- Por ltimo, se tiene la dimensin fsica de la interfaz, esto es, en primer lugar se encuentran los
patrones orientados a la distribucin de los elementos en el espacio o plano fsico, posteriormente, los
patrones que representan secuencias o series discretas de eventos, de dilogos, etc., y aquellos
patrones que muestran continuidad en el tiempo, tales como el diseo de buenas tcnicas de animacin
en la interfaz de usuarios.

Mahemoff y Johnston (1998) proponen un enfoque de diseo de Interaccin Humano Computador, basado en
patrones orientados a la usabilidad. Estos autores definen cuatro clases de patrones IHC, a saber: Patrones del
Sistema, Patrones de Tareas, Patrones de Elementos de la Interfaz, Patrones de Usuarios. Los patrones del
sistema capturan aspectos concernientes al desarrollo del mismo, por ejemplo los atributos de usabilidad que
se deben garantizar, el propsito del sistema, etc. Los patrones de tareas describen las funcionalidades de la
aplicacin y cmo se deben llevar a cabo. Los patrones de elementos de interfaz describen elementos tales
como los conocidos widgets o composiciones de stos. Los patrones de usuarios describen los perfiles de
los usuarios potenciales de la aplicacin.
A1.5 Patrn de Flujo de Trabajo
Los patrones de flujo de trabajo o workflow, se corresponden con un conjunto de actividades bsicas que
permiten el control de un proceso de negocio, y son escenarios de los patrones de anlisis descritos en el
Anexo 1.1 (por lo que no se mencionan en la taxonoma), estos patrones de workflow son: aprobacin
simple, aprobacin simple con escalacin automtica, aprobacin simple con renovacin automtica, flujo de
trabajo secuencial, flujo de trabajo secuencial con escalacin automtica, flujo de trabajo paralelo, flujo de
trabajo paralelo con revisin final, asignacin manual y notificacin.

Todos estos patrones de flujo de trabajo, permiten separar la lgica de negocio y la de presentacin,
garantizando la meta configuracin de las aplicaciones asociadas a los procesos de negocio, a continuacin se
presentan cada uno de estos patrones de flujo de trabajo.
Tabla A1.6 Patrn Asignacin
Nombre Asignacin


114
Clasificacin Workflow
Autor MSc. Pedro Bonillo
Confiabilidad 100 %
Problema Debe ser ejecutada una tarea por un usuario o grupo de acuerdo a ciertas reglas de
asignacin y manejando una lista de tareas (Work List).
Solucin a. Asignacin de valores a los atributos de la tarea desde procesos
externos.
b. Asignacin de atributos relacionados a acuerdos de servicio mediante la
invocacin de una Administrador de Acuerdos de Servicio (Administrador
Acuerdos Servicios)
c. Asignacin de atributos de sistema mediante la invocacin de un Servicio
Administrador de Sistema (Administrador sistema),
d. Invocacin de un servicio administrador de tareas (Servicio
Administracin Tarea), el cual utilizara los atributos de la tarea, para
determinar la agregacin de dicha tarea a la lista de trabajo de un usuario
o grupo de usuarios, adems de realizar otras actividades como verificar
la permisologa, estado de transicin, documentacin, acuerdos de
servicios, calcular tiempo, asignar auditoria, verificar modificaciones,
encuestas y soluciones sobre la tarea.
e. Posteriormente, los resultados o eventos son manejados por un Servicio
Administrador de Eventos de Tarea
(ServicioAdministracionEventosTarea) a fin de verificar la expiracin, la
renovacin y los errores asociados.

Contexto Cualquier proceso donde se requiera asignar una tarea a un usuario o grupo.
Fuerzas Todos los workflow que incluyen interaccin humano computador requieren administracin
de las tareas a ser asignadas a los usuarios, adems de manejar una lista de tareas
Usabilidad Permite administrar la asignacin de tareas de acuerdo a ciertos atributos asignados a las
mismas.
Consecuencias Asignacin de tareas a usuarios o grupos de usuarios tomando en cuenta las
caractersticas de la tarea para la asignacin y manejando una lista de trabajos(work list)
Ejemplo Un empleado, a travs de un portal de empleados suministra una solicitud de vacaciones.
El portal inicia un proceso de negocios que incluye una tarea de usuario modelada usando
un simple workflow, la tarea es asignada al supervisor del empleado. Cuando el supervisor
aprueba o rechaza la solicitud de vacaciones, el empleado es notificado con la decisin del
supervisor por e-mail.
Patrones
Relacionados
f. Administrador de Acuerdos de Servicios
g. Administrador de Sistema
h. Administrador de Tarea
i. Administrador de Eventos sobre la Tarea
Tabla A1.7 Patrn Asignacin con Escalacin
Nombre Asignacin con Escalacin

Clasificacin Workflow
Autor MSc. Pedro Bonillo
Confiabilidad 100 %
Problema Debe escalarse una tarea asignada de un usuario a otro, tomando en cuenta
acuerdos de servicios preestablecidos (Service Level Agreement)
Solucin Utilizacin del Patrn de Asignacin y adicionalmente invocacin de una operacin
denominada verificarEscalacion, que determina de acuerdo a las condiciones del
SLA, si la tarea asignada debe ser escalada, cuando debe ser escalada una tarea a
otro usuario, quien es el usuario a ser notificado de la escalacin y escala la tarea de
ser necesario.
Contexto Cualquier proceso donde se requiera escalar una tarea en caso de no ser cumplidas
las polticas de SLA.
Fuerzas Es necesario manejar escalacin de tareas en caso de no ser cumplidos acuerdos de
SLA como por ejemplo la expiracin de la tarea ya que esto evita retrasos en el
proceso y asignacin de las tareas a usuarios o grupos que si puedan manejar dichos
acuerdos

115
Usabilidad Todos los procesos donde sea necesario escalar tareas en base a un conjunto de
acuerdos de SLA.
Consecuencias Asignacin de tareas a usuarios o grupos de usuarios tomando en cuenta las
caractersticas de la tarea para la asignacin y manejando una lista de trabajos(work
list), adems de manejar informacin sobre acuerdos de servicios para realizar
escalacin de tareas a otros usuarios o grupos
Ejemplo El proceso de HelpDesk da a usuarios la capacidad de archivar tickets de peticin del
servicio. Si la persona que recibe el boleto no acta dentro de un perodo
especificado, el boleto se escala automticamente a su encargado. El boleto se
escala automticamente tres veces si nadie ha actuado en l dentro de un tiempo
predefinido, hasta que consigue al gerente de la compaa. Si el gerente tampoco
acta, el ticket expira.
Patrones
Relacionados
- Asignacin
- AdministradorEventosTarea

Tabla A1.8 Patrn Asignacin con Renovacin

Nombre Asignacin con Renovacin

Clasificacin Workflow
Autor MSc. Pedro Bonillo
Confiabilidad 100 %
Problema Se debe renovar la asignacin de una tarea a un usuario una cantidad definida de
veces, cada ves que esta expire. Este tiempo de expiracin viene especificado en los
acuerdos de SLA(Service Level Agreement)
Solucin Utilizacin del patrn de asignacin y adicionalmente invocacin de una operacin
denominada verificarRenovacion, que adems de realizar las mismas funciones de
la operacin verificarEscalacion (determinar segn los acuerdos de SLA si una tarea
debe ser escalada, cuando, a quien y escalar la tarea de ser necesario) tambin esta
en la capacidad de renovar la tarea asignarla al mismo usuario o grupo una
cantidad definida de veces.
Contexto Cualquier proceso donde se requiera renovar la asignacin de tareas a un usuario o
grupo conforme a los acuerdos de SLA.
Fuerzas Puede darse el caso en que se flexibilicen los acuerdos de servicios, para dar
oportunidad a un usuario o grupo de usuarios de completar una tarea
Usabilidad Todos los procesos donde sea necesario escalar tareas en base a un conjunto de
acuerdos de SLA.
Consecuencias Asignacin de tareas a usuarios o grupos de usuarios permitiendo la renovacin de la
misma al mismo usuario, un nmero definido de veces antes de ser escalada.
Ejemplo El proceso de HelpDesk da a usuarios la capacidad de archivar tickets de peticin del
servicio. Si la persona que recibe el boleto no acta dentro de un perodo
especificado, el boleto se escala automticamente a su encargado. El boleto se
escala automticamente tres veces si nadie ha actuado en l dentro de un tiempo
predefinido, hasta que consigue a la ltima persona con capacidad de atender la
peticin de servicio, si esta persona tampoco acta, el ticket expira. En este caso
puede ser renovada la asignacin a la misma persona cierta cantidad de veces, con
el fin de no truncar la posibilidad de prestar el servicio.
Patrones
Relacionados
- Asignacin
- Administrador de Eventos de Tarea
Tabla A1.9 Patrn Asignacin Automtica Secuencial

Nombre Asignacin Automtica Secuencial

Clasificacin Workflow
Autor MSc. Pedro Bonillo
Confiabilidad 100 %
Problema Una tarea debe ser realizada o procesada por un usuario o grupo de usuarios en forma

116
secuencial.
Solucin Creacin de una secuencia de usuarios que procesaran la tarea mediante un servicio
Administrador de Secuencia, La tarea ser asignada a cada usuario en la secuencia
utilizando el patrn de asignacin hasta llegar al ltimo usuario.
Contexto Un proceso que contiene una lista de usuarios asociados a una tarea a realizar. La tarea
tiene un conjunto de acuerdos de SLA asociados.
Fuerzas Es frecuente el caso en que existe un orden definido en el cual ms de un usuario o grupo
de usuario requieren procesar una misma tarea.
Usabilidad Cualquier proceso donde se haga necesario el procesamiento de una tarea por varios o
grupo de usuarios en forma secuencial.
Consecuencias El procesamiento de una tarea por mltiples usuarios en forma secuencial
Ejemplo En un sistema aprobador de rdenes de compras, un usuario perteneciente a un grupo
supervisor evala inicialmente la orden de compra. Despus que el usuario inicial aprueba
la orden, el gerente del departamento debe aprobarla tambin.
Patrones
Relacionados
- Asignacin
- Administrador de Secuencia

Tabla A1.10 Patrn Asignacin Automtica Secuencial con Escalacin

Nombre Asignacin Automtica Secuencial con Escalacin

Clasificacin Workflow
Autor MSc. Pedro Bonillo
Confiabilidad 100 %
Problema Una tarea debe ser realizada o procesada por un usuario o grupo de usuarios en forma
secuencial, si alguno de los usuarios no cumple los acuerdos de SLA, la tarea es escalada
a otro usuario.
Solucin Creacin de una secuencia de usuarios que procesaran la tarea mediante un servicio
AdministradorDeSecuencia, La tarea ser asignada a cada usuario en la secuencia
utilizando el patrn de asignacinConEscalacion hasta llegar al ltimo usuario. En este
caso, la tarea puede ser escalada en caso de no ser cumplidos los acuerdos de SLA por
alguno de los usuarios en la lista.
Contexto Un proceso que contiene una lista de usuarios asociados a una tarea a realizar y los cuales
deben cumplir con un conjunto de acuerdos de SLA.
Fuerzas Es frecuente el caso en que existe un orden definido en el cual mas de un usuario o grupo
de usuario requieren procesar una misma tarea, a esto se la agrega la necesidad de
escalar la dicha tarea si uno mas de dichos usuarios no cumplen con los acuerdos de SLA.
Usabilidad Cualquier proceso donde se haga necesario el procesamiento de una tatarea por varios o
grupo de usuarios en forma secuencial y los cuales deban cumplir con acuerdos de SLA.
Consecuencias El procesamiento de una tarea por mltiples usuarios en forma secuencial y escalacin de
dichas tareas en caso de no haber sido ejecutadas segn los acuerdos de SLA.
Ejemplo Un empleado solicita una nueva computadora porttil urgentemente. El workflow
secuencial primero encamina la tarea a su jefe para la aprobacin y despus a una
persona en el departamento encargado de adquirir la computadora porttil. Si el SLA
indica que la tarea debe escalarse despus de dos das, entonces la peticin primero va al
jefe para la aprobacin y si no se aprueba en dos das, la tarea se puede encaminar
automticamente a la persona siguiente en la jerarqua de gerencia. Un escalamiento
similar se puede tambin hacer para el departamento encargado de adquirir la
computadora porttil. Esto permite al workflow terminar sin largos retrasos en el proceso
de aprobacin.
Patrones
Relacionados
- Asignacin con Escalacin
- Administrador de Secuencia

Tabla A1.11 Patrn Asignacin Manual

Nombre Asignacin Manual


117
Clasificacin Workflow
Autor MSc. Pedro Bonillo
Confiabilidad 100 %
Problema Se presenta cuando a un usuario o un grupo de usuarios no han aprobado la
tarea, y no se ha remitido la tarea al usuario original que creo la tarea, para su
aprobacin final.
Solucin Se puede solucionar, cambiando los atributos inciales y validando con el
administrador de acuerdos de servicios, para determinar cuales son los grupos de
usuarios que van a recibir la tarea para su revisin y validacin, una vez creado el
grupo al cual se le va a enrutar la tarea se invoca al administrador de Tarea, que
en este caso va hacer el encargado de enrutar la tarea cuando cada usuario haya
revisado la tarea y la envi a su revisor original.
Contexto Cualquier proceso donde se requiera tener ms de una revisin no automtica,
para su aprobacin final.
Fuerzas Cuando se requiere que exista una aprobacin sin un criterio especfico de
asignacin automtica este patrn permite la asignacin manual.
Usabilidad Permite enrutar tareas a un usuario o grupo de usuarios de forma manual, para su
posterior aprobacin
Consecuencias La tarea es asignada a una persona o grupo que fue seleccionada por un criterio
manual
Ejemplo Un representante de una Compaa HR, escribe un nuevo documento, y lo tiene
repasado por su encargo. El encargado puede decidir que otra persona debe
tambin repasarlo antes de que se acepte. Esta persona puede alternadamente
remitir la tarea a otras antes de aprobarla. Por lo tanto la tarea se puede enrutar a
mltiples usuarios, antes de volverse al revisor original, que entonces la aprueba
basado en comentarios de otros.
Patrones
Relacionados
Proceso Externo, Asignacin

Tabla A1.12 Patrn Asignacin Paralela

Nombre Asignacin Paralela

Clasificacin Workflow
Autor MSc. Pedro Bonillo
Confiabilidad 100 %
Problema El problema que resuelve este patrn, es que se lleva un control de la tarea desde su
inicio hasta su estado de completitud, ya que el dueo de la tarea le puede hacer un
seguimiento al proceso permitiendo la aprobacin en paralelo de varios usuarios a
travs de sub tareas
Solucin Cuando se completan las subtareas el administrador de eventos tarea, prepara un
mensaje de completitud de subtarea, que se le es enviado al administrador de tarea
para indicarle al dueo de proceso que ya la tarea padre puede ser retirada, esto
ocurre cuando se ha logrado el 75% de completitud de subtarea.
Contexto Se utiliza Asignacin Paralela cuando una tarea se debe aprobar por mltiples
usuarios o simultneamente por grupos de usuarios, cuando se crea una tarea cada
usuario tiene una copia de la tarea, los usuarios podrn agregar informacin, agregar
comentarios independiente de otros usuarios, como premisa los usuarios que
repasan las tareas en paralelo no pueden ver las tareas de los otros usuarios
(incluyendo comentarios, resultados, etc.). El dueo de la tarea puede ver todas las
subtareas en ejecucin. Cuando el creador de la tarea retira a la tarea Padre, todas
las subtareas se retiran.
Fuerzas El administrador de Tareas, se puede saturar a la hora de atender cada peticin de
subtarea, ya que una tarea se puede dividir en muchas partes. En ese momento el
administrador de eventos de tarea prepara un mensaje de completitud de subtarea,
que es enviado al administrador de tarea, para si retirar la tarea padre y finalizar el
proceso.
Usabilidad La usabilidad de este patrn viene dada, con la rapidez con que se desea agilizar una

118
tarea principal, para que sea divida en subtareas, para que varios usuarios puedan
resolver un problema de manera rpida.
Consecuencias
Ejemplo Un ejemplo concreto es el de emplear a un nuevo aspirante para optar a un cargo
dentro de una organizacin. Cada entrevistador da su voto para emplear o no al
candidato, si en el resultado de la votacin el candidato obtiene un promedio de 75%,
obviamente ser aceptado, caso contrario ser rechazado, se hace regencia en este
ejemplo porque cada entrevistador puede votar independientemente de los otros
entrevistadores.
Patrones
Relacionados
Proceso Externo, Administrador Sub Tarea, Administrador Tarea, Asignacin

Tabla A1.13 Patrn Asignacin Paralela con Escalacin

Nombre Asignacin Paralela con Escalacin

Clasificacin Workflow
Autor MSc. Pedro Bonillo
Confiabilidad 100 %
Problema El problema que resuelve este patrn, es que se lleva un control de la tarea desde su
inicio hasta su estado de completitud, ya que el dueo de la tarea le puede hacer un
seguimiento al proceso. Permite tambin realizar escalaciones cuando no se ha
completado una tarea o subtarea
Solucin Cuando se completan las subtareas el administrador de eventos tarea, prepara un
mensaje de completitud de subtarea, que se le es enviado al administrador de tarea
para indicarle al dueo de proceso que ya la tarea padre puede ser retirada, esto
ocurre cuando se ha logrado el 75% de completitud de subtarea.
Contexto Se utiliza Asignacin Paralela con Escalacin cuando una tarea se debe aprobar por
mltiples usuarios o simultneamente por grupos de usuarios, Si la Tarea no se ha
completado se realiza la escalacin automtica. Cuando se crea una tarea cada
usuario tiene una copia de la tarea, los usuarios podrn agregar informacin, agregar
comentarios independientes de otros usuarios, como premisa los usuarios que
repasan las tareas en paralelo no pueden ver las tareas de los otros usuarios
(incluyendo comentarios, resultados, etc.). El dueo de la tarea puede ver todas las
subtareas en ejecucin. Cuando el creador de la tarea retira a la tarea Padre, todas
las subtareas se retiran.
Fuerzas El administrador de Tareas, se puede saturar a la hora de atender cada peticin de
subtarea, ya que una tarea se puede dividir en muchas partes. En ese momento el
administrador de eventos de tarea prepara un mensaje de completitud de subtarea,
que es enviado al administrador de tarea, para si retirar la tarea padre y finalizar el
proceso.
Usabilidad La usabilidad de este patrn viene dada, con la rapidez con que se desea agilizar una
tarea principal, para que sea divida en subtareas, para que varios usuarios puedan
resolver un problema de manera rpida. Permite adems llevar un control de
notificaciones a los supervisores por medio de escalaciones, cuando la tarea ha
expirado o no ha sido completada.
Consecuencias
Ejemplo Una Persona Duea de un proceso, crea una tarea, y la imparte a los usuarios o
grupos de usuarios para que revisen y le agreguen informacin adicional a las
subtareas de manera que sean procesadas en forma independiente de cada usuario,
que esta procesando la subtarea, cada usuario aprobara la subtarea en porcentajes
de completacin. Si las subtareas no son completadas en un lapso de tiempo la
subtarea escala un nivel hacia los supervisores de los usuarios que son responsables
de procesar las subtareas.
Patrones
Relacionados
Asignacin Paralela, Asignacin con Escalacin, Administrador Sub Tareas,
Administrador Tarea, Proceso Externo


119
Tabla A1.14 Patrn Asignacin Paralela con Revisin Final

Nombre Asignacin Paralela con Revisin Final

Clasificacin Workflow
Autor MSc. Pedro Bonillo
Confiabilidad 100 %
Problema El problema que resuelve este patrn, es que se lleva un control de la tarea desde su
inicio hasta su estado de completitud, ya que el dueo de la tarea le puede hacer un
seguimiento al proceso y a su vez es apoyado por un usuario que revisa la tarea para
su aprobacin final, es decir la tarea pasa por una doble validacin.
Solucin Cuando se completan las subtareas el administrador de eventos de tarea, prepara un
mensaje de completitud de subtarea, que se le es enviado al administrador de tarea
para indicarle al revisor final que ya la tarea padre puede ser retirada, esto ocurre
cuando se ha logrado el 75% de completitud de subtarea.
Contexto Asignacin Paralela con un Revisin Final es una extensin del patrn Asignacin
Paralela, en el cual despus de la revisin de la tarea en paralelo por parte de los
usuarios, la tarea se asigna a un revisor final. El revisor final puede ser un usuario o
un grupo. Cuando hay ms de un revisor final o si la tarea se asigna a un grupo, uno
de los usuarios tiene que adquirir la tarea antes de repasarla, el revisor final puede
ver todas las subtareas.
Fuerzas El administrador de Tareas, se puede saturar a la hora de atender cada peticin de
subtarea, as como tambin si se selecciona a un grupo para que actu como revisor
final, se puede perder tiempo en escoger al usuario que va a tomar la tarea para el
cambio de estatus de las subtareas para que sea retirada por el dueo del proceso.
Usabilidad La usabilidad de este patrn viene dada, con la rapidez con que se desea agilizar la
tarea principal, la cual se les enva a los mltiples usuarios en paralelo y en seguida
se le enva a un revisor final para que el dueo del proceso pueda tomar una
decisin.
Consecuencias
Ejemplo En un proceso de revisin de documentos, el creador del documento inicia el proceso
especificando el documento y a los revisores del documento. Cada revisor puede
repasar el documento simultneamente e independientemente de los otros revisores,
despus de que todos los revisores hayan hecho el repaso del documento, el creador
del documento consigue repasar los comentarios de los revisores.
Patrones
Relacionados
Asignacin Paralela, Asignacin, Proceso Externo, Administrador Tarea,
Administrador Sub Tarea.

Tabla A1.15 Patrn Asignacin Paralela Revisin Final con Escalacin

Nombre Asignacin Paralela Revisin Final con Escalacin

Clasificacin Workflow
Autor MSc. Pedro Bonillo
Confiabilidad 100 %
Problema El problema que resuelve este patrn, es que se lleva un control de la tarea desde su
inicio hasta su estado de completitud, ya que el dueo de la tarea le puede hacer un
seguimiento al proceso y a su vez es apoyado por un usuario que revisa la tarea para
su aprobacin final, es decir la tarea pasa por una doble validacin. Si la tarea no es
completada se escala a otra instancia, para la toma de decisiones.
Solucin Cuando se completan las subtareas el administrador de eventos de tarea, prepara un
mensaje de completitud de subtarea, que se le es enviado al administrador de tarea
para indicarle al revisor final que ya la tarea padre puede ser retirada, esto ocurre
cuando se ha logrado el 75% de completitud de subtarea.
Contexto Asignacin Paralela con un Revisin Final es una extensin del patrn Asignacin
Paralela, en el cual despus de la revisin de la tarea en paralelo por parte de los
usuarios, la tarea se asigna a un revisor final. El revisor final puede ser un usuario o
un grupo. Cuando hay ms de un revisor final o si la tarea se asigna a un grupo, uno

120
de los usuarios tiene que adquirir la tarea antes de repasarla, el revisor final puede
ver todas las subtareas.
Fuerzas El administrador de Tareas, se puede saturar a la hora de atender cada peticin de
subtarea, as como tambin si se selecciona a un grupo para que actu como revisor
final, se puede perder tiempo en escoger al usuario que va a tomar la tarea para el
cambio de estatus de las subtareas para que sea retirada por el dueo del proceso.
Usabilidad La usabilidad de este patrn viene dada, con la rapidez con que se desea agilizar la
tarea principal, la cual se les enva a los mltiples usuarios en paralelo y en seguida
se le enva a un revisor final para que el dueo del proceso pueda tomar una
decisin.
Consecuencias
Ejemplo En un proceso de revisin de documentos, el creador del documento inicia el proceso
especificando el documento y a los revisores del documento. Cada revisor puede
repasar el documento simultneamente e independientemente de los otros revisores,
despus de que todos los revisores hayan hecho el repaso del documento, el creador
del documento consigue repasar los comentarios de los revisores, en caso contrario
si el creador de la tarea no logra cerrar el proceso, se realiza una notificacin de que
una tarea no ha sido completada.
Patrones
Relacionados
Asignacin Paralela, Asignacin Paralela con Escalacin, Asignacin con Escalacin
Asignacin Paralela con Revisin Final, Administrador Sub Tarea, Administrador
Tarea, Proceso Externo.

Tabla A1.16 Patrn Administrador de Sub Tarea

Nombre Administrador de Sub Tarea

Clasificacin Workflow
Autor MSc. Pedro Bonillo
Confiabilidad 100 %
Problema Se requiere que varias personas a travs de subtareas como copia de la tarea
principal realicen una aprobacin en paralelo
Solucin Creacin de subtareas copia de la tarea de la tarea original permitiendo a travs del
administrador de subtareas la aprobacin en paralelo
Contexto Recibe las solicitudes de Asignacin Paralela, Asignacin Paralela con Escalacin,
Asignacin Paralela con Revisin Final, Asignacin Paralela Revisin Final con
Escalacin, a travs del servicio de administracin de sub tarea, procesa las sub
tareas y enva respuesta.
Fuerzas Ayuda al administrador de tarea en el procesamiento de las subtareas de manera
paralela cuando se ha colocado una tarea principal y necesita ser gestionada por
mltiples usuarios.
Usabilidad Se utiliza como una funcionalidad que apoya el procesamiento y gestin de las
subtareas.
Consecuencias Cuando se crea la tarea principal la Asignacin Paralela en cualquiera de sus
modalidades, realiza una invocacin al Administrador de Subtarea, el cual es el
encargado de recibir procesar (crear, modificar, consultar, eliminar) las subtareas.
Permitiendo llevar un control de la gestin de la subtarea, permite monitorear el
porcentaje de completitud de subtarea, realiza validaciones de grupos y usuarios a
los cuales se les distribuye las subtareas para su revisin, trabaja en paralelo con el
administrador de tareas.
Ejemplo El Administrador es una funcionalidad que permite procesar las tareas en subtareas,
en donde todo comienza cuando una tarea se esta procesando en paralelo, esta
tarea se ejecuta de manera independiente de cada usuario, cada uno de los usuarios
desconoce la informacin que le agregan al momento de la completacin de la tarea,
el administrador de tarea recibe los atributos necesarios para poder distribuir la tarea
al usuario o al grupo de usuarios para su gestin.
Patrones
Relacionados
Asignacin Paralela, Asignacin, Administrador Tarea


121
Tabla A1.17 Patrn Asignacin sin Notificacin

Nombre Asignacin sin Notificacin

Clasificacin Workflow
Autor MSc. Pedro Bonillo
Confiabilidad 100 %
Problema Cuando se crea una tarea, no se espera una respuesta del usuario, ya que no
interviene un administrador de acuerdos de servicios
Solucin Para tener una respuesta satisfactoria, se utiliza el administrador de acuerdos de
servicio, el cual permite notificar al supervisor, cuando un usuario ha recibido una
tarea, cuando fue aprobada y ejecutada por el usuario final.
Contexto El FYI es una Tarea que no se bloquea y se enumera como tareas asignadas a un
usuario, esta tarea se aloja en el worklist para su aprobacin, El proceso que crea
la tarea no espera una respuesta del usuario.
Fuerzas Si el administrador de acuerdo de servicio no puede determinar la ubicacin del
usuario o grupos de usuario, no se podr realizar la notificacin de que la tarea ha
sido entregada, ni aprobada, esto generara un error, el cual es lanzado por el
administrador de tareas.
Usabilidad Viene dada, para llevar un control del flujo de la tarea, hasta el momento de su
aprobacin por el usuario.
Consecuencias
Ejemplo Un ejemplo prctico es cuando se utiliza un proceso de sistema de rdenes de
compra. Cuando el sistema procesa aprobaciones sobre cierta cantidad como por
ejemplo: $100, un supervisor tiene que ser notificado, pero sin parar el proceso,
esta informacin es vital para el supervisor ya que le permite monitorear el
sistema.
Patrones
Relacionados
Asignacin Simple


122
Anexo 2 Formato de Solicitud de Requerimiento

En este anexo se presenta el formato a travs del cual se solicita un requerimiento de creacin o mejora de un
proceso de negocio.


Nmero de Solicitud

Fecha:
Nombre Solicitante:
Telfonos Solicitante:
E-Mail del Solicitante:
Gerencia:
Unidad:

Objetivos: (Indique cada uno de los objetivos que deben ser cubiertos)







Descripcin del Problema: (Situacin Actual, Diagramas de Procesos, etc.)





Alcance: (Indique cul ser el alcance del desarrollo, qu aspectos deben contemplarse y cules no)



Beneficios: (Indique los beneficios que traer el desarrollo e implementacin del proyecto en base a procesos,
uso de recursos, etc.)


123





Elementos de Entrada: (Indique cules son los datos o elementos de entrada que deber recibir el sistema. Ej.
Datos, archivos logs, etc.)






Elementos de Salida: (Indique cules son los datos o elementos que debe mostrar el sistema como resultado
de su procesamiento. Ej. Automatizacin de configuracin, reportes, etc.)




reas Involucradas (Indique las reas y/o personas que estarn relacionadas con el desarrollo solicitado)

rea Alias rea Supervisor Persona Contacto Telfono Persona Contacto.







Usuarios: (Indique quines sern los usuarios finales, nombres, telfonos, e-mail, ubicacin administrativa y
ubicacin fsica. En caso de ser un grupo colocar los datos del grupo del supervisor)

Nombre/
Grupo
Telfonos E-mail (personal y del alias de
la unidad a la que pertenece)
Ubicacin
Administrativa
Ubicacin Fsica





Anexos. (Anexe a este formato toda aquella informacin que considere sea necesaria, as como informacin
que pueda ayudar al desarrollo de este proyecto)
Solo Para ser Llenado por la Unidad de Recepcin de la Solicitud:

Responsable:
Factibilidad:
Fecha Reunin Inicial:


124
Anexo 3 Cartelera de Actividades Propuestas

A continuacin se presentan las actividades que conforman la metodologa y una duracin en das promedio
para un proceso medianamente complejo (entre 20 y 60 pasos):

Tiempo para la creacin de un proceso
Nombre de Tarea Duracin (das)
Process Mangement (Gerencia de Procesos sustentada en Patrones) 186
1. Crear Procesos 130
1.1 Analizar 28
1.1.1 Identificar Requerimientos 8
1.1.1.1 Describir Requerimiento 5
1.1.1.2 Definir Prioridad 1
1.1.1.3 Evaluar Cartelera de Actividades 2
1.1.2 Levantar Informacin 20
1.1.2.1 Mapear al Marco Referencial del Proceso 5
1.1.2.2 Levantar Situacin Actual 15
1.2 Disear 24
1.2.1 Estandarizar Proceso 2
1.2.2 Evaluar Riesgos 2
1.2.3 Realizar Modelo Propuesto 15
1.2.4 Efectuar el Setup del Laboratorio 5
1.3 Modelar 8
1.3.1 Diagramar 5
1.3.2 Simular Prueba Funcional 1
1.3.3 Integrar Arquitectura 1
1.3.4 Simular Prueba Integral 1
1.4 Configurar 50
1.4.1 Completar UML 5
1.4.2 Construir Lgica de Negocios 10
1.4.3 Construir Interfaz 10
1.4.4 Construir Reportes 10
1.4.5 Configurar el BPEL 10
1.4.6 Realizar Pruebas Unitarias 5
2. Administrar Procesos 56
2.1 Mantener Configuraciones 16
2.1.1 Mantenimiento de Aplicaciones 6
2.1.1.1 Analizar y validar el tipo de requerimiento 2
2.1.1.2 Disear 3
2.1.1.3 Aplicar Pruebas 1
2.1.2 Mantener Variables del Proceso 5
2.1.3 Mantener Plataforma 5
2.2 Monitorear 40
2.2.1 Monitorear Funciones 20
2.2.2 Monitorear Plataforma 20



125

Anexo 4 Escenario Proceso de Gestin de Versiones ITIL
en base al Patrn de Anlisis de Produccin

A travs de este anexo se expresa el Proceso de Gestin de Versiones de ITIL como un escenario del Patrn
de Anlisis de Produccin.

Tabla A4.1: Escenario Gestin de Versiones, del Patrn de Anlisis Produccin
TITULO Gestin de Versiones
OBJETIVO La Gestin de Versiones es la encargada de la implementacin y control de calidad de todo el
software y hardware instalado en el entorno de produccin.

La Gestin de Versiones debe colaborar estrechamente con la Gestin de Cambios y de
Configuraciones para asegurar que toda la informacin relativa a las nuevas versiones se
integra adecuadamente en la CMDB de forma que sta se halle correctamente actualizada y
ofrezca una imagen real de la configuracin de la infraestructura TI.

La Gestin de Versiones tambin debe mantener actualizada la Biblioteca de Software
Definitivo (DSL), donde se guardan copias de todo el software en produccin, y el Depsito de
Hardware Definitivo (DHS), donde se almacenan piezas de repuesto y documentacin para la
rpida reparacin de problemas de hardware en el entorno de produccin.

Las interacciones y funcionalidades de la Gestin de Versiones se resumen a travs de la
siguiente figura:


CONTEXTO Gerencia de TI
ACTORES Usuario, Consultor Service Desk, Supervisor Service Desk, Soporte de Campo, Supervisor
Soporte de Campo, Gestor de Cambio, Comit de Cambio.
RECURSOS CMDB, Infraestructura de TI: Hardware y Software
EPISODIOS 1.

126
2.

3.
4.
5.
6.
7.

8.



EXCEPCIONES Conflictos en el uso de la CMDB, DSL y DHL, Conflicto en el uso de los RFC
Conflictos entre los horarios de RollOut, Desarrollo y Produccin, Conflictos entre los horarios
del CAB, Conflictos con el uso de la Infraestructura de TI.

127

Anexo 5 Artculos Arbitrados Publicados

En este anexo se presentan las dos publicaciones en revistas internacionales, todas
relacionadas con su tema de tesis, a saber:

[1] Bonillo P. Evaluation System Model for Remote Control Software. Rev. Tc. Ing. Univ.
Zulia, Aug. 2004, Vol. 27, No.2, p.123-134. ISSN 0254-0770. (Aceptado el 15 de Marzo de
2004).

[2] Bonillo P., Zambrano N., Acosta E. Methodological Proposal for Business Process
Management sustained in the use of Patterns.Journal of Object Technology, Vol. 7, No. 6,
2008, ISSN 1660-1769. (Aceptado el 14 de Noviembre de 2007)

La publicacin [1] propone un modelo sistmico de evaluacin de herramientas de
software, fundamentado en el estudio de la Tecnologa de la Informacin y la
Comunicacin (TIC) y la representacin de la Gerencia de las TIC como un sistema, con su
respectivo sub-sistema de control. La publicacin [2] propone una metodologa para la
gerencia de los procesos de negocio sustentada en el uso de patrones, estudia los procesos
de desarrollo de software UP, XP y FDD, la construccin de software basada en
componentes, relacionando los conceptos de patrones, componentes, aplicaciones,
procesos, metodologa y calidad, estableciendo una taxonoma de patrones de software y
proponiendo la representacin de estos conceptos a travs de un ADL, que incluye la
utilizacin de ABAS para la medicin de la calidad y la formulacin de un meta-patrn.

La revista Tcnica de Ingeniera de la Universidad del Zulia esta indexada en el Ulrich's
International Periodicals Directory e Engineering Information Inc. La revista Journal of
Information Systems and Technology Management esta indexada en Latindex. La revista
Journal of Object Technology es publicada por el Chair of Software Engineering de ETH
Swiss Federal Institute of Technology.




128


129
MODELO SISTMICO DE EVALUACIN DE SOFTWARE
DE CONTROL REMOTO
Pedro N. Bonillo
Centro ISYS, Facultad de Ciencias, UCV, Apdo. 48097
Apdo. 48097, Los Chaguaramos 1041-A, Caracas, Venezuela
pbonillo@kuaimare.ciens.ucv.ve
RESUMEN

El objetivo de este artculo es presentar y describir un Modelo Sistmico para la Evaluacin de Herramientas de Software.
Al hablar de evaluacin de software, lo ms sencillo y fcilmente manejable que viene a la cabeza es una lista de cotejo en
la que se verifica la existencia o ausencia de determinadas caractersticas o procesos involucrados en su uso. Es tambin
fcilmente justificable que no se puede hablar de una evaluacin aislada del contexto y los procesos por los que transita el
software antes de llegar a las manos del usuario, o bien, divorciada de los objetivos que tiene quien conduce la evaluacin.
En este proceso de evaluacin, se evidencian la existencia de entidades, atributos, y relaciones que afectan en gran medida
a la organizacin, y que sugieren la utilizacin del enfoque sistmico, a travs del cual la evaluacin pueda ser modelada
como un sistema abierto. Esta investigacin busca establecer las relaciones y condiciones necesarias entre el pensamiento
sistmico y la perspectiva de evaluacin, dentro de un modelo diferenciador que permita obtener una buena estimacin y
un conjunto de criterios para evaluar exitosamente el uso del software en el marco de los intereses del negocio, tomando
como caso de estudio la herramienta de software de control remoto en la organizacin de soporte interno de la empresa
venezolana CANTV.
PALABRAS CLAVES
Modelo Sistmico de Evaluacin, Gerencia TI.
1. INTRODUCCIN
La tecnologa de la informacin (TI) est continuamente en rpida evolucin, al mismo tiempo que lo est
el ambiente de los negocios, lo cual coloca presin sobre las Organizaciones que estn seguras de que pueden
soportar los cambios fundamentales que en ellas ocurren. La tecnologa de la informacin soporta las
Organizaciones sobre el tiempo y el espacio, sin embargo las Organizaciones no tienen an la cantidad de
soluciones suficientes y coherentes para desarrollar la dimensin de la estructura organizacional, la
estrategia, los recursos humanos, la tecnologa y los procesos del negocio. Los cambios producidos en las
Ciencias de la Computacin han sido para encontrar una manera de atacar este problema mediante acciones
continuas y rpidas a travs del desarrollo de nuevas interrelaciones entre la tecnologa de la informacin y la
de la comunicacin, alinendolas tanto con las necesidades sociales del grupo de usuarios cooperativos, como
con la administracin de los requerimientos de las Organizaciones formales. Paul Strassmann, conocido
consultor norteamericano que ha estudiado con profundidad el impacto de las tecnologas de la informacin
en las organizaciones, seala que no hay una relacin directa entre la inversin de las empresas en TI y el
retorno que consiguen de esa inversin [1].
En general, los criterios que se utilizan para evaluar software en las organizaciones, son ms bien
cualitativos, sin presentar una estandarizacin que permita a los especialistas valorar aspectos y evidenciar
criterios mnimos de confiabilidad [2]. Cabe sealar que, aunque este es un problema ampliamente
reconocido, existen escasas instancias de evaluacin de software que permitan determinar su influencia
positiva sobre la Organizacin. [3].
En muchas reas de aplicaciones de software, a menudo, es ms econmico adquirirlo que realizar su
desarrollo. Los Gerentes de sistemas se enfrentan a una decisin, de hacer-o-comprar, que se puede complicar
con varias opciones de adquisicin: (1) Se pueden adquirir programas (o una licencia de uso); (2) Se pueden

130
comprar programas y modificarlos luego para que se ajuste a las necesidades especficas y (3) Se puede
encargar a una tercera parte la construccin de un programa que se ajuste a las especificaciones del
comprador.
En los pases subdesarrollados, se requiere de esfuerzos tecnolgicos orientados a obtener un equilibrio
adecuado entre la adquisicin de la tecnologa del exterior, el desarrollo y utilizacin de la capacidad
tecnolgica de la propia empresa y la seleccin, adaptacin y generacin de la tecnologa que demanda para
producir; ya que, en estos pases, las empresas no poseen capacidad ni tradicin suficientes en el desarrollo de
tecnologas, siendo la principal opcin el recurrir a la transferencia de tecnologa, provenientes stas de pases
desarrollados. [4].
Asimismo, la Gerencia de Tecnologa de la Informacin se enfrenta al reto de prestar soporte a un nmero
mayor de usuarios, con computadoras personales cada vez ms complejas y con una movilidad en aumento,
sin acrecentar los costos o incluso reducindolos. Esto representa un reto enorme [5]. Como apoyo a la
Gerencia de Tecnologa de la Informacin, en este enorme reto, las Organizaciones normalmente cuentan con
una Mesa de Ayuda o Helpdesk. Esta Mesa de Ayuda constituye la primera lnea de defensa en la mayora de
las organizaciones de soporte y tiene a su cargo la deteccin y resolucin de problemas a travs del telfono
con el fin de reducir la necesidad de que un tcnico se desplace hasta el usuario o que el usuario tenga que
llevar su computadora a un centro de soporte. En estas dos alternativas, la productividad se ve afectada y los
costos del soporte aumentan drsticamente. Segn una encuesta realizada por la compaa Forrester Research,
el 60 por ciento de los encuestados reportaron que sus tcnicos tuvieron que visitar los sistemas de los
usuarios para resolver problemas (el 43 por ciento varias veces al da y el 17 por ciento varias veces a la
semana) [5].
Dentro de las nuevas tecnologas que apoyan al personal del centro de soporte a sopesar este tipo de
inconveniente tenemos las herramientas de atencin remota de fallas (Remote Control), las cuales permiten a
los tcnicos tomar el control de la Computadora Personal (PC) del usuario a travs de la red y trabajar con ella
como si fuera una computadora local. De esta forma, los problemas se resuelven rpida y sencillamente, sin
necesidad de que el tcnico abandone el centro de soporte, disminuyendo el tiempo de atencin, y enseando
al cliente mediante el enfoque de aprender haciendo [6]. El Grupo Gartner estima que, en un periodo de 3
aos, las herramientas de control remoto pueden reducir los costos anuales de los centros de soporte entre un
6% y un 13%. Se estima que los costos anuales de los centros de soporte se encuentran en un rango de los 158
a los 1.447 dlares por PC. Esto significa un ahorro anual de 21 a 77 dlares por PC, o de 153.800 a 576.900
dlares en un entorno con 2.500 computadoras personales [5].Sin embargo, estas herramientas de ayuda
normalmente son implementadas en la Organizacin sin una medicin previa de su impacto sobre la
operacin. Las Organizaciones en general fallan en los procesos de evaluacin de software, por no contar con
mecanismos para medir el desempeo de los mismos. Es as como se ha pensado estudiar modelos que
permitan subsanar esta debilidad. Un elemento crtico para el xito y la supervivencia de las organizaciones,
es la administracin efectiva de la informacin y de la Tecnologa de Informacin relacionada. Las empresas
en Venezuela toman decisiones referentes a la tecnologa que utilizan, pero sin tener mucha conciencia de
ello; se utilizan enfoques que tienden a subestimar o ignorar aspectos importantes de la seleccin y uso de la
tecnologa que compran. Esto, obviamente repercute de manera sensible sobre el rendimiento econmico de
las empresas y sus posibilidades de desarrollo futuro. Comnmente la tecnologa de informacin en las
organizaciones venezolanas se adquiere por moda, sin previo estudio, sin un anlisis o evaluacin y slo
despus de que se compra el producto y se exige una mtrica de la gestin del mismo, o una justificacin de
los costos asociados, es que se comienza a evaluar tanto el producto, como su efecto sobre los procesos del
negocio. La carencia de un enfoque de evaluacin de software en estas organizaciones ha generado problemas
en la productividad y la calidad, as como en la evaluacin, cada vez que una nueva tecnologa y metodologa
es aplicada a la organizacin. La pregunta normal, de las organizaciones, al enfrentarse al trmino de
evaluacin es: Por qu no tenemos mediciones adecuadas actualmente? Las respuestas: (1) Se requiere
tiempo y esfuerzo; (2) La evaluacin responde a la cultura existente en la organizacin: (2.1) histricamente
no se ha medido la calidad de las funciones de servicios y las administrativas; (2.2) histricamente las
mediciones se han usado para castigar, no para recompensar; (2.3) las expectativas y necesidades tendrn que
ser definidas ms claramente. Para mejorar debemos saber dnde nos encontramos, y para saber dnde nos
encontramos debemos evaluar, medir y estimar [8].
La pretensin de ofrecer un Modelo Sistmico de Evaluacin de Herramientas de Software de Control
Remoto, como reza el ttulo de este articulo, pasa entonces por la definicin de los tres elementos esenciales:
evaluacin: (para qu evaluamos) qu se pretende hacer con los resultados de la evaluacin y quin est

131
interesado en hacerlo; comparacin: qu base de comparacin se utiliza para juzgar el valor, es decir, cules
son los criterios valorativos que servirn de patrn para contrastar con ellos la situacin conocida;
conceptualizacin: qu es necesario conocer de las herramientas a evaluar, lo cual supone claridad conceptual
sobre las dimensiones que encierra la situacin a la que se le da nombre, y desglosar esas dimensiones en
aspectos concretos, que sirven para definir un conjunto de indicadores que se puedan observar, describir o
medir. La garanta para la validez de ese conocimiento sobre lo que se pretende evaluar incluye definir cmo
se obtiene, es decir, qu modelos, metodologas, mtodos y tcnicas se utilizarn, con una fundamentacin
terica que garantice esa validez.
Todos estos elementos de comparacin dentro de un modelo sistmico y orientado a la evaluacin de
herramientas de control remoto permitirn desglosar esas dimensiones en aspectos concretos, que sirvan para
definir un conjunto de indicadores que se puedan observar, describir o medir. Esta investigacin busca
establecer las relaciones y condiciones necesarias entre el pensamiento sistmico y la perspectiva de
evaluacin, dentro de un modelo diferenciador que permita obtener una buena estimacin y un conjunto de
criterios para evaluar exitosamente el uso del software en el marco de los intereses del negocio, utilizando
como caso de estudio las herramientas de software de control remoto. En la prxima seccin se estudia en
detalle la metodologa aplicada para llevar a cabo esta investigacin y el desarrollo y aplicacin del modelo.
2. CUERPO DEL ARTICULO
2.1 Metodologa
La metodologa propuesta para la elaboracin de esta investigacin, es una instanciacin
de la metodologa Systemic Evaluation for Stakeholder Learning (SESL) propuesta por
Magnus Ramage en 1997, para los sistemas de trabajo cooperativo (Cooperative Work):
La combinacin de la tecnologa, personas y la organizacin que facilita la
comunicacin y coordinacin necesaria para que un grupo trabaje efectivamente con la
finalidad de alcanzar un objetivo comn [9]. Teniendo en cuenta que los escritorios de
ayuda (helpdesk) y las herramientas de control remoto de fallas junto con la
Organizacin constituyen un sistema de trabajo cooperativo, y tomando como referencia
la metodologa SESL, se propone una instanciacin de esta metodologa a travs de los
siguientes pasos: (1) Determinar la naturaleza del sistema para conformar el marco
terico referencial; (2) Determinar el tipo de evaluacin; (3) Identificar individuos que
afectan al sistema; (4) Estudiar y analizar las preguntas claves; (5) Disear el Modelo
Sistmico de Evaluacin de Herramientas de Software de Control Remoto; (6) Aplicar el
modelo y (7) Retroalimentacin de los resultados. Como se muestra en la Figura N 1.

132

Figura N1 Instanciacin de la Metodologa SESL Para MOSEHSARF.
Fuente: Adaptado de [9]
2.2 Resultados
El modelo sistmico de evaluacin MOSEHSARF puede describirse en trminos de la
Teora General de Sistemas (TGS) como un conjunto de ENTIDADES caracterizadas
por poseer ciertos ATRIBUTOS, los cuales mantienen RELACIONES entre s y estn
localizados en un determinado AMBIENTE de acuerdo a un cierto OBJETIVO [10]. La
representacin del sistema de estudio utilizando la teora general de sistemas, presenta
una utilidad prctica, ligada a la sencillez, proponiendo un enfoque top-down en su
descripcin. (Ver Figura N 2).

Figura N2 Organizacin de Soporte Interno en trminos de Sistemas.
La metodologa SESL, sugiere la existencia de cuatro tipos de evaluacin, el modelo
sistmico propuesto, asume slo dos de estos cinco tipos de evaluacin en forma
integrada: evaluacin de los efectos del sistema y para la compra de nuevos productos.

133
De acuerdo al estudio del sistema a evaluar (primer paso de la metodologa) los
individuos afectados (stakeholders) pueden ser definidos a travs de las entidades. Se
estudian adems los intereses de cada uno de ellos. De acuerdo a los intereses
establecidos para los stakeholders, a continuacin es necesario establecer las preguntas
claves y aplicar algn instrumento para obtener los resultados (sugerido: cuestionarios).
La arquitectura del modelo propuesto (Ver Figura N 3), contempla seis etapas: (1)
Complejidad: cuantificacin de la complejidad de la organizacin de soporte interno;
(2) Costo de Soporte: costos de la organizacin de soporte interno sin herramientas de
control remoto de fallas; (3) Impacto Control Remoto: impacto de las herramientas de
control remoto de fallas sobre los costos de la organizacin de soporte interno.
Disminucin en tiempos de atencin y nmero de llamadas; (4) Costo Control Remoto:
cuantificacin del costo total (planificacin, procura, implementacin, operacin,
adquisicin y reemplazo) de la herramienta de control remoto; (5) Efecto Econmico:
cuantificacin final del beneficio econmico; (6) Retroalimentacin: comunicacin de
los resultados de la evaluacin, el proceso de decisin asociado y de aprendizaje
organizacional (ya sea para la evaluacin de los efectos o de la compra).



134
Figura N3 Arquitectura MOSEHSARF
Inicialmente en el modelo se realiza el clculo de la complejidad segn la Tabla N 1.
TABLA N1 Factores que determinan la Complejidad de la Gerencia de TI. Adaptado [11]
% Factor Factor Medicin

0.225
(1)


Complejidad de la
Estructura
Altamente
Centralizada
0.20
Centralizada

0.40
Dispersa

0.60
Descentralizada

0.80
Altamente
Descentralizada
1



0.375 (1)



Madurez de los
Procesos
Tiene, usa,
documenta,
administra y
optimiza los
procesos de TI
0.20
Tiene, usa,
documenta,
administra los
procesos de TI

0.40
Tiene, usa,
documenta los
proceso de TI


0.60
Tiene y usa los
procesos de TI



0.80
Tiene proceso de TI



1

0.051 (1)
Dispersin de los
Usuarios
Altamente
Centralizados
0.20
Centralizados

0.40
Dispersos

0.60
Descentralizados

0.80
Altamente
Descentralizados
1


0.0495 (1)
Disponibilidad de
los Servicios de TI
5x8
dasxhora
0.20
6x9
dasxhora
0.40
7x12
dasxhora
0.60
7x15
dasxhora
0.80
7x24
dasxhora
1

0.0495 (1)
Niveles de
Acuerdo de
Servicio
Prximo da o
mejor esfuerzo
0.20
Prximo da
garantizado
0.40
Mismo da
garantizado
0.60
4 horas

0.80
Inmediato o menor a
30 minutos
1

0.067
(2)

% de Aplicaciones
que son Cliente /
servidor
20 o menos
0.20
40
0.40
60
0.60
80
0.80
100
1


0.0335 (2)
Numero de
Plataformas de
Sistemas
Operativos
Diferentes
1


0.20
2


0.40
4


0.60
6


0.80
Mayor a 6


1


0.02512 (2)
Tiempo promedio
de reemplazo de
Aplicaciones
Cliente / servidor
3 meses


0.20
6 meses


0.40
12 meses


0.60
24 meses


0.80
Mayor a 30 meses


1

0.02512 (2)
% Aplicaciones
Criticas
20 o menos
0.20
40
0.40
60
0.60
80
0.80
100
1

0.01675
(2)

% Aplicaciones de
Productividad
Personal
100

0.20
80

0.40
60

0.60
40

0.80
Menor a 20

1

0.04125
(3)

# de Arquitecturas
Distintas de
Hardware
1
0.20
2
0.40
4
0.60
6
0.80
Mayor a 6
1

0.02475
(3)

Porcentaje Anual
de Reposicin de
PC
10% o menos

0.20
20%

0.40
50%

0.60
70%

0.80
100%

1


0.00825
(3)

Redundancia
(% de Servidores,
ubs, router con
redundancia)
100%


0.20
70%


0.40
50%


0.60
20%


0.80
10% o menos


1

0.00825
(3)

% de Dispositivos
Mviles o
Porttiles
10% o menos
0.20
20%
0.40
50%
0.60
70%
0.80
100%
1

Donde el primer factor
(1)
representa el 75% asociado a la complejidad de la gerencia de
TI como tal, el segundo
(2)
y el tercer factor
(3)
correspondientes al impacto del 67%
software y el 33% hardware que respectivamente unidos conforman el 25% asociado al
impacto de la infraestructura de TI.
A partir del clculo del porcentaje de Complejidad se puede utilizar una escala

135
(0-9) con la finalidad de establecer un nivel de complejidad de la gerencia de TI en la
organizacin.
( ) d Complejida ejidad NivelCompl % 8 1 + =
(ec. 1)
El estudio predictivo toma los cambios en los factores de complejidad y los aplica a
todos los clculos de costos a fin de predecir los nuevos valores.
Una vez establecido el porcentaje y el nivel de complejidad de la Gerencia de TI, se
procede a realizar el clculo del costo de soporte, para lo cual es necesario calcular el
nmero total de llamadas en el periodo de evaluacin, de acuerdo a la siguiente
ecuacin:
[ ] ( ) ( ) [ ] t llampromAc ActApli ActSOP u llampromus meses PC llamadas + + =
(ec.2)
Donde, el smbolo PC representa el nmero de computadoras personales, meses el
nmero de meses del periodo de evaluacin, llampromusu las llamadas mensuales
promedio por usuario, ActSOP la cantidad de actualizaciones de sistema operativo,
ActApli las actualizaciones de aplicaciones y llampromAct el nmero promedio de
llamadas por actualizacin.
Gartner Group sugiere que en un periodo de dos a tres aos, el nmero de llamadas
promedio de un usuario por mes en el peor caso es de 3.5 llamadas y en el mejor caso es
de 1. Adems, que el nmero de actualizaciones de sistema operativo es de 1 en el peor
caso y 0 en el mejor caso, y que el nmero de actualizaciones de aplicaciones es de 6 en
el peor caso y 5 en el mejor caso. El usuario efecta en promedio por actualizaciones de
sistema operativo y aplicaciones 2 llamadas extras en el peor caso y 1 en el mejor caso.
Tomando en cuenta estas sugerencias del Gartner Group, se puede estimar un clculo

136
para el nmero total de llamadas en el periodo para un mejor y peor caso en forma
predictiva a travs de las siguientes ecuaciones:
( ) 5 ) ( + = meses PC mejorcaso llamadas
(ec. 3)
( ) [ ] 14 5 . 3 ) ( + = meses PC peorcaso llamadas

(ec. 4)
Gartner Group, nuevamente sugiere una distribucin para los tipos de llamadas y sus
tiempos de atencin en el primero y segundo nivel en un mejor y peor caso. A
continuacin se tiene que:
toop aten tiempoprom llamadas Operacin Costo cos _ =
(ec. 5)
tohelpdesk t llamadas d llamada HelpDesk Costo
i i i
cos _ _
1 1
=
(ec. 6)
Donde 0 < i < 9 representa el tipo de llamada, i=1 requerimiento de servicio, i=2 mantenimiento, i=3
mudanza, i=4 instalacin, i=5 consulta, i=6 reparacin, i=7 cambio de clave, i=8 interrupcin. La variable
llamadas representa el nmero total de llamadas en el periodo de evaluacin, tiempopromaten es el tiempo
promedio de atencin, costop es el costo de operacin en dlares por hora y costohelpdesk es el costo en
dlares por hora del helpdesk.
Finalmente el costo original de soporte (COS) se determina a partir de:
( )
= =

=
n
j
m
i
j ji ji j
osto t d d llamadas COS
1 1
1
c
(ec. 7)
Donde j representa los diferentes niveles de soporte de la organizacin. Por ejemplo j=1 Helpdesk, j=2
Servicio de Campo, j=3 Proveedor Nacional, j=4 Proveedor Regional, j=5 Proveedor Internacional.
Los d
ji
son el porcentaje de llamadas tipo i del nivel de soporte j-1 que pasan al nivel de soporte j. Con d
0i
=1

t
ji
representa el tiempo promedio de resolucin para el tipo de llamada i por el nivel de soporte j.
costoj es el costo en horas asociado al nivel de soporte j.
Es importante aclarar que las llamadas atendidas en el nivel j son un porcentaje de las atendidas en el
nivel j-1 es por esto que existe la multiplicacin de los factores d
(j-1)i
x d
j
Una vez establecido el costo original de soporte es necesario calcular el mismo costo pero aplicando
el impacto de implementar las herramientas de control remoto, para esto se pueden tomar mediciones en el
caso de que el software haya sido implementado antes del estudio o se pueden utilizar las siguientes
mediciones sugeridas por el Gartner Group.
De tal forma que el Costo de soporte con RC o Costo Reducido de Soporte (CRS), se expresa de la
siguiente manera:
( )
( ) ( ) [ ]

= =

=
n
j
m
i
ji ji j ji ji j
dt d c t d d llamadas CRS
1 1
1 1
1 1

(ec. 8)
Donde j representa los diferentes niveles de soporte de la organizacin. Por ejemplo j=1 Helpdesk, j=2
Servicio de Campo, j=3 Proveedor Nacional, j=4 Proveedor Regional, j=5 Proveedor Internacional.
Los dji son el porcentaje de llamadas tipo i del nivel de soporte j-1 que pasan al nivel de soporte j. Con d
0i
=1

d
lji
es el porcentaje de disminucin por uso de la herramienta en el nmero de llamadas del tipo i del total de
llamadas asociadas al nivel de soporte j. Con i y j como en los casos anteriores. Con d
0i
=1

dt
ji
es el porcentaje de disminucin por uso de la herramienta en el tiempo promedio atencin del tipo de
llamada i del total de llamadas asociadas al nivel de soporte j. Con i y j como en los casos anteriores. Con
d
0i
=1

t
ji
representa el tiempo promedio de resolucin para el tipo de llamada i por el nivel de soporte j.

c
j
es el costo en horas asociado al nivel de soporte j.


137
Una vez calculado el costo de soporte con la reduccin introducida por la herramienta, a
continuacin es necesario calcular el costo de la herramienta H, tomando en cuenta las caractersticas
discutidas referentes a los costos asociados al ciclo de vida del producto, el cual puede calcularse de acuerdo a
la siguiente ecuacin:
[ ] { } Re Im + + + + + + + = Sop Mant Licen Op Hop ple Himple Neg Hneg Plan Hplan PC H

(ec. 9)
Donde H representa el costo de la Herramienta, PC es el numero de computadoras personales, Hplan
corresponde a las horas de planeacin, Plan al costo de planeacin, Hneg las horas de negociacin o procura,
Neg el costo de negociacin, Himple las horas de implementacin, Imple el costo de implementacin, Hop las
horas de operacin, Op el costo de operacin, Licen el costo de licenciamiento, Mant el costo de
mantenimiento, Sop el costo de soporte y Re el costo de reemplazo.
Finalmente generalizando la ecuacin 9 a partir de la ecuacin 8 para diferentes niveles de soporte y tipos
de llamadas, se obtiene la ecuacin 10 Costo Real (CR):
H CRS CR + =

(ec. 10)
A continuacin es necesario calcular el efecto econmico (EEC) que no es ms que tomar el costo
normal y restar el costo reducido y el costo de la herramienta tal como se muestra en la siguiente ecuacin:
CR COS ECC =
(ec. 11)
Esta ecuacin debe ser mayor que cero para obtener un efecto econmico positivo, lo que indica que
lo que pagaba antes la empresa por mantener la operacin debe ser mayor de lo que se pagar al reducir los
costos a consecuencia de implementar la herramienta, adems del costo en el que la organizacin incurre al
ejecutar el proyecto. Donde el Costo Original de Soporte - Costo Reducido de Soporte es el Ahorro que se
obtiene al implementar la herramienta sin incluir el costo del proyecto (H).
De la ecuaciones 11 y 12 con un ECC positivo se deriva la siguiente desigualdad:
CR H COS >
(ec. 12)
Esta ecuacin (ec. 12), indica que si se conoce la situacin actual y se aproxima con certeza el costo
del proyecto de implantacin de la herramienta, se obtiene una meta mnima del nuevo costo reducido. Si el
Costo Reducido es igual al Costo Anterior, la empresa se encuentra en la situacin inicial, es decir no mejoro
al implantar la herramienta. Si el Costo Reducido es cero, quiere decir que la herramienta elimina todas las
llamadas o llev todos los tiempos a cero y sto es una situacin utpica.
Resumiendo, el Efecto Econmico est en funcin de la reduccin en nmero de llamadas y
tiempo de atencin que se obtiene en los niveles de soporte como consecuencia de las herramientas de
control remoto de fallas, en comparacin con el costo total.
Finalmente el modelo establece la realizacin de una fase de retroalimentacin donde se
comuniquen los resultados. Luego de obtener los datos finales de la relacin de la evaluacin, stos son
analizados con el objetivo de obtener resultados que conduzcan a conclusiones relevantes en cuanto al
comportamiento del modelo de evaluacin y de las herramientas de control remoto en la organizacin de
soporte interno. Si se conducen ambos estudios, el estudio predictivo con las tablas de Gartner por que se
desea comprar la aplicacin y el estudio evaluativo ya que la aplicacin est en funcionamiento, se puede
realizar un tercer anlisis correspondiente a un estudio comparativo entre los dos resultados utilizando la
arquitectura del modelo.Para la aplicacin del modelo de evaluacin, se tom la empresa venezolana
CANTV, en la cual se contemplaron cada una de las seis etapas propuestas en la arquitectura del modelo. Con
la finalidad de validar el modelo en su totalidad, se realizaron dos estudios de evaluacin separados: un
estudio predictivo y un estudio evaluativo en base a los dos aos de utilizacin de la herramienta de software
Remote Control de IBM-Tivoli implementada en CANTV a partir del 1 de enero del 2000.
3. CONCLUSION
Comparando este modelo con los propuestos por Flagg 1990, Strovink 1998 y Garner Group 2000 y
algunos otros autores asociados a la calidad del producto de software (Booch 1994, Segovia 1996, Fenton
1997, Hopkins 1997, Rumbaugh 1998 y Patrick 2000) se evidencia que sus bondades fundamentales se
encuentran en la utilizacin de la teora general de sistemas en la representacin del sistema objeto y la
organizacin de soporte como un sistema abierto, as como el subsistema de control que lo sustenta,

138
permitiendo establecer una abstraccin del mismo que garantice su aplicacin no slo en el mbito de otras
organizaciones de soporte y otras herramientas de control remoto, sino en especial en la evaluacin de otro
tipo de software, igualmente se destaca en este estudio la relacin entre la complejidad de la gerencia de
tecnologa de la informacin y el retorno de inversin asociado a las inversiones de software en el marco de
los intereses del negocio.
El Modelo, permite obtener una visin clara de la organizacin de soporte interno y de su entorno en
cuanto a la capacidad, necesidad y voluntariedad para adoptar y usar una herramienta de control remoto, as
como su participacin en el logro de los objetivos, de manera que se reduzcan los riesgos asociados a su
implantacin y uso. El Modelo determina como influye la complejidad de la Organizacin en el componente
econmico, en la efectividad del soporte y en la efectividad del proyecto, teniendo en cuenta factores de
costos que normalmente no son utilizados al medir el impacto del software en la organizacin (costo de
negociacin, planeacin, implementacin, reemplazo, etc.). As como tambin, permite determinar
tendencias, detectar debilidades y factores de mejora asociados a la obtencin de un efecto econmico
positivo.
A travs de este estudio se puede determinar que la complejidad de la organizacin, el tiempo promedio de
atencin, el factor de disminucin y el costo del proyecto son los factores claves en la organizacin de soporte
interno. Los costos por hora en el modelo predictivo, dan una cota de hasta cuanto debe pagar la organizacin
para mantener el proyecto, es decir ellos influyen directamente en el ahorro y ste ltimo acota el presupuesto
asociado a la herramienta. Cuando se aumentan los costos por hora de los diferentes niveles de soporte se
disminuye el potencial de efecto econmico positivo. Adems los costos de atencin estn en funcin de la
disminucin en los tiempos de atencin y llamadas evitadas. El hecho de que los costos de soporte
disminuyan notablemente no implica que se obtendr un efecto econmico positivo, si se siguen manteniendo
igual los porcentajes de disminucin asociados al impacto de la herramienta.
En cuanto a las limitaciones se tiene que el modelo aplica. Sin embargo, existen otras variaciones de la
organizacin de soporte interno que pueden involucrar que los costos disminuyan y se calculen de una forma
diferente al modelo. Cabe destacar que los resultados finales obtenidos se ajustan al caso de estudio en
particular. Es decir, al cambiar las condiciones del caso, los resultados obtenidos en la aplicacin del Modelo
podran ser diferentes. Las limitaciones confrontadas en cuanto a la veracidad de las respuestas de los
cuestionarios, impiden asegurar con total certeza la representatividad de la muestra. Esta situacin restringe la
validez estadsticas de las generalizaciones a las poblaciones de las muestras. Pero los trabajos que brindan
informacin sobre el comportamiento de usuarios reales son necesarios y deseables para el progreso y el
desarrollo de sistemas de control an cuando el comportamiento sea observado en muestras pequeas no
controladas.
Se puede generalizar el modelo, como una forma de estudiar el impacto de una TI, determinando el costo
antes de la TI, el costo de reduccin, el resto de los costos asociados y verificando el efecto econmico tanto
en forma predictiva como en forma evaluativa, destacando la influencia de la complejidad de la gerencia de
TI en la determinacin predictiva de los costos.Otros estudios futuros podran orientarse en la evaluacin del
mtodo desde la perspectiva de la investigacin de operaciones con la finalidad de obtener valores exactos de
la forma como las variables pueden combinarse para garantizar la eficacia de la organizacin. Adems de
concluir / desarrollar estudios topolgicos.
REFERENCIAS
[3] Campos F., Campos G. & Rocher, A. Dez etapas o desenvolvimiento de software. 3er congreso
iberoamericano de informtica, Barranquilla Colombia (1996)
[8] Evans J. Administracin y control de la calidad. International Thomson Editorial. S.A. Mxico
5ta Edicin (2001)
[2] Flagg. B. Software Evaluation. Hillsdale, New Jersey. Lawrence Erlbaum Associates,
Publishers (1990).
[5] Garner Group Inc. Hiring for the 21st Century. The Public Workshops (2000)
[10] Johansen B. Introduccin a la teora general de sistemas. Editorial Limusa, Mexico DF. (1997)
[9] Manus R. Developing a Methodology for the Evaluation Cooperative Systems. (1997)
[4] Paredes L. Gestin Tecnolgica y reconversin industrial. Revista Espacios, Vol 12. Num. 3.

139
pp. 59-77. (1991)
[1] Strassmann, P. Getting better value from information management
Information Economics Journal, (2003).
[11] Strovink K., Paquet R., Keyworth B., Ardito Smith. Lowering Support Costs UIT LAN
Management Tools. Strategic Analysis Report Garner Group (1998)
[6] Symantec Latin America Headquarters. Enterprise remote control (2001)


















140
Methodological Proposal for Business
Process Management sustained in the
use of Patterns
Pedro Bonillo, Nancy Zambrano and Eleonora Acosta, Central University of
Venezuela, Caracas, Venezuela
Abstract
At the moment, enterprises require complex business models with an organizational
structures, processes and systems that must be explicitly designed. The work designed by
these business models is clearly interdisciplinary, since it requires business development
knowledge, different processes enterprises, management of these processes, and
technological applications. In the scope of the software engineering would be desirable to
obtain a system of methods, tools and techniques that allows the reuse of the best
practices during the process of software development according to each one of the
processes that are implemented in each domain. This work describes a theoretical
methodology proposal framework. The methodology includes from the analysis of the
requirements to the monitoring of the processes, supporting the analysis stages, design,
model and configuration, through the use of patterns. The methodological proposal is
conformed by two macro-processes: one related to the creation of the process itself and
other that corresponds to the administration, and it includes: the maintenance,
administration of the process in production and the monitoring through management
indicators.
1 INTRODUCTION
The main purpose of this work is to propose a methodology that allows the Management of
the Business Processes (BPM), based in the use of patterns [Alexander et. Al.77] [Gamma
et al.95] [Buschmann et. Al 96]. This Work propose a taxonomy of patterns and its
representation through an Architecture Definition Laguages (ADL) into an architecture of
processes, services, and canon objects in the BPM domain. In addition, it opens out the
pattern especifications[Acosta, Zambrano04], in order to be able to measure its quality
through Attribute-Based into Architectural Styles (ABAS) [Kazman. Klein04]. ISO14-598
and ISO-9126 are used as a quality models of procesess and as the product. Considering
this combination of methods, tools and techniques, it proposes a group of steps that in the
BPM scope, allows to identify the key processes, to model them and to analyze them, to
simulate them, to implant them in an assisted way (Such as new processes as their
versions); to evaluate them, monitore them and improve them.

Construction of Software Based on Components

In literature, exists several definitions for component In [D Souza, Wills99] it is
understood by component as a coherent package of code that: (i) can be developed and

141
distributed independently, (ii) has explicit and right specified interfaces to the service that it
offers, (iii) has explicit and right specified interfaces to the services that are reliable from
other components; and (iv) can be formed by other components, maybe opens out some of
its properties, but without modifying the component itself [DSouza, Wills99]. A more
general definition is given by Jacobson, Griss and Jonsson[Jacobson et.al97] who defined
it as an device that has been developed specifically to be reuse (this definition will be the
one which this article will adopt). In this case a component could be as much as a case of
use as any other reusable element that will rise during the development processes and it will
be used in any activity, whenever it does not require knowledge of the software that uses it.

In the Objects Oriented (OO) approach, the objects can be seen as components,
unless they satisfy additional guides directed to make auto-contents for them, the use of
another components by means of aggregation and generally they interact with other
components through the events.

The component used in the development process of software has three main targets: the
reusability, the adaptation and the extension (the reusability can imply the adaptation and
extension), understanding that:
- A component is reusable since its services can be used by another application.
- A component is adaptable if its supplier has anticipated the possible changes that can
suffer this component, and can make it compatible with other hardware and software
platforms.
- A component is extending whether its supplier gives the mechanism to modify or
extend the services that the component offers.

Last year, we studied among others, two ways of the processes for software
development: the agile and heavy methods. The fundamental difference between both of
them is that while heavy methods try to obtain the common objective by means of order
and documentation, the agile methods do it improving the direct and immediate
communication processes between the people who are within. The development processes
to consider in this proposal are: Unified Process (UP) as a method of heavy development,
XP (eXtreme Programming Project) and FDD (Feature Driven Development) in
representation of the agile methods.
If the project is sufficiently large to suggest the adaptation of components from
previous developments, it is possible to say that UP is appropriate for the process of
software development because it allows to obtain a better structure and discipline. A good
possibility of reducing the work is with the reusability of models and processes already
defined in a previous implementations of UP in different scopes. Referring to the
architecture, XP with the system metaphors tries to determine an optimal architecture in the
early stages of its development.Even though FDD is centered in the quality, it leaves all the
weight of the architectural decisions to the main architect, but it does not specify how these
decisions are related with the quality of the developing system.
On the other hand there is a generalized problem for the development processes UP,
XP and FDD: the selection of the suitable architecture or combination of different

142
architectural styles for a software system, is a problem that has not been solved yet and that
it has been treated widely in literature. In relation to this problem, the use of components in
these software development processes allows:
- In relation to obtain requirements: (i) the vertical analysis, focus in a domain or in a
specific area of business; which its objective is that the resulting components can later
become standards for any developed application in that domain and points out towards
its reusability; (ii) the horizontal analysis, made in a generic way to give service to an
ample rank of applications, without restricting itself to a domain of a given business;
and (iii) specific analysis, made in a concrete domain, to obtain components ad hoc
where the emphasis does not make so much in the reusability but in the extension.
- In relation to Design: during the gathering of requirements all the functions that had
been identified and must be supported, but the distribution of these functions can occur
immediately or can be constructed adapting the existing components. The following
aspect corresponds to the partition of components, which can be made through: the use
of cases, the patterns of design, the organizations of the domain, the anticipated
evolution of the system, and the already existing components.
- Regarding the interaction of components: it is said it is direct (simple interaction) when
the offered service adjusts to the forms and necessities of the required service. If the
forms are not the suitable ones, it is necessary to previously make a packing process
(wrapper).
The growth of the systems complexity, usually constructed through the integration
of components, increases the necessity to obtain more rigorous approaches than lead this
process of decision. UP, XP and FDD have absence of a clear relation between the
components (between these, the patterns), the architecture and the characteristics of the
quality associated to the architecture. UP on the other hand, doesnt have an association of
the nonfunctional requirements with the use of cases; a bad selection of the main use cases
affects the architecture of the system; the model used test to evaluate the architecture
doesnt have guides precise to determine this relation. In the next section, there will be a
presentation of a new form to relate these concepts, to solve this deficiency.

Establishing the relationship between Patterns, Components, Applications,
Processes, Methodology and Quality
In the Fowler book[Fowler97] there is an interesting generic definition: a pattern is an idea
that has been used in a practical context and probably it will be useful in others. The main
idea expresses that a pattern can be any thing. The expression in the practical context
reflects the fact that it is developed (some authors prefer: discover) due to the practical
experience of real projects. Considering this general definition of patterns, it is possible to
affirmed that such can be expressed through components and these, as well as functions
that are implemented in different applications (Figure 1).

143

Fig 1: Relation Patterns, Components, Applications, Processes, Methodology and Quality.
In figure 1, the notches represents a through expression, which means that the
patterns express themselves through components, the applications through components and
patterns, the processes through applications and patterns, all of these within the framework
of a methodology (a system that joins the concepts) and where each element must have
associated with quality.
The concept of patterns in software engineering [Gamma et al.95], was introduced
with the design patterns. At the moment, the software patterns constitute a more general
concept, representing applicable conceptual structures in the diverse phases of the
development process. In the following section, a new taxonomy of software patterns are set
out.
Taxonomy of Patterns
A pattern is a solution to a problem, accepted as correct, which has been received a name
and that can be applied in other contexts [Fowler97]. A pattern captures the experience and
knowledge of experts, who have produced successful solutions to problems, giving the
disposition of a soclution to those with less experience; nevertheless, the patterns do not
always provide the definitive solutions, sometimes, the users of patterns must have
creativity to use or implement a pattern [Acosta, Zambrano04].
In todays the Software engineering, the patterns can be applied at the level of:
analysis of requirements, architecture designs, detailed designs, the interaction with the
users and codes. With these the following classification or taxonomy can be set out,
according to the abstraction level:
- Patterns Analysis: They are groups of concepts that represent a common construction of
the conceptual model in the world. Can be relevant to a domain or adapted to many
domains. The main idea is the construction of scenes using patterns. It is essential to try
to have one more conceptual and structural vision of the situations, with the purpose of
identify the intrinsic nature of the same ones. With that vision, it is possible to
determine the type of scene corresponding to each situation and choose a pattern of a
catalogue, reusing his structure with the purpose of deriving the easiest and directly
scene. They consist in a text guide which for each scene component it includes
guidelines about the content that must have the same one. They are presented as
described scenes which a reduced number of conformation rules has been added as

144
scene meta-components. Each component of the scene, according to the structure
defined in [Leite00], has been completed with a nominal text that is expected to be
replaced in the real scene generated when the pattern is used, but it as well guides the
writing of the component [Ridao01]. For example, the analysis pattern to make a
productive activity is applied to the scene to design a meeting agenda such as a form to
reuse the characteristics of a productive activity to the specific domain of a meetings
agenda.
- Patterns Architecture: They are fundamental organization schemes in a software
system. They specify a series of subsystems and its respective responsibilities. It
includes the rules and criterias to organize the existing relations among them [Klein,
Kazman99]. Some examples are: layers, filters and connections; models, views and
controls (MVC). The architectonic styles are a generalization of the architecture
patterns because they express the components and the relations of the structural and
general skeleton of an independent application of the context and other styles; they are
the categorization systems [Klein, Kazman99]. Some typical styles are the architectures
based on data flow, those of implicit invocation, hierarchic and centered in data or those
of virtual interpreter-machine.
- Patterns design: They are patterns of a level of abstraction smaller than the architecture
patterns. They are therefore, next to which would be the final source code. For example:
abstract factory, constructor and chain responsibility [Buschmann et al.96].
- Patterns Interaction: also known as Patterns Interface describes a successful solution to
a recurrent problem concerning the users interface in a given context. A Pattern of
Interaction is a way communication that is expressed in a simple annotation, in order to
be understood by the people of the interactive design team that is generally
multidisciplinary [Mahemoff, Johnston98]. Some examples are: Data formats of dates,
hierarchic visual representations of the systems state [Van00].
- Patterns Implementation: They talk about the form to program or to implement a
solution in a specific language, it is associated with the term kit or idiom.
From this hierarchical structuring, it is precise to notice the differences that exists
between the types of patterns themselves and from the architectural styles, it is related to its
level of abstraction (isolated patterns versus families - languages or catalogues - of
patterns).
In general, the patterns have a limitation: they are difficult to specify and to evaluate
from a model of a particular quality. For the specifying problem and the taxonomic relation,
the use of ADL (Architecture Definition Language), according to the suggested hierarchic
proposed and as far as the evaluation of the quality, proposes to use one of the first
initiatives of quality measurement in the patterns: ABAS (Atribute-Based Architecture
Styles) [Kazman, Klein04], as structures that extend the representation of the patterns, with
the purpose to specify the information on themselves and the relative characteristics of
quality. These subjects are considered in the next section.
Representation of Patterns and its Taxonomy, through a Language of
Definition of Architectures
ADL (Architecture Definition Language) is a descriptive language that concentrates in the
structure of high level application before the details of implementation of its concrete

145
modules [Cod, May99]. A consensual definition of ADL doesnt exist until today, but
commonly it is accepted that an ADL must provide an explicit model of components,
connectors and their respective configurations. It is considered desirable, in addition, that
an ADL provides the support of tools for the development of solutions based on
architecture and its later evolution.
A Shaw study [Shaw,Clements96] analyzes the complex influence of the theory and
the practice of the patterns on the ADL. This author considers that the ADL have been own
of the software architects community, while the patterns and their respective languages
have prospered between the software designers, particularly among the groups joined to
objects oriented in designs. Naturally, both communities overcome themselves. Concerning
to the relation between architecture and design, the maintained discussions have reached a
consensus in that these designers operate at abstraction levels lower than the architects, but
over the programmers levels[Shaw, Clements96]. On the other hand, Buschmann has
documented patterns that are used as architectonic styles governed by ADL [Buschmann et
al.96]. Shaw and Clements concluded their analysis alleging that the ADL can benefit
incorporating analogous type of elements to the patterns in the sections that refer about
styles, groups and rules of design [Shaw, Clements96].
The representation of an architecture of processes, canonical services and objects for
its subsequent administration, implies the use of a ADL or a modeled generic language as it
could be UML, this would allow to make the association that is explained in figure 1:
relating the taxonomy of patterns before described, with the components and the
applications, through the process, according to a methodology. In this association, it is
necessary to establish measures that allow studying the quality and the audit process of the
software construction and its product obtained through it, which is the reason why the next
section is the ABAS subject [Kazman, Klein04].

Evaluation of the Quality in the Patterns of Software
An Attribute-Based Architecture Styles, (ABAS) is an information structure, a group that
contemplates the pattern descriptions with the quality attributes; it was propose by Kazman,
Klein, Barbacci, Longstaff, Lipson and Carriere [Kazman et al.98]. It is defined with a
three elements base : (1) the topology of the types of components, and a description of the
patterns of data and control, forthe interaction between the components (as in the standard
definition); (2) a specific attribute of quality in a quality model, and; (3) the reasoning
resulting after applying the attributes of an specific model of quality in the interaction of
the types of components.
With the purpose of incorporating the concept of ABAS in the taxonomy of patterns
exposed previously on this article and taking as a reference the patterns representations
from interaction on the base of meta-pattern proposed by Acosta and Zambrano [Acosta,
Zambrano04], the following extended representation is obtained:
Name (title), author
classification, domain
(well-known uses)
Name: Central idea by which the pattern is identified.
Author: Name of the person who created the pattern.
Classification: Type of pattern according to the taxonomy before

146
and rank. mentioned.
Dominion: Indicates the domain or the domains in which the
pattern has been implemented.
Rank: it is the degree of trustworthiness of this pattern with
respect to the domain in which it has been implemented.
Problem Describes the problem that will be solved, from the point of
view of the user.
Solution Describes, in a narrative and graphical way, the solution to the
problem. With a base in: Objective, Intention, Motivation,
Actors or Participants, Resources, Structures, Episodes,
Collaborations and Implementations.
Attributes of Quality Attributes of quality of interest, the context of use, contrasts and
relevant attributes (specific requirements).
Measures of attributes
of Quality
A summary about what is discussed in the description of the
problem, using specific terms related to measurable aspects of
the attributes in the quality model. This includes a discussion of
events that could cause that the architecture responds or changes.
Parameters of
attributes of Quality


A summary about what it will be discussed in the solution
section, but specifying relevant terms to the parameters of the
specified attributes in the quality model.
Analysis of the Model
of Quality
A description of how the attributes of the quality model will
formally be related to the elements of the pattern and the
conclusions on the architectural behavior that it is obtained with
the model.
Context Presents the conditions under the used pattern.
Force Conflicts that could restrict the solution. Including the
exceptions.
Consequences Describes the result to apply the pattern.
Examples/Against-
Examples

Shows examples and against-examples of the proposed solution.

Related Pattern

Other patterns that are related to the pattern described.
Table 1 Meta-pattern adapted from [Acosta, Zambrano04] and [Kazman, Klein04]

It is important to mention that the usability of the pattern indicated in the
representation of Acosta and Zambrano [Acosta, Zambrano04] is, in this case, a quality

147
attribute. In addition, a pattern does not require, generally, all the elements mentioned
before. In order to fulfill its objective, a pattern must have as a minimum the following
elements: Name, Problem, Solution and Context.
Business Process Management (BPM)
Business Process Management is an ancient problem. This article tries to study it
according to the new technologies, being considered to the potentialities of a model that
includes re-usable components.
In the scope of the business processes, the technological solution by excellence talks
about the term workflow, which is the process through the individual tasks that is
coordinated to complete a transaction (using the defined processes of the business) within
an organization. Workflow is a set of mechanisms that automate the work processes. These
mechanisms, related to each other aspects of the administration, establishes priorities
between the diverse tasks of each employee and optimize the communications between the
different operative units. To obtain this, it is necessary to define which are the different
tasks that are built in an organization; who participate in their execution; who are
responsible for the same ones; which is the sequence of tasks of each processes and which
are the actions that initiate each process. Although the contribution of the traditional
workflow (modeled by the WFMC Workflow Management Coalition), it is still remarkable
that there is a new generation which perhaps a hybrid that reunites the better things of all
the workflow systems and other technologies: Business Process Management Systems
(BPMS).
The BMPS incorporates ample capacities of integration with modern Java
architectures, Net and XML. Additionally, they add other technologies such as Web
Services, Business Rules Motors, Business Activity Monitoring (BAM) and Business
Process Optimization (BPO). In agreement with Howard Smith and Peter Fingar [Bell03],
guaranteed by BPMI (Business Process Management Initiative) and the WFMC, nowadays
it can be affirmed that the BPMS allows the companies to model, implement and manage
the business processes, including enterprise applications, departments, and suppliers
(partners), but without a referential frame integrated [Bell03].
The BPMS have evolved since the integration of business architectures, where it is
contemplated to the transformation and routings of data, administration of events,
automatization of processes and the use of adapters in the 90s; to the integration in the
2000 of the business processes through the basic model of the processes, the management
of the suppliers, connectivity between companies through the ecommerce and formation of
certain groups of processes for vertical industries; until arriving at the actual concept (since
2004) involved: applications of workflow, sophisticated model of processes, monitoring of
the activities associated to the business processes (BAM), exhibition of the functions of the
applications through web services, use of business rules management, support to multiple
devices of access to the information in any place and from any position (aware-contex)
through the use of portals, use of management tools of the life cycle of the software
application development that supports the processes, mobile support of the processes and
the interfaces, extraction, transformation and load (ETL) of data that are used by the

148
processes and the capacity of simulation on the processes and versioning of them (Bussines
Process Optimization BPO).
In spite of all the characteristics before mentioned, the BPMS lacks from a global
and integral framework that establishes a methodology for its implementation and use.
According to its implementation, most of the software patterns are not supported in a
precise form. The market of the BPM architectures tends to concentrate in system flows to
system and it is emerging slowly as far as the human-human flow attended by the computer
[Bell03]. Based on this, BPMI is the organization which assumes the elaboration of
standards (BPA, BPMN and BPMS; analysis, notation and semantics respectively) that
sustains the BPM concept focusing on the business process such as the start point between
the environment of it and putting it in practice through the technology. At the moment
Workflow Management Coalition is being unified with the BPMI and with OMG (Object
Management Group).
All the aspects discussed and the deficiencies shown above,lead to the elaboration
of the methodological proposal.


2 METHODOLOGICAL PROPOSAL
In this section, there will be a description of the methodological proposal for business
process management sustained in the use of patterns, as a form to solve the problems before
they appear. Initially, appears an integral theoretical framework; following it with the
appearance of the methodological proposal making aspecial emphasis in the aspects of the
generation of applications, through the software engineering.
Integral Theoretical Framework
In this integral theoretical framework is outlined a possible solution to the problems shown
in this investigation.
As shown in the taxonomy of patterns in figure 2, there is a relation between the
abstraction level, the type of patterns, and the standard suggestions by BPMI, which obtains
a direct relation of taxonomy of patterns with the domain where the methodology sets out
(BPM). In addition, the taxonomy of patterns is also associated with its formal definition
through an ADL establishing the relation between patterns, components, applications and
processes through a methodology. Finally, this taxonomy of patterns is associated with the
necessity to measure the quality of each pattern and to establish a mechanism of auditing in
the use of the patterns, providing them of specifications of quality with the ABAS use,
within the framework of a quality model (ISO9126 for the quality of the product and
ISO14598 for the quality of the process).

149

Fig 2: Integral theoretical framework of the Methodological proposal

The specification, through an ADL, of the levels of abstraction of the BPM
architecture that sustains the propose methodology, allows the representation in four layers
of the same one: layer of processes where the orchestation is made of itself, layer of
services (represent the canonical objects and the services as functions of the applications),
application layer (applications, components and software) and layer of technology
(hardware). These layers allow the identification of three specific architectures: services,
components and applications architecture.
In special, the architecture of services contains the services of: infrastructure
management, administration of suppliers or associate, own business applications,
applications of legacy, interaction, processes of business, information and connectivity
(which allow the communication between all the services mentioned). In a level of
abstraction superior to these services, there are services of management indicators and
software development, which had the rolls such as business analyst (modeler of the
process), architect, specialist of integration, developer and analyst of tests.
The process associated to the software development services has a direct
relationship with the process since it manages other one; this process, as well, is defined in
the services of process and is the conductor that will allow to administer of integral form
the BPMS and that defines a cycle for the management of the business processes that
consist of the identification of the key tasks, the model and analysis of the tasks, the
simulation and implantation of new processes, and their evaluation and monitoring.
Description of the Methodological Proposal

150
The methodological proposal for the business processes management sustained in the use of
patterns is conformed by two macro-processes: (1) Creation of the business processes; and
(2) Administration of the business processes in execution.
The first macro-process includes the following sub-processes:
1.1. Analysis and evaluation of the requirements considering the type of priority
and the base of the elicitation practices requirements of the software
engineering. In this sub-process, the user asks for a requirement on an existing
process or a new one, the analyst of the business identifies the requirement
according to the practices of elicitation of requirements of the software
engineering (it describes the requirement in terms of the functional requirements
and nonfunctional, it assigns a priority for it and evaluates a billboard of the
possible activities to make in the time). Next the analyst of the business consults
the patterns of analysis available in domain and relates them to the requirement.
Finally, for any other necessary information that it rises, it invokes a process of
change management in order to introduce the new requirement in the existing
architecture of processes;
1.2. Design of a standardized model of the process according to the patterns of
analysis in the domain (better practices). In this sub-process, the analyst of the
business compares it according to the requirements of the user, with the analysis
patterns (better practices domain), in order to identify the existing breaches and
the organizational risks to assume. Later, it negotiates the risks with the client;
the analyst of the business makes a design of the process model according to the
architectural styles and the architectural patterns that are associated to the
selected patterns analysis or the specific requirements of the user. In order to
finalize this sub-process, the analyst of the business defines a definitive list of
activities in the time and invokes to the process of software development, which
the architect selects a development process (UP, XP or FDD) and configures a
development environment (hardware and software).
1.3. Modeled, diagram and simulation. In this sub-process, the analyst of the
business makes a diagram of the process designed in a BPA tool (selecting the
already existing diagrams for the patterns of analysis, architectural styles and
chosen architectural patterns in the sub-process of design). Next, the analyst of
the business makes a simulation in the BPA tool in order to detect tendencies
(necks of bottles, cycles, etc.) and asks the user for the approval of the process
simulation. Then, the analyst of the business joins the actual diagram process
with the existing general diagram for the architecture of all the processes
(relating the present process to the existing processes) and makes a simulation
again in order to verify the tendencies with respect to the general architecture of
processes, asks to the user for the approval, makes a closing report of the design
and the modeled one of the process, and indicates the architect whom exports
the BPEL (Language of Execution of Processes proposed by the BPMI) from
the BPA tool and the UML (Unified Language of Modeling) who will be input
for the software development process.
1.4. Configuration and implementation of the logic of integration, businesses and
presentation of the process through the orchestration of services, objects and the
use of patterns of design and interface with base in the modeled phase. In this

151
sub-process, the architect takes the UML diagrams created by BPA tool, and the
functional and nonfunctional requirements from the analysis of process
requirements, and it completes the UML diagrams according to the process of
the selected development (UP, XP or FDD). Later, from the UML diagrams, the
BPEL and the patterns of design related to the analysis patterns, architectural
styles and selected architectural patterns in the previous sub-processes, the
architect asks for the developer that it constructs the logic of business of the
application that will sustain to the process (the developer besides to select the
patterns design, also selects the idiom in which it made the development of the
business logic); similarly according to the patterns interaction related to the
analysis patterns, the architectural styles and selected patterns architectural in
the previous sub-processes, the BPEL and the associate interfaces automatically
with the BPEL through the BPA tools the architect asks for the developer that
constructs the interface of the tool that supported the process (the developer
besides to select the patterns interaction also selected idiom in which it made the
development of the interface). Then, the architect asks for the integration of a
specialist who makes integrations between the BPEL, the interface and the logic
of business. Having the BPEL, the logic of business and the interface integrated,
the architect proceeds to place in the BPEL the indicators management that will
be measure the process, for this it selects of a set previously defined according
to the analysis pattern, the necessary indicators and it as well asks for the
developer that constructs the reports necessary to show the indicators (the
BPMS contains a modulate of BAM which store these indicators in the time
according to structures of business intelligence). Finally the architect asks for
the tests analyst the software certification product that sustains the process, soon
to finalize the process of change management of the architecture of processes
and to solicit collocates it to production of the process (it is precise to mention
that different versions from a same process can be handled).
The other macro-process corresponds to the administration of the processes
in execution and includes: the maintenance, administration of the process in production;
and the monitoring, validation of the technical-functional data of the processes
implemented through indicators management.
3 CONCLUSION
It can be concluded that at the moment it doesnt exist a treatment sufficiently exhaustive
and consolidated of the subjects of business process management sustained in the use of
patterns, according to the audit and the quality of the process and the product of the
software. By means of this investigation these deficiencies are attacked, and propose the
construction of:
- A language of patterns for the methodology of business process management with a
base in the construction sustained in software components: a study of the existing
alternatives for the selection, application and verification of patterns and the
composition of components of software from the point of view of the conditioners

152
raised here (audit, verification static, automatic and reasonable) contemplating to the
model object and the architecture of services for the processes;
- An attended modeled method of applications of software that allows the audit in diverse
stages of the software life cycle. This method of modeled and verification have in
addition special characteristic: (a) it can be used by a development organization,
without knowledge on formal methods; (b) it foments the collection and uses a
knowledge that is habitually lost; (c) it allows to manage this knowledge with the
necessity to integrate it in the source code of the developed programs, and (d) it is not
joined to any language of specific development nor any specific intention.
- A system of practical viable verification of components: (a) the tools can be developed
with base in network technologies and (b) the necessary basic knowledge fits in the
typical profile of the professional software development.
The future pieces will orient the construction of one wikipedia for the administration
of taxonomy of patterns and its quality in the BPM domain, along with the specification of
the ADL and a prototype of low level that supports the implementation of the
methodological proposal through a case of study in the BPM domain.
REFERENCES
[Acosta, Zambrano04]
Acosta, E. y Zambrano N.: Patterns and Objects for User
Interface Construction, in Journal of Object Technology, vol. 3
no. 3 March-April 2004 pp. 75-90
[Alexander et al.77]
Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M.,
Fidsdahl-King, I., Angel, Sh.: A Pattern Language. Oxford
University Press, New York, 1977.
[Bell03]
Bell, T.: A BPM Taxonomy: Creating Clarity in a Confusing
Market. Gartner Research Note, Technology, T-18-9669. 2003.
[Buschmann et al.96]
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., y
Stal, M.: Pattern-Oriented Software Architecture: A System of
Patterns. Wiley & Sons. 1996.
[Cod, May99]
Coad, P., May, M.: JAVA Design: Building Better Apps and
Applets. 2
nd
Edition. Yourdon Press, Upper Saddle River, 1999.
[DSouza,Wills99]
DSouza, D., y Wills, A.: Objects, Components and
Frameworks with UML. The Catalysis approach. Addison-
Wesley. 1999.
[Fowler97]
Fowler, M.: Analysis Patterns: Reusable Object Models.
Addison-Wesley, 1997.
[Gamma et al.95]
Gamma, E., Helm, R., Johnson, R., y Vlissides, J.: Design
Patterns. Addison Wesley. 1995.
[Jacobson et al.97]
Jacobson, I., Griss, M., y Jonsson, P.: Software Reuse.
Architecture, Process and Organization for Business Success.
Addison-Wesley. 1997.
[Kazman, Klein04]
Kazman R., y Klein, M.: Attribute-Based Architectural Styles.
Carnegie Mellon Software Engineering Institute Technical

153
Report CMU/SEI-99-TR-022, 2004.
[Kazman et al.98]
Kazman R., Klein M., Barbacci M., Longstaff T., Lipson H.,
Carriere J.:The Architecture Tradeoff Analysis Method.
CMU/SEI-98-TR-008, ESC-TR-98-008. 1998.
[Klein, Kazman99]
Klein M. y Kazman R.: Attribute-Based Architectural Styles,
CMU/SEI-99-TR-022, ESC-TR-99-022: 1-69. 1999.
[Leite00]
Leite, J., Hadad, G., Doorn, J., Kaplan, G.: A Scenario
Construction Process, Requirements Engineering Journal,Vol.5,
N 1 2000 pp. 38-61.
[Mahemoff, Johnston98]

Mahemoff, M. y Johnston, L.: Pattern Language for Usability :
An Investigation of Alternative Approaches. Asia-Pacific
Conference on Human-Computer Interaction (APCHI98)
Proceedings, 25-31. Tanaka, 1998.
[Ridao01]
Ridao, M.: Uso de Patrones en el Proceso de Construccin de
Escenarios. Tesis Maestra en Ingeniera de Software, Univ.
Nacional de La Plata, Noviembre 2001.
[Shaw, Clements96]
Shaw M., Clements P.: How Should Patterns Influence
Architectural Description Languages? A Call for Discussion.
Computer Science Department and Software Engineering
Institute Carnegie Mellon University. 1996.
[Van00]
Van Welie, M. y Troetteberg, H. Interaction Patterns in User
Interfaces. 7
th
Pattern Language of Programs Conference,
August 2000, Illinois, USA, 2000. URL:
http://www.cs.vu.nl/~martijn/patterns/index.html
About the author(s)
Pedro Bonillo Ramos is a teacher and researcher at the Central University
of Venezuela. He obtained his Master in Computer Sciences at the Simon
Bolivar University in Venezuela in 2002 and his Master in Business
Administration at the Yacamb University in Venezuela in 2004.
Currently, he is working on his PhD in Computing Sciences doing
research about Software Engineering mainly focusing in Business Process
Management. He is also working on his other PhD in Management
Sciences doing research about Value Data Maps. He can
be reached at pbonillo@cantv.net
Nancy Zambrano Rivas is a teacher and researcher at the Central
University in Venezuela. She obtained her Master in Computer Sciences
at the Central University of Venezuela in 1989. She obtained her PhD. in
Computing Sciences, Informatique at the Laboratoire de Recherche en
Informatique (LRI), Universit Paris-Sud XI, in 1995. She is researching
about Software Engineering (light methods, heavy methods, object-

154
oriented methods, Unified Process, software development methods based on
transformations) and Human-Computer Interaction (interaction patterns, tendencies in
interface). She can be reached at nzambran@ciens.ucv.ve

Alecia Eleonora Acosta is a teacher and researcher at the Central
University of Venezuela. She did a D.E.A dInformatique at the
Universit Paris-Sud XI, France, in September 1992. Later, she obtained
her Master in Computer Sciences at the Central University of Venezuela
in 1993. She obtained her PhD. in Computing Sciences at the Central
University of Venezuela in 2004. She is researching about user interface
designs, patterns, usability and socialization of the computation. She can be reached at
eacosta@ciens.ucv.ve