UNIVERSIDAD SIMN BOLVAR

COORDINACION DE INGENIERA DE LA COMPUTACIN

Automatizacin de Procesos de Negocio de RRHH de

Develcom Soluciones e Informtica, C.A

Por:
Vernica Elizabeth Cuello Gonzlez

INFORME FINAL DE CURSOS EN COOPERACIN

Presentado ante la Ilustre Universidad Simn Bolvar
Como Requisito Parcial para Optar al Ttulo de
Ingeniero en Computacin

Sartenejas, Septiembre de 2005.

UNIVERSIDAD SIMN BOLVAR

COORDINACION DE INGENIERA DE LA COMPUTACIN

Automatizacin de Procesos de Negocio de RRHH de

Develcom Soluciones e Informtica, C.A

Informe de Pasanta elaborado en:

Develcom Soluciones e Informtica, C.A

Autor: Vernica Elizabeth Cuello Gonzlez.

Carnet No: 99-31641
Tutor Acadmico: Profesor Richard Gil.
Tutor Industrial: Ingeniero Freddy de Brito.

Sartenejas, Septiembre de 2005.

UNIVERSIDAD SIMN BOLVAR

DECANATO DE ESTUDIOS PROFESIONALES
COORDINACIN DE INGENIERA DE LA COMPUTACIN

ACTA FINAL DE CURSOS EN COOPERACIN

Automatizacin de Procesos de Negocio de RRHH de

Develcom Soluciones e Informtica, C.A

Presentado Por:
Vernica Elizabeth Cuello Gonzlez.
Este trabajo de cursos en Cooperacin ha sido aprobado en nombre de la
Universidad Simn Bolvar por el siguiente jurado examinador:

Prof. Edumilis Mndez.

Jurado

Prof. Richard Gil.

Tutor Acadmico

Sartenejas, Septiembre de 2005

Resumen.
El presente proyecto de pasanta ha sido realizado en la empresa Develcom Soluciones e
Informtica C.A. El trabajo realizado durante la pasanta, esta motivado por la necesidad de la
empresa de formalizar y automatizar sus procesos de negocio de recursos humanos. Como
resultado de este proyecto pasanta se han realizado varios documentos y diagramas que
fundamentan el desarrollo, se han implementado todos los procesos requeridos por la compaa y
se ha diseado una aplicacin preliminar para la manipulacin de esto procesos integrados en un
prototipo. El prototipo funcional implementado se denomina Sistema de Gestin de Recursos
Humanos, este prototipo esta constituido por un motor de flujos de trabajo para los procesos de
recursos humanos y una aplicacin Web que interacta con los procesos implementados. Las
funcionalidades de este sistema permiten instanciar los procesos de recursos humanos y realizar
las tareas constitutivas de cada uno de los procesos.
El desarrollo fue llevado a cabo usando el estndar BPEL y el marco de trabajo Struts,
que combinadas, ofrecieron las bases tecnolgicas necesarias para la realizacin del proyecto.
El diseo y desarrollo del sistema fue regido por la metodologa Rational Unified Process (RUP), la
metodologa propone cuatro fases de desarrollo asociadas a cada ciclo de desarrollo. En la
primera fase, denominada concepcin, se plantearon los objetivos principales del sistema y se
delimit el alcance del mismo. En la segunda fase, denominada elaboracin, se hizo un
levantamiento extensivo de los requerimientos, se plante un diseo del sistema y la arquitectura
de software. En la tercera, llamada fase de construccin, se procedi a desarrollar el prototipo
funcional del sistema. Y la cuarta y ltima fase, la fase de transicin, se procedi a probar el
sistema y a realizar una descripcin en detalle del estatus final del proyecto.
Como resultado de este proyecto de pasanta se obtuvo una visin completa del sistema,
un diseo preliminar y la implantacin de un prototipo inicial.

Dedicado a m!
Vernica Cuello.

Agradecimientos.
Quiero agradecer a mis familiares que me quieren y apoyan. A Juancho, a Yeyita, a
Mandinga y a Alvarito. A mis aguelos Cuello, mi aguelo Efrn y la aguela Elsy, a mis tos Jose,
Juan Carlos, Maria, y Nano, y las primas Virgi y Mafer.
Tambin quiero agradecer a las personas de la Uni que me dieron las herramientas y el
conocimiento para afrontar este proyecto, en especial al profesor Richard Gil, a la profesora Ana
Maria Borges y a la ingeniero Maribel Pepe por sus consejos acertados y continua ayuda moral y
acadmica, tanto en el pasado como en el presente proyecto, en especial a mi tutor el profe Gil.
Un agradecimiento muy especial para la compaa que me recibi en la realizacin de
este proyecto, Develcom Soluciones e Informtica C.A, cuyo personal me ha dado la oportunidad
de aprender mucho y me han apoyado para la realizacin exitosa de este proyecto. Un
agradecimiento especial a Alfredo, Angie, Blas, Alejandro, Erika y Rosme que siempre estuvieron
dispuestos a ayudarme, especialmente Alfredo.
And last but not least, un agradecimiento sper especial a todos mis amigos de la Uni
que me dieron su apoyo acadmico, moral y emocional no solo en este proyecto si no tambin
durante toda mi carrera. De primerito gracias al Chesco por ser mi pana, gracias a todos los
infelices o aledaos en orden correlativo descendente al Peck, a a, a Anto, a Ivan, a Albi, a Adri
y a Roman.
Y gracias a Dios que por fin me grado!! :D

ndice de Contenido.
Captulo I - Introduccin........................................................................................................9
Captulo II Entorno Empresarial. ......................................................................................11
1. Escenario Empresarial. .............................................................................................. 11
2. Ubicacin del Pasante dentro de la Empresa. ................................................................ 12
Captulo III Planteamiento del Problema. ........................................................................13
1. Descripcin del Proyecto. .......................................................................................... 13
2. Objetivos. ............................................................................................................... 14
a. Objetivo General. ....................................................................................................... 14
b. Objetivos Especficos. ................................................................................................. 14
3. Alcance. ................................................................................................................. 14
Captulo IV Metodologa de Desarrollo. ............................................................................16
1. Las Mejores Prcticas. .............................................................................................. 16
2. Modelo de Arquitectura de 4+1 Vistas. ........................................................................ 17
3. Racional Unified Process; Fases e Iteraciones ............................................................... 19
a. Fase de Inicio o Concepcin........................................................................................ 20
b. Fase de Elaboracin. .................................................................................................. 21
c. Fase de Construccin.................................................................................................. 22
d. Fase de Transicin. .................................................................................................... 23
4. Racional Unified Process; Diagramas. .......................................................................... 23
a. Modelo Conceptual. .................................................................................................... 23
b. Modelo de Datos. ....................................................................................................... 24
c. Diagramas de Casos de Uso. ....................................................................................... 24
d. Extensin del Diagrama de Actividad de UML para modelado de Workflow. .................... 24
Captulo V Marco Terico...................................................................................................27
1. Integracin de Sistemas. ........................................................................................... 27
2. Flujo de Trabajo (Workflow). ..................................................................................... 28
3. Business Process Manager (BPM)................................................................................ 28
4. Business Process Execution Language for Web Services (BPEL). ...................................... 32
5. Oracle BPEL Process Manager. ................................................................................... 34
a. Oracle JDeveloper BPEL Designer. ............................................................................... 35
b. Oracle BPEL Console................................................................................................... 36
c. Oracle BPEL Server..................................................................................................... 36
6. Definicin de los Conceptos Asociados a BPEL .............................................................. 36
a. Arquitectura SOA (Service Oriented Architecture). ........................................................ 36
b. Web Services. ............................................................................................................ 37
7. Jakarta Struts. ......................................................................................................... 38
Captulo VI Desarrollo del Sistema. ..................................................................................40
1. Fase de Inicio .......................................................................................................... 40
a. Requerimientos Funcionales. ....................................................................................... 40
b. Requerimientos no Funcionales. .................................................................................. 41
c. Definicin de Actores.................................................................................................. 41
d. Lista de Riesgos. ........................................................................................................ 42
e. Glosarios del Sistema.................................................................................................. 43
f. Modelo Conceptual del Sistema. .................................................................................. 43
g. Modelo Inicial de Casos de Uso. .................................................................................. 44
h. Delimitacin del Ciclo de Proyecto y Plan de Proyecto. .................................................. 50
2. Fase de Elaboracin. ................................................................................................ 53
a. Modelos WAD; Modelo de Flujo de Procesos de RRHH. ................................................. 53
i. Solicitud de Constancia de Trabajo. ..................................................................... 54
ii. Solicitud de Prestaciones. ................................................................................... 55
iii. Solicitud de Prstamo. ........................................................................................ 56

iv.
v.
vi.
vii.

Solicitud de Vacaciones. ..................................................................................... 58

Solicitud de Personal. ......................................................................................... 60
Solicitud de Pago de Relaciones de Gasto. ........................................................... 61
Solicitud de Cursos de Capacitacin. .................................................................... 63

b. Modelo de Datos del Negocio. ..................................................................................... 64

c. Descripcin de la Arquitectura del software. ................................................................. 66
d. Lista Revisada de Riesgos. .......................................................................................... 69
3. Fase de Construccin. ............................................................................................... 69
a. Implementacin de los Procesos de Negocio. ............................................................... 69
b. Implementacin de la Capa Lgica de Aplicacin. ......................................................... 72
c. Implementacin de la Interfaz..................................................................................... 72
d. Mapa de Navegacin del Prototipo............................................................................... 73
4. Fase de Transicin. .................................................................................................. 73
a. Descripcin del Estado Actual del Proyecto................................................................... 73
i. Revisin de Lista de Riesgos. .............................................................................. 74
ii. Descripcin del Prototipo. ................................................................................... 75
b. Pruebas Finales.......................................................................................................... 81
c. Plan para Prximos Ciclos. .......................................................................................... 82
Captulo VII Conclusiones y Recomendaciones. ...............................................................84
1. Conclusiones. .......................................................................................................... 84
2. Recomendaciones. ................................................................................................... 86
Referencias Bibliogrficas. ...................................................................................................88
Referencias Electrnicas. .....................................................................................................89
Glosario de Trminos............................................................................................................90
Apndice. ..............................................................................................................................96
Apndice 1: Especificacin de Lista de Requerimientos Funcionales. ......................................... 96
Apndice 2: Especificacin de Lista de Requerimientos no Funcionales. .................................... 99
Apndice 3: Especificacin de Lista de Riesgos. .................................................................... 102
Apndice 4: Especificacin de Lista Casos de Uso.................................................................. 104
Apndice 5: Plan de Trabajo para el Primer Ciclo de Desarrollo. ............................................. 120
Apndice 6: Plan de Trabajo para el Segundo Ciclo de Desarrollo. .......................................... 121
Apndice 7: Plan de Trabajo para el Tercer Ciclo de Desarrollo. ............................................. 121
Apndice 8: Plan de Trabajo para el Cuarto Ciclo de Desarrollo. ............................................. 122
Apndice 9: Pantallas del Prototipo. ..................................................................................... 122
Ilustraciones.......................................................................................................................126
Ilustracin 1: Desarrollo Iterativo de Software. ..................................................................... 126
Ilustracin 2: Gestin de Requerimientos.............................................................................. 126
Ilustracin 3: Protagonistas en la Integracin de Sistemas..................................................... 127
Ilustracin 4: Oracle BPEL un ejemplo de Integracin............................................................ 127
Ilustracin 5: Notacin Estndar propuesta por ISO/IEC 9126................................................ 128
Ilustracin 6: Interfaces del Sistema. ................................................................................... 129
Ilustracin 7: Flujos de Procesos Implementados en Oracle BPEL. .......................................... 130
Ilustracin 8: Model, View, Controller. .................................................................................. 132
Anexo..................................................................................................................................133
Anexo 1: Extending UML Activity Diagram for Workflow Modelling in Production Systems......... 133
Anexo 2: Ten Pillars for World Class Business Process Management ....................................... 134

ndice de Figuras.
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig
Fig

1 Arquitectura de 4+1 Vistas ............................................................................................... 18

2 - Fases de RUP. .................................................................................................................. 19
3 Fases e Hitos del RUP. ..................................................................................................... 20
4 Diagrama conceptual del WAD. ......................................................................................... 26
5 -. Arquitectura de OracleAS BPEL Process Manager ............................................................... 34
6 Diagrama de Actores........................................................................................................ 42
7 Diagrama Conceptual. ...................................................................................................... 44
8 Diagrama inicial de Casos de Uso. ..................................................................................... 49
9 Diagrama de Casos de Uso del Ciclo. ................................................................................. 52
10 Diagrama WAD de Solicitud de Constancia de Trabajo. ..................................................... 54
11 Diagrama WAD de Solicitud de Prestaciones..................................................................... 55
12 Diagrama WAD de Solicitud de Prstamo. ........................................................................ 57
13 Diagrama WAD de Solicitud de Vacaciones....................................................................... 58
14 Diagrama WAD de Solicitud de Personal. ......................................................................... 60
15 Diagrama WAD de Solicitud de Pago de Relaciones de Gasto............................................. 62
16 Diagrama WAD de Solicitud de Cursos de Capacitacin. .................................................... 63
17 Modelo de Datos. ........................................................................................................... 64
18 Modelo de Implementacin; Struts + BPEL. ..................................................................... 67
19 Implementacin del proceso de Solicitud de Constancia de Trabajo en Oracle BPEL. ........... 71
20 Mapa de Navegacin. ..................................................................................................... 73
21 Prototipo: Inicio. ............................................................................................................ 76
22 Prototipo: Bandeja de Tareas. ......................................................................................... 77
23 Prototipo: Realizar Tarea. ............................................................................................... 77
24 Prototipo: Solicitar Prstamo. .......................................................................................... 78
25 Prototipo: Ver Relaciones de Gasto Ponderadas de Subalternos ......................................... 79
26 Prototipo: Ingresar y Ver Relacin de Gasto del Mes en Curso ........................................... 80
28 Prototipo: Aprobar y Recalcular Relaciones de Gasto de Subalternos.................................. 81

ndice de Tablas.
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla

1:
2:
3:
4:
5:
6:
7:

Descripcin de la Fase de Inicio. ..................................................................................... 21

Descripcin de la Fase de Elaboracin. ............................................................................ 22
Descripcin de la Fase de Construccin. .......................................................................... 22
Descripcin de la Fase de Transicin. .............................................................................. 23
Tabla Comparativa entre BPM y BPEL. ............................................................................. 33
Descripcin de Actores y sus Responsabilidades. .............................................................. 41
Descripcin de Casos de uso........................................................................................... 44

Captulo I - Introduccin.
Las necesidades empresariales actuales apuntan hacia una comunidad de negocios cada
vez mas interconectada. La integracin de procesos de negocio es hoy un valor agregado para las
relaciones entre compaas que comparten intereses, informacin y objetivos comunes, esto
implica que se establece una comunicacin entre los sistemas que soportan los procesos de
negocio, pero cada participante es dueo de una parte de del proceso, y solo se comparte aquella
informacin o tareas que de un valor agregado a los participantes.
Existen muchas barreras no triviales que deben romperse para lograr la tan deseada
integracin entre compaas que tienen inters en que sus sistemas colaboren; las compaas no
tienen un conocimiento profundo de sus propios procesos de negocio, las plataformas en donde
se encuentran los sistemas son divergentes o incompatibles y el coeficiente de costo-esfuerzo de
la integracin es inviable. Los procesos de negocio son complejas redes de tareas guiadas por
reglas de negocio, cuando las compaas tienen muchos y muy complicados procesos de negocio
es probable que se tenga una definicin errada del flujo del proceso y que el proceso de negocio
caiga en redundancias o en actividades que no agregan ningn valor a proceso, la falta de
comprensin de los procesos hace ardua su integracin. El problema de las plataformas
divergentes se ha solucionado en otros escenarios usando el protocolo de Internet para la
comunicacin entre sistemas, este protocolo es abierto y flexibiliza la comunicacin entre sistema
diferentes, la tendencia es que la integracin de sistemas tienda a Internet. Y por ltimo, las
soluciones implementadas para lograr la integracin de sistemas deben ser flexibles para que se
adapten a la cambiante realidad de los negocios, de lo contrario el costo y el tiempo para que los
sistemas se integren se hace inmanejable haciendo que los participante pierdan valiosas
oportunidades de negocio y dinero.
El Business Process Manager (BPM) es la propuesta mas viable hacia la integracin de
procesos de negocio. BPM ofrece los lineamientos para modelar, integrar, monitorear y optimizar
todas las partes de un proceso de negocio, controlando y haciendo visible de principio a fin las
transacciones constitutivas del proceso. La definicin misma del BPM esta orientado
principalmente hacia el proceso de negocio en s, dejando un poco de lado la comunicacin que
es necesario establecer para lograr la integracin, es decir, BPM especifica el como deben de
hacerse las cosas pero no propone como tecnolgicamente implementar la integracin. Para
cubrir este nicho tecnolgico, ha surgido BPEL como la solucin ms robusta, consistente,
completa y viable. BPEL, Business Process Execution Language for Web Services, es el estndar
propuesto por Oasis para la integracin de procesos negocio. BPEL posee toda la riqueza de los
flujos de trabajo y la flexibilidad de los Web Services.

Oracle Corporation ofrece un IDE para la implementacin en BPEL denominado Oracle

BPEL Process Manager. Esta herramienta facilita la implementacin de verdaderas aplicaciones
integradas, motores de workflow montados como Web Services orquestados en aplicaciones de
integracin. Es la solucin a los problemas de integracin que presenta el mundo empresarial.
Develcom Soluciones e Informtica C.A es una compaa desarrolladora de software con
amplia experiencia en el desarrollo de aplicaciones de flujos de trabajo aplicados a procesos de
negocio. Con la idea de incursionar en la nueva propuesta Oasis implementada por Oracle, decidi
automatizar sus propios procesos de recursos humanos en BPEL. Esto le permitir a Develcom
Soluciones e Informtica C.A un primer acercamiento a la automatizacin de sus propios procesos
de negocio y sentar un precedente dentro de la compaa para la implementacin de soluciones
integradas de procesos de negocio usando Oracle BPEL Process Manager.
El presente informe de pasanta recoge la informacin que foment al desarrollo del
sistema de gestin de procesos de recursos humanos implementado para Develcom Soluciones e
Informtica C.A usando Oracle BPEL Process Manager y orientado por la conocida metodologa de
desarrollo Rational Unified Process (RUP).
El informe consta de siete captulos que describen la motivacin del proyecto, los
basamentos tericos, los lineamientos metodolgicos, los aspectos ms relevantes del desarrollo
del sistema y, por ltimo las conclusiones finales del proyecto. A continuacin se presenta una
breve lista de los captulos que constituyen este informe de pasanta y una breve resea de su
contenido:
9

Captulo I Introduccin: En el primer captulo se encuentra el presente apartado

introductorio del documento.

9

Captulo II Entorno Empresarial: En el segundo captulo se explica el entorno

empresarial y cual es el papel del pasante dentro del proyecto.

9

Captulo III Planteamiento del Problema: En el tercer captulo se plantea el

problema, se definen los objetivos y el alcance del proyecto.

9

Captulo IV Metodologa de Desarrollo: En el cuarto captulo se definen los

lineamientos metodolgicos que guiaron el desarrollo.

9

Captulo V Marco Terico: En el quinto captulo de definen los basamentos tericos

que fundamentaron el desarrollo de la aplicacin.

9

Captulo VI Desarrollo del Sistema: En el sexto captulo se describen los pasos y

productos sucesivos del proceso de desarrollo de la aplicacin.

9

Captulo VII Conclusiones y Recomendaciones: En el sptimo y ltimo captulo se

enumeran las conclusiones y recomendacin que la experiencia del desarrollo arrojaron.

10

Captulo II Entorno Empresarial.

En el presente captulo se expone el escenario empresarial de Develcom Soluciones e
Informtica, como tambin la ubicacin del pasante dentro de la empresa. La definicin del
entorno empresarial permite entender donde se desarrolla el proyecto, y en este caso, para quien
se desarrolla el proyecto.

1. Escenario Empresarial.
Develcom Soluciones e informtica es una compaa pequea que se encarga de
desarrollar soluciones informticas, tiene aproximadamente 30 empleados. Develcom se
encuentra en franco crecimiento, y sus procedimientos administrativos internos han crecido y se
han vuelto ms complejos a travs del tiempo. Actualmente la compaa no cuenta con un
departamento de Recursos Humanos, las tareas asociadas a esta figura son realizadas en su
mayora por la alta gerencia. Los procedimientos asociados a las solicitudes de recursos humanos
no estn definidos formalmente, es decir, no existe un manual de procedimiento de cmo
procesar dichas solicitudes. Sin embargo, los procedimientos se rigen por una serie de reglas de
negocio que son ms o menos intuitivas a los participantes.
La gerencia de Develcom Soluciones e Informtica desea cambiar para mejor esta
situacin desarrollando una aplicacin informtica que gue el procesamiento de las solicitudes de
recursos humanos formalizando las tareas asociadas al proceso.
Las solicitudes que se desearan automatizar son:

Solicitud de Vacaciones.

Solicitud de Prestaciones.

Solicitud de Prstamo.

Solicitud de Constancia de Trabajo.

Solicitud de Cursos de Capacitacin.

Solicitud de Personal.

Solicitud de Pago de Relaciones de Gasto.

Actualmente estas solicitudes son procesadas por la alta gerencia y el empleado

solicitante, algunas veces involucrando a los supervisores directos del solicitante, el abogado de la
empresa o el administrador. La mayora de los empleados de Develcom Soluciones e Informtica
se encuentran en otras oficinas fuera de la empresa, realizando tareas de consultora a clientes de
la empresa, esta lejana implica que los empleados deben de enviar por correo electrnico sus
solicitudes o presentarse personalmente en la oficina de Develcom para realizar sus solicitudes,

11

esto tambin dificulta el feedback que se le puede dar de dichas solicitudes durante su
procesamiento y su seguimiento.
Con la finalidad de formalizar el procedimiento de procesamiento de las solicitudes se
desea

definir

algunas

figuras

administrativas

que

permitirn

especificar

funciones

responsabilidades dentro de los procesos. Estas figuras son el Ente Legal, el Ente Administrativo,
y el Ente de Recursos Humanos. Esto permitir definir funcionalidades que perdurarn en el
tiempo y que mantendrn los procedimientos de recursos humanos vigentes en la medida en que
la empresa crezca. Estas figuras son grupos de personas que comparten las responsabilidades
asociadas a un grupo de tareas, los grupos pueden solaparse o estar conformados por
individualidades.
La formalizacin de los procedimientos le permitir a Develcom Soluciones e Informtica
tener un mayor control sobre sus procesos de Recursos Humanos, procesando mas eficiente y
efectivamente las solicitudes, traducindose en una mayor satisfaccin de los empleados con la
atencin de sus solicitudes. Como se sabe la satisfaccin de los empleados con la empresa se
traduce en una menor movilidad laboral, mayor sentido de pertenencia, ms eficiencia, entre
otras cosas que se traducir en beneficios de productividad de los empleados en su trabajo.

2. Ubicacin del Pasante dentro de la Empresa.

Develcom Soluciones e Informtica no cuenta con una divisin departamental bien
definida, sin embargo, se podra decir que existen tres vertientes dentro de la estructura
organizacional; el rea de ventas, el rea de soporte y consultora, y el rea de desarrollo de
software. El pasante se ubica en el rea de desarrollo de software, la labor del pasante ser el
desarrollo del presente proyecto, cuyas especificaciones se definen en el presente documento.

12

Captulo III Planteamiento del Problema.

En el presente captulo se exponen los objetivos, alcance y descripcin del proyecto
desarrollado. Con el planteamiento del problema se pretende establecer una definicin preliminar
del proyecto donde se especifica la finalidad y alcance del desarrollo.

1. Descripcin del Proyecto.

El proyecto persigue desarrollar una aplicacin que permita monitorear, activar y realizar
tareas de los procesos de negocio asociados a RRHH de Develcom Sistemas, C.A de forma enlnea, remota y concurrente. Ms que un sistema experto en los procesos de Recursos Humanos
se desea realizar un motor de flujo de trabajo (workflow) que gue las tareas de los procesos de
Recursos Humanos de la Empresa, sirviendo de apoyo para los empleados en la realizacin de
tareas. Es decir, la aplicacin no pretende ser un sistema de informacin tradicional, si no un
motor de flujo de procesos. La informacin de la que se nutre el sistema viene de los
participantes de los procesos y depende de ellos.
Todo el desarrollo de la aplicacin estar soportado por la metodologa Racional Unified
Process (RUP). Esta metodologa le ofrecer una estructura formal para el desarrollo del proyecto,
tambin permitir que el proyecto crezca mas all de los lmites de este planteamiento inicial,
sentando las bases documentales para el desarrollo total del proyecto y la implementacin de
todos los requerimientos planteados por la empresa, como tambin nuevos procesos
administrativos de la compaa.
El proyecto ser desarrollado utilizando la tecnologa BPEL Process Manager de ORACLE
(Business Process Execution Language) para definir e implementar los procesos de negocio, y el
marco de trabajo de Jakarta Struts para construir las pginas Web que ofrecer la interfaz al
usuario. Estas herramientas presentan caractersticas robustas y coherentes con los objetivos del
proyecto ofreciendo una implementacin ms sencillas y rica de la aplicacin.

13

2. Objetivos.
a. Objetivo General.
Desarrollar una aplicacin que automatice procesos de negocio asociados a RRHH para
monitorear, activar y realizar tareas de manera concurrente y remota. La aplicacin debe proveer
un servicio consistente, concurrente y continuamente disponible, y mejorar significativamente la
consistencia, rapidez y comodidad en que los procesos de negocio asociados a RRHH son llevados
a cabo.
b. Objetivos Especficos.
1) Identificar, Modelar y Analizar los procesos de negocio asociados a RRHH con el fin de
establecer formalmente un marco de procedimiento para el flujo de los procesos.
2) Disear un sistema en plataforma Web que permita interactuar con los procesos de RRHH.
3) Elaborar una estrategia para la implementacin del sistema a fin de facilitar los
procedimientos y sus pruebas respectivas.
4) Determinar el perfil de los usuarios del sistema para determinar la permisologa, pertinencia y
participacin de los empleados de Develcom Soluciones e Informtica.
5) Ofrecer un motor de flujo de trabajo para los procesos de RRHH que sea consistente con las
reglas de negocio para que cubra cabalmente las necesidades de la empresa.

