Tesis: Desarrollo de Aplicación Web tipo help desk integrado en Sistema Web existente

UNIVERSIDAD DE CARABOBO
Facultad Experimental de Ciencias y Tecnología
Licenciatura en Computación
Módulo de Gestión de Órdenes de Servicio y
Actividades para el Sistema Web de la empresa
CrediNat C.A.
Trabajo Especial de Grado presentado ante la ilustre Universidad de
Carabobo como credencial de mérito para optar al título de Licenciado en
Computación
Autor:
Jiménez Blanco Jesús Gabriel
Tutor:
Prof. Marylin Giugni O.
Valencia, mayo de 2018

Dedicatoria
Le dedico este trabajo a mi amada Familia, a mi Mamá, a mi Papá, a mi Hermano,
pues han estado conmigo esperando y anhelando este momento, acompañándome,
dándome ánimos y fuerza para seguir adelante, y me han dado todo su apoyo y amor
incondicional en todas las etapas de mi vida.
A mi Novia, que me ha impulsado a seguir adelante sin importar qué, y me ha traído
tanta alegría.
A mis Amigos, que siempre están para mí cuando los necesito, y cuando no,
también, y han entrado en mi vida como un miembro más de mi Familia.
A todos ustedes les dedico este logro, es por ustedes que sigo trabajando cada día
en ser mejor persona.

Agradecimientos
Quiero agradecer, primeramente, a Dios, que me ha dado la fortaleza para enfrentar
todos mis obstáculos hasta ahora.
A toda mi familia, a mis tíos, mis abuelas, mis primos, mi hermano, a mis familiares
que ya no siguen conmigo en esta vida, pero sobre todo a mis padres, todos han estado
presentes en mi vida y me han convertido en la persona que soy, es gracias a todos que
me he planteado y alcanzado mis metas, les agradezco infinitamente, mis logros son sus
logros.
A mi novia, que me ha dado todo su apoyo y me ha llenado de alegría. A mis amigos,
que han formado parte de mi vida y me han enseñado importantes lecciones de vida. A
mi tutora, que me ha apoyado y guiado, no sólo en lograr esta meta, si no a lo largo de
toda la carrera, y a quien le tengo mucho aprecio y respeto.
A todas las personas que de alguna forma han estado presentes en mi vida y han
puesto su granito de arena para convertirme en la persona que soy, a todos mis
familiares, a todos mis amigos, a todos mis profesores, cada instante que compartí con
todos es de gran valor, por eso a todos les agradezco.

iv
Índice General
Dedicatoria.................................................................................................................. ii
Agradecimientos ........................................................................................................ iii
Índice de Figuras....................................................................................................... vii
Índice de Tablas......................................................................................................... ix
Introducción ................................................................................................................1
Capítulo 1. El Problema..................................................................................................3
1.1. Planteamiento del Problema ................................................................................3
1.2. Objetivos ..............................................................................................................6
1.2.1. Objetivo General............................................................................................6
1.2.2. Objetivos específicos.....................................................................................6
1.3. Justificación..........................................................................................................7
Capítulo 2. Marco Teórico ..............................................................................................9
2.1. Antecedentes .......................................................................................................9
2.2. Bases Teóricas ..................................................................................................12
2.2.1. Escritorio de Ayuda .....................................................................................12
2.2.2. Objetivos del Escritorio de Ayuda................................................................12
2.2.3. Escritorio de Servicio...................................................................................13
2.2.4. Objetivos del Escritorio de Servicio .............................................................13
2.2.5. Factores de éxito de un Escritorio de Ayuda ...............................................14
2.2.6. Estándares relacionados con la evaluación de la Usabilidad ......................14
2.2.7. Estándares de Usabilidad orientados al proceso.........................................15
2.2.8. Lógica de Negocios .....................................................................................17
2.2.9. Sistema de la Empresa CrediNat C.A..........................................................17
2.2.10. Lenguaje de programación Java. ..............................................................17

v
2.2.11. Gestor de proyectos Maven.......................................................................18
2.2.12. Framework Spring .....................................................................................18
2.2.13. Framework Vaadin ....................................................................................18
2.2.14. Desarrollo frontend y backend...................................................................19
Capítulo 3. Marco Metodológico ...................................................................................20
3.1. Tipo de Investigación .........................................................................................20
3.2. Metodología de Investigación.............................................................................20
3.3. Metodología para el desarrollo del software ......................................................21
Capítulo 4. Resultados .................................................................................................24
4.1. Módulo de Gestión de Órdenes de Servicio.......................................................24
4.1.1. Funcionalidad ..............................................................................................25
4.1.2. Estructura ....................................................................................................30
4.1.3. Tecnologías de Desarrollo...........................................................................32
4.2. Artefactos...........................................................................................................33
4.2.1. Matriz de Requerimientos............................................................................33
4.2.2. Matriz de Funcionalidades...........................................................................33
4.2.3. Diagrama Entidad/Relación.........................................................................34
4.2.4. Navegación entre ventanas.........................................................................38
4.2.5. MockUps de las Ventanas...........................................................................40
4.3. Pruebas realizadas ............................................................................................43
4.3.1. Pruebas de requerimientos:.........................................................................43
4.3.2. Pruebas de funcionalidad: ...........................................................................44
4.4. Sprints................................................................................................................51
Capítulo 5. Conclusiones y Recomendaciones ..........................................................54
5.1. Conclusiones ..................................................................................................54

vi
5.2. Recomendaciones ..........................................................................................56
Glosario de Términos ...................................................................................................58
Glosario de Acrónimos .................................................................................................59
Referencias Bibliográficas ............................................................................................60

vii
Índice de Figuras
Figura 1: Actividades de ISO 13407 para el Diseño Centrado en el Usuario. ..............16
Figura 2: Vista de creación de nuevo caso sin rellenar formularios..............................25
Figura 3: Vista de creación de nuevo caso con formularios rellenos............................26
Figura 4: Vista de Detalle de un caso ya creado. .........................................................26
Figura 5: Menú lateral de navegación entre vistas de gestión de un caso creado. ......27
Figura 6: Vista General de gestión de un caso.............................................................28
Figura 7: Vista de Actividades de gestión de un caso. .................................................29
Figura 8: Arquitectura de aplicativos de la Empresa.....................................................31
Figura 9: Parte 1 del Diagrama Entidad/Relación.........................................................35
Figura 10: Parte 2 del diagrama Entidad/Relación. ......................................................37
Figura 11: Leyenda de Navegación entre Ventanas.....................................................38
Figura 12: Diseño Lógico de Navegación entre Ventanas............................................39
Figura 13: MockUp de creación de nuevo Caso...........................................................40
Figura 14: MockUp de Detalle de Caso: Usuario Cliente..............................................41
Figura 15: MockUp de Editar Caso – Sección General: Usuario Administrador...........42
Figura 16: MockUp de Editar Caso - Sección de Actividades: Usuario Administrador. 42
Figura 17: Nuevo Caso de prueba................................................................................44
Figura 18: Caso de prueba Creado. .............................................................................45
Figura 19: Detalle/Edición de Caso de prueba. ............................................................46
Figura 20: Detalle/Edición con cambios de Caso de prueba. .......................................46
Figura 21: Listado con cambios en Caso de prueba.....................................................47
Figura 22: Sección de Actividades Vacía. ....................................................................47
Figura 23: Sección de Actividades - Actividad creada..................................................48
Figura 24: Sección de Actividades - Lleno para prueba. ..............................................49

viii
Figura 25: Guardado exitoso de cambios en Caso de prueba......................................49
Figura 26: Listado de Casos - Caso seleccionado........................................................50
Figura 27: Confirmación para eliminar Caso. ...............................................................50
Figura 28: Eliminación exitosa de Caso de prueba.......................................................51

ix
Índice de Tablas
Tabla 1: Matriz de Requerimientos Funcionales...........................................................33
Tabla 2: Matriz de Funcionalidades..............................................................................34
Tabla 3: Pruebas de Requerimientos. ..........................................................................43

x
UNIVERSIDAD DE CARABOBO
Facultad Experimental de Ciencias y Tecnología
Licenciatura en Computación
Módulo de Gestión de Órdenes de Servicio y Actividades para el Sistema
Web de la empresa CrediNat C.A.
Resumen:
El propósito de los Escritorios de Ayuda es el establecimiento de un grupo de personas que den
soporte y atención a problemas o servicios que el personal contratado pueda necesitar dentro de
una misma empresa. La empresa CrediNat C.A. cuenta con sedes y empleados a lo largo de todo
el país, a los cuales no podría proporcionárseles atención y soporte fácilmente debido a la distancia.
Así pues, un sistema de tipo Escritorio de Ayuda puede mantener atención hacia todos los
empleados de todas las sedes de manera centralizada sin importar en qué parte del país se
encuentre. Por esta razón la empresa necesitaba de un sistema de este tipo en su infraestructura,
sin embargo, la empresa se encontraba en medio del desarrollo de un sistema web, por lo que este
nuevo sistema debió ser un módulo integrado al sistema en desarrollo, y debió cumplir con los
mismos estándares. En base a la situación expuesta, el propósito de esta investigación fue diseñar,
desarrollar y probar dicho módulo, incluyéndose en el flujo de desarrollo y evaluación de la empresa,
haciendo uso de la metodología de investigación “Investigación – Acción” y de la metodología de
desarrollo de software SCRUM complementado con artefactos de diseño propios del flujo de trabajo
de la Empresa. Como resultado, se diseñó, desarrolló y probó una aplicación que permite atender
incidencias inmediatamente a través de la gestión de Órdenes de Servicio y Actividades, integrada
en el sistema web de la Empresa, junto con una serie de artefactos propuestos en la metodología
de investigación.
Palabras clave: Escritorio de Ayuda, Escritorio de Servicio, Aplicación Web.
Autor:
Jiménez Blanco Jesús Gabriel
Tutor:
Giugni Marylin

Introducción
Los sistemas de tipo Escritorio de Ayuda (Help Desk) y Escritorio de Servicio (Service
Desk) son frecuentemente aplicados dentro de las Empresas y Organizaciones para atender
las necesidades de sus empleados y clientes y así aumentar la satisfacción por parte de los
mismos y dar solvencia y soporte a problemas que puedan afectar el flujo regular de las
actividades.
Este tipo de sistemas permite a sus usuarios notificar la necesidad de recibir un servicio
o la presencia de un incidente, y consecutivamente, atender y dar solución a la problemática
planteada o prestar el servicio requerido, comúnmente permiten gestionar las actividades
individuales asociadas al problema, así como a las personas o grupos involucrados.
Por otro lado, en la actualidad las aplicaciones tienden a poseer una arquitectura web;
desde páginas web estáticas o aplicaciones con contenido limitado, hasta aplicaciones
complejas compuestas con Frameworks de desarrollo web (Riehle, 2000), y distintos tipos
de tecnologías en la parte frontend y backend (Kruchten, 1995) de su arquitectura. Esta
arquitectura la componen protocolos de transmisión como HTTP (Hypertext Transfer
Protocol) (Lafon, 2003); y estándares de comunicación de servicios web como JSON
(JavaScript ObjectNotation) (Rhone, 2013), XML (Extensible MarkupLanguage)
(Silberschatz y Korth, 2002), entre otros. La ventaja que aportan los estándares es la
interoperabilidad entre aplicaciones de software independientemente de sus propiedades o
de las plataformas sobre las que se instalen.
Así pues, los beneficios de este tipo de aplicaciones se pueden incluir en cualquier tipo
de estructura organizacional en la que existan individuos involucrados, ya que pueden ser
accedidas a través de la web haciendo uso de cualquier dispositivo con acceso a internet, y
gracias al uso de estándares es posible integrar aplicaciones dentro de sistemas más
grandes, siendo estas aplicaciones módulos de dichos sistemas.
En perspectiva, las aplicaciones de tipo Escritorio de Ayuda y Servicio tienden a
desarrollarse de manera monolítica, siendo estas un único pilar independiente, sin embargo,
la Empresa CrediNat C.A. se encontraba en proceso de desarrollo de un gran sistema del
cual se podían reutilizar elementos para el desarrollo de una aplicación de este tipo. Esto

