Sistema web para el control de registro y mantenimiento de los bienes informáticos de la corporación

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas

SISTEMA WEB PARA EL CONTROL DE REGISTRO Y MANTENIMIENTO DE LOS BIENES INFORMÁTICOS DE LA CORPORACIÓN NACIONAL DE ELECTRICIDAD (CNEL EP) EN LA PROVINCIA DE SANTO DOMINGO DE LOS TSÁCHILAS DURANTE EL PERIODO 2017- 2018.

Trabajo de Titulación previo a la obtención del título de Ingenieros en Sistemas y Computación

Línea de Investigación: Estudio, Diseño e Implementación de Software

Autores: GUILLERMO ALEXIS BARCIA GÓNGORA NÓLVAR ANDRÉS GÓMEZ EGAS

Director: Mg. RODOLFO SIRILO CÓRDOVA GÁLVEZ

Santo Domingo – Ecuador Enero, 2018

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas HOJA DE APROBACIÓN

SISTEMA WEB PARA EL CONTROL DE REGISTRO Y MANTENIMIENTO DE LOS BIENES INFORMÁTICOS DE LA CORPORACIÓN NACIONAL DE ELECTRICIDAD (CNEL EP) EN LA PROVINCIA DE SANTO DOMINGO DE LOS TSÁCHILAS DURANTE EL PERIODO 2017- 2018.

Línea de Investigación: Estudio, Diseño e Implementación de Software Autores: GUILLERMO ALEXIS BARCIA GÓNGORA NÓLVAR ANDRÉS GÓMEZ EGAS

Rodolfo Sirilo Córdova Gálvez, Mg.

f.

DIRECTOR DEL TRABAJO DE TITULACIÓN Fausto Ernesto Orozco Iguasnia, Mg.

f.

CALIFICADOR Franklin Andrés Carrasco Ramírez, Mg.

f.

CALIFICADOR Luis Javier Ulloa Meneses, Mg.

f.

DIRECTOR DE LA ESCUELA DE SISTEMAS Santo Domingo – Ecuador Enero, 2018

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Guillermo Alexis Barcia Góngora portador de la cédula de ciudadanía No. 0802703702 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniero de Sistemas y Computación son absolutamente originales, auténticos y personales.

En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legal y académica.

Guillermo Alexis Barcia Góngora.

CI. 0802703702

iv

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Nólvar Andrés Gómez Egas portador de la cédula de ciudadanía No. 1724133630 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniero de Sistemas y Computación son absolutamente originales, auténticos y personales.

En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legal y académica.

Nólvar Andrés Gómez Egas CI. 1724133630

v

AGRADECIMIENTO

A la Divina Providencia. Por la vida misma y los momentos de mi infancia y juventud que siempre recordaré.

A mi universidad. Por ser mi segundo hogar y haberme brindado la oportunidad de ser mejor.

Guillermo Barcia

Agradezco a Dios por darme las fuerzas y las ganas necesarias para culminar mi carrera, a mi familia quienes me apoyaron en todo lo indispensable, además de brindarme su apoyo incondicional que ha sido el pilar fundamental en mi camino como estudiante.

Nólvar Gómez

vi

DEDICATORIA

A las personas que me dieron la mano y supieron darme el mejor de los consejos en los momentos más difíciles.

Guillermo Barcia

El presente trabajo de titulación es dedicado a mi familia, quienes han sido parte primordial para culminar mi carrera universitaria, ellos son quienes me brindaron su cariño y apoyo incondicional, además de ser los principales protagonistas de este “sueño alcanzado”.

Nólvar Gómez

vii

RESUMEN

El presente trabajo de titulación contempla como propósito general mejorar la gestión de registros y mantenimientos de los bienes informáticos en la Corporación Nacional de Electricidad de Santo Domingo de los Tsáchilas a través del desarrollo e implementación de un sistema web. Dicho sistema realiza una administración adecuada de los registros de los bienes y se mejora el control de sus respectivos mantenimientos tanto preventivos como correctivos que lleva a cabo el centro de cómputo. La composición y elaboración del sistema SGtics (Sistema para el control de registros y mantenimiento de los bienes) se encuentra dividido en cuatro módulos, los cuales son; proveedores y bienes los cuales son módulos que sirven para registrar los bienes con sus respectivas características; encargados que permite registrar la persona a cargo del bien; y mantenimiento para cada bien registrado. El presente documento de investigación se realizó de forma secuencial, utilizando la metodología ágil de desarrollo de software XP, la cual fue seleccionada de acuerdo al previo análisis comparativo entre metodologías ágiles. Utiliza una arquitectura Modelo Vista Controlador, Spring y java hibernate como framework’s web para el desarrollo ágil, Bootstrap como herramienta de programación frontend, IBM DB2 para la gestión de la bases de datos, con la finalidad de brindar al cliente un sistema totalmente funcional, agradable a la vista y de fácil utilización.

Palabras clave: Mantenimiento, Diseño de sistemas, Tecnologías de la información, Automatización, Inventario.

viii

ABSTRACT The current titling work has as general purpose to improve the management of records and maintenance of computer goods in the Corporaciรณn Nacional de Electricidad de Santo Domingo de los Tsรกchilas through the development and implementation of a web system. Such system makes an adequate administration of the registers of the goods and improves the control of their respective maintenance both preventive and corrective carried out by the computer center. The composition and development of the SGtics system (System for the control of records and maintenance of goods) is divided into four modules, which are; suppliers and goods which are modules that serve to register the goods with their respective characteristics; managers that allow to register the person in charge of the property; and maintenance for each registered asset. This research document was made sequentially, using the agile methodology of software development XP, which was selected according to the previous comparative analysis among agile methodologies. It uses a View Controller Model, Spring and java hibernate as web frameworks for agile development, Bootstrap as frontend programming tool, IBM DB2 for database management, in order to provide the customer with a fully functional, pleasant system at sight and easy to use.

Keywords: Maintenance, Systems design, Information technologies, Automation, Inventory.

ix

ÍNDICE DE CONTENIDOS

1. INTRODUCCIÓN ................................................................................................................. 1 2. PLANTEAMIENTO DEL PROBLEMA .............................................................................. 2 2.1. Antecedentes ....................................................................................................................... 2 2.1.1. Revisión literaria e Investigaciones previas relacionados con la temática. ..................... 3 2.2. Problema de investigación .................................................................................................. 5 2.3. Justificación de la investigación ......................................................................................... 6 2.4. Objetivos de investigación .................................................................................................. 7 2.4.1. Objetivo General. ............................................................................................................. 7 2.4.2. Objetivos Específicos....................................................................................................... 7 3. MARCO REFERENCIAL ..................................................................................................... 8 3.1. Revisión de los fundamentos teóricos................................................................................. 9 3.1.1. Conceptos básicos. ........................................................................................................... 9 3.1.1.1. Software. ....................................................................................................................... 9 3.1.1.2. Ingeniería de software. .................................................................................................. 9 3.1.1.3. Proceso de software. ..................................................................................................... 9 3.1.1.4. Ciclo de vida del software........................................................................................... 10 3.1.1.5. Paradigma orientado a objetos. ................................................................................... 10 3.1.2. Metodologías de desarrollo de software. ....................................................................... 11 3.1.2.1. Metodologías tradicionales. ........................................................................................ 12 3.1.2.1.1. Cascada. ................................................................................................................... 12 3.1.2.1.2. Rup. .......................................................................................................................... 13 3.1.2.1.3. Msf. .......................................................................................................................... 13 3.1.2.2. Metodologías ágiles. ................................................................................................... 14 3.1.2.2.1. Programación extrema (xp)...................................................................................... 15 3.1.2.2.1.1. Valores xp. ............................................................................................................ 15 3.1.2.2.1.2. Roles y responsabilidades. .................................................................................... 16 3.1.2.2.1.3. Proceso xp. ............................................................................................................ 17 3.1.2.2.2. Scrum. ...................................................................................................................... 17 3.1.2.2.2.1. Pilares y valores scrum. ........................................................................................ 18 3.1.2.2.2.2. Eventos de scrum. ................................................................................................. 19 3.1.2.2.2.3. Roles de scrum. ..................................................................................................... 19 3.1.2.2.2.4. Proceso scrum. ...................................................................................................... 20 3.1.2.3. Tabla comparativa entre metodologías de desarrollo tradicionales y ágiles............... 21 3.1.2.3.1. Gestión de la incertidumbre del proyecto. ............................................................... 21 3.1.2.3.2. Gestión del cambio del proyecto.............................................................................. 21 3.1.2.3.3. Gestión de los equipos del proyecto. ....................................................................... 22 3.1.2.3.4. Procesos de dirección de proyectos. ........................................................................ 22 3.1.2.4. Tabla comparativa entre metodologías ágiles. ............................................................ 23 3.2. Aplicaciones web .............................................................................................................. 26 3.2.1. Arquitectura de aplicaciones web. ................................................................................. 26

x

3.2.1.1. Arquitectura cliente/servidor. ..................................................................................... 26 3.2.1.2. Arquitectura de tres niveles. ....................................................................................... 26 3.2.1.3. Modelo vista controlador (mvc).................................................................................. 27 3.2.2. Tipos de aplicaciones web. ............................................................................................ 28 3.2.2.1. Aplicaciones estáticas. ................................................................................................ 28 3.2.2.2. Aplicaciones web dinámicas. ...................................................................................... 28 3.3. Herramientas de desarrollo web........................................................................................ 29 3.3.1. Eclipse JEE. ................................................................................................................... 29 3.3.2. Spring framework. ......................................................................................................... 29 3.3.3. Java Hibernate. ............................................................................................................... 29 3.3.4. DB2. ............................................................................................................................... 29 3.4. Gestión Administrativa ..................................................................................................... 30 3.4.1. Administración. .............................................................................................................. 30 3.4.2. Sistema de Gestión. ........................................................................................................ 30 3.4.3. Proceso de Administración. ........................................................................................... 30 3.4.4. Calidad de servicio. ........................................................................................................ 30 3.4.5. Inventario. ...................................................................................................................... 31 3.4.6. Administración de inventario. ........................................................................................ 31 3.4.7. Importancia de la administración de inventario. ............................................................ 31 3.4.8. Mantenimiento preventivo. ............................................................................................ 31 3.4.9. Mantenimiento correctivo. ............................................................................................. 31 4. METODOLOGÍA DE LA INVESTIGACIÓN ................................................................... 32 4.1. Diseño / Tipo de investigación ......................................................................................... 32 4.1.1. Enfoque de Investigación. .............................................................................................. 32 4.1.2. Diseño de Investigación. ................................................................................................ 32 4.1.3. Tipo de Investigación. .................................................................................................... 33 4.1.3.1. Investigación descriptiva. ........................................................................................... 33 4.1.3.2. Investigación aplicada. ................................................................................................ 33 4.1.3.3. Investigación de campo............................................................................................... 33 4.2. Población / Universo ......................................................................................................... 34 4.2.1. Población........................................................................................................................ 34 4.2.2. Muestra. ......................................................................................................................... 34 4.3. Técnicas/ Instrumentos para la recolección de datos ........................................................ 34 4.4. Técnica de Análisis de Datos ............................................................................................ 35 4.5. Metodología de desarrollo de Software ............................................................................ 36 4.5.1. Descripción de Roles y Responsabilidades de XP. ........................................................ 36 4.5.2. Fases de la Metodología XP. ......................................................................................... 36 4.5.2.1. Fase de planeación. ..................................................................................................... 37 4.5.2.2. Fase de diseño. ............................................................................................................ 37 4.5.2.3. Fase de codificación. ................................................................................................... 37 4.5.2.4. Fase de pruebas. .......................................................................................................... 38 4.5.2.5. Muerte. ........................................................................................................................ 38 5. RESULTADOS.................................................................................................................... 39 5.1. Análisis y Discusión de los resultados ............................................................................. 39

xi

5.1.1. Entrevista realizada al personal del centro de cómputo en CNEL EP. .......................... 39 5.1.1.1. Conclusión de la entrevista. ........................................................................................ 40 5.1.2. Entrevista realizada al jefe del centro de cómputo. ....................................................... 41 5.1.2.1. Conclusión de la entrevista ......................................................................................... 41 5.1.3. Encuesta realizada a los miembros del departamento de cómputo en la Empresa ........ 42 5.2. Resultados de la Aplicación de la Metodología XP.......................................................... 50 5.2.1. Fase de planeación. ........................................................................................................ 50 5.2.1.1. Historias de usuario..................................................................................................... 50 5.2.1.2. Plan de publicaciones. ................................................................................................. 51 5.2.1.3. Plan de iteraciones. ..................................................................................................... 52 5.2.2. Fase de diseño. ............................................................................................................... 53 5.2.2.1. Tarjetas CRC. .............................................................................................................. 53 5.2.2.2. Diseño de la base de datos. ......................................................................................... 61 5.2.2.2.1. Diseño lógico de la base de datos. ........................................................................... 61 5.2.2.2.2. Diccionario de datos. ............................................................................................... 62 5.2.2.2.3. Script de la base de datos. ........................................................................................ 62 5.2.2.2.4. Diseño de interfaces. ................................................................................................ 62 5.2.2.2.5. Interfaces ingreso/registro. ....................................................................................... 63 5.2.2.2.6. Interfaces internas. ................................................................................................... 64 5.2.3. Fase de codificación. ...................................................................................................... 67 5.2.3.1. Codificación a nivel de base de datos. ........................................................................ 67 5.2.3.2. Codificación de interfaces........................................................................................... 68 5.2.3.3. Fase de pruebas. .......................................................................................................... 72 5.2.3.3.1. Pruebas unitarias. ..................................................................................................... 72 5.2.3.3.2. Pruebas de aceptación. ............................................................................................. 73 5.2.4. Fase final. ....................................................................................................................... 74 5.3. Análisis de impactos ......................................................................................................... 74 5.3.1. Impacto tecnológico. ...................................................................................................... 75 5.3.2. Impacto social ................................................................................................................ 75 5.3.3. Impacto ambiental. ......................................................................................................... 76 5.3.4. Impacto Económico ....................................................................................................... 76 5.3.5. Impacto general .............................................................................................................. 77 5.4. Conclusiones ..................................................................................................................... 78 5.5. Recomendaciones ............................................................................................................. 79 GLOSARIO DE TÉRMINOS........................................................................................... 85 ANEXOS .......................................................................................................................... 86

xii

ÍNDICE DE TABLAS Tabla 1 Investigaciones previas ................................................................................................. 4 Tabla 2 Comparación entre Metodología Tradicional y Ágil .................................................. 22 Tabla 3 Comparativa de Metodologías (XP y Scrum) ............................................................. 25 Tabla 4 Administración de los procesos de registro y control de mantenimiento de los dispositivos .............................................................................................................................. 42 Tabla 5 Gestión de la duración de garantías ............................................................................ 43 Tabla 6 Inconvenientes en la ejecución de los procesos de registro de equipos...................... 44 Tabla 7 Administración de los mantenimientos preventivos y correctivos de los equipos ..... 45 Tabla 8 Utilidad de las aplicaciones web en la administración de inventarios ........................ 46 Tabla 9 Beneficios de la aplicación de sistemas web en la administración de equipos ........... 47 Tabla 10 Necesidad de agilizar los procesos de registro y mantenimiento de equipos ........... 48 Tabla 11 Aceptación de la implementación de un sistema web en la empresa ....................... 49 Tabla 12 Plantilla de Historia de Usuario ................................................................................ 51 Tabla 13 Plan de Entregas........................................................................................................ 52 Tabla 14 Plan de Iteraciones .................................................................................................... 53 Tabla 15 Tarjeta CRC Agencia ................................................................................................ 54 Tabla 16 Tarjeta CRC Área ..................................................................................................... 54 Tabla 17 Tarjeta CRC Código ................................................................................................. 55 Tabla 18 Tarjeta CRC Departamento ...................................................................................... 55 Tabla 19 Tarjeta CRC Dispositivo complemento .................................................................... 56 Tabla 20 Tarjeta CRC Dispositivo Tipo .................................................................................. 56 Tabla 21 Tarjeta CRC Dispositivo Tipo 4 ............................................................................... 57 Tabla 22 Tarjeta CRC Dispositivo........................................................................................... 57 Tabla 23 Tarjeta CRC Mantenimiento ..................................................................................... 58 Tabla 24 Tarjeta CRC Detalle Mantenimiento ........................................................................ 58 Tabla 25 Tarjeta CRC Marca ................................................................................................... 59 Tabla 26 Tarjeta CRC MyRevision ......................................................................................... 59 Tabla 27 Tarjeta CRC Sistema Operativo ............................................................................... 60 Tabla 28 Tarjeta CRC Usuario ................................................................................................ 60 Tabla 29 Definición de permisos ............................................................................................. 67 Tabla 30 Plantilla Prueba de Aceptación ................................................................................. 73 Tabla 31 Tabla de identificación de los niveles de impactos................................................... 74 Tabla 32 Impacto tecnológico. ................................................................................................ 75 Tabla 33: Impacto social ......................................................................................................... 75 Tabla 34 Impacto ambiental..................................................................................................... 76 Tabla 35 Impacto Económico .................................................................................................. 76 Tabla 36 Impacto general......................................................................................................... 77

xiii

ÍNDICE DE FIGURAS Figura 1. Esquema de Contenidos. ............................................................................................ 8 Figura 2. Flujo de proceso "Cascada". ..................................................................................... 12 Figura 3. Modelo de gobernanza MSF. ................................................................................... 13 Figura 4. Flujo del Proceso XP.. .............................................................................................. 17 Figura 5. Roles de Scrum.. ....................................................................................................... 20 Figura 6. Proceso Scrum.. ........................................................................................................ 20 Figura 7. Gráfica del uso de las Metodologías Ágiles. ............................................................ 24 Figura 8. Arquitectura Cliente/Servidor.. ................................................................................ 26 Figura 9. Arquitectura en tres niveles.. .................................................................................... 27 Figura 10. Patrón Modelo Vista Controlador.. ........................................................................ 28 Figura 18. Administración de registro y control de mantenimiento de los dispositivos.......... 42 Figura 19. Gestión de la duración de las garantías. ................................................................. 43 Figura 20. Inconvenientes en la ejecución de los procesos de registro de equipos. ................ 44 Figura 21. Administración de los mantenimientos preventivos y correctivos de los equipos. 45 Figura 22. Utilidad de las aplicaciones web en la administración de inventarios. .................. 46 Figura 23. Beneficios de la aplicación de sistemas web en la administración de equipos. ..... 47 Figura 24. Necesidad de agilizar los procesos de registro y mantenimiento de equipos. ........ 48 Figura 25. Aceptación de la implementación de un sistema web en la empresa. .................... 49 Figura 26. Diseño lógico de la base de datos. .......................................................................... 61 Figura 27. Prototipo interfaz de Login. .................................................................................... 63 Figura 28. Prototipo interfaz de Registro. ................................................................................ 63 Figura 29. Prototipo del Panel Principal. ................................................................................. 64 Figura 30. Prototipo Módulo de Usuarios................................................................................ 64 Figura 31. Prototipo Módulo de Catálogos. ............................................................................. 65 Figura 32. Prototipo Módulo de Dispositivos. ......................................................................... 65 Figura 33. Prototipo ingreso nuevo dispositivo. ...................................................................... 66 Figura 34. Prototipo interfaz Módulo Consultas...................................................................... 66 Figura 35. Parámetros de conexión.. ........................................................................................ 67 Figura 36. Conexión a la base de datos.................................................................................... 68 Figura 37. Codificación Login de Usuario. ............................................................................. 68 Figura 38. Interfaz Inicio de Sesión. ........................................................................................ 69 Figura 39. Interfaz Módulo Dispositivos. ................................................................................ 69 Figura 40. Interfaz Registro de Dispositivos. .......................................................................... 70 Figura 41. Codificación Registro de dispositivos. ................................................................... 70 Figura 42. Codificación Módulo Mantenimientos. .................................................................. 71 Figura 43. Interfaz Módulo Mantenimientos. .......................................................................... 71 Figura 44. Resultado Prueba Unitaria – Clase Dispositivo...................................................... 72

xiv

ร NDICE DE ANEXOS

Anexo 1: Entrevista realizada al personal del centro de cรณmputo en CNEL EP ..................... 86 Anexo 2: Entrevista realizada al jefe del centro de cรณmputo................................................... 88 Anexo 3: Encuesta realizada a los miembros del centro de cรณmputo de la CNEL EP ............ 89 Anexo 4: Acta de requerimientos ............................................................................................ 91 Anexo 5: Acta de entrega recepciรณn ........................................................................................ 95 Anexo 6: Carta de impacto ...................................................................................................... 96 Anexo 7: Historias de usuario .................................................................................................. 97 Anexo 8: Diccionario de datos ............................................................................................... 119 Anexo 9: Script de la Base de Datos ...................................................................................... 127

1

INTRODUCCIÓN La presente investigación pretende mejorar la administración que se lleva a cabo al momento de brindar mantenimiento preventivo y correctivo a los bienes informáticos que posee la Corporación nacional de electricidad a través de un software orientado a la web que monitoree y administre los periodos en los que se debe realizar dichos mantenimientos, se pretende desarrollar esta aplicación orientada a la web por motivo de portabilidad, ofreciendo la posibilidad de ser ejecutada sobre cualquier sistema operativo existente (Windows, Linux, Mac OS).

Para comenzar con el proyecto de investigación se realizó la recopilación de material bibliográfico relacionado con la temática, haciendo uso de artículos científicos, libros, revistas científicas, etc. Toda esta bibliografía se centra en las nuevas tendencias de la programación, tanto en la sección de herramientas para el diseño, como en la sección de desarrollo del software, de esta manera se obtendrá un sistema web flexible, escalable y robusto, que sea capaz de satisfacer todas las necesidades que tiene la Corporación nacional de electricidad.

Este proyecto presenta los siguientes temas: Como primer tema se presenta el planteamiento de la investigación, el problema, el objetivo general y los objetivos específicos, la justificación, además del marco teórico.

También se abordan los aspectos metodológicos se usaron dentro del proyecto de investigación.

En segundo lugar se abordan los aspectos teóricos con relación a la administración y mantenimiento de bienes informáticos, sus características y como los sistemas informáticos mejoran los procesos de gestión dentro de las instituciones. Se tratan aspectos como la metodología de desarrollo de software. Se describe también qué es un sistema web y como está diseñado internamente, y se fundamenta por qué es necesario.

Por último se aborda los aspectos relacionados con el desarrollo de software. Se propone el uso de herramientas modernas, robustas y ágiles que se adapten con facilidad al desarrollo del presente proyecto investigativo.

2

PLANTEAMIENTO DEL PROBLEMA Antecedentes La Empresa Eléctrica Pública Estratégica Corporación Nacional de Electricidad CNEL EP es la mayor Empresa de distribución y comercialización de energía eléctrica en el Ecuador, se constituyó mediante Decreto Ejecutivo No. 1459, emitido el 13 de marzo de 2013 por el Presidente de la República, Rafael Correa Delgado, con el fin de prestar los servicios públicos de distribución y comercialización de energía eléctrica, actualmente tiene la responsabilidad de servir a más de 2,3 millones de clientes, con una cobertura del 95% dentro de su área de servicio incluyendo a la provincia de Santo Domingo de los Tsáchilas donde se tiene establecida una matriz, agencias y subestaciones.

La misión de la Empresa eléctrica es brindar el servicio público de distribución y comercialización de energía eléctrica para generar bienestar a los consumidores y contribuir al desarrollo del país, con talento humano comprometido, tecnología de punta, innovación y respeto al ambiente. Su visión es ser una Empresa líder en la prestación del servicio eléctrico en el Ecuador, reconocida por su calidad, cobertura y eficiencia.

