Uce-Fing-Isi-Cachimuel Luis-Viscaino Cristian

Universidad Central del Ecuador
Facultad de Ingeniería y Ciencias Aplicadas

Carrera de Ingeniería Informática
Implementación de un sistema de información integrado para la gestión de

procesos en una empresa del área de TI.
Trabajo de titulación – Opción: Proyecto integrador presentado para obtener el grado
académico de Ingeniero Informático.
Autores: Luis Raúl Cachimuel Pazmiño

Cristian Xavier Viscaino Tacuri
Tutor: Ing. Santiago Leonardo Morales Cardos, Ph.D
Quito – 2023
Cesión de derechos de autor.
Mediante el envío del presente correo electrónico ACEPTO EN FORMA EXPRESA en

calidad de autor, titular de los derechos morales y patrimoniales del trabajo de titulación:
[Implementación de un sistema de información integrado para la gestión de procesos
en una empresa del área de TI]. De conformidad con el Artículo 114 del Código
Orgánico de la Economía Social de los Conocimientos, Creatividad e Innovación:
“De los titulares de derechos de obras creadas en las instituciones de educación superior y
centros educativos.- En el caso de las obras creadas en centros educativos, universidades,
escuelas politécnicas, institutos superiores técnicos, tecnológicos, pedagógicos, de artes y los
conservatorios superiores, e institutos públicos de investigación como resultado de su
actividad académica o de investigación tales como trabajos de titulación, proyectos de
investigación o innovación, artículos académicos, u otros análogos, sin perjuicio de que
pueda existir relación de dependencia, la titularidad de los derechos patrimoniales
corresponderá a los autores. Sin embargo, el establecimiento tendrá una licencia gratuita,
intransferible y no exclusiva para el uso no comercial de la obra con fines académicos.”
Asimismo, autorizo a la Universidad Central del Ecuador para que realice la publicación de
este trabajo de titulación en el repositorio institucional en formato digital tal como lo
establece el documento RHCU.SO.22 CIRCULAR No. 027-2021 del 11 de junio del año
2021 con nombre “Creación del archivo digital de la Universidad Central del Ecuador”, y de
conformidad a lo dispuesto en el Artículo 144 de la Ley Orgánica de Educación Superior:
“Trabajos de Titulación en formato digital. - Todas las instituciones de educación superior

estarán obligadas a entregar los trabajos de titulación que se elaboren para la obtención de
títulos académicos de grado y posgrado en formato digital para ser integradas al Sistema
Nacional de Información de la Educación Superior del Ecuador para su difusión pública
respetando los derechos de autor.”
El/la autor/autora declara que la obra objeto de la presente autorización es original en su

forma de expresión y no infringe el derecho de autor de terceros, asumiendo la
responsabilidad por cualquier reclamación que pudiera presentarse por esta causa y liberando
a la Universidad de toda responsabilidad.
El/la autor/autora reconozco que este mensaje electrónico de aceptación reemplaza a mi

firma física, y tiene la validez legal de conformidad a lo dispuesto en la Ley de Comercio
Electrónico, Firmas y Mensajes de Datos, en sus artículos 3, 6 y 8,
“Art. 3.- Incorporación por remisión. - Se reconoce validez jurídica a la información no
contenida directamente en un mensaje de datos, siempre que figure en el mismo, en forma
de remisión o de anexo accesible mediante un enlace electrónico directo y su contenido sea
conocido y aceptado expresamente por las partes.”
“Art. 6.- Información escrita. - Cuando la Ley requiera u obligue que la información conste
por escrito, este requisito quedará cumplido con un mensaje de datos, siempre que la
información que éste contenga sea accesible para su posterior consulta.”
“Art. 8.- Conservación de los mensajes de datos. - Toda información sometida a esta Ley,
podrá ser conservada; este requisito quedará cumplido mediante el archivo del mensaje de
datos, siempre que se reúnan las siguientes condiciones:
a. Que la información que contenga sea accesible para su posterior consulta;

b. Que sea conservado con el formato en el que se haya generado, enviado o recibido,
o con algún formato que sea demostrable que reproduce con exactitud la información
generada, enviada o recibida;
c. Que se conserve todo dato que permita determinar el origen, el destino del mensaje,
la fecha y hora en que fue creado, generado, procesado, enviado, recibido y
archivado; y,
d. Que se garantice su integridad por el tiempo que se establezca en el reglamento a esta
ley.
Toda persona podrá cumplir con la conservación de mensajes de datos, usando los servicios
de terceros, siempre que se cumplan las condiciones mencionadas en este artículo.”
(Este documento esta validado por el autor a través del formato en el archivo de Mensaje de datos cuya
descripción es “DERECHOS DE AUTOR”)
Luis Raúl Cachimuel Pazmiño
C.C. 1313170100
C.C. 1726517608
Dedicatoria.
Este trabajo está dedicado a toda mi familia, especialmente a mis padres que fueron mi
motivación omnipresente a lo largo de toda mi carrera universitaria, y a mi hermano para
impulsarlo a cumplir grandes objetivos como lo es este.
También quiero dedicarle este trabajo a mi novia Valeria, por su incansable apoyo durante
todo este proceso.
Para finalizar, este trabajo también va dedicado a mi querido amigo Hugo Salazar, el cual en
vida fue un talentoso y aguerrido estudiante de esta carrera.

Dedicatoria.
Dedico el presente trabajo a Dios y a toda mi familia, especialmente a mi madre y padre, que
me apoyaron en toda la carrera universitaria, y por motivarme a seguir adelante.
También le quiero dedicar este trabajo a todas las personas que en su momento me dieron
palabras de aliento y apoyo para seguir adelante y llegar a este punto.

Agradecimiento.
Gracias a mi madre, por ser la persona más perseverante que existe y por transmitirme ese
sentimiento que me ha impedido claudicar, además de ser mi impulso de superación.
A mi padre, la voz del optimismo y el apoyo, que nunca ha dejado de estar empujándome
hacia adelante.
A mi novia, por ser el apoyo emocional y físico sin el cual no podría haberlo logrado.
A mi familia que ha estado conmigo desde que era un niño y ahora también en mi etapa
laboral.
A todos mis amigos, que me han brindado su entusiasmo y compañía.

Agradecimiento.
Gracias a mi madre y padre, por todo su apoyo emocional y todas sus palabras de aliento a
través de los años.
A Luis Raúl Cachimuel Pazmiño, por permitirme formar parte del desarrollo de la presente
tesis. A todas las personas y amigos que conocí en la vida universitaria, por aportar con su
granito de arena.

Resumen.
El presente trabajo tiene como objetivo resaltar las diferencias de la interpretación de una pintura
con texto desde tres miradas: la de un crítico de arte, la de un escritor y la de un espectador.
Analizando el concepto de interpretación de una obra pictórica indaga en los aspectos
estructurales de la obra visual y la palabra en conjunto, así como las particularidades de cada
interpretación desde el campo sensorial y cognitivo. Para el presente desarrollo se toman como
base los conceptos en cuanto a las formas de pensamiento, la transformación de la visualidad en
lenguaje y las características del texto en la obra.
Palabras clave: Odoo, Postgresql, Help desk, Gestión de proyectos.
Abstract.
This work aims to develop a system for project management and customer service for an IT
company through the ERP (Enterprise Resource Planning) ODOO, which will allow the company
to optimize the use of its resources, increase the quality of developments and services provided to
customers, thus increasing efficiency and reducing response times of internal processes,
consequently reducing costs and increasing the company's sales.
Keywords: Odoo, Postgresql, Help Desk, Project management.
i
Tabla de contenidos
Tabla de contenidos .................................................................................................................... i
Lista de tablas ............................................................................................................................ v
Lista de ilustraciones................................................................................................................vii
Introducción ............................................................................................................................... 1
Capítulo 1.................................................................................................................................. 2
1. Presentación del problema .............................................................................................. 2
1.1 Planteamiento del problema ........................................................................................ 2
1.2 Objetivos del proyecto ................................................................................................ 2
1.2.1 Objetivo general ...................................................................................................... 2
1.2.2 Objetivos específicos ............................................................................................... 3
1.3 Justificación ................................................................................................................. 3
1.4 Alcance ........................................................................................................................ 4
1.4.1 Perfiles en la aplicación ............................................................................................. 4
1.4.2 Creación de tickets en el sistema ............................................................................... 5
1.4.3 Gestión de proyectos .................................................................................................. 5
1.4.4 Creación de KPI´S ..................................................................................................... 5
1.4.5 Gestión de reportes .................................................................................................... 6
Capítulo 2.................................................................................................................................. 7
2. Marco teórico .................................................................................................................. 7
2.1 ERP.............................................................................................................................. 7
2.1.1 Beneficios de un ERP .................................................................................................. 7
2.1.2 Comparación ERP....................................................................................................... 8
2.2 ODOO ....................................................................................................................... 10
2.2.1 Seguridad ............................................................................................................... 10
2.2.2 Características....................................................................................................... 11
ii
2.2.3 Arquitectura de ODOO ......................................................................................... 11
2.3 Python........................................................................................................................ 13
2.4 Ubuntu 20.0.4 LTS .................................................................................................... 13
2.5 Pycharm ..................................................................................................................... 13
2.6 Help Desk .................................................................................................................. 13
2.6.1 Módulo de la comunidad Website Help Desk .......................................................... 14
2.7 Gestión de Proyectos ................................................................................................. 15
2.8 MVC en Odoo ........................................................................................................... 16
2.9.1 Modelo ................................................................................................................... 17
2.9.2 Vista ....................................................................................................................... 18
2.10 Estado del Arte .......................................................................................................... 19
Capítulo 3................................................................................................................................ 22
3. Metodología .................................................................................................................. 22
3.1 Metodologías ágiles................................................................................................... 22
3.2 Scrum ........................................................................................................................ 22
3.2.1 Fases de la metodología Scrum ............................................................................. 23
3.2.2 Perfiles de la metodología Scrum .......................................................................... 23
3.2.3 Beneficios de la metodología Scrum ..................................................................... 24
Capítulo 4................................................................................................................................ 25
4. Aplicación de la metodología de desarrollo.................................................................. 25
4.1 Levantamiento de requerimientos ............................................................................. 25
4.1.1 Resumen de roles y funciones ................................................................................ 49
4.1.2 Funcionalidades .................................................................................................... 50
4.1.2.2 KPI´s .................................................................................................................. 50
4.1.3 Flujograma ............................................................................................................ 51
4.2 Casos de uso .............................................................................................................. 52
4.3 Diagrama de procesos ............................................................................................... 53

iii
Proceso A .......................................................................................................................... 53
Proceso B........................................................................................................................... 53
4.4 Modelo entidad relación .............................................................................................. 1
4.5 Diccionario de datos .................................................................................................. 45
4.6 Sprint 0 ...................................................................................................................... 51
4.6.1 Planificación del sprint ............................................................................................. 51
4.6.2 Ejecución del sprint ................................................................................................... 52
4.6.3 Revision del sprint ................................................................................................. 54
4.6.4 Resultados y pruebas ............................................................................................. 54
4.7 Sprint 1 ...................................................................................................................... 54
4.7.1 Planificación del sprint ............................................................................................. 54
4.7.2 Ejecución del sprint ................................................................................................... 55
4.8 Sprint 2 ...................................................................................................................... 55
4.8.1 Planificación del sprint ......................................................................................... 56
4.8.2 Ejecución del sprint ............................................................................................... 56
4.9 Sprint 3 ...................................................................................................................... 59
4.9.1 Planificación del sprint ......................................................................................... 59
4.9.2 Ejecución del sprint ............................................................................................... 60
4.10 Sprint 4 ...................................................................................................................... 62
4.10.1 Planificación del sprint ...................................................................................... 63
4.10.2 Ejecución del sprint ........................................................................................... 63

iv
4.10.3 Revision del sprint.............................................................................................. 64
4.10.4 Resultados y pruebas ......................................................................................... 65
Capítulo 5................................................................................................................................ 66
5. Paso a producción, despliegue en AWS ....................................................................... 66
5.3 Proceso de despliegue ............................................................................................... 67
Capítulo 6................................................................................................................................ 71
6. Conclusiones y recomendaciones ................................................................................. 71
6.1 Conclusiones ............................................................................................................. 71
6.2 Recomendaciones ...................................................................................................... 71
7.Referencias bibliográficas ..................................................................................................... 73

v
Lista de tablas
Tabla 1: Comparación de ERP.................................................................................................. 8
Tabla 2: R01 Acceso al sistema .............................................................................................. 25
Tabla 3: R02 Acceso seguro al sistema .................................................................................. 25
Tabla 4: R03 Perfiles de usuarios ........................................................................................... 26
Tabla 5: R04 Portal de invitados............................................................................................. 27
Tabla 6: R05 Estados de un ticket/tarea.................................................................................. 28
Tabla 7: R06 Creación de nuevo ticket para tickets en estado Reabierto ............................... 29
Tabla 8: R07 Creación de tickets ............................................................................................ 29
Tabla 9: R08 Atención de tickets ............................................................................................ 30
Tabla 10: R09 Visualizar información de contacto y de infraestructura del cliente............... 31
Tabla 11: R010 Registrar tiempo de trabajo en tickets/tareas ................................................ 32
Tabla 12: R011 Pantalla de worksheet ................................................................................... 33
Tabla 13: R012 Administración de contratos ......................................................................... 33
Tabla 14: R013 Administración de proyectos ........................................................................ 34
Tabla 15: R014 Visualización de tickets de soporte ............................................................... 35
Tabla 16: R015 Visualización de tareas de desarrollo ............................................................ 36
Tabla 17: R016 Creación automática de proyectos por contrato creado ................................ 37
Tabla 18: R017 Creación de tickets de soporte mediante la lectura de una bandeja de entrada
de e-mail................................................................................................................................... 37
Tabla 19: R018 Notificaciones automáticas de correo por cambio de estado de los tickets .. 38
Tabla 20: R019 Manejo de listas negras para tickets ingresados por correo .......................... 39
Tabla 21: R020 Archivar tickets después de un periodo de tiempo ....................................... 40
Tabla 22: R021 Envió de encuestas de satisfacción al cierre de un ticket .............................. 40
Tabla 23: R022 Menús y funcionalidades perfil técnico ....................................................... 41
Tabla 24: R023 Menús y funcionalidades perfil gerente ........................................................ 42
Tabla 25: R024 Menús y funcionalidades perfil cliente ......................................................... 43
Tabla 26: R025 Menús y funcionalidades perfil cliente técnico ............................................ 43
Tabla 27: R026 Notificación, interesado ................................................................................ 44
Tabla 28: R027 Configuración de categorías de proyectos .................................................... 45
Tabla 29: R028 Configuración de prioridades ........................................................................ 45
Tabla 30: R029 Configuración de clientes ............................................................................. 46
Tabla 31: R030 Configuración de centro de costo ................................................................. 46
Tabla 32: R031 Configuración general ................................................................................... 47
vi
Tabla 33: R032 Plantillas de correo electrónico configurables .............................................. 47

