Entregable 3 PI3 - Sumarriva Rubio

UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS
FACULTAD DE INGENIERÍA
DIVISIÓN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS
CARRERA DE INGENIERÍA DE SISTEMAS
SISTEMA DE GESTIÓN DE SERVICIO TÉCNICO Y MONITOREO PARA

EQUIPOS DE INSPECCIÓN Y DETECCIÓN DE METALES Y EXPLOSIVOS
PROYECTO PROFESIONAL PRESENTADO POR:

LUIS SUMARRIVA RUBIO (U201220953)
PARA OPTAR POR EL TÍTULO DE INGENIERO DE SISTEMAS
ASESOR:
HÉCTOR SAIRA
Lima, Noviembre de 2015

RESUMEN
El presente proyecto de tesis “SISTEMA DE GESTIÓN DE SERVICIO TÉCNICO Y

MONITOREO PARA EQUIPOS DE INSPECCIÓN Y DETECCIÓN DE METALES Y
EXPLOSIVOS” tiene como objetivo el desarrollo de un sistema web y móvil para la
empresa Unlimited-Systems SAC, con la finalidad de gestionar, controlar, optimizar y
agilizar las actividades y los procesos de servicio de soporte técnico que brinda el área de
tecnología.
En el proceso de soporte técnico se ha analizado la necesidad de implementar un solución

informática acorde a la problemática del área, dentro de los requerimiento del área y
utilizando las tecnologías de punta que se encuentran en el mercado actualmente.
Por lo cual en este documento se desarrolla la solución propuesta para la empresa y

abarcando diferentes aspectos importantes para la implementación y entendimiento del
proyecto tanto para los interesados del proyecto como para los usuarios finales.
El contenido del trabajo se divide en 7 capítulos comprendiendo desde los fundamentos

teóricos, objeto de estudio, los objetivos generales y específicos así como como la situación
problemática y propuesta de solución; pasando por el modelado del negocio y de los
requerimientos del sistema, hasta el desarrollo y construcción de la arquitectura de software
y la gestión de proyecto.
Al final como resultado se espera obtener un sistema de gestión de servicio técnico que
cumpla con todos los objetivos descritos en el proyecto, que gestione los casos de servicio del
área y ayuda en la mejora continua de los procesos del área.
Página 2
ÍNDICE
RESUMEN.................................................................................................................................2
ÍNDICE......................................................................................................................................3
LISTAS ESPECIALES..............................................................................................................8
INTRODUCCIÓN...................................................................................................................11
CAPÍTULO 1: FUNDAMENTOS TEÓRICOS......................................................................13
1 INTRODUCCIÓN..........................................................................................................13
2 MARCO TEÓRICO.......................................................................................................13
2.1 Fundamentos teóricos sobre el negocio..........................................................................13
2.2 Fundamentos teóricos sobre las tendencias y tecnologías actuales...............................17
3 OBJETO DE ESTUDIO.................................................................................................22
3.1 Organización Objetivo....................................................................................................22
3.1.1 Descripción de la organización objetivo.........................................................................22
3.1.2 Líneas de negocio...........................................................................................................22
3.1.3 Servicios ofrecidos..........................................................................................................23
3.1.4 Productos Ofrecidos........................................................................................................25
3.1.5 Trayectoria Empresarial..................................................................................................26
3.2 Misión.............................................................................................................................26
3.3 Visión..............................................................................................................................26
3.4 Objetivos Estratégicos....................................................................................................27
3.5 Organigrama...................................................................................................................27
4 CAMPO DE ACCIÓN...................................................................................................28
4.1 Breve Descripción..........................................................................................................28
4.2 Procesos del Negocio......................................................................................................29
4.3 Sistemas automatizados vinculados con el campo de acción.........................................32
5 ANÁLISIS CRÍTICO DE LOS PROBLEMAS DE INFORMACIÓN..........................33
5.1 Situación problemática y Problemas a resolver..............................................................33
6 CONCLUSIONES..........................................................................................................38
CAPÍTULO 2: PROPUESTA DE SOLUCIÓN......................................................................39
1 INTRODUCCIÓN..........................................................................................................39
Página 3
2 OBJETIVOS DEL PROYECTO....................................................................................39
2.1 Objetivo general..............................................................................................................39
2.2 Objetivos específicos......................................................................................................39
2.3 Fundamentación de los objetivos....................................................................................42
2.4 Indicadores de logro de los objetivos.............................................................................45
3 BENEFICIOS DEL PROYECTO..................................................................................46
3.1 Beneficios tangibles........................................................................................................46
3.2 Beneficios intangibles.....................................................................................................46
4 ANTECEDENTES.........................................................................................................47
4.1 Soluciones encontradas...................................................................................................47
4.2 Análisis comparativo......................................................................................................50
4.3 Evaluación de la mejor solución.....................................................................................51
5 TENDENCIA Y TECNOLOGÍAS PROPUESTAS.....................................................54
6 CONCLUSIONES..........................................................................................................56
CAPÍTULO 3: MODELADO DEL NEGOCIO......................................................................57
1 INTRODUCCIÓN..........................................................................................................57
2 REGLAS DEL NEGOCIO.............................................................................................57
3 MODELO DE CASOS DE USO DEL NEGOCIO........................................................60
3.1 Actores del negocio........................................................................................................60
3.2 Casos de uso del negocio................................................................................................62
3.3 Diagrama de Casos de Uso del Negocio.........................................................................63
4 MODELO DE ANÁLISIS DEL NEGOCIO..................................................................63
4.1 Trabajadores del negocio................................................................................................63
4.2 Entidades del negocio.....................................................................................................65
5 REALIZACIÓN DE LOS CASOS DE USO DEL NEGOCIO......................................70
5.1 CUN_01_SOLICITAR SERVICIO................................................................................70
5.1.1 Especificación del caso de uso del negocio....................................................................70
5.1.2 Diagrama de actividades.................................................................................................72
5.1.3 Lista de actividades a automatizar..................................................................................73
5.1.4 Diagrama de Clases del Negocio....................................................................................74
5.2 CUN_02_PLANIFICAR SERVICIO.............................................................................75
Página 4
5.3 CUN_03_ATENDER SERVICIO..................................................................................80
6 CONCLUSIONES..........................................................................................................85
CAPÍTULO 4: REQUERIMIENTOS......................................................................................86
1 INTRODUCCIÓN..........................................................................................................86
2 ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL SOFTWARE......................86
2.1 Requerimientos Funcionales...........................................................................................86
2.2 Requerimientos No Funcionales.....................................................................................91
3 MODELO DE CASOS DE USO DEL SISTEMA.........................................................97
3.1 Especificación de los actores del sistema.......................................................................97
3.2 Diagrama de actores del sistema...................................................................................100
3.3 Diagrama de paquetes del sistema................................................................................100
3.4 Diagrama de casos de uso del sistema por paquete......................................................101
3.4.1 Solicitar Servicio..........................................................................................................101
3.4.2 Planificar Servicio........................................................................................................102
3.4.3 Atender Servicio...........................................................................................................103
3.4.4 Seguridad......................................................................................................................104
4 ATRIBUTOS DE LOS CASOS DE USO DE SISTEMA...........................................105
5 ESPECIFICACIONES ALTO NIVEL DE LOS CASOS DE USO DE SISTEMA....106
6 ESPECIFICACIONES DETALLADAS LOS CASOS DE USO DEL NÚCLEO
CENTRAL.............................................................................................................................120
6.1 CUS_001_Registrar Solicitud de Atención de Servicio...............................................120
6.2 CUS_002_Consultar Solicitud de Atención de Servicio del Cliente............................126
6.3 CUS_006_Actualizar Caso de Servicio........................................................................130
6.4 CUS_015_Gestionar planificación más idónea para casos de servicio........................139
6.5 CUS_046_Gestionar logs de errores del Hitrax...........................................................144
7 MODELO CONCEPTUAL..........................................................................................150
7.1 Diagrama del Modelo Conceptual................................................................................150
Página 5
7.2 Diccionario del Modelo Conceptual.............................................................................151
8 CONCLUSIONES........................................................................................................158
CAPÍTULO 5: ARQUITECTURA DE SOFTWARE...........................................................159
1 INTRODUCCIÓN........................................................................................................159
2 DIAGRAMA DE LOS CASOS DE USO MÁS SIGNIFICATIVOS PARA LA
ARQUITECTURA DEL SOFTWARE.................................................................................160
3 METAS DE LA ARQUITECTURA DE SOFTWARE...............................................161
4 RESTRICCIONES DE LA ARQUITECTURA DE SOFTWARE..............................164
5 MECANISMOS ARQUITECTURALES....................................................................166
6 VISTA LÓGICA DE LA ARQUITECTURA DE SOFTWARE.................................174
6.1 Capa Presentación.........................................................................................................175
6.2 Capa Negocio................................................................................................................175
6.3 Capa Datos....................................................................................................................176
7 VISTA DE IMPLEMENTACIÓN DE LA ARQUITECTURA DE SOFTWARE......177
8 VISTA DE DESPLIEGUE DE LA ARQUITECTURA DE SOFTWARE.................178
9 CONCLUSIONES........................................................................................................179
CAPÍTULO 6: CONSTRUCCIÓN........................................................................................180
1 INTRODUCCIÓN........................................................................................................180
2 PATRONES DE LA SOLUCIÓN PROPUESTA........................................................181
2.1 Patrón MVC..................................................................................................................181
2.2 Patrón Repository.........................................................................................................183
3 MODELO DE DATOS.................................................................................................185
3.1 Modelo de datos físico del sistema..............................................................................185
3.2 Diccionario de Datos....................................................................................................186
4 CONCLUSIONES........................................................................................................193
CAPÍTULO 7: CALIDAD Y PRUEBAS DEL SOFTWARE...............................................194
1 INTRODUCCIÓN........................................................................................................194
2 PLAN DE LA CALIDAD DEL SOFTWARE.............................................................194
2.1 Política de calidad.........................................................................................................194
2.2 Objetivos de calidad.....................................................................................................194
2.3 Normatividad aplicable.................................................................................................195
2.4 Métricas de calidad de software...................................................................................196
3 PRUEBAS DEL SOFTWARE.....................................................................................197
Página 6
3.1 Casos de prueba para CUS_006_Actualizar Caso de Servicio.....................................197
3.1.1 Especificación de los Casos de Prueba.........................................................................197
3.1.2 Escenarios y juego de datos de los Casos de Prueba....................................................204
3.2 Casos de prueba para CUS_046_Gestionar Logs de Errores del Hitrax......................205
3.2.1 Especificación de los Casos de Prueba.........................................................................205
3.2.2 Escenarios y juego de datos de los Casos de Prueba....................................................210
4 CONCLUSIONES........................................................................................................211
CAPÍTULO 8: GESTIÓN DEL PROYECTO.......................................................................212
1 INTRODUCCIÓN........................................................................................................212
2 REGISTRO DE INTERESADOS................................................................................212
3 EDT...............................................................................................................................213
4 CRONOGRAMA DE EJECUCIÓN............................................................................214
5 ACTA DE ACEPTACIÓN DEL ENTREGABLE.......................................................217
6 CONCLUSIONES........................................................................................................221
CONCLUSIONES.................................................................................................................222
GLOSARIO DE TÉRMINOS................................................................................................223
SIGLARIO.............................................................................................................................225
BIBLIOGRAFÍA....................................................................................................................226
ANEXOS................................................................................................................................229
Página 7
LISTAS ESPECIALES
Gráficos
Gráfico 1: Ciclo de Trabajo de mantenimiento [9]..................................................................14

Gráfico 2: Ciclo de Gestión de Calidad [8]..............................................................................16
Gráfico 3: Arquitectura de un sistema móvil [13]...................................................................19
Gráfico 4: Implementación de servicio web con aplicación móvil [13]..................................21
Gráfico 5: Organigrama de la empresa Unlimited-Systems [elaboración propia]...................27
Gráfico 6: Mapa de Procesos General [elaboración propia]....................................................28
Gráfico 7: Flujo de tareas del proceso del área [elaboración propia].......................................31
Gráfico 8: Diagrama de casos de uso del negocio [elaboración propia]..................................63
Gráfico 9: Diagrama de actividades de CUN_01_Solicitar Atención [elaboración propia]....72
Gráfico 10: Diagrama de clases de CUN_01_Solicitar Atención [elaboración propia]..........74
Gráfico 11: Diagrama de clases de CUN_02_Planificar Servicio [elaboración propia]..........77
Gráfico 12: Diagrama de clases de CUN_02_Planificar Servicio [elaboración propia]..........79
Gráfico 13: Diagrama de actividades de CUN_03_Atender Servicio [elaboración propia]....82
Gráfico 14: Diagrama de clases de CUN_03_Atender Servicio [elaboración propia]............84
Gráfico 15: Diagrama de actores del sistema [elaboración propia].......................................100
Gráfico 16: Diagrama de paquetes de sistema [elaboración propia]......................................100
Gráfico 17: DCU Solicitar Servicio [elaboración propia]......................................................101
Gráfico 18: DCU Planificar Servicio [elaboración propia]....................................................102
Gráfico 19: DCU Atender Servicio [elaboración propia]......................................................103
Gráfico 20: DCU Seguridad [elaboración propia].................................................................104
Gráfico 21: Formulario Registro Solicitud de Atención nueva [elaboración propia]............124
Gráfico 22: Formulario Registro Detalle de Solicitud de Atención [elaboración propia].....124
Gráfico 23: Formulario Edición de Detalle de Solicitud de Atención [elaboración propia]..125
Gráfico 24: Mensaje Eliminación de Detalle de Solicitud de Atención [elaboración propia]
................................................................................................................................................125
Gráfico 25: Formulario Consulta Solicitud de Atención [elaboración propia]......................128
Gráfico 26: Formulario Consulta Solicitud de Atención Filtrado [elaboración propia]........129
Gráfico 27: Detalle de Solicitud de Atención [elaboración propia].......................................129
Página 8
Gráfico 28: Formulario Búsqueda Solicitudes de Atención [elaboración propia].................136
Gráfico 29: Formulario Registro Caso de Solicitud de Servicio Nuevo [elaboración propia]
................................................................................................................................................136
Gráfico 30: Formulario Registro Detalle de Caso de Servicio [elaboración propia].............137
Gráfico 31: Formulario Edición Detalle de Caso de Servicio [elaboración propia]..............137
Gráfico 32: Mensaje Eliminación Detalle de Caso de Servicio [elaboración propia]...........138
Gráfico 33: Formulario Búsqueda Casos de Servicio [elaboración propia]..........................142
Gráfico 34: Detalle Caso de Servicio [elaboración propia]...................................................143
Gráfico 35: Formulario Asignación Técnico a Detalle de Caso [elaboración propia]...........143
Gráfico 36: Panel de Monitoreo de Errores Hitrax [elaboración propia]...............................148
Gráfico 37: Monitoreo Activado [elaboración propia]..........................................................148
Gráfico 38: Monitoreo Detenido [elaboración propia]..........................................................148
Gráfico 39: Formulario Carga de Archivo de Error [elaboración propia]............................149
Gráfico 40: Diagrama del Modelo Conceptual [elaboración propia].....................................150
Gráfico 41: Diagrama de los CUS más significativos para la arquitectura del software
[elaboración propia]...............................................................................................................160
Gráfico 42: Vista Lógica de la Arquitectura de Software [elaboración propia]....................174
Gráfico 43: Vista de Implementación de la Arquitectura de Software [elaboración propia].177
Gráfico 44: Vista de Despliegue de la Arquitectura de Software [elaboración propia].........178
Gráfico 45: Diagrama del patrón Model-Controller-View [18].............................................181
Gráfico 46: Diagrama del patrón Repository [20].................................................................183
Gráfico 47: Diagrama del Modelo de Datos Físico del Sistema [elaboración propia]..........185
Gráfico 48: Diagrama EDT [elaboración propia]..................................................................213
Gráfico 49: Cronograma de tareas Fase 1 [elaboración propia]............................................214
Tablas
Tabla 1: Tipos de Servicio Postventa [10]...............................................................................15

Tabla 2: Situación Problemática vs Problema a Resolver [elaboración propia]......................35
Tabla 3: Problema a Resolver vs Objetivos Específicos [elaboración propia]........................44
Tabla 4: Indicadores de los objetivos del proyecto [elaboración propia]................................45
Página 9
Tabla 5: Solución 01: MP Software [elaboración propia].......................................................48
Tabla 6: Solución 02: Sistrade [elaboración propia]................................................................49
Tabla 7: Análisis comparativo de soluciones [elaboración propia].........................................50
Tabla 8: Atributos de los casos de uso del sistema [elaboración propia]...............................105
Tabla 9: Metas de la Arquitectura de Software [elaboración propia]....................................163
Tabla 10: Restricciones de la Arquitectura de Software [elaboración propia]......................165
Tabla 11: Mecanismos Arquitecturales [elaboración propia]................................................173
Tabla 12: Especificación del patrón MVC [elaboración propia]...........................................182
Tabla 13: Especificación del patrón Repository [elaboración propia]...................................184
Tabla 14: Métricas de Calidad del Proyecto [elaboración propia].........................................196
Tabla 15: Escenarios y Juego de Datos CPS_006_Actualizar Caso de Servicio [elaboración
propia]....................................................................................................................................204
Tabla 16: Escenarios y Juego de Datos CPS_046_Gestionar Logs de Errores del Hitrax
[elaboración propia]...............................................................................................................210
Tabla 17: Registro de Interesados [elaboración propia]........................................................212
Página 10
INTRODUCCIÓN
En la actualidad la tecnología avanza a pasos agigantados, por lo cual todas las empresas
optan por la automatización de sus procesos para mejorar la productividad y generar mayores
ingresos a menor costo operativo.
Dentro de los actuales avances tecnológicos está el creciente uso de dispositivos móviles, el
cual se ha incrementado tanto las ventas como su uso en la población de forma exponencial
desde su introducción al mercado. Por este motivo, el uso de aplicaciones móviles y las ya
mayormente utilizadas aplicaciones Web, son eficientemente explotadas y utilizadas para
solucionar los problemas operativos de las empresas y para gestionar eficazmente sus
procesos.
La empresa Unlimited Systems S.A.C es una empresa líder en el Perú y con experiencia a
nivel mundial que brinda soluciones integrales en tecnología dentro de sus tres líneas de
negocio: inspección y detección, equipos médicos y medio ambientales. Son los
representantes de SMITHS DETECTION, CEIA S.P.A., STI, CROSSMATCH
TECHNOLOGIES en el Perú. Su línea de negocio más rentable son los equipos de seguridad
perimetral como los pórticos detectores de metales y los equipos de inspección de bultos por
Rayos X.
El proyecto presentado tiene como fondo el desarrollo de un sistema web y móvil para la
empresa Unlimited-Systems SAC, con la finalidad de gestionar, controlar y dar seguimiento a
todos los servicios de soporte técnicos ejecutados por el área de tecnología, así como el de
manejar recursos del área, optimizar los tiempo de servicio, agilizar los procesos internos del
área y brindar indicadores cuantitativos que ayuden a mejorar, optimizar y automatizar el
proceso de soporte técnico del área.
El sistema a desarrollar debe gestionar eficientemente los casos de servicios generados por el
área, así como proveer facilidad de consultas a los técnicos de campo en la ejecución de la
atención. También deberá contar con indicadores y estadística de rendimiento de los equipos,
de los técnicos y de los recursos que el área consume durante la gestión de servicio que
realiza.
Página 11
El contenido del presente trabajo se divide en 6 capítulos los cuáles tratarán a fondo y en
detalle cada aspecto del proyecto a presentar.
El capítulo 1, se centra en los fundamentos teóricos inherentes del sistema a desarrollar, así
también se desarrolla el objeto de estudio y el campo de acción el cuál es el marco sobre el
cuál se trabaja este proyecto de tesis, finalmente se analiza con detalle las causas y problemas
más resaltantes, a los cuáles el sistema se enfocará en solucionar.
El capítulo 2, se centra en la propuesta de solución que presenta este proyecto de tesis, sus
objetivos generales y específicos a cumplir, los cuales satisfacen los problemas encontrados
en el capítulo anterior, también se explora diferentes soluciones en el mercado y se hace una
comparativa con el sistema propuesto.
El capítulo 3, se centra en el análisis del negocio desde el punto de vista de modelo RUP. Se
detalla los casos de uso del negocio junto con los actores del negocio, los trabajadores del
negocio y las entidades del negocio.
El capítulo 4, se centra en el análisis de los requerimientos del sistema desde el punto de vista
de modelo RUP. Se identifican los Requerimientos Funcionales y No Funcionales, se detalla
los casos de uso del sistema junto con los actores del sistema, los paquetes del sistema y las
por último se elabora el modelo conceptual del sistema.
El capítulo 5, se centra en el análisis de la arquitectura de software que contendrá el sistema
desde el punto de vista de modelo RUP. Se identifican las metas y restricciones de la
arquitectura de software y se elabora los mecanismos arquitecturales para su solución. Se
detalla las vistas de la arquitectura: lógica, implementación y despliegue, que dan una visión
de la arquitectura que tendrá el desarrollo del proyecto.
El capítulo 6, se centra en la construcción del sistema a desarrollar. Se detallará los patrones
usados, así como el diagrama completo del modelo de datos del sistema.
El capítulo 7, se centra en todo los aspectos de la gestión de proyecto que rigen la ejecución
del proyecto. Se presenta el cronograma de actividades del proyecto, el EDT y la carta de
aceptación de la empresa a la cual se está desarrollando el presente sistema.
Al final como resultado se espera obtener un sistema de gestión y control de los servicios
brindados por el área, que pueda optimizar y mejorar los tiempos de asignación de los
recursos y tareas a ejecutar del área, que cumpla con todos los objetivos descritos en el
proyecto, que gestione los casos de servicio del área y ayuda en la mejora continua de los
procesos del área.
Página 12
Página 13
CAPÍTULO 1: FUNDAMENTOS TEÓRICOS
1 INTRODUCCIÓN
El presente capítulo proporciona información referente a los fundamentos teóricos sobre el

negocio y sobre las tendencias y tecnologías actuales. Adicionalmente, se detalla la
organización a la cual se elabora el proyecto y se define el campo de acción del mismo.
Finalmente, se presenta un análisis de los problemas y sus causas dentro del proceso campo
de acción, y para el cuál se apunta a resolver a través del presente trabajo.
2 MARCO TEÓRICO
2.1 Fundamentos teóricos sobre el negocio
El desarrollo e implementación de un modelo real y factible para la gestión global del

mantenimiento se ha convertido en un tema de investigación y discusión fundamental para
alcanzar un buen desempeño en la gestión de mantenimiento, cuyos objetivos están alineados
al cumplimiento de los objetivos de la empresa
La gestión del mantenimiento dentro de las empresas hoy por hoy es necesaria para correcto
cuidado y funcionamiento de toda una empresa. Está se convertido en una pieza fundamental
y de factor competitivo en el sector empresarial, ya que puede determinar el estado de los
procesos, afectarlos directamente y con ello afectar la productividad y eficiencia de la
compañía. Las actividades incluidas en la gestión de mantenimiento están destinadas a
determinar objetivos y prioridades de mantenimiento, las estrategias y las responsabilidades.
[7]
El concepto base que da lugar a la ingeniería de mantenimiento es la mejora continua del

proceso de gestión del mantenimiento mediante la incorporación de conocimiento,
Página 14
inteligencia y análisis que sirvan de apoyo a la toma de decisiones en el área del
mantenimiento, orientadas a favorecer el resultado económico y operacional global.
La ingeniería de mantenimiento permite, a partir del análisis y modelado de los resultados

obtenidos en la ejecución de las operaciones de mantenimiento, renovar continua y
justificadamente la estrategia y, por consiguiente, la programación y planificación de
actividades para garantizar la producción y resultados económicos al mínimo costo global.
[9]
Gráfico 1: Ciclo de Trabajo de mantenimiento [9]
La calidad de un producto está dada por su capacidad de satisfacer determinadas necesidades

y expectativas de los clientes, depende del "valor total" que estos atribuyan al producto. Para
Zuthaml (1988, Citado en Colectivo de Autores, 1999) el valor percibido por el cliente es la
valoración total que el cliente realiza de la utilidad de un producto basada en la percepción de
lo que se recibe y se da a cambio y este valor total comprende tres dimensiones:
 Valor de compra: El cliente se pregunta cuanto valor le reportará determinado producto.
 Valor de uso: Se relaciona con la satisfacción que produce un producto durante su uso.
 Valor final: Es la satisfacción que reporta a al cliente después del consumo total.
La composición del valor demuestra que en todo momento la empresa debe preocuparse por
la satisfacción del cliente con determinado producto.
Página 15
Según Carothers, Sander y Kirby (Citado en Colectivo de Autores, 1998, p. 18) "las empresas
que no suministren suficiente valor, por incapacidad o por propia decisión, serán eliminadas
selectivamente por los clientes"
Una de las maneras de agregar valor a un producto es mediante el desarrollo de un buen
servicio postventa que incluso, si es deficiente, puede afectar negativamente la opinión del
cliente y disminuir los niveles de las ventas.
Después de la venta una empresa no puede olvidarse de sus productos y servicios pues el
comportamiento de estos durante su uso o consumo y la percepción de los clientes al respecto
es imprescindible para la mejora continua de los procesos que desarrolla.
Como actividades posteriores a la venta se incluyen:
 Capacitación
 Instalación
 Mantenimiento
 Reparación
TIPO DE SERVICIO INDICADORES
Tiempo de respuesta.
Instalación Número de quejas.
Indicadores financieros.
Cumplimiento del plan
Mantenimiento
Número de quejas.
Porciento de casos solucionados.
Porciento de roturas técnicas solucionadas.
Índice de devoluciones.
Reparación
Valor (en dinero) de las devoluciones.
Número de quejas.
Tasa de fallo.
Roturas por mala operación.
Adiestramiento al
Reclamaciones originadas por desconocimiento del
cliente
cliente.
Tabla 1: Tipos de Servicio Postventa [10]
La percepción de calidad es la diferencia que existe entre las expectativas del cliente, que es
lo que este espera obtener como consecuencia de la prestación del servicio, y lo que en
realidad obtiene. La calidad tiene dos componentes:
 Calidad interna, relacionada con los aspectos técnicos - operativos del servicio.
Página 16
 Calidad externa, que es la evaluación que realizan los clientes de la forma en que se
realizó el servicio.
Estos dos componentes serán evaluados dentro del marco del proyecto, la calidad interna
estará comprometida con la calidad de la solución propuesta, el software a desarrollar y las
métricas y pruebas que serán realizadas. La calidad externa esta comprometida con los
servicios que se brindarán a los clientes y su mejoramiento con el proyecto dado, así mismo
el sistema proyecta tener un módulo de evaluación de calidad tanto del servicio como del
técnico hecho por el cliente externo, llevando esto analizar los datos recabados, implementar
planes de acción y mejorar la calidad del proceso en cuestión.
El fracaso de una empresa de servicio puede tener su origen en una inadecuada concepción
(calidad interna) o en la materialización de este diseño (calidad externa). Para lograr un
servicio postventa verdaderamente satisfactorio la empresa debe realizar una gestión de la
calidad que la asegure desde el punto de vista interno como externo.
Para gestionar la calidad en el proceso de servicio postventa se desarrollan acciones para

planificar, implementar, mejorar y controlar la calidad en este proceso.
Gráfico 2: Ciclo de Gestión de Calidad [8]
Página 17
2.2 Fundamentos teóricos sobre las tendencias y tecnologías actuales
La primera aplicación P2P (Peer-to-peer) fue Hotline Connect, desarrollada en 1996 para el
sistema operativo Mac OS. Pretendía ser una plataforma de distribución de archivos
destinada a empresas y universidades, pero no tardó en servir de intercambio de archivos de
casi todo tipo.
La evolución de las apps se dio rápidamente gracias a las innovaciones en tecnología WAP y
la tecnología EDGE a través de la transmisión de data y su conexión a internet. Eso propicio
un desarrollo muy fuerte de los celulares. Y permitió un mayor desarrollo en las aplicaciones
ya existentes. Hoy estamos en un momento de “boom” de aplicaciones para celulares.
Conforme la tecnología móvil avanza, igualmente las aplicaciones hacen cada vez más uso de
los recursos del móvil para lanzar o relanzar sistemas móviles prácticos y útiles para el día a
día.
Resumiremos brevemente que es realmente una aplicación móvil: También conocida como
App es una aplicación informática diseñada para ser ejecutada en teléfonos inteligentes,
tabletas y otros dispositivos móviles. Habitualmente la podemos encontrar en plataformas de
distribución, operadas por las compañías propietarias de los sistemas operativos móviles.
(Android, iOS, BlackBerry OS, Windows Phone etc.) Existen aplicaciones móviles gratuitas
u otras de pago.
Claramente, los teléfonos móviles ya no son sólo teléfonos; se han convertido rápidamente en
agentes de datos integrados. Las implicaciones son amplias y significativas. La tecnología y
la amplia gama de aplicaciones que lanza determina cómo gestionar nuestras decisiones,
dispensar los servicios, proporcionar educación, monitorear nuestra salud, reaccionar
socialmente, control nuestra identidad, y vivir, literalmente, nuestro individuo vive en un
mundo cada vez más cyber público.
Las aplicaciones móviles, gracias a GPS, pueden localizar un dispositivo dentro del globo,
con lo cual las ubicaciones de los usuarios también se vuelven públicas. Esta tecnología, la
cuál será utilizada en nuestro proyecto mediante el uso del móvil inteligente, es un sistema
Página 18
que permite determinar en todo el mundo la posición de un objeto (una persona, un vehículo)
con una precisión de hasta centímetros (si se utiliza GPS diferencial), aunque lo habitual son
unos pocos metros de precisión. Para determinar las posiciones en el globo, el sistema GPS
está constituido por varios satélites que orbitan la tierra creando una red de satélites en todo el
globo, actualmente hay más de 30 satélites operativos y se planea lanzar satélites más
modernos y equipados en 2016. Al recibir una señal del móvil, el satélite marca una
referencia de ubicación, esto es confirmado por la marcación de otro satélite, siendo la
intersección de ambas el lugar probable donde sea el origen de la señal, con un tercer satélite
se mejora dicha precisión, y con un cuarto se puede llegar a una ajuste en metros de la
ubicación de la persona. Con ello se puede localizar el posicionamiento global de un objeto
mediante referencias geoespaciales, como latitud, longitud, altura, las cuáles en el día de hoy
son extensivamente usadas por el 95% de las aplicaciones móviles instaladas.
Junto con el GPS, muchas tecnologías y herramientas han ido saliendo, mejorando y
expandiéndose, con el fin de mejorar la vida de las personas, mejorar el rendimiento de las
tareas ejecutadas y facilitar el procesamiento de todos los datos con los cuales nos
enfrentamos día a día.
Una de estas es la IA (Inteligencia Artificial), la cual se describe como la capacidad de

razonar de un agente no vivo, en este caso de un equipo electrónico, mediante algoritmos de
programación y reglas bayesianas, las cuáles emulan las decisiones humanas frente a
situaciones específicas. En el proyecto, se usarán dicha herramienta para poder brindar un
sistema experto que pueda analizar los casos previos, aprender de ellos, y sugerir soluciones,
así como evaluar los técnicos mejor capacitados para la tarea, teniendo que razonar frente a
varias variables dentro de su razonamiento.
Otra a utilizar es la BI (Bussiness Inteligence o Inteligencia de Negocios). La inteligencia de

negocios utiliza los datos de una empresa, los analiza y los convierte en conocimiento con
valor, el cual permite la fácil toma de decisiones. Esto lo logra gracias a las diferentes
herramientas que han surgido junto con este campo, el cuál mediante procesos ETL
(Extracción, Transformación y Carga), permite el rápido análisis, comparación y
procesamiento de las grandes cantidades de datos para su uso y generación de valor para los
procesos de una empresa. En el proyecto, será usado este campo para la extracción de datos,
Página 19
análisis y generación de indicadores y reportes, los cuales tendrán información de valor para
el área y la gerencia, con el cuál se podrá tomar decisiones para la mejora y optimización del
área y los servicios que proporciona. [11]
La arquitectura relacionada a la conectividad con aplicaciones móviles se presenta a

continuación:
Gráfico 3: Arquitectura de un sistema móvil [13]
La expansión de las aplicaciones móviles se da en 6 aspectos, teniendo en cuenta los avances

en las plataformas y lenguajes usados como JAVA y potenciadores gráficos 3D. [12]
 Entretenimiento
 Marketing Móvil
 Compras Multicanal
 Navegación GPS
 Transacciones financieras
 Intranet móvil y aplicaciones