Uno de los principales problemas que presentaba la empresa eléctrica (CNEL EP) era la forma en que se llevaba el registro de la adquisición de nuevos equipos informáticos el cual era inadecuado, todo esto conllevaba a un deficiente control en la administración de los datos en los registros de los nuevos equipos informáticos que adquiere la empresa.

En la empresa de estudio había una carencia al momento de llevar el control en el manejo de garantías, debido a la inexistencia de este control se generaba un total desconocimiento de todos los beneficios que brindan los proveedores a la empresa por motivos de garantía en equipos informáticos.

Otro factor a tomar en cuenta, era el mantenimiento que se les daba a los equipos dentro de la empresa eléctrica ya que era inadecuado, ante la falta de un historial de los cuidados que se llevaban de los equipos, todo esto generaba un desconocimiento del cronograma de los mantenimientos a todos los equipos informáticos, todo esto por la inexistencia de un historial de mantenimientos a los equipos de la corporación.

3

2.1.1. Revisión literaria e Investigaciones previas relacionados con la temática.

Con la finalidad de sustentar el desarrollo de la presente investigación, se ha realizado una amplia revisión literaria tanto de sistemas como de trabajos de investigación similares al planteado, procurando que estos compartan características destacadas, tengan relación con la temática y haciendo énfasis en trabajos de actualidad. Además, se proporciona una explicación deductiva para un mejor entendimiento.

Explicación.

Como primer punto hay que destacar que las soluciones informáticas hoy en día son de gran ayuda dado que han modernizado la forma en cómo se llevaban los procesos de una determinada empresa. Existen sistemas desde los más sencillos hasta los más complejos y completos que abarcan un gran número de Áreas/Departamentos de una empresa y consigo la administración de sus respectivos procesos. Es aquí donde comienza nuestro análisis, realizando una breve investigación sobre estos sistemas completos, y en este caso en particular, los CMMS. Los CMMS (Computerized Maintenance Management System) son sistemas que permiten llevar la gestión del mantenimiento hacia un nivel empresarial. Es una plataforma que administra el mantenimiento tanto predictivo, preventivo, correctivo, etc., de los equipos e instalaciones de una empresa. Son sistema que generalmente poseen varios módulos y suelen integrarse con sistemas ERP para complementar sus funciones administrativas, además de ser particularmente costosos (licencia propietario). IBM es uno de los grandes exponentes en este campo con su software MAXIMO Asset Management.

4

Revisión A continuación se presenta una tabla con los trabajos de investigación más relevantes y con temática similar: Tabla 1 Investigaciones previas

Año

Autor/es

2014

Michael Herrera Galán, Yoenia Duany-Alfonso, Armando AbreuDuque Yanelis Suárez Fragas, Diarelys Medina Peña, Pablo Hernández Alfonso

2015

Título

Contribución/Descripción

Sistema Automatizado para la Gestión del Mantenimiento

Creación de un sistema para planificar, controlar, optimizar y automatizar los procesos de los mantenimientos a equipos a través de un GMAO Elaboración de un sistema informático que brinde apoyo en los procesos de administración de los mantenimientos y la reparación de los equipos en la Universidad UNAH mejorando de forma significativa la forma en cómo se los llevaba (manualmente) a llevarlos de forma automatizada.

Desarrollo de un software para brindar soluciones integrales a personas, procesos y medios que intervengan en la utilización de equipos informáticos, brindando beneficios en las áreas de soporte técnico (mantenimientos) y de servicio al cliente

a

b

Sistema automatizado para la gestión del mantenimiento de equipos (módulos patrimonio y órdenes de trabajo)

c

Sistema automatizado para la gestión del mantenimiento de equipos (módulos administración y solicitud de servicio)

2015

Ángel Ibujés Villacís

d

2017

Hugo Silva Alvarez

e

Análisis, diseño y desarrollo de una herramienta de administración de mantenimiento y reparación de equipos informáticos, Computerized Maintenance Management System, CMMS

Desarrollo e implementación de un sistema web con MVC para el control del mantenimiento preventivo y correctivo de los bienes del Cuerpo de Bomberos del Gobierno Autónomo Descentralizado Municipal de Santo Domingo; periodo 2016-2017

Elaboración de un sistema que permite realizar una administración eficiente en el registro de los dispositivos informáticos y mejora en los procesos de seguimiento y control de los mantenimientos.

Fuente: Adaptado de a) Herrera, M., Duany-Alfonso, Y., & Abreu-Duque, A. (2014). Sistema Automatizado para la Gestión del Mantenimiento. Inge@UAN, 4(8), 48-54. Obtenido de http://csifesvr.uan.edu.co/index.php/ingeuan/article/view/268/pdf b) Medina, D., Suárez, Y., & Hernández, P. (2015). Sistema automatizado para la gestión del mantenimiento de equipos (módulos patrimonio y órdenes de trabajo). Revista Ciencias Técnicas Agropecuarias, 24, 79-84. Obtenido de http://www.redalyc.org/pdf/932/93243475014.pdf c) Suárez, Y., Medina, D., & Hernández, P. (2015). Sistema automatizado para la gestión del mantenimiento de equipos (módulos administración y solicitud de servicio). Revista Ciencias Técnicas Agropecuarias, 4(5), 85-90. Obtenido de http://www.rcta.unah.edu.cu/index.php/rcta/article/view/395/404 d) Ibujés, Á.

(2015). Análisis, Diseño y Desarrollo de una herramienta de Administración de Mantenimiento y Reparación de Equipos Informáticos, Computarized Maintenance Management System, CMMS. (tesis de grado), Universidad Central del Ecuador, Quito, Ecuador. Obtenido de http://www.dspace.uce.edu.ec/handle/25000/4297 e) Silva, H. (2017). Desarrollo e implementación de un sistema web con MVC para el control del mantenimiento preventivo y correctivo de los bienes del Cuerpo de Bomberos del Gobierno Autónomo Descentralizado Municipal de Santo Domingo; periodo 2016-2017. (tesis de grado), Pontificia Universidad Católica del Ecuador, Santo Domingo, Ecuador.

Obtenido de https://issuu.com/pucesd/docs/dg_2017_-_silva_hugo

5

Problema de investigación El presenta proyecto de investigación responderá a la problemática: ¿Cómo mejorar el control de registros y mantenimiento de los bienes informáticos de la Corporación Nacional de Electricidad (CNEL EP) de Santo Domingo de los Tsáchilas?

La CNEL EP disponía de un sistema informático que no permitía llevar un control adecuado de todos los bienes existentes en la corporación, por tal motivo se requiere un sistema web para el control de registro y mantenimiento preventivo y correctivo en la institución.

El registro y el control de los mantenimientos tanto preventivos como correctivos no era adecuado para la corporación, todo esto generaba un retraso en la solución de los sucesos, también había demora en los procesos laborales de los empleados lo que producía una pérdida de productividad tanto en el centro de cómputo como en los demás departamentos dentro de la empresa.

Uno de los factores más importantes a resaltar es la pérdida de equipos que se ha presentado, todo esto es debido al déficit en el control de los equipos, dentro de la corporación existe la política de que cada empleado tiene a su cargo uno o más equipos para laborar, para el centro de cómputo era una tarea difícil el llevar un adecuado control de los diferentes equipos y de sus custodios.

El presente trabajo de investigación pretende ayudar a responder las siguientes preguntas directrices: ¿Cuál es el proceso que se lleva al momento de registrar los equipos informáticos dentro de la empresa? ¿Cuál es el proceso que se lleva al momento de realizar el mantenimiento a los equipos informáticos dentro de la empresa? ¿Qué metodología de software permite un desarrollo ágil, flexible y escalable al momento de elaborar un sistema web? ¿Cuáles son los requerimientos necesarios que debe cubrir el sistema web para gestionar el control de los bienes informáticos eficientemente?

6

¿Cómo conocer la efectividad de un sistema web para el registro y mantenimiento de los bienes informáticos?

Justificación de la investigación La Corporación Nacional de Electricidad de Santo Domingo usaba un sistema control manual, que requirió mayor esfuerzo de parte de los profesionales del departamento de cómputo de la empresa, aun así se desencadenaron una serie de problemas que afectaron a toda la empresa, como la falta de mantenimiento y control de garantías además del deficiente control de asignación de responsables de cada uno de los bienes informáticos por tanto fue propenso a varias irregularidades con los bienes informáticos de la empresa.

La popularidad de las aplicaciones web reside en el fácil acceso que estas tienen, porque solo se necesita un navegador web, su funcionamiento sobre cualquier sistema operativo, la facilidad de actualización y mantenimiento sin tener que instalar o reinstalar la aplicación a cada usuario. Además destaca que las aplicaciones en la nube son más que almacenamiento si no que ofrecen funcionalidades desde la nube que cualquier usuario puede acceder, usar y compartir información. (Hernández Claro & Greguas Navarro, 2016, págs. 69-70) El presente proyecto de investigación está relacionado con el objetivo número once del plan nacional del buen vivir: “Asegurar la soberanía y eficiencia de los sectores estratégicos para la transformación industrial y tecnológica”, concretamente al inciso 11.3.m, el cual menciona: “Promover el uso de TIC en la movilidad eficiente de personas y bienes, y en la gestión integral de desechos electrónicos, para la conservación ambiental y el ahorro energético”. Con ello se pretende gestionar de una manera más óptima todos los procesos que se llevan a cabo dentro de la empresa de estudio. (Secretaría Nacional de Planificación y Desarrollo, 2013) Siendo la Corporación Nacional de Electricidad una entidad pública, que proporciona la producción y distribución de energía eléctrica, todos los empleados tienen a su disposición varios equipos informáticos que les facilita su labor diaria dentro de la empresa, al ser un numero grande de dispositivos resulta complicado llevar un adecuado control de los mantenimientos y los registros de dichos equipos, de esta manera surge la necesidad de manejar una herramienta informática que controle tanto el inventario de los equipos como el mantenimiento que se da a los mismos.

7

Los motivos que determinan la importancia y justifican el desarrollo de sistema web son: registrar y controlar los procesos de mantenimiento tanto preventivo como correctivo que antes se realizaban de una manera inadecuada, a través de este sistema informático se busca la optimización de recursos, procesos y tiempo, permitiendo a la empresa llevar un control adecuado de todos los procesos que se llevan a cabo.

La automatización del sistema para dicho control no solamente mejoró el proceso, sino ha optimizado los tiempos invertidos en las fases que se lleva manualmente, he aquí la importancia y justificación del desarrollo del sistema de información web puesto la productividad de la empresa depende esencialmente de los equipos tecnológicos.

Dicho sistema ha permitido realizar los mantenimientos de los bienes informáticos en los plazos definidos por la institución, y controlar de mejor manera el registro de dichos bienes, al realizarse con herramientas robustas, el sistema es escalable y no es propenso a la pérdida de rendimiento por manejar unos grandes volúmenes de datos, esto es gracias al uso de nuevas tecnologías y herramientas de software libre y privativas.

Objetivos de investigación 2.4.1. Objetivo General.

Implementar un sistema web de registro y mantenimiento de los bienes informáticos de la Corporación Nacional de Electricidad (CNEL), en el periodo 2017.

2.4.2. Objetivos Específicos.

Determinar los diferentes procesos para control de registro y mantenimiento de los bienes informáticos dentro de la Empresa CNEL EP. Definir los recursos de desarrollo de hardware y software para la construcción del sistema.

Seleccionar la metodología de desarrollo de software ágil, que se va aplicar en el desarrollo del sistema web.

Desarrollar el sistema web para el registro y mantenimiento de los bienes informáticos.

8

MARCO REFERENCIAL Software

Ingenieria de Software

Conceptos Básicos

Proceso de Software

Ciclo de vida del software

Revisión Fundamentos Teóricos

Paradigma Orientado a Objetos

Cascada

Metodologías tradicionales

RUP

MSF

Valores XP

Programación Extrema

Roles y Responsabilidades

Proceso XP

Metodologías de Desarrollo de Software

Pilares y Valores

Eventos Scrum SCRUM Roles Scrum Metodologías Ágiles

Proceso Scrum

Arquitectura Cliente/Servidor

Arquitectura de aplicaciones web

Contenidos Marco Referencial

Gestión de la incertidumbre Arquitectura de tres niveles

Gestión del cambio Modelo Vista Controlador Aplicaciones Web

Tabla Comparativa Metodos Tradicionales y Ágiles Gestion de los Equipos

Aplicaciones Estáticas Tipos de Aplicaciones Web

Tabla Comparativa Métodologías Ágiles

Aplicaciones Web Dinámicas Eclipse JEE

Spring Framework Herramientas de Desarrollo Web Java Hibernate

DB2

Administración

Sistema de Gestión

Gestión Administrativa

Proceso Administrativo

Calidad de Servicio

Inventario

Figura 1. Esquema de Contenidos. Fuente: Datos obtenidos de la investigación de campo

Procesos de Dirección

9

Revisión de los fundamentos teóricos 3.1.1. Conceptos básicos.

Software.

El software es un programa de cómputo que se compone de varias secuencias de órdenes, que le indican al computador que acción debe realizar en un momento determinado.

Es decir, el ordenador va a procesar todas las instrucciones que le indican que operaciones o tareas debe realizar en cada instante determinado, las instrucciones se sitúan en memoria y son leídas desde el procesador para su ejecución o procesamiento. (Joyanes, 2013, pág. 10).

Ingeniería de software.

Es una parte de la ingeniería que se relaciona con aspectos que competen en la producción de software (Sommerville, 2011, pág. 6). Además, ofrece varios métodos y técnicas que se involucran en el proceso de producción y mantenimiento para asegurar el desarrollo de software de calidad capaz de brindar soluciones estables.

Con respecto a la creación de Sistemas de Información, lo principal a considerar es poseer las bases del software, y de esta manera, abarcar los requerimientos no funcionales que son aquellos que potencian las capacidades y características del sistema de información. Es aquí donde la Ingeniería de Software ayuda a cumplir este propósito, fijando varios fundamentos para el desarrollo de software que incluyen tanto los requerimientos funcionales y no funcionales de un sistema (Ixmatlahua, Raygoza, Romero, Uribe, & Vargas, 2015, pág.

45).

Proceso de software.

El proceso de software de acuerdo con Sommerville (2011) es el conjunto de procesos y actividades que se hallan involucrados en la creación y despliegue de un software (pág. 743).

Es decir, que son actividades que el equipo de trabajo (o de desarrollo) ejecuta en secuencia con la finalidad de seleccionar las mejoras tareas y herramientas para el desarrollo rápido de software de calidad.

10

Ciclo de vida del software.

Se entiende como ciclo de vida de software al conjunto de fases por medio de las cuales un producto de software pasa desde su etapa inicial (concepción) hasta la fase final (retiro del servicio). Cada producto de software tiene su ciclo de vida, y estos a su vez suelen tener una duración larga (Gibson, 2017). De forma general, todo desarrollo de software, ya sea de forma directa o indirecta, pasa al menos por las siguientes fases que a continuación se mencionan: 

Requerimientos: cubre las necesidades del cliente.



Diseño: define la estructura del software.



Codificación: se escribe el software en código.



Pruebas: se pone a prueba el software para eliminar posibles defectos.



Mantenimiento: mejoras del software luego del despliegue.

Paradigma orientado a objetos.

Los lenguajes de programación proporcionan al programador diversos mecanismos para poner en funcionamiento un paradigma de programación. Un paradigma es una forma de comprender y representar la realidad que nos rodea, cada paradigma nuevo es capaz de replicar una necesidad real, volviéndolo apto para afrontar cualquier problema, brindando de forma rápida e inmediata una solución a dichos problemas.

El paradigma orientado a objetos permite modelar el mundo a través de la abstracción de la realidad y codificarlo en un lenguaje de programación determinado creando un software que dé solución a un problema (Flórez, 2012, pág. 23). La programación orientada a objetos o POO mira los problemas de otra forma, basándose en el concepto primordial de objeto, es decir, la realidad se representará por medio de objetos, los cuales poseen estados o características (atributos) y algunos comportamientos (métodos) (López & Gutiérrez, 2014, págs. 104-105).

La programación orientada a objetos es un paradigma muy diferente a los clásicos, dado que hace uso de técnicas o métodos diferentes para la resolución de problemas. De acuerdo con Moreno (2012), entre las características fundamentales de POO se encuentran los siguientes: 

Abstracción: es la acción que se realiza para identificar todas las características que posee el objeto (las cuales formarán parte del programa), y a partir de ello, crear las clases que poseerá los atributos y métodos.

11



Encapsulamiento: consiste en un principio de ocultamiento, es decir, el programador no necesariamente debe conocer cómo trabaja el método que un objeto ejecuta, simplemente lo ejecuta (conoce la interfaz). En otras palabras, el objeto se ve según el comportamiento o acción externa.



Herencia: hace referencia a la forma en cómo se estructuran las clases, la cual se realiza de forma jerárquica. Con ello se consigue que se herede características (propiedades, métodos) a la nueva definición de clase.



Polimorfismo: un método puede ser creado de diversas maneras, consiguiendo que un mismo método tenga diferentes comportamientos (pág. 41-42).

3.1.2. Metodologías de desarrollo de software.

Una metodología determina una forma de representación que permite el uso de patrones o modelos, de igual forma posibilita el intercambio de información entre las partes que intervienen en el desarrollo de un sistema. He aquí donde radica el éxito de un proyecto, el saber manejar las partes interesadas (participantes del proyecto), las expectativas y la comunicación entre todos ellos. (Cendejas, Vega, Isordia, Gutiérrez, & Ferreira, 2014, págs.

138-139) Las metodologías de desarrollo de software, como se describe en Amaya (2013), son la colección de procedimientos, herramientas, técnicas, etc., que sirven de apoyo para los desarrolladores en su tarea de crear software, ésta a su vez se basan en una filosofía y se compone de fases, que son guías para elegir las mejoras prácticas a aplicar en un proyecto. El número de fases, las prácticas, técnicas, herramientas, artefactos, son solo algunos de los elementos que hacen que una metodología se diferencia de otra (pág. 112).

Antes de comenzar un proyecto se debe tomar en cuenta un punto muy importante: la planificación; ello involucra alcance, factibilidad, presupuesto entre otros aspectos y documentos. Entonces surgen interrogantes tales como: qué realizar en primer lugar, cómo equilibrar el trabajo, organizar mi equipo y alcanzar el éxito, qué debo presentar, entre otras.

Para hacer frente a todas estas adversidades e inconvenientes se emplean las metodologías, que guiarán y darán recomendaciones y mejoras prácticas, orientando al equipo de desarrollo de software en la gestión y producción de software de calidad. (Coronel, 2011, pág. 23)

12

Metodologías tradicionales.

Las metodologías tradicionales se fundamentan en llevar una planeación rigurosa (calendario) y secuencial en todo su proceso. Al iniciar un proyecto, en esta metodología se realiza un estricto proceso de recopilación de requerimientos, con la finalidad de asegurar calidad en el desarrollo. Es frecuentemente usado en proyecto de grandes magnitudes con amplios plazos de planeación, sea estructurado y donde los requerimientos no cambien y el flujo de trabajo sea lineal (sin posibilidad de regresar a etapas previas) (Navarro, Fernández, & Morales, 2013, pág. 31) 3.1.2.1.1. Cascada.

La metodología tradicional o también denominada “Cascada” son generalmente consideradas como un enfoque o forma “tradicional” de dirigir un proyecto de desarrollo de software, y por muchas décadas fue la opción más usada para ello. Muchos problemas son comunes aquí, como por ejemplo: la recopilación y documentación por anticipado de los requerimientos (paso obligatorio), la inflexibilidad de los mismos, y la insatisfacción del cliente al no lograr capturar (y desarrollar) lo que realmente éste quería. (Murray, 2016, págs. 31-33)

Figura 2. Flujo de proceso "Cascada" Fuente: Adaptado de Murray, A. (2016).

The Complete Software Project Manager: Mastering Technology from Planning to Launch and Beyond. Hoboken: John Wiley & Sons Inc.

13

3.1.2.1.2. Rup. La metodología denominada Proceso Unificado de Desarrollo o Rational Unified Process (RUP) por sus siglas en inglés, fue desarrollada por los creadores de UML en 1998.

Desde un principio se creó para ser empleada junto con el lenguaje de modelado UML. El objetivo final que persigue esta metodología es desarrollar software de calidad que cumpla con la planificación y presupuestos establecidos. Emplea casos de usos para administrar y seguir el flujo de los procesos, los cuales giran en torno a cinco etapas (requerimientos, análisis, diseño, implementación, pruebas) siendo incremental e iterativo (Brito, Sosa, & Héctor, 2015, pág. 12) 3.1.2.1.3. Msf. La metodología MSF o Microsoft Software Solutions brinda un enfoque personalizable en lo que concierne a la entrega de un producto de software, de forma rápida, exitosa, ahorrando recursos y enfocados en soluciones de calidad. El modelo de proceso (o también denominado modelo de gobernanza) es un modelo centrado en optimizar el proceso de entrega y en el uso eficiente y eficaz de recursos. Por otro lado, es un modelo iterativo que posee cinco etapas o pistas de ejecución que son: Visión (Prever), Planeación, Desarrollo (Compilar), Estabilización y Despliegue (Implementar). (Microsoft Corporation, 2017)

Figura 3. Modelo de gobernanza MSF. Fuente: Adaptado de Microsoft Corporation. (2017).

Descripción general de Microsoft Solutions Framework (MSF).

Obtenido de https://msdn.microsoft.com/eses/library/jj161047(v=vs.120).aspx

14

Metodologías ágiles.

No se puede hablar de metodologías ágiles sin antes dar una reseña acerca del Manifiesto Ágil (Agile Manifesto). En 2001, un grupo de 17 profesionales desarrolladores de software se reúnen en Utah para compartir ideas y diversos enfoques respecto al desarrollo de software que a fines de 1990 comenzaban a cobrar importancia. Estas metodologías ya combinaban prácticas antiguas como nuevas, algunas como la colaboración cercana con el cliente, entregas frecuentes, auto-organización del equipo entre otras. Es conocido que los profesionales no consensaron en muchos aspectos, pero sí estuvieron de acuerdo en 4 valores principales y 12 principios. Así nació el Manifiesto para el Desarrollo de Software Ágil (Agile Alliance, 2017).

Los principios o valores en que se basa el Manifiesto Ágil son: 

El producto de software es la parte esencial en el proceso de desarrollo.



El comportamiento humano e interacciones son esenciales para el éxito.



Un enfoque incremental, entregas frecuentes y colaboración con el cliente.



Reacción rápida frente a los cambios. (Fuggetta & Di Nitto, 2014, pág. 3)

Las metodologías ágiles se han ido posicionando de buena manera e incluso se aplican en varios campos muy distintos al mundo que las concibió que fue el desarrollo de software.

Cuando se emplea este nuevo enfoque todo se transforma, dado que propone un cambio de paradigma, pasar de lo tradicional a lo ágil; partir de un plazo y presupuesto determinado e ir entregando incrementos funcionales del producto al cliente en contraposición a la rigidez de los requisitos y planificación rigurosa del proyecto. (Álvarez, De las Heras del Dedo, & Lasa, 2012, págs. 24-32) Los métodos ágiles se basan en la filosofía Agile que se propone en el Manifiesto Ágil cumpliendo con sus principios y valores, además, son muy flexibles en cuanto a la forma en cómo se aplican dado que sus prácticas o reglas deberían cumplirse siempre, pero facilitará que se apliquen las que sean realmente útiles y que se creen nuevas si fuese necesario (Álvarez et al., pág. 33). Son muy útiles en proyectos donde los requerimientos son variables o no son estables dado que proveen una respuesta rápida y efectiva al cambio, incluso adaptándose al mismo, a su vez que la entrega del producto se simplifica y los clientes quedan más satisfechos.

(Brito et al., 2015, pág. 30)

15

3.1.2.2.1. Programación extrema (XP).