2
planteó un reto adicional, pues debió desarrollarse un módulo integrado en la lógica de
negocios existente que conviviera con los elementos presentes en dicho sistema.
Por esta razón, otro propósito de esta investigación, adicional a desarrollar una
aplicación de tipo Escritorio de Ayuda y Servicio, fue el de integrar dicha aplicación al
sistema en desarrollo, por lo que debe cumplir con requerimientos como lo es presentar un
diseño orientado a la arquitectura REST, exponiendo su lógica a través de una API.
Finalmente, este documento se divide en 5 capítulos: El capítulo 1, el problema, aborda
la problemática tratada en esta investigación, lo objetivos a resolver y la justificación; el
capítulo 2, el marco teórico, aborda los antecedentes y las bases teóricas asociadas a la
investigación; el capítulo 3, el marco metodológico, aborda el tipo de investigación y la
metodología de desarrollo de software propuesta y utilizada; el capítulo 4, los resultados,
luego del proceso de investigación y consiguiente desarrollo, se produce una aplicación de
tipo Escritorio de Ayuda y Servicio integrada en el sistema en desarrollo por la empresa,
complementada con un conjunto de artefactos; finalmente el capítulo 5, concluye el
contenido del documento con las conclusiones de la investigación y recomendaciones para
futuros trabajos; adicionalmente el documento incluye bibliografía, glosario de términos y
acrónimos como complemento para mejor compresión del documento.

3
Capítulo 1. El Problema
En este capítulo se describirán la problemática que ha motivado a esta investigación,
los objetivos planteados que conllevan la solución de dicha problemática y la justificación e
importancia en los mismos.
1.1. Planteamiento del Problema
Las empresas son entidades que, mediante la organización de sus elementos
humanos, materiales, técnicos y financieros proporcionan bienes o servicios a cambio de un
precio que le permita la reposición de los recursos empleados y la consecución de objetivos
prefijados. Cuervo (2001).
El éxito y subsistencia de las empresas recae en la gestión tanto de sus actividades
como de sus recursos. Alonso (2014). Para el caso de la empresa CrediNat C.A., estas
actividades son llevadas a cabo por sus trabajadores, clientes y diversos dispositivos, todos
estos distribuidos a lo largo del país; además ocurren a través de un sistema web
desarrollado y mantenido por el departamento de informática de la misma empresa.
De ocurrir cualquier situación que afecta a los usuarios o dispositivos (llamadas
incidencias) que llevan a cabo las actividades de la empresa, el flujo de estas actividades
se ve afectado negativamente, lo que impide el cumplimiento de las funciones de la
empresa, poniendo en riesgo el éxito y subsistencia de la misma, razón por la cual es
necesario que se atiendan dichas incidencias lo antes posible.
Ante la presencia de las mencionadas incidencias, tendría que notificarse de alguna
manera a un empleado designado para este fin, este empleado debe crear una Orden de
Servicio a la cual se le designa un grupo de empleados para trabajar en una temprana
solución.

4
En un mismo orden de ideas, las Órdenes de Servicios representan la necesidad de
prestar cualquier servicio por parte de algún ente (ya sea un empleado, un grupo o equipo
o alguna subdivisión de la empresa) por lo que no sólo son usados para atender incidencias,
también incluyen actividades de Recursos Humanos, proyectos de extensión o cualquier
servicio que deba ser prestado tanto dentro de la empresa como a terceros.
Lo mencionado en los párrafos anteriores implica que empleados de diferentes
localidades deben organizarse para atender Órdenes de Servicio, también, provenientes de
diferentes localidades, en el proceso de atención debe ocurrir una constante comunicación
y organización de los empleados designados, y constante retroalimentación con aquellos
siendo atendidos.
Esta situación planteada hace evidente la necesidad de implementar un sistema que
sirva como punto único de comunicación entre los empleados, en la que puedan notificar de
la necesidad de Órdenes de Servicio, así como gestionar equipos de trabajo y actividades
intermedias que conllevan a atender dichas órdenes, al igual que mantener
retroalimentación con los empleados atendidos.
En busca de solución a este tipo de problemas, las empresas y organizaciones
implantan aplicaciones de tipo Escritorio de Ayuda y Servicio en su infraestructura, que
ayudan a sus usuarios a encontrar respuestas a sus preguntas y soluciones a sus
problemas, y sirven como punto único de contacto entre sus usuarios y la organización,
Tueti (2010); así pues, este tipo de aplicaciones sirven de guía en el desarrollo de la
aplicación mencionada en el párrafo anterior, y así dar con una solución efectiva a la
problemática planteada hasta este punto.
Sumado a lo ya mencionado, la empresa ya cuenta con un sistema web, del cual un
conjunto de Módulos se encuentra ya en producción, mientras otro conjunto se encuentra
actualmente en desarrollo, por lo que el sistema a desarrollar debe estar acoplado con la
parte del sistema en desarrollo como un módulo más. Esto implica que el módulo debe
cumplir con los estándares de calidad y hacer uso del conjunto de tecnologías utilizadas
para el desarrollo del sistema, además, debe de acoplarse en la metodología de desarrollo
seguida por la empresa y producirse los artefactos de diseño generados como guía en este
proceso.

5
Para la exitosa integración de un módulo dentro de un sistema, se hace uso de
estándares de desarrollo y comunicación entre aplicaciones, como lo son el estándar REST
y el protocolo HTTP, que permiten la interoperabilidad entre aplicaciones y tecnologías que
respeten las pautas establecidas; y de la misma forma para cumplir con niveles de calidad
y obtener la mayor aceptación por parte de los usuarios finales, se hace uso de estándares
y pautas de usabilidad, como lo son los Estándares de Usabilidad Orientados al Proceso,
que proveen pautas para el proceso de diseño de aplicaciones que permitan dirigir el
resultado hacia lo que el usuario realmente necesita.
De los párrafos anteriores surge la siguiente interrogante: ¿Es posible desarrollar un
módulo para la Gestión de Órdenes de Servicios y Actividades, basado en aplicaciones de
tipo Escritorio de Ayuda y Servicio, que sirva como punto centralizado de atención entre los
usuarios finales y la empresa, integrado en el Sistema Web en desarrollo de la empresa
CrediNat C.A., haciendo uso de estándares de usabilidad, y cumpliendo con sus estándares
de diseño, desarrollo y calidad?

6
1.2. Objetivos
1.2.1. Objetivo General
Desarrollar el Módulo de Gestión de Órdenes de Servicio y Actividades para el Sistema
Web de la empresa CrediNat C.A., que permita la retroalimentación con los usuarios, y
mejorar el servicio que ésta ofrece.
1.2.2. Objetivos específicos
 Realizar una revisión bibliográfica de sistemas empresariales de tipo escritorio
de ayuda y escritorio de servicio, así como también de las funcionalidades y
atributos de calidad de uso que éstos deban exhibir.
 Levantar una Matriz de Requerimientos Funcionales que sirva de guía al diseñar
el sistema.
 Diseñar el Modelo de Datos que refleje la Lógica de Negocios del Sistema.
 Escoger una metodología de desarrollo de software que sirva de guía en el
desarrollo del sistema.
 Aplicar estándares, patrones y lineamientos de usabilidad en el diseño de la
aplicación, para que este diseño de interfaces sea claro y fácilmente aceptado
por los usuarios finales.
 Desarrollar el sistema que cumpla con los requerimientos funcionales,
siguiendo las pautas de la metodología de desarrollo de software escogida.
 Realizar las pruebas de las funcionalidades desarrolladas y evaluación integral
del módulo

7
1.3. Justificación
Los sistemas de tipo Escritorio de Ayuda (Help Desk), como lo será el sistema a
desarrollar, son de vital importancia en las grandes empresas, ya que ofrece a todos los
empleados un punto de contacto único para la gestión y resolución de sus problemas,
extiende el rango de los servicios y ofrece un enfoque más global, se encargan de manejar,
coordinar y resolver Incidentes tan pronto como sea posible, asegurando que ningún
requerimiento es perdido, olvidado o ignorado y también proveen una interfaz para otras
actividades como Solicitudes de Cambio, Gestión de Configuración, Gestión de
Disponibilidad, etc. Guia (2005).
Para dar más valor al párrafo anterior, citamos a Walker (citado por Balmori, 2003),
quien afirma que en corporaciones públicas y privadas se revelan dos caras en el valor de
un Help Desk formal. Para cualquier organización con cientos de usuarios sería insensato
no centralizar esta función de soporte. Esta herramienta organiza y reduce la carga de
trabajo del equipo de soporte, ayuda a proporcionar un servicio responsable y puede servir
para crear un repositorio que contenga herramientas para encontrar una solución.
Para lograr estos beneficios el módulo contará con la capacidad de llevar control de
actividades asociadas a la atención de órdenes de servicio y de grupos de trabajo, ofrecerá
interfaces de control y consulta de actividades, de esta forma pueden colaborar empleados
de diferentes sucursales en el desarrollo de un mismo conjunto de actividades. Esto es de
gran utilidad pues permite sacar mejor provecho de la disponibilidad de los empleados
atendiendo las órdenes al mismo tiempo que mantienen retroalimentación con los
empleados siendo atendidos.
Por otro lado, las órdenes de servicio no se limitan a la aparición de incidencias
técnicas, el sistema igualmente podrá ser utilizado para la gestión de proyectos de
mejoramiento de características de la empresa, así como la necesidad de prestar cualquier
tipo de servicio dentro de la empresa. Adicionalmente, se llevará registro de todas estas
actividades, lo que permitiría hacer posteriores métricas y análisis de diferentes elementos
que permitan revelar la necesidad de mejorar diferentes aspectos de la empresa.

8
Adicionalmente, gracias al uso de estándares de desarrollo y comunicación, el módulo
podrá ser fácilmente extendido en el futuro para mejorar sus características y extender sus
funcionalidades, además de permitir incorporar nuevos módulos que hagan uso de su lógica
para diferentes propósitos y así complementar aún más el sistema en el que estará
integrado.
Así entonces, de manera resumida, los beneficios de este proyecto para la empresa
incluyen:
 Mejora del servicio a los empleados, su percepción y su satisfacción con sus