Tabla 34: R033 Generación de reportes ................................................................................. 48
Tabla 35: R034 Visualización de KPI´s mediante Dashboards .............................................. 49
Tabla 36: Tabla "support.contract" ........................................................................................ 45
Tabla 37: Tabla "support.project" .......................................................................................... 45
Tabla 38: Tabla "website.support.ticket" ............................................................................... 46
Tabla 39: Tabla "res.partner" ................................................................................................. 48
Tabla 40: Tabla "mail.template" ............................................................................................ 50
Tabla 41: Ejecución del sprint 0 ............................................................................................. 52
vii
Lista de ilustraciones
Ilustración 1: Arquitectura de Odoo ....................................................................................... 12
Ilustración 2: MVC Odoo....................................................................................................... 16
Ilustración 3: Herencia en Odoo ............................................................................................ 18
Ilustración 4: Flujograma Planteado ...................................................................................... 51
Ilustración 5: Casos de Uso – Cliente .................................................................................... 52
Ilustración 6: Casos de Uso - Gerente del proyecto ............................................................... 52
Ilustración 7: Registro de Ticket mediante el sistema ........................................................... 53
Ilustración 8: Registro de Ticket mediante email .................................................................. 53
Ilustración 9: Creación del Ticket por parte del usuario ........................................................ 58
Ilustración 10: Respuesta a los Tickets 1 ............................................................................... 59
Ilustración 11: Respuesta a los Tickets 2 ............................................................................... 59
Ilustración 12: Reporte por estado & Tickets Reabiertos ...................................................... 65
Ilustración 13: Reporte por Requerimientos por recurso & Requerimientos Nivel de Recurso
.................................................................................................................................................. 65
Ilustración 14: KPI´s Tiempo Estimado/Real & Tiempo Ejecución ...................................... 65
Ilustración 15: Parámetros de conexión mediante SFTP ....................................................... 67
Ilustración 16: Terminal de Ubuntu ....................................................................................... 68
1
Introducción
Actualmente, debido al nivel de competencia entre organizaciones, es necesario contar con un
punto de apoyo y comunicación entre el proveedor TI y el usuario final.
Primero, en empresas que no tienen un sistema de mesa de ayuda, no tienen control sobre el
servicio al cliente, todo se maneja por correo, mensajes de texto o llamadas. No hay
documentación sobre cuánto tiempo tardan los técnicos en completar una solicitud, entre otras
cosas.
En segundo lugar, las empresas utilizaron el sistema Help Desk, que requería que los clientes
se registraran, iniciaran sesión y una serie de pasos adicionales con el llenado múltiple de
consultas simples, lo que provocó que el cliente no quisiera usar el sistema de ayuda. Estos
sistemas no contienen métricas que ayuden a la empresa a centrar los esfuerzos de mejora en
áreas en las que no está teniendo éxito.
Adicional a esto, dichos sistemas de mesa de ayuda no proporcionar herramientas que ayuden
a la empresa en la toma de decisiones dentro de sus áreas de desarrollo o soporte, lo que
desaprovecha la información que generan este tipo de sistemas, dicho esto sabemos que existen
sistemas para la administración, la ejecución de proyectos, pero no existe un sistema que
integre de manera exitosa ambos conceptos.

2
Capítulo 1
1. Presentación del problema
1.1 Planteamiento del problema
Actualmente, la mayoría de las empresas, organizaciones que trabajan con sistemas
de información o en el área de Tecnología de Información (Tl) brindan a sus clientes, usuarios
una forma de generar una incidencia en línea.
Estos incidentes pueden ir desde problemas pequeños a problemas que lleven días
para su adecuada resolución. Por lo que el usuario requiere ser atendido de la manera más
pronta posible y sin la necesidad de llenar formularios, y registros complejos como lo presentan
los sistemas de registros de incidencias conocidos como GLPI, que son una solución libre de
gestión de servicios de tecnología de la información, donde se requiere un registro de usuario,
al momento de crear la incidencia requiere llenar formularios extensos y en algunos casos
algunos campos son poco entendible si el usuario no está familiarizado con el ámbito de Tl.
Adicionalmente, las empresas que gestionan estos requerimientos necesitan llevar un
control del proceso de atención impartido por los empleados de dichas empresas, para
posteriormente realizar análisis de tiempos de entrega, costos y tiempo efectivo realizado por
estos recursos; lo que influye en toma de decisiones para el desarrollo y mejor manejo de los
procesos internos de estas empresas del área de las tecnologías de la información.
1.2 Objetivos del proyecto
1.2.1 Objetivo general
Desarrollar un sistema para la gestión de proyectos y atención al cliente para una
empresa de TI, el cual permita a dicha empresa optimizar el uso de sus recursos, incrementar
la calidad de los desarrollos y entregables al cliente.

3
1.2.2 Objetivos específicos
Minimizar pérdidas por la necesidad de seguimiento a tareas repetitivas, pérdida de
código fuente y trabajo operativo sin la supervisión necesaria para cumplir con el
aseguramiento de la calidad de este.
Ayudar en la toma de decisiones de el o los jefes de departamentos de desarrollo y
soporte de sistemas, mediante el uso de distintos medidores de rendimiento (KPI) que ayuden
a identificar falencias en el proceso de atención al cliente.
Simplificar el proceso de ingreso de tickets en el sistema para promover que la mayor
cantidad de clientes se apeguen al estándar del uso de dicho sistema y poder centralizar,
monitorear y evaluar la mayor cantidad de problemas que ingresen al departamento de soporte.
Categorizar las tareas realizadas por los empleados, en los distintos proyectos internos
con los que cuente la empresa, para de esta manera hacer un análisis efectivo de los clientes,
productos y/o servicios que ofrezca esta.
1.3 Justificación
Según la experiencia de una empresa del área de TI ubicada en la ciudad de Quito, el
promedio de tiempo extra que se desperdicia al atender cualquier tipo de requerimiento de
soporte de forma manual o con una herramienta ineficiente es de entre 20 minutos y 1 hora por
ticket. Por tanto, es necesario automatizar y optimizar la atención y satisfacción del cliente,
obtener indicadores que permitan a la empresa tomar decisiones que optimicen el uso de sus
recursos (personas) para de la misma manera optimizar la atención al cliente, reduciendo costos
tanto a la empresa como al cliente.

4
Además, es necesario clasificar las tareas que se realizan por parte de los recursos en
distintos proyectos internos de la empresa (Soporte, desarrollos, mantenimiento,
infraestructura, entre otros) para de esta manera dar un seguimiento eficaz a estos proyectos,
además de categorizar y monitorear los distintos productos, clientes y servicios que atiende u
ofrece la empresa en cuestión. Esto la beneficiará, volviéndola competitiva y aumentando las
referencias y/o el alcance de esta.
Como cualquier otro sistema informático transaccional, este generará información
valiosa para la toma de decisiones de la empresa, el presente proyecto tiene planeado abordar
de una manera adecuada esta información mediante el uso de recursos de Inteligencia de
Negocios, pero también, en un futuro, dichos datos podrán ser aprovechados mediante la
adaptación adecuada de un esquema de Big Data, ya que según (Santiago Morales, 2019) “Los
sistemas de inteligencia de negocios tradicionales ofrecen diferentes niveles y tipos de análisis
de datos estructurados, pero hace poco no estaban diseñados para manejar los datos no
estructurados, que es uno de los retos de estas plataformas.”
1.4 Alcance
El sistema deberá incluir las siguientes funcionalidades:

 Control de usuarios con acceso a la aplicación.
 Ingreso y registro de tickets de soporte por parte de requerimientos del cliente.
 Creación de proyectos que estarán enlazados a las distintas tareas que se realicen al
atender un ticket.
 Visualización de KPI’s mediante dashboards.
 Generación de reportes con base en la información del ticket de soporte, persona
encargada y tiempo de resolución.
1.4.1 Perfiles en la aplicación
Se crearán los perfiles necesarios para el uso de la aplicación, los que consideramos serían 3:
5
 Usuarios cliente.
 Usuarios técnicos/ soporte
Estos se podrán clasificar por el puesto (nivel) que se les asigna según las tareas que
cumplan. Por ejemplo: Desarrollador senior, junior, líder de proyectos, jefe de área,
entre otros.
 Usuario administrador de soporte.
1.4.2 Creación de tickets en el sistema
Se podrán ingresar tickets de 2 formas:

 Mediante el ingreso con usuario y contraseña al sistema y creando un nuevo ticket de
forma manual.
 A través del envío de correo electrónico a una cuenta determinada que se configurará
en el sistema.
1.4.3 Gestión de proyectos
Se podrán crear proyectos que permitan a la empresa clasificar las tareas que se
cumplan en base a los tickets recibidos. Esto implica que cada proyecto tenga un grupo de
usuarios (técnicos) los cuales serán los únicos autorizados a trabajar sobre tickets
pertenecientes a dichos proyectos. Por consecuente, se contará con el tiempo trabajado y las
fechas de estos para su posterior uso en un calendario de actividades de cada empleado, y al
proyecto al que estos pertenecen.
1.4.4 Creación de KPI´S
Los KPI´S son los indicadores claves que nos ayudaran a mejorar el negocio.
1. Tiempo estimado vs, tiempo ejecutado.
2. Cantidad de requerimientos atendidos por recursos.
3. Cantidad de requerimientos ejecutados según el nivel de recurso.
4. Requerimientos con tiempos de trabajo altos (Mayor al tiempo estimado).
6
5. Cantidad de tickets reabiertos vs total de tickets.
1.4.5 Gestión de reportes
Estos reportes serán tabulares basándonos en la necesidad de la empresa y que
contendrán información para revisiones periódicas.

7
Capítulo 2
2. Marco teórico
2.1 ERP
Los ERP son sistemas de gestión empresarial diseñados para modelar y automatizar la
mayoría de los procesos empresariales en varios campos. Su función es facilitar la planificación
de todos los recursos de la empresa.
Para Davenport, “Un sistema ERP es un software empresarial que integra toda la
información que circula en una empresa: Información financiera y contable, información sobre
recursos humanos, información sobre la cadena de suministro e información sobre los clientes.”
(Davenport T.H., 1998).
Según Holland y Light, un ERP automatiza las actividades corporativas nucleares, tales
como: fabricación, recursos humanos, finanzas y gestión de la cadena de abastecimiento,
incorporando las mejores prácticas para facilitar la toma de decisiones rápida, la reducción de
costes y el mayor control directivo (Holland & Light 1999).
2.1.1 Beneficios de un ERP
Las empresas reducen costes al aumentar su eficiencia por medio de la estandarización,
la racionalización y la agilidad de los procesos de negocio (Aberdeen GROUP, 2009).
Adicionalmente, la introducción de los sistemas de medición basados en procesos representa
una oportunidad para difundir el potencial de integración latente en los sistemas ERP (Beretta,
2002).
Chand y otros (2005) plantearon un cuadro de mando que utiliza un modelo que divide
los beneficios de la ERP en tres niveles: el nivel "Automatizar" se centra en los beneficios
operativos del sistema; el nivel "Informar" se centra en las decisiones tácticas relativas a los
8
resultados de la implantación; el nivel "Transformar" se centra en el impacto estratégico de la
implantación de la ERP. Según el tamaño de la empresa, la solución elegida y las decisiones
de negocio, el retorno económico del ERP es alcanzado en un plazo de hasta cinco años (Huang
y otros, 2009).
Un sistema ERP es también un modelo de información de una organización, por lo que
hay que tener en cuenta tanto el diseño de la propia organización como el del software. (Esteves
y Pastor, 2000; Gibson y otros, 1999). Por lo tanto, elegir la solución
ERP ideal es fundamental para una implementación exitosa: las personalizaciones del
software pueden comprometer los beneficios de la integración; por esta razón, la mayoría de
las empresas exitosas han cambiado sus procesos comerciales para adaptarse al nuevo
sistema, teniendo en cuenta los cambios y adaptaciones organizacionales. (Soh y otros, 2000;
Injazz, 2001; Somers y Nelson, 2003).
2.1.2 Comparación ERP
Tabla 1: Comparación de ERP
SAP
Oracle - Microsoft
Características Bind ERP Odoo S/4HANA
NetSuite Dynamics
Cloud
Minnt
Solutions
Desarrollador Odoo SA. SAP SE Microsoft
S.A.P.I de
CV
Año inicial de
2013 2005
lanzamiento
Grand
Monterey, Walldorf, Austin, Texas,
Sede principal Rosiere,
México Alemania EE. UU.
Bélgica
Europa,
Oriente Perú,
Países de medio, Colombia,
México + 50 países
operación África, EE. Chile, México,
UU., Argentina.
Canadá,
9
América
Latina,
Caribe,
Asia, Japón.
Base de +8 mil + 5 millones + 440.000 +30.000
Clientes Empresas de usuarios Clientes empresas
Inglés,
alemán, Español,
12 idiomas
Idiomas Frances, Castellano,
Español incluyen
disponibles español, inglés,
español
portugués, portugués
chino
Micro,
pequeñas y Empresas de Medianas Todo tipo de Todo tipo de
Dedicado
medianas gran tamaño Empresas. organizaciones organizaciones
empresas
Integración     
Modularidad     
Finanzas, Finanzas,
Compras,
Compras, Ventas, CRM, Ventas,
Inventarios,
Inventarios, Marketing y Finanzas, Marketing,
Producción,
Producción, Clientes, Compras, Compras,
Fabricación,
Ventas, Compras, Producción y Inventario,
Ventas,
Finanzas, Inventario, cadena de Fabricación y
Ecommerce,
Módulos Contabilidad, Producción suministro, cadena de
Finanzas,
RRHH, y cadena de Inventario, suministro,
Contabilidad,
Nómina, Sitio suministro, CRM, RRHH,
Facturación
Web, Gestión de Proyectos, BI, Proyectos,
Electrónica,
Marketing, Almacén, BI Ecommerce Gestión de
Nómina,
Productividad (Inteligencia Almacén, BI,
Reportes
Empresarial) IA.
Permite
Reportes Interfaz Interfaz Reportes Interfaz
personalización
10
2.2 ODOO
Es un sistema de planificación de recursos empresariales (ERP: Enterprise Resource
Planning) que consta de una variedad de aplicaciones, una para cada necesidad empresarial.
Con el pasar de los años, Odoo se ha vuelto una plataforma de desarrollo con múltiples
enfoques empresariales y funcionales, permitiendo la construcción de un sinfín de aplicaciones
por parte de los usuarios de su comunidad.
2.2.1 Seguridad
2.2.1.1 Modo de encriptación.
En Odoo, las contraseñas de los clientes están protegidas por el estándar de encriptación
PBKDF2+SHA512. Los datos de conexión se transmiten siempre de forma segura a través de
HTTPS.
2.2.1.2 Pbkdf2.
Es una función matemática de derivación de claves que cifra de forma segura las
contraseñas para que puedan ser almacenadas correctamente en las bases de datos de
aplicaciones móviles o web, y forma parte de la serie de Estándares criptográficos de clave
pública (PKCS). Es un algoritmo irreversible que se utiliza para reforzar la seguridad de las
contraseñas de los usuarios que eligen valores demasiado simples como claves secretas de
registro.
Algoritmos como el PBKDF2 están destinados principalmente a proteger a los usuarios
que eligen contraseñas de seguridad media y que tienden a repetirlas en varias cuentas.
11
2.2.1.3 SHA512
SHA-2 (Secure Hash Algorithm 2) es un conjunto de funciones hash criptográficas
desarrolladas por la Agencia de Seguridad Nacional de Estados Unidos (NSA) y publicadas
por primera vez en 2001 para generar hashes o códigos únicos basados en un estándar.
La generación del algoritmo hash funciona únicamente en una dirección, se puede
generar un hash de cualquier contenido o huella digital, pero no hay manera de generar el
contenido original, ya que la única manera conocida es mediante fuerza bruta, que actualmente
tomaría miles de años. SHA512 Tiene un tamaño de salida de 512 bits.
2.2.2 Características
Es un software que controla toda la empresa, evitando que tengamos procedimientos
para todo, como es el caso de un proceso de contabilidad, uno de nómina, otro de facturación,
entre otros.
Nos permite desarrollar programas específicos o módulos propios, ya que es software
libre y está programado en lenguaje de programación Python bajo el sistema de gestión de
base de datos Postgresql.
2.2.3 Arquitectura de ODOO
Es una arquitectura cliente-servidor que permite a todos los usuarios trabajar con el
mismo almacén de datos. Odoo está desarrollado utilizando una arquitectura basada en la web,
por lo que se puede acceder a su plataforma mediante un navegador web y una conexión a
Internet.
12
Ilustración 1: Arquitectura de Odoo
2.2.3.1 ODOO 12
En esta versión, se han agregado varias funciones, en comparación con versiones
anteriores, mejoras de usabilidad en las funciones existentes y mejoras técnicas para mejorar
el rendimiento del servidor y la velocidad de respuesta. Interfaz de usuario.
Las mejoras incluyen mejoras de rendimiento, actualizaciones de la interfaz de
usuario para Bootstrap 4, migración de Less CSS a SCSS y migración de Yml a Python.
2.2.3.2 PostgreSQL
Es un sistema de gestión de base de datos objeto-relacional, distribuido bajo licencia
BSD y su código fuente es OpenSource, utiliza el modelo cliente-servidor y usa multiprocesos
en vez de multihilos para garantizar la estabilidad del sistema, entre sus características se tiene
integridad referencial, base de datos 100% ACID, replicación asincrónica/sincrónica, acceso
encriptado vía SSL, documentación completa entre otras.

