DESARROLLO DE UN PROTOTIPO DE SOFTWARE...
218
DESARROLLO DE UN PROTOTIPO DE SOFTWARE WEB CON INTEGRACIÓN DE PROCESOS DE WORKFLOW PARA AUTOMATIZAR LAS TAREAS DE “REALIZACIÓN DE SERVICIO” EN UNA EMPRESA DE ASISTENCIA VIAL CARLOS JULIO ORTIZ TRIANA RONALD AUGUSTO ORTIZ CRUZ UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS BOGOTÁ – COLOMBIA 2015
-
Upload
nguyenkhue -
Category
Documents
-
view
219 -
download
0
Transcript of DESARROLLO DE UN PROTOTIPO DE SOFTWARE...
DESARROLLO DE UN PROTOTIPO DE SOFTWARE WEB CON INTEGRACIÓN DEPROCESOS DE WORKFLOW PARA AUTOMATIZAR LAS TAREAS DE
“REALIZACIÓN DE SERVICIO” EN UNA EMPRESA DE ASISTENCIA VIAL
CARLOS JULIO ORTIZ TRIANARONALD AUGUSTO ORTIZ CRUZ
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDASFACULTAD DE INGENIERÍAINGENIERÍA DE SISTEMAS
BOGOTÁ – COLOMBIA2015
DESARROLLO DE UN PROTOTIPO DE SOFTWARE WEB EN TRES CAPAS CONINTEGRACIÓN DE PROCESOS DE WORKFLOW PARA AUTOMATIZAR LAS TAREAS
DE “REALIZACIÓN DE SERVICIO” EN UNA EMPRESA DE ASISTENCIA VIAL
CARLOS JULIO ORTIZ TRIANA
RONALD AUGUSTO ORTIZ CRUZ
Proyecto final de grado en modalidad de trabajo de grado para optar por el título de Ingeniero de Sistemas
DIRECTOR:
Ing. Oswaldo Alberto Romero
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDASFACULTAD DE INGENIERÍAINGENIERÍA DE SISTEMAS
BOGOTÁ – COLOMBIA2015
Nota de aceptación
_________________________________________________________________
_________________________________________________________________
Firma del Jurado
____________________________
Contenido1. LISTA DE FIGURAS ........................................................................................................... 13
2. LISTA DE TABLAS............................................................................................................. 15
1. INTRODUCCIÓN................................................................................................................. 17
2. GLOSARIO........................................................................................................................... 19
CAPITULO I - PRELIMINARES................................................................................................ 21
3. DEFINICIÓN DEL PROBLEMA......................................................................................... 21
4. JUSTIFICACIÓN.................................................................................................................. 29
5. ALCANCES Y LIMITACIONES......................................................................................... 31
6. OBJETIVOS.......................................................................................................................... 33
6.1 OBJETIVO GENERAL.....................................................................................................................33
6.2 OBJETIVOS ESPECÍFICOS..............................................................................................................33
CAPITULO II - ANALISIS DEL SISTEMA............................................................................... 35
7 MARCO TEÓRICO .............................................................................................................. 35
7.1 LOS SISTEMAS ESTRATÉGICOS DE INFORMACIÓN......................................................................35
7.2 ARQUITECTURA DE SOFTWARE ..................................................................................................37
7.2.1 Arquitectura Multicapas. ....................................................................................................38
7.3 SOA (Service Oriented Architecture) .......................................................................................41
7.3.1 Web Services .......................................................................................................................42
7.4 BPM (Business Process Management) ........................................................................................43
7.4.1 Objetivos de BPM................................................................................................................45
7.4.2 Dimensiones de BPM ..........................................................................................................45
7.4.3 BPMN (Business Process Management Notation) ..............................................................46
7.5 WORKFLOW ................................................................................................................................47
7.5.1 Workflow Reference Model................................................................................................48
8 MARCO REFERENCIAL .................................................................................................... 51
8.1 Soluciones de negocio soportadas en procesos de Workflow ...................................................53
9 DISEÑO METODOLOGICO ............................................................................................... 54
9.1 PROCEDIMIENTO.........................................................................................................................54
9.2 METODOLOGÍA INGENIERIL ........................................................................................................56
10 ANALISIS Y DISEÑO DEL SISTEMA........................................................................... 59
10.1 REQUERIMIENTOS ESPECIFICOS DE INTERFACES ............................................... 59
10.1.1 INTERFACES DE USUARIO........................................................................................................59
10.1.2 INTERFACES DE HARDWARE ...................................................................................................59
10.1.3 INTERFACES SOFTWARE..........................................................................................................60
11 REQUERIMIENTOS DE PERSISTENCIA ..................................................................... 60
12 CARACTERIZACIÓN DEL PROTOTIPO DE SOFTWARE ......................................... 61
12.1 REQUERIMIENTOS FUNCIONALES...............................................................................................62
12.2 REQUERIMIENTOS NO FUNCIONALES.........................................................................................63
CAPITULO III – DISEÑO DEL SISTEMA......................................................................... 67
13 MODELO ESTRUCTURAL BASADO EN CASOS DE USO........................................ 67
13.1 ACTORES......................................................................................................................................68
13.2 MODULO GESTIÓN DE USUARIOS...............................................................................................70
13.2.1 ESPECIFICACIÓN DE CASOS DE USO........................................................................................71
13.2.1.1 CASO DE USO: Crear usuario..........................................................................................71
13.2.1.2 CASO DE USO: Registrar datos ........................................................................................73
13.2.1.3 CASO DE USO: Crear rol .................................................................................................74
13.2.1.4 CASO DE USO: Cambiar rol de usuario............................................................................76
13.2.1.5 CASO DE USO: Eliminar usuario ......................................................................................79
13.2.1.6 CASO DE USO: Buscar usuario.........................................................................................81
13.3 MODULO GESTIÓN DE FACTURAS...............................................................................................83
13.3.1 ESPECIFICACIÓN DE CASOS DE USO........................................................................................84
13.3.1.1 CASO DE USO: Calcular costo de servicio........................................................................84
13.3.1.2 CASO DE USO: Consultar datos de servicio.....................................................................86
13.3.1.3 CASO DE USO: Generar factura.......................................................................................89
13.4 MODULO GESTIÓN DE ACCESO...................................................................................................92
13.4.1 ESPECIFICACIÓN DE CASOS DE USO........................................................................................93
13.4.1.1 CASO DE USO: Abrir aplicación .......................................................................................93
13.4.1.2 CASO DE USO: Iniciar Sesión ...........................................................................................95
13.4.1.3 CASO DE USO: Configurar entorno de acuerdo al rol .....................................................97
13.4.1.4 CASO DE USO: Cambiar contraseña ................................................................................99
13.4.1.5 CASO DE USO: Cerrar sesión .........................................................................................102
13.4.1.6 CASO DE USO: Cerrar aplicación ...................................................................................105
13.5 MODULO GESTIÓN DE SERVICIOS.............................................................................................106
13.5.1 ESPECIFICACIÓN DE CASOS DE USO......................................................................................107
13.5.1.1 CASO DE USO: Registrar datos del servicio ...................................................................107
13.5.1.2 CASO DE USO: Asociar cliente.......................................................................................110
13.5.1.3 CASO DE USO: Asociar Operario ...................................................................................112
13.5.1.4 CASO DE USO: Asignar vehículo ....................................................................................114
13.5.1.5 CASO DE USO: Crear servicio ........................................................................................117
13.5.1.6 CASO DE USO: Consultar disponibilidad .......................................................................119
13.5.1.7 CASO DE USO: Modificar datos del servicio..................................................................122
13.5.1.8 CASO DE USO: Cambiar estado del servicio..................................................................124
13.5.1.9 CASO DE USO: Buscar servicio ......................................................................................127
13.5.1.10 CASO DE USO: Agregar evento......................................................................................128
13.5.1.11 CASO DE USO: Cancelar servicio ...................................................................................131
13.5.1.12 CASO DE USO: Solicitar servicio ....................................................................................134
13.6 BOCETOS VISUALES DE LA INTERFAZ GRÁFICA DE USUARIO....................................................137
13.6.1 Iniciar sesión .....................................................................................................................137
13.6.2 Crear usuario.....................................................................................................................138
13.6.3 Registrar datos ..................................................................................................................138
13.6.4 Crear rol ............................................................................................................................139
13.6.5 Buscar usuario...................................................................................................................140
13.6.6 Editar roles ........................................................................................................................141
13.6.7 Calcular costo de servicio..................................................................................................141
13.6.8 Crear servicio ....................................................................................................................142
13.6.9 Asignar cliente al servicio..................................................................................................142
13.6.10 Confirmación datos servicio..........................................................................................143
14 MODELO ESTRUCTURAL........................................................................................... 145
14.1 DIAGRAMA DE CLASES ..............................................................................................................145
14.1.1 GESTIÓN DE ACCESO.........................................................................................................146
14.1.2 GESTIÓN DE USUARIOS .....................................................................................................147
14.1.3 GESTIÓN DE SERVICIOS .....................................................................................................148
14.1.4 DICCIONARIO DE CLASES...................................................................................................149
15 MODELO WORKFLOW................................................................................................ 153
15.1 IDENTIFICACIÓN DE PROCESOS.................................................................................................153
15.1.1 Consulta disponibilidad recursos. .....................................................................................153
15.1.2 Asignar Operario. ..............................................................................................................154
15.1.3 Registro gastos de servicio................................................................................................154
15.1.4 Generación factura ...........................................................................................................154
15.2 DISEÑO DE MODELO WORKFLOW ............................................................................................155
16 MODELO DE BASE DE DATOS .................................................................................. 159
16.1 ENTIDADES ................................................................................................................................160
16.2 DICCIONARIO DE DATOS ...........................................................................................................161
CAPITULO IV – DESPLIEGUE ............................................................................................... 169
17 MANUAL DE USUARIO............................................................................................... 169
17.1 Aplicación Web .........................................................................................................................169
17.2 Administración ..........................................................................................................................169
17.2.1 Creación Usuario...............................................................................................................170
17.3 Administración de Roles .......................................................................................................171
17.3.2 Consulta de Roles..............................................................................................................172
17.3.3 Consulta y edición de usuarios..........................................................................................173
17.3.4 Edición de Roles ................................................................................................................174
17.4 Registro de Servicios operador Call Center (BPM)....................................................................175
CAPITULO V – CONCLUSIONES Y RECOMENDACIONES.............................................. 183
18 REVISIÓN Y CIERRE.................................................................................................... 183
18.1 Caso de prueba 1. .....................................................................................................................183
18.2 Caso de prueba 2. .....................................................................................................................184
18.3 Caso de prueba 3. .....................................................................................................................184
18.4 Caso de prueba 4. .....................................................................................................................185
19 CONCLUSIONES Y RECOMENDACIONES .............................................................. 187
20 BIBLIOGRAFÍA ............................................................................................................. 189
ANEXO 1 Herramientas tecnológicas para la implementación de Workflow ........................... 191
Oracle Workflow ...............................................................................................................................192
Intalio BPM........................................................................................................................................192
Servidores de Workflow....................................................................................................................193
ANEXO 2 DESPLIEGUE DE COMPONENTES ..................................................................... 197
1. LISTA DE FIGURAS
Figura 1 Mapa de Procesos típicos de realización del servicio Empresa LST (Logística alservicio del transporte). Fuente propia.......................................................................................... 25Figura 2 Arquitectura de tres capas, [.NET Architecture guide, 2011] ........................................ 38Figura 3 Estructura trasversal del negocio. [HITPASS, 2012] ..................................................... 44Figura 4 Estructura genérica de Workflow. [HOLLINGSWORTH, 2005].................................. 49Figura 5 Modelo estructural- Módulos casos de uso .................................................................... 67Figura 6, Actores del sistema....................................................................................................... 68Figura 7 Modulo gestión de usuarios............................................................................................ 70Figura 8 - Diagrama de actividades crear usuario ........................................................................ 72Figura 9 - Diagrama de actividades registrar datos ..................................................................... 74Figura 10 - Diagrama de actividades crear rol.............................................................................. 76Figura 11 - Diagrama de actividades cambiar rol de usuario ....................................................... 78Figura 12 - Diagrama de actividades eliminar usuario ................................................................. 81Figura 13 - Diagrama de actividades buscar usuario .................................................................... 83Figura 14 - Modulo gestión de facturas ........................................................................................ 84Figura 15 - Diagrama de actividades calcular costo de servicio................................................... 86Figura 16 - Diagrama de actividades consultar datos de servicio................................................. 89Figura 17 - Diagrama de actividades generar factura ................................................................... 91Figura 18-Modulo gestión de acceso ............................................................................................ 92Figura 19- Diagrama de actividades abrir aplicación ................................................................... 94Figura 20 - Diagrama de actividades iniciar sesión ...................................................................... 97Figura 21 - Diagrama de actividades configurar entorno de acuerdo al rol.................................. 99Figura 22- Diagrama de actividades cambiar contraseña ........................................................... 102Figura 23 - Diagrama de actividades cerrar sesión ..................................................................... 104Figura 24 - Diagrama de actividades cerrar aplicación .............................................................. 106Figura 25 - Modulo gestión de servicios..................................................................................... 107Figura 26- Diagrama de actividades registrar datos del servicio ............................................... 110Figura 27- Diagrama de actividades asociar cliente ................................................................... 112Figura 28- Diagrama de actividades asociar operario................................................................ 114Figura 29- Diagrama de actividades asignar vehículo ................................................................ 116Figura 30- Diagrama de actividades crear servicio..................................................................... 119Figura 31 - Diagrama de actividades consultar disponibilidad................................................... 121Figura 32 - Diagrama de actividades modificar datos del servicio............................................. 124Figura 33- Diagrama de actividades cambiar estado del servicio............................................... 126Figura 34- Diagrama de actividades buscar servicio .................................................................. 128
Figura 35- Diagrama de actividades agregar evento................................................................... 131Figura 36- Diagrama de actividades cancelar servicio ............................................................... 134Figura 37- Diagrama de actividades solicitar servicio................................................................ 136Figura 38 Boceto visual iniciar sesión ........................................................................................ 137Figura 39 Boceto visual crear usuario ........................................................................................ 138Figura 40 Boceto visual registrar datos ..................................................................................... 139Figura 41 Boceto visual crear rol................................................................................................ 140Figura 42 Boceto visual buscar usuario ...................................................................................... 140Figura 43 Boceto visual editar roles ........................................................................................... 141Figura 44 Boceto visual calcular costo servicio ......................................................................... 141Figura 45 Boceto visual crear servicio........................................................................................ 142Figura 46 Boceto visual Asignar cliente al servicio ................................................................... 142Figura 47 Boceto visual confirmación datos servicio................................................................. 143Figura 48 Módulos modelo estructural ....................................................................................... 145Figura 49 Diagrama de clases módulo gestión de acceso........................................................... 146Figura 50 Diagrama de clases módulo gestión de usuarios ........................................................ 147Figura 51 Diagrama de clases módulo gestión de servicios ....................................................... 148Figura 52 Diseño del modelo Workflow .................................................................................... 155Figura 53 Modelo de base de datos............................................................................................. 159Figura 54 Creación de ususario................................................................................................... 170Figura 55 Interfaz creación de usuario........................................................................................ 170Figura 56 Menú crear roles ......................................................................................................... 171Figura 57 Campos creación roles............................................................................................... 172Figura 58 Menu consultar roles .................................................................................................. 172Figura 59 Interfaz datos roles ..................................................................................................... 173Figura 60 Menu consultar usuarios............................................................................................. 173Figura 61Interfaz consulta usuario.............................................................................................. 174Figura 62Resultados consulta usuarios ....................................................................................... 174Figura 63Interfaz asignación roles.............................................................................................. 175Figura 64interfaz asignar rol ....................................................................................................... 175Figura 65 Interfaz acceso BPM................................................................................................... 176Figura 66 Interfaz gestión de procesos ....................................................................................... 177Figura 67 Interfaz asignar recursos............................................................................................. 178Figura 68 Interfaz inicio de servicio .......................................................................................... 179Figura 69 Interfaz mensaje inicio servicio.................................................................................. 179Figura 70 Interfaz terminación servicio ...................................................................................... 180Figura 71 Interfaz registro de gastos........................................................................................... 180Figura 72 Interfaz generar factura............................................................................................... 181Figura 73 Cantidad de errores por Sprint.................................................................................... 186
2. LISTA DE TABLAS
Tabla 1 Requerimientos de persistencia ....................................................................................... 61Tabla 2 Requerimientos funcionales............................................................................................. 63Tabla 3 Requerimientos no funcionales ………………………..…………………….………….63
1. INTRODUCCIÓN
La información que fluye al interior de las empresas está en continuo crecimiento y requiere un
tratamiento sistematizado para ser gestionada adecuadamente de manera que permita, por un lado,
apoyar todos los procesos operativos, y por otro, soportar la toma de decisiones estratégicas de
negocio.
Este trabajo se muestra el desarrollo realizado para la elaboración de un prototipo de software web
con integración de procesos de Workflow para la sistematización de procesos operativos asociados
a la empresa de asistencia vial LST (Logística al servicio del transporte) enfocado a que se le
facilite a la empresa el prestar un servicio oportuno a sus clientes de manera que permita aumentar
su competitividad dentro del mercado. Esta empresa presta servicios de traslado de vehículos, taller
grúa, conductor elegido y transporte de carga; para la prestación de dichos servicios se tienen
plataformas de contacto como call center y correo electrónico en donde son canalizados los
servicios solicitados por los clientes y mediante los cuales también se realiza el monitoreo del
estado de cada una de las solicitudes de servicio.
Con la sistematización de los procesos operativos se espera que la empresa sea capaz de superar
los retos relacionados con conseguir la flexibilidad y agilidad necesarias para adaptarse a los
rápidos y continuos movimientos del mercado, aumentando la satisfacción de sus clientes y
mejorando la toma de decisiones de negocio.
En la primera parte de este documento se muestra la contextualización del caso de estudio que fue
abordado en el desarrollo de este proyecto en donde se contempla la definición del problema, los
alcances y limitaciones y la justificación para la elaboración el software propuesto inicialmente,
además se encuentra la definición de los objetivos por los cuales se rige el desarrollo del proyecto.
En el segundo capítulo se realiza el análisis del sistema donde se contempla la contextualización
del mismo dentro de un entorno teórico/académico dando una breve descripción de los elementos
que se trabajaran en el desarrollo del proyecto como los son BPM y Workflow, también
encontraremos el diseño metodológico que será utilizado así como un previo análisis y diseño del
sistema en donde se establecen los requerimientos funcionales y no funcionales del sistema
pasando por las interfaces que se requieren para el desarrollo del mismo. En el capítulo tres se
muestra el diseño del sistema abordando el modelo funcional cuyo diseño está basado en los casos
de uso obtenidos del análisis de requerimientos realizado en la fase anterior, el modelo estructural
donde se pueden observar los cuatro módulos propuestos para la elaboración del software y el
modelo de base de datos que permitirá administrar la persistencia de la información del sistema.
En el capítulo cuatro se muestra el proceso necesario para la ejecutar el despliegue del prototipo
de software elaborado de manera que pueda ser utilizado para la ejecución de pruebas funcionales
y de desempeño. Por ultimo en el capítulo cinco se muestran los resultados de las pruebas
realizadas al prototipo de software, las conclusiones y recomendación y los posibles trabajos
futuros que pueden ser abordados tomando como punto de partida los diseños y el prototipo que
se elaboró.
2. GLOSARIO
BPM: Business Process Management, es un conjunto de herramientas y métodos para representar,
analizar y controlar procesos de negocio, combinando las tecnologías de la información y procesos
de gobierno
BPMN: Business Process Modeling Notation o BPMN (en español Notación para el Modelado
de Procesos de Negocio) es una notación gráfica estandarizada que permite el modelado de
procesos de negocio
PROCESOS DE “REALIZACIÓN DEL SERVICIO”: Secuencia de procesos necesarios para
la prestación de los servicios misionales de la empresa de asistencia vial, que cubre desde el
momento en que un cliente solicita el servicio hasta la culminación del mismo.
SCRUM: Es una metodología para la gestión y desarrollo de software basada en un proceso
iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.
SOA: Arquitectura Orientada a Servicios (en inglés Service Oriented Architecture), es un concepto
de arquitectura de software que define la utilización de servicios para hacer más flexible el
mantenimiento de soluciones de negocio.
UML: Lenguaje Unificado de Modelado (por sus siglas en inglés, Unified Modeling Language) es
el lenguaje de modelado de sistemas software más conocido y utilizado en la actualidad; está
respaldado por el OMG (Object Management Group).
WORKFLOW: Es el estudio de los aspectos operacionales de una actividad de trabajo, cómo se
estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo
fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de las
tareas.
WSO2: Es un servidor de Business Process de código abierto enfocado a soportar una arquitectura
orientada a servicios.
CAPITULO I - PRELIMINARES
3. DEFINICIÓN DEL PROBLEMA
La empresa de asistencia vial LST es una empresa dedicada a la prestación de servicios de traslado
de vehículos, taller grúa, conductor elegido y transporte de carga. Esta empresa cuenta con
vehículos tipo grúas, vehículos de carga y vehículos de desplazamiento. Para la prestación de sus
servicios, la empresa LST se encuentra afiliada a las aseguradoras de vehículos quienes son los
principales clientes, aunque también prestan servicios a personas particulares sin que sea un
requisito que estén afiliados a una aseguradora.
Dentro de los servicios que presta LST están:
1. Asistencia vial: servicio de asistencia en carretera a cualquier tipo de vehículo.
2. Traslado de vehículos: traslado de vehículos livianos que son movilizados en grúas
tipo plataforma y vehículos pesados que son movilizados en grúas tipo pluma desde
y a cualquier lugar del país.
3. Carro taller: proporciona el servicio de suministro de combustible y atención a
fallos mecánicos básicos.
4. Conductor elegido: servicio de movilización de vehículos a solicitud del usuario
desde y a cualquier lugar del país.
5. Cerrajería: apertura de puertas vehículos y domiciliarias
6. Carga: movimiento de equipos y herramientas catalogados como carga.
Las empresa cuenta con un call center y un correo electrónico para recepción de llamadas y correos
electrónicos, operando las 24 horas los 7 días de la semana en donde son canalizadas las solicitudes
de servicios de acuerdo a la necesidad del usuario (aseguradoras o personas naturales), siendo
estos canales de comunicación, además, el mecanismo de contacto de los usuarios con la empresa
para estar monitoreando permanentemente el estado de cada uno de los servicios solicitados.
Dentro de los procesos que se manejan en las empresas de asistencia vial se destacan los “procesos
de realización de servicio” que son los que están ligados directamente a la prestación de servicios
al cliente. Estos procesos de negocio están divididos en dos grupos:
Procesos para la gestión de operaciones
1. Disponibilidad de recursos para la prestación de los servicios, se realiza una consulta de
los automóviles y grúas disponibles para prestar un servicio.
2. Asignación de los operarios al servicio, se realiza una consulta de los recursos humanos
disponibles para ser asignados a la prestación de un servicio.
3. Contacto para asignación de servicios, se hace un contacto telefónico con el operario
asignado a la prestación del servicio.
4. Liquidación de los servicios prestados, se registran el kilometraje recorrido y los gastos
generados durante la prestación del servicio.
5. Generación de factura para el servicio, se genera la factura con la totalidad del valor de la
prestación del servicio.
6. Control de los gastos y costos de los vehículos, se realiza a diario registrando el gasto de
gasolina e insumos para los vehículos que prestan los servicios.
Procesos para la gestión de los clientes
7. Atención al cliente y recepción del servicio, se registran los datos para la prestación del
servicio.
8. Contacto para información del servicio, se realiza una consulta con los operarios de los
vehículos para conocer cuál es el estado del servicio.
9. Contacto para culminación del servicio, se realiza el contacto del operario con el call
center para informar de la culminación del servicio.
En la Figura 1 de la página siguiente se muestra el flujo de los procesos de realización del servicio
y la relación que existe entre ellos.
En este flujo se muestran los procesos de realización de servicio existentes en LST. Este flujo inicia
cuando el cliente envía la solicitud del servicio, en la empresa se realiza el registro del servicio
solicitado, el operador del call center realiza la verificación de la disponibilidad de los operarios
y los vehículos para la prestación del servicio solicitado. En caso de que no haya disponibilidad
para el servicio, se envía una notificación al cliente informándole; si por el contrario hay
operadores y vehículos disponibles, el despachador se encarga de asignar el operario y el vehículo
al servicio.
Por su parte el operador del call center envía una notificación al cliente informándole que la
prestación del servicio ha iniciado y le envía los datos tanto del vehículo como del operador
asignado al servicio. En algunos casos el cliente se comunica con la empresa para solicitar
información sobre el estado en el cual se encuentra el servicio, el operador del call center se
comunica con el operario asignado al servicio y solicita la información, el operador indica si ya
está en el lugar del servicio, si está trasladando el vehículo o si ya culminó el servicio.
Luego de que se culmina el servicio, el operador diligencia un documento donde indica el
kilometraje recorrido durante el servicio y los gastos causados por la prestación del servicio. Con
base en la información que el operario diligencia, el despachador liquida el valor del servicio para
posteriormente generar la factura respectiva que será enviada al cliente. Por último se envía la
notificación al cliente que el servicio culminó, comunicándole si se presentó algún evento fuera de
lo común durante la prestación de éste.
Figura 1 Mapa de Procesos típicos de realización del servicio Empresa LST (Logística al servicio del transporte). Fuente propia
Estos procesos que intervienen en el flujo no se encontraban documentados de ninguna manera lo
que ocasionaba que se ejecutaran de manera subjetiva ya que en la medida que el personal de la
empresa va cambiando, la forma en que se ejecutan puede cambiar.
Previo al desarrollo de esta aplicación LST no contaba con una herramienta sistematizada para el
registro, atención y consulta de las solicitudes de servicio o para el control de los procesos de
realización de servicio. Los procesos y procedimientos se hacían manualmente y dependian
exclusivamente de la persona que esté a cargo de dicha labor, lo cual conllevaba a que no se
pudiera disponer de información que permitiera gestionar oportunamente las actividades diarias
dentro de la empresa generando retrasos en la atención de las solicitudes de servicios hechas por
los usuarios.
Otra de las consecuencias derivadas de estos problemas era la dificultad para la toma de decisiones
ya que estas dependian estrictamente de quien esté a cargo de la empresa en dicho momento, lo
que genera altos riesgos para la empresa y no permite que dichas decisiones sean confiables,
oportunas y que sean tomadas acorde con la misión y la visión empresarial.
4. JUSTIFICACIÓN
La gestión y automatización de procesos de negocio y recursos empresariales juega un papel
fundamental para que las empresas se puedan enfrentar a la economía actual, generando un control
completo de los procesos, visibilidad del estado de la empresa para la correcta toma de decisiones
y orientación estratégica para la consecución de objetivos a corto y largo plazo. BPM surge
entonces como una propuesta metodológica y tecnológica para dar respuesta a la necesidad
creciente de flexibilización y automatización de procesos de negocio de tal manera que le permita
a las empresas agilidad y eficiencia operacional.
El desarrollo de este proyecto representa la oportunidad de poner en práctica los conocimientos y
experiencia adquirida durante nuestra formación planteando una solución al manejo automatizado
de procesos empresariales. Se realizó la construcción de un prototipo de software para la
automatización e integración de los procesos operativos, administrativos y de toma de decisiones
de la empresa de asistencia vial LST de forma que se puedan manejar eficientemente todos los
flujos de información, tanto internos como externos, permitiendo que se mejoren los tiempos de
respuesta y la calidad de los servicios prestados por la empresa mejorando la imagen institucional.
Con el control y manejo sistematizado de los procesos de negocio en la empresa de asistencia vial
LST se generará:
1. Reducción en los tiempos de respuesta para la prestación de servicios, permitiendo que los
servicios que ofrece la empresa sean ejecutados de manera más eficiente generando una
mayor satisfacción para los clientes.
2. Reducción de cuellos de botella dentro de la prestación del servicio.
3. Mejoramiento en la planificación de los recursos utilizados para la prestación del servicio
4. Control oportuno sobre los servicios prestados y mejoramiento en la comunicación con el
cliente.
5. Optimización de los recursos físicos que posee la empresa generando un aumento en los
ingresos por la prestación de servicios.
6. Optimización de los costos generados por la prestación del servicio.
Con la inclusión de estas mejoras y la existencia de datos en línea, la toma de decisiones
administrativas y estratégicas tendrá una base sólida sobre la cual operar de manera que estas
puedan ser mucho más oportunas y confiables, generando un valor agregado para la empresa.
5. ALCANCES Y LIMITACIONES
Alcances
Se diseñó un prototipo de software web en tres capas con integración de procesos Workflow, que
permite ejecutar y controlar los procesos de “realización de servicio” para la empresa de asistencia
vial LST, donde el prestador del servicio tendrá la capacidad de controlar el flujo completo de la
prestación del servicio, generar facturación, y darle la posibilidad al usuario de conocer el estado
del servicio continuamente. El aplicativo está compuesto por:
1. Módulo para consulta de datos y gestión de los servicio prestados, donde los actores
internos de la empresa tendrán la capacidad de controlar y consultar todo el flujo del
proceso de la prestación del servicio.
2. Módulo para consultar la disponibilidad de recursos para la prestación de un servicio,
para ser utilizado en la asignación y priorización de los recursos para prestar un servicio.
3. Módulo generador de Facturas de los servicios, donde al finalizar cada servicio se
contabilizan los recursos utilizados y generan costos por la prestación del servicio.
4. Módulo de gestión de información de clientes.
5. Módulo para clientes, donde será posible consultar el estado del servicio a través de una
interfaz actualizada simultáneamente conforme avanza el flujo del proceso de prestación
del servicio.
6. Base de datos con la información de los servicios prestados, donde se almacenará y
actualizará toda la información involucrada en la prestación del servicio, tanto de
recursos como usuarios y el flujo del proceso, además de ser actualizada mientras el
proceso de prestación del servicio avanza.
7. Implementación de procesos de Workflow para controlar las tareas en las cuales hay
intervención humana.
Limitaciones
1. No se contempló el uso de un sistema GPS (Global Positioning System) para establecer
la ubicación real de los vehículos que permitiera facilitar la asignación de los mismos a
un servicio, de manera que la estimación de tiempos del servicio se puede ver un poco
afectada.
2. Se utilizaron herramientas de software libre para implementar los procesos de Workflow
y la lógica de la aplicación dado que las soluciones propietarias que existen en el
mercado tienen unos costos de licenciamiento bastante altos.
3. El prototipo desarrollado no contemplo el control de procesos administrativos dentro de
la empresa
6. OBJETIVOS
6.1 OBJETIVO GENERAL
Elaborar un prototipo de software Web utilizando la arquitectura de tres capas e integrando
procesos de Workflow para automatizar los procesos de negocio asociados específicamente a los
de “realización de servicio” de la empresa de asistencia vial LST.
6.2 OBJETIVOS ESPECÍFICOS
1. Identificar los procesos de negocio de la línea operativa de las empresas de asistencia
vial.
2. Especificar los requerimientos funcionales y no funcionales para el diseño e
implementación del prototipo de software.
3. Analizar, diseñar los procesos de “realización del servicio” de la empresa.
4. Identificar los procesos con intervención humana que deben ser controlados
automáticamente.
5. Definir el modelo arquitectónico de tres capas.
6. Elaborar un modelo estructural del SI de acuerdo a los procesos modelados.
7. Diseñar el modelo de procesos de Workflow.
8. Diseñar el modelo de Base de Datos que soporte los requerimientos funcionales y no
funcionales del sistema de información
9. Implementar el prototipo del sistema de información y de los procesos de Workflow.
10. Validar el prototipo desarrollado y realizar los ajustes necesarios.
CAPITULO II - ANALISIS DEL SISTEMA
7 MARCO TEÓRICO
Dado que en el proyecto se busca desarrollar un prototipo de software para automatizar procesos
operativos dentro de la empresa con el objetivo de aumentar la eficiencia y calidad en la
prestación del servicio, a continuación se presentan los tópicos más relevantes para el desarrollo
del mismo, destacando los beneficios de la implementación de un sistema de información con
relación a la productividad y competitividad. También se mencionarán arquitecturas de software,
modelado de procesos de negocio y herramientas tecnológicas, todo ello con el fin de tener una
base conceptual y tecnológica sólida para la ejecución del proyecto.
7.1 LOS SISTEMAS ESTRATÉGICOS DE INFORMACIÓN
En la última etapa de evolución de los sistemas de información, estos constituyen los denominados
Sistemas Estratégicos de Información. Monforte [Monforte, 1994] define sistema estratégico de
información como: “aquel sistema de información que forma parte del “ser” de la empresa, bien
porque supone una ventaja competitiva por sí mismo, bien porque está unido de una forma esencial
al negocio y aporta un atributo especial a los productos, operaciones o toma de decisiones”. Laudon
y Laudon [LAUDON, 1996], a su vez definen sistemas estratégicos de información como:
“sistemas computacionales a cualquier nivel en la empresa que cambian las metas, operaciones,
servicios, productos o relaciones del medio ambiente para ayudar a la institución a obtener una
ventaja competitiva”.
De ambas definiciones se puede destacar el concepto “ventaja competitiva”, relacionado
directamente con la estrategia de la empresa. La ventaja competitiva de una empresa se entiende
como aquella característica de una empresa que la diferencia del resto de competidores
colocándola en una posición relativa superior para competir. Bueno y Morcillo [BUENO Y
MORCILLO, 1993] la definen como: “el dominio y control por parte de una empresa de una
característica, habilidad, recursos o conocimiento que incrementa su eficiencia y le permite
distanciarse de los competidores”. Dicha posición de superioridad sobre los competidores ha de
ser sostenible en el tiempo, pues solo así se lograrán los resultados para la organización.
Así, un sistema de información permitiría a una organización obtener unos mejores resultados que
el resto de agentes de la economía. La empresa se beneficiaría de una reducción de costos en la
fabricación del producto, reducción del costo de comunicación entre las diferentes áreas de la
empresa, mejor coordinación entre los diferentes niveles jerárquicos de la empresa, una mejor
conectividad con proveedores y clientes, rápida adaptación a las necesidades del consumidor,
disminución del tiempo de entrega del producto, etc. De este modo se reforzaría la posible
estrategia seguida por la empresa, por ejemplo las planteadas por Porter [PORTER, 1982]:
liderazgo en costos, diferenciación del producto y concentración. En el caso particular de LST
tendría una ventaja competitiva sobre las demás empresas al disminuir los tiempos de respuesta,
generando una mayor calidad en el servicio para los usuarios y una reducción de costos en las
operaciones de la empresa.
7.2 ARQUITECTURA DE SOFTWARE
De acuerdo a lo que se plantea en la metodología N-Layer propuesta por Microsoft [DE LA
TORRE, 2010] el diseño de la arquitectura para un sistema es un proceso en el cual se define una
solución para los requerimientos técnicos y operacionales del mismo, en este proceso se definen
cuáles componentes formarán el sistema, sus relaciones y como mediante su interacción llevarán
a cabo la funcionalidad. El diseño de una arquitectura debe tener en cuenta los intereses de todas
las partes interesadas (usuarios del sistema, el sistema y objetivos de negocio), pues cada una de
estas generará requerimientos y restricciones que se deben contemplar en el diseño de la
arquitectura; por ejemplo, para los usuarios es necesario que el sistema reaccione de una forma
fluida, mientras que para el negocio es importante que el sistema no sea costoso.
Los principales estilos de arquitectura son Cliente/servidor, Sistemas por componentes, MVC,
arquitectura en capas, N-Niveles y SOA [DE LA TORRE, 2010]. En una aplicación enfocada en
los servicios es útil utilizar SOA; en nuestro caso se utilizara la arquitectura en capas,
específicamente de 3 capas (Presentación, Negocio, Datos) que es la que más se ajusta a la
estructura lógica del desarrollo del proyecto.
El paso a seguir en la construcción de una arquitectura es seleccionar las tecnologías, tema que va
ligado a los requerimientos y las restricciones impuestas por un cliente, luego definir los
requerimientos de calidad como la seguridad (autenticación), las comunicaciones y el manejo de
excepciones.
7.2.1 Arquitectura Multicapas.
La arquitectura de múltiples capas [DE LA TORRE, 2012] es un estilo arquitectónico de
despliegue que describe la separación de la funcionalidad en segmentos definidos como capas. La
arquitectura de tres capas se caracteriza por la descomposición funcional de aplicaciones y su
despliegue distribuido, este estilo arquitectónico ofrece una mayor escalabilidad, disponibilidad,
capacidad de gestión y utilización de recursos. Cada nivel es completamente independiente de
todos los demás niveles, excepto para aquellos inmediatamente por encima y por debajo de ella.
El n-ésimo nivel sólo tiene que saber cómo manejar una petición del nivel n+1, y cómo transmitir
esta petición al nivel n-1 (silo hay), y cómo manejarlos resultados de la solicitud. La comunicación
entre niveles es típicamente asíncrona con el fin de apoyar una mejor escalabilidad.
Cuando la capa de dominio y la capa de aplicación se juntan en una sola capa, el modelo se conoce
como arquitectura en 3 capas como se observa en la Figura 2.
Figura 2 Arquitectura de tres capas, [.NET Architecture guide, 2011]
7.2.1.1 Capa de Infraestructura de Persistencia de Datos
Los componentes de persistencia de datos proporcionan acceso a datos que están hospedados
dentro de las fronteras del sistema (nuestra base de datos principal), pero también datos expuestos
fuera de las fronteras de nuestro sistema, como servicios web de sistemas externos. Contiene, por
lo tanto, componentes de tipo “Repositorio‟ que proporcionan la funcionalidad de acceder a datos
hospedados dentro de las fronteras de nuestro sistema o bien “Agentes de Servicio‟ que
consumirán Servicios Web que expongan otros sistemas back-end externos. Ver figura 3.
7.2.1.2 Capa de Modelo de Dominio
Esta capa debe ser responsable de representar conceptos de negocio, información sobre la situación
de los procesos de negocio e implementación de las reglas del dominio. También debe contener
los estados que reflejan la situación de los procesos de negocio, aun cuando los detalles técnicos
de almacenamiento se delegan a las capas inferiores de infraestructura. Entonces, dichos
componentes implementan la funcionalidad principal del sistema y encapsulan toda la lógica de
negocio relevante. Ver figura 3.
La principal razón de implementar capas de lógica del dominio (negocio) radica en diferenciar y
separar muy claramente el comportamiento de las reglas del dominio y los detalles de la
implementación de infraestructura. De esta forma se incrementa drásticamente la mantenibilidad
del sistema y se podría llegar a sustituir las capas inferiores sin que el resto de la aplicación se vea
afectada.
7.2.1.3 Capa de presentación
La capa de presentación contiene los componentes que implementan y muestran la interfaz de
usuario y que además gestionan su interacción. Esta capa incluye controles para la entrada del
usuario y la pantalla, además de los componentes que organizan la interacción del usuario. Ver
figura 3.
La capa de presentación generalmente incluye:
Componentes de la interfaz de usuario. Estos son los elementos visuales de la aplicación
que se utilizan para mostrar la información al usuario y acepta entradas del usuario.
Componentes lógicos de presentación. La lógica de presentación es el código de la
aplicación que define el comportamiento lógico y de estructura de la aplicación de manera
que es independiente de cualquier implementación de interfaz de usuario específica.
Los principales beneficios del estilo arquitectónico por capas son:
1. Capacidad de mantenimiento, debido a que cada nivel es independiente de los otros
niveles, las actualizaciones pueden llevarse a cabo sin afectar a la aplicación como un
todo.
2. Escalabilidad, debido a que los niveles se basan en el despliegue de capas, el
escalamiento de una aplicación es relativamente sencillo.
3. Flexibilidad, debido a que cada nivel se puede manejar o escalar de forma independiente,
la flexibilidad es mayor.
4. Disponibilidad, las aplicaciones pueden aprovechar la arquitectura modular para permitir
a los sistemas que utilizan componentes ser fácilmente escalables, lo que aumenta la
disponibilidad.
7.3 SOA (Service Oriented Architecture)
SOA es un paradigma para organizar y utilizar capacidades distribuidas que pueden estar bajo el
control de diferentes propietarios. En general [OASIS, 2006], las entidades (personas y
organizaciones) desarrollan capacidades para resolver o apoyar la solución de los problemas que
enfrentan en el ejercicio de sus actividades. Es natural pensar que las necesidades de una persona
sean suplidas por las capacidades ofrecidas por alguien más, o bien, en el mundo de la computación
distribuida, los requisitos de un agente computacional sean logrados por un agente externo.
SOA propone una arquitectura de software en la que se contempla la posibilidad de unir las
diferentes fuentes de información de una organización para brindar un servicio más flexible e
integrado, por ello, permite relacionar las necesidades con las capacidades, para ello propone tres
conceptos que la definen en su totalidad, visibilidad, interacción y efecto.
La visibilidad se refiere a que los que ofrecen sus capacidades y los que tienen necesidades se
puedan ver entre sí para que sepan entre quiénes pueden colaborar normalmente se logra
proporcionando descripciones de aspectos tales como las funciones, los requisitos técnicos,
restricciones o políticas relacionadas y los mecanismos para el acceso o respuesta. Las
descripciones deben estar en una forma en que su sintaxis y semántica sean ampliamente accesibles
y entendibles. La interacción posibilita, una vez descubierta una capacidad, esta pueda ser
accedida y consumir su funcionalidad. Esto se logra a través de un intercambio de mensajes e
invocaciones. El Efecto se da por el hecho de consumir la capacidad, y tiene como resultado la
entrega de información solicitada o un cambio de estado entre las entidades relacionadas.
7.3.1 Web Services
Ofrecer servicios vía web aporta ventajas significativas a las organizaciones. La mas importante
de estas ventajas es la disponibilidad y accesibilidad de estos servicios a través de la infraestructura
de internet, ayudando a que los negocios crezcan de manera significativa y se obtengan nuevos
clientes. Al mismo tiempo, esta expansión esto se convierte en un reto para los prestadores de los
servicios.
Un servicio Web es un sistema de software diseñado para soportar la interoperabilidad máquina a
máquina sobre una red, tiene una interfaz definida en un lenguaje procesable por una máquina
(WSDL). Otros sistemas interactúan con los servicios web de una forma especificada en su
descripción utilizan mensajes SOAP, típicamente transmitidos usando HTTP con una serialización
XML en conjunto con otros estándares web. [W3C, 2006]
La introducción del lenguaje XML crea un precedente para la interoperabilidad a través de un
lenguaje de etiquetas basado en texto. Este puede ser utilizado para representar datos de negocio,
además de hacer el transporte de datos independiente de la red o es sistema operativo. XML forma
la base de Web Services y también habilita la interoperabilidad, que es un requerimiento crucial.
Algunas definiciones de Web Services se refieren más a vocabularios avanzados de XML, estos
vocabularios son especificaciones del XML básico, tres de los más importantes en la definición de
Web Services son: SOAP (Simple Object Access Protocol), WSDL (Web Services Description
Languaje) y UDDI (Universal Description, Discovery and Integration). Así, un servicio web
puede ser definido como un componente de software que utiliza alguna de estas tecnologías
(SOAP, WSDL o UDDI) para realizar tareas de computación distribuida, el uso de cualquiera de
estas tecnologías básicas constituye un Web Service.
Las funciones de cada una de estas tecnologías son:
SOAP, describe un mensaje en formato XML y herramientas para intercambiar
información entre aplicaciones en ambientes distribuidos. Estos mensajes SOAP contienen
elementos de tipo Envelope, que identifican a un documento XML como mensaje SOAP,
un Header que provee mecanismos para almacenar información adicional como los de
seguridad , por ultimo Elementos de tipo Body que contienen la información que va a ser
intercambiada a través del mensaje.
WSDL, describe la interfaz, ubicación y formas de acceso de un Web Service, consta de
dos partes, una descripción abstracta y una descripción concreta.
UDDI, define un directorio y un modelo de datos para almacenar información de los
servicios, provee una forma de publicar y buscar Web Service.
7.4 BPM (Business Process Management)
La llegada del marco de trabajo abierto de los servicios Web y su capacidad de abstraer totalmente
la tecnología propietaria, cambió todo el panorama de la integración del middleware [HITPASS,
2012]. La dependencia hacia los vendedores pudo ser terminada invirtiendo en servicios móviles
en oposición a plataformas propietarias, y las organizaciones ganaron más control sobre la
evolución de sus arquitecturas de integración.
En los años recientes [HITPASS, 2012], BPM ha incursionado convirtiéndose en una tendencia
para la gestión empresarial y tecnológica, colocando al cliente en primer lugar. BPM provee un
conjunto de herramientas y métodos para representar, analizar y controlar procesos de negocio,
combinando las tecnologías de la información y procesos de gobierno.
Los procesos corresponden a la representación de un conjunto de actividades que se hacen
cumpliendo ciertas reglas y que son capaces de disparar eventos, para cumplir un determinado fin,
a su vez los procesos de negocio son aquellos que ejecutándolos en cierta secuencia generan valor
para un cliente, la principal característica de un proceso de negocio es que es ejecutado por un
cliente y los resultados de la ejecución deben volver al cliente. El proceso de negocio es transversal
a las áreas y atraviesa la cadena de valor de principio a fin (“end to end”) aunque el cliente sea
interno o externo de la organización. Ver Figura 3.
Figura 3 Estructura trasversal del negocio. [HITPASS, 2012]
Los componentes más importantes de una implementación BPM son la administración del cambio
organizacional y las personas asociadas. El compromiso de las personas en la implementación es
crucial, por lo que se hace necesario un aprovechamiento holístico en el conocimiento de las
personas y en diferentes aspectos de administración.
7.4.1 Objetivos de BPM
1. Lograr o mejorar la agilidad de negociar, en una organización. El concepto de agilidad de
negocio se entiende como la capacidad que tiene una organización de adaptarse a los
cambios del entorno a. través de los cambios en sus procesos integrados [HITPASS,
2012].
2. Lograr mayor eficacia, el concepto de eficacia se entiende como la capacidad que tiene
una organización para lograr en mayor o menor medida los objetivos estratégicos o de
negocio [HITPASS, 2012].
3. Mejorar los niveles de «eficiencia». Eficiencia es la relación entre los resultados obtenidos
y los recursos utilizados; es decir, el grado de productividad de un resultado. El término
eficiencia está relacionado con todos los indicadores de productividad en cuanto a calidad,
costos y tiempos [HITPASS, 2012].
7.4.2 Dimensiones de BPM
7.4.2.1 El negocio
La dimensión del negocio [JESTON ,2006] crea valor tanto para los clientes como para los demás
interesados en el funcionamiento de la empresa. BPM concentra recursos y esfuerzos de la empresa
para crear valor para los clientes. También genera la agilidad necesaria para la respuesta al cambio.
7.4.2.2 El proceso
También llamada la dimensión de la transformación [JESTON ,2006] crea valor a través de
procesos. Los procesos transforman recursos en productos finales para los clientes. Mediante BPM
los procesos de negocio son más efectivos y más ágiles, además por medio de los procesos se
producen menos errores, y cuando estos se dan, se detectan y se solucionan más rápido. BPM
proporciona procesos ágiles, minimizando el tiempo y el esfuerzo necesarios para traducir ideas
en acciones.
7.4.2.3 La gestión
La gestión o la dimensión de capacitación [JESTON ,2006], coordina las acciones de las personas
y los sistemas para llevar a los procesos a la acción en busca de los objetivos del negocio. En la
gestión la herramienta principal son los procesos.
7.4.3 BPMN (Business Process Management Notation)
Para el modelamiento de los procesos de negocio BPM cuenta con su propia notación estándar
llamada BPMN [BPMN 1.1, 2009]. Existen diferentes tipos de modelamiento de procesos:
1. Mapas de proceso: Son simples diagramas de flujo de las actividades.
2. Descripciones de proceso: Son diagramas de flujo con información adicional, pero no
suficiente para definir el desempeño actual del proceso.
3. Modelos de proceso: Son diagramas de flujo con la suficiente información como para
que el proceso pueda ser analizado, simulado y ejecutado.
BPMN soporta los tres tipos, es una notación basada en diagramas de flujo para definir procesos
de negocio, se establece por acuerdos entre los distintos proveedores que tenían sus propias
notaciones, con el fin de mejorar el aprendizaje y el entendimiento, provee un mecanismo para
generar y ejecutar procesos.
BPM se utilizará en el proyecto para modelar los procesos de negocio relacionados con la
prestación del servicio, separando adecuadamente las actividades según el rol o área responsable,
modelando la secuencia de tareas y el flujo de información entre ellas.
7.5 WORKFLOW
El Workflow [FISCHER, 2012] se ocupa de la automatización de los procedimientos en los que se
transmiten documentos, información o tareas entre los participantes de acuerdo con un conjunto
definido de reglas para cumplir, o para contribuir a un objetivo general de la empresa.
Mientras que el Workflow puede ser organizado de forma manual, en la práctica la mayor parte del
flujo de trabajo se organiza normalmente en el contexto de un sistema informático para
proporcionar soporte informático en la automatización de procedimientos.
Definición de Workflow
“The computerised facilitation or automation of a business process, in whole or part.”
[Hollingsworth, 2007]
“La facilitación de la automatización de un proceso de negocio, total o en parte”
Workflow se asocia a menudo con Business Process Re-engineering (BPR) [Hollingsworth, 2007],
que se refiere a la evaluación, análisis, modelado, definición y posterior aplicación operativa de
los principales procesos de negocio de una organización. Aunque no todas las actividades de BPR
resultan en las implementaciones de flujo de trabajo, la tecnología de flujo de trabajo es a menudo
una solución adecuada, ya que proporciona la separación de la lógica de negocio con relación a su
procedimiento de TI de apoyo operacional, permitiendo que los cambios posteriores puedan ser
incorporados en las normas de procedimiento que definen el proceso de negocio. A la inversa, no
todas las implementaciones de flujo de trabajo necesariamente forman parte de un ejercicio BPR.
7.5.1 Workflow Reference Model
[HOLLINGSWORTH, 2005] El 8.4.1.El Workflow Reference Model se ha desarrollado a partir
de la estructura genérica de Workflow mediante la identificación de las interfaces dentro de esta
estructura que permitirá a los productos interoperar en una variedad de niveles. Todos los sistemas
Workflow contienen un número de componentes genéricos que interactúan en un conjunto definido
de maneras; diferentes productos típicamente exhiben diferentes niveles de capacidad dentro de
cada uno de estos componentes genéricos. Para lograr la interoperabilidad entre los productos de
Workflow es necesario un conjunto normalizado de interfaces y formatos de intercambio de datos
entre los componentes. Se pueden construir diferentes escenarios de interoperabilidad tomando
como referencia a dichas interfaces, y acorde a la identificación de los diferentes niveles de la
conformidad funcional según sea apropiado para la gama de productos del negocio.
En la Figura 4 se muestran los principales componentes e interfaces de una arquitectura genérica
Workflow.
Figura 4 Estructura genérica de Workflow. [HOLLINGSWORTH, 2005]
La definición del proceso puede referirse a un modelo de organización/función que contiene
información sobre la estructura organizacional y los roles dentro de la organización (por ejemplo,
un directorio de la organización). Esto permite a la definición del proceso que se especifiquen en
términos de entidades organizacionales y en roles de funciones asociadas con actividades
particulares u objetos de información, en lugar de participantes específicos. El servicio de
lanzamiento de Workflow tiene entonces la responsabilidad de vincular entidades organizativas o
roles con los actores específicos dentro del entorno de ejecución de flujo de trabajo.
Workflow está ligado directamente con BPM ya que Workflow se puede considerar como un
proceso de negocio en el cual se controla la intervención humana.
8 MARCO REFERENCIAL
La asistencia vial es un servicio proporcionado a los conductores cuyos vehículos han sufrido de
una falla o problema mecánico lo suficientemente significativo como para inmovilizar
temporalmente al vehículo. Este servicio puede ser ofrecido por ciertos talleres mecánicos,
asociaciones de automovilistas, aseguradoras, fabricantes automotrices, el gobierno, empresas de
asistencia vial o ciertas concesionarias viales en ciertas vías a su cargo.
La mayoría de estos servicios requieren del pago de una cuota o seguro, ya sea en forma mensual
o anual, mayormente usado por las asociaciones y aseguradoras, el pago de peajes, usado por las
concesionarias o el gobierno, o en el momento de requerir la asistencia.
Entre los servicios prestados pueden estar el cambio de llantas, arranque con pinzas, la carga de
una pequeña cantidad de combustible y otras reparaciones menores. En caso que el problema no
pueda ser arreglado en el lugar o necesite ser movido de manera urgente, usualmente también
prestan el servicio de grúa.
Con la popularización del automóvil surgieron varias asociaciones de automovilistas, quienes en
su mayoría eran fanáticos de los automóviles. Tiempo después estas asociaciones vieron la
necesidad de un servicio de emergencia para ayudar sus miembros. En los primeros años se
utilizaron motocicletas para llegar al lugar, las cuales luego fueron remplazadas por vehículos
mayores, especialmente furgonetas e incluso grúas para remolcar los vehículos averiados1.
Actualmente en el país existen muchas empresas de asistencia vial dentro de las cuales se
encuentran:
1. IRS Vial.
2. Destino Seguro.
3. IKÉ Asistencia.
4. RSA Colombia.
5. RedAssist.
Cada una de estas empresas cuentas con distintas soluciones de software para la administración de
sus actividades pero la mayoría de estas soluciones están estandarizadas por lo que cualquier
empresa, sin tener en cuenta sus necesidades particulares, lo podría usar pero requiere que la
empresa sea la que tenga que adaptarse al diseño del software y cambiar sus procesos y
procedimientos de manera que estos vayan acorde al diseño del sistema.2
Dentro del software existente para la empresas de asistencia vial se destaca SOFTOW3, que es
utilizado específicamente para la administración y asignación de servicios; por otra parte, está SCL
(Sistema de Control Logístico)4 que es un software que está diseñado para asignación, monitoreo
de servicios y reservas en línea que ha sido adaptado para la asignación de grúas y vehículos de
asistencia vial.
1 www.fasecolda.com/fasecolda/BancoMedios/Documentos/seguro de automoviles.pdf2 Esta información fue obtenida mediante consultas telefónicas y visitas a las empresas.3 http://www.softow.com/4 http://www.destinoseguro.net/scl/
En algunas de la empresas de asistencia vial no hay ningún tipo de software especializado,
únicamente manejan hojas de Excel donde se encuentran los registros de todos los servicios que
se prestan, así como el registro de los recursos disponibles para la prestación de los servicios, es
por estas razones que se propone el desarrollo de un software web que permita integrar tanto las
asignaciones de vehículos a los servicios así como el manejo del flujo de procesos dentro de la
empresa, haciéndola más eficiente y más competitiva en el mercado5.
LST no usa ninguna de las soluciones existentes en el mercado ya que esto implicaría tener que
adaptar sus procesos y procedimientos a la herramienta adquirida, cuando lo que se quiere es tener
un software diseñado y adaptado a cada uno de los procesos de realización de servicio que se
ejecutan dentro de la empresa.
Dentro de las empresas de asistencia vial existen gran variedad de estructuras organizacionales por
lo cual hoy en día, existen diversas aproximaciones al tema de cómo hacer que las personas
trabajen dentro de una organización de manera colaborativa, teniendo en cuenta el grado de
penetración de las tecnologías de la información en cada una de estas estructuras. Es por ello
necesario, establecer una forma estándar de expresar la forma como se realiza el trabajo, para luego
poder determinar consecuentemente la manera como estas personas o equipos van a comunicarse.
8.1 Soluciones de negocio soportadas en procesos de Workflow
Dentro de las soluciones que implementen Workflow para automatizar procesos de negocio con
intervención humana, se pueden tomar como referencia los siguientes documentos a manera de
guía para el desarrollo de este proyecto:
5 La información relacionada con el tipo de software y la manera como manejan la información se obtuvo viatelefónica y con entrevistas personales directamente en las empresas.
“Diseño del procedimiento para la implementación del sistema Workflow en la sección de
egresos Caja de Compensación Familiar Colsubsidio”, tesis de grado de la Universidad
de La Salle6 elaborada por Diana Angélica Vargas y Yeyson Muñoz
“Executable Models for Extensible Workflow Engines” tesis doctoral de la Universidad de
los Andes elaborada por Mario Sanchez Puccini en donde se propone una aproximación
para la construcción de motores para nuevos lenguajes de Workflows. La propuesta está
basada en la ingeniería guiada por modelos (MDE), utiliza modelos ejecutables y se
encuentra implementada en una plataforma llamada Cumbia.7
“Modelos ejecutables extensibles como activos en una fábrica de motores de Workflow:
caso BPEL”, tesis de maestría de la Universidad de los Andes8, elaborada por Daniel
Romero.
9 DISEÑO METODOLOGICO
9.1 PROCEDIMIENTO
El desarrollo del proyecto se dividió en seis fases las cuales corresponden a cada uno de los sprint
que se describen a continuación,
Fase 1: Definición general del proyecto, fase de exploración y levantamiento de
requerimientos.
6 Revisado en el Repositorio de Tesis de la Universidad de la Salle.http://repository.lasalle.edu.co/bitstream/10185/2016/1/T88.07%20V426d.pdf7 Revisado en el Repositorio de Tesis de la Universidad de los Andes. http://sistemas.uniandes.edu.co/~mar-san1/dokuwiki/doku.php?id=tesis8 Revisado en el Repositorio de Tesis de la Universidad de los Andes.http://cumbia.uniandes.edu.co/wikicumbia/lib/exe/fetch.php?media=public:documentodanielromero.pdf
Fase 2: Diseño y elaboración del módulo para la gestión de la prestación del servicio.
Fase 3: Diseño y elaboración del módulo de gestión de recursos para la prestación del
servicio.
Fase 4: Diseño y elaboración del módulo para consulta de clientes.
Fase 5: Diseño y elaboración del módulo para facturación de servicios.
Fase 6: implementación de todos los módulos y ejecución de pruebas funcionales
Cada uno de los sprint está divido en tareas y actividades que se irán ejecutaron secuencialmente,
estas tareas comprendieron el modelado del negocio, la definición de requerimientos, análisis,
diseño, implementación, ejecución de pruebas, manejo de persistencia y documentación de cada
uno de los componentes del proyecto que dará solución al problema planteado inicialmente.
Los sprint están contemplados mediante las etapas de análisis y diseño, pruebas e implementación,
realizando pruebas al final de cada etapa que darán las pautas para los ajustes necesarios. Al final
de la etapa de Diseño se realizó una prueba unitaria para la detección primaria de errores del
módulo en particular. Dentro de cada una de las iteraciones también se contempló la creación y
adaptación del modelo físico de la base de datos modificándolo con las necesidades específicas
que se generen en el desarrollo de cada módulo.
En un último sprint se realizaron las de pruebas de integración, donde se detectaron errores en la
funcionalidad de los módulos una vez se encontraron interactuando entre sí, lo que permitió
realizar la corrección de estos hallazgos. En este sprint también se contempló la etapa de
implementación donde se instaló el software en un entorno productivo y se realizaron distintas
pruebas con casos reales para validar el funcionamiento del prototipo por parte de los usuarios
finales.
9.2 METODOLOGÍA INGENIERIL
Dentro de un desarrollo se debe tener una metodología de trabajo que pueda ser adoptada por los
integrantes del proyecto, considerando diferentes factores que influyen en el desempeño del
equipo, como cualidades de trabajo de cada uno de los integrantes, disponibilidad de tiempo, los
resultados esperados, las herramientas y recursos disponibles.
Existen diversas metodologías que pueden ser adoptadas para el desarrollo y ejecución del
proyecto, las metodologías que contemplan el cambio intempestivo, la recolección de información
y el rediseño en etapas avanzadas se consideran metodologías flexibles o metodologías ágiles.
Estas son comunes en ambientes donde el tiempo de ejecución del proyecto es corto y se debe
empezar con información poco detallada. Las metodologías que requieren un panorama completo,
un estudio previo exhaustivo y que minimizan la posibilidad de cambios en una etapa avanzada
del proyecto, se denominan metodologías tradicionales.
Después de evaluar diversos factores, especialmente el tiempo y la disponibilidad de información
con que se cuenta, se concluyó que la metodología a usar debería ser una metodología ágil, por lo
cual se toma como opción Scrum, ya que dada su estructura, facilita la construcción del prototipo
a la par con las entradas de información, las cuales, a pesar de redefinir en cada iteración las
directrices del proyecto, permiten que este se lleve a cabo buscando productividad y flexibilidad.
De esta forma, para el desarrollo del prototipo se determinaron seis Sprint, cada uno con un tiempo
de desarrollo de 4 semanas, en los cuales se revisaron los incrementos generados y se planearon
las actividades del siguiente Sprint. A su vez, se realizaron reuniones semanales para la revisión
de los avances, actividades resueltas, actividades pendientes y algún tipo de observación que se
tenga.
En cada uno de los Sprints contemplados se incluyeron las siguientes tareas:
Una tarea inicial basada en la extracción de requerimientos a partir de entrevistas realizadas con
el personal de la empresa y del conocimiento previo que se ha logrado extraer sobre el tema,
posteriormente se realizó el diseño base del componente, el cual se alimentó en cada iteración.
En la tarea de construcción se realizó el diseño de artefactos, tomando en cuenta las modificaciones
que surgieron en cada una de las iteraciones.
10 ANALISIS Y DISEÑO DEL SISTEMA
En esta sección se describen los resultados obtenidos luego de hacer una indagación preliminar
sobre las expectativas que la empresa tiene sobre el desarrollo del software, así como también el
estudio realizado sobre el problema planteado inicialmente y los objetivos que se establecieron al
inicio del proyecto cuyo fin principal es automatizar y aumentar la eficiencia de los procesos de
realización de negocio dentro de la empresa.
10.1 REQUERIMIENTOS ESPECIFICOS DE INTERFACES
10.1.1 INTERFACES DE USUARIO
El prototipo de software elaborado para el manejo de los procesos de realización de servicios de
la empresa de asistencia vial fue diseñado para ser usado vía web permitiendo que las interfaces
a las cuales acceden los usuarios y administradores de la aplicación estén alojadas en un servidor
ubicado en la empresa, por lo cual lo único que necesitan los usuarios para acceder a la aplicación
es un navegador web el cual les ira desplegando las interfaces de la aplicación correspondientes a
la actividad que deseen realizar.
10.1.2 INTERFACES DE HARDWARE
Para el manejo del software web es necesario contar con un equipo de cómputo cuyas
características técnicas le permitan al usuario manipular de una manera fácil el entorno gráfico
desplegado por la aplicación.
10.1.3 INTERFACES SOFTWARE
Para el funcionamiento del software es necesario contar con un navegador Web que permita
acceder a la aplicación, los demás procesos como la persistencia y el manejo de procesos workflow
serán llevados a cabo en el servidor, donde además están alojados el manejador de bases de datos,
el servidor de procesos y el servidor de la aplicación.
11 REQUERIMIENTOS DE PERSISTENCIA
Para el desarrollo del prototipo de software se tuvo en cuenta el siguiente listado de requerimientos
relacionados con el manejo de la persistencia del prototipo:
ID REQUERIMIENTOS DE PERSISTENCIA
RP-01 Registro de Usuarios de la aplicación con datos personales y datos de
acceso a la aplicación.
RP-02 Registro de los datos básicos de los operarios de los vehículos que trabajan
o han trabajado en la empresa
RP-03 Registro de los datos básicos de los operadores del callcenter que trabajan
o han trabajado en la empresa.
RP-04 Registro de los datos básicos de los despachadores que trabajan o han
trabajado en la empresa
RP-05 Registro de los datos de las empresas aseguradoras a las cuales se encuentra
afiliada la empresa.
RP-06 Registro de datos personales de los clientes a los cuales se les prestarán los
servicios.
RP-07 Registro de los servicios que serán prestados incluyendo ubicación, tipo de
servicio y persona quien solicita el servicio
RP-08 Registro de cambios en los estados de los servicios prestados, tomados
desde los procesos Workflow
RP-09 Registro de costos de los servicios prestados, incluyen kilometraje y otros
gastos que se asuman para la realización del servicio
RP-10 Registro para el apoyo en la obtención de la disponibilidad para la
prestación de un servicio.
RP-11 Registro de los cambios de estado de los servicios que han sido prestados
por la empresa.
Tabla 1Requerimientos de persistencia
12 CARACTERIZACIÓN DEL PROTOTIPO DE SOFTWARE
A continuación se presenta el listado de requerimientos que han sido obtenidos luego de
realizar el análisis del problema y de realizar una estimación de la posible solución para el
mismo.
12.1 REQUERIMIENTOS FUNCIONALES
ID REQUERIMIENTOS PARA USUARIOS
RU-1 Registrar datos básicos de Usuarios internos
RU-2 Registrar datos básicos de Clientes
RU-3 Crear nombres de usuario y contraseñas para Clientes y Operadores
RU-4 Restringir acceso al sistema mediante la autenticación de usuarios.
RU-5 Permitir la modificación de la información básica por parte del usuario.
RU-6
Diferenciar usuarios internos entre operadores de callcenter, despachadores y
operarios
RU-7
Limitar el acceso del usuario cliente solo para solicitud y consulta de los
servicios.
RU-8 Manejar el histórico de todos los usuarios, tanto internos como externos.
RU-9
Permitir la creación y eliminación de un usuario interno por parte del
administrador de la aplicación.
RU-10 Los usuarios internos podrán cambiar su contraseña de acceso cuando lo deseen.
RU-11 Permitir que el administrador le pueda cambiar el rol a los usuarios internos.
REQUERIMIENTOS DE REALIZACIÓN DE SERVICIOS
RS-1 Registrar datos básicos del servicio a prestar.
Generar un identificador del servicio para que este pueda ser consultado por el
cliente.
RS-2 Permitir asociar un Cliente al servicio que será prestado.
RS-3 Permitir asociar un operario para la prestación el servicio.
RS-4 Habilitar al Cliente para poder consultar estados de los servicios.
RS-5 Permitir la modificación del estado de los servicios.
RS-6
Permitir agregar eventos aleatorios que se pudieran presentar en la prestación del
servicio.
RS-7
Generar alertas al operador de callcenter de los servicios en espera de cambio de
estados.
RS-8 Permitir al cliente realizar la cancelación de su servicio
RS-9 Permitir al operador de callcenter realizar la cancelación un servicio
RS-10 Consultar la disponibilidad de recursos para prestación de servicios
RS-11 Notificar al cliente de la culminación de los servicios.
RS-12 Notificar al Cliente del inicio de la prestación del servicio.
RS-13 Enviar notificaciones del estado de los servicios a los clientes.
RS-14
Registrar kilometraje recorrido durante la prestación del servicio por parte del
despachador.
Permitir el registro de gastos generados por la prestación del servicio por parte
del despachador.
RS-15 Notificar al cliente de la disponibilidad o no para la prestación del servicio.
RS-16 Consultar histórico de servicios prestados.
REQUERIMIENTOS PARA LA GENERACIÓN DE FACTURAS
RF-1 Permitir la consulta de los gastos generados por la prestación del servicio
RF-2
Permitir calcular los costos de cada uno de los servicios que se culminaron
satisfactoriamente
RF-3
Calcular el costo total para la generación de la factura por la prestación del
servicio
RF-4
Generación de la factura con los datos del cliente, aseguradora, descripción del
servicio y posibles eventos aleatorios que se pudieran presentar.
Tabla 2 Requerimientos funcionales
12.2 REQUERIMIENTOS NO FUNCIONALES
Los requerimientos no funcionales del software son aquellos que no intervienen directamente con
el objetivo del negocio, pero son necesarios para el funcionamiento del software, a continuación
se describen los requerimientos no funcionales obtenidos luego de realizar la estimación de la
solución al problema planteado.
ID REQUERIMIENTO NO FUNCIONAL
RNF1 El sistema debe estar disponible permanentemente ya que va a ser
utilizado 7X24.
RNF2 La navegación dentro del sistema debe ser muy sencilla ya que esta será
usada por personas que no cuentan con una amplia experiencia en el manejo
de aplicaciones informáticas
RNF3 El tiempo de respuesta debe ser inmediato a cualquier tipo de consulta que
se realice.
RNF4 El sistema debe rechazar accesos o modificaciones no autorizadas.
RNF5 El sistema debe estar restringido para su uso, impidiendo que personas no
autorizadas tengan acceso al mismo
RNF6 Se requiere que el motor de procesos sea capaz de gestionar interacciones
de los usuarios con los procesos (Workflow), además de manejar
notificaciones hacia los usuarios.
RNF7 Contar con un motor de procesos que permita realizar la integración de los
procesos diseñados y aplicaciones java mediante el uso de mensajes.
RNF8 Se requiere un motor de procesos que soporte lenguaje bpmn para el
manejo de los procesos de la empresa.
RNF9 El sistema debe ser diseñado y construido con los mayores niveles de
flexibilidad en cuanto a la parametrización de los tipos de datos, de tal
manera que la administración del sistema sea realizada por un
administrador funcional del sistema.
RNF10 El sistema debe contar con facilidades para la identificación de la
localización de los errores durante la etapa de pruebas y posteriormente en
la etapa de operación.
RNF11 El sistema no podrá permitir el cierre abrupto de un servicio que se
encuentre en ejecución
RNF12 El sistema debe estar en capacidad de permitir que en el futuro el
desarrollo de nuevas funcionalidades, modificando las existentes o
adicionando nuevas.
RNF13 Se debe contar con un DBMS con alta disponibilidad que permita el
manejo de todas las transacciones que se generan dentro del sistema.
RNF14 Debe haber una parametrización de los datos administrados que facilite su
manejo
Tabla 3 Requerimientos no funcionales
CAPITULO III – DISEÑO DEL SISTEMA
13 MODELO ESTRUCTURAL BASADO EN CASOS DE USO
Dentro del desarrollo del proyecto se contempló la creación de cuatro módulos para la ejecución
de las funciones propuestas inicialmente para el funcionamiento de la aplicación, estos módulos
corresponden al módulo de gestión de servicios, módulo de gestión de usuarios, módulo de gestión
de facturas y módulo de gestión de acceso, en la figura se detalla el contenido de cada uno de los
módulos.
Figura 5 Modelo estructural- Módulos casos de uso
13.1 ACTORES
Dentro de los actores propuestos para el desarrollo del proyecto se destaca como actor principal
"usuario", del cual heredan los demás actores del sistema, se define dicha jerarquía de actores dado
que la ejecución de ciertas funcionalidades dentro del sistema están ligadas al rol asignado a cada
uno de los usuarios.
Figura 6, Actores del sistema
Usuario: Agrupa a todos los actores que hacen uso de la aplicación.
Cliente: Es quien realiza la solicitud de prestación del servicio y adicionalmente solicita
información del estado del servicio que le están prestando.
Administrador: Es el encargado de crear, administrar y eliminar los usuarios del sistema y
adicionalmente gestionar y supervisar la ejecución de los servicios por parte de la empresa.
Usuario Interno: Agrupa los usuarios que trabajan dentro de la empresa y hacen uso de la
aplicación.
Operario: Es cada uno de los empleados de la empresa que se encargan de la ejecución y/o
prestación de los servicios a los usuarios finales
Operador callcenter: Es el encargado de realizar la recepción de los servicios, registrar los datos
necesarios para le prestación del servicio y ejecutar los procesos para dar inicio a la prestación del
mismo. Adicionalmente realiza el registro de los eventos que se generan durante la prestación del
servicio.
Despachador: Es el encargado de asignar cada uno de los servicios que se crean a los operarios
para su ejecución, adicionalmente es quien realiza el cálculo de los costos y hace el registro de los
gastos generados durante la prestación del servicio.
13.2 MODULO GESTIÓN DE USUARIOS
Este módulo está diseñado en el fin de permitir a los administradores de la aplicación realizar la
creación eliminación y administración de usuarios, así como la asignación roles y permisos que
pueda tener cada uno de estos usuarios dentro de la aplicación con el fin de que puedan ejecutar
las actividades a las cuales están explícitamente asignados
Figura 7 Modulo gestión de usuarios
13.2.1 ESPECIFICACIÓN DE CASOS DE USO
A continuación se muestra la especificación de cada uno de los casos de uso del modelo planteado,
acompañado de su respectivo diagrama de actividades.
13.2.1.1 CASO DE USO: Crear usuario
ACTORES Administrador
TIPO Primario
DESCRIPCION Permite realizar la creación de un usuario de la aplicación internos y
externos, registrando sus datos personales, asignándoles un rol especifico
y un nombre de usuario y contraseña de manera que el usuario pueda
ingresar y hacer uso de la aplicación.
REFERENCIAS
CRUZADAS
Registrar datos
PRECONDICIONES El usuario debe tener un rol de administrador y estar logueado dentro de
la aplicación para poder realizar la creación de un nuevo usuario
POSTCONDICIONES Se crea un usuario el cual posteriormente puede ingresar a la aplicación y
realizar sus actividades de acuerdo al rol asignado.
ESCENARIO NORMAL
ACTORES SISTEMA
1. Usuario da clic en el botón crear usuario.
2. Despliega ventana para ingresar los datos
personales del usuario a crear
3. Ingresa los datos solicitados por la
aplicación.
4. Da clic en el botón aceptar.
5. Despliega una ventana con los posibles
roles que se le pueden asignar al usuario.
6. Selecciona el rol que será asignado al
usuario.
7. Da clic en el botón aceptar.
Figura 8 - Diagrama de actividades crear usuario
13.2.1.2 CASO DE USO: Registrar datos
ACTORES Administrador
TIPO Primario
DESCRIPCION Permite realizar el registro de los datos personales de un usuario que hará
uso de la aplicación
REFERENCIAS
CRUZADAS
PRECONDICIONES Administrador logueado dentro de la aplicación.
POSTCONDICIONES
ESCENARIO NORMAL
ACTORES SISTEMA
1. Captura los datos ingresados por el
usuario.
2. Guarda los datos capturados en la base de
datos.
3. Muestra mensaje de notificación exitoso.
2.1 Muestra mensaje de error al no poder
guardar la información en la base de
datos.
2.2 Muestra la opción de guardar datos
nuevamente.
2.3 Intenta guardar los datos nuevamente.
Figura 9 - Diagrama de actividades registrar datos
13.2.1.3 CASO DE USO: Crear rol
ACTORES Administrador
TIPO Primario
DESCRIPCION Permite realizar la creación de un rol específico dentro de la aplicación a
el cual se le asignan determinados permisos acorde al cargo que
desempeñe dentro de la empresa, esto con el fin de poder diferenciar las
actividades que puede realizar cada uno de los usuarios dentro de la
aplicación
REFERENCIAS
CRUZADAS
PRECONDICIONES Administrador logueado dentro de la aplicación.
POSTCONDICIONES
ESCENARIO NORMAL
ACTORES SISTEMA
1. Usuario da clic en el botón crear rol
2. Despliega la ventana para ingresar el
nombre del rol y seleccionar los permisos
que se le asignarán al rol.
3. Digita los datos y selecciona los permisos
4. Da clic en el botón aceptar
5. Guarda los datos en la base de datos.
6. Muestra mensaje de confirmación.
5.1 Si no se pueden guardar los datos,
muestra mensaje de error.
5.2 Devuelve al usuario a la pantalla
inicial para que seleccione nuevamente la
opción guardar.
Figura 10 - Diagrama de actividades crear rol
13.2.1.4 CASO DE USO: Cambiar rol de usuario
ACTORES Administrador
TIPO Primario
DESCRIPCION Permite al administrado cambiar el rol que tiene asignado un usuario con
el fin restringirle o asignarle más permisos de los que tiene asignados de
acuerdo al cargo que desempeñe dentro de la empresa.
REFERENCIAS
CRUZADAS
Buscar usuario
PRECONDICIONES Administrador logueado dentro de la aplicación.
POSTCONDICIONES
ESCENARIO NORMAL
ACTORES SISTEMA
1. Usuario da clic en la opción cambiar de
rol.
2. Muestra la ventana de búsqueda de
usuario.
3. Ingresa los valores solicitados.
4. Muestra el rol asignado actualmente al
usuario.
5. Verifica el rol actual y en caso que desee
cambiar da clic en el botón cambiar.
6. Muestra una ventana con los roles
disponibles para seleccionar.
7. Selecciona el nuevo rol para el usuario
8. Da clic en el botón guardar
9. Asigna el nuevo rol al usuario y guarda
los datos en la base de datos.
10. Muestra mensaje de confirmación.
5.1 Da clic en el botón cancelar ya que no
quiere cambiar el rol.
4.2 Usuario no encontrado, muestra mensaje de
error y devuelve al usuario a la ventana anterior.
5.2 Cierra las ventanas de cambio de rol.
9.1 No se pudieron guardar los datos, muestra
mensaje de error.
9.2 Devuelve al usuario a la ventana anterior.
Figura 11 - Diagrama de actividades cambiar rol de usuario
13.2.1.5 CASO DE USO: Eliminar usuario
ACTORES Administrador
TIPO Primario
DESCRIPCION Permite desactivar la cuenta de un usuario específico con el fin de
denegarle el acceso total a la aplicación para que no pueda hacer uso de
esta.
REFERENCIAS
CRUZADAS
Buscar usuario.
PRECONDICIONES Administrador logueado dentro de la aplicación.
POSTCONDICIONES A pesar de que se desactiva la cuenta del usuario, los datos quedan
almacenados con el fin de conservar registros históricos de los usuarios
que han usado la aplicación.
ESCENARIO NORMAL
ACTORES SISTEMA
1. Usuario da clic en la opción eliminar
usuario.
2. Despliega la ventana de búsqueda de
usuarios.
3. Ingresa lo valores solicitados.
4. Busca el usuario y devuelve los datos en
una nueva ventana.
5. Si el usuario es el solicitado da clic en el
botón eliminar
6. Elimina el rol asignado al usuario.
7. Cambia el estado del usuario a
desactivado.
8. Se almacena la información en la base de
datos.
9. Muestra el mensaje de confirmación.
4.1 Usuario no encontrado, muestra mensaje y
devuelve al usuario a la ventana anterior.
5.1 Da clic en el botón cancelar.
5.2 Se cierran las ventanas relacionadas con
eliminación del usuario.
8.1 No se pudo almacenar la información,
muestra mensaje de error, devuelve al
usuario a la ventana anterior.
Figura 12 - Diagrama de actividades eliminar usuario
13.2.1.6 CASO DE USO: Buscar usuario
ACTORES Administrador
TIPO Primario
DESCRIPCION Permite realizar la búsqueda de un usuario específico dentro de la
aplicación, la búsqueda puede ser realizada por nombre o rol.
REFERENCIAS
CRUZADAS
PRECONDICIONES Administrador logueado dentro de la aplicación.
POSTCONDICIONES Devuelve el listado de usuario que coincide con los parámetros de
búsqueda.
ESCENARIO NORMAL
ACTORES SISTEMA
1. Muestra ventana con los parámetros de
búsqueda.
2. Ingresa los datos solicitados.
3. Captura los datos ingresados
4. Envía la consulta a la base de datos.
5. Recibe y transforma la información
proveniente de la base de datos.
6. Muestra una ventana con la información
del usuario solicitado.
5.1 No hay resultados de la consulta.
5.2 Muestra mensaje de error.
5.3 Devuelve al usuario a la ventana
principal.
Figura 13 - Diagrama de actividades buscar usuario
13.3 MODULO GESTIÓN DE FACTURAS
Este módulo permite a los usuarios de la aplicación realizar la liquidación del costo del servicio y
generar la factura al cliente por concepto de la prestación del servicio solicitado.
Figura 14 - Modulo gestión de facturas
13.3.1 ESPECIFICACIÓN DE CASOS DE USO
A continuación se muestra la especificación de cada uno de los casos de uso del modelo planteado
acompañado de su respectivo diagrama de actividades para el módulo de gestión de facturas.
13.3.1.1 CASO DE USO: Calcular costo de servicio
ACTORES Despachador
TIPO Primario
DESCRIPCION Permite establecer el costo total del servicio que fue prestado.
REFERENCIAS
CRUZADAS
Buscar servicio
PRECONDICIONES Se deben tener todos los datos del servicio prestado, el estado del
servicio debe ser culminado.
POSTCONDICIONES Devuelve el valor total del servicio, para poder generar la factura.
ESCENARIO NORMAL
ACTORES SISTEMA
1. Clic en el botón calcular costo
2. Despliega ventana para ingreso del
código del servicio.
3. Ingresa el código del servicio y da clic en
el botón aceptar.
4. Realiza la consulta de los costos y gastos
generados por el servicio.
5. Realiza la sumatoria de los valores
correspondientes al servicio prestado.
6. Calcula la utilidad y muestra el resultado
final.
4.1 Genera mensaje de error al no
encontrar en servicio buscado.
4.2 Devuelve al usuario a la pantalla
principal.
Figura 15 - Diagrama de actividades calcular costo de servicio
13.3.1.2 CASO DE USO: Consultar datos de servicio
ACTORES Despachador, Operador Callcenter
TIPO Primario
DESCRIPCION Permite consultar toda la información del servicio, así como el historial
de los eventos que han ocurrido durante la prestación del servicio.
REFERENCIAS
CRUZADAS
Buscar servicio.
PRECONDICIONES Se debe tener el identificador del servicio para buscarlo y poder agregar
la información al servicio.
POSTCONDICIONES Devuelve la información y todo el historial de la prestación del servicio.
ESCENARIO NORMAL
ACTORES SISTEMA
1. El usuario da clic en el botón consultar
servicio.
2. El sistema despliega una ventana para
ingresar el número del servicio a
consultar.
3. Ingresa el número del servicio
4. Da clic en el botón consultar
5. Genera la consulta a la base de datos.
6. Transforma la información recibida de la
base de datos.
7. Muestra una ventana con toda la
información del servicio.
4.1 Da clic en el botón cancelar
4.2 Devuelve al usuario a la ventana anterior
6.1 Muestra error al no encontrar datos del
servicio ingresado.
6.2 Devuelve al usuario a la ventana anterior.
Figura 16 - Diagrama de actividades consultar datos de servicio
13.3.1.3 CASO DE USO: Generar factura
ACTORES Despachador
TIPO Primario
DESCRIPCION Permite generar la factura por la prestación de un servicio que será
enviada a la aseguradora para su posterior cobro.
REFERENCIAS
CRUZADAS
Calcular costo del servicio.
PRECONDICIONES Para poder generar la factura el estado del servicio debe estar en
culminado y ya debe tener un costo calculado.
POSTCONDICIONES
ESCENARIO NORMAL
ACTORES SISTEMA
1. Da clic en la opción generar factura
2. El sistema muestra la ventana para buscar
el servicio.
3. Ingresa el número del servicio a buscar.
4. Devuelve los datos del servicio.
5. Da clic en la opción generar factura.
6. Valida las condiciones para generar la
factura.
7. Se genera la factura con el valor a cobrar
a la aseguradora
4.1 Devuelve mensaje de error al no
encontrar datos del servicio.
4.2 Devuelve al usuario a la ventana
anterior.
5.1 Da clic en el botón cancelar
5.2 Devuelve al usuario a la ventana anterior.
6.1 Muestra mensaje de error al no
cumplirse las condiciones para generar la
factura.
6.2 Devuelve al usuario a la ventana
anterior.
Figura 17 - Diagrama de actividades generar factura
13.4 MODULO GESTIÓN DE ACCESO
Dentro de este módulo se contemplan las actividades relacionadas con el acceso a la aplicación por parte
de los usuarios, tales como el inicio de sesión y la configuración del entorno gráfico de la aplicación de
acuerdo al rol que tenga asignado el usuario al momento del ingreso a la aplicación.
Figura 18-Modulo gestión de acceso
13.4.1 ESPECIFICACIÓN DE CASOS DE USO
A continuación se muestra la especificación de cada uno de los casos de uso propuestos en el
modelo, acompañados de su respectivo diagrama de actividades.
13.4.1.1 CASO DE USO: Abrir aplicación
ACTORES Usuario
TIPO Primario
DESCRIPCION Permite desplegar el entorno grafico de la aplicación, realizar la conexión
a la base de datos y al servidor de procesos.
REFERENCIAS
CRUZADAS
Iniciar sesión
PRECONDICIONES
POSTCONDICIONES La aplicación queda lista para que los usuario puedan iniciar sesión
ESCENARIO NORMAL
ACTORES SISTEMA
1. Doble clic en el icono de la aplicación
2. Realiza la conexión a la base de datos.
3. Despliega entorno gráfico de la
aplicación.
4. Habilita campos de texto para ingresar
nombre de usuario y contraseña.
2.1 La conexión a la base de datos no fue
exitosa, muestra mensaje de error de
conexión.
2.2 Intenta realizar la conexión a la base
de datos.
2.3 Cierra la aplicación
Figura 19- Diagrama de actividades abrir aplicación
13.4.1.2 CASO DE USO: Iniciar Sesión
ACTORES Usuario
TIPO Primario
DESCRIPCION Permite al usuario digitar su nombre usuario y contraseña para que sean
validados por la aplicación para que este pueda tener acceso, además de
generar un registro de acceso a la aplicación
REFERENCIAS
CRUZADAS
Abrir aplicación, configurar entorno de acuerdo al rol
PRECONDICIONES Inicio de la aplicación
POSTCONDICIONES Permite que los usuarios puedan ejecutar sus labores dentro de la
aplicación, los usuario quedan autenticados dentro de la aplicación.
ESCENARIO NORMAL
ACTORES SISTEMA
1. Ingresa nombre de usuario.
2. Ingresa contraseña.
3. Da clic en el botón aceptar.
4. Valida el nombre de usuario y la
contraseña en la base de datos.
5. Despliega ventana inicial de la aplicación,
configurada de acuerdo al rol.
6. Genera registro de acceso a la aplicación.
4.1. Si usuario o contraseña no son correctos
muestra mensaje de error.
4.2. Despliega nuevamente campos para
ingreso de usuario y contraseña
4.3 Ingresa nuevamente nombre de usuario
4.4 Ingresa contraseña
Figura 20 - Diagrama de actividades iniciar sesión
13.4.1.3 CASO DE USO: Configurar entorno de acuerdo al rol
ACTORES Usuarios
TIPO Primario
DESCRIPCION Permite que la aplicación muestre un entorno gráfico acorde al rol del
usuario que inicio sesión de modo que se muestren únicamente las
funcionalidades a las que puede acceder el usuario
REFERENCIAS
CRUZADAS
Iniciar sesión
PRECONDICIONES Inicio de sesión del usuario
POSTCONDICIONES La aplicación queda lista para que los usuarios puedan hacer uso de sus
funcionalidades.
ESCENARIO NORMAL
ACTORES SISTEMA
1. Consulta del rol de usuario en la base de
datos.
2. Configura entorno grafico habilitando las
opciones asignadas al rol.
Figura 21 - Diagrama de actividades configurar entorno de acuerdo al rol
13.4.1.4 CASO DE USO: Cambiar contraseña
ACTORES Usuarios
TIPO Primario
DESCRIPCION Permite que los usuarios de la aplicación puedan cambiar la contraseña
de acceso que fue asignada inicialmente de manera que el usuario sea el
único que la conozca.
REFERENCIAS
CRUZADAS
PRECONDICIONES El usuario debe estar logueado en la aplicación
POSTCONDICIONES La contraseña ha sido cambiada y es conocida únicamente por el
propietario.
ESCENARIO NORMAL
ACTORES SISTEMA
1. Clic en la opción cambiar contraseña.
2. Despliega ventana con campos para el
ingreso de antigua y nueva contraseña.
3. Ingresa la contraseña antigua.
4. Ingresa la nueva contraseña en los dos
campos habilitados.
5. Valida la contraseña actual.
6. Verifica que la contraseña nueva
ingresada coincida en los dos campos.
7. Actualiza la contraseña nueva en la base
de datos.
8. Muestra mensaje de confirmación de
cambio de contraseña.
5.1. La contraseña actual no es la correcta,
muestra mensaje de error.
5.2. Ingresa los datos de la contraseña
actual y la contraseña nueva.
6.1. Las contraseñas nuevas no coinciden,
muestra mensaje de error.
6.2. Ingresa los datos de la contraseña
actual y la contraseña nueva.
7.1. No se pueden actualizar los datos en la
base de datos, muestra mensaje de error.
7.2. Despliega ventana con campos para el
ingreso de antigua y nueva contraseña
Figura 22- Diagrama de actividades cambiar contraseña
13.4.1.5 CASO DE USO: Cerrar sesión
ACTORES Usuarios
TIPO Primario
DESCRIPCION Permite a los usuarios dejar la aplicación inhabilitada para realizar
cualquier tipo de transacción, lo que evita suplantaciones dentro del
sistema.
REFERENCIAS
CRUZADAS
Cerrar aplicación
PRECONDICIONES El usuario debe haber iniciado sesión previamente.
POSTCONDICIONES El usuario queda por fuera de la aplicación de manera que no tiene la
posibilidad de realizar ningún tipo de actividad dentro de la aplicación
ESCENARIO NORMAL
ACTORES SISTEMA
1. Da clic en la opción cerrar sesión
2. Muestra ventana de confirmación para
guardar o no los cambios que se han
hecho.
3. Selecciona la opción de guardar o no.
4. Guarda o descarta los cambios.
5. Cierra el entorno gráfico de la aplicación
6. Muestra la ventana inicial para iniciar
sesión.
4.1 No se pudieron guardar los datos,
muestra mensaje de error.
4.2 cierra el mensaje de error.
4.3 Trata de guardar los datos
nuevamente.
Figura 23 - Diagrama de actividades cerrar sesión
13.4.1.6 CASO DE USO: Cerrar aplicación
ACTORES Usuarios
TIPO Primario
DESCRIPCION Cierra la aplicación, lo que genera que se cierre el entorno gráfico, se
elimine la conexión a la base de datos y al motor de servicios.
REFERENCIAS
CRUZADAS
Cerrar sesión
PRECONDICIONES El usuario debe haber cerrado sesión antes de cerrar la aplicación.
POSTCONDICIONES Queda cerrada la conexión a la base de datos y cualquier sesión que
hubiera podido estar abierta.
ESCENARIO NORMAL
ACTORES SISTEMA
1. Usuario cierra la ventana de la aplicación
o da clic en el botón de cerrar la
aplicación.
2. Se cierra el entorno grafico de la
aplicación.
3. Se cierra la conexión con la base de datos
y el motor de procesos.
Figura 24 - Diagrama de actividades cerrar aplicación
13.5 MODULO GESTIÓN DE SERVICIOS
Este módulo está diseñado con el fin de permitirle a los usuarios de la aplicación el manejo de
todas las posibles opciones relacionadas con la recepción, creación, asignación, ejecución y
finalización de los servicios que pueden ser prestados por la empresa tales como el servicio de
grúa, carro taller y desplazamiento.
Figura 25 - Modulo gestión de servicios
13.5.1 ESPECIFICACIÓN DE CASOS DE USO
A continuación se muestra la especificación de cada uno de los casos de uso propuestos en el
modelo, acompañado de su respectivo diagrama de actividades.
13.5.1.1 CASO DE USO: Registrar datos del servicio
ACTORES Operador Callcenter
TIPO Primario
DESCRIPCION Permite realizar el registro de los datos de prestación del servicio tales
como tipo de servicio, ubicación del servicio, datos del asegurado, etc.
REFERENCIAS
CRUZADAS
Crear servicio
PRECONDICIONES El operador de callcenter debe estar logueado dentro de la aplicación
con el rol que le permita ejecutar el registro de los datos.
POSTCONDICIONES Quedan registrados los datos del servicio para que este pueda ser
asignado a un operario.
ESCENARIO NORMAL
ACTORES SISTEMA
1. El operador callcenter da clic en el botón
de crear servicio.
2. Consulta la disponibilidad para la
prestación del servicio.
3. Despliega la ventana para ingresar los
datos del servicio.
4. El operador ingresa los datos solicitados.
5. Da clic en el botón guardar
6. Se almacenan temporalmente los datos
iniciales del servicio.
7. Despliega la ventana para asociar un
cliente al servicio.
8. Selecciona el cliente a asociar al servicio.
9. Almacena temporalmente el cliente
asociado.
10. Muestra ventana con los datos del servicio
ingresados
11. Da clic en el botón aceptar confirmando
los datos que ha ingresado previamente
12. Se almacenan los datos en la base de
datos.
2.1 No hay disponibilidad, muestra
mensaje y devuelve al usuario a la
pantalla principal.
11.1 Da clic en cancelar y modifica los
datos ingresados.
12.1 Muestra mensaje de error al
almacenar los datos, devuelve al usuario a
la pantalla anterior.
Figura 26- Diagrama de actividades registrar datos del servicio
13.5.1.2 CASO DE USO: Asociar cliente
ACTORES Operador Callcenter
TIPO Primario
DESCRIPCION Permite asociar una de las aseguradoras que se encuentran registradas en
la base de datos al servicio que se está solicitando.
REFERENCIAS
CRUZADAS
Crear servicio
PRECONDICIONES El operador de callcenter debe estar logueado dentro de la aplicación,
deben existir clientes en la base de datos de manera que puedan ser
asociados a un servicio.
POSTCONDICIONES El servicio queda con un cliente asociado de manera que se puede
generar y hacer el cobro de la factura al cliente.
ESCENARIO NORMAL
ACTORES SISTEMA
1. El operador da clic en el botón asociar
cliente.
2. Realiza la consulta de los clientes
existentes activos.
3. Muestra la ventana con el listado de datos
devueltos por la consulta.
4. Selecciona el cliente dentro del listado.
5. Da clic en el botón asociar
6. Asocia al cliente al servicio y almacena
los datos.
4.1 Da clic en el botón cancelar
4.2 Devuelve al usuario a la ventana anterior.
6.1 Muestra mensaje de error y devuelve al
usuario a la ventana anterior.
Figura 27- Diagrama de actividades asociar cliente
13.5.1.3 CASO DE USO: Asociar Operario
ACTORES Despachador
TIPO Primario
DESCRIPCION Permite asignar un operario, que se encuentre disponible, al servicio.
REFERENCIAS
CRUZADAS
Asociar vehículo.
PRECONDICIONES El despachador debe estar logueado en la aplicación, deben existir
operarios y vehículos disponibles para ser asignados al servicio, debe
estar abierta la ventana del servicio al cual se le asociara el operario.
POSTCONDICIONES El servicio queda con un operario asignado, quien será el que preste el
servicio.
ESCENARIO NORMAL
ACTORES SISTEMA
1. El operador da clic en el botón asociar
operario.
2. Realiza la consulta de los operarios
existentes disponibles.
3. Muestra la ventana con el listado de datos
devueltos por la consulta.
4. Selecciona el operario dentro del listado.
5. Da clic en el botón asociar
6. Asocia al operario al servicio y almacena
los datos en la aplicación.
7. Muestra mensaje de confirmación.
4.1 Da clic en el botón cancelar
4.2 Devuelve al usuario a la ventana anterior.
6.1 Muestra mensaje de error y devuelve al
usuario a la ventana anterior.
Figura 28- Diagrama de actividades asociar operario
13.5.1.4 CASO DE USO: Asignar vehículo
ACTORES Despachador
TIPO Primario
DESCRIPCION Permite asociar un vehículo al servicio, dependiendo del tipo de servicio
que se vaya a prestar (grúa, carro taller)
REFERENCIAS
CRUZADAS
Asignar operario
PRECONDICIONES El despachador debe estar logueado en la aplicación, debe haber
vehículos disponibles para ser asignados al servicio.
POSTCONDICIONES El servicio queda con un vehículo asignado para la prestación del mismo.
ESCENARIO NORMAL
ACTORES SISTEMA
1. El operador da clic en el botón asociar
vehículo.
2. Realiza la consulta de los vehículos
disponibles dependiendo el tipo de
servicio.
3. Muestra la ventana con el listado de datos
devueltos por la consulta.
4. Selecciona el vehículo dentro del listado.
5. Da clic en el botón asociar
6. Asocia el vehículo al servicio y almacena
los datos.
4.1 Da clic en el botón cancelar
4.2 Devuelve al usuario a la ventana anterior.
6.1 Muestra mensaje de error y devuelve al
usuario a la ventana anterior.
Figura 29- Diagrama de actividades asignar vehículo
13.5.1.5 CASO DE USO: Crear servicio
ACTORES Operador Callcenter
TIPO Primario
DESCRIPCION Permite generar el registro de la solicitud de prestación de un servicio,
asignándole un identificador único para que pueda ser procesado
posteriormente, además de asociarle un estado inicial al servicio.
REFERENCIAS
CRUZADAS
PRECONDICIONES El operador debe estar logueado dentro de la aplicación. Se debe tener un
registro de la forma de contacto para la solicitud del servicio
POSTCONDICIONES El servicio queda listo para que le pueda ser asignado un operario y un
vehículo.
ESCENARIO NORMAL
ACTORES SISTEMA
1. El operador da clic en la opción crear
servicio.
2. Despliega el entorno grafico para la
creación del servicio.
3. Diligencia todos los campos solicitados
por la aplicación
4. Da clic en el botón guardar.
5. Captura y almacena los datos en la base
de datos.
6. Muestra mensaje de confirmación de la
creación del servicio.
4.1 Da clic en el botón cancelar.
4.2 Devuelve al usuario a la ventana
principal.
5.1 Muestra mensaje de error al
almacenar los datos.
5.2 Devuelve al usuario a la pantalla
anterior.
Figura 30- Diagrama de actividades crear servicio
13.5.1.6 CASO DE USO: Consultar disponibilidad
ACTORES Operador callcenter
TIPO Primario
DESCRIPCION Permite establecer si hay recursos disponibles para la prestación del
servicio (Operarios y vehículos), en caso de que haya devuelve un listado
de todos los recursos disponibles para la prestación del servicio.
REFERENCIAS CRUZADAS
PRECONDICIONES
POSTCONDICIONES El sistema da un resultado si hay o no disponibilidad para la prestación
del servicio.
ESCENARIO NORMAL
ACTORES SISTEMA
1. Clic en el botón consultar disponibilidad.
2. Despliega ventana para ingreso de datos
3. Ingresa los datos solicitados.
4. Clic en el botón aceptar
5. Válida campos diligenciados.
6. Realiza consulta
7. Recibe y transforma los datos obtenidos.
8. Muestra mensaje con las opciones
disponibles.
8.1 Muestra mensaje de indisponibilidad.
Figura 31 - Diagrama de actividades consultar disponibilidad
13.5.1.7 CASO DE USO: Modificar datos del servicio
ACTORES Operador Callcenter
TIPO Primario
DESCRIPCION Permite que los datos registrados inicialmente en el servicio puedan ser
modificados.
REFERENCIAS
CRUZADAS
PRECONDICIONES El operador debe estar logueado en la aplicación, el servicio debe tener
datos asociados para que puedan ser modificados
POSTCONDICIONES
ESCENARIO NORMAL
ACTORES SISTEMA
1. Da clic en la opción modificar servicios.
2. Despliega la ventana para buscar los
servicios.
3. Ingresa el servicio a buscar
4. Muestra la ventana con los datos del
servicio con los campos modificables.
5. Modifica los datos del servicio
6. Da clic en el botón guardar
7. Almacena los datos del servicio.
8. Muestra mensaje de confirmación
6.1 Da clic en el botón cancelar.
6.2 Devuelve al usuario a la ventana
principal.
7.1 Error al almacenar los datos.
7.2 Muestra mensaje de error y devuelve
al usuario a la ventana anterior.
Figura 32 - Diagrama de actividades modificar datos del servicio
13.5.1.8 CASO DE USO: Cambiar estado del servicio
ACTORES Operador de callcenter
TIPO Primario
DESCRIPCION Permite que durante el tiempo que dure la prestación del servicio, se le
pueda asignar y cambiar el estado al servicio de manera que se pueda
establecer cuál ha sido la evolución del mismo.
REFERENCIAS
CRUZADAS
Buscar servicio
PRECONDICIONES El operador debe estar logueado dentro de la aplicación, debe haber un
servicio previamente creado el cual tenga asignado operario y vehículo
POSTCONDICIONES
ESCENARIO NORMAL
ACTORES SISTEMA
1. Usuario selecciona la opción
cambiar estado del servicio.
2. Muestra la ventana para buscar los
servicios.
3. Digita el número de servicio a buscar.
4. Devuelve una ventana con los datos del
servicio donde la opción de estado del
servicio es modificable.
5. Cambia el estado del servicio.
6. Da clic en el botón guardar.
7. Almacena los datos del servicio.
8. Muestra mensaje de confirmación
6.1. Da clic en el botón cancelar
6.2. Devuelve al usuario a la ventana anterior
7.1. Error al almacenar los datos, muestra
mensaje.
7.2. Devuelve al usuario a la ventana anterior
Figura 33- Diagrama de actividades cambiar estado del servicio
13.5.1.9 CASO DE USO: Buscar servicio
ACTORES Operador Callcenter, Despachador
TIPO Primario
DESCRIPCION Permite buscar dentro de la base de datos un servicio específico mediante
su número de identificación.
REFERENCIAS
CRUZADAS
PRECONDICIONES Se debe conocer el número de identificación asociado al servicio.
POSTCONDICIONES
ESCENARIO NORMAL
ACTORES SISTEMA
1. El usuario da clic en la opción buscar
servicio.
2. Despliega la ventana para ingresar el
número del servicio a buscar.
3. Ingresa el número del servicio a buscar.
4. Captura los datos y envía la consulta.
5. Recibe los datos de la consulta y muestra
una ventana con la información asociada.
5.1 Muestra mensaje de error al no
encontrar datos.
5.2 Devuelve al usuario a la ventana
anterior.
Figura 34- Diagrama de actividades buscar servicio
13.5.1.10 CASO DE USO: Agregar evento
ACTORES Operador callcenter
TIPO Primario
DESCRIPCION Permite asociar un evento extraordinario a un servicio de manera que se
pueda llevar un histórico de los eventos asociados al mismo
REFERENCIAS
CRUZADAS
Buscar servicio
PRECONDICIONES El operador debe estar logueado dentro de la aplicación, debe existir un
servicio al cual se le agregue el evento.
POSTCONDICIONES
ESCENARIO NORMAL
ACTORES SISTEMA
1. El usuario da clic en la opción agregar
evento.
2. Despliega la ventana para buscar el
servicio al cual asociar el evento.
3. Digita el número del servicio.
4. Da clic en el botón aceptar
5. Realiza la búsqueda del servicio y
devuelve los datos del servicio.
6. Da clic en el botón agregar evento
7. Habilita el campo para ingresar la
descripción del evento.
8. Ingresa la descripción del evento.
9. Da clic en el botón guardar.
10. Captura los datos nuevos y los almacena
11. Muestra mensaje de confirmación.
4.1 Da clic en el botón cancelar
4.2 Devuelve al usuario a la ventana
anterior.
6.1. Da clic en el botón cancelar
6.2 Devuelve al usuario a la ventana
anterior.
Figura 35- Diagrama de actividades agregar evento
13.5.1.11 CASO DE USO: Cancelar servicio
ACTORES Operador callcenter, despachador, cliente
TIPO Primario
DESCRIPCION Permite cancelar un servicio que se encuentre en estado listo para iniciar
o dirigiéndose al lugar, por parte del cliente de manera externa o por
parte del operador o despachador de manera interna.
REFERENCIAS
CRUZADAS
Buscar servicio
PRECONDICIONES El usuario debe estar logueado dentro de la aplicación, debe existir el
servicio que se desee cancelar, el estado del servicio debe ser listo para
iniciar o dirigiéndose al lugar.
POSTCONDICIONES
ESCENARIO NORMAL
ACTORES SISTEMA
1. El usuario da clic en la opción cancelar
servicio.
2. Despliega la ventana para buscar el
servicio que se desea cancelar.
3. Digita el número del servicio.
4. Da clic en el botón aceptar
5. Realiza la búsqueda del servicio y
devuelve los datos del servicio.
6. Da clic en el botón cancelar servicio.
7. Verifica el estado actual del servicio y lo
cancela.
8. Envía notificación de la cancelación del
servicio.
4.1 Da clic en el botón cancelar
4.2 Devuelve al usuario a la ventana
anterior.
7.1 El estado del servicio no permite
cancelar el servicio, muestra mensaje de
error.
7.2 Devuelve al usuario a la ventana
anterior.
Figura 36- Diagrama de actividades cancelar servicio
13.5.1.12 CASO DE USO: Solicitar servicio
ACTORES Cliente
TIPO Primario
DESCRIPCION Permite realizar la solicitud de un servicio mediante la aplicación
REFERENCIAS
CRUZADAS
PRECONDICIONES El cliente debe estar logueado dentro de la aplicación,
POSTCONDICIONES Se crea la solicitud de un servicio de manera que pueda ser procesada
dentro de la empresa para su posterior prestación.
ESCENARIO NORMAL
ACTORES SISTEMA
1. El usuario da clic en el botón solicitar
servicio.
2. El sistema muestra una ventana para
digitar todos los datos referentes al
servicio.
3. El usuario digita la información
solicitada.
4. Da clic en el botón aceptar.
5. El sistema captura los datos y los
almacena.
6. Muestra mensaje de confirmación, envía
notificación.
5.1 Muestra mensaje de error al no poder
guardar los datos.
5.2 Devuelve al usuario a la ventana
anterior.
Figura 37- Diagrama de actividades solicitar servicio
13.6 BOCETOS VISUALES DE LA INTERFAZ GRÁFICA DE USUARIO
A continuación se muestran los bocetos de las interfaces de usuario que serán desarrolladas para
dar solución al problema planteado inicialmente, estos bocetos corresponden a ventanas que serán
desplegadas por un navegador web a lo largo de la ejecución de todas las funcionalidades de la
aplicación.
13.6.1 Iniciar sesión
Esta interfaz les permite a los usuarios ingresar su nombre de usuario y contraseña para acceder a
la aplicación.
Figura 38 Boceto visual iniciar sesión
13.6.2 Crear usuario
Esta interfaz permite al administrador de la aplicación crear nuevos usuarios que puedan hacer
uso de la aplicación.
Figura 39 Boceto visual crear usuario
13.6.3 Registrar datos
Esta es la interfaz inicial donde se ingresan todos los datos necesarios para realizar la creación de
un usuario dentro de la aplicación.
Figura 40 Boceto visual registrar datos
13.6.4 Crear rol
Esta interfaz permite crear un rol nuevo dentro de la aplicación, esto para que posteriormente
pueda ser asignado a un usuario particular dentro de la aplicación.
Figura 41 Boceto visual crear rol
13.6.5 Buscar usuario
En esta interfaz se puede realizar la búsqueda de un usuario que haga parte de la aplicación, para
que sus atributos puedan ser modificados
.
Figura 42 Boceto visual buscar usuario
13.6.6 Editar roles
Esta interfaz le permite al administrador de usuarios de la aplicación modificar cualquier rol que
se encuentre creado dentro de la aplicación.
Figura 43 Boceto visual editar roles
13.6.7 Calcular costo de servicio
Esta interfaz le permite al administrador o despachador realizar el cálculo del valor total del
servicio para que posteriormente sea generada la factura para el cliente.
Figura 44 Boceto visual calcular costo servicio
13.6.8 Crear servicio
Esta interfaz permite realizar la creación de un nuevo servicio para su posterior ejecución.
Figura 45 Boceto visual crear servicio
13.6.9 Asignar cliente al servicio
Esta interfaz permite asignar un cliente al servicio que ha sido creado de manera que
posteriormente se pueda tener contacto con el cliente y generar la facturación por la prestación
del servicio.
Figura 46 Boceto visual Asignar cliente al servicio
13.6.10 Confirmación datos servicio
Mediante esta interfaz el usuario confirma que los datos con los cuales se creó el servicio sean
los correctos, esto con el fin de evitar errores en la prestación del mismo.
Figura 47 Boceto visual confirmación datos servicio
14 MODELO ESTRUCTURAL
Luego de realizar el respectivo análisis y entendimiento de los requisitos se diseñó un modelo
estructural que permitirá la elaboración del software para al apoyo en el manejo de los procesos
de la empresa LST el cual encapsula la lógica del negocio presente actualmente dentro de la
empresa.
14.1 DIAGRAMA DE CLASES
Figura 48 Módulos modelo estructural
El modelo estructural propuesto comprende tres módulos diseñados para atender los
requerimientos de acceso a la aplicación por parte de los usuarios, gestión y administración de
usuarios y gestión de servicios y generación de facturas, a continuación se muestra el detalle de
cada uno de los módulos.
14.1.1 GESTIÓN DE ACCESO
Figura 49 Diagrama de clases módulo gestión de acceso
Este módulo permite la interacción de los usuarios con la aplicación mediante la asignación de un
usuario de aplicación y una contraseña, además de asignar un rol al usuario el cual le permita tener
un entorno específico dentro de la aplicación que le permita ejecutar todas las tareas
correspondientes a su cargo dentro de la empresa, adicionalmente este módulo permite tener un
histórico de todos los datos personales de los usuarios que han existido dentro de la aplicación.
14.1.2 GESTIÓN DE USUARIOS
Figura 50 Diagrama de clases módulo gestión de usuarios
Este módulo permite realizar la creación, eliminación y administración de usuarios de la
aplicación, estos usuarios puedes ser internos, empleados de la empresa, o externos que son los
clientes que atiende la empresa. A los clientes internos se les asigna un rol dentro de la aplicación
para que puedan ejecutar sus actividades, y a los clientes se les asigna un código identificador el
cual permite que puedan ser asociados posteriormente a una factura luego de la prestación de un
servicio.
14.1.3 GESTIÓN DE SERVICIOS
Figura 51 Diagrama de clases módulo gestión de servicios
Este módulo permite la gestión total de los servicios que se prestan dentro de la empresa, desde su
solicitud y creación hasta culminación del servicio y la respectiva generación de la factura,
abordando los procesos correspondientes a la asignación de los operarios al servicio, control de
gastos durante el servicio, registro histórico de eventos asociados al servicio y en determinado caso
cancelación del servicio.
14.1.4 DICCIONARIO DE CLASES
A continuación se muestra la descripción de cada una de las clases propuestas con sus respectivos
atributos y métodos todas las clases propuestas poseen sus métodos get y set correspondientes para
cada uno de sus atributos.
MODULO GESTIÓN DE ACCESO
Clase Entorno
Atributos
Nombre Visibilidad Tipo Semantica
Usuario privado Usuario
Este atributo corresponde a la ejemplificación del usuario
que ingresa a la aplicación
MODULO GESTIÓN DE ACCESO
Clase CuentaUsuario
Atributos
Nombre Visibilidad Tipo Semantica
contraseña privado String
Es la contraseña que posee cada usuario para ingresa a
la aplicación
idCuenta privado Int
Numero identificador de la cuenta de cada uno de los
usuarios de la aplicación
usuario privado String
Es el nombre que asignan los usuario para ingresa a la
aplicación
MODULO GESTIÓN DE USUARIOS
Clase Usuario
Atributos
Nombre Visibilidad Tipo Semantica
apellidos public String Apellidos del usuario.
cuenta private CuentaUsuario
Cuenta que posee cada uno de los usuarios de la
aplicación.
direccion private String Direccion de ubicación del usuario.
documento private int
Número de documento de identificación del usuario
de la aplicación.
e-mail public String Correo electronico del usuario de la aplicación.
nombres public String Nombres completos del usuario de la aplicación.
rol private Rol
Rol que tiene asignado el usuario dentro de la
aplicación.
telefono public int Número de telefono fijo que posee el usuario.
telefonoMovil public int Número de telefono movil que posee el usuario.
tipoDocumento public int Especifica que tipo de documento posee el usuario.
MODULO GESTIÓN DE USUARIOS
Clase Cliente
Atributos
Nombre Visibilidad Tipo Semantica
ciudad privado String
Nombre de la ciudad dondo se encuentra ubicado el
cliente
idCliente privado String
Numero unico identificador del cliente dentro de la
aplicación
MODULO GESTIÓN DE USUARIOS
Clase UsuarioInterno
Atributos
Nombre Visibilidad Tipo Semantica
activo privado int
Estado del usuario dentro de la aplicación, indica si
esta activo o no.
codigoEmpleado privado int Codigo asigando por la empresa al empleado
fechaContratacion privado int
Fecha en la cual se vinculo el empleado con la
empresa.
fechaFin privado int
Fecha en la cual se retiro el empleado de la empresa,
en el caso de que el empleado ya no trabeje en la
empresa.
MODULO GESTIÓN DE SERVICIOS
Clase Gasto
Atributos
Nombre Visibilidad Tipo Semantica
descripcion private String
Descripción del gasto que se generó duarante la
prestación del servicio
idGasto public int Numero unico identificador del gasto.
valor private int Valor por el cual se registra el gasto.
MODULO GESTIÓN DE SERVICIOS
Clase Factura
Atributos
Nombre Visibilidad Tipo Semantica
cliente public Cliente
Ejemplificación del cliente para ser asigando a la
factura
descripcion public String
Descripcion de el servicio por el cual se genera la
factura
fecha public int Fecha en la cual se genera la factua.
idFactura private int Número unico de identificación de la factura
servicios public
set of
Servicio
Listado de todos los servicios por los cuales se genera
la factua.
valor private int Valor total por el cual se genera la factura.
MODULO GESTIÓN DE SERVICIOS
Clase Solicitud
Atributos
Nombre Visibilidad Tipo Semantica
descripcion private String
Descripción de la solicitud del cliente para la
prestación del servicio.
fecha public int
Fecha en la cual se realiza la solicitud por parte del
cliente.
idSolicitud public int
Número único de identificación de la solicitud dentro
de la aplicación
tipoSolicitud private int
Atributo que permite identificar cual es el tipo de
solicitud que se realiza.
usuarioRegistra public UsuarioInterno
Ejemplificación del usuario de la aplicación quien
realiza el registro de la solicitud del servicio.
MODULO GESTIÓN DE SERVICIOS
Clase EventoServicio
Atributos
Nombre Visibilidad Tipo Semantica
descripcion private String
Atributo que permite registra una corta descripción del
evento que se va a registrar, el cual sucedió durante la
prestación del servicio.
fecha private int Registro de la fecha en la cual ocurrio el evento.
hora private int Registro de la hora en la cual ocurrio el evento.
idServicio public int
Numero identificador del servicio al cual se le va a
asociar el evento que se generó.
ubicación public String Ubicación en donde ocurrio el evento.
MODULO GESTIÓN DE SERVICIOS
Clase Servicio
Atributos
Nombre Visibilidad Tipo Semantica
destino public String
Lugar en donde debe culminar la prestación del
servicio.
distancia public int
Distancia calculada entre el origen y el destino del
servicio
evento private
Set of
EventoServicio
Colección de eventos que se generaron durante la
prestación del servicio.
factura private Factura
Número de la factura asociada la prestación del
servicio
gastos private Set of Gasto
Colección de los gastos que se generan durante la
prestación del servicio.
origen public String Lugar en donde se inicia la prestación del servicio.
15 MODELO WORKFLOW
15.1 IDENTIFICACIÓN DE PROCESOS
Dentro de todos los procesos que existen dentro de la empresa se seleccionaron cuatro procesos
que son los que se implementaran en el sistema, a continuación se realiza la descripción de cada
uno de los procesos seleccionados para su automatización.
15.1.1 Consulta disponibilidad recursos.
El propósito general de este proceso es establecer si existen los recursos físicos necesarios para la
prestación de un servicio, la disponibilidad está relacionada directamente con el tipo de servicio
que se vaya a prestar por lo cual se debe tener en cuenta disponibilidad de vehículos y personas,
este proceso tiene como entradas la ubicación del usuario que solicita el servicio y el tipo de
servicio que se está solicitando, como salida del procesos se tiene un listado de todos los vehículos
y los operarios disponibles para la ejecución del servicio. El responsable de este proceso es el
operador de callcenter, él es el encargado de ingresar la información para su ejecución y de
verificar el resultado entregado por el proceso.
15.1.2 Asignar Operario.
Este proceso permite que dentro de los operarios que se encuentran disponibles para la prestación
del servicio el despachador seleccione uno operario el cual será encargado de realizar
completamente la ejecución del servicio. La entrada de este proceso el listado de operarios
disponibles y como salida este proceso asigna el operario seleccionado al servicio.
15.1.3 Registro gastos de servicio.
El propósito de este proceso es registrar cada uno de los gastos que se generan durante la
prestación del servicio, estos gastos son registrados por los operarios del vehículo y son tenidos en
cuenta para la liquidación del valor total del servicio, este proceso tiene como entradas la
descripción del gasto y el valor del mismo, la responsabilidad de la ejecución del proceso es del
operario de los vehículos y dicho proceso además es supervisado por el despachador quien verifica
los gastos que han sido ingresados durante la prestación del servicio.
15.1.4 Generación factura
Este proceso tiene como propósito principal la recolección de la información, gastos y costos
generados durante la prestación de un servicio para realizar los cálculos del valor total del servicio
por el cual debe ser generada la factura al cliente que realizo la solicitud del servicio. Este proceso
es responsabilidad del despachador, quien es el encargado de ejecutarlo una vez la prestación del
servicio hay culminado satisfactoriamente. Las entradas del servicio son los datos del servicio y
los gastos adicionales generados, esta información es tomada automáticamente de la base de datos,
el resultado del proceso es la factura que posteriormente es entregada al cliente.
15.2DISEÑO DE MODELO WORKFLOW
El diseño del modelo Workflow está basado en los cuatro procesos identificados inicialmente los
cuales intervienen en la ejecución del macro proceso sobre el cual está enfocado el desarrollo de
este proyecto que es la prestación del servicio a cualquier tipo de cliente, a continuación se muestra
el diseño basado en las premisas enunciadas anteriormente:
Figura 52 Diseño del modelo Workflow
Este diseño consta de ocho subprocesos, cada uno de ellos con sus respectivas actividades que
permiten la ejecución del macro procesos, los subprocesos son los siguientes:
- Consultar recursos disponibles: Con este subproceso el usuario puede hacer la consulta los
recursos (operario y vehículo) necesarios para la prestación del servicio de maneta que
puedan ser mostrados en la pantalla para que el usuario selecciones el más apropiado para
ser asignado a la prestación del servicio.
- Notificar cancelación: Este subproceso fue diseñado para que en caso de que no se
obtengan resultados de recursos disponibles (operario y/o vehículo), la aplicación
automáticamente se notificará al cliente que su servicio no será prestado por
indisponibilidad de recursos.
- Asignar Recursos: Mediante este proceso el despachador asigna un operario particular para
la prestación del servicio, el operario es seleccionado de la lista que muestra la consulta de
los recursos disponibles, una vez seleccionado, automáticamente se notifica al operario
para que se dirija al lugar a prestar el servicio.
- Confirmar inicio de servicio: Con este subproceso el operario notifica en la aplicación que
ha recibido los datos (Cliente, tipo de servicio y ubicación) y se dispone a prestar el
servicio.
- Finalizar servicio: Una vez terminado el servicio, el operario accede a la aplicación con el
fin de que pueda notificar la culminación del servicio, dejando una nota del resultado bien
sea que se haya culminado exitosamente o que se culminó debido a algún tipo de
inconveniente.
- Registrar gastos del servicio: Tras finalizar la prestación del servicio, el operario ingresa
datos de kilometraje, desplazamientos y eventuales gastos adicionales para la posterior
liquidación del servicio.
- Generar factura: En este subproceso el despachador consulta y puede agregar otros gastos
y costos a los ya registrados por el operario, para finalmente generar una factura que será
enviada al cliente. Con esto se da fin al proceso de prestación del servicio.
-
Adicionalmente se pueden identificar tres lanes que corresponden a los tres roles asociados a cada
uno de los empleados de la empresa, cada uno de estos roles tiene como función ejecutar una
actividad, seleccionar una opción o registrar algún tipo de dato necesario para que el flujo del
proceso continúe normalmente.
Este proceso está diseñado de manera que pueda ser integrado con los demás componentes del
sistema ya que en general, Bonita no ofrece una integración directa de un lenguaje de
programación, por el contrario trabaja con el standard BPEL y el modelo desarrollado es
compilado en un fichero de ese lenguaje esto quiere decir que la única posibilidad que se tiene es
la de invocar módulos lógicos individuales como servicios web, adicionalmente en caso de ser
necesario este proceso puede ser llamado desde otro proceso bien sea interno o externo al sistema,
para la integración con la aplicación java, el proceso diseñado, y que se ejecuta sobre Bonita es
capaz de desplegar procesos y publicarlos automáticamente usando Apache Axis2, que es un motor
de servicios web que debe ser invocado desde cualquier código Java a través de una petición en
un mensaje SOAP.
Adicionalmente el proceso fue pensado de manera que los usuarios puedan iniciar los procesos y
llevarán a cabo sus tareas además de monitorearlas teniendo disponibles tras vistas para dicho
monitoreo:
Procesos
Tareas
Notificaciones
En la vista de procesos los usuarios tendrán una lista de los procesos que estén activos y/o en
ejecución, adicionalmente de poder observar los procesos que se puedan lanzar de acuerdo al rol
que posee.
En la vista de tareas, aparecerán aquellas tareas que el usuario tenga que llevar a cabo de manera
que pueda continuar el flujo del proceso, se le mostrarán los formularios oportunos para aquellas
tareas que así lo requieran y además, podrán gestionar las tareas a través de un panel de acciones,
mediante el cual se puede saltar la tarea, reasignarla a otro usuario, rechazar la tarea, etc., todo esto
acorde al rol asignado.
Por último en la vista de notificaciones en donde aparecerán todas las notificaciones que se le
hayan enviado al usuario, resultado del workflow de los procesos instanciados.
El versátil motor de procesos que brinda Intalio permite la ejecución simultánea de este proceso
por uno o varios usuarios mediante la creación de instancias que como se dijo anteriormente
pueden ser monitoreadas para ver en tiempo real el estado en el cual se encuentra el proceso.
16 MODELO DE BASE DE DATOS
A continuación se muestra el diseño del modelo entidad relación planteado para dar solución al
manejo de los datos que se generan en la ejecución de los procesos dentro de la empresa. Este
diseño contempla el manejo tanto de datos de la aplicación como de los procesos bpm propuestos
inicialmente.
Figura 53 Modelo de base de datos
16.1 ENTIDADES
En el modelo planteado se propusieron las siguientes entidades:
Usuario
Servicios
Factura
Evento
Solicitud
Vehículos
Roles
Estado del servicio
Permisos
Clientes
Ubicaciones
Ciudades
Gastos
Estas entidades se basan en las operaciones propias del negocio encapsulando semánticamente la
lógica existente entre ellas.
16.2 DICCIONARIO DE DATOS
A continuación se muestra la descripción de cada una de las entidades propuestas inicialmente,
se hace una descripción breve de cada uno de sus atributos, así como su atributo primario.
USUARIO
Atributo Tipo Descripción
idUsuario INT
Número único asignado a cada uno de los usuarios que se
crean en la aplicación.
Nombres VARCHAR(45) Nombres completos del usuario de la aplicación.
Apellidos VARCHAR(45) Apellidos completos del usuario de la aplicación.
Roles_idRoles INT Numero identificador del rol asignado al usuario.
Numero_identificació
n VARCHAR(45) Número del documento de identidad del usuario.
usuario VARCHAR(45)
Nombre único que se le asigna al usuario para el ingreso a la
aplicación.
Contraseña VARCHAR(45) Contraseña asociada al usuario de ingreso a la aplicación.
Estado VARCHAR(45)
Estado en el cual se encuentra el usuario dentro de la
empresa.
Disponible TINYINT(1)
Disponibilidad del usuario para la prestación de algún
servicio.
tipoDoc VARCHAR(45) Tipo de documento de identidad del usuario de la aplicación
teléfono VARCHAR(45) Número telefónico fijo del usuario de la aplicación
telefonoMovil VARCHAR(45) Número telefónico celular del usuario de la aplicación
FechaInicio DATE Fecha en la cual se incorporó a la empresa.
FechaFin DATE Fecha en la cual se retiró de la empresa.
Atributo Primario: idUsuario
CLIENTES
Atributo Tipo Descripción
idClientes INT
Número único asignado a cada uno de los clientes que se
crean en la aplicación.
Tipo VARCHAR(45) Tipo de cliente, natural, jurídico o particular.
Nombre o razón
social VARCHAR(45) Nombre del cliente al cual se le prestan los servicios.
Telefono VARCHAR(45) Teléfono de contacto del cliente.
Dirección VARCHAR(45) Dirección en la cual se encuentra ubicado el cliente.
Ciudad VARCHAR(45) Ciudad en la cual se encuentra ubicado el cliente.
Atributo Primario: idClientes
ROLES
Atributo Tipo Descripción
idRoles INT
Número único asignado a los roles que existen dentro de la
aplicación.
Rol VARCHAR(45)
Nombre asignado a los roles para los usuarios de la
aplicación.
Atributo Primario: idRoles
PERMISOS
Atributo Tipo Descripción
idPermisos INT
Número único del permiso que será asignado al rol de un
usuario.
NombrePermiso VARCHAR(45)
Nombre descriptor del permiso que se asigna al rol de un
usuario.
DescripcionPermiso VARCHAR(45) Breve descripción del permiso creado.
Atributo Primario: idPermisos
PERMISOS_HAS_ROLES
Atributo Tipo Descripción
Permisos_idPermisos INT
Número único del permiso que será asignado al rol de un
usuario.
Roles_idRoles INT
Número único asignado a los roles que existen dentro de la
aplicación.
Atributo Primario: Permisos_idPermisos-Roles_idRoles
SERVICIOS
Atributo Tipo Descripción
idServicios INT Número único identificador del servicio.
Clientes_idClientes INT
Número identificador del cliente al cual se le está prestando
el servicio.
Vehiculos_idVehicul
os INT
Número identificador del vehículo que está realizando la
prestación del servicio
Estado_Servicio_idEs
tado_Servicio INT
Identificador del estado en el cual se encuentra el servicio en
el momento de la consulta.
Costo Final VARCHAR(45) Costo total que se generó por la prestación del servicio.
ubicaciones_origen INT
Ubicación donde se encuentra el asegurado desde donde se
inicia la prestación del servicio
ubicaciones_destino INT
Ubicación a donde se llevara el asegurado por la prestación
del servicio.
Distancia INT Distancia recorrida durante la prestación del servicio.
Tipo VARCHAR(45)
Tipo de servicio que se presta. (Carro taller, desplazamiento,
servicio de grúa).
operario INT
Código de Identificación del operario que está realizando la
prestación del servicio.
Atributo Primario: idServicios
VEHÍCULOS
Atributo Tipo Descripción
idVehiculos INT
Código interno de identificación de cada uno de los vehículos
de la empresa.
Tipo VARCHAR(45) Tipo de vehículo (grúa, carro taller, carro desplazamiento)
Placa VARCHAR(45) Placa del vehículo
Disponible TINYINT(1)
Estado de disponibilidad del vehículo para la prestación de un
servicio.
Atributo Primario: idVehiculos
FACTURA
Atributo Tipo Descripción
idFactura INT
Número único de identificación de las facturas que se
generan dentro de la empresa.
Servicios_idServicios INT
Número identificador del servicio sobre el cual se está
generando la factura.
Clientes_idClientes INT
Número identificador del cliente al cual se le está generando
la factura del servicio.
Fecha DATE Fecha de generación de la factura.
valor INT Valor total por el cual se genera la factura.
Descripción VARCHAR(200) Descripción del servicio prestado.
Atributo Primario: idFactura
ESTADO
Atributo Tipo Descripción
idEstado_Servicio INT
Número identificador del posible estado que puede tener el
servicio.
Estado VARCHAR(45)
Nombre descriptor del posible estado que puede tener el
servicio.
Atributo Primario: idEstado_Servicio
UBICACIONES
Atributo Tipo Descripción
idUbicacion INT
Número identificador de la ubicación donde se realiza la
prestación del servicio.
Nombre_ubicacion VARCHAR(45)
Nombre descriptivo de la ubicación donde se realiza la
prestación del servicio.
Descripción VARCHAR(45)
Descripción corta de la ubicación donde se ingresan
indicaciones adicionales para llegar al lugar.
ciudades_codigo INT
Código de la ciudad donde está ubicado el lugar de la
prestación del servicio.
Atributo Primario: idUbicacion
GASTOS
Atributo Tipo Descripción
idGastos INT
Número único identificador del gasto generado por la
prestación del servicio.
Servicios_idServicios INT
Numero identificador del servicio al cual se le asigna el
gasto generado.
Descripción VARCHAR(45) Descripción del gasto generado.
Valor INT Valor del gasto generado.
Atributo Primario: idGastos
EVENTO
Atributo Tipo Descripción
idEvento INT
Número único identificador del evento que se genera
durante la prestación del servicio.
Descripción VARCHAR(45)
Descripción del evento que se generó durante la prestación
del servicio.
Servicios_idServicios INT
Numero identificador del servicio al cual se le asigna el
evento que se generó.
Reporta VARCHAR(45)
Descripción de la persona y la razón por la cual se reporta el
evento.
fecha DATE Fecha en la cual se genera el evento.
hora TIME Hora en la cual se genera el evento.
ubicación VARCHAR(45) Ubicación en la cual se genera el evento.
Atributo Primario: idEvento
SOLICITUD
Atributo Tipo Descripción
idSolicitud INT
Número único identificador de la solicitud que se genera
para la prestación del servicio.
descripción VARCHAR(45) Descripción de la solicitud generada.
fecha VARCHAR(45) Fecha en la cual se realiza la solicitud
tipo VARCHAR(45) Tipo de solicitud.
Usuario_idUsuario INT Numero identificador del usuario que registra la solicitud.
Atributo Primario: idSolicitud
CIUDADES
Atributo Tipo Descripción
Código INT Código identificador de la ciudad.
Nombre VARCHAR(45) Nombre de la ciudad.
Atributo Primario: Código
CAPITULO IV – DESPLIEGUE
En esta sección se encuentran los manuales tanto de instalación como de uso de la aplicación,
debido a lo extenso del manual de instalación este se deja como adicional el cual puede ser
observado en el Anexo 2 de este documento.
17 MANUAL DE USUARIO
17.1 Aplicación Web
La aplicación Web de Prestación de servicios permite la edición de usuarios (empleados y
clientes), administración de roles de la aplicación, consulta de histórico de casos de prestación de
servicio registrados y Consulta de facturas generadas al finalizar casos de prestación de servicio
exitosamente.
17.2 Administración
Las opciones de administración permiten gestionar usuarios y los roles asignados a estos, así como
los permisos correspondientes a cada rol dentro de la aplicación.
17.2.1 Creación Usuario
Ingresar al menú "Administración" -> "Usuarios Crear Usuario":
Figura 54 Creación de ususario
A continuación se despliega la interfaz de creación de usuario:
Figura 55 Interfaz creación de usuario
Para crea un usuario, ingresar los datos solicitados en el formulario de creación y dar Clic en
"Terminar" para terminar la creación.
17.3 Administración de Roles
Una vez creados los usuarios es necesario asignar a estos un rol específico, para esto en el menú
administración también se pueden crear, consultar y editar los roles de usuario de la aplicación.
17.3.1 Creación de Roles
Ingresar al menú "Administración" -> "Gestión Roles"-> Crear Roles":
Figura 56 Menú crear roles
Diligenciar los campos solicitados, seleccionar los permisos del rol y dar clic en "Crear".
Figura 57 Campos creación roles
Para cancelar la creación dar clic en "Cancelar"
17.3.2 Consulta de Roles
Ingresar al menú "Administración" -> "Gestión Roles"-> Consultar Roles":
Figura 58 Menu consultar roles
Se muestra tabla con listado de roles:
Figura 59 Interfaz datos roles
Se muestra el detalle del nombre y descripción del rol, acompañados del botón "Editar" el cual
redirige a la interfaz de edición que permite editar las propiedades del rol así como los permisos
de este.
17.3.3 Consulta y edición de usuarios
La consulta de usuarios permite buscar los usuarios por nombre, documento o login de la
aplicación. Para acceder a la consulta de usuarios, ingresar al menú "Administración" ->
"Usuarios"-> Consultar Usuario":
Figura 60 Menu consultar usuarios
A continuación se redirige a la interfaz de consulta de usuario, se debe ingresar algún criterio de
búsqueda y dar clic en buscar
Figura 61Interfaz consulta usuario
Se muestran resultados:
Figura 62Resultados consulta usuarios
Desde la tabla de resultados es posible editar los roles o eliminar un usuario (siempre que el que
usuario que realiza la consulta tienga el rol de administrador).
17.3.4 Edición de Roles
Para editar los roles de un usuario, desde la búsqueda de usuarios seleccionar el botón "Roles", a
continuación se muestra la interfaz de edición de roles de usuario.
Figura 63Interfaz asignación roles
Para cambiar el rol del usuario seleccionar en la lista desplegable el rol a asigna y dar clic en
"Guardar":
Figura 64interfaz asignar rol
17.4 Registro de Servicios operador Call Center (BPM)
El registro y gestión de servicios prestados se realizan a través del BPM, donde se tiene disponible
el proceso de prestación del servicio.
Para iniciar el proceso de prestación de servicio se ingresa a la página principal del BPM con el
rol operador de Call Center
Figura 65 Interfaz acceso BPM
Ir a la pestaña Procesos, en esta se muestran los procesos que estan disponibles en el servido BPM,
y si el usuario está autorizado puede iniciar un nuevo caso del proceso.
Figura 66 Interfaz gestión de procesos
Seleccionar Proceso Prestar Servicio y luego hacer clic en “Inicio”. A continuación se muestra la
interfaz de inicio del servicio, donde se solicitan los datos básicos para dar inicio al servicio.
Para que el caso quede registrado en el sistema se debe seleccionar Cliente, ingresar direcciones
de origen y destino, tipo de servicio y dar clic en "Confirmar"
Se muestra confirmación de inicio del "Caso".
A continuación se queda en espera de que se encuentren los recursos disponibles para continuar el
caso, una vez encontrados será asignada la nueva tarea.
En caso de que no se encuentren recursos disponibles en los siguientes 10 minutos al registro de
la solicitud se cerrará el caso y se notificará automáticamente al cliente.
En caso contrario cuando se encuentren los recursos disponibles (tarea automática) se activa la
tarea asignar recursos, donde se muestran dos listas de selección con las opciones de conductor y
vehículos.
Figura 67 Interfaz asignar recursos
Tras asignar los recursos (operario y vehículo) se inicia la tarea de confirmación del servicio donde
el operador redacta mensajes de notificación para Cliente y Operario, estos mensajes de
notificación adicionalmente contienen todos los datos ingresados en las tareas anteriores.
Figura 68 Interfaz inicio de servicio
Dar clic en , para iniciar ejecutan las tareas de notificación al cliente y al operario, para
dar inicio a la prestación del servicio.
En esta etapa el caso pasa a ser controlado por el rol operario, quien confirma el inicio del servicio,
notificando si le fue posible ponerse en contacto con el cliente y agregando una observación.
Figura 69 Interfaz mensaje inicio servicio
En caso de no marcar la casilla de "Cliente encontrado" el proceso notificará la cancelación al
cliente y finaliza el caso.
Si se marca la "Cliente encontrado", se entiende que el servicio ha iniciado y se activa la tarea
finalizar servicios donde se registra una observación al finalizar el servicio.
Figura 70 Interfaz terminación servicio
Al finalizar el servicio se habilita la tarea registrar gastos donde el operario registra los gastos
generados por la prestación.
Figura 71 Interfaz registro de gastos
Registra gastos y observaciones y seleccionar la opción continuar.
A continuación se habilita la tarea Generar factura que genera la factura del servicio basándose en
los gastos registrados por el operario.
Figura 72 Interfaz generar factura
La factura generada se almacena en base de datos y está disponible en la aplicación Web, en el
módulo de Gestión.
CAPITULO V – CONCLUSIONES Y RECOMENDACIONES
18 REVISIÓN Y CIERRE
El propósito de las pruebas funcionales es encontrar errores y asegurarse que los módulos
funcionen tal y como lo previsto en el punto 12.1 donde se realizó la definición de requerimientos,
se comprobará el requerimiento con pruebas del tipo Caja Negra que permite detectar
funcionamiento incorrecto o incompleto, errores de interfaces, errores de inicio y errores de
terminación, los casos de prueba están diseñados con el fin de validar cual es el comportamiento
de la aplicación cuando se ingresan valores errados, se plantean de esta manera los casos de prueba
ya que al final de cada sprint se realizaron pruebas de funcionalidad de la aplicación en donde se
pudo observar que la aplicación cumplía con todos los requerimientos funcionales que fueron
establecidos inicialmente.
A continuación se describirá en forma general las pruebas funcionales que se realizaron a cada
uno de los módulos implementados con el fin de validar el comportamiento de la aplicación
cuando se ejecutan tareas que no están acorde al funcionamiento normal de la aplicación
18.1 Caso de prueba 1.
Este caso de prueba contempla la validación de los siguientes requerimientos funcionales:
RU-1 Registrar datos básicos de Usuarios internos
RU-2 Registrar datos básicos de Clientes
RU-3 Crear nombres de usuario y contraseñas para Clientes y Operadores
Se intentó crear un usuario y un cliente en la aplicación sin diligenciar todos los campos
solicitados, se obtuvo como resultado una ventana con el mensaje de error donde se indica cuales
campos son obligatorios para realizar la creación del usuario, adicionalmente se intentó crear dos
usuarios con el mismo login donde la aplicación respondió con una ventana mostrando un mensaje
de error donde se indicaba que ya había un usuario con el mismo login.
18.2 Caso de prueba 2.
Este caso de prueba contempla la validación de los siguientes requerimientos funcionales:
RU-4 Restringir acceso al sistema mediante la autenticación de usuarios.
Para la ejecución de este caso de prueba se validaron los siguientes escenarios:
- Ingresar a la aplicación con un login que no existe
- Ingresar a la aplicación con un login existente y un password inválido.
A estos escenarios la aplicación respondió con un mensaje de error indicando que el nombre de
usuario o password no son válidos, esto con el fin de aumentar la seguridad y no dar indicios a
los usuarios de cuál de los dos datos ingresados es el erróneo.
18.3 Caso de prueba 3.
Este caso de prueba contempla la validación de los siguientes requerimientos funcionales:
RU-7 Limitar el acceso del usuario cliente solo para solicitud y consulta de los servicios.
El escenario contemplado para este caso de prueba consistió en ingresar a a la aplicación son el rol
de un cliente y verificar que no se pudiera ejecutar ninguna actividad diferente a la de verificar el
estado de los servicios solicitados, al culminar este escenario de prueba se pudo establecer que con
el rol de usuario no hay posibilidad de realizar alguna actividad diferente ya que todos los botones
y menús correspondientes a las demás consultas no se encuentran visibles para el rol de cliente.
18.4 Caso de prueba 4.
Este caso de prueba contempla la validación de los siguientes requerimientos funcionales:
RS-2 Permitir asociar un Cliente al servicio que será prestado.
RS-3 Permitir asociar un operario para la prestación el servicio.
Este caso de prueba permite la validación de la asociación de usuarios y operadores a cualquier un
servicio, este caso se diseñó con los siguientes escenarios:
- Asignar un operario que no existe a un servicio.
- Asignar un cliente que no existe a un servicio.
- Asignar un operario a un servicio que no existe.
- Asignar un cliente a un servicio que no existe.
El resultado arrojado por la aplicación fue el mismo para todos los escenarios, mostrar una
ventana indicando que la operación que se trataba de realizar no se podía ejecutar ya que los
parámetros ingresados con concordaban con la información requerida.
Adicionalmente a estos casos de prueba enunciados, al final de cada uno de los Sprint se realizaron
pruebas funcionales sobre la aplicación con el fin de validar cada uno de los módulos desarrollados
en cada fase. A continuación se muestra una gráfica que relaciona la cantidad de errores que se
presentan en la aplicación luego de ejecutar las pruebas funcionales al final de cada uno de los
Sprint.
Figura 73 Cantidad de errores por Sprint
Al trabajar con metodologías ágiles, se busca llegar rápidamente a un prototipo a través de los
requerimientos que se actualizan al ejecutar las pruebas al final de cada Sprint. En cada etapa se
logró un acercamiento al producto final, lo que se ve reflejado en la disminución de errores a través
de las etapas y de la menor ejecución de las pruebas sobre las tareas relacionadas a los últimos
Sprint, al final del Sprint 6 se evidencia que el total de errores es cero, esto se logró luego de
realizar los ajustes correspondientes a cada módulo una vez realizadas las pruebas en cada Sprint
, lo que además se puede evidenciar en el funcionamiento de la aplicación donde se refleja que
esta cumple con el 100% de los requerimientos establecidos inicialmente.
02468
1012141618
Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6
Cant
idad
Sprint
Cantidad de errores
Cantidad de errores
19 CONCLUSIONES Y RECOMENDACIONES
Con el auge de las tecnologías de la información, se hace indispensable para cualquier tipo
de empresa poder dar acceso a sus clientes a sus servicios a través de herramientas
tecnológicas como aplicaciones Web donde sea posible solicitar o consumir directamente
los servicios ofrecidos por la organización, así como también permite brindar herramientas
para que los empleados puedan agilizar sus labores e incluso poder prestar sus servicio de
forma remota sin establecerse en un puesto de trabajo físico en la empresa.
Dentro de las empresas se hace indispensable contar con una definición clara de los
procesos, BPM aporta herramientas para el entendimiento de estos aportando información
detallada de las tareas y responsabilidades de los distintos roles dentro de la organización
en la ejecución de estos.
Contar con el modelado de los procesos mejora el procesamiento de información que por
lo general en las empresas pequeñas y medianas no se maneja de forma sistematizada, sino
de forma manual, dificultando el manejo de la información y en algunos casos haciendo
que la prestación de servicios que involucran a los clientes no sea eficiente. Mientras que
si se tiene definidos los procesos y en lo posible implementados en herramientas
informáticas, la productividad se incrementa y se facilita la adaptación de nuevos actores
(empleados) en la ejecución de estos.
Es importante destacar que en la elección de productos de software (en este caso el sistema
de BPM), se deben tener distintos factores, como los tipos de licencias donde en algunos
casos se debe adquirir una por cada actor que desee acceder al sistema, o licencias abiertas
donde se puede utilizar el sistema de forma gratuita pero con limitaciones como algunos
componentes no disponibles o límite de personas en la organización; también se debe
considerar dependiendo de las necesidades de la empresa y sus recursos para invertir en
Software la viabilidad de contar con un BPMS o dependiendo de los requerimientos de los
procesos misionales optar por un desarrollo a la medida.
En el desarrollo de aplicaciones es importante contar con una metodología de desarrollo
bien definida. Las Metodologías Agiles permiten el desarrollo controlado y en tiempos
definidos, estableciendo claramente los roles y responsabilidades dentro de los equipos de
trabajo, así como alcances posibles de cumplir en fechas definidas. En este caso (Scrum)
define los alcances a corto o mediano plazo (Sprints), permitiendo así tener avances
tangibles y esperados por los interesados en el desarrollo.
Establecer una arquitectura donde se tenga en cuenta en qué forma se van a integrar los
sistemas que se construyan o se implementen es vital para el desarrollo de un proyecto,
pues es importante tener claro que interfaces deben ser implementadas para que se acoplen
de manera correcta las aplicaciones sin que tengan problemas comunes como los de
concurrencia en la persistencia de datos.
Es importante una vez puesto en producción el prototipo desarrollado, tener actualizada la
información relacionada con los procesos que se ejecutan dentro de la empresa, esto facilita en
un futuro el poder actualizar o agregar nuevas funcionalidades a la aplicación.
La posibilidad e implementar un sistema GPS mejoraría los tiempos de respuesta para los servicios
ya que con ello es posible tener un valor más acertado de los tiempos de respuesta para los servicios
que se van a prestar.
20 BIBLIOGRAFÍA
1. ANDREU, R., RICART J. E. Y VALOR, J. (1991): Estrategia y Sistemas de
Información. Mc Graw-Hill, Madrid
2. BPMN 1.1 Specification http://www.omg.org/bpmn/Documents/BPMN_1-
1_Specification.pdf
3. BUENO Y MORCILLO(1993): La Competitividad De La Empresa
4. CHAIX, Y. (2007): SOA PRINCIPLES http://soaprinciples.com
5. DE LA TORRE, C (2012): Guía de Arquitectura N-Capas Orientada al Dominio con
.NET 4.0
6. ERL, T.(2007):SOA: Principles of Service Design
7. FISCHER, L. (2010):BPM and Workflow Handbook
8. GARIMELLA, K (2008): Introducción a BPM
9. HITPASS, B (2012): Business Process Management (BPM) Fundamentos y
Conceptos de Implementación
10. HOLLINGSWORTH, D (2005): The Workflow Reference Model
11. JESTON J. NELIS J. (2006): Business Process Management Practical Guidelines to
Successful Implementations.
12. LAUDON, K.C. Y LAUDON, J.P. (1996): Administración de los Sistemas de
Información, Prentice Hall, México
13. MONFORTE, M (1994): Sistemas de Información para la Dirección. Pirámide, Madrid
14. PORTER, M (1982): Estrategia competitiva. C.E.C.S.A., México
15. PRESSMAN, Roger(2005):Ingeniería del Software: Un Enfoque Práctico, (Sexta
Edición)
16. SUTHERLAND, J (2007): El método Scrum.
17. ORACLE (2003): ORACLE WORKFLOW USER´s GUIDE, Disponible en
http://www.oracle.com/technetwork/middleware/adapters/overview/index.html
18. OMG (2012), BPMN Specification, Disponible en
http://www.omg.org/bpmn/Documents/BPMN_1-1_Specification.pdf
19. INTALIO Inc. (2012): http://www.intalio.com/bpm
20. OASIS (2006), Reference Model for Service Oriented Architecture 1.0, Disponible en
http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf
21. W3C (2004), Web Services Architecture, Disponible en
http://www.w3.org/TR/ws-arch/wsa.pdf
ANEXO 1 Herramientas tecnológicas para la implementación de Workflow
Actualmente existen muchos WMS (Workflow Management System) que son un conjunto de
herramientas que proveen soporte a procesos de definición, comportamiento administración y
monitoreo de procesos Workflow. A pesar de la gran variedad de técnicas de implementación y
ambientes operacionales, en ninguna de las empresas de asistencia vial se cuenta con un WMS para
controlar los procesos empresariales o de prestación de servicios.
Dentro de los WMS´s más destacados se encuentran WASA29 un WMS orientado a objetos que tiene
como objetivo apoyar la ejecución de Workflow flexibles y distribuidos en ambientes
heterogéneos, ADEPT 10 que es un proyecto de investigación relacionado con el desarrollo de
sistemas de información orientado a procesos, EXOTICA 11 el cual es un grupo de investigación y
desarrollo de IBM enfocado en la administración avanzada de transacciones desarrollando la
aplicación FlowMark siendo este un sistema que soporta procesos de reingeniería así como la
definición y actualización constante de flujos de trabajo.
A continuación se relacionan algunas herramientas existentes para el manejo de procesos
Workflow, con el fin de establecer cuál de ellas es la más viable para ser usada en el desarrollo del
proyecto.
9 http://www09.sigmod.org/sigmod/sigmod99/eproceedings/papers/wasa1.pdf10 http://dbis.eprints.uni-ulm.de/620/1/ER_BPM_Workshop.pdf11 www.almaden.ibm.com/cs/exotica
Oracle Workflow
Entre las herramientas más populares para el desarrollo y administración de procesos Workflow se
encuentra Oracle Workflow [ORACLE, 2003] ya que ofrece un sistema completo de gestión
Workflow que permite la integración de procesos de negocio. Su tecnología permite el modelado,
automatización y mejora continua de los procesos de negocio, la información de enrutamiento de
cualquier tipo de acuerdo con las reglas de negocio definidas por el usuario. Oracle Workflow
automatiza y optimiza los procesos de negocio tanto dentro como fuera de la empresa, el apoyo a
las aplicaciones tradicionales basadas en Workflow, así como soluciones de integración de
negocios electrónicos (e-business Workflow-Integration). Oracle Workflow es único en ofrecer
una solución de flujo de trabajo tanto para los procesos internos y la coordinación de procesos de
negocios entre aplicaciones.
Intalio BPM
Otra herramienta muy popular y de software libre es Intalio BPM12 que permite a los analistas de
negocio y de TI colaborar en el diseño, implementación y gestión continua de todos los procesos
de negocio, ya sean pequeñas o grandes, simples o complejos, transaccional o Workflow.
Intalio está basado en Eclipse y posee un diseñador de BPMN que es capaz de traducir cualquier
diagrama BPMN a BPEL process completamente ejecutables en 2.0.
Dentro de las características que posee Intalio se destacan:
12 http://www.intalio.com/bpm
Creación e integración de formularios AJAX que ofrecen gran variedad de controles, junto con
el desarrollo de aplicaciones a más bajos costos de implementación.
Supervisión de la actividad a través de una vista global de todos los procesos de negocio
desplegados en la producción.
Interfaz de usuario web intuitiva para la gestión de flujo de trabajo y la supervisión de procesos
que permite la comprobación y validación dinámica para proyectos de pruebas, procesos de
depuración y evitar la implementación de los procesos incompletos.
Estándar de despliegue J2EE que se traduce en un alto rendimiento, fiabilidad y escalabilidad.
Integración nativa de SOA que permite a varios usuarios realizar diferentes tareas, supervisar
y gestionar la integración de servicios en todo el ciclo de vida útil de despliegue.
Servidores de Workflow
Entre los servidores Workflow se destacan los servidores Together Workflow Server13, y WSO214.
Together Workflow Server 15 (TWS) es un sistema de administración de Workflow basado en Java,
este servidor permite la implementación sencilla y eficiente de procesos de negocio y su
administración, contiene herramientas como Together Workflow Editor, donde se hace posible
automatizar procesos con tan solo modelarlos para luego ser lanzados en el servidor y consta de
una interfaz gráfica basada en Java.
Algunas ventajas de TWS son:
Minimizar el tiempo de ejecución de los procesos.
13 http://www.together.at/prod/workflow14 http://wso2.org15 http://www.together.at/prod/workflow
Saber el estado de las instancias del proceso en cualquier momento gracias al monitoreo
de procesos.
Tener registros y reportes de las ejecuciones del proceso, con el fin de mejorar el modelo.
Es altamente escalable al permitiendo hasta miles de usuarios y millones de transacciones
en la ejecución de los procesos.
En TWS se brinda soporte para procesos de Workflow automáticos, manuales o mixtos, hace
posible la invocación de programas Java, ejecutables nativos, y scripts en cualquier lenguaje,
servicios Web e interacciones humanas para el caso de los Workflow que son manejadas por Work
Items que se ejecutan de manera completamente manual.
El servidor de Business Process WSO216 permite a los desarrolladores desplegar fácilmente los
procesos de negocio elaborados con el estándar WS-BPEL, y también sirve para la gestión de
procesos de negocio y el entorno de SOA.
WSO2 está impulsado por el motor de orquestación Apache Director (ODE) que es un motor BPEL,
el servidor de Business Process WSO2 ofrece una consola gráfica fácil de implementar, administrar
y visualizar procesos.
Dentro de las características principales se encuentran:
Compatibilidad con WS-BPEL 172.0 y 1.1 BPEL4WS18.
16 http://wso2.org17 http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html18 http://xml.coverpages.org/bpel4ws.html
Ejecución en memoria para procesos ejecutables cortos.
Procesos garantizados con WS-Security y Kerberos.
Seguridad de la propagación de contexto a través de proceso.
Invocación segura de socios con WS-Security y Kerberos
Para la ejecución del proyecto se utilizará Bonita BPM para el modelado de procesos ya que este
software permite modelar procesos BPM y procesos Workflow, lo que le da un valor agregado con
relación a las demás herramientas de modelado, como motor de procesos se utilizará el motor
propio de Bonita por su versatilidad y facilidad en la ejecución de los procesos Workflow y la
notable reducción de tiempos en la ejecución de los procesos, comparado con otros motores de
procesos.
ANEXO 2 DESPLIEGUE DE COMPONENTES
A continuación se describe la instalación y configuración de las aplicaciones necesarias para la
ejecución del prototipo web desarrollado para la prestación de servicio de la empresa de
asistencia vial.
1. Creación Modelo de Base de Datos
1.1. Instalar "mysql-installer-community-5.6.23.0"
1.1.1. Configurar Usuario Administrador (root)
1.1.2. Agregar Usuario de Base de datos
1.1.3. Finalizar Instalación
1.2. Iniciar MySQL Workbench
Abrir la instancia local:
Ejecutar Script de creación de Base de datos asistenciaDB
2. Configurar Servidor JBoss EAP 6.3
Descomprimir el servidor jboss-eap-6.3.0.zip en la ubicación deseada <Ruta de instalación>.
Iniciar el servidor
Ingresar por línea de comandos a la ruta <Ruta de instalación>/bin
Ejecutar el bat Standalone.bat
Esperar a que termine el inicio del servidor.
2.1. Crear usuario administrador servidor Jboss
Ingresar por línea de comandos a la ruta <Ruta de instalación>/bin
Ejecutar add-user.bat
Ingresar la opción (a)
Ingresar nombre del nuevo usuario administrador
Ingresar password para el nuevo usuario
Dejar vacía la siguiente opción.
Confirmar creación
Configurar Driver MySql en el servidor JBoss
Copiar el archivo mysql-connector-java-5.1.35-bin.jar en la ruta Ruta de
instalación>/modules/com/mysql/main/
Crear el archivo module.xml en la ruta <Ruta de instalación>/modules/com/mysql/main/, como
se describe a continuación:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="com.mysql">
<resources>
<resource-root path="mysql-connector-java-5.1.35-bin.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
</dependencies>
</module>
Configurar datasource en el archivo standalone.xml que se encuentra en la ruta <Ruta de
instalación>/standalone/configuration/, agregando el datasource dentro del tag <datasources>:
<datasource jndi-name="java:jboss/datasources/AsistenciaDS" pool-name="asist_pool"
enabled="true" use-java-context="true">
<connection-url>jdbc:mysql://localhost:3306/tesisprueba</connection-url>
<driver>mysqlDrv</driver>
<security>
<user-name>Usuario de la base de datos</user-name>
<password>clave de la base de datos</password>
</security>
</datasource>
Y agregar el Driver dentro del tag <drivers> así:
<driver name="mysqlDrv" module="com.mysql">
<driver-class>com.mysql.jdbc.Driver</driver-class>
</driver>
Verificar en la consola administrativa que se haya creado exitosamente el DataSource:
Hacer test de conexión
Instalar "Ear" de Aplicación WEB
Ingresar a la consola administraticva de Jboss (http://127.0.0.1:9990/console/)
Ingresar Usuario creado en paso 1.
Ir a Runtime -> Server -> Manage Deployments
Seleccionar el botón Add y luego Explorar
Navegar hasta la ruta del archivo AISITV.ear
Abrir el archivo y dar clic en "Next".
Dar clic en "Save"
Seleccionar la opción "En/Disable"
Dar clic en "Confirm"
Verificar la instalación ingresando a http://localhost:8080/AsistenciaVial/:
Si la instalación fue exitosa se mostrará la pantalla de inicio de la aplicación:
Instalación BPM
El servidor de BPM de bonita funciona sobre un servidor JBOSS, por tanto algunos pasos de
configuración no serán descritos a detalle.
Inicio del Servidor
Descomprimir el archivo BonitaBPMCommunity-6.5.1-JBoss-7.1.1.Final, en la ruta que se desee
instalar.
Luego ir a la carpeta <Ruta de instalación>\bonita\client\platform\conf y abrir el archivo
platform-tenant-config.properties, y cabiar los valores de contraseña y usuario administrador por
defecto.
Iniciar el servidor desde <Ruta de instalación>/bin, ejecutando el archivo standalone.bat
Ingresar a la dirección e iniciar sesión con el usuario de configuración:
Ir al menú "Organización-> Roles" y hacer clic en el botón "crear un rol" y cree los roles
necesarios para la aplicación (Despachador, Operador Call Center, Operario Vehiculo, y
administrador):
A continuación ir al menú Ir al menú "Organización-> Usuarios" y crear los usuarios necesarios
para la prestación del servicio asignándoles los roles creados en el paso anterior.
A continuación dar clic en el botón "Añadir" bajo el titulo Membresía para asignar el rol:
Crear Usuario Administrador
De la misma forma que se creó el usuario anterior, crear un usuario destinado a la administracion
Ir al menú "Configuración -> Privilegios" y agregar el usuario al grupo de administradores:
Despliegue del Proceso
Iniciar sesión como el usuario administrador:
Ir al menú "Gestión de Procesos -> Procesos"
Seleccionar el botón instalar:
Instalar archivos BAR suministrados "Prestar Servicio--1.0.bar " y "Buscar Recursos--1.0.bar"
De esta forma quedan listos todos los componentes necesarios para el funcionamiento de la
aplicación.