Hoy en día las aplicaciones móviles son comercializadas activamente y descargadas a cada
minuto por los consumidores, por lo tanto la industria de las aplicaciones móviles está en un
Página 20
creciente auge. Según Stephanie Baghdassarian, directora de investigación de Gartner, “A
medida que los teléfonos inteligentes crecen en popularidad y las tiendas de aplicaciones se
convierten en el foco de varios actores de la cadena de valor, más consumidores
experimentarán con descargas de aplicaciones. Los juegos siguen siendo la aplicación N ° 1,
y las compras móviles, redes sociales, servicios públicos y herramientas de productividad
siguen creciendo y atrayendo cada vez más dinero.”
Una aplicación puede ser libre porque el desarrollador está ofreciendo sin costo alguno la
descarga para el consumidor, sin embargo puede cargarle costos dentro de la aplicación.
También hay aplicaciones que son de uso gratuito, pero que cobran por bienes físicos que
puede haber entregado a través de la aplicación. Hay muchas aplicaciones que son gratuitas
para los usuarios y derivan sus ingresos de la publicidad.
Ingresos de las descargas de aplicaciones móviles en todo el mundo superó $4,2 billones
dólares en 2009 y crecerá a $ 29,5 billones a finales de 2013. Este pronóstico de ingresos
incluye el gasto del usuario final en las aplicaciones gratuitas con publicidad y las
aplicaciones pagados. Las aplicaciones gratuitas con publicidades son las que generarán casi
el 25 por ciento de los ingresos de las tiendas de aplicaciones móviles para el año 2013. [14]
En lo respectivo a la interacción móvil con el servicio central a brindar, se utiliza el servicio

web (Web Services). Desde hace algunos años, se presentó como una solución a los
problemas de comunicación entre servidores con diferentes lenguajes y plataformas. Los
servicios SOAP y Rest, fueron los servicios web más usados, siendo SOAP el primero en ser
utilizado e implementado en los diferentes servicios públicos y privados. El Web Service es
una tecnología que utiliza un conjunto de protocolos y estándares que sirven para
intercambiar datos entre aplicaciones que trabajan bajo lenguajes y plataformas diferentes. La
interoperabilidad se consigue mediante la adopción de estándares abierto las cuales son
reglamentadas y reguladas por las organizaciones OASIS y W3C.
Para que un aplicación móvil pueda comunicarse con un servidor central dentro de una
solución integral de servicio, existen varias métodos de conexión y de comunicación, una de
estas es el uso de servicios web para la interacción móvil-servidor central. La combinación de
servicio web y la tecnología de agentes móviles, hoy en día es la herramienta más usada para
Página 21
la interacción de una aplicación móvil y el aplicativo core central, integrándose con métodos
de seguridad y optimización de ancho de banda, se puede implementar soluciones en móviles
y web altamente funcionales, que mejoren los procesos de la empresa y los tiempos de
respuesta en sus actividades. [13]
Gráfico 4: Implementación de servicio web con aplicación móvil [13]
Página 22
3 OBJETO DE ESTUDIO
3.1 Organización Objetivo
3.1.1 Descripción de la organización objetivo
Unlimited Systems S.A.C es una empresa líder en el Perú y con experiencia a nivel mundial
que brinda soluciones integrales de detección y defensa, equipos médico y medio
ambientales. Son los representantes de SMITHS DETECTION, CEIA S.P.A., STI,
CROSSMATCH TECHNOLOGIES, y otras marcas líderes mundiales en el campo de la
Detección de Amenazas y Filtros de Seguridad. Brinda servicios técnico, operativo y
entrenamiento en todas sus líneas de negocio a nivel mundial y comercializa los diferentes
productos y equipos a nivel nacional.
3.1.2 Líneas de negocio
Unlimited Systems S.A.C ofrece al mercado nacional 3 líneas de negocio con toda la
experiencia e innovación que lo caracteriza:
 Detección y Defensa: Soluciones tecnológicas que permiten detectar rápidamente

cualquier tipo de amenaza. Identificación de sustancias químicas desconocidas,
sistemas con capacidad de detección de explosivos, narcóticos, contrabando,
mercancías peligrosas. Sistemas de Rayos X con la capacidad de inspeccionar
camiones, contenedores, automóviles, bultos de carga, maletas y personas con la
finalidad. Toda la gama de productos bajo esta línea de negocio puede identificar
mercancías peligrosas, contrabando, armas, drogas, explosivos, agentes químicos,
biológicos y radioactivos, patrimonio cultural y recursos naturales, entre otros. Todo
ello con rapidez, precisión y fiabilidad, optimizando los niveles de seguridad y
reduciendo los gastos por falsas alarmas, demoras, daños o pérdidas.
o Sistema de Inspección
Página 23
o Sistemas de Detección de Amenazas
o Sistemas de Identificación de Sustancias Desconocidas
o Sistemas de Integración y Monitoreo
 Médica: Soluciones en equipamiento científico y médico con tecnología de vanguardia.

Provee soluciones de equipamiento fijo, móvil y de alta precisión en aplicaciones de
cuidados críticos, intensivos, asistencia y monitoreo de pacientes, ambulancias y
laboratorios entre otros. Se cuenta con instrumentos portátiles para la identificación de
sustancias químicas desconocidas, además de una amplia variedad de equipos para
análisis elemental por XRF/XRD y microanálisis con la tecnología más avanzada y los
límites de detección más bajos en el mercado.
o Cuidados Vitales
o Administración de Medicación y Monitoreo de Paciente
 Medio Ambiente: Soluciones tecnológicas de vanguardia para el tratamiento de aguas

y la utilización de energías renovables. Se cuenta con soluciones para los diferentes
puntos nacionales, aún los más remotos, y para las diferentes escalas de necesitadas por
los clientes.
o Energías Alternativas
o Tratamiento de Aguas
3.1.3 Servicios ofrecidos
Unlimited Systems S.A.C ofrece el siguiente portafolio de servicios a todos sus clientes a
nivel mundial:
 Servicio de Ingeniería y Preparación de Proyectos:

o Elaboración de Estudios e Implementación de Proyectos
Cuenta con un área de estudios especializados para el diseño e implementación de
proyectos aplicados a sus diferentes líneas de negocio y elaborados tomando en
cuenta aspectos de ingeniería, operatividad y viabilidad financiera.
o Propuestas “Llave en Mano
Página 24
Ofrece la implementación de soluciones integrales que implican la disposición del
equipamiento, el personal y los servicios requeridos enfocados a las necesidades
específicas del cliente. El equipamiento puede ser por venta directa o las opciones
de financiamiento directo e incluso el alquiler del equipamiento requerido junto
con la operación y el soporte necesario.
o Integración de Tecnologías
Cuenta con soluciones de integración para el monitoreo permanente centralizado
orientado a la operación de sus equipos:
 Desarrollo de packs tecnológicos.
 Integración de tecnologías.
 Centros de monitoreo y control remoto.
 Servicio Técnico:
Se tiene un equipo de más de 50 ingenieros, técnicos y operadores a nivel nacional, con
cobertura de servicios para responder ante inconvenientes o consultas a nivel nacional
las 24 horas del día durante los 7 días de la semana, incluyendo feriados. Los técnicos
se encuentran entrenados, certificados y revalidados por el fabricante, lo que permite
garantizar la calidad y profesionalismo en el servicio. Dentro de servicio técnico se
incluye:
o Servicios de Instalación y Protocolos de Prueba
o Servicios de Mantenimiento Preventivo y Predictivo
o Servicios de Mantenimiento Correctivo
 Servicio de Operación:
Se cuenta con una amplia experiencia en la operación de las tecnologías que ofrecen al
mercado, habiendo demostrado índices superiores al 95% de operatividad en los
sistemas más demandados, sistemas de rayos X. Todos sus operadores son entrenados,
certificados y revalidados periódicamente para garantizar el uso correcto y maximizar
las capacidades de los sistemas ofrecidos.
 Servicio de Capacitación:
Página 25
Se cuenta con una estructura de entrenamientos, complementado con sistemas virtuales,
para lograr el desarrollo correcto de las capacidades del usuario, maximizando las
bondades de los equipos.
3.1.4 Productos Ofrecidos
Unlimited Systems S.A.C comercializa y da soporte técnico y operativo a los siguientes

equipos agrupados por tecnología:
 Rayos X:
Son los equipos de mayor servicio en la empresa, siendo representantes de Smiths
Detection en el país. Esta tecnología de procesamiento de imágenes y detección de
radiación genera instantáneamente excelentes imágenes de los objetos escaneados
mientras mantiene el nivel más alto posible de seguridad del operador (extremadamente
baja dosis de radiación). La función de discriminación de material permite una
representación de color casi real de diferentes materiales empacados, permitiendo al
operador distinguir fácilmente diferentes tipos de materiales desde naranja (orgánico)
hasta azul (materiales pesados).
o HS 6040i, HS 7555, HS 9075, HS 100100V, HS 100100T, HS 145180, HS
180180, HS CAB 250250, HCVG, HCVM, HCVP, HCVe, HS 100100V-2is, HS
100100T-2is, HS 180180-2is, HS 145180-2is, HS 250250-2is, BSCAN FB,
BSCAN DV, HS 10080 EDtS, HS 10080 EDX-2is, HS 10080 XCT
 Ondas Milimétricas:
Las ondas milimétricas poseen la propiedad única de pasar transparentemente a través

de materiales ligeros tales como las telas de la ropa. Esta propiedad se usa en escáneres
de onda mm que se aplican principalmente en sistemas de detección de objetos ocultos
(presencias de armas y contrabando).
o EQO
 Espectrometría de Movilidad de Iones:
Página 26
Tecnología usada para la detección de agentes químicos y explosivos.
o IONSCAN 500DT, SABRE 5000, MMTD, LCD 3.2E, LCD 3.3, LCD-NEXUS
 Espectrometría de Infrarrojo por Transformada de Fourier:

La tecnología FTIR facilita la rápida evaluación de una amplia variedad de amenazas
químicas incluyendo agentes de guerra química, explosivos, químicos industriales
tóxicos, pesticidas, narcóticos y polvos blancos comunes.
o HAZMAT ID 360, HAZMAT ID ELITE, HAZMAT ID RANGER
 Cromatografía de gases / Espectrometría de Masa (GS/MS):

o GUARDIAN
 Espectroscopia de Rayos Gamma:

o RADSEEKER
 Raman:
o RESPONDER RCI
3.1.5 Trayectoria Empresarial
Unlimited Systems S.A.C ha ganado una gran cantidad de clientes en base a su experiencia
en ventas y servicios, no sólo en Latinoamérica, sino en todo el mundo, especialmente en
zonas de alto riesgo. Los especialistas de Unlimited-Systems son continuamente solicitados
para instalar y dar soporte técnico a los equipos de las distintas tecnologías que representan,
contando con una cobertura nacional e internacional.
3.2 Misión
“Proveer soluciones integrales en el ámbito de la seguridad, protección y desarrollo

comercial, comprendiendo las necesidades del cliente y proponiendo acciones concretas para
Página 27
satisfacerlas en forma completa, todo esto con el compromiso de éxito de sus trabajadores y
la innovación tecnológica permanente.”
3.3 Visión
“Ser la empresa líder a nivel nacional con los productos y servicios que ofrecemos en materia
de seguridad, protección, innovación tecnológica y conservación del medio ambiente.”
3.4 Objetivos Estratégicos
 Incrementar las ventas de equipos y servicios en un 20%
 Fortalecer el área de Marketing en la empresa y atraer nuevos clientes.
 Elevar la atención de calidad en los puntos de operaciones por encima del 90% de
satisfacción
 Mejorar en un 30% la atención de servicio al cliente.
 Incrementar los puntos de servicio técnico y laboratorios en Provincias.
 Optimizar los procesos de servicio técnico y soporte en un 40%
 Mejorar la productividad del personal en un 20%.
3.5 Organigrama
Página 28
Gráfico 5: Organigrama de la empresa Unlimited-Systems [elaboración propia]
Página 29
4 CAMPO DE ACCIÓN
4.1 Breve Descripción
El proyecto se centrará en el área de Tecnología, el cuál realiza el proceso de. El rubro de la

empresa Unlimited-Systems SAC es la comercialización y servicio de las máquinas que
ofrece al mercado, para lo cual todas las áreas apoyan tanto directa como indirectamente a
este fin.
A continuación se detalla el mapa de procesos general de la empresa.
Gráfico 6: Mapa de Procesos General [elaboración propia]
Página 30
Como muestra el gráfico, el flujo básico de trabajo de la empresa es la comercialización de
los productos y/o servicios que ofrece.
El campo de acción en el cuál se enfoca el proyecto es “Gestión de Soporte Técnico” el cuál

es realizado por el área de Tecnología. Dentro del área de tecnología se manejan dos áreas
funcionales, campo y laboratorio. El área de campo se encarga de todos los servicios de
campo, como instalación, mantenimiento, reparación in situ, capacitación, etc. El área de
laboratorio se encarga del diagnóstico, mantenimiento y reparación de piezas y equipos,
mayormente de los equipos transportables medianos y pequeños.
4.2 Procesos del Negocio
El campo de acción de este proyecto es el de Gestión de Soporte Técnico, el cual contiene

todos los servicios brindados por el área de tecnología a los clientes de la empresa. Estos
servicios son asignados como casos dentro del área, cada caso de servicio está ligado al
paquete de servicios contratado por un cliente, pudiendo dentro del mismo caso haber varios
servicios de mantenimiento preventivo/complementario/correctivo, instalaciones nuevas y
capacitaciones. Los equipos en garantía tienen ilimitados mantenimientos correctivos y
mantenimientos preventivos/complementarios cada 3 meses. El tipo del mantenimiento es
intercalado comenzando siempre por mantenimiento complementario. Los contratos son
gestionados por el área Comercial, sin embargo, el área de Tecnología mantiene el registro
de los contratos asociados a los clientes y equipos para su control de los servicios.
El proceso comienza cuando el área de tecnología recibe una solicitud de servicio vía correo
de alguna área (especialmente comercial y operaciones) o una llamada de servicio del cliente,
este servicio puede ser por una instalación, un correctivo, preventivo, diagnostico o
capacitación, algunas veces el cliente tiene a la mano el código de error y el log de errores
dado por el mismo equipo (Sólo equipos Hitrax). El coordinador verifica que el equipo tenga
garantía vigente, si no lo tiene, deriva la solicitud al área comercial para que coticen el costo
del servicio.
Página 31
Una vez aceptado la cotización, o si esta con garantía vigente, el coordinador de servicio,
ingresa los datos de la solicitud en un archivo Excel y lo registra con un código único
correlativo, luego se pone en contacto con el cliente para pactar una fecha y hora para el
servicio.
Durante el inicio del día, el Gerente de Tecnología planifica todos los servicios a realizar en
el transcurso del día. El supervisor de servicio, detalla los servicios del día y asigna a los
técnicos que realizarán dichos servicios, junto con los horarios establecidos para cada
servicio. El coordinador de servicio para cada servicio genera una orden de servicio,
registrando los técnicos a participar, así mismo asigna las tarifas para la movilidad de los
técnicos.
El técnico recibe la orden de servicio, verifica los materiales a usar y se dirige a realizar el
servicio en la fecha y hora pactada. El técnico, luego de hacer el servicio llena el reporte de
servicio y el acta de conformidad, el cliente firma los documentos, quedándose con una copia
de cada documento.
Al regresar el técnico a la oficina, este elabora el informe técnico, escanea el reporte y el acta
firmado por el cliente, y lo adjunta al informe. Luego, coloca el documento en una carpeta
dentro del servidor del área con el número del caso de servicio. El supervisor del área, revisa
el informe colgado en el servidor y le da su aprobación colocando el documento en otra
carpeta de “revisados” dentro del mismo servidor.
Finalmente, el coordinador revisa los casos “revisados” dentro del servidor, registra los datos
en la hoja Excel concluyendo el caso, imprime los documentos y los archiva en el file del
cliente. Después, pasa el informe a la carpeta “Final” dentro del servidor a modo de historial
y el caso de servicio termina. El informe es luego enviado al cliente mediante correo
electrónico adjuntando el escaneado de los reportes de servicio firmados
A continuación se detalla el flujo de tareas que forman parte del proceso.
Página 32
Gráfico 7: Flujo de tareas del proceso del área [elaboración propia]
Página 33
4.3 Sistemas automatizados vinculados con el campo de acción
El área de Tecnología no cuenta con algún sistema automatizado que ayude a los procesos
manuales de atención de casos. Todos los casos de servicio son almacenados en un archivo
Excel maestro con todos los campos necesarios para su detalle.
Sin embargo, los equipos Hitrax, el cuál es el nombre del equipo central de los equipos
SMITH de rayos X modelos HS, cuentan con una tarjeta de red, la cuál conectada a una red
LAN local, es capaz de enviar a una carpeta compartida dentro de una red LAN, tanto las
imágenes escaneadas a tiempo real (en formato .jpg) así también como los archivos log de
errores .log, ayudando esto a su diagnóstico al momento de la intervención.
Así mismo, el área cuenta con documentos impresos predefinidos para las órdenes de servicio
y los reportes de servicio; y con un servidor propio con licencia Microsoft Server, en el cuál
almacenan todos los informes digitales y los reportes escaneados de a cada caso de servicio
terminado.
Página 34
5 ANÁLISIS CRÍTICO DE LOS PROBLEMAS DE INFORMACIÓN
5.1 Situación problemática y Problemas a resolver
La situación problemática que presenta el área de Tecnología se centra en la gestión de los

servicios atendidos por el área, así como en los procesos manuales que realiza. No se cuenta
con una centralización óptima de los datos ni con un análisis efectivo de los casos atendidos.
Así mismo, muestra una falta de indicadores y reportes que ayuden al área a llegar a los
objetivos y metas establecidos por la empresa.
A continuación se detallan la situación problemática y los problemas encontrados en el área
de tecnología
Situación Problemática Problema a Resolver
El procedimiento para la generación de casos es de forma
manual, llenando un archivo excel, esto con lleva en una
demora en su creación y asignación, y por ende en la atención
del cliente
Se comenten errores en la correlación de números de caso,
esto provoca a una falta de control y dificultan el seguimiento
y consulta de los casos
Las observaciones y recomendaciones no se registran en el
archivo central, sólo en el informe físico, dificultando su
busqueda rápida al momento de la atención
El proceso de generación de orden de servicio es manual,
llenando un documento físico, demorando en la atención total No existe una gestión, seguimiento, monitoreo y
del servicio y teniendo problemas en el llenado control adecuado de los casos de servicio
No se tiene buen control del estado de los casos de servicio,
esto se realiza de forma manual. No hay una registro físico
del estado del caso, esto causa una deficiencia en el
seguimiento de los casos y una demora sustancial en la
atención de consultas de los clientes
No hay un seguimiento ni un control del estado de los
informes de los servicios, dificultando su monitoreo y
provocando demoras y mala imagen del servicio al cliente
El seguimiento de los casos de servicio se realizan de forma
manual, haciendo dificil su control y demora en su
actualización o reprogramación
Falta de conocimiento previo sobre un equipo al momento de
realizar un servicio, esto conlleva a demora en la atención del
servicio, teniendo que esperar a una comunicación y consulta
del problema con la central
No se cuenta con información histórica de los casos
Falta de análisis de datos previos sobre los casos realizados y
de servicio ni de los equipos atendidos
sus observaciones, esto lleva a que el técnico no cuente con
un historial previo de problema al cuál se enfrentará, teniendo
que volver a buscar la solución al problema, demorando más
tiempo en su resolución de lo esperado Página 35
La consulta de casos y su historial es de forma manual,
demorando en la atención del servicio y en las consultas hecha
por los técnicos al momento del servicio
La busqueda de garantía de un equipo es de forma manual,

demorando en la decisión de si un equipo cuenta o no con
Demora en la generación y atención de casos de
garantía, demorando la atención, o pudiendo atender un
servicio y demora en la consulta de garantía de los
equipos sin tener garantía
casos de servicio y de sus equipos relacionados
Los documentos electrónicos, escaneados y fotos, no son
compartidas fácilmente a cualquier interesado del área, esto
lleva a que los técnicos de campo no cuenten con un
conocimiento previo de soluciones pasadas, de los equipos
previo al problema, o datos de servicios pasados que puedan
ayudar a solucionar el problema existente.
Los servicios son programados de forma manual, y
frecuentemente es olvidado por los técnicos, llevando a quejas
de los clientes por la tardanza en su atención y mancillando la
No existe un calendario de programación de los
imagen de la empresa
mantenimientos a ejecutar, de las tareas asiganadas
Falta de alertas o programación de calendarios que permita
ni de los servicios ejecutados, tampoco existen
mantener un control de los mantenimientos a realizar, esto
alertas que permitan dar seguimiento y recordar las
lleva a que los mantenimientos rutinarios por contrato sean
tareas a realizarse
olvidados o programados a técnicos con a tareas ya
asignadas, llevando a una demora u olvido del servicio y por
ende a quejas de parte del cliente
No existe lista de partes o piezas de reparación para cada
tipo de equipo, dificultando la pronta solución y reparación del
Inadecuado manejo de inventario de equipos y
equipo, demorando en la entrega del equipo al cliente
piezas asociadas a esta por equipos, tampoco existe
Lista de equipos inventariados no es actualizada
un adecuado control del estado de garantía de los
oportunamente, llevando a atender equipos que estan fuera de
equipos a los que se da servicio
alcance del contrato del cliente o atendiendo equipos que no
estan dentro de un contrato formal
No hay control sobre las tarifas y gastos en transporte de los
técnicos, esto produce sobregastos en los recursos y budgets
del area, afectando el desempeño del área y las decisiones de
la gerencia
No hay control de asignación de tareas a cada técnico
disponible, llevando a malentendidos en su planificación, doble
asignación de tareas o cruces entre técnicos, lo cuál conlleva
en un retraso en la atención del servicio
No hay un control sobre la ubicación actual del técnico al
Inadecuado manejo de los recursos del área, falta
momento de realizar un servicio, teniendo que esperar a que el
de control sobre los técnicos al momento de realizar
técnico regrese a la oficina para que pueda programarse otra
el servicio e inadecuado seguimiento de sus tareas y
visita, conllevando en demora en la atención y sobrecostos en
de los gastos producidos por los servicios atendidos
el transporte
Se producen cruces de tareas entre los técnicos o se asignan
más técnicos de lo necesario para el servicio, haciendo que
otros servicios se tengan que atrazar en su atención por falta
de organización y control de asignaciones
Falta de control de las herramientas de los técnicos,
constantemente se paran perdiendo, causando gastos extra de
reposición y haciendo que al atender el servicio no se tenga
los materiales adecuados para una atención de calidad Página 36
No existe indicadores de rendimiento de los técnicos para la
mejora continua del área, no tienen indicadores de
productividad o eficiencia de los técnicos, esto evita que
puedan percatarse de problemas de atención, baja
productividad del personal técnico, afectando la imagen de la
empresa frente a los clientes No se cuenta con información de rendimiento,
productividad y eficiencia de los técnicos, tampoco
No existe un indicador sobre los tiempos de atención de los
existe indicadores sobre las fallas, tiempos de
servicios ni la demora entre el inicio y fin del servicio, evitando
respuesta o atenciones de los servicios que puedan
que pueda mejorarse el servicio o el tiempo de atención al no
dar sustento a los planes de acción del área para el
tener conocimiento de los tiempos y la calidad del servicio
mejoramiento del servicio al cliente
Falta de indicadores y estadísticas de fallas de los equipos y
servicios realizados para tomar acciones de control al
respecto, esto evita tener un monitoreo y control de los
equipos que más fallan, las fallas más comunes, produciendo
continuas molestias a los clientes por fallas recurrentes
No se puede establecer comunicación con la oficina central al
momento de la ejecución de servicio, esto produce que los
técnicos no puedan comunicarse facilmente con la central para
ayuda, consulta o reprogramaciones, teniendo que regresar a
la oficina, esto produce que las atenciones se demoren días y
causando molestias por el paro del equipo al cliente
Cualquier reprogramación o incidencia durante el servicio se

No hay posibilidad de acceder a los datos
debe esperar a la llegada a la oficina para ser registrada,
existentes en la oficina sobre los servicios, fallas,
produciendo demora en la atención y/o en la reprogramacion
historial o manuales cuando se encuentran fuera de
del servicio
la oficina
Falta de revisión de datos de equipos o casos asociados
cuando se encuentran en servicio de campo, produciendo una
demora en la atención debido a la imposibilidad de poder
consultar datos anterior o manuales de los equipos al
momento de la atención, teniendo que programar otra visita
para dar finalizado la atención, causando malestar al cliente y
causando una mala imagen de la empresa en el servicio
técnico
No existen reportes de estado de equipos, atención a clientes
o productividad de técnicos, esto hace que la gerencia y las
diferentes áreas no puedan tener reportes de las atenciónes,
fallas y servicios que se realizan a sus clientes, también
dificulta llevar un control de la eficiencia de los técnicos para
No se cuenta con reportes que faciliten la toma de
poder tomar decisiones de contratación o capacitaciones al
desiciónes para la mejora del área, tampoco hay
área
reportes que ayuden a las diferentes área en sus
Los reportes solicitados sobre el rendimiento, atención y procesos o planes de acción, más para el área
servicios del área son realizados manualmente, produciendo comercial y sus realaciones con los clientes
una demora de días en poder recabar la información solicitada
por gerencia o por comercial de sus clientes, esto a su vez
produce una demora en la toma de decisiones frente a nuevos
contratos o en las relaciones con los clientes ya existentes
Página 37
Tabla 2: Situación Problemática vs Problema a Resolver [elaboración propia]
El sistema informático deberá poder gestionar de manera eficiente las tareas y servicios que
son ejecutados por el área, llevando un control de los casos y el seguimiento hasta el final,
deberá mandar alertas de servicios y mantener un calendario de programación de
mantenimiento y servicios.
Permitirá un adecuando manejo de los técnicos, asignará automáticamente a los técnicos que
realizarán los servicios programados, con esto se evitará cruces de tareas. Asignará de forma
automática las rutas más económicas a seguir para el servicio de atención, así se tendrá
registrado los gastos por transporte y el consumo del móvil propio de la empresa.
El sistema será una plataforma web y móvil con la cual se podrá acceder a ella desde
diferentes dispositivos, sea PC o, Tablets o Smartphones (para el caso de la parte móvil),
integrará una desarrollo para móviles con el cuál se pretende dar un seguimiento a los
técnicos al momento de cumplir sus servicios reportándole su ubicación en un determinado
tiempo; los técnicos podrán acceder a este herramienta para consultar, para reportar
incidencias durante el servicio. Podrán registrar su inicio y fin de actividades, se les facilitará
la obtención de la serie por lectura de código de barras para mejor identificación y podrán
cargar las fotos tomadas del servicio para envío en línea a la oficina central.
A su vez podrán manejar sus atenciones de servicio, el control y seguimiento de sus servicios,
y podrán incluso realizar un chat en línea con la oficina para ayuda inmediata, así mismo se
podrá mantener la ubicación del técnico durante sus tareas, con el cuál se podrá reprogramar
más adecuadamente las tareas asignadas. Todo esto para optimizar los tiempos de servicio,
mejorar la atención del cliente y utilizar las últimas herramientas tecnológicas en la mejora
del proceso.
Así mismo, el sistema permitirá un completo y eficiente manejo de la relación de los equipos
a dar servicio, pudiendo acceder fácilmente al historial de equipos, datos necesarios,
manuales, casos previos, contratos asociados y toda información necesaria para los servicios
y la gestión. Se enviará periódicamente el estado de los equipos al cliente, así como el
proceso que está llevando su pieza de repuesto desde su pedido, envío, aduana y reparación.
Página 38
Conjuntamente, el sistema al recopilar y centralizar todos los datos, podrá analizar y mostrar
cuadros comparativos de datos de equipos, el sistema podrá sugerir posibles soluciones a los
problemas más frecuentes reportados, pudiendo incrementar su sugerencias en base a los
diferentes casos reportados, a su vez;, mostrará indicadores de fallas de equipos, tiempo entre
fallas, fallas frecuentes; e indicadores de rendimiento de los técnicos, de los clientes y de los
servicios realizados, así como cuadros estadísticos de los casos y servicios atendidos, también
podrá mostrar reportes del rendimiento del área (clientes, técnicos, servicios, etc),
imprimirlos y descargarlos, con lo cual se ayudará para la mejora de decisiones y el alcance
de metas y objetivos del área.
Página 39
6 CONCLUSIONES
 El área de tecnología presenta varios problemas dentro de las diversas actividades que
realiza lo cual agrava la productividad del área y la atención del servicio, provocando
esto demoras en la atención y sobrecostos operativos.
 La empresa cuenta con objetivos estratégicos que trazan las metas a alcanzar, para lo
cual es necesario el desarrollo de un sistema de gestión que ayude al proceso de soporte
técnico y solucione la situación problemática encontrada.
 Se han podido identificar los problemas que presenta el área de tecnología con sus
respectivas causas, las cuales se buscará resolver con el presente proyecto.
Página 40
CAPÍTULO 2: PROPUESTA DE SOLUCIÓN
1 INTRODUCCIÓN
En el presente capítulo se expone el objetivo general del proyecto, así como los objetivos
específicos y su fundamentación en base a los problemas detallados anteriormente.
Adicionalmente, se presenta los beneficios para la empresa que tiene el presente proyecto.
También se explora otras soluciones existentes en el mercado y se hace una comparación con
la solución propuesta. Finalmente, se detallan las tendencias tecnológicas y las tecnologías
propuestas para el desarrollo del presente proyecto.
2 OBJETIVOS DEL PROYECTO
2.1 Objetivo general
Desarrollar un sistema web y móvil que permita gestionar, controlar, monitorear y dar
seguimiento a los servicios que brinda el área de tecnología, optimizar los recursos del área
para su mejor eficacia y productividad, presentar alertas e indicadores de rendimiento que
permita optimizar los recursos y las tareas ejecutadas por el área, todo esto cumpliendo con
los estándares de calidad y tiempo requeridos.
2.2 Objetivos específicos
 El sistema debe poder generar los reportes de órdenes de servicio y los inventarios de
equipos atendidos.
 El sistema debe almacenar los datos, reportes, casos, manuales, fotos y todo tipo de
información útil y relacionada con los servicios prestado a los clientes, todo de forma
centralizada y a disposición tanto para la interfaz web como móvil.
Página 41
 El sistema debe poder gestionar los clientes que tiene el área, mantendrá el control de
los contratos vigentes y los equipos relacionados con su garantía respectiva, mejorando
así la eficacia de atención a los clientes.
 El sistema debe manejar eficientemente el registro de los equipos a dar servicio, así
como las consultas en línea para su historial, casos asociados, manuales, contratos, etc.
 El sistema contará con seguridad de inicio de sesión y segregación de roles para la
revisión de los informes y el seguimiento adecuado de los servicios.
 El sistema debe permitir conectarse al servidor del área para poder acceder a los
informes técnicos y escaneos de los casos pasados.
 El sistema debe generar indicadores de rendimiento de los técnicos, indicadores de
fallas e indicadores que faciliten la auditoría y mejora continua en las tareas del área.
 El sistema debe mandar alertas de próximos mantenimientos y pérdida de garantías de
equipos para facilitar el trabajo de seguimiento de trabajos.
 El sistema debe poder optimizar las rutas de trabajo de los técnicos al momento de
asignar sus rutas de trabajo, eligiendo la ruta más corta para varios puntos de servicio.
 El sistema debe poder leer los códigos de barras de los equipos para su correcta
identificación, adjuntar fotos y fallas de los equipos, actualizando el reporte de servicio
desde el móvil.
 El sistema debe ayudar en la gestión, consulta, registro, modificación e impresión de
los casos de servicio, evitando errores de codificación o duplicados.
 El sistema debe permitir reducir la documentación física en más de un 70% y el uso de
tablas Excel.
 El sistema debe poder reducir los tiempos generación de casos de servicio, y mejorar el
tiempo total de atención de servicio, optimizando el manejo del personal con el que
cuenta el área.
 El sistema debe tener una interfaz de solicitud y consulta de servicio para el cliente, por
el cual podrá estar informado del servicio brindado.
 El sistema mostrará una interfaz de monitoreo para el cliente, siempre que sus equipos
Hitrax estén conectados a una red LAN, por el cual podrá ver de forma centralizada las
imágenes escaneadas a tiempo real de los equipos y se guardará los logs generados por
los equipos al momento de un error.
Página 42
 El sistema permitirá la carga de los archivos logs de errores de los equipos, facilitando
así su diagnóstico al verificar los datos del archivo, el código de error y los parámetros
indicados en el archivo.
 El sistema debe poder asignar a técnicos para los casos generados, teniendo en cuenta
los servicios previos, su experiencia y nivel de competencia.
 El sistema enviará y centralizará encuestas sobre los servicios realizados y los técnicos
a los clientes, analizará los datos, y deberá generar cuadros estadísticos en base a los
resultados recabados.
 El sistema debe ser accesible desde plataformas móviles para consultas, registro, carga
de archivos y chat en línea.
 El sistema debe permitir al técnico informar los estados y avances de los servicios, así
como también los informes detallados de los servicios realizados.
 El sistema debe poder verificar la ubicación de los técnicos y registrar su ingreso y
salida de atención, así como asignar reprogramaciones en línea y alertas a su móvil.
 El sistema debe mostrar los posibles problemas y soluciones de acuerdo a datos de
servicios pasados, y que esta base de conocimiento se incremente conforme se registran
nuevos casos.
 El sistema debe generar reportes gerenciales de acuerdo a los clientes y servicios
realizados, también de la productividad de los técnicos, para ayudar en la toma de
decisiones y acciones.
 El sistema debe poder generar reportes personalizados usando los datos centralizados,
guardar las plantillas generadas y exportar los datos y tablas necesarias para el análisis
de los datos.
 El sistema debe poder gestionar, listar y mantener un reporte de las herramientas usadas