13
2.3 Python
Python es un lenguaje de programación de alto nivel, interpretado y de propósito
general. En los últimos años, su uso ha crecido y actualmente es uno de los lenguajes de
programación más utilizados para el desarrollo de software. Es un lenguaje potente y flexible,
con una sintaxis clara y concisa, además es de código abierto y cualquiera puede contribuir a
su desarrollo y distribución.
2.4 Ubuntu 20.0.4 LTS
Es una distribución de Linux. Tiene por eslogan la frase “Linux para seres humanos”.
La palabra Ubuntu tiene origen africano cuyo significado es: “humanidad para otros”.
2.5 Pycharm
Es un entorno de desarrollo integrado (IDE), el cual permite un mejor desarrollo de la
productividad del programador a través de herramientas como análisis de código, depurador
gráfico, entre otras.
2.6 Help Desk
Las situaciones de emergencia técnica pueden resolverse creando un único punto de
contacto, que debe tener en cuenta todas las solicitudes y garantizar su cumplimiento en el
menor tiempo posible, documentando las soluciones para sistematizar la secuencia y frecuencia
de los errores. Estos problemas se denominan mesas de ayuda o departamentos de soporte
técnico. Para Amschler, Beaver y Lucente (2016) el objetivo principal de estas mesas de ayuda
es proporcionar servicios eficientes y oportunos de tecnologías de información a una

14
organización, a través de un sencillo espacio físico, una línea telefónica, una dirección de
correo electrónico o cualquier otro canal de comunicación (More, Stieber y Liu, 2016).
En las empresas u organizaciones es conocido que los usuarios no reciben un buen
servicio por parte del personal de TI, debido a que sus necesidades o solicitudes de soporte
técnico no son atendidas en tiempo y forma. Resulta que la tarea es la misma. No se llevan bien
con las personas adecuadas y los retrasos a menudo se deben a que se olvidan de las tareas de
soporte técnico. Por lo tanto, necesitan una herramienta que pueda mejorar el tiempo de
respuesta y manejar todos estos problemas de manera proactiva.
2.6.1 Módulo de la comunidad Website Help Desk
Para el presente trabajo se utilizó como punto de partida el módulo de la comunidad de
Odoo “Website Help Desk” por Sythil Tech , Adaptive City; el cual nos proveyó de
funcionalidades básicas de un sistema de Help desk, como lo es la lectura de una bandeja de
correo electrónico para la creación de los tickets y un prototipo de formulario para el registro
de tickets. Este módulo tiene una licencia GPLv3, la cual determina lo siguiente:
Cada contribuidor le otorga una licencia de patente no exclusiva, mundial y libre de
regalías que cubre los reclamos materiales de las patentes del contribuidor para crear, usar,
vender, ofrecer para la venta, importar y ejecutar, modificar y distribuir la versión del
contribuidor del contenido de este acuerdo. (gnu.org)

15
2.7 Gestión de Proyectos
La gestión de proyectos se refiere a la consideración de herramientas de estilo de
gestión, y estas herramientas deben estar dirigidas a que una empresa u organización pueda
desarrollar un conjunto de habilidades tanto para individuos como para equipos. El propósito
de realizar esta actividad es planificar, organizar, dirigir y controlar los eventos relacionados
con el proyecto, bajo un escenario predeterminado de tiempo, costo y calidad.
La definición oficial proporcionada por el Instituto de Gestión de Proyectos (PMI,
2013) dice: La gestión de proyecto, entonces, es el uso de los conocimientos, habilidades y
técnicas para ejecutar proyectos de manera eficaz y eficiente. Se trata de una competencia
estratégica para organizaciones, que les permite vincular los resultados de un proyecto con las
metas comerciales para posicionarse mejor en el mercado.
La definición oficial proporcionada por la Asociación para la Gestión de Proyectos
(APM, 2013) dice: La gestión de proyecto se enfoca en controlar la introducción del cambio
deseado. Esto implica:
- Comprender las necesidades de los grupos de interés.
- Planificar qué se necesita hacer, cuándo, por quién y bajo qué estándares.
- Crear y motivar al equipo.
- Coordinar el trabajo de diferentes personas.
- Monitorear el trabajo que se realiza.
- Gestionar cualquier cambio del plan.
- Alcanzar resultados satisfactorios.

16
2.8 MVC en Odoo
Odoo se basa en una arquitectura Modelo-Vista-Controlador (MVC). Uno de los
principales objetivos de esta arquitectura es separar la visualización de la información de las
reglas comerciales y la gestión de los datos subyacentes. MVC no reemplaza los formularios
web. Podemos crear las páginas de nuestro sitio web de Odoo utilizando el marco MVC. Esto
es cierto para mantener la flexibilidad en la visualización de datos. (Zbeanztech).
Ilustración 2: MVC Odoo
En Odoo, podemos aplicar esta semántica modelo-vista-controlador de la siguiente
manera:
Modelo: Las tablas de PostgreSQL, representadas por las herencias de la clase abstracta
“Model”, estas tienen un nombre y un conjunto de atributos que representan los campos y los
tipos de campos que puede tener una tabla en PostgreSQL.
Vista: las vistas se definen en archivos XML.
Controlador: Los objetos, que pueden ser clases Python totalmente independientes del
modelo, o a su vez se pueden representar como el conjunto de métodos y funciones dentro de
la misma clase del Modelo.

17
En la construcción de un sitio web en Odoo, la arquitectura MVC se usa mucho para
enrutar, redirigir las páginas y mostrar datos de la base de datos.
2.9 Herencia
Una característica principal de Odoo es la de agregar características sin modificar
directamente los objetos subyacentes. Esto se logra a través de mecanismos de herencia, que
funcionan como capas para la modificación por encima de los objetos existentes.
2.9.1 Modelo
Odoo dispone de dos mecanismos de herencia para extender un modelo existente de
forma modular.
El primero permite a un módulo modificar el comportamiento de un modelo definido
en otro módulo, este primer mecanismo permite realizar lo siguiente:
 Añadir campos a un modelo,

 Anular la definición de los campos de un modelo,
 Añadir restricciones a un modelo,
 Añadir métodos a un modelo,
 Anular métodos existentes en un modelo.
El segundo, también conocido como delegación, permite vincular cada registro de un
modelo a un registro en un modelo principal y proporciona acceso transparente a los campos
del registro principal.

18
2.9.2 Vista
En lugar de modificar las vistas existentes en el lugar (sobrescribiéndolas), Odoo
proporciona la herencia de vistas donde las vistas "extensión" de los hijos se aplican en la parte
superior de las vistas raíz, y pueden añadir o eliminar el contenido de su padre.
Una vista de extensión hace referencia a su padre usando el campo inherit_id, y en
lugar de una sola vista, su campo arch está compuesto por cualquier número de elementos
xpath que seleccionan y alteran el contenido de su vista padre.
Ilustración 3: Herencia en Odoo

19
2.10 Estado del Arte
En el año 2015, en la Universidad Politécnica Salesiana del Ecuador, durante el proceso
de obtención del título de Ingeniero de Sistemas a cargo de José Luis Ponce Huanca y Michael
Fernando Samanego Castro, se explica cómo configurar e implementar el sistema GLPI.
Donde se mencionan las siguientes desventajas para este tipo de sistema.
 El tiempo de adaptación del usuario al software puede retrasar el uso adecuado

de la herramienta.
 En los casos en que la demora no pueda justificarse, el funcionario podrá imponer
sanciones a su discreción.
En este trabajo no se menciona ninguna forma de integración con el correo
electrónico, para crear problemas directamente por correo electrónico recibido por el usuario.
Además, faltan los KPI y los informes para el sistema de mesa de ayuda.
Si avanzamos en el tiempo nos encontramos con el siguiente trabajo “Implementación
de una aplicación web Help Desk para la Cooperativa de ahorro y crédito Kullki Wasi”
realizada en el año 2017, en la Universidad Técnica de Ambato por Gonzalo Alexander Ruiz.
Donde su objetivo principal fue, desarrollar una aplicación web Help Desk a la medida de las
necesidades de la Cooperativa de Ahorro y Crédito Kullki Wasi agencia matriz como
herramienta para la gestión de solicitudes al Departamento de Sistemas. En este desarrollo se
observan lo siguiente, la aplicación web al ser realizado desde cero, sus funcionalidades son
básicas y cubren de forma básica las funciones de un sistema de Help Desk, por lo cual carece
de reportes y maneras de medir KPI´s, también su única forma de acceso es mediante usuario
y contraseña, por lo tanto, no permite el ingreso de requerimientos por email.
En el año 2020, en la Universitat Oberta de Catalunya, se presentó el tema “Estudio,
análisis, selección e implantación de un Sistema ERP modular en un organismo público” por

20
Ángel David Domínguez Ruso. Donde se realiza un análisis los módulos de un ERP, aquí se
menciona y se realiza un análisis del módulo Help-Desk, pero únicamente centrándose en la
opción de Chat en vivo, para atender requerimientos, entre sus pruebas realizadas se muestra
que este chat en vivo no es óptimo para atender requerimientos o solicitudes, debido a que en
muchas ocasiones se necesita dejar un registro del problema, y en muchos casos para atender
un requerimiento se necesita la asistencia técnica, finalmente aquí no se menciona las
funcionalidades básicas y su capacidad de personalización de módulo.
En el año 2021, en Lima-Perú en la Universidad Privada del Norte se presentó el tema”
SISTEMA HELPDESK BAJO PLATAFORMA WEB PARA LA MEJORA DEL PROCESO
DE SERVICIO TECNICO DE LA EMPRESA DATASUM S.R.L.” por Zosimo Humberto
Vergara Guerrero, aquí se menciona que debido a la alta competitividad de las empresas
globales, para garantizar su éxito, las empresas deben estar siempre en las mejores condiciones,
sin tiempos de inactividad, tratar siempre de diferenciarse de otras empresas, brindar a los
usuarios una alta disponibilidad de recursos informáticos, especialmente en el caso de
ayudarles inmediatamente en caso un incidente.
Aquí se hace evidente que los servicios Help Desk, cada vez son más requeridos y
utilizados, en este trabajo en particular se menciona que la forma de registrar un ticket es de
forma manual cuando llegan por correo electrónico o por llamada telefónica, por lo cual no se
considera una forma de tomar el incidente de un correo y registrarlo automáticamente,
finalmente se hace mención a la creación de reportes en casos de éxito por lo cual este reporte
no permitiría identificar fallas y tomar decisiones en fin de mejorar la atención al cliente.