Es una metodología de desarrollo de software creada por Kent Beck en 1996, quien tres años después publica el libro Extreme Programming Explained en donde se explica de forma detallada la metodología XP. Es una metodología flexible que combina de forma ordenada valores, principios y buenas prácticas en el desarrollo de software de calidad, siendo adecuada para equipos pequeños o medianos. El nombre de “Programación Extrema” es debido a que la colección de principios y prácticas que posee son puestas a un nivel “extremo” con la finalidad de asegurar la satisfacción del cliente y la alta calidad del software. (Anwer, Aftab, Muhammad, & Waheed, 2017, pág. 1) Esta metodología presta un especial énfasis al trabajo en equipo y el resultado que se obtenga es responsabilidad del equipo de trabajo, todo ello se conjuga en tres procesos de equipo que son: propiedad colectiva del código, estandarización colectiva del código y la integración continua. (Wood, Michaelides, & Thomson, 2013, pág. 662). Además, es una metodología que impulsa el aprendizaje de los desarrolladores, fortalece la comunicación y retroalimentación entre los participantes, promueve un desarrollo simple y proporciona un buen ambiente de trabajo (Brito et al., 2015, pág. 15).

XP provee una buena y rápida respuesta al cambio, trabaja con grupos de 2 a 12 integrantes con ciclos de desarrollo cortos que generalmente van de 1 a 3 semanas (iterations), pruebas continuas y refactorización (Flora & Chande, 2014, pág. 3627). La filosofía de esta metodología, de acuerdo con Rosado, Quintero, & Meneses (2012) se basa en cuatro prácticas principales que son: 

Entregas pequeñas del sistema



Semana de 40 horas laborales



Cliente forma parte activa del equipo



Programación en parejas (pág. 25)

3.1.2.2.1.1. Valores xp.

Para lograr un desarrollo ágil efectivo, XP emplea cuatro valores o principios que rigen en sus procesos. Estos valores de acuerdo con Flora & Chande (2014) son los siguientes:

16



Comunicación: es un factor importante dado que muchos proyectos fracasan por una mala comunicación. Con este valor se fomenta el trabajo en equipo, comunicación oral, reuniones breves, equipos de desarrollo en el mismo lugar, desarrollo en parejas, reuniones breves entre otros.



Simplicidad: conlleva un desarrollo simple del producto y que este cumpla con las necesidades del negocio y las expectativas del cliente. Ello implica escribir código fácil de entender y mantener, desarrollar software sencillo cumpliendo con lo que debe hacer en el ahora y no en el mañana.



Retroalimentación: es muy importante dado que se valoran las observaciones o comentarios que tanto el cliente como los participantes del proyecto aportan.

Ello supone que se trabaje con iteraciones y entregas incrementales frecuentes, pruebas unitarias y pruebas de funcionalidad.



Coraje: significa estar preparados para tomar difíciles decisiones y con ello brindar apoyo a otras prácticas y principios. Además, se consigue hacer bien las cosas para alcanzar el éxito (págs. 3627-3628)

3.1.2.2.1.2. Roles y responsabilidades.

Los roles que se desempeñan en XP y sus respectivas responsabilidades, como se detalla en Flora & Chande (2014) son los siguientes: 

XP Coach: guía el equipo a seguir el proceso XP



XP Customer: el cliente que describe las historias de usuario y las prioriza



XP Administrator: prepara el entorno del programador



XP Programmer: escribe el código y los tests



XP Tracker: rastrea las iteraciones y el progreso de las mismas.



XP Tester: ayuda al cliente a escribir y a ejecutar pruebas de funcionalidad.



XP Consultant: miembro externo que ayuda al equipo a resolver problemas (pág. 3628).

17

3.1.2.2.1.3. Proceso xp.

La metodología XP es un método ágil que hace uso de iteraciones en su ciclo o proceso y las entregas que se realizan se dan de forma incremental. De acuerdo a Pressman (2010), el proceso XP se realiza en torno a cuatro actividades estructurales, cada una con actividades bien definidas y con sus respectivos artefactos. Estas actividades son: Planeación, Diseño, Codificación y Pruebas (pág. 62).

Figura 4. Flujo del Proceso XP. Fuente: Adaptado de Pressman, R. (2010).

Ingeniería del software: Un enfoque práctico. México: Mc GrawHill.

3.1.2.2.2. Scrum.

Scrum ya se venía practicando desde antes de que el Manifiesto Ágil sea anunciado.

Fue introducido por Ken Schwaber en 1995, más tarde fue incluida como metodología ágil dado que poseía los mismos principios y prácticas que se usan en el desarrollo ágil (Iqbal & Javed, 2014, pág. 296). Scrum provee un marco de trabajo para la gestión del proyecto donde estos posean requerimientos cambiantes, y al ser aplicado en el desarrollo de software, emplea los principios de desarrollo iterativo e incremental. (Brito et al., 2015, pág. 14) Desde un principio, Ken Schwaber y Jeff Sutherland desarrollaron Scrum para la gestión y desarrollo del producto y se ha difundido ampliamente para ser aplicada en varios campos. Scrum no es un método o proceso absoluto, sino un marco de trabajo en donde se aplican varias técnicas y procesos que permiten a las personas afrontar problemas complejos que requieran adaptabilidad, con la finalidad de desarrollar y entregar un producto con un alto valor de negocio y mejorarlo continuamente (Schwaber & Sutherland, 2017, pág. 3)

18

Al centrarse en la administración iterativa del desarrollo, no describe técnicas o procedimientos propios de la ingeniería de software ágil (como la forma o prácticas de programación entre otros). Es por esta razón que se puede tomar a Scrum como la base y se lo puede combinar con cualquier otro método ágil, siendo XP el más habitual, y de esta manera, complementar este aspecto o enfoque técnico (Sommerville, 2011, pág. 72).

3.1.2.2.2.1. Pilares y valores scrum.

Scrum se basa en la ideología empírica, es decir, de la experiencia y conocimientos adquiridos al tomar decisiones. Al ser iterativo e incremental se controla la predictibilidad y los riesgos. Son tres los pilares fundamentales que abarcan Scrum, y son los siguientes: 

Transparencia: todos los aspectos referidos a los procesos deben ser visibles para los responsables, estos aspectos deben ser manejados bajo un estándar “común” de entendimiento.



Inspección: los usuarios de Scrum inspeccionan los artefactos y el progreso determinados por un objetivo con el fin de detectar posibles variaciones. Estas inspecciones no deben interferir con el trabajo.



Adaptación: si varios aspectos de un proceso se desvía de lo aceptable, el proceso debe ajustarse. Este ajuste se realiza lo antes posible para así evitar desviaciones mayores (Schwaber & Sutherland, 2017, págs. 4-5).

De acuerdo con Schwaber & Sutherland (2017) los valores Scrum son los siguientes: 

Compromiso: de forma individual a alcanzar las metas del equipo



Coraje: para afrontar problemas difíciles y hacer bien las cosas



Enfoque: en el sprint, el trabajo y las metas del equipo



Apertura: con los miembros del equipo y a los desafíos del trabajo



Respeto: de forma mutua para ser personas independientes y capaces (pág. 5).

19

3.1.2.2.2.2. Eventos de scrum.

Se producen en Scrum de forma predefinida para evitar realizar reuniones innecesarias, todos los eventos tiene un tiempo de vida máxima (time-boxes). Todos ellos giran en torno al Sprint y como tal éste último tiene una duración fija. Los eventos sirven de oportunidad para cumplir y/o realizar en primer lugar, la inspección y adaptación de algún aspecto, y todo ello deriva en el cumplimiento final de la transparencia (Schwaber & Sutherland, 2017, págs. 5-9).

Los eventos que se desarrollan dentro del Sprint son los siguientes: 

Sprint: parte fundamental de Scrum, puede durar un mes o menos y culmina entregando un incremento del producto final totalmente terminado. Un Sprint inicia inmediatamente cuando finaliza uno previo. En el desarrollo del Sprint no se pueden realizar cambios que afecten el objetivo del Sprint (Sprint Goal), no se disminuye la calidad y no se renegocia el alcance. o Sprint Planning: planificación del trabajo a realizar en el sprint. El Equipo Scrum completo lo realiza y la planificación puede durar máximo 8 horas para un Sprint normal. o Daily Scrum: se lleva a cabo cada día con una duración de máximo 15 minutos. El equipo de desarrollo lo realiza planificando lo que se realizará en las próximas 24 horas y de este modo rastrear el progreso. o Sprint Review: es una reunión informal donde se realiza una revisión del sprint cuando éste finaliza, con la finalidad de analizar el incremento y si es necesario, adaptar la lista de productos. o Sprint Retrospective: sirve a manera de autoevaluación que lleva a cabo el Equipo Scrum y de esta manera realizar mejoras que serán implementadas en el siguiente Sprint. (Schwaber & Sutherland, 2017, págs. 9-14)

3.1.2.2.2.3. Roles de scrum.

Los roles de Scrum tienen que entenderse como “responsabilidades a cargo” en el proceso mas no como una jerarquía dentro de la organización. Cada rol se encuentra bien definido y diferenciado. El único rol que se subdivide es el del “Equipo Scrum” dado que este

20

abarca al Product Owner, Scrum Master y Equipo de desarrollo (Álvarez et al., 2012, págs. 4064). Los roles se describen en la siguiente figura:

Figura 5. Roles de Scrum. Fuente: Adaptado de: Álvarez, A., De las Heras del Dedo, R., & Lasa, C. (2012). Métodos Ágiles y Scrum. Madrid: Anaya.

3.1.2.2.2.4. Proceso scrum.

El proceso se desarrolla en torno a los sprints. Comienza con la especificación del Product Backlog (lista de productos) en el Sprint 0. Después se desarrollan los siguientes Sprints, cada uno empieza con el Sprint Plannig y después se crea el Sprint Backlog (lista de trabajos que se realizaran en el sprint). En el Sprint se realizan los Daily Meeting donde se revisan los avances y el trabajo futuro. El final del Sprint llega con el Sprint Review donde se lleva a cabo el Review Meeting o inspección de resultados. Por último, con el Sprint Retrospective se analizan puntos positivos y negativos (Álvarez et al., 2012, págs. 59-60).

Figura 6. Proceso Scrum. Fuente: Adaptado de Levy, R., Short, M., & Measey, P. (2015). Agile foundations: principles, practices and frameworks. Swindon: BSC.

21

Tabla comparativa entre metodologías de desarrollo tradicionales y ágiles.

Previamente en la sección 3.1.2.1 y 3.1.2.2 se especificó de manera general las definiciones y características que poseen las metodologías en este caso las tradicionales y ágiles. A continuación en el presente apartado se abordara la comparativa entre las metodologías de desarrolla anteriormente mencionadas.

Es importante realizar una comparativa que esté orientada a la dirección de proyectos, tomando cuatro puntos clave, los cuales son: -

Gestión de la incertidumbre del proyecto: Se aborda la manera en la que se maneja la incertidumbre del producto del proyecto y de los cambios que puede solicitar el cliente durante la gestión del proyecto.

-

Gestión del cambio del proyecto: Se trata la forma en la que las metodologías tradicionales y agiles tienen en cuenta los cambios que puede llegar a tener el proyecto.

-

Gestión de los equipos del proyecto: Aborda la manera en la que se manejan los equipos tanto en las metodologías tradicionales como en las ágiles.

-

Procesos de dirección de proyectos: Trata la forma en la que se controla y gestiona la dirección que va a tomar el proyecto.

3.1.2.3.1. Gestión de la incertidumbre del proyecto.

En las metodologías ágiles, a diferencia de las tradicionales, en lugar de contratos estrictos se procura mantener una relación muy cercana con el cliente del proyecto, incluso hay ocasiones en las que se llega a contratos de alcance variable, lo que nos convierte en un “proveedor” para nuestro cliente, con la finalidad de poder darle un valor agregado y poder manejar de mejor manera los posibles errores que se presenten a futuro.

3.1.2.3.2. Gestión del cambio del proyecto.

En métodos tradicionales se piensa que el proyecto está bien definido desde el inicio hasta el final, en teoría el proyecto no debería presentar muchos cambios, y en caso de haberlos no se hace una correcta retroalimentación con el cliente, esto puede acarrear un desajuste importante en el desarrollo del proyecto, por el contrario en los métodos ágiles los cambios son algo normal durante el desarrollo del proyecto, es más, se los consideran necesarios.

22

3.1.2.3.3. Gestión de los equipos del proyecto.

Dentro de las metodologías ágiles se toma al cliente del proyecto como parte del equipo de desarrollo, tomándolo como una persona con la que se interactúan continuamente, por otra parte las metodologías tradicionales el cliente delega todo el trabajo al equipo de desarrollo.

En las metodologías tradicionales se fomenta la competencia individual, generando individualismo dentro del equipo, mientras que las metodologías ágiles su filosofía es el trabajo en equipo para conseguir un beneficio común.

3.1.2.3.4. Procesos de dirección de proyectos.

En las metodologías tradicionales, el principal objetivo está orientado al proceso, establecer parámetros que, independientemente, de donde se apliquen, puedan funcionar.

Mientras que en las metodologías ágiles, lo que se determinar es un marco de actuación que sea adaptativo, dependiendo del equipo o del contexto en el que se vaya a mover o desenvolver.

En la siguiente tabla comparativa se procede a realizar un análisis de las diferentes ventajas y desventajas que poseen las metodologías de desarrollo de software anteriormente tratadas, se procedió a tomar como referencias solo las principales cualidades que tienen y de acuerdo a ellas se llegó a la siguiente tabla: Tabla 2 Comparación entre Metodología Tradicional y Ágil Metodologías tradicionales

Metodologías ágiles

Contratos estrictos.

Contratos de alcance variable.

Esconde el error.

Detecta el error y trata de resolverlo lo más pronto posible.

Se resiste a cambios.

El cambio forma parte del proceso.

No existe retroalimentación antes de los problemas.

Se desarrolla en base a las necesidades.

El cliente delega su responsabilidad.

El cliente forma parte del equipo.

Competición: beneficio individual.

Trabajo en equipo.

Orientado al proceso (funciona bien en cualquier equipo).

Orientado a las personas.

Fuente: Adaptado de Pressman, R. (2010). Ingeniería del software: Un enfoque práctico. México: Mc GrawHill

23

Conclusión De acuerdo a la tabla presentada anteriormente y las necesidades del proyecto, es más factible hacer uso de una metodología de desarrollo de software ágil, uno de los motivos de esta decisión es el tiempo con el que se contó para el desarrollo del proyecto, también se tomó en cuenta el número de miembros que formaban el equipo de desarrollo, entre otras más.

Tabla comparativa entre metodologías ágiles.

En la siguiente tabla se establecen los aspectos que están más relacionados con el proyecto y se los comparó en base al cumplimiento de las diferentes metodologías de desarrollo de software, las seleccionadas para su comparación son Extreme Programming (XP) y Scrum, ya que se encuentran entre las metodologías agiles más usadas por diferentes empresas y grupos de desarrollo.

Se determina comparar las dos metodologías antes mencionadas luego de realizar un amplio análisis y recolección de información que avale dicha comparativa. A continuación se expondrá tres revisiones bibliográficas, desde la más antigua hasta la más reciente, tratando de describir los aspectos más relevantes de dichas investigaciones, con la finalidad de no cansar al lector con amplia teoría y que la presente investigación no se salga de su cauce.

1. De acuerdo con el artículo titulado Empirical study of agile software development methodologies: A comparative analysis presentado en 2015 por Matharu, Mishra, Singh, y Upadhyay, en donde se recaba informacion acerca de tres métodos ágiles (Scrum, XP y Kanban) y ademas también se hace referencia a

estudios y encuentas realizadas por empresas y grupos

encuestadores, evidenciando que en Europa, un 27% respondieron a favor de Scrum y un 54% a favor de XP. Mientras que The French Scrum User Group revela un 86% de aceptación de Scrum y ademas un 52% alegaron usar XP. 2. Otra investigacion, en este caso llevada a cabo por la empresa VersioOne que es lider en software y servicios ágiles, por medio de The 11th annual State of Agile Survey, que es una encuesta llevada a cabo desde Julio a Diciembre de 2016, expone un 58% de aceptacion para Scrum, un 10% para una variacion de XP (un hibrido) y como tal un 1% a XP.

24

Figura 7. Gráfica del uso de las Metodologías Ágiles. Fuente: Adaptado de VersionOne. (2017). The 11th Annual State of Agile Report. Obtenido de https://explore.versionone.com/state-of-agile/versionone-11th-annualstate-of-agile-report-2

3. Para finalizar, en una reciente investigación publicada en Marzo de 2017 titulada Agile Software Development Methodologies: Survey of Surveys que fue llevada a cabo por Al-Zewairi, Biltawi, Etaiwi, & Shaout, donde se realiza una meticulosa, amplia y detallada revision bibliográfica a las encuestas (documentadas) realizadas a los diferentes métodos ágiles desde el año 2000 hasta el 2015 aplicando la metodologia de investigacion CR (Compara y Revisa). La investigacion se divide en cuatro secciones y en si es muy vasta, pero lo importante a descatar aquí son las siguientes cifras: un 57% revela que Scrum es la metodologia más usada, un 27% XP junto a Scrum y un 5% XP. Después de realizar la justificación anterior, se procede a explicar la forma de comparación entre XP y Scrum. Se compara entre los diferentes valores de la metodología de desarrollo y de los aspectos que tiene el proyecto, los aspectos a tratar están relacionados tanto con el uso que se le da a la metodología, su capacidad de agilidad, y por último la aplicabilidad que tiene la metodología con respecto al proyecto a desarrollar, si tanto la metodología como el proyecto concuerdan se dará el valor de 1 caso contrario será 0, luego se hará una sumatoria de puntos para llegar a una selección adecuada de la metodología más aplicable al presente proyecto.

25 Tabla 3 Comparativa de Metodologías (XP y Scrum) Criterios

Características XP

USO.

CAPACIDAD DE AGILIDAD.

APLICABILIDAD (AMBIENTE).

Puntuación Scrum

Cumplimiento de los requerimientos.

1

1

Se respeta la calidad ante todo.

0

0

Se respeta la fecha de entrega.

0

1

Sabe adaptar los procesos antes de suspenderlos por incidentes.

1

0

Satisfacción total del usuario-cliente.

1

1

Se centra en los usuarios finales.

1

1

Existe colaboración por parte de todo el equipo.

1

1

Integración de cambios.

1

1

Iteraciones cortas.

1

1

Los requisitos funcionales pueden cambiar.

1

1

Los requisitos no funcionales pueden cambiar.

0

0

Los recursos a usar pueden cambiar.

1

0

Tamaño del proyecto (Grande, Mediano, Pequeño).

1

1

Complejidad del proyecto (Baja, Alta).

1

0

Número de miembros que forman el equipo (Pequeño, Medianos, Grande).

1

1

Grado de iteraciones con el cliente (Baja, Alta).

0

0

Riesgos del proyecto (Bajo, Alto).

1

0

13

10

Totales Fuente: Datos obtenidos de la investigación de campo

Conclusión: Se estableció para el desarrollo del sistema la metodología de desarrollo programación extrema (XP), basándose en la comparativa realizada anteriormente entre las diferentes metodologías y su cumplimiento con los diversos aspectos del proyecto como son el uso que se le va a dar, la capacidad de agilidad con la que cuenta al momento de presentarse cambios en los requerimientos, y por último su aplicabilidad en el ambiente que se desenvolverá.

26

Aplicaciones web 3.2.1. Arquitectura de aplicaciones web.

Arquitectura cliente/servidor.

Es un modelo de aplicación que se caracteriza por emplear la idea de servicio. Las tareas se dividen en dos lados; por una parte, el cliente que solicita recursos y por otra el servidor que es quien proporciona los recursos o servicios. El funcionamiento es sencillo, el cliente generalmente inicia el intercambio de información al servidor, y éste responde a la solicitud del cliente enviando flujos de datos (López, y otros, 2014, pág. 14) La separación que se lleva a cabo en esta arquitectura no necesariamente tiene que ser física (una máquina dedicada solo al servidor) sino que se puede realizar de manera lógica. Un cliente puede conectarse a varios servidores, y un servidor puede procesar peticiones de varios clientes. Entre las ventajas que posee esta arquitectura esta la escalabilidad, centralización de la información, fácil mantenimiento y un amplio abanico de tecnologías diseñadas para esta arquitectura (Ferrer, 2014, págs. 21-22).

Figura 8. Arquitectura Cliente/Servidor. Fuente: Adaptado de López, M., Vara, J., Verde, J., Sánchez, D., Jiménez, J., & de Castro, V. (2014). Desarrollo Web en Entorno Servidor. Madrid: Ra-Ma.

Arquitectura de tres niveles.

La arquitectura a tres niveles es una variante de la Cliente/Servidor. En esta arquitectura se tiene una capa intermedia, es decir una capa dedicada para el servidor de aplicaciones o software intermedio. A continuación se describe cada una de las capas:

27



Cliente: el que solicita los recursos.



Servidor de aplicaciones: proporciona los recursos necesarios que otro servidor le provee. Sirve de nexo entre el cliente y el servidor de datos.



Servidor de datos: proporciona los datos a la capa intermedia que es la que los solicitó. (Ferrer, 2014, págs. 23-24)

Figura 9. Arquitectura en tres niveles. Fuente: Adaptado de Ferrer, J. (2014).

Implantación de Aplicaciones Web. Madrid: Ra-Ma.

Modelo vista controlador (mvc).

El patrón Modelo Vista Controlador o Model-View-Controller (MVC), por sus siglas en inglés, se desarrolló en el año 1979 y se presentó como una característica del lenguaje Smalltalk de ese entonces. Se creó con la finalidad de reducir los esfuerzos en el desarrollo (programación) e implementación de sistemas. Se reconoce tres componentes que conforman el programa y a su vez se las considera como entidades claramente separadas; estos componentes son el Modelo, la Vista y el Controlador (Fernández & Díaz, 2012, pág. 48).

A continuación se explica cada uno de los componentes: 

Modelo: parte de la aplicación donde se coloca la lógica de negocio, es decir, que se representa la información con que va a funcionar la aplicación

28



Vista: es la parte visual o interfaz de usuario con la cual este último interactuará directamente. Si se trata de aplicaciones web, el conjunto de páginas web la confirmas, o a su vez se construyen según el modelo de datos especificado.



Controlador: es el encargado de gestionar la interacción con el usuario, es decir que selecciona la vista adecuada para representar o mostrar la información requerida por el modelo. (López, y otros, 2014, pág. 96)

Figura 10. Patrón Modelo Vista Controlador. Fuente: Adaptado de López, M., Vara, J., Verde, J., Sánchez, D., Jiménez, J., & de Castro, V. (2014). Desarrollo Web en Entorno Servidor. Madrid: Ra-Ma.

3.2.2. Tipos de aplicaciones web.

Aplicaciones estáticas.

Una página web estática se caracteriza solo por mostrar información al usuario final que es el que navega por la web. El usuario solamente puede leer dicha información pero no interactúa con la página que la provee. Este tipo de aplicaciones se desarrollan a base de enlaces (links) y que se conectan o re-direccionan a otras páginas web. Al no interactuar con los usuarios, no puede distinguir uno de otro (Zofío, 2013, pág. 7).

Aplicaciones web dinámicas.

Este tipo de aplicaciones se diferencia de las estáticas por promover la interacción con el usuario final, es decir, permite crear un canal de comunicación entre la aplicación y el usuario final. Las web dinámicas si se consideran aplicaciones web dado que el acceso a los datos les es permitido a los usuarios finales de forma interactiva. Ejemplos de este tipo de aplicaciones son los correos electrónicos, envío de formularios, entre otros (Zofío, 2013, pág. 7).

29

Herramientas de desarrollo web.