por el técnico durante cada servicio que realiza.
 El proyecto debe generar los manuales de usuario y la documentación de pruebas
realizadas.
 El proyecto debe estar realizado dentro del cronograma establecido y bajo el
presupuesto asignado.
Página 43
2.3 Fundamentación de los objetivos
Los objetivos específicos descritos en la sección anterior se escogieron porque su

cumplimiento permitirá mejorar la calidad del proceso de gestión de postventa de la empresa.
A continuación se detalla las relaciones de los problemas encontrados los cuáles serán
solucionados con el cumplimiento de los objetivos descritos.
Problema a Resolver Objetivos Específicos
El sistema debe permitir reducir la documentación física en

mas de un 70% y el uso de tablas Excel.
El sistema debe ayudar en la gestión, consulta, registro,

modificación e impresión de los casos de servicio, evitando
errores de codificación o duplicados.
El sistema debe poder leer los códigos de barras de los

equipos para su correcta identificación, adjuntar fotos y fallas
de los equipos, actualizando el reporte de servicio desde el
No existe una gestión, seguimiento, monitoreo y móvil.
control adecuado de los casos de servicio
El sistema debe poder generar los reportes de órdenes de

servicio y los inventarios de equipos atendidos.
El sistema debe permitir al técnico informar los estados y

avances de los servicios, así como también los informes
detallados de los servicios realizados.
El sistema contará con seguridad de inicio de sesión y
segregación de roles para la revisión de los informes y el
seguimiento adecuado de los servicios
El sistema debe mostrar los posibles problemas y soluciones
de acuerdo a datos de servicios pasados, y que esta base de
conocimiento se incremente conforme se registran nuevos
casos.
El sistema permitirá la carga de los archivos logs de errores de
los equipos, facilitando así su diagnóstico al verificar los datos
No se cuenta con información histórica de los casos
del archivo, el código de error y los parámetros indicados en
de servicio ni de los equipos atendidos
el archivo.
El sistema debe almacenar los datos, reportes, casos,
manuales, fotos y todo tipo de información útil y relacionada
con los servicios prestado a los clientes, todo de forma
centralizada y a disposición tanto para la interfaz web como
móvil.
Página 44
El sistema debe poder gestionar los clientes que tiene el área,
mantendra el control de los contratos vigentes y los equipos
relacionados con su garantía respectiva, mejorando así la
eficacia de atención a los clientes
El sistema debe tener una interfaz de solicitud y consulta de

servicio para el cliente, por el cuál podrá estar informado del
servicio brindado.
Demora en la generación y atención de casos de
servicio y demora en la consulta de garantía de los El sistema mostrará una interfaz de monitoreo para el cliente,
casos de servicio y de sus equipos relacionados siempre que sus equipos Hitrax estén conectados a una red
LAN, por el cual podrá ver de forma centralizada las imágenes
escaneadas a tiempo real de los equipos y se guardará los logs
generados por los equipos al momento de un error.
El sistema debe poder reducir los tiempos generación de casos

de servicio, y mejorar el tiempo total de atención de servicio,
optimizando el manejo del personal con el que cuenta el área.
No existe un calendario de programación de los

mantenimientos a ejecutar, de las tareas asiganadas El sistema debe mandar alertas de próximos mantenimientos y
ni de los servicios ejecutados, tampoco existen pérdida de garantías de equipos para facilitar el trabajo de
alertas que permitan dar seguimiento y recordar las seguimiento de trabajos.
tareas a realizarse
Inadecuado manejo de inventario de equipos y

El sistema debe manejar eficientemente el registro de los
piezas asociadas a esta por equipos, tampoco existe
equipos a dar servicio, así como las consultas en línea para su
un adecuado control del estado de garantía de los
historial, casos asociados, manuales, contratos, etc.
equipos a los que se da servicio
El sistema debe poder optimizar las rutas de trabajo de los

técnicos al momento de asignar sus rutas de trabajo, eligiendo
la ruta más corta para varios puntos de servicio.
El sistema debe poder verificar la ubicación de los técnicos y

Inadecuado manejo de los recursos del área, falta registrar su ingreso y salida de atención, así como asignar
de control sobre los técnicos al momento de realizar reprogramaciones en línea y alertas a su móvil.
el servicio e inadecuado seguimiento de sus tareas y
de los gastos producidos por los servicios atendidos El sistema debe poder asignar a técnicos para los casos
generados, teniendo en cuenta los servicios previos, su
experiencia y nivel de competencia.
El sistema debe poder gestionar, listar y mantener un reporte

de las herramientas usadas por el técnico durante cada servicio
que realiza.
Página 45
El sistema debe generar indicadores de rendimiento de los
técnicos, indicadores de fallas e indicadores que faciliten la
auditoría y mejora continua en las tareas del área.
No se cuenta con información de rendimiento,
productividad y eficiencia de los técnicos, tampoco
existe indicadores sobre las fallas, tiempos de
respuesta o atenciones de los servicios que puedan
dar sustento a los planes de acción del área para el El sistema enviará y centralizará encuestas sobre los servicios
mejoramiento del servicio al cliente realizados y los técnicos a los clientes, analizará los datos, y
deberá generar cuadros estadísticos en base a los resultados
recabados.
El sistema debe permitir conectarse al servidor del área para

poder acceder a los informes técnicos y escaneos de los casos
pasados.
No hay posibilidad de acceder a los datos

existentes en la oficina sobre los servicios, fallas,
historial o manuales cuando se encuentran fuera de
la oficina
El sistema debe ser accesible desde plataformas móviles para
consultas, registro, carga de archivos y chat en línea.
El sistema debe generar reportes gerenciales de acuerdo a los

clientes y servicios realizados, también de la productividad de
los técnicos, para ayudar en la toma de decisiones y acciones.
No se cuenta con reportes que faciliten la toma de
desiciónes para la mejora del área, tampoco hay
reportes que ayuden a las diferentes área en sus
procesos o planes de acción, más para el área
comercial y sus realaciones con los clientes El sistema debe poder generar reportes personalizados usando
los datos centralizados, guardar las plantillas generadas y
exportar los datos y tablas necesarias para el analisis de los
datos.
Página 46
Tabla 3: Problema a Resolver vs Objetivos Específicos [elaboración propia]
2.4 Indicadores de logro de los objetivos
Para poder verificar el cumplimiento de los objetivos definidos anteriormente, se presentan

los indicadores que validarán su cumplimiento. Por ser un proyecto de tesis de Ingeniería de
Sistemas, la gran cantidad de los objetivos son validados por las pruebas unitarias que serán
realizadas por los usuarios claves en la presentación de la 1ra versión del sistema.
A continuación se listan los indicadores para el presente proyecto.
Indicador Definición Frecuencia Fuente

Prueba de la 1ra versión del sistema a los
Presentación de la 1ra version del sistema - Sistema Web
usuarios claves
Prueba del estado de comunicación y acceso
Pruebas de comunicación movil - Sistema Movil
del sistema con los dispositivos moviles
# total de documentación física que es Reporte de
Número de documentación física en el proceso Mensual
utilizada luego de desarrollado el sistema Tecnología
Número de errores de código en los casos de # total de errores en los códigos de Reporte de
Mensual
servicio generación de casos de servicio Tecnología
Sumatoria de Tiempos de Ejecución en los Reporte de
Tiempo promedio de ejecución del servicio Mensual
Servicios / todos los servicios del mes Tecnología
Sumatoria de Tiempos de atención de todo el Reporte de
Tiempo promedio de atención total al cliente Mensual
proceso/ todos los servicios del mes Tecnología
Presentación de documentación de modelado y Presentación de toda la documentación Documentos del
Una vez
diseño del sistema relativa al proyecto de desarrollo del sistema proyecto
Presentación del acta de aceptación donde
Documentos del
Actas de aceptación del beneficiario certifica la conformidad del beneficiario al Una vez
proyecto
sistema
Tabla 4: Indicadores de los objetivos del proyecto [elaboración propia]
Página 47
3 BENEFICIOS DEL PROYECTO
3.1 Beneficios tangibles
 Los beneficios tangibles del proyecto están relacionados con los indicadores
presentados en la sección 2.4, los cuáles detallan la documentación pertinente al
proyecto, así como indicadores de reducción de los tiempos de atención y de ejecución
de las tareas.
 La reducción de toda la documentación en más de un 70%, al ya no tener que manejar
ordenes de servicio y reportes técnicos por escrito, teniendo todos los datos necesarios
centralizados en un sistema y los reportes a la mano para su generación.
 Se obtendrá reportes gerenciales e indicadores estadísticos con una rapidez de
elaboración y generación de un par de segundos, a comparación de las horas-hombre
que se utiliza actualmente, lo cual ayudara al análisis por parte de los encargados del
área y a la mejora en la toma de decisiones al momento de emprender una mejora en los
procesos del área.
3.2 Beneficios intangibles
En los beneficios intangibles del proyecto se puede mencionar:

 Se formarán tecnológicamente todos los usuarios del sistema, debido a la gran
interacción que habrá para la gestión del proceso; los usuarios del área incrementarán
sus conocimientos en el uso de las nuevas tendencias tecnológicas lo cual mejorará la
productividad del área y las competencias del usuario.
 Se mejorara la imagen institucional de la empresa con cara a los clientes, gracias a la
mejora en la ejecución de sus tareas y los servicios que proporcionara al cliente. Se
reducirá las quejas, mejorando los lazos comerciales y de confianza entre sus clientes.
Página 48
4 ANTECEDENTES
4.1 Soluciones encontradas
A continuación se describe 2 soluciones para la gestión de mantenimientos en equipos,

gestión de postventa y reportería.
Solución 01: MP Software
País Creadora: México. Distribuidora: Perú.
http://www.mpsoftware.com.mx/index.html?ln=es#
WEB
Gestión y Mantenimiento de equipos
 Maneja 3 versiones: MP Básico, MP Profesional, MP Empresarial.

 Documenta toda la información referente a sus equipos e instalaciones.
 Documenta los planes o rutinas de mantenimiento de cada uno de sus
equipos.
 Genera los calendarios de mantenimiento en forma automática.
 Informa sobre los trabajos de mantenimiento que se deben realizar.
 Reprograma las fechas de mantenimiento.
 Automatiza y simplifica el proceso de generación, control y
Características
seguimiento de las órdenes de trabajo.
 Mantiene control total sobre su inventario de repuestos y disminuye
niveles de inventario mediante la adquisición de repuestos justo a
tiempo.
 Mantiene organizada y disponible para consulta toda la información
histórica referente a trabajos realizados y recursos utilizados.
 Genera gran cantidad de reportes, índices y gráficas relacionados con
la gestión de mantenimiento.
Beneficios  Reducción de paros imprevistos

 Incremento de la vida útil de los equipos
Página 49
 Prevención de reparaciones costosas
 Prevención de accidentes
 Confiabilidad y uniformidad de la calidad
 Reducción de los niveles de inventario de repuestos
 Mejora el desempeño del personal de mantenimiento
Precios
Tabla 5: Solución 01: MP Software [elaboración propia]
Solución 02: SISTRADE
País Creadora: Portugal. Distribuidora: Perú.
WEB http://www.sistrade.com/es/home.htm
Página 50
ERP de Mantenimiento de equipos
 Mantenimiento de Equipos
 Árbol de Equipos
 Generación de las solicitudes de mantenimiento programadas
 Captura de Datos de Mantenimiento
 Alertas al responsable vía PC
 Programación manual o automática del mantenimiento
 Generación de la Orden de Mantenimiento y de su Medición
 Gestión de Averías y Mantenimiento Correctivo
 Estadísticas de los acontecimientos, eventos y causas de los problemas
Características  Gestión de Ordenes de Mantenimiento
 Integración con Plan de Producción
 Organización y Documentación
 Registro de Tiempos
 Supervisión y Control de las ordenes
 Gestión de Recambios
 Costes de Mantenimiento
 Informes y estadísticas de Mantenimiento
 ERP 100% Web
 ERP en Tablet con uso de Cloud Computing
 Más económico al estar centralizado en un único servidor;

 Aprovecha los desarrollos y estándares de mayor uso actualmente en el
mundo
Beneficios
 Facilita el acceso remoto a la información
 Agiliza el proceso de intercambio de información entre terceros
 Facilidad de utilización por parte de los usuarios
Tabla 6: Solución 02: Sistrade [elaboración propia]
Página 51
4.2 Análisis comparativo EMPRESA/PRODUCTO
IMPACTO EN
CRITERIOS DE EVALUACION MP Software Sistrade ERP Solución Propuesta
EL NEGOCIO
Valorización Total Valorización Total Valorización Total
Listado de Equipos 2 2 4 2 4 2 4
Catalogo de Documentos 2 2 4 2 4 1 2
Rutinas de Mantenimiento 1 2 2 2 2 2 2
Generación de Ordenes de Trabajo 2 2 4 2 4 2 4
Sugerir posibles soluciones mediante metodos heurísticos 2 0 0 0 0 2 4
Solicitudes via Web 2 1 2 1 2 2 4
Monitoreo en tiempo real de lo escaneado por el equipo 1 0 0 0 0 2 2
Creación de Casos de Servicio 2 1 2 1 2 2 4
Chat online con oficina central 1 1 1 0 0 2 2
Calculo automatico de los calendarios de mantenimiento 2 2 4 1 2 2 4
Distribucion de cargas de trabajo 2 2 4 1 2 2 4
Localización GPS de técnicos 1 0 0 0 0 2 2
Interfaz de consulta y busquera a clientes 1 0 0 0 0 2 2
Actualizacion de trabajos realizados 2 2 4 2 4 2 4
Actualización de Reporte vía móvil con firma 1 0 0 0 0 1 1
Gestión de tarifas de transporte 1 0 0 1 1 1 1
Conectividad Movil con Web principal 1 2 2 2 2 2 2
Control movil para atención de servicios 2 1 2 2 4 2 4
Compatibilidad con dispositivos móviles 1 2 2 1 1 2 2
Inventario de Respuestsos y Consumibles 0 2 0 1 0 0 0
Generación de Informe Técnico automático 2 1 2 0 0 2 4
Optimización de rutas y gastos de transporte 2 0 0 0 0 1 2
Gestión de clientes y encuentas de servicio 2 1 2 0 0 1 2
Listado de Mano de Obra 1 2 2 2 2 2 2
Envío de fotos por aplicación móvil 2 2 4 0 0 2 4
Catalgo de Proveedores y Servicios Externos 0 2 0 1 0 0 0
Alertas a correo y/celular 1 1 1 1 1 2 2
Asignación de técnicos para un servicio 2 1 2 0 0 2 4
Control de devolucion de herramientas 2 2 4 1 2 2 4
Revisión de agenda personalizada móvil 2 1 2 0 0 2 4
Confirmación por lector de barras 2 0 0 0 0 2 4
Gestión de Recursos y Actividades 2 2 4 1 2 2 4
Vales de Almacen 0 2 0 0 0 0 0
Consumos 0 2 0 1 0 0 0
Historial de consumo y trabajos realizados 2 2 4 2 4 2 4
Historial de casos por equipos 2 1 2 2 4 2 4
Reportes Gerenciales 1 1 1 2 2 1 1
Reportes Personalizados 1 0 0 0 0 1 1
Reporte de causas y fallas 2 2 4 2 4 2 4
Carga de archivos logs propios del equipo y análisis de
2 0 0 0 0 2 4
sus parametros
Historia Gráfica 2 2 4 2 4 2 4
Gráfica de costos,paros,etc 1 2 2 2 2 2 2
Control de Garantias 2 2 4 1 2 2 4
Seguridad 1 1 1 2 2 2 2
Conexión Remota 2 2 4 2 4 2 4
BBDD centralizada y accesible 1 1 1 2 2 2 2
TOTAL 87 71 126
VENTAJA PORCENTUAL 31% 44%
Leyenda Impacto: 0 = No Necesario, 1 = Importante, 2 = Muy Importante
Leyenda Valoración: 0 = No Cubierto, 1 = Cubierto Parcialmente, 2 = Cubierto
Página 52
Tabla 7: Análisis comparativo de soluciones [elaboración propia]
4.3 Evaluación de la mejor solución
Se ha analizado 2 propuestas similares para la gestión de post venta para mantenimiento de

equipos. Luego de comparar las soluciones dentro del marco funcional requerido por el
proceso y la organización, se ha encontrado que la propuesta de solución planteada en este
proyecto es la solución más acorde y con mayor funcionalidad prevista requerida por el área.
Dentro de la funcionalidad prevista para el sistema, el cuál abarca todos los puntos
comparados y las soluciones a los problemas encontrados en la organización se tienen.
Gestión de Servicio (Web):

 Registrar los casos de servicio y generar la orden de servicio.
 Autogenerar código de caso de servicio correlacionado único.
 Emitir alerta de estado de casos pendientes y servicios de mantenimiento mensual.
 Búsqueda avanzada de casos de servicio.
 Impresión de detalle de casos consultados.
 Consulta rápida de los últimos casos de servicio.
 Controlar el estado de los casos de servicio, informado al clientes mediante correos
electrónico automático el estado del caso.
 Controlar el flujo de revisión y aprobación de los informes técnicos, mediante
segregación de roles y usuarios.
 Control de las aprobaciones de los informes técnicos para el cierre del caso.
 Controlar y asignar técnicos según disponibilidad y competencias.
 Optimizar y asignar los gastos por transporte en los casos de servicio.
 Controlar y asignar las herramientas de los técnicos al momento del servicio y al
finalizar el servicio.
 Visualizar los reportes e informes técnicos en digital relacionados al caso.
 Editar los casos de servicio siempre que no estén cerrados.
Página 53
 Controlar la creación, modificación y aprobación de los informes técnicos asociados a
los casos de servicio.
 Asignar automáticamente a los técnicos disponibles para los servicios programados
según cercanía, disponibilidad y criticidad de servicio.
 Validar automáticamente la garantía de los equipos al momento de registrar la
atención.
 Generar automáticamente un caso de servicio al recibir una solicitud de un cliente.
 Programar automáticamente los mantenimientos preventivos a los equipos que se
encuentren en garantía.
 Mostrar disponibilidad de técnicos que no tengan asignados un servicio.
 Manejar calendarios para que los técnicos conozcan sus programaciones de servicio
periódicas.
 Mostrar las posibles soluciones a los incidentes registrados automáticamente de
acuerdo a la base de conocimiento de servicios
 Comunicarse en línea con su aplicativo móvil para resolver consultas, recepción de
datos y chat en línea.
 Manejo de auditorías para los diferentes tareas ejecutadas en el sistema.
 Alertas de finalización de garantía para el cliente y el Gerente de tecnología.
 Envío de informe técnico al cliente por correo al finalizar la elaboración y revisión.
 Interfaz de solicitud y consulta de servicio para el cliente.
 Interfaz de visualización en línea de los equipos modelo HS conectados a la red LAN,
para monitoreo en tiempo real de los objetos escaneados.
 Alerta automática de algún error que suceda con un equipo HS conectado a la red
LAN.
 Carga de archivos log de errores, análisis de los códigos y parámetros para su
diagnóstico y solución.
 Generar, analizar y centralizar encuestas de calidad de servicio.
Gestión de Equipos:
 Registrar los equipos nuevos al momento de realizar un servicio, su ubicación actual,
estado, cliente, etc.
 Registrar los contratos de servicio de los equipos y sus garantías correspondientes.
Página 54
 Generar propuestas de posibles mantenimientos preventivos.
 Verificación de unicidad de serie de equipos.
 Emitir alertas de término de garantía.
 Emitir alertas de estado de equipo inoperativo cuando supera máximo de días
permitidos.
 Búsqueda de equipos registrados.
 Consulta de últimos casos asociados a los equipos y de los manuales de los equipos.
 Visualización de fotos de los equipos consultados.
 Reporte de últimas fallas presentadas por equipos.
 Reporte de estado de equipos.
 Impresión de lista de equipos.
 Envío de correo automático a clientes sobre estado de reposición de pieza de equipo.
 Lista de partes y repuestos por equipo.
 Registro y control de las herramientas usadas por los técnicos en sus servicios.
Indicadores, reportes y estadísticas:

 Indicadores de rendimiento de los técnicos por casos ejecutados en periodos
mensuales y anuales.
 Reporte de fallas frecuentes en periodo mensual.
 Cantidad de casos de servicio ejecutados con éxito y no éxito.
 Costos de transporte por casos de servicio, y por periodos.
 Indicadores de porcentaje de fallas y tiempo entre fallas de los equipos.
 Tiempo de atención de casos, desde su registro hasta su término.
 Reporte de clientes con mayor atención de servicios en un periodo.
 Indicadores de tiempo de inoperatividad de equipos.
 Reportes gerenciales de clientes por servicio, productividad de técnicos, gastos del
área, etc.
 Reportes personalizados a medida utilizando los datos disponibles.
Gestión de Servicio (Móvil):

 Ingreso a la herramienta móvil para Tablet y Smartphone
Página 55
 Revisión de historial de equipos.
 Consultar mapa con hoja de ruta de servicios
 Registrar información de costos operativos: movilidad, peajes, etc. asociado al
servicio.
 Verificación de equipos por lector de barras del dispositivo móvil.
 Acceso a consulta de casos y equipos.
 Registro de incidencias y observaciones en sistema en línea.
 Comunicación con sistema web central para chat en línea con la oficina central.
 Carga de fotos de los equipos al momento del servicio técnico.
 Registro de encuesta de servicio que será llenado por el cliente en el dispositivo.
 Revisión de servicios programados diarios, semanal, mensual.
 Reprogramación de servicios en línea.
 Control y seguimiento de las tareas del técnico desde el aplicativo móvil.
 Ubicación del técnico en un tiempo determinado.
 Asistir al técnico en posibles problemas de un equipo, de tal forma que el sistema
proponga alternativas de solución, según el equipo.
 Registrar información del servicio realizado en campo. Asimismo, el técnico podrá
adjuntar información, documentos adicionales o fotos.
 Enviar Reporte de servicio por correo electrónico al cliente.
 Alerta de tareas y servicios programados al móvil.
 Reporte de servicio actualizado en móvil con firma digital.
5 TENDENCIA Y TECNOLOGÍAS PROPUESTAS
Dentro de la solución propuesta se incluye el desarrollo de tecnologías de punta, está

tecnología actualmente se encuentra en un gran auge por lo cual hoy y mañana seguirán
siendo una tendencia a seguir. La tecnología propuesta es el desarrollo Web y Móvil para la
solución del problema.
Página 56
La tecnología Web aporta una solución con entorno amigable, de fácil acceso y con gran
seguridad; mientras la tecnología móvil aporta una solución compacta, navegable y portable
en cualquier dispositivo móvil, para lo cual los técnicos podrán hacer uso de ella en los
puntos de servicio del cliente.
Así mismo, se incluye varias funcionalidades de mejora de la gestión, estadística y

generación de reportes para la mejor toma de decisiones en base a los datos de los casos
atendidos.
Página 57
6 CONCLUSIONES
 Se analizó la problemática de la empresa y se formuló los objetivos específicos para

que resuelvan dicha problemática y para que se mejore el proceso de servicio
automatizando actividades.
 Los indicadores presentados verifican la totalidad de los objetivos del proyecto, estos se
desarrollarán al final del proyecto y durante los casos de prueba que se ejecutarán en la
primera versión del sistema.
 El sistema presentado ha sido comparado con otras soluciones existentes en el mercado

encontrándose como la solución más compatible con el negocio y los requerimientos de
la empresa, aportando tecnología de punta a la organización objetivo y solucionando
sus problemas críticos en el proceso campo de acción.
Página 58
CAPÍTULO 3: MODELADO DEL NEGOCIO
1 INTRODUCCIÓN
El presente capítulo contiene el Modelado del Negocio. Se desarrolla las reglas de negocio y
los actores de negocio que participan. Así mismo, se detallan los trabajadores y entidades del
negocio. Luego, se pasa a describir los casos de uso del negocio junto con cada uno de sus
diagramas de actividades correspondientes para un mejor entendimiento. Finalmente, para
fines de seguimiento, se incluyen las matrices de trazabilidad perteneciente a esta fase.
2 REGLAS DEL NEGOCIO
Reglas de operaciones
RN_01_Atención de equipos con garantía

Los equipos con garantía vigente serán atendidos directamente por el área de tecnología.
RN_02_Atención de equipos sin contrato vigente

Los equipos sin contrato de mantenimiento son atendidos siempre y cuando el área comercial
los haya cotizado.
RN_03_Solicitar compra de herramientas

El técnico tiene que solicitar la compra de herramientas faltantes antes de realizar un servicio.
RN_04_Asignación de técnicos
Para cualquier asignación de técnicos a un servicio, se debe de consultar su disponibilidad
previamente.
RN_05_Confirmación de atención
Página 59
El cliente tiene que haber confirmado una fecha y hora para que se pueda realizar el servicio.
RN_06_Atención programada
Si el Cliente necesita una atención para un día diferente al día actual, está quedará pendiente
para su asignación y planificación.
RN_07_Emisión de orden de servicio

Debe emitirse una orden de servicio para que el técnico pueda salir a realizar el servicio.
RN_08_Escaneo de reportes
El técnico debe escanear todos los reportes técnicos firmados para adjuntarlos al informe
técnico.
RN_09_Entrega de documentos al finalizar atención

El técnico debe entregar al coordinador el informe técnico revisado por el supervisor, los
reportes de servicio escaneados y el reporte de herramientas si lo hubiera.
RN_10_Verificación de herramientas
El técnico debe verificar que sus herramientas están completas antes y después de realizar un
servicio.
Reglas de flujo
RN_11_Revisión de asignación de técnicos

La asignación de los técnicos hecha por el coordinador debe ser revisada por el supervisor
antes de confirmar su atención.
RN_12_Revisión de calendario de planificación

El calendario de planificación elaborado por el coordinador debe ser revisado por el
supervisor antes de actualizar los casos correspondientes.
RN_13_Revisión de informe
El informe técnico debe ser revisado por el supervisor del área antes de enviárselo al cliente.
Página 60
RN_14_Firma de reporte de servicio
El reporte de servicio debe ser firmado por el cliente al finalizar el servicio.
RN_15_Aprobación de reprogramación
El cliente debe dar su aprobación cuando se realice una reprogramación del servicio.
Reglas de estímulo y respuesta
RN_16_Cliente no da facilidades de acceso

Si el cliente no da las facilidades de acceso al área del equipo, se procederá con la
reprogramación del servicio.
Reglas de dominio de datos
RN_17_Código de caso de servicio

El número de caso de servicio debe tener 2 números correspondiente al año, un guion, y
luego un valor numérico de 3 cifras correlativos.
RN_18_Código de informe técnico

El código del informe técnico debe ser el mismo que el código de caso de servicio.
RN_19_Tipos de técnicos
Los técnicos pueden ser o técnicos de campo o técnicos de laboratorio.
Reglas de relación
RN_25_Asociación de equipos a una Solicitud de Servicio

Varios equipos pueden estar registrados dentro de una Solicitud de Servicio.
RN_20_Asociación de casos de servicio

Un caso de servicio puede tener asociados varios tipos de servicios de mantenimiento,
instalación o capacitación.
Página 61
RN_21_Relación equipo atendido y reporte de servicio
Cada equipo atendido tiene su respectivo reporte de servicio.
Reglas de inferencia
RN_22_Equipo inoperativo
Si el equipo al finalizar el servicio no está en funcionamiento se considerará equipo
inoperativo.
RN_23_Caso de servicio pendiente

Un caso de servicio apenas es creada tendrá el estado de pendiente.
RN_24_Caso de servicio terminado

Un caso de servicio se considerará terminado cuando el informe técnico sea enviado al
cliente.
3 MODELO DE CASOS DE USO DEL NEGOCIO
3.1 Actores del negocio
 AN_001_Cliente
Es el actor que solicita un servicio al ocurrir algún incidente o requerimiento. Se
beneficia de la solicitud de servicio y de la atención oportuna del servicio.
 AN_002_Gerente de Tecnología
Página 62
Es el responsable del área de tecnología. Pide la atención del servicio al cliente y se
beneficia de la correcta planificación de los diferentes servicios que serán atendidos
durante el día.
Página 63
3.2 Casos de uso del negocio
 CUN_001_Solicitar Servicio
Este caso de uso hace referencia a la solicitud de atención de servicio de parte del
cliente hasta la confirmación de la atención con la fecha y hora pactada. Si es cliente
requiere una atención inmediata, esta es asignada a un técnico disponible, y sus datos
son incluidos en la confirmación de la atención enviada al cliente.
 CUN_002_Planificar Servicio
Este caso de uso hace referencia a la planificación necesaria para la atención de los
casos de servicio del día y tiene como finalidad la programación de los servicios a
atender, la asignación de los técnicos y la creación de las órdenes de servicio.
 CUN_003_Atender Servicio
Este caso de uso hace referencia a la atención del servicio que realiza el área de
tecnología a algún incidente reportado; se elabora y revisa el informe técnico
correspondiente, finalizando con el envío del informe técnico al cliente.
Página 64
3.3 Diagrama de Casos de Uso del Negocio
Gráfico 8: Diagrama de casos de uso del negocio [elaboración propia]
4 MODELO DE ANÁLISIS DEL NEGOCIO
4.1 Trabajadores del negocio
Página 65
Trabajador Descripción
Se encarga de las coordinaciones con el
cliente, maneja los casos de servicio y
crea las ordenes de servicio para los
técnicos. Así también, asigna a los
técnicos para algún servicio inmediato y
elabora el calendario de planificaciones
a solicitud del supervisor.
Se encarga de la atención del servicio en
el sitio del cliente, elabora el informe
técnico y el reporte de servicio, también
debe reportar las herramientas antes y
después del servicio y envía toda la
documentación del servicio atendido al
coordinador.
Se encarga de revisar las asignaciones
hechas por el coordinador, el calendario
de planificaciones y el informe técnico
del técnico. Así también, es quien asigna
a los técnicos durante la planificación
diaria y entrega la planificación al
gerente.
Se encarga de revisar las solicitudes con
equipos que necesiten una cotización
previa al servicio. Elabora la cotización
respectiva y se lo envía al cliente para su
aceptación. Envía la respuesta del cliente
al coordinador para continuar con la
atención.
Página 66
4.2 Entidades del negocio
Entidades Descripción
Representa el contrato de compra,
mantenimiento o garantía que tiene un equipo.
Cuenta con:
 Código
 Nombre, dirección de cliente
 Equipo(s) asociados(s)
 Duración del contrato
 Descripción del contrato
Representa la información del equipo. Cuenta
con:
 Número Serie
Página 67
 Nombre, marca y descripción
 Ubicación actual
 Estado actual
Representa la solicitud hecha por el cliente para
la atención de un servicio. Cuenta con:
 Nombre, RUC, dirección de cliente
 Fecha de la solicitud
 Descripción de los equipos a atender
 Estado de la solicitud
Representa la respuesta de cotización en proceso
que recibe el cliente a su solicitud de atención, y
que deberá ponerse en contacto con el área
comercial. Cuenta con :
 Equipos a atender
 Detalle de la solicitud enviada a
comercial
 Datos de contacto del área comercial
Representa la respuesta positiva de atención que
recibe el cliente a la solicitud solicitada. Cuenta
con :
 Equipos a atender
 Fecha y hora acordada
Representa los datos del servicio que se atienden
en el área, es actualizado por el coordinador.
Cuenta con:
 Código
 Datos del cliente
 Datos del equipo
 Código de Reporte de servicio
Página 68
 Datos del técnico asignado
 Tipo de servicio
 Detalles del servicio
 Fecha y hora de atención
Representa los horarios asignados de los
técnicos. Cuenta con:
 Datos del técnico
 Casos de Servicio asignados
Representa los datos personales del técnico.
Cuenta con:
 Nombre y apellido
 DNI
 Fecha de ingreso
 Dirección y teléfonos
Representa el documento generado por el
coordinador que debe ser entregado al técnico
antes de cada servicio. Cuenta con:
 Código de caso de servicio
 Técnico asignado
 Herramientas y materiales a usar
 Costo de transporte
Representa el listado generado por el
coordinador que muestra los casos pendientes
actuales. Cuenta con:
 Código
 Fecha y hora coordinada con cliente
 Estado de caso
Página 69
Representa el documento generado por el
coordinador donde se planifica y asigna a los
técnicos para cada servicio. Cuenta con:
 Código de caso
 Datos de cliente
 Datos de equipo
 Técnico asignado
 Fecha y hora de atención
Representa los datos de las herramientas que el
técnico debe tener siempre en su maletín de
herramientas. Cuenta con:
 Código
 Nombre, marca y descripción
 Cantidad
Representa el documento elaborado por el
técnico en cada servicio. Cuenta con:
 Código de reporte
 Datos de equipo
 Nombre de cliente
 Tipo y detalle de servicio
 Firma de técnico y de cliente
técnico cuando devuelve incompleto las
herramientas. Cuenta con:
 Fecha y hora
 Datos del técnico
 Detalle de las herramientas
 Datos del servicio atendido
técnico al final de la atención. Cuenta con:
 Código de informe
Página 70
 Nombre del cliente
 Número de serie, ubicación del equipo
 Detalle del requerimiento
 Causas del problema
 Resolución del problema
 Recomendaciones y observaciones
 Nombre del técnico que atendió el