21
Un trabajo más reciente fue enviado el 25 de febrero de 2022, en la Universidad
Católica de Guayaquil por Ibáñez Mendoza Fidel Xavier, con el tema “Implementación de
servicio help desk o mesa de ayuda para la empresa Machalagps”.
Es claro que, aunque han pasado los años, no todas las empresas dedicadas a TI cuentan
con un sistema de mesa de ayuda, en dicho trabajo el principal problema es:
MachalaGPS no cuenta con un servicio de soporte de herramientas que permita a las
personas reportar fallas en los equipos y luego proceder a arreglar dichos elementos.
Este trabajo detalla las herramientas y cómo implementar el sistema de mesa de ayuda,
pero el sistema carece de integración de correo electrónico, no proporciona KPI y no
proporciona informes relacionados con el negocio.

22
Capítulo 3
3. Metodología
Acogerse a una metodología de trabajo ayuda a los integrantes alinear los objetivos y
propósitos para conseguir una estandarización de los procesos internos como externos. Esto
ayuda también en la optimización de recursos, mejorando así la calidad del trabajo, reduciendo
posibles riesgos que puedan presentarse en el transcurso del proyecto, estableciendo
prioridades y dando soluciones a clientes y proveedores. (Negocios y Estrategia, 2018).
3.1 Metodologías ágiles
Los métodos ágiles son flexibles y pueden modificarse para adaptarse a las realidades
de cada equipo y proyecto.
Los proyectos ágiles se dividen en proyectos más pequeños utilizando una lista
ordenada de funciones. Cada proyecto se maneja de forma independiente y desarrolla un
subconjunto de características en un corto período de tiempo, de dos a seis semanas. Los
proyectos son altamente colaborativos y se adaptan mejor a los cambios. De hecho, los
requisitos cambiantes son una característica esperada y deseable, ya que tanto el producto
como el proceso se mejoran periódicamente.
3.2 Scrum
Es un marco en el cual, los colaboradores de un proyecto pueden resolver problemas
complejos de adaptabilidad de manera efectiva y creativa mientras entregan productos del
mayor valor posible. La estructura de Scrum se basa en ciclos de trabajo llamados Sprints.
Estas repeticiones son de 1 a 4 semanas y se suceden. Se establecen plazos específicos para las
entregas, finalizando en una fecha específica, incluso si el trabajo estaba incompleto y

23
nunca continuó. Scrum demuestra la eficacia relativa de nuestras prácticas de gestión y
desarrollo de productos para que podamos mejorar.
3.2.1 Fases de la metodología Scrum
3.2.1.1 Planificación: Product Backlog
Esta es la etapa en la que se identifican las tareas prioritarias y se obtiene información
breve y detallada sobre el proyecto a desarrollar. Es necesario para poder empezar con el primer
sprint, y se permite cambiar y evolucionar tantas veces como sea posible según lo aprendido
durante el desarrollo del producto.
3.2.1.2 Ejecución: Sprint
Es un periodo de hasta un mes en el que se está desarrollando un producto, también se
lo puede definir como un pequeño proyecto en el que un equipo se centra en desarrollar tareas
para lograr un objetivo establecido.
3.2.1.3 Control: Burn Down
Burn Down es una fase que mide el progreso de un proyecto Scrum.
3.2.2 Perfiles de la metodología Scrum
3.2.2.1 Product Owner
El encargado de aumentar al máximo el valor del producto resultante del esfuerzo en
equipo dentro del marco de Scrum. La manera en la que se lleva a cabo puede variar
ampliamente dependiendo de las organizaciones, equipos Scrum y personas involucradas.

24
3.2.2.2 Scrum Máster
La principal responsabilidad del Scrum Máster es ayudar al equipo a comprender y
seguir la teoría de Scrum.
3.2.2.3 Scrum Team
Es el equipo responsable del desarrollo y la entrega del producto. Su trabajo es
fundamental, este equipo es una estructura horizontal, autoorganizativa y capaz de
autogestionarse.
3.2.3 Beneficios de la metodología Scrum
Se fomenta el espíritu de equipo y todos los esfuerzos se centran en lograr objetivos
comunes, Scrum se basa en la autodisciplina y la autonomía que tiene un impacto positivo en
la entrega del producto.
En términos de comunicación, esta metodología mejora la interacción entre los
miembros del equipo. Además, permite reducir el tiempo de desarrollo de productos, aumentar
la adaptabilidad y la flexibilidad frente a requisitos y entornos cambiantes.

25
Capítulo 4
4. Aplicación de la metodología de desarrollo
4.1 Levantamiento de requerimientos
A continuación, se describe los requerimientos levantados para el desarrollo del
sistema, cada requerimiento tiene su propia tabla donde se describe el requerimiento y el
resultado esperado para ese requerimiento.
Tabla 2:
R01 Acceso al sistema
Código del
R01
requerimiento
Acceso al sistema
Nombre
El sistema deberá poder ser accedido desde cualquier
Descripción navegador web.
Sistema desplegado correctamente sin errores de Javascript
Resultados ni de visualización.
Tabla 3:
R02 Acceso seguro al sistema
Código del
R02
requerimiento
Nombre Acceso seguro al sistema
El sistema deberá proveer de un mecanismo de
Descripción
autenticación.
26
 Solo las personas con un usuario en el sistema

puedan acceder al contenido de este.
 Existirán usuarios invitados o sin cuenta que puedan
Resultados
hacer uso de funciones limitadas a través de un sitio
portal dedicado a ellos.
Tabla 4:
R03 Perfiles de usuarios
Código del
R03
requerimiento
Nombre Perfiles de usuarios
Se requiere de la creación de 5 perfiles de usuarios, cada
Descripción uno de ellos podrá tener acceso a diferentes opciones del

sistema.
 Que los perfiles puedan ser modificados o

configurados cuando se requiera.
 Los perfiles deben manejarse en jerarquías según
corresponda
 Perfil técnico, es un usuario de la empresa que
resuelve los problemas de los clientes, permite
acceder a los menús relacionados con la atención de
tickets o ejecución de tareas.
Resultados
 Perfil gerencial, es un usuario de la empresa cuyas
funcionalidades están orientadas al manejo de la
operación de los técnicos, permite acceder a la
configuración de proyectos y acceder a la
información que requiera, además también podría
reclasificar las tareas.
 Perfil usuario cliente, es un usuario funcional del
cliente que puede ingresar tickets que requerirá de
27
aprobación de un usuario cliente técnico para su

ejecución.
 Perfil cliente técnico, es un usuario del cliente que
se encarga de filtrar o aprobar los requerimientos
ingresados por el usuario cliente.
 Perfil administrador del sistema, es un usuario de la
empresa que tiene acceso a los parámetros de
configuración de todo el sistema.
 Los menús y funcionalidades de cada perfil se
ampliarán en otros requerimientos descritos en este
mismo documento.
Tabla 5:
R04 Portal de invitados
Código del
R04
requerimiento
Nombre Portal de invitados
Se requiere contar con un portal de invitados que tenga las
Descripción
siguientes funciones.
 Ingreso de tickets de soporte mediante formulario

simplificado, que contenga los siguientes campos:
número de identificación (para poder verificar que
el usuario exista dentro del sistema y posteriormente
pueda ingresar el ticket de manera contraria no se le
Resultados dejará enviar la solicitud para la creación del ticket),

nombre (solo lectura), correo electrónico (solo
lectura), proyecto (filtrando únicamente los
proyectos del cliente), asunto, descripción y
adjuntos.
 Acceso a información de un ticket mediante URL.
28
Tabla 6:
R05 Estados de un ticket/tarea
Código del
R05
requerimiento
Nombre Estados de un ticket/tarea
Es la creación de los estados por los que pasa un ticket en
Descripción
un ciclo de vida.
Un ticket/tarea puede cambiar de estados por acciones

manuales o automáticas, todo cambio de estado o cambio
de información debe quedar auditado, los estados son:
 Pendiente (Un requerimiento ingresado, pero no

aprobado).
 Rechazado (Un requerimiento ingresado y que
requería aprobación, pero fue rechazado).
 Ingresado.
 En proceso.
Resultados  Pausado.
 Entregado (proceso técnico terminado, en espera de
la aceptación del cliente, puede requerir hacer tareas
de puesta en pruebas, sesiones de trabajo, pruebas
en conjunto, puesta en producción).
 Terminado.
 Reabierto (Estado determinado por la satisfacción o
no del cliente con el resultado de la atención del
requerimiento).
29
Tabla 7:
R06 Creación de nuevo ticket para tickets en estado Reabierto
Código del
R06
requerimiento
Nombre Creación de nuevo ticket para tickets en estado reabierto.
Cuando un ticket reabierto se identifica como una
funcionalidad o problemática distintas a las del ticket
Descripción original, se debe crear un nuevo ticket basándose en el

motivo de reapertura para reclasificarlo como un nuevo
ticket.
 Se debe añadir un botón que solo sea visible cuando

un ticket ha sido reabierto, este botón cambiará el
estado del ticket a cerrado, y creará un nuevo ticket
con el motivo de la última reapertura para poder
Resultados
reclasificarlo en el proyecto con la categoría
adecuada.
Tabla 8:
R07 Creación de tickets
Código del
R07
requerimiento
Nombre Creación de tickets.
Es la creación de un ticket/tarea que nazca aprobado y
Descripción
vinculado a un proyecto.
Debe existir un formulario donde se especifiquen los

siguientes campos obligatorios:
Resultados  Descripción.
 Prioridad.
 Proyecto.
30
 Solicitante.
Deberán existir otros campos opcionales en el ingreso de un

ticket y serán:
 Adjuntos.
 Asignado a.
 Fecha ofrecida/estimada de culminación.
 Tiempo estimado de resolución.
Tabla 9:
R08 Atención de tickets
Código del
R08
requerimiento
Atención de tickets (Estimarlo, asignarlo, cambiarlo de
Nombre
estado, reabrirlo).
Es el proceso por el cual un usuario de la empresa puede
atender un ticket o ejecutar una tarea. El ticket se deberá
tomar del backlog, asignarse a un técnico, el proceso de la
asignación no cambia de estado, pero debe quedar auditado,
un requerimiento que ya está asignado puede cambiarse de
estado mediante el movimiento en el kanban o con un botón
desde dentro del ticket/tarea, lo cual cambia el estado a “En
proceso” y será obligatorio ingresar una fecha estimada de
Descripción
culminación. Una vez que el ticket este en proceso, el
técnico deberá estar trabajando en solucionarlo, el
requerimiento puede pausarse si se requiere, pero se deberá
requerir ingresar el motivo de la pausa y opcionalmente
solicitar el worklog ejecutado en ese intervalo de tiempo. Y
cuando se reanude el requerimiento cambiará, ha estado en
proceso nuevamente. Al terminar la atención del cliente, se
debe cambiar a “por entregar”, donde él automáticamente
31
se registrará la fecha real de culminación, solicitará al

técnico si desea llenar en ese momento el worklog y en
donde se espera a que el cliente reciba satisfactoriamente el
resultado de la atención y con su confirmación se cambia a
estado terminado donde se registra automáticamente la
fecha real de entrega y se solicita el worklog al técnico y el
ingreso de la encuesta de satisfacción la misma que puede
ser accedida por el usuario cliente/técnico cliente en otro
momento.
 Un ticket “terminado” siempre debe tener fecha de

entrega.
 Un ticket “por entregar” siempre debe tener fecha
de culminación.
 Un ticket pausado siempre debe tener un motivo de
pausa.
 Auditoria registradas y visibles en el ticket. Todo
cambio de estado tener auditar el estado anterior, el
nuevo, la fecha y hora del cambio y el usuario que
Resultados
realizo el cambio.
 Un ticket terminado puede ser calificado por el
cliente en cualquier momento.
 Un ticket ya calificado no puede cambiar su
calificación.
 Un ticket reabierto debe tener la razón de la
reapertura.
Tabla 10:
R09 Visualizar información de contacto y de infraestructura del cliente
Código del
R09
requerimiento
32
Visualizar información de contacto y de infraestructura del

Nombre
cliente.
Rol Técnico, gerente.
Descripción Se requiere visualizar la información de un cliente.
 Lista de clientes desplegada por una opción de

menú del sistema.
 Por cada cliente un formulario que contenga
información como: nombres y apellidos, empresa a
la que pertenece, número de contacto, información
Resultados de infraestructura (URL del sistema, usuarios y

contraseñas de bases de datos, dirección IP de
infraestructura propia, credenciales de VPN).
 Lista y número de tickets creados/solicitados por el
cliente dentro del formulario.
Tabla 11:
R010 Registrar tiempo de trabajo en tickets/tareas
Código del
R010
requerimiento
Nombre Registrar tiempo de trabajado en tickets/tareas.
El sistema deberá permitir a los usuarios técnicos registrar
los tiempos de trabajo realizados sobre los tickets/tareas, de
Descripción
manera específica y también de una manera genérica para
minimizar el tiempo que se usa en hacer esta acción.
 Registro de fecha, tiempo, y descripción del trabajo

dentro de un ticket/tarea.
 Al cambiar el ticket a estado pausado, o por
Resultados entregar, se debe desplegar un pop up que sugiera
que se llene el tiempo trabajado de manera opcional,
ya que puede hacerlo en cualquier momento
posterior o anterior.
33
 Debe existir una opción de ingreso “rápido” de

tiempos directamente a un ticket de un proyecto, el
sistema puede crear un ticket/tarea si no existe uno
seleccionado.
Tabla 12:
R011 Pantalla de worksheet
Código del
R011
requerimiento
Nombre Pantalla de worksheet
Rol Técnico, Gerente
El sistema deberá incluir una pantalla de tipo calendario

Descripción
para visualizar los tiempos de trabajo por días.
 Pantalla estilo calendario que muestre todos los

registros de worklogs para el usuario autenticado,
donde se pueda navegar por día, semana o mes.
Resultados  Al dar clic en la pantalla se debe permitir crear un

registro de worklog de manera rápida (definido en
otro requerimiento).
Tabla 13:
R012 Administración de contratos
Código del
R012
requerimiento
Nombre Administración de contratos.
Rol Gerente
34
El sistema deberá permitir crear, modificar y visualizar
Descripción información de contratos de los distintos clientes de la

empresa.
 Lista de contratos desplegada por una opción de

menú del sistema.
 Por cada contrato, un formulario que contenga la
siguiente información: cliente, fecha de inicio,
Resultados
fecha de fin, listado de proyectos pertenecientes al
contrato.
 En la pantalla de listado se debe poder realizar
búsquedas por los campos principales del contrato.
Tabla 14:
R013 Administración de proyectos
Código del
R013
requerimiento
Nombre Administración de proyectos.
Rol Gerente
El sistema deberá permitir crear, modificar y visualizar
Descripción información de proyectos de los distintos contratos