3. Alcance.
En el proyecto de desarrollo, se implementa una aplicacin que cumple con los objetivos
planteados, dicha implementacin debe proveer las funcionalidades necesarias y factibles que
resulte del anlisis de requerimientos y debe ofrecer una interfaz de manipulacin de servicios
para los usuarios finales.
La tecnologa BPEL es usada para implementar los procesos de negocio asociados a
RRHH, BPEL es un lenguaje basado en XML diseado para permitir compartimiento de tareas de
manera distribuida por medio de una combinacin de servicios Web, formalmente el
analista/programador describe un proceso de negocio que se lleva a cabo en la Web de forma tal
que cualquier entidad de cooperacin puede realizar uno o ms pasos del proceso.
La interfaz de la aplicacin es implementada usando tecnologa Web bajo el marco de
trabajo de Jakarta Struts. Este marco de trabajo alienta una arquitectura de aplicaciones basada
en el patrn de diseo MVC (Model-View-Controller), esta caracterstica permite implementar una
interfaz amigable, al igual que integrar la lgica del negocio con la lgica de los procesos.

14

Del producto de este proceso de desarrollo, se genera documentacin que soporta

tcnica y tericamente los aspectos de diseo e implantacin del producto final, para esto, es
usada la herramienta Rational Rose que se apoya en la metodologa RUP y el lenguaje de
especificacin UML. Rational Rose facilita la generacin y manejo de modelos UML necesarios
para el proyecto; modelo de casos de uso, diagrama conceptual, y diagramas de actividad.

15

Captulo IV Metodologa de Desarrollo.

A continuacin se describe de manera detallada la metodologa que gua el proceso de
desarrollo de la aplicacin. La metodologa Racional Unified Process (RUP) propuesta por Philippe
Kruchten [RUP1999] es una slida y reconocida metodologa fundamentada en aos de
conocimiento en el desarrollo de software, en ella se combinan las mejores prcticas del
desarrollo de sistemas de software definiendo un conjunto de pasos que gua a un desarrollo
exitoso y consistente. RUP apoya el ciclo de vida evolutivo incremental, adems de estar
orientada al desarrollo de componentes, dando apoyo al desarrollo orientado a objetos
consistente con los marcos de trabajo ofrecidos por BPEL y Struts. RUP consta de varias fases,
actividades y entregables que garantizan el ptimo diseo, desarrollo y justificacin del sistema. El
ciclo de desarrollo del proyecto tiene definidos varios puntos de control o hitos para cada fase.

1. Las Mejores Prcticas.

RUP define seis mejores prcticas que representan los lineamientos para un buen
desarrollo de software, estos lineamientos representan una gua de correcto uso de la
metodologa, es decir, un marco referencial. Las seis mejores prcticas son:

Desarrollo Iterativo del Software.

El desarrollo de software iterativo consiste en el proceso incremental y cclico de

desarrollo de sistemas de software, debido a la complejidad que presenta el software en la

actualidad el desarrollo lineal no es una buena prctica ya que no soporta el cambio evolutivo del
sistema y de sus requerimientos. Con esto se logra reducir los riesgos del proyecto y tener un
subsistema ejecutable tempranamente. (Ver Ilustracin 1).

Gestin de Requerimientos.
Gestionar requerimientos implica elicitar, organizar, y documentar los requerimientos del

dueo del sistema. Para llevar una efectiva gestin de requerimientos es importante documentar
los cambios en estos, sobre todo porque el cambio es la regla cuando hablamos de
requerimientos, se hace necesario llevar un registro de cambios y decisiones asociadas a esos
cambios. La forma de documentar los requerimientos es a travs de casos de usos, estos han
demostrado ser una buena forma de guiar el diseo, la implementacin y las pruebas. (Ver
Ilustracin 2).

16

Arquitecturas basadas en componentes.

La arquitectura basada en componentes enfoca sus bondades en su velocidad de

desarrollo, la abstraccin que le ofrece al desarrollador, su flexibilidad al cambio, y el re-uso de

componentes de software.

Modelar el software visualmente.

Modelar visualmente el software disminuye la ambigedad del diseo acercndose mejor

a los requerimientos del sistema, esto se debe a que es ms interpretable una solucin que ha
sido diseada grficamente. El modelado visual tambin muestra como encajan apropiadamente
los elementos del sistema y guardan consistencia entre s desde el diseo hasta la
implementacin. Por ultimo, promueve una comunicacin no ambigua en el equipo de desarrollo
traducindose en desarrollo rpido y ajustado a los requerimientos.

Verificacin de la Calidad del Software.

La verificacin de la calidad se realiza a travs de todo el proceso de desarrollo de

software, esta verificacin se realiza por medio de pruebas sucesivas. Las pruebas se concentran
en los aspectos de mayor riesgo. La verificacin constante de la calidad reduce los costos del
desarrollo ya que los problemas se detectan de manera temprana. Es importante tener siempre
en cuenta que la calidad es inherente al desarrollo.

Gestin del cambio

El cambio es la regla, debido a que el contexto en que se desarrolla software y las

necesidades que el software pretende cubrir son de naturaleza catica, el sistema debe cambiar
constantemente para adaptarse a la realidad de su entorno. Por lo tanto, los cambios hay que
monitorearlos para que no se vuelvan inmanejables.

2. Modelo de Arquitectura de 4+1 Vistas.

La arquitectura de software es usada en el Rational Unified Process como un artefacto
primario para conceptualizar, construir, gerenciar y hacer evolucionar un sistema en desarrollo

[PS61161999]. La arquitectura es un conjunto de componentes enlazados coherentemente para

satisfacer los principales requerimientos funcionales y no funcionales del sistema.
RUP esta basado en el celebre modelo de las 4+1 vistas, este esta definido en cinco partes
constitutivas y concurrentes: [PS61161999] [Kontio2005]

17

1) La Vista Lgica.
Esta vista comprende las abstracciones fundamentales del sistema a partir del dominio
del problema, es decir, es la vista que describe los requerimientos funcionales del sistema. La
vista lgica permite descomponer el problema para su anlisis.
2) La Vista de Proceso.
La vista de proceso es la vista que describe los procesos del sistema, en especial los
concurrentes. Esta vista toma en cuenta requerimientos no funcionales como disponibilidad,
desempeo, integridad y tolerancia a fallos.
3) La Vista de Implementacin.
La vista de implementacin representa la organizacin esttica de los mdulos en el
entorno de desarrollo. Los paquetes, subsistemas y libreras son considerados como mdulos.

Fig 1 Arquitectura de 4+1 Vistas

4) La Vista Implantacin.
La vista fsica es un mapeado del software sobre el hardware, es decir, esta vista describe
como la aplicacin es instalada y ejecutada en el hardware, tambin describe que recursos de
software necesita para ejecutarse. En esta vista se especifican como los elementos descritos en la
vista lgica, del proceso y desarrollo son mapeados en el hardware. Esta vista toma en cuenta
requerimientos no funcionales como disponibilidad, confiabilidad, desempeo y escalabilidad.

18

5) Vista de Casos de Uso.

El quinto elemento considera todos los anteriores en el contexto de casos de uso, es
decir, es la integracin de las otra cuatro vistas, por lo tanto es redundante. Sin embargo tiene
por finalidad ayudar a los analistas en la identificacin de los componentes arquitectnicos y
validar el diseo de la arquitectura.
El modelo 4+1 se percibe hoy como un intento de reformular una arquitectura estructural
y descriptiva en trminos de objeto y de UML.

3. Racional Unified Process; Fases e Iteraciones

RUP propone un marco de trabajo integrado por fases e iteraciones. Una iteracin puede
considerarse como un mini proyecto de software. El final de cada iteracin es una versin limitada
del producto final. Un conjunto de iteraciones forma una fase a la cual siempre se asocia un hito.
Un hito es un punto de evaluacin de procesos, cada hito esta constituido por un conjunto de
actividades que chequean los logros de la fase, y un conjunto de entregables que constituyen el
producto de la fase. (Ver Ilustracin 1) [RUP1999]
Las fases definidas por RUP son: Inicio o Concepcin, Elaboracin, Construccin, y
Transicin. (Ver Ilustracin 3). Las cuatro fases constituyen un ciclo de desarrollo que termina con
el lanzamiento de un sistema a produccin.

Fig 2 - Fases de RUP.

19

En la figura 2 se puede ver una representacin grfica de las fases e iteraciones

propuestas por RUP. En el eje horizontal se representa el tiempo y muestra los aspectos del ciclo
de vida del proceso, esta es la parte dinmica del proceso y est expresada en trminos de ciclos,
fases e iteraciones. En el eje vertical se representan los flujos de trabajo del proceso, los cuales
agrupan actividades de acuerdo a su naturaleza, esta es la parte esttica del proceso, debido a
que es descrito en trminos de componentes, actividades, flujos de trabajo, artefactos y roles.
RUP est basado en UML. UML es un lenguaje de especificacin que permite visualizar,
especificar, construir y documentar los modelos de un sistema. UML Permite definir todas las
decisiones de anlisis, diseo e implementacin, construyndose modelos precisos, no ambiguos y
completos.
Cuatro utilidades de los modelos UML:
9

Visualizar cmo es o queremos que sea el sistema.

Especificar la estructura y comportamiento del sistema.

Proporcionan plantillas que guan la construccin del sistema.

Documentan las decisiones.

El modelado es la parte esencial de todas las actividades que conducen a la produccin

de software de calidad, una empresa software con xito es aquella que produce de manera
consistente software de calidad, de all la relevancia de UML para RUP.

Fig 3 Fases e Hitos del RUP.

a. Fase de Inicio o Concepcin.
La fase de inicio es la primera fase del ciclo, en ella se define el alcance, objetivos, y
factibilidad del proyecto. Los objetivos claves de esta fase son entender la finalidad y los lmites
del proyecto, identificar las funcionalidades claves del sistema a desarrollar a travs de un
diagrama de casos de uso preliminar, determinar al menos una solucin posible, y determinar si
es factible el costo de la realizacin del proyecto. Los casos de uso son una expresin de los
requerimientos, pueden ser usados para modelar el negocio y proveer un contexto para el
desarrollo del sistema. [PS61161999]

20

Tabla 1: Descripcin de la Fase de Inicio.

Objetivos del Ciclo Acuerdo de los participantes acerca de la definicin del alcance, su costo
de Vida
inicial y el tiempo estimado
Acuerdo acerca de los requerimientos capturados y su entendimiento
Acuerdo acerca del costo y tiempo estimados, prioridades, riesgos y
procesos de desarrollo
Acuerdo acerca de los riesgos iniciales identificados y sus estrategias de
mitigacin
Artefactos
9
Documento Visin
9
Modelo de casos de uso inicial
9
Caso del negocio inicial
9
Evaluacin inicial de riesgos
9
Plan del proyecto
9
Plan de desarrollo de software
9
Glosario del proyecto
9
Modelo del dominio
9
Caso de desarrollo
b. Fase de Elaboracin.
La fase de elaboracin es la segunda fase de la metodologa RUP, esta define los
principales riesgos, construye una arquitectura esqueleto del sistema y refina el plan del proyecto.
La fase de elaboracin se enfoca en obtener una arquitectura de software estable que satisfaga
los requerimientos. La arquitectura de software es usada en el RUP como un paso primario para
conceptualizar, construir, gerenciar y hacer evolucionar el sistema en desarrollo. La arquitectura
de software no slo est relacionada con la estructura y el comportamiento, sino tambin con el
contexto del sistema; uso, funcionalidad, desempeo, re-uso, y restricciones tecnolgicas y
econmicas. [PS61161999]
La fase de elaboracin tiene mltiples iteraciones, el nmero de iteraciones que tenga
cada proyecto estar determinado por el cumplimiento de los hitos de evaluacin y la complejidad
del sistema a desarrollar. (Ver Figura 3)
Las actividades principales de la primera fase de elaboracin son:

Disear, implementar y probar un nmero pequeo de escenarios para identificar qu

tipo de arquitectura y mecanismos son necesarios para la aplicacin.

Identificar, implementar y probar un conjunto pequeo e inicial de mecanismos

arquitectnicos.

Realizar un diseo preliminar lgico de la base de datos.

Probar lo suficiente para validar que los riesgos arquitectnicos son mitigados. En las
siguientes iteraciones de elaboracin se realizan las siguientes actividades:

Corregir los errores de la primera iteracin.

Disear, implementar y probar los escenarios restantes que son significativos

arquitectnicamente.

21

Identificar e implementar la concurrencia, procesos, hilos y distribucin fsica.

Disear e implementar una base de datos preliminar.

Probar, validar y refinar la arquitectura

Tabla 2: Descripcin de la Fase de Elaboracin.

Arquitectura del
Estabilidad de la arquitectura.
ciclo de Vida
Enfoques apropiados para las pruebas y evaluaciones.
Principales elementos de riesgos direccionados y resueltos.
Fidelidad y detalle de los planes de iteracin para la fase de Construccin.
Estimaciones confiables que soporten los planes de iteracin para la fase
de Construccin.
Estabilidad de los requerimientos y la Visin.
Acuerdo de los participantes acerca de la Visin.
Anlisis de costos coherente.
Artefactos
9
Modelo de casos de uso refinado
9
Requerimientos complementarios
9
Descripcin de la arquitectura del software
9
Prototipo arquitectnico ejecutable
9
Lista revisada de riesgos
9
Caso del negocio revisado
9
Plan de desarrollo
9
Plan de pruebas y de integracin
9
Caso de desarrollo actualizado
9
Manual de usuario preliminar
c.

Fase de Construccin.
La fase de Construccin se enfoca en el diseo detallado, la implementacin y prueba del

software completo. El objetivo principal de la fase de construccin es desarrollar iterativamente un

producto completo que est listo para la transicin a la comunidad de usuarios. [PS61161999]
Esta fase esta determinada por dos pasos fundamentales la planificacin que est
principalmente conducida por los casos de uso que deberan ser implementados porque son ms
esenciales para los clientes o estn asociados con riesgos, y la implementacin donde se
identifican, disean e implementan los componentes necesarios para proveer la funcionalidad a
los casos de uso.
Tabla 3: Descripcin de la Fase de Construccin.
Capacidad
Madurez y estabilidad de la versin para entregarlo a los usuarios.
Operacional Inicial Disposicin de los interesados y dueos del sistema para la transicin.
Costos reales aceptables.
Artefactos
9
Producto de software integrado en la plataforma adecuada.
9
Manuales de usuario.
9
Descripcin del producto final.

22

d. Fase de Transicin.
El enfoque de la fase de Transicin es asegurar que el software est completamente
alineado con las necesidades de sus usuarios. El objetivo primordial de esta fase es entonar la
funcionalidad, su desempeo y la calidad en general, puede incluir correr sistemas nuevos y viejos
en paralelo, migrar datos, entrenar usuarios y ajustar procesos del negocio. [PS61161999]
Algunas de las tareas ms importantes para esta fase son:

Realizar pruebas Beta para validar que las expectativas de los usuarios estn cubiertas.

Entrenar a los usuarios y encargados del mantenimiento para lograr usuarios confiables.

Preparar el sitio de implantacin y convertir las bases de datos operacionales.

Tabla 4: Descripcin de la Fase de Transicin.

Liberacin del
Satisfaccin del usuario
Producto
Costos reales aceptables contra los presupuestados
Artefactos
9
Producto.
9
Plan de implantacin.
9
Plan de entrega.
9
Manual de instalacin.
9
Plan de gerencia de configuracin.
9
Plan de entrenamiento.

4. Racional Unified Process; Diagramas.

Los diagramas UML se realizan en las primeras fases del proceso de desarrollo y son
revisados y reformulados a travs de todo el proceso. Los diagramas permiten modelar el
problema y la solucin asociados al desarrollo. Existen muchos diagramas asociados a la
metodologa RUP, es pertinente indicar que el grupo de desarrollo deber escoger aquellos
diagramas que considere pertinentes. A continuacin se describen los diagramas que sern
desarrollados en el transcurso de este proyecto.
a. Modelo Conceptual.
El Modelo Conceptual es una representacin del dominio del problema, es decir,
representa al conjunto de conceptos que relacionados representan el problema planteado. Los
conceptos provienen del mundo real donde se planteo el problema. [PS61161999]
El diagrama conceptual es muy importante porque le permite al analista/programador tener una
visin grfica del problema, esto implica que tendr una mayor comprensin del dominio, y por lo
tanto, propondr una mejor solucin.

23

b. Modelo de Datos.
Un modelo de datos es un sistema formal y abstracto que permite describir los datos de
acuerdo con reglas y convenios predefinidos. Es formal pues los objetos del sistema se manipulan
siguiendo reglas perfectamente definidas y utilizando exclusivamente los operadores definidos en
el sistema, independientemente de lo que estos objetos y operadores puedan significar

[Ullman2004], es decir, Un modelo de datos es como una herramienta para especificar los tipos
de datos y la organizacin de los mismos.
El modelo entidad-relacin es un modelo de datos en el que es posible especificar
formalmente los datos de un sistema. El modelo entidad-relacin concibe los datos como un
conjunto de objetos o entidades que se relacionan entre s.
c.

Diagramas de Casos de Uso.

El diagrama de casos de uso representa una primera aproximacin al dominio de la solucin.

El diagrama de casos de uso representa la forma en como un cliente o actor opera con el sistema
en desarrollo, adems de la forma, tipo y orden en como los elementos interactan. El diagrama
de caso de uso representa todas las funcionalidades del sistema y quien tiene acceso a esas
funcionalidades. Es el documento ms importante para el proceso de desarrollo guiado por RUP, a
partir de l se materializan los requerimientos del cliente. Un diagrama de casos de uso consta de
los siguientes elementos: actores, casos de uso, relaciones de uso, herencia y comunicacin.

[UChile]
d. Extensin del Diagrama de Actividad de UML para modelado de Workflow.
En el documento Extending UML Activity Diagram for Workflow Modeling in Production
Sytems desarrollado por los profesores Ricardo M. Bastos y Duncan Dubugras A. Ruiz de la
Pontifcia Universidade Catlica do Ro Grande do Sul (Ver Anexo 1), se define una extensin del
diagrama de actividad de UML para representar flujos de trabajo (workflows). Debido a las
caractersticas del presente proyecto, donde los procesos de negocio son implementados
heredando de la filosofa del workflow, se decidi usar esta extensin para la representacin de
los procesos debido a que se consider que es la ms adecuada a las necesidades del proyecto,
se acopla perfectamente a la metodologa, y a las herramientas de desarrollo.
El diagrama de actividad tradicional se utiliza para modelar un caso e uso y el flujo de
eventos que ocurre dentro de l. El diagrama de actividad para flujos de trabajo (Workflow
Activity Diagram, WAD) describe un dominio de proceso, donde mltiples casos de uso esta
asociados a uno o ms flujos de proceso.
A continuacin de presenta una descripcin del modelo conceptual que explica como el
WAD funciona, en este modelo se muestra la relacin existente entre los conceptos que

24

intervienen en el diseo y definicin de flujos de procesos. La lista siguiente presenta

especficamente los conceptos del WAD y como se relacionan. (Ver Figura 4)
El dominio de problema posee de uno a muchos dominios de proceso.
Cada dominio de proceso dispara de cero a muchos eventos.
Cada dominio del proceso esta reglamentado por uno o muchas reglas de comportamiento.
Un dominio del proceso posee de uno a muchos procesos de negocio.
Un dominio del proceso posee de cero a muchas actividades empresariales.
Un proceso de negocio posee de una a muchas actividades empresariales.
Una actividad empresarial tiene de una a muchas operaciones funcionales.
Una operacin funcional es ejecutada por una o muchas entidades funcionales.
Una entidad funcional ejecuta de cero a muchas operaciones funcionales.
Una actividad empresarial requiere de cero a muchas capacidades funcionales.
Una entidad funcional provee de una a muchas capacidades funcionales, y una capacidad
funcional puede ser provista por una o muchas entidades funcionales.
Las Entidades Funcionales pueden ser humanas, software o maquinaria.
En el modelo conceptual del WAD previamente expuesto se presenta la instanciacin y
control de procesos (parte derecha figura 6), esto no es mas que la instanciacin,
implementacin y aplicabilidad de los conceptos desarrollados en el diseo del proceso.
Durante el proceso de investigacin de WAD se contact a los autores del documento para
consultarles sobre la ausencia de las excepciones en el planteamiento del diagrama, como
veremos mas adelante las excepciones son un componente importante de los procesos de
negocio. Los profesores sealaron que las excepciones se representan como indica UML2. Debido
a que la herramienta de modelado usada para este proyecto (Rational Rose Enterprise Edition
versin 2003.06.13) usa UML1 no es posible representar las excepciones en el flujo de los
procesos modelados. Sin embargo, en los modelos generados por el Oracle Process Manager se
representa claramente el manejo de excepciones.
Para una mayor comprensin del diagrama WAD remitirse al Anexo 1 donde se encuentra
el documento de donde fue extrada esta informacin, este documento es el basamento terico
para la realizacin de todos los diagramas WAD desarrollados en el presente proyecto.

25

Fig 4 Diagrama conceptual del WAD.

26

Captulo V Marco Terico.

En el siguiente marco terico se describe en detalle los conceptos bsicos o bases
tericas que se manejan a lo largo del presente informe de pasanta. Estos conceptos o bases
tericas, estn constituidos principalmente por las tecnologas y teoras que facilitan el desarrollo
de la solucin.
A continuacin se describe brevemente lo que constituye la integracin de sistemas,
profundizaremos en la integracin de procesos de negocio con flujos de informacin a travs de
Business Process Manager, Business Process Execution Lenguaje como la propuesta OASIS para
implementar Business Process Manager, los basamentos tericos y tcnicos de Business Process
Execution Language, y por ltimo la implementacin Oracle de Business Process Manager.

1. Integracin de Sistemas.
Organizaciones y personas que trabajan juntos necesitan que sus aplicaciones y servicios
trabajen juntos. La integracin de sistemas es la necesidad de negocios que surge en las
organizaciones que buscan a travs de la automatizacin de procesos y la conectividad la
optimizacin de procesos de negocio, ofrecer servicios de manera masiva a bajo costo, crear un
cerrado vnculo con los clientes, generar mayor penetracin en el mercado y crecer en sus
relaciones de negocios. La integracin es ms que una actividad simple de unir partes; la
integracin debe permitir que esas partes se unan de forma coherente.
La falta de integracin entre los sistemas de informacin castiga directamente la
productividad, rapidez y eficiencia de los procesos de negocio, por ello las organizaciones
persiguen integrar sus aplicaciones y procesos de negocios a travs de estndares de
comunicacin con sus unidades constitutivas y socios de negocio. Lograr los niveles de integracin
deseados suele tener un alto grado de complejidad. Las organizaciones, al pretender participar en
el nuevo mundo de la interconexin, deben enfrentar la dificultad de manejar una amplia
diversidad de tecnologas y aplicaciones heterogneas, lo cual ha demostrado ser difcil y costoso.
(Ver Ilustracin 3)
Existen muchos niveles de integracin posibles entre los sistemas de una organizacin, la
integracin de procesos es uno de esos niveles. La integracin de procesos implica tener un
modelo bien definido de los procesos de negocio donde se define la participacin de personas y
sistemas de software, la interaccin e integracin de la informacin, y las reglas establecidas por
el negocio. Los sistemas de software participantes en una integracin de procesos de negocio

27

deben acoplarse de forma tal que sean independientes a pesar que coexistan en un flujo de
proceso y que compartan un flujo de informacin.

2. Flujo de Trabajo (Workflow).

Workflow es una tecnologa de informacin que utiliza sistemas electrnicos para manejar
y para supervisar procesos del negocio, permitiendo el seguimiento del flujo de trabajo entre
individuos y entidades funcionales. La finalidad principal del workflow es ayudar en la
automatizacin de tareas de negocio y enrutar electrnicamente la informacin correcta a las
personas indicadas en el momento indicado. Una de caractersticas mas resaltantes de los flujos
de trabajo es que su monitoreo es inherente a su definicin, este es su valor agregado.

[Wikipedia] [Allen]
Formalmente la Workflow Management Coalition define los flujos de trabajo como:

La automatizacin de procesos de negocio, en su totalidad o en parte, durante el cual

documentos, informacin o tareas son pasadas de un participante a otro para realizar una
accin, de acuerdo a una serie de reglas procedimentales
Para la implementacin de flujos de trabajo se estudian los aspectos operacionales de
una actividad de trabajo: cmo se estructuran las tareas, cmo se realizan, cul es su orden
correlativo, cmo se sincronizan, cmo fluye la informacin que soporta las tareas y cmo se le
hace seguimiento al cumplimiento de las tareas. Los flujos de trabajo son muy importantes para la
implementacin de trabajo colaborativos.

3. Business Process Manager (BPM).

La integracin de procesos de negocio no es nada trivial, la misma naturaleza divergente
de los procesos internos de una organizacin, su complejidad, la diferente informacin que cada
proceso maneja y la misma definicin del modelo del proceso hace que integrar los procesos
necesite una plataforma terica y tecnolgica potente y robusta para soportar la integracin. Ms
all de la integracin de procesos, existen varios aspectos a considerar cuando se habla de
procesos de negocio, como lo son eficiencia, eficacia, pertinencia, relevancia y control. Un negocio
exitoso esta construido sobre una fundacin de procesos que alinean recursos para conseguir
metas empresariales. Los procesos de negocio definen la identidad de una empresa, sin embargo,
hay empresas que no tiene un buen entendimiento de sus procesos de negocio o control sobre
ellos. Las organizaciones que no tienen bien controlados sus procesos de negocio impiden su
propio xito, debido a que sus procesos estn plagados de redundancia, errores, e ineficiencias.
Una propuesta coherente que apoya la implementacin ptima de procesos de negocio es
el Business Process Management (BPM). BPM es un modelo de trabajo para modelar, integrar,

28

monitorear y optimizar todas las partes de un proceso de negocio, controlando y haciendo visible
de principio a fin las transacciones constitutivas del proceso.
BPM tiene cuatro caractersticas fundamentales:
9

Modelar: Definir y construir de forma grfica la representacin de los procesos de

negocios de su empresa. (Reglas de Negocios, Procesamiento paralelo, Excepciones, SubProcesos)

Integrar: Conectar los procesos a fin de intercambiar informacin que apoyen la toma de
decisiones del negocio.

Monitorear: Visualizar de forma grafica a travs de una consola los procesos que se
encuentran en progreso as como los casos particulares de cada proceso.

Optimizar: Analizar partiendo del monitoreo de procesos, aquellos que son ineficientes y
ejecutar cambios al proceso en real-time para lograr procesos ms eficaces.
Mediante una solucin BPM se puede modelar un proceso de principio a fin, generar la