servicio
Representa la cotización elaborada por
comercial para cada equipo sin garantía vigente.
Cuenta con:
 Código de cotización
 Nombre del cliente
 Número de serie, ubicación del equipo
 Detalle del servicio requerido.
 Precio del servicio requerido
 Total de precio + IGV
Página 71
5 REALIZACIÓN DE LOS CASOS DE USO DEL NEGOCIO
5.1 CUN_01_SOLICITAR SERVICIO
5.1.1 Especificación del caso de uso del negocio
 Actores del Negocio

AN_001_Cliente
 Propósito
Solicitar una atención de servicio al área de tecnología.
 Breve Descripción
El caso de uso inicia cuando el Cliente envía una solicitud de atención de servicio.
Dicha solicitud es evaluada por el Coordinador para verificar si cuenta con contrato
vigente. Luego se coordina una fecha y hora para la atención. El caso de uso termina
cuando el Cliente recibe una confirmación de la atención por parte del Coordinador del
área de tecnología.
 Flujo Básico
1. El Cliente solicita la atención de un servicio al área de tecnología
2. El Coordinador recibe la solicitud y verifica si el equipo cuenta con contrato
vigente. [RN_01] [RN_02]
3. El Coordinador registra la solicitud en un caso de servicio. [RN_17] [RN_20]
[RN_23]
4. El Coordinador coordina con el Cliente una posible fecha y hora para la atención
del servicio. [RN_05]
5. El Coordinador verifica la disponibilidad de los técnicos para asegurarse que la
fecha proporcionada por el cliente sea factible para su atención. [RN_04]
6. El Coordinador actualiza el caso de servicio. [RN_06]
Página 72
7. El Coordinador asigna a un técnico para la atención del servicio solicitado.
[RN_19]
8. El Coordinador solicita la aprobación de dicha asignación por parte del Supervisor.
9. El Supervisor revisa la asignación y envía el resultado al Coordinador. [RN_11]
10. El Coordinador llena la orden de servicio y se lo entrega al técnico. [RN_07]
11. El Coordinador envía la confirmación de la atención al cliente informando sobre la
fecha y hora programada para la atención.
 Flujo Alterno
1. Si en [2] el Coordinador verifica que no hay contrato vigente asociado al equipo al
cuál se está requiriendo el servicio, este envía la Solicitud de Servicio a Comercial.
Comercial recibe la Solicitud de Servicio y elabora la Cotización respectiva de los
equipos sin garantía, luego envía la cotización al Cliente para su aceptación. El
Cliente envía la respuesta de la cotización al Comercial y este envía la cotización
aceptada al Coordinador entones continua en el paso 3.
2. Si en [1] del Flujo Alterno, el Cliente no acepta la cotización enviada, entonces el
Comercial envía la respuesta negativa al Coordinador. El coordinador redacta una
respuesta a la Solicitud de Servicio enviada junto con la cotización Rechazada por
el cliente. El Coordinador envía la respuesta al Cliente terminando el caso de uso.
3. Si en [5] el Coordinador no encuentra técnico disponible para la fecha y hora
propuesta por el Cliente entonces continua en el paso 4.
4. Si en [6] el Coordinador revisa que la fecha propuesta no es para el día actual
entonces continua en el paso 11.
5. Si en [9] el Supervisor no aprueba la asignación, este solicita una nueva asignación
al Coordinador y continúa en el paso 7.
 Precondiciones
o Registro de contratos actualizado.
 Postcondiciones
o Quedará registrada el Caso de Servicio con estado “pendiente”.
o Se emitirá una confirmación de atención de servicio al Cliente
Página 73
Página 74
5.1.2 Diagrama de actividades
Gráfico 9: Diagrama de actividades de CUN_01_Solicitar Atención [elaboración propia]
Página 75
Página 76
5.1.3 Lista de actividades a automatizar
 Atender Solicitud de Atención de Servicio

 Verificar contrato vigente del equipo
 Enviar Solicitud de Servicio a Comercial
 Recibir Solicitud de Servicio a Cotizar
 Enviar Cotización de Coordinador
 Enviar Respuesta de Solicitud al Cliente
 Registrar solicitud en un caso de servicio
 Consultar disponibilidad de técnicos
 Actualizar caso de servicio
 Asignar técnico para atención
 Revisar asignación de técnico
 Enviar resultado a Coordinador
 Llenar orden de servicio
 Imprimir orden de servicio
 Enviar Confirmación de Atención al Cliente
Página 77
5.1.4 Diagrama de Clases del Negocio
Gráfico 10: Diagrama de clases de CUN_01_Solicitar Atención [elaboración propia]
Página 78
5.2 CUN_02_PLANIFICAR SERVICIO

AN_002_Gerente de Tecnología
 Propósito
Planificar los servicios que serán atendidos en el día.
El caso de uso inicia cuando el Gerente de Tecnología solicita la planificación de los
servicios del día. El Supervisor le pide al Coordinador los casos de servicios que estén
pendientes por atender. Luego el Supervisor asigna a los técnicos según su
disponibilidad para cada servicio pendiente. El Coordinador elabora el calendario de
planificación y se lo envía al Supervisor para su revisión. Luego de revisado el
Coordinador actualiza los casos y genera las ordenes de servicio correspondientes. El
caso de uso termina cuando el Gerente de Tecnología recibe del Supervisor el
calendario de planificación detallado para los servicios pendientes.
 Flujo Básico
1. El Gerente de Tecnología solicita la planificación de los servicios del día al
Supervisor.
2. El Supervisor solicita al Coordinador los casos de servicios pendientes.
3. El Coordinador revisa los casos de servicio y entrega al Supervisor los que estén
pendientes de atención.
4. El Supervisor consulta la disponibilidad de los técnicos. [RN_04]
5. El Supervisor asigna a los técnicos a cada caso de servicio pendiente. [RN_19]
6. El Supervisor entrega la lista de casos pendientes asignados al Coordinador.
7. El Coordinador elabora el calendario de planificación y se lo envía al Supervisor
para su revisión.
Página 79
8. El Supervisor revisa el calendario y envía el resultado al Coordinador. [RN_12]
9. El Coordinador actualiza los casos de servicio según las nuevas asignaciones.
10. El Coordinador llena la orden de servicio correspondiente y se lo entrega a los
técnicos asignados. [RN_07]
11. El Coordinador envía el calendario aprobado al Supervisor.
12. El Supervisor envía el calendario aprobado al Gerente de Tecnología.
 Flujo Alterno
1. Si en [5] el Supervisor no puede asignar a un técnico porque se encuentra
indisponible para dicha fecha y hora en la cual está acordado el servicio, continua
en el paso 4.
2. Si en [8] el Supervisor no aprueba el calendario elaborado por el Coordinador,
agrega observaciones en el calendario y se lo envía al Coordinador, luego continua
en el paso 7.
 Precondiciones
o Existen casos de servicio pendientes.
 Postcondiciones
o Quedará actualizado los casos de servicio con los técnicos que harán la atención.
o Se elaborará un calendario de planificación de servicios.
Página 80
Gráfico 11: Diagrama de clases de CUN_02_Planificar Servicio [elaboración propia]
Página 81
 Consultar casos de servicio

 Generar lista de casos de servicio pendientes
 Enviar casos de servicio pendientes al Supervisor
 Revisar casos de servicio pendientes
 Consultar disponibilidad de técnicos
 Asignar técnicos a cada servicio
 Enviar servicios pendientes asignados al Coordinador
 Elaborar calendario de planificación
 Enviar calendario de planificación al Supervisor
 Revisar calendario de planificación
 Agregar observaciones al calendario de planificación
 Enviar calendario aprobado al Coordinador
 Actualizar caso de servicio
 Llenar orden de servicio
 Imprimir orden de servicio
 Enviar calendario al Gerente de Tecnología
Página 82
Gráfico 12: Diagrama de clases de CUN_02_Planificar Servicio [elaboración propia]
Página 83
5.3 CUN_03_ATENDER SERVICIO

AN_001_Cliente
AN_002_Gerente de Tecnología
 Propósito
Atender un servicio requerido previamente por el Cliente.
El caso de uso inicia cuando el Gerente de Tecnología solicita la atención de un
servicio. El técnico revisa las ordenes pendientes que tiene, y se acerca a atender el
servicio donde el cliente. El técnico llena el Reporte de Servicio y el Cliente lo firma.
Luego, el técnico elabora el informe técnico, el cual es revisado por el supervisor del
área. Después el técnico adjunta en el informe los escaneados de los Reportes de
Servicio y se lo entrega al Coordinador. El Coordinador actualiza el caso de servicio
correspondiente, archiva el informe y los reportes. El caso de uso termina cuando el
Cliente recibe del Coordinador el informe técnico sobre el servicio atendido.
 Flujo Básico
1. El Gerente de Tecnología solicita la atención del servicio de un Cliente.
2. El Técnico revisa las órdenes de servicio que le corresponden.
3. El Técnico revisa sus herramientas y verifica que estén completas antes de salir a
atender el servicio. [RN_10]
4. El Técnico visita al cliente en la fecha y hora acordada. [RN_16]
5. El Técnico realiza el servicio requerido. [RN_22]
6. El Técnico llena el Reporte de Servicio con los datos del servicio efectuado.
[RN_21]
7. El Cliente firma el Reporte de Servicio. [RN_14]
Página 84
8. El Técnico revisa sus herramientas luego de finalizar el servicio. [RN_10]
9. El Técnico elabora el informe técnico. [RN_18]
10. El Técnico envía el informe técnico al Supervisor para su revisión.
11. El Supervisor revisa el informe técnico. [RN_12]
12. El Supervisor devuelve el informe técnico con el visto bueno de su revisión.
13. El Técnico escanea los Reportes de Servicio firmados por el Cliente. [RN_08]
14. El Técnico adjunta los Reportes de Servicio al documento del informe técnico.
15. El Técnico envía el informe y los reportes asociados a este al Coordinador.
[RN_09]
16. El Coordinador actualiza el caso de servicio.
17. El Coordinador imprime el informe técnico.
18. El Coordinador archiva el informe técnico y los reportes asociados a modo de
historial.
19. El Coordinador envía el informe técnico revisado y con los reportes de servicio
adjuntado al Cliente. [RN_24]
 Flujo Alterno
1. Si en [3] el Técnico verifica que sus herramientas no están completas, este solicita
la compra de las herramientas faltantes, y continua en el paso 3. [RN_03]
2. Si en [4] el Cliente no da las facilidades de acceso al área de trabajo del equipo,
entonces el Técnico solicita la reprogramación del servicio y el Cliente propone
una nueva fecha y hora, terminando el caso de uso. [RN_15]
3. Si en [8] el Técnico verifica que sus herramientas no están completas, este elabora
el Reporte de Herramientas, y continúa en el paso 9.
4. Si en [11] el Supervisor no aprueba el informe técnico, éste agrega algunas
observaciones al documento y se lo envía al técnico para su modificación, luego
continua en el paso 9.
 Precondiciones
o Existen Ordenes de Servicio pendientes para atender recepcionadas por el Técnico.
o Se debe de haber programado una fecha y hora con el Cliente para la atención.
 Postcondiciones
Página 85
o Quedará registrado el Caso de Servicio con estado “terminado”.
o Se creará el informe técnico y los reportes de servicio sobre la atención hecha.
Página 86
Gráfico 13: Diagrama de actividades de CUN_03_Atender Servicio [elaboración propia]
Página 87
Página 88
 Revisar orden de servicio

 Revisar herramientas antes del servicio
 Llenar el reporte de servicio
 Verificar las herramientas después del servicio
 Llenar reporte de herramientas
 Elaborar informe técnico
 Enviar informe técnico al supervisor
 Revisar informe técnico
 Agregar observaciones al informe técnico
 Enviar informe técnico revisado al técnico
 Escanear reporte de servicio
 Adjuntar reporte de servicio al informe técnico
 Enviar Informe técnico y reportes asociados al coordinador
 Actualizar el caso de servicio
 Imprimir informe técnico
 Archivar informe técnico y reportes de servicio asociados.
 Enviar informe técnico al Cliente
Página 89
Gráfico 14: Diagrama de clases de CUN_03_Atender Servicio [elaboración propia]
Página 90
6 CONCLUSIONES
 Se identificó los actores de negocio y los casos de uso del negocio principales dentro
del proceso de la organización, basándose en esto se desarrollará el sistema y los casos
de uso de sistema más adelante.
 Se identificó que el negocio cuenta con reglas de flujo y reglas de estímulo respuesta
que controlan el proceso de atención de la empresa. Así también se identificó que el
negocio no cuenta con reglas de cálculo que influyan directamente en sus procesos.
 Con los diagramas de actividades se pudo identificar las actividades a automatizar, las
cuales servirán como base para los casos de uso del sistema y como soporte para el
desarrollo del sistema de gestión proyectado.
 El Modelado del Negocio constituye una metodología válida para conceptualizar y

plasmar los procesos que se presentan en una empresa, y ayudados por los diagramas
UML se convierte en el punto de inicio de todo proyecto de desarrollo gracias a su fácil
entendimiento y amplio uso.
Página 91
CAPÍTULO 4: REQUERIMIENTOS
1 INTRODUCCIÓN
El presente capítulo contiene los Requerimientos del Sistema. Se detallan los Requerimientos
funcionales y no funcionales acordados con el cliente y que satisfacen la necesidad de
solución de la empresa. Así mismo, se detallan los actores del sistema y los casos de uso del
sistema. Luego, se pasa a describir los casos de uso del sistema del núcleo central, el cuál
formará la columna de todo el sistema, y se especifica los casos de uso que serán
programados en cada ciclo. Finalmente, se elabora el mapa conceptual, con sus atributos y el
diccionario de clases respectivo.
2 ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL SOFTWARE
2.1 Requerimientos Funcionales
RF_001_Registrar Estado de la Cotización

El sistema debe poder registrar los estados de las cotizaciones realizadas por comercial dentro
de la solicitud de atención de servicio hecha por un cliente para verificar si historia y
seguimiento.
RF_002_Actualizar Solicitudes de Atención de Servicio

El sistema debe permitir consultar, registrar y enviar las solicitudes de atención de servicio al
servidor central, así como emitir una alerta en el sistema cada vez que se haya registrado una
solicitud nueva por parte de un cliente, la cuál será vista por el coordinador y el gerente.
RF_003_Atender Solicitud de Atención de Servicio
Página 92
El sistema debe permitir verificar la existencia de garantía vigente de los equipos a los que el
cliente ha solicitado una atención, así como enviar una respuesta al correo del cliente sobre el
resultado de la atención.
RF_004_Actualizar Caso de Servicio

El sistema debe permitir la consulta, registro, modificación y eliminación de un caso de
servicio. Así como mantendrá un registro log sobre el usuario y la fecha de su creación y
última modificación.
RF_005_Mostrar Posibles Soluciones al Caso de Servicio

El sistema deberá poder analizar y mostrar las posibles soluciones al problema registrado en
el caso de servicio, mostrando una lista con los errores y sus soluciones más probables.
RF_006_Realizar encuesta de servicio

El sistema debe permitir al cliente poder llenar una encuesta de servicio por cada caso de
servicio atendido, el sistema debe permitir guardar y modificar los cambios de la encuesta
para continuar en otro momento.
RF_007_Programar técnicos
El sistema debe permitir la consulta de disponibilidad de horario del técnico y poder asignar
un técnico disponible para dicho caso de servicio.
RF_008_Aprobar técnicos asignados

El sistema debe permitir la aprobación de los técnicos que realizarán el servicio de atención.
RF_009_Mostrar Autoasignación de Técnicos

El sistema debe poder analizar y mostrar las posibles autoasignaciones del técnico que mejor
se adecuen al caso de servicio mediante las competencias del técnico y su historial de casos.
RF_010_Actualizar Agenda de Tareas del Técnico

El sistema debe permitir registrar, modificar y consultar el calendario de tareas del técnico
según rango de fechas, así también visualizar la agenda de tareas en el móvil.
Página 93
RF_011_Enviar alerta de nuevo servicio
El sistema debe enviar una alerta al móvil del técnico sobre el nuevo caso de servicio
asignado.
RF_012_Generar Orden de Servicio

El sistema debe permitir generar una orden de servicio para el técnico.
RF_013_Adjuntar fotos
El sistema debe permitir adjuntar fotos tomadas del móvil y asociarlas al caso de servicio
respectivo guardándolas en el servidor central, así también podrá adjuntar fotos en el Informe
Técnico respectivo para su envío al cliente.
RF_014_Lectura de código de barras

El sistema debe permitir la lectura de los códigos de barras de un equipo con el móvil al
momento de registrar un reporte de servicio.
RF_015_Firma digital del Reporte de Servicio

El sistema debe permitir poder guardar la firma del cliente en digital al finalizar el servicio.
RF_016_Generar ruta más corta para servicios programados

El sistema debe poder optimizar la ruta más corta a seguir para la atención de los servicios la
asignación de que técnico disponible es más idóneo para dicho servicio.
RF_017_Ingresar a chat online

El sistema debe permitir el ingreso a un chat online entre los técnicos de campo y la oficina
principal.
RF_018_Enviar alerta por garantía

El sistema debe poder emitir alertas y mostrarlas en el sistema cuando un equipo está a un
mes de su vencimiento de garantía y/o de contrato de mantenimiento.
RF_019_Actualizar Reporte de Servicio
Página 94
El sistema debe permitir el registro, modificación y eliminación de un Reporte de Servicio
asociado a un caso de servicio, teniendo un reporte de servicio por cada equipo y tipo de
servicio atendido.
RF_020_Actualizar Informe Técnico

El sistema debe permitir el registro, modificación, eliminación, revisión y consulta de un
Informe Técnico asociado a un caso de servicio.
RF_021_Aprobar Informe Técnico

El sistema debe permitir la revisión y aprobación de un Informe Técnico antes de su envío al
cliente.
RF_022_Revisar lista de herramientas

El sistema debe poder mostrar la lista de herramientas a utilizar para el servicio y registrar
una solicitud de compra de herramientas si una herramienta falta antes de un servicio.
RF_023_Actualizar Reporte de herramientas

El sistema debe permitir registrar, modificar y eliminar un Reporte de Herramientas para
mostrar la pérdida o rotura de una herramienta luego de realizado un servicio.
RF_024_Actualizar ubicación de Técnico

El sistema debe enviar las coordenadas de ubicación cada vez que el técnico actualice el
Reporte de Servicio o realice consultas a su agenda de tareas, así mismo debe poder mostrar
las ubicaciones registradas de los técnicos dentro de un rango de fecha.
RF_025_Generar Reportes del área

El sistema debe generar reportes de productividad de técnicos, de atención de servicios por
cliente y de fallas de los equipos, así como generar reportes nuevos personalizados usando los
datos disponibles y guardarlos para futuras consultas
RF_026_Actualizar Cliente
El sistema debe permitir la consulta, registro, modificación y eliminación de los datos de un
cliente.
Página 95
RF_027_Actualizar Equipo
El sistema debe permitir la consulta, registro, modificación y eliminación de los datos de un
equipo.
RF_028_Actualizar Contrato de Servicio

El sistema debe permitir el registro, modificación y eliminación de los contratos de servicio
de un cliente.
RF_029_Registar alertas para mantenimientos programados

El sistema debe poder registrar y mandar alertas de los próximos mantenimientos
programados.
RF_030_Actualizar Piezas por Equipo

El sistema debe permitir el registro, modificación y eliminación de los datos de las piezas de
repuesto de un equipo.
RF_031_Actualizar Competencias del Técnico

El sistema debe permitir el registro, modificación y eliminación de las competencias de los
técnicos.
RF_032_Actualizar Técnico
El sistema debe permitir la consulta, registro, modificación y eliminación de los datos de los
técnicos.
RF_033_Actualizar niveles de competencia del técnico

El sistema debe permitir el registro, modificación y eliminación de los niveles que tiene cada
técnico en cada uno de sus competencias.
RF_034_Cargar datos de errores del Hitrax al sistema

El sistema debe poder cargar los datos y parámetros de los archivos logs de errores generados
del Hitrax para su registro y análisis en el diagnóstico de un equipo.
Página 96
RF_035_Monitoreo de imágenes escaneadas
El sistema debe poder conectarse a la carpeta de exportación del Hitrax y mostrar en tiempo
real las imágenes jpg que están siendo escaneadas, así como enviar una alerta cuando el
equipo no puede escanear debido a un fallo interno.
RF_036_Alerta de Errores en equipos Hitrax

El sistema debe poder alertar de un error producido en el equipo Hitrax de forma automática
y mostrarla en pantalla para su inmediata acción.
2.2 Requerimientos No Funcionales
Usabilidad
RNF_001_Facilidad de uso
El sistema utilizará una Interfaz web y móvil interactiva e intuitiva, que facilitará su
utilización y manejo a los usuarios sin mucha experiencia en el uso de herramientas
informáticas.
RNF_002_Manejo de Excepciones
El sistema debe manejar mostrar en pantalla y en detalle los errores que puedan generarse
durante la ejecución del sistema.
RNF_003_Generación de reportes
El sistema debe poder generar los reportes solicitados por la gerencia como promedio en 20
segundos.
RNF_004_Exportar e Imprimir Información

Todas las tablas mostradas en el sistema deben permitir exportar e imprimir la información
consultada a formato PDF o Excel.
Confiabilidad
Página 97
RNF_005_Alerta ante fallas
El sistema ante una falla posible enviará un mensaje email al personal de Soporte designado,
con el dato detallado del error.
RNF_006_Tiempo de Caída
El tiempo de caída del sistema no deberá exceder 15 minutos.
RNF_007_Disponibilidad del Sistema

El sistema debe estar disponible en un 95% durante el horario laboral de Lunes a Viernes de
9:00 am a 06:00 pm.
Rendimiento
RNF_008_Tiempo de Respuesta
El sistema debe permitir un tiempo de respuesta para las transacciones que no debe exceder:
 Los 4 segundos con un ancho de banda de 100 Mbps.
 Los 6 segundos con un ancho de banda de 54 Mbps.
RNF_009_Tiempo de Consulta
El tiempo promedio de cada consulta realizada al sistema deberá ser menor a 6 segundos.
RNF_010_Inactividad de la Sesión
El sistema debe detectar el tiempo de inactividad en la sesión de un usuario de sistema,
teniendo como límite de tiempo 5 minutos, luego de transcurrido este tiempo se cerrará
automáticamente la sesión.
RNF_011_Sesiones Concurrentes
El sistema no permitirá que un mismo usuario abra más de una sesión de manera concurrente.
RNF_012_Concurrencia de Usuarios
El sistema permitirá el acceso concurrente de 20 usuarios diferentes.
Página 98
RNF_013_Tiempo de Respuesta de Reportes
El tiempo de respuesta promedio del sistema para las operaciones involucradas con los
reportes es de 6 segundos.
Soporte
RNF_014_Navegador Web
Los navegadores soportados por el sistema serán Microsoft Internet Explorer 8.0 o superior,
Firefox 3.0 o superior, Google Chrome 20.0 o superior y Safari 2.0 o superior.
RNF_015_Sistema Móvil
El sistema móvil debe soportar la plataforma Android con versión API 4.1 o superior.
RNF_016_Plataforma de la aplicación Web

El sistema deberá ser compatible con Microsoft Windows Server 2003 o superior y será
publicado en el servidor web IIS 7.0 o superior.
RNF_017_Log de Auditoria
El sistema registrará el usuario que ejecutó la transacción, así como la fecha y hora de
modificación.
RNF_018_Requerimientos de Software de estación de trabajo

La estación de trabajo del usuario deberá disponer del siguiente software: visor de archivos
PDF Adobe Reader 9 o superior, visor de archivos Microsoft Excel 2003 o Superior, y un
sistema Microsoft Windows XP SP3 o superior.
RNF_019_Requerimientos de servidor de base de datos

El servidor que alojará la base de datos deberá cumplir con los siguientes requerimientos
mínimos: 02 Procesadores Intel Xeon de 2.4 GHz, 8 GB de RAM, HD 500 GB.
Restricciones de diseño
Página 99
RNF_020_IDE a utilizar
El IDE para el desarrollo del sistema Web será Visual Studio 2013 y para el sistema Móvil
será Android Studio.
RNF_021_Lenguaje de programación
El lenguaje de programación a emplear para el desarrollo del sistema Web será .NET C# con
Framework 4.5 y se usará Ajax como complemento; para el caso del sistema Móvil será
JAVA.
RNF_022_Arquitectura de Desarrollo de Software

La solución debe considerar una Arquitectura de 3 capas. Las capas deben ser: Capa de
Presentación, Capa de Negocio y Capa de Datos.
RNF_023_Base de Datos
El motor de base de datos utilizado deberá ser MS SQL Server 2012 Standard Edition.
RNF_024_Tipo de archivo de los reportes

El formato de salida de los reportes deberá ser formato PDF y XLS.
RNF_025_Servicios Web
La comunicación entre el sistema Web y el sistema móvil será mediante servicios web REST;
el sistema móvil se comunicará mediante protocolo HTML y XML.
Documentación de usuario y sistema de ayuda
RNF_026_Manuales
Se elaborarán los manuales de usuario y manual técnico. Además, estos se publicarán en
PDF. El manual de usuario debe ser accedido en línea para cualquier consulta de los usuarios.
Componentes adquiridos
No aplica.
Página 100
Interfaces
 Interfaz de hardware
No aplica.
 Interfaces de usuario
RNF_027_Logotipo
El logotipo se mostrará en la esquina superior izquierda con nombre de la empresa
Unlimited Systems en todas las interfaces principales del sistema.
RNF_028_Animación
No se incorporarán animaciones en el sistema.
RNF_029_Interfaz gráfica
El diseño de las pantallas del sistema debe seguir el estándar de diseño del cliente
(colores de la empresa), siendo estos naranja, negro y plomo.
 Interfaces de software
RNF_030_Google Maps
El sistema interactuará con los servicios de Google maps para la ubicación en mapa de
los técnicos.
 Interfaces de Comunicaciones
RNF_031_Hitrax
El sistema se conectará con los logs de errores y las imágenes escaneadas del equipo,
siempre que el Hitrax esté conectado en una red LAN.
Licenciamiento
Página 101
RNF_030_Sistema Operativo Servidor
Se necesitará adquirir una licencia del sistema operativo para servidor MS Windows Server
2012 R2 Standard Edition.
RNF_031_Motor de Base de Datos

Se necesitará adquirir una licencia del software de motor de base de datos MS SQL Server
2012 Standard Edition.
RNF_032_Licenciamiento de base de datos por máquina

Se requerirá # CAL para MS SQL Server 2008 (# = cantidad de usuarios del sistema).
Legales y de derecho de autor
RNF_033_Declaración de derecho de autor

La declaración de derecho de autor que indica la propiedad del contenido deberá colocarse en
el pie de página de todas las páginas de la aplicación, mostrando los datos de la compañía
según lo requiere la política.
Estándares aplicables
No aplica
Página 102
3 MODELO DE CASOS DE USO DEL SISTEMA
3.1 Especificación de los actores del sistema
 AS_001_Usuario
Es el actor que generaliza el rol de acceso al sistema y cambio de contraseña.
 AS_002_Coordinador
Es el encargado de actualizar los casos de servicio, generar la orden de servicio y el
calendario de tareas y generar la ruta más corta para la atención de los servicios.
 AS_003_Supervisor
Es el rol encargado de verificar la ubicación de los técnicos y consultar los informes
técnicos realizado por los Técnicos.
 AS_004_Técnico
Es el encargado de actualizar el Reporte de Servicio y el Informe Técnico, también se
encarga de visualizar su agenda de tareas, enviar su ubicación actual, actualizar la lista
de herramientas a su cargo tanto antes como después de la atención.
 AS_005_Gerente
Es el rol encargado de generar los reportes del área predefinidos por la gerencia, así
como generar nuevos reportes personalizados a medida con todos los datos que se
dispone en el sistema. También se encarga de actualizar los niveles de competencia de
los técnicos.
 AS_006_Cliente
Es el encargado de registrar una solicitud de atención de servicio, consultar sus casos de
servicio para verificar el estado y su historial propio de atención, así mismo se encarga
de llenar la encuesta de atención de servicio por cada caso de servicio atendido.
Página 103
 AS_007_Administrador del Sistema
Es el rol encargado actualizar la información de los usuarios y los perfiles en el sistema.
 AS_008_Aprobador
Es el encargado revisar la asignación de técnicos para un caso de servicio, aprobando o
rechazando su asignación colocando la observación respectiva; así también se encarga
de revisar los informes técnicos, aprobándolos o poniendo sus observaciones para la
corrección del informe técnico.
 AS_009_Asignador
Es el rol encargado de asignar los técnicos a los casos de servicio, consultar los horarios
de los técnicos para verificar su disponibilidad y mostrar los posibles técnicos
autoasignados por el sistema.
 AS_010_Asistente
Es el rol encargado de actualizar la información de los técnicos y las competencias del
área, también se encarga de actualizar los datos de los equipos, actualizar las piezas de
repuesto por equipo y de enviar alertas de próximo vencimiento de garantía. Así
mismo, se encarga de actualizar los datos de los clientes, registrar los nuevos contratos
de servicio y registrar las alertas para los servicios de mantenimiento programados.
 AS_011_Operador
Es el rol encargado de consultar los casos de servicio, mostrar las posibles soluciones a
un caso de servicio, consultar clientes, consultar equipos e ingresar al chat online.
 AS_012_Asistente Comercial
Es el rol encargado de consultar las solicitudes de atención de servicio que estén
pendientes de cotizar. Actualiza el estado de los equipos cotizados y registra si la
cotización fue aceptada o no por el cliente.
 AS_013_Google Maps
Página 104
Es el Sistema Externo otorgado por Google Services para la utilización de Mapas y
ubicación de calles.
 AS_014_Hitrax
Es el sistema de los equipos marca SMITH que se encarga de la generación de los logs
de errores y de la exportación de las imágenes a tiempo real de lo escaneado por el
mismo equipo.
Página 105
3.2 Diagrama de actores del sistema
Gráfico 15: Diagrama de actores del sistema [elaboración propia]
3.3 Diagrama de paquetes del sistema
Gráfico 16: Diagrama de paquetes de sistema [elaboración propia]
Página 106
3.4 Diagrama de casos de uso del sistema por paquete
3.4.1 Solicitar Servicio
Página 107
Gráfico 17: DCU Solicitar Servicio [elaboración propia]
Página 108
3.4.2 Planificar Servicio
Página 109
Gráfico 18: DCU Planificar Servicio [elaboración propia]
Página 110
3.4.3 Atender Servicio
Página 111
Gráfico 19: DCU Atender Servicio [elaboración propia]
3.4.4 Seguridad
Gráfico 20: DCU Seguridad [elaboración propia]
Página 112
4 ATRIBUTOS DE LOS CASOS DE USO DE SISTEMA
Nombre del Caso de Uso Complejidad Estado Dificultad Responsable Prioridad
CUS_001_Registrar Solicitud de Atención de Servicio Primario Definido Alta Luis Sumarriva Ciclo 0
CUS_002_Consultar Solicitudes del cliente Secundario Definido Media Luis Sumarriva Ciclo 0
CUS_003_Consultar Solicitud de Atención de Servicio Primario Definido Baja Luis Sumarriva Ciclo 1
CUS_004_Consultar casos de servicio del Cliente Secundario Definido Baja Luis Sumarriva Ciclo 1
CUS_005_Llenar encuesta de atención de servicio Secundario Definido Media Luis Sumarriva Ciclo 2
CUS_006_Actualizar Caso de Servicio Primario Definido Alta Luis Sumarriva Ciclo 0
CUS_007_Consultar Caso de Servicio Secundario Definido Media Luis Sumarriva Ciclo 1
CUS_008_Mostrar Posibles Soluciones al Caso de Servicio Secundario Definido Alta Luis Sumarriva Ciclo 2
CUS_009_Consultar Cliente Secundario Definido Media Luis Sumarriva Ciclo 1
CUS_010_Actualizar Cliente Primario Definido Media Luis Sumarriva Ciclo 1
CUS_011_Registrar Contrato de Servicio Primario Definido Media Luis Sumarriva Ciclo 1
CUS_012_Registar alertas para mantenimientos programados Secundario Definido Media Luis Sumarriva Ciclo 1
CUS_013_Enviar alerta de nuevo servicio Secundario Definido Alta Luis Sumarriva Ciclo 2
CUS_014_Generar Orden de Servicio Primario Definido Alta Luis Sumarriva Ciclo 2
CUS_015_Gestionar planificación más idonea para casos de servicio Primario Definido Alta Luis Sumarriva Ciclo 0
CUS_016_Actualizar calendario de tareas Primario Definido Media Luis Sumarriva Ciclo 1
CUS_017_Consultar Horario Técnico Primario Definido Media Luis Sumarriva Ciclo 1
CUS_018_Asignar Técnico Primario Definido Media Luis Sumarriva Ciclo 1
CUS_019_Mostrar Posibles Técnicos Secundario Definido Alta Luis Sumarriva Ciclo 2
CUS_020_Actualizar Técnico Primario Definido Media Luis Sumarriva Ciclo 1
CUS_021_Actualizar Competencias del Técnico Secundario Definido Baja Luis Sumarriva Ciclo 1
CUS_022_Consultar Técnico Secundario Definido Media Luis Sumarriva Ciclo 1
CUS_023_Actualizar niveles de competencia del técnico Secundario Definido Baja Luis Sumarriva Ciclo 1
CUS_024_Aprobar asignación de técnicos Primario Definido Media Luis Sumarriva Ciclo 1
CUS_025_Actualizar Reporte de Servicio Primario Definido Alta Luis Sumarriva Ciclo 1
CUS_026_Consultar Agenda de Tareas Primario Definido Alta Luis Sumarriva Ciclo 1
CUS_027_Enviar ubicación actual Secundario Definido Alta Luis Sumarriva Ciclo 1
CUS_028_Actualizar Lista de Herramientas Secundario Definido Media Luis Sumarriva Ciclo 1
CUS_029_Actualizar Informe Técnico Primario Definido Alta Luis Sumarriva Ciclo 1
CUS_030_Consultar ubicación de Técnico Secundario Definido Media Luis Sumarriva Ciclo 1
CUS_031_Consultar Informe Técnico Primario Definido Media Luis Sumarriva Ciclo 1
CUS_032_Aprobar Informe Técnico Primario Definido Media Luis Sumarriva Ciclo 1
CUS_033_Actualizar Equipo Primario Definido Media Luis Sumarriva Ciclo 1
CUS_034_Enviar alerta por garantía Secundario Definido Alta Luis Sumarriva Ciclo 2
CUS_035_Actualizar Piezas por Equipo Primario Definido Media Luis Sumarriva Ciclo 1
CUS_036_Consultar Equipo Primario Definido Media Luis Sumarriva Ciclo 1
CUS_037_Ingresar a chat online Secundario Definido Alta Luis Sumarriva Ciclo 2
CUS_038_Generar Reportes de Rendimiento del área Primario Definido Alta Luis Sumarriva Ciclo 2
CUS_039_Generar Reportes de Atención a Clientes Primario Definido Media Luis Sumarriva Ciclo 1
CUS_040_Actualizar Información de Perfiles Secundario Definido Baja Luis Sumarriva Ciclo 2
CUS_041_Actualizar Información de Usuarios Secundario Definido Baja Luis Sumarriva Ciclo 2
CUS_042_Ingresar al Sistema Secundario Definido Baja Luis Sumarriva Ciclo 1
CUS_043_Cambiar Contraseña Opcional Definido Baja Luis Sumarriva Ciclo 2
CUS_044_Actualizar cotización de solicitud de atención Primario Definido Media Luis Sumarriva Ciclo 1
CUS_045_Monitorear imagenes de sus equipos Hitrax Primario Definido Alta Luis Sumarriva Ciclo 2
CUS_046_Gestionar logs de errores del Hitrax Primario Definido Alta Luis Sumarriva Ciclo 0
Tabla 8: Atributos de los casos de uso del sistema [elaboración propia]
Página 113
5 ESPECIFICACIONES ALTO NIVEL DE LOS CASOS DE USO DE SISTEMA
Caso de uso: CUS_003_Consultar Solicitud de Atención de Servicio