condiciones de trabajo.
 Aumento de la accesibilidad a través de un solo punto de contacto, de
comunicación, y de información.
 Mejor calidad y tiempo de respuesta a los servicios.
 Mejoras en el trabajo en equipo y comunicación.
 Uso mejorado de los recursos de soporte de TI y aumento en la productividad
del personal de la empresa.
 Mayor facilidad para realizar análisis de desempeño.
 Posibilidad de extensión y reutilización del trabajo desarrollado.
Lo mencionado en esta sección evidencia la importancia del Módulo de Gestión de
Ordenes de Servicio y Actividades para el correcto desempeño de la empresa CrediNat C.A.

9
Capítulo 2. Marco Teórico
En este capítulo se describen investigaciones previas que hayan servido como fuente
importante y de guía en el desarrollo de esta investigación, de igual manera se definen
conceptos de gran importancia para el entendimiento del presente documento.
2.1. Antecedentes
En la Facultad de Ingeniería de Sistemas e Informática de la Universidad Peruana de
Integración Global, Huerta y Lenin (2014) presentaron un trabajo titulado, Implantación de
un Sistema Help Desk para el Proceso de Atención de Incidencias de Hardware y Software
Bajo la Modalidad Open Source en la Empresa Mixercon S.A., el cual consistió en el análisis,
diseño e implantación de un sistema Help Desk para la atención de incidencias del área de
Sistemas. Este sistema se encargó del proceso de atención de incidencias de hardware y
software bajo la modalidad Open Source, utilizó la metodología Rational Unified Process
(RUP) y el lenguaje de Modelamiento unificado (UML). Se buscó mantener un control de
incidencias de los recursos informáticos de la empresa, así como de los servicios que se
prestan a estos. Este trabajo ayuda a reforzar las bases teóricas entorno al desarrollo de
sistemas Help Desk.
En la Coordinación de Ingeniería de Producción y Organización Empresarial de la
Universidad Simón Bolívar, Tueti (2010) presentó un trabajo titulado Análisis y propuesta de
Mejora del Proceso de Gestión de Incidentes del Service Desk de Mercantil Seguros, el cual
consistió en elaborar una propuesta de mejora del proceso de Gestión de Incidentes de
Mercantil Seguros, orientada a minimizar los tiempos de respuesta y aumentar la eficiencia
y rentabilidad del mismo. En este trabajo se identificaron los factores determinantes para el
rendimiento del Proceso de Gestión de Incidentes en Mercantil Seguros, hizo uso de la
metodología DMAMC (Definición, Medición, Análisis, Mejora y Control). A través de este

10
trabajo se pueden comprender factores determinantes en el desempeño de aplicaciones de
tipo Help Desk y de este modo enfocar el diseño y desarrollo de este proyecto hacia la
eficiencia desde el principio.
En la División de Electrónica, Computación, Información y Comunicaciones del
Instituto Tecnológico y de: Estudios Superiores de Monterrey, Balmori (2003) presentó una
Tesis bajo el título de Factores de Éxito e Inhibidores en el Uso de un Help Desk basado en
Internet para ofrecer Soporte Técnico; que tuvo como finalidad presentar una visión de las
ventajas que se puedan obtener de la implantación de un Help Desk basado en Internet y
apoyado en la Administración del Conocimiento y la Memoria Organizacional, para así
determinar cuáles son los factores más importantes para el éxito de un Help Desk de este
tipo, así como elementos inhibidores que pueden generar su fracaso. En el Marco Teórico
de esta tesis se describen, con lujo de detalle, los factores de éxito de un Help Desk al ser
usado por clientes, información que es de gran valor para el correcto diseño y posterior
desarrollo del módulo para este trabajo de investigación.
En el Área de Ingeniería de la Universidad Nacional Abierta, Rodríguez (2011)
presentó un trabajo titulado, Sistema Automatizado de Soporte y Atención al Usuario para
Supermetanol y Super Octanos, el cual consistió en la elaboración del diseño de un sistema
para el soporte y atención al usuario. Este sistema se encargó del registro y seguimiento
adecuado de las solicitudes de apoyo técnico asociadas a las tecnologías de información,
utilizó la metodología RUP (Proceso Unificado de Desarrollo de Software) la cual utiliza el
Lenguaje Unificado de Modelado (UML). En este trabajo se realizó un levantamiento
detallado y minucioso de los requerimientos funcionales, involucrando para ello a los
diferentes usuarios que interactúan con el sistema, lo que proporciona valiosa información
de base para el diseño del proyecto, particularmente en el levantamiento de requerimientos
y funcionalidades.
En el Departamento de Sistemas Informáticos y Computación de la Universidad
Politécnica de Valencia, Martínez (2009) presentó una Tesina de Máster en Ingeniería del
Software, la cual tiene como título, WUEP: Un Proceso de Evaluación de Usabilidad Web
Integrado en el Desarrollo de Software Dirigido por Modelos, con la cual se pretendió
proponer WUEP (Web Usability Evaluation Process), apoyada en un amplio estudio del

11
estado del arte, realizado mediante la conducción de una revisión sistemática, acerca de los
métodos de evaluación de usabilidad existentes para el ámbito Web, el estudio de los
estándares directamente relacionados con la evaluación de la calidad de productos software
y un análisis de las diferentes propuestas existentes. Si bien los resultados obtenidos en
esta tesina definen un Modelo de Usabilidad Web y la definición del proceso de evaluación
de usabilidad, el contexto dentro del cual son aplicables sale del alcance de este trabajo de
investigación, sin embargo, dentro del amplio estudio expuesto en el documento, se incluyen
procesos de evaluación de Usabilidad Web integrados en el desarrollo que se adaptan al
alcance de este trabajo de investigación, y que proporcionan una guía para el cumplimiento
de los objetivos planteados.
En la Escuela de Computación de la Universidad Central de Venezuela, Hernández
(2015) presentó un trabajo titulado Desarrollo del Módulo de Gestión de Trámites de
Profesores del Sistema de Gestión de la Programación Docente para el Departamento de
la Escuela de Computación de la Universidad Central de Venezuela, el cual consistió en la
automatización de los procesos de gestión de la Programación Docente. Este trabajo
desarrolla un impecable marco metodológico enfocado a la metodología Scrum, el cual
puede ser usado como una valiosa base para la correcta aplicación de esta metodología.
En la Escuela de Computación de la Universidad de Carabobo, Gamez (2014)
presentó un trabajo titulado Barradas en Framework de Gestión de Infraestructura de TI
Basado en Buenas Prácticas, Enmarcado en el Proceso de Gestión Financiera, el cual
consistió en la creación de un Framework de Gestión de Infraestructura de TI basado en
ITIL y COBIT. El valor de este trabajo recae en su marco metodológico, específicamente en
la metodología Investigación – Acción, la cual está muy completa y representa una sólida
base en el desarrollo de la metodología de investigación del proyecto.

12
2.2. Bases Teóricas
2.2.1. Escritorio de Ayuda
De acuerda a la completa investigación de Tueti (2010) un Escritorio de Ayuda es un
área en cualquier organización que ayuda a sus usuarios a encontrar respuestas a sus
preguntas o soluciones a sus problemas, reacciona ante los incidentes y es usado para
manejar problemas cuando los mismos surgen, permitiendo llevar un registro, control y con
suerte, finalmente llegar a una resolución.
2.2.2. Objetivos del Escritorio de Ayuda
Los objetivos del Escritorio de Ayuda son los siguientes:
 Recibir los reportes realizados por los usuarios que solicitan un servicio cuando:
Se interrumpe la operación normal de su trabajo, requieran soporte sobre el
hardware o software instalado, requieran nuevos productos de hardware o
software y necesiten asesoramiento sobre el funcionamiento o utilización de los
recursos informáticos disponibles.
 Escalar incidentes a los grupos especializados.
 Corroborar que las soluciones brindadas a los usuarios sean las más
adecuadas.
 Realizar estadísticas de los servicios proporcionados por el Escritorio de Ayuda
y así realizar análisis de la actividad del área de informática que ayudará al
mejoramiento del servicio.
 Planes de contingencia en caso de que un servicio así lo requiera.
 Control de los inventarios de software y hardware de la organización.
 Control de la base de datos de los usuarios.
 Administración de las licencias de software.
 Desarrollo de manuales de normas y procedimientos.

13
2.2.3. Escritorio de Servicio
Según Palomino (citado por Ortiz, 2015), las buenas prácticas ITIL V3 lo define como
el único punto de contacto para los clientes/usuarios que necesitan ayuda proporcionando
un servicio de soporte de alta calidad tanto para la infraestructura de cómputo como para
los usuarios. Un Escritorio de Servicio puede hacer todo lo que un Escritorio de Ayuda, pero
además permite planear, estructurar y proveer la entrega de una gran variedad de servicios
IT.
2.2.4. Objetivos del Escritorio de Servicio
Los principales objetivos del Escritorio de Servicio son:
 Ser el único punto de contacto entre los usuarios y el departamento de TI.
 Facilitar la restauración normal del servicio dentro de los niveles y prioridades
establecidas, minimizando el impacto al negocio.
 Identificar mejoras en los servicios prestados por el departamento de TI.
 Optimizar procesos y procedimientos que permitan reducir los tiempos de
solución y el correcto escalado de los mismos.
 Detectar problemas y buscar la solución de éstos.
 Tener un control de los elementos de que sean parte de la infraestructura para
detectar cualquier cambio que se haya generado.
 Proporcionar a la administración, información y recomendaciones para la
mejora del servicio.
La diferencia entre Escritorio de Ayuda y Escritorio de Servicio es que la operación del
primero se limita a asegurarse de que se dispongan de los recursos humanos y tecnológicos
que permitan satisfacer la demanda de los requerimientos reportados por los usuarios,
mientras que las actividades del Escritorio de Servicio más allá de satisfacer única y

14
exclusivamente la demanda deben alinear los objetivos de los departamentos TI con los
objetivos de la organización.
2.2.5. Factores de éxito de un Escritorio de Ayuda
Además de los objetivos que buscan cumplir los Escritorios de Ayuda y Servicio, es
pertinente mencionar algunos factores de éxito de sistemas de este tipo. Así pues, acudimos
a Adams (citado por Balmori, 2003), quien indica que para que un sistema de este tipo sea
exitoso debe contar con las siguientes características:
 Debe permitir a los usuarios solucionar sus problemas.
 Debe ser fácil de crear y mantener.
 Debe ofrecer un acceso rápido.
 Debe estar abierto a validación, reporteo y distribución.