3.3.1. Eclipse JEE. Eclipse es una plataforma de desarrollo, fue creada con la idea de convertirse en una plataforma de integración de herramientas de desarrollo genérica. El trabajo con el que cuenta esta herramienta de desarrollo está basado en las perspectivas, que no es otra cosa que una preconfiguración de ventanas y editores de texto, relacionados entre sí, que nos proporciona un entorno de trabajo de forma óptima y adecuada capaz de adaptarse a las necesidades del usuario, también otra de sus cualidades es ser multiplataforma y de código abierto. (Eclipse, 2017).

3.3.2. Spring framework.

Spring permite desarrollar aplicaciones de manera más sencilla, rápida y funcional, saltándose tareas repetitivas y ahorrándose líneas de código, creando así aplicaciones mucho más ligeras, spring utiliza la inyección de dependencias o el uso de objetos convencionales como objetos de negocio. Eso posibilitó que de ser un framework inicialmente diseñado para la capa de negocio pasara a ser un completo apilamiento de tecnologías para todas las capas de la aplicación. (Spring, 2017) 3.3.3. Java Hibernate.

Hibernate es una herramienta de Mapeo objeto-relacional (ORM) para la plataforma Java que facilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicación, mediante archivos declarativos (XML), en pocas palabras Hibernate es un framework que agiliza la relación entre la aplicación y la base de datos.

Además cabe mencionar que Hibernate es software libre, distribuido bajo los términos de la licencia GNU LGPL. (Hibernate, 2017) 3.3.4. DB2.

Sistema de gestión de base de datos relacionales de IBM multiplataforma, permite el manejo de objetos grandes, la declaración de datos y funciones por parte del usuario, el chequeo de integridad referencial, SQL recursivo, soporte multimedia: video, texto, imágenes, audio.

Además posee un monitor grafico de performance el cual posibilita observar el tiempo de ejecución de una sentencia SQL y corregir detalles para aumentar el rendimiento. (IBM, 2017).

30

Gestión Administrativa 3.4.1. Administración.

El termino administración ha ido variando conforme ha ido pasando el tiempo. Ha evolucionado y su significancia se ha ido refinando, pero su concepción principal no. La administración (desde un contexto tradicional) poseía actividades de gestión, planeación u organización para una correcta designación de recursos. Posterior, en la Edad Media con la creación de la Hacienda, este término se refería a la preservación y correcto uso de los recursos de esta última. Los términos gestión o administración se refieren a los mismo cuando se tratan de administrar o dirigir una institución y sus componentes. (Martínez, 2012, págs. 4-5) 3.4.2. Sistema de Gestión.

Comprende los procesos de gerencia o de dirección que se fundamentan en los hechos históricos, cultura, experiencia, y teoría de las organizaciones involucradas. Los sistemas de gestión definen métodos y objetivos para calcular el rendimiento que se ha obtenido con la asignación de recursos para la financiación, competitividad, producción, etc. Las formas de organización (o gestión) han evolucionado con el paso del tiempo; de formas empíricas con enfoques cerrados, hasta las formas más complejas de administración. (Martínez, 2012, pág.

11) 3.4.3. Proceso de Administración.

El proceso de administración se encuentra formado por fases en donde se aplican los conocimientos, métodos, técnicas para efectuar una correcta administración. Se evidencian dos fases en el proceso administrativo de cualquier empresa: la primera que es la fase estructural (también conocida como mecánica) que establece lo que se debe hacer, la otra fase denominada operacional o dinámica, que es la que pone en ejecución lo establecido en la fase anterior, es decir, se refiere a la operación de la empresa (Münch, 2014, págs. 24-25).

3.4.4. Calidad de servicio.

La calidad de un servicio es la capacidad que tiene éste para satisfacer las necesidades y las expectativas del cliente. Para poder proporcionar calidad, el proveedor deberá evaluar continuamente la forma en que se experimenta el servicio y lo que el cliente espera en el futuro.

(Janvan, 2015, pág. 55).

31

3.4.5. Inventario.

En las empresas tiene un papel muy importante los inventarios porque son indispensables en los procesos productivos de las mismas, en estos se reflejada parte de la inversión de la empresa. (García, 2014, pág. 274).

3.4.6. Administración de inventario.

La administración de inventarios es un conjunto de técnicas y procedimientos, que tienen como fin establecer y mantener cantidades adecuadas de bienes de cualquier tipo, de esta manera se minimizan costos y se contribuye a que la empresa cumpla con sus objetivos gracias a una mejor. (García, 2014, pág. 274).

3.4.7. Importancia de la administración de inventario.

La importancia de esto permite tener un eficaz control sobre los inventarios ya que es esencial para mejorar el servicio que se brinda a los clientes, además sin este control, no se puede producir el máximo de eficiencia, también el costo del mantenimiento de inventarios depende de la pericia con la que estos se controlen.

“Una estimación del costo del mantenimiento que oscila entre un diez y un veinte y cinco por ciento del valor de los inventarios de la empresa, también depende de las condiciones especiales que tienen las empresas”. (García, 2014, pág. 274) 3.4.8. Mantenimiento preventivo.

El mantenimiento preventivo resulta innovador y conveniente, tomando una visión tradicional y general, en la actualidad todavía sigue muy generalizada, con una idea orientada a tener a los mantenimientos como elementos apartados o aislados, y no como un componente que es parte de una totalidad con una actividad que realizar. (Rey, 2014, pág. 31) 3.4.9. Mantenimiento correctivo.

Para todos los mantenimientos correctivos que son aplicados es muy imprescindible definir un plan de actividades a seguir para corregir la falla que se presente, además de designar a un responsable que lleve a cabo el mantenimiento correctivo necesario para el equipo que lo necesite. (Rey, 2014, pág. 39)

32

METODOLOGÍA DE LA INVESTIGACIÓN Diseño / Tipo de investigación 4.1.1. Enfoque de Investigación.

