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