Actor: AS_002_Coordinador
Permitir la búsqueda de las solicitudes de atención de servicio
Propósito:
registradas
El caso de uso comienza, cuando el actor del sistema selecciona la

opción de búsqueda de solicitudes. El actor del sistema ingresa los
Descripción:
filtros necesarios. El caso de uso termina cuando el sistema muestra
en pantalla los resultados de la consulta realizada.
Requerimientos: RF_002_Actualizar Solicitudes de Atención de Servicio

Clasificación: Primario
Caso de uso: CUS_004_Consultar casos de servicio del Cliente

Actor: AS_006_Cliente
Permitir al cliente consultar sus casos de servicio para poder darle
Propósito:
seguimiento
El caso de uso comienza cuando el cliente accede a la opción de

consultar casos de servicio. Ingresa los filtros que necesite y realiza
Descripción:
la consulta. El caso de uso termina cuando el sistema devuelve los
casos según el filtro pedido.
Requerimientos: RF_004_Actualizar Caso de Servicio

Clasificación: Secundario
Caso de uso: CUS_005_Llenar encuesta de atención de servicio

Actor: AS_006_Cliente
Permitir al cliente realizar y enviar encuesta sobre la atención de los
Propósito:
servicios atendidos
Página 114
El caso de uso comienza cuando el Cliente consulta los casos de
servicio con encuestas activadas. Accede a la encuesta y la realiza.
Descripción:
El caso de uso termina cuando el cliente finaliza la encuesta y la
envía para su procesamiento.
Requerimientos: RF_006_Realizar encuesta de servicio

Caso de uso: CUS_007_Consultar Caso de Servicio

Actor: AS_011_Operador
Propósito: Permitir consultar los casos de servicio y su historial
El caso de uso comienza cuando el Operador realiza una búsqueda

de los casos de uso según los filtrados que realice. El caso de uso
Descripción:
termina cuando el sistema muestra la lista de casos de servicio
requeridos por el operador.
Requerimientos: RF_004_Actualizar Caso de Servicio

Caso de uso: CUS_008_Mostrar Posibles Soluciones al Caso de Servicio

Pedir al sistema que realice un análisis de las posibles soluciones al
Propósito:
problema ingresado en el caso de servicio
El caso de uso comienza cuando el Operador pide al sistema que le

muestre las posibles soluciones al detalle del problema indicado en
Descripción:
el caso de servicio. El caso de uso termina cuando el sistema
muestra en pantalla una lista de posibles soluciones.
Requerimientos: RF_005_Mostrar Posibles Soluciones al Caso de Servicio

Caso de uso: CUS_009_Consultar Cliente

Página 115
Propósito: Permitir la consulta de los clientes
El caso de uso comienza, cuando el Operador desea consultar los

datos de un cliente. El Operador ingresa los filtros de búsqueda
Descripción:
necesarios. El caso de uso termina cuando el sistema muestra los
clientes que coinciden con los filtros consultados.
Requerimientos: RF_026_Actualizar Cliente

Caso de uso: CUS_010_Actualizar Cliente

Actor: AS_010_Asistente
Permitir la el registro, modificación y eliminación de la información
Propósito:
de un cliente
El caso de uso comienza, cuando el Asistente tiene que actualizar

algún dato de los clientes. El Asistente puede registrar, modificar,
Descripción:
visualizar y eliminar los datos del cliente. El caso de uso termina
cuando se actualiza la información del cliente.
Requerimientos: RF_026_Actualizar Cliente

Caso de uso: CUS_011_Registrar Contrato de Servicio

Propósito: Permitir el registro de los contrato de servicio
El caso de uso comienza, cuando el Asistente tiene que registrar el

contrato de servicio. El Asistente registra los datos del contrato de
Descripción:
servicio. El caso de uso termina cuando el sistema valida el registro
correcto del contrato de servicio.
Requerimientos: RF_028_Actualizar Contrato de Servicio

Caso de uso: CUS_012_Registar alertas para mantenimientos programados
Página 116
Permitir registrar y emitir las alertas de los próximos
Propósito:
mantenimientos programados.
El caso de uso comienza cuando se ha registrado un contrato de

servicio. El sistema registra las alertas para los mantenimientos
Descripción:
según el contrato de servicio. El caso de uso termina cuando el
sistema manda la alerta por un próximo mantenimiento programado.
Requerimientos: RF_029_Registar alertas para mantenimientos programados

Caso de uso: CUS_013_Enviar alerta de nuevo servicio

Propósito: Permitir enviar una alerta de nuevo servicio al móvil del técnico
El caso de uso comienza cuando el actor del sistema genera una

orden de servicio. El sistema envía una alerta de nuevo servicio al
Descripción:
móvil del técnico asignado. El caso de uso termina cuando se
verifica la recepción de la alerta.
Requerimientos: RF_011_Enviar alerta de nuevo servicio

Caso de uso: CUS_014_Generar Orden de Servicio

Permitir generar la orden de servicio que será llevada por el técnico
Propósito:
al cliente
El caso de uso comienza cuando el actor del sistema consulta el caso
de servicio que ya fue aprobado en asignación de técnico. Luego
Descripción: elige opción generar orden de servicio. Elige los ítems que llevará.
El caso de uso termina cuando el sistema genera la orden de
servicio.
Requerimientos: RF_012_Generar Orden de Servicio
Página 117
Caso de uso: CUS_016_Actualizar calendario de tareas
Permitir consultar un calendario de las tareas programadas y
Propósito:
asignadas
El caso de uso comienza cuando el actor del sistema escoge la

opción de consultar calendario. Ingresa el rango de fechas
Descripción:
requeridas. El caso de uso termina cuando el calendario de tareas es
mostrado por el sistema.
Requerimientos: RF_010_Actualizar Agenda de Tareas del Técnico

Caso de uso: CUS_017_Consultar Horario Técnico

Actor: AS_009_Asignador
Consultar los horarios de los técnicos para verificar su
Propósito:
disponibilidad.
opción de “Consultar Horario de Técnicos”, donde podrá visualizar
Descripción: los horarios disponibles de los técnicos. El caso de uso termina
cuando el sistema muestra la información requerida por el actor del
sistema.
Requerimientos: RF_007_Programar técnicos
Caso de uso: CUS_018_Asignar Técnico

Propósito: Asignar técnicos a los casos de uso pendientes por asignación.

opción de “Asignación de Técnicos”, donde podrá asignar al técnico
Descripción:
que realizará el caso de servicio. El caso de uso termina cuando el
caso de servicio queda actualizado con la asignación del técnico.
Página 118
Requerimientos: RF_007_Programar técnicos
Caso de uso: CUS_019_Mostrar Posibles Técnicos

Pedir al sistema que realice un análisis de los posibles técnicos que
Propósito:
pueden ser asignados al caso de servicio
El caso de uso comienza cuando el actor del sistema va a realizar
una asignación de técnico. Elige la opción de mostrar posibles
Descripción: técnicos. El caso de uso termina cuando el sistema muestra una lista
de los posibles técnicos mejor capacitados para poder realizar el
servicio.
Requerimientos: RF_009_Mostrar Autoasignación de Técnicos
Caso de uso: CUS_020_Actualizar Técnico

Permitir el registro, modificación y eliminación de la información
Propósito:
de los técnico
El caso de uso comienza cuando el actor del sistema tiene que

actualizar algún dato de los técnicos. Puede registrar, modificar,
Descripción:
visualizar y eliminar los datos del técnico. El caso de uso termina
cuando se actualiza la información del técnico.
Requerimientos: RF_032_Actualizar Técnico

Caso de uso: CUS_021_Actualizar Competencias del Técnico

Propósito:
de las competencias del técnico
Página 119
actualizar algún dato de competencias del técnico. Puede registrar,
Descripción: modificar, visualizar y eliminar los datos de las competencias del
técnico. El caso de uso termina cuando se actualiza la información
de las competencias del técnico.
Requerimientos: RF_031_Actualizar Competencias del Técnico
Caso de uso: CUS_022_Consultar Técnico

Propósito: Permitir la consulta de los técnicos
El caso de uso comienza cuando el Operador desea consultar los

datos de un técnico. El Operador ingresa los filtros de búsqueda
Descripción:
necesarios. El caso de uso termina cuando el sistema muestra los
técnicos que coinciden con los filtros consultados.
Requerimientos: RF_032_Actualizar Técnico

Caso de uso: CUS_023_Actualizar niveles de competencia del técnico

Actor: AS_005_Gerente
Permitir el registro, modificación y eliminación de los niveles de
Propósito:
competencia del técnico
actualizar algún valor del nivel de competencia. Puede registrar,
Descripción: modificar, visualizar y eliminar los datos de los niveles. El caso de
uso termina cuando se actualiza la información de los niveles de
competencia del técnico.
Requerimientos: RF_033_Actualizar niveles de competencia del técnico
Caso de uso: CUS_024_Aprobar asignación de técnicos
Página 120
Actor: AS_008_Aprobador
Revisar y aprobar las asignaciones de técnicos realizadas a los casos
Propósito:
de servicio.
El caso de uso comienza cuando el actor del sistema selecciona la

opción de “Aprobar técnico”, donde podrá aprobar o rechazar la
Descripción:
asignación del técnico. El caso de uso termina cuando la asignación
del técnico en un caso de servicio has sido aprobado.
Requerimientos: RF_008_Aprobar técnicos asignados

Caso de uso: CUS_025_Actualizar Reporte de Servicio

Actor: AS_004_Técnico
Propósito: Efectuar la actualización de un Reporte de Servicio

opción de “Reporte de Servicio”, donde podrá registrar el reporte de
Descripción:
servicio. El caso de uso termina con la Actualización del Reporte de
Servicio.
RF_013_Adjuntar fotos
RF_014_Lectura de código de barras
Requerimientos:
RF_015_Firma digital del Reporte de Servicio
RF_019_Actualizar Reporte de Servicio
Caso de uso: CUS_026_Consultar Agenda de Tareas

Propósito: Permitir al técnico poder consultar su agenda de tareas
El caso de uso comienza cuando el técnico selecciona consultar su

Descripción: agenda de tareas. El caso de uso termina cuando el sistema muestra
la agenda de tareas al técnico.
Página 121
Requerimientos: RF_010_Actualizar Agenda de Tareas del Técnico
Caso de uso: CUS_027_Enviar ubicación actual

Actor: AS_004_Técnico, AS_013_Google Maps
Propósito: Enviar la ubicación actual del técnico en un momento específico
El caso de uso comienza cuando el sistema se conecta el servicio
Google Services, el Actor Google Maps certifica las coordenadas, y
Descripción: el sistema envía un registro de la ubicación actual del técnico con la
hora actual. El caso de uso termina cuando el sistema verifica que
los datos han sido registrados satisfactoriamente.
Requerimientos: RF_024_Actualizar ubicación de Técnico
Caso de uso: CUS_028_Actualizar Lista de Herramientas

Permitir al técnico poder consultar la lista de herramientas y
Propósito:
registrar un reporte de herramientas o una solicitud de compra.
El caso de uso comienza cuando el actor del sistema requiere revisar
la lista de herramientas. Si antes de un servicio alguna herramienta
le falta o está averiada el técnico registra la solicitud de compra de
Descripción: la herramientas, si después de servicio realiza la revisión entonces
registra el reporte de herramientas especificando las herramientas
faltantes y el motivo. El caso de uso termina cuando el sistema
actualiza la solicitud o el reporte en el sistema.
RF_022_Revisar lista de herramientas
Requerimientos:
RF_023_Actualizar Reporte de herramientas
Secundario Secundario
Caso de uso: CUS_029_Actualizar Informe Técnico

Propósito: Efectuar la actualización de un Informe Técnico.
Página 122
opción de “Informe Técnico”, donde podrá registrar el informe
Descripción:
técnico para su revisión y envío al cliente. El caso de uso termina
con la Actualización del Informe Técnico.
Requerimientos: RF_020_Actualizar Informe Técnico

Caso de uso: CUS_030_Consultar ubicación de Técnico

Actor: AS_003_Supervisor, AS_013_Google Maps
Propósito: Consultar la ubicación de un técnico en un intervalo de tiempo
El caso de uso comienza cuando el Supervisor quiere consultar la
ubicación de un técnico. Elige el rango de fecha donde saldrá la
búsqueda de la posiciones del técnico. El sistema se conecta con
Descripción: Google Service y el actor Google Maps envía el mapa con los
servicios de navegación. El caso de uso termina cuando el sistema
muestra las posiciones registras del técnico dentro del mapa de
Google Maps como coordenadas en el rango de fecha elegido.
Requerimientos: RF_024_Actualizar ubicación de Técnico
Caso de uso: CUS_031_Consultar Informe Técnico

Actor: AS_003_Supervisor
Propósito: Efectuar la consulta de un Informe Técnico.
El caso de uso comienza cuando el actor del sistema requiere

consultar un Informe Técnico. Selecciona los filtros de búsqueda
Descripción:
necesarios. El caso de uso termina cuando el sistema devuelve los
Informes Técnicos buscados.
Requerimientos: RF_020_Actualizar Informe Técnico

Caso de uso: CUS_032_Aprobar Informe Técnico
Página 123
Actor: AS_008_Aprobador
Propósito: Revisar los informes técnicos registrado por los técnicos.

opción de “Aprobar Informe Técnico”, donde podrá revisar un
Descripción:
Informe Técnico para luego aprobarlo o rechazarlo. El caso de uso
termina cuando Informe Técnico ha sido aprobado o rechazado.
Requerimientos: RF_021_Aprobar Informe Técnico

Caso de uso: CUS_033_Actualizar Equipo

Permitir la el registro, modificación y eliminación de la información
Propósito:
de los equipos

actualizar algún dato de los equipos. Puede registrar, modificar,
Descripción:
visualizar y eliminar los datos del equipo. El caso de uso termina
cuando se actualiza la información del equipo.
Requerimientos: RF_027_Actualizar Equipo

Caso de uso: CUS_034_Enviar alerta por garantía

Permitir enviar las alertas por próximo vencimiento de garantía al
Propósito:
correo o móvil asignado
El caso de uso comienza el sistema requiere enviar una alerta de
próximo vencimiento de garantía. El sistema envía una alerta al
Descripción: correo y móvil del usuario designado faltando 1 mes, con un
recordatorio cada semana. El caso de uso termina cuando el sistema
confirma el envío y recepción de las alertas.
Requerimientos: RF_018_Enviar alerta por garantía
Página 124
Caso de uso: CUS_035_Actualizar Piezas por Equipo
Propósito:
de las piezas de repuesto de los equipos
El caso de uso comienza, cuando el actor del sistema tiene que
actualizar algún dato de las piezas de reparación de los equipos.
Descripción: Puede registrar, modificar, visualizar y eliminar los datos de las
piezas. El caso de uso termina cuando se actualiza la información de
las piezas del equipo.
Requerimientos: RF_030_Actualizar Piezas por Equipo
Caso de uso: CUS_036_Consultar Equipo

Propósito: Permitir la consulta de los equipos
El caso de uso comienza cuando el actor del sistema desea consultar

los datos de un equipo. Ingresa los filtros de búsqueda necesarios. El
Descripción:
caso de uso termina cuando el sistema muestra los equipos que
coinciden con los filtros consultados.
Requerimientos: RF_027_Actualizar Equipo

Caso de uso: CUS_037_Ingresar a chat online

Permitir el ingreso a un chat privado online entre el técnico móvil y
Propósito:
la oficina central

opción de chat en línea. El caso de uso termina cuando el sistema
Descripción:
muestra la interfaz de chat en línea y los usuarios conectados
disponibles para entablar conversación.
Página 125
Requerimientos: RF_017_Ingresar a chat online
Caso de uso: CUS_038_Generar Reportes de Rendimiento del área

Permitir la generación de reportes a medida personalizados
Propósito:
utilizando los datos disponibles en el sistema
El caso de uso comienza cuando el actor del sistema necesita un
Reporte nuevo. Selecciona los datos que necesitara que aparezcan en
Descripción: el reporte. El caso de uso termina cuando el sistema genera el
reporte requerido y guarda el modelo para futuras consultas al
mismo reporte.
Requerimientos: RF_025_Generar Reportes del área
Caso de uso: CUS_039_Generar Reportes de Atención a Clientes

Propósito: Permitir la generación de los reportes gerenciales usados por el área
El caso de uso comienza, cuando el actor del sistema desea generar

un reporte de los ya predefinidos del área. Escoge el intervalo de
Descripción:
fechas, equipo, técnico y cliente que saldrá en el reporte. El caso de
uso termina cuando el sistema genera el reporte solicitado.
Requerimientos: RF_025_Generar Reportes del área

Caso de uso: CUS_044_Actualizar cotización de solicitud de atención

Actor: AS_012_Asistente Comercial
Actualizar el estado de la cotización de los equipos de la solicitud de
Propósito:
atención
Página 126
El caso de uso comienza cuando el actor del sistema ingresa a la
opción solicitud de atención y se muestran las solicitudes con
equipos pendientes de cotización. El actor del sistema ingresa a la
Descripción: solicitud de atención requerida y cambia el estado de la cotización
de los equipos a aceptada o rechazada. El caso de uso termina
cuando el sistema graba la información y da un mensaje de
confirmación de la transacción
Requerimientos: RF_001_Registrar Estado de la Cotización
Caso de uso: CUS_045_Monitorear imágenes de sus equipos Hitrax

Actor: AS_006_Cliente, AS_014_Hitrax
Actualizar el estado de la cotización de los equipos de la solicitud de
Propósito:
atención
El caso de uso comienza cuando el actor del sistema ingresa a la
opción monitoreo de equipos. El actor del sistema selecciona el
Descripción: equipo a monitorear de una lista. El caso de uso termina cuando el
sistema le muestra las imágenes transmitidas por el actor Hitrax en
tiempo real.
Requerimientos: RF_035_Monitoreo de imágenes escaneadas
Página 127
6 ESPECIFICACIONES DETALLADAS LOS CASOS DE USO DEL NÚCLEO
CENTRAL
6.1 CUS_001_Registrar Solicitud de Atención de Servicio
Actores de Sistema
 AS_006_Cliente
Propósito
 Registrar una Solicitud de Atención de Servicio de una falla de uno o varios equipos del
cliente.
Breve Descripción
 El caso de uso comienza, cuando el actor del sistema selecciona la opción de “Crear
Solicitud”, en donde podrá registrar una nueva solicitud de atención de servicio. El caso
de uso termina cuando el actor registra a los equipos dentro de la solicitud y está queda
registrada en el sistema con estado pendiente.
Flujo de Eventos
 Flujo Básico
1. El actor del sistema selecciona la opción Solicitud de Servicio del Menú.
2. El actor del sistema selecciona la opción Crear Solicitud.
3. El sistema muestra la página Registrar Solicitud de Atención Nueva con los
siguiente campos:
- Fecha de Solicitud (Fecha Actual. No editable)
- Observaciones
Y con las opciones:
- Agregar
- Cancelar
Página 128
4. El actor del sistema ingresa los datos necesarios y hace click en la opción Agregar.
Si el actor selecciona la opción Cancelar, termina el caso de uso y el sistema retorna
a la página de inicio.
5. El sistema graba la información ingresada por el actor del sistema y crea la solicitud
de servicio con un código correlativo único automático.
6. El sistema muestra la página Registrar Detalle de Solicitud de Atención #X (X es el
número correlativo creado por el sistema) con los siguientes campos:
- Marca
- Modelo
- Serie
- #Error
- Problema
- Observaciones
Y con las opciones:
- Agregar
- Cancelar
Asimismo muestra una lista con los equipos que están registrados dentro de la
solicitud de atención de servicio. La lista tiene los siguientes campos:
- Marca
- Modelo
- Serie
- Problema
- Error
- Observaciones
- Opción Editar
- Opción Borrar
7. El actor del sistema ingresa los datos necesarios y selecciona la opción Agregar. Si
el actor del sistema selecciona la opción Editar, se ejecuta el subflujo Editar Detalle
de Solicitud de Servicio, si el actor del sistema selecciona la opción Borrar, se
ejecuta el subflujo Borrar Detalle de Solicitud de Servicio. Si el actor selecciona la
opción Cancelar, termina el caso de uso y el sistema retorna a la página de inicio.
8. El sistema valida los datos requeridos y graba la información ingresada por el actor
del sistema.
Página 129
9. El sistema muestra en la parte superior de la pantalla el mensaje: “Equipo Agregado
a la Solicitud de Atención”.
10. El caso de uso retorna al paso [6] del flujo básico.
 SubFlujos
Editar Detalle de Solicitud de Servicio

1. En el punto [7] del flujo básico, el actor del sistema selecciona la opción Editar.
2. El sistema muestra la pantalla Editar Detalle de Solicitud de Atención con los datos
del detalle de la Solicitud seleccionada. Los campos sin poder editar son:
- Marca
- Modelo
- Serie
Los campos editable son:
- #Error
- Problema
- Observaciones
Y las opciones:
- Grabar
- Cancelar
3. El actor del sistema ingresa los datos requeridos y selecciona la opción Grabar.
4. El sistema válida los datos y graba la información ingresada por el actor del
sistema.
5. El sistema cierra la ventana de Editar y muestra un mensaje en la parte superior
“Detalle de la Solicitud Editada”.
6. El caso de uso regresa al punto [6] del flujo básico
Borrar Detalle Solicitud de Servicio

1. En el punto [7] del flujo básico, el actor del sistema selecciona la opción Borrar.
2. El sistema muestra el mensaje “¿Desea eliminar el equipo de la Solicitud de
Atención?” con las opciones:
- Aceptar
- Cancelar
Página 130
3. El actor del sistema selecciona la opción Aceptar.
4. El sistema cierra el mensaje, borra el equipo de la solicitud de servicio y muestra el
mensaje en la parte superior de la pantalla “Equipo Eliminado de la Solicitud”.
5. El caso de uso regresa al punto [6] del flujo básico.
 Flujos Alternos
Cancelación de Editar Detalle de Solicitud de Servicio

Si en el punto [3] del subflujo Editar Detalle de Solicitud de Servicio el actor del
sistema selecciona la opción Cancelar, el sistema cierra la pantalla y regresa al paso [6]
del flujo básico.
Cancelación de Borrar Detalle de Solicitud de Servicio

Si en el punto [3] del subflujo Borrar Detalle de Solicitud de Servicio el actor del
sistema selecciona la opción Cancelar, el sistema cierra la pantalla y regresa al paso [6]
del flujo básico.
Precondiciones
 Credenciales del sistema
El actor debe contar con usuario y contraseña para acceder al sistema.
 Lista de Equipos
Debe existir una lista de Equipos registrados en el sistema
 Lista de Clientes
Debe existir una lista de Clientes registrados en el sistema.
Postcondiciones
 Solicitud de Atención de Servicio Registrado
La Solicitud de Atención de Servicio quedará registrada con los datos ingresados por el
actor del sistema con el estado Pendiente.
Puntos de Inclusión
 No aplica
Página 131
Puntos de Extensión
 No aplica
Requerimientos Funcionales Asociados

 RF_002_Actualizar Solicitudes de Atención de Servicio
Reglas de Negocio
 RN_25_ Asociación de equipos a una Solicitud de Servicio
Información Adicional
Gráfico 21: Formulario Registro Solicitud de Atención nueva [elaboración propia]
Página 132
Gráfico 22: Formulario Registro Detalle de Solicitud de Atención [elaboración propia]
Gráfico 23: Formulario Edición de Detalle de Solicitud de Atención [elaboración propia]
Gráfico 24: Mensaje Eliminación de Detalle de Solicitud de Atención [elaboración propia]
Página 133
Página 134
6.2 CUS_002_Consultar Solicitud de Atención de Servicio del Cliente
Actores de Sistema
 AS_006_Cliente
Propósito
 Consultar las Solicitudes de Servicio registradas por el cliente y su estado actual.
Breve Descripción
 El caso de uso comienza, cuando el actor del sistema selecciona la opción de
“Consultar Solicitud”, donde podrá buscar una solicitud de servicio. El caso de uso
termina cuando el sistema muestra en pantalla los datos de la solicitud consultada.
Flujo de Eventos
 Flujo Básico
1. El actor del sistema selecciona la opción Solicitud de Servicio del Menú.
2. El actor del sistema selecciona la opción Consultar Solicitud.
3. El sistema muestra la página Consultar Solicitud de Atención con los siguiente
campos de búsqueda:
- Código
- Fecha Inicial
- Fecha Final
- Estado
Y con las opciones:
- Buscar
- Cancelar
Así mismo muestra la lista de las 20 Solicitudes más recientes. La lista tiene los
siguientes campos:
- Código
- Fecha
- Estado
- Observaciones
Página 135
- Opción Detalle
4. El actor del sistema ingresa los filtros necesarios y selecciona la opción Buscar. Si
el actor del sistema selecciona la opción Detalle, se ejecuta el sub flujo Detalle de
Solicitud de Servicio. Si el actor selecciona la opción Cancelar, termina el caso de
uso y el sistema retorna a la página de inicio.
5. El sistema valida los datos ingresado y actualiza la lista con los datos encontrados
que concuerden con los filtros ingresados.
 SubFlujos
Detalle de Solicitud de Servicio

1. En el punto [4] del flujo básico, el actor del sistema selecciona la opción Detalle.
2. El sistema muestra una lista con el detalle de la Solicitud seleccionada con los
siguientes campos:
- Marca
- Modelo
- Serie
- Problema
- Error
- Observaciones
 Flujos Alternos
No hay registros coincidentes

Si en el punto [5] del flujo básico el sistema no encuentra datos que concuerden con los
filtros ingresados, se muestra un mensaje en la parte superior de la pantalla “No hay
registros coincidente”, retornado al paso [3] del flujo básico.
Precondiciones
Página 136
Postcondiciones
La Solicitud de Atención de Servicio continúa en el mismo estado.
 No aplica
 No aplica

 RF_002_Actualizar Solicitudes de Atención de Servicio
Reglas de Negocio
 No aplica
Página 137
Gráfico 25: Formulario Consulta Solicitud de Atención [elaboración propia]
Gráfico 26: Formulario Consulta Solicitud de Atención Filtrado [elaboración propia]
Gráfico 27: Detalle de Solicitud de Atención [elaboración propia]
Página 138
6.3 CUS_006_Actualizar Caso de Servicio
Actores de Sistema
Propósito
 Registrar un Caso de Servicio para la atención de un servicio de un cliente.
Breve Descripción
Caso Servicio”, en donde podrá registrar un nuevo caso de servicio. El caso de uso
termina cuando el actor registra a los equipos dentro del caso y está queda registrada en
el sistema con estado pendiente.
Flujo de Eventos
 Flujo Básico
1. El actor del sistema selecciona la opción Caso Servicio del Menú.
2. El actor del sistema selecciona la opción Crear Caso Servicio.
- Código
- Fecha Inicial
- Fecha Final
- Estado
Y con las opciones:
- Nuevo Caso
- Buscar
- Cancelar
Así mismo muestra la lista de las 20 Solicitudes con estado pendiente. La lista tiene
los siguientes campos:
- Código
- Fecha
Página 139
- Estado
- Observaciones
- Opción Ver
- Opción Crear Caso
4. El actor del sistema selecciona la opción Nuevo Caso. Si el actor del sistema
selecciona la opción Buscar, se ejecuta el caso de uso “CUS_003_Consultar
Solicitud de Atención de Servicio”. Si el actor del sistema selecciona la opción Ver,
se ejecuta el subflujo Ver Solicitud de Servicio. Si el actor del sistema selecciona la
opción Crear Caso, se ejecuta el subflujo Creación de Caso de Servicio. Si el actor
selecciona la opción Cancelar, termina el caso de uso y el sistema retorna a la
página de inicio.
5. El sistema muestra la página Registrar Caso de Servicio Nuevo con los siguiente
campos:
- Fecha Caso (Fecha Actual. No editable)
- Cod Solicitud (No editable)
- N° Equipos (No Editable)
- Observaciones
Y con las opciones:
- Crear
- Cancelar
6. El actor del sistema ingresa los datos necesarios y selecciona la opción Crear.
7. El sistema graba la información ingresada por el actor del sistema y crea el caso de
servicio con un código único automático.
8. El sistema muestra la página Registrar Detalle de Caso de Servicio #X (X es el
- Marca
- Modelo
- Serie
- Fecha Inicial
- Fecha Final
- Tipo de Servicio
- Detalle de Servicio
- #Error
Página 140
Y con las opciones:
- Agregar
- Cancelar
Asimismo muestra una lista con los equipos que están registrados dentro del caso de
servicio. La lista tiene los siguientes campos:
- Marca
- Modelo
- Serie
- Tipo
- Detalle
- Reporte
- Opción Editar
- Opción Borrar
9. El actor del sistema ingresa los datos necesarios y selecciona la opción Agregar. Si
el actor del sistema selecciona la opción Editar, se ejecuta el subflujo Editar Detalle
de Caso de Servicio, si el actor del sistema selecciona la opción Borrar, se ejecuta el
subflujo Borrar Detalle de Caso de Servicio.
del sistema.
al Caso de Servicio”.
 SubFlujos
Creación de Caso de Servicio

1. En el punto [4] del flujo básico, el actor del sistema selecciona la opción Crear
Caso.
campos:
Página 141
- Observaciones
Y con las opciones:
- Crear
- Cancelar
5. El sistema verifica la cantidad de equipos con garantía vigente que están en la
solicitud de servicio y los graba dentro del detalle del caso de servicio nuevo recién
creado.
Editar Detalle de Caso de Servicio

2. El sistema muestra la pantalla Editar Detalle de Caso de Servicio con los datos del
detalle del equipo seleccionado. Los campos sin poder editar son:
- Marca
- Modelo
- Serie
- Fecha Inicial
- Fecha Final
- Tipo de Servicio
- Error
Y las opciones:
- Grabar
- Cancelar
sistema.
“Detalle del Caso de Servicio Editado”.
Página 142
Borrar Detalle de Caso de Servicio

2. El sistema muestra el mensaje “¿Desea eliminar el equipo del Caso de Servicio?”
con las opciones:
- Aceptar
- Cancelar
4. El sistema cierra el mensaje, borra el equipo del caso de servicio y muestra el
mensaje en la parte superior de la pantalla “Equipo Eliminado del Caso de
Servicio”.
 Flujos Alternos
Cancelación de Registrar Caso de Servicio