registrados en el sistema con anterioridad.
 Lista de proyectos desplegada por una opción de

menú del sistema.
 Por cada proyecto, un formulario que contenga la
siguiente información: Nombre del proyecto,
Cliente, categoría del proyecto, fecha de inicio,
Resultados
fecha de fin (si es que el proyecto es medible),
Productos/Tecnologías relacionadas con el
proyecto, centro de costos.
 En la pantalla de listado se debe poder realizar
búsquedas por Clientes, productos/tecnologías,
35
categoría del proyecto, agrupar registros por

clientes, productos o categorías.
 En la lista de proyectos poner información útil como
por ejemplo fecha creación, fecha de fin estimado,
porcentaje de avance real, porcentaje de avance
estimado.
Tabla 15:
R014 Visualización de tickets de soporte
Código del
R014
requerimiento
Nombre Visualización de tickets de soporte
Rol Técnico, Gerente
Es necesario visualizar de manera ágil, organizada y óptima

Descripción
los tickets de tipo soporte ingresados en el sistema.
 Lista de tickets de soporte desplegada por una

opción de menú del sistema. Esta lista se debe
mostrar por defecto con un filtro los tickets que no
se han atendido, también debe ser posible retirar
este filtro y visualizar todos los tickets (atendidos,
no atendidos, rechazados, etc.).
 Pantalla tipo kanban para la visualización
organizada y agrupada por estado de los tickets. Las
Resultados
tarjetas de los kanban deben mostrar el asunto del
ticket, el proyecto al que pertenece, el solicitante y
la fecha de ingreso del ticket. Las columnas en las
que están organizadas las tarjetas del kanban deben
ser los estados anteriormente mencionados del
ticket. También debe ser posible cambiar de estado
los tickets arrastrando las tarjetas que representan a
estos.
36
 Pantalla de formulario, en la cabecera debe ir, como

título, el asunto del ticket, como subtítulo, el
número de ticket, en el cuerpo de la cabecera: la
prioridad, el proyecto, el usuario asignado y el
solicitante. En la parte inferior en una pestaña la
descripción, en otra el resto de información
detallada en el requerimiento de creación de tickets,
en otra pestaña los adjuntos, worklogs y registros de
estado.
 Deben existir controles para cada cambio de estado
cuando se arrastra un ticket hacia un nuevo estado.
Tabla 16:
R015 Visualización de tareas de desarrollo
Código del
R015
requerimiento
Nombre Visualización de tareas de desarrollo.
Rol Técnico, Gerente.
Es necesario visualizar de manera similar a los tickets de
Descripción soporte las tareas creadas para proyectos medibles

(Desarrollos).
 Lista de tareas de proyectos desplegada por una

opción de menú del sistema. Esta lista se debe
mostrar por defecto los tickets pertenecientes a
proyectos activos o en curso.
 Pantalla tipo kanban para la visualización
Resultados
organizada y agrupada por estado de las tareas de
los proyectos. Las tarjetas de los kanban deben
mostrar el asunto del ticket, el proyecto al que
pertenece, el solicitante y la fecha de ingreso del
ticket, adicional los estados de estos serán distintos
37
a los estados de un ticket de soporte. También debe

ser posible cambiar de estado los tickets arrastrando
las tarjetas que representan a estos.
 Deben existir controles para cada cambio de estado
cuando se arrastra una tarea hacia un nuevo estado.
Tabla 17:
R016 Creación automática de proyectos por contrato creado
Código del
R016
requerimiento
Creación automática de proyectos por contrato creado
Nombre
(Soporte, mantenimiento, garantía, etc.).
Rol Gerente.
Se espera que el sistema cree automáticamente ciertos

proyectos predeterminados con la creación de un contrato
Descripción
de un cliente que a su vez contiene un producto/tecnología
relacionada.
 Al crear un nuevo contrato de un determinado o

determinados productos, se deberán crear sus
respectivos proyectos por defecto relacionados con
el cliente, de la siguiente manera: SOPORTE-
Resultados
PRODUCTO X-CLIENTE Y, MANTENIMIENTO-
PRODUCTO X-CLIENTE Y, GARANTÍA-
PRODUCTO X-CLIENTE Y, DESARROLLO
FACTURADO-PRODUCTO X-CLIENTE Y.
Tabla 18:
R017 Creación de tickets de soporte mediante la lectura de una bandeja de entrada de e-mail
Código del
R017
requerimiento
38
Creación de tickets de soporte mediante la lectura de una

Nombre
bandeja de entrada de correo electrónico.
Rol Automático
El sistema deberá leer una bandeja de correo de una
Descripción dirección determinada y configurable para la creación de

nuevos tickets.
 Cada correo leído deberá ser procesado y

transformado en un nuevo ingreso de ticket de
soporte al sistema, el cual deberá extraer de dicho
correo, el cuerpo del correo, el asunto, el remitente,
y el nombre del sujeto del correo, para
posteriormente utilizar dicha información básica
para crear el nuevo ticket.
 Si es que el correo del remitente se encuentra ya
registrado en el sistema, este deberá auto llenar
información del ticket basándose en la ficha del
Resultados
cliente encontrado por dirección de correo.
 Si el correo del remitente no se encuentra registrado
en la ficha de un cliente, el ticket quedará en estado
“en espera” y permanecerá en dicho estado hasta la
aprobación manual de algún usuario con dicho
permiso para hacerlo.
 Las respuestas de correos que ya tienen un ticket
deben añadirse como comentarios del ticket ya
creado.
Tabla 19:
R018 Notificaciones automáticas de correo por cambio de estado de los tickets
Código del
R018
requerimiento
39
Notificaciones automáticas de correo por cambio de

Nombre
estado de los tickets.
Rol Automático
El sistema deberá enviar mensajes por correo electrónico al

cliente al suceder determinados cambios de estado de un
Descripción ticket de soporte solicitado por este.
 El sistema debe permitir configurar los estados se

necesitan enviar una notificación por correo
electrónico al cliente, por ejemplo, cuando un ticket
ya ha sido asignado a un recurso o cuando el ticket
ya fue cerrado por el técnico.
 Es necesario tener una pantalla de configuración de
Resultados estados, el cual se pueda indicar si el estado necesita
notificación mediante un check, y una plantilla de
correo electrónico con el mensaje a enviar al cliente
por el cambio a dicho estado.
 Cada vez que el usuario asignado de un ticket
cambie se debe notificar al cliente.
Tabla 20:
R019 Manejo de listas negras para tickets ingresados por correo
Código del
R019
requerimiento
Nombre Manejo de listas negras para tickets ingresados por correo.
Rol Automático
El sistema deberá controlar el ingreso de correo basura
Descripción hacia la bandeja de entrada configurada para la lectura de

tickets.
40
 El sistema tendrá que llevar un registro de los

correos que no están registrados en fichas de
clientes.
 Por cada registro en la lista de correos se debe
desplegar un formulario con: la dirección de correo
Resultados
electrónico, un check que indica si está activo o no,
y un campo de texto para ingresar un comentario
relacionado con la activación o desactivación de
este.
Tabla 21:
R020 Archivar tickets después de un periodo de tiempo
Código del
R020
requerimiento
Nombre Archivar tickets después de un periodo de tiempo
Rol Automático
Eliminar los tickets que están en estado “Pendiente”

Descripción
después de un periodo de tiempo configurable en el sistema.
 Opción de configuración para determinar el tiempo

que debe haber pasado para borrar tickets en estado
“Pendiente”
Resultados  El sistema deberá eliminar automáticamente estos
tickets mediante una tarea calendarizada que se
ejecute diariamente.
Tabla 22:
R021 Envió de encuestas de satisfacción al cierre de un ticket
Código del
R021
requerimiento
41
Nombre Envío de encuestas de satisfacción al cierre de un ticket
Rol Automático
Eliminar los tickets que están en estado “Pendiente”

Descripción
después de un periodo de tiempo configurable en el sistema.
 Página web única por ticket que permita al cliente

dar una calificación del servicio brindado y un
comentario opcional sobre el mismo.
Resultados  El ingreso y envío de dicha encuesta deberá cambiar
el estado del ticket y actualizar la calificación del
cliente.
Tabla 23:
R022 Menús y funcionalidades perfil técnico
Código del
R022
requerimiento
Nombre Menús y funcionalidades perfil técnico.
Rol Técnico
Es necesario que los usuarios técnicos accedan de manera
Descripción ágil y simple a las funciones necesarias para la atención de

tickets y el ingreso de tiempos de trabajo sobre las tareas.
 Acceso únicamente a las siguientes opciones del

sistema: Visualización de tickets de soporte,
visualización de tareas de proyectos medibles,
calendario para visualizar tiempos de trabajo por
Resultados días, pantalla de ingreso de tiempos de trabajo.
 El usuario técnico puede buscar tickets por distintos
parámetros, modificar información, cambiar
estados, enviar encuestas de satisfacción de los
tickets, ver sus propios tiempos de trabajo en la vista
42
de calendario, añadir tiempos de trabajo por ticket o

por proyecto.
Tabla 24:
R023 Menús y funcionalidades perfil gerente
Código del
R023
requerimiento
Nombre Menús y funcionalidades Perfil gerente
Rol Gerente
Es necesario que los usuarios gerentes, además de poder

acceder a la información de los tickets, puedan visualizar la
Descripción
información de proyectos, contratos y ciertos parámetros de
configuración del sistema.
 Acceso para visualizar, crear y modificar tickets,

proyectos y contratos, además de acceder a
opciones de configuración como lo son: Centros de
costo y categorías.
 El usuario gerente debe tener las mismas
capacidades en cuanto a la modificación y ciclo de
vida de los tickets que el técnico, además de poder
asignar a cualquier recurso técnico dentro de un
Resultados ticket.
 El usuario gerente debe poder generar reportes
basándose en la información de tickets y proyectos
(los cuales se detallarán en un siguiente
requerimiento).
 También podrá acceder al panel de visualización de
dashboards de KPI’S (de igual manera se detallarán
en un siguiente requerimiento).
43
Tabla 25:
R024 Menús y funcionalidades perfil cliente
Código del
R024
requerimiento
Nombre Menús y funcionalidades perfil cliente
Rol Cliente
Es necesario que los usuarios cliente puedan ingresar
Descripción nuevos tickets y puedan visualizar en qué estado se

encuentran sus tickets ingresados anteriormente.
 El usuario cliente debe poder ingresar la

información únicamente necesaria para la atención
de su requerimiento, como lo es: asunto,
descripción, proyecto (únicamente de los proyectos
de la empresa cliente), prioridad y adjuntos. Este
ticket se ingresa en un estado de “en espera” para
Resultados que posteriormente el usuario cliente técnico pueda
aprobar el ingreso de dicho ticket.
 El usuario cliente podrá visualizar de manera de
lista o en la vista tipo kanban todos los tickets
ingresados por el usuario con el que está
autenticado.
Tabla 26: R025
Menús y funcionalidades perfil cliente técnico
Código del
R025
requerimiento
Nombre Menús y funcionalidades perfil cliente técnico.
Rol Cliente técnico

44
Es necesario que los usuarios de tipo cliente técnico tengan
Descripción las mismas capacidades que el perfil cliente y otras

funcionalidades extras.
 El usuario cliente técnico, además de poder realizar

todas las acciones que un usuario cliente puede
hacer, debe poder aprobar los tickets de los usuarios
cliente de su empresa.
Resultados
 El usuario cliente técnico puede generar un reporte
de horas de trabajo empleadas en sus tickets dentro
de un periodo de tiempo.
Tabla 27:
R026 Notificación, interesado
Código del
R026
requerimiento
Nombre Notificación, interesado.
Rol Cliente técnico.
Toda acción realizada sobre un ticket debe notificarse a un

Descripción
contacto configurable por cada cliente (empresa).
Se debe poder configurar un contacto interesado para

notificaciones por cliente (empresa).
Para todo cambio de estado que tenga configurado una
Resultados acción de notificación, se debe notificar al usuario que
ingresó el ticket y adicionalmente al contacto configurado
en la empresa cliente.
45
Tabla 28:
R027 Configuración de categorías de proyectos
Código del
R027
requerimiento
Nombre Configuración de categorías de proyectos.
Rol Administrador
Visualización, creación y modificación de categorías de los

Descripción
proyectos.
Opción de menú que despliegue la lista de categorías de

proyectos, cada registro al hacer clic debe mostrar un
Resultados
formulario con la siguiente información: Nombre, Tipo
(medible o no medible).
Tabla 29:
R028 Configuración de prioridades
Código del
R028
requerimiento
Nombre Configuración de prioridades.
Rol Administrador
Visualización, creación y modificación de prioridades de

Descripción
los tickets.

proyectos, cada registro al hacer clic podremos editar el
nombre de la prioridad, no se debe abrir un formulario para
Resultados agilizar el uso de esta opción de menú que solo contiene un
campo.
46
Tabla 30:
R029 Configuración de clientes
Código del
R029
requerimiento
Nombre Configuración de clientes.
Rol Administrador, gerente
Descripción Visualización, creación y modificación de clientes.

proyectos, cada registro al hacer clic debe mostrar un
formulario con la siguiente información: nombre, si es
Resultados individual o empresa, identificación, teléfono, móvil,
correo electrónico, indicador si está activo.
Tabla 31:
R030 Configuración de centro de costo
Código del
R030
requerimiento
Nombre Configuración de centros de costo
Rol Administrador, gerente
Visualización, creación y modificación de centros de costo

Descripción
de los proyectos.
Opción de menú que despliegue la lista de centros de costo

de los proyectos, cada registro al hacer clic podremos editar
Resultados el nombre del centro de costo, no se debe abrir un
formulario para agilizar el uso de esta opción de menú que
solo contiene un campo.
47
Tabla 32:
R031 Configuración general
Código del
R031
requerimiento
Nombre Configuración general
Rol Administrador
Visualización y modificación de parámetros varios del

Descripción
sistema.
Opción de menú que despliegue un formulario que

contenga parámetros del sistema configurables, estos son:
Máximo de adjuntos para el portal sin autenticación,
tamaño máximo de archivo para el portal sin autenticación,
Resultados
plantilla del correo electrónico para el cambio de
asignación de recurso técnico en el ticket, prioridad por
defecto para el portal sin autenticación.
Tabla 33:
R032 Plantillas de correo electrónico configurables
Código del
R032
requerimiento
Nombre Plantillas de correo electrónico configurables.
Rol Gerente
Se requerirá poder crear y modificar las plantillas de los
Descripción correos electrónicos usadas por el sistema para el envío de