integracin necesaria entre los sistemas que el proceso de negocio cruza, posee manejo de
excepciones y procesos alternativos, monitorear el ciclo de vida completo del proceso, y cambiar
el proceso para agregar eficiencia.
Las soluciones BPM estn diseadas para solventar la desconexin que ocurre entre la
gerencia y el departamento de tecnologa de una compaa, la alta gerencia toma decisiones que
dependen del ritmo del mercado y el departamento encargado de la tecnologa de la informacin
debe desarrollar una solucin para ejecutar ese nuevo proceso de negocio que requiere la
gerencia. BPM captura como las decisiones son implementadas, gua la toma de decisiones, y
provee la abstraccin necesaria para desarrollar la mejor aplicacin para que se realice el trabajo.
Cuando la gerencia se mueve para capturar una oportunidad de negocio, el departamento de
tecnologa tendr el vehculo listo para llevar a la compaa hacia esa oportunidad. Esto se
traduce en una empresa mucho ms gil.
Con una solucin BPM, los desarrolladores puede re-usar modelos de procesos y
modificar los existentes para implementar un nuevo servicio, esto ahorra los costos en desarrollo,
entrenamiento y mantenimiento.
Adicionalmente una solucin BPM impulsa la eficiencia de los empleados de una empresa.
A travs de BPM se pueden automatizar tareas del proceso de negocio agilizndolas. Cuando los
procesos estn automatizados se gana en precisin y tiempo. Cuando tareas simples estn
automatizadas los empleados pueden concentrase en tareas ms complicadas y de mayor valor.
Las empresas pueden inteligentemente guiar los procesos hacia la gente indicada con las
habilidades adecuadas en el momento preciso.BPM ofrece beneficios extraordinarios entre ellos:

29

Aumento de la Productividad a fin de reducir costos.

Mejoramiento en los Servicios a los Clientes.

Capacidad de modificar los procesos de negocios.

Reduccin del tiempo de los ciclos de produccin.

Reduccin de los errores y por lo tanto el re-trabajo.

Menor tiempo dedicado a actividades de administracin y gastos generales.

Las caractersticas que toda solucin BPM son: [Hurwitz2001]

Automatizacin de procesos unificados y modelos de flujo de trabajo.
Los procesos de negocio necesitan que las aplicaciones y las actividades humanas estn
combinadas, el modelo de proceso debe integrar a sistemas y personas como uno solo.
Ejecucin y manipulacin directa del proceso.
Los procesos de negocio deben tener la integracin de cdigo suficiente como para lograr la
integracin entre aplicaciones y personas dentro del ambiente del sistema organizacional, esto
implica mecanismos de adaptacin entre las distintas aplicaciones participantes, una robusta
plataforma de comunicacin, y posibilidades de desplegar interfaces apropiadas a los participantes
del proceso. El modelo del proceso debe ser independiente de la arquitectura, para que los
cambios en esta no afecten la lgica de integracin entre los componentes del proceso.
Manejo de Estados.
Las soluciones BPM deben mantener el registro del estado de todos los procesos sin importar
su complejidad o estado actual, esto permite tomar decisiones de negocio al momento y
mantener un histrico para futuros anlisis y cambios del proceso. Las decisiones de negocio se
deben basar en la informacin que refleja como los procesos de negocio se estn desempeando
en cualquier momento en cualquier punto del proceso.
Manejo de Excepciones.
Las excepciones en los procesos de negocio son muy comunes, el entorno catico donde se
desarrolla el negocio hace necesario que los procesos de negocio estn bien definidos para las
excepciones, la finalidad es que el proceso se pueda adaptar a los rpidos cambios que ocurren
en el entorno. La excepcin ms comn es de tiempo en la que el proceso se puede retrasar por
infinidad de razones. Estas excepciones deben ser manejadas para que el flujo de proceso quede
caducado o intil ante un cambio de situacin, esto automticamente aumenta la productividad y
baja los costos ya que las excepciones estn consideradas dentro del modelo.

30

 Monitoreo y Anlisis Robusto del Proceso.

El monitoreo de los procesos de negocio es crucial para lograr la mayor eficiencia operacional.
Las soluciones BPM representan un activo importante para la empresa ya que a travs del
monitoreo de los procesos es posible tener una radiografa de la organizacin en todo momento y
a partir de esto tomar las decisiones para la mejora del negocio, y estas decisiones dependen de
la habilidad de los procesos para adaptarse a estos cambios.
Modelo de Soporte Anidado.
Los procesos generalmente estn constituidos por sub-procesos, por lo tanto una solucin
BPM debe soportar la reutilizacin de sub-procesos. Esto proporciona un mayor control granular
sobre los procesos y abstraccin.
Soporte de Modelo Concurrente.
Los procesos de negocio generalmente desencadenan ms de un evento de negocio, por lo
tanto una solucin BPM debe soportar concurrencia y paralelismo. Los flujos paralelos deben tener
la capacidad de ejecutarse independientemente pero al mismo tiempo deben de poder
componerse para el caso en que varios flujos paralelos preceden a un nico evento de negocio.
Este paralelismo permite que los desarrolladores representen fielmente las condiciones complejas
del proceso de negocio.
Basados en Estndares.
Debido a que el BPM interacta con todos los aspectos del ambiente computacional de la
organizacin este tiene que estar basado en estndares, y ser lo suficientemente abierto como
para acoplarse con los estndares emergentes que puedan ser adoptados por la organizacin en
un futuro.
Alta Escalabilidad.
En un ambiente complejo una solucin BPM podra manejar muchas instancias de
proceso en distintos estados de distintos procesos y sub-procesos, por lo tanto, la solucin BPM
debe tener la capacidad de escalar para manejar todo el procesamiento que esto implica. La
solucin BPM debe tener la capacidad de escalar horizontalmente para manejar procesos que se
extienden mucho en el tiempo y verticalmente para soportar mltiples procesos corriendo
concurrentemente.

31

 Alta Confiabilidad.
Debido a que BPM es estratgico, BPM deben recuperarse de las fallas, debe asegurar la
integridad de las transacciones, y debe asegurar que si ocurre cualquier fallo la integridad del
flujo del proceso y la informacin relacionada permanece intacta.
Una solucin BPM que cumpla con las anteriores caractersticas garantiza modelado,
entendimiento, integracin, automatizacin, manejo, y optimizacin de sus procesos de negocio,
es decir, la receta del xito del negocio; eficiencia tctica, efectividad y seguridad estratgica para
una organizacin optimizada y experta.

4. Business Process Execution Language for Web Services (BPEL).