Si en el punto [5] del flujo básico el actor del sistema selecciona la opción Cancelar, el
sistema regresa al paso [3] del flujo básico.
Cancelación de Registrar Detalle de Caso de Servicio

Campos obligatorios
Si en el punto [9] del flujo básico el actor no ingresa todos los campos obligatorios, el
sistema muestra el mensaje “Debe de llenar todos los campos obligatorios”. El sistema
regresa al paso [8] del flujo básico
Garantía activas en equipos

Si en el punto [5] del subflujo Creación Casos de Servicio, el sistema verifica que
ningún equipo dentro de la solicitud tiene garantía vigente, muestra un mensaje en la
parte superior de la pantalla “Error al Crear Caso de Servicio. Solicitud no presenta
Página 143
equipos con garantías activas”. El sistema regresa al paso [2] del subflujo Creación
Casos de Servicio.
Cancelación de Editar Detalle de Caso de Servicio

Si en el punto [2] del subflujo Editar Detalle de Caso de Servicio el actor del sistema
selecciona la opción Cancelar, el sistema cierra la pantalla y regresa al paso [8] del
flujo básico.
Cancelación de Borrar Detalle de Caso de Servicio

Si en el punto [2] del subflujo Borrar Detalle de Caso de Servicio el actor del sistema
flujo básico.
Precondiciones
Postcondiciones
 Solicitud de Atención de Servicio Registrado
La Solicitud de Atención de Servicio quedará registrada con los datos ingresados por el
actor del sistema con el estado Pendiente.
 CUS_003_Consultar Solicitud de Atención de Servicio
 No aplica
Página 144
 RF_004_Actualizar Caso de Servicio
Reglas de Negocio
 RN_05_Confirmación de atención
 RN_06_Atención programada
 RN_17_Código de caso de servicio
 RN_20_Asociación de casos de servicio
 RN_23_Caso de servicio pendiente
Gráfico 28: Formulario Búsqueda Solicitudes de Atención [elaboración propia]
Página 145
Gráfico 29: Formulario Registro Caso de Solicitud de Servicio Nuevo [elaboración propia]
Gráfico 30: Formulario Registro Detalle de Caso de Servicio [elaboración propia]
Gráfico 31: Formulario Edición Detalle de Caso de Servicio [elaboración propia]
Página 146
Gráfico 32: Mensaje Eliminación Detalle de Caso de Servicio [elaboración propia]
Página 147
6.4 CUS_015_Gestionar planificación más idónea para casos de servicio
Actores de Sistema
Propósito
 Gestionar las asignaciones de los casos de servicio y seleccionar al técnico más idóneo
para un servicio.
Breve Descripción
“Asignación de Técnicos”, donde podrá seleccionar que caso de servicio necesita la
asignación de un técnico. El caso de uso termina cuando el sistema muestra en pantalla
el técnico más idóneo y lo registra en el Caso de Servicio.
Flujo de Eventos
 Flujo Básico