notificaciones.
Lista y formulario de estados, dentro del formulario se debe

Resultados permitir indicar si el estado se notifica o no, y además
configurar la plantilla para la notificación.
48
Tabla 34:
R033 Generación de reportes
Código del
R033
requerimiento
Nombre Generación de reportes.
Rol Gerente
El sistema debe permitir generar reportes en excel para el

análisis de la información de los tickets y las tareas de
Descripción
proyecto desde diferentes perspectivas para generar valor
agregado a los datos.
Reporte 1 Cantidad de requerimientos atendidos por

recursos en un rango de fechas.
Reporte 2 Cantidad de tareas por nivel del recurso que la
atendió en un rango de fechas.
Reporte 3 Cantidad de tickets reabiertos (que el trabajo
entregado al cliente no es el esperado) vs total de tickets en
un periodo de tiempo.
Reporte 4 Cantidad de tickets con tiempos de ejecución
altos (requerimientos con tiempos de trabajo altos, es decir,
Resultados mayor al tiempo estimado) vs el total de tickets en un rango
de fechas.
Reporte 5 Tiempo estimado vs. tiempo ejecutado, se debe
permitir el ingreso de una fecha de inicio y una fecha de fin,
columnas: Nombre del recurso, nivel, Número de ticket +
descripción, tiempo estimado, tiempo real o ejecutado.
49
Tabla 35:
R034 Visualización de KPI´s mediante Dashboards
Código del
R034
requerimiento
Nombre Visualización de KPI’s mediante Dashboards
Rol Gerente
El sistema debe permitir visualizar dashboards que
Descripción permitan de primer vistazo analizar la situación actual de

los proyectos.
Opción del sistema que despliegue la misma cantidad de

gráficos (barras, pastel, líneas) que de reportes planteados
Resultados
en el requerimiento 33.
4.1.1 Resumen de roles y funciones
4.1.1.1 Cliente
Las funciones del cliente son:

 Registrar un requerimiento o incidencia desde la plataforma web.
 Registrar el nivel de urgencia del requerimiento o solicitud.
 Solicitar un requerimiento o incidencia mediante correo electrónico, dirigido a un email
en específico.
 Atender oportunamente a las notificadas enviadas a su correo electrónico o perfil
personal, inicio de solicitud, seguimiento de solicitud, cierre de solicitud
 Hacer buen eso de las funcionalidades para evitar repetición de tickets o spam en caso
de usar correo electrónico.
4.1.1.2 Técnicos/Soporte
Las funciones del personal Técnico/Soporte son:

 Atender a los requerimientos o incidencias enviadas por los clientes.
50
 Seleccionar los tickets a los cual va a dar seguimiento según su dificultad y grado de
experiencia (Desarrollador Senior, Junior; Líder de proyectos, jefe de área, entre otros).
 Asignar los tiempos aproximados en el cual el ticket será resuelto.
 Enviar notificaciones cuando el ticket sea resuelto.
 Notificar al administrador cuando el ticket no se pudo resolver, para ser reasignado a
otra personal con mayor experiencia.
4.1.1.3 Gerente de proyectos
Las funciones de los gerentes de proyecto son:

 Permitir la comunicación efectiva entre clientes y personal.
 Creación y asignación de contratos y proyectos en los que el personal va a trabajar.
 Uso efectivo de los reportes y dashboards a desarrollar.
4.1.2 Funcionalidades
4.1.2.1 E-Mail
El sistema Help Desk permitirá la integración con el correo electrónico, permitiendo
una forma diferente de ingresar o solicitar un requerimiento a una empresa de TI.
4.1.2.2 KPI´s
El sistema contará con los siguientes indicadores
 Tiempo estimado vs tiempo ejecutado.

 Cantidad de requerimientos atendidos por recursos.
 Cantidad de requerimientos ejecutados según el nivel de recurso.
 Requerimientos con tiempos de trabajo altos (Mayor al tiempo estimado).
 Cantidad de tickets reabiertos vs total de tickets.
51
4.1.3 Flujograma
El siguiente flujograma representa a nivel macro, el flujo que sigue el ingreso de un
requerimiento o solicitud de un usuario. El requerimiento puede pasar por un solo nivel de
soporte o pasar por los tres niveles hasta que sea solucionado.
Ilustración 4: Flujograma Planteado

52
4.2 Casos de uso

Caso de uso para la creación de una incidencia o requerimiento por parte del cliente.
Ilustración 5: Casos de Uso – Cliente
Caso de uso de la administración del gerente del proyecto dentro del sistema.
Ilustración 6: Casos de Uso - Gerente del proyecto

53
4.3 Diagrama de procesos

Proceso A
El diagrama que se muestra a continuación describe como se atiende un ticket por parte
del personal de Soporte, cuando un Ticket es ingresado por un cliente mediante la aplicación
web.
Ilustración 7: Registro de Ticket mediante el sistema
Proceso B
El diagrama que se muestra a continuación describe como se atiende un ticket por parte
del personal de Soporte, cuando un Ticket es ingresado por un cliente mediante él envió de un
correo electrónico.
Ilustración 8: Registro de Ticket mediante email

44
4.4 Modelo entidad relación

45
4.5 Diccionario de datos

A continuación, se describen las tablas principales del modelo entidad relación, en un
diccionario de datos donde se presenta el nombre del campo, el tipo de dato, la longitud y una
descripción, donde se detalla valores por defecto y la relación (FK) de los campos con las
demás tablas.
Tabla 36:
Tabla "support.contract"
Campo Tipo de Dato Tamaño Descripción

id INT Identificación de la tabla support.contract.
name VARCHAR 45 Descripción del contrato.
Estado del contrato, se establece por defecto
state VARCHAR 45 los siguientes estados: "nuevo", "en proceso",
"terminado".
value FLOAT 45 Valor del contrato.
date_start DATE Fecha de inicio del contrato.
date_end DATE Fecha de finalización del contrato.
Relación many2one con la tabla res.partner, se
partner_id INT
lo identificará como un campo cliente.
Tabla 37:
Tabla "support.project"

id INT Identificación de la tabla support.project.
name VARCHAR 45 Nombre del proyecto.
Estado del proyecto, se establece por
state VARCHAR 45 defecto los siguientes estados: "nuevo", "en
proceso", "terminado".
date_start DATE Fecha de Inicio del proyecto.
date_end DATE Fecha de finalización del proyecto.
type VARCHAR 45 Categoría del proyecto.
46
Relación many2one con la tabla

contract_id INT support.contract, este campo se lo
identificará como contrato.
cost_center INT support.cost.center, este campo se lo
identificará como centro de costes.
Relación many2many con la tabla
support_product_ids INT support.product, este campo se lo
identificará como productos.
website.support.ticket.category, este campo
project_category_id INT
se lo identificará como categoría del
proyecto.
Tabla 38:
Tabla "website.support.ticket"

Identificación de la tabla
id INT
website.support.ticket.
channel VARCHAR 45 Canal.
person_name VARCHAR 45 Nombre de la persona.
email VARCHAR 45 Email.
support_email VARCHAR 45 Email de soporte.
subject VARCHAR 45 Asunto.
description VARCHAR 45 Descripción.
name VARCHAR 45 Ticket.
Campo para definir un ticket reabierto
re_opened CHAR 1
(False or True).
portal_access_key CHAR 1 Clave de acceso al portal.
ticket_number VARCHAR 45 Número de ticket.
ticket_color VARCHAR 45 Color del ticket.
support_rating INT Calificación del soporte.
47
support_comment TEXT 100 Comentario del soporte.

close_comment TEXT 100 Comentario de cierre.
close_time DATETIME Tiempo de cierre.
close_date DATE Fecha de cierre.
time_to_close INT Tiempo de cierre en segundos.
planned_time DATETIME Tiempo previsto.
approval_message TEXT 100 Mensaje de aprobación.
estimated_time FLOAT 100 Tiempo de trabajo estimado.
estimated_close_time DATETIME Hora estimada de cierre.
project_type VARCHAR 45 Tipo de proyecto.
Relación Many2one con la tabla
state_id INT website.support.ticket.state , este campo
se lo identificará como estado.
category_id INT website.support.ticket.state , este campo
se lo identificará como estado.
website.support.ticket.subcategory , este
sub_category_id INT
campo se lo identificará como
subcategoría.
website.support.ticket.approval , este
approval_id INT
campo se lo identificará como
aprobación.
project_Id INT support.project, este campo se lo
identificará como proyecto.
priority_id INT website.support.ticket.priority, este
campo se lo identificará como prioridad.
tag_ids INT website.support.ticket.tag, este campo se
lo identificará como etiquetas.
48

proj_state_id INT website.project.task.sate, este campo se
lo identificará como estado.
partner_id INT res.partner, este campo se lo identificará
como colaborador.
company_id INT res.company, este campo se lo
identificará como empresa/compañía.
Relación Many2one con la tabla
user_id INT res.users, este campo se lo identificará
como usuario asignado.
Relación many2one con la tabla res.users,
closed_by_id INT este campo se lo identificará como
cerrado por.
Relación many2one con la tabla res.users,
create_user_id INT este campo se lo identificará como crear
usuario.
Tabla 39:
Tabla "res.partner"

id INT Identificación de la tabla res.partner.
name VARCHAR 45 Nombre.
date DATE Fecha.
parent_name VARCHAR 45 Nombre del colaborador.
ref VARCHAR 45 Referencia interna.
Idioma, todos los correos electrónicos y
language VARCHAR 45 documentos enviados a este contacto se
traducirán a este idioma.
timezone TIME Zona horaria.
active CHAR 1 Campo para establecer false or true.
49
Campo para establecer si es un cliente (Flase

customer CHAR 1
or True), se define True por defecto.
Campo para establecer si es un vendedor
supplier CHAR 1
(False or True).
Campo para establecer si un contacto es un
employee CHAR 1
empleado (False or True).
type VARCHAR 45 Tipo de colaborador.
street VARCHAR 45 Dirección principal.
street 2 VARCHAR 45 Dirección secundaria.
zip VARCHAR 45
city VARCHAR 45 Ciudad.
email VARCHAR 45 Email.
phone VARCHAR 45 Teléfono.
mobile VARCHAR 45 Teléfono celular.
Campo para definir si se trata de una compañía
is_company CHAR 1
(False or True).
company_name VARCHAR 45 Nombre de la empresa/compañía.
title INT res.partner.title, este campo se lo identificará
como título.
category_id INT res.partner.category, este campo se lo
identificará como categoría
Relación many2one con la tabla res.users, este
user_id INT
campo se lo identificará como vendedor.
company_id INT “res.company”, este campo se lo identificará
como compañía.
Relación Many2one con la tabla res.partner,
parent_id INT este campo se lo identificará como empresa
relacionada.
50
Tabla 40:
Tabla "mail.template"

id INT Identificación de la tabla mail.template.
name VARCHAR 45 Nombre.
model VARCHAR 45 Modelo de documento relacionado.
Idioma de traducción opcional (código ISO)
lang VARCHAR 45
para seleccionar al enviar un correo electrónico.
La firma del usuario se añadirá a la versión de
user_signature CHAR 1
texto del mensaje (Flase or True).
Dirección del remitente, si no se establece, el
valor predeterminado será el alias de correo
email_from VARCHAR 45
electrónico del autor, si está configurado, o la
dirección de correo electrónico.
Destinatarios predeterminados del registro socio
use_default_to CHAR 1 o correo electrónico (mediante el campo
email_from o email) (False or True).
Direcciones de destinatarios separadas por
email_to VARCHAR 45 comas (pueden utilizarse marcadores de
posición).
Id. separados por comas de los socios
partner_to VARCHAR 45 destinatarios (pueden utilizarse marcadores de
posición).
Destinatarios de la copia (pueden utilizarse
email_cc VARCHAR 45
marcadores de posición).
Dirección de respuesta preferida (pueden
reply_to VARCHAR 45
utilizarse marcadores de posición).
body_html TEXT 100 Cuerpo.
Nombre que se utilizará para el archivo de
report_name VARCHAR 45
informe generado.
auto_delete CHAR 1 Borrado automático (False or True)
51
Valor opcional que se utilizará si el campo de

null_value VARCHAR 45
destino está vacío.
Expresión de marcador de posición final, que se
copyvalue VARCHAR 45 copiará y pegará en el campo de plantilla
deseado.
scheduled_date VARCHAR 45 Fecha programada.
Relación many2one con la tabla ir.mode, el
sub_object INT
campo se identificará como sub-model.
Tipo de documento con el que se puede utilizar
model_id INT
esta plantilla.
4.6 Sprint 0
En el siguiente Sprint se describe las tareas iniciales para levantar el ambiente de
desarrollo, además de la elaboración del modelo entidad relación, con la finalidad de que al
final del sprint se pueda interactuar entre el ambiente de Odoo y la base de datos y realizar
consultas básicas.
4.6.1 Planificación del sprint
La duración final del sprint fue de 23 días, trabajando 4 horas al día de lunes a viernes,
teniendo un total de 92 horas aproximadamente.
Se definió como objetivo principal es iniciar con la configuración e instalación de
requerimientos para el levantamiento del entorno de desarrollo, concluyendo con el diseño e
implementación de diagrama ER de la Base de Datos.
- Instalación de Ubuntu.
- Instalación de IDE Pycharm y PostgreSQL 10.
- Configuración de accesos y permisos de la base de datos e instalación y configuración
de PGAdmin.
- Instalación de requerimientos Python.
- Levantamiento y Configuración de Odoo 12
52
- Elaboración del modelo ER
4.6.2 Ejecución del sprint
Tabla 41:
Ejecución del sprint 0
ID Fecha Tarea Realizada Descripción Dificultades