Los conceptos de Escritorio de Ayuda y Escritorio de Servicio expuestos anteriormente
son de gran importancia para este trabajo de investigación, ya que ambos cumplen objetivos
similares a los requeridos por el Módulo de Gestión de Órdenes de Servicio desarrollado,
por esta razón los objetivos expuestos en los párrafos anteriores, al igual que los factores
de éxito, sirvieron de guía en el diseño de los requerimientos funcionales de dicho módulo.
Sin embargo, algunos de estos objetivos van más allá del alcance de la investigación, por
esta razón sólo parte de estos conceptos fueron tomados para el desarrollo del módulo en
cuestión, así pues, los factores de éxito mencionados en el párrafo anterior en conjunto con
algunos de los objetivos expuestos anteriormente serán tomados como pautas a ser
cumplidas.
2.2.6. Estándares relacionados con la evaluación de la Usabilidad
La organización internacional para la estandarización (ISO) ha desarrollado una gran
variedad de modelos para especificar y medir la usabilidad del software, entre muchas otras
características de calidad. El empleo de estándares ofrece algunas ventajas, entre ellas se
destacaría que los métodos de evaluación de usabilidad basados en ellos presentan
homogeneidad en cuanto a definiciones de conceptos, ya que estos conceptos han sido

15
consensuados entre diferentes grupos que participan en la elaboración del estándar.
Además, proveen una base de gran utilidad para realizar inspecciones. Estos estándares
se categorizan en dos grupos: orientados al proceso (ISO 9241 e ISO 13407) y orientados
al producto (ISO 9126 e ISO 14598). (Martínez, 2009).
Los estándares orientados al producto se caracterizan por la evaluación de la calidad
de un producto de software existente, por lo general, ya implantado; debido a que la
implantación del módulo desarrollado no está comprendida en el alcance de este trabajo de
investigación, nos centraremos en los estándares orientados al proceso.
2.2.7. Estándares de Usabilidad orientados al proceso
El estándar ISO 9241 es un conjunto de normas internacionales acerca de los
requisitos ergonómicos y recomendaciones, para oficinas con terminales visuales, relativas
al hardware, al software, y los atributos del entorno, los cuales contribuyen a un nivel de
usabilidad adecuado con respecto a unos principios ergonómicos subyacentes. (Martínez,
2009).
Según este estándar, la medición de la usabilidad del sistema consta de tres atributos
de la usabilidad evaluados de acuerdo con el contexto de la utilización del software:
 Efectividad: ¿Los usuarios alcanzan sus objetivos correctamente al usar el
sistema?
 Eficiencia: ¿Qué recursos se han requerido a fin de alcanzar los objetivos del
usuario?
 Satisfacción: ¿Qué impresiones tienen los usuarios sobre el uso del sistema?
Las características del contexto de uso (usuarios, tareas y entorno) pueden ser
suficientes para determinar la usabilidad como una característica del producto: un cambio
en cualquier aspecto relevante del contexto de uso puede afectar a la usabilidad del
producto. Por ejemplo, un producto que podría resultar usable por usuarios expertos, podría
no serlo por usuarios principiantes. Es más, aspectos del entorno de trabajo, tales como el
ruido o la distribución espacial del lugar de trabajo, también podrían afectar a la usabilidad.

16
La ISO 9241‐11 recomienda un enfoque basado en procesos para evaluar la
usabilidad, mediante el cual, un sistema se obtiene a través de un Diseño Centrado en el
Usuario. Por esto motivo, esta norma debe aplicarse conjuntamente con el estándar ISO
13407. (Chou, 2002)
La ISO 13407 proporciona guías sobre las actividades involucradas en el ciclo de vida
perteneciente al Diseño Centrado en el Usuario. En ella se describe el Diseño Centrado en
el Usuario como una actividad multidisciplinar, que incorpora factores humanos y
conocimientos ergonómicos con el objetivo de mejorar la efectividad y eficiencia, las
condiciones de trabajo, y contrarrestar los posibles efectos adversos del uso que guardan
relación con la salud, la seguridad y el rendimiento. (Conte, Massolar, Mendes y Travassos,
2007). La Figura 1 muestra las actividades que se llevan a cabo en un Diseño Centrado en
el Usuario.
Figura 1: Actividades de ISO 13407 para el Diseño Centrado en el Usuario.
Para asegurar que el módulo desarrollado en esta investigación cumpla con
efectividad, eficiencia y satisfacción por parte de los usuarios, dicho de otra forma, cumpla

17
con los estándares de usabilidad (como lo fue planteado en los objetivos), se aplican las
actividades propuestas por la ISO 13407 para el diseño centrado en el usuario en el diseño
del módulo de Gestión de Órdenes de Servicio, lo cual será expuesto en los resultados.
2.2.8. Lógica de Negocios
La Lógica de Negocios engloba la lógica aplicativa que permite el correcto
funcionamiento del sistema. Es, en términos sencillos, la parte del programa que codifica
las reglas de negocio del mundo real, indica cómo deben interactuar los objetos de negocio
entre sí y cómo se puede acceder a ellos. (Rivera, 2008).
2.2.9. Sistema de la Empresa CrediNat C.A.
Como ya ha sido mencionado, el módulo de Gestión de Órdenes de Servicio deberá
estar integrado a un Sistema en desarrollo por lo que deberá cumplir con el uso de
tecnologías y distribución establecidos para dicho sistema, lo cual se procede a explicar:
 El Sistema está siendo desarrollado en el lenguaje de programación Java,
siguiendo el estándar de desarrollo REST donde el frontend y el backend son
aplicaciones separadas comunicadas entre sí a través del protocolo HTTP.
 La aplicación frontend es desarrollada con ayuda del Framework de Java,
Vaadin, mientras que la aplicación backend es desarrollada con ayuda del
Framework también de Java, Spring.
 El Sistema se comunica con una aplicación de Seguridad, la cual gestiona los
usuarios y sus permisos. A través de esta comunicación, el Sistema puede
gestionar el acceso, los menús y la autenticación.
2.2.10. Lenguaje de programación Java.
Java es un lenguaje de programación y una plataforma comercializada creada por Sun
Microsystems en 1995. Es la base para la gran mayoría de aplicaciones de red, además del
estándar global para desarrollar y distribuir aplicaciones móviles y embebidas, juegos,
contenido basado en web y software de la empresa. Java permite desarrollar, implementar

18
y utilizar de forma eficaz interesantes aplicaciones y servicios. Actualmente sufre constantes
evoluciones y mejoras donde incluyen librerías que facilitan el desarrollo de las aplicaciones.
2.2.11. Gestor de proyectos Maven
Maven es una herramienta utilizada para gestionar y empaquetar proyectos basados
en Java, su principal objetivo es el de permitir al desarrollador comprender el estado
completo del esfuerzo invertido en el desarrollo, esto lo logra facilitando el proceso de
empaquetado, proveyendo un sistema de empaquetado uniforme, proveyendo información
de calidad acerca del proyecto, proveyendo lineamientos para las mejores prácticas en el
desarrollo y permitiendo un migración transparente entre nuevas características.
2.2.12. Framework Spring
Spring Framework proporciona un modelo completo de programación y configuración
para aplicaciones empresariales modernas basadas en Java, en cualquier tipo de
plataforma de implementación. Un elemento clave de Spring es el soporte de infraestructura
a nivel de aplicación: Spring se centra en la "plomería" de las aplicaciones empresariales
para que los equipos puedan concentrarse en la lógica empresarial de nivel de aplicación,
sin vínculos innecesarios con entornos de despliegue específicos.
2.2.13. Framework Vaadin
Vaadin es una plataforma de desarrollo que ofrece todas las herramientas necesarias
para construir fácilmente una aplicación web. Es un Framework GWT (Google Web Toolkit)
de Java de código abierto, que se utiliza para crear y mantener aplicaciones web en una
sola página, a su vez brindando un set de métodos que permiten la integración sencilla con
otros trabajos de arquitectura Web. Su objetivo es aumentar las aplicaciones basadas en
navegador, permitiendo que el desarrollo y las pruebas sean más fáciles.
Una de las características más relevantes de vaadin es que el framework es hibrido,
ya que su desarrollo es de lado del servidor pero cuando se instancia en el momento de
ejecución permite la creación elementos que se conocen describe como “widgets”, los
cuales son objetos generados dinámicamente en JavaScript, partiendo de los componentes
previamente definidos en Java de lado del servidor, de esta manera vaadin comunica los

19
objetos de lado del cliente con su contraparte en el lado del servidor y hace que el desarrollo
de una aplicación web Full Stack sea generada con menor esfuerzo.
2.2.14. Desarrollo frontend y backend
El desarrollo frontend en general se asocia con los principios de diseño y de estructura
de páginas teniendo en cuenta la usabilidad y la legibilidad de la página o de la aplicación
web, su trabajo se ejecutará en el lado Cliente, en la mayoría de los casos, en el navegador.
La interfaz del módulo de Gestión de Órdenes de Servicio está integrada a la aplicación
frontend del Sistema, y se comunica con la aplicación backend.
El desarrollo backend trabaja del lado Servidor, se encarga de interactuar con bases
de datos, verificar manejo de sesiones de usuarios, montar la página en un servidor, y desde
éste “servir” al frontend. De este lado, integrado en la aplicación backend del Sistema, se
sirve la comunicación con el frontend, se procesa toda la lógica del Módulo, de comunica
con la aplicación de seguridad y se gestionan las bases de datos.

20
Capítulo 3. Marco Metodológico
En este capítulo se describe brevemente el tipo de investigación y se explica la
Metodología de Investigación utilizada para la realización de este documento,
adicionalmente, al tener como objetivo general el desarrollo de una aplicación, se explica la
Metodología de Desarrollo de Software utilizada para desarrollar el módulo de Gestión de
Órdenes de Servicio.
3.1. Tipo de Investigación
De acuerdo con Fidias (2006), un proyecto factible es una propuesta de acción para
resolver un problema práctico o satisfacer una necesidad. Es indispensable que dicha
propuesta se acompañe de una investigación que demuestre su factibilidad o posibilidad de
realización.
De esta forma, el presente proyecto que tiene como objetivo desarrollar el Módulo de
Gestión de Órdenes de Servicio y Actividades para el Sistema Web de la empresa CrediNat
C.A., se ve orientado en el modelo de un proyecto factible, ya que brindara solución a la
problemática antes estudiada.
3.2. Metodología de Investigación
La investigación es un proceso que, mediante la aplicación del método científico,
procura obtener información relevante y fidedigna, para entender, verificar, corregir o aplicar
el conocimiento. Tamayo (2008).
Así pues, la investigación acción es el proceso en donde se desea mejorar la práctica
o la comprensión personal. En primera instancia se debe llevar a cabo un estudio, para así
de esta manera definir con claridad el problema; y, en segundo lugar, para especificar un
plan de acción en respuesta a la problemática descrita. Elliott, (2000).