En la teora anteriormente expuesta de BPM falta un aspecto esencial; La plataforma
tecnolgica mediante la cual se implemente una solucin BPM debe tener caractersticas muy
especficas para satisfacer la definicin de BPM.
Business Process Excecution Lenguaje para Web Services es una robusta solucin BPM
que fue definido como un estndar certificado por el grupo Oasis (http://www.oasis-open.org).
Oasis es un reconocido consorcio sin fines de lucro que se encarga de conducir, desarrollar y
promover nuevas tecnologas para los negocios electrnicos. Oasis ofrece a BPEL como la mejor
opcin para satisfacer los requerimientos del mundo real.
BPEL es un estndar de la industria para la orquestacin y definicin de procesos de
negocios. Desde un punto de vista tcnico BPEL es un lenguaje estndar que habilita el envi de
mensajes XML a servicios remotos, la manipulacin de las estructuras de datos XML, la recepcin
de mensajes sincrnicos y asincrnicos desde servicios remotos, la administracin de eventos,
manejo de excepciones, la definicin de secuencias paralelas de ejecucin y deshacer la accin de
los procesos cuando es detectada una excepcin. Estos son los componentes necesarios para
lograr componer un grupo de servicios en procesos de negocio colaborativos y transaccionales.

[Oracle2004]
Constitucin del Estndar BPEL:

32

Web Services/WSDL como modelo de componentes.

XML como modelo de datos.

Patrones de intercambio de mensajes sncronos y asncronos.

Coordinacin de flujo determinstico y no determinstico.

Manejo de excepciones.

BPEL define la creacin, publicacin, manejo y orquestacin de Web Services, y

automatiza la integracin de los servicios existentes. BPEL es el primer estndar para el manejo
de procesos de negocio. La unin de BPEL y los estndares de los Web Services permiten disear
un patrn dbilmente acoplado y robustamente engranado que permite una implementacin
eficiente de una arquitectura SOA para la definicin de procesos de negocio.
BPEL es el lenguaje para la definicin de procesos y flujo de trabajos ms maduro hasta
la fecha, define todas las utilidades necesarias para implementar complejos flujos de trabajo.
BPEL tiene un soporte robusto para el manejo de excepciones a tiempo de diseo y tiempo de
corrida, ofrece soporte en el manejo de las notificaciones y deteccin de eventos en el flujo del
proceso permitiendo la implementacin de flujos no determinsticos de trabajo, y por ultimo
incluye un mecanismo de compensacin para la implementacin de transacciones que toman
mucho tiempo inclusive cuando los servicios componentes no usen un protocolo transaccional
comn.
En la tabla siguiente se muestra comparativamente como BPEL encaja perfectamente en
la definicin de BPM.
Tabla 5: Tabla Comparativa entre BPM y BPEL.
Caracterstica BPM
BPEL
Automatizacin de procesos BPEL ofrece toda la riqueza conceptual de los flujos de trabajo
unificados y modelos de flujo de tradicionales mas la integracin total de los procesos humanos y
trabajo.
computacionales.
Ejecucin
y
manipulacin Las caractersticas tecnolgicas de BPM para la comunicacin,
directa del proceso.
ejecucin y despliegue de aplicaciones estn cubiertas por BPEL
gracias a las tecnologas que constituyen el esqueleto de BPEL.
Manejo de Estados.
BPEL maneja mltiples estados para los procesos
Maneo de Excepciones.
BPEL hace especial nfasis en el manejo de excepciones
Monitoreo y Anlisis Robusto BPEL ofrece monitorio del proceso desde el principio hasta el
del Proceso.
final sin importar su estado de ejecucin y maneja indicadores
de gestin que ofrecen estadsticas asociadas al proceso
propicias para tareas de anlisis.
Modelo de Soporte Anidado.
BPEL soporta el manejo de sub-procesos y el uso extensivo de
estos en mltiples procesos.
Soporte de Modelo Concurrente BPEL permite construir flujos de procesos concurrentes.
Basados en Estndares.
Las tecnologas constituyentes de BPEL representan estndares
de desarrollo bien establecidos.
Alta Escalabilidad.
Estas caractersticas son propias de cada implementacin del
servidor de BPEL, mas adelante veremos que el Oracle BPEL
Alta Confiabilidad.
Server puede escalar horizontal y verticalmente sin problemas y
es altamente confiable.

33

5. Oracle BPEL Process Manager.

Consecuentemente con las necesidades y nuevas tendencias para soluciones de
integracin. Oracle introduce una robusta y completa solucin para la integracin de sistemas
denominada OracleAS Integration. [Oracle2004]
OracleAS Integration esta desarrollado bajo las especificaciones J2EE y utiliza como
infraestructura al servidor de aplicaciones proporcionando un alto rendimiento y escalabilidad.
Esta Solucin Oracle ofrece satisfacer todas las necesidades, requerimientos y especificaciones del
entorno empresarial actual ofreciendo BPEL Process Manager dentro de su conjunto de soluciones
empresariales para la implementacin de procesos de negocio a travs de BPEL.
Oracle BPEL Process Manager proporciona a las organizaciones la posibilidad de modelar
y desarrollar procesos de negocios basados en Business Process Execution Lenguaje para Web
Services (BPEL). El estndar BPEL proporciona una gua para la reduccin de costos y complejidad
de los proyectos de integracin agregando un valor estratgico a la organizacin. Oracle BPEL
Process Manager ofrece la portabilidad de los procesos y una solucin probada, robusta y
confiable basada en el estndar de orquestacin BPEL.

Fig 5 -. Arquitectura de OracleAS BPEL Process Manager

Implementar y manejar la orquestacin lgica de aplicaciones orientadas al servicio
implica varios requerimientos no triviales. A continuacin se presentan algunos de estos
requerimientos y como Oracle BPEL Process Manager los solventa.

34

 Estndares abiertos.
Oracle BPEL Process Manager esta construido sobre los estndares que soporta a los Web
Services ofreciendo a las aplicaciones y procesos de negocio toda la interoperabilidad y
portabilidad caracterstica de los servicios Web.
Escalabilidad y Confiabilidad.
Oracle BPEL Process Manager puede manejar un volumen incremental de transacciones.
Una instancia de un proceso BPEL puede ser re-localizada fcilmente en un servidor distinto al de
su creacin, inclusive durante su ejecucin.
Manejo, Administracin y Visibilidad del Negocio.
Oracle BPEL Process Manager incluye capacidades de administracin y manejo,
soportando el desarrollo de vistas del proceso y estadsticas del proceso.
Control de Versiones.
Oracle BPEL Process Manager permite mejorar o adaptar la lgica del flujo de proceso
para nuevas instancias de este, mientras las instancias existentes siguen la lgica del proceso
vigente para el momento de su creacin.
Auditoria.
Oracle BPEL Process Manager mantiene automticamente informacin de auditoria del
flujo de trabajo, soportando una representacin grfica y textual de la historia y estado del
proceso, esta informacin de auditoria puede ser personalizada para que sea relevante a la
semntica del proceso
Adems de estas caractersticas Oracle BPEL Process Manager ofrece cdigo Java
embebido en el proceso BPEL, servicio

de mensajera de correo-e y JMS, servicio de

transformacin XSLT y XQuery, integracin de tareas del flujo de trabajo con portales, y un marco
de trabajo WSIF asociado.
El Oracle BPEL Process Manager esta constituido por el JDeveloper BPEL Designer, el
Oracle BPEL Console y el BPEL Server.
a. Oracle JDeveloper BPEL Designer.
JDeveloper BPEL Designer extiende sus funcionalidades tradicionales para ofrecer
funcionalidades de modelado, edicin y diseo de procesos BPEL. Las principales caractersticas
de esta herramienta son el soporte nativo BPEL, modelado de procesos arrastra y suelta (drag

35

and drop), servicio de browser UDDI y WSIL, editor XPath, y construccin-publicacin con un
click.
b. Oracle BPEL Console.
Oracle BPEL Console permite un rico manejo de procesos BPEL publicados en el servidor
BPEL, permite el manejo de versiones, el manejo de las instancias del proceso en el momento de
corrida, capacidades avanzadas para el debugging y administracin, pruebas de stress,
publicacin y monitoreo. Mediante el BPEL Console de Oracle es posible obtener la informacin de
auditoria e historia del proceso. Las caractersticas ms resaltantes del Oracle BPEL Console son el
monitoreo visual, auditoria, debugging, administracin de los procesos mientras corren, y
estadsticas del desempeo de los procesos.
c.

Oracle BPEL Server.

Oracle BPEL Server es una implementacin robusta y escalable de un servidor BPEL, este

descansa en un J2EE Application Server. Los atributos que destacan del Oracle BPEL Server son el
context dehydration, manejo avanzado de las excepciones, mensajeria sincrona y asncrona, y
manejo de versiones.

6. Definicin de los Conceptos Asociados a BPEL

a. Arquitectura SOA (Service Oriented Architecture).
SOA es un estilo arquitectnico cuya meta es lograr una interaccin dbilmente acoplada
entre componentes de software que colaboran entre s. El concepto mas ntimamente ligado a
SOA es el de servicio, un servicio es una unidad del trabajo ofrecida por un servidor cuya finalidad
es alcanzar los resultados deseados por un cliente. [He2003]
SOA logra una arquitectura dbilmente acoplada por medio de dos premisas:
1.

Un pequeo grupo de interfaces simples y adecuadas a todos los componentes del

software que participan. Las interfaces deben estar universalmente disponibles para
todos los abastecedores y consumidores.

2.

Mensajes descriptivos entregado a travs de las interfaces, restringidos por un esquema

extensible. Un esquema limita el vocabulario y la estructura de los mensajes, y permite
que las nuevas versiones de servicios sean introducidas sin que los servicios existentes
sufran por el nuevo protocolo.
La mejor forma de realizar una integracin que sea flexible ante los cambios constantes

de las reglas de negocio es adaptar la infraestructura de tecnologa de la informacin a una

arquitectura basada en servicios (SOA). Los servicios permiten una alta modularidad para la

36

conformacin de sistemas de negocio, su carcter independiente permite agregar, eliminar o

modificar servicios para adaptarlos a la realidad cambiante del negocio sin que esto tenga un
impacto estresante en el normal funcionamiento del negocio o los sistemas. Los servicios ofrecen
un menor costo ante el cambio ya que permite integrar elementos de mltiples tecnologas,
permiten un menor tiempo de desarrollo y menor costo para soluciones de sistemas de negocio.
Por lo tanto, los servicios ofrecen alta adaptabilidad al medio catico en que se desarrollan
procesos de negocio con un mejor diferencial costo-beneficio.
La Arquitectura SOA permite coordinar y manejar procesos de negocio, esta arquitectura
ofrece herramientas y servicios comunes para cubrir las necesidades de integracin de las
organizaciones actuales, esto implica integrar flujos de negocio que van ms all de los lmites de
la propia organizacin. En una organizacin en la que los sistemas de informacin estn basados
en una arquitectura de servicios pueden definirse servicios re-usables para todos los sistemas de
informacin implementados, esto implica menor costo y menor tiempo de desarrollo.
b. Web Services.
El trmino Web Service se refiere a un grupo de estndares de interoperabilidad que
simplifica la integracin con sistemas heterogneos. Los Web Services estn basados en el
estndar WSDL para describir las interfaces y los detalles del servicio, y el estndar XML como
modelo de datos. Estas caractersticas le dan a los Web Services la suficiente flexibilidad para
soportar casi cualquier protocolo. Los servicios Web permiten crear una plataforma distribuida que
permite la cooperacin simple y confiable de sistemas heterogneos.
Los servicios Web se publican, orquestan, implementan y ejecutan.
Para que un servicio Web este disponible en un servidor este debe ser previamente
publicado, un servicio publicado se puede considerar como un bloque lgico que recibe un
mensaje de peticin XML, hace un procesamiento y genera un grupo de mensajes de repuesta
XML. Publicar significa poner el servicio disponible a travs de una interfaz estndar, al publicar
un servicio se toma una pieza funcional existente y se pone disponible en una red para que pueda
ser fcilmente integrado a una aplicacin.
Para que un servicio pase a ser una unidad lgica en una aplicacin este debe orquestarse en la
aplicacin, orquestar significa integrar y coordinar estos servicios en una aplicacin de negocio
manejable.
La implementacin, ejecucin y manejo de la lgica de orquestacin son los pasos ms
complejos a la hora de utilizar Web Services en una solucin empresarial.
Conceptos asociados a los Web Services: [Webopedia]

37

WSDL (Web Service Description Language): Lenguaje utilizado para describir los Web
Services como una coleccin de bloques de comunicacin capaces de intercambiar
mensajes. WSDL es una parte integral de UDDI.

UDDI (Universal Descriptor, Discovery and Integration): Es un directorio distribuido que

permite que los servicios se publiquen en la Web y que, a su vez, los servicios se
encuentren entre s.

XML (Extensible Markup Language): XML es un lenguaje de definicin de datos derivado

de SGML. Fue creado para permitirle a los desarrolladores Web personalizar las etiquetas
de sus aplicaciones, XML permite la definicin, transmisin, validacin, e interpretacin
de data contenida en mensajes intercambiables entre aplicaciones. XML posee todas las
virtudes del HTML pero sin sus limitaciones, XML es adaptable, mantenible, relacional,
simple, y portable.

7. Jakarta Struts.
Con la finalidad de proveer una interfaz amigable para la interaccin con los procesos
BPEL se decidi usar el marco de trabajo Struts por ser estndar y acorde con la forma de
invocacin ofrecido por BPEL a travs de libreras Java.
Struts es un marco de trabajo que implementa el patrn de arquitectura Model View
Controller en Java. El patrn de arquitectura MVC es un patrn que define la organizacin
independiente del Modelo (Objetos de Negocio), la Vista (interfaz con el usuario u otro sistema) y
el Controlador (controlador del workflow de la aplicacin). (Ver Ilustracin 8) [Struts]
Struts esta especialmente orientado hacia el desarrollo de aplicaciones Web. Struts
funciona de la siguiente manera; el cliente accede al navegador y genera una solicitud que es
atendida por el Controlador, este analiza la solicitud y llama a un ejecutable .Java denominado
accin que procesa la peticin, este utiliza los objetos de negocio para concretar la tarea. Segn
el resultado que retorne la accin, el controlador derivar la generacin de interfaz a uno o ms
JSPs, los cuales podrn consultar los objetos del modelo a fines de realizar su tarea.
La comunicacin que se establece entre el cliente y la vista de la aplicacin se establece a
travs de la Web con la arquitectura estndar de cliente/servidor. Struts esta orientado a este tipo
de arquitectura donde el proceso se reparte entre los clientes y el servidor, los clientes son
aquellos que requieren un servicio y el servidor es aquel que las atiende. La comunicacin entre
cliente y servidor se establece gracias a componentes de hardware y software que permiten el
envo de mensajes y su gestin.
Struts simplifica notablemente la implementacin de una arquitectura cliente/servidor
basado en el patrn MVC. El mismo separa muy bien lo que es la gestin del workflow de la
aplicacin, del modelo de objetos de negocio y de la generacin de interfaces.

38

El controlador ya se encuentra implementado por Struts, aunque si fuera necesario se

puede heredar y ampliar o modificar. Las acciones que se ejecutarn sobre el modelo de objetos
de negocio se implementan basndose en clases predefinidas, se implementan en lenguaje Java y
en ella se pueden llamar cualquier librera Java valida (para este proyecto en particular las
libreras de manejo de procesos BPEL). La generacin de interfaz se soporta mediante un
conjunto de etiquetas (tags) predefinidas por Struts, lo cual genera ventajas de mantenimiento y
de desempeo.
Struts separa claramente el desarrollo de interfaz del workflow y lgica de negocio
permitiendo desarrollar ambas en paralelo o con personal especializado.

39

Captulo VI Desarrollo del Sistema.

En el presente captulo se expone la totalidad del proceso de desarrollo realizado para la
implementacin de una solucin viable a las necesidades presentadas por Develcom Soluciones e
Informtica. El proceso de desarrollo fue guiado por el marco metodolgico y fomentado por el
marco terico anteriormente expuesto.

1. Fase de Inicio
La fase de inicio de este proyecto hay una sola iteracin, en ella se realizo el
levantamiento y anlisis de requerimientos, el modelo conceptual del sistema, el diagrama de
casos de uso inicial, la lista de riesgos y el plan de proyecto.
a. Requerimientos Funcionales.
Los requerimientos funcionales definen las funciones que el sistema ser capaz de realizar.
Una funcionalidad describe las transformaciones que el sistema realiza sobre las entradas para
producir salidas.
Los requerimientos funcionales se obtuvieron a travs de un proceso de anlisis de las
necesidades de la empresa, la informacin necesaria se obtuvo a travs de entrevistas sucesivas a
los involucrados del proceso y mltiples feedbacks ante los anlisis preliminares de las
necesidades de la empresa.
En general Develcom Soluciones e Informtica requiere la automatizacin de algunos de sus
procesos de Recursos Humanos, su monitoreo y gestin. A continuacin se presenta una lista de
requerimientos donde se especifica las necesidades que el software debe cubrir. (Ver Apndice 1)
Lista de Requerimientos:
Req1: Capturar, Analizar y Procesar Solicitudes de Procesos de RRHH.
Req1.1: Capturar, Analizar y Procesar Solicitudes de Adelanto de Prestaciones.
Req1.2: Capturar, Analizar y Procesar Reclutamiento de Personal.
Req1.3: Capturar, Analizar y Procesar Relaciones de Gasto.
Req1.4: Procesamiento de Solicitud de Constancia de Trabajo.
Req1.5: Capturar, Analizar y Procesar Solicitudes de Cursos de Capacitacin.
Req1.6: Capturar, Analizar y Procesar Solicitudes de Prstamo.
Req1.7: Capturar, Analizar y Procesar Solicitudes de Vacaciones.
Req2: Monitorear Procesos de RRHH.

40

Req3: Generar Reportes sobre los Procesos de RRHH.

Req4: Gerenciar el Sistema.
b. Requerimientos no Funcionales.
Los requerimientos no funcionales del sistema se refieren a las caractersticas de
desempeo y calidad que debe tener el software. Los requerimientos no funcionales dependen
directamente de las necesidades que el software pretenda cubrir, el costo del desarrollo, y el
tiempo de desarrollo. Existen algunas caractersticas que son cubiertas por la tecnologa que
soporta el desarrollo, y otras deben ser garantizadas por el analista/programador. A continuacin
se presenta la lista de requerimientos del sistema, esta fue basada en la notacin estndar
propuesta por ISO 9126. (Ver Ilustracin 5, y Apndice 2) [ISO1991]
Lista de Requerimientos no Funcionales:
Req.5: Requerimientos de Funcionalidad.
Req.6: Requerimientos de Fiabilidad.
Req.7: Requerimientos de Usabilidad.
Req.8: Requerimientos de Eficiencia.
Req.9: Requerimientos de Mantenibilidad.
Req.10: Requerimientos de Portabilidad.
c.

Definicin de Actores.

Tabla 6: Descripcin de Actores y sus Responsabilidades.

Nombre
Descripcin
Responsabilidades
Empleado
Persona empleada o contratada por Generar Solicitudes a procesos de RRHH,
Develcom Soluciones e Informtica Cumplir tareas relativas a los procesos
C.A
de RRHH
Supervisor
Es un empleado que tiene a su cargo Aprobar Solicitudes a procesos de RRHH
uno o ms empleados.
realizados por sus subalternos.
Gerente
Es un supervisor de supervisores de su Aprobar Solicitudes a procesos de RRHH
rea.
realizados por los supervisores de su
rea y los empleados subalternos de
estos.
Ente RRHH
Es un ente que es responsable de los Realizar tareas de anlisis, diseo,
procesos de RRHH de la empresa.
aprobacin y monitoreo de los procesos
de RRHH implementados por el sistema.
Ente
Es un ente que es responsable de los Realizar tareas de pago generados por
Administrativo procesos de administrativos de la los procesos de RRHH implementados
empresa.
por el sistema.
Ente Legal
Es un ente que es responsable de los Realizar tareas legales generadas por los
procesos de legales de la empresa.
procesos de RRHH implementados por el
sistema.
Administrador Es un empleado que se encarga de la Es el responsable del mantenimiento del
del Sistema
administracin del sistema.
sistema.

41

A partir del anlisis de los requerimientos se definieron los actores que interactuarn con
el sistema. Este anlisis defini roles que tendrn acceso a funcionalidades especificas del
software. Los actores definidos fueron; Empleado, Supervisor, Gerente, Ente RRHH, Ente
Administrativo, Ente Legal y Administrador del Sistema. En la tabla 6 se especifica la descripcin
de cada actor y sus responsabilidades para con el sistema.
En la figura 6 se presenta un diagrama ilustrativo de cmo los actores heredan los roles
entre s, esto es importante ya que la herencia de cada actor determinara las funcionalidades a las
que tendr acceso en el sistema, los usuarios y su participacin en los procesos de Recursos
Humanos.

Empleado

Administ rador del

Sistema

Ente RRHH

Supervisor

Ente Legal

Ente Adminis trativo

Gerente

Fig 6 Diagrama de Actores

d.

Lista de Riesgos.
La Lista de Riesgos sirve para conservar visibles los riesgos que pueden atentar contra la

finalizacin del proyecto. Esta lista es utilizada como una base para la planificacin del proyecto.
Un riesgo puede ser visto como una variable del proyecto que puede tomar un valor que
perjudique o elimine la posibilidad de xito de un proyecto. [PS61161999]
Lista de Riesgos:
Risk.1 No contar con los recursos tcnicos para desarrollar a tiempo el sistema.
Risk.2 Cambio de nuevas versiones de las herramientas asociadas a ORACLE BPEL.
Risk.3 Inexperiencia relativa al uso de BPEL como tecnologa de desarrollo.
Risk.4 El sistema no es apropiadamente probado en cada iteracin.
Risk.5 Crecimiento incontrolado de los requerimientos del usuario.

42

e. Glosarios del Sistema.

Candidatos: Son los posibles postulados a un cargo.
Comentarios: Son comentarios o notas relativas al flujo de un proceso de RRHH, los
comentarios pueden contener impresiones del responsable de una tarea, son incremntales y
tienen varios autores (tantos autores como participantes del proceso).
Documentos: Son documentos generados o asociados por procesos de RRHH. Ej. Contratos.
Notificaciones: Son mensajes que se realizan a los interesados del proceso, Ej. Solicitantes o
candidatos.
Solicitante: Es cualquier empleado que inicie un proceso de RRHH.
Solicitud: Se refiere a cualquier proceso de RRHH que necesite ser iniciado por un solicitante.
Tarea: Actividad que debe ser realizada por un empleado a travs del sistema.
f.

Modelo Conceptual del Sistema.

El modelo conceptual a continuacin representa el dominio del problema.
La interpretacin del diagrama conceptual es la siguiente: Los procesos de Recursos

Humanos estn constituidos por mltiples tareas, dichas tareas se rigen por reglas de negocio que
determinan el momento en que debe ser realizada una determinada tarea, por quien debe ser
realizada y bajo que lnea de flujo de trabajo. Los empleados realizan las tareas e inician los
procesos de recursos humanos, un empleado puede pertenecer a cualquiera de los siguientes
grupos de empleados; Ente Legal, Ente RRHH, o Ente Administrativo. Los empleados pueden ser
simplemente empleados, supervisores o gerentes, los gerentes y supervisores tienen a su cargo al
menos un empleado. Los roles y grupos son importantes para que las reglas de negocio
determinen la pertinencia de un empleado en una tarea. Los procesos de Recursos humanos
pueden ser de Vacaciones, Prstamo, Prestaciones, Constancia de trabajo, Relaciones de Gasto,
Personal, o Cursos de Capacitacin.

43

Fig 7 Diagrama Conceptual.

g. Modelo Inicial de Casos de Uso.
Partiendo de los requerimientos obtenidos de los usuarios finales, se dise un diagrama
inicial de casos de uso. Este diagrama establece un primer acercamiento a la solucin requerida
por Develcom Soluciones e Informtica. Este diagrama fue analizado y reformulado, hasta obtener
una versin refinada y adaptada a las necesidades de la empresa.
A continuacin en la tabla se hace la descripcin de cada caso de uso. (Ver Apndice 4 y
Figura 9)
Tabla 7: Descripcin de Casos de uso.
Nombre:
Actores:
Propsito:
Resumen:

CU-1 Iniciar Sesin

Empleado.
Entrar al sistema
El usuario inserta a travs del teclado su nombre de usuario y su clave. El sistema
hace las verificaciones necesarias y el usuario entra al sistema.

Nombre:
Actores:
Propsito:
Resumen:

CU-2 Cerrar Sesin

Empleado.
Cerrar una sesin del sistema
El usuario termina una sesin del sistema

Nombre:
Actores:
Propsito:
Resumen:

CU-3 Cambiar Clave

Empleado.
Cambiar la clave personal de usuario
El usuario selecciona el cambio de clave, se identifica su identidad y se efecta el
cambio

44

Nombre:
Actores:
Propsito:
Resumen:

CU-4 Monitorear Estado de Solicitudes

Empleado.
Monitorear el estado en el que se encuentra una solicitud de RRHH realizada por el
usuario o alguno de sus subalternos.
El usuario selecciona ver el estado las solicitudes realizadas y se le presenta
informacin como su estado, su presunto tiempo de finalizacin, sus notificaciones
asociadas, etc.

Nombre:
Actores:
Propsito:
Resumen:

CU-5 Consultar Tareas Asignadas

Empleado.
Consultar las tareas que le han sido asignadas
El usuario selecciona ver sus tareas asignadas, se le presentan todas sus tareas a
realizar y la opcin de efectuarlas.

Nombre:
Actores:
Propsito:
Resumen:

CU-5.1 Realizar Tarea Asignada

Empleado.
Realiza una tarea asignada
El usuario selecciona realizar una de sus tareas asignadas

Nombre:
Actores:
Propsito:
Resumen:

CU-5.2 Abrir Documentos Asociados

Empleado.
Solicita abrir un documento asociado a un proceso de RRHH.
Para cada tarea de los procesos de RRHH implementados que genere un
documento, los documentos se pueden leer, editar e imprimir.

Nombre:
Actores:
Propsito:
Resumen:

CU-5.2.1 Editar Documento

Empleado.
Solicita editar un documento.
Para cada tarea de los procesos de RRHH implementados que genere un
documento, este caso de uso ser invocado para la edicin de los templeates
disponibles.

Nombre:
Actores:
Propsito:
Resumen:

CU-5.2.2 Imprimir
Empleado.
Solicita imprimir un documento.
El usuario selecciona imprimir un documento asociado a un proceso de RRHH.

Nombre:
Actores:
Propsito:
Resumen:

CU-6 Ingresar Solicitud

Empleado.
Ingresar una solicitud de RRHH
El usuario selecciona ingresar una solicitud de RRHH. Las solicitudes posibles son
de vacaciones, constancia de trabajo, cursos de capacitacin, de prestaciones o de
prstamos.

Nombre:
Actores:
Propsito:

CU-7 Generar Notificacin

Empleado.
Genera notificaciones editables aprobacin, rechazo, contratacin, de entrevista y
alertas
El usuario genera una notificacin asociada a un proceso de RRHH

Resumen:

45

Nombre:
Actores:
Propsito:
Resumen:

CU-8 Ingresar Relacin de Gastos

Empleado.
Ingresar una relacin de gastos
El usuario selecciona ingresar una relacin de gastos, las relaciones de gasto se
ingresan por tuplas y se hace de manera incremental a travs del tiempo.

Nombre:
Actores:
Propsito:
Resumen:

CU-9 Monitorear Procesos Asignados a los Subalternos

Supervisor.
Consultar los procesos de RRHH asignados a los subalternos
El usuario selecciona monitorear procesos asignados a los subalternos, los procesos
terminados y los que aun no han terminado.

Nombre:
Actores:
Propsito:
Resumen:

CU-10 Solicitar Personal

Supervisor
Definir el perfil de una vacante en su rea
El usuario selecciona definir perfil de vacante

Nombre:
Actores:
Propsito:
Resumen:

CU-11 Aprobar Informacin Curricular

Supervisor, Ente RRHH.
Aprobar la informacin curricular de un candidato previamente solicitado
El usuario selecciona aprobar la informacin curricular de un candidato

Nombre:
Actores:
Propsito:
Resumen:

CU-12 Entrevistar Candidato

Supervisor, Ente RRHH.
Sealar que se ha entrevistado un candidato a personal, e ingresar los datos
relativos a la entrevista.
El usuario selecciona entrevistar candidato

Nombre:
Actores:
Propsito:
Resumen:

CU-13 Aprobar Candidato

Supervisor.
Aprobar un Candidato previamente solicitado
El usuario selecciona aprobar un candidato a personal

Nombre:
Actores:
Propsito:
Resumen:

CU-14 Aprobar Solicitud

Supervisor.
Aprobar una solicitud de RRHH
El usuario selecciona aprobar una solicitud de RRHH, la solicitud puede ser de curso
de capacitacin, prestaciones, prstamos, o vacaciones.

Nombre:
Actores:
Propsito:
Resumen:

CU-15 Confirmacin de Reintegro de un Subalterno

Supervisor.
Indicar que un subalterno ha regresado de vacaciones
El usuario indica la fecha en la que el empleado se reintegra al trabajo

Nombre:
Actores:
Propsito:
Resumen:

CU-16 Aprobar Relacin de Gastos

Supervisor.
Aprobar una solicitud de RRHH
El usuario selecciona aprobar las tuplas de una relacin de gastos

46

Nombre:
Actores:
Propsito:
Resumen:

CU-17 Consultar Procesos de RRHH

Gerente, Empleado
Consultar los procesos de RRHH que se estn realizando y los ya realizados.
El usuario selecciona consultar los procesos de RRHH de la compaa

Nombre:
Actores:
Propsito:
Resumen:

CU-17.1 Solicitar Reporte

Gerente, Empleado
Solicitar un reporte sobre los procesos de RRHH de la empresa
El usuario selecciona realizar un reporte

Nombre:
Actores:
Propsito:

CU-18 Emitir Pagos y/o Recibos

Ente Administrativo.
Procesar solicitudes administrativas que son generadas por procesos de RRHH,
como lo son las solicitudes de vacaciones, prestaciones, prstamos o cursos de
capacitacin.
El usuario selecciona procesar un pago y/o generara un recibo producto de un
proceso de RRHH.

Resumen:

Nombre:
Actores:
Propsito:
Resumen:

CU-19 Contratar Candidato

Ente Legal.
Contratar un candidato
El usuario selecciona contratar un candidato a personal

Nombre:
Actores:
Propsito:
Resumen:

CU-20 Emitir Constancia de Trabajo

Ente Legal.
Emitir Constancia de Trabajo
El usuario selecciona emitir una constancia de trabajo

Nombre:
Actores:
Propsito:
Resumen:

CU-21 Identificar Recursos

Ente RRHH.
Determinar la factibilidad de una solicitud identificando los recursos necesarios
luego que el proceso de RRHH termine. Esto incluye solicitudes de prstamo,
prestaciones, vacaciones, cursos de capacitacin, y reclutamiento.
El usuario selecciona identificar recursos.

Nombre:
Actores:
Propsito:
Resumen:

CU-22 Seleccionar Candidato

Ente RRHH.
Sealar que se ha identificado un candidato para una vacante
El usuario selecciona seleccionar candidato

Nombre:
Actores:
Propsito:

CU-23 Informe de Seguimiento de Cursos de Capacitacin

Ente RRHH.
Crea un informe basado en el curso de capacitacin realizado por un determinado
empleado.
El usuario selecciona realizar un informe de seguimiento de cursos de capacitacin.

Resumen:
Nombre:
Actores:
Propsito:
Resumen:

47

CU-24 Cambiar Perfil Empleado

Administrador del Sistema.
Actualizar datos relativos al empleado y en especial su posicin en la estructura
organizativa.
El usuario cambia los datos previamente cargados sobre el usuario.

Nombre:
Actores:
Propsito:
Resumen:

CU-25 Crear Usuario

Administrador del Sistema.
Crea un nuevo usuario del sistema este debe ser un empleado de la empresa.
El Administrador del Sistema crea un nuevo usuario del sistema

Nombre:
Actores:
Propsito:
Resumen:

CU-26 Cambiar Ventanas de Tiempo de los Procesos

Administrador del Sistema.
Cambiar Ventanas de tiempo de los procesos
El Administrador del Sistema cambia las ventanas de tiempo de los procesos

Nombre:
Actores:
Propsito:

CU-27 Determinar Acceso al Reporteador

Administrador del Sistema.
Determina que empleados a parte de los usuarios gerentes tienen acceso al
reporteador
El Administrador del Sistema determina el acceso al reporteador

Resumen:

48

Fig 8 Diagrama inicial de Casos de Uso.

49

h. Delimitacin del Ciclo de Proyecto y Plan de Proyecto.

El presente apartado representa el entregable final de esta fase, la delimitacin del
proyecto y su planificacin permitirn establecer los lmites de este primer ciclo de desarrollo.
Se tom la decisin de que solo algunos de los requerimientos expuestos para este
primer ciclo de desarrollo tomando en cuenta los riesgos 1, 2 y 3 de la lista de riesgos. Se
determin que debido a la complejidad inherente al desarrollo de una aplicacin con una
tecnologa nueva y desconocida el riesgo de retraso era grande. La complejidad en la
implementacin de la comunicacin entre los procesos BPEL con la interfaz desarrollada en Struts
es un punto de retraso probable. En este primer ciclo del desarrollo se implementaron los
requerimientos asociados a los procesos, dejando para futuras iteraciones los requerimientos
funcionales asociados al monitoreo, control y gerencia de los procesos.
Es as que, los requerimientos funcionales a implementar son:
Req1: Capturar, Analizar y Procesar Solicitudes de Procesos de RRHH.
Req1.1: Capturar, Analizar y Procesar Solicitudes de Adelanto de Prestaciones.
Req1.2: Capturar, Analizar y Procesar Reclutamiento de Personal.
Req1.3: Capturar, Analizar y Procesar Relaciones de Gasto.
Req1.4: Procesamiento de Solicitud de Constancia de Trabajo.
Req1.5: Capturar, Analizar y Procesar Solicitudes de Cursos de Capacitacin.
Req1.6: Capturar, Analizar y Procesar Solicitudes de Prstamo.
Req1.7: Capturar, Analizar y Procesar Solicitudes de Vacaciones.
Los requerimientos funcionales que quedan para futuras iteraciones son:
Req2: Monitorear Procesos de RRHH.
Req3: Generar Reportes sobre los Procesos de RRHH.
Req4: Gerenciar el Sistema.
Los requerimientos no funcionales son garantizados, en parte, por la plataforma de
software escogida. La medicin del cumplimiento de los requerimientos no funcionales queda para
futuras iteraciones sin embargo se destacan en el presente documento para establecer un norte
en las caractersticas que tendr la aplicacin en su ciclo final de produccin, sin embargo, el
analista/programador tendr siempre presente dichos requerimientos para intentar cubrir aquellos
requerimientos que no estn contemplados por la tecnologa, como por ejemplo el requerimiento
de usabilidad.
Habiendo escogido los requerimientos de implementacin, se determin que los casos de
uso implementados en este primer ciclo estn representados en la siguiente lista y se pueden

50

visualizar en el diagrama de casos de uso del ciclo anexo, dicha decisin se tomo principalmente
por las referencias cruzadas de los casos de uso (ver Apndice 4):
CU-1 Iniciar Sesin
CU-2 Cerrar Sesin
CU-5 Consultar Tareas Asignadas
CU-5.1 Realizar Tarea Asignada
CU-6 Ingresar Solicitud
CU-7 Generar Notificacin
CU-8 Ingresar Relacin de Gastos
CU-8 Ingresar Relacin de Gastos
CU-10 Solicitar Personal
CU-11 Aprobar Informacin Curricular
CU-12 Entrevistar Candidato
CU-13 Aprobar Candidato
CU-14 Aprobar Solicitud
CU-15 Confirmacin de Reintegro de un Subalterno
CU-16 Aprobar Relacin de Gastos
CU-18 Emitir Pagos y/o Recibos
CU-19 Contratar Candidato
CU-20 Emitir Constancia de Trabajo
CU-21 Identificar Recursos
CU-22 Seleccionar Candidato
CU-23 Informe de Seguimiento de Cursos de Capacitacin
En el Apndice 5 se presenta el plan de trabajo para este primer ciclo de desarrollo del
software, se especifican las actividades, iteraciones, fases y entregables en una lnea de tiempo
de 20 semanas.

51

Fig 9 Diagrama de Casos de Uso del Ciclo.

52

2. Fase de Elaboracin.
a. Modelos WAD; Modelo de Flujo de Procesos de RRHH.
A continuacin se presentan los diagramas WAD asociados a cada uno de los procesos
que deben ser desarrollados en el presente proyecto. Los diagramas son presentados y explicados
detalladamente. Cabe desatacar que en los diagramas desarrollados la definicin de los objetos
participantes en los flujos coincide con la definicin de actores desarrollada previamente.
Existen algunas tareas asociadas a los procesos que son comunes a todos los procesos
modelados, otras tareas son especficas a cada flujo y tienen acciones especficas a las reglas del
proceso. A continuacin se presenta una lista de tareas brevemente detalladas que son comunes
a todos o muchos de los procesos modelados:

Aprobacin de Solicitudes.
Las solicitudes son aprobadas o desaprobadas durante sus flujos de proceso. Esta tarea

representa la tarea ms importante debido a que es extensamente usada. La aprobacin y

desaprobacin puede ser realizada por un empleado o por un ente de la empresa. Todo rechazo o
desaprobacin de solicitud genera una tarea de notificacin para informarle al empleado
solicitante la razn del rechazo, y desemboca en la terminacin de todo el flujo de proceso. En
caso aprobatorio la tarea da paso a la siguiente tarea del flujo de proceso.
9

Envo de notificaciones.
Las notificaciones son enviadas automticamente por el flujo de proceso o son enviadas

por un empleado que se le ha asignado dicho envo como una tarea.

9

Impresin y Firma de Documentos.

Los documentos generados durante el proceso deben ser impresos y firmados por el

emisor. A pesar de que esta tarea es trasciende al sistema por sus caractersticas fsicas, es un
paso primordial confirmarle al sistema que estas tareas han sido efectuadas para dar paso a la
siguiente tarea.
Las tareas son como componentes simples que se configuran en el flujo de proceso, el
orden y lgica que sigan dichas tareas es lo que distingue a un proceso de otro.
Para una mayor comprensin de los diagramas remitirse al anexo 1.

53

i.

Solicitud de Constancia de Trabajo.

Fig 10 Diagrama WAD de Solicitud de Constancia de Trabajo.

El proceso de solicitud de constancia de trabajo es iniciado por un empleado de Develcom
Soluciones e Informtica C.A., luego el sistema genera una notificacin automtica al gerente y
supervisor directo del empleado informando que el empleado ha solicitado una constancia de
trabajo y que su procesamiento ya ha dado inicio. La solicitud pasa a manos del ente Legal de la
compaa donde deber imprimirse y firmarse la constancia de trabajo. Luego, se enva
automticamente una notificacin de fin de proceso a los superiores del empleado. (Ver Fig 11)

54

ii.

Solicitud de Prestaciones.

Fig 11 Diagrama WAD de Solicitud de Prestaciones.

55

El proceso de solicitud de prestaciones es iniciado por un empleado de Develcom

Soluciones e Informtica C.A. El ente de recursos humanos identifica si existen los recursos
necesarios para procesar la solicitud, esta es una tarea de aprobacin donde se aprueba o
desaprueba la existencia de recursos. La tarea pasa al supervisor que aprueba o desaprueba la
solicitud, en caso aprobatorio el gerente realiza otra tarea aprobatoria. Si el gerente aprueba la
solicitud, esta pasa al ente administrativo que deber imprimir y firmar el recibo correspondiente
al pago de las prestaciones, como tambin, un documento donde haga constar la solicitud y
procesamiento del pago de prestacin realizadas al empleado solicitante. Luego, se enva
automticamente una notificacin de fin de proceso a los superiores del empleado. (Ver Figura
12)

iii.

Solicitud de Prstamo.
Si observamos detenidamente el flujo de proceso que debe seguir una solicitud de

prstamo se puede notar que es exactamente igual al seguido por una solicitud de prestaciones,
lo que cambia entre ellos es la naturaleza de los datos que se maneja en uno y otro proceso. (Ver
Figura 13)

56

Fig 12 Diagrama WAD de Solicitud de Prstamo.

57

iv.

Solicitud de Vacaciones.

Fig 13 Diagrama WAD de Solicitud de Vacaciones.

El proceso de solicitud de vacaciones es iniciado por un empleado de Develcom
Soluciones e Informtica C.A. El supervisor del solicitante aprueba o desaprueba la solicitud. En
caso aprobatorio y de manera similar, el gerente del solicitante aprueba o desaprueba la solicitud.
Luego el flujo de proceso tiene una bifurcacin donde las vacaciones pueden haber sido
solicitadas con o sin pago, con o sin disfrute.

58

Si el solicitante ha solicitado sus vacaciones con su pago correspondiente, el ente de

recursos humanos deber identificar los recursos correspondientes a ese pago, esta es una tarea
de aprobacin donde se aprueba o desaprueba la existencia de recursos. Si los recursos son
identificados, el ente administrativo deber imprimir y firmar el recibo del pago correspondiente.
Luego se sigue el flujo correspondiente a la solicitud de vacaciones sin pago, donde deber
imprimirse y firmarse el documento donde consta el procesamiento de la solicitud. Si las
vacaciones son con disfrute, el supervisor del solicitante deber sealar cuando fue el reintegro de
su supervisado a su puesto de trabajo. (Ver Figura 14)

59

v.

Solicitud de Personal.

Fig 14 Diagrama WAD de Solicitud de Personal.

El proceso de solicitud de personal es iniciado por un supervisor de Develcom Soluciones
e Informtica C.A. El supervisor realiza la solicitud cuando identifica una necesidad de personal en
su rea o proyectos a cargo. Paralelamente, el gerente del supervisor solicitante aprueba o
desaprueba la solicitud y el ente de recursos humanos identifica los recursos necesarios para
poder reclutar nuevo personal. Si ambos aprueban la solicitud, se habr un espacio para la

60

propuestas de candidatos, el supervisor solicitante, su gerente directo y el ente de recursos

humanos son los nicos que pueden proponer candidatos a la vacante aprobada.
Una ves se tenga un candidato este es pasa por una revisin curricular en la que se
aprueba o desaprueba el candidato, tambin es aprobado por recursos humanos quien revisa sus
referencias laborales, notar que estas son tareas de aprobacin y que se llevan en paralelo.
Si ambos aprueban al candidato, el candidato pasa por tres entrevistas. Para continuar el
proceso el candidato debe salir aprobado de dos de las tres entrevistas, notar que es una tarea de
aprobacin. Los encargados de realizar las entrevistas son el supervisor solicitante, el gerente
directo de este y el ente de recursos humanos.
Si el candidato es aprobado por el proceso de entrevistas el ente de recursos humanos le
enva una notificacin de aprobacin. Luego el ente legal debe encargarse de la contratacin del
candidato y su posterior notificacin de contratacin. (Ver Figura 15)

vi.

Solicitud de Pago de Relaciones de Gasto.

El proceso de solicitud de de pago de relaciones de gasto se inicia automticamente una

ves al mes. Los empleados ingresan las distintas relaciones de pago durante el mes, luego una
ves al mes el flujo de trabajo cierra el mes de relaciones de gasto las pondera y permite que los
supervisores aprueben o desaprueben las relaciones de gasto de sus supervisados. Si al menos
una tupla de la relacin de gastos ha sido aprobada esta pasa al gerente del empleado, este
realiza otra tarea de aprobacin/desaprobacin de tuplas. Si el gerente aprueba al menos una
tupla esta es ponderada finalmente y se pasa al ente administrativo quien deber imprimir y firma
el recibo correspondiente al pago de las relaciones de gasto. Finalmente, se le enva
automticamente una notificacin al empleado que la aprobacin de sus relaciones de gasto ha
finalizado. (Ver Figura 16)

61

Fig 15 Diagrama WAD de Solicitud de Pago de Relaciones de Gasto.

62

vii.

Solicitud de Cursos de Capacitacin.

Fig 16 Diagrama WAD de Solicitud de Cursos de Capacitacin.

El proceso de solicitud de cursos de capacitacin es iniciado por un empleado de
Develcom Soluciones e Informtica C.A. Luego el ente de recursos humanos aprueba o
desaprueba la identificacin de recursos para procesar la solicitud. La tarea pasa al supervisor que
aprueba o desaprueba la solicitud, en caso aprobatorio el gerente realiza otra tarea aprobatoria.

63

Si el gerente aprueba la solicitud, El ente legal enva una notificacin aprobatoria del curso de
capacitacin. Luego, iterativamente, el ente de recursos humanos har un informe de seguimiento
del curso de capacitacin y el ente administrativo imprimir y firmara los recibos correspondientes
al pago del curso cada vez que sea la fecha de pago correspondiente. Finalmente, cuando sea la
ltima fecha de curso se enviara una notificacin a los superiores del empleado solicitante para
notificar la finalizacin del curso, y por lo tanto la finalizacin de pagos. (Ver Figura 17)
b. Modelo de Datos del Negocio.
El modelo de datos del negocio representa los datos que son propios del negocio y como
estos datos se relacionan entre s. Los datos que son propios del proceso son manejados
directamente por BPEL y son accesados solo para consultar informacin de los procesos
existentes. Los datos del negocio son aquellos datos que van ms all del proceso, se usa una
base de datos para el almacenaje de estos datos principalmente porque son datos que deben ser
persistentes.
A continuacin se presenta un modelo Entidad Relacin para la representacin del
modelo de datos del negocio, este modelo fue elaborado con la opcin de diagramas disponible
en JDeveloper 10g de Oracle. [Zaane1995]

Fig 17 Modelo de Datos.

64

La definicin de los datos en el modelo ER es el siguiente:

Proceso: Representa los procesos de recursos humanos requeridos por Develcom

Soluciones e Informtica.

Tarea: Representa las tareas de los procesos de recursos humanos requeridos por
Develcom Soluciones e Informtica. Debido a que se deseaba que el tiempo lmite de
ejecucin de las tareas fuese no determinstico se guarda como un dato que se lee y
puede ser editable.

Empleado: Representa un empleado de Develcom Soluciones e Informtica.

Grupo: Representa los distintos grupos definidos para Develcom Soluciones e Informtica
y sus integrantes; Ente Legal, Ente Administrativo y Ente RRHH.

Ente: Representa los distintos entes definidos para Develcom Soluciones e Informtica.

Vacante: Una vacante es un puesto que esta sin ocupar en Develcom Soluciones e
Informtica.

Dato_Vacante: Es un dato asociado a una vacante.

Relacion_Gasto: Es una relacin de gasto.

Relacion_Gasto_Mes: Es la ponderacin de las relaciones de gasto en un mes.

RG_Mes_Motivo_Monto: Es la ponderacin de las relaciones de gasto en un mes por

motivo.

Relacion_Gasto_Pro: Es una relacin de gasto procesada o cancelada.

Relacion_Gasto_Mes_Pro: Es la ponderacin de las relaciones de gasto en un mes

procesada o cancelada.

RG_Mes_Motivo_Monto_Pro: Es la ponderacin de las relaciones de gasto en un mes por

motivo procesada o cancelada.
Las relaciones entre los datos del modelo ER son las siguientes:

Un proceso tiene de una a muchas tareas, una tarea puede pertenecer a muchos
procesos.

Un empleado puede o no pertenecer a uno o ms grupos, un grupo tiene de uno a

muchos empleados.

Un empleado puede ser gerente de un ente, un ente solo tiene un gerente.

Un empleado tiene o no gerente, un gerente es empleado.

Un empleado tiene o no supervisor, un supervisor es empleado.

Una vacante esta asociada a un gerente, un gerente puede tener asociadas muchas
vacantes.

Una vacante esta asociada a un supervisor, un supervisor puede tener asociadas muchas
vacantes.

65

Una vacante tiene de uno a muchos datos asociados, un dato solo pertenece a una
vacante.

Una relacin de gasto del mes en curso esta asociada solo a un empleado, un empleado
puede tener muchas relaciones de gasto del mes en curso.

Un empleado puede tener o no muchas relaciones de gasto ponderadas del mes, una
relacin de gasto ponderada del mes solo pertenece a un empleado.

Una relacin de gasto pertenece o no a una relacin de gasto ponderada del mes, una
relacin de gasto ponderada del mes posee de una a muchas relaciones de gasto.

Una relacin de gasto ponderada del mes esta asociada a una o muchas ponderaciones
por motivo en el mes, una ponderacin por motivo en el mes solo esta asociada a una
relacin de gasto ponderada del mes.

c.

Descripcin de la Arquitectura del software.

La arquitectura del presente proyecto esta basada en el modelo de 4+1 vistas. A

continuacin se especifica la organizacin de los componentes de cada una de las 4+1 vistas para
el desarrollo del presente proyecto.

Vista Lgica
En la vista lgica se especifica el dominio del problema, es decir, los requerimientos

funcionales del sistema. Los diagramas utilizados para la implementacin de esta vista fueron el
diagrama conceptual, el diagrama de datos, y los diagramas WAD. Esto diagramas representan lo
que se espera del sistema y como se debern relacionar los elementos desarrollados entre s.

Vista de Proceso
La vista de proceso no fue desarrollada debido a que la concurrencia de los procesos del

sistema es totalmente transparente para el programador, esto se debe a la tecnologa que

sustenta el desarrollo del sistema. A continuacin se presenta una breve lista de las tecnologas
usadas y que problema de concurrencia solventan.
9

Oracle BPEL Server: maneja la concurrencia entre los procesos BPEL y las peticiones
concurrentes de los clientes, en el caso particular del sistema, las llamadas concurrentes
de la aplicacin desde la capa lgica.

Oracle Application Server: a travs del marco de trabajo Struts el Application Server de
Oracle resuelve la concurrencia de comunicacin de la capa lgica con las interfaces y las
peticiones de los clientes.

66

Vista de Implementacin.
En esta vista se especifica la organizacin de los mdulos del sistema. La combinacin del

marco de trabajo de Struts con los procesos BPEL establece una estructura que organiza los
componentes de la aplicacin. Los componentes definidos por Struts estn desplegados en el
Oracle Application Server, los procesos BPEL en el Oracle BPEL Server y las bases de datos estn
en Oracle Database.
En la Figura 19 se ilustra la manera en que se integro el marco de trabajo de Struts con
BPEL. El marco de trabajo de Struts esta basado en el modelo MVC (Ver apartado 7 del marco
terico), que consta de tres capas constitutivas; modelo, vista y controlador. A continuacin se
tiene una breve lista donde se explica como se establece la comunicacin entre la vista, el
controlador, el modelo, las bases de datos, y los procesos BPEL.

La vista est implementada mediante pginas JSP, que se comunican con el controlador a
travs de una librera de etiquetas ofrecidas por Struts.

Las actividades del controlador son realizadas automticamente por Struts por medio de
un archivo de configuracin XML que establece la comunicacin con la vista y el modelo.

El modelo es un conjunto de clases Java que le da la estructura de datos a la vista, y

ejecuta la lgica de la aplicacin. Para que las clases del modelo se ejecuten deben ser
invocadas por el controlador.

Los procesos BPEL se comunican con las clases del modelo a travs de unas libreras Java
ofrecidas por BPEL, por medio de estas libreras los procesos BPEL son consultados y
operados. Los procesos BPEL se encargan de ejecutar la lgica del proceso.

Las base de datos tanto del proceso como del negocio son accesadas a travs de
procesos BPEL.

Fig 18 Modelo de Implementacin; Struts + BPEL.

67

Vista de Implantacin.
Esta vista describe los recursos de hardware y software que son necesarios para ejecutar

la aplicacin, tanto en el servidor como en el cliente.

9

Servidor de Base de Datos.

Software: Oracle Database 10 g.

Hardware:

Memoria fsica RAM mnimo 256 MB recomendado 512.

Memoria Virtual el doble del RAM.

Espacio Temporal de disco de 100 MB.

Espacio de disco duro de 1.5 GB.

Adaptador de video 256 colores.

Procesador de 200 MHz mnimo.

Servidor de Aplicaciones.

Software: Oracle Application Server Containers for J2EE (OC4J) 10 g.

Hardware:

Procesador de 300 MHz mnimo.

Memoria fsica RAM mnimo 512 MB.

Espacio de disco duro de 1 GB.

Espacio Temporal de disco de 256 MB.

Espacio de Intercambio 640 MB mnimo.

Adaptador de video 256 colores.

Servidor BPEL.

Software: BPEL Process Manager 10.1.2 con JDeveloper 10g, OC4J 10g, y Oracle Lite.
Hardware:

Memoria fsica RAM mnimo 512 MB recomendado 1 GB.

Espacio de disco duro de 600 MB.

Adaptador de video 256 colores.

Espacio de Intercambio 1535 MB mnimo.

Cliente.

Software: Cualquier sistema operativo con navegador instalado.

Hardware:

68

Procesador de al menos 133MHz.

Memoria fsica RAM de al menos 128Mb.

Tarjeta de red y conexin a Internet.

Vista de Casos de Uso.

Esta vista constituye la unin de las otras cuatro vistas, esta vista sintetiza las otras vistas

dndole una poderosa herramienta al analista para tomar decisiones de diseo e implementacin.
El diagrama utilizado para lograr la finalidad de esta vista fue el diagrama de casos de uso y sus
sucesivos refinamientos, en el se representan el dominio de la solucin mostrando todas las
funcionalidades del sistema y cmo el cliente interactuara con ellas.
d. Lista Revisada de Riesgos.
Luego de revisar detenidamente la lista de riesgos, se concluye que los riesgos ms
difciles de controlar sern los siguientes: (Ver Apndice 3)
Risk.1 No contar con los recursos tcnicos para desarrollar a tiempo el sistema.
Risk.2 Cambio de nuevas versiones de las herramientas asociadas a ORACLE BPEL.
Esto se debe a que debido a que Oracle BPEL Process Manager aun no es estable, es una
tecnologa nueva donde no existe suficiente documentacin, y es totalmente nueva para el
programador existen muchas probabilidades que surjan problemas que solo es posible detectar a
tiempo de implementacin. Para mitigar estos riesgos se recomienda el uso extensivo del foro de
expertos de Oracle y usar toda la documentacin disponible.

3. Fase de Construccin.
a. Implementacin de los Procesos de Negocio.
Los procesos de negocio estn implementados usando Oracle JDeveloper 10 g. Hay una
serie de subprocesos que fueron implementados para ayudar en la reutilizacin de procesos y
para favorecer la abstraccin del cdigo, estos sub-procesos estn desplegados en el servidor y
pueden ser accesados como servicios BPEL. Los procesos de solicitud de vacaciones, prestaciones,
prestamos, constancia de trabajo, personal, curso de capacitacin y pago de relaciones de gasto
estn compuestos por un flujo lgico que hace llamada a estos sub-servicios conformando la
lgica del proceso expuesta en lo diagramas WAD previamente explicados.
Todos los procesos de negocio estn implementados en BPEL siguiendo fielmente el
respectivo modelo WAD diseado, exceptuando el caso del pago de relaciones de gasto y solicitud
de personal en el que los procesos fueron divididos en sub-procesos que juntos cumplen con la
lgica descrita en los diagramas WAD correspondientes, el resto de los procesos son iniciados por
el usuario activando el flujo del proceso, y el proceso asigna las tareas segn la lgica de negocio
a los responsables correspondientes hasta su cierre final.

69

El proceso de pago de relaciones de gasto se dividi en tres sub-procesos de negocio; el

ingreso de las relaciones de gasto, la ponderacin de las relaciones de gasto del mes y la
aprobacin de las relaciones de gasto. El ingreso de las relaciones de gasto es un servicio
continuamente disponible en el que el usuario ingresa los datos y un servicio guarda los datos en
la base de datos del negocio. La ponderacin de las relaciones de gasto es un proceso continuo
que se activa una vez al mes, este proceso pondera las relaciones de gasto ingresadas en el mes.
Y por ultimo, el proceso aprobatorio que consta de varias tareas aprobatorias de las relaciones de
gasto ponderadas por el demonio de clculo de totales.
El proceso de solicitud de personal tambin se dividi en tres sub-procesos; la solicitud de
personal y aprobacin de la vacante, el ingreso de candidatos, y la aprobacin de candidatos. El
proceso de solicitud de personal y aprobacin de vacantes es iniciado por un supervisor y es
aprobado por los responsable correspondientes, cuado esta aprobacin ha terminado se ha
creado una vacante. Luego, el proceso de ingreso de candidatos se pone disponible a los usuarios
asociados a la vacante. Y finalmente, cada vez que un usuario ingrese un candidato este pasa a
un proceso aprobatorio hasta su posible contratacin.
El manejo de excepciones en los procesos es en su mayora de violacin del lmite de
tiempo para la ejecucin de una determinada tarea de usuario. Las excepciones fueron manejadas
dentro de los sub-procesos implementados, de esta manera la excepcin es capturada
tempranamente y se toman las medidas necesarias, esto se hace de manera muy similar a como
Java maneja las excepciones.
Tambin se implement un conjunto de procesos que son de acceso, consulta y escritura
de datos en la base de datos del negocio. Algunos de estos procesos son sub-procesos de otros
procesos BPEL implementados, otros son para obtener datos que sern desplegados en la
interfaz, y otros son demonios de clculo y manejo de datos.
A continuacin se presenta uno de los procesos implementados. En la ilustracin
siguiente se ve el proceso tal como se ve grficamente con la herramienta de desarrollo,
acompaado de la ilustracin se presenta una pequea descripcin de la implementacin del
proceso.

70

 Solicitud de Constancia de Trabajo.

Fig 19 Implementacin del proceso de Solicitud de Constancia de Trabajo en Oracle BPEL.

71

En la figura 19 se ilustra como fue implementado el proceso de Solicitud de Constancia de

Trabajo. Al observar la imagen podemos notar que es muy similar al diagrama WAD previamente
expuesto del proceso. En la imagen se suceden un grupo de tareas en un flujo. Las cajas
amarillas son las asignaciones de datos de entrada a los subprocesos y las cajas azules son las
invocaciones y recepciones de dichos subprocesos. La caja inicial es aquella que instancia el
proceso e inicia el flujo, la caja final es la que se encarga de retornar el valor final de
procesamiento y da fin al flujo del proceso. Para este proceso se usaron tres sub-procesos; el que
realiza la notificacin de solicitud de constancia de trabajo, el que se encarga de imprimir y firmar
la solicitud, y por ultimo, el subproceso que se encarga de enviar la notificacin de finalizacin de
proceso.
En la Ilustracin 7 en la seccin de ilustraciones se encuentran imgenes de otros
procesos en los que se puede apreciar flujos paralelos, ciclos, y otras caractersticas propias de
los flujos de trabajo.
b. Implementacin de la Capa Lgica de Aplicacin.
La lgica de la aplicacin se encuentra en la capa modelo de la arquitectura del sistema,
esta capa esta implementada en Lenguaje Java. En las clases Java implementadas se manejan los
datos obtenidos desde la interfaz, se realizan operaciones de validacin de datos, se construyen
los XMLs para la invocacin de los procesos BPEL, se llama a los funciones que instancias los
procesos BPEL, se obtiene el estado de los procesos, se procesan los datos que se obtienen de los
procesos, y se preparan los datos para pasrselos a la interfaz. Tambin se realizan operaciones
que escapan a la lgica de los procesos pero que son inherentes al funcionamiento de la
aplicacin, como lo es la solicitud de datos para su despliegue en la interfaz.
c.

Implementacin de la Interfaz.
La interfaz esta diseada para asegurar la mxima usabilidad de la aplicacin, la finalidad

es minimizar el esfuerzo del usuario para operar la aplicacin. Los elementos estn distribuidos
estratgicamente para que sean agradables y comprensibles fcilmente, los colores de la interfaz
corresponden a varias escalas de azules, de grises, y blanco. Los colores fueron escogidos a partir
de la paleta de colores caractersticos de la compaa Develcom Soluciones e Informtica.
Ntese que la aplicacin, desde el punto de vista de la interfaz, es un buzn de tareas,
despachador de tareas e iniciador de tareas, por lo tanto, son tres tipos de interfaces; la interfaz
del buzn de tareas, la interfaz de despacho de tareas y la interfaz de inicio de solicitud o ingreso
de datos par las tareas. (Ver Ilustracin 6)

72

d. Mapa de Navegacin del Prototipo.

A continuacin se presenta la figura 20 donde se puede apreciar el mapa de navegacin
de la aplicacin, en este mapa de navegacin solo estn representadas las funcionalidades que
sern implementadas en este ciclo de desarrollo.

Fig 20 Mapa de Navegacin.

4. Fase de Transicin.
a. Descripcin del Estado Actual del Proyecto.
El proyecto tiene actualmente operativos todos los procesos de negocio de Recursos
Humanos que fueron requeridos por Develcom Soluciones e Informtica C.A. Estos fueron
implementados y probados con Oracle BPEL Process Manager siguiendo fielmente el diseo de
procesos que se model por medio de los diagramas WAD usando el Oracle JDeveloper BPEL
Designer.
Los procesos fueron probados, ms especficamente, con el Oracle BPEL Console y el
Sample Worklist Aplication de Oracle BPEL donde es posible auditar las instancias de los procesos
y realizar las tareas que conforman el proceso. Estos procesos fueron validados por la fuente de
requerimientos.

73

Las interfaces estn implementadas en su totalidad, el feel and look de la interfaz fue
terminado y todas las pginas se ejecutan correctamente.
Sin embargo, existen problemas con las libreras Java ofrecidas por Oracle para BPEL
para la implementacin de las clases Java que integran a las interfaces con los procesos BPEL.
Estas libreras ofrecen las funciones y procedimientos para invocar o iniciar los procesos, consultar
el estado de los procesos, obtener los resultados de un proceso y para realizar las tareas de
usuario que conforman el proceso. Las libreras Java se encuentran mal documentadas o sin
ningn tipo de documentacin, y algunas funciones y procedimientos no realizan las operaciones
esperadas. Usando estas libreras disponibles se logr realizar la invocacin de los procesos,
haciendo el pase de datos e instanciando el proceso en el Oracle BPEL Server, tambin es posible
obtener los resultados de una instancia de proceso cerrada usando mtodos no sugeridos por
Oracle pero igualmente efectivos, sin embargo, no fue posible usar las funciones que permiten
realizar las tareas del proceso.
Por lo tanto, los procesos de negocio de Recursos Humanos estn listos y corriendo en el
Oracle BPEL Server, las interfaces estn listas y correctas, pero la comunicacin entre la lgica de
la aplicacin y la lgica de los procesos, hasta ahora, slo est establecida a medias.

i.

Revisin de Lista de Riesgos.

Los riesgos sealados previamente en la lista revisada de riesgos se convirtieron en

puntos palpables de retraso en el proyecto en desarrollo, a pesar que los planes de contingencia
se aplicaron casi inmediatamente despus que los riesgos se materializaron no fue posible
mitigarlos. (Ver Apndice 3)
El riesgo 1, denominado Risk.1, se materializ cuando en la fase de construccin se
comenz la implementacin de las clases Java que permiten la comunicacin entre la lgica de la
aplicacin y la lgica del proceso, esto es debido a que las libreras Java ofrecidas por Oracle para
BPEL estn mal documentadas e implementadas.
Se recurri a la consulta de la documentacin disponible en el site oficial de Oracle BPEL
Process

Manager

(http://www.oracle.com/technology/products/ias/bpel/index.html),

la

consulta de expertos en la tecnologa por va correo electrnico o foros de discusin, sin embargo,
no fue posible dar con una solucin viable para establecer la comunicacin necesaria para la
realizacin de las tareas constitutivas de los procesos.
La solucin propuesta por los expertos fue la instalacin de la versin ms reciente de
Oracle BPEL Process Manager, cuyo lanzamiento fue en julio del 2005, es decir, en el transcurso
de las 20 semanas establecidas para la realizacin del presente proyecto, en este punto se
materializ el segundo riesgo de la lista de riesgo, denominado Risk.2. Esta nueva versin del
Oracle BPEL Process Manager an hoy est sometida a numerosos cambios y requiere mltiples

74

instalaciones de parches para su correcto funcionamiento, esto incluye las libreras Java para el
manejo de procesos BPEL.
Sin embargo, por recomendacin de los expertos, la nueva versin se instal. Se
probaron los procesos desarrollados en BPEL con la versin anterior, estos presentaron mltiples
problemas de incompatibilidad que para solucionarlos hubiese sido necesario alargar el tiempo del
presente ciclo de desarrollo y ajustar los objetivos de la fase de construccin orientndolos a la
adaptacin de los procesos implementados a la nueva versin del Oracle BPEL Process Manager.
Por lo tanto, se decidi seguir la implementacin con la versin anterior de Oracle BPEL
Process Manager hasta donde fuese posible, y establecer en el plan de prximas iteraciones el
pase de la aplicacin a la nueva versin y la implementacin de los requerimientos faltantes, esta
decisin se bas en la evaluacin de riesgo 3, denominado Risk.3, donde no se establece que el
tiempo de construccin excediese los tiempos establecidos ya que esto retrasara la totalidad del
proyecto.

ii.

Descripcin del Prototipo.

En el siguiente apartado se presenta la descripcin del prototipo final, como el usuario

debe interactuar con el sistema, y la apariencia final del prototipo. Se tom como referencia el
mapa de navegacin descrito previamente y las pantallas ms representativas del sistema, el
resto de las imgenes del sistema pueden ser encontradas en el apndice 9 acompaadas de una
descripcin de uso.

Inicio
En la pgina Web inicial de la aplicacin se presenta en la esquina superior derecha los

campos correspondientes al identificador y clave de usuario del sistema, en estos campos el

usuario ingresa su identificacin y clave correspondiente para accesar al Sistema de Gestin de
Recursos Humanos. (Ver Figura 21)
Una vez el usuario haya ingresado al sistema se le presentar un men en la parte
superior que le permitir navegar libremente a travs de todo el prototipo. El men tiene la
siguiente configuracin:
Home
Bandeja de Tareas
Solicitudes
Constancia de Trabajo
Prestaciones
Prstamo
Vacaciones
Curso de Capacitacin
Personal
Relaciones de Gastos

75

 Mi Relacin de Gastos del Mes

Relacin de Gastos del Mes Subalternos

Fig 21 Prototipo: Inicio.

Bandeja de Tareas
Una vez el usuario ingrese en el sistema se le presenta la bandeja de tareas del usuario,

en esta bandeja se especifica el nmero, el ttulo, el estatus, el usuario o grupo asignado y la

ultima fecha de modificacin de las tareas asignadas a este usuario. Los ttulos de las tareas son
vnculos que le permiten al usuario accesar a una tarea especifica y re-direcciona al usuario hacia
la realizacin de de la tarea.
Sobre la bandeja de tareas, a la derecha, se presenta un botn que le permite al usuario
refrescar su bandeja de tareas. (Ver Figura 22)

76

Fig 22 Prototipo: Bandeja de Tareas.

Realizar Tarea

Fig 23 Prototipo: Realizar Tarea.

77

Una vez el usuario haya seleccionado realizar una tarea, se le presenta una tabla con
todos los datos asociados a la tarea seleccionada, un campo de texto para agregar sus
comentarios, y una serie de botones correspondientes a las acciones que se pueden tomar en la
tarea, por ejemplo; Aprobar o Rechazar. (Ver Figura 23)

Solicitar Prstamo

Fig 24 Prototipo: Solicitar Prstamo.

Una vez el usuario haya ingresado al sistema, podr solicitar un prstamo ingresando el
monto del prstamo, el motivo, y la forma de pago, en caso de que el pago sea de contado
indicar la fecha de pago, si el pago es fraccionado indicar si el pago es mensual o quincenal y el
monto correspondiente a las fracciones de pago, luego podr enviar su solicitud clickeando sobre
el botn que sale en la mitad llamado Solicitar (Ver figura 24).

Ver Relaciones de Gasto Ponderadas de Subalternos

Una vez el usuario haya ingresado al sistema, podr solicitar ver las relaciones de gasto

ponderadas de sus subalternos, esto solo es posible si el usuario es un supervisor. Se presenta

una bandeja de relaciones de gasto donde se muestra el nmero identificador de la relacin de
gasto del mes, el nombre del subalterno, y el total y el total ajustado de la relacin de gastos del
mes. El nombre del empleado es un vnculo que le permite al usuario ver en detalle la relacin de
gasto del mes para el empleado, para luego procesarla. (Ver Figura 25)

78

Fig 25 Prototipo: Ver Relaciones de Gasto Ponderadas de Subalternos

Ingresar y Ver Relacin de Gasto del Mes en Curso

Una vez el usuario haya ingresado al sistema, podr ingresar y ver sus relaciones de

gasto del mes en curso. Para ingresar las relaciones de gasto deber indicar el nmero de factura,
la fecha correspondiente, el monto, el nombre del proyecto, el motivo y las observaciones si lo
desea, luego clickea en el botn Enviar y sus relaciones de gasto sern registradas. Para Ver las
relaciones de gasto que ya han sido ingresadas el usuario deber clickear sobre el botn Ver y
se le mostrarn sus relaciones de gasto. (Ver figura 26)

79

Fig 26 Prototipo: Ingresar y Ver Relacin de Gasto del Mes en Curso

Aprobar y Recalcular Relaciones de Gasto de Subalternos

Una vez el usuario haya solicitado ver las relaciones de gasto de un usuario subalterno,

se le presentaran todas las tuplas de la relacin de gasto correspondiente. Los datos relativos a la
relacin de gasto que se muestran son el nmero de factura,

la fecha, el proyecto, las

observaciones, el motivo, el monto de cada relacin y su estado. Tambin se presenta el monto

total real y ajustado, como tambin el total parcial por cada motivo.
Para cada relacin de gastos existe la opcin de cambiar su estado de aprobado a
desaprobado o viceversa. Al final de la pgina hay dos botones que permiten recalcular la relacin
de gastos o procesarla. Al recalcular la relacin de gasto se pueden ver los totales resultantes
antes de tomar una decisin final, las relaciones de gasto desaprobadas no son sumadas en los
totales una vez se recalcule la relacin de gasto. El procesamiento cierra finalmente la relacin de
gasto iniciando el proceso aprobatorio de la relacin de gastos (ver Figura 28)

80

Fig 28 Prototipo: Aprobar y Recalcular Relaciones de Gasto de Subalternos

b. Pruebas Finales.
La aplicacin implementada fue probada con diversos escenarios dando resultados
satisfactorios en todos los casos probados.

Las pruebas fueron realizadas en dos fases, una

primera fase de comprobacin de los procesos BPEL, y una segunda fase de comprobacin de la
lgica de la aplicacin y las interfaces. (Ver Apndice 5)
Los procesos BPEL estn probados en su totalidad usando el Oracle BPEL Console y el
Sample Worklist Application, estos se apegan fielmente a los flujos WAD diseados y el dueo del
sistema se mostr complacido con esas pruebas realizadas.
Por otro lado, Las interfaces y la lgica de la aplicacin est probada totalmente, bajo
varios escenarios, usuarios y data, y los resultados son totalmente satisfactorios para todas las
funcionalidades implementadas. La integracin de los procesos BPEL con la interfaz tambin ha
sido probada y

el resultado tambin es satisfactorio, tomando en cuenta las dificultades

previamente expuestas.

81

c.

Plan para Prximos Ciclos.

El presente apartado pretende proponer un plan para el total desarrollo del sistema, su

objetivo es servir como una gua para los siguientes ciclos de desarrollo, no debe ser considerado
definitivo y hay que someterlo a revisin antes de comenzar cada ciclo.
Considerando las caractersticas del presente ciclo de desarrollo, se estableci que para la
culminacin total del desarrollo seran necesarios tres ciclos ms de desarrollo. Los ciclos
considerados son muchos ms cortos debido a que se ha tenido en este primer ciclo una curva de
aprendizaje sobre las necesidades de Develcom Soluciones e Informtica, como tambin de la
Tecnologa que har que los siguientes ciclos de desarrollo se agilicen. A continuacin, se
presenta la descripcin de las principales actividades que cada uno de estos ciclos debe cumplir:

Ciclo 2: Pase a la Nueva Versin BPEL Process Manager

9

Pase de los procesos BPEL, clases Java y paginas JSP implementados a la nueva
versin de BPEL Process Manager.

Establecer la conexin a la Base de Datos del negocio.

Probar la aplicacin con la nueva versin de BPEL Process Manager.

Hacer los ajustes necesarios para que la aplicacin funcione igual o mejor que en la
versin anterior de BPEL Process Manager.

Revisar los requerimientos del ciclo anterior y, de ser necesario, ajustarlos a la nueva
realidad. Este ajuste puede implicar ajustes conceptuales, de diagramas, de
documentacin y de implementacin.

Implementar la comunicacin que falta entre interfaz y los procesos BPEL.

Realizar pruebas finales del ciclo.

Ciclo 3: Implementacin de Requerimientos Restantes

9

Revisar los requerimientos del ciclo anterior y, de ser necesario, ajustarlos a la nueva
realidad. Este ajuste puede implicar ajustes conceptuales, de diagramas, de
documentacin y de implementacin.

Evaluar todos los requerimientos no funcionales, y asegurar que se cumplen por lo

menos parcialmente.

Implementar los requerimientos funcionales restantes.

Req2: Monitorear Procesos de RRHH.
Req3: Generar Reportes sobre los Procesos de RRHH.
Req4: Gerenciar el Sistema.

82

Realizar las pruebas del ciclo.

Ciclo 4: Pase a Produccin.

9

Pasar la aplicacin del ambiente de desarrollo al ambiente de liberacin.

Evaluar todos los requerimientos no funcionales, y asegurar que se cumplen.

Realizar pruebas exhaustivas.

Entrenamiento de usuarios finales.

Si se determina que los siguientes ciclos de desarrollo sern realizados con los mismos
recursos humanos y tcnicos que estuvieron disponibles para el presente ciclo, se estim que el
segundo ciclo tomara mes y medio, el tercero un mes y el cuarto un total de quince das. Por lo
tanto se estima que la aplicacin estar en produccin en tres meses ms. Esta estimacin se
basa en condiciones ideales en el que no ocurran imprevistos, y que los requerimientos no
crezcan considerablemente. Para ver ms especficamente los planes de cada ciclo ver el apndice
6, 7 y 8.

83

Captulo VII Conclusiones y Recomendaciones.

El siguiente apartado presenta las conclusiones y recomendaciones que se obtuvieron en
el desarrollo del presente proyecto de pasanta. Las conclusiones y recomendaciones fueron
divididas en cinco tipos; conclusiones y recomendaciones sobre la metodologa, sobre la
tecnologa, sobre el producto, sobre las herramientas y sobre la pasanta. Esta divisin permite
enfocarse en los distintos aspectos presentes en el proyecto, en conjunto representa un anlisis
de los resultados obtenidos en el presente proyecto y ofrece una visin general de lo que fue el
proceso de desarrollo y la naturaleza del producto.

1.

Conclusiones.
Sobre la Metodologa
9

La metodologa de desarrollo usada para llevar a cabo el proyecto de pasanta, Rational

Unified Process (RUP), es abierta y adaptable al desarrollo que se realiz. La metodologa
garantiz un anlisis exhaustivo de requerimientos, un buen planteamiento de una
solucin viable y sent el precedente para futuros ciclos de desarrollo del sistema, como
tambin para otros sistemas que se desarrollen en Develcom Soluciones e Informtica.

La documentacin del proceso de desarrollo ayud al analista/programador a definir las

necesidades del usuario final, a establecer prioridades, proponer una solucin viable y
mitigar las dificultades que en el proceso de desarrollo se dieron. Esta documentacin fue
la gua indiscutible de la implementacin de la solucin ahorrando esfuerzo y tiempo en la
fase de construccin del sistema, como tambin garantiz la satisfaccin casi inmediata
del dueo del sistema ante la implementacin de la solucin.

La arquitectura de 4+1 vistas fue la piedra angular del desarrollo ya que integr los
resultados del anlisis de la solucin dando una visin global del sistema final. Esto es
particularmente importante para establecer las referencias y objetivos finales del
proyecto, evitando extravos en el proceso de desarrollo.

Sobre la Tecnologa.
9

BPEL representa un poderoso estndar para el diseo e implementacin de procesos de

negocio, se perfila como la gran solucin en la integracin de sistemas e implementacin
de procesos de negocio. Su carcter Web, los estndares universales que lo fundamentan
y su flexibilidad, hacen de BPEL un fuerte candidato tecnolgico para el desarrollo de
procesos de negocio.

84

Uno de los mayores retos de este proyecto fue la conjugacin del marco de trabajo Struts
con el estndar BPEL, esta propuesta persigue sentar un precedente en el uso de un
marco de trabajo formal como lo es MVC con un estndar de flujos de trabajo orientado a
Web. La unin de estos estndares obtuvo resultados positivos aligerando el proceso de
desarrollo, estableciendo la pertinencia de cada una de las partes de la arquitectura y
maximizando las caractersticas positivas de BPEL y Struts.

El uso de la plataforma Web para las interfaces se acopla perfectamente a los

requerimientos del sistema y ofrece una interfaz amigable y fcil de utilizar.

Sobre las Herramientas.

9

Oracle ofrece un ambiente de desarrollo integrado (IDE, integrated Development

Enviroment) que agiliza el proceso de desarrollo, y facilita la integracin de Struts y BPEL.

Rational Rose Enterprise Edicion es una herramienta muy potente para el desarrollo de
los diagramas que fueron pertinentes a este desarrollo.

Oracle BPEL Process Manager es una buena herramienta para la implementacin de

procesos BPEL. A pesar de sus inconsistencias inherentes a su estreno reciente, se perfila
como la mejor forma para disear, implementar, publicar y orquestar procesos BPEL.

Sobre el Producto.
9

Se dise e implement el sistema para la gestin de los procesos de recursos humanos

de Develcom Soluciones e Informtica, este sistema cumple con los requerimientos
establecidos para el primer ciclo de desarrollo. Consta de los procesos BPEL, la lgica de
la aplicacin y las interfaces.

Los procesos diseados e implementados formalizan la forma es que los procesos deben
ser llevados a cabo, eliminando ambigedades en el flujo del proceso, en las tareas y la
distribucin de responsabilidades. Este sistema implica el inicio de la automatizacin de
los procesos internos de la empresa, apuntando hacia la mayor eficiencia y efectividad de
los mismos.

El sistema permite llevar un control de la gestin de los procesos de recursos humanos de

una manera ms sencilla, rpida y segura, minimizando as el trabajo manual que se
llevaba a cabo con los procesos y el tiempo de procesamiento.

Sobre la Pasanta.
9

Este proyecto de pasanta fue para el pasante una gran enseanza. La experiencia del
proyecto sirvi para que la pasante aplicase y afianzase los conocimientos adquiridos en
las materias de su carrera, complementndolo para su futuro desempeo laboral. Llevar
la teora a la prctica fue para el pasante una experiencia enriquecedora y ardua que le

85

ense aspectos de la carrera que solo es posible aprender de esta manera. De igual
manera, permiti al pasante desempearse en un ambiente totalmente nuevo que lo ret
a desarrollar nuevas habilidades que le sern de mucha utilidad en el futuro.

2.

Recomendaciones.
Sobre la Metodologa
9

Es en extremo relevante seguir muy de cerca las 6 mejores prcticas vigentes de

desarrollo de software ya que brindan una gua muy til para el desarrollo total del
proyecto.

El diseo de la arquitectura representa el entregable ms importante del proceso de

desarrollo y establece las bases para todos los ciclos de desarrollos posteriores del
proyecto.

Sobre la Tecnologa.
9

Cuando se desarrolle una solucin informtica usando tecnologa nueva y desconocida

para el programador, se debe asegurar que la documentacin y soporte sean suficientes
y correctos para establecer las aspiraciones del proyecto. Particularmente para el caso
Oracle BPEL Process Manager, la documentacin plantea cosas que an no es posible
hacer, esta disparidad represent un problema para el cumplimiento cabal de los
objetivos planteados.

Para la combinacin de BPEL con Struts es de gran ayuda tener experiencia en desarrollo
Web, Java y de Web Services. Esto facilita la comprensin de la implementacin y deja
ms tiempo para la comprensin de BPEL que es la parte ms pesada del desarrollo.

Sobre las Herramientas.

9

Para el uso de los ambientes integrados de desarrollo Oracle es importante tener

experiencia en ambientes similares de desarrollo y hacer los tutoriales explicativos de la
herramienta, ya que es fcil que el programador se pierda entre el gran nmero de
funcionalidades o que no se use la herramienta al mximo de su capacidad omitiendo
funcionalidades que ayudan mucho en el proceso de desarrollo.

Referente a la herramienta Rational Rose Enterprise Edition es recomendable usarla ya

que es la herramienta ms completa para el uso de UML, sin embargo, hubiese sido de
mucha ayuda que existiese una versin disponible de la misma con UML2 para el caso
particular de las excepciones en el flujo del proceso.

86

 Sobre la Pasanta.
9

Para un proyecto de pasanta como el presente, es recomendable asegurarse que la

tutora industrial tiene experiencia en este tipo de desarrollos y que tienen la disposicin
y el tiempo de prestar ayuda al pasante.

Por otro lado, BPEL es fcil de aprender a travs del Oracle BPEL Process Manager y si
adems, se tiene experiencia en las otras reas que involucran este proyecto la
experiencia puede ser satisfactoria.

87

Referencias Bibliogrficas.
[RUP1999] The Rational Unified Process, Philippe Kruchten, Addison Wesley, 1999.
[PS61161999] Notas del curso PS6116, Universidad Simn Bolvar, 1999.
[Hurwitz2001] Ten pillars for World Class Business Process Manager, Hurwitz Group White
Paper, Julio 2001.

[Oracle2004] Orchestrating Web Services: The Case for a BPEL Server, Oracle White Paper,
June 2004.

[Ullman2004] Introduccin a los Sistemas de Bases de Datos, Ullman, Jeffrey y Widom,

Jennifer. Editorial Prentice Hall, Mxico 1999.

88

Referencias Electrnicas.
[UChile] http://www.dcc.uchile.cl/~psalinas/uml/casosuso.html, Universidad de Chile, Facultad de
Ciencias Fsicas y Matemticas, Departamento de Ciencias de la Computacin, Patricio Salinas
Caro.

[Wikipedia] es.wikipedia.org/wiki/Workflow, Wikipedia

[Allen]

http://www.wfmc.org/information/Workflow-An_Introduction.pdf,

Workflow:

an

Introduction, Rob Allen.

[Webopedia] www.webopedia.com, Webopedia.
[Struts] http://jakarta.apache.org/struts, The Apache Software fundation, Struts.
[He2003] http://webservices.XML.com/pub/a/ws/2003/09/30/soa.html, Webservices XML.com,
Hao He, September 30, 2003.

[ISO1991] http://www.cse.dcu.ie/essiscope/sm2/9126ref.html, ISO 9126: The Standard of

Reference, ISO/IEC 9126 Information technology Software Product Evaluation Quality
characteristics and guidelines for their use, 1991.

[Zaane1995]

http://www.cs.sfu.ca/CC/354/zaiane/material/notes/Chapter2/node16.html,

Design of an E-R Database Scheme, Osmar R. Zaane, Septiembre 1995.

[Kontio2005]

http://www-128.ibm.com/developerworks/wireless/library/wi-arch11/,

Architectural manifesto: Designing software architectures, Part 5, Mikko Kontio, Febrero 2005.

89

Glosario de Trminos.
A
Actor: es el rol de un usuario o entidad (otro sistema, una base de datos o el tiempo) que inicia
un Caso de Uso
Ambiente de Desarrollo: es el ambiente donde se le da forma a las configuraciones necesarias
del software.
Ambiente de Produccin: es el ambiente donde el sistema ya esta robado y corriendo, se
puede ver como el ambiente final.
Aplicacin: Programa o grupo de programas diseado para un usuario final.
Arquitectura del Software: se refiere a la disposicin del hardware y del software en un
sistema.

Arquitectura Cliente/Servidor: llamado modelo cliente-servidor o servidor-cliente es una

forma de dividir y especializar programas y equipos de computo a fin de que la tarea que cada
uno de ellos realiza se efecte con la mayor eficiencia, y permita simplificar las actualizaciones y
mantenimiento del sistema. En esta arquitectura la capacidad de proceso est repartida entre el
servidor y los clientes.

Arquitectura 4+1 Vistas: modelo arquitectnico propuesto por Philippe Kruchten, que define
cinco formas de ver la arquitectura del software; la vista lgica, la de proceso, la de
implementacin, la de implantacin y la de caso de usos que constituye la integracin de las otras
cuatro.

SOA: Service Oriented Architecture. Arquitectura de software orientada a los objetos. En esta
arquitectura todas las funciones o servicios esta definidas usando un lenguaje de descripcin y se
tiene interfaces de invocacin que son llamadas para ejecutar procesos de negocio.

B
BPEL: Business Process Execution Language for Web Services. Lenguaje basado en XML para
estandarizar procesos de negocio en un ambiente distribuido que permite que negocios separados
interconecten sus aplicaciones y compartan data.
BPM: Business Process Management. Disciplina empresarial cuyo objetivo es mejorar la eficiencia
a travs de la gestin sistemtica de los procesos de negocio, que se deben modelar, automatizar,
integrar, monitorizar y optimizar de forma continua. Bsicamente son servicios y herramientas que
soportan la administracin explicita de procesos: anlisis, definicin, ejecucin y monitoreo.
Browser: Aplicacin de Software usada para buscar y mostrar paginas Web.

90

C
Caso de Uso: es una forma especfica de utilizar el sistema. Un Caso de Uso es una secuencia de
acciones que se realizan dentro del sistema para alcanzar una meta en particular.
Ciclo: Proceso completo de desarrollo esta constituido por fases e iteraciones.
Cliente: Es el que inicia un requerimiento de servicio, e interacta con el usuario.
Confiabilidad: probabilidad de buen funcionamiento de algo.

D
Diagrama: Dibujo geomtrico que sirve para demostrar una proposicin, resolver un problema o
representar de una manera grfica la ley de variacin de un fenmeno.

Diagrama de Actividad: tambin denominado diagrama de estado es el diagrama que captura

el ciclo de vida de los objetos. Este ciclo se expresa en trminos de los estados que los objetos
pueden asumir y los eventos que causan estos cambios de estado.

Diagrama de Casos de Uso: la esencia de este diagrama es capturar los requerimientos que el
usuario tiene del nuevo sistema, detallando todos los escenarios en los que se ve involucrado,
comenzando de cero o desde un sistema ya existente. Este diagrama muestra cmo los actores
que estn en el ambiente se comunican con los Casos de Uso que estn dentro de un sistema.
Dominio del Problema: se refiere al entorno del mundo real de cosas y conceptos relacionados
con el problema que el sistema va a modelar.
Dominio de la Solucin: es el conjunto de conceptos que dan forma a la solucin.

E
Entidad: colectividad considerada como unidad.
Escalabilidad: Es la capacidad de un sistema informtico de adaptarse a un nmero de usuarios
cada vez mayor, sin perder calidad en los servicios. En general, se podra definir como la
capacidad del sistema informtico de cambiar su tamao o configuracin para adaptarse a las
circunstancias cambiantes.
Estndar: que sirve como tipo, modelo, norma, patrn o referencia.
Excepciones: condicin anormal en un programa o proceso.
Explorador: Ver Browser.

F
Fase: parte constitutiva de una iteracin de desarrollo.

91

Fiabilidad: Ver Confiabilidad.

Flujo de Trabajo: Un serie definida de tareas con cierta organizacin que constituyen un
procedimiento cuyo objetivo esta bien definido
Funcionalidad: Cualidad de funcional. Que funciona.

H
Hito: Milestone. Suceso o acontecimiento que sirve como punto de referencia.

I
Implantacin: Accin y efecto de implantar. Encajar, insertar.
Implementacin: Accin y efecto de implementar. Poner en funcionamiento
Informtica: Software requerido para la ejecucin de una Actividad.
Interfaz: Pantallas por las que el usuario de un sistema interacta con el mismo.
ISO 9126: Estndar para medir la calidad de los productos de software.
Iteracin: Repeticin de una actividad o secuencia de actividades para lograr o mejorar un
objetivo planteado.

J
Java: Lenguaje de programacin orientado a objetos independiente de la plataforma;
desarrollado por Sun Microsystems.
JSP: Java Server Pages (JSP) es la tecnologa para generar pginas Web de forma dinmica en el
servidor, desarrollado por Sun Microsystems, basado en scripts que utilizan una variante del
lenguaje java.

M
Mantenibilidad: Propiedad de un sistema que representa la cantidad de esfuerzo requerida para
conservar su funcionamiento normal o para restituirlo una vez se ha presentado un evento de
falla. Se dir que un sistema es "Altamente Mantenible" cuando el esfuerzo asociado a la
restitucin sea bajo. Sistemas poco mantenibles o de "Baja Mantenibilidad" requieren de grandes
esfuerzos para sostenerse o restituirse.
Marco de Trabajo: es una estructura de soporte definida en la cual otro proyecto de software
puede ser organizado y desarrollado.
Metodologa: se refiere a los mtodos de investigacin en una ciencia.
Modelo: Un modelo es una conceptualizacin de un evento, un proyecto, una hiptesis, el estado
de una cuestin, un problema, que se representa como un esquema con smbolos descriptivos de

92

caractersticas y relaciones ms importantes con un fin: ser sometido a modelizacin como un

diseo flexible, que emerge y se desarrolla durante el inicio de la investigacin como una
evaluacin de su relevancia.

Modelo Conceptual: Modelo que representa el dominio del problema.

Modelo de Datos: Un modelo de datos es un sistema formal y abstracto que permite describir
los datos de acuerdo con reglas y convenios predefinidos

Modelo Entidad/Relacin: El modelo entidad-relacin es el modelo conceptual ms utilizado

para el diseo conceptual de bases de datos. Fue introducido por Peter Chen en 1976. El modelo
entidad-relacin est formado por un conjunto de conceptos que permiten describir la realidad
mediante un conjunto de representaciones grficas y lingsticas.
MVC: Model View Controller. Arquitectura de software que separa el modelo de datos, la interfaz
con el usuario y la lgica de una aplicacin, en tres componentes.

O
Oasis: Organization for the Advancement of Structured Information Standards.
Oracle: Es una gran compaa de software que tradicionalmente esta orientada al desarrollo de
software para base de datos.
Orquestar: Combinar servicios Web dentro de una aplicacin.

P
Proceso: es la ejecucin de un conjunto de instrucciones entregadas a la CPU para el
cumplimiento de una etapa especfica sealada por los comandos de algn programa.
Prototipo: Interfaces estticas de un sistema, no conllevan manejo de informacin.
Publicar: poner disponible un servicio Web.

R
Regla de Negocio: Coleccin de las polticas y restricciones de negocio de una organizacin.
Relacin: Ver Modelo Entidad/Relacin.
Requerimiento: Necesidad de un usuario.
RUP: Rational Unified Process. Metodologa para el desarrollo de software de Rational Software
Corporation (actualmente propiedad de IBM).

S
Servidor: Computadora dentro de una red dedicada a un propsito especifico, sea almacenando
informacin o realizando transacciones crticas asociadas a tal propsito.

93

Sistema: grupo de tems independientes que interactan entre si regularmente para realizar una
tarea.
Site: Nombre comnmente utilizado para referirse a un sitio de Internet (Pgina Web).
SOAP: Simple Object Access Protocol. Protocolo ligero para el intercambio de mensajes entre
componentes de software. Su uso esta adherido al paradigma de programacin orientado a
objetos.
Software: Instrucciones computacionales o data. Cualquier cosa que pueda ser guardad
electrnicamente es software.
Struts: es una herramienta de soporte para el desarrollo de aplicaciones Web bajo el patrn MVC
bajo la plataforma J2EE (Java 2, Enterprise Edition). Struts se desarrolla como parte del proyecto
Jakarta de la Apache Software Foundation. Struts permite reducir el tiempo de desarrollo, su
carcter de "software libre" y su compatibilidad con todas las plataformas en donde Java
Entreprise est disponible, lo convierte en una herramienta altamente disponible.

T
Tarea: Unidad constitutiva de un flujo de trabajo.
Tecnologa: Conjunto de teoras y de tcnicas que permiten el aprovechamiento prctico del
conocimiento cientfico.
Transaccin: Accin y efecto de transigir. Relativo a trato o negocio. Una transaccin consiste en
una interaccin con una estructura de datos que, an siendo compleja y estar compuesta por
varios procesos que se han de aplicar uno despus del otro, queremos que se realice de una sola
vez y que la estructura a medio manipular no sea jams alcanzable por el resto del sistema.
Tupla: Las tuplas son estructuras que contienen datos de diferentes tipos.

U
UDDI: Universal Description, Discovery, and Integration. Estndar para marcos de trabajo
independientes de plataforma para la descripcin de servicios en el Internet.
UML: Unified Modeling Language. Lenguaje de especificacin y modelado de tercera generacin.
Usabilidad: es la medida de la facilidad de uso de un producto o servicio.

W
WAD: Workflow Activity Diagram. Diagrama de Actividad especializado en representar flujos de
trabajo.
Web: Relativo al World Wide Web, este es un sistema de servidores de Internet que soportan
documentos especialmente formateados.

94

Web Service: Es un estndar usado para integrar aplicaciones basadas en Web usando los
estndares abiertos XML, SOAP, WSDL, y UDDI sobre el protocolo de la Internet.
WDSL: Web Services Description Language. Formato XML publicado para la descripcin de los
Web Services.
WorkFlow: Ver Flujo de Trabajo.

X
XML: eXtensible Markup Language. Meta lenguaje extensible que habilita el intercambio de
informacin estructurada auto describible, para ser usada en otras aplicaciones o presentaciones.

95

Apndice.
Apndice 1: Especificacin de Lista de Requerimientos Funcionales.
NMERO:
NOMBRE:
DESCRIPCIN:
TIPO:
DETALLES Y
RESTRICCIONES:
VERSIN:
CONDICIN:

NMERO:
NOMBRE:
DESCRIPCIN:
TIPO:
DETALLES Y
RESTRICCIONES:

VERSIN:
CONDICIN:

NMERO:
NOMBRE:
DESCRIPCIN:
TIPO:
DETALLES Y
RESTRICCIONES:

VERSIN:
CONDICIN:

96

Req.1
Capturar, Analizar y Procesar Solicitudes de Procesos de RRHH
El sistema deber ofrecer funcionalidades que permitan ingresar solicitudes de
procesos de recursos humanos, su anlisis, procesamiento y aprobacin.
Funcional
Todo empleado podr realizar solicitudes de procesos de RRHH.
La lgica propia de cada proceso determinara los individuos responsables de cada
tarea del proceso.
1.0
Obligatorio
Req.1.1
Capturar, Analizar y Procesar Solicitudes de Adelanto de Prestaciones
El sistema deber ofrecer funcionalidades que permitan ingresar solicitudes de
adelanto de prestaciones, su anlisis, procesamiento y aprobacin.
Funcional
Solo aquellos empleados que pertenezcan a la nomina podrn realizar solicitudes
de adelanto de prestaciones.
Los individuos participantes en este proceso son:
Los empleados en nomina: Activan el proceso.
Su supervisor inmediato y el gerente del rea: Analizan y aprueban la solicitud.
El Dpto. de RRHH: Analiza la factibilidad de la solicitud.
El Dpto. Administrativo: Emite los pagos correspondientes a las prestaciones.
1.0
Obligatorio
Req.1.2
Capturar, Analizar y Procesar Reclutamiento de Personal
El sistema deber ofrecer funcionalidades que permitan ingresar solicitudes de
reclutamiento de personal, su anlisis, procesamiento y aprobacin.
Funcional
Los individuos participantes en este proceso son:
Supervisor: Hace la solicitud de personal para su rea.
Gerente: Analiza y aprueban la solicitud.
El Dpto. de RRHH: Analiza la factibilidad de la solicitud.
El Dpto. Legal: Realizara la contratacin del candidato escogido.
1.0
Obligatorio

NMERO:
NOMBRE:
DESCRIPCIN:
TIPO:
DETALLES Y
RESTRICCIONES:

VERSIN:
CONDICIN:

NMERO:
NOMBRE:
DESCRIPCIN:
TIPO:
DETALLES Y
RESTRICCIONES:
VERSIN:
CONDICIN:

NMERO:
NOMBRE:
DESCRIPCIN:
TIPO:
DETALLES Y
RESTRICCIONES:

VERSIN:
CONDICIN:

97

Req.1.3
Capturar, Analizar y Procesar Relaciones de Gasto
El sistema deber ofrecer funcionalidades que permitan ingresar las relaciones de
gasto del personal, su anlisis, procesamiento y aprobacin.
Funcional
Los empleados podrn ingresar en cualquier momento su relacin de gastos del
mes, y hacerlo de manera incremental.
La captura de entradas en la relacin de gastos tendr restricciones de tiempo, Ej.
No se aceptan entradas de un mes vencido solo del mes en curso.
El procesamiento de las relaciones de gastos se har mensualmente de forma
automtica por medio del sistema.
Los individuos participantes en este proceso son:
Los empleados: Activan el proceso.
Su supervisor inmediato y el gerente del rea: Analizan y aprueban la relacin de
gastos.
El Dpto. Administrativo: Emite los pagos correspondientes a la relacin de gastos.
1.0
Obligatorio
Req.1.4
Procesamiento de Solicitud de Constancia de Trabajo
El sistema deber ofrecer funcionalidades que permitan ingresar la solicitud de
constancias de trabajo y su procesamiento
Funcional
Los individuos participantes en este proceso son:
Los empleados: Activan el proceso.
Dpto. Legal: Procesa la solicitud.
1.0
Obligatorio
Req.1.5
Capturar, Analizar y Procesar Solicitudes de Cursos de Capacitacin
El sistema deber ofrecer funcionalidades que permitan ingresar solicitudes de
cursos de capacitacin, su anlisis, procesamiento y aprobacin.
Funcional
Los pagos relativos a un curso de capacitacin podrn realizarse mensualmente,
quincenalmente, anualmente o cancelar el curso en su totalidad, por lo tanto el
nmero de pagos relativo a un curso de capacitacin es variable.
Los individuos participantes en este proceso son:
Los empleados en nomina: Activan el proceso.
Su supervisor inmediato y el gerente del rea: Analizan y aprueban la solicitud.
El Dpto. de RRHH: Analiza la factibilidad de la solicitud.
El Dpto. Administrativo: Emite los pagos correspondientes al curso de capacitacin.
1.0
Obligatorio

NMERO:
NOMBRE:
DESCRIPCIN:
TIPO:
DETALLES Y
RESTRICCIONES:

VERSIN:
CONDICIN:

NMERO:
NOMBRE:
DESCRIPCIN:
TIPO:
DETALLES Y
RESTRICCIONES:

VERSIN:
CONDICIN:

NMERO:
NOMBRE:
DESCRIPCIN:
TIPO:
DETALLES Y
RESTRICCIONES:
VERSIN:
CONDICIN:
NMERO:
NOMBRE:
DESCRIPCIN:
TIPO:
DETALLES Y
RESTRICCIONES:

VERSIN:
CONDICIN:

98

Req.1.6
Capturar, Analizar y Procesar Solicitudes de Prstamo
El sistema deber ofrecer funcionalidades que permitan ingresar solicitudes de
prstamo, su anlisis, procesamiento y aprobacin.
Funcional
Los individuos participantes en este proceso son:
Los empleados en nomina: Activan el proceso.
Su supervisor inmediato y el gerente del rea: Analizan y aprueban la solicitud.
El Dpto. de RRHH: Analiza la factibilidad de la solicitud.
El Dpto. Administrativo: Emite los pagos correspondientes a los prestamos.
1.0
Obligatorio
Req.1.7
Capturar, Analizar y Procesar Solicitudes de Vacaciones
El sistema deber ofrecer funcionalidades que permitan ingresar solicitudes de
vacaciones, su anlisis, procesamiento y aprobacin.
Funcional
Las vacaciones podrn ser tomadas con o sin disfrute, con o sin pago.
Si un empleado no ha tomado sus vacaciones en un periodo mayor a un ao
deber notificrsele que debe tomarlas, tambin deber notificrsele a su
supervisor inmediato y al gerente de rea.
Los individuos participantes en este proceso son:
Los empleados: Activan el proceso.
Su supervisor inmediato y el gerente del rea: Analizan y aprueban la solicitud.
El Dpto. de RRHH: Analiza la factibilidad de la solicitud.
El Dpto. Administrativo: Emite los pagos correspondientes a las vacaciones.
1.0
Obligatorio
Req.2
Monitorear Procesos de RRHH
El sistema deber ofrecer funcionalidades que permitan monitorear los procesos
de RRHH; consultar sobre el estado de un proceso (propio y de los subalternos).
Funcional
Todo empleado podr saber el estado de sus propias solicitudes.
Todo supervisor podr saber el estado de los procesos de sus subalternos.
1.0
Obligatorio
Req.3
Generar Reportes sobre los Procesos de RRHH
El sistema deber ofrecer funcionalidades que permitan generar reportes sobre los
procesos de RRHH activados por el sistema.
Funcional
Los reportes sobre los procesos solo podrn ser realizados por la Alta Gerencia.
Los reportes deben ser flexibles y auto-explicativos.
Cada reporte puede generar un documento.
Los reportes pueden ser almacenados.
1.0
Obligatorio

NMERO:
NOMBRE:
DESCRIPCIN:
TIPO:
DETALLES Y
RESTRICCIONES:
VERSIN:
CONDICIN:

Req.4
Gerenciar el Sistema
El sistema deber ser gerenciado por un individuo que tendr la responsabilidad
de mantener los datos del sistema en vigencia.
Funcional
El administrador del sistema podr crear un nuevo usuario, cambiar los perfiles de
usuario, y gerenciar la duracin de los procesos de negocio.
1.0
Obligatorio

Apndice 2: Especificacin de Lista de Requerimientos no Funcionales.

NMERO:
TIPO:
CLASIFICACIN:
SUB-CARACTERISTICA:
DESCRIPCIN:

VERSIN:
CONDICIN:

NMERO:
TIPO:
CLASIFICACIN:
SUB-CARACTERISTICA:
DESCRIPCIN:
VERSIN:
CONDICIN:

NMERO:
TIPO:
CLASIFICACIN:
SUB-CARACTERISTICA:
DESCRIPCIN:

Req.5.1
No Funcional
Requerimiento de Funcionalidad
Seguridad
El sistema deber tener la capacidad de prevenir el acceso desautorizado,
accidental o deliberado, a los programas o a los datos. Los datos manejados
por la aplicacin son confidenciales y debe garantizarse dicha
confidencialidad.
1.0
Obligatorio
Req.5.2
No Funcional
Requerimiento de Funcionalidad
Conveniencia
La aplicacin debe poder ser accesada desde cualquier navegador; Mozilla,
Netscape, Explorer, entre otros.
1.0
Obligatorio

CONDICIN:

Req.5.3
No Funcional
Requerimiento de Funcionalidad
Conveniencia
La aplicacin debe realizar los procesos asociados a RRHH mas rpido que el
que se hace manualmente
1.0
Obligatorio

NMERO:
TIPO:
CLASIFICACIN:
SUB-CARACTERISTICA:
DESCRIPCIN:
VERSIN:
CONDICIN:

Req.6.1
No Funcional
Requerimiento de Fiabilidad
Madurez
La frecuencia de errores, fallas y defectos debe ser mnima
1.0
Obligatorio

VERSIN:

99

NMERO:
TIPO:
CLASIFICACIN:
SUB-CARACTERISTICA:
DESCRIPCIN:

VERSIN:
CONDICIN:

NMERO:
TIPO:
CLASIFICACIN:
SUB-CARACTERISTICA:
DESCRIPCIN:

VERSIN:
CONDICIN:

NMERO:
TIPO:
CLASIFICACIN:
SUB-CARACTERISTICA:
DESCRIPCIN:
VERSIN:
CONDICIN:

NMERO:
TIPO:
CLASIFICACIN:
SUB-CARACTERISTICA:
DESCRIPCIN:
VERSIN:
CONDICIN:

NMERO:
TIPO:
CLASIFICACIN:
SUB-CARACTERISTICA:
DESCRIPCIN:
VERSIN:
CONDICIN:

100

Req.6.2
No Funcional
Requerimiento de Fiabilidad
Tolerancia a fallas
La aplicacin debe mantener un nivel especificado del funcionamiento en
caso de que ocurra una falla de hardware o software; la aplicacin debe
estar disponible los 365 das del ao.
1.0
Obligatorio
Req.6.3
No Funcional
Requerimiento de Fiabilidad
Recuperabilidad
El software debe presentar la capacidad de reestablecer su nivel del
funcionamiento y recuperar los datos directamente afectados en caso de
que ocurra una falla
1.0
Obligatorio
Req.7.1
No Funcional
Requerimiento de Usabilidad
Entendimiento
El esfuerzo de los usuarios para reconocer las funcionalidades del software y
su aplicabilidad debe ser mnimo
1.0
Obligatorio
Req.7.2
No Funcional
Requerimiento de Usabilidad
Operabilidad
El esfuerzo de los usuarios para la operacin y el control de sus operaciones
debe ser mnimo
1.0
Obligatorio
Req.8.1
No Funcional
Requerimiento de Eficiencia
Comportamiento en el tiempo
Los tiempos de respuesta y procesamiento relativos al sistema debe tener
buenas tasas de desempeo
1.0
Obligatorio

NMERO:
TIPO:
CLASIFICACIN:
SUB-CARACTERISTICA:
DESCRIPCIN:

VERSIN:
CONDICIN:

NMERO:
TIPO:
CLASIFICACIN:
SUB-CARACTERISTICA:
DESCRIPCIN:

Req.9.1
No Funcional
Requerimiento de Mantenibilidad
Caractersticas Analizables
El esfuerzo necesario para el diagnostico de deficiencias o de causas de
fallas es mnimo, al igual que el esfuerzo necesario para identificar piezas
del software a modificar en el tiempo
1.0
Obligatorio

CONDICIN:

Req.9.2
No Funcional
Requerimiento de Mantenibilidad
Capacidad de Cambio
El esfuerzo requerido para la modificacin del software, inclusin de un
nuevo componente, retiro de una avera o para el cambio ambiental debe
ser mnimo
1.0
Obligatorio

NMERO:
TIPO:
CLASIFICACIN:
SUB-CARACTERISTICA:
DESCRIPCIN:
VERSIN:
CONDICIN:

Req.9.3
No Funcional
Requerimiento de Mantenibilidad
Estabilidad
El riesgo del efecto de modificaciones de software es manejable
1.0
Obligatorio

NMERO:
TIPO:
CLASIFICACIN:
SUB-CARACTERISTICA:
DESCRIPCIN:
VERSIN:
CONDICIN:

Req.9.4
No Funcional
Requerimiento de Mantenibilidad
Capacidad de Prueba
El esfuerzo necesario para validar el software modificado es mnimo
1.0
Obligatorio

NMERO:
TIPO:
CLASIFICACIN:
SUB-CARACTERISTICA:
DESCRIPCIN:

Req.10.1
No Funcional
Requerimiento de Portabilidad
Adaptabilidad
La flexibilidad para la adaptacin del software a diversos ambientes
especificados sin la aplicacin de mayores acciones
1.0
Obligatorio

VERSIN:

VERSIN:
CONDICIN:

101

Apndice 3: Especificacin de Lista de Riesgos.

NMERO:
NOMBRE:
Magnitud del
riesgo:
DESCRIPCIN:

IMPACTO:
FASE DE IMPACTO:
INDICADORES:
ESTRATEGIA DE
MITIGACIN:
PLAN DE
CONTINGENCIA:

NMERO:
NOMBRE:
Magnitud del
riesgo:
DESCRIPCIN:
IMPACTO:
FASE DE IMPACTO:
INDICADORES:
ESTRATEGIA DE
MITIGACIN:
PLAN DE
CONTINGENCIA:
NMERO:
NOMBRE:
Magnitud del
riesgo:
DESCRIPCIN:
IMPACTO:
FASE DE IMPACTO:
INDICADORES:
ESTRATEGIA DE
MITIGACIN:
PLAN DE

102

Risk.1
No contar con los recursos tcnicos para desarrollar a tiempo el sistema.
Alta
Si los recursos tcnicos para la realizacin del proyecto no estn disponibles ser
imposible cumplir con los objetivos establecidos. Los recursos tcnicos son
aquellos requeridos para el desarrollo e implantacin del sistema, esto incluye
hardware y software necesario para culminar las tareas establecidas.
Sin los recursos tcnicos ser imposible cerrar ninguna iteracin. El proceso se
detendr en la fase de construccin.
Fase de Construccin
Los recursos estn disponibles cuando son necesarios.
Los recursos tcnicos necesarios estn bien definidos.
En caso que el riesgo se materialice, debern buscarse recursos tcnicos
alternativos. La ausencia total de recursos imposibilita el proyecto y debe ser
abortado.
Risk.2
Cambio de nuevas versiones de las herramientas asociadas a ORACLE BPEL
Alta
Debido a que ORACLE BPEL es una herramienta totalmente nueva las nuevas
versiones son una realidad a la que el proyecto tendr que ajustarse.
Las versiones sucesivas quizs no son del todo compatibles
Fase de Construccin y Fase de Transicin.
Ante una nueva versin, la versin del sistema implementada no se adapta a la
nueva versin de BPEL.
Usar como nica versin tecnolgica la actualmente disponible
En el caso de que sea necesario usar las nuevas versiones de BPEL, ajustar el
plan de iteracin para el cambio de versin.
Risk.3
Inexperiencia relativa al uso de BPEL como tecnologa de desarrollo.
Alta
Debido a que ORACLE BPEL es una herramienta totalmente nueva el
entrenamiento para el uso de la tecnologa puede tornarse difcil, traducindose
en retraso en las fases de construccin.
Si el entrenamiento no es efectivo el proyecto puede sufrir retrasos
Fase de Construccin
Las fases de construccin toman ms tiempo del esperado.
Estipular en el plan de iteracin el entrenamiento en la tecnologa.
Uso extensivo de los foros de ayuda disponibles en la pgina oficial de ORACLE,
y tutora especial de parte de conocedores de la tecnologa (tutor industrial).
Asegurarse que el cdigo generado es debidamente inspeccionado y probado.
En el caso de que sea el entrenamiento tome ms tiempo del esperado, ajustar

CONTINGENCIA:

el plan de iteracin para el desarrollo de la aplicacin.

NMERO:
NOMBRE:
Magnitud del
riesgo:
DESCRIPCIN:

Risk.4
El sistema no es apropiadamente probado en cada iteracin.
Mediana

IMPACTO:

FASE DE IMPACTO:
INDICADORES:
ESTRATEGIA DE
MITIGACIN:
PLAN DE
CONTINGENCIA:
NMERO:
NOMBRE:
Magnitud del
riesgo:
DESCRIPCIN:

IMPACTO:

FASE DE IMPACTO:
INDICADORES:

ESTRATEGIA DE
MITIGACIN:

PLAN DE

103

En cada iteracin, el producto resultado no es pasado por un plan de pruebas

riguroso.
Si los productos sucesivos no estn debidamente probados los problemas
pueden ser arrastrados hasta una fase de liberacin o los problemas son
detectados muy tarde y los costos para repararlos son inmanejables.
Fase de Construccin, Fase de Transicin.
Deteccin de errores, defectos o fallas.
Incluir en cada plan de iteracin un riguroso plan de pruebas.
En el caso de los problemas encontrado no puedan solventarse hacer una
iteracin completa solo para realizar pruebas.
Risk.5
Crecimiento incontrolado de los requerimientos del usuario.
Alta
Si el nmero de requerimientos crece de forma descontrolada o los
requerimientos ya identificados cambian a travs del tiempo, es probable que no
sea posible implementar todos los casos de uso en las fases de construccin. La
satisfaccin del usuario final es el principal indicador de xito del proyecto y los
requerimientos representan sus necesidades.
Si los objetivos no son cumplidos, el proyecto habr terminado de forma
incompleta no satisfaciendo los requerimientos del usuario final. Si los nuevos
requerimientos son muy complejos o muy alejados del diseo original el tiempo
de implementacin puede salirse del tiempo inicialmente estipulado.
Fase de Inicio, Elaboracin, y Construccin
El usuario realiza nuevos requerimientos que se traducen en nuevos casos de
uso.
El nmero de casos de uso diseado es igual al nmero de casos de uso
implementados.
Todos los requerimientos del sistema son cubiertos por los casos de uso
implementados.
El riesgo se convertir en palpable si ocurren retrasos significativos en los planes
de iteracin diseados.
Los productos de las iteraciones no satisfacen al usuario; los prototipos
presentados al usuario son evaluados negativamente por este.
En cada iteracin la lista de requerimientos es revisada y actualizada, si los
cambios ocurren debe de medirse el impacto de tiempo sobre las actividades
pautadas o la definicin de nuevas actividades.
La delimitacin de objetivos, el alcance, y los planes de iteracin debern ser
cuidadosamente rediseados.
El plan de iteracin deber ser constantemente revisado para monitorear las
actividades de desarrollo, y ajustado de ser necesario.
El uso de prototipos.
La constante evaluacin de los productos sucesivos por parte del usuario.
En caso que el riesgo se materialice, deber disearse un nuevo plan de

CONTINGENCIA:

iteracin para el futuro, con la idea de cerrar el ciclo de desarrollo para el

periodo de 20 semanas planteado para la realizacin del proyecto. Si los
cambios en los requerimientos y los casos de uso son muy grandes, establecer
nuevas prioridades y establecer un nuevo plan de iteracin.

Apndice 4: Especificacin de Lista Casos de Uso.

Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:
Curso Normal

Curso Alterno

Post-condicin:
Referencias Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:
Curso Normal

CU-1 Iniciar Sesin

Empleado.
Entrar al sistema
El usuario inserta a travs del teclado su nombre de usuario y su clave. El
sistema hace las verificaciones necesarias y el usuario entra al sistema.
Primario y esencial.
Ninguna
Accin del Actor
Accin del Sistema
1. Introduce nombre
de usuario y la clave,
enviar.
2. Valida la combinacin nombre de usuario /
clave. Le permite al usuario entrar al sistema.
Mensaje de xito.
Accin del Actor
Accin del Sistema
2.1. Mensaje de error: Combinacin nombre de
usuario / clave incorrecto.
El usuario ha abierto una sesin valida para el sistema
Ninguna.

Curso Alterno

CU-2 Cerrar Sesin

Empleado.
Cerrar una sesin del sistema
El usuario termina una sesin del sistema
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Accin del Actor
Accin del Sistema
1. Selecciona la opcin de
cerrar sesin.
2. Cierra la sesin del usuario.
Accin del Actor
Accin del Sistema

Post-condicin:
Referencias Cruzadas:

El usuario ha cerrado una sesin valida para el sistema.

Ninguna.

Nombre:
Actores:
Propsito:
Resumen:

CU-3 Cambiar Clave

Empleado.
Cambiar la clave personal de usuario
El usuario selecciona el cambio de clave, se identifica su identidad y se
efecta el cambio
Secundario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Accin del Actor
Accin del Sistema

Tipo:
Pre-condiciones:
Curso Normal

104

Selecciona cambiar clave.

2. Solicitar datos para el cambio de
clave.
3. Ingresa su antigua clave, y la
nueva clave junto con su
confirmacin.

Curso Alterno

Post-condicin:
Referencias Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:

Curso Normal

Curso Alterno

Post-condicin:
Referencias Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:

105

4. Valida la combinacin nombre de

usuario / clave y la nueva clave con su
confirmacin. El cambio se efecta. Se
le notifica al usuario del xito de la
operacin.
Accin del Actor
Accin del Sistema
4.1. Mensaje de error: Combinacin
nombre de usuario / clave incorrecto.
4.2. Mensaje de error: Clave nueva
invlida; mnimo de 6 caracteres.
4.3 Mensaje de error: La nueva clave
no concuerda con la confirmacin.
El usuario ha cambiado su clave personal
Ninguna.
CU-4 Monitorear Estado de Solicitudes
Empleado.
Monitorear el estado en el que se encuentra una solicitud de RRHH
realizada por el usuario o alguno de sus subalternos.
El usuario selecciona ver el estado las solicitudes realizadas y se le
presenta informacin como su estado, su presunto tiempo de finalizacin,
sus notificaciones asociadas, etc.
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Todo empleado podr monitorear las solicitudes propias.
Los supervisores y gerentes no solo podrn consultar las propias
solicitudes si no tambin las de los subalternos.
Accin del Actor
Accin del Sistema
1. Selecciona monitorear estado
de solicitudes.
2. Identificar los procesos activados por
el usuario y sus subalternos y
mostrarlo.
Accin del Actor
Accin del Sistema
2.1. Mensaje: El usuario no ha activado
ningn proceso.
2.2. Mensaje: sus subalternos no han
activado ningn proceso.
El usuario ha monitoreado los procesos activos
Req.1, Req.2
CU-5 Consultar Tareas Asignadas
Empleado.
Consultar las tareas que le han sido asignadas
El usuario selecciona ver sus tareas asignadas, se le presentan todas sus
tareas a realizar y la opcin de efectuarlas.
Primario y esencial.

Pre-condiciones:
Curso Normal

Curso Alterno

Post-condicin:
Referencias Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:

El usuario debe haber iniciado una sesin en el sistema (CU - 1).

Accin del Actor
Accin del Sistema
1. Selecciona consultar sus
tareas asignadas.
2. Identificar las tareas asignadas a
este usuario. Mostrar las tareas
asignadas (fecha de inicio, su
responsable, documentos asociados,
...)
Accin del Actor
Accin del Sistema
2.1. Mensaje: El usuario no tiene
ninguna tarea asignada.
El usuario ha consultado sus tareas asignadas
Req.1

Curso Alterno

CU-5.1 Realizar Tarea Asignada

Empleado.
Realiza una tarea asignada
El usuario selecciona realizar una de sus tareas asignadas
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
El usuario debe haber activado el caso de uso Consultar Tareas Asignadas
(CU - 5)
Si el responsable de una tarea asignada no cumple con su tarea en el
tiempo estipulado por el proceso, se generara una notificacin de alerta
para s mismo y para el supervisor inmediato.
Accin del Actor
Accin del Sistema
1. Selecciona una de sus tareas
asignadas para realizarla
2. Identificar las tareas seleccionadas.
Realiza la tarea. Mensaje de xito. Ver:
CU8.1, CU8.2, CU8.3 CU9, CU11,
CU12, CU13,
Accin del Actor
Accin del Sistema

Post-condicin:
Referencias Cruzadas:

El usuario ha realizado su tarea asignada

Req.1, Req.1.1, Req.1.2, Req.1.3, Req.1.4, Req.1.5, Req.1.6, Req.1.7

Nombre:
Actores:
Propsito:
Resumen:

CU-5.2 Abrir Documentos Asociados

Empleado.
Solicita abrir un documento asociado a un proceso de RRHH.
Para cada tarea de los procesos de RRHH implementados que genere un
documento, los documentos se pueden leer, editar e imprimir.
Secundario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Debe haberse activado un proceso de RRHH que gener documentos.
Accin del Actor
Accin del Sistema

Curso Normal

Tipo:
Pre-condiciones:
Curso Normal

106

1.
Selecciona
documento.

editar

un
Muestra el documento correspondiente
a la edicin.

3.
Edita
el
documento,
selecciona guardar.
Curso Alterno

Accin del Actor

3.1 Edita el documento, no
selecciona guardar.

4. El documento se guarda.
Accin del Sistema
3.2 Pregunta si desea descartar el
documento.

3.3 Responde.
Post-condicin:
Referencias Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:
Curso Normal

Curso Alterno

Post-condicin:
Referencias Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:

107

3.4 Acta en consecuencia guardndolo

o descartndolo. Cierra el editor.
El usuario ha ingresado una solicitud de vacaciones, constancia de
trabajo, cursos de capacitacin, de prestaciones o de prstamos.
Ninguno
CU-5.2.1 Editar Documento
Empleado.
Solicita editar un documento.
Para cada tarea de los procesos de RRHH implementados que genere un
documento, este caso de uso ser invocado para la edicin de los
templeates disponibles.
Secundario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Debe haberse activado un proceso de RRHH que genere documentos.
Accin del Actor
Accin del Sistema
1.
Selecciona
editar
un
documento.
Muestra el documento correspondiente
a la edicin.
3.
Edita
el
documento,
selecciona guardar.
4. El documento se guarda.
Accin del Actor
Accin del Sistema
3.1 Edita el documento, no
selecciona guardar.
3.2 Pregunta si desea descartar el
documento.
3.3 Responde.
3.4 Acta en consecuencia guardndolo
o descartndolo. Cierra el editor.
El usuario ha ingresado una solicitud de vacaciones, constancia de
trabajo, cursos de capacitacin, de prestaciones o de prstamos.
Ninguno
CU-5.2.2 Imprimir
Empleado.
Solicita imprimir un documento.
El usuario selecciona imprimir un documento asociado a un proceso de
RRHH.

Tipo:
Pre-condiciones:
Curso Normal

Curso Alterno
Post-condicin:
Referencias Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:
Curso Normal

Curso Alterno
Post-condicin:
Referencias Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:

108

Secundario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Accin del Actor
Accin del Sistema
1. Selecciona imprimir un
documento.
2.
Muestra
el
documento
correspondiente a la impresin. Solicita
reconfirmacin de impresin.
3. Confirma la impresin
4. El documento se imprime.
Accin del Actor
Accin del Sistema
3.1 Cancela la impresin
El usuario ha ingresado una solicitud de vacaciones, constancia de
trabajo, cursos de capacitacin, de prestaciones o de prstamos.
Ninguno
CU-6 Ingresar Solicitud
Empleado.
Ingresar una solicitud de RRHH
El usuario selecciona ingresar una solicitud de RRHH. Las solicitudes
posibles son de vacaciones, constancia de trabajo, cursos de capacitacin,
de prestaciones o de prstamos.
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Accin del Actor
Accin del Sistema
1. Selecciona ingresar una
solicitud.
2.
Muestra
el
formulario
correspondiente a la solicitud.
3.
Llena
los
datos
del
formulario, enva.
4. Guarda Solicitud a la BD. La solicitud
es registrada iniciando un nuevo
proceso de RRHH y se asignan las
tareas necesarias para que se realice el
proceso. Mensaje de xito. Invoca CU4.
Accin del Actor
Accin del Sistema
4.1. Mensaje: Datos incompletos.
El usuario ha ingresado una solicitud de vacaciones, constancia de
trabajo, cursos de capacitacin, de prestaciones o de prstamos.
Req.1, Req.1.1, Req.1.3, Req.1.4, Req.1.5, Req.1.6, Req.1.7

CU-7 Generar Notificacin

Empleado.
Genera notificaciones editables aprobacin, rechazo, contratacin, de
entrevista y alertas
El usuario genera una notificacin asociada a un proceso de RRHH
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
El empleado debi activar el caso de uso Realizar Tarea Asignada (CU 5.1)
Las notificaciones de contratacin y entrevista replican la notificacin va mail.

Curso Normal

Curso Alterno
Post-condicin:
Referencias
Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:
Curso Normal

Curso Alterno

Post-condicin:
Referencias
Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:
Curso Normal

109

Debe haberse activado un proceso de RRHH que genere notificaciones.

Accin del Actor
Accin del Sistema
1.
Selecciona
generar
una
notificacin editable.
2.
Se presenta el template de
notificacin dependiendo del caso.
3. Se edita la notificacin, enva.
4. La notificacin es guardada asociada
a un proceso de RRHH en marcha.
Accin del Actor
Accin del Sistema
El usuario ha ingresado una solicitud de vacaciones, constancia de trabajo,
cursos de capacitacin, de prestaciones o de prstamos.
Req.1, Req.1.1, Req.1.3, Req.1.5, Req.1.6, Req.1.7

CU-8 Ingresar Relacin de Gastos

Empleado.
Ingresar una relacin de gastos
El usuario selecciona ingresar una relacin de gastos, las relaciones de gasto
se ingresan por tuplas y se hace de manera incremental a travs del tiempo.
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Accin del Actor
Accin del Sistema
1. Selecciona ingresar una tupla de
la relacin de gastos.
2. Solicita los datos necesarios para la
insercin de la tupla.
3. Llena los datos necesarios, enva.
4. almacena la tupla de la relacin de
gastos. Mensaje de xito.
Accin del Actor
Accin del Sistema
4.1. Mensaje: Datos incompletos.
4.2 Mensaje de error: Ha excedido el
mximo de estacionamiento.
El usuario ha ingresado una relacin de gastos
Req.1, Req.1.3

CU-9 Monitorear Procesos Asignados a los Subalternos

Supervisor.
Consultar los procesos de RRHH asignados a los subalternos
El usuario selecciona monitorear procesos asignados a los subalternos, los
procesos terminados y los que aun no han terminado.
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Accin del Actor
Accin del Sistema

1. Selecciona consultar los procesos

de
RRHH
asignados
a
sus
subalternos.

Curso Alterno

Post-condicin:
Referencias
Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:
Curso Normal

Curso Alterno
Post-condicin:
Referencias
Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:

Curso Normal

110

2. Determinar los subalternos del

supervisor, mostrar tareas de RRHH
asignadas a los subalternos.
Accin del Actor
Accin del Sistema
2.1. Mensaje: Sus subalternos no
tienen tareas asignadas.
El usuario ha consultado los procesos de RRHH asignados a sus subalternos.
Req.2, Req. 3

CU-10 Solicitar Personal

Supervisor
Definir el perfil de una vacante en su rea
El usuario selecciona definir perfil de vacante
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
El supervisor debi activar el caso de uso Realizar Tarea Asignada (CU 5.1)
Accin del Actor
Accin del Sistema
1. Selecciona definir un perfil de
vacante
Solicita todos los datos relativos a la
vacante.
3. Ingresa los datos necesarios,
enva.
4. Se almacena el perfil de la vacante.
Mensaje de xito.
Accin del Actor
Accin del Sistema
El usuario ha ingresado un perfil de vacante
Req.1, Req.1.2

CU-11 Aprobar Informacin Curricular

Supervisor, Ente RRHH.
Aprobar la informacin curricular de un candidato previamente solicitado
El usuario selecciona aprobar la informacin curricular de un candidato
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Debe existir un proceso de solicitud de personal activado en el que el
supervisor debe cumplir una tarea de aprobacin de informacin curricular.
El supervisor se le ha asignado una tarea de aprobacin relativa a una
solicitud de personal.
Un supervisor solo podr aprobar la informacin curricular de un candidato
que previamente ha solicitado.
El supervisor debi activar el caso de uso Realizar Tarea Asignada (CU
5.1)
Accin del Actor
Accin del Sistema

1.
Selecciona
candidato.

aprobar

un
Muestra todos los datos relativos a la
informacin del candidato.

3. Aprueba el curriculum, y enva

su respuesta con los comentarios
correspondientes.

Curso Alterno

Accin del Actor

3.1 Desaprueba el curriculum, y
enva su respuesta con los
comentarios correspondientes.

4. Se almacena la aprobacin y los

comentarios
correspondientes.
Mensaje de xito.
Accin del Sistema

3.2 Se almacena la desaprobacin y

los comentarios correspondientes.
Mensaje de xito. Enva notificacin
de rechazo.
Post-condicin:
Referencias Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:

Curso Normal

Curso Alterno

111

El usuario ha aprobado el curriculum

Req.1, Req.1.2
CU-12 Entrevistar Candidato
Supervisor, Ente RRHH.
Sealar que se ha entrevistado un candidato a personal, e ingresar los
datos relativos a la entrevista.
El usuario selecciona entrevistar candidato
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Debe existir un proceso de solicitud de personal activado en el que el
supervisor debe cumplir una tarea de entrevista. El supervisor se le ha
asignado una tarea de entrevista relativa a una solicitud de personal.
Un supervisor solo entrevistar un candidato que previamente ha
solicitado.
El supervisor debi activar el caso de uso Realizar Tarea Asignada (CU
5.1)
Accin del Actor
Accin del Sistema
1.
Selecciona
entrevistar
candidato.
Muestra todos los datos relativos al
candidato y a la entrevista (fecha,
hora...).
3. seala la entrevista como
exitosa, y enva su respuesta con
los comentarios correspondientes.
4. Se almacena la aprobacin y los
comentarios
correspondientes.
Mensaje de xito.
Accin del Actor
Accin del Sistema

3.1 Desaprueba la entrevista, y

enva su respuesta con los
comentarios correspondientes.
3.2 Se almacena la desaprobacin y
los comentarios correspondientes.
Mensaje de xito. Enva notificacin
de rechazo.
Post-condicin:
Referencias Cruzadas:

El usuario ha aprobado la entrevista

Req.1, Req.1.2

Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:

CU-13 Aprobar Candidato

Supervisor.
Aprobar un Candidato previamente solicitado
El usuario selecciona aprobar un candidato a personal
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Debe existir un proceso de solicitud de personal activado en el que el
supervisor debe cumplir una tarea de aprobacin. El supervisor se le ha
asignado una tarea de aprobacin relativa a una solicitud de personal.
Un supervisor solo aprobara un candidato que previamente ha solicitado.
El supervisor debi activar el caso de uso Realizar Tarea Asignada (CU
5.1)
Accin del Actor
Accin del Sistema
1. Selecciona aprobar un
candidato.
Muestra todos los datos relativos al
candidato.
3. Aprueba al candidato, y enva
su
respuesta
con
los
comentarios correspondientes.
4. Se almacena la aprobacin y los
comentarios correspondientes. Mensaje
de xito.
Accin del Actor
Accin del Sistema
3.1 Desaprueba al candidato, y
enva su respuesta con los
comentarios correspondientes.
3.2 Se almacena la desaprobacin y los
comentarios correspondientes. Mensaje
de xito. Enva notificacin de rechazo.
El usuario ha aprobado un candidato
Req.1, Req.1.2

Curso Normal

Curso Alterno

Post-condicin:
Referencias Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:

112

CU-14 Aprobar Solicitud

Supervisor.
Aprobar una solicitud de RRHH
El usuario selecciona aprobar una solicitud de RRHH, la solicitud puede ser
de curso de capacitacin, prestaciones, prstamos, o vacaciones.
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Debe existir un proceso de solicitud activado en el que el supervisor debe
cumplir una tarea de aprobacin. El supervisor se le ha asignado una tarea
de aprobacin relativa a una solicitud de RRHH.

Curso Normal

Curso Alterno

Post-condicin:
Referencias Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:

Curso Normal

Curso Alterno

Post-condicin:
Referencias Cruzadas:

113

Un supervisor solo podr aprobar una solicitud que ha sido generada por un
subalterno.
El supervisor debi activar el caso de uso Realizar Tarea Asignada (CU
5.1)
Accin del Actor
Accin del Sistema
1.
Selecciona
aprobar
una
solicitud.
Muestra todos los datos relativos a la
solicitud.
3. Aprueba la solicitud, y enva su
respuesta con los comentarios
correspondientes.
4. Se almacena la aprobacin y los
comentarios
correspondientes.
Mensaje de xito.
Accin del Actor
Accin del Sistema
3.1 Desaprueba la solicitud, y
enva su respuesta con los
comentarios correspondientes.
3.2 Se almacena la desaprobacin y los
comentarios
correspondientes.
Mensaje de xito. Enva notificacin de
rechazo.
El usuario ha aprobado una solicitud de curso de capacitacin, prestaciones,
prstamos, o vacaciones.
Req.1, Req.1.1, Req.1.2, Req.1.3, Req.1.4, Req.1.5, Req.1.6, Req.1.7
CU-15 Confirmacin de Reintegro de un Subalterno
Supervisor.
Indicar que un subalterno ha regresado de vacaciones
El usuario indica la fecha en la que el empleado se reintegra al trabajo
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Debe existir un proceso de solicitud de vacaciones activado en el que el
supervisor debe cumplir una tarea de confirmacin de reintegro. El
supervisor se le ha asignado una tarea de confirmacin de reintegro de un
subalterno.
El supervisor debi activar el caso de uso Realizar Tarea Asignada (CU
5.1)
Accin del Actor
Accin del Sistema
1. Selecciona confirmar el
reintegro de un subalterno.
Muestra todos los datos relativos a las
vacaciones del reintegro, solicita fecha real de
reintegro y comentarios.
3. Ingresa los datos
necesarios, enva.
Accin del Actor

4. Se almacenan los datos. Mensaje de xito.

Accin del Sistema
4.1 Mensaje: la fecha de reintegro se ha
excedido.
Se ha confirmado un reintegro de vacaciones.
Req.1, Req.1.2

Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:

Curso Normal

Curso Alterno

Post-condicin:
Referencias Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:
Curso Normal

Curso Alterno

114

CU-16 Aprobar Relacin de Gastos

Supervisor.
Aprobar una solicitud de RRHH
El usuario selecciona aprobar las tuplas de una relacin de gastos
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Debe existir un proceso de solicitud activado en el que el supervisor debe
cumplir una tarea de aprobacin. El supervisor se le ha asignado una tarea
de aprobacin relativa a una solicitud de RRHH.
Un supervisor solo podr aprobar una solicitud que ha sido generada por un
subalterno.
El supervisor debi activar el caso de uso Realizar Tarea Asignada (CU
5.1)
Accin del Actor
Accin del Sistema
1.
Selecciona
aprobar
una
relacin de gastos.
Muestra todos los datos relativos a la
relacin de gastos.
3. Aprueba las tuplas de la
relacin de gastos.
4. Se almacena la relacin de gastos
con el estado de aprobacin de cada
una de sus tuplas. Mensaje de xito.
Accin del Actor
Accin del Sistema
3.1 Desaprueba la solicitud, y
enva su respuesta con los
comentarios correspondientes.
3.2 Se almacena la desaprobacin y los
comentarios correspondientes. Mensaje
de xito. Enva notificacin de rechazo.
El usuario ha aprobado las tuplas de una relacin de gastos
Req.1, Req.1.3
CU-17 Consultar Procesos de RRHH
Gerente, Empleado
Consultar los procesos de RRHH que se estn realizando y los ya realizados.
El usuario selecciona consultar los procesos de RRHH de la compaa
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Los nicos empleados que podrn tener acceso a la consulta de los procesos
de RRHH son aquellos que estn autorizados por el sistema.
Accin del Actor
Accin del Sistema
1. Selecciona consultar los
procesos de RRHH.
2. Se le muestra al usuario los filtros de
bsqueda posibles.
3. El usuario llena los filtros para
su consulta, la consulta es
dinmica. Enva la consulta.
4. Se buscan los resultados de la
consulta y se muestran al usuario.
Accin del Actor
Accin del Sistema

Post-condicin:
Referencias Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:
Curso Normal

4.1. Mensaje: Su bsqueda es vaca.

El usuario ha consultado los procesos de RRHH de la empresa.
Req.2, Req. 3
CU-17.1 Solicitar Reporte
Gerente, Empleado
Solicitar un reporte sobre los procesos de RRHH de la empresa
El usuario selecciona realizar un reporte
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
El usuario debe haber activado el caso de uso Consultar Procesos de RRHH
(CU 12)
Accin del Actor
Accin del Sistema
Selecciona realizar un reporte.
Se realiza un reporte basado en la
bsqueda previamente realizada. Se
genera un documento que puede ser
almacenado. Se muestra el documento.
3.
Selecciona
que
desea
guardarlo, determina la ruta.

Curso Alterno

Accin del Actor

3.1 Selecciona que no desea
guardar el documento.

4. Se almacena el documento. Mensaje

de xito.
Accin del Sistema
3.2 Se vuelve al resultado obtenido en
CU-12.

Post-condicin:
Referencias Cruzadas:

El usuario ha generado un reporte

Req.2, Req. 3

Nombre:
Actores:
Propsito:

CU-18 Emitir Pagos y/o Recibos

Ente Administrativo.
Procesar solicitudes administrativas que son generadas por procesos de
RRHH, como lo son las solicitudes de vacaciones, prestaciones, prstamos o
cursos de capacitacin.
El usuario selecciona procesar un pago y/o generara un recibo producto de
un proceso de RRHH.
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Debe existir un proceso de solicitud activado en el que el ente
administrativo debe cumplir una tarea de pago o emisin de recibos. El
ente administrativo se le ha asignado una tarea administrativa relativa a
una solicitud de RRHH.
El supervisor debi activar el caso de uso Realizar Tarea Asignada (CU
5.1)
Accin del Actor
Accin del Sistema
Selecciona emitir un pago o
recibo.
2. El sistema emite el recibo
correspondiente. Guarda los datos del
proceso.
Accin del Actor
Accin del Sistema

Resumen:
Tipo:
Pre-condiciones:

Curso Normal

Curso Alterno

115

Post-condicin:
Referencias Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:

El usuario ha realizado las tareas administrativas relativas a la solicitud de

vacaciones, prestaciones, prstamos o cursos de capacitacin.
Req.1, Req.1.1, Req.1.3, Req.1.5, Req.1.6, Req.1.7

Curso Alterno

CU-19 Contratar Candidato

Ente Legal.
Contratar un candidato
El usuario selecciona contratar un candidato a personal
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Debe existir un proceso de solicitud de personal activado en el que el ente
legal debe cumplir una tarea de contratacin. El ente legal se le ha
asignado una tarea de contratacin relativa a una solicitud de personal.
El supervisor debi activar el caso de uso Realizar Tarea Asignada (CU
5.1)
Accin del Actor
Accin del Sistema
1.
Selecciona
contratar
un
candidato.
2. Muestra todos los datos relativos
al candidato, y se solicitan los datos
necesarios para el contrato. Se
presenta un template de contrato
editable por el usuario.
3. Edita el template, y lo imprime.
Accin del Actor
Accin del Sistema

Post-condicin:
Referencias Cruzadas:

El usuario ha aprobado un candidato

Req.1, Req.1.2

Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:

Curso Alterno

CU-20 Emitir Constancia de Trabajo

Ente Legal.
Emitir Constancia de Trabajo
El usuario selecciona emitir una constancia de trabajo
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Debe existir un proceso de solicitud de constancia de trabajo activado en
el que el ente legal debe cumplir una tarea de emisin. El ente legal se le
ha asignado una tarea de emisin de constancia de trabajo.
El supervisor debi activar el caso de uso Realizar Tarea Asignada (CU
5.1)
Accin del Actor
Accin del Sistema
1. Seleccin emitir una constancia
de trabajo.
2. El sistema procesa la solicitud, e
imprime una constancia de trabajo.
Accin del Actor
Accin del Sistema

Post-condicin:
Referencias Cruzadas:

El usuario emitido una constancia de Trabajo

Req.1, Req.1.4

Nombre:
Actores:

CU-21 Identificar Recursos

Ente RRHH.

Curso Normal

Curso Normal

116

Propsito:

Resumen:
Tipo:
Pre-condiciones:

Curso Normal

Curso Alterno

Post-condicin:
Referencias Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:

Curso Normal

Determinar la factibilidad de una solicitud identificando los recursos

necesarios luego que el proceso de RRHH termine. Esto incluye solicitudes
de prstamo, prestaciones, vacaciones, cursos de capacitacin, y
reclutamiento.
El usuario selecciona identificar recursos.
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Debe existir un proceso de solicitud de RRHH activado en el que deban
identificarse recursos. El ente RRHH se le ha asignado una tarea de
identificacin de recursos.
El ente de RRHH debi activar el caso de uso Realizar Tarea Asignada (CU
5.1)
Accin del Actor
Accin del Sistema
1. Seleccin identificar recursos.
Muestra los recursos necesarios para
dicha solicitud.
3.
Selecciona
recursos
identificados, enva.
4. Almacena que los recursos han
sido identificados. Mensaje de xito.
Accin del Actor
Accin del Sistema
3.1 Selecciona recursos no
identificados, enva.
3.2 Almacena que los recursos no
han sido identificados. Mensaje de
xito. Enva notificacin de rechazo.
El usuario los recursos necesarios para un solicitud de RRHH.
Req.1, Req.1.4
CU-22 Seleccionar Candidato
Ente RRHH.
Sealar que se ha identificado un candidato para una vacante
El usuario selecciona seleccionar candidato
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Debe existir un proceso de solicitud de personal activado en el que el ente
de RRHH debe cumplir una tarea de seleccin de candidato. El ente de RRHH
se le ha asignado una tarea de seleccin de candidato.
El supervisor debi activar el caso de uso Realizar Tarea Asignada (CU 5.1)
Accin del Actor
Accin del Sistema
1. Selecciona seleccionar candidato.
Solicita los
candidato.

datos

relativos

al

3. Ingresa los datos, enva.

4. Se almacenan los datos. Mensaje
de xito.
Accin del Sistema

Curso Alterno

Accin del Actor

Post-condicin:
Referencias
Cruzadas:

El usuario ha seleccionado un candidato para una vacante.

Req.1, Req.1.2

117

Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:

Curso Normal

CU-23 Informe de Seguimiento de Cursos de Capacitacin

Ente RRHH.
Crea un informe basado en el curso de capacitacin realizado por un
determinado empleado.
El usuario selecciona realizar un informe de seguimiento de cursos de
capacitacin.
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Debe existir un proceso de curso de capacitacin activado sobre el cual se
pueda realizar un informe de seguimiento. El ente RRHH se le ha asignado
una tarea de realizacin de informe de seguimiento de curso de
capacitacin.
El ente de RRHH debi activar el caso de uso Realizar Tarea Asignada (CU
5.1)
Accin del Actor
Accin del Sistema
1. Seleccin realizar informe de
seguimiento
de
curso
de
capacitacin.
Se solicitan los datos necesarios para
realizar en informe.
3. Llena los datos necesarios, enva.
4. Almacena los datos relativos al
informe de seguimiento. Mensaje de
xito.
Accin del Sistema

Curso Alterno

Accin del Actor

Post-condicin:

El usuario ha realizado un informe de seguimiento de cursos de

capacitacin.
Req.1, Req.1.4

Referencias
Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:
Curso Normal

Curso Alterno
Post-condicin:
Referencias
Cruzadas:

118

CU-24 Cambiar Perfil Empleado

Administrador del Sistema.
Actualizar datos relativos al empleado y en especial su posicin en la
estructura organizativa.
El usuario cambia los datos previamente cargados sobre el usuario.
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Accin del Actor
Accin del Sistema
1. El usuario solicita cambiar un
perfil de empleado.
Solicita los datos necesarios.
3. El usuario cambia los datos que
desea cambiar, enva.
4. Almacena los nuevos datos.
Mensaje de xito.
Accin del Actor
Accin del Sistema
El usuario ha abierto una sesin valida para el sistema
Req. 4

Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:
Curso Normal

CU-25 Crear Usuario

Administrador del Sistema.
Crea un nuevo usuario del sistema este debe ser un empleado de la
empresa.
El Administrador del Sistema crea un nuevo usuario del sistema
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Accin del Actor
Accin del Sistema
1. El usuario solicita crear un
usuario.
Solicita los datos mnimos necesarios.
3. El usuario llena los datos, enva.
4. Almacena los
Mensaje de xito.
Accin del Sistema

nuevos

datos.

Curso Alterno

Accin del Actor

Post-condicin:
Referencias
Cruzadas:

El usuario ha abierto una sesin valida para el sistema

Req. 4

Nombre:
Actores:
Propsito:
Resumen:
Tipo:
Pre-condiciones:
Curso Normal

CU-26 Cambiar Ventanas de Tiempo de los Procesos

Administrador del Sistema.
Cambiar Ventanas de tiempo de los procesos
El Administrador del Sistema cambia las ventanas de tiempo de los procesos
Primario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Accin del Actor
Accin del Sistema
1. El usuario solicita cambiar las
ventanas de tiempo de un proceso.

3. El usuario edita los tiempos

establecidos por tarea, enva los
cambios

Curso Alterno

Post-condicin:
Referencias
Cruzadas:
Nombre:
Actores:
Propsito:
Resumen:

119

Se muestran todos los procesos

posibles del sistema y sus tareas,
cada tarea con su tiempo establecido
para cumplirse.

4. Los tiempos establecidos por tarea

se actualizan. Mensaje de xito.
Accin del Actor
Accin del Sistema
4.1 Mensaje de error: tiempos
incongruentes.
El usuario ha abierto una sesin valida para el sistema
Req. 4

CU-27 Determinar Acceso al Reporteador

Administrador del Sistema.
Determina que empleados a parte de los usuarios gerentes tienen acceso al
reporteador
El Administrador del Sistema determina el acceso al reporteador

Tipo:
Pre-condiciones:
Curso Normal

Curso Alterno
Post-condicin:
Referencias
Cruzadas:

Secundario y esencial.
El usuario debe haber iniciado una sesin en el sistema (CU - 1).
Accin del Actor
Accin del Sistema
1. El usuario solicita determinar el
acceso al reporteador.
Se muestran todos los empleados del
sistema
que
tiene
acceso
al
reporteador y aquellos que no.
3. El usuario selecciona aquellos
que podrn tener acceso al
reporteador.
4. Se almacena la informacin.
Mensaje de xito.
Accin del Actor
Accin del Sistema
El usuario ha determinado cuales empleados tienen acceso al reporteador
Req. 4

Apndice 5: Plan de Trabajo para el Primer Ciclo de Desarrollo.

S
01
02
03

Actividades
-

Introduccin a Develcom Sistemas, C.A

Revisin del Plan de Trabajo
Adiestramiento: tutoriales, documentos, cursos.
Adiestramiento: tutoriales, documentos, cursos.
Realizar plan de iteracin
Levantamiento de Requerimientos.
Anlisis del problema.

Revisar plan de iteracin

Instalacin del ambiente de desarrollo.
Modelado de la solucin.
Justificacin de la solucin.
Definicin de la arquitectura.
Revisin de requerimientos.
Prototipo inicial de interfaz.
Definir el plan de Construccin.
Revisin de Riesgos

Iteracin/
Fase
1/Inicio
1/Inicio
1/Inicio

04
05

06
07
08
09

120

1/Elaboracin

Entregables

- Documento Visin.
- Caso de negocio.
- Lista de
requerimientos
- Lista de riesgos
- Diagrama conceptual.
- Diagrama preliminar
de Casos de uso.
- Glosario del proyecto.
- Plan de Proyecto
- Diagrama especificado
de Casos de Uso
- Diagramas WAD.
- Mapa de navegacin.
- Plan de Construccin
- Modelos de Base de
Datos

10
11
12
13
14
15
16
17
18
19
20

- Revisar plan de iteracin

- Implementacin de un prototipo funcional (50%
de las funcionalidades)
- Revisar lista de requerimientos
- Actualizar diagramas
- Feedback usuario final ante las funcionalidades
implementadas
- Revisin de requerimientos.
- Revisin de Riesgos
- Revisar plan de iteracin
- Implementacin de un prototipo funcional (100%
de las funcionalidades)
- Actualizar diagramas
- Revisin de requerimientos.
- Revisin de Riesgos
- Beta Testing
- Unificar Documentos; de desarrollo, instalacin y
usuarios
- Plan de Prxima Iteracin.
- Terminar libro de Pasanta

2/Elaboracin - Diagramas
1/Construccin Actualizados

2/Construccin

1/Transicin

Apndice 6: Plan de Trabajo para el Segundo Ciclo de Desarrollo.

S
01

02
03
04
05
06

Actividades

Iteracin/
Fase
1/Inicio
1/ Elaboracin

- Revisin del Plan de Trabajo

- Revisin y Ajuste de Requerimientos; Diagramas y
Documentacin
- Revisin de Lista de Riesgos.
- Pase de los procesos BPEL, clases Java y paginas 1/Construccin
JSP implementados a la nueva versin de BPEL
1/Transicin
Process Manager.
- Establecer la conexin a la Base de Datos del
negocio.
- Probar la aplicacin con la nueva versin de BPEL
Process Manager.

Entregables
- Lista de Riesgos.
- Plan del ciclo
revisado.
- Diagramas revisados.

- Implementar la comunicacin que falta entre 2/Construccin

interfaz y los procesos BPEL.
2/Transicin
- Realizar pruebas finales del ciclo.

Apndice 7: Plan de Trabajo para el Tercer Ciclo de Desarrollo.

S

Actividades

01

- Revisin del Plan de Trabajo

- Revisin y Ajuste de Requerimientos; Diagramas y
Documentacin
- Revisin de Lista de Riesgos.
- Implementarlos requerimientos restantes.

02
03
04

121

- Revisin de requerimientos no funcionales

- Pruebas del ciclo.

Iteracin/
Fase
1/Inicio
1/ Elaboracin
1/ Elaboracin
1/Construccin
1/Construccin
1/Transicin

Entregables
- Lista de Riesgos.
- Plan del ciclo
revisado.
- Diagramas revisados.

Apndice 8: Plan de Trabajo para el Cuarto Ciclo de Desarrollo.

S
01

02

Actividades

Iteracin/
Fase
1/Inicio
1/ Elaboracin

- Revisin del Plan de Trabajo

- Revisin y Ajuste de Requerimientos; Diagramas y
Documentacin
- Revisin de Lista de Riesgos.
- Revisin de requerimientos no funcionales.
1/Construccin
- Pase al ambiente de Produccin
1/Transicin
- Pruebas del ciclo; Trafico.
- Entrenamiento de usuarios finales.

Entregables
- Lista de Riesgos.
- Plan del ciclo
revisado.
- Diagramas revisados.

Apndice 9: Pantallas del Prototipo.

Solicitar Constancia de Trabajo

Una ves el usuario haya ingresado al sistema, podr solicitar una constancia de trabajo
clickeando sobre el botn que sale en la mitad llamado Solicitar.

Solicitar Prestaciones
Una ves el usuario haya ingresado al sistema, podr solicitar sus prestaciones ingresando

el porcentaje de sus prestaciones que desea y luego clickeando sobre el botn que sale en la
mitad llamado Solicitar.

122

Solicitar Vacaciones

Una ves el usuario haya ingresado al sistema, podr solicitar sus vacaciones indicando si
las vacaciones sern con pago, con disfrute o ambas. Si las vacaciones son con pago deber
indicar a que ao es correspondiente el pago, si son con disfrute deber indicar la fecha de inicio

123

y la fecha de fin de su disfrute. Luego podr enviar su solicitud clickeando sobre el botn que sale
en la mitad llamado Solicitar.

Solicitar Curso de Capacitacin

Una ves el usuario haya ingresado al sistema, podr solicitar un curso de capacitacin

ingresando el nombre del curso, la institucin, la fecha de inicio del curso y la fecha de fin, la
descripcin del curso, los beneficios que le aportara el curso, el horario de clases, y la forma de
pago si el curso es pago, luego podr enviar su solicitud clickeando sobre el botn que sale en la
mitad llamado Solicitar.

Solicitar Personal
Una ves el usuario haya ingresado al sistema, podr solicitar personal siempre que el

usuario sea un supervisor. El usuario debe ingresar el nombre del cargo, las caractersticas
tcnicas del cargo, las competencias, y si se desea la profesin requerida, los aos de experiencia,

124

el sexo, y el mximo y mnimo de la edad requerida, luego podr enviar su solicitud clickeando
sobre el botn que sale en la mitad llamado Solicitar.

125

Ilustraciones.
Ilustracin 1: Desarrollo Iterativo de Software.

Ilustracin 2: Gestin de Requerimientos.

126

Ilustracin 3: Protagonistas en la Integracin de Sistemas.

Ilustracin 4: Oracle BPEL un ejemplo de Integracin.

127

Ilustracin 5: Notacin Estndar propuesta por ISO/IEC 9126.

128

Ilustracin 6: Interfaces del Sistema.

129

Ilustracin 7: Flujos de Procesos Implementados en Oracle BPEL.

Proceso de Ponderacin de Relaciones de Gasto.

130

Parte del Proceso de Solicitud de Prestaciones.

131

Ilustracin 8: Model, View, Controller.

132

Anexo.
Anexo 1: Extending UML Activity Diagram for Workflow Modelling in Production Systems.

133

134

135

136

137

138

139

140

141

142

143

Anexo 2: Ten Pillars for World Class Business Process Management

144