Descarga e instalación de
VirtualBox/Vmware.
Descarga e Instalación de la
01/08/2022- Instalación de Iso de Ubuntu 20.0.4.
1
01/08/2022 requerimientos Descarga e Instalación de
Pycharm.
Instalación de PostgreSQL
10.
Ciertas librerías
Actualización de Python 3. de necesarias
Configuración y deben tener una
02/08/2022-
2 levantamiento de Instalación de las librerías y versión en
02/08/2022
Odoo 12 paquetes necesarias para el específico para
Levantamiento de Odoo. evitar
problemas.
Configuración de un
Administrador para la Base
Configuración de de Datos.
03/08/2022- PostgreSQL e Instalación de PgAdmin.
3
03/08/2022 instalación de Configuración de Puertos y
PGADMIN permisos necesarios para la
comunicación entre la base
de datos y Odoo.
53
Instalación y
04/08/2022-
4 configuración de
05/08/2022
módulos de Odoo 12
Se establece las tablas
necesarias para la Base de
Datos con sus respectivos
campos.
Elaboración del Se estable el tipo de
08/08/2022-
5 modelo ER de la relaciones que van a tener las
12/08/2022
Base de Datos tablas.
Se estable el tipo de registros
que van a tener los campos
(Numérico, Varchar, Date,
String).
Se realizan pruebas en las
Elaboración del consultas dentro de
15/08/2022-
6 modelo ER de la PgAdmin para verificar que
19/08/2022
Base de Datos las consultas sean las
correctas.
Se realizan correcciones en
las relaciones entre las
tablas.
Elaboración del Se corrigen campos que no
22/08/2022-
7 modelo ER de la se consideran útiles o
26/08/2022
Base de Datos necesarios.
Se modifican el tipo de
variables que van a tener los
campos.
Se realiza un diagrama del
Elaboración del
29/08/2022- modelo entidad relación.
8 modelo ER de la
31/08/2022 Se crean las tablas y campos
Base de Datos
correctos como un modelo
54
dentro de Odoo(Archivos
.py).
4.6.3 Revision del sprint
Se finalizó con éxito el sprint del levantamiento y configuración del sistema, donde se
puede interactuar con los módulos y se realizó pruebas del ambiente.
4.6.4 Resultados y pruebas
Se finalizó que, al finalizar cada sprint, se haría una revisión con los interesados para
definir si el alcance de dicho sprint es correcto, o si en necesario realizar ajustes varios, esto
incluye modificar el proceso del negocio, la estructura del diagrama de la base de datos y
también patrones de diseño en la aplicación.
4.7 Sprint 1
En el siguiente Sprint se describe las tareas de funcionalidad, es decir el inicio del
desarrollo del sistema, en este sprint se desarrolló las pantallas para los formularios de tickets,
con la finalidad de tener las pantallas principales del sistema.
Se definió como objetivo principal es el diseño de las siguientes pantallas:
- Pantalla de Grids.
- Formulario de tickets.
- Pantalla de Configuraciones.
55
Tabla 42:

Diseño y construcción de la
01/09/2022- Catálogo de funcionalidad de la pantalla
1
02/09/2022 Funcionalidad de Grids.
05/09/2022- Catálogo de funcionalidad de la pantalla
2
06/09/2022 Funcionalidad de Formularios de tickets.
07/09/2022- Catálogo de
3 funcionalidad de la pantalla
08/09/2022 Funcionalidad
de Configuraciones.
Se finalizó con éxito el sprint del diseño de pantallas del sistema, donde se puede
interactuar con las pantallas e iniciar con la funcionalidad del sistema.
Se finalizó que, al finalizar cada sprint, se haría una revisión con los interesados para
definir si el alcance de dicho sprint es correcto, o si en necesario realizar ajustes varios, esto
incluye modificar el proceso del negocio, la estructura del diagrama de la base de datos y
también patrones de diseño en la aplicación.
4.8 Sprint 2
56
En el siguiente sprint se describe las tareas que involucran el desarrollo del sistema en
general como creación y edición de proyectos, creación de edición de contratos, con la finalidad
de poder interactuar con los formularios y comenzar a generar tickets y guardarlos en la base
de datos.
Se definió como objetivo principal fue iniciar con el desarrollo del sistema, contando
con las siguientes características o funciones.
- Worklogs para registro de horas del ticket.

- Modelos de proyecto, contrato y partner.
- Modelo de producto y categoría del proyecto
- Vistas de contrato.
- Vistas del proyecto y categorías del proyecto.
- Vistas para el modelo del worklogs.
Tabla 43:

Tiempos de trabajo Crear modelo de
09/09/22-
1 relacionado con los worklogs con sus
12/09/22
tickets respectivos campos
Worklogs para
13/09/22- Añadir grid a la vista
2 registro de horas del
14/09/22 del ticket
ticket
57
Archivos .py con la

Modelos de definición de los
15/09/22-
3 proyecto, contrato y modelos de los objetos
19/09/22
partner y sus respectivos
campos
Archivos .py con la
Modelo de producto definición de los
20/08/22-
4 y categoría del modelos de categoría y
22/08/22
proyecto producto relacionados
con proyecto.
Hacen falta
controles de
Vistas para
15/08/22- entrada de datos
5 Vistas de contrato configuración y CRUD
20/08/22 como
de contratos.
longitudes, o
validar fechas.
Hacen falta
Vistas para controles de
Vistas del proyecto
23/08/22- configuración y CRUD entrada de datos
6 y categorías del
29/09/22 de proyectos y como
proyecto
categorías del proyecto. longitudes, o
validar fechas.
Hace falta
implementar el
Crear vistas de tipo
registro
Vistas para el calendario para
30/09/22- “rápido” de
7 modelo del visualizar worklogs de
06/10/22 worklogs sin
worklogs cada empleado.
necesidad de
CRUD para worklogs
ingresar al
ticket.

58
Se finalizó con éxito el primer sprint correspondiente al desarrollo del sistema, se define
mejoras para las siguientes vistas:
 Contrato
 Proyecto
 Categorías del proyecto
 Worklogs
Soporte Cliente – Creación de tickets
Se permite la creación de un ticket por parte del usuario en el cual, puede ingresar la
Prioridad de su incidencia, adicionalmente también podrá dar una pequeña descripción de su
solicitud, en la descripción se puede incluir imágenes en caso de ser necesario.
Los campos: “Solicitante” – “Nombre de la persona” – “Email” se llenan
automáticamente con los datos de usuario.
Ilustración 9: Creación del Ticket por parte del usuario
De parte del rol de administrador, se permite tratar a los tickets creados como un tablero
kanban, para pasar por todo el ciclo de vida desde la creación del ticket hasta su cierre o
respuesta de este.
59
Ilustración 10: Respuesta a los Tickets 1
Ilustración 11: Respuesta a los Tickets 2
4.9 Sprint 3
En el siguiente sprint se describe las tareas para mejorar la funcionalidad del sistema
como mejorar las vistas de contrato, proyecto, categorías del proyecto y worklogs.
Se definió como objetivo principal fue mejorar la visualización de las vistas generadas
en el anterior Sprint.
60
Tabla 44:

07/10/2022- Añadir la creación rápida
Vistas para el
1 07/10/2022 de worklogs en la
modelo del worklogs
pantalla de calendario.
10/10/2022- Modelo y vista para Creación de pantalla de
2 10/10/2022 el centro de costos lista y formulario para
del proyecto centro de costo
11/10/2022- Desactivar créate & edit
Controles de
3 11/10/2022 en proyecto en la vista
pantallas
del ticket
12/10/2022- Ocultar o desactivar las
Controles de
4 13/10/2022 Subcategorías de los
pantallas
proyectos
Se asigna a ciertos
14/10/2022-
Controles de campos como lectura, ya
5 14/10/2022
pantallas que se asignan
automáticamente.
17/10/2022-
Controles de pantalla Control para campos
6 17/10/2022
de tickets obligatorios
18/10/2022- Realizar las

Actualizar archivo de
7 18/10/2022 traducciones
traducciones.
correspondientes
Controlar que la fecha de
Control en pantalla inicio no puede ser
19/10/2022-
8 de contratos y anterior a la fecha de
19/10/2022
proyectos. finalización del
Proyecto.
61
Controlar que la fecha de

inicio no puede ser
anterior a la fecha de
finalización del Contrato.
Creación de un nuevo
20/10/2022- Control de tickets modelo, para control de
9
20/10/2022 por ingreso de email Lista Negra y evitar
Spam
Distribuir de mejor
manera campos en el
21/10/2022- Mejoras de
10 formulario de tickets,
21/10/2022 navegación varias
para mejorar la
experiencia de usuario
24/10/2022- Controles de
11
24/10/2022 proyecto y contrato
Diseño y desarrollo de
una pantalla simplificada
Pantalla para ingreso
25/10/2022- para el ingreso de tickets
12 rápido de tickets sin
02/11/2022 al sistema, mediante la
autenticación
digitación de la cedula de
identidad del usuario
Archivos de Traducción,
07/11/2022- Configuraciones desactivación de
13
07/11/2022 varias creación y edición de
”Assigned User”
Desarrollo de un servicio
Controles para web para la consulta de
08/11/2022-
14 pantalla simplificada identificaciones de
09/11/2022
de ingreso de tickets usuarios que estén
registrados en el sistema.
62
Creación de modelo para

10/11/2022- Registro de estados
15 el registro, historial por
10/11/2022 de tickets,
el que pasa un ticket.
Agregar un campo para
11/11/2022- Proyectos Medibles diferenciar entre
16
11/11/2022 y No medibles proyectos de soporte y
proyectos de desarrollo.
Se finalizó con éxito el segundo sprint correspondiente al desarrollo del sistema, donde
se pudo mejorar las vistas de contrato, proyecto, categorías del proyecto y worklogs. Se define
el siguiente sprint como el sprint final y se establece realizar las funcionalidades finales y
corregir funciones incorrectas.
Se propone realizar entre las tareas más relevantes:

 Pop-ups, para controlar el cambio de estado de los tickets.
 Información de infraestructura del cliente.
En este sprint se logró mejorar la experiencia del usuario al momento de interactuar con
el sistema, también se logró agregar más funcionalidad al sistema con el ingreso de tickets
mediante e-mail.
4.10 Sprint 4
En el siguiente sprint se describe las tareas que se realizar para finalizar con el
desarrollo del sistema, entre las principales funcionalidades se destacan la realización del
reporte de estados y tickets reabiertos, la creación del KPI de tiempo Estimado & Tiempo de
Ejecución.
63
Se definió como objetivo principal agregar funcionalidades finales y corregir funciones
erróneas
Tabla 45:

14/11/2022- Wizard para la
1 14/11/2022 reapertura de ticket
ya entregado
Se agrega un campo
de comentario para
15/11/2022- Agregar “Comentario”
tickets en pausa, &
2 15/11/2022 & Reanudación de
modificación
tickets en pausa
pantalla emergente
para pausar un ticket
16/11/2022-
3
16/11/2022
Control de proceso Implementación de
17/11/2022-
4 de atención de botones en el
17/11/2022
tickets formulario del ticket
Proceso que crea un
18/11/2022- Estado de ticket
5 nuevo ticket a partir de
18/11/2022 reabierto
un ticket reabierto
Casos de Usos +
21/11/2022- Diagrama de
6
22/11/2022 Procesos, corrección
de Documentación
64
Desarrollo de
funcionalidades,
23/11/2022-
7 Perfiles de Usuario permisos, y menús para
28/11/2022
cada perfil de usuario
definido
Desarrollo de pantallas
Información de
29/11/2022- de formulario y lista
8 Infraestructura del
30/11/2022 para visualizar la
Cliente
información
Desarrollo de pantalla
01/12/2022- de tipo calendario para
9 Hojas de Trabajo
02/12/2022 visualizar y registrar
horas de trabajo
06/12/2022- Aprobación de
10
07/12/2022 tickets pendientes
Desarrollo de los cinco
08/12/2022- KPI´S (Dashboards) y
11 Reportes y KPI´S
19/12/2022 los reportes tabulares
relacionados con estos
Se finalizó con éxito el tercer sprint correspondiente al desarrollo del sistema, donde se
pudo completar las tareas más relevantes:
 Pop-up para la reapertura de tickets.

 Reanudación de tickets.
 Información de infraestructura del cliente.
 KPI´S y reportes varios.
65
Ilustración 12: Reporte por estado & Tickets Reabiertos
Ilustración 13: Reporte por Requerimientos por recurso & Requerimientos Nivel de Recurso
Ilustración 14: KPI´s Tiempo Estimado/Real & Tiempo Ejecución

66
Capítulo 5
5. Paso a producción, despliegue en AWS
5.1 EC2
Elastic Compute Cloud, o EC2, es uno de los servicios de AWS que se centra en
proporcionar la capa informática para nuestras aplicaciones. EC2 le permite específicamente
crear máquinas virtuales (también conocidas como instancias) a las que se les asigna una cierta
cantidad de potencia informática según la cantidad y el tipo de CPU, la cantidad de RAM y el
espacio en disco utilizado para el almacenamiento.
Además, EC2 le permite elegir el sistema operativo para instalar en la instancia,
proporcionando una máquina virtual completamente funcional en segundos donde los usuarios
pueden implementar aplicaciones tal como lo hacen en máquinas virtuales y servicios. Un
servidor local o en una máquina virtual instalada en cualquier otro hipervisor.
5.2 Características
Un entorno informático virtual llamado instancia. Una plantilla preconfigurada para su
instancia, llamada Imagen de máquina de Amazon (AMI), que empaqueta las partes que
necesita para su servidor (incluido un sistema operativo y software adicional).
Diferentes configuraciones de CPU de instancia, memoria, almacenamiento y
capacidad de red, conocidas como tipos de instancia. Protección las credenciales de inicio de
sesión de su instancia con un par de claves (AWS almacena la clave pública, usted almacena
la clave privada en un lugar seguro).
La cantidad de almacenamiento de datos temporales que se elimina cuando una
instancia se suspende, finaliza o hiberna, lo que se conoce como almacenamiento de instancias.
Volúmenes de almacenamiento de datos persistentes mediante Amazon Elastic Block Store
(Amazon EBS), conocido como Amazon EBS Volumes.

67
Múltiples ubicaciones físicas para recursos, como instancias y volúmenes de Amazon
EBS, denominadas regiones y zonas de disponibilidad.
5.3 Proceso de despliegue
Para este ejercicio se utilizó una instancia M5a de Amazon EC2, con 2 CPU’s y 8 GB
de Memoria RAM con un sistema operativo Ubuntu 20.04 (Linux). Después de inicializar la
instancia y obtener su IP pública, accedemos por SSH con el usuario y contraseña que hayamos
configurado para el servidor, para este caso vamos a usar WinSCP que nos permite conectarnos
rápidamente por SSH (PuTTY) y a su vez la transferencia de archivos por SFTP.
Ilustración 15: Parámetros de conexión mediante SFTP
1.- IP pública del servidor
2.- Usuario para autenticación del sistema operativo
3.- Contraseña de este usuario

