View
1
Download
0
Category
Preview:
Citation preview
I
INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍAS, CIENCIAS SOCIALES Y ADMINISTRATIVAS
SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN “PROPUESTA DE DISEÑO DE DESARROLLO DE UN SISTEMA
DE ADMINISTRACIÓN DE LOS SERVICIOS DE MANTENIMIENTO (SASM) DE UNA EMPRESA DE CONSTRUCCIÓN DE EQUIPOS DE VERIFICACIÓN
VEHICULAR” T E S I S
QUE PARA OBTENER EL GRADO DE: MAESTRO EN CIENCIAS EN INFORMÁTICA
PRESENTA: JORGE RAMÍREZ VILLARREAL
DIRECTORA: DRA. MARTHA JIMÉNEZ GARCÍA
CD DE MÉXICO DICIEMBRE, 2018
II
ACTA DE REVISIÓN DE TESIS ----------------------------------------------------------------------------------------------------
III
CARTA DE CESIÓN DE DERECHOS ----------------------------------------------------------------------------------------------------
IV
AGRADECIMIENTOS -------------------------------------------------------------------------------------------------------------------------------- Académicamente, especial agradecimiento a mi directora de tesis Dra. Martha Jiménez García por su infinita paciencia, por su inigualable vocación, por su invaluable apoyo en la culminación del presente trabajo y por su gran calidad humana. A mi comité tutorial, integrado por la Dra. Claudia Marina Vicario Solórzano, Dr. Fernando Vázquez Torres, Dr. Eric Manuel Rosales Peña Alfaro y el M. en C. Abel Bueno Meza, por sus revisiones y sugerencias, de quienes también tuve la fortuna de recibir cátedra y enseñanzas que superan los límites del salón de clase. A todos los profesores de la SEPI UPIICSA, por su gran conocimiento y apoyo desde el inicio. Familiarmente, especial agradecimiento a mi esposa por contar siempre con su apoyo incondicional; a mis hijos, nietos, suegros, hermanos, tíos, mi madre y a mi querido padre ya fallecido, de quienes sus consejos han sido una guía para mi viaje por la vida. En el ámbito laboral, especial agradecimiento a la empresa Medios y Procedimientos Tecnológicos, S.A. de C.V, a mis jefes y compañeros de trabajo, que son muchos para nombrarlos a todos, pero aprecio el tiempo, las oportunidades y el apoyo que me han brindado siempre.
V
RESUMEN Considerando que las empresas proveedoras de equipos de verificación vehicular son
importantes para el desarrollo económico de México y que contribuyen de manera directa al
correcto funcionamiento de los verificentros e indirectamente en los factores de movilidad y la
salud de la población; los cuales son factores clave en el desarrollo del país. El objetivo de esta
investigación fue desarrollar una propuesta de un sistema para ayudar a estas empresas a
incrementar sus niveles de competitividad y productividad en el proceso de entrega de servicio
(mantenimiento y/o reparaciones) mediante la adición de TIC a dicho proceso. La metodología
utilizada para el desarrollo del sistema es la metodología evolutiva en espiral.
Como resultados se presenta la propuesta del diseño de desarrollo de un Sistema de
Administración de los Servicios de Mantenimiento (SASM) de una empresa de construcción de
equipos de verificación vehicular, dicha propuesta inicia con aspectos legales y normativos que
son considerados en el diseño, posteriormente se analizaron los requerimientos funcionales y no
funcionales, así como los reportes deseados, y los casos de uso con los actores en los procesos
involucrados. Posteriormente se plantea la arquitectura lógica y física del sistema, el cual dirige
hacia un modelo de datos relacional, y finalmente se presentan el diseño de las interfaces de
usuario del sistema.
VI
ABSTRACT Considering that the suppliers of vehicle verification equipment are important for the economic
development of Mexico and that they contribute directly to the proper functioning of the
verificenters and indirectly to the factors of mobility and the health of the population; which are key
factors in the development of the country. The objective of this research was to develop a proposal
for a system to help these companies increase their levels of competitiveness and productivity in
the service delivery process (maintenance and / or repairs) by adding ICT to this process. The
methodology used for the development of the system is the spiraling evolutionary methodology.
As a result, the proposal for the development design of a Maintenance Services Management
System (SASM) of a vehicle verification equipment construction company is presented, this
proposal starts with legal and regulatory aspects that are considered in the design, subsequently
the functional and non-functional requirements were analyzed, as well as the desired reports, and
the cases of use with the actors in the processes involved. Subsequently, the logical and physical
architecture of the system is proposed, which leads to a relational data model, and finally the
design of the user interfaces of the system are presented.
7
ÍNDICE GENERAL ------------------------------------------------------------------------------------------------------------------------ 1 CAPÍTULO I. ANTECEDENTES ................................................................... 24
1.1 Planeamiento del Problema .............................................................. 24
1.2 Justificación ...................................................................................... 25
1.3 Objetivo ............................................................................................ 26
1.4 Objetivos específicos ........................................................................ 26
1.4.1 Hipótesis ..................................................................................... 26
1.5 Metodología ..................................................................................... 27
1.6 Las TIC y su inclusión en las empresas ............................................... 27
1.7 Importancia de la inclusión de las TIC en el mantenimiento ............. 28
1.8 Objetivos de la inclusión de las TIC en la empresa “Medios y Procedimientos Tecnológicos, S.A. de C.V.” ............................................... 30
1.9 Metodología para la inclusión de las TIC en la empresa “Medios y Procedimientos Tecnológicos, S.A. de C.V.” ............................................... 31
1.10 Vista General del Sistema SASM en una arquitectura distribuida de 3 capas 35
1.11 Asunciones, riesgos y alcances del Sistema SASM .......................... 37
1.12 Descripción del sistema: Sistema de Administración de los Servicios de Mantenimiento (SASM) ......................................................................... 38
1.13 Resultados esperados a la implementación del SASM ................... 38
2 CAPÍTULO II. ANTECEDENTES: LA INDUSTRIA DE LAS EMPRESAS PROVEEDORAS DE MANTENIMIENTO Y EQUIPOS DE VERIFICACIÓN VEHICULAR 40
2.1 Situación actual en México, principales empresas y por nivel de gobierno, actores de la industria y sus relaciones ...................................... 40
2.1.1 Principales empresas en el país................................................... 40
2.1.2 Principales empresas por nivel de gobierno: Federal, Estatal y CDMX 42
2.1.3 Actores de la industria y sus relaciones ....................................... 43
2.2 Marco legal (Principales órganos reguladores, legislación y normas ambientales). ............................................................................................. 44
8
2.2.1 Secretaría de Medio Ambiente y Recursos Naturales (SEMARNAT) 44
2.2.2 Comisión Ambiental de la Megalópolis (CAMe) .......................... 44
2.2.3 Centro de Investigación: Centro Mario Molina para Estudios Estratégicos sobre Energía y Medio Ambiente, A.C. ................................ 45
2.2.4 Centro de Investigación: Instituto Nacional de Ecología y Cambio Climático ................................................................................................. 45
2.2.5 Dirección General de Normas (DGN) de la Secretaría de Economía (SE) 45
2.3 Legislación y normas ambientales ..................................................... 46
2.3.1 Ley General del Equilibrio Ecológico y Protección al Ambiente ... 46
2.3.2 NOM-041-SEMARNAT-2015 ........................................................ 46
2.3.3 NOM-045-SEMARNAT-2006 ........................................................ 47
2.3.4 NOM-047-SEMARNAT-2014 ........................................................ 47
2.3.5 NOM-050-SEMARNAT-1993 ........................................................ 47
2.3.6 NOM-167-SEMARNAT-2017 ........................................................ 47
2.4 Marco TIC (Plan Nacional de Desarrollo 2013-2018, Agenda Digital Nacional e Iniciativas de ley) ...................................................................... 48
2.5 CASO DE ESTUDIO: “Medios y Procedimientos Tecnológicos, S.A. de C.V.” 49
2.6 Análisis general de la situación actual: FODA .................................... 51
2.6.1 Estructura organizacional............................................................ 52
2.6.2 Procesos primarios relacionados con el de proceso de Servicio (La Cadena de Valor) ..................................................................................... 54
2.6.3 Proceso Clave: Entrega Del Servicio ............................................ 55
2.6.4 Elementos que Integran el Sistema propuesto: “Sistema de Administración de los Servicios de Mantenimiento (SASM)” .................. 56
3 CAPÍTULO III. ANÁLISIS DEL SISTEMA DE ADMINISTRACIÓN DE LOS SERVICIOS DE MANTENIMIENTO (SASM) – REQUERIMIENTOS Y CASOS DE USO 57
3.1 Actores del sistema y acciones .......................................................... 57
9
3.1.1 Requerimientos Funcionales (RF): Inicio y cierre de sesión ......... 58
3.1.2 Requerimientos Funcionales (RF): Catálogo de Usuarios ............ 59
3.1.3 Requerimientos Funcionales (RF): Catálogo de Centros de Servicio 60
3.1.4 Requerimientos Funcionales (RF): Catálogo de Conceptos de Servicio ................................................................................................... 61
3.1.5 Requerimientos Funcionales (RF): Catálogo de Conceptos de Adeudo ................................................................................................... 62
3.1.6 Requerimientos Funcionales (RF): Solicitudes de Servicio ........... 63
3.1.6.1 Formato: Reporte de la nueva solicitud de servicio .............. 65
3.1.7 Requerimientos Funcionales (RF): Adeudos (consultas) .............. 69
3.1.8 Requerimientos Funcionales (RF): Reportes ............................... 71
3.1.8.1 Formato: Reporte de estado de las solicitudes de servicio (Iniciada, Asignada, Finalizada, Pendiente de pago, Pagada y Sin costo) 72
3.1.8.2 Formato: Reporte de adeudos .............................................. 73
3.1.8.3 Formato: Reporte de Cómputo ............................................. 74
3.1.8.4 Formato: Reporte de centros x concepto de servicio (tipo de solicitud) ............................................................................................. 75
3.1.8.5 Formato: Reporte de técnicos x concepto de servicio (tipo de solicitud) ............................................................................................. 76
3.1.8.6 Formato: Reporte de opciones: Ecológico/Local ................... 77
3.2 Requerimientos no Funcionales (RNF) .............................................. 77
3.2.1 RNF: Generales (manejo y detección de errores, modelado UML, respaldo de BD, tiempo de respuesta razonable y protección de datos personales) ............................................................................................. 77
3.2.2 RNF: Calidad (manual de usuario, mensajes de error e información para usuarios y disponibilidad del sistema) ............................................. 78
3.2.3 RNF: Arquitectura Física del Sistema (servidor de aplicaciones, lenguaje de programación, base de datos y cantidad de usuarios) ......... 78
3.2.4 RNF: Arquitectura lógica del sistema (diagramas: casos de uso, conceptual, clases, interacción, estados, componentes y cronograma) .. 79
10
3.2.5 RNF: Modelo de datos ................................................................ 80
3.3 CASOS DE USO .................................................................................. 81
3.3.1 Caso de uso general del sistema SASM ....................................... 81
3.3.2 Login ........................................................................................... 82
3.3.3 Administrar catálogos ................................................................. 82
3.3.4 Crear Solicitud ............................................................................. 83
3.3.5 Consultar solicitud ...................................................................... 84
3.3.6 Capturar Adeudos ....................................................................... 85
3.3.7 Generar Reportes ....................................................................... 86
3.3.8 Lista de casos de uso ................................................................... 87
4 CAPÍTULO IV. DISEÑO DEL SISTEMA DE ADMINISTRACIÓN DE LOS SERVICIOS DE MANTENIMIENTO (SASM) ...................................................... 89
4.1 Arquitectura Lógica ........................................................................... 89
4.1.1 Diagrama de componentes del sistema ...................................... 89
4.1.2 Diagramas de secuencia .............................................................. 90
4.1.3 Diagramas de estado ................................................................ 104
4.1.4 Diagramas de actividad ............................................................. 108
4.1.5 Diagrama de clases ................................................................... 120
4.1.6 Diagrama de despliegue del SASM ............................................ 121
4.2 Arquitectura Física .......................................................................... 122
4.2.1 Capas ........................................................................................ 123
4.2.2 Representación de la arquitectura de 3 capas .......................... 124
4.2.3 Infraestructura .......................................................................... 125
4.2.4 Ambientes del sistema .............................................................. 126
4.2.5 Recomendaciones de hardware para producción ..................... 127
4.3 Modelo de datos ............................................................................. 128
4.3.1 Diagrama Entidad Relación ....................................................... 129
4.3.2 Modelo de datos relacional ...................................................... 130
4.3.3 Diccionario de datos ................................................................. 131
11
4.4 Interfaces de Usuario (Guías gráficas) ............................................. 133
4.4.1 GUI: Acceso al sistema .............................................................. 133
4.4.2 GUI: Menú principal del sistema ............................................... 134
4.4.3 GUI: Catálogos de usuarios, centros de servicio y de conceptos de adeudo 135
4.4.4 GUI: Nuevas solicitudes de mantenimiento y servicio ............... 138
4.4.5 GUI: Consulta de solicitudes iniciadas y asignadas .................... 140
4.4.6 GUI: Finalizar solicitudes de mantenimiento y servicio ............. 142
4.4.7 GUI: Consulta de solicitudes finalizada y de adeudos ................ 144
4.4.8 GUI: Captura de adeudos .......................................................... 146
4.4.9 GUI: Reporte del estado de la solicitud, de adeudos, de cómputo, de centros por tipo de solicitud, de técnicos por tipo de solicitud y de opciones ................................................................................................ 147
CONCLUSIONES ........................................................................................... 150
TRABAJO FUTURO ....................................................................................... 151
REFERENCIAS BIBLIOGRÁFICAS .................................................................... 152
REFERENCIAS ELECTRÓNICAS ...................................................................... 154
Anexo A: Descripciones de los Casos de Uso ............................................... 156
12
GLOSARIO ------------------------------------------------------------------------------------------------------------------------ Abstracción Es la capacidad de separar aspectos importantes de detalles. Una abstracción
define una delimitación relativa a la perspectiva del observador.
Actor Es un tipo con un estereotipo predefinido, que denota una entidad externa al sistema
que interactúa con casos de uso.
Análisis Es la parte del proceso de desarrollo de software cuyo propósito principal es
realizar un modelo del dominio del problema. El análisis hace foco en qué hacer, el diseño
hace foco en cómo hacerlo.
Aplicación Uno o más programas de sistema o componentes de software que proporcionan
una función de soporte directo de un proceso o procesos de negocio específicos. Véase
también servidor de aplicaciones.
Aplicación cliente Aplicación, que se ejecuta en una estación de trabajo y está enlazada
con un cliente, que da acceso a la aplicación para poner servicios en cola en un servidor.
Aplicación web Aplicación a la que puede accederse mediante un navegador web y que
proporciona otras funciones aparte de la visualización estática de la información,
permitiendo, por ejemplo, que el usuario realice una consulta a una base de datos. Los
componentes comunes de una aplicación web incluyen páginas HTML, páginas JSP y
servlets.
Arquitectura Consiste en la estructura organizacional de un sistema. Una arquitectura
puede ser descompuesta recursivamente en partes que interactúan entre sí por medio de
interfaces, relaciones que conectan las partes, y restricciones para ensamblar las partes.
Artefacto (artifact) Es una información que es usada o producida mediante un proceso de
desarrollo de software. Un artefacto puede ser un modelo, una descripción o software.
Atributo Es una parte específica de una clase. Una propiedad de un tipo identificada
mediante un nombre.
Calidad de Software Es la concordancia con los requerimientos funcionales y de
rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente
documentados y con las características implícitas que se esperan de todo software
desarrollado profesionalmente.
13
Capa (layer) Una forma específica de agrupar paquetes en un modelo al mismo nivel de
abstracción.
Casos de Uso Es aquello que describe la interacción de los Actores con el sistema para
lograr un objetivo.
Componente Es un módulo de software ejecutable que tiene identidad y una interface bien
definida.
Comportamiento Se dice que un objeto tiene comportamiento, el cual está representado
por los mensajes que envía o recibe de otro objeto. Son los efectos visibles de su operación,
ejecución de eventos, incluyendo sus resultados.
Confiabilidad Es la probabilidad de operación libre de fallas de un programa de
computadora en un entorno determinado y durante un tiempo específico.
Consistencia Es aquello que consiste en el uso de un diseño uniforme de técnicas de
documentación a lo largo del proyecto de desarrollo de software.
Contenedor Es un objeto que existe para contener otros objetos, y que provee operaciones
para acceder o iterar sobre su contenido. Por ejemplo: arreglos, conjuntos, diccionarios. Es
un componente que existe para contener otras componentes.
Dependencia Es aquello que indica la relación semántica entre elementos del modelo.
Diagrama de Actividad Es un caso especial de diagrama de estados en el que todos, o la
mayoría, son estados activos y en el que todas, o la mayoría, de las transiciones son
disparadas por la finalización de las acciones de los estados.
Diagrama de Casos de Uso Es el diagrama que muestra la relación entre los actores y los
casos de uso dentro de un sistema.
Diagrama de Clases Es el diagrama que muestra una colección de elementos del modelo
tales como las clases, tipos y sus contenidos y relaciones.
Diagrama de Componentes Es un diagrama que muestra la organización de los
componentes y sus dependencias.
Diagrama Entidad / Relación Es una descripción conceptual de las estructuras de datos y
sus relaciones.
Diagrama de Estado Es el diagrama que muestra el estado de la máquina.
14
Diagrama de Flujo de Datos (DFD) Es una descripción informal del sistema de
información.
Diagrama de Interacción Es un término genérico que se aplica a diversos tipos de
diagramas que enfatizan la interacción entre objetos. Incluye: diagrama de colaboraciones,
diagrama de secuencias, diagrama de actividades.
Diagrama de Secuencia Es el diagrama que muestra los objetos que participan en la
interacción y la secuencia de mensajes que intercambian.
Diseño Es la parte del proceso de desarrollo de software cuyo propósito principal es decidir
cómo se construirá el sistema. Durante el diseño se toman decisiones estratégicas y
tácticas para alcanzar los requerimientos funcionales y la calidad esperada.
Dominio Es un área de conocimiento o actividad caracterizada por un conjunto de
conceptos y términos comprendidos por los practicantes de esa área.
Elemento Es un elemento atómico constitutivo de un modelo.
Escenario Es una instancia de un Caso de Uso.
Especificación Es un informe de acuerdo entre el implementador y el usuario.
Especificación de Requerimientos Es aquella que establece un acuerdo entre el usuario
y el desarrollador del sistema.
Estado Es una condición o situación en la vida de un objeto, durante la cual satisface una
condición, realiza una actividad o está esperando un evento.
Evento Es un acontecimiento que puede disparar una transición de estados.
Fallo Es cualquier no concordancia con los requerimientos del software.
Framework Es un micro-arquitectura que provee un molde extensible para aplicaciones de
un dominio específico.
Implementación Es la definición de cómo está construido o compuesto algo. Por ejemplo:
una clase es una implementación de un tipo, un método es una implementación de una
operación.
Ingeniería de Software Es una disciplina para el desarrollo de software de alta calidad para
sistemas basados en computadora.
15
Interacción Es una especificación de comportamiento cuyo fin es lograr un propósito
específico. Abarca un conjunto de intercambios de mensajes entre un conjunto de objetos
dentro de un contexto particular. Una interacción puede ilustrarse mediante uno o más
escenarios.
Integridad de los datos Servicio de seguridad que detecta si se si ha producido una
modificación no autorizada o un manejo indebido de los datos. El servicio sólo detecta si se
han modificado datos; no restaura datos a su estado original si se han modificado.
Interfaz de programación de aplicaciones (API) Interfaz que permite que un programa
de aplicación escrito en un lenguaje de nivel alto pueda utilizar funciones o datos específicos
del sistema operativo o de otro programa.
Java Lenguaje de programación orientado a objetos para código de interpretación portable
que soporta la interacción entre objetos remotos. Java fue desarrollado y especificado por
Sun Microsystems, Incorporated.
JavaBeans Según la definición de Sun Microsystems para Java, modelo de componente
portable, independiente de la plataforma y reutilizable.
Java Platform, Enterprise Edition (Java EE) Entorno para desarrollar y desplegar
aplicaciones empresariales, definido por Sun Microsystems Inc. La plataforma Java EE se
compone de un conjunto de servicios, interfaces de programación de aplicaciones (API) y
protocolos que proporcionan la funcionalidad para desarrollar aplicaciones de varios niveles
basadas en web.
JavaServer Faces (JSF) Infraestructura para construir interfaces de usuario basadas en
web en Java. Los desarrolladores web pueden construir aplicaciones colocando
componentes de UI reutilizables en una página, conectando los componentes a un origen
de datos de aplicaciones y transmitiendo eventos de cliente a manejadores de eventos de
servidor.
Lógica de negocio Expresada por reglas de negocio, que consisten en decisiones que
afectan la forma como una empresa responde a unas condiciones de negocio específicas.
Por ejemplo, una decisión que determina qué descuento hay que dar a un cliente preferido
es lógica de reglas.
Método Es un procedimiento o función asociada a un tipo de objeto declarado dentro de un
objeto. Es la implementación del mensaje. La implementación de una operación. El
algoritmo o procedimiento que permite llegar al resultado de una operación.
16
Modelo Es una abstracción semánticamente consistente de un sistema.
Módulo Son los objetos más las operaciones. Es una unidad de manipulación y
almacenamiento de un software. Incluyen: módulos de código fuente, módulos de código
binario, módulos de código ejecutable.
Objeto Es un componente del mundo real que tiene una cierta estructura interna y un
determinado comportamiento. Una entidad delimitada precisamente y con identidad, que
encapsula estado y comportamiento. El estado es representado por sus atributos y
relaciones, el comportamiento es representado por sus operaciones y métodos. Un objeto
es una instancia de una clase.
Precondición Es una restricción que debe ser verdadera cuando una operación es
invocada.
Producto Son los artefactos del desarrollo de software. Por ejemplo: modelos, código,
documentación, planes de trabajo.
Prototipo Es aquello que permite diseñar con una adecuada definición lo que ve el usuario,
cómo interpreta la interface con el sistema y qué espera de él a nivel de información.
Proyecto En al ámbito informático, es un conjunto ordenado de tareas realizado por
recursos humanos con responsabilidad utilizando recursos técnicos entendiendo su
complejidad, que permiten construir un producto de software, que cubre el logro de algún
objetivo u objetivos claramente predeterminados por alguien.
Repositorio Es aquel que consta de las tablas y vistas que se utilizan como interfaz con
los datos y el código procedimental que las maneja. Almacena los detalles del sistema que
se está desarrollando.
Requerimiento Es una característica, propiedad o comportamiento deseado para un
sistema.
Seguridad Es la disponibilidad de mecanismos que controlen o protejan los programas o
datos.
Servidor Gestor de colas que proporciona servicio de cola a aplicaciones cliente que se
ejecutan en una estación de trabajo remota. Programa de software o sistema que
proporciona servicios a otros programas de software o sistemas.
Sesión Conexión lógica o virtual entre dos estaciones, programas de software o
dispositivos de una red que permite que los dos elementos se comuniquen e intercambien
17
datos durante la sesión. Serie de solicitudes a un servlet provenientes del mismo usuario
en el mismo navegador. En Java EE, objeto utilizado por un servlet para realizar un
seguimiento de la interacción del usuario con una aplicación web en varias solicitudes
HTTP.
Spring Es un Framework de desarrollo que simplifica el desarrollo de aplicaciones Java,
independientemente de si se trata de aplicaciones web ordinarias o sin conexión web. Sus
mayores ventajas son un código fuente más simplificado y una menor dificultad en los
ajustes.
Vista Es una proyección de un modelo, que es observado desde una perspectiva dada y
que omite entidades que no son relevantes para esa perspectiva.
18
ÍNDICE DE TABLAS ------------------------------------------------------------------------------------------------------- Tabla 1: Formato 6.1 Reporte de la nueva solicitud de servicio ........... 65 Tabla 2: Formato 8.1 Reporte de estado de las solicitudes de servicio ...................................................................................................................... 72 Tabla 3: Formato 8.2 Reporte de adeudos ............................................. 73 Tabla 4: Formato 8.3 Reporte de cómputo ............................................. 74 Tabla 5: Formato 8.4 Reporte de centros x concepto de servicio (tipo de solicitud) ....................................................................................................... 75 Tabla 6: Formato 8.5 Reporte de técnicos x concepto de servicio (tipo de solicitud) ................................................................................................. 76 Tabla 7: Formato 8.6 Reporte de opciones: Ecológico/Local ............... 77 Tabla 8: Listado de los casos de uso ....................................................... 87 Tabla 9: Estilo/Patrón arquitectónico Fuente: Elaboración propia ...... 122 Tabla 10: Recomendación de HW para el ambiente de producción del SASM Fuente: Elaboración propia ......................................................... 127 Tabla 11: Diccionario de Datos Fuente: Elaboración propia ............... 131 Tabla 12: Caso de uso: Crear sesión Fuente: Elaboración propia ..... 156 Tabla 13: Caso de uso: Cerrar sesión Fuente: Elaboración propia ... 157 Tabla 14: Caso de uso: Expira sesión Fuente: Elaboración propia ... 158 Tabla 15: Caso de uso: Reanudar sesión Fuente: Elaboración propia .................................................................................................................... 159 Tabla 16: Caso de uso: Crear usuario Fuente: Elaboración propia ... 160 Tabla 17: Caso de uso: Modificar usuario Fuente: Elaboración propia .................................................................................................................... 161 Tabla 18: Caso de uso: Crear centro de servicio Fuente: Elaboración propia ......................................................................................................... 162 Tabla 19: Caso de uso: Modificar centro de servicio Fuente: Elaboración propia ......................................................................................................... 163 Tabla 20: Caso de uso: Crear concepto de adeudo Fuente: Elaboración propia ......................................................................................................... 164 Tabla 21: Caso de uso: Modificar concepto de adeudo Fuente: Elaboración propia ................................................................................... 165 Tabla 22: Caso de uso: Crear solicitud Fuente: Elaboración propia .. 166 Tabla 23: Caso de uso: Reporte de solicitud de mantenimiento Fuente: Elaboración propia ................................................................................... 168 Tabla 24: Caso de uso: Reporte de solicitud de servicios Fuente: Elaboración propia ................................................................................... 169
19
Tabla 25: Caso de uso: Consulta de solicitud iniciada Fuente: Elaboración propia ................................................................................... 170 Tabla 26: Caso de uso: Modificar solicitud iniciada Fuente: Elaboración propia ......................................................................................................... 171 Tabla 27: Caso de uso: Asignación de técnico Fuente: Elaboración propia ......................................................................................................... 172 Tabla 28: Caso de uso: Cancelar solicitudes Fuente: Elaboración propia .................................................................................................................... 173 Tabla 29: Caso de uso: Consulta de solicitud asignada ...................... 174 Tabla 30: Caso de uso: Modificar solicitud asignada ........................... 175 Tabla 31: Caso de uso: Finalizar solicitud asignada ............................ 176 Tabla 32: Caso de uso: Consulta de solicitud finalizada ..................... 177 Tabla 33: Caso de uso: Consulta de adeudos ...................................... 178 Tabla 34: Caso de uso: Captura de adeudos ....................................... 179 Tabla 35: Caso de uso: Reporte de estado de solicitud ...................... 180 Tabla 36: Caso de uso: Reporte de adeudos ....................................... 181 Tabla 37: Caso de uso: Reporte de cómputo ....................................... 182 Tabla 38: Caso de uso: Reporte centros por tipo de solicitud ............ 183 Tabla 39: Caso de uso: Reporte de técnicos por tipo de solicitud ..... 184 Tabla 40: Caso de uso: Reporte de opciones ....................................... 185
20
ÍNDICE DE FIGURAS ------------------------------------------------------------------------------------------------------- Figura 1: Modelos en Espiral .................................................................... 32 Figura 2: Evolución de los largos ciclos de desarrollo en cascada (a) a ciclos iterativos más cortos (b) y a la mezcla que hace XP .................. 34 Figura 3: Metodología XP – Iteración ....................................................... 35 Figura 4: Metodología XP – Desarrollo .................................................... 35 Figura 5: Arquitectura general del SASM ................................................ 36 Figura 6: Principales empresas proveedoras de mantenimiento y equipos de verificación en México............................................................ 41 Figura 7: Principales empresas proveedoras de mantenimiento y equipos de verificación por Nivel de Gobierno ....................................... 42 Figura 8 Principales Actores Fuente: Elaboración propia ..................... 43 Figura 9: Análisis FODA de las empresas proveedoras ........................ 51 Figura 10: Estructura organizacional típica y sus funciones ................. 52 Figura 11: Macroproceso de las empresas proveedoras ...................... 53 Figura 12: La Cadena de Valor Genérica ................................................ 54 Figura 13: Proceso Clave: SERVICIO, Fuente: Elaboración propia .... 55 Figura 14: Elementos organizacionales que integran el SASM ............ 56 Figura 15: Caso de uso general del SASM ............................................. 81 Figura 16: Caso de uso de acceso al sistema: Login ............................ 82 Figura 17: Caso de uso: Administrar catálogos ...................................... 82 Figura 18: Caso de uso: Crear solicitud de servicio o mantenimiento . 83 Figura 19: Caso de uso: Consultar solicitud ............................................ 84 Figura 20: Caso de uso: Captura de adeudos ........................................ 85 Figura 21: Caso de uso: Generar reportes .............................................. 86 Figura 22: Diagrama de componentes del SASM .................................. 90 Figura 23: Diagrama de secuencia: Acceso al sistema ......................... 91 Figura 24: Diagrama de secuencia: Expirar y reanudar sesión ............ 91 Figura 25: Diagrama de secuencia: Crear usuario ................................. 92 Figura 26: Diagrama de secuencia: Modificar usuario ........................... 92 Figura 27: Diagrama de secuencia: Habilitar/Inhabilitar usuario .......... 93 Figura 28: Diagrama de secuencia: Crear centro de servicio ............... 93 Figura 29: Diagrama de secuencia: Modificar centro de servicio ......... 94 Figura 30: Diagrama de secuencia: Habilitar/inhabilitar centro de servicio ......................................................................................................... 94 Figura 31: Diagrama de secuencia: Crear concepto de adeudo Fuente: Elaboración propia ..................................................................................... 95
21
Figura 32: Diagrama de secuencia: Modificar concepto de adeudo .... 95 Figura 33: Diagrama de secuencia: Crear solicitud ............................... 96 Figura 34: Diagrama de secuencia: Consultar solicitud ........................ 97 Figura 35: Diagrama de secuencia: Modificar solicitud iniciada ........... 98 Figura 36: Diagrama de secuencia: Asignación de técnico .................. 98 Figura 37: Diagrama de secuencia: Cancelar solicitud iniciada ........... 99 Figura 38: Diagrama de secuencia: Cancelar solicitud asignada ......... 99 Figura 39: Diagrama de secuencia: Modificar solicitud asignada ...... 100 Figura 40: Diagrama de secuencia: Finalizar solicitud asignada ........ 101 Figura 41: Diagrama de secuencia: Consulta de adeudo ................... 102 Figura 42: Diagrama de secuencia: Captura de adeudo ..................... 102 Figura 43: Diagrama de secuencia: Consulta y generación de reportes .................................................................................................................... 103 Figura 44: Diagrama de estado: Acceso al sistema ............................. 104 Figura 45: Diagrama de estado: Administración de usuario ............... 105 Figura 46: Diagrama de estado: Administración de centro de servicio .................................................................................................................... 105 Figura 47: Diagrama de estado: Administración de concepto de adeudo .................................................................................................................... 106 Figura 48: Diagrama de estado: Administrar solicitud ......................... 106 Figura 49: Diagrama de estado: Administración de adeudo Fuente: Elaboración propia ................................................................................... 107 Figura 50: Diagrama de estado: Consultar y generar reportes Fuente: Elaboración propia ................................................................................... 107 Figura 51: Diagrama de actividad: Acceso al sistema ......................... 108 Figura 52: Diagrama de actividad: Alta de usuarios ............................. 109 Figura 53: Diagrama de actividad: Modificar usuario Fuente: Elaboración propia ................................................................................... 110 Figura 54: Diagrama de actividad: Alta de centro de servicio ............. 110 Figura 55: Diagrama de actividad: Modificar centro de servicio ......... 111 Figura 56: Diagrama de actividad: Alta de concepto de adeudo ........ 112 Figura 57: Diagrama de actividad: Modificar concepto de adeudo .... 113 Figura 58: Diagrama de actividad: Alta de solicitud ............................. 114 Figura 59: Diagrama de actividad: Consulta de solicitud Fuente: Elaboración propia ................................................................................... 115 Figura 60: Diagrama de actividad: Modificar solicitud.......................... 115 Figura 61: Diagrama de actividad: Eliminar solicitud ........................... 116 Figura 62: Diagrama de actividad: Asignar solicitud ............................ 117
22
Figura 63: Diagrama de actividad: Finalizar solicitud ........................... 118 Figura 64: Diagrama de actividad: Consulta de adeudo ...................... 119 Figura 65: Diagrama de actividad: Captura de adeudo ....................... 119 Figura 66: Diagrama de clases Fuente: Elaboración propia ............... 120 Figura 67: Diagrama de despliegue del SASM ..................................... 121 Figura 68: Arquitectura de 3 capas del SASM ...................................... 124 Figura 69: Diagrama Entidad Relación .................................................. 129 Figura 70: Modelo de Datos Relacional ................................................. 130 Figura 71: GUI: Acceso al sistema ......................................................... 133 Figura 72: GUI: Menú principal del sistema .......................................... 134 Figura 73: GUI: Catálogo de usuarios ................................................... 135 Figura 74: GUI: Catálogo de centros de servicio .................................. 136 Figura 75: GUI: Catálogo de conceptos de adeudo ............................. 137 Figura 76: GUI: Nueva solicitud de mantenimiento .............................. 138 Figura 77: GUI: Nueva solicitud de servicio .......................................... 139 Figura 78: GUI: Consulta de solicitud iniciada ...................................... 140 Figura 79: GUI: Consulta de solicitud asignada ................................... 141 Figura 80: GUI: Finalizar solicitud de mantenimiento .......................... 142 Figura 81: GUI: Finalizar solicitud de servicio ....................................... 143 Figura 82: GUI: Consulta de solicitud finalizada ................................... 144 Figura 83: GUI: Consulta de adeudos ................................................... 145 Figura 84: GUI: Captura de adeudos ..................................................... 146 Figura 85: GUI: Reporte del estado de la solicitud Fuente: Elaboración propia ......................................................................................................... 147 Figura 86: GUI: Reporte de adeudos ..................................................... 147 Figura 87: GUI: Reporte de cómputo ..................................................... 148 Figura 88: GUI: Reporte de centros por tipo de solicitud ..................... 148 Figura 89: GUI: Reporte de técnicos por tipo de solicitud ................... 149 Figura 90: GUI: Reporte de opciones .................................................... 149
23
INTRODUCCIÓN Las empresas proveedoras de equipos de verificación vehicular son importantes para el
desarrollo económico de México, pues contribuyen de manera directa al correcto
funcionamiento de los verificentros e indirectamente en los factores de movilidad y la salud
de la población en el aspecto ambiental; los cuales son factores clave en el desarrollo del
país. El objetivo de esta investigación fue desarrollar una propuesta de un sistema para
ayudar a estas empresas a incrementar sus niveles de competitividad y productividad en el
proceso de entrega de servicio (mantenimiento y/o reparaciones) mediante la adición de
TIC a dicho proceso. La metodología utilizada para el desarrollo del sistema es la
metodología evolutiva en espiral.
El diseño del sistema contempla de forma automática tareas y actividades que ayudarán a
reducir errores propios tanto en la operación como la asignación errónea de ingenieros para
atender un servicio, así mismo con dicho sistema busca reducir tiempos de traslado y de
entrega del servicio, mejorar el control de los materiales utilizados, y dar seguimiento
oportuno al estatus de los reportes de servicio, llevando a los administradores del sistema
a una mejor toma de decisiones.
La propuesta del sistema toma en cuenta toma en cuenta la teoría administrativa, buenas
prácticas y metodologías de la ingeniería de software con el fin de que el producto esperado
sea funcional, útil y de calidad.
La presente investigación se agrupa en cuatro capítulos; Capítulo I. Antecedentes: con la
cual establecemos la visión general de la investigación Capítulo II: Antecedentes de la
industria de las empresas proveedoras de mantenimiento y equipos de verificación
vehicular, estableciendo un marco contextual, legal y TIC que se debe observar.
Posteriormente la propuesta del sistema, está formada por los capítulos III y IV donde se
hace un análisis del sistema propuesto, requerimientos funcionales y no funcionales y casos
de uso, finalmente se concluye con el diseño del sistema propuesto, diagramas de
componentes, de secuencia, de estado, de actividad y clases, representación de la
arquitectura del sistema, infraestructura y ambientes, modelo de datos, interfaces de
usuario, consultas y reportes.
24
1 CAPÍTULO I. ANTECEDENTES
En este capítulo se incluyen primeramente los antecedentes principales como son la
problemática, con su respectiva justificación y de allí se deriva el objetivo principal,
asimismo se describe la metodología para realizar el diseño de un Sistema de
Administración de los Servicios de Mantenimiento (SASM) de una Empresa de
Construcción de Equipos de Verificación Vehicular. Posteriormente se describen las
Tecnologías de Información y Comunicación (TIC) y su inclusión en las empresas en el
mantenimiento para analizar como incluirlas en la empresa caso de estudio. En
consecuencia, se plantean los objetivos de la inclusión de las TIC en la empresa citada, de
igual forma se presenta una vista general del sistema, así como sus riesgos y alcances; se
incluye también una descripción del sistema y los resultados al implementarse dicho
sistema.
1.1 Planeamiento del Problema Las Tecnologías de Información y Comunicación no han sido incluidas en varios procesos
fundamentales de la mayor parte de las pequeñas y medianas empresas (Abrego Almazán
et al., 2017; Antonz et al., 2015). Un ejemplo claro de esta problemática son las empresas
que brindan servicios a los consorcios de verificación vehicular en la Ciudad de México.
Derivado del hecho anterior se decidió realizar la investigación en una empresa dedicada
al mantenimiento de los sistemas de verificación vehicular, la empresa seleccionada como
objeto de estudio fue “Medios y Procedimientos Tecnológicos, S.A. de C.V.”
Como primer paso en esta investigación se hizo un sondeo de la empresa, durante dicho
sondeo se concluyó que la empresa no cuenta con un sistema apoyado en las TIC que
facilite la administración y/o gestión de los servicios de mantenimiento y reparaciones de
los verificentros. El hecho de que la empresa no cuente con tecnología para llevar a cabo
estos servicios genera otros problemas relacionados los cuales se enlistan a continuación.
• La mayoría de las solicitudes de los servicios es realizada vía telefónica, lo que
genera ineficiencia, lo cual es un factor que baja la satisfacción del cliente, puesto
que sería más rápido y eficiente si los clientes no tuvieran que depender de una
persona que conteste el teléfono y lo pudieran hacer a través de un sistema con una
interfaz web, a cualquier hora.
• Los reportes se capturan y generan manualmente lo cual genera “errores de dedo”.
• Los reportes tienen campos y datos incompletos.
25
• Los reportes no se generan en tiempos adecuados, pueden tardar horas o días.
• Los datos son vulnerables puesto que se almacenan manualmente en archivos de
hojas de cálculo como Excel y no se almacenan en bases de datos relacionales.
Actualmente la empresa para llevar a cabo el proceso de entrega del servicio de
mantenimiento involucra diversas acciones realizadas tanto por diferentes áreas dentro de
la empresa, así como también por parte de los clientes. A continuación, se hace una breve
explicación del proceso de alta del servicio de mantenimiento.
Las solicitudes de servicios son originadas los clientes vía telefónica, con lo cual se da inicio
al proceso; tales solicitudes son susceptibles de ser modificadas o incluso canceladas. Los
reportes de solicitudes son capturados en una hoja de cálculo y deben ser llenados ciertos
campos importantes. Durante todo el proceso se debe llevar un control adecuado en cuanto
a la asignación de recursos para atender solicitudes, además de dar puntual seguimiento a
las que están abiertas para brindar una mejor atención a los clientes.
Derivado de las afirmaciones anteriores, se justifica la propuesta para crear diseño de un
sistema para el proceso de entrega y mantenimiento de la empresa “Medios y
Procedimientos Tecnológicos, S.A. de C.V.” pero para poder llevar a cabo el sistema, este
debe de cumplir una serie de requerimientos y estar dirigido hacia el cumplimiento de
algunos objetivos particulares acorde a las necesidades tanto del proceso como de la
empresa.
1.2 Justificación El mantenimiento es una de las actividades más importantes dentro de la ingeniería, por
ello debe ser ejecutada con mucha eficacia desde el punto inicial hasta el final, entre más
tecnología ocupe el proceso de manteamiento más se incrementa el rendimiento y control
de dicha actividad (Díaz Estipiñan & Vargas Vargas, 2015; Suárez Fragas, Medina Peña,
& Hernández Alfonso, 2015). Varias empresas han optado por generar sistemas para
ejecutar, documentar y controlar de manera eficiente los procesos de mantenimiento de sus
equipos lo cual ha generado un mayor grado de satisfacción por parte de los demandantes
de los servicios de mantenimiento.
Existe evidencia de que los sistemas de información como complementos a los procesos
de gestión administrativa tienen un impacto positivo en el rendimiento de la empresa. Por
ello se considera que la propuesta de crear un sistema de para la administración de
servicios de mantenimiento de la empresa objeto de estudio, es de gran importancia, debido
a que con ello se mejorará acorde a la evidencia científica la competitividad de la empresa,
26
al mismo tiempo que se da solución a los problemas relacionados, se considera que el
sistema apoyará a la empresa a:
• Aumentar la competitividad.
• Agilizar la gestión de los servicios de mantenimiento.
• Mejorar el servicio a sus clientes.
Se contempla acorde con la teoría que las implicaciones o consecuencias negativas que
habría para la organización en caso de no resolverlo, son principalmente las siguientes:
• Reducción de ventas.
• Fracaso operativo.
• Tiempos grandes de entrega del servicio.
• La empresa al no ser eficiente, obliga a sus clientes a buscar otras opciones de
servicio, lo que da paso a otros competidores.
• La potencial pérdida de la autorización para operar como proveedor del servicio, lo
que daña la misión y reputación de este tipo de empresas especializadas y llevaría
a la muerte a la organización.
1.3 Objetivo Esta investigación se llevó a cabo con el objetivo principal de proponer el “Diseño de un
Sistema de Administración de los Servicios de Mantenimiento (SASM) de una Empresa de
Construcción de Equipos de Verificación Vehicular”, para incrementar sus niveles de
competitividad y productividad mediante la adición de Tecnologías de la Información y
Comunicación (TIC), tomando como base un caso de estudio para conocer de forma
general cómo operan este tipo de empresas.
1.4 Objetivos específicos Buscar sistemas de mantenimiento de empresas de servicio de verificación vehicular
Analizar requerimientos para el sistema
Diseñar sistema mediante casos de uso
Diseñar pantallas que cumplan con los requerimientos planteados
1.4.1 Hipótesis El diseño de un Sistema de Administración de los Servicios de Mantenimiento (SASM) de
una Empresa de Construcción de Equipos de Verificación Vehicular, incrementa sus niveles
de competitividad y productividad mediante la adición de Tecnologías de la Información y
Comunicación (TIC).
27
1.5 Metodología Para poder llevar a cabo la presente investigación se llevó a cabo el sondeo del
funcionamiento de varias empresas del giro de verificación en específico de la empresa
“Medios y Procedimientos Tecnológicos, S.A. de C.V” la cual funge como objeto de estudio
de la presente investigación. De dicho sondeo se obtuvo la descripción del proceso de
entrega de servicio de mantenimiento, con lo cual a través de un análisis FODA se
determinaron las actividades principales en las cuales se centrará el sistema, la actividad
principal es: “Entrega de los Servicios de Mantenimiento”. El sistema utiliza la metodología
espiral para su funcionamiento.
1.6 Las TIC y su inclusión en las empresas Las TIC existen hace más de tres décadas y la adopción de ellas por parte de las empresas
ha sido progresiva desde 1990, año en el cual las empresas catalogadas como AAA,
hicieron las primeras inversiones en el área TIC, principalmente en herramientas de soporte
a las funciones administrativas, obteniendo grades beneficios como la reducción de los
costes y la simplificación de tareas, al ver estos beneficios la adopción de las TIC se
extendió también a las pequeñas y medianas empresas, sin embargo, la absorción de las
TIC por parte de las empresas más pequeñas no ha sido uniforme, a pesar de esto los
beneficios de las TIC son visibles en todas las áreas de las empresas que las implementan
(Antonz, Pozo Rodríguez, & Cancio, 2015).
Desde de la inclusión de las TIC en el sector empresarial de las pequeñas y medianas
empresas, se han generado diversas investigaciones para constatar y destacar los
beneficios que estas aportan a los gerentes de las empresas y a los clientes de estas.
Algunas investigaciones demuestran que desde la integración de las TIC al el entorno
empresarial, las inversiones en TIC se han vuelto muy relevantes ya que estas son un factor
elemental para la supervivencia de las empresas en el mercado, puesto que brindan a las
organizaciones y a los clientes, activos intangibles como la experiencia o la capacidad para
innovar, lo cual puede dar lugar a ventajas competitivas (Sánchez, Monelos, & López,
2016). Derivado de este hecho las TIC se han convertido en un factor importante para
determinar la eficiencia y competitividad empresarial puesto que un mayor grado de
aprovechamiento de las TIC permite determinar si una empresa puede ser más competitiva
(Ibarra Cisneros, González Torres, & Cervantes Collado, 2016).
Existe evidencia de como la inclusión de las TIC ha apoyado a las pequeñas y medianas
empresas de diferentes giros a mejorar su competitividad a través del uso de sistemas de
28
información. Los sistemas de información permiten generar valor agregado a la
organización y a las relaciones con los clientes permitiendo en muchos casos desarrollar
nuevas oportunidades de mercado, basadas en la confiabilidad y seguridad de los servicios
que otorgan los sistemas de información (Ramírez & De la Vega Tomé, 2015).
Asimismo, los sistemas de información como su nombre lo indica permiten obtener
información de manera efectiva para llevar a cabo diferentes procesos empresariales. La
información juega un papel muy importante en el mundo de las empresas, y la
administración, puesto que el control eficaz de esta información es elemento primordial, es
por ello que las TIC se consideran esenciales en la administración y control de estos datos,
y tratan de llevar un buen control de esta información a través de herramientas como
sistemas y bases de datos que en su conjunto cumplen un fin predeterminado (Ramírez &
De la Vega Tomé, 2015). Investigaciones afirman que los resultados obtenidos por la
inclusión de las TIC en forma de sistemas de información favorecen sus resultados
organizacionales, puesto que los usuarios de dichos sistemas de se ven motivados al uso
de estos, mejorando la calidad en los servicios ofertados, contribuyendo al rendimiento
organizacional (Abrego Almazán et al., 2017).
Sin embargo, a pesar de los beneficios que las TIC en forma de sistemas de información
aportan tanto a la organización como a los servicios que la organización oferta, las TIC no
han sido incluidas en varios procesos fundamentales de la mayor parte de las pequeñas y
medianas empresas (Abrego Almazán et al., 2017; Antonz et al., 2015).
1.7 Importancia de la inclusión de las TIC en el mantenimiento El mantenimiento es una de las actividades más importantes dentro de la ingeniería, por
ello debe ser ejecutada con mucha eficacia desde el punto inicial hasta el final, entre más
tecnología ocupe el proceso de manteamiento más se incrementa el rendimiento y control
de dicha actividad (Díaz Estipiñan & Vargas Vargas, 2015; Suárez Fragas, Medina Peña,
& Hernández Alfonso, 2015). Varias empresas han optado por generar sistemas para
ejecutar, documentar y controlar de manera eficiente los procesos de mantenimiento de sus
equipos lo cual ha generado un mayor grado de satisfacción por parte de los demandantes
de los servicios de mantenimiento.
Existe evidencia de que los sistemas de información como complementos a los procesos
de gestión administrativa tienen un impacto positivo en el rendimiento de la empresa. Por
ello se considera que la propuesta de crear un sistema de para la administración de
servicios de mantenimiento de la empresa objeto de estudio, es de gran importancia, debido
29
a que con ello se mejorará acorde a la evidencia científica la competitividad de la empresa,
al mismo tiempo que se da solución a los problemas relacionados, se considera que sistema
apoyará a la empresa a:
• Aumentar la competitividad.
• Agilizar la gestión de los servicios de mantenimiento.
• Mejorar el servicio a sus clientes.
Se contempla acorde con la teoría que las implicaciones o consecuencias negativas que
habría para la organización en caso de no resolverlo, son principalmente las siguientes:
• Reducción de ventas.
• Fracaso operativo.
• Tiempos grandes de entrega del servicio.
• La empresa al no ser eficiente, obliga a sus clientes a buscar otras opciones de
servicio, lo que da paso a otros competidores.
• La potencial pérdida de la autorización para operar como proveedor del servicio, lo
que daña la misión y reputación de este tipo de empresas especializadas y llevaría
a la muerte a la organización.
Actualmente la empresa para llevar a cabo el proceso de entrega del servicio de
mantenimiento involucra diversas acciones realizadas tanto por diferentes áreas dentro de
la empresa, así como también por parte de los clientes. A continuación, se hace una breve
explicación del proceso de alta del servicio de mantenimiento.
Las solicitudes de servicios son originadas los clientes vía telefónica, con lo cual se da inicio
al proceso; tales solicitudes son susceptibles de ser modificadas o incluso canceladas. Los
reportes de solicitudes son capturados en una hoja de cálculo y deben ser llenados ciertos
campos importantes. Durante todo el proceso se debe llevar un control adecuado en cuanto
a la asignación de recursos para atender solicitudes, además de dar puntual seguimiento a
las que están abiertas para brindar una mejor atención a los clientes.
El llevar a cabo la captura de las solicitudes de forma manual tiene varias implicaciones
negativas para la empresa, puesto que llevar a cabo el levantamiento de pedidos es un
proceso en el que cometer un error puede ser fácil, sobre todo si se realiza de forma manual,
estos fallos en la preparación de pedidos afectan directamente a los niveles de calidad del
servicio al cliente y pueden llegar a dañar los objetivos de rentabilidad de una organización,
30
ya que se hace necesario duplicar operaciones y gestiones administrativas para corregirlos
(Neteris, 2017).
Una forma de solucionar éstos problemas es a través de la implementación de sistemas
informáticos. Las TIC en los proceso de levantamiento de pedidos simplifican las
operaciones, reducen los costos por errores y mejoran los flujos de información (Correa
Espinal, Gómez Montoya, & Cano Arenas, 2010). En países de Sudamérica se ha
demostrado que la incorporación de sistemas a los procesos de levantamiento y
seguimiento de pedidos de cualquier tipo (Mendoza, 2017).
Derivado de las afirmaciones anteriores, se justifica la creación de un sistema para el
proceso de entrega y mantenimiento de la empresa “Medios y Procedimientos
Tecnológicos, S.A. de C.V.” pero para poder llevar a cabo el sistema este debe de cumplir
una serie de requerimientos y estar dirigido hacia el cumplimiento de algunos objetivos
particulares acorde a las necesidades tanto del proceso como de la empresa, dichos
objetivos están plasmados en la siguiente sección.
1.8 Objetivos de la inclusión de las TIC en la empresa “Medios y Procedimientos Tecnológicos, S.A. de C.V.”
Hablando en específico de la empresa objeto de estudio se considera que la propuesta del
sistema a desarrollar debe tener la capacidad de personalizar mediante roles y perfiles las
actividades que pueden realizar los usuarios tanto internos como externos dentro del
sistema.
En cuanto a los requerimientos se requiere que en el sistema se incluya el área contable
para el cobro de adeudos por servicios, con la finalidad de agilizar el proceso de
comunicación entre áreas al avanzar en las diferentes etapas del proceso. Así mismo que
los involucrados requieren de consultar el estatus de las solicitudes en las diferentes etapas
o verificar que actividades les han sido asignadas. También es de vital importancia que se
puedan cuantificar los servicios otorgados, generar reportes y estadísticas para conocer el
desempeño de los técnicos, identificar los servicios más comunes o de mayor demanda,
facilitar la exportación de datos para su análisis, todo esto con la finalidad de mejorar el
proceso, y facilitar la toma de decisiones y ofrecer un mejor servicio para poder ser
competitivos en el mercado.
Derivado del hecho anterior se formuló el objetivo general de esta investigación el cual es
proponer el diseño de un sistema que permita facilitar la gestión de los servicios de
mantenimiento de la empresa denominada “Medios y Procedimientos Tecnológicos, S.A.
31
de C.V.”, la cual es proveedora de equipos de verificación vehicular, esta gestión
comprende desde su solicitud por los clientes, hasta su conclusión por parte de la empresa,
conociendo en todo momento su estatus, técnico asignado, materiales empleados y la
generación de reportes.
Los principales objetivos específicos del sistema propuesto, son los siguientes:
• Realizar el análisis y diseño del sistema de tipo web.
• Utilizar modelado UML.
• Diseñar casos de uso.
• Diseñar la arquitectura general del sistema propuesto.
• Diseñar la arquitectura de almacenamiento de datos, para que estén centralizados,
actualizados, íntegros y disponibles.
• Diseño de reportes relacionados al servicio.
• Que el sistema propuesto sirva para agilizar la entrega y calidad de los servicios de
mantenimiento al cliente.
• Extender la capacidad de atención a más centros de verificación clientes.
• Innovación tecnológica al dotar a los ingenieros del servicio con un sistema
automatizado que sirva como herramienta facilitar el desarrollo de sus actividades
diarias.
• Que el sistema propuesto no solo sea útil para la empresa caso de estudio, sino
también para todas las demás empresas del ramo.
• Que el sistema propuesto sirva como base de una nueva y potencial herramienta de
vigilancia y control por parte de las Secretarías de Medio Ambiente de los Estados,
para el seguimiento de las actividades de las empresas proveedoras, ya que
actualmente solo tienen sistemas similares para el monitoreo de los centros de
verificación y no para los proveedores.
Si bien se espera que el sistema provea de ventaja competitiva a la empresa “Medios y
Procedimientos Tecnológicos, S.A. de C.V.”, esta investigación solo contempla el
diseño del sistema, cualquier alteración al mismos, y evaluación del sistema son objetos
de futuras investigaciones.
1.9 Metodología para la inclusión de las TIC en la empresa “Medios y Procedimientos Tecnológicos, S.A. de C.V.”
Como método para poder cumplir los requerimientos descritos con anterioridad se hizo un
análisis de las metodologías de desarrollo de software y se eligieron algunas metodologías
32
eficaces para el diseño del sistema, entre las cuales figuran; modelo evolutivo en espiral y
el Xtreme Programming, para finalmente crear la arquitectura del proyecto. A continuación,
se hace una recopilación y descripción de las metodologías utilizadas y se finaliza con la
arquitectura previamente mencionada.
Para comenzar con los trabajos de diseño se llevó a cabo un Modelo de Desarrollo
Software, el cual es una representación abstracta del desarrollo de software (Sommerville,
2005). Existen una gran variedad de modelos de desarrollo de software, como pueden ser,
entre otros: modelo de cascada, modelo evolutivo y modelo de componentes reutilizables;
que no se excluyen mutuamente y a menudo se utilizan en conjunto (Cervantes Ojeda &
Gómez Fuentes, 2012).
Para la implementación del sistema propuesto se recomienda el modelo evolutivo en
espiral. Este modelo se basa en la idea de desarrollar una implementación inicial,
exponiéndola a los comentarios del usuario y refinándola a través de las diferentes
versiones hasta que se desarrolla un sistema adecuado (Joskowicz, 2008).
Durante las primeras iteraciones, la versión podría ser un modelo en papel o un prototipo.
Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema
diseñado. Este modelo enfatiza ciclos de trabajo de Análisis, Diseño, Implementación y
Pruebas, cada uno de los cuales estudia el riesgo antes de proceder al siguiente ciclo
(Weitzenfeld Ridel & Guardati Buemo, 2007).
Figura 1: Modelos en Espiral Fuente: (Weitzenfeld, 2007)
33
Así mismo para tener un mejor diseño de software se contempla el Xtreme Programming
(XP). Está es una metodología ágil, aplicada a proyectos de calidad a corto plazo, orientada
a la obtención de resultados, en donde el usuario aprueba el producto (Beck, 2000).
La filosofía de XP integra al cliente como parte del equipo de desarrollo, promueve el trabajo
en equipo, un grupo de programadores pequeño y se adecúa a proyectos con requisitos
imprecisos, cambiantes y con alto riesgo técnico; XP, tiene como valores la comunicación
cara a cara, la simplicidad, retroalimentación cliente-desarrollador, valentía para ir a la par
del cambio y respeto por el equipo de desarrollo al no tomar decisiones repentinas (Beck,
2000; Joskowicz, 2008)
Los roles de XP, de acuerdo con la propuesta original de Beck, 2000, son:
• Programador, que produce el código y describe las pruebas
• Cliente, que escribe las historias de usuario y realiza las pruebas de funcionalidad
para validar la implementación
• Encargado de pruebas (Tester), que ayuda al cliente a escribir las pruebas
funcionales y las ejecuta regularmente y difunde los resultados,
• Encargado de seguimiento (Tracker), retroalimenta al equipo en el proceso XP,
verifica los tiempos estimados contra el real dedicado y determina si es necesario
realizar cambios.
• Entrenador (Coach), es responsable del proceso global y sus prácticas.
• Consultor, es un miembro externo del equipo con conocimiento para resolver un
problema específico en algún tema necesario para el proyecto.
• Gestor (Big boss), es el vínculo entre clientes y programadores, coordina que el
equipo trabaje efectivamente, creando las condiciones adecuadas.
La metodología XP también define cuatro variables para cualquier proyecto de software:
costo, tiempo, calidad y alcance. De estas cuatro variables, sólo tres de ellas podrán ser
fijadas arbitrariamente por actores externos al grupo de desarrolladores (clientes y jefes de
proyecto). El valor de la variable restante podrá ser establecido por el equipo de desarrollo,
en función de los valores de las otras tres. Este mecanismo indica que, por ejemplo, si el
cliente establece el alcance y la calidad, y el jefe de proyecto el precio, el grupo de desarrollo
tendrá libertad para determinar el tiempo que durará el proyecto (Beck, 2000; Patricio
Letelier, 2012).
34
Se trata de realizar ciclos de desarrollo cortos o iteraciones (típicamente lleva de 10 a 15),
con entregables funcionales al finalizar cada ciclo. En cada iteración se realiza un ciclo
completo de análisis, diseño, desarrollo y pruebas, pero utilizando el conjunto de reglas y
prácticas que caracterizan a XP (Patricio Letelier, 2012).
La siguiente figura esquematiza los ciclos de desarrollo en cascada e iterativos tradicionales
(por ejemplo, incremental o espiral), comparados con el de XP.
Figura 2: Evolución de los largos ciclos de desarrollo en cascada (a) a ciclos iterativos más cortos (b) y a la mezcla que hace XP Fuente: Tomado de Reglas y Prácticas en eXtreme Programming de Ing. José Joskowicz (2008) El proceso XP de desarrollo, consiste a grandes rasgos en los siguientes pasos:
• El cliente define el valor de negocio a implementar.
• El programador estima el esfuerzo necesario para su implementación.
• El cliente selecciona qué construir, de acuerdo con sus prioridades y las
restricciones de tiempo.
• El programador construye ese valor de negocio.
• Volver al paso 1 (Joskowicz, 2008).
El ciclo de vida XP, es muy dinámico y se puede separar en las siguientes Fases:
• Fase I de Exploración:
• Fase II de Planificación de la Entrega
• Fase III de Iteraciones
• Fase IV de Producción:
• Fase V de Mantenimiento:
• Fase VI de Muerte del Proyecto (Joskowicz, 2008).
35
Figura 3: Metodología XP – Iteración Fuente: Tomado de Reglas y Prácticas en eXtreme Programming de Ing. José Joskowicz (2008)
La parte de desarrollo de este método es de vital importancia puesto que involucra varios
procesos infalibles para el diseño del sistema, la parte de desarrollo contempla seis
actividades las cuales se ilustran gráficamente en la Figura 4.
Figura 4: Metodología XP – Desarrollo Fuente: Tomado de Reglas y Prácticas en eXtreme Programming de Ing. José Joskowicz (2008)
Siguiendo de forma estructurada las metodologías enlistadas con anterioridad la
arquitectura del Sistema propuesto titulado, Sistema de Administración de los Servicios de
Mantenimiento (SASM) toma la siguiente forma.
1.10 Vista General del Sistema SASM en una arquitectura distribuida de 3 capas La figura 5 proporciona una vista general del sistema SASM, mediante un diagrama de
componentes que muestra cómo se compone el sistema SASM a alto nivel, en una
arquitectura distribuida de 3 capas (de presentación, de aplicación y de almacenamiento de
datos).
36
Los detalles de implementación de cada capa los veremos en el capítulo de diseño.
Figura 5: Arquitectura general del SASM
Fuente: Elaboración propia
Se describen de forma general, los requisitos que tienen un impacto significativo en la
arquitectura del sistema en línea SASM:
• Plataforma Técnica:
Se desplegará en un servidor de aplicaciones Glassfish versión 3.1, ya que cumple
las especificaciones de J2EE.
• Transacción:
El sistema es transaccional con diferentes opciones de consulta, aprovechando las
capacidades de la plataforma técnica.
• Seguridad
Cada usuario debe ingresar sólo a las secciones que le corresponden, y el sistema
debe implementar comportamientos básicos de seguridad.
Autenticación, iniciar sesión utilizando un nombre de usuario y contraseña.
Autorización, según el perfil de usuario, para tener o no la posibilidad de realizar
algunas acciones específicas (cliente. administrador, técnico o contador).
Integridad de los datos, los datos deben garantizar su integridad en las diferentes
etapas del proceso.
37
Auditoria, cada acción sensible puede ser registrada. El modelo de seguridad de
Spring Security será utilizado.
• Persistencia
Se tratará utilizando una base de datos relacional. Como framework se usará la Java
Persistence API mejor conocida por sus siglas en inglés JPA 2.0.
• Fiabilidad/Disponibilidad (failover)
La disponibilidad del sistema es un requisito clave por naturaleza, ya que se trata
de un sistema interno y de atención al cliente. La arquitectura candidata debe
garantizar la capacidad de conmutación por error. Fiabilidad/Disponibilidad se
abordará a través de la plataforma J2EE. Disponibilidad específica es de 24/7: 24
horas al día, 7 días a la semana.
• Rendimiento
El proceso de consulta o captura de datos debe ser inferior a 10 segundos.
1.11 Asunciones, riesgos y alcances del Sistema SASM Las asunciones son las siguientes:
• La comunicación entre los involucrados se realizará cuando sea necesaria
existiendo disponibilidad de ambas partes.
• El cliente cuenta con los elementos tecnológicos de software y de hardware (intranet
y servidor) para implementar la solución tecnológica.
• el cliente cuenta con personal capacitado para administrar la aplicación
desarrollada.
Los riesgos que podemos encontrar son los siguientes:
• Cambio en los requerimientos definidos por el usuario.
• La organización no disponga de la tecnología suficiente para implementar esta
solución.
• No exista personal especializado para administrar la aplicación.
• No contar con la infraestructura de hardware para desplegar la aplicación.
Los alcances que se determinaron son los siguientes:
• Solo los requerimientos mostrados en el capítulo de análisis y casos descritos en el
capítulo de diseño del sistema.
• Los cambios serán analizados para validar su impacto en el proyecto.
38
• El proyecto no incluye la instalación del sistema, configuración de infraestructura y
la transferencia de conocimiento, sin embargo, se podrá ofrecer una guía rápida de
instalación del sistema en los anexos del presente.
• El mantenimiento del proyecto no está contemplado como parte de este proyecto
1.12 Descripción del sistema: Sistema de Administración de los Servicios de Mantenimiento (SASM)
El sistema debe facilitar la administración de los servicios de mantenimiento desde la
creación de una solicitud del cliente, el otorgamiento, seguimiento a servicios, y adeudos,
bitácoras de control de servicios, generación de reportes, administración de catálogos como
pueden ser clientes, usuarios, servicios, tipos de servicios, cierre de solicitudes, además
del contar con un historial de servicios y clientes.
El Sistema de Administración de los Servicios de Mantenimiento (SASM) debe ser una
aplicación web que permitirá agilizar y gestionar de forma eficiente el proceso de servicios
de mantenimiento otorgados a centros de servicio, específicamente se requiere el alta de
solicitudes de servicio, gestión de las solicitudes y módulo de reporteo, visualización de
datos, actualización y modificación de catálogos, involucrar a las áreas de la empresa.
El sistema permitirá la captura de datos, consultarlos y modificarlos, existen diferentes
perfiles de acceso y un control para la administración del sistema (roles y perfiles).
El usuario se identificará en el sistema a través de la pantalla de Ingreso, se verifican y
validan sus datos (usuario y contraseña).
El sistema le presentará la página al usuario con las opciones correspondientes según su
rol asignado. Se permiten: alta, modificación, consulta, búsqueda y baja de solicitudes.
El administrador del sistema puede agregar nuevos usuarios o modificar el rol asignado,
así como modificar catálogos de servicios.
La información se almacenará en una base de datos.
Se muestra la información pertinente para que los usuarios puedan visualizar los datos de
manera ágil mediante el establecimiento de filtros de consulta.
1.13 Resultados esperados a la implementación del SASM Los principales resultados esperados son los siguientes:
• Mayor aprovechamiento del tiempo u horas/hombre de los ingenieros de entrega del
servicio.
39
• Reducción de tiempos perdidos por traslados, ya que el sistema facilitará la
asignación de las solicitudes vía web al ingeniero de servicio desde cualquier lugar
en que se encuentre.
• Prestar un número mayor de servicios.
• Optimización del servicio, ya que el sistema permitirá balancear las cargas de
trabajo.
• El sistema facilitará la asignación de solicitudes por centros de servicio y por
Ingenieros de Servicio.
• Generar reportes de productividad individual y grupal sobre periodos de tiempo
seleccionados, por Verificentro y/o técnicos asignados.
• Generar reportes de solicitudes cerradas satisfactoriamente y las que quedan
inconclusas por día o por algún periodo de tiempo seleccionado.
• Generación de reportes electrónicos para entrega mensual a las autoridades
ambientales correspondientes.
• Por lo anterior, las empresas proveedoras de equipos de verificación vehicular
requieren que el sistema propuesto cubra los requerimientos solicitados.
• Permite conocer la situación actual de la solicitud de servicio.
• Facilita la organización y consulta de servicios actuales e históricos.
• Alinea la consecución de objetivos que surgen del proceso de servicio, mediante el
seguimiento de las etapas del proceso.
• Agiliza la asignación de recursos e involucra las diferentes áreas de la empresa.
• .
40
2 CAPÍTULO II. ANTECEDENTES: LA INDUSTRIA DE LAS EMPRESAS PROVEEDORAS DE MANTENIMIENTO Y EQUIPOS DE VERIFICACIÓN VEHICULAR
El presente capítulo muestra el panorama general de las empresas proveedoras de mantenimiento y equipos de verificación vehicular en México, así mismo se presenta el marco: contextual, legal y el marco general TIC, que deben ser aplicados por este tipo organizaciones. Esto a fin de buscar una relación con lo planteado en el capítulo 1 y poder realizar un buen diseño del sistema. 2.1 Situación actual en México, principales empresas y por nivel de gobierno,
actores de la industria y sus relaciones Las empresas proveedoras de equipos de verificación vehicular y mantenimiento, tienen
como actividades las siguientes:
• Construcción de dichos equipos
• Instalación
• Configuración
• Reparación y mantenimiento
• Venta y comercialización de equipos de verificación completos y de sus partes
(componentes internos hardware y software)
Lo anterior se realiza para los verificentros existentes en los diferentes estados de la
república mexicana, incluyendo a la Ciudad de México, en donde se cuente con un
programa de verificación vehicular obligatorio.
Para operar, las empresas proveedoras están sujetas a una autorización anual otorgada
por cada entidad de la República Mexicana basada en su capacidad financiera, técnica y
operativa para la prestación del servicio (SEDEMA, 2017).
2.1.1 Principales empresas en el país Se tienen identificadas en México a las empresas que se muestran en la Figura 6, como las
principales y con mayor actividad en el país en cuanto a servicios de mantenimiento de
equipo de verificación vehicular.
41
Figura 6: Principales empresas proveedoras de mantenimiento y equipos de verificación en México Fuente: Elaboración propia
42
2.1.2 Principales empresas por nivel de gobierno: Federal, Estatal y CDMX Cada nivel de gobierno cuenta con un catálogo de empresas proveedoras autorizadas, es
decir, dichos proveedores pueden diferir de un Estado a otro (EMA, 2017).
En la Figura 7, se muestran a las principales empresas por niveles de gobierno.
Figura 7: Principales empresas proveedoras de mantenimiento y equipos de verificación por Nivel de Gobierno Fuente: Elaboración propia
43
2.1.3 Actores de la industria y sus relaciones Los principales actores de la industria son:
• Gobierno
• Proveedores de equipos de verificación vehicular
• Verificentros
• Sociedad
Y tienen relaciones directas con las Normas Oficiales Mexicanas (NOMs) porque:
• El gobierno las genera por medio de la Dirección General de Normas de la
Secretaría de Economía.
• Los proveedores desarrollan tecnología en base a NOMs.
• Los verificentros implementan las NOMs vía equipos del proveedor ya que sólo son
operarios.
• La sociedad observa las NOMs vía uso del servicio de los verificentros.
En la Figura 8 se muestran a los principales actores de la industria y sus relaciones, de lo
descrito anteriormente.
Figura 8 Principales Actores Fuente: Elaboración propia Las Autorizaciones Gubernamentales para operar, son documentos que acreditan que los
verificentros y las empresas proveedoras de sus equipos tienen la capacidad técnica,
44
operativa y económica para desempeñar sus funciones y que cumplieron con los requisitos
determinados por el gobierno para tal efecto:
• El gobierno las emite a nivel federal y estatal.
• Los proveedores operan en base a su autorización.
• Los verificentros operan en base a su autorización.
• Para este caso la sociedad no tiene una autorización, pero los ciudadanos tienen la
obligación de leer y observar el programa de verificación vehicular obligatorio
vigente en su entidad (SEDEMA, 2017).
2.2 Marco legal (Principales órganos reguladores, legislación y normas ambientales).
Las empresas proveedoras son reguladas a través de leyes ambientales y normas
específicas para este tipo de industria y vigiladas por instituciones gubernamentales
dedicadas a la preservación del medio ambiente.
Entre los siguientes órganos se dan reuniones de trabajo en conjunto con fines ambientales
y de ellas emanan la legislación y normas ambientales obligatorias.
2.2.1 Secretaría de Medio Ambiente y Recursos Naturales (SEMARNAT) Es la secretaría de estado del poder ejecutivo federal de México encargada de todo lo
relacionado a la protección, conservación y aprovechamiento de los recursos naturales del
país y de la conformación de la política ambiental nacional para el desarrollo sustentable
(SEMARNAT, Poder Ejecutivo Federal, 2000).
2.2.2 Comisión Ambiental de la Megalópolis (CAMe) Esta comisión está formada por seis estados de la república mexicana que tienen
programas ambientales coordinados y homologados entre sí (CAMe, 2013), la integran las
siguientes secretarías:
• Secretaría del Medio Ambiente del Gobierno de la CDMX
• Secretaria del Medio Ambiente del Gobierno del Edo. México.
• SEMARNAT del Gobierno del Estado de Hidalgo
• Secretaría de Desarrollo Sustentable del Gobierno de Morelos
• Secretaría de Desarrollo Rural, Sustentabilidad y Ordenamiento Territorial del
Gobierno del Estado de Puebla
• Coordinación General de Ecología del Estado de Tlaxcala
45
2.2.3 Centro de Investigación: Centro Mario Molina para Estudios Estratégicos sobre Energía y Medio Ambiente, A.C.
Es una asociación civil, independiente y sin fines de lucro (Centro Mario Molina para
Estudios Estratégicos sobre Energía y Medio Ambiente, 2004), que tiene los siguientes
propósitos:
• Encontrar soluciones prácticas, realistas y de fondo a los problemas relacionados
con la protección del medio ambiente y desarrollo sustentable.
• Generar conocimiento científico a través de la investigación y lo vincula con las
políticas ambientales y energéticas.
• Generar consensos entre los diferentes sectores de la sociedad en México.
2.2.4 Centro de Investigación: Instituto Nacional de Ecología y Cambio Climático Es un órgano desconcentrado de la SEMARNAT (Instituto Nacional de Ecología y Cambio
Climático, 1991), que tiene como misión:
• Generar, integrar y difundir conocimiento e información a través de investigación
científica aplicada y el fortalecimiento de capacidades, para apoyar la formulación
de política ambiental y la toma de decisiones que promuevan el desarrollo
sustentable.
2.2.5 Dirección General de Normas (DGN) de la Secretaría de Economía (SE) La Dirección General de Normas, es una Unidad Administrativa dependiente de la
Subsecretaria de Competitividad y Normatividad de la Secretaría de Economía de México
(Dirección General de Normas, Subsecretaría de Competitividad y Normatividad, Secretaría
de Economía, 2006-2012), que:
• Ejerce las atribuciones conferidas en la Ley Federal sobre Metrología y
Normalización, la Ley Federal de Protección al Consumidor, la Ley de
Hidrocarburos, Ley Federal de Telecomunicaciones y Radiodifusión, los
reglamentos y demás disposiciones aplicables en materia de normalización,
metrología y evaluación de la conformidad, así como los acuerdos y tratados
internacionales en esa materia.
• Establece a través de las Normas Oficiales Mexicanas (NOMs) de aplicación
obligatoria, los estándares mínimos de calidad de los productos y servicios, que se
ofrecen a la sociedad.
• En México, las Normas Oficiales Mexicanas (NOMs) son de carácter obligatorio, y
son elaboradas por las Dependencias del Gobierno Federal según sus atribuciones
46
a través de los Comités Consultivos Nacionales de Normalización; siendo estas de
carácter público.
• Para dar máxima eficacia en materia de normalización, la Secretaría de Economía
participa en foros y organismos internacionales como son Codex Alimentarius,
Comisión Panamericana de Normas Técnicas (COPANT), Comisión Electrotécnica
Internacional (IEC)y la Organización Internacional de Normalización (ISO).
• La Dirección General de Normas es responsable de coordinar el sistema de
normalización y evaluación de la conformidad, con base en lo dispuesto en Ley
Federal sobre Metrología y Normalización y su Reglamento, para fomentar la
competitividad de la industria y el comercio en el ámbito nacional e internacional.
2.3 Legislación y normas ambientales Aquí se presentan las principales leyes de protección ambiental y que se relacionan con las
normas oficiales mexicanas que dictan las especificaciones que deben cumplir los equipos
de verificación vehicular, y que son de carácter obligatorio.
2.3.1 Ley General del Equilibrio Ecológico y Protección al Ambiente La Federación, los Estados, el Distrito Federal y los Municipios ejercerán sus atribuciones
en materia de preservación y restauración del equilibrio ecológico y la protección al
ambiente, de conformidad con la distribución de competencias prevista en esta Ley y en
otros ordenamientos legales, (PROFEPA, Ley General del Equilibrio Ecológico y Protección
al Ambiente, 2015).
Código para la Biodiversidad del Estado de México
Establece políticas, criterios, recomendaciones, mecanismos, lineamientos ecológicos,
estrategias ecológicas e instrumentos de coordinación y concertación con personas,
organizaciones e instituciones de los sectores público, privado y social para la realización
de acciones, programas y proyectos acordes al proceso de ordenamiento ecológico, en el
ámbito de su competencia, (Gobierno del Estado de México, 2005).
2.3.2 NOM-041-SEMARNAT-2015 Que establece los límites máximos permisibles de emisión de gases contaminantes
provenientes del escape de los vehículos automotores en circulación que usan gasolina
como combustible, (PROFEPA, NOM-041-SEMARNAT-2015, 2015).
47
2.3.3 NOM-045-SEMARNAT-2006 Para vehículos en circulación que usan diésel como combustible, límites máximos
permisibles de opacidad, procedimiento de prueba, características técnicas del equipo de
medición y protocolo de prueba, (Diario Oficial de la Federación, 2012).
2.3.4 NOM-047-SEMARNAT-2014 Establece las características del equipo y el procedimiento de medición para la verificación
de los límites de emisión de contaminantes, provenientes de los vehículos automotores en
circulación que usan gasolina, gas licuado de petróleo, gas natural u otros combustibles
alternos, (PROFEPA, NOM-047-SEMARNAT-2014, 2014).
2.3.5 NOM-050-SEMARNAT-1993 Establece los niveles máximos permisibles de emisión de gases contaminantes
provenientes del escape de los vehículos automotores en circulación que usan Gas Licuado
de Petróleo, Gas Natural u otros combustibles alternos como combustible, (PROFEPA,
NOM-050-SEMARNAT-1993, 1993).
2.3.6 NOM-167-SEMARNAT-2017 Originalmente publicada como norma emergente NOM-EM-167-SEMARNAT-2016, el 7 de
junio de 2016. Se prorrogó por un plazo de seis meses contados a partir del 1 de enero de
2017. Fue una norma de emergencia muy importante, actualmente se establece como
NOM-167-SEMARNAT-2017, quedando como obligatoria y vigente a la fecha y en la que
se establecen, (SEMARNAT, 2017):
• Los niveles de emisión de contaminantes para los vehículos automotores que
circulan en la Ciudad de México, Hidalgo, Estado de México, Morelos, Puebla y
Tlaxcala.
• Los métodos de prueba para la certificación de dichos niveles y las especificaciones
de los equipos que se utilicen para dicha certificación.
• Las especificaciones para los equipos tecnológicos que se utilicen para la medición
de emisiones por vía remota y para la realización de dicha medición.
48
2.4 Marco TIC (Plan Nacional de Desarrollo 2013-2018, Agenda Digital Nacional e Iniciativas de ley)
En México, el Gobierno Federal ha impulsado distintas iniciativas para promover el
desarrollo del sector TIC e incrementar la difusión y el uso de las mismas en todos los
ámbitos de la economía, el gobierno. El gobierno Federal ha llevado a cabo estas iniciativas
a través del Plan Nacional de Desarrollo, documento donde se plasman los objetivos de
Impulsar la economía digital y fomentar el desarrollo de habilidades en el uso de las TIC, a
efecto de aprovechar las oportunidades del mundo globalizado, así como el diseñar e
impulsar, junto con los distintos órdenes de gobierno y la sociedad civil, la puesta en marcha
de actividades dirigidas a la creación y fortalecimiento de la infraestructura tecnológica a
través de plataformas digitales, (Gobierno de la República Mexicana, 2013).
Así mismo el gobierno se vale de la Agenda Digital Nacional (A.D.N.) también participa en
las propuestas de impulso a la tecnología, puesto que esta es el vehículo para lograr la
competitividad del país con base en las TIC (Senado de la República LXI Legislatura,
Comisión de Ciencia y Tecnología, 2011) y tiene como cometido:
• Alinear objetivos, políticas y acciones de todos los actores de la sociedad.
• Dicha alineación es a todos los niveles de gobierno y sociedad: estados, municipios e
individuos y organizaciones de todos sectores y estratos.
• El esfuerzo coordinado que promueve, se realiza bajo el principio de que las TIC son
un factor indispensable, pero no suficiente, para la generación de competitividad.
Por tanto, la A.D.N., es una herramienta viva, que constantemente debe recibir
retroalimentación de parte de todos los sectores y para ser efectiva, abarca cinco áreas
interdependientes y fundamentales:
1) Promueve el aprovechamiento de las TIC para el desarrollo de los individuos y las organizaciones, ya sean gubernamentales y/o empresas del sector particular,
con el fin de mejorar del entorno digital, de los derechos humanos, la salud, la
educación y el comercio electrónico.
2) El desarrollo de la industria TIC, con la respectiva oferta de software y servicios
TIC, el fortalecimiento de políticas y prácticas de interoperabilidad y neutralidad
tecnológicas, el acceso a financiamiento, el apoyo a las MIPYMES, el desarrollo de
contenidos, aplicaciones y servicios creativos en el mundo digital y el acceso al
mercado global digital.
3) El acceso y protección de usuarios de la tecnología, de modo que puedan
aprovechar las ventajas digitales sin menoscabo de su privacidad, seguridad y
49
confianza en los datos, manteniendo la seguridad de la información y aprovechando
el acceso digital como un derecho fundamental.
4) El gobierno electrónico, que se refiere al aprovechamiento de los recursos
digitales para el fortalecimiento de la transparencia, la seguridad, el cuidado de los
datos personales, las transacciones con el gobierno, los modelos de adquisición y
las consecuentes adecuaciones al marco legal.
5) Las telecomunicaciones, cuya infraestructura y operación competitiva debe
promover el desarrollo de todos los sectores productivos (Senado de la República
LXI Legislatura, Comisión de Ciencia y Tecnología, 2011).
Si bien la agenda digital y el plan nacional de desarrollo son herramientas que utiliza el
gobierno federal para la inclusión de las TIC, también se vale de las iniciativas de Ley TIC,
propuestas por el Congreso de la Unión, quien ha tenido avances al reconocer la
importancia de la TIC para el país, aunque no ha logrado reflejarlos en leyes concretas, ha
impulsado las siguientes iniciativas, (Senado de la República LXI Legislatura, Comisión de
Ciencia y Tecnología, 2011):
• Iniciativa de Ley de Planeación (Agenda Digital Nacional Transexenal)
• Comisión Especial de Acceso Digital
• Minuta de la Ley para el Desarrollo de la Sociedad de la Información
• Ley Federal de Protección de Datos Personales
• Minuta Firma Electrónica Avanzada.
Derivado de estas iniciativas, es que se justifica que se incluyan las TIC en todos los
sectores debido a los beneficios que otorgan, en esta investigación en específico como se
comentó en el Capítulo I, se trabajara con una empresa dedicada al mantenimiento de
equipo de verificentros, en la siguiente sección se realiza una descripción de la empresa.
2.5 CASO DE ESTUDIO: “Medios y Procedimientos Tecnológicos, S.A. de C.V.” Nuestro caso de estudio es la empresa denominada “Medios y Procedimientos
Tecnológicos, S.A. de C.V.”, conocida abreviadamente como MPT, de la cual se obtiene
información importante para conocer el funcionamiento de las empresas proveedoras del
mantenimiento y de los equipos de verificación vehicular y que nos servirá de base para
proponer el sistema SASM.
Las actividades principales de la empresa son: Suministrar, instalar, configurar y dar
mantenimiento a los equipos de verificación vehicular; a sus partes, componentes y
50
dispositivos, oportunamente a los clientes y cumpliendo con las normas ambientales
vigentes en sus diferentes combustibles Gasolina, Gas L.P., Gas Natural y Diesel.
La empresa cuenta con un plan estratégico es decir cuenta con una herramienta de gestión
que permite apoyar la toma de decisiones de las organizaciones en torno al que hacer actual
y al camino que deben recorrer en el futuro para adecuarse a los cambios y a las demandas
que les impone el entorno y lograr la mayor eficiencia, eficacia, calidad en los bienes y
servicios que se proveen (Armijo, 2009).
Las principales metas estratégicas de la empresa se enlistan a continuación.
• Ser el mejor proveedor de equipos de verificación vehicular a nivel nacional.
• Conocer los últimos cambios a las normas vigentes obligatorias para implementarlas
correctamente en los equipos de verificación vehicular.
• Mejorar la entrega del servicio a nuestros clientes, para que sea más rápido,
eficiente y de mayor calidad.
Estas metas están alineadas a los siguientes objetivos estratégicos:
• Tener presencia en los 31 estados de la República Mexicana y en la Capital del
País.
• Participar anualmente en las convenciones, conferencias y cumbres que se llevan a
cabo, relacionadas a la verificación vehicular para dar a conocer nuestra marca y
servicios.
• Revisar semestralmente la emisión de las nuevas normas y/o modificaciones a las
existentes vía Diario Oficial de la Federación y/o Gacetas del Gobierno de los
Estados para estar actualizados e implementar los cambios a la brevedad.
• Contar con un completo y suficiente stock de refacciones y componentes para poder
construir por lo menos 30 equipos nuevos de verificación para entrega inmediata.
• Contar con por lo menos 15 técnicos de mantenimiento para cada Entidad
Federativa, 8 técnicos para los centros federales de la SCT y más 6 técnicos iniciales
por cada nuevo Estado en donde nos sea otorgada la autorización para operar como
proveedor.
• Distribuir a los técnicos de servicio de forma estratégica por zonas geográficas para
maximizar la cobertura del servicio.
• Atender a más tardar 24 horas después de que el cliente solicitó el servicio.
51
• Que los técnicos asignados a los servicios porten un stock mínimo de piezas y
refacciones que son de uso más común en el mantenimiento y entrega de servicio.
2.6 Análisis general de la situación actual: FODA Para indagar más acerca de la empresa se realizó un análisis situacional FODA, para
detectar puntos de mejora. En figura 9, se muestra el resultado de un análisis general de la
situación actual de las empresas proveedoras, en donde se resalta la necesidad de un
sistema que apoye las actividades de entrega del servicio.
Figura 9: Análisis FODA de las empresas proveedoras Fuente: Elaboración propia
52
2.6.1 Estructura organizacional A continuación, se presenta en la figura 10, la estructura organizacional general, en donde
se muestran algunas de las funciones mínimas que se tienen en la organización.
Figura 10: Estructura organizacional típica y sus funciones Fuente: Elaboración propia
53
Así mismo la figura 11 muestra el macroproceso genérico de las empresas proveedoras de
equipos de verificación vehicular, mostrando las principales áreas y funciones de la
organización, hasta llegar a su cliente final que son los verificentros.
Figura 11: Macroproceso de las empresas proveedoras Fuente: Elaboración propia
La línea roja circula el proceso de Servicio y Mantenimiento y su entrega a los clientes
finales, mostrando la parte que se pretende hacer más eficiente con el desarrollo del SASM.
54
2.6.2 Procesos primarios relacionados con el de proceso de Servicio (La Cadena de Valor)
En la figura 12 se muestran los procesos primarios de la organización y que inciden de
modo directo en la prestación del SERVICIO, y por lo tanto la satisfacción del cliente, y
dichos procesos tienen las siguientes características:
• Centrada en el cliente.
• Objetivos comunes en donde todas las actividades participan.
• Se requiere manejo estratégico de los flujos de información.
• Relaciones de trabajo cooperativas.
Qué valoran los clientes de los equipos de verificación vehicular:
• Precios bajos.
• Atención personalizada.
• Rapidez en la entrega de equipos y en la puesta en operación.
• Buen desempeño y funcionalidad.
• Resolución de fallas y mantenimiento oportuno.
Todo lo anterior es más fácil de alcanzar con la utilización del sistema propuesto.
Figura 12: La Cadena de Valor Genérica Porter, M. (1987). Competitive Advantage – Creating and Sustaining Superior Performance
55
2.6.3 Proceso Clave: Entrega Del Servicio El proceso de SERVICIO es que se pretende mejorar mediante el desarrollo del sistema
propuesto, la figura 13 lo describe iniciándose con una entrada que es la solicitud de servicio
por parte del cliente y una salida que es la entrega del servicio; el sistema propuesto nos
ayudará a gestionar y/o administrar cada solicitud de servicio.
Figura 13: Proceso Clave: SERVICIO, Fuente: Elaboración propia El servicio y/o mantenimiento, es considerado el proceso clave, ya que le da la razón de ser
a la organización por los siguientes motivos:
1. Es su mayor fuente de ingresos económicos.
2. La empresa está condicionada por el gobierno a prestar el servicio de forma
oportuna, satisfactoria y continua para los verificentros.
3. Es el proceso interno más complejo y difícil de controlar y con la necesidad de
generar reportes e informes de forma rápida para la toma de decisiones.
4. El proceso de servicio interactúa con otros procesos importantes de la empresa tales
como:
• Entradas y salidas de almacén de las partes, piezas e insumos.
• Generación de órdenes de servicio con los datos de fecha, hora, nombre del
cliente atendido, clave, nombre del responsable, teléfono, sello y firma de
recibido de conformidad, que son el medio de comprobación con el gobierno
del tipo de servicio y el alcance llevado a cabo.
• Alimenta el proceso de facturación, cuyas órdenes de servicio sirven como
medio de comprobación para realizar la factura y cobrar al cliente el servicio
y las piezas consumidas.
56
2.6.4 Elementos que Integran el Sistema propuesto: “Sistema de Administración de los Servicios de Mantenimiento (SASM)”
De lo anterior, resalta la necesidad de hacer más eficiente la gestión del servicio a los
verificentros alineando sus metas y objetivos estratégicos, para potenciar su productividad
y competitividad frente a empresas rivales, y que agregando el componente de las TIC
ayuda a generar un elemento innovador de la empresa en beneficio de sus clientes; por lo
que se justifica la creación del sistema.
En la figura 15 se muestran los elementos organizaciones que integran el sistema
propuesto.
Figura 14: Elementos organizacionales que integran el SASM Fuente: Elaboración propia
Sistema SASM
TIC
Metas y Objetivos
Organizacionales
SERVICIO+
VALOR
57
3 CAPÍTULO III. ANÁLISIS DEL SISTEMA DE ADMINISTRACIÓN DE LOS
SERVICIOS DE MANTENIMIENTO (SASM) – REQUERIMIENTOS Y CASOS DE USO
En este capítulo se presentan los principales actores del sistema y las acciones que realizan
en él. Se especifica el sistema SASM que será el responsable de gestionar el proceso de
los servicios de mantenimiento, con un diseño modular que permita incrementar la
funcionalidad del sistema en versiones futuras. También se determinan los requerimientos
funcionales y no funcionales del sistema propuesto SASM.
3.1 Actores del sistema y acciones Un sistema debe contar con actores y acciones principales que son los individuos que
utilizarán el sistema y la forma de cómo lo harán A continuación, se describen a los actores
que usarán el sistema y se da un breve panorama de las acciones que tiene permitidas
cada actor dentro de él.
• Administrador:
Un administrador puede agregar y eliminar usuarios del sistema, también realiza
tareas de actualización de catálogos. Asigna los técnicos a las solicitudes. Es el
usuario experto para realizar acciones de cancelación o eliminación. Visualiza los
reportes generados por el sistema. Además de realizar las acciones los otros roles.
• Técnico:
Puede generar, consultar y actualizar solicitudes, captura el cierre de una solicitud
ingresando las soluciones realizadas y materiales utilizados.
• Contador:
Gestiona los adeudos del cliente por los servicios proporcionados, controla e
identifica el tipo de pago y el costo a cobrar, monitorea los pagos realizados,
consulta la sección de reportes.
• Cliente:
Puede crear solicitudes de servicio, monitorea el estado de su solicitud, así como
consultar su historial de servicios.
Ya definidos los actores del sistema se prosigue con los requerimientos funcionales y
técnicos del mismo los cuales son necesarios y propios del sistema propuesto, los relativos
al inicio y cierre de sesión, catálogo de usuarios, catálogo de centros de servicio, catálogo
de conceptos de servicio, catálogo de conceptos de adeudo, solicitudes de servicio,
adeudos (consultas) y reportes.
58
3.1.1 Requerimientos Funcionales (RF): Inicio y cierre de sesión Se listan los principales requisitos funcionales y algunos escenarios que se pueden
presentar relacionados al inicio y cierre de sesión.
RF 1.1: Para un usuario el estado de acceso puede ser con sesión abierta o sin sesión.
RF 1.2: El sistema debe controlar el estado de acceso creando una sesión en el servidor.
Escenario 1.1 Apertura de sesión
• Precondición: El usuario no tiene una sesión abierta en el sistema.
• El usuario accede al sistema.
• Se le solicita al usuario que ingrese su nombre de usuario y su clave en una página
de acceso.
• El usuario provee el nombre y clave correctos.
• Se crea la sesión de usuario y la página de ingreso al sistema es desplegada.
RF 1.3: El escenario 1.1. Apertura de sesión, deberá ser soportado por el sistema
Escenario 1.2: Cierre de sesión
• Precondición El usuario tiene una sesión abierta en el sistema.
• Al usuario se le presenta una opción que indica el cierre de sesión
• El usuario solicita el cierre de sesión.
• Se cierra la sesión del usuario y es redireccionado a la página de inicio del sistema.
RF 1.4: El escenario 1.2. Cierre de sesión, deberá ser soportado por el sistema
Escenario 1.3 Fallo en el inicio de sesión
• Precondición El usuario no tiene una sesión abierta en el sistema.
• El usuario accede al sistema.
• Se le solicita al usuario que ingrese su nombre de usuario y su clave en una página
de acceso.
• El usuario provee el nombre y/o clave incorrecta
• No se crea sesión de usuario y un mensaje de error es desplegado.
• Se le solicita nuevamente al usuario su nombre de usuario y su clave de acceso.
RF 1.5: El escenario 1.3. Fallo en el inicio de sesión, deberá ser soportado por el sistema
59
RF 1.6: Cuando un usuario llega al sistema y no ha iniciado sesión se le pedirá que
proporcione un nombre de usuario y una contraseña. Ninguna otra información debe
proporcionarse al usuario
RF 1.7: Todas las páginas mostradas a un usuario en sesión deben incluir la funcionalidad
para cerrar sesión, por ejemplo, un botón para salir del sistema.
RF 1.8: Si un usuario conectado permanece inactivo durante más de 30 minutos se debe
cerrar la sesión y se le debe solicitar que vuelva a conectarse para seguir usando el sistema.
3.1.2 Requerimientos Funcionales (RF): Catálogo de Usuarios Se presentan los principales requisitos funcionales para el catálogo de usuarios.
RF 2.1: En el menú de opciones de administración del sistema debe existir una opción para
administrar los usuarios del sistema.
RF 2.2: El catálogo de usuarios solo deberá ser visible para usuarios con el rol de
administrador
RF 2.3: Los usuarios pueden ser internos (Administrador, técnico y contador) o externos
(cliente).
RF 2.4: En la página de administración debe ser posible agregar un nuevo usuario.
RF 2.5: En la página de administración un usuario deberá tener los siguientes datos nombre
de usuario, contraseña, nombre, apellido paterno, apellido materno, teléfono, correo, rol y
estatus.
RF 2.6: Si el usuario es externo deberá capturarse la entidad a la que pertenecen (centro
de servicio).
RF 2.7: Si el usuario es externo deberá indicarse si el usuario es el
responsable/gerente/encargado del centro de servicio.
RF 2.8: Solo puede existir un responsable (gerente/encargado) por centro de servicio. Si
existe otro usuario del mismo centro con el estatus de encargado el estatus de encargado
debe cambiarse a falso (activo/inactivo).
RF 2.9: El usuario solo puede pertenecer a una entidad (centro de servicio).
RF 2.10: La entidad deberá seleccionarse del catálogo de centros de servicio disponibles.
RF 2.11: El usuario tendrá un asociado que deberá seleccionarse de un catálogo de roles
predefinido (Administrador, técnico, contador y cliente).
60
RF 2.12: El usuario solo podrá tener un rol asociado.
RF 2.13: Los nombres de usuario deben ser únicos para cada usuario.
RF 2.14: Si el administrador intenta añadir un nuevo usuario con un nombre de usuario que
ya existe en el sistema deberá mostrar un mensaje de error y el usuario no deberá ser
agregado.
RF 2.15: Los nombres de usuario deben constar de 10 caracteres, los valores permitidos
son números “0-1”, “A-Za-z” y “ _”.
RF 2.16: Las contraseñas deben constar de 8 caracteres, los valores permitidos son
números “0-1”, “A-Za-z” y “ _”.
RF 2.17: Los usuarios no pueden eliminarse, en cambio es posible modificar su estatus de
activo a inactivo o viceversa.
RF 2.18: Los usuarios inactivos no tendrán acceso al sistema.
RF 2.19: Los datos del usuario pueden ser modificados a excepción del nombre de usuario.
RF 2.20: Si el administrador trata de agregar un nuevo usuario o modificar un usuario cuyos
datos violan los requerimientos 2.14, 2.15 o 2.16 un mensaje de error deberá mostrarse.
3.1.3 Requerimientos Funcionales (RF): Catálogo de Centros de Servicio RF 3.1: En el menú de opciones de administración del sistema debe existir una opción para
administrar los centros de servicio.
RF 3.2: El catálogo de centros de servicio solo deberá ser visible para usuarios con el rol
de administrador.
RF 3.3: Un centro de servicio deberá tener los siguientes datos número de centro, estado,
razón social, calle, colonia, código postal, RFC, teléfono, número de líneas y estatus.
RF 3.4: Debe ser posible agregar un nuevo centro de servicio.
RF 3.5: El número de centro es único y no puede repetirse.
RF 3.6: Si el administrador intenta añadir un centro de servicio con un número de centro
que ya existe en el sistema deberá mostrar un mensaje de error y el centro no deberá ser
agregado.
RF 3.7: Los números de centro deben constar de 12 caracteres, los valores permitidos son
números “0-1”, “A-Za-z” y “-”.
61
RF 3.8: El estado deberá ser seleccionado de un catálogo de estados.
RF 3.9: Los centros de servicio no pueden eliminarse, en cambio es posible modificar su
estatus de activo a inactivo o viceversa.
RF 3.10: Los usuarios asociados a un centro de servicio inactivo cambiará su estatus a
inactivo de forma automática.
RF 3.11: Todos los datos del centro de servicio pueden ser modificados
RF 3.12: Si el administrador trata de agregar un nuevo centro de servicio o modificar uno
ya existente cuyos datos violan el requerimiento 3.7, un mensaje de error deberá mostrarse.
3.1.4 Requerimientos Funcionales (RF): Catálogo de Conceptos de Servicio Los siguientes requerimientos funcionales son los relacionados con los conceptos de
servicio.
RF 4.1: En el menú de opciones de administración del sistema debe existir una opción para
administrar los conceptos de servicio.
RF 4.2: La opción para administrar los conceptos de servicio solo deberá estar accesible
para usuarios con el rol de administrador.
RF 4.3: Un concepto de servicio deberá tener los siguientes datos: nombre del servicio
(mantenimiento mensual, mantenimiento bimestral, reparación, servicio no incluido en
póliza y garantía) y estado (iniciado, asignado, finalizado, pendiente de pago, pagado y sin
costo).
RF 4.4: Debe ser posible agregar un nuevo concepto de servicio para el rol de
administrador.
RF 4.5: El nombre del concepto de servicio es único.
RF 4.6: Si el administrador intenta añadir o modificar un concepto de servicio con un nombre
de concepto que ya existe en el sistema deberá mostrar un mensaje de error y el concepto
no deberá ser agregado.
RF 4.7: Los conceptos de servicio no pueden eliminarse, en cambio es posible modificar su
estatus de activo a inactivo o viceversa.
RF 4.8: Todos los datos del concepto de servicio pueden ser modificados.
62
3.1.5 Requerimientos Funcionales (RF): Catálogo de Conceptos de Adeudo RF 5.1: En el menú de opciones de administración del sistema debe existir una opción para
administrar los conceptos de adeudo.
RF 5.2: El catálogo de conceptos de adeudo solo deberá ser visible para usuarios con el rol
de administrador y contador, no para el técnico ni el responsable, ya que es el catálogo
interno de conceptos de adeudo.
RF 5.3: Un concepto de adeudo deberá tener los siguientes datos: nombre del concepto,
tiene costo y estatus.
• El nombre del concepto, dentro de la solicitud de servicio tiene los valores:
mantenimiento mensual, mantenimiento bimestral, mantenimiento general,
reparación, servicio no incluido en póliza, servicio incluido en póliza y garantía.
• Tiene costo, son valores: verdadero/falso.
• Estatus, son valores: pagado/ no pagado.
RF 5.4: Existen cinco tipos de concepto de adeudo que tienen costo: mantenimiento
mensual, mantenimiento bimestral, mantenimiento general, reparación y servicio no incluido
en póliza.
RF 5.5: Existen dos tipos de concepto de adeudo que no tienen costo: servicio incluido en
póliza y garantía.
RF 5.6: Debe ser posible agregar un nuevo concepto de adeudo.
RF 5.7: Si el administrador intenta añadir o modificar un concepto de adeudo con un nombre
de concepto que ya existe en el sistema deberá mostrar un mensaje de error y el concepto
no deberá ser agregado.
RF 5.8: Los conceptos de adeudo no pueden eliminarse, en cambio es posible modificar su
estatus de activo a inactivo o viceversa.
RF 5.9: Todos los datos del concepto de adeudo pueden ser modificados.
63
3.1.6 Requerimientos Funcionales (RF): Solicitudes de Servicio Los siguientes requisitos funcionales son los relacionados con las órdenes o solicitudes de
servicio que soliciten los clientes o centros de verificación a la empresa proveedora.
RF 6.1: En el menú de opciones del sistema debe existir una opción para administrar las
solicitudes de servicio.
RF 6.2: Las solicitudes de servicio debe ser visibles para el rol administrador, técnico y
cliente.
RF 6.3: Las solicitudes de servicio pueden estar en alguno de los siguientes estados
Iniciado, asignado, finalizado o cancelado.
Escenario 6.1 Nueva solicitud de servicio
Precondición: El usuario tiene un rol con acceso a la funcionalidad de solicitudes de servicio.
1. El usuario accede a la administración de solicitudes de servicio.
2. Se le solicita al usuario que seleccione el centro de servicio.
3. El usuario selecciona el concepto de servicio (mantenimiento mensual,
mantenimiento bimestral, mantenimiento general, reparación, servicio no incluido en
póliza, servicio incluido en póliza y garantía)
4. El sistema muestra dos opciones de selección mutuamente excluyentes,
Ecológico o Local (ecológico, es para los servicios relacionados con los equipos que
vigilan las secretarías del medio ambiente y local es para otros equipos como
telefonía y computadoras administrativas, etc.).
5. El usuario selecciona alguna opción.
6. Si el usuario selecciona Ecológico:
6.1 El sistema muestra las opciones del área de cómputo: Server, Impresión y
Tenencia.
6.2 El usuario puede seleccionar varias opciones de cómputo.
6.3 Por cada opción de cómputo seleccionada se despliega un campo de texto
con la leyenda “Falla en: ” concatenado con el tipo de cómputo seleccionado.
6.4 El sistema provee la cantidad de líneas de mantenimiento disponibles para
el centro de servicio seleccionado
6.5 El usuario selecciona las líneas de mantenimiento que sean requeridas
6.6 Por cada línea seleccionada se despliega un campo de texto con la leyenda
“Falla en: ” concatenado con el número de la línea seleccionada
64
6.7 El sistema muestra un campo de comentarios para captura de datos
adicionales
6.8 El sistema provee la cantidad de líneas de mantenimiento disponibles para
el centro de servicio seleccionado.
6.9 El usuario selecciona las líneas de mantenimiento que sean requeridas.
6.10 Por cada línea seleccionada se despliega un campo de texto con la
leyenda “Falla en: ” concatenado con el número de la línea seleccionada.
7. Si el usuario selecciona Local:
7.1 El usuario indica el equipo que está fallando y describe brevemente la falla
8. Se muestra un campo de texto para capturar el nombre de “quien reporta”
(Nombre y apellidos de una persona).
9. El sistema muestra un campo de comentarios para captura de datos
adicionales
10. El sistema guarda la solicitud y genera un folio de servicio.
11. El sistema notifica que la solicitud ha sido guardada y el folio de servicio
generado
12. El estado de la solicitud es “iniciado”.
RF 6.4: El escenario 6.1. Nueva solicitud de servicio, deberá ser soportado por el sistema
Escenario 6.2 Generar reporte de la nueva solicitud de servicio
Precondición: RF 6.4 (Nueva solicitud de servicio)
1. El sistema ha guardado la solicitud de servicio
2. El sistema genera un documento en PDF con los datos de la solicitud
capturada
3. El sistema permite la descarga del documento.
4. El formato del reporte debe ser como se muestra en el formato.
65
3.1.6.1 Formato: Reporte de la nueva solicitud de servicio Tabla 1: Formato 6.1 Reporte de la nueva solicitud de servicio Fuente: Elaboración propia
MEDIOS Y PROCEDIMIENTOS TECNOLÓGICOS
REPORTE DE SERVICIO
Nombre del centro Nombre del centro Número de folio Núm. folio generado
Reportado por Nombre de quién reporta Fecha y hora En que se generó
DESCRIPCIÓN DEL REPORTE
Estatus El estatus de la solicitud iniciado/asignado/finalizado
Concepto de servicio
Mantenimiento mensual, mantenimiento bimestral, mantenimiento general, reparación
Líneas Línea 1, Línea 4, etc.
Falla reportada Descripción de la falla
Solución aplicada Descripción de la solución utilizada para la falla al finalizarla
Material aplicado Descripción del material o materiales utilizados
Comentarios Datos capturados al momento de crear la solicitud
Observaciones Observaciones hechas por el técnico al momento de finalizar
Nombre del técnico Nombre del responsable del centro
Nombre y firma del personal de MPT Nombre, firma y sello del centro
Número de página
66
RF 6.5: El escenario 6.2. Generar reporte de la nueva solicitud de servicio, deberá ser
soportado por el sistema
Escenario 6.3 Consulta de solicitudes iniciadas (abiertas sin asignar)
Precondición: RF 6.4 (Nueva solicitud de servicio)
1. El sistema muestra una tabla con solicitudes en estado “iniciado”, el máximo
número de solicitudes mostradas es de 15 ordenadas por fecha de apertura en
forma descendente
2. Si el usuario tiene un rol de técnico o cliente, se muestran sólo aquellas
solicitudes que le pertenecen al usuario (solicitudes creadas por el mismo usuario
que las consulta)
3. Si el usuario tiene un rol de cliente, también se muestran las solicitudes en
estado “asignado”
4. Si el usuario tiene un rol de administrador se muestran las solicitudes
iniciadas sin importar a quién pertenecen las solicitudes
5. Las solicitudes se pueden filtrar por un intervalo de fecha de apertura (inicio
y fin), se muestra el total de solicitudes obtenidas con paginación.
6. Las solicitudes se pueden filtrar por centro de servicio, técnico, solo aplica
para el rol administrador. Se muestra el total de solicitudes obtenidas con paginación
7. Los datos que se muestran en la tabla son Centro, número de folio, tipo de
solicitud, fecha de alta de la solicitud, técnico asignado, descarga del reporte
generado.
RF 6.6: El escenario 6.3 Consulta de solicitudes iniciadas (abiertas sin asignar), deberá ser
soportado por el sistema
Escenario 6.4 Asignación de técnico a solicitudes iniciadas
• Precondición: RF 6.4: (El escenario 6.1. Nueva solicitud de servicio)
• Los usuarios con el rol de cliente o contador, no podrán asignar técnico a las
solicitudes del servicio.
• Si el usuario tiene el rol de técnico y la solicitud está en estatus “iniciado”, entonces
el técnico podrá asignarse a sí mismo la solicitud o a otro(s) técnico(s).
• El usuario administrador podrá asignar técnico(s) a las solicitudes iniciadas.
• El usuario selecciona un registro de una solicitud iniciada y el sistema permite
realizar las asignaciones.
67
• Al asignarse un técnico, el estatus de la solicitud cambia a “asignado”.
RF 6.7: El escenario 6.4 Asignación de técnico a solicitudes iniciadas, deberá ser soportado
por el sistema
Escenario 6.5 Reasignación de técnico a solicitudes asignadas
Precondición: RF 6.7 (El escenario 6.4, Asignación de técnico a solicitudes iniciadas)
1. Si el usuario tiene un rol de cliente, contador o técnico, no podrán reasignar
técnico a las solicitudes del servicio.
2. El rol administrador puede realizar esta acción.
3. El usuario selecciona un registro de una solicitud asignada.
4. El sistema permite que el usuario reasigne el técnico o técnicos para atender
esta solicitud.
5. El estatus de la solicitud permanece en “asignado”.
RF 6.8: El escenario 6.5 Reasignación de técnico a solicitudes asignadas, deberá ser
soportado por el sistema
Escenario 6.6 Cancelación de solicitudes
Precondiciones: RF 6.4 (El escenario 6.1. Nueva solicitud de servicio) ó
RF 6.7: El escenario 6.4 Asignación de técnico a solicitudes iniciadas ó
RF 6.8: El escenario 6.5 Reasignación de técnico a solicitudes asignadas
• La acción no puede ser realizada por los usuarios de cliente, técnico y contador.
• La acción sólo puede ser realizada por el usuario administrador y en cualquier
estado (iniciada, asignada, reasignada).
• El usuario selecciona un registro de una solicitud para ser cancelado.
• A la solicitud se le agrega el nuevo estatus de “Cancelada”, no se debe borrar a nivel
físico.
RF 6.9: El escenario 6.6 Cancelación de solicitudes, deberá ser soportado por el sistema
Escenario 6.7 Consulta de solicitudes asignadas (abiertas)
Precondiciones: RF 6.7 (El escenario 6.4, Asignación de técnico a solicitudes iniciadas) ó
RF 6.8 (El escenario 6.5 Reasignación de técnico a solicitudes asignadas)
1. Solo el rol de técnico o administrador pueden realizar esta función.
68
2. El sistema muestra una tabla con solicitudes en estatus “asignado”, el
máximo número de solicitudes mostradas es de 15 ordenadas por fecha de apertura
en forma descendente.
3. Si el rol es técnico las solicitudes mostradas corresponden a las que le fueron
asignadas al usuario.
4. Si el rol es administrador se muestran todas las solicitudes asignadas.
5. Las solicitudes se pueden filtrar por un intervalo de fechas de apertura (inicio
y fin), se muestra el total de solicitudes obtenidas con paginación.
6. Las solicitudes se pueden filtrar por centro de servicio, se muestra el total de
solicitudes obtenidas con paginación.
7. Las solicitudes se pueden filtrar por técnico, se muestra el total de solicitudes
obtenidas con paginación. Solo aplica para el rol de administrador.
8. Los datos que se muestran en la tabla son Centro, número de folio, tipo de
solicitud, fecha de alta, técnico asignado
9. Opción de descargar en archivo pdf, el reporte generado.
RF 6.10: El escenario 6.7 Consulta de solicitudes asignadas (abiertas), deberá ser
soportado por el sistema
Escenario 6.8 Finalizar solicitudes asignadas
• Precondición Requerimiento 6.11
• No se pueden finalizar solicitudes sin tener un técnico asignado.
• Los usuarios cliente y contador no pueden finalizar solicitudes.
• El usuario técnico o administrador, selecciona un registro de una solicitud.
• El sistema permite que el usuario finalice la solicitud.
• El sistema muestra un campo llamado “solución aplicada” por cada opción, cómputo
o línea que tenga la solicitud. El usuario debe llenar el campo de forma obligatoria
• El sistema muestra un campo llamado “materiales empleados” por cada opción,
cómputo o línea que tenga la solicitud. El usuario debe llenar el campo de forma
obligatoria.
• El usuario asigna el estatus de la solicitud a “finalizado”.
• El sistema guarda los datos y cambia el estatus de la solicitud a “finalizado”.
RF 6.11: El escenario 6.8 Finalizar solicitudes asignadas, deberá ser soportado por el
sistema
Escenario 6.9 Consulta de solicitudes finalizadas
69
Precondición: RF 6.11 (El escenario 6.8, Finalizar solicitudes asignadas)
1. Es visible para Administrador, técnico y cliente.
2. El sistema muestra una tabla con solicitudes en estatus “finalizado”, el
máximo número de solicitudes mostradas es de 15 ordenadas por fecha de
finalización en forma descendente.
3. Si el rol es técnico o cliente las solicitudes mostradas corresponden a las que
le fueron asignadas al usuario.
4. Si el rol es administrador o se muestran todas las solicitudes finalizadas.
5. Las solicitudes se pueden filtrar por un intervalo de fecha de finalización
(inicio y fin), se muestra el total de solicitudes obtenidas con paginación.
6. Las solicitudes se pueden filtrar por centro de servicio, se muestra el total de
solicitudes obtenidas con paginación.
7. Las solicitudes se pueden filtrar por técnico, se muestra el total de solicitudes
obtenidas con paginación. Solo aplica para el rol de administrador.
8. Los datos que se muestran en la tabla son Centro, número de folio, tipo de
solicitud, fecha de alta, técnico asignado.
9. Se puede realizar la descarga del reporte generado, en archivos XLS y CSV.
RF 6.12: El escenario 6.9 Consulta de solicitudes finalizadas, deberá ser soportado por el
sistema
3.1.7 Requerimientos Funcionales (RF): Adeudos (consultas) RF 7.1: En el menú de opciones del sistema debe existir una opción para consultar adeudos.
RF 7.2: El adeudo de una solicitud puede estar en uno de estos tres estados: Pendiente de
pago, Pagado y Sin costo. El estatus por default del adeudo es: Pendiente de pago.
Escenario 7.1 Consulta de adeudo
Precondición: RF 6.11 (El escenario 6.8, Finalizar solicitudes asignadas)
1. Es visible para el administrador, contador y cliente.
2. El sistema muestra una tabla con solicitudes en estatus “finalizado”, el máximo
número de solicitudes mostradas es de 15 ordenadas por fecha de finalización en
forma descendente.
3. Las solicitudes se pueden filtrar por un intervalo de fechas de finalización (inicio y
fin), se muestra el total de solicitudes obtenidas con paginación.
70
4. Las solicitudes se pueden filtrar por centro de servicio, se muestra el total de
solicitudes obtenidas con paginación. Este filtro no aplica para el cliente.
5. Las solicitudes se pueden filtrar por técnico, se muestra el total de solicitudes
obtenidas con paginación. Este filtro no aplica para el cliente.
6. Las solicitudes se pueden filtrar por estatus de pago (Pendiente de pago, Pagado y
Sin costo), se muestra el total de solicitudes obtenidas con paginación.
7. Los datos que se muestran en la tabla son Centro, número de folio, tipo de solicitud,
fecha de alta, fecha de atención, estado de adeudo, total del adeudo.
RF 7.3: El escenario 7.1 Consulta de adeudo, deberá ser soportado por el sistema.
Escenario 7.2 Captura de adeudo
Precondición: RF 6.11 (El escenario 6.8, Finalizar solicitudes asignadas)
1. Es visible para el administrador y contador.
2. El usuario selecciona un registro de una solicitud.
3. El usuario selecciona el concepto de adeudo del catálogo para cada partida de la
orden de servicio.
4. Si el concepto de adeudo tiene un costo, el sistema permite que el usuario capture
el costo y el I.V.A. ambos son campos numéricos.
5. Si el concepto de adeudo no tiene costo, no permite captura del costo ni del I.V.A.
6. El sistema calcula el costo total como la suma del I.V.A. más el costo de la orden de
servicio, si el concepto no tiene costo es cero.
7. El sistema permite que el usuario cambie el estatus del adeudo de la orden de
servicio: pendiente de pago, pagado y sin costo.
RF 7.4: El escenario 7.2 Captura de adeudo, deberá ser soportado por el sistema
71
3.1.8 Requerimientos Funcionales (RF): Reportes
RF 8.1: En el menú de opciones del sistema debe existir una opción para consultar reportes.
Escenario 8.1 Reporte de estado de las solicitudes de servicio
Precondición: Existen solicitudes de servicio: iniciadas, asignadas, finalizadas, pendientes
de pago, pagadas y sin costo.
1. Para el rol de técnico se muestran sólo las iniciadas para poder asignarse a
sí mismo, asignadas a él y finalizadas por él.
2. Para los usuarios administrador, contador y cliente, se muestran todos los
estados de la solicitud
3. Las solicitudes se pueden filtrar por un intervalo de fechas de atención (inicio
y fin), se muestra el total de solicitudes obtenidas.
4. Las solicitudes se pueden filtrar por centro de servicio, se muestra el total de
solicitudes obtenidas.
5. Las solicitudes se pueden filtrar por técnico, se muestra el total de solicitudes
obtenidas.
6. Las solicitudes se pueden filtrar estado de la solicitud, se muestra el total de
solicitudes obtenidas.
7. Los filtros son mutuamente incluyentes
8. Los datos a mostrarse son como en el formato 8.1
9. Los resultados se pueden exportar en formato XLS y CSV
72
3.1.8.1 Formato: Reporte de estado de las solicitudes de servicio (Iniciada, Asignada, Finalizada, Pendiente de pago, Pagada y Sin costo)
Tabla 2: Formato 8.1 Reporte de estado de las solicitudes de servicio
Fuente: Elaboración propia
MEDIOS Y PROCEDIMIENTOS TECNOLÓGICOS
REPORTE DE ESTADO
Centro #folio tipo de solicitud
fecha alta fecha atención
estatus
Técnico(s)
RF 8.2: El escenario 8.1 Reporte de estado de las solicitudes de servicio, deberá ser
soportado por el sistema
Escenario 8.2 Reporte de adeudos
Precondición Existen solicitudes de servicio pendientes de pago.
1. Es visible para el administrador y contador. Para el cliente solo se muestra lo
relacionado a su verificentro.
2. Las solicitudes se pueden filtrar por un intervalo de fechas de atención (inicio y fin),
se muestra el total de solicitudes obtenidas.
3. Las solicitudes se pueden filtrar por centro de servicio, se muestra el total de
solicitudes obtenidas.
4. Las solicitudes se pueden filtrar por técnico, se muestra el total de solicitudes
obtenidas.
5. Las solicitudes se pueden filtrar por concepto de adeudo: pendientes de pago o
pagadas, se muestra el total de solicitudes obtenidas y la suma de la cantidad total.
6. Los filtros son mutuamente incluyentes
7. Los datos a mostrarse son como en el formato 8.2
8. Los resultados se pueden exportar en formato XLS y CSV
73
3.1.8.2 Formato: Reporte de adeudos Tabla 3: Formato 8.2 Reporte de adeudos
Fuente: Elaboración propia
MEDIOS Y PROCEDIMIENTOS TECNOLÓGICOS
REPORTE DE ADEUDOS
Centro #folio tipo de solicitud
fecha atención
Técnico(s) estatus de adeudo
Total
RF 8.3: El escenario 8.2 Reporte de adeudos, deberá ser soportado por el sistema
Escenario 8.3 Reporte de computo
Precondición: Existen solicitudes de servicio finalizadas.
1. Es visible para los usuarios administrador, contador, cliente y técnico.
2. Las solicitudes se pueden filtrar por un intervalo de fechas de atención (inicio
y fin), se muestra el total de solicitudes obtenidas con paginación.
3. Los datos de los centros se agrupan por centro, cómputo y estado (iniciado,
asignado, finalizado).
4. Los datos a mostrarse son como en el formato 8.3
5. Los resultados se pueden exportar en formato XLS y CSV
74
3.1.8.3 Formato: Reporte de Cómputo Tabla 4: Formato 8.3 Reporte de cómputo
Fuente: Elaboración propia
MEDIOS Y PROCEDIMIENTOS TECNOLÓGICOS
REPORTE DE CÓMPUTO
Rango de fechas Fechas de búsqueda
Centro Estado Cómputo Cantidad
RF 8.4: El escenario 8.3 Reporte de cómputo, deberá ser soportado por el sistema
Escenario 8.4 Reporte de centros x concepto de servicio (tipo de solicitud)
Precondición: Existen solicitudes de servicio iniciadas, asignadas o finalizadas.
1. Para el cliente, se muestran sólo las relacionadas con su centro de servicio.
2. Para el técnico, se muestran las iniciadas y las asignadas o finalizadas por él.
3. Es visible para el administrador y contador, se muestran todos los centros y técnicos.
4. Las solicitudes se pueden filtrar por un intervalo de fechas (inicio y fin), se muestra
el total de solicitudes obtenidas.
5. Las solicitudes se pueden filtrar por centro.
6. Los filtros son mutuamente excluyentes.
7. Los datos se agrupan por centro, concepto de servicio (tipo de solicitud:
mantenimiento mensual, mantenimiento bimestral, mantenimiento general,
reparación, servicio no incluido en póliza, servicio incluido en póliza y garantía) y
estado.
8. Los datos a mostrarse son como en el formato 8.4
9. Los resultados se pueden exportar en formato XLS y CSV.
75
3.1.8.4 Formato: Reporte de centros x concepto de servicio (tipo de solicitud) Tabla 5: Formato 8.4 Reporte de centros x concepto de servicio (tipo de solicitud)
Fuente: Elaboración propia
MEDIOS Y PROCEDIMIENTOS TECNOLÓGICOS
REPORTE DE CENTROS x CONCEPTO DE SERVICIO (TIPO DE SOLICITUD)
Centro Concepto de servicio
(Tipo de solicitud)
estado cantidad
Requerimiento 8.5: El escenario 8.4 Reporte de centros x concepto de servicio (tipo de
solicitud), deberá ser soportado por el sistema.
Escenario 8.5 Reporte de técnicos x concepto de servicio (tipo de solicitud)
Precondición: Existen solicitudes de servicio iniciadas, asignadas o finalizadas.
1. Para el cliente, se muestran sólo las relacionadas con su centro de servicio.
2. Para el técnico, se muestran las iniciadas y las asignadas o finalizadas por él.
3. Es visible para el administrador y contador, se muestran todos los centros y técnicos.
4. Las solicitudes se pueden filtrar por un intervalo de fechas (inicio y fin), se muestra
el total de solicitudes obtenidas.
5. Las solicitudes se pueden filtrar por centro.
6. Los filtros son mutuamente incluyentes.
7. Los datos se agrupan por técnico, concepto de servicio (tipo de solicitud:
mantenimiento mensual, mantenimiento bimestral, mantenimiento general,
reparación, servicio no incluido en póliza, servicio incluido en póliza y garantía) y
estado.
8. Los datos a mostrarse son como en el formato 8.5
9. Los resultados se pueden exportar en formato XLS y CSV.
76
3.1.8.5 Formato: Reporte de técnicos x concepto de servicio (tipo de solicitud) Tabla 6: Formato 8.5 Reporte de técnicos x concepto de servicio (tipo de solicitud)
Fuente: Elaboración propia
MEDIOS Y PROCEDIMIENTOS TECNOLÓGICOS
REPORTE DE TÉCNICOS x CONCEPTO DE SERVICIO (TIPO DE SOLICITUD)
Técnico Concepto de servicio (tipo de solicitud)
estado cantidad
Requerimiento 8.6: El escenario 8.5 Reporte de técnicos x concepto de servicio (tipo de
solicitud), deberá ser soportado por el sistema
Escenario 8.6 Reporte de opciones: Ecológico/Local
Precondición: Existen solicitudes de servicio iniciadas, asignadas o finalizadas.
1. Es visible para el administrador y contador.
2. Las solicitudes se pueden filtrar por un intervalo de fechas (inicio y fin), se muestra
el total de solicitudes obtenidas.
3. Las solicitudes se pueden filtrar por opción: Ecológico/Local.
4. Los datos de los centros se agrupan por centro, opción y estado.
5. Los datos a mostrarse son como en el formato 8.6
6. Los resultados se pueden exportar en formato XLS y CSV.
77
3.1.8.6 Formato: Reporte de opciones: Ecológico/Local Tabla 7: Formato 8.6 Reporte de opciones: Ecológico/Local
Fuente: Elaboración propia
MEDIOS Y PROCEDIMIENTOS TECNOLÓGICOS
REPORTE DE OPCIONES
Centro Opción estado cantidad
RF 8.7: El escenario 8.6 Reporte de opciones: Ecológico/Local, deberá ser soportado por
el sistema
3.2 Requerimientos no Funcionales (RNF) A continuación, se muestra la declaración de los principales requerimientos no funcionales
que son necesarios para cualquier sistema, y en específico los requeridos para el SASM,
como son los relacionados a la calidad (manual de usuario, mensajes de error e información
para usuarios y disponibilidad del sistema), de la arquitectura física del sistema (servidor de
aplicaciones, lenguaje de programación, base de datos y número de usuarios), de la
arquitectura lógica del sistema (diagramas de casos de uso, conceptual, de clases,
interacción, estados y componentes) y del modelo de datos.
3.2.1 RNF: Generales (manejo y detección de errores, modelado UML, respaldo de BD, tiempo de respuesta razonable y protección de datos personales)
RNF 1.1: Manejo y detección de errores
El sistema debe ser capaz de manejar y detectar errores. Ningún tipo de entrada incorrecta
debería ser capaz de colapsar el sistema o corromper los datos del sistema. Verificar tipos
de datos en secciones anteriores.
RNF 1.2: Modelado UML
El modelado del sistema debe realizarse usando UML
RNF 1.3: Respaldo de BD cada 24 horas
78
La base de datos debe respaldarse cada 24 horas. Los respaldos deben ser almacenados
en dos dispositivos diferentes.
RNF 1.4: Tiempo de respuesta razonable
Toda funcionalidad del sistema y transacción de negocio debe responder al usuario en un
tiempo razonable.
RNF 1.5: Protección de datos personales
El sistema no revelara a sus operadores otros datos personales de los clientes distintos a
nombres y números de referencia.
3.2.2 RNF: Calidad (manual de usuario, mensajes de error e información para usuarios y disponibilidad del sistema)
En esta sección se muestran los principales requerimientos no funcionales relacionados a
la calidad, que son necesarios para cualquier sistema, y en específico los requeridos para
la calidad del SASM.
RNF 2.1: Manual de usuario
El sistema debe contar con manuales de usuario estructurados adecuadamente.
RNF 2.2: Mensajes de error e información para los usuarios
El sistema debe proporcionar mensajes de error que sean informativos y orientados a
usuario final.
RNF 2.3: Disponibilidad del sistema
El sistema debe tener una disponibilidad del 97% de las veces en que un usuario intente
acceder.
3.2.3 RNF: Arquitectura Física del Sistema (servidor de aplicaciones, lenguaje de programación, base de datos y cantidad de usuarios)
Ahora, se muestran los principales requerimientos no funcionales que son necesarios para
cualquier sistema, y en específico los requeridos para la arquitectura del SASM.
RNF 3.1: Servidor de aplicaciones GlassFish
El sistema debe utilizar como servidor de aplicaciones Glassfish.
RNF 3.2: Desarrollo en Java 1.8
El sistema debe ser desarrollado en la plataforma Java 1.8.
79
RNF 3.3: Base de Datos MySQL 5.5
Una base de datos MySQL 5.5 debe ser utilizada por el sistema SASM para guardar los
datos que deben persistir entre sesiones.
RNF 3.4: El sistema debe soportar 100 usuarios promedio con tres accesos promedio al día
La cantidad de usuarios puede aumentar.
3.2.4 RNF: Arquitectura lógica del sistema (diagramas: casos de uso, conceptual, clases, interacción, estados, componentes y cronograma)
Aquí se plasman, los principales requerimientos no funcionales que son necesarios para la
arquitectura lógica de cualquier sistema, y en específico para la arquitectura lógica del
SASM.
Los siguientes requisitos también sirven como documentación del SASM.
RNF 4.1: Diseñar los diagramas de casos de uso.
Desarrollar los principales casos de uso del sistema propuesto.
RNF 4.2: Diseñar el diagrama el conceptual.
Desarrollar un diagrama conceptual para el sistema propuesto.
RNF 4.3: Diseñar los diagramas de clase.
Desarrollar los diagramas de clase del sistema propuesto.
RNF 4.4: Diseñar los diagramas de interacción.
Desarrollar los diagramas de interacción para el sistema propuesto.
RNF 4.5: Diseñar los diagramas estado.
Desarrollar los diagramas de estado para el sistema propuesto.
RNF 4.6: Diseñar el diagrama de componentes o interfaces.
Desarrollar el diagrama de componentes del sistema propuesto.
RNF 4.7: Definir el cronograma del proyecto
Desarrollar el cronograma del proyecto para el desarrollo del SASM.
80
3.2.5 RNF: Modelo de datos A continuación, se muestran los principales requerimientos no funcionales que son
necesarios para el modelado de datos de cualquier sistema, y en específico para modelar
el SASM. El desarrollo de estos requisitos, también sirven como parte de la documentación
del sistema SASM.
RNF 5.1: Incluir el diagrama entidad relación del sistema.
Desarrollar el diagrama de entidad relación del sistema propuesto.
RNF 5.2: Debe modelar la base de datos del sistema usando un diagrama relacional.
Modelar la base de datos del sistema propuesto, usando un diagrama relacional.
RNF 5.3: Integrar el diccionario de datos.
Desarrollar el diccionario de datos como parte de la documentación.
81
3.3 CASOS DE USO Se describen los principales diagramas de casos de uso para el sistema SASM y están
basados en la especificación de requerimientos de software que es responsable de
gestionar el proceso de los servicios de mantenimiento.
3.3.1 Caso de uso general del sistema SASM Los actores interactúan con el sistema a través de diferentes módulos, se requiere de
identificación en el sistema (ver Figura 15).
Figura 15: Caso de uso general del SASM
Fuente: Elaboración propia
82
3.3.2 Login Acceso al sistema y control de sesiones, en la figura 16 se puede apreciar brevemente el
caso de uso correspondiente al sistema Login
Figura 16: Caso de uso de acceso al sistema: Login
Fuente: Elaboración propia
3.3.3 Administrar catálogos Casos de uso dentro de la administración de catálogos (ver figura 17).
Figura 17: Caso de uso: Administrar catálogos
Fuente: Elaboración propia
83
3.3.4 Crear Solicitud Casos de uso dentro de las solicitudes que pueden ser de servicio o mantenimiento (ver
Figura 18).
Figura 18: Caso de uso: Crear solicitud de servicio o mantenimiento
Fuente: Elaboración propia
84
3.3.5 Consultar solicitud Casos de uso generados a partir de la consulta de una solicitud (ver Figura 19).
Figura 19: Caso de uso: Consultar solicitud
Fuente: Elaboración propia
85
3.3.6 Capturar Adeudos Casos de uso para la captura de adeudos ver figura 20.
Figura 20: Caso de uso: Captura de adeudos
Fuente: Elaboración propia
86
3.3.7 Generar Reportes Casos de uso para generación de reportes, ver figura 21.
Figura 21: Caso de uso: Generar reportes
Fuente: Elaboración propia
87
3.3.8 Lista de casos de uso Tabla 8: Listado de los casos de uso
Fuente: Elaboración propia
ID Prioridad Descripción
SSN.1 ALTA Crear sesión
SSN.2 BAJA Cerrar sesión
SSN.3 BAJA Expira sesión
SSN.4 BAJA Reanudar sesión
USR.1 ALTA Crear usuario
USR.2 MEDIA Modificar usuario
CSRV.1 ALTA Crear centro de servicio
CSRV.2 MEDIA Modificar centro de servicio
CADD.1 ALTA Crear concepto de adeudo
CADD.2 ALTA Modificar concepto de adeudo
SLC.1 ALTA Crear solicitud
SLC.2 BAJA Reporte de solicitud de mantenimiento
SLC.3 BAJA Reporte de solicitud de servicio
SLC.4 MEDIA Consulta de solicitud iniciada
SLC.5 MEDIA Modificar solicitud iniciada
SLC.6 MEDIA Asignación de técnico
SLC.7 BAJA Cancelar solicitudes
SLC.8 MEDIA Consulta de solicitud asignada
SLC.9 MEDIA Modificar solicitud asignada
SLC.10 MEDIA Finalizar solicitud asignada
SLC.11 MEDIA Consulta de solicitud finalizada
ADD.1 BAJA Consulta de adeudo
ADD.2 BAJA Captura de adeudo
RPT.1 BAJA Reporte estado de solicitud
RPT.2 BAJA Reporte de adeudos
RPT.3 BAJA Reporte de computo
RPT.4 BAJA Reporte centros por tipo de solicitud
RPT.5 BAJA Reporte de técnicos por tipo de solicitud
RPT.6 BAJA Reporte de opciones
Las descripciones de los casos de uso se localizan en el anexo A.
89
4 CAPÍTULO IV. DISEÑO DEL SISTEMA DE ADMINISTRACIÓN DE LOS SERVICIOS DE MANTENIMIENTO (SASM)
El presente capítulo toma los requerimientos identificados en el capítulo de análisis y las
funcionalidades requeridas por el sistema y se concretan dichas especificaciones mediante
el diseño de la arquitectura lógica, física, el modelo de datos y las interfaces de usuario.
El Diseño del sistema sirve para describir, organizar y estructurar sus componentes, tanto
a nivel arquitectónico como a nivel detallado, necesario para construir el sistema propuesto.
4.1 Arquitectura Lógica La arquitectura lógica, es el diseño a alto nivel de la estructura del sistema, que proporciona
un marco definido para su implementación. También es una actividad de modelaje de los
requisitos y este modelo representa un acercamiento a la solución.
4.1.1 Diagrama de componentes del sistema Los diagramas de componentes ofrecen a los arquitectos un formato natural para comenzar
a modelar una solución. Los diagramas de componentes permiten a un arquitecto verificar
que la funcionalidad requerida del sistema está siendo implementada por los componentes,
asegurando así que el sistema final sea aceptable.
En esta sección se presentan diagramas de componentes, utilizando la notación UML 2,
para el sistema SASM.
Ilustran las piezas de software, controladores embebidos, etc. que conformarían el sistema.
El diagrama de componentes tiene un nivel de abstracción más alto que un diagrama de
clase, usualmente un componente se implementa por una o más clases en tiempo de
ejecución. Un componente puede comprender una gran porción del sistema (ver figura 22).
90
Figura 22: Diagrama de componentes del SASM
Fuente: Elaboración propia
4.1.2 Diagramas de secuencia El diagrama de secuencia se utiliza principalmente para mostrar las interacciones entre
objetos en el orden secuencial en que se producen dichas interacciones. Una organización
puede encontrar diagramas de secuencia útiles para comunicar cómo funciona el negocio
en la actualidad, mostrando cómo interactúan los diversos objetos de negocios. Además de
documentar los asuntos actuales de una organización.
Los diagramas de secuencia están referenciados a los casos de uso, para mayor
información consultar el documento CU-SASM.
• Sirven para mostrar qué objetos se comunican con qué otros objetos, a través de
qué métodos y qué mensajes disparan esas comunicaciones.
• Se utilizan para diseñar la lógica y el comportamiento del sistema.
• No están pensados para mostrar lógicas de procedimientos complejos.
• Los diagramas de UML que representan el modelo dinámico incluyen diagrama de
secuencia, diagrama de comunicación.
91
Acceso al sistema
CU referenciados: SSN.1, SSN. 2
Actor: Administrador, técnico, contador, cliente (ver figura 23)
Figura 23: Diagrama de secuencia: Acceso al sistema
Fuente: Elaboración propia
Expirar y reanudar sesión
CU referenciados: SSN.3, SSN.4
Actor: Administrador, técnico, contador, cliente(ver figura 24)
Figura 24: Diagrama de secuencia: Expirar y reanudar sesión
Fuente: Elaboración propia
92
Crear usuario
CU referenciados: USR.1
Actor: Administrador (ver figura 25)
Figura 25: Diagrama de secuencia: Crear usuario
Fuente: Elaboración propia
Modificar usuario
CU referenciados: USR.2 Actor: Administrador (ver figura 26)
Figura 26: Diagrama de secuencia: Modificar usuario
Fuente: Elaboración propia
93
Habilitar/Inhabilitar usuario
CU referenciados: USR.2
Actor: Administrador (ver figura 27)
Figura 27: Diagrama de secuencia: Habilitar/Inhabilitar usuario
Fuente: Elaboración propia
Crear centro de servicio
CU referenciados: CSRV.1
Actor: Administrador (Ver figura 28)
Figura 28: Diagrama de secuencia: Crear centro de servicio
Fuente: Elaboración propia
94
Modificar centro de servicio
CU referenciados: CSRV.2
Actor: Administrador (ver figura 29)
Figura 29: Diagrama de secuencia: Modificar centro de servicio
Fuente: Elaboración propia
Habilitar/inhabilitar centro de servicio
CU referenciados: CSRV.2
Actor: Administrador (Ver figura 30)
Figura 30: Diagrama de secuencia: Habilitar/inhabilitar centro de servicio
Fuente: Elaboración propia
95
Crear concepto de adeudo
CU referenciados: CADD.1
Actor: Administrador (Ver Figura 31)
Figura 31: Diagrama de secuencia: Crear concepto de adeudo Fuente: Elaboración propia
Modificar concepto de adeudo
CU referenciados: CADD.2 Actor: Administrador (Ver Figura 32)
Figura 32: Diagrama de secuencia: Modificar concepto de adeudo
Fuente: Elaboración propia
96
Crear solicitud
CU referenciados: SLC.1, SLC.2, SLC.3
Actor: Administrador, técnico, cliente ( Ver Figura 33)
Figura 33: Diagrama de secuencia: Crear solicitud
Fuente: Elaboración propia
97
Consultar solicitud
CU referenciados: SLC.4, SLC.8, SLC.11
Actor: Administrador, técnico, cliente (Ver Figura 34)
Figura 34: Diagrama de secuencia: Consultar solicitud
Fuente: Elaboración propia
98
Modificar solicitud iniciada
CU referenciados: SLC.5
Actor: Administrador, técnico, cliente (Ver Figura 35)
Figura 35: Diagrama de secuencia: Modificar solicitud iniciada
Fuente: Elaboración propia
Asignación de técnico
CU referenciados: SLC.6
Actor: Administrador (Ver Figura 36)
Figura 36: Diagrama de secuencia: Asignación de técnico
Fuente: Elaboración propia
99
Cancelar solicitud iniciada
CU referenciados: SLC.7
Actor: Administrador, técnico, cliente (Ver Figura 37)
Figura 37: Diagrama de secuencia: Cancelar solicitud iniciada
Fuente: Elaboración propia
Cancelar solicitud asignada
CU referenciados: SLC.7
Actor: Administrador, técnico, cliente (ver figura 38)
Figura 38: Diagrama de secuencia: Cancelar solicitud asignada
Fuente: Elaboración propia
100
Modificar solicitud asignada
CU referenciados: SLC.9
Actor: Administrador, técnico, cliente (ver figura 39)
Figura 39: Diagrama de secuencia: Modificar solicitud asignada
Fuente: Elaboración propia
101
Finalizar solicitud asignada
CU referenciados: SLC.10
Actor: Administrador, técnico (Ver Figura 40)
Figura 40: Diagrama de secuencia: Finalizar solicitud asignada
Fuente: Elaboración propia
102
Consulta de adeudo
CU referenciados: ADD.1
Actor: Administrador, contador (ver figura 41)
Figura 41: Diagrama de secuencia: Consulta de adeudo
Fuente: Elaboración propia
Captura de adeudo
CU referenciados: ADD.2
Actor: Administrador, contador (ver figura 42)
Figura 42: Diagrama de secuencia: Captura de adeudo
Fuente: Elaboración propia
103
Consulta y generación de reportes
CU referenciados: RPT.1, RPT.2, RPT.3, RPT.4, RPT.5, RPT.6,
Actor: Administrador, contador (ver figura 43)
Figura 43: Diagrama de secuencia: Consulta y generación de reportes
Fuente: Elaboración propia
104
4.1.3 Diagramas de estado
Los diagramas de la máquina de estados de UML representan los diversos estados en los
que un objeto puede estar y las transiciones entre esos estados. De hecho, en otros
lenguajes de modelado, es común que este tipo de diagrama se llame diagrama de
transición de estados o simplemente diagrama de estados. Un estado representa una etapa
en el patrón de comportamiento de un objeto, y como los diagramas de actividad UML es
posible tener estados iniciales y estados finales. Un estado inicial, también llamado estado
de creación, es aquel en el que se encuentra un objeto cuando se crea por primera vez,
mientras que un estado final es aquel en el que no se producen transiciones. Una transición
es una progresión de un estado a otro y se desencadenará por un evento interno o externo
al objeto.
Acceso al sistema
Figura 44: Diagrama de estado: Acceso al sistema
Fuente: Elaboración propia
105
Administración de usuario
Figura 45: Diagrama de estado: Administración de usuario
Fuente: Elaboración propia
Administración de centro de servicio
Figura 46: Diagrama de estado: Administración de centro de servicio
Fuente: Elaboración propia
106
Administración de concepto de adeudo
Figura 47: Diagrama de estado: Administración de concepto de adeudo
Fuente: Elaboración propia
Administrar solicitud
Figura 48: Diagrama de estado: Administrar solicitud
Fuente: Elaboración propia
107
Administración de adeudo
Figura 49: Diagrama de estado: Administración de adeudo Fuente: Elaboración propia
Consultar y generar reportes
Figura 50: Diagrama de estado: Consultar y generar reportes Fuente: Elaboración propia
108
4.1.4 Diagramas de actividad Los diagramas de actividad se utilizan normalmente para modelar los procesos del negocio,
para modelar la lógica capturada por un caso de uso único o escenario de uso, o para
modelar la lógica detallada de una regla del negocio. Aunque los diagramas de actividad
UML podrían potencialmente modelar la lógica interna de una operación compleja, sería
mucho mejor simplemente reescribir la operación para que sea lo suficientemente simple
como para no requerir un diagrama de actividad. En muchos sentidos, los diagramas de
actividad UML son el equivalente orientado a objetos de diagramas de flujo y diagramas de
flujo de datos (DFDs) del desarrollo estructurado.
Esta sección presenta los diagramas de actividad para el SASM.
Acceso al sistema
Figura 51: Diagrama de actividad: Acceso al sistema
Fuente: Elaboración propia
109
Alta de usuarios
Figura 52: Diagrama de actividad: Alta de usuarios
Fuente: Elaboración propia
110
Modificar usuario
Figura 53: Diagrama de actividad: Modificar usuario Fuente: Elaboración propia
Alta de centro de servicio
Figura 54: Diagrama de actividad: Alta de centro de servicio
Fuente: Elaboración propia
111
Modificar centro de servicio
Figura 55: Diagrama de actividad: Modificar centro de servicio
Fuente: Elaboración propia
112
Alta de concepto de adeudo
Figura 56: Diagrama de actividad: Alta de concepto de adeudo
Fuente: Elaboración propia
113
Modificar concepto de adeudo
Figura 57: Diagrama de actividad: Modificar concepto de adeudo
Fuente: Elaboración propia
114
Alta de solicitud
Figura 58: Diagrama de actividad: Alta de solicitud
Fuente: Elaboración propia
115
Consulta de solicitud
Figura 59: Diagrama de actividad: Consulta de solicitud Fuente: Elaboración propia
Modificar solicitud
Figura 60: Diagrama de actividad: Modificar solicitud
Fuente: Elaboración propia
116
Eliminar solicitud
Figura 61: Diagrama de actividad: Eliminar solicitud
Fuente: Elaboración propia
117
Asignar solicitud
Figura 62: Diagrama de actividad: Asignar solicitud
Fuente: Elaboración propia
118
Finalizar solicitud
Figura 63: Diagrama de actividad: Finalizar solicitud
Fuente: Elaboración propia
119
Consulta de adeudo
Figura 64: Diagrama de actividad: Consulta de adeudo
Fuente: Elaboración propia
Captura de adeudo
Figura 65: Diagrama de actividad: Captura de adeudo
Fuente: Elaboración propia
120
4.1.5 Diagrama de clases Muestra las clases del sistema, sus interrelaciones, sus atributos y métodos. Los diagramas
de clase se utilizan para una amplia variedad de propósitos, incluyendo tanto el modelado
conceptual/dominio como el modelado de diseño detallado.
Figura 66: Diagrama de clases Fuente: Elaboración propia
121
4.1.6 Diagrama de despliegue del SASM Los diagramas de despliegue muestran el hardware para el sistema, el software que está
instalado en ese hardware y el middleware utilizado para conectar los equipos dispares
entre sí. También se pueden crear diagramas de despliegue para explorar la arquitectura
de los sistemas integrados, mostrando cómo funcionan juntos los componentes de
hardware y software.
El sistema SASM se describe en el siguiente diagrama de despliegue (ver figura 67).
Figura 67: Diagrama de despliegue del SASM
Fuente: Elaboración propia
122
4.2 Arquitectura Física La arquitectura usada para el desarrollo del sistema es una arquitectura n-capas con
enfoque cliente-servidor que será accesada vía web por los usuarios comunes del sistema
los clientes, técnicos y contadores, quienes acceden para hacer parte de sus labores diarias
dentro de la empresa y como parte del proceso de administración de solicitudes, también
se identificó a usuarios administradores del sistema que acceden para realizar
mantenimiento de la aplicación, administración de la seguridad, actualización de, catálogos
y decisiones que requieren de un usuario experto. Todos los tipos de usuarios podrán
acceder a la aplicación a través de un navegador web, el cual se comunicará con el servidor.
El servidor implementa las reglas del negocio y controla los accesos del usuario además de
verificar que los datos sean almacenados en la base de datos
Un estilo arquitectónico, a veces llamado patrón arquitectónico, es un conjunto de reglas y
principios que proporcionan una estructura abstracta para una familia de sistemas. Un estilo
arquitectónico mejora la división y promueve la reutilización del diseño al proporcionar
soluciones a problemas frecuentes.
Tabla 9: Estilo/Patrón arquitectónico Fuente: Elaboración propia
Estilo de arquitectura
Descripción
Cliente/Servidor Separa el sistema en dos aplicaciones, donde el cliente realiza peticiones al servidor. En algunos casos, el servidor es una base de datos con lógica de aplicación representada como procedimientos almacenados.
Arquitectura basada en componentes
Descompone el diseño de la aplicación en componentes funcionales o lógicos reutilizables que exponen interfaces de comunicación bien definidas.
Orientado a objetos Un paradigma de diseño basado en la división de responsabilidades para una aplicación o sistema en objetos individuales reutilizables y autosuficientes, cada uno de los cuales contiene los datos y el comportamiento relevante al objeto.
Modelo Vista Controlador (MVC)
Es un patrón de arquitectura de software, que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario.
Una combinación de estilos de arquitectura permitirá lograr una separación efectiva de los
módulos utilizando el estilo de arquitectura en capas. Esto separa la lógica de presentación
de la lógica de negocio y de acceso a los datos.
123
4.2.1 Capas El sistema SASM es una aplicación web bajo la especificación J2EE, con una arquitectura
de N-capas. Usando JSF podemos tener un manejo de capas permite definir un conjunto
simple de clases base de Java para componentes de la interfaz de usuario, estado de los
componentes y eventos de entrada. Estas clases tratarán los aspectos del ciclo de vida de
la interfaz de usuario, controlando el estado de un componente durante el ciclo de vida de
su página.
Presentación
● Vista: Páginas web usando componentes de PrimeFaces para la interfaz de
usuario, incluyendo los elementos estándares de HTML para representar un
formulario. Además con PrimeFaces logramos automatizar la generación de salidas
apropiadas para las interfaces de usuario, teniendo en cuenta que los componentes
han sido probados en las últimas versiones de los navegadores más comunes.
● Controladores: JSF automatiza la generación de salidas apropiadas para el
objetivo del cliente, teniendo en cuenta todos los datos de configuración disponibles
del cliente, como versión del navegador. Los estilos de las páginas se definen
usando CSS3.
● Objetos de la vista: objetos reutilizados de la capa de modelo de dominio.
Lógica de Negocios
● Servicios: contiene los componentes encargados de ejecutar procesos complejos
de la lógica de negocio. Estos componentes interactúan con los objetos del modelo
de dominio. Usando el framework de Spring los objetos son creados y gestionados
por el Contenedor de Spring, usando inyección de dependencias se obtiene un
código más desacoplado que permite cambiar partes del sistema más fácilmente en
caso de que fuese necesario.
● Modelo de dominio: componentes con la estructura conceptual que representa el
dominio de la aplicación, en la forma de JavaBeans u POJO’s de java.
124
Datos
● DAO es un objeto de acceso a datos (en inglés, data access object, abreviado DAO)
es un componente de software que suministra una interfaz común entre la aplicación
y uno o más dispositivos de almacenamiento de datos, tales como una Base de
datos o un archivo.
● ORM El mapeo objeto-relacional (más conocido por su nombre en inglés, Object-
Relational mapping, o sus siglas O/RM, ORM, y O/R mapping) es una técnica de
programación para convertir datos entre el sistema de tipos utilizado en un lenguaje
de programación orientado a objetos y la utilización de una base de datos relacional
como motor de persistencia.
4.2.2 Representación de la arquitectura de 3 capas El siguiente diagrama (Figura 68) se presenta las capas del SASM y los elementos que la
integran.
Figura 68: Arquitectura de 3 capas del SASM Fuente: Elaboración propia
125
4.2.3 Infraestructura ● Spring es un framework liviano y no intrusivo: generalmente los objetos que
programamos no tienen dependencias en clases específicas de Spring. Sus
características principales son inyección de dependencias y programación
orientada a aspectos.
● JavaServer Faces 2.2 (JSF) es una tecnología y framework para aplicaciones Java
basadas en web que simplifica el desarrollo de interfaces de usuario en aplicaciones
Java EE. JSF usa JavaServer Pages (JSP) como la tecnología que permite hacer
el despliegue de las páginas
● PrimeFaces 5.1 es un componente para JavaServer Faces (JSF) de código abierto
que cuenta con un conjunto de componentes ricos que facilitan la creación de las
aplicaciones web. Primefaces está bajo la licencia de Apache License V2.
● MySQL 5.7 es un sistema de gestión de bases de datos relacional, multihilo y
multiusuario con más de seis millones de instalaciones.1 MySQL AB —desde enero
de 2008 una subsidiaria de Sun Microsystems y ésta a su vez de Oracle Corporation
desde abril de 2009— desarrolla MySQL como software libre en un esquema de
licenciamiento dual.
● GlassFish es un servidor de aplicaciones de software libre desarrollado por Sun
Microsystems, compañía adquirida por Oracle Corporation, que implementa las
tecnologías definidas en la plataforma Java EE y permite ejecutar aplicaciones que
siguen esta especificación. Es gratuito, de código libre y se distribuye bajo un
licenciamiento dual a través de la licencia CDDL y la GNU GPL. La versión comercial
es denominada Oracle GlassFish Enterprise Server (antes Sun GlassFish Enterprise
Server).
126
4.2.4 Ambientes del sistema Se recomienda ampliamente crear los siguientes ambientes para desplegar el sistema
SASM.
1. Entorno de producción (PROD): El entorno de producción es el entorno de acceso
público SASM desde Internet. La última versión estable se despliega en la
producción acorde con los requerimientos del SASM.
2. Entorno de preproducción (PREPROD): El entorno de preproducción es una
réplica exacta del entorno de producción en términos de despliegue de aplicaciones
y topología de servidores. Contiene la misma versión que el entorno de producción.
Se utiliza para la replicación/prueba de problemas; para el entorno de producción.
La corrección de errores, se implementan primero en el ambiente de preproducción.
3. Entorno de pruebas (TEST): El entorno de pruebas es una réplica exacta del
entorno de producción en términos de despliegue de aplicaciones y topología de
servidores. La distribución de servidores de aplicaciones en las máquinas virtuales,
pueden diferir del entorno de producción. El entorno de pruebas contiene la
siguiente versión que se va a implementar en el entorno de producción. El entorno
de prueba es abierto al personal de la empresa, para probar las nuevas
funcionalidades, correcciones, etc.
4. Entorno de desarrollo (DEV): El entorno de desarrollo es una réplica exacta del
entorno de producción en términos de despliegue de aplicaciones y topología de
servidores. La distribución de servidores de aplicaciones en máquinas virtuales
puede diferir del entorno de producción. El entorno de desarrollo está siendo
sincronizado continuamente con el repositorio de desarrollo del SASM y contiene la
última rama de trabajo.
127
4.2.5 Recomendaciones de hardware para producción La recomendación óptima para el buen desempeño del sistema se describe en la tabla 10:
Tabla 10: Recomendación de HW para el ambiente de producción del SASM Fuente: Elaboración propia
Ambiente recomendado para producción
Arquitectura x86_64
Sistema operativo Red Hat Enterprise Linux Server release 7.3, ó
Windows Server 2012, Windows server 2016
CPU mínimo 2x 64bit Xeon Dual Core RAM mínimo recomendado 16GB
JVM Java Sun 1.8.0_121
Servidor de aplicaciones Oracle GlassFish Server 3.1.2
Servidor de base de datos MySql community Server 5.7
128
4.3 Modelo de datos Por lo general, se suele crear un modelo de datos para describir la estructura de los datos
tratados en los sistemas de información y que persisten en los sistemas de gestión de bases
de datos. Esa estructura a menudo se representa en la relación de entidades
diagramas o diagramas de clase UML. Estos diagramas muestran básicamente las
entidades de datos y sus relaciones. Esta sección presenta el diagrama Entidad Relación,
Modelo relacional y diccionario de datos para el sistema SASM.
El modelo de datos del SASM contiene información arquitectónica importante y sirve para
los siguientes propósitos prácticos:
● Proporcionar una descripción conceptual de los objetos en el sistema y sus
relaciones.
● Proporcionar un modelo para crear la estructura de la base de datos.
● Guiar la implementación de las unidades de código que acceden a la base de datos.
● Guiar las mejoras de rendimiento en las operaciones de acceso a datos.
● Sirve como entrada para la generación automática del esquema de base de datos y
código de acceso a los datos.
● Facilitar la comunicación con las partes interesadas en el análisis de los dominios y
las tareas de obtención de requisitos.
Los diagramas corresponden a tres etapas del diseño
Conceptual. Diagrama ER: El modelo de datos conceptual resume los detalles de
implementación para centrarse en las entidades y sus relaciones y propiedades que se
generan en el ámbito del problema. Es el modelo más adecuado para la comunicación con
los grupos de interés en general.
Lógico. Modelo relacional: El modelo lógico de datos es una evolución del modelo
conceptual de datos hacia una tecnología de gestión de datos (por ejemplo, bases de datos
relacionales).
Físico. Diccionario de datos: El modelo de datos físicos se refiere a la implementación de
las entidades de datos. Incorpora optimizaciones que pueden incluir particiones o entidades
fusionadas, duplicando datos, creando claves e índices de identificación.
129
4.3.1 Diagrama Entidad Relación
Figura 69: Diagrama Entidad Relación
Fuente: Elaboración propia
130
4.3.2 Modelo de datos relacional
Figura 70: Modelo de Datos Relacional
Fuente: Elaboración propia
131
4.3.3 Diccionario de datos Tabla 11: Diccionario de Datos Fuente: Elaboración propia
Tabla Nombre Llave
primaria
Tipo Longitud Precisión
Nulo Descripción
adeudo
id_adeudo PK bigint 13 no Identificación del adeudo
Iva decimal 10,2 si IVA del costo
costo decimal 10,2 si Costo del servicio
estado varchar 120 no Estado del adeudo
cat_adeudo
id_catadeudo PK bigint 0 no Identificación del adeudo
tienecosto decimal 10,2 no Bandera para indicar si el tipo de adeudo tiene un costo
nombre varchar 400 no Nombre del concepto de adeudo
cat_estado id_catestado PK bigint 13 no Identificación del estado
nombre varchar 120 no Nombre del estado de la república
cat_rol
id_catrol PK bigint 13 no Identificación del rol
Nombre varchar 80 no Nombre del rol
activo boolean 0 no Si el registro está activo
cat_servicio
id_catservicio PK bigint 13 no Identificación del servicio
nombre varchar 250 no Nombre del servicio
activo boolean 0 no Si el registro está activo
cat_tipousuario
d_cattipousuario PK bigint 13 no Identificación del tipo de usuario
nombre varchar 80 no Nombre del tipo de usuario
activo boolean 0 no Si el registro está activo
cat_usuario
paterno varchar 80 no Apellido paterno del usuario
Materno varchar 80 si Apellido materno del usuario
correo varchar 50 no correo electrónico del usuario
telefono varchar 20 no Teléfono del usuario
usuario varchar 10 no Nombre de usuario del sistema
id_catusuario PK bigint 13 no Identificación del usuario
activo boolean 0 no Si el usuario está activo
132
Clave varchar 10 no Contraseña del usuario
Nombre varchar 80 no Nombre propio del usuario
centro_servicio
calle varchar 250 no Calle del centro de servicio
RFC varchar 13 no Registro federal de contribuyentes
activo boolean 0 no Si el registro está activo
numerocentro varchar 12 no Número del centro de servicio
colonia varchar 120 no Colonia del centro de servicio
codigopostal varchar 5 no Código postal
id_centroservicio PK bigint 13 no Identificador del registro
razonsocial varchar 250 no Nombre del centro de servicio
Cierre
material varchar 1200 si Material usado en el servicio
solucion varchar 1200 no Solución aplicada en el servicio
id_solicitud PK bigint 13 no Identificador del registro
computo
solucion varchar 1200 no Solución aplicada en el cómputo
material varchar 1200 si Material usado en el cómputo
id_solicitud PK bigint 13 no Identificador del registro
Solicitud
id_solicitud PK bigint 13 no Identificador del registro
comentario varchar 1200 si Comentario por parte del técnico
falla varchar 1200 si Falla reportada
estado varchar 20 no estado de la solicitud
fechaalta datetime 0 no fecha en que se creó el registro
fechatatencion datetime 0 si fecha en que se atendió el registro
reportado varchar 120 si Quien reportó las fallas
133
4.4 Interfaces de Usuario (Guías gráficas) Este apartado describe las guías gráficas, que sirven como referencia para el diseño de las
pantallas en la construcción del SASM, agregando consistencia al diseño, tales como las
de acceso al sistema, menú principal del sistema (crear sesión), catálogos de usuario,
centros de servicio, conceptos de adeudo, nueva solicitud de mantenimiento y de servicio,
consulta de solicitudes iniciadas y asignadas, finalización de solicitudes de mantenimiento
y de servicio, consulta de solicitudes finalizadas y de adeudos, captura de adeudos,
reportes del estado de la solicitud, de adeudos, de cómputo, de centros por tipo de solicitud,
de técnicos por tipo de solicitud y de opciones, las cuales se detallan en éste capítulo.
4.4.1 GUI: Acceso al sistema Descripción: Pantalla de bienvenida al sistema
Figura 71: GUI: Acceso al sistema
Fuente: Elaboración propia
134
4.4.2 GUI: Menú principal del sistema Referencia: Caso de uso SSN.1, SSN.2, SSN.3, SSN.4
Descripción: Pantalla de bienvenida al sistema
Figura 72: GUI: Menú principal del sistema
Fuente: Elaboración propia
135
4.4.3 GUI: Catálogos de usuarios, centros de servicio y de conceptos de adeudo Catálogo de usuarios:
Referencia: Caso de uso USR.1, USR.2
Descripción: Pantalla que controla los usuarios, permite la búsqueda, creación y
modificación de usuarios
Figura 73: GUI: Catálogo de usuarios
Fuente: Elaboración propia
136
Catálogo de centros de servicio
Referencia: Caso de uso CSRV.1, CSRV.2
Descripción: Pantalla que controla centros de servicio, permite la búsqueda, creación y
modificación de centros de servicio.
Figura 74: GUI: Catálogo de centros de servicio
Fuente: Elaboración propia
137
Catálogo de conceptos de adeudo
Referencia: Caso de uso CADD.1, CADD.2
Descripción: Pantalla que controla los conceptos de adeudo, permite la búsqueda,
creación y modificación de conceptos de adeudo.
Figura 75: GUI: Catálogo de conceptos de adeudo
Fuente: Elaboración propia
138
4.4.4 GUI: Nuevas solicitudes de mantenimiento y servicio Nueva solicitud de mantenimiento
Referencia: Caso de uso SLC.1
Descripción: Pantalla que permite la creación de una nueva solicitud de mantenimiento.
Figura 76: GUI: Nueva solicitud de mantenimiento
Fuente: Elaboración propia
139
Nueva solicitud de servicio
Referencia: Caso de uso SLC.1, SLC.5
Descripción: Pantalla que permite la creación y modificación de una nueva solicitud de
servicio.
Figura 77: GUI: Nueva solicitud de servicio
Fuente: Elaboración propia
140
4.4.5 GUI: Consulta de solicitudes iniciadas y asignadas Consulta de solicitud iniciada
Referencia: Caso de uso SLC.4, SLC.6
Descripción: Pantalla que permite la consulta de una nueva solicitud, cancelación y
asignación de técnico.
Figura 78: GUI: Consulta de solicitud iniciada
Fuente: Elaboración propia
141
Consulta solicitud asignada
Referencia: Caso de uso SLC.8
Descripción: Pantalla que permite la consulta de una solicitud asignada.
Figura 79: GUI: Consulta de solicitud asignada
Fuente: Elaboración propia
142
4.4.6 GUI: Finalizar solicitudes de mantenimiento y servicio Finalizar solicitud de mantenimiento
Referencia: Caso de uso SLC.10
Descripción: Pantalla que permite la finalizar una solicitud de mantenimiento.
Figura 80: GUI: Finalizar solicitud de mantenimiento
Fuente: Elaboración propia
143
Finalizar solicitud de servicio
Referencia: Caso de uso SLC.10
Descripción: Pantalla que permite la finalizar una solicitud de servicio
Figura 81: GUI: Finalizar solicitud de servicio
Fuente: Elaboración propia
144
4.4.7 GUI: Consulta de solicitudes finalizada y de adeudos Consulta de solicitud finalizada
Referencia: Caso de uso SLC.11
Descripción: Pantalla que permite la consulta de una solicitud finalizada.
Figura 82: GUI: Consulta de solicitud finalizada
Fuente: Elaboración propia
145
Consulta de adeudos
Referencia: Caso de uso ADD.1
Descripción: Pantalla que permite la consulta de adeudos.
Figura 83: GUI: Consulta de adeudos
Fuente: Elaboración propia
146
4.4.8 GUI: Captura de adeudos Referencia: Caso de uso ADD.2
Descripción: Pantalla que permite la captura de adeudos
Figura 84: GUI: Captura de adeudos
Fuente: Elaboración propia
.
147
4.4.9 GUI: Reporte del estado de la solicitud, de adeudos, de cómputo, de centros por tipo de solicitud, de técnicos por tipo de solicitud y de opciones
Reporte del estado de la solicitud
Referencia: Caso de uso RPT.1
Descripción: Pantalla que permite generar el reporte de estado por solicitud
Figura 85: GUI: Reporte del estado de la solicitud Fuente: Elaboración propia
Reporte de adeudos
Referencia: Caso de uso RPT.2
Descripción: Pantalla que permite generar el reporte de adeudos
Figura 86: GUI: Reporte de adeudos
Fuente: Elaboración propia
148
Reporte de cómputo
Referencia: Caso de uso RPT.3
Descripción: Pantalla que permite generar el reporte de cómputo, seleccionando los
valores server, impresión y técnico.
Figura 87: GUI: Reporte de cómputo
Fuente: Elaboración propia
Reporte de centros por tipo de solicitud
Referencia: Caso de uso RPT.4
Descripción: Pantalla que permite generar el reporte de centros por tipo de solicitud.
Figura 88: GUI: Reporte de centros por tipo de solicitud
Fuente: Elaboración propia
149
Reporte de técnicos por tipo de solicitud
Referencia: Caso de uso RPT.5
Descripción: Pantalla que permite generar el reporte de centros por tipo de solicitud.
Figura 89: GUI: Reporte de técnicos por tipo de solicitud
Fuente: Elaboración propia
Reporte de opciones
Referencia: Caso de uso RPT.6
Descripción: Pantalla que permite generar el reporte de opciones: Ecológico y Local
Figura 90: GUI: Reporte de opciones
Fuente: Elaboración propia
150
CONCLUSIONES
El sistema de información web propuesto SASM (Sistema de Administración de los
Servicios de Mantenimiento) se adapta al objetivo planteado que es el incremento en los
niveles de competitividad y productividad mediante la adición de Tecnologías de
Información y Comunicación en una empresa de Construcción de equipos de Verificación
Vehicular. Pues ante la problemática planteada en el que la empresa no cuenta con un
sistema apoyado en las TIC que facilite la administración y/o gestión de los servicios de
mantenimiento y reparaciones de los verificentros; dicha propuesta ayuda a solucionar el
problema planteado de forma efectiva ya que con el diseño presentado aumenta su valor y
mejora el servicio de atención a equipos de mantenimiento, lo cual hace que la empresa
presente una mejora en su posición competitiva.
Además, esta propuesta tiene relación directa con la demanda del negocio, pues el análisis
presentado incluye una infraestructura tecnológica que dan solución al problema planteado
con la oferta informática. Lo cual ofrece nuevas oportunidades de negocio para la empresa
caso de estudio.
151
TRABAJO FUTURO
Una vez desarrollado el sistema propuesto, se puede robustecer con el desarrollo de
nuevos módulos como pueden ser almacén (inventarios), facturación, cuentas por cobrar,
cuentas por pagar y sus respectivos módulos de reporteo, de tal forma que integren
progresivamente más procesos básicos de soporte a las operaciones de la organización
con el fin de hacerla más eficiente.
Una vez desarrollados en un futuro los módulos mencionados, se pueden extender los
beneficios del sistema al integrar a todas las empresas del ramo, lo que el sistema podría
servir a los Gobiernos como un medio de administración y control de las actividades de las
empresas proveedoras de equipos de verificación; ya que actualmente sólo cuentan con
sistemas similares de vigilancia y control sobre verificentros.
152
REFERENCIAS BIBLIOGRÁFICAS
Abrego Almazán, D., Sánchez Tovar, Y., Medina Quintero, J. M., Abrego Almazán, D.,
Sánchez Tovar, Y., & Medina Quintero, J. M. (2017). Influencia de los sistemas de
información en los resultados organizacionales. Contaduría y Administración, 62(2),
303–320. https://doi.org/10.1016/j.cya.2016.07.005
Antonz, M. S., Pozo Rodríguez, J. M., & Cancio, L. P. (2015). ESTUDIO DE APLICACIÓN
DE LAS TIC EN LAS PYMES. 3c Empresa: Investigación y Pensamiento Crítico, 4(1),
69–87. Retrieved from https://dialnet.unirioja.es/servlet/articulo?codigo=4990918
Armijo, M. (2009). Manual de Planificación Estratégica e Indicadores de Desempeño en el
Sector Público. Retrieved from
https://www.cepal.org/ilpes/noticias/paginas/3/38453/manual_planificacion_estrategic
a.pdf
Beck, K. (2000). Extreme programming eXplained : embrace change. Addison-Wesley.
Cervantes Ojeda, J., & Gómez Fuentes, M. del C. (2012). Taxonomía de los modelos y
metodologías de desarrollo de software más utilizados. Universidades, LXII(52).
Retrieved from http://www.redalyc.org/html/373/37326902005/
Correa Espinal, A. A., Gómez Montoya, R. A., & Cano Arenas, J. A. (2010). Gestión de
almacenes y tecnologías de la información y comunicación (TIC). Estudios
Gerenciales, 26(117), 145–171. https://doi.org/10.1016/S0123-5923(10)70139-X
Díaz Estipiñan, S., & Vargas Vargas, I. (2015). Mainpack 10.0. software para la gestión de
la actividad de mantenimiento en la industria azucarera. ICIDCA. Sobre Los Derivados
de La Caña de Azúcar, 49(2), 3–7. Retrieved from
http://www.redalyc.org/articulo.oa?id=223143421001
Ibarra Cisneros, A. M., González Torres, A., & Cervantes Collado, K. (2016). El
aprovechamiento de las TIC en empresas pequeñas y medianas de Baja California,
México: el caso del sector manufacturero. Revista Internacional de Economía y
Gestión de Las Organizaciones, 3(1). Retrieved from
https://journals.epistemopolis.org/index.php/gestion/article/view/1156
Joskowicz, J. (2008). Reglas y Prácticas en eXtreme Programming. Retrieved from
http://iie.fing.edu.uy/~josej/docs/XP - Jose Joskowicz.pdf
Neteris. (2017). La automatización del picking mejora la preparación de pedidos. Retrieved
153
November 11, 2018, from https://blog.neteris.com/stepforward/la-automatizacion-del-
picking-mejora-la-preparacion-de-pedidos
Patricio Letelier, M. C. P. (2012). Métodologías ágiles para el desarrollo de software:
eXtreme Programming (XP). Retrieved from
http://roa.ult.edu.cu/handle/123456789/477
Porter, M. (1987). Competitive Advantage - Creating and Sustaining Superior Performance.
Ramírez, J. L., & De la Vega Tomé, O. (2015). Sistemas de información gerencial e
innovación para el desarrollo de las organizaciones. Télématique: Revista Electrónica
de Estudios Telemáticos, ISSN-e 1856-4194, Vol. 14, No. 2, 2015 (Ejemplar Dedicado
a: TELEMATIQUE), Págs. 201-213, 14(2), 201–213. Retrieved from
https://dialnet.unirioja.es/servlet/articulo?codigo=5157976
Sánchez, C. P., Monelos, P. de L., & López, M. R. (2016). Las TIC como inductores de
competitividad y facilitadores del éxito empresarial. International Journal of Information
Systems and Software Engineering for Big Companies (IJISEBC), 3(1), 8–26.
Retrieved from http://uajournals.com/ojs/index.php/ijisebc/article/view/120/109
SEDEMA. (2017). SECRETARÍA DEL MEDIO AMBIENTE. Retrieved from
http://www.data.sedema.cdmx.gob.mx/centros-verificacion-
vehicular/descargas/Bases-de-la-convocatoria.pdf
Suárez Fragas, Y., Medina Peña, D., & Hernández Alfonso, P. M. (2015). Sistema
automatizado para la gestión del mantenimiento de equipos ... Revista Ciencias
Técnicas Agropecuarias, 24(Especial), 85–90. Retrieved from
http://www.redalyc.org/html/932/93243475015/
Weitzenfeld Ridel, A., & Guardati Buemo, S. (2007). Capítulo 12 Ingeniería de software: el
proceso para el desarrollo de software. Retrieved from
http://weitzenfeld.robolat.org/wp-
content/uploads/2015/01/WeitzenfeldGuardatiComputacion2008.pdf
154
REFERENCIAS ELECTRÓNICAS
Ambiente, P. F. (2015). NOM-041-SEMARNAT-2015. Recuperado el 16 de Enero de 2017,
de http://www.profepa.gob.mx/innovaportal/file/7251/1/nom-041-semarnat-2015.pdf
CAMe, C. A. (2013). Comisión Ambiental de la Megalópolis (CAMe). Recuperado el 13 de
Enero de 2017, de http://www.gob.mx/comisionambiental
Centro Mario Molina para Estudios Estratégicos sobre Energía y Medio Ambiente, A. (2004).
Centro Mario Molina para Estudios Estratégicos sobre Energía y Medio Ambiente,
A.C. Recuperado el 15 de Enero de 2017, de https://centromariomolina.org/
Diario Oficial de la Federación. (2012). NOM-045-SEMARNAT-2006. Recuperado el 16 de
Enero de 2017, de
http://www.dof.gob.mx/nota_detalle.php?codigo=5281443&fecha=06/12/2012
Dirección General de Normas, Subsecretaría de Competitividad y Normatividad, Secretaría
de Economía. (2006-2012). Dirección General de Normas. Recuperado el 16 de
Enero de 2017, de http://www.2006-2012.economia.gob.mx/conoce-la-se/atencion-
ciudadana/procesos-administrativos/dgn
Gobierno de la República Mexicana. (2013). Plan Nacional de Desarrollo 2013-2018.
Recuperado el 19 de 12 de 2016, de http://pnd.gob.mx/wp-
content/uploads/2013/05/PND.pdf
Gobierno del Estado de México. (2005). Código para la Biodiversidad del Estado de México.
Recuperado el 16 de Enero de 2017, de
http://legislacion.edomex.gob.mx/sites/legislacion.edomex.gob.mx/files/files/pdf/co
d/vig/codvig009.pdf
PROFEPA. (1993). NOM-050-SEMARNAT-1993. Obtenido de
http://www.aire.cdmx.gob.mx/descargas/publicaciones/gestion-ambiental-aire-
memoria-documental-2001-2006/descargas/nom_semarnat_050.pdf
PROFEPA. (2014). NOM-047-SEMARNAT-2014. Recuperado el 16 de Enero de 2017, de
http://www.profepa.gob.mx/innovaportal/file/6630/1/nom-047-semarnat-2014.pdf
PROFEPA. (2015). Ley General del Equilibrio Ecológico y Protección al Ambiente.
Recuperado el 16 de Enero de 2017, de
http://www.profepa.gob.mx/innovaportal/file/1133/1/ley_general_del_equilibrio_ecol
ogico_y_la_proteccion_al_ambiente.pdf
155
PROFEPA. (2015). NOM-041-SEMARNAT-2015. Recuperado el 16 de Enero de 2017, de
http://www.profepa.gob.mx/innovaportal/file/1133/1/ley_general_del_equilibrio_ecol
ogico_y_la_proteccion_al_ambiente.pdf
Secretaría de Desarrollo Sustentable (SEDESU), P. E. (2014). Secretaría de Desarrollo
Sustentable (SEDEDU), Poder Ejecutivo del Estado de Querétaro. Recuperado el
14 de Enero de 2017, de http://www.queretaro.gob.mx/sedesu/
SEMARNAT. (2017). NOM-167-SEMARNAT-2017. Obtenido de
http://dof.gob.mx/nota_detalle.php?codigo=5496105&fecha=05/09/2017
SEMARNAT, Poder Ejecutivo Federal. (2000). Secretaria de Medio Ambiente y Recursos
Naturales (SEMARNAT). Recuperado el 12 de Enero de 2017, de
https://www.gob.mx/semarnat
Senado de la República LXI Legislatura, Comisión de Ciencia y Tecnología. (2011). Agenda
Digital Nacional Resúmen Ejecutivo. Recuperado el 16 de Enero de 2017, de
www3.diputados.gob.mx/camara/content/download/254215/752378/file/ADNcompl
eto%2004112011.pdf
Instituto Nacional de Ecología y Cambio Climático. (1991). Instituto Nacional de Ecología y
Cambio Climático (INCC). Recuperado el 16 de Enero de 2017, de http://www.gob.mx/inecc
156
Anexo A: Descripciones de los Casos de Uso
CU: Crear sesión Tabla 12: Caso de uso: Crear sesión Fuente: Elaboración propia
Crear sesión
ID del Caso de Uso: SSN.1
Nombre: Crear sesión
Fecha de creación: 11/08/2017
Creado por: JRV
Actores: Administrador, Contador, Técnico, Cliente
Descripción: Permite al usuario el acceso al sistema
Referencias: Req: 1.1, 1.2, 1.3, 1.5, 2.18
Precondiciones: El usuario no tiene una sesión abierta en el sistema.
Pos condiciones: 1. El usuario ingresa al sistema 2. El sistema le crea una sesión al usuario
Prioridad: ALTA
Flujo Normal:
1. El usuario accede a la pantalla de inicio del sistema. 2. Se le solicita al usuario que ingrese su nombre de usuario y su clave 3. El usuario provee el nombre y clave correctos. 4. Se crea la sesión de usuario y la página de ingreso al sistema es
desplegada.
C C
ó S
1 E ib b d i
2 P l l b tó d
3 Válid l d t i t l b d d t t
4 V ifi l i t l t t ti
5 M t á i d i i i
Flujos Alternativos: El nombre de usuario y/o clave ingresados no son correctos
Acciones de los Actores Acción del Sistema
3A. Los datos no existen en la base de datos o no son correctos.
4A. No se crea sesión de usuario y un mensaje de error es desplegado.
5A. Se le solicita nuevamente al usuario su nombre de usuario y su clave de acceso.
Flujos Alternativos: El estatus del usuario está inactivo
Acciones de los Actores Acción del Sistema
4A. El estatus del usuario es inactivo.
5A. No se crea sesión de usuario y un mensaje de error es desplegado.
6A. Se le solicita nuevamente al usuario su nombre de usuario y su clave de acceso.
157
CU: Cerrar sesión Tabla 13: Caso de uso: Cerrar sesión Fuente: Elaboración propia
Cerrar sesión
ID del Caso de Uso: SSN.2
Nombre: Cerrar sesión
Fecha de creación: 11/08/2017
Creado por: JRV
Actores: Administrador, Contador, Técnico, Cliente
Descripción: Permite al usuario salir del sistema
Referencias: Req: 1.4, 1.7
Precondiciones: El usuario tiene una sesión abierta en el sistema.
Pos condiciones: 1. El usuario sale del sistema 2. La sesión del usuario es finalizada
Prioridad: BAJA
Flujo Normal: 1. Al usuario se le presenta una opción que indica el cierre de sesión 2. El usuario solicita el cierre de sesión. 3. Se cierra la sesión del usuario y es redireccionado a la página de inicio
del sistema.
Actores: Administrador, Contador, Técnico, Cliente
Acciones de los Actores Acción del Sistema
1. Pulsa la opción de cierre de sesión 2. La sesión es finalizada
3. Se redirecciona a la página de inicio
158
CU: Expira sesión Tabla 14: Caso de uso: Expira sesión Fuente: Elaboración propia
Expira sesión
ID del Caso de Uso: SSN.3
Nombre: Expira Sesión
Fecha de creación: 11/08/2017
Creado por: JRV
Actores: Administrador, Contador, Técnico, Cliente
Descripción: Tras una etapa de inactividad por parte del usuario, el servidor termina la sesión.
Referencias: Req: 1.8
Precondiciones: El usuario tiene una sesión abierta en el sistema.
Pos condiciones: La sesión del usuario es finalizada
Prioridad: BAJA
Flujo Normal: 1. El usuario tiene una sesión abierta en el sistema 2. No hay actividad del usuario en el servidor por un periodo de 30 minutos 3. Se cierra la sesión del usuario y es redireccionado a la página de inicio
del sistema.
Actores: Administrador, Contador, Técnico, Cliente
Acciones de los Actores Acción del Sistema
Ninguna 1. La sesión es finalizada
2. Se redirecciona a la página de inicio
159
CU: Reanudar sesión Tabla 15: Caso de uso: Reanudar sesión Fuente: Elaboración propia
Reanudar sesión
ID del Caso de Uso: SSN.4
Nombre: Reanudar sesión
Fecha de creación: 11/08/2017
Creado por: JRV
Actores: Administrador, Contador, Técnico, Cliente
Descripción: Al término de una sesión, el usuario trata de acceder sin pasar por pantalla de inicio
Referencias: Req: 1.6
Precondiciones: El usuario no tiene una sesión abierta en el sistema.
Pos condiciones: El sistema redirecciona al usuario a la página de inicio
Prioridad: BAJA
Flujo Normal: 1. El usuario intenta ingresar a una sección del sistema 2. El sistema lo redirecciona a la página de inicio
Actores: Administrador, Contador, Técnico, Cliente
Acciones de los Actores Acción del Sistema
1. Escribe una url del sistema en el navegador 2. Verifica que la sesión no está activa
3. Muestra página de inicio
160
CU: Crear usuario Tabla 16: Caso de uso: Crear usuario Fuente: Elaboración propia
Crear usuario
ID del Caso de Uso: USR.1
Nombre: Crear usuario
Fecha de creación: 11/08/2017
Creado por: JRV
Actores: Administrador
Descripción: Crea un nuevo usuario en el sistema
Referencias: Req: 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9, 2.10, 2.11, 2.12, 2.13, 2.14, 215, 216
Precondiciones: Ninguna
Pos condiciones: 1. Se crea un nuevo usuario en el sistema 2. Por default el estatus de un nuevo usuario es activo
Prioridad: ALTA
Flujo Normal: 1. El usuario accede a la pantalla de administración de usuarios. 2. Se le solicita al usuario que ingrese los siguientes datos: nombre de usuario, contraseña, nombre,
apellido paterno, apellido materno, teléfono, correo y estatus. 3. Seleccionar el rol de usuario administrador, contador o técnico 4. Se crea el usuario con estatus activo y se muestra mensaje de éxito.
A t Ad i i t d A i d l A t A ió d l Si t 1. Escribe nombre de usuario, contraseña, nombre,
llid llid léf
2. Valida que los datos introducidos tengan el formato correcto
3 S l i l l d i i t d t d té i 4 P i b tó d 5 El b d l i i t l i t 6 S i t i t t ti t j d é it
Flujos Alternativos: Los datos ingresados no tienen el formato correcto
A i d l A t A ió d l Si t 2A S d li l j d i di d l l l f t id
Flujos Alternativos: El nombre de usuario ya existe en el sistema
A i d l A t A ió d l Si t 5A El b d l i i t l i t 6A S t j d i di d l b d i i t l i t
Flujos Alternativos: El rol de usuario seleccionado es cliente y no es encargado del centro de servicio
A i d l A t A ió d l Si t 3A S l i l li t 4A D li l t d i i di ibl l t t d d d l t d i i d f lt
5A S l i t d i i 4 P i b tó d 5 V ifi l b d i i t l i t 6 S i t i t t ti t j d é it
Flujos Alternativos: El rol de usuario seleccionado es cliente y es encargado del centro de servicio
A i d l A t A ió d l Si t 3A S l i l li t 4A D li l t d i i di ibl l t t d d d l t d i i d f lt
5A S l i t d i i 6A C bi l t t d d d d 4 P i b tó d 5 V ifi l b d i i t l i t 6 Si i t t i d l i t t t d d d d l bi f l 7 S i t i t t ti t j d é it
161
CU: Modificar usuario Tabla 17: Caso de uso: Modificar usuario Fuente: Elaboración propia
Modificar usuario
ID del Caso de Uso: USR.2
Nombre: Modificar usuario
Fecha de creación: 11/08/2017
Creado por: JRV
Actores: Administrador
Descripción: Modifica los datos de un usuario existente en el sistema
Referencias: Req: 2.17, 2.19, 2.20
Precondiciones: Se ha seleccionado un usuario para ser modificado
Pos condiciones: Se actualizan los datos del usuario en el sistema
Prioridad: MEDIA
Flujo Normal: 1. El usuario accede a la pantalla de administración de usuarios. 2. Selecciona un usuario a ser modificado 3. Se pueden modificar los siguientes datos: contraseña, nombre, apellido paterno,
apellido materno, teléfono, correo, estatus. 4. Se actualizan los datos del usuario y se muestra mensaje de éxito.
Actores: Administrador
Acciones de los Actores Acción del Sistema
1. Modifica alguno de los siguientes datos: contraseña, nombre, apellido paterno, apellido materno, teléfono, correo.
2. Valida que los datos introducidos tengan el formato correcto
3. Presiona botón actualizar 4. Actualiza los datos del usuario y se muestra mensaje de éxito
Flujos Alternativos: Los datos ingresados no tienen el formato correcto
Acciones de los Actores Acción del Sistema
2A. Se despliegan los mensajes de error indicando que los campos no cumplen con el formato requerido.
Flujos Alternativos: Habilitar/Inhabilitar un usuario
Acciones de los Actores Acción del Sistema
1A. Modifica el valor del estatus activo/inactivo
2. Presiona botón actualizar 3. Actualiza los datos del usuario y se muestra mensaje de éxito
162
CU: Crear centro de servicio Tabla 18: Caso de uso: Crear centro de servicio Fuente: Elaboración propia
Crear centro de servicio
ID del Caso de Uso: CSRV.1
Nombre: Crear centro de servicio
Fecha de creación: 14/08/2017
Creado por: JRV
Actores: Administrador
Descripción: Dar de alta un nuevo centro de servicio en el sistema
Referencias: Req: 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8
Precondiciones: Ninguna
Pos condiciones: 1. Se crea un nuevo centro de servicio en el sistema 2. Por default el estatus de un nuevo centro de servicio es activo
Prioridad: ALTA
Flujo Normal: 1. El usuario accede a la pantalla de administración de centros de servicio. 2. Se le solicita al usuario que ingrese los siguientes datos: número de centro, estado, razón
social, calle,colonia, código postal, RFC, teléfono, número de líneas y estatus. 3. Se crea el centro de servicio con estatus activo y se muestra un mensaje de éxito.
Actores: Administrador
Acciones de los Actores Acción del Sistema
1. Escribe nombre de usuario, número de centro, estado, razón social, calle,colonia, código postal, RFC, teléfono, número de líneas y estatus.
2. Valida que los datos introducidos tengan el formato correcto
3. Presiona botón guardar 4. Verifica que el nombre de centro no exista en el sistema
5. Se inserta un nuevo centro de servicio con estatus activo y se muestra mensaje de éxito
Flujos Alternativos: Los datos ingresados no tienen el formato correcto
Acciones de los Actores Acción del Sistema
2A. Se despliegan los mensajes de error indicando que los campos no cumplen con el formato requerido.
Flujos Alternativos: El nombre de centro ya existe en el sistema
Acciones de los Actores Acción del Sistema
5A. Se muestra un mensaje de error indicando que el nombre de usuario ya existe en el sistema.
163
CU: Modificar centro de servicio Tabla 19: Caso de uso: Modificar centro de servicio Fuente: Elaboración propia
Modificar centro de servicio
ID del Caso de Uso: CSRV.2
Nombre: Modificar centro de servicio
Fecha de creación: 14/08/2017
Creado por: JRV
Actores: Administrador
Descripción: Modifica los datos de un centro de servicio existente en el sistema
Referencias: Req: 3.9, 3.10, 3.11, 3.12
Precondiciones: Se ha seleccionado un centro de servicio para ser modificado
Pos condiciones: Se actualizan los datos del centro de servicio en el sistema
Prioridad: MEDIA
Flujo Normal: 5. El usuario accede a la pantalla de administración de centro de servicio. 6. Selecciona un centro de servicio a ser modificado 7. Se pueden modificar los siguientes datos: número de centro, estado, razón social, calle, colonia,
código postal, RFC, teléfono, número de líneas y estatus 8. Se actualizan los datos del centro de servicio y se muestra mensaje de éxito.
Actores: Administrador
Acciones de los Actores Acción del Sistema
1. Modifica alguno de los siguientes datos: número de centro, estado, razón social, calle,colonia, código postal, RFC, teléfono, número de líneas y estatus
2. Valida que los datos introducidos tengan el formato correcto
3. Presiona botón actualizar 4. Actualiza los datos del centro de servicio y se muestra mensaje de éxito
Flujos Alternativos: Los datos ingresados no tienen el formato correcto
Acciones de los Actores Acción del Sistema
2A. Se despliegan los mensajes de error indicando que los campos no cumplen con el formato requerido.
Flujos Alternativos: Inhabilitar un centro de servicio
Acciones de los Actores Acción del Sistema
1A. Modifica el valor del estatus a inactivo
3. Presiona botón actualizar 4A. Inhabilita a todos los usuarios del centro de servicio
5A. Actualiza el estatus del centro de servicio y se muestra mensaje de éxito
Flujos Alternativos: Habilitar un centro de servicio
Acciones de los Actores Acción del Sistema
1A. Modifica el valor del estatus a activo
3. Presiona botón actualizar 4A. Habilita a todos los usuarios del centro de servicio
5A. Actualiza el estatus del centro de servicio y se muestra mensaje de éxito
164
CU: Crear concepto de adeudo Tabla 20: Caso de uso: Crear concepto de adeudo Fuente: Elaboración propia
Crear concepto de adeudo
ID del Caso de Uso: CADD.1
Nombre: Crear concepto de adeudo
Fecha de creación: 14/08/2017
Creado por: JRV
Actores: Administrador
Descripción: Dar de alta un nuevo concepto de adeudo en el sistema
Referencias: Req: 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7, 5.8
Precondiciones: El catálogo cuenta con seis valores predefinidos: ● Existen cuatro tipos de concepto de adeudo que tienen costo: mantenimiento mensual, mantenimiento
bimestral, mantenimiento general y servicio no incluido en póliza. ● Existen dos tipos de concepto de adeudo que no tienen costo: servicio incluido en póliza y garantía sin costo
Pos condiciones: 1. Se crea un nuevo concepto de adeudo en el sistema 2. Por default el estatus de un nuevo concepto de adeudo es activo
Prioridad: MEDIA
Flujo Normal: 1. El usuario accede a la pantalla de administración de concepto de adeudo. 2. Se le solicita al usuario que ingrese los siguientes datos: nombre del concepto, tiene costo y estatus. Tiene
costo y estatus son valores verdadero/falso. 3. Se crea el concepto de adeudo con estatus activo y se muestra un mensaje de éxito.
Actores: Administrador
Acciones de los Actores Acción del Sistema
1. Escribe nombre del concepto, selecciona si tiene costo y su estatus.
2. Valida que los datos introducidos tengan el formato correcto
3. Presiona botón guardar 4. Verifica que el nombre de concepto no exista en el sistema
5. Se inserta un nuevo concepto de adeudo con estatus activo y se muestra mensaje de éxito
Flujos Alternativos: Los datos ingresados no tienen el formato correcto
Acciones de los Actores Acción del Sistema
2A. Se despliegan los mensajes de error indicando que los campos no cumplen con el formato requerido.
Flujos Alternativos: El nombre de centro ya existe en el sistema
Acciones de los Actores Acción del Sistema
5A. Se muestra un mensaje de error indicando que el nombre de concepto de adeudo ya existe en el sistema.
165
CU: Modificar concepto de adeudo Tabla 21: Caso de uso: Modificar concepto de adeudo Fuente: Elaboración propia
Modificar concepto de adeudo
ID del Caso de Uso: CADD.2
Nombre: Modificar concepto de adeudo
Fecha de creación: 14/08/2017
Creado por: JRV
Actores: Administrador
Descripción: Modifica los datos de un concepto de adeudo existente en el sistema
Referencias: Req: 5.9, 5.10, 5.11, 5.12
Precondiciones: Se ha seleccionado un concepto de adeudo para ser modificado
Pos condiciones: Se actualizan los datos del concepto de adeudo en el sistema
Prioridad: MEDIA
Flujo Normal: 1. El usuario accede a la pantalla de administración de concepto de adeudo. 2. Selecciona un concepto de adeudo a ser modificado 3. Se pueden modificar los siguientes datos: nombre del concepto, tiene costo y
estatus. 4. Se actualizan los datos del concepto de adeudo y se muestra mensaje de éxito.
Actores: Administrador
Acciones de los Actores Acción del Sistema
1. Modifica alguno de los siguientes datos: nombre del concepto, tiene costo y estatus
2. Valida que los datos introducidos tengan el formato correcto
3. Presiona botón actualizar 4. Actualiza los datos del concepto de adeudo y se muestra mensaje de éxito
Flujos Alternativos: Los datos ingresados no tienen el formato correcto
Acciones de los Actores Acción del Sistema
2A. Se despliegan los mensajes de error indicando que los campos no cumplen con el formato requerido.
Flujos Alternativos: Habilitar/Inhabilitar un concepto de adeudo
Acciones de los Actores Acción del Sistema
1A. Modifica el valor del estatus a inactivo
3. Presiona botón actualizar 4A. Actualiza el estatus del concepto de adeudo y se muestra mensaje de éxito
Flujos Alternativos: Cobro/Sin cobro (tiene costo) para un concepto de adeudo
Acciones de los Actores Acción del Sistema
1A. Modifica el valor del campo tiene cobro
3. Presiona botón actualizar 4A. Actualiza el tipo de cobro del concepto de adeudo y se muestra mensaje de éxito
166
CU: Crear solicitud Tabla 22: Caso de uso: Crear solicitud Fuente: Elaboración propia
Crear solicitud
ID del Caso de Uso: SLC.1
Nombre: Crear solicitud
Fecha de creación: 15/08/2017
Creado por: JRV
Actores: Administrador, cliente, técnico
Descripción: Dar de alta una nueva solicitud de servicio en el sistema
Referencias: Req: 6.1, 6.2, 6.3, 6.4, 6.5
Precondiciones: Ninguna
Pos condiciones: 3. Se crea una nueva solicitud de servicio o mantenimiento en el sistema 4. Por default el estado de un nueva solicitud es “iniciado”
Prioridad: ALTA
Flujo Normal: Crear solicitud de mantenimiento 1. El usuario accede a la administración de solicitudes de servicio. 2. Se le solicita al usuario que seleccione el centro de servicio. 3. El usuario selecciona el concepto de mantenimiento. 4. El sistema provee la cantidad de líneas de mantenimiento disponibles para el centro de servicio
seleccionado. 5. El usuario selecciona las líneas de mantenimiento que sean requeridas. 6. Por cada línea seleccionada se despliega un campo de texto con la leyenda “Falla en: ” concatenado con
el número de la línea seleccionada. 7. Se muestra un campo de texto para capturar el nombre de “quien reporta” (Nombre y apellidos de una
persona). 8. El sistema muestra un campo de comentarios para captura de datos adicionales 9. El sistema guarda la solicitud y genera un folio de servicio. 10. El sistema notifica que la solicitud ha sido guardada y el folio de servicio generado 11. El estado de la solicitud es “iniciado”.
Actores: Administrador, técnico, cliente
Acciones de los Actores Acción del Sistema
1. El usuario accede a la administración de solicitudes de servicio.
2. El usuario selecciona el concepto de mantenimiento.
3. El sistema verifica el tipo de rol del usuario, si es cliente solo despliega el centro de servicio al que pertenece , si es administrador o técnico despliega todos los centros de servicio
4. Seleccionar el centro de servicio
5. El sistema provee la cantidad de líneas de mantenimiento disponibles para el centro de servicio seleccionado.
6. Selecciona las líneas de mantenimiento que sean requeridas.
7. Por cada línea seleccionada se despliega un campo de texto con la leyenda “Falla en: ”, concatenado con el número de la línea seleccionada
8. Se muestra un campo de texto para capturar el nombre de “quien reporta” (Nombre y apellidos de una persona).
9. Despliega un campo de comentarios para captura de datos adicionales
10. Captura las fallas en líneas, el nombre de quien reporta y comentarios
11. Presiona el botón guardar 12. La información persiste y se crea un número de folio
13. El sistema notifica del éxito de la operación
167
Flujos Alternativos: Crear solicitud de servicio 1. El usuario accede a la administración de solicitudes de servicio. 2. Se le solicita al usuario que seleccione el centro de servicio. 3. El usuario selecciona el concepto de servicio. 4. El sistema muestra dos opciones de selección mutuamente excluyentes, Ecológico o Local. 5. El usuario selecciona alguna opción. 6. El sistema muestra las opciones de cómputo Server, Impresión y Tenencia. 7. El usuario puede seleccionar varias opciones de cómputo. 8. Por cada opción de cómputo seleccionada se despliega un campo de texto con la leyenda “Falla en: ”
concatenado con el tipo de cómputo seleccionado. 9. El sistema provee la cantidad de líneas de mantenimiento disponibles para el centro de servicio
seleccionado 10. El usuario selecciona las líneas de mantenimiento que sean requeridas 11. Por cada línea seleccionada se despliega un campo de texto con la leyenda “Falla en: ” concatenado con
el número de la línea seleccionada 12. El sistema muestra un campo de comentarios para captura de datos adicionales 13. El sistema guarda la solicitud y genera un folio de servicio 14. El sistema notifica que la solicitud ha sido guardada y el folio de servicio generado 15. El estado de la solicitud es “iniciado”.
Actores: Administrador, técnico, cliente
Acciones de los Actores Acción del Sistema
1. El usuario accede a la administración de solicitudes de servicio.
2. El usuario selecciona el concepto de servicio
3. El sistema verifica el tipo de rol del usuario, si es cliente solo despliega el centro de servicio al que pertenece, si es administrador o técnico despliega todos los centros de servicio
4. Seleccionar el centro de servicio 5. El sistema muestra dos opciones de selección mutuamente excluyentes, Ecológico o Local.
6. El sistema muestra las opciones de cómputo Server, Impresión y Tenencia.
7. El sistema provee la cantidad de líneas de mantenimiento disponibles para el centro de servicio seleccionado.
8. El usuario selecciona alguna opción Ecológico o local.
9. El usuario selecciona una o varias opciones de cómputo. 10. Por cada opción de cómputo seleccionada se despliega un campo de texto con la leyenda “Falla en: ” concatenado con el tipo de cómputo seleccionado.
11. Selecciona las líneas de mantenimiento que sean requeridas.
12. Por cada línea seleccionada se despliega un campo de texto con la leyenda “Falla en: ” concatenado con el número de la línea seleccionada
13. Se muestra un campo de texto para capturar el nombre de “quien reporta” (Nombre y apellidos de una persona).
14. Despliega un campo de comentarios para captura de datos adicionales
15. Captura las fallas en líneas, el nombre de quien reporta y comentarios
16. Presiona el botón guardar 17. La información persiste y se crea un número de folio
18. El sistema notifica del éxito de la operación
168
Reporte de solicitud de mantenimiento Tabla 23: Caso de uso: Reporte de solicitud de mantenimiento Fuente: Elaboración propia
Reporte de solicitud de mantenimiento
ID del Caso de Uso: SLC.2
Nombre: Reporte de solicitud de mantenimiento
Fecha de creación: 15/08/2017
Creado por: JRV
Actores: Administrador, técnico, cliente
Descripción: Generar un reporte al finalizar una nueva solicitud
Referencias: Req: 6.6
Precondiciones: ● El usuario ha capturado una nueva solicitud. ● El formato del reporte debe ser como se muestra en el formato 6.1
del documento ERS-SASM
Pos condiciones: Se genera un reporte PDF con la información de la solicitud
Prioridad: BAJA
Flujo Normal: 1. El sistema ha guardado la solicitud de mantenimiento 2. El sistema genera un documento en PDF con los datos de la
solicitud capturada 3. El sistema permite la descarga del documento.
Actores: Administrador, técnico, cliente
Acciones de los Actores
Acción del Sistema
1. Usuario genera una nueva solicitud de mantenimiento
2. El sistema ha guardado la solicitud de mantenimiento
3. El sistema genera un documento en PDF con los datos de la solicitud capturada
4. El formato del reporte debe ser como se muestra en el formato 6.1 del documento ERS-SASM
5. El sistema permite la descarga del documento
169
Reporte de solicitud de servicios Tabla 24: Caso de uso: Reporte de solicitud de servicios Fuente: Elaboración propia
Reporte de solicitud de servicio
ID del Caso de Uso: SLC.3
Nombre: Reporte de solicitud de servicio
Fecha de creación: 15/08/2017
Creado por: JRV
Actores: Administrador, técnico, cliente
Descripción: Generar un reporte al finalizar una nueva solicitud
Referencias: Req: 6.7
Precondiciones: ● El usuario ha capturado una nueva solicitud. ● El formato del reporte debe ser como se muestra en el formato 6.2
del documento ERS-SASM
Pos condiciones: Se genera un reporte PDF con la información de la solicitud
Prioridad: BAJA
Flujo Normal: 1. El sistema ha guardado la solicitud de mantenimiento 2. El sistema genera un documento en PDF con los datos de la
solicitud capturada 3. El sistema permite la descarga del documento.
Actores: Administrador, técnico, cliente
Acciones de los Actores
Acción del Sistema
1. Usuario genera una nueva solicitud de servicio
2. El sistema ha guardado la solicitud de servicio
3. El sistema genera un documento en PDF con los datos de la solicitud capturada
4. El formato del reporte debe ser como se muestra en el formato 6.2 del documento ERS-SASM
5. El sistema permite la descarga del documento
170
CU: Consulta de solicitud iniciada Tabla 25: Caso de uso: Consulta de solicitud iniciada Fuente: Elaboración propia
Consulta de solicitud iniciada
ID del Caso de Uso: SLC.4
Nombre: Consulta de solicitud iniciada
Fecha de creación: 15/08/2017
Creado por: JRV
Actores: Administrador, técnico, cliente
Descripción: Hacer una búsqueda en la base de datos de las consultas en estado “iniciado”
Referencias: Req: 6.8
Precondiciones: Existen solicitudes capturadas
Pos condiciones: El sistema muestra una tabla con solicitudes en estado “iniciado”.
Prioridad: MEDIA
Flujo Normal: 1. Las solicitudes se pueden filtrar por un intervalo de fecha de apertura (inicio y fin), se muestra el total de solicitudes obtenidas con paginación.
2. Las solicitudes se pueden filtrar por centro de servicio, técnico, solo aplica para el rol administrador. Se muestra el total de solicitudes obtenidas con paginación
3. Si el usuario tiene un rol de técnico o cliente, se muestran sólo aquellas solicitudes que le pertenecen al usuario (solicitudes creadas por el mismo usuario que las consulta)
4. Si el usuario tiene un rol de administrador se muestran las solicitudes iniciadas sin importar a quién pertenecen las solicitudes
5. El sistema muestra una tabla con solicitudes en estado “iniciado” 6. Los datos que se muestran en la tabla son Centro, número de folio, tipo de solicitud, fecha
de alta, descarga del reporte generado.
Actores: Administrador, técnico, cliente
Acciones de los Actores Acción del Sistema
1. Usuario ingresa a la consulta de solicitudes iniciadas
2. El sistema muestra una tabla con solicitudes en estado “iniciado”, el máximo número de solicitudes mostradas es de 15 ordenadas por fecha de apertura en forma descendente
3. Si el rol es administrador se muestran los filtros de centro de servicio y técnico.
4. Selecciona filtro por un intervalo de fecha de apertura (inicio y fin)
5. Si el usuario tiene un rol de técnico o cliente, se muestran sólo aquellas solicitudes en estado “iniciado” que le pertenecen al usuario, en caso contrario se muestran todas
6. Los datos que se muestran en la tabla son Centro, número de folio, tipo de solicitud, fecha de alta, técnico asignado, descarga del reporte generado.
Flujos Alternativos: Filtrar por centro de servicio o técnico
Acciones de los Actores Acción del Sistema
4A. Selecciona el filtro de centro de servicio y/o técnico.
5A. Se muestra el total de solicitudes en estado “iniciado” obtenidas con paginación
171
CU: Modificar solicitud iniciada Tabla 26: Caso de uso: Modificar solicitud iniciada Fuente: Elaboración propia
Modificar solicitud iniciada
ID del Caso de Uso: SLC.5
Nombre: Modificar solicitud iniciada
Fecha de creación: 15/08/2017
Creado por: JRV
Actores: Administrador, técnico, cliente
Descripción: Cambiar los valores de una solicitud
Referencias: Req: 6.9
Precondiciones: Se ha realizado una consulta de solicitudes iniciadas
Pos condiciones: Los datos de una solicitud son actualizados
Prioridad: MEDIA
Flujo Normal: 1. El usuario selecciona un registro de una solicitud. 2. El sistema permite que el usuario haga cambios a la solicitud
seleccionada
Actores: Administrador, técnico, cliente
Acciones de los Actores Acción del Sistema
1. El usuario selecciona un registro de una solicitud
2. El sistema muestra los valores de la solicitud seleccionada
3. Realiza cambios en la solicitud
3. Actualiza los cambios en la base de datos
172
CU: Asignación de técnico Tabla 27: Caso de uso: Asignación de técnico Fuente: Elaboración propia
Asignación de técnico
ID del Caso de Uso: SLC.5
Nombre: Asignación de técnico
Fecha de creación: 15/08/2017
Creado por: JRV
Actores: Administrador
Descripción: Asignar un técnico o técnicos a la solicitud para ser atendida
Referencias: Req: 6.10
Precondiciones: Se ha realizado una consulta de solicitudes iniciadas
Pos condiciones: Se asigna un técnico a la solicitud
Prioridad: ALTA
Flujo Normal: 1. Solo un rol administrador puede realizar esta acción. 2. El usuario selecciona un registro de una solicitud iniciada. 3. El sistema permite que el usuario asigne el técnico o técnicos para
atender esta solicitud. 4. Al asignar un técnico el estatus de la solicitud cambia a “asignado”.
Actores: Administrador
Acciones de los Actores
Acción del Sistema
1. El usuario selecciona un registro de una solicitud iniciada
2. El sistema muestra los valores de la solicitud seleccionada
3. Asigna técnicos a la solicitud
3. Actualiza los cambios en la base de datos
4. Cambia el estado de la solicitud a asignado
173
CU: Cancelar solicitudes Tabla 28: Caso de uso: Cancelar solicitudes Fuente: Elaboración propia
Cancelar solicitudes
ID del Caso de Uso: SLC.6
Nombre: Cancelar solicitudes
Fecha de creación: 15/08/2017
Creado por: JRV
Actores: Administrador, técnico, cliente
Descripción: Se elimina una solicitud del sistema
Referencias: Req: 6.11
Precondiciones: ● Se ha realizado una consulta de solicitudes iniciadas ● Se ha realizado una consulta de solicitudes asignadas. Solo para un administrador
Pos condiciones: La solicitud es eliminada de la base de datos
Prioridad: MEDIA
Flujo Normal: Cancelar solicitud iniciada 1. La acción puede ser realizada por un cliente, un técnico y un administrador. 2. El usuario selecciona un registro de una solicitud. 3. Si el rol es cliente o técnico, la solicitud sólo podrá ser cancelada si está en estado de
“iniciado”. 4. El administrador puede cancelar una solicitud en cualquier estado. 5. La cancelación equivale a un borrado a nivel físico del registro.
Actores: Administrador, técnico, cliente
Acciones de los Actores Acción del Sistema
1. El usuario selecciona un registro de una solicitud iniciada
2. El usuario presiona el botón eliminar solicitud
3. El sistema pide confirmación de la acción
4. El usuario valida el cambio 5. La solicitud es cancelada
Flujos Alternativos: Cancelar solicitud asignada 6. La acción puede ser realizada por un administrador. 7. El usuario selecciona un registro de una solicitud. 8. Si el rol es cliente o técnico, la solicitud sólo podrá ser cancelada si está en estado de
“iniciado”. 9. El administrador puede cancelar una solicitud en cualquier estado. 10. La cancelación equivale a un borrado a nivel físico del registro.
Acciones de los Actores Acción del Sistema
1A. El usuario selecciona un registro de una solicitud iniciada
2. El usuario presiona el botón eliminar solicitud
3. El sistema pide confirmación de la acción
4. El usuario valida el cambio 5. La solicitud es cancelada
174
CU: Consulta de solicitud asignada Tabla 29: Caso de uso: Consulta de solicitud asignada Fuente: Elaboración propia
Consulta de solicitud asignada
ID del Caso de Uso: SLC.7
Nombre: Consulta de solicitud asignada
Fecha de creación: 16/08/2017
Creado por: JRV
Actores: Administrador, técnico
Descripción: Hacer una búsqueda en la base de datos de las consultas en estado “asignado”
Referencias: Req: 6.12
Precondiciones: Existen solicitudes en estado “asignado”
Pos condiciones: El sistema muestra una tabla con solicitudes en estado “asignado”,
Prioridad: MEDIA
Flujo Normal: 1. Las solicitudes se pueden filtrar por un intervalo de fecha de apertura (inicio y fin), se muestra el total de solicitudes obtenidas con paginación.
2. Las solicitudes se pueden filtrar por centro de servicio, técnico, solo aplica para el rol administrador. Se muestra el total de solicitudes obtenidas con paginación
3. Si el usuario tiene un rol de técnico, se muestran sólo aquellas solicitudes que le pertenecen al usuario o le han sido asignadas.
4. Si el usuario tiene un rol de administrador se muestran las solicitudes asignadas sin importar a quién pertenecen las solicitudes
5. El sistema muestra una tabla con solicitudes en estado “asignado” 6. Los datos que se muestran en la tabla son Centro, número de folio, tipo de solicitud, fecha de
alta, descarga del reporte generado, técnico asignado.
Actores: Administrador, técnico
Acciones de los Actores Acción del Sistema
1. Usuario ingresa a la consulta de solicitudes asignadas
2. El sistema muestra una tabla con solicitudes en estado “asignado”, el máximo número de solicitudes mostradas es de 15 ordenadas por fecha de apertura en forma descendente
3. Si el rol es administrador se muestran los filtros de centro de servicio y técnico.
4. Selecciona filtro por un intervalo de fecha de apertura (inicio y fin)
5. Si el usuario tiene un rol de técnico, se muestran las solicitudes en estado “asignado” que le pertenecen al usuario o le fueron asignadas. En caso contrario se muestran todas
6. Los datos que se muestran en la tabla son Centro, número de folio, tipo de solicitud, fecha de alta, técnico asignado, descarga del reporte generado.
Flujos Alternativos: Filtrar por centro de servicio o técnico
Acciones de los Actores Acción del Sistema
4A. Selecciona el filtro de centro de servicio y/o técnico.
5A. Se muestra el total de solicitudes en estado “asignado” obtenidas con paginación
175
CU: Modificar solicitud asignada Tabla 30: Caso de uso: Modificar solicitud asignada Fuente: Elaboración propia
Modificar solicitud asignada ID del Caso de Uso: SLC.8
Nombre: Modificar solicitud asignada Fecha de creación: 16/08/2017
Creado por: JRV
Actores: Administrador, técnico Descripción: Cambiar los valores de una solicitud
Referencias: Req: 6.13
Precondiciones: Se ha realizado una consulta de solicitudes asignadas Pos condiciones: Los datos de una solicitud son actualizados
Prioridad: MEDIA
Flujo Normal: 3. El usuario selecciona un registro de una solicitud. 4. El sistema permite que el usuario haga cambios a
la solicitud seleccionada
Actores: Administrador, técnico
Acciones de los Actores Acción del Sistema
1. El usuario selecciona un registro de una solicitud
2. El sistema muestra los valores de la solicitud seleccionada
3. Realiza cambios en la solicitud
3. Actualiza los cambios en la base de datos
176
CU: Finalizar solicitud asignada Tabla 31: Caso de uso: Finalizar solicitud asignada Fuente: Elaboración propia
Finalizar solicitud asignada
ID del Caso de Uso: SLC.9
Nombre: Finalizar solicitud asignada
Fecha de creación: 16/08/2017
Creado por: JRV
Actores: Administrador, técnico
Descripción: Cambiar el estado de una solicitud a finalizado, ingresar los datos del servicio proporcionado
Referencias: Req: 6.14
Precondiciones: Se ha realizado una consulta de solicitudes asignadas
Pos condiciones: ● Los datos de una solicitud son actualizados. ● El estado de la solicitud es finalizado
Prioridad: MEDIA
Flujo Normal: 1. El usuario selecciona un registro de una solicitud. 2. El sistema permite que el usuario finalice la solicitud. 3. El sistema muestra un campo llamado “solución aplicada” por cada opción,
cómputo o línea que tenga la solicitud. El usuario debe llenar el campo de forma obligatoria
4. El sistema muestra un campo llamado “materiales empleados” por cada opción, cómputo o línea que tenga la solicitud. El usuario debe llenar el campo de forma obligatoria.
5. El usuario cambia el estatus de la solicitud a “finalizado”
Actores: Administrador, técnico
Acciones de los Actores Acción del Sistema
1. El usuario selecciona un
2. El sistema muestra los valores de la solicitud seleccionada
3. El sistema muestra un campo llamado “solución aplicada” por cada opción, cómputo o línea que tenga la solicitud. El usuario debe llenar el campo de forma obligatoria
4. El sistema muestra un campo llamado “materiales empleados” por cada opción, cómputo o línea que tenga la solicitud. El usuario debe llenar el campo de forma obligatoria.
5. Actualiza los campos
6. Cambia el estado a
7. Se valida que todos los campos han sido llenados.
8. Se guardan los datos y cambia el estado de la solicitud
Flujos Altrnativos: Finalizar una solicitud con datos incompletos
Acciones de los Actores Acción del Sistema
7A. No todos los campos han sido llenados
8A. Se guardan los datos y se le notifica al usuario que no es posible finalizar la solicitud a menos que tenga todos los campos llenos
9. La solicitud continúa en estado asignado
177
CU: Consulta de solicitud finalizada Tabla 32: Caso de uso: Consulta de solicitud finalizada Fuente: Elaboración propia
Consulta de solicitud finalizada
ID del Caso de Uso: SLC.10
Nombre: Consulta de solicitud finalizada
Fecha de creación: 17/08/2017
Creado por: JRV
Actores: Administrador, técnico, cliente
Descripción: Hacer una búsqueda en la base de datos de las consultas en estado “finalizado”
Referencias: Req: 6.15
Precondiciones: Existen solicitudes en estado “finalizado”
Pos condiciones: El sistema muestra una tabla con solicitudes en estado “finalizado”,
Prioridad: MEDIA
Flujo Normal: 1. Las solicitudes se pueden filtrar por un intervalo de fecha de apertura (inicio y fin), se muestra el total de solicitudes obtenidas con paginación.
2. Las solicitudes se pueden filtrar por centro de servicio, técnico, solo aplica para el rol administrador. Se muestra el total de solicitudes obtenidas con paginación
3. Si el usuario tiene un rol de técnico o cliente, se muestran sólo aquellas solicitudes que le pertenecen al usuario o le han sido asignadas.
4. Si el usuario tiene un rol de administrador se muestran las solicitudes asignadas sin importar a quién pertenecen las solicitudes
5. El sistema muestra una tabla con solicitudes en estado “finalizado” 6. Los datos que se muestran en la tabla son Centro, número de folio, tipo de solicitud, fecha de
alta, descarga del reporte generado, técnico asignado.
Actores: Administrador, técnico, cliente
Acciones de los Actores Acción del Sistema
1. Usuario ingresa a la consulta de solicitudes finalizadas
2. El sistema muestra una tabla con solicitudes en estado “finalizado”, el máximo número de solicitudes mostradas es de 15 ordenadas por fecha de apertura en forma descendente
3. Si el rol es administrador se muestran los filtros de centro de servicio y técnico.
4. Selecciona filtro por un intervalo de fecha de apertura (inicio y fin)
5. Si el usuario tiene un rol de técnico o cliente, se muestran las solicitudes en estado “finalizado” que le pertenecen al usuario o le fueron asignadas. En caso contrario se muestran todas
6. Los datos que se muestran en la tabla son Centro, número de folio, tipo de solicitud, fecha de alta, técnico asignado, descarga del reporte generado.
Flujos Alternativos: Filtrar por centro de servicio o técnico
Acciones de los Actores Acción del Sistema
4A. Selecciona el filtro de centro de servicio y/o técnico.
5A. Se muestra el total de solicitudes en estado “finalizado” obtenidas con paginación
178
CU: Consulta de adeudos Tabla 33: Caso de uso: Consulta de adeudos Fuente: Elaboración propia
Consulta de adeudo
ID del Caso de Uso: ADD.1
Nombre: Consulta de adeudo
Fecha de creación: 18/08/2017
Creado por: JRV
Actores: Administrador, contador, cliente
Descripción: Hacer una búsqueda en la base de datos de las consultas en estado “finalizado” y datos de los adeudos de clientes
Referencias: Req: 7.3
Precondiciones: Existen solicitudes en estado “finalizado”
Pos condiciones: El sistema muestra una tabla con solicitudes en estado “finalizado” y datos del adeudo
Prioridad: BAJA
Flujo Normal: 1. Las solicitudes se pueden filtrar por un intervalo de fecha de apertura (inicio y fin), se muestra el total de solicitudes obtenidas con paginación.
2. Las solicitudes se pueden filtrar por centro de servicio, técnico, solo aplica para el rol administrador o contador. Se muestra el total de solicitudes obtenidas con paginación
3. Si el usuario tiene un rol de cliente, se muestran sólo aquellas solicitudes que le pertenecen al usuario. 4. Si el usuario tiene un rol de administrador o contador se muestran las solicitudes asignadas sin importar
a quién pertenecen las solicitudes 5. El sistema muestra una tabla con solicitudes en estado “finalizado” 6. Los datos que se muestran en la tabla son Centro, número de folio, tipo de solicitud, fecha de alta,
descarga del reporte generado, técnico asignado, concepto adeudo, estado de adeudo y total del adeudo.
Actores: Administrador, técnico,contador, cliente
Acciones de los Actores Acción del Sistema
1. Usuario ingresa a la consulta de adeudos
2. El sistema muestra una tabla con solicitudes en estado “finalizado”, el máximo número de solicitudes mostradas es de 15 ordenadas por fecha de apertura en forma descendente
3. Si el rol es administrador o contador se muestran los filtros de centro de servicio y técnico.
4. Selecciona filtro por un intervalo de fecha de apertura (inicio y fin)
5. Si el usuario tiene un rol de cliente, se muestran las solicitudes en estado “finalizado” que le pertenecen al usuario. En caso contrario se muestran todas
6. Los datos que se muestran en la tabla son Centro, número de folio, tipo de solicitud, fecha de alta, técnico asignado, descarga del reporte generado, concepto adeudo, estado de adeudo y total del adeudo.
Flujos Alternativos: Filtrar por centro de servicio o técnico
Acciones de los Actores Acción del Sistema
4A. Selecciona el filtro de centro de servicio y/o técnico.
5A. Se muestra el total de solicitudes en estado “finalizado” obtenidas con paginación
179
CU: Captura de adeudos Tabla 34: Caso de uso: Captura de adeudos Fuente: Elaboración propia
Captura de adeudo
ID del Caso de Uso: ADD.2
Nombre: Captura de adeudo
Fecha de creación: 18/08/2017
Creado por: JRV
Actores: Administrador, contador
Descripción: Agregar los conceptos de adeudo para una solicitud finalizada
Referencias: Req: 7.4
Precondiciones: Usuario ha realizado una consulta de adeudo
Pos condiciones: Se capturan los costos y conceptos de adeudo para una solicitud
Prioridad: BAJA
Flujo Normal: 1. Es visible para el administrador y contador. 2. El usuario selecciona un registro de una solicitud. 3. El usuario selecciona el concepto de adeudo del catálogo. 4. Si el concepto de adeudo tiene un costo, el sistema permite que el usuario capture
el costo y el I.V.A. ambos son campos numéricos. 5. Si el concepto de adeudo no tiene costo, no se permite la captura del costo ni del
I.V.A. 6. El sistema calcula el costo total como la suma del I.V.A. más el costo, si el concepto
no tiene costo es cero. 7. El sistema permite que el usuario cambie el estatus del pago pendiente/pagado
Actores: Administrador, contador
Acciones de los Actores Acción del Sistema
1. Usuario ingresa a la consulta de adeudo
2. El usuario selecciona un registro de una solicitud.
3. Se muestran el número de folio de la solicitud, los servicios otorgados y el catálogo de adeudos, el estado del adeudo pendiente/pagado
5. Selecciona el concepto de adeudo con costo asociado
6. el sistema permite que el usuario capture el costo y el I.V.A. ambos son campos numéricos.
7. Captura el estado del adeudo
8. Presiona el botón guardar
9. Se guardan los datos
Flujos Alternativos: El concepto de adeudo no genera costo
Acciones de los Actores Acción del Sistema
5A. Selecciona el concepto de adeudo con costo asociado
6A. El sistema captura el costo cero e iva cero.
180
CU: Reporte de estado de solicitud Tabla 35: Caso de uso: Reporte de estado de solicitud Fuente: Elaboración propia
Reporte estado de solicitud
ID del Caso de Uso: RPT.1
Nombre: Reporte estado de solicitud
Fecha de creación: 21/08/2017
Creado por: JRV
Actores: Administrador, contador
Descripción: Hacer una búsqueda en la base de datos de las consultas por estado
Referencias: Req: 8.2
Precondiciones: Existen solicitudes en cualquier estado
Pos condiciones: El sistema muestra una tabla con solicitudes
Prioridad: BAJA
Flujo Normal: 1. Es visible para el administrador y contador. 2. Las solicitudes se pueden filtrar por un intervalo de fechas de atención (inicio y fin),
se muestra el total de solicitudes obtenidas. 3. Las solicitudes se pueden filtrar por centro de servicio, se muestra el total de
solicitudes obtenidas. 4. Las solicitudes se pueden filtrar por técnico, se muestra el total de solicitudes
obtenidas. 5. Las solicitudes se pueden filtrar estado de la solicitud, se muestra el total de
solicitudes obtenidas. 6. Los filtros son mutuamente incluyentes 7. Los datos a mostrarse son como en el formato 8.1 del documento ERS-SASM 8. Los resultados se pueden exportar en formato XLS y CSV
Actores: Administrador, contador
Acciones de los Actores Acción del Sistema
1. Usuario selecciona el reporte de estado
2. El sistema muestra los filtros disponibles. intervalo de fechas de atención (inicio y fin), centro de servicio, técnico, estado de la solicitud
3. El usuario selecciona uno o varios filtros
4. El sistema despliega una tabla con la solicitudes que cumplan las características de la búsqueda.
5. Los datos que se muestran en la tabla son Centro, número de folio, tipo de solicitud, fecha de alta, técnico asignado, estado de la solicitud.
6. El sistema muestra botones para exportación de los datos a XLS y CSV
181
CU: Reporte de adeudos Tabla 36: Caso de uso: Reporte de adeudos Fuente: Elaboración propia
Reporte de adeudos
ID del Caso de Uso: RPT.2
Nombre: Reporte de adeudos
Fecha de creación: 21/08/2017
Creado por: JRV
Actores: Administrador, contador
Descripción: Hacer una búsqueda en la base de datos de las consultas por tipo de adeudo
Referencias: Req: 8.4
Precondiciones: Existen solicitudes en con conceptos de adeudo
Pos condiciones: El sistema muestra una tabla con solicitudes y sus adeudos
Prioridad: BAJA
Flujo Normal: 1. Es visible para el administrador y contador. 2. Las solicitudes se pueden filtrar por un intervalo de fechas de atención (inicio y fin),
se muestra el total de solicitudes obtenidas. 3. Las solicitudes se pueden filtrar por centro de servicio, se muestra el total de
solicitudes obtenidas. 4. Las solicitudes se pueden filtrar por técnico, se muestra el total de solicitudes
obtenidas. 5. Las solicitudes se pueden filtrar por estatus de pago, se muestra el total de
solicitudes obtenidas. 6. Las solicitudes se pueden filtrar por concepto de adeudo, se muestra el total de
solicitudes obtenidas. 7. Los filtros son mutuamente incluyentes 8. Los datos a mostrarse son como en el formato 8.2 del documento ERS-SASM 9. Los resultados se pueden exportar en formato XLS y CSV
Actores: Administrador, contador
Acciones de los Actores Acción del Sistema
1. Usuario selecciona el reporte de adeudos
2. El sistema muestra los filtros disponibles. intervalo de fechas de atención (inicio y fin), centro de servicio, técnico, estatus de pago, y concepto de adeudo
3. El usuario selecciona uno o varios filtros
4. El sistema despliega una tabla con la solicitudes que cumplan las características de la búsqueda.
5. Los datos que se muestran en la tabla son Centro, número de folio, tipo de solicitud, fecha de alta, técnico asignado, estatus de pago, concepto de adeudo, costo e I.V.A.
6. El sistema muestra botones para exportación de los datos a XLS y CSV
182
CU: Reporte de cómputo Tabla 37: Caso de uso: Reporte de cómputo Fuente: Elaboración propia
Reporte de cómputo
ID del Caso de Uso: RPT.3
Nombre: Reporte de cómputo
Fecha de creación: 21/08/2017
Creado por: JRV
Actores: Administrador, contador
Descripción: Hacer una búsqueda en la base de datos de las consultas por tipo de cómputo: Server, Impresión o tenencia
Referencias: Req: 8.4
Precondiciones: Existen solicitudes en cualquier estado
Pos condiciones: El sistema muestra una tabla con solicitudes filtradas
Prioridad: BAJA
Flujo Normal: 1. Es visible para el administrador y contador. 2. Las solicitudes se pueden filtrar por un intervalo de fechas de atención
(inicio y fin), se muestra el total de solicitudes obtenidas con paginación. 3. Los datos de los centros se agrupan por centro, tipo de solicitud y estado 4. Los datos a mostrarse son como en el formato 8.3 del documento ERS-
SASM 5. Los resultados se pueden exportar en formato XLS y CSV
Actores: Administrador, contador
Acciones de los Actores
Acción del Sistema
1. Usuario selecciona el reporte de cómputo
2. El sistema muestra los filtros disponibles. intervalo de fechas de atención (inicio y fin)
3. El usuario selecciona la fecha de inicio y fin
4. Los datos de los centros se agrupan por centro, cómputo y estado
4. El sistema despliega una tabla con las solicitudes que cumplan las características de la búsqueda.
5. Los datos que se muestran en la tabla son Centro, estado, cómputo y cantidad.
6. El sistema muestra botones para exportación de los datos a XLS y CSV
183
CU: Reporte Centros por tipo de solicitud Tabla 38: Caso de uso: Reporte centros por tipo de solicitud Fuente: Elaboración propia
Reporte centros por tipo de solicitud
ID del Caso de Uso: RPT.4
Nombre: Reporte centros por tipo de solicitud
Fecha de creación: 21/08/2017
Creado por: JRV
Actores: Administrador, contador
Descripción: Hacer una búsqueda en la base de datos de las consultas por tipo de solicitud: Servicio o Mantenimiento
Referencias: Req: 8.5
Precondiciones: Existen solicitudes capturadas
Pos condiciones: El sistema muestra una tabla con solicitudes filtradas
Prioridad: BAJA
Flujo Normal: 1. Es visible para el administrador y contador. 2. Las solicitudes se pueden filtrar por un intervalo de fechas de
atención (inicio y fin), se muestra el total de solicitudes obtenidas con paginación.
3. Los datos de los centros se agrupan por centro, tipo de solicitud y estado
4. Los datos a mostrarse son como en el formato 8.4 del documento ERS-SASM
5. Los resultados se pueden exportar en formato XLS y CSV
Actores: Administrador, contador
Acciones de los Actores
Acción del Sistema
1. Usuario selecciona el reporte de centros por tipo de solicitud
2. El sistema muestra los filtros disponibles. intervalo de fechas de atención (inicio y fin)
3. El usuario selecciona las fechas de inicio y fin
4. Los datos de los centros se agrupan por centro, tipo de solicitud y estado
4. El sistema despliega una tabla con las solicitudes que cumplan las características de la búsqueda.
5. Los datos que se muestran en la tabla son Centro, tipo de solicitud, estado y cantidad.
6. El sistema muestra botones para exportación de los datos a XLS y CSV
184
CU: Reporte de técnicos por tipo de solicitud Tabla 39: Caso de uso: Reporte de técnicos por tipo de solicitud Fuente: Elaboración propia
Reporte de técnicos por tipo de solicitud
ID del Caso de Uso: RPT.5
Nombre: Reporte de técnicos por tipo de solicitud
Fecha de creación: 21/08/2017
Creado por: JRV
Actores: Administrador, contador
Descripción: Hacer una búsqueda en la base de datos de las consultas por tipo de solicitud: Servicio o Mantenimiento
Referencias: Req: 8.6
Precondiciones: Existen solicitudes capturadas
Pos condiciones: El sistema muestra una tabla con solicitudes filtradas
Prioridad: BAJA
Flujo Normal: 1. Es visible para el administrador y contador. 2. Las solicitudes se pueden filtrar por un intervalo de fechas de atención
(inicio y fin), se muestra el total de solicitudes obtenidas con paginación. 3. Las solicitudes se pueden filtrar estado de la solicitud, se muestra el
total de solicitudes obtenidas. 4. Los filtros son mutuamente incluyentes. 5. Los datos de los centros se agrupan por técnico, tipo de solicitud y
estado 6. Los datos a mostrarse son como en el formato 8.4 del documento ERS-
SASM 7. Los resultados se pueden exportar en formato XLS y CSV
Actores: Administrador, contador
Acciones de los Actores
Acción del Sistema
1. Usuario selecciona el reporte de técnicos por tipo de solicitud
2. El sistema muestra los filtros disponibles. intervalo de fechas de atención (inicio y fin), tipo de solicitud
3. El usuario selecciona uno o varios filtros
4. Los datos de los centros se agrupan por técnico, tipo de solicitud y estado
4. El sistema despliega una tabla con la solicitudes que cumplan las características de la búsqueda.
5. Los datos que se muestran en la tabla son técnico, tipo de solicitud, estado y cantidad.
6. El sistema muestra botones para exportación de los datos a XLS y CSV
185
CU: Reporte de opciones Tabla 40: Caso de uso: Reporte de opciones Fuente: Elaboración propia
Reporte de opciones
ID del Caso de Uso: RPT.6
Nombre: Reporte de opciones
Fecha de creación: 21/08/2017
Creado por: JRV
Actores: Administrador, contador
Descripción: Hacer una búsqueda en la base de datos de las consultas opción:Ecológico o Local
Referencias: Req: 8.7
Precondiciones: Existen solicitudes en cualquier estado
Pos condiciones: El sistema muestra una tabla con solicitudes filtradas
Prioridad: BAJA
Flujo Normal: 1. Es visible para el administrador y contador. 2. Las solicitudes se pueden filtrar por un intervalo de fechas de
atención (inicio y fin), se muestra el total de solicitudes obtenidas con paginación.
3. Los datos de los centros se agrupan por centro, opción y estado 4. Los datos a mostrarse son como en el formato 8.6 del documento
ERS-SASM 5. Los resultados se pueden exportar en formato XLS y CSV
Actores: Administrador, contador
Acciones de los Actores
Acción del Sistema
1. Usuario selecciona el reporte de opciones
2. El sistema muestra los filtros disponibles. intervalo de fechas de atención (inicio y fin)
3. El usuario selecciona las fechas de inicio y fin
4. Los datos de los centros se agrupan por centro, opción y estado
4. El sistema despliega una tabla con las solicitudes que cumplan las características de la búsqueda.
5. Los datos que se muestran en la tabla son Centro, estado, opción y cantidad.
6. El sistema muestra botones para exportación de los datos a XLS y CSV
Recommended