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
DESARROLLO DE UN PROTOTIPO DE SOFTWARE WEB EN TRES CAPAS 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
Proyecto final de grado en modalidad de trabajo de grado para optar por el título de Ingeniero deSistemas DIRECTOR:
Ing. Oswaldo Alberto Romero
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS BOGOTÁ–COLOMBIA
Nota de aceptación _________________________________________________________________ _________________________________________________________________
Firma del Jurado
Contenido
1. 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.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.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.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
Oracle Workflow ...192
Intalio BPM...192
Servidores de Workflow...193
1. LISTA DE FIGURAS
Figura 1 Mapa de Procesos típicos de realización del servicio Empresa LST (Logística al
servicio del transporte). Fuente propia... 25
Figura 2 Arquitectura de tres capas, [.NET Architecture guide, 2011] ... 38
Figura 3 Estructura trasversal del negocio. [HITPASS, 2012] ... 44
Figura 4 Estructura genérica de Workflow. [HOLLINGSWORTH, 2005]... 49
Figura 5 Modelo estructural- Módulos casos de uso ... 67
Figura 6, Actores del sistema... 68
Figura 7 Modulo gestión de usuarios... 70
Figura 8 - Diagrama de actividades crear usuario ... 72
Figura 9 - Diagrama de actividades registrar datos ... 74
Figura 10 - Diagrama de actividades crear rol... 76
Figura 11 - Diagrama de actividades cambiar rol de usuario ... 78
Figura 12 - Diagrama de actividades eliminar usuario ... 81
Figura 13 - Diagrama de actividades buscar usuario ... 83
Figura 14 - Modulo gestión de facturas ... 84
Figura 15 - Diagrama de actividades calcular costo de servicio... 86
Figura 16 - Diagrama de actividades consultar datos de servicio... 89
Figura 17 - Diagrama de actividades generar factura ... 91
Figura 18-Modulo gestión de acceso ... 92
Figura 19- Diagrama de actividades abrir aplicación ... 94
Figura 20 - Diagrama de actividades iniciar sesión ... 97
Figura 21 - Diagrama de actividades configurar entorno de acuerdo al rol... 99
Figura 22- Diagrama de actividades cambiar contraseña ... 102
Figura 23 - Diagrama de actividades cerrar sesión ... 104
Figura 24 - Diagrama de actividades cerrar aplicación ... 106
Figura 25 - Modulo gestión de servicios... 107
Figura 26- Diagrama de actividades registrar datos del servicio ... 110
Figura 27- Diagrama de actividades asociar cliente ... 112
Figura 28- Diagrama de actividades asociar operario... 114
Figura 29- Diagrama de actividades asignar vehículo ... 116
Figura 30- Diagrama de actividades crear servicio... 119
Figura 31 - Diagrama de actividades consultar disponibilidad... 121
Figura 32 - Diagrama de actividades modificar datos del servicio... 124
Figura 33- Diagrama de actividades cambiar estado del servicio... 126
Figura 35- Diagrama de actividades agregar evento... 131
Figura 36- Diagrama de actividades cancelar servicio ... 134
Figura 37- Diagrama de actividades solicitar servicio... 136
Figura 38 Boceto visual iniciar sesión ... 137
Figura 39 Boceto visual crear usuario ... 138
Figura 40 Boceto visual registrar datos ... 139
Figura 41 Boceto visual crear rol... 140
Figura 42 Boceto visual buscar usuario ... 140
Figura 43 Boceto visual editar roles ... 141
Figura 44 Boceto visual calcular costo servicio ... 141
Figura 45 Boceto visual crear servicio... 142
Figura 46 Boceto visual Asignar cliente al servicio ... 142
Figura 47 Boceto visual confirmación datos servicio... 143
Figura 48 Módulos modelo estructural ... 145
Figura 49 Diagrama de clases módulo gestión de acceso... 146
Figura 50 Diagrama de clases módulo gestión de usuarios ... 147
Figura 51 Diagrama de clases módulo gestión de servicios ... 148
Figura 52 Diseño del modelo Workflow ... 155
Figura 53 Modelo de base de datos... 159
Figura 54 Creación de ususario... 170
Figura 55 Interfaz creación de usuario... 170
Figura 56 Menú crear roles ... 171
Figura 57 Campos creación roles... 172
Figura 58 Menu consultar roles ... 172
Figura 59 Interfaz datos roles ... 173
Figura 60 Menu consultar usuarios... 173
Figura 61Interfaz consulta usuario... 174
Figura 62Resultados consulta usuarios ... 174
Figura 63Interfaz asignación roles... 175
Figura 64interfaz asignar rol ... 175
Figura 65 Interfaz acceso BPM... 176
Figura 66 Interfaz gestión de procesos ... 177
Figura 67 Interfaz asignar recursos... 178
Figura 68 Interfaz inicio de servicio ... 179
Figura 69 Interfaz mensaje inicio servicio... 179
Figura 70 Interfaz terminación servicio ... 180
Figura 71 Interfaz registro de gastos... 180
Figura 72 Interfaz generar factura... 181
2. LISTA DE TABLAS
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.
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
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
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
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
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.
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.
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.
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.
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.
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.
5. ALCANCES Y LIMITACIONES
Alcances
Se diseñó un prototipo de software web en tres capas con integración de procesos Workflow, que permiteejecutar 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.
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.
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
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
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.
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.
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.
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
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.
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.
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]
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.
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 3Estructura trasversal del negocio. [HITPASS, 2012]
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
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
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”
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.
Figura 4Estructura 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
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.
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)4que 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.
1www.fasecolda.com/fasecolda/BancoMedios/Documentos/seguro de automoviles.pdf 2Esta información fue obtenida mediante consultas telefónicas y visitas a las empresas. 3http://www.softow.com/
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:
5La información relacionada con el tipo de software y la manera como manejan la información se obtuvo via
“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 Salle6elaborada 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.
6Revisado en el Repositorio de Tesis de la Universidad de la Salle.
http://repository.lasalle.edu.co/bitstream/10185/2016/1/T88.07%20V426d.pdf
7Revisado en el Repositorio de Tesis de la Universidad de los Andes.
http://sistemas.uniandes.edu.co/~mar-san1/dokuwiki/doku.php?id=tesis
8Revisado en el Repositorio de Tesis de la Universidad de los Andes.
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.
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.
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.
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
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-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
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-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.
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.
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
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 lafigura se detalla el contenido de cada uno de los módulos.
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.
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
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
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.
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.
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.
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
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.
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
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.
9.1 No se pudieron guardar los datos, muestra mensaje de error.
9.2 Devuelve al usuario a la ventana anterior.