21
Luego se emprende una evaluación para comprobar y establecer la efectividad de la
acción tomada. Por último, los participantes reflexionan, explican los progresos y comunican
estos resultados a la comunidad de investigadores de la acción. La investigación acción es
un estudio científico auto reflexivo de los profesionales para mejorar la práctica. McKernan,
(1999).
Con lo anteriormente dicho, la aplicación de investigación acción se logra siguiendo el
ciclo de vida presentado en los siguientes párrafos:
Planificar: El foco inicial es la identificación de la idea general, con la finalidad de
cambiar algún aspecto problemático del entorno de investigación. Con ello, se identifica y
diagnostica el problema; para así posteriormente plantear las hipótesis o estrategias de
acción
Actuar: Está representada por ese conjunto de estrategias aplicadas para dar
respuesta a la problemática planteada. El desarrollo debe estar planteado en un tiempo
específico. Y la generación de datos debe seguir un proceso sistemático, ya que ésta forjará
la base para la fase de reflexión o evaluación de los resultados. Para este proyecto, esta
fase será ejecutada siguiendo la metodología Scrum, de la cual se hablará con más detalle
en la sección de Metodología de Desarrollo.
Observar: La observación se ejecuta sobre la acción con el fin de identificar si la
mejora ha tenido lugar o no. Ésta implica la recolección y análisis de datos.
Evaluar: Es la fase que cierra el ciclo. Se centra en cómo interpretar los datos
obtenidos, extrayendo significados relevantes para evaluar las consecuencias del plan de
acción y a través de este proceso de reflexión, se decidirá si se inicia de nuevo el ciclo con
un replanteamiento del problema.
3.3. Metodología para el desarrollo del software
Las metodologías de desarrollo de software imponen un proceso disciplinado sobre el
desarrollo de software con el fin de hacerlo más predecible y eficiente. Lo hacen
desarrollando un proceso detallado con un fuerte énfasis en planificar, inspirado por otras
disciplinas de la ingeniería. Delgado (2008).

22
Como metodología de desarrollo de software, Scrum es un modelo de referencia que
define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para
definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales
en Scrum son el Scrum Master, que mantiene los procesos y trabaja de forma similar al
director de proyecto, el Dueño del Producto (Product Owner), que representa a los clientes
externos o internos, y el Equipo que incluye a los desarrolladores. Durante cada iteración
(sprint), un periodo entre 15 y 30 días (la magnitud es definida por el equipo), el equipo crea
un incremento de software potencialmente entregable. Hernández (2015).
La flexibilidad y adaptabilidad de SCRUM la hacen ideal para llevar a cabo este
módulo, ya que no está atada a una estricta planificación, permitiendo planificar cada sprint
en base a los avances presentados en el sistema al que debe ir. Adicionalmente la empresa
exige el desarrollo de ciertos artefactos de diseño como parte de su flujo de trabajo, los
cuales serán explicados más adelante en esta misma sección.
Así se propone la siguiente dinámica de trabajo basada en SCRUM complementado
con la implementación de los artefactos de diseño exigidos por la empresa en su flujo de
desarrollo:
Previo al desarrollo del módulo, se generarán los artefactos de diseño exigidos por la
empresa, los cuales constan de lo siguiente:
Matriz de requerimientos: En base a las necesidades de la empresa, y a los
resultados de la investigación de sistemas similares, se procederá a elaborar una minuciosa
lista de requerimientos, de modo que el cumplimiento de estos conlleve a la satisfacción de
las necesidades de la empresa.
Matriz de funcionalidades: A partir de la Matriz de Requerimientos, se elaborará una
lista de todas las posibles acciones a ser efectuadas por un usuario para cada requerimiento
funcional, de esta forma se contará con una descripción más minuciosa de las
funcionalidades que conforman a cada requerimiento.
Diagrama Entidad Relación: Es un esquema de la empresa que representa la
estructura lógica completa de una base de datos. McKernan, (1999). Con la elaboración de

23
este modelo será posible implementar la base de datos que alimentará al módulo a
desarrollar.
Diseño lógico de la navegación entre ventanas: Este consistirá de un diagrama que
relaciona cada conjunto de funcionalidades a ventanas y define la transición entre ellas.
MockUps de las ventanas del módulo: Maquetas de cada funcionalidad de cada
ventana representada en el diagrama mencionado en el ítem anterior, con esto podrá
orientarse el desarrollo de las interfaces sin dejar por fuera ninguna funcionalidad.
Con base en los elementos de diseño presentados en los párrafos previos, se propone
desarrollar el módulo siguiendo la metodología de desarrollo Scrum como se describe a
continuación:
Sprints: Un Sprint es el periodo de tiempo durante el que se desarrolla un incremento
de funcionalidad. Hernández (2015). Estos Sprints, idealmente, tendrán una duración de
una semana, dentro de la cual se desarrollarán los elementos del módulo planificados para
este Sprint, sin embargo, de alcanzarse los objetivos planificados antes de la culminación
del lapso de tiempo se adelantará la planificación e inicio del siguiente Sprint, de la misma
manera, de determinarse la necesidad de extender la duración, el inicio del siguiente Sprint
podrá posponerse.
Dueño del producto: Se contará con un miembro del departamento de Calidad y
Procesos quien será encargado de velar por el cumplimiento de los requerimientos
establecidos.
SCRUM Master: Se contará además con un líder de proyecto encargado de supervisar
el avance de cada Sprint, aportando guía en la correcta implementación de los estándares
establecidos por la empresa.
Inicio y Final de Sprint: Antes de trabajar, se hacen una serie de reuniones con el fin
de planificar el siguiente Sprint en base a los avances del Sprint culminado.

24
Capítulo 4. Resultados
En este capítulo se describe el Módulo de Gestión de Órdenes de Servicio desarrollado
para este trabajo de investigación, su funcionalidad y estructura. Adicionalmente se
describen los artefactos generados en el desarrollo del mencionado módulo.
4.1. Módulo de Gestión de Órdenes de Servicio
El módulo permite gestionar Órdenes de Servicio, llamados Casos en la versión final,
y Actividades asociadas a los casos. Para los usuarios recibiendo el servicio, permite crear
casos dirigidos a distintas organizaciones o individuos y llevar seguimiento del estatus de
dicho caso hasta su conclusión; para los usuarios prestando servicio, permite crear
actividades asociadas al caso con las que puede organizar el progreso a la solución del
caso, además de asociar valor de esfuerzo a las actividades como respaldo del trabajo
invertido en su realización y asociar documentos como anexo al caso. Esto fue diseñado en
base a requerimientos levantados a partir de reuniones con el cliente final, los cuales serán
expuestos más adelante en las secciones 4.2.1 y 4.2.2, y apoyándose en las definiciones
expuestas previamente en las secciones 2.2.1, 2.2.2, 2.2.3 y 2.2.4.
Este módulo es parte de un sistema web, por lo que fue desarrollado utilizando el
lenguaje de programación Java el cual es un lenguaje de programación de uso general de
lado del servidor para el desarrollo web de contenido dinámico, en conjunto con el
Framework de desarrollo Web Spring, el cual es un completo Framework compuesto por
múltiples módulos, diseñado para optimizar la implementación de las aplicaciones Web
empresariales; por otro lado, para desarrollar las vistas de la aplicación se utilizó Vaadin, el
cual es un Framework GWT (Google Web Toolkit) de Java de código abierto, que se utiliza
para crear y mantener aplicaciones web en una sola página, a su vez brindando un set de
métodos que permiten la integración sencilla con otros proyectos de arquitectura Web.

25
4.1.1. Funcionalidad
Para enviar una Orden de Servicio, atenderla y retroalimentar al usuario, deben
hacerse las siguientes acciones:
1. Crear un nuevo Caso dirigido a una Organización.
2. Crear Actividades asociadas.
3. Modificar el Estatus del Caso.
Primeramente, se debe haber ingresado a la aplicación a través del módulo de
seguridad, y luego a la sección de Gestión de Casos para crear el caso:
1. Creación de casos
Una vez en la pantalla de creación de un nuevo caso (Figura 2), se procede a rellenar
los campos (Figura 3): Se le debe colocar un título y una descripción; el campo tipo permite
clasificar el caso, las opciones vienen dadas por parámetros de configuración de la
aplicación; el campo “Dirigido a” permite señalar a que organización (subdivisión de la
empresa) o individuo está dirigido el caso; y la sección de etiquetas permite complementar
la descripción del caso.
Figura 2: Vista de creación de nuevo caso sin rellenar formularios.

26
Figura 3: Vista de creación de nuevo caso con formularios rellenos.
Una vez creado el caso, sus valores ya no pueden ser modificados y en su lugar podrán
ser consultados a través de una vista de detalle (Figura 4), seguidamente un usuario
administrador del área de atención de casos de la organización a la cual va dirigido el caso
se encargará de gestionar el estatus y las actividades asociadas al caso. En la sección de
estatus se podrá verificar el estatus del caso.
Figura 4: Vista de Detalle de un caso ya creado.

27
2. Gestión de casos
Es posible para un usuario administrador designado gestionar los casos dirigidos a
determinada organización, esta gestión se divide en dos vistas: La vista general (Figura 6)
y la vista de actividades (Figura 7). La navegación entre estas dos vistas ocurre a través del
menú lateral ubicado a la izquierda (Figura 5).
Figura 5: Menú lateral de navegación entre vistas de gestión de un caso creado.
Dentro de la vista general hay tres secciones: Una primera sección de detalle en la
que se pueden observar el título, la descripción, el tipo, la organización o individuo a quien
va dirigido el caso, y una subsección con las etiquetas asociadas; una segunda sección en
la que se puede cambiar la prioridad asignada al caso y el estatus del caso que podrá ser
consultado por el cliente; y una tercera y última sección de documentos en la que se podrán
adjuntar documentos asociados al caso.

28
Figura 6: Vista General de gestión de un caso.
Dentro de la vista de actividades se enlistan todas las actividades asociadas al caso,
permite crear nuevas actividades, editarlas y eliminarlas. Cada actividad tiene, al igual que
cada caso, título, descripción, estatus y prioridad; adicionalmente, tiene el tiempo estimado
de realización de la actividad y el tiempo total invertido para realizarla ambos expresados
en horas hombre, estos dos últimos campos son calculados automáticamente en base al
esfuerzo asociado a la actividad.
Adicional a los campos mencionados en el anterior párrafo, cada actividad cuenta con
una subsección de esfuerzo que permite gestionar las tareas realizadas para cumplir con la
actividad. Cada tarea debe ser catalogada con un tipo, el cual determina la cantidad de
horas hombre estimadas tiene la tarea, y se le asigna una cantidad de horas hombre
invertidas. Finalmente, la suma de todas las horas hombre estimadas y la suma de todas
las horas hombre invertidas determinan la cantidad total de horas hombre estimadas y horas
hombre invertidas del caso respectivamente.

29
Figura 7: Vista de Actividades de gestión de un caso.
Adicionalmente, dada la separación del frontend con el backend, el módulo dispone de
una API con servicios REST, de modo que otras aplicaciones pueden consumirlos, con la
finalidad de brindarles acceso a la lógica de negocios a otros módulo y aplicaciones que
requieran de servicios de gestión de Órdenes de Servicio y sus Actividades.
De las dos secciones anteriores se puede señalar el cumplimiento de las siguientes
pautas de calidad, expuestas en la sección 2.2.5:
 Permite a los usuarios solucionar sus problemas, esto gracias a que los casos
son atendidos por los usuarios encargados.

30
 Es fácil de mantener, esto gracias al cumplimiento de estándares, como lo es el
estándar REST mencionado en párrafos anteriores.
 Ofrece un acceso rápido, esto gracias a que el módulo está integrado en un
sistema de uso frecuente por parte de los usuarios.
 Está abierto a validación y reporteo, esto gracias a que guarda registro de cada