Para la presente investigación se plantea emplear un enfoque mixto que permita dar solución a la problemática previamente desarrollada. El enfoque mixto se caracteriza por conjugar tanto el método cuantitativo y cualitativo en una investigación, es decir, se realiza la recolección, análisis e interpretación de varios tipos de datos, ya sean estos numéricos, textuales, verbales, etc. Este tipo de enfoque (mixto) provee un valor agregado al fenómeno en estudio dado que logra tener una percepción (perspectiva más detallada de la realidad del objeto de estudio (Hernández, Fernández, & Baptista, 2014, págs. 534-537).

Se hará uso del método cuantitativo para fundamentarse en los resultados obtenidos de la encuesta y posteriormente se usara el método cualitativo el cual nos permitirá analizar e interpretar los resultados obtenidos de las entrevistas.

4.1.2. Diseño de Investigación.

En la presente investigación se empleará el diseño de investigación no experimental.

La razón principal de su uso es porque no se ejercerá una influencia (o manipulación) sobre el objeto o fenómeno de estudio, únicamente se ha realizado la observación del mismo y su posterior análisis.

En un diseño de investigación no experimental se tiene más acceso a las variables de estudio como tal consiguiendo con ello más detalles sus comportamientos. Es aquella en donde no se manipulan intencionalmente las variables. Al no generarse ninguna situación (dado que estas ya están generadas) solamente se realiza la observación del fenómeno en su ambiente natural. No se puede controlar ni manipular las variables independientes ni sus efectos por el motivo de que estos ya sucedieron (Hernández, Fernández, & Baptista, 2014, págs. 152-163).

33

4.1.3. Tipo de Investigación.

Investigación descriptiva.

La investigación descriptiva es aquella en donde se detallan las características principales del objeto de estudio. Es el tipo de investigación que sirve de base para otros tipos de investigación, además es la más popular entre los investigadores. Se basa generalmente en las preguntas de investigación que ha realizado el investigador. Este tipo de investigación se apoya en la entrevista, encuesta, revisión documental y observación (Bernal, 2010, pág. 113).

Se ha empleado este tipo de investigación dado que ha permitido reconocer las causas fundamentales y las características que posee el fenómeno de estudio (el problema de investigación) que se dan lugar en la institución CNEL EP. Investigación aplicada.

La Investigación aplicada o empírica es aquella donde se pone en práctica o se emplean los conocimientos que se han adquirido. Al tiempo que se aplican dichos conocimientos, se pueden ir adquiriendo otros y el resultado de tal es una investigación rigurosa y sistemática. Es de este modo que en la presente investigación se han usado todos los conocimientos que se han obtenido en el proceso de instrucción profesional y que no solo se reflejan en el desarrollo de un sistema informático, sino que se lo crea para su implementación dentro de la institución una vez que se finalice la investigación, con el fin de agilizar el trabajo del personal dentro de la empresa.

Investigación de campo.

Se emplea este tipo de investigación dado que se asistió a la institución (en este caso CNEL EP) con la finalidad de recabar toda la información necesaria acerca de los procesos que realizaban las personas del Departamento de Computo con relación al registro de los dispositivos. Para ello se ha consultado con el Director del departamento que conoce el funcionamiento de los procesos que manejan.

34

Población / Universo 4.2.1. Población.

La población es el conjunto de entes (personas, animales o cosas) sobre los cuales se desea dar respuesta al problema de investigación (Borda, 2013, págs. 146-147). La población que se ha considerado en el presente documento son el personal de la Corporación Nacional de Electricidad (CNEL EP) Santo Domingo, que consta de 6 personas de las cuales se obtendrá información relevante para la presente investigación 4.2.2. Muestra.

En conformidad con el modelo convencional, la muestra es un subconjunto de la población o universo de estudio. La finalidad de realizar la muestra es para poder generalizar los resultados obtenidos en la investigación a la población de la cual se obtuvo. (Borda, 2013, pág. 147) De acuerdo al planteamiento del problema, donde se ha evidenciado que los principales beneficiados e involucrados en la presente investigación es el departamento de Cómputo en CNEL EP (corporación), por tal motivo se utilizó como muestra a las 6 personas que laboran dentro de dicho departamento como personal administrativo.

Técnicas/ Instrumentos para la recolección de datos Se define como técnica a la colección de procedimientos que permiten al investigador constituir una relación con el fenómeno o sujeto de investigación. De forma general se describen dos técnicas de investigación (enfoque cualitativo) que es la técnica documental y de campo (Borda, 2013, pág. 62). A continuación se especifican las técnicas e instrumentos que se han empleado en la presente investigación. 

Técnica de campo o Entrevista: sirve para obtener información de forma verbal, es decir, por medio de un dialogo o conversación. La lleva a cabo el entrevistador a través de un esquema de preguntas. (Borda, 2013, pág. 62).

35

o Observación: obtención de información de forma visual al observar las situaciones (ambiente) en que se desenvuelve el sujeto o fenómeno a observar. (Borda, 2013, pág. 63). Por medio de esta técnica se ha podido comprobar cómo es el manejo de los procesos en CNEL EP respecto al registro y mantenimiento de dispositivos. 

Auto diligenciamiento: a manera de cuestionarios, se solicita al encuestado que resuelva uno o varios cuestionarios con la finalidad de evitar recolectar información errónea por miedo a la entrevista (Borda, 2013, pág. 164).



Instrumentos o Guía del entrevistador: empleado en la Entrevista. o Registros de observación: empleados en la Observación. o Cuestionarios: empleados en las Encuestas o Auto diligenciamiento.

Técnica de Análisis de Datos Para el procesamiento de los datos recolectados (en bruto) se ha realizado el correspondiente análisis e interpretación de los mismos. El análisis de datos cuantitativos (encuesta) se ha efectuado con apoyo de la computadora a través de un software específico que permita realizar la tabulación de las respuestas capturadas y posterior representación estadística para una mejor apreciación.

Las entrevistas que se han aplicado a las fuentes primarias (en este caso el personal del Departamento de Cómputo de CNEL EP) han servido para la obtención de datos, los cuales se sometieron al entendimiento e interpretación, destacando aspectos relevantes respecto al desarrollo del sistema informático. Por último, un análisis minucioso de la observación que se ha realizado en relación a la forma de llevar los procesos la institución en cuestión.

36

Metodología de desarrollo de Software Después de realizar el análisis y la comparativa respectiva en cuanto a metodologías de desarrollo de software, para la presente investigación se ha aplicado la Metodología Programación Extrema o XP, la cual, por su característica de ágil, permite un desarrollo rápido, y adaptabilidad a cambios o reajustes que presente el cliente. Al controlar de forma eficiente los riesgos en cada una de sus etapas y promover (asegurar) la calidad en los incrementos o entregas que realiza, es la metodología más idónea a emplear por cuanto a flexibilidad, simplicidad de la solución y forma de trabajo.

4.5.1. Descripción de Roles y Responsabilidades de XP. De acuerdo a lo descrito en la sección 3.1.2.2.1 y considerando aspectos importantes como el número de integrantes (desarrolladores) que se posee, la definición de los roles y correspondientes responsabilidades se da de la siguiente manera: Sponsor o Institución vinculada: CNEL EP - Santo Domingo 

Ing. Paul Toapanta.: Customer (Cliente)



Mg. Rodolfo Córdova: Consultant (Consultor)



Guillermo Barcia: Programmer – Tester - Tracker



Nólvar Gómez: Programmer – Administrator - Coach

4.5.2. Fases de la Metodología XP. En los siguientes apartados se explica cada una de las etapas que posee XP, cuáles son sus características, artefactos y prácticas que hace uso. Se ha resumido y descrito lo más sencillo posible para brindar una idea general del proceso que realiza XP dado que el resultado de su aplicabilidad en el presente proyecto se reflejan en la sección cinco (Resultados) del presente documento. Cabe recalcar que al ser un método ágil iterativo, cada una de las etapas involucradas se repite en cada nueva iteración, excepto la Finalización.

37

Fase de planeación.

Es la primera fase del proceso XP. Empieza con el juego de planeación en donde los integrantes del equipo XP escuchan al cliente y recaban los requerimientos para la construcción del sistema. Estos requerimientos las escribe el cliente en las Historias de Usuario con un lenguaje informal y prioriza según la importancia en el negocio. Los miembros técnicos del equipo estiman y negocian la entrega de las historias de usuario. Además, se realiza el Plan de Entregas (que puede ir variando) y el Plan de Iteraciones para ir dando seguimiento a las historias y avances del proyecto.

Fase de diseño.

En esta fase lo primordial es la sencillez, es decir, hacer lo justo y necesario pero simple con el objetivo de que la historia de usuario pueda ser implementada. En esta fase se desarrollan pequeños prototipos del sistema. Las tarjetas CRC (Clase-Responsabilidad-Colaborador) se realizan en esta fase y sirven para tener una concepción orientada a objetos de la solución o del software, identificando cada una de las clases que se usarán y las responsabilidades (acciones) que tendrá a cargo dicha clase, a su vez los colaboradores que permitirá que la clase funcione adecuadamente.

Fase de codificación.

Una de las características principales de esta etapa es la programación en parejas, con ello se consigue mejores soluciones y calidad en el desarrollo (constante revisión del código mientras se lo crea). Antes de codificar se describen pruebas unitarias (de acuerdo al incremento a entregar), luego de ello el desarrollador implementa lo necesario para pasar la prueba. No es necesario documentarlas e incluso estas se pueden automatizar con la ayuda de herramientas de software.

Existe retroalimentación continua entre los desarrolladores (dado que trabajan en pareja) y aunque lo ideal es que el rol se desempeñe por igual, este puede variar, es decir, una persona puede centrarse en el código y otra en los estándares y validación del mismo. Conforme se termina de codificar, el trabajo resultante se integra y se une al resto. Esta práctica se denomina integración continua y logra la compatibilidad de la solución.

38

Fase de pruebas.

La fase de pruebas en XP se caracteriza por ser de dos tipos: pruebas unitarias y pruebas de aceptación. Como se explicó anteriormente, las pruebas unitarias sirven para que el desarrollador haga lo estrictamente necesario para pasar la prueba; nada más y nada menos.

Con ello se pretende evitar cometer errores. Por otro lado, las pruebas de aceptación las realiza netamente el cliente, y es este último el que pone a prueba todas las características y funcionalidades del sistema.

Muerte.

La muerte del proceso XP se da cuando ya no existen más historias de usuario por implementar o cuando el cliente ya no especifica más de estas. Es en ese momento cuando se da por finalizado el desarrollo del proyecto. La culminación exitosa de un proyecto sucede cuando el cliente está totalmente satisfecho con el trabajo realizado; y en el caso adverso, cuando el proyecto no es viable o no cuenta con la financiación pertinente.

39

RESULTADOS Análisis y Discusión de los resultados 5.1.1. Entrevista realizada al personal del centro de cómputo en CNEL EP. El resultado que se obtuvo mediante el levantamiento de la entrevista realizada a cada miembro del centro de cómputo de CNEL EP Santo Domingo fue lo siguiente, ver Anexo 1.

-

¿De acuerdo a su criterio que tan útil y sobre todo necesario considera la implementación de un sistema web para la gestión y mantenimiento de los bienes informáticos?

Interpretación: Se aprecia un gran interés por parte del personal que labora en el centro de cómputo, ya que les sería de gran ayuda contar con un software que les facilite la manera de llevar el registro y los mantenimientos que se les den a los equipos informáticos.

-

¿De qué manera se lleva el control de los registros y el mantenimiento de los bienes informáticos?

Interpretación: En el centro de cómputo cuentan con un sistema web que no dispone de todas las funciones que son llevadas a cabo al momento de ingresar un equipo al sistema, ni mucho menos que les alerte de las fechas exactas que se deben dar mantenimiento a los equipos informáticos.

-

¿Una estimación de equipos que ingresan a diario al centro de cómputo?

Interpretación: Se puedo apreciar que al centro de cómputo ingresan diariamente alrededor de 5 equipos que deben ser atendidos por diferentes motivos ya sea por registro del equipo o por mantenimiento correctivo o preventivo.

-

¿Una estimación del tiempo requerido para registrar un equipo informático?

Interpretación: Se pudo observar mediante la entrevista realizada que el registro de un equipo puede tardar entre unos 23 a 38 minutos, dependiendo de las circunstancias en las que se encuentren.

40

-

¿Una estimación del tiempo requerido para dar mantenimiento a un equipo informático?

Interpretación: Se apreció que un mantenimiento ya sea preventivo o correctivo tiene un tiempo estimado de 45 minutos hasta una hora y media de duración dependiendo el caso.

-

¿De qué manera se alerta o notifica al personal encargado que un equipo necesita mantenimiento ya sea preventivo o correctivo?

Interpretación: Se pudo observar que para los mantenimientos preventivos no existe ninguna forma de llevar un control, y para lo que es mantenimiento correctivo el mismo encargado del equipo se debía acercar al centro de cómputo y solicitar se lo ayudara con su inconveniente.

-

¿Problemas comunes al momento de realizar el registro y/o mantenimiento de un equipo informático?

Interpretación: Se observaron varios problemas con el registro de un equipo ya que muchos de ellos no contaban con sus respectivos códigos, o se sabía quién era su custodio, todo esto generaba desconcierto al momento de registrar un equipo.

Conclusión de la entrevista.

Los resultados obtenidos mostraron evidentemente la necesidad de mejorar y automatizar los procesos que se llevan a cabo al momento de registrar un equipo o de darle mantenimiento preventivo o correctivo; el desarrollo e implementación de un sistema web para gestionar de mejor manera todos los equipos que ingresen al centro de cómputo en el CNEL EP tiene como única finalidad dar solución a los problemas que se mencionaron anteriormente.

41

5.1.2. Entrevista realizada al jefe del centro de cómputo.

El resultado que se obtuvo mediante el levantamiento de información de la entrevista (Ver Anexo 2), realizada al jefe del centro de cómputo del CNEL EP el Ing. Paul Toapanta fue lo siguiente: -

¿Qué sistema operativo utiliza el servidor web?

Interpretación: Actualmente se cuenta con un servidor web con Windows, en el cual se puede alojar una aplicación web desarrollada en Java Enterprise Edition.

-

¿Qué gestor de base de datos se utiliza dentro de la empresa?

Interpretación: Por políticas de la empresa se debe utilizar como gestor de base de datos DB2 IBM.

-

¿Lenguaje de programación requerido para el desarrollo (back-end)?

Interpretación: Se requiere la utilización de java como política de desarrollo dentro de la empresa.

Conclusión de la entrevista

En la entrevista que se mantuvo con el jefe del centro de cómputo sirvió para establecer todos los requerimientos que debe tener el sistema, de igual manera se establecieron todas las herramientas con las que se deben desarrollar el mismo, por políticas de desarrollo de la empresa se pidió hacer uso de java como lenguaje de programación y db2 IBM como gestor de base de datos, además se establecieron todos los requerimientos que debe tener el software a desarrollar (Ver Anexo 4).

42

5.1.3. Encuesta realizada a todos los miembros que laboran en el departamento de cómputo en la Empresa CNEL EP. 1. ¿Cree usted que los procesos de control de registros y mantenimientos de los equipos informáticos se llevan de forma adecuada en la institución?

Tabla 4 Administración de los procesos de registro y control de mantenimiento de los dispositivos Opción

Frecuencia

Porcentaje

Si

0

0%

No

8

100 %

Total

8

100 %

Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP – Santo Domingo

9 8 7 6 5 4 3 2 1 0 Si

No

Figura 11. Administración de los procesos de registro y control de mantenimiento de los dispositivos. Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP – Santo Domingo

Análisis: A través de los resultados obtenidos en la encuesta aplicada, se puede apreciar que el 100 % de los encuestados consideran que no es correcta la forma en la que se llevaba el control de los registros y el mantenimiento de los bienes informáticos, y ello fue evidenciado con las observaciones realizadas por parte de los investigadores.

43

2. ¿Conoce usted el tiempo de vigencia de las garantías de los equipos informáticos de la institución?

Tabla 5 Gestión de la duración de garantías Opción

Frecuencia

Porcentaje

Si

0

0%

No

8

100 %

Total

8

100 %

Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP – Santo Domingo

9 8 7 6 5 4 3 2 1 0 Si

No

Figura 12. Gestión de la duración de las garantías. Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP – Santo Domingo

Análisis: de acuerdo con los resultados obtenidos de la encuesta aplicada, el total de los encuestados afirma no conocer de forma exacta el tiempo de vigencia de las garantías que posee un equipo informático en la institución, evidenciando con ello la falta de información que poseen las personas.

44

3. ¿Cree usted que existen dificultades al momento de registrar los equipos de la institución?

Tabla 6 Inconvenientes en la ejecución de los procesos de registro de equipos Opción

Frecuencia

Porcentaje

Si

8

100 %

No

0

0%

Total

8

100 %

Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP – Santo Domingo

9 8 7 6 5 4 3 2 1 0 Si

No

Figura 13. Inconvenientes en la ejecución de los procesos de registro de equipos. Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP – Santo Domingo

Análisis: de acuerdo con los datos obtenidos de la encuesta aplicada, se determina que el 100% de las personas encuestadas afirman tener algún tipo de inconveniente o dificultad al momento de registrar los equipos que posee la institución.

45

4. ¿Es adecuada la manera en que se lleva a cabo el control de los mantenimientos preventivos y correctivos de los equipos?

Tabla 7 Administración de los mantenimientos preventivos y correctivos de los equipos Opción

Frecuencia

Porcentaje

Si

0

0%

No

8

100 %

Total

8

100 %

Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP – Santo Domingo

9 8 7 6 5 4 3 2 1 0 Si

No

Figura 14. Administración de los mantenimientos preventivos y correctivos de los equipos.

Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP – Santo Domingo

Análisis: de acuerdo con los resultados obtenidos en la encuesta, se evidencia que el total de los encuestados (100%) manifiestan que el control tanto preventivo como correctivo de los equipos de la institución no se realiza de manera adecuada, lo cual deriva en un uso poco eficiente del tiempo.

46

5. ¿Considera usted que las aplicaciones web son de mucha utilidad y sobre todo necesarias para el manejo de inventario dentro de una empresa?

Tabla 8 Utilidad de las aplicaciones web en la administración de inventarios Opción

Frecuencia

Porcentaje

Si

8

100 %

No

0

0%

Total

8

100 %

Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP – Santo Domingo

9 8 7 6 5 4 3 2 1 0 Si

No

Figura 15. Utilidad de las aplicaciones web en la administración de inventarios. Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP – Santo Domingo

Análisis: según el resultado obtenido de la pregunta 5 de la encuesta, el 100% de las personas están de acuerdo en que el empleo de las aplicaciones web son de gran utilidad en lo que respecta al manejo de inventario (en este caso de equipos informáticos) de la empresa.

47

6. ¿Cree usted que con el desarrollo de una aplicación web que lleve el control de los registros y mantenimientos de equipos, sea beneficioso para la empresa al momento de realizar nuevas adquisiciones?

Tabla 9 Beneficios de la aplicación de sistemas web en la administración de equipos Opción

Frecuencia

Porcentaje

Si

8

100 %

No

0

0%

Total

8

100 %

Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP – Santo Domingo

9 8 7 6 5 4 3 2 1 0 Si

No

Figura 16. Beneficios de la aplicación de sistemas web en la administración de equipos. Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP Santo Domingo

Análisis: de acuerdo con los resultados obtenidos de la encuesta, el total de encuestados (100%) concuerdan en que el desarrollo de una aplicación web que lleve a cabo los procesos de registro y control de mantenimientos de los equipos beneficiará directamente a la empresa dado que dichos procesos se realizarán de una forma eficiente, mejorando con ello los tiempos empleados en dichas actividades

48

7. ¿Cree usted que se facilitará el proceso de registro y de mantenimiento de equipos con el desarrollo de aplicación web?

Tabla 10 Necesidad de agilizar los procesos de registro y mantenimiento de equipos Opción

Frecuencia

Porcentaje

Si

8

100 %

No

0

0%

Total

8

100 %

Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP – Santo Domingo

9 8 7 6 5 4 3 2 1 0 Si

No

Figura 17. Necesidad de agilizar los procesos de registro y mantenimiento de equipos. Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP Santo Domingo

Análisis: de acuerdo con los resultados obtenidos, se evidencia que el 100% de los encuestados afirman que los procesos de registro y mantenimiento de equipos se verán facilitados con el desarrollo de la aplicación web para que lleven a cabo dichos procesos.

49

8. ¿Está de acuerdo con la implementación de un sistema web que permita llevar un control adecuado de los registros y mantenimientos de la empresa?

Tabla 11 Aceptación de la implementación de un sistema web en la empresa Opción

Frecuencia

Porcentaje

Si

8

100 %

No

0

0%

Total

8

100 %

Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP – Santo Domingo

9 8 7 6 5 4 3 2 1 0 Si

No

Figura 18. Aceptación de la implementación de un sistema web en la empresa. Fuente: Encuesta aplicada al personal del Departamento de Cómputo CNEL EP Santo Domingo

Análisis: en concordancia con los resultados obtenidos por medio de la encuesta, se puede conocer que la totalidad de las personas (100%) están en común acuerdo con la implementación y puesta en marcha del software o aplicación web desarrollada para la empresa.

50

Resultados de la Aplicación de la Metodología XP 5.2.1. Fase de planeación.

Es en esta fase en donde se empieza con la recolección de requerimientos o funcionalidades que poseerá el sistema a través de pequeñas tarjetas o historias de usuario que el cliente describe. Éste último prioriza las historias de usuario de acuerdo a su valor en el negocio; el equipo de trabajo se reúne y evalúa el tiempo que tomará realizarlas, las estiman y se negocia la entrega de las mismas con el cliente. Los desarrolladores eligen el orden en cómo se irán implementando las historias de usuario. Luego de ello, se realiza el Plan de Entrega y el Plan de Iteraciones que guiarán el desarrollo del proyecto.

Historias de usuario.

Generalmente en métodos ágiles la forma de hacer la recolección de requerimientos es a través de Historias de Usuario. Esta forma de capturar requisitos es centrada en el usuario y viene a reemplazar al Software Requeriments Especification o SRS que es común en metodologías tradicionales. Tienen cierta similitud con los Casos de Uso pero no llegan a ser lo mismo. Las historias de usuario son escritas por el cliente en un lenguaje informal (no técnico) y en ellas se especifica las funcionalidades que debe poseer el sistema.

La principal diferencia entre una HU (Historia de Usuario) y un SRS es el nivel de detalle. En una HU no se escribe con mucho detalle lo que debe tener el sistema (como sucede en un SRS) sino solo el suficiente que permita a los programadores estimar el tiempo y empezar con el desarrollo. Las HU son la parte primordial en el proceso XP, dado que paralelo a ellas se escriben los criterios de aceptación. Además, en base a ellas se elabora el Plan de Entregas y el Plan de Iteración. El formato básico de escritura de una HU gira en torno a tres frases: 

Cómo: haciendo referencia al tipo de usuario



Quiero: en donde se especifica la característica o funcionalidad de la HU.



Para: la razón o el porqué de dicha funcionalidad.

En el presente proyecto se realizó la valoración de las Historias de Usuario empleando la serie Fibonacci (medición en base a la complejidad) acotándola en el rango 1, 2, 3, 5, 8. La especificación completa de las Historias de Usuario empleadas en el desarrollo del sistema se

51

encuentra en la sección Anexos del presente documento (Ver Anexo X). A continuación se presenta un modelo de las Historias de Usuario y los Criterios de Aceptación con una breve descripción de cada una de sus partes.

Tabla 12 Plantilla de Historia de Usuario

Historia de Usuario Identificador: (Número de HU)

Nombre: (Nombre de la historia de usuario)

Prioridad: (Prioridad en negocio Alta/Media/Baja)

Iteración: (Número de la Iteración asignada)

Riesgo en desarrollo: (Alta/Media/Baja)

Estimación: (valor realizado por los desarrolladores)

Desarrolladores Responsables: (nombre de los desarrolladores a cargo) Rol

Funcionalidad

Razón

Rol de usuario (tipo de usuario)

Funcionalidad que necesita/debe

que desempeña la funcionalidad

hacer el sistema

Representa el resultado o finalidad

Observación: (algún comentario, aclaración o sugerencia respecto a lo solicitado)

Escenario de pruebas Criterios de aceptación

Identificador (Número)

Contexto

Evento

Resultado

Descripción de condiciones

Acciones a ejecutar

Consecuencias

Fuente: Investigación de campo

Plan de publicaciones.

Denominado Release Plan, es un artefacto de XP que se genera en la Reunión de Planificación de Lanzamientos (Release Planning Meeting) y que gobierna o dirige el desarrollo del proyecto de forma general. En este plan se describen las entregas o “lanzamientos” del producto final que se realizará en todo el transcurso del proyecto. En otras palabras, se agrupan y listan las historias de usuario que se implementarán en una determinada entrega (release) y el tiempo estimado para dicha entrega, generalmente en meses.

El Release Plan no siempre es estático, puede modificarse conforme el cliente vaya añadiendo (historias de usuario) o modificando características del software, a su vez que sirve de base para crear el Iteration Plan o Plan de Iteraciones. El Release Plan para el presente proyecto se evidencia en la Tabla 13.

52 Tabla 13 Plan de Entregas

Módulos del Sistema

Historias de Usuario

Tiempo estimado Semanas

Administración

Catálogo

Dispositivos Consultas

Mantenimientos

Registro de Usuarios Actualización de Usuarios Registro de Agencias Modificación de Agencias Registro de Áreas Modificación de Áreas Registro de Departamentos Modificación Departamentos Registros de Marcas Modificación de Marcas Registro de Sistemas Operativos Modificación Sistemas Operativos Reporte de Agencias Reporte de Áreas Reporte de Departamentos Reporte de Marcas Reporte de Sistemas Operativos Registro de Dispositivos Modificación de Dispositivos Reporte de Dispositivos Consulta de Dispositivo Reporte Consulta Dispositivo Registro de Mantenimiento Modificación Mantenimiento Reporte de Mantenimiento Cambio de Estado de Mantenimiento

1 1 1 1 1 1 1,2 1,2 0,6 1,6 1,2 2,6 1,6

Lanzamiento 1

2

3

                         

Fuente: Investigación de campo

Plan de iteraciones.

El Plan de Iteraciones (Iteration Plan) es otro artefacto de la Planeación en XP. Este plan se realiza en la Reunión de Planificación de Iteración (Iteration Planning Meeting) que tiene lugar al principio de cada iteración. Las iteraciones pueden durar entre 1-3 semanas. Es en esta etapa en donde el cliente selecciona las historias de usuario (del Release Plan) que se desarrollarán en determinada iteración y en un orden establecido.

De acuerdo con los lineamientos de la metodología XP se determina el tiempo calendario para la realización de las iteraciones, en el caso de la presente investigación, se encuentra determinado por 1 mes de 4 semanas, cada semana con 5 días laborales, y cada día con 4 horas.

53 Tabla 14 Plan de Iteraciones

Administración

Catálogo

Dispositivos Consultas

Mantenimientos

Tiempo Estimado

Iteración Asignada

Módulos del Sistema

Historias de Usuario 1 Registro de Usuarios Actualización de Usuarios Registro de Agencias Modificación de Agencias Registro de Áreas Modificación de Áreas Registro de Departamentos Modificación Departamentos Registros de Marcas Modificación de Marcas Registro de Sistemas Operativos Modificación Sistemas Operativos Reporte de Agencias Reporte de Áreas Reporte de Departamentos Reporte de Marcas Reporte de Sistemas Operativos Registro de Dispositivos Modificación de Dispositivos Reporte de Dispositivos Consulta de Dispositivo Reporte Consulta Dispositivo Registro de Mantenimiento Modificación Mantenimiento Reporte de Mantenimiento Cambio de Estado de Mantenimiento

2

3

4

5

6

H

D Semanas

 

12 8 12 8 12 8 12 8 12 8 12 8 12 12 12 12 12 20 12 12 12 20 20 12 20 12

3 2 3 2 3 2 3 2 3 2 3 2 3 3 3 3 3 5 3 3 3 5 5 3 5 3

                       

3

3

3

2,8

2,6 1,6

Fuente: Investigación de campo

5.2.2. Fase de diseño.

Tarjetas CRC. En la metodóloga XP, el paradigma que se usa para la codificación del producto final es el orientado a objetos. Las tarjetas Clase-Responsabilidad-Colaborador permiten a los desarrolladores tener una idea de la realidad modelada a través de clases y objetos, de esta forma se crean escenarios previo a la codificación. La tarjeta se divide en tres partes: la primera que es la especificación del nombre de la Clase, en la columna izquierda las Responsabilidades que poseerá dicha clase, y en la columna derecha las clases Colaboradoras. A continuación se realiza la especificación de las tarjetas CRC empleadas:

54

Tabla 15 Tarjeta CRC Agencia Tarjeta CRC Nombre del Sistema: SGtics

Institución vinculada: CNEL EP

Código: CRC-001

Realizado por: Guillermo Barcia – Nólvar Gómez Datos de la clase Nombre de la clase: AgenciaDAOImpl.java

Responsabilidades

Colaboradores

Crear agencias Editar/Actualizar agencias Listar agencias Eliminar agencias

Agencia.java AgenciaDAO.java

Fuente: Investigación de campo

Tabla 16 Tarjeta CRC Área Tarjeta CRC Nombre del Sistema: SGtics

Institución vinculada: CNEL EP

Código: CRC-002

Realizado por: Guillermo Barcia – Nólvar Gómez Datos de la clase Nombre de la clase: AreaDAOImpl.java

Responsabilidades

Colaboradores

Crear áreas Editar/Actualizar áreas Listar áreas Eliminar áreas

Area.java AreaDAO.java

Fuente: Investigación de campo

55

Tabla 17 Tarjeta CRC Código Tarjeta CRC Nombre del Sistema: SGtics

Institución vinculada: CNEL EP

Código: CRC-003

Realizado por: Guillermo Barcia – Nólvar Gómez Datos de la clase Nombre de la clase: CodigoDAOImpl.java

Responsabilidades

Colaboradores

Crear códigos Editar/Actualizar códigos Listar códigos Eliminar códigos

Codigo.java CodigoDAO.java

Fuente: Investigación de campo

Tabla 18 Tarjeta CRC Departamento Tarjeta CRC Nombre del Sistema: SGtics

Institución vinculada: CNEL EP

Código: CRC-004

Realizado por: Guillermo Barcia – Nólvar Gómez Datos de la clase Nombre de la clase: DepartamentoDAOImpl.java

Responsabilidades

Colaboradores

Crear departamentos Editar/Actualizar departamentos Listar departamentos Eliminar departamentos

. Departamento.java DepartamentoDAO.java

Fuente: Investigación de campo

56

Tabla 19 Tarjeta CRC Dispositivo complemento Tarjeta CRC Nombre del Sistema: SGtics

Institución vinculada: CNEL EP

Código: CRC-005

Realizado por: Guillermo Barcia – Nólvar Gómez Datos de la clase Nombre de la clase: Dispositivo_cplDAOImpl.java

Responsabilidades

Colaboradores

Crear complemento dispositivo Editar/Actualizar complemento dispositivo Listar complemento dispositivo Eliminar complemento dispositivo

Dispositivo_cpl.java Dispositivo_cplDAO.java

Fuente: Investigación de campo

Tabla 20 Tarjeta CRC Dispositivo Tipo Tarjeta CRC Nombre del Sistema: SGtics

Institución vinculada: CNEL EP

Código: CRC-006

Realizado por: Guillermo Barcia – Nólvar Gómez Datos de la clase Nombre de la clase: Dispositivo_tipoDAOImpl.java

Responsabilidades

Colaboradores

Crear tipos de dispositivos Editar/Actualizar tipos de dispositivos Listar tipos de dispositivos Eliminar tipos de dispositivos

Dispositivo_tipo.java Dispositivo_tipoDAO.java

Fuente: Investigación de campo

57 Tabla 21 Tarjeta CRC Dispositivo Tipo 4 Tarjeta CRC Nombre del Sistema: SGtics

Institución vinculada: CNEL EP

Código: CRC-007

Realizado por: Guillermo Barcia – Nólvar Gómez Datos de la clase Nombre de la clase: Dispositivo_tipo4DAOImpl.java

Responsabilidades

Colaboradores

Crear componentes pc Editar/Actualizar componentes pc Listar componentes pc Eliminar componentes pc

Dispositivo_tipo4.java Dispositivo_tipo4DAO.java

Fuente: Investigación de campo

Tabla 22 Tarjeta CRC Dispositivo Tarjeta CRC Nombre del Sistema: SGtics

Institución vinculada: CNEL EP

Código: CRC-008

Realizado por: Guillermo Barcia – Nólvar Gómez Datos de la clase Nombre de la clase: DispositivoDAOImpl.java

Responsabilidades

Colaboradores

Crear dispositivos Editar/Actualizar dispositivos Listar dispositivos Eliminar dispositivos

Dispositivo.java DispositivoDAO.java

Fuente: Investigación de campo

58 Tabla 23 Tarjeta CRC Mantenimiento Tarjeta CRC Nombre del Sistema: SGtics

Institución vinculada: CNEL EP

Código: CRC-009

Realizado por: Guillermo Barcia – Nólvar Gómez Datos de la clase Nombre de la clase: MantenimientoDAOImpl.java

Responsabilidades

Colaboradores

Crear mantenimientos Editar/Actualizar mantenimientos Listar mantenimientos Eliminar mantenimientos

Mantenimiento.java MantenimientoDAO.java

Fuente: Investigación de campo

Tabla 24 Tarjeta CRC Detalle Mantenimiento Tarjeta CRC Nombre del Sistema: SGtics

Institución vinculada: CNEL EP

Código: CRC-010

Realizado por: Guillermo Barcia – Nólvar Gómez Datos de la clase Nombre de la clase: MantenimientoDetalleDAOImpl.java

Responsabilidades

Colaboradores

Crear detalle mantenimientos Editar/Actualizar detalle mantenimientos Listar detalle mantenimientos Eliminar detalle mantenimientos

MantenimientoDetalle.java MantenimientoDetalleDAO.java

Fuente: Investigación de campo

59 Tabla 25 Tarjeta CRC Marca Tarjeta CRC Nombre del Sistema: SGtics

Institución vinculada: CNEL EP

Código: CRC-011

Realizado por: Guillermo Barcia – Nólvar Gómez Datos de la clase Nombre de la clase: MarcaDAOImpl.java

Responsabilidades

Colaboradores

Crear marcas Editar/Actualizar marcas Listar marcas Eliminar marcas

Marca.java MarcaDAO.java

Fuente: Investigación de campo

Tabla 26 Tarjeta CRC MyRevision Tarjeta CRC Nombre del Sistema: SGtics

Institución vinculada: CNEL EP

Código: CRC-012

Realizado por: Guillermo Barcia – Nólvar Gómez Datos de la clase Nombre de la clase: MyRevision.java

Responsabilidades

Colaboradores

Crear auditorias Editar/Actualizar auditorias Listar auditorias Eliminar auditorias

DefaultRevisionEntity.java

Fuente: Investigación de campo

60 Tabla 27 Tarjeta CRC Sistema Operativo Tarjeta CRC Nombre del Sistema: SGtics

Institución vinculada: CNEL EP

Código: CRC-013

Realizado por: Guillermo Barcia – Nólvar Gómez Datos de la clase Nombre de la clase: SisOperativoDAOImpl.java

Responsabilidades

Colaboradores

Crear sistemas operativos Editar/Actualizar sistemas operativos Listar sistemas operativos Eliminar sistemas operativos

SisOperativo.java SisOperativoDAO.java

Fuente: Investigación de campo

Tabla 28 Tarjeta CRC Usuario Tarjeta CRC Nombre del Sistema: SGtics

Institución vinculada: CNEL EP

Código: CRC-014

Realizado por: Guillermo Barcia – Nólvar Gómez Datos de la clase Nombre de la clase: UsuarioDAOImpl.java

Responsabilidades

Colaboradores

Crear usuarios Editar/Actualizar usuarios Listar usuarios Eliminar usuarios

Usuario.java UsuarioDAO.java

Fuente: Investigación de campo

61

Diseño de la base de datos.

5.2.2.2.1. Diseño lógico de la base de datos.

Figura 19. Diseño lógico de la base de datos. Fuente: Investigación de campo

62

5.2.2.2.2. Diccionario de datos.

El diccionario de datos es un aspecto importante en cuanto se refiere al diseño de una base de datos. Es un archivo en donde se especifica de forma estructurada toda la información acerca de los datos que se encuentran almacenados en una base de datos. Es decir, en él se lista de forma organizada todas las tablas (entidades) que componen el sistema, los campos de las tablas, el tamaño, tipos de datos empleados, comentarios, entre otras características. SGtics, al igual que otros sistemas, cuenta con su propio diccionario de datos, el cual se encuentra en la sección Anexos del presente documento (ver Anexo 8).

5.2.2.2.3. Script de la base de datos.

La especificación o creación del script de una base de datos se realiza en un archivo independiente y es generado luego de la creación del diseño lógico de la base de datos del sistema. En este archivo se encuentran todas las sentencias e instrucciones (generalmente en lenguaje sql) que mueven toda la actividad de la base de datos, como la creación de entidades, triggers, operaciones CRUD, entre otros. Un resumen del script de la base de datos del sistema SGtics se muestra en el apartado Anexos (ver Anexo 9) del presente documento.

5.2.2.2.4. Diseño de interfaces.

La presentación de pequeños modelos (prototipos) de la parte visual de un sistema es de gran utilidad para los desarrolladores, dado que el cliente (o el usuario) pueden observar cómo quedará los componentes finales del sistema, y a su vez brindar feedback (comentarios, sugerencias) respecto a los mismos. La maquetación de las vistas o interfaces del sistema SGtics se ha realizado empleando la herramienta de prototipado de mockups, MockPlus.

63

5.2.2.2.5. Interfaces ingreso/registro.

Ingreso al Sistema.

Figura 20. Prototipo interfaz de Login. Fuente: Investigaciรณn de campo

Registro en el sistema.

Figura 21. Prototipo interfaz de Registro. Fuente: Investigaciรณn de campo

64

5.2.2.2.6. Interfaces internas.

Panel Principal

Figura 22. Prototipo del Panel Principal. Fuente: Investigaci贸n de campo

Administraci贸n de Usuarios

Figura 23. Prototipo M贸dulo de Usuarios. Fuente: Investigaci贸n de campo

65

Administración de Catálogos

Figura 24. Prototipo Módulo de Catálogos. Fuente: Investigación de campo

Administración de Dispositivos

Figura 25. Prototipo Módulo de Dispositivos. Fuente: Investigación de campo

66

Figura 26. Prototipo ingreso nuevo dispositivo. Fuente: Investigaciรณn de campo

Consultas

Figura 27. Prototipo interfaz Mรณdulo Consultas. Fuente: Investigaciรณn de campo

67

5.2.3. Fase de codificación.

Es en esta fase en donde se transforman las historias de usuario (requerimientos) junto con las tarjetas CRC en instrucciones o código de un lenguaje de programación específico. La codificación de las características del sistema se ha realizado tanto a nivel de base de datos como de aplicación. Como punto previo se presenta una tabla con los tipos de usuario que posee el sistema y su nivel de acceso correspondiente en el sistema.

Tabla 29 Definición de permisos Módulos Tipos de Usuarios Administración

Catálogo

Dispositivos

Consultas

Mantenimiento



















Súper-Administrador Administrador Usuario Fuente: Investigación de campo

Codificación a nivel de base de datos.

Figura 28. Parámetros de conexión. Fuente: Investigación de campo.



68

Figura 29. Conexión a la base de datos. Fuente: Investigación de campo

Codificación de interfaces.

A continuación se presenta la codificación y su resultado (interfaces) de las partes más destacadas del sistema. 

Inicio de Sesión

Figura 30. Codificación Login de Usuario. Fuente: Investigación de campo

69

Figura 31. Interfaz Inicio de Sesión. Fuente: Investigación de campo



Dispositivos

Figura 32. Interfaz Módulo Dispositivos. Fuente: Investigación de campo

70

Figura 33. Interfaz Registro de Dispositivos. Fuente: Investigaciรณn de campo

Figura 34. Codificaciรณn Registro de dispositivos. Fuente: Investigaciรณn de campo

71



Mantenimientos

Figura

35.

Codificación

Módulo

Mantenimientos.

Fuente:

Investigación de campo

Figura 36. Interfaz Módulo Mantenimientos. Fuente: Investigación de campo

72

Fase de pruebas.

5.2.3.3.1. Pruebas unitarias.

Las pruebas unitarias se realizan en la fase de codificación como primer punto, pero que en conjunto se suman a la fase de pruebas finales del sistema para el aseguramiento de la calidad del software. Este tipo de pruebas se realizan de forma automatizada, ya sea creándolas o a su vez empleando software que simplifique la tarea. Todo esto se realiza con la finalidad de testear todas las clases que posee el código del sistema asegurando que el código liberado cumpla siempre con la finalidad esperada.

Para la ejecución de los Unit Test en el sistema SGtics se ha empleado la característica JUnit que viene incluida en el IDE Eclipse. A continuación se muestra el resultado exitoso de la ejecución de una prueba unitaria en la clase Dispositivos:

Figura 37. Resultado Prueba Unitaria – Clase Dispositivo. Fuente: Investigación de campo

73

5.2.3.3.2. Pruebas de aceptación.

Las pruebas de aceptación al ser realizadas por el cliente comprueban la funcionalidad del sistema según lo determinado en las historias de usuario. De acuerdo con la Metodología XP, este tipo de pruebas se realiza por historia de usuario escrita, basándose en ella y en los criterios de aceptación que posea; en el caso del presente proyecto se ha realizado de la misma manera. A continuación se presenta la plantilla de las pruebas de aceptación que se han empleado.

Tabla 30 Plantilla Prueba de Aceptación Empresa: Corporación Nacional de Electricidad (CNEL EP) Santo Domingo

Código Caso de Prueba: Elaborado por: Release: Iteración: Módulo/sección: Objetivo:

Prueba de Aceptación Nombre de la Prueba: Ejecutado por: Historia de usuario involucrada: Perfil de Usuario:

Propósito: Precondiciones: Flujo del test Pasos y condiciones de ejecución

N° 1 2 3 4 5 Resultado Esperado: Resultado Obtenido:

Errores

Status Aprobado

Fallida

Post-Condiciones: Fuente: Investigación de campo

Graves

Leves

Ninguno

Observaciones y/o Recomendaciones:

74

5.2.4. Fase final.

Es la Ăşltima fase de la metodologĂ­a XP o tambiĂŠn denominada Muerte del Proceso XP. Sucede cuando el cliente ya no describe o trae consigo nuevas historias de usuario (requerimientos o funcionalidades) para que el equipo de desarrollo las implemente en una nueva entrega. Es entonces que se da por cumplidas o satisfechas todas las necesidades y expectativas del cliente respecto al desarrollo del sistema.

Para dar por finalizado la realizaciĂłn del proyecto, se ha efectuado la respectiva entrega del sistema SGtics al personal que lo utilizarĂĄ en la empresa. De igual modo se ha elaborado el correspondiente Manual de InstalaciĂłn que cubre todos los aspectos tĂŠcnicos del sistema, y el Manual de Usuario que brinda una inducciĂłn general del funcionamiento global del sistema, siendo una Ăştil herramienta de apoyo para el usuario final.

AnĂĄlisis de impactos El anĂĄlisis de impacto se orienta en la conducta externa del producto, para comprender mejor los impactos generados en el proyecto, a continuaciĂłn se expone una tabla, donde se especifican los diferentes niveles, he indicadores numĂŠricos de cada uno respectivamente. Para el cĂĄlculo de los niveles de impacto se utilizara la siguiente tabla: Tabla 31 Tabla de identificaciĂłn de los niveles de impactos Nivel

DescripciĂłn

-3

Impacto de alto nivel negativo

-2

Impacto de medio nivel negativo

-1

Impacto de bajo nivel negativo

0

No hay impacto

1

Impacto de bajo nivel positivo

2

Impacto de medio nivel positivo

3

Impacto de alto nivel positivo

Nota: Adoptado de “MetodologĂ­a para el trabajo de gradoâ€?, por M. A. Posso, 2009. Tesis y Proyectos Cuarta ed. Ibarra: NINA Comunicaciones.

Para determinar el impacto total se utilizara la siguiente fĂłrmula: đ?‘ đ??ź = ∑/đ?‘ ° Nivel de impacto = total sumatorio dividido para la cantidad de indicadores

75

5.3.1. Impacto tecnolĂłgico.

Tabla 32 Impacto tecnolĂłgico.

Nivel de impacto

-3

-2

-1

0

1

2

3

Indicadores AutomatizaciĂłn de procesos Total

X -

-

-

-

Sumatoria ∑ Total

-

2

-

∑=2

Resultado

đ?‘ đ??ź =

2 =2 1

Impacto de alto nivel positivo Fuente: InvestigaciĂłn de campo

AnĂĄlisis: La CNEL EP cuenta con infraestructura tecnolĂłgica (Equipos informĂĄticos) y el aporte de este proyecto es mejorar el rendimiento de las actividades (registros y mantenimientos) con la ayuda del sistema SGtics.

5.3.2. Impacto social Tabla 33: Impacto social Nivel de impacto

-3

-2

-1

0

1

2

3

Indicadores AtenciĂłn al cliente.

Total Sumatoria ∑ Total Resultado

X -

-

-

-

-

2

-

∑=2 đ?‘ đ??ź =

2 =2 1

Impacto de medio nivel positivo Fuente: InvestigaciĂłn de campo

AnĂĄlisis: La CNEL EP se preocupa por agilizar procesos en la atenciĂłn al cliente, es por ello que con el uso del sistema SGtics se ha logrado disminuir considerablemente el tiempo que se tarda en dar mantenimiento o reparar un equipo que tenga algĂşn defecto.

76

5.3.3. Impacto ambiental.

Tabla 34 Impacto ambiental Nivel de impacto

-3

-2

-1

0

1

2

3

Indicadores Uso de papel y carpetas

x

UtilizaciĂłn de tinta en copias

x

Total

-

-

-

-

Sumatoria ∑ Total

-

4

-

∑=4

Resultado

đ?‘ đ??ź =

4 =2 2

Impacto de medio nivel positivo Fuente: InvestigaciĂłn de campo

AnĂĄlisis: El sistema SGtics permite la gestiĂłn de los mantenimientos de los equipos por medio de un sistema web, obteniendo asĂ­ un ahorro considerable de papel y carpetas. Con el sistema SGtics existe una disminuciĂłn considerable en el uso de tinta para impresiones, actualmente ya no es necesario imprimir un formato para llenar el registro de un nuevo bien informĂĄtico, o informes de mantenimientos.

5.3.4. Impacto EconĂłmico Tabla 35 Impacto EconĂłmico Nivel de impacto

-3

-2

-1

0

1

2

3

Indicadores ReducciĂłn de fondos para impresiones,

X

papel y carpetas Total Sumatoria ∑ Total Resultado

-

-

-

-

-

2

-

∑=2 đ?‘ đ??ź =

2 =2 1

Impacto de medio nivel positivo Fuente: InvestigaciĂłn de campo

AnĂĄlisis: La mayor parte de los fondos se destinan a la adquisiciĂłn de papel, tinta y carpetas, con el sistema SGtics no se harĂĄ uso de este fondo, ahorrando dinero a la empresa

77

5.3.5. Impacto general Tabla 36 Impacto general Nivel de impacto

-3

-2

-1

0

1

2

3

Indicadores Impacto TecnolĂłgico

X

Impacto Social

X

Impacto Ambiental

X

Impacto EconĂłmico

X

Total Sumatoria ∑ Total Resultado de FĂłrmula

-

-

-

-

-

8

-

∑=8 đ?‘ đ??ź =

8 =2 4

Impacto de medio nivel positivo Fuente: InvestigaciĂłn de campo

AnĂĄlisis: El sistema encargado del control de registros y mantenimiento de los bienes informĂĄticos en la CNEL EP muestra un impacto de nivel medio positivo, lo cual evidencia la viabilidad del proyecto en esta empresa. La automatizaciĂłn de los registros y mantenimiento aprovecha de manera adecuada el tiempo que se le emplea a cada una de estas actividades.

78

Conclusiones -

Con la implementación del sistema web, la Corporación Nacional de Electricidad (CNEL EP) Santo Domingo moderniza la forma de realizar los procesos involucrados en el registro de los dispositivos que posee la institución, a su vez que permite llevar una eficiente administración de los mismos facilitando efectuar un adecuado control y seguimiento de los respectivos mantenimientos, consiguiendo con ello optimizar el tiempo empleado en dichas tareas.

-

La metodología seleccionada Extreme Programming –XP- demostró ser la indicada para el desarrollo del presente proyecto dado que se acopló de forma adecuada a la naturaleza y dimensiones del mismo. Al ser una metodología que pone especial énfasis en el desarrollo, permitió al equipo de trabajo tener una concepción uniforme del sistema, realizar integraciones continuas y entregas incrementales del mismo. El flujo de su proceso organizado (Planificar, Diseñar, Codificar, Probar) permitió llevar un ritmo de trabajo flexible y cómodo tanto para el cliente como para el equipo de trabajo.

-

Con la aplicación de las respectivas entrevistas se logró definir puntos importantes respecto al desarrollo del sistema web, como son el lenguaje de programación a emplear, qué servidor web aplicar, qué base de datos usar, aspectos a considerar en los módulos, entre otros. Todo aquello con la finalidad de servir de guía o punto de partida para el desarrollo y mantener la compatibilidad con las tecnologías que se emplean hasta la fecha en la institución.

-

Una amplia recopilación de información acerca de los procesos y la forma en cómo se ejecutaban en la institución permitió al equipo de desarrollo empaparse de la situación actual de la misma y formarse una idea global de la lógica de negocio que se maneja, con el propósito de entenderla y tomar las medidas adecuadas para optimizar los procesos en el sistema elaborado.

-

Respecto a las herramientas de desarrollo empleadas se concluye que: Java EE es una excelente plataforma que permite crear aplicaciones robustas, escalables y portables empleando el lenguaje Java, Bootstrap permitió el diseño de interfaces web de forma dinámica y visualmente atractivas para el usuario final, DB2 permitió almacenar los datos y manejar de forma eficiente todas las peticiones del usuario a través de consultas.

79

Recomendaciones -

Seleccionar la metodología de desarrollo de software más idónea a aplicar en el proyecto considerando factores como el tiempo, adaptabilidad, alcance, entre otros aspectos. Además analizar las ventajas y desventajas de su aplicabilidad.

-

La disponibilidad y comunicación por parte del cliente es un factor muy importante en el éxito o fracaso de un proyecto, dado que de este modo se puede recibir información acerca de las herramientas de desarrollo a emplear, los requerimientos, etc.

-

Las capacitaciones acerca del correcto uso del sistema debe contar con la participación de la mayoría de los usuarios involucrados en la administración del mismo, de este modo se previenen futuros inconvenientes en la utilización del sistema.

-

Realizar respaldos periódicos de la base de datos en formas alternativas de almacenamiento, asegurando de esta forma la protección y el reguardo de los mismos.

-

Emplear el Manual de Usuario como herramienta de apoyo en la administración del sistema web.

80

Lista de Referencias Agile Alliance. (2017). What is Agile? Obtenido de https://www.agilealliance.org/agile101/ Álvarez, A., De las Heras del Dedo, R., & Lasa, C. (2012). Métodos Ágiles y Scrum. Madrid: Anaya.

Al-Zewairi, M., Biltawi, M., Etaiwi, W., & Shaout, A. (2017). Agile Software Development Methodologies: Survey of Surveys. Journal of Computer and Communications, 5(5), 74-97. doi:10.4236/jcc.2017.55007 Amaya, Y. (2013). Metodologías ágiles en el desarrollo de aplicaciones para dispositivos móviles. Estado actual. Revista de Tecnología, 12(2), 111-124. Obtenido de http://m.uelbosque.edu.co/sites/default/files/publicaciones/revistas/revista_tecnologia/ volumen12_numero2/12Articulo_Rev-Tec-Num-2.pdf Andreu, J. (2011). Instalación de equipos de red. Configuración (Redes locales). Madrid: Editorial Editex S.A. Anwer, F., Aftab, S., Muhammad, S., & Waheed, U. (2017). Comparative Analysis of Two Popular Agile Process Models: Extreme Programming and Scrum. International Journal of Computer Science and Telecommunications, 8(2), 1-7. Obtenido de http://www.ijcst.org/Volume8/Issue2/p1_8_2.pdf Bernal, C. (2010). Metodología de la Investigación. Colombia: Pearson Educación.

Borda, M. (2013). El proceso de Investigación: Visión general de su desarrollo. Barranquilla: Editorial Universidad del Norte.

Brito, K., Sosa, D., & Héctor, K. (2015). Selección de Metodologías de Desarrollo para Aplicaciones Web. USA: Editorial Académica Española.

Cendejas, J., Vega, C., Isordia, A., Gutiérrez, O., & Ferreira, H. (2014). Diseño del modelo integral colaborativo para el desarrollo ágil de software en las empresas de la zona centro-occidente en México. Nova Scientia, 7(13), 133-148. Obtenido de http://www.scielo.org.mx/pdf/ns/v7n13/v7n13a8.pdf Coronel, G. (2011). Desarrollando soluciones con Java. España: Macro.

81

Daza, A., Parra, J., & Espinosa, L. (2016). Metodología de representación de software orientada al desarrollo ágil de aplicaciones: Un enfoque arquitectural. Redes de Ingeniería, 7(1), 26-33.

Eclipse,

F.

(Martes

de

Agosto

de

2017).

Eclipse.

Obtenido

de

Eclipse:

https://www.eclipse.org/home/index.php Fernández, Y., & Díaz, Y. (2012). Patrón Modelo-Vista-Controlador. Telem@tica, 11(1), 4757. Obtenido de http://revistatelematica.cujae.edu.cu/index.php/tele/article/view/15/10 Ferrer, J. (2014). Implantación de Aplicaciones Web. Madrid: Ra-Ma. Flora, H., & Chande, S. (2014). A Systematic Study on Agile Software Development Methodologies and Practices. International Journal of Computer Science and Information

Technologies,

5(3),

3626-3637.

Obtenido

de

https://pdfs.semanticscholar.org/5d2a/d96c2dce23e6875dfeeae70a4cf122372457.pdf Flórez, H. (2012). Programación Orientada a Objetos usando JAVA. Bogotá: Ecoe.

Fuggetta, A., & Di Nitto, E. (2014). Software Process. Proceedings of the on Future of Software Engineering (págs. 1-12). Hyderabad, India: Association for Computing Machinery. doi:10.1145/2593882.2593883 García, J. (2014). Contabilidad de Costos. México: McGRAW-HILL/INTERAMERICANA EDITORES, S.A. DE C.V. Gibson, J. (2017). Foundations Of Software Engineering. Obtenido de http://www-public.temtsp.eu/~gibson/Teaching/CSC7003/L10-Process.pdf Hernández Claro, R., & Greguas Navarro, D. (2016). Estandares de diseño Web. Ciencias de la información, 69-70.

Hernández, R., Fernández, C., & Baptista, M. (2014). Metodología de la Investigación.

México: McGrawHill.

Herrera, M., Duany-Alfonso, Y., & Abreu-Duque, A. (2014). Sistema Automatizado para la Gestión

del

Mantenimiento.

Inge@UAN,

4(8),

48-54.

http://csifesvr.uan.edu.co/index.php/ingeuan/article/view/268/pdf

Obtenido

de

82

Hibernate. (Jueves de Septiembre de 2017). Hibernate. Obtenido de Hibernate: http://hibernate.org/orm/documentation/5.2/ IBM.

(10

de

septiembre

de

2017).

IBM.

Obtenido

de

IBM:

https://www.ibm.com/analytics/us/en/db2/ Ibujés, Á. (2015). Análisis, Diseño y Desarrollo de una herramienta de Administración de Mantenimiento y Reparación de Equipos Informáticos, Computarized Maintenance Management System, CMMS. (tesis de grado), Universidad Central del Ecuador, Quito, Ecuador. Obtenido de http://www.dspace.uce.edu.ec/handle/25000/4297 Iqbal, U., & Javed, A. (2014). Review-Scrum(R-Scrum) Introduction Of Model Driven Architecture (MDA) In Agile Methodology. International Journal of Scientific & Technology Research, 3(11), 296-302.

Ixmatlahua, D., Raygoza, O., Romero, O., Uribe, F., & Vargas, F. (2015). Metrópoli Digital: Una plataforma Web para la inclusión integral de las PyMES, Sociedad y Gobierno en el uso de las Tecnologías de la Información en la región de las Altas Montañas del estado de Veracruz, México. Revista Ibérica de Sistemas e Tecnologias de Información, 43-54.

Janvan, B. (2015). Fundamentos de Gestión de Servicios TI. EEUU: Itsmf international.

Joyanes, L. (2013). Fundamentos generales de programación. México: McGraw Hill.

Levy, R., Short, M., & Measey, P. (2015). Agile foundations: principles, practices and frameworks. Swindon: BSC. López, L., & Gutiérrez, Á. (2014). Programación Orientada a Objetos C++ y Java. México: Grupo Editorial Patria.

López, M., Vara, J., Verde, J., Sánchez, D., Jiménez, J., & de Castro, V. (2014). Desarrollo Web en Entorno Servidor. Madrid: Ra-Ma. Martínez, C. (2012). Administración de Organizaciones. Bogotá: Facultad de Ciencias Económicas.

Matharu, G., Mishra, A., Singh, H., & Upadhyay, P. (2015). Empirical study of agile software

83

development methodologies: A comparative analysis. ACM SIGSOFT Software Engineering Notes, 40(1). doi:10.1145/2693208.2693233 Medina, D., Suárez , Y., & Hernández , P. (2015). Sistema automatizado para la gestión del mantenimiento de equipos (módulos patrimonio y órdenes de trabajo). Revista Ciencias Técnicas

Agropecuarias,

24,

79-84.

Obtenido

de

http://www.redalyc.org/pdf/932/93243475014.pdf Microsoft Corporation. (2017). Descripción general de Microsoft Solutions Framework (MSF). Obtenido de https://msdn.microsoft.com/es-es/library/jj161047(v=vs.120).aspx Moreno, J. (2012). Programación. Bogotá: Ediciones de la U. Münch, L. (2014). Administracion: Gestion organizacional, enfoques y proceso administrativo. México: Pearson Educación.

Murray, A. (2016). The Complete Software Project Manager : Mastering Technology from Planning to Launch and Beyond. Hoboken: John Wiley & Sons Inc. Navarro, A., Fernández, J., & Morales, J. (2013). Revisión de metodologías ágiles para el desarrollo

de

software.

Prospectiva,

11(2),

30-39.

Obtenido

de

http://www.redalyc.org/pdf/4962/496250736004.pdf Pérez, M. (2015). MySQL Diseño, Programación y Aministración de Bases de Datos. San Bernardino: Createspace.

Piñeiro, J. (2013). Base de datos relacionales y modelado de datos. España: Ediciones Paraninfo, S.A. Posso, M. A. (2009). Metodología para el trabajo de grado: Tesis y Proyectos (Cuarta ed.).

Ibarra: NINA Comunicaciones.

Pressman, R. (2010). Ingeniería del software: Un enfoque práctico. México: Mc GrawHill.

Rey, F. (2014). Elaboración y optimización de un plan de mantenimiento preventivo. Técnica Industrial(308), 30-41.

Rosado, A., Quintero, A., & Meneses, C. (2012). Desarrollo ágil de software aplicando Programación

Extrema.

Ingenio,

5(1),

24-29.

Obtenido

de

84

http://revistas.ufpso.edu.co/index.php/ringenio/article/view/23/10 Schwaber,

K.,

&

Sutherland,

J.

(2017).

The

Scrum

Guide.

Obtenido

de

http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-GuideUS.pdf#zoom=100 Secretaría Nacional de Planificación y Desarrollo. (2013). Plan Nacional para el Buen Vivir.

Quito.

Silva, H. (2017). Desarrollo e implementación de un sistema web con MVC para el control del mantenimiento preventivo y correctivo de los bienes del Cuerpo de Bomberos del Gobierno Autónomo Descentralizado Municipal de Santo Domingo; periodo 20162017. (tesis de grado), Pontificia Universidad Católica del Ecuador, Santo Domingo, Ecuador. Obtenido de https://issuu.com/pucesd/docs/dg_2017_-_silva_hugo Sommerville, I. (2011). Ingenieria de software. Mexico: Person Educacion.

Spring.

(Martes

de

Septiembre

de

2017).

Spring.net.

Obtenido

de

Spring.net:

http://springframework.net/documentation.html Suárez, Y., Medina, D., & Hernández, P. (2015). Sistema automatizado para la gestión del mantenimiento de equipos (módulos administración y solicitud de servicio). Revista Ciencias

Técnicas

Agropecuarias,

4(5),

85-90.

Obtenido

de

http://www.rcta.unah.edu.cu/index.php/rcta/article/view/395/404 VersionOne. (2017). The 11th Annual State of Agile Report

. Obtenido de

https://explore.versionone.com/state-of-agile/versionone-11th-annual-state-of-agilereport-2 Wood, S., Michaelides, G., & Thomson, C. (2013). Successful extreme programming: Fidelity to the methodology or good teamworking? Information and Software Technology, 55(4), 660-672. doi:10.1016/j.infsof.2012.10.002 Zofío, J. (2013). Aplicaciones Web. Madrid: MACMILLAN IBERIA.

85

GLOSARIO DE TÉRMINOS Apache: Servidor web con licencia libre de uso. Es software multiplataforma capaz de ejecutarse sobre cualquier plataforma, y mantiene un excelente rendimiento.

Bootstrap: Framework para facilitar diseño de páginas web adaptativas, este proyecto fue liberado por Twitter.

Framework: Considerado como uan estructura conceptual y tecnológica de asistencia definida, con artefactos o módulos fijos de software, que puede servir de base para la organización y desarrollo de software.

Javascript: Lenguaje de programación principalmente usado en el desarrollo de páginas web dinámicas, integrado en los navegadores web donde se interpreta y ejecuta.

JEE: Java Enterprise Edition, Plataforma de programación Java para desarrollar y ejecutar software con arquitectura de N capas distribuidas y que se apoya ampliamente en componentes de software modulares ejecutándose sobre un servidor de aplicaciones.

MVC: Estilo de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos, significa en español Modelo Vista Controladores.

SGBD: Sistema gestor de base de datos. Es un conjunto de programas que permiten el almacenamiento, modificación y extracción de la información en una base de datos, además de proporcionar herramientas para añadir, borrar, modificar y analizar los datos.

Software: Se considera al software como la parte lógica de un sistema informático, que percibe el conjunto de los dispositivos lógicos necesarios que hacen posible la elaboración de tareas específicas.

UML: Unified Modeling Language o lenguaje unificado de modelado, es el lenguaje de modelado de sistemas de software, es el lenguaje en el que está descrito el modelo.

86

Anexos Anexo 1: Entrevista realizada al personal del centro de cómputo en CNEL EP

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO ESCUELA DE SISTEMAS. Entrevista dirigida al personal del Centro de Cómputo de CNEL EP Santo Domingo Objetivo de la Entrevista: recopilar información acerca de los procesos que se manejan internamente en el Centro de Cómputo de CNEL EP en relación al registro y mantenimiento de equipos informáticos

Datos Informativos: Lugar: _______________________________________________________________ Entrevistado: ______________________ Cargo: ________________________________ Entrevistador: _____________________

Fecha: ________________________________

1. ¿De acuerdo a su criterio, qué tal útil y sobre todo necesario considera la implementación de un sistema

web

para

la

gestión

y

mantenimiento

de

los

bienes

informáticos?

___________________________________________________________________________ ___________________________________________________________________________ ____________________________________________________________ 2. ¿De qué manera se lleva el control de los registros y el mantenimiento de los bienes informáticos? ___________________________________________________________________________ ___________________________________________________________________________ ____________________________________________________________

87 3. Una estimación de equipos que ingresan a diario al centro de cómputo

_____________________________________________________________________ _____________________________________________________________________ ______________________________________________________ 4. Una estimación del tiempo requerido para registrar un equipo informático

_____________________________________________________________________ _____________________________________________________________________ ______________________________________________________

5. Una estimación del tiempo requerido para dar mantenimiento a un equipo informático

_____________________________________________________________________ _____________________________________________________________________ ______________________________________________________

6. ¿De qué manera se alerta o notifica al personal encargado que un equipo necesita mantenimiento ya sea preventivo o correctivo?

_____________________________________________________________________ _____________________________________________________________________ ______________________________________________________

7. Problemas comunes al momento de realizar el registro y/o mantenimiento de un equipo informático

_____________________________________________________________________ _____________________________________________________________________ ______________________________________________________

88

Anexo 2: Entrevista realizada al jefe del centro de cómputo.

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO ESCUELA DE SISTEMAS. Entrevista dirigida al Jefe del Departamento de Cómputo de CNEL EP Santo Domingo Objetivo de la Entrevista: recolectar información crucial referente de las políticas internas del departamento y determinación de requerimientos iniciales en conformidad a las herramientas que emplea CNEL EP.

Datos Informativos: Lugar: _______________________________________________________________ Entrevistado: ______________________ Cargo: ________________________________ Entrevistador: _____________________ 1. ¿Cuál

es

el

sistema

Fecha: ________________________________ operativo

que

utiliza

el

servidor

web?

___________________________________________________________________________ ___________________________________________________________________________ ____________________________________________________________ 2. ¿Cuál es el sistema gestor de base de datos que se utiliza dentro de la institución? ___________________________________________________________________________ ___________________________________________________________________________ ____________________________________________________________ 3. ¿Cuál es el lenguaje solicitado para la elaboración del sistema informático?

_____________________________________________________________________ _____________________________________________________________________ ______________________________________________________

89

Anexo 3: Encuesta realizada a los miembros del centro de cómputo de la CNEL EP

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO ESCUELA DE SISTEMAS. Encuesta dirigida al personal que labora en el Departamento de Cómputo de CNEL EP Santo Domingo Objetivo de la Encuesta: recolectar información acerca de los procesos que se llevan a cabo en el departamento de Cómputo de CNEL EP

Nota: 

La información proporcionada es confidencial y será utilizada con fines académicos.



Seleccione solamente una respuesta y márquela con un visto ()

1. ¿ ¿Cree usted que los procesos de control de registros y mantenimientos de los equipos informáticos se llevan de forma adecuada en la institución?

2. ¿Conoce usted el tiempo de vigencia de las garantías de los equipos informáticos de la institución?

3. ¿Cree usted que existen dificultades al momento de registrar los equipos de la institución?

90 4. ¿Es adecuada la manera en que se lleva a cabo el control de los mantenimientos preventivos y correctivos de los equipos?

5. ¿Considera usted que las aplicaciones web son de mucha utilidad y sobre todo necesarias para el manejo de inventario dentro de una empresa?

6. ¿Cree usted que con el desarrollo de una aplicación web que lleve el control de los registros y mantenimientos de equipos, sea beneficioso para la empresa al momento de realizar nuevas adquisiciones?

7. ¿Cree usted que se facilitará el proceso de registro y de mantenimiento de equipos con el desarrollo de aplicación web?

8. ¿Está de acuerdo con la implementación de un sistema web que permita llevar un control adecuado de los registros y mantenimientos de la empresa?

91

Anexo 4: Acta de requerimientos

92

93

94

95

Anexo 5: Acta de entrega recepciรณn

96

Anexo 6: Carta de impacto

97

Anexo 7: Historias de usuario

Historia de Usuario Identificador: 001

Nombre: Registro de usuarios

Prioridad: Alta

Iteraciรณn: 1

Riesgo en desarrollo: Medio

Estimaciรณn: 5

Desarrolladores Responsables: Guillermo Barcia โ Nรณlvar Gรณmez Rol Como usuario

Funcionalidad

Razรณn

Quiero poder registrarme en el

Para acceder y administrar el

sistema

sistema

Observaciรณn: El registro debe hacerse por medio de un formulario. Se deben validar los nick de usuario.

Debe mostrarse un resumen de los datos ingresados y un mensaje de confirmaciรณn.

Escenarios de pruebas Criterios de aceptaciรณn

Identificador

1

Contexto

Evento

Resultado

En caso de dejar en blanco

Cuando el usuario pulse

El sistema no procede

los campos obligatorios del

el botรณn de confirmar

con el registro y muestra

formulario de registro

2

un mensaje de alerta

En caso que se registre un

Cuando el usuario pulse

El sistema realizarรก la

nick (user) ya existente en el

el botรณn de confirmar

validaciรณn necesaria y no

sistema

lo registra.

98

Historia de Usuario Identificador: 002

Nombre: Actualización de usuarios

Prioridad: Alta

Iteración: 1

Riesgo en desarrollo: Baja

Estimación: 3

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol Como súper-administrador

Como súper-administrador

Funcionalidad

Razón

Quiero poder actualizar la

Para mantener la información al

información de los usuarios

día

Quiero poder asignar un perfil

Para que ellos puedan acceder al

determinado a los usuarios

sistema de acuerdo a su perfil

Observación: debe mostrarse un listado de los usuarios registrados. La activación y asignación de permisos debe realizarse de forma sencilla..

Escenarios de pruebas Criterios de aceptación

Identificador

1

Contexto

Evento el

Resultado

En caso de no activar al

Cuando

súper-

El

sistema

no

lo

usuario

administrador pulse el

permitirá hasta que el

botón actualizar

usuario sea activado

99

Historia de Usuario Identificador: 003

Nombre: Registro de Agencias

Prioridad: Alta

Iteración: 1

Riesgo en desarrollo: Bajo

Estimación: 5

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder ingresar (registrar)

Para identificar en que agencia

administrador

agencias en el sistema

se encuentra cierto dispositivo

Observación: Al finalizar el registro se debe mostrar una notificación informando del suceso.

Escenarios de pruebas Identificador

1

Criterios de aceptación Contexto

Evento el

Resultado

En caso de que se dejen en

Cuando

súper-

El sistema notificará del

blanco el campo de registro

admin/admin pulse el

inconveniente sucedido.

botón guardar

2

En caso que se escriba le

Cuando

el

súper-

El sistema validará los

mismo nombre de agencia

admin/admin pulse el

datos e informará del

botón guardar

error asociado.

100

Historia de Usuario Identificador: 004

Nombre: Modificación de Agencias

Prioridad: Alta

Iteración: 1

Riesgo en desarrollo: Bajo

Estimación: 3

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder modificar las

Para actualizar la información de

administrador

agencias previamente ingresadas

la agencia registrada

Observación: se debe informar del cambio realizado por medio de notificaciones.

Escenarios de pruebas Criterios de aceptación

Identificador

1

2

Contexto

Evento

En caso de que se dejen en

Cuando

blanco

admin/admin pulse el

informando que se llenen

formulario

botón guardar

los campos.

En caso que se ingrese una

Cuando

súper-

El sistema validará los

agencia ya existente

admin/admin pulse el

datos e informará del

botón guardar

error asociado.

los

campos

del

el

Resultado

el

súper-

El

sistema

notificará

101

Historia de Usuario Identificador: 005

Nombre: Registro de Áreas

Prioridad: Medio

Iteración: 1

Riesgo en desarrollo: Bajo

Estimación: 2

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder ingresar (registrar)

Para identificar al dispositivo en

administrador

áreas en el sistema

el Área de determinada Agencia

Observación: Al finalizar el ingreso se debe mostrar una notificación informando del registro. Se deben validar datos.

Escenarios de pruebas Identificador

1

2

Criterios de aceptación Contexto

Evento el

Resultado

En caso de que se dejen en

Cuando

súper-

El sistema no procederá

blanco el campo de registro

admin/admin pulse el

con el ingreso y lo

botón guardar

notificará.

En caso que se escriba el

Cuando

el

súper-

El sistema validará los

mismo nombre de un área

admin/admin pulse el

datos e informará del

ingresada

botón guardar

error asociado.

102

Historia de Usuario Identificador: 006

Nombre: Modificación de Áreas

Prioridad: Medio

Iteración: 1

Riesgo en desarrollo: Bajo

Estimación: 2

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder modificar las Áreas

Para actualizar la información del

administrador

registradas previamente

Área de la agencia

Observación: se debe informar del cambio realizado por medio de notificaciones.

Escenarios de pruebas Identificador

1

2

Criterios de aceptación Contexto

Evento el

Resultado

En caso de que se dejen en

Cuando

blanco el campo de edición

admin/admin pulse el

informando que se llene

botón guardar

el campo

el

súper-

El

sistema

notificará

En caso que se ingrese un

Cuando

súper-

El sistema no guardará

área ya existente

admin/admin pulse el

los datos ingresados e

botón guardar

informará del error.

103

Historia de Usuario Identificador: 007

Nombre: Registro de Departamentos

Prioridad: Alta

Iteración: 2

Riesgo en desarrollo: Bajo

Estimación: 5

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder registrar los

Para identificar el departamento

administrador

departamentos

asociado a un dispositivo

Observación: Al finalizar el ingreso se debe mostrar una notificación informando del registro. Se deben validar datos.

Escenarios de pruebas Criterios de aceptación

Identificador

1

Contexto

Evento el

Resultado

En caso de que se dejen en

Cuando

súper-

blanco el campo de registro

admin/admin pulse el

El sistema no procederá con el ingreso de datos.

botón guardar

2

En caso que se escriba el

Cuando

súper-

El sistema validará los

mismo

admin/admin pulse el

datos e informará del

botón guardar

error asociado.

nombre

departamento

de

un

el

104

Historia de Usuario Identificador: 008

Nombre: Modificación de Departamentos

Prioridad: Alta

Iteración: 2

Riesgo en desarrollo: Bajo

Estimación: 3

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador

Quiero poder modificar los

Para actualizar la información del

administrador

departamentos ingresados.

departamento.

Observación: se debe informar del cambio realizado por medio de notificaciones.

Escenarios de pruebas Identificador

1

2

Criterios de aceptación Contexto En caso de que se dejen en blanco el campo de edición

En caso que se ingrese un área ya existente

Evento Cuando

el

Resultado súper-

El

sistema

notificará

admin/admin pulse el

informando que se llene

botón guardar

el campo

Cuando

el

súper-

El sistema no guardará

admin/admin pulse el

los datos ingresados e

botón guardar

informará del error.

105

Historia de Usuario Identificador: 009

Nombre: Registro de Marcas

Prioridad: Medio

Iteración: 2

Riesgo en desarrollo: Bajo

Estimación: 5

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Como súper-administrador y administrador

Razón

Quiero poder ingresar Marcas

Para identificar la marca de un dispositivo ingresado

Observación: Al finalizar el ingreso se debe mostrar una notificación informando del registro. Se deben validar datos.

Escenarios de pruebas Criterios de aceptación

Identificador

1

Contexto

Evento el

Resultado

En caso de que se dejen en

Cuando

súper-

blanco el campo de registro

admin/admin pulse el

El sistema no procederá con el ingreso de datos.

botón guardar

2

En caso que se escriba el

Cuando

súper-

El sistema validará los

mismo

admin/admin pulse el

datos e informará del

botón guardar

error asociado.

nombre

marca ingresada

de

una

el

106

Historia de Usuario Identificador: 010

Nombre: Modificación de Marcas

Prioridad: Medio

Iteración: 2

Riesgo en desarrollo: Bajo

Estimación: 3

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador

Quiero poder modificar las

Para actualizar la información de

administrador

marcas ingresadas.

la marca del dispositivo

Observación: se debe informar del cambio realizado por medio de notificaciones. Se deben validar datos.

Escenarios de pruebas Identificador

1

2

Criterios de aceptación Contexto En caso de que se dejen en blanco el campo de edición

En caso que se registre una marca ya existente

Evento Cuando

el

Resultado súper-

El

sistema

notificará

admin/admin pulse el

informando que se llene

botón guardar

el campo

Cuando

el

súper-

El sistema no guardará

admin/admin pulse el

los datos registrados e

botón guardar

informará del error.

107

Historia de Usuario Identificador: 011

Nombre: Registro de Sistemas Operativos

Prioridad: Medio

Iteración: 2

Riesgo en desarrollo: Bajo

Estimación: 5

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder ingresar tipos de

Para identificar el sistema

administrador

sistemas operativos

operativo de cierto dispositivo

Observación: Al finalizar el ingreso se debe mostrar una notificación informando del registro. Se deben validar datos.

Escenarios de pruebas Criterios de aceptación

Identificador

1

Contexto

Evento el

Resultado

En caso de que se dejen en

Cuando

súper-

blanco el campo de registro

admin/admin pulse el

El sistema no procederá con el ingreso de datos.

botón guardar

Historia de Usuario Identificador: 012

Nombre: Modificación de sistemas operativos

Prioridad: Medio

Iteración: 2

Riesgo en desarrollo: Bajo

Estimación: 3

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador

Quiero poder modificar los

Para actualizar la información de

administrador

sistemas operativos ingresados

los sistemas de un dispositivo.

Observación: se debe informar del cambio realizado por medio de notificaciones. Se deben validar datos.

Escenarios de pruebas Identificador

1

Criterios de aceptación Contexto En caso de que se dejen en blanco el campo de edición

Evento Cuando

el

Resultado súper-

El

sistema

notificará

admin/admin pulse el

informando que se llene

botón guardar

el campo

108

Historia de Usuario Identificador: 013

Nombre: Reporte de Agencias

Prioridad: Alto

Iteración: 3

Riesgo en desarrollo: Medio

Estimación: 5

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder generar un reporte

Para identificar las agencias que

administrador

de las agencias

están registradas en el sistema

Observación: el reporte debe ser generado en pdf

Escenarios de pruebas Criterios de aceptación

Identificador

Contexto

Evento

En caso de solicitar un

1

reporte de las agencias

Cuando

el

Resultado súper-

El sistema abrirá una

admin/admin pulse el

pestaña nueva con el

botón Imprimir

reporte generado.

Historia de Usuario Identificador: 014

Nombre: Reporte de Áreas

Prioridad: Alto

Iteración: 3

Riesgo en desarrollo: Medio

Estimación: 5

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder generar un reporte

Para identificar las áreas de las

administrador

de las áreas

agencias registradas

Observación: el reporte debe ser generado en pdf

Escenarios de pruebas Identificador

1

Criterios de aceptación Contexto En caso de solicitar un reporte de áreas

Evento Cuando

el

Resultado súper-

El sistema abrirá una

admin/admin pulse el

pestaña nueva con el

botón Imprimir

reporte generado.

109

Historia de Usuario Identificador: 015

Nombre: Reporte de Departamentos

Prioridad: Alto

Iteración: 3

Riesgo en desarrollo: Medio

Estimación: 5

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder generar un reporte

administrador

de Departamentos

Para identificar los departamentos de las agencias ingresadas

Observación: el reporte debe ser generado en pdf

Escenarios de pruebas Criterios de aceptación

Identificador

Contexto

Evento

En caso de solicitar un

1

reporte de departamentos

Cuando

el

Resultado súper-

El sistema abrirá una

admin/admin pulse el

pestaña nueva con el

botón Imprimir

reporte generado.

Historia de Usuario Identificador: 016

Nombre: Reporte de Marcas

Prioridad: Alto

Iteración: 3

Riesgo en desarrollo: Medio

Estimación: 5

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder generar un reporte

Para identificar las marcas de los

administrador

de las Marcas

dispositivos ingresados

Observación: el reporte debe ser generado en pdf

Escenarios de pruebas Identificador

1

Criterios de aceptación Contexto En caso de solicitar un reporte de marcas

Evento Cuando

el

Resultado súper-

El sistema abrirá una

admin/admin pulse el

pestaña nueva con el

botón Imprimir

reporte generado.

110

Historia de Usuario Identificador: 017

Nombre: Reporte de Sistemas Operativos

Prioridad: Alto

Iteración: 3

Riesgo en desarrollo: Medio

Estimación: 5

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder generar un reporte

administrador

de los sistemas operativos

Para identificar los diferentes sistemas operativos que poseen los dispositivos registrados

Observación: el reporte debe ser generado en pdf

Escenarios de pruebas Criterios de aceptación

Identificador

1

Contexto

Evento

En caso de solicitar un

Cuando

súper-

El sistema abrirá una

reporte

admin/admin pulse el

pestaña nueva con el

botón Imprimir

reporte generado.

operativos

de

sistemas

el

Resultado

111

Historia de Usuario Identificador: 018

Nombre: Registro de Dispositivos

Prioridad: Alta

Iteración: 4

Riesgo en desarrollo: Alto

Estimación: 8

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder registrar los

Para almacenar y administrar la

administrador

dispositivos en el sistema

información de los mismos

Como súper-administrador y

Quiero poder registrar las

Para poder clasificar y ordenar

administrador

categorías de los dispositivos

los dispositivos en el sistema

Observación: Al finalizar el ingreso se debe mostrar una notificación informando del registro. Se deben validar datos. Debe permitir seleccionar un icono para cada categoría.

Escenarios de pruebas Criterios de aceptación

Identificador

1

2

3

Contexto

Evento el

Resultado

En caso de que se dejen en

Cuando

blanco el campo de registro

admin/admin pulse el

de categoría

botón guardar

En caso de no recordar o

Cuando

súper-

El sistema mostrará una

saber el tipo de categoría

admin/admin pulse el

ventana modal con un

botón “tipos”

resumen de los tipos

el

el

súper-

súper-

ninguna categoría.

En caso de dejar en blanco

Cuando

los campos obligatorios del

admin/admin pulse el

con

formulario de registro de

botón de guardar

informará

dispositivo

4

El sistema no guardará

El sistema no procederá el

ingreso del

e

error

asociado

En caso de querer subir un

Cuando

archivo

admin/admin presione el

explorador de archivos

botón “subir archivo”

para

asociado

dispositivo a registrar

al

el

súper-

El

sistema

archivo

abrirá

seleccionar

el

el

112

Historia de Usuario Identificador: 019

Nombre: Modificación de Dispositivos

Prioridad: Alta

Iteración: 4

Riesgo en desarrollo: Medio

Estimación: 5

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder modificar los

Para actualizar la información de

administrador

dispositivos registrados

referente a los mismos

Como súper-administrador y

Quiero poder modificar las

Para poder actualizar la

administrador

categorías de los dispositivos

información en el sistema

Observación: se debe informar del cambio realizado por medio de notificaciones. Se deben validar datos.

Escenarios de pruebas Criterios de aceptación

Identificador

1

2

Contexto

Evento el

Resultado

En caso de que se dejen en

Cuando

súper-

El sistema avisará que se

blanco el campo de edición

admin/admin pulse el

llenen los campos y

de categoría

botón guardar

notificará del error.

En caso de registrar una

Cuando

categoría ya existente

admin/admin pulse el

el

súper-

El sistema notificará del error asociado

botón “guardar”

3

En caso de dejar en blanco

Cuando

el

súper-

El sistema no procederá

los campos obligatorios del

admin/admin pulse el

con la acción e informará

formulario de edición de

botón de guardar

del error asociado

dispositivo En 4

caso

dispositivo (códigos)

registrar ya

un

existente

Cuando

el

súper-

admin/admin presione el botón “subir archivo”

El sistema notificará del suceso

113

Historia de Usuario Identificador: 020

Nombre: Reporte de Dispositivos

Prioridad: Alto

Iteración: 4

Riesgo en desarrollo: Medio

Estimación: 5

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder generar un reporte

Para poder visualizar cuantos

administrador

de los dispositivos ingresados

dispositivos están registrados

Observación: el reporte debe ser generado en pdf

Escenarios de pruebas Identificador

1

Criterios de aceptación Contexto En caso de solicitar un reporte de dispositivos

Evento Cuando

el

Resultado súper-

El sistema abrirá una

admin/admin pulse el

pestaña nueva con el

botón Imprimir

reporte generado.

114

Historia de Usuario Identificador: 021

Nombre: Consulta de Dispositivos

Prioridad: Alta

Iteración: 4

Riesgo en desarrollo: Medio

Estimación: 5

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador,

Quiero poder consultar los

administrador y usuario

dispositivos registrados

Como súper-administrador,

Quiero poder observar la consulta

Para observar la información

administrador y usuario

en una tabla modificable

según las necesidades requeridas

Para poder tener un fácil acceso

Observación: la consulta debe permitir realizarse de forma intuitiva. Debe facilitar la modificación de la tabla y el número de registro visibles.

Escenarios de pruebas Criterios de aceptación

Identificador

1

Contexto

Evento

Resultado

En caso de ingresar un

Cuando el súper-

El sistema realizará la

código, nombre, o algún

admin/admin/user

búsqueda

parámetro

cambie de campo

filtrando los datos según

asociado

al

dispositivo en la caja de

respectiva

lo ingresado.

texto

2

En caso de ingresar datos

Cuando el súper-

El sistema validará los

basura en la caja de texto

admin/admin/user

datos

cambie de campo

informará que no halló

ingresados

una búsqueda exitosa

e

115

Historia de Usuario Identificador: 022

Nombre: Reporte de la consulta

Prioridad: Alto

Iteración: 5

Riesgo en desarrollo: Alto

Estimación: 8

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador,

Quiero poder generar un reporte

Para poder imprimirla y

administrador y usuario

de la consulta realizada

visualizarla posteriormente

Observación: se debe permitir seleccionar los aspectos que contendrá el reporte. Se debe generar un pdf

Escenarios de pruebas Identificador

1

Criterios de aceptación Contexto En caso de solicitar un reporte de la consulta

Evento Cuando

súper-

El sistema abrirá una

admin/admin/user pulse

pestaña nueva con el

el botón Imprimir

reporte generado.

Cuando 2

el

Resultado

el

súper-

En caso de solicitar un

admin/admin/user pulse

reporte parametrizado

el

botón

Visibles”

“Columnas

El sistema mostrara una ventana

flotante

y

permitirá seleccionar los aspectos que se desea visualizar en el reporte

116

Historia de Usuario Identificador: 023

Nombre: Registro de Mantenimientos

Prioridad: Alta

Iteración: 5

Riesgo en desarrollo: Alto

Estimación: 8

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder registrar el

administrador

mantenimiento de un dispositivo

Como súper-administrador y

Quiero poder ingresar los detalles

Para poseer mayor información

administrador

del mantenimiento

respecto al mismo

Para que quede registrado y almacenado el mantenimiento que se ha realizado

Observación: debe permitir escoger el tipo de mantenimiento (correctivo-preventivo). La fecha del mantenimiento se debe ingresar automáticamente.

Escenarios de pruebas Criterios de aceptación

Identificador

1

2

Contexto

Evento

En caso de que se dejen en

Cuando

súper-

El sistema informará que

blanco

admin/admin pulse el

se rellenen los campos

registro de mantenimientos

botón guardar

correspondientes

En caso de que se dejen en

Cuando

blanco

los

campos

admin/admin pulse el

ningún

registro

de

detalles del

botón “guardar”

mantenimiento

los

campos

de

de

el

Resultado

el

súper-

mantenimientos

3

El sistema no guardará detalle

del

ingresado

En caso de registrar el

Cuando

súper-

El sistema de forma

mantenimiento

admin/admin pulse el

automática asignará la

botón de guardar

fecha del día de registro

detalles del mismo

y

los

el

y su estado

117

Historia de Usuario Identificador: 024

Nombre: Modificación de Mantenimientos

Prioridad: Medio

Iteración: 5

Riesgo en desarrollo: Medio

Estimación: 5

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador y

Quiero poder modificar el

Para actualizar la información

administrador

mantenimiento

respecto del mismo

Como súper-administrador y

Quiero poder modificar los

Para actualizar la información del

administrador

detalles del mantenimiento

mantenimiento

Observación: se debe notificar de los cambios realizados.

Escenarios de pruebas Criterios de aceptación

Identificador

1

2

Contexto

Evento

En caso de que se dejen en

Cuando

súper-

El sistema informará que

blanco

admin/admin pulse el

se rellenen los campos

edición de mantenimientos

botón guardar

correspondientes

En caso de que se dejen en

Cuando

blanco

los

campos

de

admin/admin pulse el

ningún

edición

de

detalles

del

botón “guardar”

mantenimiento editado

los

campos

mantenimientos

de

el

Resultado

el

súper-

El sistema no guardará detalle

del

118

Historia de Usuario Identificador: 025

Nombre: Reporte del mantenimiento

Prioridad: Alto

Iteración: 6

Riesgo en desarrollo: Alto

Estimación: 8

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador,

Quiero poder generar un reporte

administrador

de los mantenimientos realizados

Para poder visualizar los mantenimientos y a que equipos se los ha realizado

Observación: Se debe generar un informe pdf

Escenarios de pruebas Criterios de aceptación

Identificador

Contexto

Evento

En caso de solicitar un

1

reporte de mantenimientos

Cuando

el

Resultado súper-

El sistema abrirá una

admin/admin/user pulse

pestaña nueva con el

el botón Imprimir

reporte generado.

Historia de Usuario Identificador: 026

Nombre: Cambio de estado del mantenimiento

Prioridad: Medio

Iteración: 6

Riesgo en desarrollo: Medio

Estimación: 5

Desarrolladores Responsables: Guillermo Barcia – Nólvar Gómez Rol

Funcionalidad

Razón

Como súper-administrador,

Quiero poder cambiar el estado

Para poder dar por finalizado un

administrador

del mantenimiento

mantenimiento determinado

Observación: debe permitir administrar archivos. El estado debe cambiar de forma automática

Escenarios de pruebas Identificador

1

Criterios de aceptación Contexto

En caso de querer cambiar el estado del mantenimiento

Evento Cuando

el

Resultado súper-

admin/admin/user pulse el botón “Subir Archivo”

El sistema luego de permitir la subida del archivo respectivo, el estado cambiará.

119

Anexo 8: Diccionario de datos

Tabla: DISINF - Información del dispositivo Atributos Not PK FK Null Si Si No Si No No

Nombre

Tipo

DISPID DIACTI

INT TINYINT(1)

DIMODE

VARCHAR(20)

Si

No

No

DISERI DIESTA

VARCHAR(30) VARCHAR(10)

Si Si

No No

No No

DIVERI

VARCHAR(15)

Si

No

No

DIUSRE

VARCHAR(45)

Si

No

No

DIFERE DIOBSE DICDGA

DATETIME VARCHAR(180) DATE

No No No

No No No

No No No

FKDTDI

INT

Si

No

Si

FKMADI

INT

Si

No

Si

FKDEDI

INT

Si

No

Si

FKAGDI

INT

Si

No

Si

FKARDI

INT

Si

No

Si

FKCODI

INT

Si

No

Si

Default

true

bueno

Significado Id estado del dispositivo activo/inactivo Modelo del dispositivo Número de serie Estado bueno/malo/regul ar verificado por (persona o departamento que verifica el equipo) usuario del sistema que registro el dispositivo fecha de registro observaciones fecha de caducidad de la garantía llave foránea con la taba de tipo de dispositivo llave foránea con la taba de marcas llave foránea con la taba de departamentos llave foránea con la taba agencias llave foránea con la taba areas llave foránea con la taba de códigos

120

Tabla: MNTDEQ - Mantenimiento del dispositivo Atributos Not PK Null Si Si Si No

Nombre

Tipo

FK

MANTID MNPEEN

INT VARCHAR(45)

MNPERE

VARCHAR(45)

Si

No

No

MNCLAV

VARCHAR(15)

No

No

No

MNUSRE

VARCHAR(45)

Si

No

No

MNFEIN

DATETIME

Si

No

No

MNFESA

VARCHAR(45)

No

No

No

MNESTA

VARCHAR(15)

No

No

No

FKDIMN

INT

Si

No

Si

No No

Default

Significado Id persona que entrega el dispositivo persona que recibe clave del equipo usuario del dispositivo fecha de ingreso del dispositivo fecha de salida del dispositivo estado del mantenimiento llave forรกnea con la tabla de dispositivos

121

Tabla: RDUTSS - Usuarios Nombre

Tipo

RDIDEN RDUNO M RDUAPE

INT VARCHAR(25 ) VARCHAR(25 ) VARCHAR(50 ) VARCHAR(60 ) VARCHAR(25 )

RDUSUA RDPASS RDROLU

RDACTI

TINYINT(1)

Atributos Not PK FK Null Si Si No Si No No Si

No

No

Si

No

No

Si

No

No

No

No

No

Si

No

No

Default

Significado Id Nombres del usuario Apellidos del usuario nombre de la cuenta password

false

rol del usuario (usuario,administra dor o super administrador) campo de usuario activo o inactivo

Tabla: AUDTAB - Auditoría Atributos Not PK FK Default Null Si Si No Si No No

Nombre

Tipo

AUTAID AUUSID

INT INT

AUTBID

INT

Si

No

No

AUACCT

VARCHAR(11)

Si

No

No

AUCAMT

VARCHAR(6)

Si

No

No

AUCAAT VARCHAR(45) AUCANU VARCHAR(45) AUFERE DATETIME(0)

Si Si Si

No No No

No No No

Significado Id id del usuario que modifica la Tabla id de la fila de la Tabla audiatada acción que se realiza en la Tabla campo que se modifica en la Tabla campo anterior campo nuevo fecha de registro

122

Tabla: CODIEQ - Códigos del equipo Nombre

Tipo

INT CODIID COCNEL VARCHAR(20) COUSUA VARCHAR(20) COCCOM VARCHAR(20) COPROV

VARCHAR(20)

Atributos Not PK FK Default Null Si Si No Si No No Si No No Si No No Si

No

No

Significado Id código CNEL código de usuario código de centro de computo código de Acúrio

Tabla: DISPOS - Tipos de dispositivos Atributos Nombre

Tipo

Not Null

PK FK Default

Significado

DSPSID

INT

Si

Si

No

Id

DSNOMB VARCHAR(25)

Si

No

No

nombre del dispositivo

DSINIC

VARCHAR(3)

Si

No

No

iniciales del nombre

DSACTI

TINYINT(1)

Si

No

No

activo true/false

DSTIPO

INT

Si

No

No

tipo de dispositivo

DSIURL

VARCHAR(50)

No

No

No

ruta del icono del dispositivo

123

Tabla: DOCCSS - Documentos pdf de los dispositivos Nombre

Tipo

INT DOCCID TINYINT(1) DOCACT DOCNOM VARCHAR(25) INT FKDODI

Atributos Not PK FK Default Null Si Si No Si No No Si No No Si No Si

Significado Id activo true/false nombre del documento llave forรกnea con la Tabla de dispositivo

Tabla: DOCMAN - Documentos pdf de los mantenimientos Nombre

Tipo

DOMCID DOMACT DOMNOM

INT TINYINT(1) VARCHAR(25)

FKDIMT

INT

Atributos Not PK Null Si Si Si No Si No Si

No

FK No No No Si

Default

Significado Id activo true/false nombre del documento llave forรกnea con la Tabla de mantenimientos

124

Tabla: D4COMP - Datos complementarios de informacion del dispositivo Atributos Nombre

Tipo

Not Null

D4OMID

INT

Si

Si

No

id

D4PROC

VARCHAR(50)

No

No

No

procesador

D4NUCL

INT

No

No

No

número de núcleos del procesador

D4CRAM VARCHAR(10)

No

No

No

D4DLAM VARCHAR(20)

No

No

No

capacidad de memoria ram almacenamiento del disco

VARCHAR(45)

No

No

No

navegador firefox

D4NACH VARCHAR(45)

No

No

No

navegador chrome

D4NAEX

VARCHAR(45)

No

No

No

navegador explorer

FKCPD4

INT

Si

No

Si

llave foránea con la Tabla complementaria de dispositivo

D4NAFI

PK FK Default

Significado

Tabla: MARTAB - Marcas de los dispositivos Nombre

Tipo

INT MARTID MANOMB VARCHAR(45) TINYINT(1) MAACTI

Atributos Not PK FK Default Null Si Si No Si No No Si No No true

Significado Id nombre de la marca estado de la marca activo/inactivo

125

Tabla: DEPART - Departamento Nombre

Tipo

INT DEPAID DENOMB VARCHAR(45) TINYINT(1) DEACTI

Atributos Not PK FK Default Null Si Si No Si No No Si No No true

Significado Id nombre de departamento estado del departamento activo/inactivo

Tabla: AGENCI - Agencias Nombre

Tipo

INT AGENID AGNOMB VARCHAR(45) TINYINT(1) AGACTI

Atributos Not PK FK Default Null Si Si No Si No No Si No No true

Significado Id nombre de la agencia estado de la agencia activo/inactivo

Tabla: AREADI - ร rea de la empresa Nombre

Tipo

INT AREAID ARNOMB VARCHAR(45) TINYINT(1) ARACTI

Atributos Not PK FK Default Null Si Si No Si No No Si No No true

Significado Id nombre del รกrea estado del รกrea activo/inactivo

Tabla: SISOPE - Sistemas operativos Nombre

Tipo

INT SISOID SIOPER VARCHAR(45) SIACTI

TINYINT(1)

Not Null Si Si Si

Atributos PK FK Default Si No

No No

No

No

true

Significado Id nombre del sistema operativo estado del sistema operativo activo/inactivo

126

Tabla: DICOMP - Tabla de datos complementarios de información del dispositivo Nombre

Tipo

INT DCOMID DCTLIP VARCHAR(19) DCDOMI VARCHAR(25)

Not Null Si No No

DCEXTE VARCHAR(17) INT FKDICP

No Si

Atributos PK FK Default Si No No

No No No

No No

No Si

Significado id ip del dispositivo nombre del dispositivo en el dominio de red extensión del teléfono llave foránea con la Tabla de dispositivos

Tabla: MNTDET - Tabla DE DETALLE DE MANTENIMIENTO Nombre

Tipo

MDNTID MDUSRE MDFEDE

INT VARCHAR(45) DATETIME

MDOBSE VARCHAR(256) MDESMA VARCHAR(15) VARCHAR(45) MDUSSI INT FKMDMQ

Atributos Not PK FK Default Null Si Si No Si No No No No No

No No No Si

No No No No

No No No Si

Significado Id usuario que registra fecha de creacion del registro del detalle de mantenimiento observaciones estado de mantenimiento usuario del sistema llave foránea con la Tabla de mantenimientos

127

Anexo 9: Script de la Base de Datos drop table ADMTIC.AGENAU CREATE TABLE ADMTIC.AGENAU ( AGENID INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, AGACTI SMALLINT, AGNOMB VARCHAR(45), PRIMARY KEY (AGENID)); ALTER TABLE ADMTIC.AGENAU ADD FOREIGN KEY (REV) REFERENCES ADMTIC.USSGAU (ID);

drop table ADMTIC.AREAUA CREATE TABLE ADMTIC.AREAUA ( AREAID INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, ARACTI SMALLINT, ARNOMB VARCHAR(45), PRIMARY KEY (AREAID)); ALTER TABLE ADMTIC.AREAUA ADD FOREIGN KEY (REV) REFERENCES S103A1CR.ADMTIC.USSGAU (ID); drop table ADMTIC.CODIAU CREATE TABLE ADMTIC.CODIAU ( CODIID INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, COACUR VARCHAR(20), COCNEL VARCHAR(20), COCCOM VARCHAR(20), COPROV VARCHAR(20), COUSUA VARCHAR(255), PRIMARY KEY (CODIID)); ALTER TABLE ADMTIC.CODIAU ADD FOREIGN KEY (REV) REFERENCES S103A1CR.ADMTIC.USSGAU (ID); drop table ADMTIC.D4COAU CREATE TABLE ADMTIC.D4COAU ( D4OMID INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, D4NACH VARCHAR(45), D4DLAM VARCHAR(20), D4NAEX VARCHAR(45), D4NAFI VARCHAR(45), D4NUCL SMALLINT, D4PROC VARCHAR(50), D4CRAM VARCHAR(10), FKCPD4 INTEGER,

SISOPE INTEGER, PRIMARY KEY (D4OMID)); ALTER TABLE ADMTIC.D4COAU ADD FOREIGN KEY (REV) REFERENCES S103A1CR.ADMTIC.USSGAU (ID); drop table ADMTIC.DEPAAU CREATE TABLE ADMTIC.DEPAAU ( DEPAID INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, DEACTI SMALLINT, DENOMB VARCHAR(45), PRIMARY KEY (DEPAID)); ALTER TABLE ADMTIC.DEPAAU ADD FOREIGN KEY (REV) REFERENCES S103A1CR.ADMTIC.USSGAU (ID); drop table ADMTIC.DICOAU CREATE TABLE ADMTIC.DICOAU ( DCOMID INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, DCDOMI VARCHAR(25), DCEXTE VARCHAR(17), DCTLIP VARCHAR(19), FKDICP INTEGER, PRIMARY KEY (DCOMID,REV)); ALTER TABLE ADMTIC.DICOAU ADD FOREIGN KEY (REV) REFERENCES S103A1CR.ADMTIC.USSGAU (ID); drop table ADMTIC.DICOMP CREATE TABLE ADMTIC.DICOMP ( DCOMID INTEGER NOT NULL, DCDOMI VARCHAR(25), DCEXTE VARCHAR(17), DCTLIP VARCHAR(19), FKDICP INTEGER, PRIMARY KEY (DCOMID) ); ALTER TABLE ADMTIC.DICOMP ADD FOREIGN KEY (FKDICP) REFERENCES S103A1CR.ADMTIC.DISINF (DISPID); drop table ADMTIC.DISIAU CREATE TABLE ADMTIC.DISIAU ( DISPID INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, DICDGA VARCHAR(10),

128 DIACTI SMALLINT, DIESTA VARCHAR(10), DIMODE VARCHAR(20), DIOBSE VARCHAR(255), DISERI VARCHAR(30), DIUSRE VARCHAR(45), DIVERI VARCHAR(15), DIFERE VARCHAR(10), PRIMARY KEY (DISPID) ); ALTER TABLE ADMTIC.DISIAU ADD FOREIGN KEY (REV) REFERENCES S103A1CR.ADMTIC.USSGAU (ID); drop table ADMTIC.DISINF CREATE TABLE ADMTIC.DISINF ( DISPID INTEGER NOT NULL, DICDGA VARCHAR(10), DIACTI SMALLINT, DIESTA VARCHAR(10), DIMODE VARCHAR(20) NOT NULL, DIOBSE VARCHAR(255), DISERI VARCHAR(30) NOT NULL, DIUSRE VARCHAR(45), DIVERI VARCHAR(15) NOT NULL, DIFERE VARCHAR(10), FKDTDI INTEGER CONSTRAINT ADMTIC.DISINF_fk_DISINF_DISPOS1 REFERENCES ADMTIC.DISPOS (DSPSID) ON DELETE NO ACTION ON UPDATE NO ACTION, FKMADI INTEGER CONSTRAINT ADMTIC.DISINF_fk_DISINF_MARTAB1 REFERENCES ADMTIC.MARTAB (MARTID) ON DELETE NO ACTION ON UPDATE NO ACTION, FKDEDI INTEGER CONSTRAINT ADMTIC.DISINF_fk_DISINF_DEPART1 REFERENCES ADMTIC.DEPART (DEPAID) ON DELETE NO ACTION ON UPDATE NO ACTION, FKAGDI INTEGER CONSTRAINT ADMTIC.DISINF_fk_DISINF_AGENCI1 REFERENCES ADMTIC.AGENCI (AGENID) ON DELETE NO ACTION ON UPDATE NO ACTION, FKARDI INTEGER CONSTRAINT ADMTIC.DISINF_fk_DISINF_AREADI1 REFERENCES ADMTIC.AREADI (AREAID) ON DELETE NO ACTION ON UPDATE NO ACTION, FKCODI INTEGER CONSTRAINT ADMTIC.DISINF_fk_DISINF_CODIEQ1 REFERENCES ADMTIC.CODIEQ (CODIID) ON DELETE NO ACTION ON UPDATE NO ACTION, FKSIDI INTEGER CONSTRAINT ADMTIC.DISINF_fk_DISINF_SISOPE1

REFERENCES ADMTIC.SISOPE (SISOID) ON DELETE NO ACTION ON UPDATE NO ACTION, PRIMARY KEY (DISPID));

drop table ADMTIC.DISPAU CREATE TABLE ADMTIC.DISPAU ( DSPSID INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, DSACTI SMALLINT, DSIURL VARCHAR(50), DSNOMB VARCHAR(25), DSTIPO SMALLINT, DSINIC VARCHAR(3), PRIMARY KEY (DSPSID) ); ALTER TABLE ADMTIC.DISPAU ADD FOREIGN KEY (REV) REFERENCES S103A1CR.ADMTIC.USSGAU (ID); -------------------------------------------documentos de dispositivo drop table ADMTIC.DOCCSS CREATE TABLE ADMTIC.DOCCSS ( DOCCID INTEGER NOT NULL, DOCACT SMALLINT, DOCNOM VARCHAR(25), FKDODI INTEGER CONSTRAINT ADMTIC.DOCCSS_fk_DOCCSS_DISINF1 REFERENCES ADMTIC.DISINF (DISPID) ON DELETE NO ACTION ON UPDATE NO ACTION, PRIMARY KEY (DOCCID) );

//-------------------------------------auditoria documentos drop table ADMTIC.DOCCUA CREATE TABLE ADMTIC.DOCCUA ( DOCCID INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, DOCACT SMALLINT, DOCNOM VARCHAR(25), FKDODI INTEGER, PRIMARY KEY (DOCCID) ); ALTER TABLE ADMTIC.DOCCUA ADD FOREIGN KEY (REV) REFERENCES S103A1CR.ADMTIC.USSGAU (ID); //-------------------------------------auditoria documentos detalles de mantenimientos

129

drop table ADMTIC.DOCDTA CREATE TABLE ADMTIC.DOCDTA ( DOCDID INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, DOCACT SMALLINT, DOCNOM VARCHAR(25) PRIMARY KEY (DOCDID) ); ALTER TABLE ADMTIC.DOCDTA ADD FOREIGN KEY (REV) REFERENCES S103A1CR.ADMTIC.USSGAU (ID); //-------------------------------------documentos detalles de mantenimientos drop table ADMTIC.DOCDTM CREATE TABLE ADMTIC.DOCDTM ( DOCDID INTEGER NOT NULL, DOCACT SMALLINT, DOCNOM VARCHAR(25), FKMDDD INTEGER CONSTRAINT ADMTIC.DOCDTM_fk_DOCDTM_MNTDET1 REFERENCES ADMTIC.MNTDET (MDNTID) ON DELETE NO ACTION ON UPDATE NO ACTION, PRIMARY KEY (DOCDID) ); //--------------------------------auditoria de documentos drop table ADMTIC.DOCMAA CREATE TABLE ADMTIC.DOCMAA ( DOCCID INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, DOCACT SMALLINT, DOCNOM VARCHAR(25), FKDIMT INTEGER, PRIMARY KEY (DOCCID,REV) ); ALTER TABLE ADMTIC.DOCMAA ADD FOREIGN KEY (REV) REFERENCES S103A1CR.ADMTIC.USSGAU (ID); //-------------------------------documentos de mantenimiento drop table ADMTIC.DOCMAN CREATE TABLE ADMTIC.DOCMAN ( DOCCID INTEGER NOT NULL, DOCACT SMALLINT, DOCNOM VARCHAR(25), FKDIMT INTEGER CONSTRAINT ADMTIC.DOCMAN_fk_DOCMAN_MNTDEQ1

REFERENCES ADMTIC.MNTDEQ (MANTID) ON DELETE NO ACTION ON UPDATE NO ACTION, PRIMARY KEY (DOCCID) ); //-----------------------------auditoria de marcas drop table ADMTIC.MARTAU CREATE TABLE ADMTIC.MARTAU ( MARTID INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, MAACTI SMALLINT, MANOMB VARCHAR(45), PRIMARY KEY (MARTID,REV) ); ALTER TABLE ADMTIC.MARTAU ADD FOREIGN KEY (REV) REFERENCES S103A1CR.ADMTIC.USSGAU (ID); //-----------------------------auditoria mantenimiento detalle drop table ADMTIC.MNTDAU CREATE TABLE ADMTIC.MNTDAU ( MANTID INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, MNCLAV VARCHAR(15), MNESTA VARCHAR(15), MNFEIN VARCHAR(19), MNFESA VARCHAR(19), MNOBSE VARCHAR(255), MNPEEN VARCHAR(45), MNPERE VARCHAR(45), MNTIPO VARCHAR(10), MNUSRE VARCHAR(45), FKDIMN INTEGER, PRIMARY KEY (MANTID) ); ALTER TABLE ADMTIC.MNTDAU ADD FOREIGN KEY (REV) REFERENCES S103A1CR.ADMTIC.USSGAU (ID); //----------------------------- mantenimiento drop table ADMTIC.MNTDEQ CREATE TABLE ADMTIC.MNTDEQ ( MANTID INTEGER NOT NULL, MNCLAV VARCHAR(15), MNESTA VARCHAR(15), MNFEIN VARCHAR(19), MNFESA VARCHAR(19), MNOBSE VARCHAR(255), MNPEEN VARCHAR(45) NOT NULL, MNPERE VARCHAR(45),