68
Ilustración 16: Terminal de Ubuntu
Luego haremos clic en el botón señalado, lo que nos desplegará una ventana de PuTTY
para ingresar comandos dentro de la consola del servidor.
Una vez hecho esto procedemos a ingresar los siguientes comandos por consola, los
cuales van a permitir el funcionamiento correcto de Odoo en su versión 12, para después poder
instalar nuestro módulo de Gestión TI.
1. Actualizamos el sistema
apt-get update && apt-get upgrade -y
2. Creamos el usuario para Odoo
sudo userdel -r odoo
adduser --system --home=/opt/odoo --group odoo
3. Instalamos PostgreSQL
sudo apt install postgresql postgresql-contrib
4. Reiniciamos PostgreSQL, iniciamos sesión en PostgreSQL y creamos el usuario

postgres, ya que es el usuario por defecto que usa Odoo.
service postgresql restart
su - postgres
createuser --createdb --username postgres --no-createrole --no-superuser --pwprompt odoo
exit
69
5. Instalamos paquetes necesarios para el funcionamiento correcto de Odoo.

(PostgresSQL server, NodeJS, PIP, GIT, etc.)
sudo apt-get update && sudo apt-get install postgresql postgresql-server-dev-10 build-
essential python3-pil python3-lxml python-ldap3 python3-dev python3-pip python3-
setuptools npm nodejs git gdebi libldap2-dev libxml2-dev libxslt1-dev libjpeg-dev -y
sudo apt-get install libsasl2-dev

6. Clonamos el repositorio oficial de Odoo 12 desde Github. Adicionalmente instalamos
todas los paquetes Python con sus versiones respectivas con PIP.
sudo git clone --depth 1 --branch 12.0 https://github.com/odoo/odoo /opt/odoo/server

sudo pip3 install -r /opt/odoo/server/requirements.txt
7. Usamos npm, que es el gestor de paquetes NodeJS para instalar Less (lenguaje de
hojas de estilo que puede ser compilado en hojas de estilo en cascada (CSS))
sudo npm install -g less less-plugin-clean-css -y && sudo ln -s /usr/bin/nodejs /usr/bin/node
8. Instalamos wkhtmltopdf, este es el paquete encargado de generar los archivos PDF

dentro de Odoo.
sudo wget
https://github.com/wkhtmltopdf/wkhtmltopdf/releases/download/0.12.1/wkhtmltox-
0.12.1_linux-trusty-amd64.deb
sudo dpkg -i wkhtmltox-0.12.1_linux-trusty-amd64.deb
sudo cp /usr/local/bin/wkhtmltopdf /usr/bin
sudo cp /usr/local/bin/wkhtmltoimage /usr/bin
9. Creamos los directorios para la generación de los logs
mkdir /var/log/odoo/
chown odoo:root /var/log/odoo
70
mkdir /etc/odoo
cp /opt/odoo/server/debian/odoo.conf /etc/odoo/odoo.conf
chown odoo: /etc/odoo/odoo.conf
chmod 640 /etc/odoo/odoo.conf
10. Establecemos los parámetros de conexión de base de datos y la ruta de donde Odoo va
a tomar el código fuente y los módulos personalizados, también definimos la ruta de
los logs.
db_user = odoo
db_password = <Contraseña definida para la el usuario odoo>
addons_path = /opt/odoo/server/addons
logfile = /var/log/odoo/odoo-server.log
logrotate = True
11. Establecemos el ejecutable de inicialización de Odoo como un servicio Linux.
sudo cp /opt/odoo/server/debian/init /etc/init.d/odoo && sudo chmod +x /etc/init.d/odoo

sudo ln -s /opt/odoo/server/odoo-bin /usr/bin/odoo
update-rc.d odoo defaults
sudo service odoo start
12. Creamos un directorio para depositar nuestros módulos personalizados.
mkdir /opt/odoo/server/extra-addons
chown odoo: /opt/odoo/ -R
13. Para finalizar debemos copiar nuestra carpeta del módulo de Gestión TI, en la ruta
que acabamos de crear, y reiniciamos el servicio que creamos en el punto 11.
Posteriormente podemos ingresar mediante la IP pública del servidor y el puerto
8069.
71
Capítulo 6
6. Conclusiones y recomendaciones
6.1 Conclusiones
Como resultado del tema “Implementación de un sistema de información integrado para
la gestión de procesos en una empresa del área de TI” podemos concluir que, la plataforma
web permite mejorar la gestión de proyectos y a su vez mejorar la atención al cliente, además
permite optimizar los recursos de esta, e incrementar la calidad de los desarrollos realizados en
una empresa.
Se implementó un sistema que reduce la necesidad de dar seguimiento a tareas
repetitivas, también permite simplificar el proceso por el cual se ingresan tickets, ya que se
dispone de varias maneras de registrar un requerimiento o incidencia, contando con las
posibilidades de ingresar un ticket mediante email, e ingreso mediante el sistema Web, además
el ingreso de tickets mediante la web se optó por mostrar los campos más relevantes para
optimizar el tiempo del cliente.
Se implementó los siguientes reportes: estado, tickets reabiertos, requerimientos por
recurso, requerimientos de nivel de recurso y el KPI: tiempo estimado vs real y tiempo de
ejecución, mismo que permitirán al jefe del departamento de desarrollo mejorar y solventar
falencias que se puedan identificar en la atención al cliente.
Finalmente, se categorizaron las tareas realizadas por los empleados, en los distintos
proyectos internos con los que cuente la empresa, permitiendo hacer un análisis del tiempo de
trabajo y tipo de tarea específicos para los distintos escenarios que representan cada cliente.
6.2 Recomendaciones
Para la optimización de los procesos es recomendable realizar una capacitación de todos
los involucrados, en la parte de creación de tickets capacitar a los “clientes” internos que
72
pueden ser los mismos empleados que registren un requerimiento o incidente y de esta manera
se pueda hacer un correcto uso de la herramienta, para los clientes externos levantar un manual
de uso, indicando los campos obligatorios o más importantes al momento de generar el ticket
y evitar campos vacíos o perdida de información importante.
Adicionalmente, es importante que los usuarios técnicos, se familiaricen con la
plataforma web, ya que este sistema permitirá realizar un seguimiento a las incidencias o
requerimientos solucionados por parte del técnico, además que se le permite realizar un registro
de horas.
El sistema permite generar información útil para poder ser utilizada en un enfoque hacia
Big Data, por lo que el proyecto queda abierto para ser utilizado como fuente para un proceso
ETL y posteriormente procesado por herramientas complementarias de BI o modelos de Deep
learning (que se aprovecha, ya que el backend del sistema está escrito en Python) que puedan
ayudar en la toma de decisiones en una empresa de esta área de las TI.

73
7. Referencias bibliográficas
Conceição Menezes, P. A. D., & González-Ladrón-de-Guevara, F. (2010). Maximización de

los beneficios de los sistemas ERP. JISTEM-Journal of Information Systems and Technology
Management, 7, 5-32.
Pop, D. P., & Altar, A. (2014). Designing an MVC model for rapid web application
development. Procedia Engineering, 69, 1172-1179.
Fernandez, A. (2013). Python 3 al descubierto. Alfaomega Grupo Editor.
Ordóñez, M. P. Z., Ríos, J. R. M., & Castillo, F. F. R. (2017). Administración de Bases de datos
con PostgreSQL (Vol. 19). 3Ciencias.
Cadavid, A. N., Martínez, J. D. F., & Vélez, J. M. (2013). Revisión de metodologías ágiles
para el desarrollo de software. Prospectiva, 11(2), 30-39.
Ponce Huanca, J. L., & Samaniego Castro, M. F. (2015). Análisis del impacto del HELP DESK
en los procesos del departamento de soporte técnico en una organización (Bachelor's thesis).
Gallardo, J. A. R., de la Madrid, M. C. L., & de los Monteros Cárdenas, A. E. Estudio sobre la
implementación del software Help Desk en una institución de educación superior Study of the
implementation of Help Desk software in an institution of higher education.
Ruiz Sánchez, G. A. (2017). Implementación de una aplicación Web Help Desk para la
Cooperativa de ahorro y crédito Kullki Wasi (Bachelor's thesis, Universidad Técnica de
Ambato. Facultad de Ingeniería en Sistemas, Electrónica e Industrial. Carrera Ingeniería en
Sistemas Computacionales e Informáticos).
Mendoza, I., & Xavier, F. (2022). Implementación de servicio help desk o mesa de ayuda para
la empresa “MachalaGPS”.
Vergara Guerrero, Z. H. (2021). Sistema HelpDesk bajo plataforma web para la mejora del
proceso de servicio técnico de la empresa Datasum SRL.
Rodríguez Gallardo, J. A., López de la Madrid, M. C., & Espinoza de los Monteros Cárdenas,
A. (2018). Study of the implementation of Help Desk software in an institution of higher
education. PAAKAT: revista de tecnología y sociedad, 8(14).
74
Parada-Soto, O., Zamora-Castro, Y., & Trujillo-Pacheco, C. (2019). Sistema de gestión de

proyectos de servicios en una entidad interface. Ciencias Holguín, 25(4), 12-21.
Pastor, R. A. T. (2009). Modelo conceptual para la gestión de proyectos. Perspectivas, (24),

165-188.
Reis, D. (2018). Odoo 12 Development Essentials: Fast-track your Odoo development skills to
build powerful business applications. Packt Publishing Ltd.
Deemer, P., Benefield, G., Larman, C., & Vodde, B. (2009). Información básica de
SCRUM. California: Scrum Training Institute.
Cardoso, S. L. M. (2019). Metodología para procesos de Inteligencia de Negocios con mejoras

en la extracción y transformación de fuentes de datos, orientado a la toma de
decisiones (Doctoral dissertation, Universitat d'Alacant-Universidad de Alicante).
Pérez Sevilla, L. (2020). Desarrollo de mecanismos de autentificación avanzados.
Ertaul, L., Kaur, M., & Gudise, V. A. K. R. (2016). Implementation and performance analysis
of pbkdf2, bcrypt, scrypt algorithms. In Proceedings of the International Conference on
Wireless Networks (ICWN) (p. 66). The Steering Committee of The World Congress in
Computer Science, Computer Engineering and Applied Computing (WorldComp).
Gnuien?, ¿quién E. S. (s/f). ¿Qué significa «el Programa» en la GPLv3? - Proyecto GNU -
Free Software Foundation. Gnu.org. Recuperado el 25 de enero de 2023, de
https://www.gnu.org/licenses/gplv3-the-program.es.html

Uce-Fing-Isi-Cachimuel Luis-Viscaino Cristian

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Uce-Fing-Isi-Cachimuel Luis-Viscaino Cristian

Cargado por

Copyright:

Formatos disponibles

Universidad Central del Ecuador

Facultad de Ingeniería y Ciencias Aplicadas

Implementación de un sistema de información integrado para la gestión de

Autores: Luis Raúl Cachimuel Pazmiño

Mediante el envío del presente correo electrónico ACEPTO EN FORMA EXPRESA en

“Trabajos de Titulación en formato digital. - Todas las instituciones de educación superior

El/la autor/autora declara que la obra objeto de la presente autorización es original en su

El/la autor/autora reconozco que este mensaje electrónico de aceptación reemplaza a mi

a. Que la información que contenga sea accesible para su posterior consulta;

Luis Raúl Cachimuel Pazmiño

Cristian Xavier Viscaino Tacuri

Luis Raúl Cachimuel Pazmiño

Cristian Xavier Viscaino Tacuri

Lista de tablas ............................................................................................................................ v

1. Presentación del problema .............................................................................................. 2

1.1 Planteamiento del problema ........................................................................................ 2

1.2 Objetivos del proyecto ................................................................................................ 2

1.2.1 Objetivo general ...................................................................................................... 2

1.2.2 Objetivos específicos ............................................................................................... 3

1.3 Justificación ................................................................................................................. 3

1.4 Alcance ........................................................................................................................ 4

1.4.1 Perfiles en la aplicación ............................................................................................. 4

1.4.2 Creación de tickets en el sistema ............................................................................... 5

1.4.3 Gestión de proyectos .................................................................................................. 5

1.4.4 Creación de KPI´S ..................................................................................................... 5

1.4.5 Gestión de reportes .................................................................................................... 6

2. Marco teórico .................................................................................................................. 7

2.1.1 Beneficios de un ERP .................................................................................................. 7

2.1.2 Comparación ERP....................................................................................................... 8

2.2 ODOO ....................................................................................................................... 10

2.2.1 Seguridad ............................................................................................................... 10

2.2.3 Arquitectura de ODOO ......................................................................................... 11

2.4 Ubuntu 20.0.4 LTS .................................................................................................... 13

2.5 Pycharm ..................................................................................................................... 13

2.6 Help Desk .................................................................................................................. 13

2.6.1 Módulo de la comunidad Website Help Desk .......................................................... 14

2.7 Gestión de Proyectos ................................................................................................. 15

2.8 MVC en Odoo ........................................................................................................... 16

2.9.1 Modelo ................................................................................................................... 17

2.9.2 Vista ....................................................................................................................... 18

2.10 Estado del Arte .......................................................................................................... 19

3.1 Metodologías ágiles................................................................................................... 22

3.2 Scrum ........................................................................................................................ 22

3.2.1 Fases de la metodología Scrum ............................................................................. 23

3.2.2 Perfiles de la metodología Scrum .......................................................................... 23

3.2.3 Beneficios de la metodología Scrum ..................................................................... 24

4. Aplicación de la metodología de desarrollo.................................................................. 25

4.1 Levantamiento de requerimientos ............................................................................. 25

4.1.1 Resumen de roles y funciones ................................................................................ 49

4.1.2 Funcionalidades .................................................................................................... 50

4.1.2.2 KPI´s .................................................................................................................. 50

4.1.3 Flujograma ............................................................................................................ 51

4.2 Casos de uso .............................................................................................................. 52

4.3 Diagrama de procesos ............................................................................................... 53

4.4 Modelo entidad relación .............................................................................................. 1

4.5 Diccionario de datos .................................................................................................. 45

4.6 Sprint 0 ...................................................................................................................... 51

4.6.1 Planificación del sprint ............................................................................................. 51

4.6.2 Ejecución del sprint ................................................................................................... 52

4.6.3 Revision del sprint ................................................................................................. 54

4.6.4 Resultados y pruebas ............................................................................................. 54

4.7 Sprint 1 ...................................................................................................................... 54

4.7.1 Planificación del sprint ............................................................................................. 54