1. El actor del sistema selecciona la opción Planificación de Casos.
2. El actor del sistema selecciona la opción Asignar Técnico.
3. El sistema muestra la página Consultar Caso de Servicio con los siguiente campos
de búsqueda:
- Código
- Fecha Inicial
- Fecha Final
- Estado
Y con las opciones:
- Buscar
- Cancelar
Así mismo muestra la lista de los 20 Casos de Servicio con estado pendiente. La
lista tiene los siguientes campos:
- Código
Página 148
- Solicitud
- Fecha
- Estado
- Asignados (# Técnicos asignados / # Equipos en el Caso)
- Observaciones
- Opción Detalle
4. El actor del sistema selecciona la opción Detalle. Si el actor del sistema selecciona
la opción Buscar, se ejecuta el caso de uso “CUS_007_Consultar Caso de Servicio”.
Si el actor selecciona la opción Cancelar, termina el caso de uso y el sistema retorna
a la página de inicio.
5. El sistema muestra la lista con los equipos conforman el caso de Servicio
seleccionado. La lista tiene los siguientes campos:
- Marca
- Modelo
- Serie
- Ubicación
- Tipo de servicio
- Técnico
- Fecha Inicio
- Fecha Fin
- #Error
- Opción Asignar
6. El actor del sistema selecciona la opción de “Asignar”.
7. El sistema procesa los datos y variables para la autoselección del técnico.
8. El sistema muestra la página “Asignar Técnico a Detalle #X del Caso de Servicio
#Y (X es el código de fila del Detalle del Caso, Y es el código del Caso de Servicio)
con los siguientes campos no editables mostrando el técnico más idóneo para el
servicio y la distancia en metros de su ubicación al punto de servicio:
- Técnico Propuesto
- Distancia al Servicio (A -> B)
- Disponibilidad
El campo editable obligatorio:
- Técnico
Página 149
También las opciones:
- Asignar
- Cancelar
Así mismo, muestra un mapa con los puntos A y B (A coordenada donde se
encuentra el técnico y B coordenada donde se realiza el servicio) y la ruta en carro
más rápida para ir.
9. El actor del sistema selecciona el técnico para la atención.
10. El sistema válida los datos y graba el técnico en el detalle del caso de servicio. Si
todas los detalles que conforman el caso de servicio ya han sido asignados a un
técnico, el caso de servicio cambia el estado a “Asignado”.
11. El sistema muestra en pantalla el mensaje “Técnico asignado al detalle
satisfactoriamente”.
12. El caso de uso regresa al paso [3] del flujo básico.
 SubFlujos
No tiene subflujos.
 Flujos Alternos
Cancelar Asignación de Técnico

sistema no graba ninguna información y el caso de uso retorna al paso [3] del flujo
básico.
Precondiciones
 Lista de Técnicos
Debe existir una lista de Técnicos registrados en el sistema
 Casos de Servicio pendientes para asignación
Debe haber casos de servicio pendientes para asignar un técnico.
Página 150
Postcondiciones
Los asignación del caso de servicio es actualizado con el técnico elegido.
 No aplica
 No aplica

 RF_007_Programar Técnicos
 RF_016_Generar ruta más corta para servicios programados
Reglas de Negocio
 RN_04_Asignación de técnicos
Gráfico 33: Formulario Búsqueda Casos de Servicio [elaboración propia]
Página 151
Gráfico 34: Detalle Caso de Servicio [elaboración propia]
Gráfico 35: Formulario Asignación Técnico a Detalle de Caso [elaboración propia]
Página 152
Página 153
6.5 CUS_046_Gestionar logs de errores del Hitrax
Actores de Sistema
 AS_012_Operador, AS_014_Hitrax
Propósito
 Monitorear la generación de logs de errores del equipo Hitrax para su inmediata
detección, alerta y gestión por parte del operador.
Breve Descripción
“Monitoreo Errores”, donde podrá detectar la creación del archivo de error generado
por el equipo Hitrax y emitirá una alerta. El caso de uso termina cuando el actor del
sistema carga el archivo de Log de error al sistema.
Flujo de Eventos
 Flujo Básico
1. El actor del sistema selecciona la opción Monitoreo de Equipo del Menú.
2. El actor del sistema selecciona la opción Monitoreo de Errores.
3. El sistema muestra la página Activar Monitorización de Eventos de Error y las
siguientes opciones:
- Iniciar
- Detener (Deshabilitado)
Asimismo muestra una lista con los últimos 20 logs de errores encontrados por el
sistema. La lista tiene los siguientes campos:
- Código (Código de Error)
- Marca
- Modelo
- Serie
- Cliente
- Ubicación (Del Equipo)
Página 154
- Fecha (Fecha del Error)
- Log Origen (Nombre del archivo Log)
- Opción Ver Detalle
4. El actor del sistema selecciona la opción de “Iniciar”. Si el actor del sistema
selecciona la opción “Ver Detalle” se ejecutará el subflujo de uso Ver Detalle de
Log Error.
5. El sistema muestra el mensaje Monitoreo Iniciado y en el panel alarma el mensaje
“Monitoreando…”.
6. El sistema monitoreará la carpeta compartida donde el actor del sistema Hitrax
colocará el archivo log de errores (extensión .htx) al momento de un fallo en el
equipo.
7. El actor del sistema Hitrax genera un archivo log de error, el cual tiene el formato
#####_yyyyMMddHHmmss.htx, donde ##### es el número de serie del equipo y
yyyyMMddHHmmss es la fecha y hora de detección del error. El actor del sistema
Hitrax coloca el log de error dentro de la carpeta compartida.
8. El sistema detecta dicho error y muestra una alerta en el panel de alarma con el
mensaje “Alerta Error X (X es el número de log errores detectados hasta el
momento).
9. El actor del sistema selecciona el mensaje mostrado en el panel de alarma. Si el
actor selecciona la opción “Detener”, se detiene el monitoreo, muestra el mensaje
Monitoreo Terminado y muestra el mensaje de “Detenido!” en el panel de alarma.
10. El sistema muestra la misma página con los siguientes campos, dependiendo de la
cantidad de errores que haya encontrado:
- Archivo Log
Y la opción:
- Cargar Archivo
- Iniciar (Deshabilitado)
- Detener
- Marca
Página 155
- Modelo
- Serie
- Cliente
11. El actor del sistema selecciona la opción Cargar Archivo.
12. El sistema verifica el archivo existente y los datos del archivo.
13. El sistema carga los parámetros del log de error en el sistema.
14. El sistema muestra el mensaje “Archivo Cargado Correctamente”
 SubFlujos
1. En el punto [4] del flujo básico, el actor del sistema selecciona la opción Ver
Detalle.
2. El sistema muestra la pantalla Detalle de Log de Error con los datos del fichero log
de error generado por el Hitrax. Los campos sin poder editar son:
- Código de Error
- Fecha del Error
- Detalle de Error
- Voltaje
- Alineación
- Visualización
- Puerto VGA
- Puerto COM
- Puerto Red
- Sistema Operativo
3. El actor del sistema visualiza la información.
 Flujos Alternos
Página 156
Validación de Archivo duplicado
Si en el punto [12] del flujo básico el sistema verifica que ya se cargó el mismo archivo
previamente, el sistema no carga el nuevo archivo y muestra el error “Archivo Log
Error ya se encuentra cargado” y el caso de uso retorna al paso [3] del flujo básico.
Archivo No Existente
Si en el punto [12] del flujo básico el sistema verifica que el archivo no se puede leer
(corrompido) o no encuentra el archivo dentro de la carpeta especificada, el sistema no
carga el archivo y muestra el error “Error al leer el archivo o no se encuentra” y el caso
de uso retorna al paso [3] del flujo básico.
Precondiciones
Debe existir una lista de Clientes registrados en el sistema
Postcondiciones
 Log de errores registrado en el sistema
El fichero log de error detectado es cargado al sistema.
 No aplica
 No Aplica

 RF_034_Cargar datos de errores del Hitrax al sistema
Página 157
 RF_036_Alerta de Errores en equipos Hitrax
Reglas de Negocio
 No Aplica
Gráfico 36: Panel de Monitoreo de Errores Hitrax [elaboración propia]
Gráfico 37: Monitoreo Activado [elaboración propia]
Página 158
Gráfico 38: Monitoreo Detenido [elaboración propia]
Gráfico 39: Formulario Carga de Archivo de Error [elaboración propia]
Página 159
7 MODELO CONCEPTUAL
7.1 Diagrama del Modelo Conceptual
Gráfico 40: Diagrama del Modelo Conceptual [elaboración propia]
Página 160
7.2 Diccionario del Modelo Conceptual
Nombre de la clase Solicitud Atención

Nombre del atributo Descripción Tipo dato Valor inicial Visibilidad
Código Código Autogenerado Integer 1 Privado
Fecha Solicitud Fecha registro de solicitud Date Privado
Problema Problema reportado String Privado
Estado Estado de la solicitud String Pendiente Privado
Observaciones de la
Observaciones String Privado
revisión
Fecha de última
Fecha modificación Date Privado
modificación
Nombre de la clase Solicitud Cotización

Fecha de Registro de
Fecha Cotización Date Privado
Solicitud de Cotización
Detalles adicionales de la
Detalle String Privado
solicitud de cotización
Fecha de última
Fecha modificación Date Privado
modificación
Nombre de la clase Cliente

Razón Social Razón Social del cliente String Privado
RUC RUC del cliente Integer Privado
Dirección Dirección del cliente String Privado
Teléfono Teléfono del cliente String Privado
Página 161
Nombre y apellido del
Nombre Contacto String Privado
contacto
Cargo Contacto Cargo del contacto String Privado
Latitud en coordenada de la
Latitud Double Privado
ubicación del cliente
Longitud en coordenada de
Longitud Double Privado
la ubicación del cliente
Nombre de la clase Departamento

Nombre Nombre del Departamento String Privado
Nombre de la clase Provincia

Nombre Nombre de la Provincia String Privado
Nombre de la clase Distrito

Nombre Nombre del Distrito String Privado
Nombre de la clase Contrato Mantenimiento

Nombre Nombre del contrato String Privado
Tipo Tipo de contrato String Privado
Fecha Inicio Fecha de inicio de contrato Date Privado
Fecha Fin Fecha de fin de contrato Date Privado
Nombre de la clase Encuesta
Página 162
Fecha de registro de Privado
Fecha Date
encuesta
Nombre de la clase Pregunta

Descripción Descripción de la pregunta String Privado
Nombre de la clase PreguntaXEncuesta

Respuesta Respuesta a la pregunta String Privado
Nombre de la clase Equipo

Marca Marca del Equipo String Privado
Modelo Modelo del Equipo String Privado
Serie Serie del Equipo String Privado
Ubicación Ubicación actual del Equipo String Privado
Descripción adicional del Privado
Descripción String
Equipo
Estado Estado actual del equipo String Privado
Fecha Compra Fecha de compra del equipo Date Privado
Nombre de la clase Piezas Equipo

Marca Marca de la pieza String Privado
Modelo Modelo de la pieza String Privado
Página 163
Numero Parte Número de Parte de la pieza String Privado
Descripción adicional de la Privado
Descripción String
pieza del equipo
País de donde se importa la Privado
País Manufactura Double
pieza del equipo
Nombre de la clase Caso de Servicio

Código Código Autogenerado Integer 15-001 Privado
Detalle del problema Privado
Detalle String
reportado
Fecha y Hora programada Privado
Fecha Programada Date
para la atención
Pendiente Privado
Estado Estado del caso de Servicio String
Asignación
Observaciones de la Privado
Observaciones String
asignación
Fecha de registro del caso Privado
Fecha Registro Date
de servicio
Fecha de última Privado
Fecha Modificación Date
modificación
Nombre de la clase Reporte de Servicio

Descripción Descripción del servicio String Privado
Fecha de inicio de la Privado
Fecha Inicio Date
atención
Fecha de término de la Privado
Fecha Fin Date
atención
Antecedentes Antecedentes del servicio String Privado
Página 164
Observaciones adicionales Privado
del servicio
Firmado Firma del cliente String Privado
Adjunto Foto Fotos tomadas del servicio String Privado
Fecha Registro Fecha de Registro Date Privado
modificación
Nombre de la clase Tipo Servicio

Nombre Nombre del tipo de servicio String Privado
Descripción del tipo de Privado
Descripción String
servicio
Nombre de la clase Técnico

Nombre Nombre del técnico String Privado
Apellido Paterno Apellido paterno del técnico String Privado
Apellido materno del Privado
Apellido Materno String
técnico
DNI DNI del técnico Integer Privado
Fecha Ingreso Fecha de inicio de labores Date Privado
Fecha Cese Fecha de cese de labores Date Privado
Técnico de Campo o de Privado
Tipo String
Laboratorio
Nombre de la clase Turno Horario

Nombre Nombre del turno String Privado
Página 165
Fecha Fecha del turno Date Privado
Hora Inicio Hora de Inicio String Privado
Hora Fin Hora de Fin String Privado
Nombre de la clase Informe Técnico

IT-US-07-15- Privado
Código Código Autogenerado Integer
001
Fecha de registro del Privado
Fecha Registro Date
informe
Observaciones de la Privado
aprobación
Pendiente Privado
Estado Estado del informe técnico String
Aprobación
Descripción Falla Descripción de la falla String Privado
Causa Falla Causa de la falla String Privado
Tareas realizadas en el Privado
Tarea Realizada String
servicio
Indicaciones para el buen Privado
Indicaciones String
uso del equipo
Recomendaciones para el Privado
Recomendaciones String
buen estado del equipo
Anexos Anexos adjuntos al informe String Privado
modificación
Nombre de la clase Caja Herramientas

Descripción Descripción de la caja String Privado
Fecha Asignado Fecha asignado al técnico Date Privado
Observaciones Observaciones adicionales String Privado
Página 166
Nombre de la clase Herramientas
Marca Marca de la herramienta String Privado
Modelo Modelo de la herramienta String Privado
Descripción de la Privado
Descripción String
herramienta
Cantidad Cantidad de herramientas Double Privado
Valor Valor de la herramienta Double Privado
Estado Estado de la herramienta String Privado
Nombre de la clase Competencias

Nombre Nombre de la competencia String Privado
Descripción de la Privado
Descripción String
competencia
Área a la cual pertenece la Privado
Área String
competencia
Nombre de la clase Competencias Técnico

Nivel Nivel de conocimiento Integer Privado
Página 167
8 CONCLUSIONES
 Se identificó los requerimientos funcionales y no funcionales del sistema, así mismo se

identificó los actores del sistema y los casos de uso del sistema, sobre los cuáles se
trabajar la programación del sistema.
 Se identificó los casos de uso del núcleo central, los cuáles servirán para comenzar a
desarrollar el esqueleto del programa.
 Con el modelo conceptual se pudo identificar las clases y sus relaciones entre ellas, así
como se pudo analizar los atributos que tendrá cada clase, el cual ayudará al momento
de elaborar el diagrama de entidad-relación del sistema.
Página 168
CAPÍTULO 5: ARQUITECTURA DE SOFTWARE
1 INTRODUCCIÓN
El presente capítulo contiene la Arquitectura de Software. Los diagramas de los casos de uso
más significativos para la arquitectura del software. Así mismo, se detallan las metas y
restricciones de la arquitectura de software; y también los mecanismos arquitecturales para
solucionar dichas metas y restricciones encontradas. Finalmente, se pasa a describir las vistas
que tendrá la arquitectura de software del proyecto, estas serán la Vista Lógica, donde se
detallan el sistema y las capas que corresponden; la Vista de Implementación, donde se
detallan las librerías y aplicativos a utilizar; la Vista de Despliegue, donde que detallan el
hardware y conexiones que tendrá el proyecto.
Página 169
2 DIAGRAMA DE LOS CASOS DE USO MÁS SIGNIFICATIVOS PARA LA
ARQUITECTURA DEL SOFTWARE
Gráfico 41: Diagrama de los CUS más significativos para la arquitectura del software
[elaboración propia]
Página 170
3 METAS DE LA ARQUITECTURA DE SOFTWARE
A continuación presentamos un inventario de los requerimientos funcionales de uso general y

de los requerimientos no funcionales de mayor impacto en la arquitectura y que son metas
para la arquitectura de software.
METAS DE LA ARQUITECTURA DE SOFTWARE

Código Descripción
Requerimientos Funcionales de uso general
Enviar alerta de nuevo servicio
RF_011 El sistema debe enviar una alerta al móvil del técnico sobre el nuevo caso de
servicio asignado.
Enviar alerta por garantía
RF_018 El sistema debe poder emitir alertas y mostrarlas en el sistema cuando un equipo
está a un mes de su vencimiento de garantía y/o de contrato de mantenimiento.
Actualizar ubicación de Técnico
El sistema debe enviar las coordenadas de ubicación cada vez que el técnico
RF_024 actualice el Reporte de Servicio o realice consultas a su agenda de tareas, así mismo
debe poder mostrar las ubicaciones registradas de los técnicos dentro de un rango de
fecha.
Registrar alertas para mantenimientos programados
RF_029 El sistema debe poder registrar y mandar alertas de los próximos mantenimientos
programados.
Cargar datos de errores del Hitrax al sistema
RF_034 El sistema debe poder cargar los datos y parámetros de los archivos logs de errores
generados del Hitrax para su registro y análisis en el diagnóstico de un equipo.
Alerta de Errores en equipos Hitrax
RF_036 El sistema debe poder alertar de un error producido en el equipo Hitrax de forma
automática y mostrarla en pantalla para su inmediata acción.
Requerimientos de capacidad de uso
Página 171
Manejo de Excepciones
RNF_002 El sistema debe manejar adecuadamente los errores que puedan generarse durante la
ejecución del sistema.
Generación de reportes
RNF_003 El sistema debe poder generar los reportes solicitados por la gerencia como
promedio en 20 segundos.
Exportar e Imprimir Información
RNF_004 Todas las tablas mostradas en el sistema deben permitir exportar e imprimir la
información consultada a formato PDF o Excel.
Requerimientos de confiabilidad
Alerta ante fallas
RNF_005 El sistema ante una falla posible enviará un mensaje email al personal de Soporte
designado, con el dato detallado del error.
Tiempo de Caída
RNF_006
El tiempo de caída del sistema no deberá exceder 15 minutos.
Disponibilidad del Sistema
RNF_007 El sistema debe estar disponible en un 95% durante el horario laboral de Lunes a
Viernes de 9:00 am a 06:00 pm.
Requerimientos de rendimiento
Tiempo de Respuesta
El sistema debe permitir un tiempo de respuesta para las transacciones que no debe
RNF_008 exceder:
• Los 4 segundos con un ancho de banda de 100 Mbps.
• Los 6 segundos con un ancho de banda de 54 Mbps.
Tiempo de Consulta
RNF_009 El tiempo promedio de cada consulta realizada al sistema deberá ser menor a 6
segundos.
Página 172
Inactividad de la Sesión
El sistema debe detectar el tiempo de inactividad en la sesión de un usuario de
RNF_010
sistema, teniendo como límite de tiempo 5 minutos, luego de transcurrido este
tiempo se cerrará automáticamente la sesión.
Concurrencia de Usuarios
RNF_012
El sistema permitirá el acceso concurrente de 20 usuarios diferentes.
Tiempo de Respuesta de Reportes
RNF_013 El tiempo de respuesta promedio del sistema para las operaciones involucradas con
los reportes es de 6 segundos.
Requerimientos de soporte
Log de Auditoria
RNF_017 El sistema registrará el usuario que ejecutó la transacción, así como la fecha y hora
de modificación.
Tabla 9: Metas de la Arquitectura de Software [elaboración propia]
Página 173
4 RESTRICCIONES DE LA ARQUITECTURA DE SOFTWARE
A continuación presentamos un inventario de los requerimientos no funcionales de mayor

impacto en la arquitectura y que son restricciones de la arquitectura de software.
RESTRICCIONES DE LA ARQUITECTURA DE SOFTWARE

Requerimientos de capacidad de uso
Facilidad de uso
El sistema utilizará una Interfaz web y móvil interactiva e intuitiva, que facilitará su
RNF_001
utilización y manejo a los usuarios sin mucha experiencia en el uso de herramientas
informáticas.
Requerimientos de rendimiento
Sesiones Concurrentes
RNF_011 El sistema no permitirá que un mismo usuario abra más de una sesión de manera
concurrente.
Requerimientos de soporte
Navegador Web
Los navegadores soportados por el sistema serán Microsoft Internet Explorer 8.0 o
RNF_014
superior, Firefox 3.0 o superior, Google Chrome 20.0 o superior y Safari 2.0 o
superior.
Sistema Móvil
RNF_015 El sistema móvil debe soportar la plataforma Android con versión API 4.1 o
superior.
Restricciones de diseño
IDE a utilizar
RNF_020 El IDE para el desarrollo del sistema Web será Visual Studio 2013 y para el
sistema Móvil será Android Studio.
Lenguaje de programación
El lenguaje de programación a emplear para el desarrollo del sistema Web
RNF_021
será .NET C# con Framework 4.5 y se usará Ajax como complemento; para el caso
del sistema Móvil será JAVA.
Página 174
RESTRICCIONES DE LA ARQUITECTURA DE SOFTWARE
Arquitectura de Desarrollo de Software
RNF_022 La solución debe considerar una Arquitectura de 3 capas. Las capas deben ser: Capa
de Presentación, Capa de Negocio y Capa de Datos.
Base de Datos
RNF_023 El motor de base de datos utilizado deberá ser MS SQL Server 2012 Standard
Edition.
Tipo de archivo de los reportes
RNF_024
El formato de salida de los reportes deberá ser formato PDF y XLS.
Servicios Web
RNF_025 La comunicación entre el sistema Web y el sistema móvil será mediante servicios
web REST; el sistema móvil se comunicará mediante protocolo HTML y XML.
Requerimientos de interfaces de usuario
Logotipo
RNF_027 El logotipo se mostrará en la esquina superior izquierda con nombre de la empresa
Unlimited Systems en todas las interfaces principales del sistema.
Interfaz gráfica
RNF_029 El diseño de las pantallas del sistema debe seguir el estándar de diseño del cliente
(colores de la empresa), siendo estos naranja, negro y plomo.
Requerimientos de interfaces de software
Google Maps
RNF_030 El sistema interactuará con los servicios de Google Maps para la ubicación en mapa
de los técnicos.
Requerimientos de interfaces de comunicaciones
Hitrax
RNF_031 El sistema se conectará con los logs de errores y las imágenes escaneadas del
equipo, siempre que el Hitrax esté conectado en una red LAN.
Tabla 10: Restricciones de la Arquitectura de Software [elaboración propia]
Página 175
5 MECANISMOS ARQUITECTURALES
Los mecanismos constituyen las soluciones que pueden implementar los requerimientos no
funcionales relacionados a la arquitectura del sistema. En esta sección se presentan y
describen los mecanismos de análisis e implementación seleccionados, y los requerimientos
no funcionales específicos que buscan satisfacer, además de la solución propuesta para
resolverlos.
MECANISMOS ARQUITECTURALES
Requerimientos
Mecanismo Solución
Abordados
El mecanismo de manejo de errores que se
empleara en el presente proyecto es el uso de las
instrucciones try / catch / finally. Estas
instrucciones permite controlar una parte del
código que puede producir un error, la instrucción
RNF_002_Manejo de
Manejo de Errores es incluida del bloque try y, si se produce un
Excepciones
Permite que los errores sean error, éste podrá ser detectado en el bloque catch,
detectados, propagados y por último, independientemente de que se
RNF_017_Log de
notificados. produzca o no una excepción, permite ejecutar el
Auditoria
código que se incluya en el bloque finally.
El sistema manejara una generación de archivos

LOG donde se registrara todo tipo de error posible
en la transacción.
Página 176
Requerimientos
Mecanismo Solución
Abordados
El uso de Controles Web contenidos en la librería
“BootStrap” permitirán que el usuario reconozca
intuitivamente el tipo de tarea: edición de un
RNF_001_Facilidad de objeto, registro de una transacción, etc. y sepa
Manejo de interfaz de Uso como operarlas. Además el uso de la librería
usuario en tiempo de también permite que la resolución sea adaptable a
ejecución RNF_014_Navegador equipos desktop o tablets.
Permite que la interfaz de Web
usuario sea fácil de operar El uso de jQuery y framework .net mejora la
en función a la tarea con RNF_027_Logotipo compatibilidad con la mayoría de navegadores
estándares previamente actuales.
definidos RNF_029_Interfaz
Gráfica Todos los formularios manejaran validadores a
nivel de interfaz, minimizando los errores por
ingreso de data y facilitando el registro de datos
para los formularios.
Página 177
Requerimientos
Mecanismo Solución
Abordados
Se utilizará un servidor de aplicaciones WEB que
estará operativo las 24 horas del día y que
RNF_006_Tiempo de proporcionará servicios para el control de
Caída transacciones y monitoreo de las tareas del
sistema consultando los parámetros óptimos de
Administración del
RNF_007_Disponibilid tiempos de respuesta y de salud del sistema.
proceso:
ad del Sistema
Proporciona el soporte para
Los reportes y el listado de información se
el manejo de los procesos y
RNF_008_Tiempo de realizara considerando paginación para disminuir
prevención de la falta de
Respuesta la carga a la BD y mejorar el tiempo de respuesta.
disponibilidad del sistema
RNF_009_Tiempo de El motor de BD será Microsoft SQL Server el

Consulta cual permitirá garantizar tanto el commit como el
rollback de las transacciones y se instalara en un
Servidor diferente al Web.
Página 178
Requerimientos
Mecanismo Solución
Abordados
El sistema contará con la creación de perfiles de usuarios,
para limitar el acceso a determinados módulos de acuerdo a
las especificaciones de caso de uso para cada uno de los
roles.
Las contraseñas no se almacenarán en claro, sino que se

almacenaran cifradas mediante MD5 de forma que garantice
su confidencialidad e integridad.
La contraseña tendrá un periodo de caducidad de 45 días. El

sistema solicitará el cambio de la contraseña en el primer
acceso al sistema. La aplicación contará con la opción de
desbloqueo y reseteo de password.
RNF_010_Inactividad
de la Sesión El sistema guardará el estado de la sesión de un usuario con
Seguridad
el cuál verificará que no se acceda con dicha cuenta
Proporciona servicios de mientras se encuentre activa la sesión.
RNF_011_Sesiones
protección contra accesos
Concurrentes
no permitidos a recursos de La aplicación previene intentos de ingresos fallidos, después
del quinto intento se bloqueará la cuenta.
información.
RNF_012_Concurrenci
a de Usuarios La aplicación utilizará mecanismos de bloqueo de aquellas
cuentas de acceso que no se hayan utilizado por un periodo
máximo de 60 días.
La aplicación mantiene un archivo histórico encriptado de al

menos las tres últimas contraseñas de acceso utilizadas para
cada cuenta evitando su reutilización.
La aplicación controla que las claves de acceso de los

usuarios tengan una longitud mínima de 7 caracteres y al
menos una letra y un número.
La aplicación permite la desconexión automática luego de 5

minutos de inactividad de la sesión.
Página 179
Requerimientos
Mecanismo Solución
Abordados
Para asegurar el funcionamiento en diferentes
RNF_014_Navegador
browsers se usará el patrón MVC que trabaja
Web
mediante vistas y no depende de los demás
Adaptabilidad componentes del sistema.
RNF_015_Sistema
Mide la capacidad con la
Móvil
que el sistema se adapta a Para asegurar el funcionamiento en las diferentes
nuevos ambientes versiones Android, se trabajara con el API 4.1 y el
RNF_022_Arquitectura
Gradle 2.2.1 del Android Studio, el cuál
de Desarrollo de
garantizará la compatibilidad con las versiones
Software
superiores a esta.
Se trabajara con la versión indicada MS SQL
Server 2012 R2 porque cubre las necesidades del
sistema como motor de búsqueda y
Persistencia
almacenamiento de datos.
Constituye el conjunto de RNF_023_Base de
servicios para manipular los Datos
Las capacidades del motor de base de datos
datos
facilitarán la conservación y la permanencia en
línea de un gran volumen de información.
Página 180
Requerimientos
Mecanismo Solución
Abordados
El sistema contara con funcionalidad de envío de
alertas por correo en caso de errores en el sistema,
dirigido al correo soporte@unlimited-
systems.com, el cuál será atendido por el técnico
de soporte del área para reducir el tiempo de
respuesta.
RF_011_Enviar Alerta El sistema permitirá el envío de correos para:

de nuevo servicio - Confirmar la atención de una solicitud a
un cliente.
RF_018_Enviar Alerta - Enviar correo al área comercial sobre una
Correo
por Garantía nueva solicitud de cotización.
Servicios que permiten que
- Envío de vencimiento de próxima garantía
las aplicación puedan enviar
RF_024_Actualizar al correo del cliente, del supervisor y del
y recibir información
Ubicación de Técnico coordinador.
RNF_005_Alerta antes El sistema enviará una alerta de nuevo servicio al

fallas móvil del técnico una vez se haya generado su
orden de servicio correspondiente, el técnico
podrá verificar dicha alerta como una nueva
entrada en su agenda de tareas.
El sistema enviará periódicamente la ubicación

del técnico mediante la función GPS y la
interacción con el Google API Google Maps.
Página 181
Requerimientos
Mecanismo Solución
Abordados
El sistema web tendrá servicios web REST
publicados para que puedan ser consumidos por la
aplicación móvil mediante HTTP y XML.
El móvil debe contar con plan de datos, conexión

RNF_025_Servicios a Wifi y conectividad 4G para garantizar la
Web comunicación con los servicios REST del
Comunicación
aplicativo Web.
Facilita la comunicación
RNF_030_Google
entre procesos y con la
Maps El sistema se comunicará con los servicios Google
aplicación en general
Services para conexión con mapas y
RNF_031_Hitrax geolocalización, usando librerías de google y
licencia otorgada por Google para desarrolladores.
El sistema se comunicará con el equipo Hitrax

mediante una carpeta compartida y en una red
LAN.
Se desarrollará una aplicación tipo Web basada en
ASP.Net MVC4 a 3 capas y servicio web REST.
RNF_020_IDE a
Mantenibilidad
utilizar Se desarrollará un sistema móvil de tipo nativo
Proporciona facilidades
con Google Api Services y NavigationDrawers.
para el mantenimiento del
RNF_021_Lenguaje de
sistema.
Programación Se considerará el lenguaje, versión del framework
e IDE indicados tanto para el sistema web como
para el móvil.
Página 182
Requerimientos
Mecanismo Solución
Abordados
Se realizaran registros de programación de
RF_029_Registrar mantenimiento futuros según los contratos de
Programación
alertas para mantenimiento que estén vigente en los equipos.
Proporciona capacidades de
mantenimiento El sistema alertará al supervisor y al coordinador
programación de tareas
programados mediante un correo sobre el mantenimiento
próximo.
RNF_003_Generacion
de reportes
Para la generación de reportes a PDF se
RNF_004_Exportación emplearán componentes y funciones que se
Reporte
e Imprimir Información encuentran en la librería itextSharp.
Proporciona facilidades
para la generación de
RNF_013_Tiempo de Para guardar reportes y archivos en Excel se
reportes
Respuesta de Reportes emplearan las librerías y métodos contenidos en el
Visual Studio .Net usando el framework 4.5
RNF_024_Tipo de
archivo de los reportes
Tabla 11: Mecanismos Arquitecturales [elaboración propia]
Página 183
6 VISTA LÓGICA DE LA ARQUITECTURA DE SOFTWARE
La arquitectura de 3 capas permite dividir la carga de procesamiento de datos en 3 niveles o

capas independientes. Esta separación es un paso importante para obtener un mejor
rendimiento, balancear la carga, obtener redundancia en caso de fallos y conseguir
escalabilidad.
En esta sección se presenta una vista de alto nivel del sistema propuesto, organizado en
capas.
Página 184
Gráfico 42: Vista Lógica de la Arquitectura de Software [elaboración propia]
6.1 Capa Presentación
Es la que el usuario ve y mediante la cual se le presenta el sistema, le comunica la

información y captura la información del usuario dando un mínimo de proceso (realiza un
filtrado previo para comprobar que no hay errores de formato). Esta capa se comunica
únicamente con la capa de negocio y es la que debe conocer las particularidades de la capa de
software y hardware que utilizará el usuario final para ejecutar la interfaz de usuario.
Contiene las clases del sistema que brindan los medios de comunicación con el usuario. La
comunicación se realizará a través de formularios tanto Web como aplicación móvil.
Se compone a la vez de:
 Interfaces de Usuario: En esta capa están las Vistas que contienen lógica mínima para
presentar la información y realizar operaciones básicas. Son las vistas del patrón MVC,
y todo documento de apoyo como librerías jquery y estilos css.
 Interfaces Móvil: En esta capa están las vistas de diseño del aplicativo móvil, así como
las operaciones básicas de presentación del aplicativo. Contiene las interfaces de
diseño, así como las librerías necesarias para su interrelación con los servicios y
arquitectura del equipo móvil.
 Servicios Web: En esta capa están las peticiones HTTP y las respuestas XML que
realizará el aplicativo móvil a la capa de negocios y a su vez a los servicios.
 Controles Web: En esta capa figuran los controles WEB que permiten establecer la
conexión con las capas de la lógica de negocio. Manejan los eventos y son los controles
del patrón MVC.
6.2 Capa Negocio
Esta es la capa que implementa las reglas del negocio a nivel de lógica de software, tiene la
responsabilidad de los algoritmos operativos y de cálculo. La implementación debe estar
completamente abstraída de las particularidades de la capa de presentación y de datos. Se
comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados; y
Página 185
con la capa de datos, para solicitar al gestor de base de datos para almacenar o recuperar
datos de él.
En esta capa hay controladoras pero a nivel de objetos de negocio totalmente independientes
de la capa de presentación.
Se compone de:
 Reglas de Negocio: Capa de las clases que definen y operan las reglas de negocio.
 Entidades de Negocio: Capa de las clases que contienen la estructura de los datos cuya
función principal es pasar los datos entre componentes.
6.3 Capa Datos
La capa de datos gestiona el ciclo de vida de los elementos persistentes de la aplicación. La

principal abstracción que se maneja es el modelo. Un modelo es un objeto que representa los
datos del programa. Maneja los datos y controla todas sus transformaciones. Es el propio
sistema el que tiene encomendada la responsabilidad de mantener enlaces entre el Modelo y
sus vistas, y notificar a las vistas cuando cambia el modelo.
En esta capa se encarga de establecer la conexión con la base de datos, establecer la conexión
con los servicios, y mediante la ejecución de transacciones permitir el almacenamiento y
recuperación de los datos persistentes. Se compone de:
 Acceso a Datos de Usuario: Capa de las clases que permiten el acceso a los datos
directamente a un repositorio persistente de información.
 Servicios: Capa de los agentes que invocan los servicios REST que serán consumidos
por el aplicativo móvil.
Página 186
7 VISTA DE IMPLEMENTACIÓN DE LA ARQUITECTURA DE SOFTWARE
Esta sección presenta la relación y comunicación de los componentes para la

implementación.
Se muestran los componentes propios del sistema (incluye librerías y aplicaciones necesarias
para que el sistema funcione).
Gráfico 43: Vista de Implementación de la Arquitectura de Software [elaboración propia]
Página 187
8 VISTA DE DESPLIEGUE DE LA ARQUITECTURA DE SOFTWARE
En esta sección se muestra los componentes de hardware y elementos en tiempo de ejecución requeridos para el correcto funcionamiento del
sistema. También se muestra la asignación de componentes a los diferentes procesadores. Los comentarios describen las características del
hardware que se necesita para la aplicación.
Página 188
Gráfico 44: Vista de Despliegue de la Arquitectura de Software [elaboración propia]
Página 189
9 CONCLUSIONES
 Se identificó los casos de uso que más impactan en la arquitectura, sobre el cuál se
definieron los casos de uso a realizar como pruebas de concepto inicial.
 Se logró identificar y proponer soluciones a las metas y restricciones detectadas en el

proyecto actual, así como se propuso mecanismos arquitecturales para poder resolver y
alcanzar dichas metas y restricciones que más impactan en la arquitectura.
 Con las vistas de implementación y de despliegue se pudo identificar los componentes

que son necesarios para la puesta en producción del software, así también cuales son los
requisitos, características y conexiones del hardware que contendrá dichos
componentes.
Página 190
CAPÍTULO 6: CONSTRUCCIÓN
1 INTRODUCCIÓN
El presente capítulo contiene la Construcción del Software. Se detallan los patrones utilizados
para la construcción del software, así como su diagrama y sustento de utilización. Así mismo,
se muestra el diagrama de modelo de datos del sistema, con su respectivo diccionario de
datos, detallando los atributos, tipos y valores que cada campo de las tablas conlleva. Por
último, se desarrolla al 100% los casos de uso del núcleo central, teniendo las funcionalidades
claves, que agregan valor al proyecto, implementadas para su ejecución y prueba.
Página 191
2 PATRONES DE LA SOLUCIÓN PROPUESTA
2.1 Patrón MVC
Gráfico 45: Diagrama del patrón Model-Controller-View [18]
El sistema se divide en tres partes diferentes: un modelo que encapsula algunos datos de la
aplicación y de la lógica que manipula los datos, independientemente de las interfaces de
usuario; una o varias vistas que muestran una parte específica de los datos para el usuario; un
controlador asociado a cada pantalla que recibe la entrada del usuario y la traduce en una
solicitud al modelo. Vistas y controladores constituyen la interfaz de usuario. Los usuarios
interactúan estrictamente a través de los puntos de vista y sus controladores,
independientemente del modelo, que a su vez notifica a todos los diferentes interfaces de
usuario sobre actualizaciones. [18]
En el diagrama se aprecia que las solicitudes son interceptadas por la clase controladora.
Dicha clase puede interactuar con los componentes que forman parte del modelo de datos.
Una vez recuperados los datos y realizada la lógica de negocios correspondiente, la
controladora genera una vista y responde a la petición del usuario.
Página 192
Nombre del
MVC
Patrón
Las aplicaciones pueden volverse muy difíciles de mantener y probar cuando no se
Problema que se
diseñan de manera que las responsabilidades de los componentes estén bien definidas.
busca resolver
Este patrón propone un esquema en donde existen responsabilidades de presentación,
lógica de negocios y coordinación, e interacción con los datos del negocio.
Estructurar la solución en capas, cada cual con responsabilidades e interacciones bien
Solución
definidas.
Ventajas:
 Separación de responsabilidades.
 Facilita el testing, en especial de la capa de lógica de negocios y de acceso a
datos.
Resultados
 Robustez y mayor adaptabilidad al cambio.
Desventajas
 Curva de aprendizaje mayor que otros esquema de desarrollo
 Conexión íntima entre vista y controlador.
Se decidió utilizar este patrón para el proyecto porque se considera que la separación de
responsabilidades brinda un mayor orden y facilita que la aplicación pueda adaptarse a
Motivo y nuevos requerimientos en el futuro. Así mismo, durante el proyecto fue necesario poder
experiencias de probar con diferentes vistas en tiempo de ejecución, gracias al beneficio de este patrón
uso se puede cambiar incorporar cambios en plena ejecución sin afectar el model o las
funcionalidades del controller. También, se decidió por su alta capacidad para
intercambiar su plataforma de vista (look&feel) en especial con el uso del bootstrap 3.0
Tabla 12: Especificación del patrón MVC [elaboración propia]
Página 193
2.2 Patrón Repository
Gráfico 46: Diagrama del patrón Repository [20]
El gráfico muestra el funcionamiento del patrón. Existen entidades del negocio definidas
como clases y el Repositorio (ORM) ofrece mapeo entre dichas clases y la base de datos así
como métodos para interactuar con la misma.
Nombre del
REPOSITORY
Patrón
Problema que se Muchos proyectos utilizan bases de datos relacionales como repositorio para los datos.
busca resolver Desafortunadamente, esto obliga a realizar un mapeo entre las clases de los lenguajes
orientados a objetos y el modelo físico de la base de datos.
Un componente que media entre las capas de dominio y asignación de datos, actuando
como una colección de objetos en memoria. Conceptualmente, un repositorio encapsula
Solución
a los objetos persistidos en una base de datos y las operaciones que se realizan sobre
ellos, proporcionando una visión más orientada a objetos de la capa de persistencia.
Página 194
Nombre del
REPOSITORY
Patrón
Ventajas:
 Facilita la interacción con la base de datos desde lenguajes orientados a objetos.
 Se minimiza la cantidad de sentencias SQL embebidas en el código, puesto que
se utiliza el API provisto por el repositorio.
Resultados Desventajas
 Mayor procesamiento y menor tiempo de respuesta inicial, puesto que tienen que
realizarse las labores de mapeo por parte del repositorio.
 En ocasiones, los programadores no entienden la manera en que el Repositorio
trabaja, lo cual genera problemas de performance.
La aplicación de este patrón en el proyecto se sustenta en que resulta conveniente poder
trabajar con la Base de Datos desde una óptica orientada a objetos. Un beneficio
adicional, es que cuando el acceso a los datos se realiza a través de un framework, el
compilador puede detectar errores de programación, lo cual no ocurre cuando se utilizan
Motivo y SQL embebidos. Para el proyecto, se utilizó el EntityFramework para la conexión y
experiencias de creación del repositorio de datos desde la base de datos SQL creada. Con esto mientras
uso va avanzando el proyecto y surgen cambios en la Base de Datos, sólo es necesario
actualizar el modelo del EntityFramework, con el cual el repositorio queda sincronizado
y el acceso a datos se realiza de forma más amigable, efectiva y sin mucho
procesamiento por parte del motor de base de datos.
Tabla 13: Especificación del patrón Repository [elaboración propia]
Página 195
3 MODELO DE DATOS
3.1 Modelo de datos físico del sistema
Gráfico 47: Diagrama del Modelo de Datos Físico del Sistema [elaboración propia]
Página 196
3.2 Diccionario de Datos
Nombre de la tabla CLIENTE

Descripción de la tabla Contiene los clientes a los que se da servicio
Nombre de la columna Descripción Tipo dato Único Tipo llave
Co_Cliente Código de cliente int Si Primaria
Tx_RazonSocial Razón Social del cliente varchar(200)
Nu_Ruc Ruc del cliente varchar(11) Si
Tx_Direccion Dirección Principal varchar(200)
Co_Distrito Código de Distrito int Foránea
Nu_Telefono Teléfono del cliente varchar(15)
No_NombreContacto Nombre del Contacto del cliente varchar(100)
Tx_CargoContacto Cargo del Contacto del cliente varchar(100)
Coordenada Latitud de la
Nu_Latitud varchar(11)
Coordenada Longitud de la
Nu_Longitud varchar(11)
Nombre de la tabla EQUIPO

Descripción de la tabla Contiene todos los equipos a los que la empresa ha dado servicio
Co_Equipo Código de equipo int Si Primaria
Tx_Modelo Modelo del equipo varchar(50)
Tx_Marca Marca del equipo varchar(50)
Tx_Serie Número de Serie del equipo varchar(50) Si
Tx_Ubicacion Ubicación del equipo varchar(200)
Co_Cliente Código del cliente int Foránea
Tx_Estado Estado del equipo varchar(20)
Tx_Descripcion Descripción del equipo varchar(200)
Página 197
Coordenada Latitud de la
Tx_Latitud varchar(11)
ubicación del equipo
Coordenada Longitud de la
Tx_Longitud varchar(11)
ubicación del equipo
Nombre de la tabla CONTRATO_EQUIPO

Descripción de la tabla Contiene la relación entre los equipos y los contratos
Primaria
Co_Contrato Código de contrato int
Foránea
Primaria
Co_Equipo Código de equipo int
Foránea
Nombre de la tabla CONTRATO

Descripción de la tabla Contiene la lista de contratos hechas por el área
Co_Contrato Código de contrato int Si Primaria
No_Contrato Número de contrato varchar(100)
Tx_Tipo Tipo de contrato varchar(50)
Fe_Inicio Fecha de inicio date
Fe_Final Fecha de vencimiento date
Tx_Estado Estado del contrato varchar(50)
Nombre de la tabla DISTRITO

Descripción de la tabla Contiene los distritos del Perú
Co_Distrito Código de distrito int Si Primaria
No_Distrito Nombre de Distrito varchar(100)
Co_Provincia Código de Provincia int Foránea
Nombre de la tabla PROVINCIA

Descripción de la tabla Contiene las provincias del Perú
Página 198
Co_Provincia Código de provincia int Si Primaria
No_Provincia Nombre de provincia varchar(100)
Co_Departamento Código de departamento int Foránea
Nombre de la tabla DEPARTAMENTO

Descripción de la tabla Contiene los departamentos del Perú
Co_Departamento Código de departamento int Si Primaria
No_Departamento Nombre de departamento varchar(100)
Nombre de la tabla USUARIO

Descripción de la tabla Contiene los usuarios del sistema
Co_Usuario Código del usuario int Si Primaria
No_Usuario Nombre de usuario varchar(50)
Tx_Password Password del usuario varchar(50)
Nombre de la tabla SOLICITUD_COTIZACION

Descripción de la tabla Contiene las solicitudes de cotización hecha por comercial
Código de solicitud de
Co_Solicitud int Si Primaria
cotización
Fe_Solicitud Fecha de solicitud de cotización date
Detalle de la solicitud de
Tx_Detalle varchar(200)
cotización
Co_SolicitudAtencion Código de solicitud de atención int Foránea
Nombre de usuario que registró
No_UsuarioIni varchar(20)
inicialmente
Fecha de última modificación de
Fe_RegistroMod date
registro
Página 199
Nombre usuario que modificó
No_UsuarioMod varchar(20)
último
Nombre de la tabla SOLICITUD_ATENCION

Descripción de la tabla Contiene las solicitudes de atención hecha por los clientes
Co_Solicitud Código de solicitud de atención int Si Primaria
Fe_Solicitud Fecha de solicitud de atención date
Tx_Estado Estado de solicitud de atención varchar(20)
Tx_Observaciones Observaciones varchar(500)
Nombre de la tabla DETALLE_SOLICITUD_ATENCION

Descripción de la tabla Contiene el detalle de las solicitudes de atención registradas
Primaria
Co_Solicitud Código de solicitud de atención int
Foránea
Primaria
Co_Equipo Código de equipo int
Foránea
Tx_Problema Problema reportado por cliente varchar(500)
Número del código de error
Nu_Error varchar(50)
reportado por el cliente
Tx_Observaciones Observaciones varchar(500)
Nombre de la tabla CASO SERVICIO

Descripción de la tabla Contiene todos los casos de servicio registrados por el área
Co_Caso Código de caso varchar(10) Si Primaria
Co_Solicitud Código de solicitud de atención int Foránea
Fe_Caso Fecha del caso date
Fl_Gasto Flag de gasto realizado varchar(4)
Ss_Gasto Monto del gasto hecho decimal(6, 2)
Fl_Facturado Flag de facturación realizada varchar(4)
Página 200
Ss_Facturado Monto de la facturación hecha decimal(6, 2)
Tx_Estado Estado del caso de servicio varchar(20)
Tx_Observaciones Observaciones generales varchar(500)
Flag de Informe Técnico
Fl_Informe varchar(4)
realizado
Fe_RegistroIni Fecha de Registro Inicial datetime
Nombre de usuario que registro
inicialmente
Fe_RegistroMod datetime
registro
Nombre usuario que modifico
último
Nombre de la tabla DETALLE_CASO_SERVICIO

Descripción de la tabla Contiene el detalle de los casos de servicio registrados
Código de detalle de caso de
Co_Detalle_Caso int Si Primaria
servicio
Co_Caso Código de caso varchar(10) Foránea
Co_Equipo Código de equipo int Foránea
Co_Tipo Código de tipo de servicio int Foránea
Fe_HoraInicial Fecha y hora inicial del servicio datetime
Fe_HoraFinal Fecha y hora final del servicio datetime
Co_Tecnico Código del técnico asignado int Foránea
Tx_DetalleServicio Detalle de las tareas realizadas varchar(500)
Número del código de error
Nu_Error varchar(50)
detectado
Indicador de Reporte de
Fl_Reporte varchar(4)
Servicio realizado
Fe_RegistroIni Fecha de Registro Inicial datetime
Nombre de usuario que registro
inicialmente
Página 201
Fe_RegistroMod datetime
registro
Nombre usuario que modifico
último
Nombre de la tabla TIPO_SERVICIO

Descripción de la tabla Contiene los tipos de servicio realizado por el área
Co_Tipo Código de tipo de servicio int Primaria
No_Nombre Nombre del tipo de servicio varchar(50)
Tx_Descripcion Descripción del tipo de servicio varchar(100)
Nombre de la tabla TECNICO

Descripción de la tabla Contiene los datos de los técnicos que son parte del área de tecnología
Co_Tecnico Código de técnico int Si Primaria
No_Tecnico Nombre del técnico varchar(200)
Ape_Paterno Apellido paterno del técnico varchar(50)
Ape_Materno Apellido materno del técnico varchar(50)
Nu_Dni Número de DNI del técnico varchar(8) Si
Tx_Telefono Teléfono del técnico varchar(12)
Tx_Celular Celular del técnico varchar(12)
Tx_Direccion Dirección del técnico varchar(500)
Co_Distrito Código de distrito int Foránea
Nombre de la tabla LOG_ERROR

Descripción de la tabla Contiene el detalle de los archivos de logs de errores detectados
Co_LogError Código de log de error int Si Primaria
Co_Error Código de error int
Co_Equipo Código de equipo int Foránea
Página 202
Fecha de creación del log de
Fe_LogError datetime
error
Tx_Detalle Detalle del error varchar(200)
Tx_Voltaje Voltaje de la placa varchar(10)
Alineación en grados de la faja
Tx_Alineacion varchar(10)
transportadora
Visualización correcta de la
Tx_Visualizacion varchar(10)
imagen escaneada
Tx_VGA Estado del puerto VGA varchar(10)
Tx_COM Estado del puerto COM varchar(10)
Voltaje de energía de entrada al
Tx_Energia varchar(10)
equipo
Versión del sistema Hitrax
Tx_Sistema varchar(50)
instalado
Tx_Archivo Nombre del archivo log varchar(300)
Nombre de la tabla GPS_TECNICO

Contiene los registros de las coordenadas GPS y fechas de captura de los
Descripción de la tabla
técnicos
Código de registro de fila
Co_Gps int Sí Primaria
autoincremental
Co_Tecnico Código de técnico int Foránea
Fe_Gps Fecha y hora de la captura datetime
Coordenada Latitud del técnico
Tx_Latitud varchar(11)
al momento de la captura
Coordenada Longitud del
Tx_Longitud técnico al momento de la varchar(11)
captura
Página 203
4 CONCLUSIONES
 Se identificó y detalló los patrones más significativos, tanto de arquitectura como de

diseño, usados en el proyecto, especificando su uso, ventaja y desventaja; con lo cual se
pudo elegir los patrones a usar más adecuados para el proyecto.
 Se diseñó e implementó una base de datos relacional debido al tipo de data que se
maneja, tanto por su gran integración entre los atributos y llaves, como también por el
tema de licenciamiento ya obtenido por la empresa en el uso de SQL como motor de
base de datos.
 Se realizó la implementación de los casos de uso del ciclo 0, mostrado las

funcionalidades que agregan valor al sistema propuesto. El uso del servicio web externo
google maps fue efectivo para la geolocalización de los técnicos y para medir las
distancias entre coordenadas dentro del mapa.
Página 204
CAPÍTULO 7: CALIDAD Y PRUEBAS DEL SOFTWARE
1 INTRODUCCIÓN
El propósito del presente capítulo es abordar todo los temas referentes a la calidad de
software dentro del marco del proyecto propuesto. Se describe las políticas, objetivos y
normas de calidad que se aplican en la empresa objetivo. Luego, se procede a especificar las
métricas internas, externas y de calidad de uso relacionadas al proyecto, para poder garantizar
el cumplimiento de los objetivos de calidad y un software de calidad. Por último, se
desarrolla el plan de pruebas del software, con los objetivos, responsables, juego de datos y
resultados esperados.
2 PLAN DE LA CALIDAD DEL SOFTWARE
2.1 Política de calidad
Es política del área de tecnología de Unlimited-Systems buscar la completa satisfacción de

nuestros clientes con productos de software y soluciones tecnológicas de calidad. Para
lograrlo nos basamos en los principios de mejora continua, eficiencia, personal calificado,
constante capacitación, trabajo en equipo y la aplicación de normativas y estándares
internacionales aplicados al desarrollo de software.
El cumplimiento de la Política de Calidad en el área de Tecnología es responsabilidad directa
del Gerente de dicha área.
2.2 Objetivos de calidad
Los objetivos de la calidad del área de Tecnología son los siguientes:
Página 205
 Entregar productos eficientes de manera oportuna, a través de procedimientos
diseñados para el desarrollo de software a fin de asegurar la satisfacción del cliente y
gestionar adecuadamente los tiempos de entrega.
 Mejorar el ciclo de vida del Software mediante la aplicación de normas internacionales
y buenas prácticas, tomando como base la ISO 9001:2008, la ISO/IEC 90003:2004, la
IEEE Std. 830-1998, la ISO/IEC 9126:2001 y la ISO 12207.
 Optimizar los gastos y las inversiones en el área de Tecnología.
 Brindar capacitación permanente al personal de Tecnología en el uso de mejores
prácticas en los servicios que brinda el área antes mencionada.
 Establecer canales de comunicación eficaces que propicien una interacción activa con
los usuarios para brindar mejores servicios, conocer su nivel de satisfacción y alentar el
trabajo en equipo.
2.3 Normatividad aplicable
 ISO 9001:2008 Sistemas de Gestión de la Calidad:

Es una norma internacional que se centra en todos los elementos de la administración
de la calidad con los que una empresa debe contar para tener un sistema efectivo que le
permita administrar y mejorar la calidad de sus productos o servicios.
 ISO/IEC 900003:2014 Software Engineering:
Provee lineamientos a las organizaciones para la aplicación de la norma ISO 9001:2008
para la adquisición, suministro, desarrollo, operación y mantenimiento de software de
computadoras y otros servicios relacionados. [15]
 IEE STD 830-1998 Especificaciones de los requerimientos del Software:
Describe y detalla el contenido y buena calidad de las especificaciones de los
requerimientos de software, incluye varios ejemplos. Estas buenas prácticas están
enfocadas en las especificaciones de los requerimientos de desarrollo de software pero
pueden también aplicarse para la selección de software comercial. Provee lineamientos
que cumplen con la norma IEEE/EIA 12207.1-1997. [16]
 ISO/IEC 9126:2001 Information Technology – Software product evaluation: Quality
characteristics and guidelines for their use:
Página 206
El estándar ISO-9126 establece que cualquier componente de la calidad del software
puede ser descrito en términos de una o más de seis características básicas, las cuales
son: funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad;
cada una de las cuales se detalla a través de un conjunto de subcaracterísticas que
permiten profundizar en la evaluación de la calidad de productos de software. [17]
Página 207
2.4 Métricas de calidad de software
Nombre de la Proposito de la Interpretación del Tipo de Escala
Categoría Característica Método Fórmula Tipo de Medida Indicador
métrica métrica valor medido Métrica
X = 1 - (A/B)
Contar el número de funciones faltantes detectadas
Completitud de la 0 <= X <= 1, más X = Conteo/Conteo 0.9 < X <= 1 => Bueno
Funcionalidad ¿Qué tan completa está la en la evaluación y compararlas con el número de A= Número de funciones faltantes detectadas en la
Interna Implementación completo si es más Absoluto A = Conteo 0.7 < X <= 0.9 => Regular
Adecuación implementación funcional? funciones descritas en la especificación de evaluación.
Funcional cercano a 1 B = Conteo 0 < X <= 0.7 => Malo
requerimientos. B= Número de funciones descritas en la especificación
de requerimientos.
Cuestionario para evaluar el atractivo de la interfaz X = A/B X = Conteo/Conteo 0.9 < X <= 1 => Muy Atractiva
Usabilidad Interacción ¿Qué tan atractiva es la 0 <= X <= 1, mejor si es
Interna para los usuarios, teniendo en cuenta características A = Cantidad de respuestas respondidas con “SI” Absoluto A = Conteo 0.6 < X <= 0.9 => Atractiva
Atractivo atractiva interfaz para el usuario? más cercano a 1
tales como el color y el diseño gráfico B = Total de preguntas B = Conteo 0 < X <= 0.6 => Poco Atractiva
¿Cuántas de los casos de
Contar las pruebas planeadas y comparar con el X = A/B 0 <= X X = Conteo/Conteo 0.9 < X <= 1 => Bueno
Fiabilidad Suficiencia de las prueba necesarios están
Interna número de pruebas requeridas para obtener una A = número de casos de prueba en el plan Entre X se mayor, mejor Absoluto A = Conteo 0.7 < X <= 0.9 => Regular
Madurez pruebas cubiertos por el plan de
cobertura adecuada. B = número de casos de prueba requeridos la suficiencia B = Conteo 0 < X <= 0.7 => Malo
pruebas?
X = A/B
¿Qué proporción de las X = Conteo/Conteo 0.8 < X <= 1 => Bueno
Usabilidad Funciones Contar las funciones evidentes al usuario y comparar A = número de funciones (o tipos de funciones) 0 <= X <= 1, mejor si es
Interna funciones del sistemas son Absoluto A = Conteo 0.5 < X <= 0.8 => Regular
Entendibilidad evidentes con el número total de funciones evidentes al usuario más cercano a 1
evidentes al usuario? B = Conteo 0 < X <= 0.5 => Malo
B = total de funciones (o tipos de funciones)
X = A/B
Validación de ¿Qué proporción de los Contar el número de campos de entrada que validan X = Conteo/Conteo X = 1 => Bueno
Usabilidad A = número de campos de entrada que validan 0 <= X <= 1, mejor si es
Interna campos de campos de entrada validan correctamente los datos ingresados y compararlo con Absoluto A = Conteo 0.9 < X < 1 => Regular
Operatividad correctamente los datos más cercano a 1
entrada correctamente los datos? el número campos de entrada totales B = Conteo 0 < X <= 0.9 => Malo
B = Total de campos input de entrada
¿Se registran
X = A/B
adecuadamente los 0 <= X <= 1 X = Conteo/Conteo 0.9 < X <= 1 => Bueno
Mantenibilidad Registrabilidad Registrar la proporción de información sobre cambios A = número de cambios a funciones o módulos que
Interna cambios a la especificación Entre más cercano a 1, Absoluto A = Conteo 0.7 < X <= 0.9 => Regular
Cambiabilidad de cambios a los módulos tienen comentarios confirmados
y a los módulos con más registrable. B = Conteo 0 < X <= 0.7 => Malo
B = total de funciones o módulos modificados
comentarios en el código?
¿Cúantas de las
funcionalidades descritas X = A/B
Funcionalidades X = Conteo/Conteo X = 1 => Bueno
Funcionalidad en la especificación del Realizar un Test Funcional (caja negra) de el sistema A = número de escenarios correctamente 0 <= X <= 1, mejor si es
Externa Implementadas Absoluto A = Conteo 0.9 < X < 1 => Regular
Exactitud requerimitento fueron acorde a las especificaciones implementados durante la evaluación más cercano a 1
correctamente B = Conteo 0 < X <= 0.9 => Malo
implementadas B = número total deescenarios
correctamente?
X = A/B
¿Qué proporción del tiempo
Fallo de Realizar un test y contar el número de fallas en el A = número de veces que se encuentra un fallo durante X = Conteo/Minutos X = 0 => Bueno
Mantenibilidad de ejecución se encuentran 0 <= X , mejor si es más
Externa comportamiento comportamiento del software durante un tiempo la operación Absoluto A = Conteo 0 < X <= 0.3 => Regular
Estabilidad fallas en el comportamiento cercano a 0
de Software específico B = tiempo de operación durante el período de B = Minutos 0.3 < X => Malo
del software?
observación especificado
X=A * B
A = Quantity (completeness). Proporción de las tareas
X=Conteo * Conteo 0.9 < X <= 1 => Bueno
Calidad de Efectividad de la ¿Qué proporción de las logradas. 0 <= X <= 1, mejor si es
Efectividad Pruebas de usuario Ratio A=Conteo 0.7 < X <= 0.9 => Regular
uso tarea tareas son efectivas? B = Quality (correcteness. Grado de logro de la más cercano a 1
B=Conteo 0 < X <= 0.7 => Malo
ejecución en la tarea desarrollada
Tabla 14: Métricas de Calidad del Proyecto [elaboración propia]
Página 208
Página 209
3 PRUEBAS DEL SOFTWARE
3.1 Casos de prueba para CUS_006_Actualizar Caso de Servicio
3.1.1 Especificación de los Casos de Prueba
Actores de Sistema
Propósito
 Registrar un Caso de Servicio para la atención de un servicio de un cliente.
Breve Descripción
Caso Servicio”, en donde podrá registrar un nuevo caso de servicio. El caso de uso
termina cuando el actor registra a los equipos dentro del caso y está queda registrada en
el sistema con estado pendiente.
Flujo de Eventos
 Flujo Básico
1. El actor del sistema selecciona la opción Caso Servicio del Menú.
2. El actor del sistema selecciona la opción Crear Caso Servicio.
- Código
- Fecha Inicial
- Fecha Final
- Estado
Y con las opciones:
- Nuevo Caso
- Buscar
Página 210
- Cancelar
Así mismo muestra la lista de las 20 Solicitudes con estado pendiente. La lista tiene
los siguientes campos:
- Código
- Fecha
- Estado
- Observaciones
- Opción Ver
- Opción Crear Caso
4. El actor del sistema selecciona la opción Nuevo Caso.
campos:
- Observaciones
Y con las opciones:
- Crear
- Cancelar
8. El sistema muestra la página Registrar Detalle de Caso de Servicio #X (X es el
- Marca
- Modelo
- Serie
- Fecha Inicial
- Fecha Final
- Tipo de Servicio
- #Error
Y con las opciones:
Página 211
- Agregar
- Cancelar
Asimismo muestra una lista con los equipos que están registrados dentro del caso de
servicio. La lista tiene los siguientes campos:
- Marca
- Modelo
- Serie
- Tipo
- Detalle
- Reporte
- Opción Editar
- Opción Borrar
9. El actor del sistema ingresa los datos necesarios y selecciona la opción Agregar.
del sistema.
al Caso de Servicio”.
 SubFlujos
Creación de Caso de Servicio

1. En el punto [4] del flujo básico, el actor del sistema selecciona la opción Crear
Caso.
campos:
- Observaciones
Y con las opciones:
- Crear
- Cancelar
Página 212
5. El sistema verifica la cantidad de equipos con garantía vigente que están en la
solicitud de servicio y los graba dentro del detalle del caso de servicio nuevo recién
creado.
Editar Detalle de Caso de Servicio

2. El sistema muestra la pantalla Editar Detalle de Caso de Servicio con los datos del
detalle del equipo seleccionado. Los campos sin poder editar son:
- Marca
- Modelo
- Serie
- Fecha Inicial
- Fecha Final
- Tipo de Servicio
- Error
Y las opciones:
- Grabar
- Cancelar
sistema.
“Detalle del Caso de Servicio Editado”.
Borrar Detalle de Caso de Servicio

Página 213
2. El sistema muestra el mensaje “¿Desea eliminar el equipo del Caso de Servicio?”
con las opciones:
- Aceptar
- Cancelar
4. El sistema cierra el mensaje, borra el equipo del caso de servicio y muestra el
mensaje en la parte superior de la pantalla “Equipo Eliminado del Caso de
Servicio”.
 Flujos Alternos
Cancelación de Registrar Caso de Servicio

Cancelación de Registrar Detalle de Caso de Servicio

Campos obligatorios
Si en el punto [9] del flujo básico el actor no ingresa todos los campos obligatorios, el
sistema muestra el mensaje “Debe de llenar todos los campos obligatorios”. El sistema
regresa al paso [8] del flujo básico
Garantía activas en equipos

Si en el punto [5] del subflujo Creación Casos de Servicio, el sistema verifica que
ningún equipo dentro de la solicitud tiene garantía vigente, muestra un mensaje en la
parte superior de la pantalla “Error al Crear Caso de Servicio. Solicitud no presenta
equipos con garantías activas”. El sistema regresa al paso [2] del subflujo Creación
Casos de Servicio.
Cancelación de Editar Detalle de Caso de Servicio
Página 214
Si en el punto [2] del subflujo Editar Detalle de Caso de Servicio el actor del sistema
flujo básico.
Cancelación de Borrar Detalle de Caso de Servicio

Si en el punto [2] del subflujo Borrar Detalle de Caso de Servicio el actor del sistema
flujo básico.
Precondiciones
Postcondiciones
 Caso de Servicio Registrado
El Caso de Servicio quedará registrado con los datos ingresados por el actor del sistema
con el estado Pendiente Asignación.
 CUS_003_Consultar Solicitud de Atención de Servicio
 No aplica

 RF_004_Actualizar Caso de Servicio
Reglas de Negocio
Página 215
 RN_05_Confirmación de atención
 RN_06_Atención programada
 RN_17_Código de caso de servicio
 RN_20_Asociación de casos de servicio
 RN_23_Caso de servicio pendiente
Página 216
3.1.2 Escenarios y juego de datos de los Casos de Prueba
CASO DE PRUEBA: CPS_006_ACTUALIZAR CASO DE SERVICIO
a. Escenarios:
Flujo de
Código de Escenario Nombre de Escenario Leyenda
Inicio
ESC-01 Registrar Caso de Servicio Nuevo Flujo Básico Valido = V
ESC-02 Registrar Detalle de Caso de Servicio Flujo Básico Invalido = I
ESC-03 Crear Caso de Servicio desde Solicitud 17 Sub Flujo No Aplica = N/A
ESC-04 Editar Detalle Caso de Servicio del Caso 15-030 Sub Flujo
ESC-05 Borrar Detalle Caso de Servicio del Caso 15-029 Sub Flujo
ESC-06 Elegir Cancelar en Registro Caso de Servicio Flujo Alterno
ESC-07 Elegir Cancelar en Registro Detalle de Caso de Servicio Flujo Alterno
ESC-08 Verificar Campos Obligatorios en Registro de Detalle de Caso de Servicio Flujo Alterno
ESC-09 Verificar Garantías Activas en Creación de Caso de Servicio desde Solicitud 18 Flujo Alterno
ESC-10 Elegir Cancelar en Edición Detalle Caso de Servicio del Caso 15-030 Flujo Alterno
ESC-11 Elegir Cancelar en Borrado Detalle Caso de Servicio del Caso 15-029 Flujo Alterno
b. Matriz de Casos de Prueba:
ID Caso de Prueba Escenario/ Condición Fecha Caso Observaciones Cod Solicitud N° Equipos Marca Modelo Serie Fecha Inicial Fecha Final Tipo de Servicio De talle de Servicio #Error Re sultado
CPS_006 ESC-01 I V I I I I I I I I I I El sistema guarda el caso de servicio y muestra la página: Registrar Detalle de Caso de Servicio #X
CPS_006 ESC-02 I I I I V V V V V V V V El sistema guarda el detalle y muestra el mensaje de confirmación: Equipo Agregado al Caso de Servicio
CPS_006 ESC-03 I V I I I I I I I I I I El sistema guarda el caso de servicio, guarda los detalles del caso y muestra la página: Registrar Detalle de Caso de Servicio #X
CPS_006 ESC-04 I I I I I I I V V V V V El sistema guarda los datos y muestra el mensaje de confirmación: Detalle del Caso de Servicio Editado
CPS_006 ESC-05 I I I I I I I I I I I I El sistema elimina el detalle seleccionado y muestra mensaje de confirmación: Equipo Eliminado del Caso de Servicio
CPS_006 ESC-06 I V I I I I I I I I I I El sistema cancela el proceso de registro de caso de servicio y regresa a lo página: Consultar Solicitud de Atención
CPS_006 ESC-07 I I I I V V V V V V V V El sistema cancela el proceso de registro de detalle de caso de servicio y regresa a lo página: Consultar Solicitud de Atención
CPS_006 ESC-08 I I I I V V V V V V V V El sistema muestra mensaje de advertencia: Debe de llenar todos los campos obligatorios
CPS_006 ESC-09 I V I I I I I I I I I I El sistema muestra mensaje de error: Error al Crear Caso de Servicio. Solicitud no presenta equipos con garantías activas
CPS_006 ESC-10 I I I I I I I V V V V V El sistema cancela el proceso de Edición de Detalle de Caso y muestra la página: Registrar Detalle de Caso de Servicio #X
CPS_006 ESC-11 I I I I I I I I I I I I El sistema cancela el proceso de Borrado de Detalle de Caso y muestra la página: Registrar Detalle de Caso de Servicio #X
c. Matriz de Casos de Prue ba con datos:
ID Caso de Prueba Escenario/ Condición Fecha Caso Observaciones Cod Solicitud N° Equipos Marca Modelo Serie Fecha Inicial Fecha Final Tipo de Servicio De talle de Servicio #Error Re sultado
CPS_006 ESC-01 N/A Facturado N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A El sistema guarda el caso de servicio y muestra la página: Registrar Detalle de Caso de Servicio #X
CPS_006 ESC-02 N/A N/A N/A N/A SMITHS HS 100 100V 72960 07-12-2015 11:00 07-12-2015 13:00 Diagnostico Diagnosticar falla de monitor de HiScan 204 El sistema guarda el detalle y muestra el mensaje de confirmación: Equipo Agregado al Caso de Servicio
CPS_006 ESC-03 N/A Incluir Movilidad N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A El sistema guarda el caso de servicio, guarda los detalles del caso y muestra la página: Registrar Detalle de Caso de Servicio #X
CPS_006 ESC-04 N/A N/A N/A N/A N/A N/A N/A 08-12-2015 11:00 08-12-2015 13:00 Complementario Mantenimiento complementario al equipo (Blanco) El sistema guarda los datos y muestra el mensaje de confirmación: Detalle del Caso de Servicio Editado
CPS_006 ESC-05 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A El sistema elimina el detalle seleccionado y muestra mensaje de confirmación: Equipo Eliminado del Caso de Servicio
CPS_006 ESC-06 N/A V N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A El sistema cancela el proceso de registro de caso de servicio y regresa a lo página: Consultar Solicitud de Atención
CPS_006 ESC-07 N/A N/A N/A N/A SMITHS HS 7555A 14376 10-12-2015 12:00 10-12-2015 15:00 Instalación Instalar Equipo en cliente 201 El sistema cancela el proceso de registro de detalle de caso de servicio y regresa a lo página: Consultar Solicitud de Atención
CPS_006 ESC-08 N/A N/A N/A N/A SMITHS HS 7555A 15866 10-12-2015 12:00 10-12-2015 15:00 (Blanco) Mantenimiento preventivo 201 El sistema muestra mensaje de advertencia: Debe de llenar todos los campos obligatorios
CPS_006 ESC-09 N/A Falta Cotizar N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A El sistema muestra mensaje de error: Error al Crear Caso de Servicio. Solicitud no presenta equipos con garantías activas
CPS_006 ESC-10 N/A N/A N/A N/A N/A N/A N/A 08-12-2015 11:00 08-12-2015 13:00 Complementario Mantenimiento complementario a HiScan 201 El sistema cancela el proceso de Edición de Detalle de Caso y muestra la página: Registrar Detalle de Caso de Servicio #X
CPS_006 ESC-11 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A El sistema cancela el proceso de Borrado de Detalle de Caso y muestra la página: Registrar Detalle de Caso de Servicio #X
Tabla 15: Escenarios y Juego de Datos CPS_006_Actualizar Caso de Servicio [elaboración propia]
Página 217
3.2 Casos de prueba para CUS_046_Gestionar Logs de Errores del Hitrax
3.2.1 Especificación de los Casos de Prueba
Actores de Sistema
 AS_012_Operador, AS_014_Hitrax
Propósito
 Monitorear la generación de logs de errores del equipo Hitrax para su inmediata
detección, alerta y gestión por parte del operador.
Breve Descripción
“Monitoreo Errores”, donde podrá detectar la creación del archivo de error generado
por el equipo Hitrax y emitirá una alerta. El caso de uso termina cuando el actor del
sistema carga el archivo de Log de error al sistema.
Flujo de Eventos
 Flujo Básico
1. El actor del sistema selecciona la opción Monitoreo de Equipo del Menú.
2. El actor del sistema selecciona la opción Monitoreo de Errores.
3. El sistema muestra la página Activar Monitorización de Eventos de Error y las
siguientes opciones:
- Iniciar
- Detener (Deshabilitado)
- Marca
- Modelo
Página 218
- Serie
- Cliente
4. El actor del sistema selecciona la opción de “Iniciar”.
5. El sistema muestra el mensaje Monitoreo Iniciado y en el panel alarma el mensaje
“Monitoreando…”.
6. El sistema monitoreará la carpeta compartida donde el actor del sistema Hitrax
colocará el archivo log de errores (extensión .htx) al momento de un fallo en el
equipo.
7. El actor del sistema Hitrax genera un archivo log de error, el cual tiene el formato
#####_yyyyMMddHHmmss.htx, donde ##### es el número de serie del equipo y
yyyyMMddHHmmss es la fecha y hora de detección del error. El actor del sistema
Hitrax coloca el log de error dentro de la carpeta compartida.
8. El sistema detecta dicho error y muestra una alerta en el panel de alarma con el
mensaje “Alerta Error X (X es el número de log errores detectados hasta el
momento).
9. El actor del sistema selecciona el mensaje mostrado en el panel de alarma.
10. El actor selecciona la opción “Detener”.
11. El sistema detiene el monitoreo y muestra el mensaje Monitoreo Terminado y
muestra el mensaje de “Detenido!” en el panel de alarma.
12. El sistema muestra la misma página con los siguientes campos, dependiendo de la
cantidad de errores que haya encontrado:
- Archivo Log
Y la opción:
- Cargar Archivo
- Iniciar (Deshabilitado)
- Detener
Página 219
- Marca
- Modelo
- Serie
- Cliente
13. El actor del sistema selecciona la opción Cargar Archivo.
14. El sistema verifica el archivo existente y los datos del archivo.
15. El sistema carga los parámetros del log de error en el sistema.
16. El sistema muestra el mensaje “Archivo Cargado Correctamente”
 SubFlujos
1. En el punto [4] del flujo básico, el actor del sistema selecciona la opción Ver
Detalle.
2. El sistema muestra la pantalla Detalle de Log de Error con los datos del fichero log
de error generado por el Hitrax. Los campos sin poder editar son:
- Código de Error
- Fecha del Error
- Detalle de Error
- Voltaje
- Alineación
- Visualización
- Puerto VGA
- Puerto COM
- Puerto Red
- Sistema Operativo
3. El actor del sistema visualiza la información.
Página 220
 Flujos Alternos
Validación de Archivo duplicado

Si en el punto [14] del flujo básico el sistema verifica que ya se cargó el mismo archivo
previamente, el sistema no carga el nuevo archivo y muestra el error “Archivo Log
Error ya se encuentra cargado” y el caso de uso retorna al paso [3] del flujo básico.
Archivo No Existente
Si en el punto [14] del flujo básico el sistema verifica que el archivo no se puede leer
(corrompido) o no encuentra el archivo dentro de la carpeta especificada, el sistema no
carga el archivo y muestra el error “Error al leer el archivo o no se encuentra” y el caso
de uso retorna al paso [3] del flujo básico.
Precondiciones
Debe existir una lista de Clientes registrados en el sistema
Postcondiciones
 Log de errores registrado en el sistema
El fichero log de error detectado es cargado al sistema.
 No aplica
 No Aplica
Página 221
 RF_034_Cargar datos de errores del Hitrax al sistema
 RF_036_Alerta de Errores en equipos Hitrax
Reglas de Negocio
 No Aplica
Página 222
3.2.2 Escenarios y juego de datos de los Casos de Prueba
CASO DE PRUEBA: CPS_046_GESTIONAR LOGS DE ERRORES DEL HITRAX
a. Escenarios:
Código de Escenario Nombre de Escenario Flujo de Inicio Leyenda

ESC-01 Iniciar Monitoreo de Error del Hitrax Flujo Básico Valido = V
ESC-02 Detección de Log de Error Hitrax Flujo Básico Invalido = I
ESC-03 Detener Monitoreo de Error Hitrax Flujo Básico No Aplica = N/A
ESC-04 Cargar archivo Log Error Flujo Básico

ESC-05 Ver Detalle de Error Hitrax Sub Flujo
Validar Archivo Log Error Duplicado con archivo
ESC-06 Flujo Alterno
73077_20151104174533.htx
ESC-07 Validar Archivo Log No Existente en la carga de archivo Flujo Alterno
b. Matriz de Casos de Prueba:
ID Caso de Prueba Escenario/ Condición Código Error Fecha Error Detalle Error Voltaje Alineación Faja Visualización Estado VGA Estado COM Energía Entrada Sistema Operativo Archivo Log Resultado
CPS_046 ESC-01 I I I I I I I I I I I El sistema muestra mensaje: Monitoreo Iniciado y en el panel alarma el mensaje: Monitoreando…
CPS_046 ESC-02 I I I I I I I I I I I El sistema muestra alerta en el panel de alarma: Alerta Error X
CPS_046 ESC-03 I I I I I I I I I I I El sistema muestra mensaje: Monitoreo Terminado y en el panel alarma el mensaje: Detenido!
CPS_046 ESC-04 I I I I I I I I I I I El sistema muestra mensaje: Archivo Cargado Correctamente
CPS_046 ESC-05 I I I I I I I I I I I El sistema muestra la página: Detalle de Log Error #X
CPS_046 ESC-06 I I I I I I I I I I I El sistema muestra mensaje de error: Archivo Log Error ya se encuentra cargado
CPS_046 ESC-07 I I I I I I I I I I I El sistema muestra mensaje de error: Error al leer el archivo o no se encuentra
c. Matriz de Casos de Prueba con datos:
ID Caso de Prueba Escenario/ Condición Código Error Fecha Error Detalle Error Voltaje Alineación Faja Visualización Estado VGA Estado COM Energía Entrada Sistema Operativo Archivo Log Resultado
CPS_046 ESC-01 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A El sistema muestra mensaje: Monitoreo Iniciado y en el panel alarma el mensaje: Monitoreando…
CPS_046 ESC-02 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A El sistema muestra alerta en el panel de alarma: Alerta Error X
CPS_046 ESC-03 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A El sistema muestra mensaje: Monitoreo Terminado y en el panel alarma el mensaje: Detenido!
CPS_046 ESC-04 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A El sistema muestra mensaje: Archivo Cargado Correctamente
CPS_046 ESC-05 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A El sistema muestra la página: Detalle de Log Error #X
CPS_046 ESC-06 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A El sistema muestra mensaje de error: Archivo Log Error ya se encuentra cargado
CPS_046 ESC-07 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A El sistema muestra mensaje de error: Error al leer el archivo o no se encuentra
Página 223
Tabla 16: Escenarios y Juego de Datos CPS_046_Gestionar Logs de Errores del Hitrax [elaboración propia]
Página 224
4 CONCLUSIONES
 Se plantearon efectivamente las métricas de calidad necesarias para el proyecto, tanto

las internas como las externas, siguiendo la metodología ISO 9126.
 Se realizaron los casos de prueba de los casos de uso 006 y 046 debido al fuerte
impacto que estos casos de uso tienen en el proyecto y en la arquitectura. El CUS_006
contiene gran cantidad de Requerimiento de negocio y el CUS_046 describe una de las
funcionalidades que agregan valor a la propuesta.
 Se diseñó el plan de pruebas siguiendo un flujo de trabajo definido por la Gerencia del
área de Tecnología. Se probó las funcionalidades y flujos descritos en el plan de
pruebas, resultando exitoso en los casos propuestos. Así mismo, se utilizó juego de
datos con valores reales del día a día.
Página 225
CAPÍTULO 8: GESTIÓN DEL PROYECTO
1 INTRODUCCIÓN
El propósito del presente capítulo es el identificar y gestionar todos los procesos del proyecto
con las buenas prácticas recomendadas por el PMBOOK. Se muestran los interesados del
proyecto, así como el diagrama EDT y el cronograma que se cumplirá para llevar a cabo con
éxito el proyecto deseado.
2 REGISTRO DE INTERESADOS
Nombre del Cargo del Organización a que Categoría de Nivel de interés Nivel de influencia
Interesado Interesado pertenece interesado (Bajo, Medio, Alto) (Bajo, Medio, Alto)
Jose Giglio Director Unlimited-systems SAC Alta Dirección Bajo Medio
Jose Giglio Gerente General Unlimited-systems SAC Alta Dirección Medio Medio
Miguel Gonzalez Gerente de Técnología Unlimited-systems SAC Patrocinador Alto Alto
Jose Diaz Supervisor del área Unlimited-systems SAC Usuario Alto Medio
Alex Reategui Coordinador del área Unlimited-systems SAC Usuario Alto Bajo
Técnicos del Área Técnico Unlimited-systems SAC Usuario Alto Bajo
Hector Saira Asesor de Tesis UPC Asesor Alto Medio
Luis Sumarriva Tesista UPC Desarrollador Alto Medio
Tabla 17: Registro de Interesados [elaboración propia]
Página 226
3 EDT
Página 227
Gráfico 48: Diagrama EDT [elaboración propia]
Página 228
4 CRONOGRAMA DE EJECUCIÓN
Gráfico 49: Cronograma de tareas Fase 1 [elaboración propia]
Página 229
Página 230
Página 231
Página 232
5 ACTA DE ACEPTACIÓN DEL ENTREGABLE
Se muestra el Acta de Aceptación por parte de la empresa Unlimited-Systems SAC
Acta de Aceptación de Proyecto Informático 1
Página 233
Página 234
Página 235
Página 236
6 CONCLUSIONES
 El proyecto se ha realizado teniendo en cuenta las buenas prácticas de la gestión de

proyecto que se señalan en el PMBOOK.
 Se identificó el registro de interesados para poder gestionar el límite de poder que

tienen los involucrados dentro del proyecto, así se dará una trazabilidad de sus
modificaciones e impacto en los interesados.
 Se elaboró el EDT y el cronograma del proyecto siguiendo las buenas prácticas del
PMBOOK, así como los requerimientos y puntos necesarios para el éxito de los
objetivos del proyecto dentro de los límites de tiempo y costos de la organización.
Página 237
CONCLUSIONES
 El presente proyecto presentó dificultades del tipo tecnológicas, debido a la poca

experiencia en dichos campos de inteligencia artificial y geolocalización, sin embargo,
luego del estudio y análisis respectivo, se pudo llevar a prueba y producción las
funcionalidades que agregan valor a la propuesta del proyecto.
 Se logró especificar los casos de uso del ciclo 0, no tanto por su relevancia en el flujo
de procesos del negocio, tampoco por su importancia como línea base del software, se
definió dichos casos por su impacto en la arquitectura del proyecto, tanto en la
innovación tecnológica como en la interacción con otros servicios, sea Google Maps, y
otros equipos, como en el caso del Hitrax, propiedad de la marca SMITHS.
 Toda la documentación descrita en el proyecto ayudó a mejorar el entendimiento de los

interesados del proyecto, así como a explorar los diferentes aspectos teóricos y técnicos
que abarca un proyecto de tesis, también se plasmó la metodología RUP necesaria para
un correcto desarrollo de software, así como se cumplió los estándares de calidad
dentro del marco normativo internacional.
Página 238
GLOSARIO DE TÉRMINOS
1. Amenaza:
Hecho que puede producir un daño provocado por un evento natural o antrópico
2. Cromatografía
Es un conjunto de técnicas basadas en el principio de retención selectiva, cuyo objetivo
es separar los distintos componentes de una mezcla, permitiendo identificar y
determinar las cantidades de dichos componentes
3. Espectrometría:
Es una técnica de análisis que permite la medición de moléculas. El espectrómetro de
masas es un artefacto que permite analizar con gran precisión la composición de
diferentes elementos químicos e isótopos atómicos, separando los núcleos atómicos en
función de su relación carga-masa (z/m). Puede utilizarse para identificar los diferentes
elementos químicos que forman un compuesto, o para determinar el contenido
isotópico de diferentes elementos en un mismo compuesto
4. Infrarrojo
Es un tipo de radiación electromagnética y térmica, de mayor longitud de onda que la
luz visible, pero menor que la de las microondas. Los infrarrojos se utilizan en los
equipos de visión nocturna cuando la cantidad de luz visible es insuficiente para ver los
objetos. La radiación se recibe y después se refleja en una pantalla. Los objetos más
calientes se convierten en los más luminosos.
5. Inspección:
La inspección es el método de exploración física que se efectúa por medio de la vista.
Tiene como objetivo detectar características físicas significativas de su entorno y
observar y discriminar en forma precisa los hallazgos anormales en relación a los
normales.
6. Narcóticos:
Es una sustancia medicinal que, por definición, provoca sueño o en muchos casos
estupor y, en la mayoría de los casos, inhibe la transmisión de señales nerviosas, en
particular, las asociadas al dolor. El grupo de los narcóticos comprende gran variedad
de drogas con efectos psicoactivos, aunque terapéuticamente no se usan para promover
Página 239
cambios en el humor, como los psicotrópicos, sino por otras propiedades
farmacológicas.
7. Radiación:
Consiste en la propagación de energía en forma de ondas electromagnéticas o partículas
subatómicas a través del vacío o de un medio material.
8. Rayos gamma:
Constituyen un tipo de radiación ionizante capaz de penetrar en la materia más
profundamente que la radiación alfa y la beta. Pueden causar grave daño al núcleo de
las células, por lo cual se usan para esterilizar equipos médicos y alimentos.
9. Rayos X:
Es una radiación electromagnética, invisible para el ojo humano, capaz de atravesar
cuerpos opacos y de imprimir sus imágenes. Los actuales sistemas digitales permiten la
obtención y visualización de la imagen radiográfica directamente en una computadora.
10. Transformada de Fourier
Es una transformación matemática empleada para transformar señales entre el dominio
del tiempo (o espacial) y el dominio de la frecuencia, que tiene muchas aplicaciones en
la física y la ingeniería. Es reversible, siendo capaz de transformaciones de cualquiera
de los dominios al otro. El propio término se refiere tanto a la operación de
transformación como a la función que produce.
11. Trilateración de Fourier
Es un método matemático para determinar las posiciones relativas de objetos usando la
geometría de triángulos de forma análoga a la triangulación. A diferencia de ésta, que
usa medidas de ángulo, la trilateración usa las localizaciones conocidas de dos o más
puntos de referencia, y la distancia medida entre el sujeto y cada punto de referencia.
Página 240
SIGLARIO
CEIA COSTRUZIONI ELETTRONICHE INDUSTRIALI AUTOMATISMI
GPS GLOBAL POSITIONING SYSTEM
HAZMAT HAZARDOUS MATERIALS
HS HI SCAN
LCD LIQUID-CRYSTAL DISPLAY
MMTD MULTI-MODE THREAT DETECTOR
OASIS ORGANIZATION FOR THE ADVANCEMENT OF STRUCTURED

INFORMATION STANDARDS
SAC SOCIEDAD ANONIMA CERRADA
STI SAFETY TECHNOLOGY INTERNATIONAL
XRD DIFRACCIÓN DE RAYOS X
XRF ANALIZADORES DE FLUORESCENCIA DE RAYOS
W3C WORLD WIDE WEB CONSORTIUM
Página 241
Página 242
BIBLIOGRAFÍA
1. Unlimited Systems (2015). Página Oficial (Consulta 09 enero).

http://www.unlimited-systems.com/
2. Baker, T. P., & Scallon, G. M. (2014). Special feature: An architecture for real-time
software systems. IEEE Software, 3(3), 50-58. doi:
http://dx.doi.org/10.1109/MS.1986.233416
3. Hall, D. (2009). The ethical software engineer. IEEE Software, 26(4), 9-10. doi:
http://dx.doi.org/10.1109/MS.2009.106
4. Southard, S. (2005). Implementing the information architect role in the rational unified
process [RUP]. Technical Communication, 52(2), 251. Retrieved from
http://search.proquest.com/docview/220998828?accountid=438600
5. MPSoftware (2015). Página Oficial (Consulta 15 enero).

http://www.mpsoftware.com.mx/software_mantenimiento/mp_cmms.html
6. SisTrade Software Computing S.A (2015). Página Oficial (Consulta 15 enero).

http://www.sistrade.com/es/Soluciones/mis-erp-sistrade-mantenimiento-equipos.htm
7. Espinosa, F. F., Dias, A., & Salinas, G. E. (2012). Un procedimiento para evaluar el
riesgo de la innovación en la gestión del mantenimiento industrial/A procedure for
assessing the risks of innovation in the management of industrial maintenance.
Ingeniare : Revista Chilena De Ingenieria, 20(2), 242-254. Retrieved from
8. Maycock, B., & Hall, S. E. (2005). Bridging the gap: Integrating quality management
into health promotion practice/Combler le fossé : Intégrer la gestion de la qualité dans
la pratique en promotion de la santé/Llenar un vacío: Integrar la gestión de la calidad en
Página 243
la práctica de la promoción de la salud. Promotion & Education, 12(1), 7-12,31,48.
Retrieved from http://search.proquest.com/docview/233363550?accountid=43860
9. Viveros, P., Stegmaier, R., Kristjanpoller, F., Barbera, L., & Crespo, A. (2013).
Propuesta de un modelo de gestión de mantenimiento y sus principales herramientas de
apoyo/Proposal of a maintenance management model and its main support tools.
Ingeniare : Revista Chilena De Ingenieria, 21(1), 125-138. Retrieved from
10. Alvarez Pantoja, Jose, Osmay Peña Morales. Dinámica del proceso enseñanza-
aprendizaje del tema “la gestión de la calidad en el servicio postventa” / José Álvarez
Pantoja, Osmay Morales Peña. Holguín. Universidad de Holguín “Oscar Lucero
Moya”, 2000. Trabajo de Diploma (Ingeniería Industrial).
11. Hurlburt, G., Voas, J., & W Miller, K. (2010). Mobile applications: The fifth cycle.
IT Professional Magazine, 12(6), 56-60. Retrieved from
12. Funk, J. L. (2004). Key technological trajectories and the expansion of mobile internet
applications. Info : The Journal of Policy, Regulation and Strategy for
Telecommunications, Information and Media, 6(3), 208-215. Retrieved from
13. Chen, X. (2013). Web service based mobile worker supporting system for construction
industry applications. Telecommunication Systems, 54(3), 277-286. doi:
http://dx.doi.org/10.1007/s11235-013-9733-y
14. Gartner (2013). Gartner says consumers will spend $6.2 billion in mobile application
stores in 2010. doi: http://www.gartner.com/newsroom/id/1282413
15. ISO/IEC 90003 Second Edition 2014-12-15 (2014). Software Engineering –

Guidelines for the application of ISO 9001:2008 to computer software. Retrieved from
https://www.iso.org/obp/ui/#!iso:std:66240:en
Página 244
16. IEEE Std 830 (Rev 1998). IEEE Recommended Practice for Software Requirements
Specifications. Retrieved from
http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
17. Sanders, Joc & Eugene Curran. Software Quality. A Framework for Success in
Software Development and Support, Addison Wesley.
18. Avgeriou, P., & Zdun, U. (2005). Architectural patterns revisited–a pattern language.
Retrieved from
http://posomas.isse.de/PosoMAS/aose.practice.tech.pattern_driven_mas_design.base/
guidances/whitepapers/resources/Avgeriou%20-%20Architectural%20Patterns
%20Revisited%20-%20A%20Pattern%20Language.pdf
19. Osmani, Addy (2015). Learning Javascript Design Patterns. Volumen 1.6.2 Retrieved
from http://addyosmani.com/resources/essentialjsdesignpatterns/book/#detailmvc
20. Losavio, F., Chirinos, L., Lévy, N., & Ramdane-Cherif, A. (2003). Quality
characteristics for software architecture. Journal of Object Technology, 2(2), 133-150.
Retrieved from http://www.jot.fm/issues/issue_2003_03/article2/
Página 245
ANEXOS
ANEXO 1: Formato de Orden de Servicio

ANEXO 2: Reporte de Servicio
ANEXO 3: Informe Técnico
Página 246
ANEXO 1: Formato de Orden de Servicio
Página 247
ANEXO 2: Reporte de Servicio
Página 248
ANEXO 3: Informe Técnico
Página 249
Página 250

Entregable 3 PI3 - Sumarriva Rubio

Cargado por

Copyright:

Formatos disponibles

Entregable 3 PI3 - Sumarriva Rubio

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

Entregable 3 PI3 - Sumarriva Rubio

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS

SISTEMA DE GESTIÓN DE SERVICIO TÉCNICO Y MONITOREO PARA

PROYECTO PROFESIONAL PRESENTADO POR:

PARA OPTAR POR EL TÍTULO DE INGENIERO DE SISTEMAS

Lima, Noviembre de 2015

El presente proyecto de tesis “SISTEMA DE GESTIÓN DE SERVICIO TÉCNICO Y

En el proceso de soporte técnico se ha analizado la necesidad de implementar un solución

Por lo cual en este documento se desarrolla la solución propuesta para la empresa y

El contenido del trabajo se divide en 7 capítulos comprendiendo desde los fundamentos

Gráfico 1: Ciclo de Trabajo de mantenimiento [9]..................................................................14

Tabla 1: Tipos de Servicio Postventa [10]...............................................................................15

El presente capítulo proporciona información referente a los fundamentos teóricos sobre el

2.1 Fundamentos teóricos sobre el negocio

El desarrollo e implementación de un modelo real y factible para la gestión global del

El concepto base que da lugar a la ingeniería de mantenimiento es la mejora continua del

La ingeniería de mantenimiento permite, a partir del análisis y modelado de los resultados

Gráfico 1: Ciclo de Trabajo de mantenimiento [9]

La calidad de un producto está dada por su capacidad de satisfacer determinadas necesidades

Para gestionar la calidad en el proceso de servicio postventa se desarrollan acciones para

Gráfico 2: Ciclo de Gestión de Calidad [8]

Una de estas es la IA (Inteligencia Artificial), la cual se describe como la capacidad de

Otra a utilizar es la BI (Bussiness Inteligence o Inteligencia de Negocios). La inteligencia de

La arquitectura relacionada a la conectividad con aplicaciones móviles se presenta a

Gráfico 3: Arquitectura de un sistema móvil [13]

La expansión de las aplicaciones móviles se da en 6 aspectos, teniendo en cuenta los avances

En lo respectivo a la interacción móvil con el servicio central a brindar, se utiliza el servicio

Gráfico 4: Implementación de servicio web con aplicación móvil [13]

3.1 Organización Objetivo

3.1.1 Descripción de la organización objetivo

3.1.2 Líneas de negocio

 Detección y Defensa: Soluciones tecnológicas que permiten detectar rápidamente

 Médica: Soluciones en equipamiento científico y médico con tecnología de vanguardia.

 Medio Ambiente: Soluciones tecnológicas de vanguardia para el tratamiento de aguas

3.1.3 Servicios ofrecidos

 Servicio de Ingeniería y Preparación de Proyectos:

3.1.4 Productos Ofrecidos

Unlimited Systems S.A.C comercializa y da soporte técnico y operativo a los siguientes

Las ondas milimétricas poseen la propiedad única de pasar transparentemente a través

 Espectrometría de Movilidad de Iones:

 Espectrometría de Infrarrojo por Transformada de Fourier:

 Cromatografía de gases / Espectrometría de Masa (GS/MS):

 Espectroscopia de Rayos Gamma:

3.1.5 Trayectoria Empresarial

“Proveer soluciones integrales en el ámbito de la seguridad, protección y desarrollo

3.4 Objetivos Estratégicos

 Incrementar las ventas de equipos y servicios en un 20%

 Fortalecer el área de Marketing en la empresa y atraer nuevos clientes.

 Mejorar en un 30% la atención de servicio al cliente.

 Incrementar los puntos de servicio técnico y laboratorios en Provincias.

 Optimizar los procesos de servicio técnico y soporte en un 40%

 Mejorar la productividad del personal en un 20%.

4.1 Breve Descripción

El proyecto se centrará en el área de Tecnología, el cuál realiza el proceso de. El rubro de la

A continuación se detalla el mapa de procesos general de la empresa.

Gráfico 6: Mapa de Procesos General [elaboración propia]

El campo de acción en el cuál se enfoca el proyecto es “Gestión de Soporte Técnico” el cuál

4.2 Procesos del Negocio

El campo de acción de este proyecto es el de Gestión de Soporte Técnico, el cual contiene

A continuación se detalla el flujo de tareas que forman parte del proceso.