130 MNTIPO VARCHAR(10), MNUSRE VARCHAR(45), FKDIMN INTEGER CONSTRAINT ADMTIC.MNTDEQ_fk_MNTDEQ_DISINF1 REFERENCES ADMTIC.DISINF (DISPID) ON DELETE NO ACTION ON UPDATE NO ACTION, PRIMARY KEY (MANTID) ); //----------------------------- mantenimiento detalle drop table ADMTIC.MNTDET CREATE TABLE ADMTIC.MNTDET ( MDNTID INTEGER NOT NULL, MDUSSI VARCHAR(45), MDFEDE VARCHAR(45), MDOBSE VARCHAR(255), MNUSSI VARCHAR(45), FKMDMQ INTEGER CONSTRAINT ADMTIC.MNTDET_fk_MNTDET_MNTDEQ1 REFERENCES ADMTIC.MNTDEQ (MANTID) ON DELETE NO ACTION ON UPDATE NO ACTION, PRIMARY KEY (MDNTID) ); //-----------------------------auditoria mantenimiento detalle drop table ADMTIC.MNTDEU CREATE TABLE ADMTIC.MNTDEU ( MDNTID INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, MDUSSI VARCHAR(45), MDFEDE VARCHAR(45), MDOBSE VARCHAR(255), MNUSSI VARCHAR(45), FKMDMQ INTEGER, PRIMARY KEY (MDNTID) ); ALTER TABLE ADMTIC.MNTDEU ADD FOREIGN KEY (REV) REFERENCES S103A1CR.ADMTIC.USSGAU (ID); //-----------------------------auditoria usuarios drop table ADMTIC.RDUTAU CREATE TABLE ADMTIC.RDUTAU ( RDIDEN INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, RDACTI SMALLINT, RDUAPE VARCHAR(25), RDUSUA VARCHAR(50), RDUNOM VARCHAR(25), RDPASS VARCHAR(60),