caso.
Adicionalmente, es conveniente señalar ciertos atributos para una medición preliminar
de usabilidad, mencionados en la sección 2.2.7 del Marco Teórico:
 La respuesta a la pregunta “¿Los usuarios alcanzan sus objetivos
correctamente al usar el sistema?” es afirmativa, ya que el objetivo del módulo
es servir como punto centralizado de seguimiento de incidentes, lo que se
cumple con lo expuesto en la sección anterior, esto cumple con el atributo de
Efectividad en la medición de usabilidad.
 La pregunta “¿Qué recursos se han requerido a fin de alcanzar los objetivos del
usuario?”, tiene una respuesta positiva, ya que el módulo saca provecho de
elemento presentes en el sistema, como será explicado en la sección 4.2.3,
gracias a esto se cumple con el atributo de Eficiencia en la medición de
usabilidad.
Todo lo expuesto anteriormente engloba la funcionalidad del módulo de Gestión de
Órdenes de Servicio desarrollado para la empresa CrediNat C.A., a continuación, se dispone
la distribución estructural del módulo.
4.1.2. Estructura
La estructura del módulo de Gestión de Órdenes de Servicio se rige por la Arquitectura
de Aplicativos (Figura 8) definida por la empresa. Como se puede apreciar en la Figura 8,
el frontend y el backend son aplicaciones separadas que se comunican entre sí a través del
protocolo HTTP, gracias a que la lógica del negocios del módulo está expuesto en el
backend con el estándar REST. Adicionalmente existen dos puntos de foco en la figura,

31
Commons y Model, los cuales representan APIs utilizadas independientemente tanto por
frontend com por backend, y desarrolladas, igualmente, como parte del módulo.
La API Commons contiene el conjunto de rutas predefinidas para el acceso a la lógica
de negocios expuesta por el backend, su intención es la de ser utilizada por todas las
aplicaciones que deseen consumir a el backend y, de esta manera, evitar ambigüedades.
La API Model contiene la definición programática del modelo de la base de datos, con
la cual los aplicativos que consuman a el backend, incluido el frontend, sean capaces de
procesar la data proveniente de la base de datos.
Figura 8: Arquitectura de aplicativos de la Empresa.

32
4.1.3. Tecnologías de Desarrollo
Como consecuencia de la integración con el Sistema de la empresa, al igual que
ocurrió con la estructura del módulo, fue necesario desarrollar utilizando las tecnologías
determinadas para el desarrollo del Sistema. Partiendo de la Figura 8 explicada en los
párrafos previos, las tecnologías utilizadas para desarrollar el Módulo constan de:
Lenguaje de programación: Como base de todo el desarrollo llevado a cabo, se
utilizó el lenguaje de programación Java en su versión 1.8.
Gestor de proyectos: Para gestionar la configuración, compilación, empaquetamiento
y convivencia de las diferentes librerías de terceros utilizadas, en conjunto con el código
fuente desarrollado, se hizo uso del gestor de proyectos basados en Java, Maven.
Backend: Como fue ya mencionado en la sección anterior, y expuesto en la Figura 8,
el Sistema de la Empresa consta de dos (2) aplicaciones independientes, siendo una de
ellas el backend, el cual se comunica directamente con la Base de Datos y expone la lógica
de negocios a través del estándar REST, esto lo logra a través del framework de Java,
Spring.
Frontend: Continuando la idea del párrafo anterior, el frontend vendría siendo la otra
aplicación que compone al sistema. Se encarga de consumir la lógica de negocios expuesta
por el backend y presentársela al usuario final a través de una interfaz. Esto se logra con el
uso del framework de Java, Vaadin.

33
4.2. Artefactos
Siguiendo la metodología de software propuesta en la sección 3.3 de este documento,
se han elaborado diversos artefactos como complemento al desarrollo del módulo. Estos
constan de: Matriz de requerimientos, matriz de funcionalidades, diagrama Entidad
Relación, diseño lógico de navegación entre ventanas, y maquetas (MockUps) de las
ventanas.
4.2.1. Matriz de Requerimientos
Primeramente, se ha elaborado la matriz de requerimientos funcionales, en esta se
enlistan y definen las funciones generales que deben de poder ser realizadas por un usuario
al utilizar el módulo. Este artefacto es el primer paso en el diseño del módulo, y fue
elaborado, evaluado y discutido con el cliente para su aprobación antes de realizar ninguna
otra actividad de diseño o desarrollo.
ID Requerimiento Resumen
1 Gestión de Órdenes de Servicio Manejo de Órdenes de Servicio
2 Gestión de Actividades
Manejo de actividades asociadas a
Órdenes de Servicio
3 Gestión de Individuos y Organizaciones
Asignación de Individuos u
Organizaciones encargadas de Órdenes
de Servicio
4 Gestión de Registros
Revisión de registro de Órdenes de Servicio
y Actividades
5 Gestión de Documentos
Manejo de documentos adjuntos a Órdenes de
Servicio
6 Gestión de Esfuerzo Manejo de esfuerzo asociado a Actividades
Tabla 1: Matriz de Requerimientos Funcionales.
4.2.2. Matriz de Funcionalidades
Complementariamente, junto a la matriz de requerimientos funcionales, se ha
elaborado la matriz de funcionalidades, en este artefacto se enlistan, para cada
requerimiento funcional enlistado en la matriz de requerimientos funcionales, cada una de
las acciones específicas que deben de poder ser efectuadas sobre el requerimiento
funcional en cuestión. Este artefacto, igualmente, fue elaborado, evaluado y discutido con
el cliente para su aprobación en conjunto con la matriz de requerimientos funcionales.

34
Requerimiento Asociado Patrón funcional
REQ-1 : Gestión de Ordenes de Servicio Crear
REQ-1 : Gestión de Ordenes de Servicio Editar
REQ-1 : Gestión de Ordenes de Servicio Eliminar
REQ-1 : Gestión de Ordenes de Servicio Detalle
REQ-1 : Gestión de Ordenes de Servicio Adjuntar
REQ-2 : Gestión de Actividades Crear
REQ-2 : Gestión de Actividades Editar
REQ-2 : Gestión de Actividades Eliminar
REQ-2 : Gestión de Actividades Detalle
REQ-3: Gestión de Individuos y Organizaciones Asignar
REQ-5: Gestión de Documentos Subir
REQ-5: Gestión de Documentos Descargar
REQ-6: Gestión de Esfuerzo Crear
REQ-6: Gestión de Esfuerzo Editar
REQ-6: Gestión de Esfuerzo Eliminar
Tabla 2: Matriz de Funcionalidades.
4.2.3. Diagrama Entidad/Relación
Con base en la lógica de negocios de la aplicación, se desarrolló el diagrama de
Entidad Relación, el cual permite representar las entidades relevantes de un sistema de
información, así como sus interrelaciones y propiedades. Debido a que el módulo de Gestión
de Órdenes de Servicio forma parte de un sistema mayor, este diagrama vendría siendo
parte de un diseño más grande el cual representa la lógica de negocios de todo el sistema,
y representa un único clúster que, aunque modela el módulo de Gestión de Órdenes de
Servicio independientemente, tiene relaciones con algunas entidades que no pertenecen
únicamente a este módulo. Por comodidad se ha divido este diagrama en dos partes (1 y 2
respectivamente).
En la parte 1 del diagrama entidad relación, la entidad principal en el módulo es Case,
esta entidad representa a las Órdenes de Servicio (o Casos como son denominados en la
interfaz). Las entidades Status, Type, Party, Priority, Document y Tag no son propias de la
lógica del módulo de Gestión de Órdenes de Servicio, sin embargo, son utilizadas

35
complementariamente y sus relaciones representan la integración del módulo con la
totalidad del sistema.
Figura 9: Parte 1 del Diagrama Entidad/Relación.

36
La entidad Type representa una generalización de tipos de entidad, la entidad Status
representa una generalización de estatus de entidad, la entidad Priority representa una
generalización de prioridades, la entidad Party representa a participantes (ya sean,
individuos, compañías u organizaciones), la entidad Document representa documentos y
por último la entidad Tag representa etiquetas asociables a entidades.
La relación CaseType representa el tipo de Caso, la relación CaseStatus representa
el estatus del Caso, la relación CasePriority representa la prioridad del Caso, la relación
RoleAssignment representa a los participantes involucrados en el caso, la relación
DocumentAssignment representa los documentos adjuntados y por último la relación
CaseTags representa las etiquetas asociadas al caso.
Continuando con la parte 2 del diagrama, la entidad principal es Activity, la cual
representa las actividades individuales asignadas a cada caso. En esta parta vuelven a estar
presentes las entidades Case, Status, Priority y Type y, adicionalmente, una nueva entidad
WorkEffort, la cual representa unidades de esfuerzo invertidas en cada actividad.
La relación CaseActivity representa la asignación de una actividad a un Caso, la
relación ActivityStatus representa el estatus de la actividad, la relación ActivityPriority
representa la prioridad de la actividad, la relación WorkEffortType representa el tipo de
unidad de esfuerzo y finalmente la relación WorkEffortAssignment representa las unidades
de esfuerzo invertidas en cada actividad.

37
Figura 10: Parte 2 del diagrama Entidad/Relación.

38
4.2.4. Navegación entre ventanas
Partiendo de las matrices de Requerimientos y de Funcionalidades, se ha elaborado
un conveniente diagrama que representa la Navegación entre ventanas. Este diagrama
permite comprender el flujo de Eventos y Tareas que ocurren a través de la navegación
entre las ventanas del módulo. Para una mejor comprensión, se ha realizado una breve
leyenda que señala los elementos que conforman al diagrama referente.
Figura 11: Leyenda de Navegación entre Ventanas

39
Figura 12: Diseño Lógico de Navegación entre Ventanas.

40
4.2.5. MockUps de las Ventanas
Para concluir con los artefactos generados, se han diseñado los MockUps (o
maquetas) de las ventanas que responden a los requerimientos acordados con el cliente, y
expuestos en las matrices de Requerimientos y Funcionalidades.
Figura 13: MockUp de creación de nuevo Caso.

41
Figura 14: MockUp de Detalle de Caso: Usuario Cliente.

42
Figura 15: MockUp de Editar Caso – Sección General: Usuario Administrador.
Figura 16: MockUp de Editar Caso - Sección de Actividades: Usuario Administrador.

43
4.3. Pruebas realizadas
Una vez que se ha desarrollado una aplicación es necesario verificar y validar que está
libre de anomalías y que se ha logrado el objetivo de su diseño. Las pruebas de
funcionalidad determinan que la aplicación satisface los requisitos funcionales esperados.
(Rodríguez, 2017).
Con el fin de cumplir con el último de los objetivos, se han realizado pruebas de
funcionalidad a la aplicación, a continuación, se detallan las pruebas:
4.3.1. Pruebas de requerimientos:
Se realizaron pruebas de requerimientos con base en la Matriz de Requerimientos
expuesta en la sección 4.2.1.
Requerimiento Se cumplió Comentario
Gestión de Órdenes de
Servicio
Sí
El módulo permite crear, mantener y eliminar
Gestión de Actividades Sí
Actividades asociadas a Órdenes de Servicio.
Gestión de Individuos y
Organizaciones
Sí
El módulo permite dirigir las Órdenes de
Servicio a los individuos y Organizaciones
registrados en el sistema.
Gestión de Registros Sí
El módulo permite conservar y volver a revisar
Órdenes de Servicio ya resueltas.
Gestión de Documentos Sí
El módulo permite adjuntar documentos a las
Gestión de Esfuerzo Sí
Unidades de Esfuerzo asociadas a Actividades.
Tabla 3: Pruebas de Requerimientos.