RDROLU VARCHAR(25), PRIMARY KEY (RDIDEN) ); ALTER TABLE ADMTIC.RDUTAU ADD FOREIGN KEY (REV) REFERENCES S103A1CR.ADMTIC.USSGAU (ID); //----------------------------- usuarios CREATE TABLE ADMTIC.RDUTSS ( RDIDEN INTEGER NOT NULL, RDACTI SMALLINT, RDUAPE VARCHAR(25) NOT NULL, RDUSUA VARCHAR(50) NOT NULL, RDUNOM VARCHAR(25) NOT NULL, RDPASS VARCHAR(60) NOT NULL, RDROLU VARCHAR(25), PRIMARY KEY (RDIDEN) ); //----------------------------- auditoria sistemas operativos drop table ADMTIC.SISOAU CREATE TABLE ADMTIC.SISOAU ( SISOID INTEGER NOT NULL, REV INTEGER NOT NULL, REVTYPE SMALLINT, SIACTI SMALLINT, SIOPER VARCHAR(25), PRIMARY KEY (SISOID) ); ALTER TABLE ADMTIC.SISOAU ADD FOREIGN KEY (REV) REFERENCES S103A1CR.ADMTIC.USSGAU (ID);

//----------------------------- sistemas operativos CREATE TABLE ADMTIC.SISOPE ( SISOID INTEGER NOT NULL, SIACTI SMALLINT, SIOPER VARCHAR(25) NOT NULL, PRIMARY KEY (SISOID) ); //----------------------------- usuarios en la tabla de auditora tabla master

CREATE TABLE ADMTIC.USSGAU ( ID INTEGER NOT NULL, TIMESTAMP BIGINT NOT NULL, USERNAME VARCHAR(45), PRIMARY KEY (ID));

131