44
4.3.2. Pruebas de funcionalidad:
Se realizaron pruebas de funcionalidad basadas en la Matriz de Funcionalidades
expuesta en la sección 4.2.2. Para poder realizar estas pruebas se debió configurar
previamente ciertos parámetros del sistema, ajenos al módulo propiamente, de los cuales
se depende para funcionar correctamente, estos incluyen: Tag, utilizadas para clasificar
Type Status y Casos propiamente; Type, para clasificar Casos, Actividades y Esfuerzo;
Status, para Casos y Actividades; Party, para dirigir los Casos; Priority, para Casos y
Actividades. Estas entidades y su relación con la lógica de negocios del módulo fueron
explicadas en la sección 4.2.3.
Creación de un Caso:
Para la creación de un nuevo caso, se llenan los campos como se muestra en la Figura
17. Este nuevo caso será visible en la lista de casos del administrador, como se muestra en
la Figura 18.
Figura 17: Nuevo Caso de prueba.

45
Figura 18: Caso de prueba Creado.
Ver detalle / Editar un Caso:
Al entrar en la vista de detalles y edición de un caso podemos apreciar que se generó
el caso con los datos suministrados por el usuario cliente, además de ciertos campos
generados por defecto, esto puede apreciarse en la Figura 19.
Para probar el funcionamiento de la edición de un Caso, se realizaron cambios en los
campos, se actualizó la prioridad del Caso de Media a Alta y el estatus de Creado a
Recibido, además se adjuntó un archivo, como puede ser observado en la Figura 20.
Finalmente pueden ver estos cambios realizados al cargar nuevamente el listado de Casos,
como se aprecia en la Figura 21.

46
Figura 19: Detalle/Edición de Caso de prueba.
Figura 20: Detalle/Edición con cambios de Caso de prueba.

47
Figura 21: Listado con cambios en Caso de prueba.
Creación/Edición de Actividades y Esfuerzo:
Para probar la creación de actividades del Caso de prueba, primero se accede a la
sección de actividades, como se puede observar en la Figura 22, en la que podemos
apreciar que en primera instancia se encuentra vacía. Seguidamente agregamos una nueva
actividad, la cual se encuentra inicialmente vacía, como se aprecia en la Figura 23.
Seguidamente se llenan los campos y se agrega el esfuerzo al que igualmente se le llenan
sus campos, como se observa en la Figura 24 y finalmente se aprecia en la Figura 25 que
se realizan los cambios de manera exitosa.
Figura 22: Sección de Actividades Vacía.

48
Figura 23: Sección de Actividades - Actividad creada.

49
Figura 24: Sección de Actividades - Lleno para prueba.
Figura 25: Guardado exitoso de cambios en Caso de prueba.
Eliminación de Casos:
Finalmente, para probar la correcta eliminación de un Caso seleccionado (Figura 26),
primero se pide confirmación de la acción (Figura 27) y seguidamente puede apreciarse el
mensaje de eliminación exitosa en la Figura 28.

50
Figura 26: Listado de Casos - Caso seleccionado.
Figura 27: Confirmación para eliminar Caso.

51
Figura 28: Eliminación exitosa de Caso de prueba.
4.4. Sprints
Siguiendo con la metodología de desarrollo de software propuesta en la sección 3.3
de este documento, a continuación se presenta la distribución de los sprints en el tiempo de
diseño, desarrollo y pruebas del módulo. En total hubo 8 sprints de duración variable, para
cada uno se cumplió con avances relacionados entre sí a nivel técnico. El tiempo total de
diseño, desarrollo y pruebas fue de 56 días, sumados 4 días de inactividad, en un lapso
comprendido entre el 5 de marzo y el 3 de mayo.
1. Especificaciones funcionales, Diseño y Modelado: El primer sprint tuvo una
duración de 9 días, en un lapso comprendido entre el 5 y el 13 de marzo de
2018. En este sprint se desarrollaron las matrices de Requerimientos y
Funcionalidades, durante el proceso de desarrollo se realizaron varias reuniones
con el cliente en las que se alinearon las matrices con las necesidades de los
usuarios y se aclaró el contexto de uso de la aplicación, por lo que resultaron
constantes cambios y ajustes en este período, esto se abordó de la manera
expuesta, siguiendo las actividades 1, 2 y 3 (Planificar centrado en el usuario,
Especificar el contexto de uso y Especificar requisitos del usuario,
respectivamente) del estándar propuesto en la sección 2.2.7. Adicionalmente se
diseñaron los modelos de la Base de Datos, de lo cual resultó el Diagrama

52
Entidad/Relación, así como el diagrama de Navegación entre Ventanas y los
MockUps, con esto se cumple la actividad 4 del mencionado estándar. Con la
conclusión de las reuniones con el cliente, teniendo la aprobación de los diseños
y modelo desarrollados en base a sus requerimientos, se cumple con la actividad
5 del mencionado estándar.
2. Configuración de Base de Datos: El segundo sprint tuvo una duración de 2
días, en un lapso comprendido entre el 15 y el 16 de marzo de 2018. En este
sprint se generaron los scripts a partir del modelo físico de la Base de Datos y
se configuró el servidor de Bases de Datos para servirle a la lógica de negocios
del módulo.
3. Entidades de Configuración del Sistema: El tercer sprint tuvo una duración
de 9 días, en un lapso comprendido entre el 17 y el 25 de marzo de 2018. En
este sprint se desarrolló el segmento de la API REST del backend del sistema
que permite dar uso a las entidades de configuración relacionadas con el
módulo, siendo estas Type, Status y Priority, explicadas previamente en la
sección 4.2.3.
4. Entidades de Configuración del Módulo: El cuarto sprint tuvo una duración de
6 días, en un lapso comprendido entre el 26 y el 31 de marzo de 2018. En este
sprint se desarrolló el segmento de la API REST del backend del módulo
relacionado con las entidades de configuración propias del módulo en cuestión,
siendo estas Document y WorkEffort, ambas explicadas previamente en la
sección 4.2.3.
5. Entidades Principales del Módulo: El quinto sprint tuvo una duración de 9 días,
en un lapso comprendido entre el primero y el 9 de abril de 2018. En este sprint
se desarrolló el segmento de la API REST del backend del módulo relacionado
con las entidades que representan la lógica principal, siendo estas Case y
Activity, ambas explicadas previamente en la sección 4.2.3.
6. Vistas: El sexto sprint tuvo una duración de 14 días, en un lapso comprendido
entre el 10 y el 23 de abril de 2018. En este sprint se desarrollaron las Vistas o

53
Ventanas diseñadas en el primer sprint, al igual que se implementó el flujo de
navegación acorde al diagrama de Navegación de Ventanas.
7. Comunicación con Backend: El séptimo sprint tuvo una duración de 5 días, en
un lapso comprendido entre el 24 y el 28 de abril de 2018. En este sprint se
implementó en las Vistas, la lógica con la que se consume la API REST expuesta
en el backend desarrollado en los sprints 3, 4 y 5.
8. Pruebas de Funcionalidad: El octavo y último sprint tuvo una duración de 2
días, en un lapso comprendido entre el 2 y el 3 de mayo de 2018. En este sprint
de realizaron pruebas al módulo, basadas en las matrices de Requerimientos y
Funcionalidades. Conjuntamente, en estas pruebas se corrobora el
cumplimiento de los diseños aprobados por el cliente en el primer sprint, con lo
que se cumple con la actividad 6 del estándar, igualmente mencionado
previamente y explicado en la sección 2.2.7, finalizando así con el desarrollo y
pruebas del módulo, haciendo uso de un estándar de usabilidad centrado en el
proceso de diseño.

54
Capítulo 5. Conclusiones y Recomendaciones
En este capítulo se presentan conclusiones y recomendaciones obtenidas como
resultado del cumplimiento de los objetivos, tanto el general como específicos, plasmados
en el Capítulo 1, y habiendo revisado los resultados del Capítulo 4.
5.1.Conclusiones
Como se explicó en la sección 1.1 de este documento, la empresa CrediNat C.A. está
distribuida a lo largo de todo el país, lo cual representa dificultades para gestionar las
necesidades de todos sus empleados, tomando en cuenta que sus recursos se encuentran
dispersos entre sus distintas sedes. Esta problemática es comúnmente resuelta por otras
empresas a través de la implementación de sistemas de tipo Escritorio de Ayuda o de
Servicio, los cuales, entre sus objetivos, incluyen la centralización de un punto de contacto
para la atención de incidentes, como así fue explicado en el Marco Teórico, es por esto que
la empresa se planteó desarrollar una aplicación de este tipo y así poder manejar
oportunamente las actividades que conlleven a solucionar su problemática. Adicionalmente,
la empresa se encontraba en pleno desarrollo de un sistema para su uso interno, por lo que
se decidió que la mencionada aplicación se integrase en el sistema ya en desarrollo, como
un módulo más, y así sacar provecho de elementos ya presentes en dicho sistema.
En base a la situación planteada, se llevó a cabo la presente investigación, en la cual
se planteó el objetivo de desarrollar el Módulo de Gestión de Órdenes de Servicio, que
permitiese a los usuarios crear Casos en los que puede ser notificada la necesidad de
prestar un servicio o la existencia de un problema, para luego ser gestionadas actividades
que conlleven a una solución. Para cumplir con este objetivo, se dispusieron objetivos
específicos, los cuales incluyen: Investigar acerca de sistemas similares, levantar

55
requerimientos, modelar y diseñar siguiendo estándares de usabilidad y finalmente
desarrollar y probar dicho módulo, todo esto expuesto en la sección 1.2 del documento.
Como resultado, se realizó una investigación, expuesta en detalle en el Capítulo 2, en
la cual se exponen trabajos previos que sirvieron de guía en esta investigación, junto con
las bases que permitieron cumplir con los objetivos general y específicos, incluyendo entre
estas: definiciones de sistemas de tipo Escritorio de Ayuda y Servicio junto con sus objetivos
y factores de éxito en su desarrollo; estándares de usabilidad aplicables en el proceso de
desarrollo de sistemas de este tipo; y demás conceptos clave en la compresión de las
especificaciones técnicas del módulo en cuestión. Conjuntamente, en el Capítulo 3, se
explican las metodologías de investigación y de desarrollo de software escogidas para llevar
a cabo esta investigación y desarrollo, respectivamente. Finalmente, en el Capítulo 4, se
exponen los resultados obtenidos en el diseño, desarrollo y pruebas del módulo que
conllevaron al cumplimiento de los objetivos, finalizando con un resumen de la distribución
de las etapas y tiempos tomados para lograr esto, divido en 8 sprints.
El producto del desarrollo fue explicado en detalle en la sección 4.1, que adicional al
cumplimiento del objetivo general y gracias a que se siguió la arquitectura planteada por la
empresa, la lógica de negocios del módulo es expuesta independientemente a través del
estándar REST, lo que permite que aplicaciones externas le den uso sin comprometer la
integridad de la base de datos, además de presentar gran escalabilidad, tanto el backend
como el frontend independientes el uno del otro.
Igualmente, en la sección 4.2, se explican a detalle los artefactos que permiten
comprender más claramente el módulo desarrollado. Estos artefactos consisten de: La
matriz de requerimientos funcionales, la cual expone las características de funcionamiento
acordadas con el cliente; la matriz de funcionalidades, la cual expone las acciones
específicas asociadas a cada característica expuesta en la matriz de requerimientos
funcionales; el diagrama entidad-relación, el cual expone gráficamente el modelo conceptual
de la base de datos de la cual se alimenta el módulo, a través de entidades, sus atributos y
sus relaciones; el diagrama de navegación entre ventanas, el cual define los eventos y
acciones realizadas por los usuarios para cumplir con los objetivos del módulo; y las

56
maquetas (MockUps) de las ventanas, en base a los requerimientos funcionales, que
sirvieron de guía al desarrollar las Vistas.
Así finalmente, se puede concluir que los objetivos planteados fueron alcanzados con
el desarrollo del Módulo de Gestión de Órdenes de Servicio de la empresa CrediNat C.A.,
integrado al sistema en proceso de desarrollo, siguiendo sus pautas de desarrollo y
metodología propuesta, y desarrollando el conjunto de artefactos.
5.2.Recomendaciones
Habiendo plasmado las conclusiones, se procede a expresar algunas
recomendaciones que pudieran ayudar a sacar mayor provecho del módulo en futuros
desarrollos.
A través de la evaluación de los dos componentes principales del módulo, las vistas
(frontend) y la API (backend), se puede señalar el potencial para una mejora en las vistas.
Ya que la lógica de negocios está expuesta independientemente de las vistas a través de la
API, se pudo notar que no se es sacado el mayor provecho de su complejidad por las vistas,
a través de la adición de más elementos visuales que reflejen la lógica de negocios, es
posible ser más descriptivos con las entidades asociadas a los ojos del usuario, lo que
permitiría ser más organizados con la clasificación de los Casos, la asociación de individuos
y organizaciones, y la verificación de los historiales actividades.
Adicionalmente, es de gran utilidad para las empresas evaluar estadísticas de las
problemáticas presentes a lo largo del tiempo con la finalidad de detectar tendencias y
errores más allá de lo evidente, actualmente es posible sondear la data y realizar las
métricas necesarias a través de la API expuesta o accediendo directamente a la Base de
Datos. Se recomienda integrar la función de configurar la realización periódica de métricas
y cálculo de estadísticas para ser evaluada regularmente a través de la interfaz. Y así sacar
mayor provecho de los registros históricos tomados por la aplicación.
Como punto de atención, si bien los estándares de usabilidad orientados al proceso
sirvieron de guía en el diseño del módulo desarrollado, estos tienen la desventaja de no
estar basados en el uso puntual de la aplicación por parte de los usuarios, para asegurar la
usabilidad de, no sólo el módulo, más de todo el sistema, es recomendable, una vez

57
implantada la aplicación, aplicar estándares de usabilidad orientados al usuario con una
población real, y así obtener resultados adaptados a los usuarios reales de la aplicación.
Finalmente, es de gran ayuda para personas con discapacidades que las aplicaciones
de su uso frecuente cumplan con los estándares de accesibilidad, previendo la existencia,
o futura existencia, de empleados con discapacidades en la empresa, se recomienda
evaluar y asegurar en el módulo dichos estándares.

58
Glosario de Términos
Estándar: documento establecido por consenso y aprobado por una institución
reconocida, que prevé, para uso común y repetido, reglas, directrices y características para
actividades o sus resultados, encaminada a la consecución del grado óptimo de definición
en un contexto dado. (ISO/IEC, 2004).
Framework: es un conjunto de conceptos estandarizados, prácticas y criterios para
enfocar un tipo de problemática como referencia, y poder abordar y resolver problemáticas
similares. (Galindo y Camps, 2008).
Recurso: es una fuente o suministro que produce un beneficio. (Garcia, 2009).
Reglas de Negocio: son condiciones externas que afectan el flujo de las actividades.
(CONACYT, 2009).
Usabilidad: La medida con la que un producto se puede usar por usuarios
determinados para conseguir objetivos específicos con efectividad, eficiencia y satisfacción
en un contexto de uso concreto. (ISO, 2018).

59
Glosario de Acrónimos
AJAX: siglas en ingles de Asynchronous JavaScript And XML, JavaScript Asíncrono y
XML, es una técnica de desarrollo web para crear aplicaciones interactivas.
API: siglas en ingles de Application Programming Interface, es un conjunto de
subrutinas que son ofrecidas para ser usadas por otro software con una capa de
abstracción.
GWT: siglas en ingles de Google Web Toolkit, es un framework creado por google que
permite ocultar la complejidad de varios aspectos de la tecnología AJAX.
HTTP: siglas en ingles de Hypertext Transfer Protocol, protocolo de transferencia de
hipertexto.
REST: siglas en ingles de Representational State Transfer, Transferencia de estado
representacional, es un estilo de arquitectura de software para los sistemas hipermedia
distribuidos.
UML: siglas en inglés, Unified Modeling Language, es el lenguaje de modelado de
sistemas de software más conocido y utilizado en la actualidad.
XML: siglas en inglés de eXtensible Markup Language.

60
Referencias Bibliográficas
Arias (2006). El Proyecto de Investigación Introducción a la metodología científica.
Caracas, Venezuela.
Balmori (2003). Factores de éxito e Inhibidores en el uso de un Help Desk basado en
Internet para ofrecer soporte técnico. Instituto Tecnológico de Estudios Superiores de
Monterrey, México.
CampusMVP (2015). Desarrollador web: Front-end, back-end y full stack. ¿Quién es
quién? Recuperado el 21 de abril de 2018, de
https://www.campusmvp.es/recursos/post/Desarrollador-web-Front-end-back-end-y-full-
stack-Quien-es-quien.aspx
Chou (2002). Redesigning a large and complex Website: how to begin, and a method
for success. The ACM Digital Library.
CONACYT (2009). Creación y administración de Reglas de Negocio. Recuperado el
09 de mayo de 2018, de
http://www.semanticwebbuilder.org.mx/es_mx/swb/Manuales_Process/_rid/347/_mto/3/_ac
t/download/doc/Creacion_y_Administracion_de_Reglas_de_Negocio.pdf
Conte, Massolar, Mendes y Travassos (2007). Usability Evaluation Based on Web
Design Perspectives. The University of Auckland.
Galindo y Camps (2008). Diseño e implementación de un marco de trabajo
(framework) de presentación para aplicaciones JEE.
Gamez (2014). Barradas en Framework de Gestión de Infraestructura de TI Basado
en Buenas Prácticas, Enmarcado en el Proceso de Gestión Financiera. Universidad de
Carabobo.
Garcia (2009). El pequeño Larousse Ilustrado. Londres: Ediciones Larousse.

61
Hernández (2015). Desarrollo del Módulo de Gestión de Trámites de Profesores del
Sistema de Gestión de la Programación Docente para el Departamento de la Escuela de
Computación de la Universidad Central de Venezuela. Universidad Central de Venezuela.
Huerta y Lenin (2014). Implantación de un Sistema Help Desk para el Proceso de
Atención de Incidencias de Hardware y Software Bajo la Modalidad Open Source en la
Empresa Mixercon S.A. Universidad Peruana de Integración Global.
Invgate Blog (2015). ¿Cuál es la diferencia entre un Help Desk y un Service Desk?
Recuperado el 10 de abril de 2018, de http://blog.invgate.com/es/diferencia-help-desk-
service-desk
ISO/IEC Guide 2 (2004). Standardization and related activities -- General vocabulary.
Recuperado el 09 de mayo de 2018, de https://www.iso.org/standard/24887.html
ISO 9241-11 (2018). Ergonomics of human-system interaction -- Part 11: Usability:
Definitions and concepts. Recuperado el 09 de mayo de 2018, de
https://www.iso.org/standard/63500.html
Kruchten, P. (1995). Architectural Blueprints—The “4+1” View. IEEE Software , 42-
50. Recuperado el 24 de abril de 2018, de
https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf.
Lafon (2003). W3C. Recuperado el 24 de abril de 2018, de
https://www.w3.org/Protocols/
Martínez (2009). WUEP: Un Proceso de Evaluación de Usabilidad Web Integrado en
el Desarrollo de Software Dirigido por Modelos. Universidad Politécnica de Valencia.
Montes, Hornos, Abad y Hurtado. Help Desk: Soporte Técnico para la Empresa del
Siglo XXI. Universidad de Granada.
Ortiz (2015). Propuesta de implementación de un Sistema Service Desk basado en
Infraestructura System Center para la gestión de Incidentes, Eventos, Peticiones y
problemas en la Universidad Central Del Ecuador.

62
Rhone (2013). The JSON Data Interchange Format.Villereuse, Suiza: Ecma
International. Recuperado el 24 de abril de 2018, de https://www.ecma-
international.org/publications/files/ECMA-ST/ECMA-404.pdf
Riehle (2000). Framework Design: A Role Modeling Approach. Ph.D, 7-9.
Recuperado el 24 de abril de 2018, de http://dirkriehle.com
Rivera (2008). Sistema asistente para la generación de horarios de cursos, Capítulo
4. Lógica de Negocios. Recuperado el 09 de mayo de 2018, de
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/rivera_l_a/capitulo4.pdf
Rodríguez (2011). Sistema Automatizado de Soporte y Atención al Usuario para
Supermetanol y Super Octanos. Universidad Nacional Abierta.
Rodríguez (2017). Sistema centralizado de control de acceso basado en una
estrategia de organización en roles a clientes y usuarios de la empresa GlobalMedia.
Universidad de Carabobo.
Silberschatz y Korth (2002). Fundamentos de bases de datos. Madrid: McGRAW-
HILL
Sun Microsystem (1995). Java: ¿Que es la Tecnología JAVA?. Recuperado el 21 de
abril de 2018, de https://www.java.com/es/download/faq/whatis_java.xml
The Apache Software Foundation (2018). What is Maven? Recuperado el 23 de
mayo de 2018, de https://maven.apache.org/what-is-maven.html
Tueti (2010). Análisis y propuesta de Mejora del Proceso de Gestión de Incidentes
del Service Desk de Mercantil Seguros. Universidad Simón Bolívar.

Tesis: Desarrollo de Aplicación Web tipo help desk integrado en Sistema Web existente

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Tesis: Desarrollo de Aplicación Web tipo help desk integrado en Sistema Web existente

Similar a Tesis: Desarrollo de Aplicación Web tipo help desk integrado en Sistema Web existente (20)

Más de Jesus Jimenez

Más de Jesus Jimenez (14)

Último

Último (20)

Tesis: Desarrollo de Aplicación Web tipo help desk integrado en Sistema Web existente