Sistema web para la gestión de bienes informáticos y asistencia técnica en el departamento de Tics

Page 1

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica – Escuela de Sistemas

SISTEMA WEB PARA LA GESTIÓN DE BIENES INFORMÁTICOS Y ASISTENCIA TÉCNICA EN EL DEPARTAMENTO DE TICS DEL MINISTERIO DE INCLUSIÓN ECONÓMICA Y SOCIAL DE 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 Ingenieras en Sistemas y Computación

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

Autoras: BELLA GARDENIA CALLE PINOS JAZMIN ALEJANDRA GAIBOR GORDÓN

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 LA GESTIÓN DE BIENES INFORMÁTICOS Y ASISTENCIA TÉCNICA EN EL DEPARTAMENTO DE TICS DEL MINISTERIO DE INCLUSIÓN ECONÓMICA Y SOCIAL DE 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 Autoras: BELLA GARDENIA CALLE PINOS JAZMIN ALEJANDRA GAIBOR GORDÓN

Rodolfo Sirilo Córdova Gálvez, Mg.

f. ___________________________

DIRECTOR DEL TRABAJO DE TITULACIÓN

William Javier Ocampo Pazos, 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 Nosotras, Bella Gardenia Calle Pinos y Jazmín Alejandra Gaibor Gordón portadoras de la cédula de ciudadanía No. 175125292-3 y No. 230023573-2 declaramos que los resultados obtenidos en la investigación que presentamos como informe final, previo la obtención del Grado Ingenieras en Sistemas y Computación son absolutamente originales, auténticos y personales. En tal virtud, declaramos 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 nuestra sola y exclusiva responsabilidad legal y académica.

Bella Gardenia Calle Pinos C.I. 175125292-3

Jazmín Alejandra Gaibor Gordón C.I. 230023573-2


iv

AGRADECIMIENTO A Dios Todopoderoso por permitirnos el logro de este éxito personal y darnos vida, salud, y entendimiento para el cumplimiento del mismo. A la ilustre Pontificia Universidad Católica del Ecuador sede Santo Domingo por darnos la oportunidad de ser parte de ella, nos sentimos sumamente orgullosas de ser profesionales de la PUCESD. Al Mg. Rodolfo Córdova nuestro asesor de Trabajo de Titulación, por compartir sus conocimientos y la excelente dirección de este proyecto de grado, y sobre todo por la paciencia con nosotras. Al Ministerio de Inclusión Económica y Social de Santo Domingo de los Tsáchilas por la confianza brindada y acceder a que nuestro trabajo de Titulación de Grado se lo realice en su prestigiosa Institución. Al Ing. y amigo José Luis Haro por todo el ánimo infundido y confianza depositada en nuestras personas. También por su colaboración con tiempo, ideas, sugerencia y apoyo en general que se ven plasmados en el presente trabajo. A nuestros queridos profesores por sus aportes científicos y colaboración incondicional. A todos ellos, muchas gracias.

Gardenia Calle Jazmín Gaibor


v

DEDICATORIA Dedico este trabajo de titulación a mis Padres José Aníbal Calle Calle (†2011) y Rosa Andiolina Pinos González que siempre me brindaron su apoyo moral y económico para formarme como persona y profesional de la patria. A mis hermanos Danny, Álvaro y Mercy, que brindan apoyo, alegría y motivación a mi vida, sobre todo enseñarme que familia siempre esta cuando más se la necesita. A mis compañeros y amigos, que sin esperar nada a cambio compartieron sus conocimientos conmigo para lograr que este sueño se haga realidad. Gardenia Calle Quiero dedicar este trabajo de titulación a mis queridos padres Franklin Gaibor (†2011) y Blanca Gordón, quienes son las personas más importantes en mi vida, por mostrarme el camino de la superación, que con su amor y comprensión me han dado la confianza necesaria de seguir adelante. A mí amado hijo Jeremy por ser mi fuente de motivación e inspiración de superarme cada día, y a mi esposo por brindarme su apoyo incondicional y confianza. A mis hermanos y sobrinos por sus palabras de aliento y por demostrarme siempre su cariño. Jazmín Gaibor


vi

RESUMEN La presente disertación de grado comprende el desarrollo de un sistema web para la gestión de bienes informáticos y asistencia técnica en el departamento de TIC del Ministerio de Inclusión Económica y Social de la provincia de Santo Domingo de los Tsáchilas, el cual tiene como objetivo automatizar los procesos y optimizar los recursos que implica la administración del departamento de TIC. La aplicación web está conformada por nueve módulos; los ocho primeros abordan los procesos de negocio por parte del administrador, en este caso el jefe del departamento de TIC, y son: agenda, usuarios, departamentos, funcionarios, bienes, sistemas, asistencias, asignaciones; el último módulo denominado bienes asignados es visible para los funcionarios/empleados del MIES, que tendrán acceso para poder visualizar y estar informados de los bienes informáticos que están a su cargo. Para el desarrollo del software se utilizó la metodología ágil XP (Xtreme Programming) siendo ésta la que mejor se adaptó a las características del proyecto, además se utilizó herramientas de software libre (Open Source) como el framework LARAVEL v5.4 con lenguaje de programación PHP v7.1.1 y su entorno de desarrollo LARAGON v2.2.2, base de datos MariaDB v10.2.3, como servidor web se usó Apache v2.4.25, para la interfaz web se hizo uso de plantillas de BOOTSTRAP v3.3.7, y como editor de texto Sublime Text v3. Palabras clave: automatización, digitalización documentos, lenguaje de programación, software de código abierto, sistema informático.


vii

ABSTRACT The present dissertation includes the development of a web system for the managing of computer goods and technical assistance in the ICT department of the Ministry of Economic and Social Inclusion of the province of Santo Domingo de los Tsachilas, which aims to mechanize the procedures and optimize the resources involved in the administration of the ICT department. The web application consists of nine modules; the first eight deal with business processes by the administrator, in this case the head of the ICT department, and are: agenda, users, departments, officials, goods, systems, assistance, assignments; The last module called assigned assets is visible to MIES officials / employees, that will have access to be able to visualize and be informed of the computer goods they are in charge of. For the development of the software the agile methodology XP (Xtreme Programming) was used, being this one the one that better adapted to the characteristics of the project, also it was used free software tools (Open Source) as the framework LARAVEL v5.4 with programming language PHP v7.1.1 and its development environment LARAGON v2.2.2, MariaDB v10.2.3 database, Apache v2.4.25 was used as web server, BOOTSTRAP v3.3.7 patterns were used for the web interface, and as editor text Sublime Text v3. Keywords: automation, document digitalization, programming language, open source software, computer system.


viii

ÍNDICE DE CONTENIDOS 1.

INTRODUCCIÓN ................................................................................................ 1

2.

PLANTEAMIENTO DEL PROBLEMA ............................................................. 2

2.1.

Antecedentes ......................................................................................................... 2

2.2.

Problema de Investigación.................................................................................... 5

2.2.1.

El presente proyecto de investigación responderá a la siguiente problemática. ........................................................................................................ 5

2.3.

Justificación de la investigación ........................................................................... 6

2.4.

Objetivos de investigación.................................................................................... 7

2.4.1.

Objetivo General................................................................................................... 7

3.

MARCO REFERENCIAL ................................................................................... 8

3.1.

Revisión de la literatura o fundamentos teóricos .................................................. 8

3.1.1.

Ingeniería de software. ......................................................................................... 8

3.1.1.1.

Modelos prescriptivos de Software. ..................................................................... 8

3.1.1.1.1.

Modelo en cascada. ............................................................................................... 9

3.1.1.1.2.

Modelo incremental. ............................................................................................. 9

3.1.1.2.

Modelos Ágil de Procesos. ................................................................................. 10

3.1.1.3.

Programación Extrema XP. ................................................................................ 11

3.1.1.4.

Diseño Arquitectónico. ....................................................................................... 13

3.1.1.4.1.

Modelo Vista Controlador (MVC). .................................................................... 13

3.1.2.

Base de Datos. .................................................................................................... 14

3.1.2.1.

Modelo Entidad Relación. .................................................................................. 14

3.1.2.2.

Lenguaje Structured Query Language (SQL). .................................................... 15

3.1.2.2.1.

Definición de la base de datos (DDL). ............................................................... 15

3.1.2.2.2.

Manipulación de la base de datos (DML). ......................................................... 15

3.1.2.3.

Sistema Gestor de Base de Datos (SGBD). ........................................................ 16

3.1.2.3.1.

Sistema Gestor de Base de Datos “My Structured Query Language” (MySQL). ........................................................................................................... 16

3.1.3.

Lenguaje de Programación. ................................................................................ 16

3.1.3.1.

Hypertext Preprocessor (PHP)............................................................................ 16

3.1.3.2.

Javascrip. ............................................................................................................ 17

3.1.4.

Servidores Web................................................................................................... 17

3.1.4.1.

Servidor Apache. ................................................................................................ 17


ix 3.1.5.

Administración de Bienes. .................................................................................. 18

3.1.5.1.

Código de identificación de bienes. .................................................................... 18

3.1.5.2.

Custodia de los Bienes. ....................................................................................... 18

3.1.5.3.

Constatación Física de los Bienes. ..................................................................... 18

3.1.5.4.

Mantenimiento de Bienes. .................................................................................. 19

3.1.5.5.

Uso de Bienes Informáticos. ............................................................................... 19

4.

METODOLOGÍA DE LA INVESTIGACIÓN .................................................. 20

4.1.

Enfoque/ Diseño/ Tipo de investigación ............................................................ 20

4.2.

Población / Muestra ............................................................................................ 21

4.2.1.

Población. ........................................................................................................... 21

4.2.2.

Muestra. .............................................................................................................. 21

4.3.

Técnicas e Instrumentos de Recogidas de Datos ................................................ 21

4.3.1.

Entrevista. ........................................................................................................... 22

4.3.2.

Encuesta. ............................................................................................................. 22

4.4.

Técnicas de Análisis de Datos ............................................................................ 22

5.

RESULTADOS .................................................................................................. 23

5.1.

Discusión y análisis de los resultados................................................................. 23

5.1.1.

Análisis situacional de la población para el uso del sistema. ............................. 23

5.1.1.1.

Entrevista al Ing. Edison Patrón del departamento de las TIC en el MIES para determinar los procesos que se realiza en el departamento de las TIC. ..... 23

5.1.1.1.1.

Discusión de la Entrevista. ................................................................................. 25

5.1.1.2.

Encuesta a los funcionarios del Ministerio de Inclusión Económica y Social de Santo Domingo de los Tsáchilas. ........................................................ 26

5.1.1.2.1.

Discusión de las encuestas. ................................................................................. 30

5.2.

Propuesta de intervención ................................................................................... 30

5.2.1.

Metodologías de desarrollo del Sistema Web. ................................................... 30

5.2.1.1.

Comparación entre metodologías Tradicionales y Metodologías Ágiles. .......... 30

5.2.1.2.

Comparación de agilidad entre modelos ágiles XP y Scrum. ............................ 31

5.2.2.

Herramientas para el desarrollo del sistema web. .............................................. 34

5.2.2.1.

Comparación de Framework en PHP basados en el patrón MVC. ..................... 34

5.2.2.2.

Laragon. .............................................................................................................. 37

5.2.2.3.

Sublime Text....................................................................................................... 38

5.2.3.

Proceso de desarrollo de software usando Programación Extrema (XP). .......... 38

5.2.3.1.

Etapa 1: Planeación. ........................................................................................... 38


x 5.2.3.1.1.

Calendario de trabajo. ......................................................................................... 38

5.2.3.1.2.

Esfuerzo desarrollado. ........................................................................................ 39

5.2.3.1.3.

Plan de entrega. ................................................................................................... 39

5.2.3.1.4.

Plan de iteración. ................................................................................................ 40

5.2.3.1.5.

Historias de usuario. ........................................................................................... 42

5.2.3.2.

Etapa 2: Diseño. .................................................................................................. 47

5.2.3.2.1.

Tarjetas CRC. ..................................................................................................... 47

5.2.3.2.2.

Base de Datos Modelo Relacional. ..................................................................... 50

5.2.3.2.3.

Diccionario de Datos. ......................................................................................... 51

5.2.3.2.4.

Diseño de Interfaces del Sistema. ....................................................................... 51

5.2.3.3.

Etapa 3: Codificación. ........................................................................................ 53

5.2.3.4.

Etapa 4: Pruebas. ................................................................................................ 55

5.2.3.4.1.

Pruebas unitarias. ................................................................................................ 55

5.2.3.4.2.

Pruebas de aceptación. ........................................................................................ 55

5.2.4.

Acta de Entrega y Recepción. ............................................................................. 58

5.3.

Evaluación de impacto del proyecto ................................................................... 59

5.3.1.

Impacto Económico. ........................................................................................... 60

5.3.2.

Impacto social. .................................................................................................... 60

5.3.3.

Impacto Tecnológico. ......................................................................................... 61

5.3.4.

Impacto general. ................................................................................................. 61

5.4.

Conclusiones ....................................................................................................... 63

5.5.

Recomendaciones ............................................................................................... 64

Lista de referencias .................................................................................................................. 65 Glosario…….. .......................................................................................................................... 69 Anexos………. ........................................................................................................................ 71


xi

ÍNDICE DE TABLAS Tabla 1

Resultados obtenidos de la primera pregunta de la encuesta. ............................... 26

Tabla 2

Resultados obtenidos de la segunda pregunta de la encuesta ............................... 27

Tabla 3

Resultados obtenidos de la tercera pregunta de la encuesta .................................. 27

Tabla 4

Resultados obtenidos de la cuarta pregunta de la encuesta ................................... 28

Tabla 5

Resultados obtenidos de la quinta pregunta de la encuesta .................................. 29

Tabla 6

Resultados obtenidos de la sexta pregunta de la encuesta .................................... 29

Tabla 7

Comparación de las metodologías para el desarrollo del software ....................... 31

Tabla 8

Dimensión 1: alcance de la Metodología XP y Scrum ......................................... 32

Tabla 9

Dimensión 2: grado de agilidad metodología XP ................................................. 32

Tabla 10

Dimensión 2: grado de agilidad metodología Scrum ............................................ 33

Tabla 11

Dimensión 3: valores ágiles metodología XP y Scrum......................................... 33

Tabla 12

Dimensión 4: características del proceso de Software metodología XP y Scrum .................................................................................................................... 34

Tabla 13

Comparativa de los Framework CodeIgniter, Symfony, Laravel y Yii. ............... 36

Tabla 14

Calendario de Trabajo ........................................................................................... 38

Tabla 15

Esfuerzo desarrollado ............................................................................................ 39

Tabla 16

Plan de Entrega ..................................................................................................... 39

Tabla 17

Plan de Iteración: primera iteración ...................................................................... 40

Tabla 18

Plan de Iteración: segunda iteración ..................................................................... 40

Tabla 19

Plan de Iteración: tercera iteración ........................................................................ 41

Tabla 20

Plan de Iteración: cuarta iteración ......................................................................... 41

Tabla 21

Historia de Usuario 1 ............................................................................................ 42

Tabla 22

Historia de Usuario 2 ............................................................................................ 42

Tabla 23

Historia de usuario 3 ............................................................................................. 42

Tabla 24

Historia de usuario 4 ............................................................................................. 43

Tabla 25

Historia de usuario 5 ............................................................................................. 43

Tabla 26

Historia de usuario 6 ............................................................................................. 43

Tabla 27

Historia de usuario 7 ............................................................................................. 44

Tabla 28

Historia de usuario 8 ............................................................................................. 44

Tabla 29

Historia de usuario 9 ............................................................................................. 44

Tabla 30

Historia de usuario 10 ........................................................................................... 45

Tabla 31

Historia de usuario 11 ........................................................................................... 45


xii Tabla 32

Historia de usuario 12 ........................................................................................... 45

Tabla 33

Historia de usuario 12 ........................................................................................... 46

Tabla 34

Historia de usuario 14 ........................................................................................... 46

Tabla 35

Historia de usuario 15 ........................................................................................... 46

Tabla 36

Historia de usuario 16 ........................................................................................... 47

Tabla 37

Tarjeta CRC 1 ....................................................................................................... 47

Tabla 38

Tarjeta CRC 2 ....................................................................................................... 47

Tabla 39

Tarjeta CRC 3 ....................................................................................................... 47

Tabla 40

Tarjeta CRC 4 ....................................................................................................... 48

Tabla 41

Tarjeta CRC 5 ....................................................................................................... 48

Tabla 42

Tarjeta CRC 6 ....................................................................................................... 48

Tabla 43

Tarjeta CRC 7 ....................................................................................................... 48

Tabla 44

Tarjeta CRC 8 ....................................................................................................... 48

Tabla 45

Tarjeta CRC 9 ....................................................................................................... 49

Tabla 46

Tarjeta CRC 10 ..................................................................................................... 49

Tabla 47

Tarjeta CRC 11 ..................................................................................................... 49

Tabla 48

Pruebas de aceptación de la iteración 1 ................................................................ 56

Tabla 49

Pruebas de aceptación de la iteración 2 ................................................................ 56

Tabla 50

Pruebas de aceptación de la iteración 3 ................................................................ 57

Tabla 51

Pruebas de aceptación de la iteración 4 ................................................................ 58

Tabla 52. Matriz de impacto ................................................................................................. 60 Tabla 53

Impacto económico ............................................................................................... 60

Tabla 54

Impacto social ....................................................................................................... 60

Tabla 55

Impacto Tecnológico............................................................................................. 61

Tabla 56

Impacto General .................................................................................................... 61


xiii

ÍNDICE DE FIGURAS Figura 1.

Modelo en Cascada ............................................................................................... 9

Figura 2.

Modelo Incremental ............................................................................................ 10

Figura 3.

Proceso de la Programación Extrema ................................................................. 12

Figura 4.

Interrelación entre los elementos del patrón MVC ............................................. 13

Figura 5.

Diagrama de procesos y actividades en la gestión de bienes informáticos y asistencia técnica. ............................................................................................... 25

Figura 6.

Figura obtenida de la primera pregunta de la encuesta....................................... 26

Figura 7.

Figura obtenida de la segunda pregunta de la encuesta ...................................... 27

Figura 8.

Figura obtenida de la tercera pregunta de la encuesta ........................................ 28

Figura 9.

Figura obtenida de la cuarta pregunta de la encuesta. ........................................ 28

Figura 10.

Figura obtenida de la quinta pregunta de la encuesta ......................................... 29

Figura 11.

Figura obtenida de la sexta pregunta de la encuesta ........................................... 30

Figura 12.

Base de Datos Modelo Relacional.. .................................................................... 50

Figura 13.

Interfaz de Login ................................................................................................ 51

Figura 14.

Interfaz de la Agenda. ......................................................................................... 51

Figura 15.

Interfaz de Bienes Informáticos. ......................................................................... 52

Figura 16.

Interfaz de tipo de Sistemas. ............................................................................... 52

Figura 17.

Formulario de registro de Asistencia Técnica. ................................................... 52

Figura 18.

Interfaz de Mantenimientos. ............................................................................... 53

Figura 19.

Reporte de Asignaciones .................................................................................... 53

Figura 20.

Controlador de la Tabla Departamento. ............................................................. 54

Figura 21.

Vista Load de la Tabla Departamento ................................................................ 54

Figura 22.

Modelo de la Tabla Departamento. .................................................................... 55

Figura 23.

Acta Entrega - Recepción ................................................................................... 59


xiv

ร NDICE DE ANEXOS Anexo 1. Cuestionario de la entrevista. ................................................................................... 71 Anexo 2. Hoja de la encuesta. .................................................................................................. 72 Anexo 3. Diccionario de datos. ................................................................................................ 73 Anexo 4. Pruebas de aceptaciรณn. ............................................................................................. 81 Anexo 5. Carta de Impacto. ..................................................................................................... 85


1

1. INTRODUCCIÓN Esta investigación tuvo como propósito el desarrollo de un sistema web para la gestión de bienes informáticos y asistencia técnica en el MIES en Santo Domingo de los Tsáchilas, para dar solución a las dificultades que presenta el actual proceso en el control de los diferentes tipos de asignaciones y asistencias de los equipos informáticos existentes. La presente disertación de grado cuenta con los siguientes apartados: Introducción.- describe las partes que componen la disertación de grado. Planteamiento del problema.- compuesta por cuatro partes como son: antecedentes del problema, donde se detalló investigaciones anteriores con miras a ubicar el problema específico de la investigación; problema de investigación, se planteó interrogantes para el mejor entendimiento y comprensión de la problemática; justificación de la investigación, se detalló la importancia y beneficiarios del proyecto además de la concordancia con el PNBV 2017; objetivos de la investigación, aquí se estableció los propósitos de la investigación. Marco referencial.- contiene fundamentos que permiten validar el presente proyecto de grado y está constituida por dos variables como son: la independiente que sustenta las herramientas que se emplea en el desarrollo del sistema, y la dependiente que sustenta las normativas, reglamentación e información en general del uso de los bienes informáticos en el MIES. Metodología de la investigación.- el presente trabajo siguió una línea de investigación-acción aborda un enfoque mixto y un diseño anidado concurrente; la población objeto de estudio es de 24 personas, y se utilizó el muestreo exhaustivo; las técnicas de recolección de datos fueron la entrevista y encuesta, para el análisis de datos se utilizó diagramas, tablas comparativas y tabulación. Resultados.- aquí se presenta los resultados obtenidos en base a los objetivos planteados en la investigación; también se proyecta la propuesta de intervención, donde se detalla toda las fases del desarrollo del sistema web; en otro apartado está la evaluación de los impactos luego de implementar el sistema web; en el último apartado se exponen las conclusiones y recomendaciones generadas a partir de los resultados antes mencionado.


2

2. PLANTEAMIENTO DEL PROBLEMA 2.1.

Antecedentes El Ministerio de Inclusión Económica y Social (MIES) de la Provincia de Santo

Domingo de los Tsáchilas se encuentra ubicado en la vía Quevedo junto al parque de la Madre, una entidad que se encarga de: Definir y ejecutar políticas, estrategias, planes, programas, proyectos y servicios de calidad y con calidez, para la inclusión económica y social, con énfasis en los grupos de atención prioritaria y la población que se encuentra en situación de pobreza y vulnerabilidad, promoviendo el desarrollo y cuidado durante el ciclo de vida, la movilidad social ascendente y fortaleciendo a la economía popular y solidaria (Ministerio de Inclusión Económica y Social [MIES], 2015).

Misión: Planificar, coordinar, gestionar, controlar y evaluar los proyectos, procesos, operaciones, infraestructura, seguridad y soporte de Tecnologías de la Información y Comunicaciones, para la aplicación de políticas públicas, mejora de la gestión institucional y de los servicios a la ciudadanía, así como garantizar la óptima operación y disponibilidad de los sistemas y servicios informáticos, e implementar la interoperabilidad con otras entidades (MIES, 2015).

Visión: Ser el referente regional y nacional en la definición y ejecución de políticas de inclusión económica y social, contribuyendo a la superación de las brechas de desigualdad; a través de la construcción conjunta del Buen Vivir para la población ecuatoriana (MIES, 2015).

Actualmente la información de registros que se realizan en la área de las TIC en el MIES, se la lleva a cabo con herramientas de ofimática que hasta al momento han servido de apoyo en la gestión de los procesos, a pesar de esta ayuda estas herramientas no cubren todas las necesidades que se necesitan para un servicio eficaz, esto implica un sinnúmero de consecuencias y problemas que describiremos a continuación: El control de inventario de los bienes asignados al departamento de las TIC, se lo realiza mediante una matriz de Excel, este método hasta ahora ha sido un apoyo, pero a medida que transcurre el tiempo los datos cada vez son mayores, provocando una deficiencia en el control de los bienes provocando pérdida, duplicación, y errores en los datos, además dificulta la manipulación de la información. El inadecuado control de registros en las asignaciones temporales y permanentes de los bienes informáticos ocasiona problemas al acceder a la información aumentando el tiempo de


3 respuesta en el requerimiento solicitado, y generando error en los datos de los equipos al momento de realizar nuevas prestaciones. La falencia en el registro de mantenimiento y/o asistencia técnica brindada a los usuarios conlleva a apuntes desordenados y confusos, lo que dificulta en primer lugar, saber el estado funcional actualizado de cada bien, y en segundo lugar, los reportes anuales que el departamento de las TIC debe entregar de las actividades realizadas. Luego del respectivo análisis in situ de las causas y consecuencias se determinó que existe un deficiente desempeño de la gestión de bienes informáticos y asistencia técnica en el departamento de TICS del Ministerio de Inclusión Económica y Social de la provincia de Santo Domingo de los Tsáchilas. Como antecedentes tenemos las siguientes investigaciones: Un primer trabajo en la Universidad Politécnica Salesiana del Azuay corresponde a Auquilla, y Andrade (2014) quienes realizaron una “Propuesta de un modelo de gestión para la administración y manejo del control de bienes del sector público aplicado a la dirección provincial del IEES en el Azuay”. El objetivo general de esta investigación es elaborar una propuesta de un modelo de gestión para la administración y manejo del control de bienes del sector público aplicado a la dirección provincial del IEES en el Azuay. En esta investigación uno de sus apartados menciona los 7 pasos para la correcta administración y manejo de inventarios de activos fijos. También hace énfasis en los 10 pasos que se requieren cumplir dentro del proceso informático. Un segundo trabajo en la Universidad Politécnica Salesiana, Quito. Otacoma y Sopa (2011) realizaron su trabajo de disertación denominado “Desarrollar e Implementar un Sistema de Información que permita realizar el registro y control de mantenimientos e inventario de registro informáticos, el mismo que se denominara KUBIK-INVENTARY PC, procesos que se ejecutaran desde el departamento de gestión tecnológica del Ministerio de Inclusión Económica y Social (MIES)”. El objetivo general de esta investigación es desarrollar un paquete de software para registrar y controlar el mantenimiento e inventario de equipos informáticos, “KUBIK-INVENTARY PC”, y por medio de éste dotar de una herramienta que permita la administración y control de la información que se genera en torno a este tema en el MIES. La aplicación se desarrolló con herramientas de código libre lo que le


4 permitió abaratar costos, uso lenguaje de programación PHP y un SGBD PostgreSql. Los módulos que tiene el software son 4: seguridad, catálogo, inventario, y de mantenimiento. Un tercer trabajo en la Universidad Politécnica Salesiana de Quito realizado por Villalba (2013), lleva por título: “Análisis, diseño y construcción un sistema de administración de actividades de Help Desk, y control de equipamiento, como aplicativo de escritorio para la Empresa Eléctrica Quito”. El objetivo general de esta investigación es analizar, diseñar y construir un sistema de administración de soporte a usuarios en actividades de Help Desk, y control de equipamiento como aplicativo de escritorio para la Empresa Eléctrica Quito. En esta investigación se utilizó el proceso unificado de modelado (RUP) para los flujos de trabajo de proceso, actividades principales para el desarrollo de software, utilizando lenguaje abierto (java) creando un aplicativo de escritorio que permitirá gestionar todas las actividades de Help Desk y control de equipamiento para los equipos informáticos de la empresa. Un cuarto trabajo en la Escuela Politécnica Nacional de Quito realizado por Mera y Paredes (2008) nombrado “Automatización de la gestión de inventario y préstamo de los bienes de la asociación de estudiantes de Ingeniería de Sistemas - AEIS”. El objetivo general de esta investigación es crear un sistema orientado a la gestión de inventarios y préstamos de bienes de la Asociación de Estudiantes de Sistemas. El producto de la investigación brinda funciones de inventariado, reserva, control de depreciación, emisión de etiquetas de identificación, control de mantenimiento, generación de reportes, gestión de usuarios; que apoya a los procesos en la gestión de bienes, aportando agilidad y fidelidad de los datos procesados por el área de las TIC. Fue desarrollado mediante la metodología de Proceso Unificado, bajo el framework Symfony, con la arquitectura Modelo Vista Controlador (MVC). Un quinto trabajo en la Universidad Técnica de Cotopaxi de Latacunga realizado por Molina (2015), bajo el título de: “Implementación de un sistema de gestión de inventarios y mantenimiento de equipos informáticos mediante la metodología Scrum, en los laboratorios de la carrera de ingeniería en informática y sistemas computacionales de la universidad técnica de Cotopaxi durante el periodo 2014-2015”. El objetivo general de esta investigación es administrar y tramitar los procesos de inventarios y mantenimiento de los equipos informáticos en los laboratorios de la carrera de Ingeniería en Informática y Sistemas Computacionales. Para el desarrollo del software se utilizaron

herramientas en Visual


5 Basic.Net y My SQL, bajo la metodología Scrum, Con la implementación del sistema se mejoró el desempeño laboral, además que se accede con facilidad a la información detalla de hardware, software y mantenimiento, y es el motor principal para la toma de decisiones gracias a los reportes que genera. La información brindada de estas investigaciones fue de gran ayuda para el presente trabajo, en cuanto a medidas de solución para la gestión de bienes informáticos y asistencias técnicas.

2.2.

Problema de Investigación

2.2.1. El presente proyecto de investigación responderá a la siguiente problemática. ¿Cómo mejorar la gestión de bienes informáticos y asistencia técnica en el departamento de TICS del MIES de la Provincia de Santo Domingo de los Tsáchilas? Los grandes y constantes avances tecnológicos han provocado un impacto en la forma en que las empresas e instituciones administran la información, involucrándose en el mundo de la automatización para sus funciones, valiéndose en especial del desarrollo de los sistemas computacionales. En el departamento de las TIC del MIES, la información y la forma de cómo se realizan los procesos ha generado un deficiente desempeño en la gestión de los bienes informáticos y asistencia técnica, por tanto surge la necesidad de crear un Sistema Web que permita automatizar los procesos de registros que se requieren, facilitando la gestión en ésta área y brindando calidad de resultados. Para un mejor entendimiento y comprensión de nuestra problemática, la seccionaremos en interrogantes claves que se plantean a continuación: 

¿Cuáles son los procesos que se realiza para la gestión de los bienes informáticos y asistencia técnica en el departamento de las TICS en el MIES?

¿Cuál es la metodología así como las herramientas de software que permiten el desarrollo del sistema web?

¿Cuáles son los requerimientos y el patrón arquitectónico para el sistema web?


6

2.3.

Justificación de la investigación La investigación se incorpora con el objetivo 5 del Plan Nacional del Buen Vivir que

dice: “Impulsar la productividad y competitividad para el crecimiento económico sostenible de manera redistributiva y solidaria” (Secretaría Nacional de Planificación y Desarrollo [SENPLADES], 2017, p.83). Se vincula de manera directa con la política 6 de este objetivo que se basa en: Promover la investigación, la formación, la capacitación, el desarrollo y la transferencia tecnológica, la innovación y el emprendimiento, la protección de la propiedad intelectual, para impulsar el cambio de la matriz productiva mediante la vinculación entre el sector público, productivo y las universidades (SENPLADES, 2017, p.83).

Gracias a la vinculación del Mies con la PUCESD, se pudo dar

solución a la

problemática que se presentaba en la empresa, es así que el sistema web genera un valor agregado al proceso y servicio que presta el Mies en el departamento de las TIC, siendo éste más limpio, eficiente y transparente. El Sistema Web propone innovación tecnológica, brindando respuesta inmediata a las consultas hechas por los usuarios; permitiendo controlar el acceso a los registros e información, a través de una interfaz orientada a la web funcional, también contará con un proceso para la generación de “actas de entrega” con el fin de tener un respaldo de la asignación y prestación de los bienes informáticos, además contará con un proceso de creación de reportes como constancia de las actividades realizadas durante un periodo determinado. La importancia del desarrollo del proyecto es que permite la gestión de bienes informáticos y asistencia técnica en el área de las TIC del MIES, que sería de carácter general y aplicable a otras instituciones públicas de similares características. Dada la naturaleza y alcance del proyecto, se considera que el mismo es factible, por cuanto el MIES cuenta con las instalaciones, recursos tecnológicos y humanos, que asiste en los aspectos necesarios para que el proyecto cumpla con los objetivos para los cuales fue planteado. El número de beneficiarios directos es uno, es decir la persona encargada del Área de las TIC (Ing. Edison Patrón), que podrá agilitar, automatizar, y dar solución a los


7 inconvenientes que genera el actual proceso. Los beneficiarios indirectos son todos las empleados del MIES, que podrán visualizar los equipos que tiene bajo su custodio.

2.4.

Objetivos de investigación

2.4.1. Objetivo General. Implementar un Sistema Web para la gestión de bienes informáticos y asistencia técnica en el departamento de las TIC del Ministerio de Inclusión Económica y Social de la Provincia de Santo Domingo de los Tsáchilas durante el periodo 2017-2018. 2.4.2.

Objetivos Específicos.

Analizar los procesos que se realiza en el departamento de las TIC del MIES.

Determinar la metodología así como las herramientas de software que permita el desarrollo del sistema web.

Desarrollar el sistema web para la gestión de bienes informáticos y asistencia técnica para el departamento de las TIC del MIES.


8

3. MARCO REFERENCIAL 3.1.

Revisión de la literatura o fundamentos teóricos A continuación, se hace una revisión bibliográfica de autores relevantes que sustentan

la presente investigación. 3.1.1. Ingeniería de software. Piattini (2016) refiere que por los años de 1940 los desarrolladores de software eran los mismos que construían el hardware. Y en 1960 se dio una crisis en la cual se hace evidente que el software y el hardware distaban mucho de entre sí. Y es aquí donde nace este término para dar solución a esta crisis, por tanto la ingeniería de software refiere al desarrollo, operación y mantenimiento del software para operar de modo confiable y eficiente en las diversas máquinas reales. 3.1.1.1.

Modelos prescriptivos de Software.

Pressman (2010) señala que los modelos de proceso prescriptivo, llamados así porque prescriben un conjunto de elementos del proceso: actividades estructurales, acciones de ingeniería de software, tareas, productos del trabajo, aseguramiento de la calidad y mecanismos de control del cambio para cada proyecto, y fueron propuestos originalmente para poner orden en el caos del desarrollo de software. Cada modelo del proceso también prescribe un flujo del proceso (también llamado flujo de trabajo), es decir, la manera en la que los elementos del proceso se relacionan entre sí. La historia indica que estos modelos tradicionales han dado cierta estructura útil al trabajo de ingeniería de software y que constituyen un mapa razonablemente eficaz para los equipos de software. Todos los modelos del proceso del software pueden incluir las actividades estructurales generales descritas a continuación, pero cada una pone distinto énfasis en ellas y define en forma diferente el flujo de proceso que invoca cada actividad estructural. Comunicación se busca entender los objetivos de los participantes respecto del proyecto, y reunir los requerimientos que ayuden a definir las características y funciones del software. Planeación crea un “mapa” que guía al equipo mientras viaja. El mapa —llamado plan del proyecto de software— define el trabajo de ingeniería de software al describir las tareas técnicas por realizar, los riesgos probables, los recursos que se requieren, los productos del trabajo que se obtendrán y una programación de las actividades. Modelado crea modelos a fin de entender mejor los requerimientos del software y el diseño que los satisfará. Construcción.


9 Esta actividad combina la generación de código (ya sea manual o automatizada) y las pruebas que se requieren para descubrir errores en éste. Despliegue. El software (como entidad completa o como un incremento parcialmente terminado) se entrega al consumidor que lo evalúa y que le da retroalimentación, misma que se basa en dicha evaluación. (Pressman, 2010, p. 13)

3.1.1.1.1. Modelo en cascada. Somerville (2014) señala que el modelo en cascada, denominado así porque sus etapas (actividades estructurales) parecen caer en cascada, es un ejemplo de un proceso riguroso dirigido por un plan, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior. Pressman (2010) refiere que el modelo en cascada, también llamado ciclo de vida clásico, se basa en un enfoque sistemático y secuencial para el desarrollo del software, que precede con la especificación de los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue. Ver Figura 1.

Figura 1. Modelo en Cascada. Adaptado de “Ingeniería del software: Un enfoque práctico” por R.S. Pressman, 2010, México: McGraw-Hill.

Somerville (2014) refiere el resultado de cada fase consiste en uno o más documentos que avalan su finalización. Debido a los costos de producción y aprobación de documentos, las iteraciones suelen ser onerosas e implicar un rediseño significativo. El modelo en cascada sólo debe usarse cuando los requerimientos se entiendan bien y sea improbable el cambio radical durante el desarrollo del sistema. 3.1.1.1.2. Modelo incremental. Hay muchas situaciones en las que los requerimientos iniciales del software están razonablemente bien definidos, pero el alcance general del esfuerzo de desarrollo imposibilita un proceso lineal. Además, tal vez haya una necesidad imperiosa de dar rápidamente cierta funcionalidad limitada de software a los usuarios y aumentarla en las entregas posteriores de software. En tales casos, se elige un modelo de proceso diseñado para producir el software en incrementos (Pressman, 2010, p. 35).

Pressman (2010) señala que el modelo incremental combina elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos. Se basa en el pensamiento


10 de construir incrementando las funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada a medida que avanza el calendario de actividades. Ver Figura 2. Cada secuencia lineal produce un incremento del software a entregarse.

Figura 2. Modelo Incremental. Adaptado de “Ingeniería del software: Un enfoque práctico” por R.S. Pressman, 2010, México: McGraw-Hill.

Somerville (2014) refiere que cuando se utiliza un modelo incremental, el primer incremento es a menudo un producto esencial, sólo con los requisitos básicos, esto significa que el cliente puede valorar el desarrollo del sistema en una etapa temprana, para verificar si se entrega lo que se solicita, caso contrario, se ajusta o cambia el incremento actual. 3.1.1.2.

Modelos Ágil de Procesos.

Mendes, Estévez & Fillottrani (2010) refiere que el Manifiesto Ágil nace como una alternativa a los modelos de procesos tradicionales caracterizados por su rigidez e incluye cuatro postulados y una serie de principios asociados: El individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. Que se basa en tres premisas como son que los miembros del equipo son el factor principal del éxito de un proyecto; es más importante crear un equipo que un entorno; y es mejor unir a un equipo y dejar que configure el entorno en función de sus propias necesidades. Desarrollar software que funciona, más que conseguir una buena documentación. Es decir que realizar documentación en la codificación del software, genera pérdida de tiempo y


11 no añade un valor directo al producto. En esta etapa de codificación los documentos no ofrecen el valor añadido que si la da comunicación con el equipo desarrollador. La colaboración con el cliente más que la negociación de un contrato. Se basa que el cliente y cualquier otro miembro deben estar integrado y colaborar con el equipo de trabajo puesto que el contrato es solo un formalismo. Responder a los cambios más que seguir estrictamente un plan; es decir que la capacidad de reaccionar ante un cambio debe ser un factor vital en el proceso de desarrollo pues puede determinar el fracaso o éxito del mismo. (pp. 68-69) Una de las metodologías ágiles más usadas es la Programación Extrema donde los clientes intervienen estrechamente en los requerimientos del sistema mediante las “historias de usuarios”, otra metodología ágil muy utilizada es la Scrum que es congruente con el manifiesto ágil y se utilizan para guiar actividades de desarrollo dentro de un proceso de análisis que incorpora las siguientes actividades estructurales: requerimientos, análisis, diseño, evolución y entrega. En el apartado 5.2.1.2 se encuentra las tablas comparativas de las metodologías XP y Scrum, como resultado la mejor metodología que se adapta al presente proyecto es la Programación Extrema. 3.1.1.3.

Programación Extrema XP.

Kent Beck (como lo menciona Mendes et al., 2010) refiere que formuló esta nueva metodología ágil que se diferencia de las demás por su adaptabilidad a los cambios en los requerimientos. Proponiendo un ambiente de trabajo agradable, basado en la comunicación y aprendizaje de los desarrolladores de software. Godoy (2015) refiere que XP basa su eje central en la retroalimentación entre el cliente y los desarrolladores forjando una fuerza para enfrentar los cambios, que en la mayoría de los proyectos presentan requisitos imprecisos y cambiantes, dando como resultado alto riesgo técnico. Por tanto XP se basa en un flujo incremental permitiendo crear versiones de software una a la vez, para la entrega al cliente, y su posterior revisión. XP tiene cinco principios básicos: 1. Simplicidad, que simplifica el diseño para acelerar el desarrollo y facilitar el mantenimiento a través de la actualización del código. 2. Comunicación que fomenta la comunicación escrita como un código autodocumentado y


12 pruebas conjuntas, recomendando la documentación de los objetivos de la clase y la funcionalidad proporcionada por los métodos; y oral, entre los programadores con los clientes, recomendando que la comunicación entre ambas partes debe ser constante y fluida. 3. Retroalimentación constante del cliente a través de ciclos breves de entrega y demostraciones de las funciones entregadas. 4. Coraje para mantener la sencillez al permitir la deferencia de las decisiones de diseño; comunicarse con otros, incluso cuando esto permite mostrar la falta de conocimiento propio, y recibir retroalimentación durante el desarrollo. 5. El respeto que se debe infundir entre los miembros del equipo, pues los desarrolladores no deben hacer cambios que puedan afectar a las pruebas ya realizadas, o retrasar el trabajo de los compañeros de equipo. (Mendes et al., 2010, p. 70)

Figura 3. Proceso de la Programación Extrema. Adaptado de “Ingeniería del software: Un enfoque práctico” por R.S. Pressman, 2010, México: McGraw-Hill.

El proceso de desarrollo XP consta de cuatro etapas: Planeación, el cliente interactúa con los técnicos XP es la fase de recogida de requisitos iniciales. La metodología propone el uso de la técnica de Historias de Usuario a través de la cual el usuario especifica los requisitos de función y no función del producto. Cada historia debe ser suficientemente atómica y comprensible para que los desarrolladores puedan implementar los requisitos en una iteración. Ver Figura 3. Diseño, XP se basa en el principio de código simple, es decir, implementar la solución más simple que pueda funcionar, la complejidad innecesaria y el código extra debe ser removido inmediatamente y no se debe agregar nuevas funcionalidades antes de que sean agendadas. También estimula el uso de las tarjetas CRC (clase-responsabilidad-colaborador), sirven para diseñar el sistema en conjunto entre todo el equipo, y reduce el modo de pensar procedural y apreciar la tecnología de objetos. Las tarjetas CRC son el único producto del trabajo de diseño que se genera como parte del proceso XP. Ver Figura 3.


13 Codificación, luego de realizar las historias de usuario, a la par también se realizan pruebas unitarias a cada historia, es decir si el código hace lo que tiene que hacer. Luego de esto se procede a la codificación. Un concepto clave es la programación en parejas, es decir, dos personas trabajando en una misma estación, siendo de ayuda en la resolución de problemas, y verificación del código. Una vez que el código complete satisfactoriamente la prueba unitaria, el código se integra al sistema real, de esta manera, se produce una integración constante, evitando una integración más costosa al final del proyecto. Ver Figura 3. Pruebas, esta fase va de la mano con la fase de codificación, en ella tenemos las pruebas unitarias, pruebas de integración, pruebas de validación, y pruebas de aceptación, esta última se deriva de las historias de usuario, y comprueba si cumple con las expectativas del cliente. Ver Figura 3. (Pressman, 2010, pp. 63-64-65)

3.1.1.4.

Diseño Arquitectónico.

Sommerville (2011) refiere que el diseño arquitectónico se interesa en cómo debe organizarse y como debe diseñarse la estructura global del sistema. Es importante porque afecta al desempeño, la potencia, y al mantenimiento de un sistema. 3.1.1.4.1. Modelo Vista Controlador (MVC). Fernández y Díaz (2012) afirma “el patrón MVC es un paradigma utilizado en muchos sistemas basados en la web que divide las partes que conforman una aplicación en el Modelo, las Vistas y los Controladores, facilitando y reduciendo el tiempo del mantenimiento de software” (p. 47). El componente Modelo maneja los datos del sistema y las operaciones asociadas a esos datos. El componente Vista define y gestiona cómo se presentan los datos al usuario. El componente controlador dirige la interacción del usuario… y pasa estas interacciones a vista y modelo (Pressman, 2010, p. 155).

Figura 4. Interrelación entre los elementos del patrón MVC. Adaptado de “Patrón Modelo-VistaControlador” por Y. Fernández, Y. Díaz, 2012, Telem@tica, 11, p. 48.

La ventaja de este patrón es la separación clara entre los componentes de un programa; lo cual permite su implementación por separado. Interfaz de Programación de


14 Aplicaciones API (Aplication Programming Interface) muy bien definida; cualquiera que use el API, podrá reemplazar el Modelo, la Vista o el Controlador, sin aparente dificultad. Conexión entre el Modelo y sus Vistas dinámica; se produce en tiempo de ejecución, no en tiempo de compilación. (Fernández y Díaz, 2012, p. 48) 3.1.2. Base de Datos. Nevado (2010) refiere que una base de datos es un sistema de información, que como su nombre lo dice, recopila la información y la organiza de tal forma que el ordenador pueda seleccionar rápidamente los datos que se necesite, mejorando los sistemas informáticos y aumentando su rendimiento. 3.1.2.1.

Modelo Entidad Relación.

Zapata, González y Chaverra (2011) refieren que Entidad Relación es un diagrama universal creado por Dr. Peter Pin-Shan Chen que permite representar gráficamente abstracciones de un sistema de información por medio de entidades y relaciones, hoy en día la obtención de este diagrama se lo hace de forma automática y semiautomática. El modelo entidad-relación se basa en los conceptos descritos a continuación para representar un modelo de la vida real: 4. Entidad, representa una “cosa” u "objeto" del mundo real con existencia independiente, es decir, se diferencia unívocamente de cualquier otro objeto o cosa, incluso siendo del mismo tipo. 5. Conjunto de entidades, es una colección de entidades que comparten los mismos atributos o características. 6. Atributos, son las propiedades que describen a cada entidad en un conjunto de entidades. Un conjunto de entidades dentro de una entidad, tiene valores específicos asignados para cada uno de sus atributos, de esta forma, es posible su identificación unívoca. 7. Restricciones, son reglas que deben mantener los datos almacenados en la base de datos. 8. Relación, describe cierta dependencia entre entidades o permite la asociación de las mismas. 9. Conjunto de relaciones, consiste en una colección de relaciones de la misma naturaleza. 10. Correspondencia de cardinalidades, dado un conjunto de relaciones en el que participan dos o más conjuntos de entidades, la correspondencia de cardinalidad indica el número de entidades con las que puede estar relacionada una entidad dada. Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de cardinalidades puede ser de uno a uno, uno a varios, varios a uno y de varios a varios.


15 11. Claves, es un subconjunto del conjunto de atributos comunes en una colección de entidades, que permite identificar unívocamente cada una de las entidades pertenecientes a dicha colección. Asimismo, permiten distinguir entre sí las relaciones de un conjunto de relaciones. Dentro de los conjuntos de entidades existen las superclave, clave candidata y clave primaria. (Catherine, 2009).

3.1.2.2.

Lenguaje Structured Query Language (SQL).

Silberschatz, Korth y Sudarshan (2002) refiere que el SQL es un lenguaje de consulta estructurado estándar para sistemas de base de datos relacionales, por ejemplo ORACLE, SQL SERVER, entre otros. Y cuenta con sentencias que se pueden utilizar para realizar diversas tareas, dependiendo de las tareas, estas sentencias se pueden clasificar en definición de la base de datos (DDL) “Se usan para crear, cambiar y destruir las estructuras lógicas que constituyen el modelo lógico. Estos comandos se pueden usar en cualquier momento para realizar cambios a la estructura de la base de datos” Catherine (2009, p. 212). Y en manipulación de la base de datos (DML) “se puede usar como un lenguaje interactivo para consultas, incrustado en un lenguaje de programación huésped” Catherine (2009, p. 218). 3.1.2.2.1. Definición de la base de datos (DDL). Borja (2013) refiere que los comandos para la definición de datos en la base de datos son: Create Database se utiliza para crear una nueva base de datos vacía, Drop Database se utiliza para eliminar completamente una base de datos existente, Create Table se utiliza para crear una nueva tabla donde la información se almacena realmente; Alter Table se utiliza para modificar una tabla ya existente, y Drop Table se utiliza para eliminar por completo una tabla existente. 3.1.2.2.2. Manipulación de la base de datos (DML). Borja (2013) refiere que los comandos para la gestión de datos en la base de datos son: Select que se utiliza para leer (o seleccionar) los datos, Insert se utiliza cuando se desea añadir (o insertar) nuevos datos, Update es utilizado para cambiar (o actualizar) datos existentes; Delete se utiliza cuando se quiere eliminar (o borrar) datos existentes, Replace en cambio es usado para añadir o cambiar (o reemplazar) datos nuevos o ya existentes, y Truncate sirve para vaciar (o borrar) todos los datos de la plantilla.


16 3.1.2.3.

Sistema Gestor de Base de Datos (SGBD).

Un sistema gestor de base de datos (SGBD) “es un sistema que permite la creación, gestión y administración de bases de datos, así como la elección y manejo de las estructuras necesarios para el almacenamiento y búsqueda de la información del modo más eficiente posible” (Iruela, 2016). 3.1.2.3.1. Sistema Gestor de Base de Datos “My Structured Query Language” (MySQL). Suris (2016) refiere que MySQL es la base de datos más popular y utilizada a la hora de desarrollar páginas web dinámicas y sitios de comercio electrónico. Es usado por muchos sitios web grandes y populares, como Wikipedia, Google (aunque no para búsquedas), Facebook, Twitter, Flickr y YouTube. Se suele trabajar en combinación con PHP y tiene características que la hacen una buena elección; entre ellas: Gratuidad: Se trata de software libre que puede ser utilizado sin limitación alguna. Popularidad: Son innumerables las páginas donde encontrar información y las listas de correo donde podrán ayudarnos desinteresadamente con nuestros proyectos. Rapidez: La velocidad de proceso de MySQL es legendaria. Versatilidad: Trabaja tanto con sistemas operativos basados en Unix como con el Sistema Operativo Windows de Microsoft. Sencillez de manejo: Utiliza el lenguaje estándar SQL. 3.1.3. Lenguaje de Programación. Según TIOBE Software BV (2000) en su comunidad de índice de lenguajes de programación indica la popularidad de los lenguajes de programación, entre los siete primeros lenguajes más utilizados se encuentran Java, C, C++, Python, JavaScript y PHP. Siendo estos dos últimos los usados en este proyecto. 3.1.3.1.

Hypertext Preprocessor (PHP).

Cobo, Gómez, Pérez y Rocha (2005) señala que PHP es un lenguaje de programación de código abierto e interpretado por el lado del servidor, es un lenguaje muy popular usado en especial para el desarrollo web que se caracteriza por su potencia, versatilidad, robustez y


17 modularidad. Los programas escritos en PHP son embebidos directamente en código HTML y ejecutados por el servidor web. Cuando el usuario realiza una petición al servidor para que le dirija a una página Web, el servidor ejecuta el intérprete PHP. Este procesa el código PHP pedido que producirá el contenido de la página. El resultado es enviado por el intérprete al servidor, que este envía al usuario. PHP es flexible y multiplataforma, trabaja con casi todos los servidores web, sistemas operativos y plataformas sin pagar por utilizar este software. 3.1.3.2.

Javascrip.

Zofío, J. (2013) señala que Javascript es un lenguaje de programación interpretado, por eso no tiene necesidad de ser compilado para su ejecución, el mismo navegador interpreta al cargar el HTML junto con los archivos CSS, esta integración permite dar una mejor y mayor funcionalidad a las páginas web y mejorar bastante la interacción que tiene el usuario al acceso a los sitios en línea, junto con este lenguaje han aparecido tecnologías (librerías) que dan la posibilidad de dinámica del contenido así como la interacción del usuario en el uso de aplicaciones web. 3.1.4. Servidores Web. López et al. (2014) refiere que la función de un servidor web es responder a las peticiones (URL y/o puerto) que realiza el usuario a través de un navegador. Es decir que un servidor web se convierte en un espacio para guardar y administrar los recursos HTML de una aplicación web. 3.1.4.1.

Servidor Apache.

Márquez, Vargas, y Sampedro (2002) refiere que un servidor Apache soporta un gran conjunto de opciones de configuración que son fáciles y sencillas de seguir. La configuración por defecto de Apache es bastante eficiente y con ella podemos empezar a crear nuestros documentos HTML de manera inmediata y publicarlos. Apache es hoy en día uno de los servidores web más usados, gracias a las ventajas que este servidor proporciona. Márquez et al. (2002) señala las siguientes ventajas, su licencia es de código abierto del tipo BSD que permite el uso comercial y no comercial de Apache. Una talentosa comunidad de desarrolladores siguiendo un proceso abierto de desarrollo. Tiene arquitectura modular. Los usuarios de Apache pueden adicionar fácilmente funcionalidad a


18 sus ambientes específicos. Portabilidad pues Apache trabaja sobre todas las versiones recientes de UNIX y Linux, Windows, BeOs, mainframes. Es robusto y seguro. (pp. 11-12) 3.1.5. Administración de Bienes. La Dirección de Investigación Técnica, Normativa y de Desarrollo Administrativo (DITNDA, 2009) refiere que para una buena administración de los bienes informáticos del sector público se debe documentar y evidenciar todos las existencias con sus especificaciones a detalle, como también la ubicación del equipo, sumando además toda actividad de dicho bien, como lo es la custodia, traspaso, mantenimiento, préstamo, etc. Con el propósito de que la información esté actualizada, mejorando la seguridad de su registro y control. 3.1.5.1.

Código de identificación de bienes.

Todo equipo informático deberá constar con un código único de identificación, que se lo colocará en un lugar visible, para su fácil identificación y organización, por tanto cada institución es responsable de mantener actualizados los registros, así como de su cuidado (DITNDA, 2009). 3.1.5.2.

Custodia de los Bienes.

Es responsabilidad del director de cada institución pública el de asignar un responsable o custodio permanente a los bienes informáticos, y de implementar su propia regulación que permitan un mejor control interno de los bienes informáticos, para saber el estado funcional del equipo, su correcto uso y reducir los riesgos de desperfecto (DITNDA, 2009). 3.1.5.3.

Constatación Física de los Bienes.

La administración de cada institución pública será la encargada de emitir las instrucciones necesarias para las comprobaciones periódicas de las existencias de los bienes informáticos, estas instrucciones serán documentadas claramente con el fin de que todo el personal que interviene en el proceso no tenga dudas. Estas constataciones tomaran lugar por lo menos una vez cada año, y el personal encargado para dicha labor no puede realizar las verificaciones a los bienes que tienen a su cargo (DITNDA, 2009). Solo en caso que lo amerite se podrá contratar servicios privados que lleven a cabo la verificación de existencia y estado de los bienes informáticos. Una vez culminada esta


19 actividad, como respaldo se deberá realizar y entregar un acta detallado con todas las particularidades y diferencias encontradas con el registro de inventario, para la respectiva actualización de datos (DITNDA, 2009). 3.1.5.4.

Mantenimiento de Bienes.

El área o departamento dentro de la institución pública encargada de la administración de los bienes informáticos ejecutara un plan de acción para su mantenimiento preventivo y correctivo, a fin de cuidar el bienestar del equipo y asegurar su correcto funcionamiento. Toda asistencia que se le dé al equipo deberá quedar registrada, para tener un mejor control en la administración (DITNDA, 2009). 3.1.5.5.

Uso de Bienes Informáticos.

En el Art. 3 de la Constitución de la República del Ecuador (como se citó en Contraloría General del Estado [CG], 2006) refiere que el buen uso y cuidado de los bienes informáticos es deber de la persona que tiene a cargo el bien informático para sus labores profesionales, en caso de avería del equipo por negligencia es el custodio que se hace cargo de los gastos de mantenimiento. Es obligación de la institución pública tener actualizados los registros donde figure la historia, destinación y uso de cada bien informático. Todo nombramiento de custodio o préstamo de un equipo informático deberá constar bajo un acta de asignación o prestación (CG, 2006).


20

4. METODOLOGÍA DE LA INVESTIGACIÓN 4.1.

Enfoque/ Diseño/ Tipo de investigación “La finalidad de la investigación-acción es comprender y resolver problemáticas

específicas de una colectividad vinculadas a un ambiente (grupo, programa, organización o comunidad), frecuentemente aplicando la teoría y mejores prácticas de acuerdo con el planteamiento” (Hernández, Fernández y Baptista, 2010, p. 496). El presente trabajo de disertación es una investigación-acción, pues se involucró profundamente a la población objeto de estudio para captar las necesidades y procesos a mejorar, también en el análisis de datos; y finalmente porque se creó el producto “Sistema web” que dio solución a la problemática.” La investigación mista implica combinar los métodos cuantitativos y cualitativos en un mismo estudio. No se remplazan sino que utiliza las fortalezas de ambos tipos, las combina y trata de minimizar sus debilidades potenciales. Implica recolección, análisis e interpretación de los datos cualitativos y cuantitativos, por lo tanto, genera inferencias de ambos tipos, así como metainferencias. (Domínguez, 2015, p. 15)

El presente trabajo de investigación es de enfoque mixto. Cuantitativo porque se realizó una encuesta para determinar si el sistema web era necesario para mejorar la gestión de bienes informáticos y asistencia técnica, donde los resultados se generalizo para toda la población. Cualitativo porque se realizó una entrevista que permitió indagar profundamente en los procesos que se realiza en el departamento de TIC para la gestión de bienes y asistencia técnica. Hernández et al. (2010) refieren que el diseño anidado concurrente tiene la peculiaridad que un método predominante es quien guía el proyecto (pudiendo ser éste cuantitativo o cualitativo). El método que posee menor prioridad es anidado o insertado dentro del que se considera central. Tal incrustación puede significar que el método secundario responda a diferentes preguntas de investigación respecto al método primario. Entonces colecta datos cuantitativos y cualitativos, con la finalidad de confirmar o corroborar resultados y efectuar validación cruzada entre datos cuantitativos y cualitativos, el diseño puede abarcar todo el proceso investigativo o solamente la parte de recolección, análisis e interpretación.


21 La investigación se alineo al diseño anidado o incrustado concurrente de modelo dominante (DIAC), porque se utilizó la encuesta a los funcionarios del MIES, como sustento de la importancia de realizar el sistema web para mejorar la administración en el departamento de TIC, que con la entrevista al jefe de departamento de TIC, ya había quedado en evidencia.

4.2.

Población / Muestra

4.2.1. Población. Según Tamayo (2014) “La población se define como la totalidad del fenómeno a estudiar donde las unidades de población posee una característica común la cual se estudia y da origen a los datos de la investigación” (pág.114). En la presente investigación la población está conformada por los empleados que tienen a su cargo algún tipo de bien informático en el MIES. Dando un total de 24 personas, incluyendo el Ingeniero encargado del departamento de las TIC el cual interviene directamente en la gestión de los bienes informáticos y asistencia técnica en el MIES de la provincia Santo Domingo de los Tsáchilas. 4.2.2. Muestra. “La muestra es un subgrupo de la población de interés sobre el cual se recolectarán datos, y que tiene que definirse y delimitarse de antemano con precisión, además de que debe ser representativo de la población” (Hernández et al., 2010, p. 173). La muestra que se utilizó fue el muestreo exhaustivo. “Se selecciona a toda la población implicada en la problemática a estudiar y no a una muestra” (Sagastizabal y Perlo, p. 85). Dado que la población de la presente investigación consta de 24 personas, y además por ser una investigación-acción, la muestra se limita a toda la población objeto de estudio.

4.3.

Técnicas e Instrumentos de Recogidas de Datos En el presente trabajo de disertación de grado se hizo uso de las siguientes técnicas de

recolección de datos para investigaciones de enfoque mixto:


22 4.3.1. Entrevista. La técnica de la entrevista, una de las más usuales en metodología cualitativa, se concreta en un instrumento por el cual una persona solicita cara a cara información a otra, puede ser desde una conversación libre hasta una interrogación estructurada (Sagastizabal y Perlo, pp. 93).

Se realizó una entrevista inicial dirigida al jefe de departamento de TIC, el Ing. Edison Patrón, con el propósito de conocer los procesos que se realiza para la gestión de los bienes informáticos y asistencia técnica. El instrumento que se utilizo fue un cuestionario como guia para la entrevista. Ver anexo 1. 4.3.2. Encuesta. Este método se basa en la concepción de que los sujetos son la principal fuente de información para conocer determinados aspectos de la realidad. Consiste por lo tanto en la solicitud de información de una persona a otra o a un grupo de personas para obtener datos sobre un problema determinado. (Sagastizabal y Perlo, pp. 93)

Se realizó una encuesta dirigida a todos los funcionarios del MIES, que son la muestra objeto de estudio, y que están involucrados directa o indirectamente en el proceso de gestión de bienes y asistencia técnica en el departamento de TIC con la finalidad de corroborar si están de acuerdo con el director de la institución de desarrollar e implementar un sistema web que mejore el proceso de administración. El instrumento que se utilizo fue una hoja de encuesta. Ver anexo 2.

4.4.

Técnicas de Análisis de Datos “En el proceso cuantitativo primero se recolectan todos los datos y luego se analizan,

mientras que en la investigación cualitativa no es así, sino que la recolección y el análisis ocurren prácticamente en paralelo” (Hernández et al., 2010, p. 418). El análisis de los datos para las encuestas fue estadístico, con ayuda de la tabulación de datos. Para las entrevistas donde se recolectó información específica de la funcionalidad del sistema se usó un análisis cualitativo y se lo plasmó con un diagrama de actividad así como las historias de usuario.


23

5. RESULTADOS 5.1.

Discusión y análisis de los resultados

5.1.1. Análisis situacional de la población para el uso del sistema. 5.1.1.1.

Entrevista al Ing. Edison Patrón del departamento de las TIC en el MIES para determinar los procesos que se realiza en el departamento de las TIC.

En esta investigación se utilizó una entrevista y una grabación como método de recolección de información para extraer cada uno de los procesos que se realizan para la gestión de los bienes informáticos y asistencia técnica en el departamento de las TIC. La entrevista realizada al Ing. Edison Patrón fue la siguiente: ¿Cómo se realiza un registro de un bien informático? El registro se lo realiza describiendo detalladamente todos los datos y características del bien, por medio de una matriz en una hoja de Excel, separándolos por marcas, modelos y series. Cabe destacar que la identificación de cada bien se lleva a cabo por un código único que asigna el MIES ¿Cuál es el proceso de asignación de un bien informático a un funcionario de la institución? En la matriz de Excel donde se registran los equipos informáticos hay un campo extra donde se asigna los datos completos del funcionario que tendrá a su cargo y cuidado dicho bien informantico por un tiempo indefinido. Además se genera un acta en Word especificando los datos anteriormente descritos para ser firmada y archivada como constancia de la asignación realizada. ¿Cómo se efectúa una prestación de un bien informático? El funcionario realiza su petición directamente al ingeniero encargado del área de las TIC, el cual revisa si el bien está disponible, si es así se lo presta por un tiempo establecido según sus necesidades. De la misma manera se genera un acta con un formato establecido en Word con los datos del equipo, funcionario y el tiempo de prestación, se firma y se almacena para la constancia del mismo.


24 ¿Qué sucede si el equipo prestado no se lo entrega en el tiempo establecido? Se envía un correo al funcionario responsable para recordarle la entrega del urgente del equipo o se acerque al departamento de las TIC para renovar la prestación. ¿Qué tipo de asistencias brinda el departamento de las TIC? Se brinda 3 tipos de asistencias como son: Asistencia Técnica, Asistencia de Sistemas y Mantenimiento. ¿En qué se diferencian las asistencias mencionadas? Asistencia Técnica: Es el soporte en el software que se les da a los bienes informáticos en el lugar donde opera dicho equipo. Asistencia de Sistemas: Cuando se le brinda ayuda técnica a las diferentes plataformas institucionales. Mantenimiento: Soporte técnico que se brinda a equipos informáticos cuando estos conllevan mayor tiempo, requiriendo que dichos equipos ingresen al área de las TIC. ¿Se lleva un registro de las asistencias realizadas? Si, en una matriz de Excel se ingresa los datos del funcionario, la fecha y el tipo de ayuda que se brindó. Cabe recalcar que solo se registra un aproximado del 60% de dichas asistencias, esto a causa de que lleva mucho tiempo asentar dicho registro. ¿De qué manera se lleva un control las actividades que debe realizar? Actualmente se realiza mediante un software online llamado “wunderlist” el cual permite agendar cada una de las actividades pendientes, de esta manera, ayuda a recordar y planificar todos los diversos eventos previstos. ¿Requiere la institución la implementación de un software para la gestión de bienes informáticos y asistencia técnica? Sí, porque la información obtenida es amplia y necesita ser registrada de manera adecuada, para que no exista perdida ni duplicación de la misma, con la implementación de


25 un sistema web sería una excelente opción para manejar eficientemente la gestión que se realiza en el departamento de las TIC. ¿En qué cree Usted Que el sistema beneficiara al departamento de las TIC en el MIESS? La información estará organizada y segura, por lo cual todas las actividades y procesos que se llevan a cabo se realizarían de una manera óptima con un tiempo de respuesta mínimo, esto me ayudará a tener más tiempo disponible para atender otras actividades y maximizar mí fuerza de trabajo. 5.1.1.1.1. Discusión de la Entrevista. De acuerdo a la entrevista realizada al jefe de área del departamento de las TIC el Ing. Edison Patrón, y expuesta en el apartado anterior, se pudo extraer de manera más específica los procesos/actividades que se realiza para la gestión de los bienes informáticos y asistencia técnica con el uso de DIAGRAMA DE ACTIVIDADES. Además que se evidencio la necesidad por parte del Departamento de Tics, el desarrollo de un software que le de soporte es sus procesos.

Figura 5. Diagrama de procesos y actividades en la gestión de bienes informáticos y asistencia técnica. Adaptado de investigación de campo.


26 5.1.1.2.

Encuesta a los funcionarios del Ministerio de Inclusión Económica y Social de Santo Domingo de los Tsáchilas.

La encuesta se la aplicó a todos los funcionarios del MIES, que son la muestra objeto de estudio, y que están involucrados directa o indirectamente en el proceso de gestión de bienes y asistencia técnica en el departamento de TIC con la finalidad de corroborar si están de acuerdo con el jefe de departamento de TIC con la propuesta de desarrollar e implementar un sistema web que mejore el proceso de administración. Ver anexo 2. Pregunta 1 ¿Qué tiempo ha tenido que esperar para ser atendido en el departamento de Tics? Tabla 1 Resultados obtenidos de la primera pregunta de la encuesta. ALTERNATIVA FRECUENCIA 3 Al instante 8 Intervalo de 2-5 minutos 13 Superior a 5 minutos 24 TOTAL

PORCENTAJE 12,5% 33,33% 54,16% 100%

Nota: Datos obtenidos de la investigación de campo.

60 50 40 54,16

30 33,33

20 10

12,5

0 Al instante

Intervalo de 2 a 5 minutos

Superior a 5 minutos

Figura 6. Figura obtenida de la primera pregunta de la encuesta. Adaptado de investigación de campo.

Análisis: En los resultados obtenidos en la primera pregunta se puede ver a simple vista que el 54,16% de los encuestados para ser atendidos en el departamento de Tics han tenido que esperar más de 5 minutos. El 33,33% ha tenido que esperar un lapso de tiempo de 2 a 5 minutos; y el 12,5% ha sido atendido al instante.


27 Pregunta 2 ¿Considera usted, que el proceso actual utilizado para realizar el control de bienes informáticos en el departamento de Tics es el más óptimo? Tabla 2 Resultados obtenidos de la segunda pregunta de la encuesta ALTERNATIVA FRECUENCIA SI 4 NO 20 TOTAL 24

PORCENTAJE 16,66% 83,33% 100%

Nota: Datos obtenidos de la investigación de campo.

100 80 60 83,33 40 20

16,66

0 Si

No

Figura7. Figura obtenida de la segunda pregunta de la encuesta. Adaptado de investigación de campo.

Análisis: Los resultados obtenidos en esta pregunta, arrojan que el 83,33% de los encuestados no están de acuerdo que los procesos para el control de bienes informático que se llevan actualmente en el departamento de Tics es el más óptimo. Mientras que el 16,66% si está de acuerdo. Pregunta 3 ¿Considera que las asistencias realizadas se las lleva a cabo de manera ordenada? Tabla 3 Resultados obtenidos de la tercera pregunta de la encuesta ALTERNATIVA FRECUENCIA SI 5 NO 19 TOTAL 24 Nota: Datos obtenidos de la investigación de campo.

PORCENTAJE 20,83% 79,16% 100%


28

80 60 79,16 40 20

20,83

0 Si

No

Figura 8. Figura obtenida de la tercera pregunta de la encuesta. Adaptado de investigación de campo.

Análisis: Los resultados obtenidos de la encuesta, muestran en esta pregunta que el 79,16% de los encuestados consideran que las asistencias realizadas no se las lleva a cabo de manera ordenada; por otra parte el 20,83% creen que las asistencias se las realiza de manera ordenada. Pregunta 4 ¿Cree conveniente automatizar el proceso de asignaciones de bienes informáticos a los funcionarios? Tabla 4 Resultados obtenidos de la cuarta pregunta de la encuesta ALTERNATIVA FRECUENCIA SI 21 NO 3 TOTAL 24 Nota: Datos obtenidos de la investigación de campo.

PORCENTAJE 87,5% 12,5% 100%

100 80 60

87,5

40 20

12,5

0 Si

No

Figura 9. Figura obtenida de la cuarta pregunta de la encuesta. Adaptado de investigación de campo.


29 Análisis: En los resultados de la pregunta cuatro adquiridos de las encuesta reflejan que el 87,5% cree conveniente implementar un sistema web que facilite el proceso de asignaciones de bienes informáticos a los funcionarios El 12,5% cree que es innecesario. Pregunta 5 ¿Le gustaría que el departamento de Tics, cuente con un sistema web para poder visualizar la información de los bienes informáticos que están a su cargo? Tabla 5 Resultados obtenidos de la quinta pregunta de la encuesta ALTERNATIVA FRECUENCIA SI 24 NO 0 TOTAL 24 Nota: Datos obtenidos de la investigación de campo.

PORCENTAJE 100% 0% 100%

100 80 60 40

100

0

20 0 SI

NO

Figura 10. Figura obtenida de la quinta pregunta de la encuesta. Adaptado de investigación de campo.

Análisis: En los resultados adquiridos de la pregunta cinco de la encuesta, refleja que al 100% de los encuestados les gustaría que el departamento de Tics cuente con un sistema web para poder visualizar la información de los bienes informáticos que están a su cargo. Pregunta 6 ¿Está usted de acuerdo que el departamento de Tics disponga de un sistema web para la gestión de bienes informáticos y asistencia técnica? Tabla 6 Resultados obtenidos de la sexta pregunta de la encuesta ALTERNATIVA FRECUENCIA SI 22 NO 2 TOTAL 24 Nota: Datos obtenidos de la investigación de campo.

PORCENTAJE 91.66% 8.33% 100%


30

91,66 100 80 60 40

8,33

20 0 SI

NO

Figura 11. Figura obtenida de la sexta pregunta de la encuesta. Adaptado de investigación de campo.

Análisis: En los resultados adquiridos en la pregunta seis, refleja que el 91,66% de los encuestados consideran conveniente la implementación de un sistema web en el departamento de Tics para el control de bienes informáticos y asistencias técnicas. Un 8.33% no ve la necesidad de la implementación de un sistema web en esta institución. 5.1.1.2.1. Discusión de las encuestas. Luego de realizar las encuestas se pudo evidenciar que la gestión en el del departamento de TIC es deficiente a cuanto al exceso de tiempo y la forma de atender una tarea, las asistencias como las asignaciones de los equipos informáticos no son ni ordenadas, metódicas o reguladas. También se pudo percatar que los funcionarios están de acuerdo con jefe de departamento de TIC de la importancia de desarrollar un sistema web que les permita visualizar los bienes que tiene a su cargo, y en general para mejorar la gestión de bienes informáticos y asistencia técnica, corroborando.

5.2.

Propuesta de intervención

5.2.1. Metodologías de desarrollo del Sistema Web. 5.2.1.1.

Comparación entre metodologías Tradicionales y Metodologías Ágiles.

Es de suma importancia definir la metodología de desarrollo a usar en el sistema web, hay que recalcar que ambos enfoques son buenos, pero se debe seleccionar de forma correcta la línea por donde se guiara el proyecto. A continuación se realizó una tabla comparativa de manera general entre las metodologías Tradicionales y las Ágiles, tomando en cuenta las características más relevantes


31 que de cada una de ellas como lo son: definición, los tipos de proyectos a los que se orienta, la relación del cliente con el programador, como se maneja los avances del sistema, y el tipo de documentación que genera cada metodología, dichos criterios se tomaron de Navarro (2010) en su artículo “Revisión de metodologías ágiles para el desarrollo de software”, después se analizaron cada uno y se asignaron valores de acuerdo a las necesidades del proyecto a realizar, siendo 3 el mayor y 1 el menor puntaje. Tabla 7 Comparación de las metodologías para el desarrollo del software Metodologías para el desarrollo de Software Criterios Metodología tradicional Metodología Ágil Pts Los proyectos son orientados Los proyectos son subdivididos a a procesos rígidos que no pequeños proyectos, incluye más Breve Descripción cambian, los requerimientos 1 comunicación con el cliente y son son definidos hasta la más adaptativos a cambios en los finalización del mismo. requerimientos. Proyectos de grandes Cada proyecto se ajusta a la realidad Tipos de proyecto dimensiones y estructura 2 por su flexibilidad. definida. Relación entre el La comunicación con el La comunicación paralela del 2 cliente y programador cliente es poca cliente y programador es constante. Se realiza un solo entregable Se realiza varios entregables Entrega del proyecto 1 al finalizar el proyecto durante el proyecto (avances) Documentación Amplia 1 Corta TOTAL 7

Pts 3

3 3 3 2 14

Nota: Adaptado de “Revisión de metodologías ágiles para el desarrollo de software” por A .Navarro, J. D. Fernández, y J. Morales, 2013, Prospect, 11, p. 31.

Como podemos observar las metodologías tradicionales cumplen un 20% con los requisitos generales de nuestro proyecto, mientras que las metodologías ágiles cumplen al 100% con nuestros requisitos. Por tanto para el presente proyecto usaremos una de las metodologías agiles para el desarrollo del software. 5.2.1.2.

Comparación de agilidad entre modelos ágiles XP y Scrum.

Una metodología de desarrollo de software cuando se orienta a la comunicación, es adaptable al cambio, iterativo y eficiente entonces se dice que es un método basado en agilidad. A continuación se analizará los métodos ágiles XP y Scrum por ser los métodos que mejor se adaptan a la naturaleza de este proyecto. Los criterios de evaluación para la comparativa éstas metodologías ágiles fueron extraídos de Qumer & Henderson (2006), cabe recalcar que el presente proyecto usó el método 4-DAT (Dimensiones para el análisis de herramientas) propuesto por Asif Qumer y Brian Henderson-Sellers. 4-DAT fue desarrollado para investigadores y profesionales con el propósito de analizar y comparar métodos ágiles. 4-DAT tiene cuatro dimensiones que proporcionan criterios de evaluación para la evaluación detallada de los métodos ágiles de desarrollo de


32 software desde diferentes perspectivas: alcance de la metodología, caracterización de la agilidad, valores ágiles (Manifiesto Ágil) y caracterización del proceso de software. Estas dimensiones fueron desarrolladas utilizando conceptos previamente publicados sobre agilidad, métodos ágiles de desarrollo de software, métodos tradicionales de desarrollo de software, valores ágiles y principios ágiles. (Qumer & Henderson, 2006). Tabla 8 Dimensión 1: alcance de la Metodología XP y Scrum Criterio Tamaño del proyecto Tamaño del equipo Estilo de desarrollo Estilo de código Entorno Tecnológico Entorno Físico Cultura de negocio Mecanismo de Abstracción

XP justificación pequeños y mediano 2 a 10 iterativo y eficiente limpio y sencillo requiere rápida retroalimentación equipos en un mismo lugar y equipos distribuidos colaborativo y cooperativo orientado a objeto

SCRUM Justificación pequeños, medianos y grandes 3a9 iterativo y eficiente no especificado no especificado no especificado no especificado orientado a objeto

Nota: Adaptado de “Evaluación comparativa de XP y Scrum usando la herramienta de análisis 4D (4-DAT)” por A. Qumer, & B. Henderson-Sellers, 2006, En Proceedings of the European and Mediterranean Conference on Information System (EMCIS), España.

Tabla 9 Dimensión 2: grado de agilidad metodología XP XP Criterio Características de Agilidad FY SD LS LG (i)Fases Exploración 1 1 0 1 1 1 0 1 Planificación 1 1 0 1 Iteración para remplazar 1 1 1 1 Producción 1 0 0 1 Mantenimiento 0 1 0 0 Muerte Total 5 5 1 5 Grado de agilidad 0,83 0,83 0,17 0,83 (ii)Prácticas 1 1 0 1 Juego de planificación 1 1 0 1 Entregables cortos 0 1 1 0 Metáfora 1 1 1 1 Diseño simple 1 1 0 1 Pruebas 1 1 1 1 Refactorización 1 0 0 1 Programación en parejas 1 0 0 1 Propiedad colectiva del código 1 1 1 1 Integración continua 0 0 0 1 Semana de 40 horas 1 0 0 1 Cliente en el sitio 1 1 1 1 Normas de codificación Total 10 8 5 11 Grado de agilidad 0,83 0,67 0,42 0,92 PROMEDIO 0,833 0,75 0,292 0,875

Total RS 1

4 1 1 1 1 0 5 0,83

4 4 5 3 1 21 0,7

1 1 0 1 1 1 1 1 1 0 1 1 10 0,83 0,833

4 4 2 5 4 5 3 3 5 1 3 5 44 3,67 2,18

Nota: Características de agilidad: Flexibilidad (FY) ¿El método acomoda cambios esperados o inesperados?, Velocidad (SD) ¿El método produce resultados rápidamente?, Leanness (LS) ¿El método sigue el lapso de tiempo más corto, utiliza instrumentos económicos, simples y de calidad para la producción?, Aprendizaje (LG) ¿El método aplica conocimientos previos actualizados y experiencia para aprender?, y Capacidad de respuesta (RS) ¿El método muestra sensibilidad? Fuente: Adaptado de “Evaluación comparativa de XP y Scrum usando la herramienta de análisis 4D (4-DAT)” por A. Qumer, & B. Henderson-Sellers, 2006, En Proceedings of the European and Mediterranean Conference on Information System (EMCIS), España.


33 Tabla 10 Dimensión 2: grado de agilidad metodología Scrum Criterio FY (i)Fases Planificación Desarrollo Cierre Total Grado de agilidad (ii)Prácticas Scrum Master Equipo Scrum Lista de Productos Sprint Reunión de Planificación Reunión Scrum diaria Revisión del Sprint Total Grado de agilidad PROMEDIO

SCRUM Características de Agilidad SD LS LG RS

Total

1 1 0 2 0,67

1 1 1 3 1

0 0 0 0 0

1 1 0 2 0,67

1 1 0 2 0,67

4 4 1 9 3

1 1 1 1 1 1 1 7 0,88 0,77

1 1 1 1 1 1 1 7 0,88 0,94

0 0 0 0 0 0 0 0 0 0

1 1 1 1 1 1 1 7 0,88 0,77

1 1 1 1 1 1 1 7 0,88 0,77

4 4 4 4 4 4 4 28 3,5 3,25

Nota: Características de agilidad: Flexibilidad (FY) ¿El método acomoda cambios esperados o inesperados?, Velocidad (SD) ¿El método produce resultados rápidamente?, Leanness (LS) ¿El método sigue el lapso de tiempo más corto, utiliza instrumentos económicos, simples y de calidad para la producción?, Aprendizaje (LG) ¿El método aplica conocimientos previos actualizados y experiencia para aprender?, y Capacidad de respuesta (RS) ¿El método muestra sensibilidad? Fuente Adaptado de “Evaluación comparativa de XP y Scrum usando la herramienta de análisis 4D (4-DAT)” por A. Qumer, & B. Henderson-Sellers, 2006, En Proceedings of the European and Mediterranean Conference on Information System (EMCIS), España.

Tabla 11 Dimensión 3: valores ágiles metodología XP y Scrum Criterio Individuos e encima de herramientas

iteraciones procesos

Software activo encima documentación comprensiva

por y

de

Colaboración con el cliente más que la negociación de un contrato. Responder a los cambios más que seguir estrictamente un plan Manteniendo de procesos ágiles. Mantener la rentabilidad de los procesos

            

XP justificación Juego de planificación. Propiedad colectiva. Cliente en el equipo desarrollo. Programación en pareja Entregables cortos. Pruebas. Integración continúa. Juego de planificación. Cliente en el equipo desarrollo. Metáforas. Diseño simple. Refactorización. Estándar de codificación. -

SCRUM Justificación

de

de

  

Equipo Scrum. Reunión de Planificación. Reuniones Scrum diarias.

 

Sprint. Revisión de Sprint.

 

Lista de Productos. Reunión de Planificación

 

Revisión del Sprint. Reunión de Planificación

 

Revisión del Sprint Reuniones Scrum diarias. -

Nota: Adaptado de “Evaluación comparativa de XP y Scrum usando la herramienta de análisis 4D (4-DAT)” por A. Qumer, & B. Henderson-Sellers, 2006, En Proceedings of the European and Mediterranean Conference on Information System (EMCIS), España.


34 Tabla 12 Dimensión 4: características del proceso de Software metodología XP y Scrum XP SCRUM Criterio Justificación Justificación 1. Entregables cortos. 2. Metáforas. 3. Diseño simple. 4. Pruebas. 11. Equipo Scrum 5. Refactorización. 12. Lista de trabajo Proceso de desarrollo 6. programación en parejas 13. Sprint 7. Propiedad colectiva. 14. Revisión del Sprint 8. Integración continúa. 9. Cliente en el equipo de desarrollo. 10. Estándar de codificación. 16. Scrum Master. Proceso de gestión de proyecto 15. Juego de planificación. 17. Reunión de Planificación 18. Reuniones Scrum diaria Proceso de la configuración del No especificado No especificado software Proceso de gestión de procesos No especificado No especificado Nota: Adaptado de “Evaluación comparativa de XP y Scrum usando la herramienta de análisis 4D (4-DAT)” por A. Qumer, & B. Henderson-Sellers, 2006, En Proceedings of the European and Mediterranean Conference on Information System (EMCIS), España.

Este análisis utilizó un enfoque tanto cualitativo como cuantitativo para evaluar los métodos ágiles tanto en el nivel de fase como en el nivel de práctica, y se concluyó que la metodología XP por sus características se considera ágil y adaptable al desarrollo del presente trabajo de investigación, además cabe recalcar que XP agrupa muchas de las llamadas “buenas prácticas de desarrollo de software” situadas en las más importantes y utilizadas metodologías ágiles encontradas en la literatura. 5.2.2. Herramientas para el desarrollo del sistema web. 5.2.2.1.

Comparación de Framework en PHP basados en el patrón MVC.

Un framework es un marco trabajo para el desarrollo de un software y en la actualidad los desarrolladores web usan esta herramienta como pauta que faciliten su trabajo de desarrollo y mantenimiento: separación de presentación y lógica, una sintaxis coherente, etc. Al usar un framework el programador no necesita plantearse una estructura global de la aplicación, sino que el framework le proporciona un esqueleto que hay que “rellenar”. También facilita la colaboración, pues el código va a estar estandarizado y esto conlleva al ahorro de tiempo y recurso en el mantenimiento. Y sobre todo cada framework viene con librerías que facilitan el desarrollo web.


35 A continuación se elaboró una tabla comparativa general de los framework más utilizados como lo son CodeIgniter, Laravel, Yii y Symfony con el propósito de conocer, analizar y decidir el más adecuado, los criterios señalados fueron postulados por Sierra et al. (2013) donde refiere que la elección de un framework en específico se basa en algunos factores, como por ejemplo, en el presente proyecto se analizó framework basados en PHP y el patrón MVC, por ser del conocimiento de los disertantes.


36 Tabla 13 Comparativa de los Framework CodeIgniter, Symfony, Laravel y Yii. Características Framework CodeIgniter

Symfony

Laravel

Yii

Ventajas

Inconvenientes

Ofrece un marco con una pequeña huella. Tiene un excelente rendimiento. Documentación completa. Ofrece una amplia contabilidad con alojamiento estándar. Casi que utiliza cero configuración. Pasar más tiempo lejos de la computadora. Soluciones simples. Fácil de instalar y usar en la mayoría de plataformas, se extender permite una mejor integración de bibliotecas.

La compatibilidad con tantas versiones de PHP hace que no podamos hablar de un framework completamente Orientado a Objetos.

Además de manejar el MVC también cuenta con el uso de mapeo objeto-relacional.

Es relativamente nuevo y muchos dejan de utilizarlo porque creen que no es confiable

Un poco más fácil de aprender que otros framework, cuenta con foro y IRC que proporciona ayuda al usuario.

Se genera código basura y en ocasiones no lo filtra de la mejor forma y complica el uso de este.

Múltiple BD

ORM

Plantill as

Cache

Ajax

Autenticació n

Módu-los

si

no

si

si

no

no

no

si

no

si

no

si

si

si

si

si

si

si

si

si

si

no

si

si

no

si

si

si

No es muy robusto

Nota: Múltiple BD, indica si el framework soporta múltiples bases de datos sin tener que cambiar nada. ORM, indica si el framework soporta un mapeador objeto-record, generalmente una implementación de ActiveRecord. Plantillas, indica si el framework tiene un motor de plantillas incorporado. Cache, indica si el framework incluye un objeto de almacenamiento en caché o alguna manera otra forma de almacenamiento en caché. Ajax, indica si el framework viene con soporte incorporado para Ajax. Módulo de autenticación, indica si el framework tiene un módulo incorporado para el manejo de la autenticación de usuario. Módulos indica si el framework tiene otros módulos, como una alimentación de RSS, módulo analizador PDF o cualquier otra cosa (útil). Fuente: Adaptado de “Estudio y análisis de los framework en php basados en el modelo vista controlador para el desarrollo de software orientado a la web” por F. Sierra, J. Acosta, J. Ariza, M. Salas, 2013, Investigación y Desarrollo en TIC, 4, p. 10.


37 En la Tabla 13, se mencionó las ventajas donde encontramos que por ser basados en lenguaje PHP, los framework antes descritos son fáciles de aprender, otro punto que se señaló fueron los inconvenientes y como resultado vemos que Laravel es que menos inconvenientes técnicos tiene, por otro lado se comparó también las características, y vemos que todo los framework a excepción de Yii, manejan múltiples BD, lo que significa que tienen compatibilidad con cualquier base de datos, sin necesidad de cambiar ningún archivo de configuración o de agregar algún complemento. Con respecto al mapeo de objeto relacional encontramos que solo Laravel y Yii cumplen con éstas características. Todos los framework descritos traen sus plantillas predeterminadas, para el inicio de desarrollo web. En cuanto al almacenamiento en caché lo cumplen Laravel y CodeIgniter. También se determinó que todos los framework descritos, a excepción de CodeIgniter usan plugins de Ajax. Otras dos comparativa fueron la autenticación que es la que indica si el framework tiene un módulo incorporado para el manejo de la autenticación de usuario o no, y la segunda es la sección de módulos, que es donde se establece si el framework tiene un analizador PDF, alimentación de RSS, por tanto se observa que todos los framework descritos, a excepción de CodeIgniter cumplen con estas características. Por todo lo puntualizado anteriormente se utilizó el framework Laravel en la versión 5.4 para el desarrollo del software. 5.2.2.2.

Laragon.

Una vez que se definió el framework Laravel para el desarrollo del sistema web, y siendo éste basado en el lenguaje PHP, entonces como suite o entorno de desarrollo hay dos posibles opciones Laragon y Homestead. Laravel Homestead proporciona un maravilloso entorno de desarrollo sin necesidad de instalar PHP, un servidor web o cualquier otro software de servidor en su máquina local, se ejecuta en cualquier sistema Windows, Mac o Linux e incluye el servidor web Nginx, PHP 7.1, MySQL, PostgreSQL, Redis, Memcached, Node y todos los demás recursos que necesita para desarrollar sorprendentes aplicaciones de Laravel. Laragon es una suite de desarrollo para PHP que funciona sobre Windows diseñado especialmente para trabajar con Laravel, nos permite crear un entorno de desarrollo con estas características Cmder (Consola para Windows), Git, Node.js, npm, SSH, Putty, PHP 7 / 5.6,


38 Extensiones de PHP, xDebug, Composer, Apache, MariaDB/MySQL, phpMyAdmin, Soporte para Laravel y Lumen, Gestión automática de Virtualhosts. Homestead es la opción más recomendada puesto que es una herramienta oficialmente soportada por Laravel, sin embargo, es una máquina virtual de 64 bits que consume una cantidad considerable de recursos como espacio en disco y memoria RAM. Por Tanto se utilizó Laragon como alternativa pues ofrece todo lo que necesita para construir aplicaciones web modernas, es portátil y muy flexible. 5.2.2.3.

Sublime Text.

Para la codificación se utilizó sublime text v3, por ser una herramienta de conocimiento de los disertantes. Sublime Text es un excepcional editor de textos que aporta muchas características útiles a la hora de programar o editar código. El editor está cargado de funcionalidades útiles y cómodas desde el punto de la usabilidad y eficiencia, utilizando el método geek y convirtiendo nuestro trabajo de edición de texto en una experiencia cada vez más sencilla y agradable, a medida que vamos aprendiendo a utilizar todas sus funcionalidades. (Manz, 2014) 5.2.3. Proceso de desarrollo de software usando Programación Extrema (XP). 5.2.3.1.

Etapa 1: Planeación.

Para la realización de nuestro proyecto mediante la metodología XP se efectuó una reunión para la planificación de liberación en el cual nos reunimos en un lugar específico a las 2pm, donde estuvo presente el manager XP, los desarrolladores y el cliente, con una duración de 2 horas. 5.2.3.1.1. Calendario de trabajo. Tabla 14 Calendario de Trabajo MES 1

SEMANAS 4

CALENDARIO DE TRABAJO DIAS 5

Nota: Datos obtenidos de la investigación de campo.

HORAS 4 (14pm-18pm)


39 Detallamos el calendario de trabajo, en el cual especificamos que en el mes tomamos de referencia 4 semanas de las cuales cada semana vamos a trabajar 5 días y cada día 4 horas completando en el mes 80 horas de trabajo. La técnica utilizada es Días Ideales y la métrica Punto de Historia. 5.2.3.1.2. Esfuerzo desarrollado. Tabla 15 Esfuerzo desarrollado PERSONA 2

ESFUERZO DESARROLLADO DIA HORA 1 4

Punto de esfuerzo 1

Nota: Datos obtenidos de la investigación de campo.

En el desarrollo del proyecto de investigación vamos a realizar dos personas y en cada día se va a trabajar 4 horas. 5.2.3.1.3. Plan de entrega. A continuación se detalla el plan de entrega en su última versión, donde se describe los atributos para cada iteración del proyecto. Tabla 16 Plan de Entrega N°

Historias de Usuario

1 2 3 4 5 6 7 8 9 10 11 12

Login Administración de Departamentos Administración de Funcionarios Administración de Usuarios Administración de Marcas Administración de Categorías Administración de Bienes Listado de Bienes Asignados Administración de Sistemas Registro de Asistencia Técnica Registro de Asistencia de Sistemas Registro de Mantenimientos Registro de Asignaciones Temporales Registro de Asignaciones Permanentes Visualización de bienes asignados Gestionar Agenda

13 14 15 16

Tiempo estimado Días 2 6 6 3 3 3 4 1 3 6 3 2

Prioridad de negocio Alto Alto Alto Alto Alto Alto Alto Alto Alto Alto Alto Alto

Riesgo en el desarrollo Medio Alto Medio Medio Medio Medio Alto Bajo Medio Alto Medio Medio

Medio

Alto

7

X

Medio

Medio

2

X

Bajo Bajo

Medio Bajo

2 3

X X

Nota: Datos obtenidos de la investigación de campo.

Release Asignada 1 X X X

2

3

4

X X X X X X X X X


40 5.2.3.1.4. Plan de iteración. Tabla 17 Plan de Iteración: primera iteración Iteración Historia de Módulo Asignada Usuario Login

Login

Departamentos

Administración de Departamentos

1

Funcionarios

Administración de Funcionarios

Tareas de Ingeniería

Días

Diseño de la interfaz de Login Asignar las rutas de login Crear la migración de departamento Ejecutar la migración de departamento Crear el modelo: Model Departamento Crear las vistas de departamentos Crear el controlador DepartamentoController Asignar las rutas de la tabla departamento Crear la migración de funcionario Ejecutar la migración de funcionario Crear el modelo: Model Funcionario Crear las vistas de funcionarios Crear el controlador FuncionarioController Asignar las rutas de la tabla funcionario Pruebas

1 1

Semanas

1 1 2 1 1

3 semanas

1 1 2 1 1 1

Nota: Datos obtenidos de la investigación de campo.

Tabla 18 Plan de Iteración: segunda iteración Iteración Asignada Historia de Módulo Usuario 2 Usuarios Administració n de Usuarios

Bienes

Administració n de marcas

Administració n de categorías

Administració n de Bienes

Listado de Bienes Asignados

Tareas de Ingeniería Crear la migración de usuario Ejecutar la migración de usuario Crear el modelo: model Usuario Crear las vistas de usuario Crear el controlador UsuarioController Asignar las rutas de la tabla usuario Crear la migración de marca Ejecutar la migración de marca Crear el modelo: Model Marca Crear las vistas de marcas Crear el controlador MarcaController Asignar las rutas de marcas Crear la migración de categoría Ejecutar la migración de categoría Crear el modelo: Model Categoría Crear las vistas de categorías Crear el controlador CategoríaController Asignar las rutas de categorías Crear la migración de bien Ejecutar la migración de bien Crear el modelo: Model Bien Crear las vistas de bienes Crear el controlador BienController Asignar las rutas de bienes Crear las vistas de bienes asignados Asignar las rutas Pruebas

Nota: Datos obtenidos de la investigación de campo.

Días

Semanas

1

3 semanas

1 1 1

1 1 1

1 1 1 1 1 1 1 1


41 Tabla 19 Plan de Iteración: tercera iteración Iteración Módulo Historia de Usuario Asignada

3

Tareas de Ingeniería

Días Semanas

Crear la migración de sistemas Ejecutar la migración de sistemas Crear el modelo: Model Sistema Administración de Sistemas Crear las vistas de sistema sistemas Crear el controlador SistemaController Asignar las rutas de sistemas Crear la migración de asistencia Ejecutar la migración de asistencia Crear el modelo: Model Asistencia Registro de asistencias Crear las vistas de asistencias técnicas técnicas Crear el controlador AsistenciaController Asignar las rutas de asistencias Asistencias técnicas Crear las vistas de asistencias de sistemas Registro de asistencias Asignar las rutas de asistencias de de sistemas sistemas Crear las vistas de mantenimientos Registro de Crear las rutas de mantenimientos mantenimientos Pruebas

1 1 1 1 1 2

3

1 1 2 1 1 1 1

Nota: Datos obtenidos de la investigación de campo.

Tabla 20 Plan de Iteración: cuarta iteración Iteración Módulo Historia de Usuario Asignada

Administración de Asignaciones permanentes Visualización de los bienes asignados

Agenda

Gestionar Agenda

Nota: Datos obtenidos de la investigación de campo.

Tareas de Ingeniería Crear la migración de EncabezadoActa y Detalle Acta Ejecutar la migración Crear el modelo: Model EncabezadoActa Crear el modelo: Model DetalleActa Crear las vistas de Asignaciones temporales Crear el controlador EncabezadoActaController Crear el controlador DetalleActaController Asignar las rutas de asignaciones temporales Crear las vistas de Asignaciones permanentes Asignar las rutas de asignaciones permanentes Crear las vistas de Asignaciones Asignar las rutas de asignaciones Crear la migración Ejecutar la migración Crear el modelo: Model Agenda Crear las vistas de agenda Crear el controlador AgendaController Asignar las rutas Pruebas

Días

Semanas

1

1 2 1 1 1 1 1 1 1 1 1 1 1

3 semanas


42 5.2.3.1.5. Historias de usuario. Las historias de usuario están desarrolladas en dependencia de la funcionalidad de la institución, las cuales están estimadas por “DIAS IDEALES”. Tabla 21 Historia de Usuario 1 Historia de Usuario Número: 1 Usuario: Usuario Nombre historia: Login Prioridad en negocio: Alto Riesgo en desarrollo: Medio Puntos estimados: 2 Iteración asignada: 1 Programador responsable: Bella Calle-Jazmín Gaibor Descripción: COMO usuario QUIERO digitar el usuario y contraseña PARA acceder al sistema. Escenario de prueba: DADO el ingreso correcto de usuario y contraseña CUANDO presiono el botón LOGIN ENTONCES accedo al menú principal. DADO el ingreso incorrecto de usuario o contraseña CUANDO presiono el botón LOGIN ENTONCES aparece un mensaje “Estas credenciales no coinciden con nuestros registros”. Nota: Datos obtenidos de la investigación de campo.

Tabla 22 Historia de Usuario 2 Historia de Usuario Usuario: Administrador Número: 2 Nombre historia: Administración departamentos Prioridad en negocio: Alto Riesgo en desarrollo: Medio Puntos estimados: 6 Iteración asignada: 1 Programador responsable: Bella Calle -Jazmín Gaibor Descripción: COMO Administrador, QUIERO añadir nuevos departamentos PARA llevar un registro de departamentos existentes en el Mies. Escenario de prueba: DADO el ingreso correcto de los datos de departamentos CUANDO presiono el botón guardar departamento ENTONCES aparece un mensaje “Departamento Creado”. DADO el ingreso incompleto de los datos de departamentos CUANDO presiono el botón guardar departamento ENTONCES aparece un mensaje “Completa este campo”. DADO la actualización de los datos de departamentos CUANDO presiono el botón guardar departamento ENTONCES aparece un mensaje “Departamento Actualizado!”. Nota: Datos obtenidos de la investigación de campo.

Tabla 23 Historia de usuario 3 Historia de Usuario Usuario: Administrador Número: 3 Nombre historia: Administración de funcionarios Prioridad en negocio: Alto Riesgo en desarrollo: Alto Puntos estimados: 6 Iteración asignada: 1 Programador responsable: Bella Calle -Jazmín Gaibor Descripción: COMO Administrador, se QUIERE crear nuevos funcionarios PARA tener la información actualizada de funcionarios. Escenario de prueba: DADO el ingreso correcto de los datos de los funcionarios CUANDO presiono el botón guardar funcionario ENTONCES aparece un mensaje “Funcionario creado!” DADO el ingreso incompletos de los datos obligatorios de los funcionarios CUANDO presiono el botón guardar funcionario ENTONCES aparece un mensaje “Completa este campo”. DADO la actualización correcta de los datos de los funcionarios CUANDO presiono el botón guardar funcionario ENTONCES aparece un mensaje “Funcionario Actualizado!”. Nota: Datos obtenidos de la investigación de campo.


43 Tabla 24 Historia de usuario 4 Historia de Usuario Usuario: Administrador Número: 4 Nombre historia: Administración de usuarios Prioridad en negocio: Alto Riesgo en desarrollo: Medio Puntos estimados: 3 Iteración asignada: 2 Programador responsable: Bella Calle-Jazmín Gaibor Descripción: COMO Administrador, QUIERO crear nuevos usuarios PARA tener la información actualizada. Escenario de prueba: DADO el ingreso correcto de los datos de los usuarios CUANDO presiono el botón guardar usuario ENTONCES aparece un mensaje con “User creado!”. DADO el ingreso de datos incompletos de los datos de los usuarios CUANDO presiono el botón guardar usuario ENTONCES aparece un mensaje “Completa este campo”. DADO la actualización correcta de los datos de los usuarios CUANDO presiono el botón guardar usuario ENTONCES aparece un mensaje “User Actualizado!”. Nota: Datos obtenidos de la investigación de campo.

Tabla 25 Historia de usuario 5 Historia de Usuario Usuario: Administrador Número: 5 Nombre historia: Administración de marcas Prioridad en negocio: Alto Riesgo en desarrollo: Medio Puntos estimados: 3 Iteración asignada: 2 Programador responsable: Bella Calle -Jazmín Gaibor Descripción: COMO Administrador, QUIERO añadir nuevas marcas PARA llevar un registro de las marcas existentes de los bienes informáticos que hay en el Mies. Escenario de prueba: DADO el ingreso correcto de los datos de marcas CUANDO presiono el botón guardar marca ENTONCES aparece un mensaje “Marca creada!” DADO el ingreso incompleto de los datos de marcas CUANDO presiono el botón guardar marca ENTONCES aparece un mensaje “Completa este campo!” DADO la actualización correcta de los datos de las marcas CUANDO presiono el botón guardar marca ENTONCES aparece un mensaje “Marca Actualizado!”. Nota: Datos obtenidos de la investigación de campo.

Tabla 26 Historia de usuario 6 Historia de Usuario Usuario: Administrador Número: 6 Nombre historia: Administrador de categorías Prioridad en negocio: Alto Riesgo en desarrollo: Medio Puntos estimados: 3 Iteración asignada: 2 Programador responsable: Bella Calle -Jazmín Gaibor Descripción: COMO Administrador, QUIERO añadir nuevas categorías de bienes informáticos PARA llevar un registro de categorías y poder vincular al registrar un bien. Escenario de prueba: DADO el ingreso correcto de los datos de categorías CUANDO presiono el botón guardar categoría ENTONCES aparece un mensaje “Categoría creada!” DADO el ingreso incompleto de los campos de categorías CUANDO presiono el botón guardar categoría ENTONCES aparece un mensaje “Completa este campo” DADO la actualización correcta de los datos de categorías CUANDO presiono el botón guardar categoría ENTONCES aparece un mensaje “Categoría Actualizada!”. Nota: Datos obtenidos de la investigación de campo.


44 Tabla 27 Historia de usuario 7 Historia de Usuario Usuario: Administrador Número: 7 Nombre historia: Administración de bienes Prioridad en negocio: Alto Riesgo en desarrollo: Alto Puntos estimados: 4 Iteración asignada: 2 Programador responsable: Bella Calle -Jazmín Gaibor Descripción: COMO Administrador, QUIERO añadir nuevos bienes PARA llevar un registro de los bienes informáticos que hay en el Mies. Escenario de prueba: DADO el ingreso correcto de los datos de los bienes informáticos CUANDO presiono el botón guardar bien ENTONCES aparece un mensaje “Bien creado!” DADO el ingreso incompleto de los datos obligatorios de los bienes informáticos CUANDO presiono el botón guardar bien ENTONCES aparece un mensaje “Completa este campo”. DADO la actualización correcta de los datos del bien CUANDO presiono el botón guardar bien ENTONCES aparece un mensaje “Bien Actualizado!”. Nota: Datos obtenidos de la investigación de campo.

Tabla 28 Historia de usuario 8 Historia de Usuario Usuario: Administrador Número: 8 Nombre historia: Listado de bienes asignados Prioridad en negocio: Alto Riesgo en desarrollo: Bajo Puntos estimados: 1 Iteración asignada: 2 Programador responsable: Bella Calle -Jazmín Gaibor. Descripción: COMO Administrador QUIERO poder visualizar el listado de todos los bienes asignados con sus respectivos custodios PARA tener un registro ordenado de todos los bienes. Escenario de prueba: DADO el listado de bienes asignados CUANDO presiono el botón Asignados ENTONCES nos muestra una tabla con información detallada de cada bien asignado con su respectivo custodio. Nota: Datos obtenidos de la investigación de campo.

Tabla 29 Historia de usuario 9 Historia de Usuario Usuario: Administrador Número: 9 Nombre historia: Administración de sistemas Prioridad en negocio: Alto Riesgo en desarrollo: Medio Puntos estimados: 3 Iteración asignada: 3 Programador responsable: Bella Calle -Jazmín Gaibor Descripción: COMO Administrador, QUIERO añadir nuevos sistemas PARA llevar un registro de los sistemas que utilizan en el Mies. Escenario de prueba: DADO el ingreso correcto de los datos de los tipos de sistemas CUANDO presiono el botón guardar sistema ENTONCES aparece un mensaje “Sistema creado!” DADO el ingreso incompletos de los datos de los tipos de sistemas CUANDO presiono el botón guardar sistema ENTONCES aparece un mensaje “Completa este campo” DADO la actualización correcta de los datos del tipo de sistema CUANDO presiono el botón guardar sistema ENTONCES aparece un mensaje “Sistema Actualizado!”. Nota: Datos obtenidos de la investigación de campo.


45 Tabla 30 Historia de usuario 10 Historia de Usuario Usuario: Administrador Número: 10 Nombre historia: Registro de asistencias técnica. Prioridad en negocio: Alto Riesgo en desarrollo: Alto Puntos estimados: 6 Iteración asignada: 3 Programador responsable: Bella Calle -Jazmín Gaibor Descripción: COMO Administrador, QUIERO añadir nuevas asistencias técnicas PARA llevar un registro de las asistencias de técnicas que se realizan desde el departamento de Tics en el Mies. Escenario de prueba: DADO el ingreso correcto de los datos de las asistencias técnicas CUANDO presiono el botón guardar asistencia ENTONCES aparece un mensaje “Asistencia creada!” DADO el ingreso incompleto de los datos de las asistencias técnicas CUANDO presiono el botón guardar asistencia ENTONCES aparece un mensaje “Completa este campo”. DADO la actualización correcta de los datos de las asistencias técnicas CUANDO presiono el botón guardar asistencia ENTONCES aparece un mensaje “Asistencia Actualizado!”. Nota: Datos obtenidos de la investigación de campo.

Tabla 31 Historia de usuario 11 Historia de Usuario Usuario: Administrador Número: 11 Nombre historia: Registro de asistencias de sistemas Prioridad en negocio: Alto Riesgo en desarrollo: Medio Puntos estimados: 3 Iteración asignada:3 Programador responsable: Bella Calle -Jazmín Gaibor. Descripción: COMO Administrador, QUIERO registrar nuevas asistencias de sistemas PARA llevar un registro de las asistencias de sistemas que se realizan desde el departamento de Tics en el Mies. Escenario de prueba: DADO el ingreso correcto de los datos de las asistencias de sistemas CUANDO presiono el botón guardar asistencia ENTONCES aparece un mensaje “Asistencia creada!” DADO el ingreso incompleto de los datos de las asistencias de sistemas CUANDO presiono el botón guardar asistencia ENTONCES aparece un mensaje de “Completa este campo”. DADO la actualización correcta de los datos de las asistencias de sistemas CUANDO presiono el botón guardar asistencia ENTONCES aparece un mensaje “Asistencia Actualizado!”. Nota: Datos obtenidos de la investigación de campo.

Tabla 32 Historia de usuario 12 Historia de Usuario Usuario: Administrador Número: 12 Nombre historia: Registro de mantenimientos Prioridad en negocio: Alto Riesgo en desarrollo: Medio Puntos estimados: 2 Iteración asignada: 3 Programador responsable: Bella Calle -Jazmín Gaibor. Descripción: COMO Administrador, QUIERO añadir nuevos mantenimientos PARA llevar un registro de los mantenimientos que se realizan desde el departamento de Tics en el Mies. Escenario de prueba: DADO el ingreso correcto de los datos de los mantenimiento CUANDO presiono el botón guardar asistencia ENTONCES aparece un mensaje “Asistencia creada!” DADO el ingreso incompleto de los datos de los mantenimientos CUANDO presiono el botón guardar asistencia ENTONCES aparece un mensaje de “Completa este campo”. DADO la actualización correcta de los datos de los mantenimientos CUANDO presiono el botón guardar asistencia ENTONCES aparece un mensaje “Asistencia Actualizada!”. Nota: Datos obtenidos de la investigación de campo.


46 Tabla 33 Historia de usuario 12 Historia de Usuario Usuario: Administrador Número: 13 Nombre historia: Registro de asignaciones temporales Prioridad en negocio: Medio Riesgo en desarrollo: Alto Puntos estimados: 7 Iteración asignada: 4 Programador responsable: Bella Calle -Jazmín Gaibor. Descripción: COMO Administrador, QUIERO añadir nuevas asignaciones temporales de bienes informáticos PARA tener un registro y llevar un control de las asignaciones temporales realizadas en la institución. Escenario de prueba: DADO el ingreso correcto de los datos de las asignaciones temporales CUANDO presiono el botón guardar datos ENTONCES aparece un mensaje “Asignación Temporal creada!” DADO el ingreso correcto de los detalles de la asignación CUANDO presiono el botón generar acta ENTONCES aparece un acta con formato PDF como constancia de la asignación realizada. DADO el ingreso incompleto de los datos de las asignaciones temporales CUANDO presiono el botón guardar datos ENTONCES aparece un mensaje “Completa este campo”. Nota: Datos obtenidos de la investigación de campo.

Tabla 34 Historia de usuario 14 Historia de Usuario Usuario: Administrador Número: 14 Nombre historia: Registro de asignaciones permanentes Prioridad en negocio: Medio Riesgo en desarrollo: Medio Puntos estimados: 2 Iteración asignada: 4 Programador responsable: Bella Calle -Jazmín Gaibor. Descripción: COMO Administrador, QUIERO añadir nuevas asignaciones permanentes de bienes informáticos PARA tener un registro y llevar un control de las asignaciones permanentes realizadas en la institución. Escenario de prueba: DADO el ingreso correcto de los datos de las asignaciones temporales CUANDO presiono el botón guardar datos ENTONCES aparece un mensaje “Asignación Temporal creada!” DADO el ingreso correcto de los detalles de la asignación CUANDO presiono el botón generar acta ENTONCES aparece un acta con formato PDF como constancia de la asignación realizada. DADO el ingreso incorrecto de los datos de las asignaciones temporales CUANDO presiono el botón guardar datos ENTONCES aparece un mensaje “Completa este campo”. Nota: Datos obtenidos de la investigación de campo.

Tabla 35 Historia de usuario 15 Historia de Usuario Usuario: Administrador Número: 15 Nombre historia: Visualizaciones de asignaciones Prioridad en negocio: Bajo Riesgo en desarrollo: Medio Puntos estimados: 3 Iteración asignada: 4 Programador responsable: Bella Calle -Jazmín Gaibor. Descripción: COMO Usuario, QUIERO poder visualizar las asignaciones que tengo a mi nombre PARA tener un control y verificar que todos los datos sean correctos. Escenario de prueba: DADO el ingreso correcto del correo y clave CUANDO presiono el botón login ENTONCES aparece los datos detallados de todas las asignaciones que he realizado. Nota: Datos obtenidos de la investigación de campo.


47 Tabla 36 Historia de usuario 16 Historia de Usuario Usuario: Administrador Número: 16 Nombre historia: Gestionar Agenda Prioridad en negocio: Bajo Riesgo en desarrollo: Bajo Puntos estimados: 3 Iteración asignada: 4 Programador responsable: Bella Calle -Jazmín Gaibor. Descripción: COMO administrador del sistema, QUIERO una agenda que permita registrar las tareas pendientes, permitiendo poner recordatorio, PARA poder dar un mejor servicio y cumplir con todos los incidentes que llegan al área de Tics. Escenario de prueba: DADO el ingreso correcto de una actividad CUANDO se presiona guardar agenda ENTONCES aparece un mensaje “Actividad Registrada”. DADO la actualización correcta de una actividad CUANDO presiono el botón guardar agenda ENTONCES aparece un mensaje “Actividad Actualizada!”. DADO una actividad ingresada CUANDO presiono el botón eliminar ENTONCES aparece un mensaje “Actividad Eliminada” y se elimina la actividad. Nota: Datos obtenidos de la investigación de campo.

5.2.3.2.

Etapa 2: Diseño.

5.2.3.2.1. Tarjetas CRC. Tabla 37 Tarjeta CRC 1 Tarjeta CRC Número: 1 Responsabilidad: Ingresar Departamentos Actualizar o Editar Departamentos Controlador: DepartamentoController

Clase: Departamento Colaboradores:

Nota: Datos obtenidos de la investigación de campo.

Tabla 38 Tarjeta CRC 2 Tarjeta CRC Número: 2 Responsabilidad: Ingresar Funcionarios Actualizar o Editar Funcionarios Controlador: FuncionarioController Nota: Datos obtenidos de la investigación de campo.

Clase: Funcionario Colaboradores: Departamento

Tabla 39 Tarjeta CRC 3 Tarjeta CRC Número: 3 Responsabilidad: Ingresar Usuarios Actualizar o Editar Usuario Asignar rol de usuario Controlador: UserController Nota: Datos obtenidos de la investigación de campo.

Clase: User Colaboradores: Funcionario


48 Tabla 40 Tarjeta CRC 4 Tarjeta CRC Número: 4 Responsabilidad: Ingresar Marcas Actualizar o Editar Marcas Controlador: MarcaController

Clase: Marca Colaboradores:

Nota: Datos obtenidos de la investigación de campo.

Tabla 41 Tarjeta CRC 5 Tarjeta CRC Número: 5 Responsabilidad: Ingresar Categorías Actualizar o Editar Categorías Controlador: CategoríaController

Clase: Categoría Colaboradores:

Nota: Datos obtenidos de la investigación de campo.

Tabla 42 Tarjeta CRC 6 Tarjeta CRC Número: 6 Responsabilidad: Ingresar Bienes Actualizar o Editar Bienes Historial del bien Listado de bienes Asignados Controlador: BienController

Clase: Bien Colaboradores: Categoría Marca

Nota: Datos obtenidos de la investigación de campo.

Tabla 43 Tarjeta CRC 7 Tarjeta CRC Número: 7 Responsabilidad: Ingresar sistemas Actualizar o Editar Sistemas Controlador: SistemaController

Clase: Sistema Colaboradores:

Nota: Datos obtenidos de la investigación de campo.

Tabla 44 Tarjeta CRC 8 Tarjeta CRC Número: 8 Responsabilidad: Ingresar Asistencias Técnicas Editar Asistencias Técnicas Ingresar Asistencias de Sistemas Editar Asistencias de Sistemas Ingresar Mantenimientos Actualizar o Editar Mantenimientos Actualizar o Editar Generar Reportes Controlador: AsistenciaController Nota: Datos obtenidos de la investigación de campo.

Clase: Asistencia Colaboradores:

Funcionario User Bien Sistema


49 Tabla 45 Tarjeta CRC 9 Tarjeta CRC Número: 9 Responsabilidad:

Clase: EncabezadoActa Colaboradores: Acta Ingresar datos generales de la asignación DetalleActa Funcionario User Controlador: EncabezadoActaController Nota: Datos obtenidos de la investigación de campo.

Tabla 46 Tarjeta CRC 10 Tarjeta CRC Número: 10 Clase: DetalleActa Responsabilidad: Colaboradores: Ingresar asignaciones temporales Ingresar asignaciones permanentes EncabezadoActa Agregar detalles Funcionario Editar asignación Bien Generar Acta Listado de bienes Asignados Controlador: DetalleActaController Nota: Datos obtenidos de la investigación de campo.

Tabla 47 Tarjeta CRC 11 Tarjeta CRC Número: 11 Responsabilidad: Ingresar Actividades Actualizar o Editar Actividades Eliminar Actividades Mostrar Calendario con las actividades registradas Mostrar resumen de las actividades Controlador: AgendaController Nota: Datos obtenidos de la investigación de campo.

Clase: Agenda Colaboradores:


50 5.2.3.2.2. Base de Datos Modelo Relacional. Luego de varias iteraciones, la siguiente es la versiรณn final de la base de datos.

Figura 12. Base de Datos Modelo Relacional. Adaptado de Sistema Gestor de Base de Datos MySQL.


51 5.2.3.2.3. Diccionario de Datos. Luego de analizar las funcionalidades, y construir la base de datos se procede a la obtención del diccionario de datos, el propósito de este es presentar la información que posee la aplicación web de forma lógica. Par visualizar el diccionario de datos ver Anexo 3. 5.2.3.2.4. Diseño de Interfaces del Sistema.

Figura 13. Interfaz de Login. Adaptado de investigación de campo.

Figura 14. Interfaz de la Agenda. Adaptado de investigación de campo.


52

Figura 15. Interfaz de Bienes Informáticos. Adaptado de investigación de campo.

Figura 16. Interfaz de tipo de Sistemas. Adaptado de investigación de campo.

Figura 17. Formulario de registro de Asistencia Técnica. Adaptado de investigación de campo.


53

Figura 18. Interfaz de Mantenimientos. Adaptado de investigación de campo.

Figura 19. Reporte de Asignaciones. Adaptado de investigación de campo.

5.2.3.3.

Etapa 3: Codificación.

La codificación se realizó con el framework LARAVEL v5.4 con lenguaje de programación PHP v7.1.1 y su entorno de desarrollo LARAGON v2.2.2, base de datos MariaDB v10.2.3, como servidor web se usó Apache v2.4.25, para la interfaz web se hizo uso de plantillas de BOOTSTRAP v3.3.7, y como editor de texto Sublime Text v3.


54 Para la estructura global del sistema se usó el Diseño Modelo Vista Controlador (MVC), a continuación se expone la estructura del módulo Departamentos. Ver Figura

Figura 20. Controlador de la Tabla Departamento. Adaptado de investigación de campo.

Figura 21. Vista Load de la Tabla Departamento. Adaptado de investigación de campo.


55

Figura 22. Modelo de la Tabla Departamento. Adaptado de investigación de campo.

La codificación del sistema como el script de la base de datos se encuentra adjunto en el CD. 5.2.3.4.

Etapa 4: Pruebas.

5.2.3.4.1. Pruebas unitarias. Las pruebas unitarias se las realizó acorde se fue codificando el sistema y sirvió para comprobar el correcto funcionamiento del código. Estas pruebas fueron verificadas con la herramienta “PHPUnit” creado por Sebastian Bergmann gracias a que el LARAVEL brinda soporte para para trabajar con ésta herramienta, PHPUnit trabaja por medio de aseveraciones es capaz de encontrar errores y comprobar que no se ha producido regresión de código. 5.2.3.4.2. Pruebas de aceptación. Las pruebas de aceptación fueron creadas en base a las historias de usuario en cada ciclo de iteración de desarrollo y sirvieron para verificar que el sistema cumpla con todas las funcionalidades que el cliente requirió. Ver Anexo 4. A continuación se presenta las pruebas de aceptación como matriz realizadas por iteraciones donde se le asignó el número y nombre de la historia, los escenarios de prueba y el estado de cada una de ellas donde el cliente evalúo la funcionalidad del sistema:


56 Tabla 48 Pruebas de aceptación de la iteración 1 PRUEBAS DE ACEPTACIÓN N° Historia Historia Escenarios de Prueba Estado DADO el ingreso correcto de usuario y contraseña CUANDO presiono el botón LOGIN ENTONCES accedo Realizado al menú principal. 1 Login DADO el ingreso incorrecto de usuario o contraseña CUANDO presiono el botón LOGIN ENTONCES aparece Realizado un mensaje “Estas credenciales no coinciden con nuestros registros”. DADO el ingreso correcto de los datos de departamentos CUANDO presiono el botón guardar departamento Realizado ENTONCES aparece un mensaje “Departamento Creado DADO el ingreso incompleto de los datos de departamentos Administración de CUANDO presiono el botón guardar departamento Realizado 2 departamentos ENTONCES aparece un mensaje “Completa este campo”. DADO la actualización de los datos de departamentos CUANDO presiono el botón guardar departamento Realizado ENTONCES aparece un mensaje “Departamento Actualizado!”. DADO el ingreso correcto de los datos de los funcionarios CUANDO presiono el botón guardar funcionario Realizado ENTONCES aparece un mensaje “Funcionario creado!” DADO el ingreso incompletos de los datos obligatorios de los funcionarios CUANDO presiono el botón guardar Administración de Realizado 3 funcionario ENTONCES aparece un mensaje “Completa funcionarios este campo”. DADO la actualización correcta de los datos de los funcionarios CUANDO presiono el botón guardar Realizado funcionario ENTONCES aparece un mensaje “Funcionario Actualizado!”. Nota: Datos obtenidos de la investigación de campo.

Tabla 49 Pruebas de aceptación de la iteración 2 PRUEBAS DE ACEPTACIÓN N° Historia Historia Escenarios de Prueba DADO el ingreso correcto de los datos de los usuarios CUANDO presiono el botón guardar usuario ENTONCES aparece un mensaje con “User creado!”. DADO el ingreso de datos incompletos de los datos de los Administración 4 usuarios CUANDO presiono el botón guardar usuario de usuarios ENTONCES aparece un mensaje “Completa este campo”. DADO la actualización correcta de los datos de los usuarios CUANDO presiono el botón guardar usuario ENTONCES aparece un mensaje “User Actualizado!”. DADO el ingreso correcto de los datos de marcas CUANDO presiono el botón guardar marca ENTONCES aparece un mensaje “Marca creada!” DADO el ingreso incompleto de los datos de marcas Administración 5 CUANDO presiono el botón guardar marca ENTONCES de marcas aparece un mensaje “Completa este campo!” DADO la actualización correcta de los datos de las marcas CUANDO presiono el botón guardar marca ENTONCES aparece un mensaje “Marca Actualizado!”. DADO el ingreso correcto de los datos de categorías CUANDO presiono el botón guardar categoría Administración 6 ENTONCES aparece un mensaje “Categoría creada!” de categorías DADO el ingreso incompleto de los campos de categorías CUANDO presiono el botón guardar categoría

Estado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado


57

7

8

Administración de bienes

Listado de bienes asignados

ENTONCES aparece un mensaje “Completa este campo” DADO la actualización correcta de los datos de categorías CUANDO presiono el botón guardar categoría ENTONCES aparece un mensaje “Categoría Actualizada!”. DADO el ingreso correcto de los datos de los bienes informáticos CUANDO presiono el botón guardar bien ENTONCES aparece un mensaje “Bien creado!” DADO el ingreso incompleto de los datos obligatorios de los bienes informáticos CUANDO presiono el botón guardar bien ENTONCES aparece un mensaje “Completa este campo”. DADO la actualización correcta de los datos del bien CUANDO presiono el botón guardar bien ENTONCES aparece un mensaje “Bien Actualizado!”. DADO el listado de bienes asignados CUANDO presiono el botón Asignados ENTONCES nos muestra una tabla con información detallada de cada bien asignado con su respectivo custodio.

Realizado

Realizado

Realizado

Realizado

Realizado

Nota: Datos obtenidos de la investigación de campo.

Tabla 50 Pruebas de aceptación de la iteración 3 PRUEBAS DE ACEPTACIÓN N° Historia Historia Escenarios de Prueba Estado DADO el ingreso correcto de los datos de los tipos de sistemas CUANDO presiono el botón guardar sistema ENTONCES Realizado aparece un mensaje “Sistema creado!” DADO el ingreso incompletos de los datos de los tipos de Administración 9 sistemas CUANDO presiono el botón guardar sistema Realizado de sistemas ENTONCES aparece un mensaje “Completa este campo” DADO la actualización correcta de los datos del tipo de sistema CUANDO presiono el botón guardar sistema ENTONCES Realizado aparece un mensaje “Sistema Actualizado!”. DADO el ingreso correcto de los datos de las asistencias técnicas CUANDO presiono el botón guardar asistencia Realizado ENTONCES aparece un mensaje “Asistencia creada!” Registro de DADO el ingreso incompleto de los datos de las asistencias 10 asistencias técnicas CUANDO presiono el botón guardar asistencia Realizado técnicas ENTONCES aparece un mensaje “Completa este campo”. DADO la actualización correcta de los datos de las asistencias técnicas CUANDO presiono el botón guardar asistencia Realizado ENTONCES aparece un mensaje “Asistencia Actualizado!”. DADO el ingreso correcto de los datos de las asistencias de sistemas CUANDO presiono el botón guardar asistencia Realizado ENTONCES aparece un mensaje “Asistencia creada!” Registro de DADO el ingreso incompleto de los datos de las asistencias de 11 asistencias de sistemas CUANDO presiono el botón guardar asistencia Realizado sistemas ENTONCES aparece un mensaje de “Completa este campo”. DADO la actualización correcta de los datos de las asistencias de sistemas CUANDO presiono el botón guardar asistencia Realizado ENTONCES aparece un mensaje “Asistencia Actualizado!”. DADO el ingreso correcto de los datos de los mantenimiento CUANDO presiono el botón guardar asistencia ENTONCES Realizado aparece un mensaje “Asistencia creada!” DADO el ingreso incompleto de los datos de los Registro de 12 mantenimientos CUANDO presiono el botón guardar asistencia Realizado mantenimientos ENTONCES aparece un mensaje de “Completa este campo”. DADO la actualización correcta de los datos de los mantenimientos CUANDO presiono el botón guardar asistencia Realizado ENTONCES aparece un mensaje “Asistencia Actualizada!”. Nota: Datos obtenidos de la investigación de campo.


58 Tabla 51 Pruebas de aceptación de la iteración 4 PRUEBAS DE ACEPTACIÓN N° Historia Escenarios de Prueba Historia 13 Registro de DADO el ingreso correcto de los datos de las asignaciones Asignaciones temporales CUANDO presiono el botón guardar datos temporales ENTONCES aparece un mensaje “Asignación Temporal creada!” DADO el ingreso correcto de los detalles de la asignación CUANDO presiono el botón generar acta ENTONCES aparece un acta con formato PDF como constancia de la asignación realizada. DADO el ingreso incompleto de los datos de las asignaciones temporales CUANDO presiono el botón guardar datos ENTONCES aparece un mensaje “Completa este campo”. 14 Registro de DADO el ingreso correcto de los datos de las asignaciones Asignaciones temporales CUANDO presiono el botón guardar datos permanentes ENTONCES aparece un mensaje “Asignación Temporal creada!” DADO el ingreso correcto de los detalles de la asignación CUANDO presiono el botón generar acta ENTONCES aparece un acta con formato PDF como constancia de la asignación realizada. DADO el ingreso incorrecto de los datos de las asignaciones temporales CUANDO presiono el botón guardar datos ENTONCES aparece un mensaje “Completa este campo”. 15 Visualización DADO el ingreso correcto del correo y clave CUANDO de los bienes presiono el botón login ENTONCES aparece los datos asignados detallados de todas las asignaciones que he realizado. 16 Gestionar DADO el ingreso correcto de una actividad CUANDO se Agenda presiona guardar agenda ENTONCES aparece un mensaje “Actividad Registrada”. DADO la actualización correcta de una actividad CUANDO presiono el botón guardar agenda ENTONCES aparece un mensaje “Actividad Actualizada!”.

Estado Realizado

Realizado

Realizado

Realizado

Realizado

Realizado

Realizado

Realizado

Realizado

Nota: Datos obtenidos de la investigación de campo.

5.2.4. Acta de Entrega y Recepción. Finalizado el sistema web para la gestión de bienes informáticos y asistencia técnica que dio solución al problema de investigación, se procedió hacer la entrega del producto en el MIES y para constancia de la misma se realizó una ACTA ENTREGA – RECEPCIÓN donde firmaron las partes involucradas: entrega las disertantes, y recibe el Director Distrital MIES.


59

Figura 23. Acta Entrega - Recepción. Adaptado de investigación de campo.

5.3.

Evaluación de impacto del proyecto El siguiente análisis de impactos se lo realizó retrospectivamente ya que se puso en

marcha luego de implementar el sistema web en el departamento de TIC del MIES. Para comprender los impactos producidos, se presenta una matriz de impactos que permite analizar el impacto generado en el proyecto en una determinada área, donde se especifican los niveles de impactos y la descripción referente a cada nivel de impacto.


60 Tabla 52. Matriz de impacto Nivel de impacto -3 -2 -1 0 1 2 3

Descripción de nivel de impacto Impacto alto Negativo Impacto medio Negativo Impacto bajo Negativo No hay Impacto Impacto bajo Positivo Impacto medio Positivo Impacto alto Positivo

Nota: Adaptado de “Metodología para el trabajo de grado”, por M. A. Posso, 2009. Tesis y Proyectos Cuarta ed. Ibarra: NINA Comunicaciones.

Para calcular los impactos en las diferentes áreas se utilizó la siguiente fórmula:

5.3.1. Impacto Económico. Tabla 53 Impacto económico Indicadores Apoyo a la gestión Total Sumatoria Σ Total Resultado

-3

Nivel de impacto -1 0 1

-2

2

3 X 3

Σ=3 NI=3/1=3 Impacto de alto nivel positivo

Nota: Datos obtenidos de la investigación de campo.

Análisis: Permite reducir el tiempo dedicado al registro y administración de información llevando un control y facilitando la toma de decisiones de esta manera se agilita los procesos en el departamento de Tics. 5.3.2. Impacto social. Tabla 54 Impacto social Indicadores Acceso a la información Confidencialidad de la información Total Sumatoria Σ Total Resultado Nota: Datos obtenidos de la investigación de campo.

-3

-2

Nivel de impacto -1 0 1 X 1

Σ=4 NI=4/2=2 Impacto medio positivo

2

3 X 3


61 Análisis Facilidad al acceder a la información tanto para el encargado de Tics como para los funcionarios desde cualquier dispositivo que tenga acceso a internet. La información es accesible solo para el funcionario al que le pertenece, o es responsable de ella. 5.3.3. Impacto Tecnológico. Tabla 55 Impacto Tecnológico Indicadores Desarrollo Tecnológico Automatización de procesos Total Sumatoria Σ Total Resultado

-3

-2

Nivel de impacto -1 0 1

2

3 X X 6

Σ=6 NI=6/2=2 Impacto alto positivo

Nota: Datos obtenidos de la investigación de campo.

Análisis: Produce desarrollo tecnológico mediante el uso de nuevas tecnologías aplicados a los procesos realizados por la institución. Permite la automatización de todos los procesos que se realizan en el departamento de Tics permitiendo agilidad y eficiencia en el desarrollo de las actividades. 5.3.4. Impacto general. Tabla 56 Impacto General Indicadores Impacto Económico Impacto Social Impacto Tecnológico Total Sumatoria Σ Total Resultado Nota: Datos obtenidos de la investigación de campo.

-3

-2

Nivel de impacto -1 0 1

2

3 X

X 2 Σ=8 NI=8/3=2,67 Impacto alto positivo

X 6


62 Análisis: El sistema web para la gestión de bienes informáticos y asistencias en el departamento de Tics del Mies muestra un Impacto alto Positivo, de acuerdo a este análisis se demuestra la viabilidad del proyecto. La automatización de los procesos para la gestión de los bienes informáticos hace más fácil al encargado del departamento la toma de decisiones, además, se realiza el registro de asignaciones de manera inmediata haciendo que los funcionarios no pierdan tiempo para ejecutar sus respectivas actividades; con el sistema se garantiza la accesibilidad, integridad y confidencialidad de la información.


63

5.4.

Conclusiones Conocer los procesos de negocios como primera fase del proyecto es una medida para

evaluar los beneficios, practicidad del desarrollo del proyecto software y para realizar la planificación operativa del proyecto. La metodología XP para la ingeniería de software fue apropiado, por su adaptabilidad a los cambios en la funcionalidad del sistema por parte del MIES, y la comunicación frecuente hizo posible superar las expectativas del cliente. El uso de herramientas de código abierto (Open Source) para el desarrollo del sistema web como el framework LARAVEL 5.4 y su marco de trabajo Laragon, así como el sistema gestor de base de datos MariaDB y el servidor Apache, permitió al MIES ahorrar recursos tanto en el coste de licencias como en infraestructura tecnológica, también en el soporte técnico por su amplia documentación y ayuda de grandes comunidades basadas en proyectos Open Source. Al analizar los resultados, se evidencia que el desarrollo e implementación del sistema web ha logrado automatizar los procesos, es decir, brinda a la institución eficiencia en la gestión de bienes informáticos y asistencia técnica. Cabe recalcar, la información plasmada en los reportes ha sido de gran ayuda para la toma de decisiones por parte de la gerencia.


64 5.5.

Recomendaciones Añadir otra funcionalidad al sistema web que permita controlar de manera inteligente,

es decir, por medio de recordatorios, los mantenimientos preventivos de los bienes informáticos. Así como también continuar con la automatización de todos los procesos del MIES. Por ello nace la necesidad de contratar a una persona capacitada, para el posterior mantenimiento del sistema. Hacer uso de las metodologías ágiles para el desarrollo de software, puesto que son eficientes, más económicas, más flexibles, y sobre todo porque las reuniones y entregables contantes con el cliente permiten desarrollar un software que cumpla con todas las funcionalidades que satisfaga al cliente, gracias a su participación en el desarrollo. Analizar los recursos tanto económicos como infraestructura tecnológica de la empresa antes de desarrollar software, para hacer uso de las herramientas de desarrollo que mejor se adapten a la situación de la organización. Asegurar la información de la base de datos mediante un software libre o comercial para protegerlas de operaciones no autorizadas que pongan en peligro su existencia, consistencia e integridad, así como evitar la pérdida de los datos por fallos de hardware o software.


65

Lista de referencias Auquilla, N. M., y Andrade, D. A. (2014). Propuesta de un modelo de gestión para la administración y manejo del control de bienes del sector público aplicado a la dirección provincial del IEES en el Azuay (tesis de maestría). Universidad Politécnica Salesiana,

Azuay.

Recuperado

de:

https://dspace.ups.edu.ec/bitstream/123456789/2550/6/UPS-CT002435.pdf . Borja, O. A. (2013). Gestión de base de datos con SQL, MySQL y Access. México : Alfaomega. Catherine, M. R. (2009). Base de Datos. México: McGraw Hill. Cobo, A., Gómez, P., Pérez, D., y Rocha, R. (2005). PHP y MySQL. Tecnologías para el desarrollo de aplicaciones web. España: Díaz Santos. Domínguez, J. B. (2015). Manual de metodología de la investigación científica. Perú: Universidad Católica Los Ángeles de Chimbote. Fernández, Y., y Díaz, Y. (2012). Patrón Modelo-Vista-Controlador. Revista Telem@tica, 11(1),

47-57.

Recuperado

de:

http://revistatelematica.cujae.edu.cu/index.php/tele/article/view/15/10. Godoy, D. A. (2015). Diseño de un Simulador Dinámico de Proyectos de Desarrollo de Software que utilizan Metodología Scrum (tesis de maestría). Universidad Nacional de

La

Plata,

Buenos

Aires,

Argentina.

Recuperado

de:

http://sedici.unlp.edu.ar/handle/10915/44915. Hernández, R., Fernández, C., y Baptista, P. (2010). Metodología de la Investigación. Perú: McGraw Hill. Iruela, J. (19 de enero de 2016). Los gestores de bases de datos más usados [Mensaje en un Blog]. Recuperado de: https://revistadigital.inesem.es/informatica-y-tics/los-gestoresde-bases-de-datos-mas-usados/. López, M., Vara, J. M., Verde, J., Sánchez, D. M., Jiménez, J. J., y De Castro, V. (2012). Desarrollo Web en Entorno Servidor. Madrid: RA-MA S.A.


66 Manz, J. R. (26 de octubre de 2014). Emzeta.com. Guía de Sublime Text: ¿El mejor editor de código?

[Mensaje

en

un

Blog].

Recuperado

de:

https://www.emezeta.com/articulos/guia-sublime-text. Márquez, J., Vargas, F., y Sampedro, L. (2002). Instalación y configuración de Apache, un servidor Web gratis. Ingeniería y Desarrollo, (12), 10-23. Recuperado de: http://www.redalyc.org/articulo.oa?id=85201202. Mendes, K., Estévez, E. C., y Fillottrani, P. R. (2010). A Quantitative Framework for the Evaluation of Agile Methodologies. Journal of Computer Science & Technology, 10(2). Recuperado de: http://hdl.handle.net/10915/9671. Mera, O. F., y Paredes, E. S. (2008). Automatización de la gestión de inventario y préstamo de los bienes de la asociación de estudiantes de Ingeniería de Sistemas – AEIS (tesis de

pregrado).

Escuela

Politécnica

Nacional,

Quito.

Recuperado

de:

http://bibdigital.epn.edu.ec/handle/15000/866. Ministerio de Inclusión Económica y Social (2015). Acuerdo Ministerial No.000080. Recuperado

de:

http://www.inclusion.gob.ec/wp-

content/uploads/downloads/2015/10/ESTATUTO-No.00080.pdf. Molina, M. M. (2015). Implementación de un sistema de gestión de inventarios y mantenimiento de equipos informáticos mediante la metodología Scrum, en los laboratorios de la carrera de ingeniería en informática y sistemas computacionales de la universidad técnica de Cotopaxi durante el periodo 2014-2015 (tesis de pregrado). Universidad

Técnica

de

Cotopaxi,

Latacunga.

Recuperado

de:

http://repositorio.utc.edu.ec/handle/27000/2921 Navarro, A., Fernández, J. D., y Morales, J. (2013). Revisión de metodologías ágiles para el desarrollo

de

software.

Prospect,

(11)

30-39.

Recuperado

de:

http://www.redalyc.org/pdf/4962/496250736004.pdf Nevado, V. (2010). Introducción a la base de datos relacionales. Madrid: Visión Libros. Otacoma, M. E., y Sopa, V. C. (2011). Desarrollar e Implementar un Sistema de Información que permita realizar el registro y control de mantenimientos e inventario de registro informáticos, el mismo que se denominara KUBIK-INVENTARY PC, procesos que


67 se ejecutaran desde el departamento de gestión tecnológica del Ministerio de Inclusión Económica y Social (MIES) (tesis de pregrado). Universidad Politécnica Salesiana, Quito. Recuperado de: https://dspace.ups.edu.ec/handle/123456789/1576. Piattini, M. (2016). Evolución de la Ingeniería del Software y la formación de profesionales. Revista Institucional De La Facultad De Informática UNLP, 2(4), 15-17. Recuperado de: http://sedici.unlp.edu.ar/handle/10915/57358. Pressman, R. S. (2010). Ingeniería del software: Un enfoque práctico. México: McGraw-Hill. Qumer, A., & Henderson-Sellers, B. (Julio, 2006). Comparative Evaluation of XP and Scrum using de 4D Analytical Tool (4-DAT) [Evaluación comparativa de XP y Scrum usando la herramienta de análisis 4D (4-DAT)]. En Proceedings of the European and Mediterranean Conference on Information System (EMCIS), España. Recuperado de: https://opus.lib.uts.edu.au/bitstream/10453/6967/1/2006005499.pdf Sagastizabal, M., Perlo, C. (2006). La investigación-acción como estrategia de cambio en las organizaciones. Cómo investigar en las instituciones educativas. Buenos Aires: Stella. Secretaría Nacional de Planificación y Desarrollo (2017). Plan Nacional para el Buen Vivir 2017-2021.

Recuperado

de:

https://www.unicef.org/ecuador/Plan_Nacional_Buen_Vivir_2013-2017.pdf Sierra, F., Acosta, J., Ariza, J., y Salas, M. (2013). Estudio y análisis de los framework en php basados en el modelo vista controlador para el desarrollo de software orientado a la web. Investigación y Desarrollo en TIC, 4(2), 1-13. Recuperado de: http://revistas.unisimon.edu.co/index.php/identic/article/view/2480/2373 Silberschatz, A., Korth, H. F., y Sudarshan, S. (2002). Fundamentos de base de datos. Madrid: McGraw-Hill. Sommerville, I. (2014). Ingeniería de Software. México: Pearson Education. Suris, B. (2016). Aplicación web para el control del tiempo de máquina en el Instituto Superior Minero Metalúrgico. Ciencia & Futuro, 6(2), 62-74. Recuperado de: http://revista.ismm.edu.cu/index.php/revista_estudiantil/article/view/1279/688. Tamayo, M. (2014). El Proceso de la Investigación científica. México: Limusa.


68 TIOBE Software BV (2000). TIOBE Index for October 2017. October Headline: Swift is losing popularity. Recuperado de: https://www.tiobe.com/tiobe-index//. Villalba, M. E. (2013). Análisis, diseño y construcción un sistema de administración de actividades de Help Desk, y control de equipamiento, como aplicativo de escritorio para la Empresa Eléctrica Quito (tesis de pregrado). Universidad Politécnica Salesiana, Quito. Recuperado de: https://dspace.ups.edu.ec/handle/123456789/11360. Zapata, C. M., González, G., y Chaverra, J.J. (2011). Generación Automática Del Diagrama Entidad Relación Y Su Representación En Sql Desde Un Lenguaje Controlado (UnLencep). Ingenierías Universidad de Medellín, 10(18), 127-135. Recuperado de: http://www.scielo.org.co/scielo.php?script=sci_arttext&pid=S169233242011000100014&lang=pt. Zofío, J. (2013). Aplicaciones Web. Madrid: Macmillan Iberia.


69

Glosario Boostrap: Bootstrap, es un framework originalmente creado por Twitter, que permite crear interfaces web con CSS y JavaScript, cuya particularidad es la de adaptar la interfaz del sitio web al tamaño del dispositivo en que se visualice. CSS: La sigla CSS corresponde a la expresin inglesa Cascading StyleSheets, que puede traducirse como “Hojas de estilo en cascada”. El concepto se utiliza en el ámbito de la informática para referirse a un lenguaje empleado en el diseño gráfico. Framework: Desde el punto de vista del desarrollo de software, un framework es una estructura de soporte definida, en la cual otro proyecto de software puede ser organizado y desarrollado. Hardware: En computación, término inglés que hace referencia a cualquier componente físico tecnológico, que trabaja o interactúa de algún modo con la computadora. HTML: Es un lenguaje de marcado que se utiliza para el desarrollo de páginas de Internet. Se trata de la sigla que corresponde a HyperText Markup Language, es decir, Lenguaje de Marcas de Hipertexto, que podría ser traducido como Lenguaje de Formato de Documentos para Hipertexto. MIES: El Ministerio de Inclusión Económica y Social, (MIES), es una entidad pública que ejerce rectoría y ejecuta políticas, regulaciones, programas y servicios para la inclusión social y atención durante el ciclo de vida, con prioridad en la población más vulnerable en niñas, niños, adolescentes, jóvenes, adultos mayores, personas con discapacidad y aquellas personas que se encuentran en situación de pobreza, a n de fortalecer su movilidad social y salida de la pobreza. Modelo ER: Modelo Entidad Relación es un tipo de modelo de datos conceptual de alto nivel que se emplea en el diseño de las base de datos relacionales. El modelo entidad-relación muestra la estructura de la base de datos empleando todo tipo de herramientas conceptuales. Open Source: Denominación para aquellas aplicaciones que tienen su código fuente liberado. En general, los programas de código abierto suele ser libres. Aunque existen aplicaciones de código abierto que no son libres.


70 PHP: Hypertext Preprocessor es un lenguaje para programar scripts del lado del servidor, que se incrustan dentro del código HTML. Este lenguaje es gratuito y multiplataforma. PostegreSQL: Es un sistema de gestión de bases de datos relacional orientado a objetos y libre, publicado bajo la licencia PostgreSQL. Script: El script es un documento que contiene instrucciones, escritas en códigos de programación. El script es un lenguaje de programación que ejecuta diversas funciones en el interior de un programa de computador. SGBD: Sistema de gestión de base de datos o en inglés Database management system (DBMS), es una agrupación de programas que sirven para definir, construir y manipular una base de datos.


71

ANEXOS Anexo 1. Cuestionario de la entrevista. CUESTIONARIO DE ENTREVISTA DIRIGIDA AL JEFE DE DEPARTAMENTO DE TIC Estimado Ing. Edison Patrón, el propósito de esta entrevista es conocer los procesos que se realiza para la gestión de los bienes informáticos y asistencia técnica en el departamento de las TIC. ¿Cómo se realiza un registro de un bien informático? ¿Cuál es el proceso de asignación de un bien informático a un funcionario de la institución? ¿Cómo se efectúa una prestación de un bien informático? ¿Qué sucede si el equipo prestado no se lo entrega en el tiempo establecido? ¿Qué tipo de asistencias brinda el departamento de las TIC? ¿En qué se diferencian las asistencias mencionadas? ¿Se lleva un registro de las asistencias realizadas? ¿De qué manera se lleva un control las actividades que debe realizar? ¿Requiere la institución la implementación de un software para la gestión de bienes informáticos y asistencia técnica? ¿En qué cree Ud. Que el sistema beneficiara al departamento de las TIC en el MIESS?


72 Anexo 2. Hoja de la encuesta. ENCUESTA

DIRIGIDA

A

LOS

FUNCIONARIOS

DEL

MINISTERIO

DE

INCLUSIÓN ECONÓMICA Y SOCIAL DE SANTO DOMINGO DE LOS TSÁCHILAS. LA PRESENTE ENCUESTA TIENE POR OBJETIVO MEDIR LA FACTIBILIDAD DE DESARROLLAR E IMPLEMENTAR UN SISTEMA WEB PARA LA GESTIÓN DE BIENES INFORMATICOS Y ASISTENCIA TÉCNICA EN EL DEPARTAMENTO DE TICS DEL MINISTERIO DE INCLUSIÓN ECONÓMICA Y SOCIAL DE LA PROVINCIA DE SANTO DOMINGO DE LOS TSÁCHILAS DURANTE EL PERIODO 2017-2018. 1. ¿Qué tiempo ha tenido que esperar para ser atendido en el departamento de Tics? Al instante

Intervalo de 2 a 5 minutos

Superior a 5 minutos

2. ¿Considera usted, que el proceso actual utilizado para realizar el control de bienes informáticos en el departamento de Tics es el más óptimo? SI

NO

3. ¿Considera que las asistencias realizadas se las lleva a cabo de manera ordenada? SI

NO

4. ¿Cree conveniente automatizar el proceso de asignaciones de bienes informáticos a los funcionarios? SI

NO

5. ¿Le gustaría que el departamento de Tics, cuente con un sistema web para poder visualizar la información de los bienes informáticos que están a su cargo? SI

NO

6. ¿Está usted de acuerdo que el departamento de Tics disponga de un sistema web para la gestión de bienes informáticos y asistencia técnica? SI

NO


73 Anexo 3. Diccionario de datos.

mydb Data Dictionay 2018-02-01 Alphabetic Index               

actas agendas asistencias bienes categorias departamentos detalleactas devoluciones encabezadoactas funcionarios marcas migrations password_resets sistemas users


74


75


76


77


78


79


80


81 Anexo 4. Pruebas de aceptación. Prueba de funcionalidad ID Caso de prueba: 01 Nombre caso de prueba: Login Historia de usuario asociada: 1 Módulo/sección a evaluar: Login Descripción: Verificar que el funcionamiento del Módulo Login se lleve a cabo con éxito y comprobar que todas validaciones y criterios de aceptación de las historias de usuario se cumplan. Pre-condiciones  Ninguna. Pasos y condiciones de ejecución El Usuario digita su correo y contraseña para acceder al sistema Click en "Login", y se tendra acceso al sistema según sus privilegios. Los cambios se guardarán con éxito Resultado esperado.  El usuario ingresa al sistema Exitoso Falló Estado de prueba X Errores asociados: Ninguno Post-condiciones: El Usuario registrado puede acceder al sistema

Prueba de funcionalidad ID Caso de prueba: 03 Nombre caso de prueba: Administración de Funcionarios Módulo/sección a evaluar: Historia de usuario asociada: 3 Funcionarios Descripción: Verificar que el funcionamiento del Módulo funcionarios se lleve a cabo con éxito y comprobar que todas validaciones y criterios de aceptación de las historias de usuario se cumplan. Pre-condiciones  El Administrador debe estar logueado Pasos y condiciones de ejecución El Administrador ingresa al módulo de Funcionarios Se visualiza los datos de los funcionarios ingresados Click en "Nuevo Funcionario", se despliega el formulario de ingreso de funcionarios en donde se escribe los datos solicitados, y click en “Guardar Funcionario” La edición y/o actualización de los datos de los funcionarios registrados se podrá realizar y los cambios se reflejarán automáticamente Los cambios se guardarán con éxito Resultado esperado.  Se guardan todos los datos correspondientes al registro  El sistema muestra una notificación informando que la transacción se realizó exitosamente Exitoso Falló Estado de prueba X Errores asociados: Ninguno Post-condiciones: Los registros realizados se guardan en la base de datos y se validan para su posterior uso.

Prueba de funcionalidad ID Caso de prueba: 02 Nombre caso de prueba: Administración de Departamentos Módulo/sección a evaluar: Historia de usuario asociada: 2 Departamentos Descripción: Verificar que el funcionamiento del Módulo de departamentos se lleve a cabo con éxito y comprobar que todas validaciones y criterios de aceptación de las historias de usuario se cumplan. Pre-condiciones  El Administrador debe estar logueado Pasos y condiciones de ejecución El Administrador ingresa al módulo de Departamentos Se visualiza los datos de departamentos ingresados


82 Click en "Nuevo Departamento", se despliega el formulario de ingreso de departamentos en donde se escribe los datos solicitados, y click en “Guardar Departamento” La edición y/o actualización de los datos de los departamentos registrados se podrá realizar y los cambios se reflejarán automáticamente Los cambios se guardarán con éxito Resultado esperado.  Se guardan todos los datos correspondientes al registro  El sistema muestra una notificación informando que la transacción se realizó exitosamente Exitoso Falló Estado de prueba X Errores asociados: Ninguno Post-condiciones: Los registros realizados se guardan en la base de datos y se validan para su posterior uso.

Prueba de funcionalidad ID Caso de prueba: 04 Nombre caso de prueba: Administración de Usuarios Módulo/sección a evaluar: Usuarios Historia de usuario asociada: 4 Descripción: Verificar que el funcionamiento del Módulo de usuarios se lleve a cabo con éxito y comprobar que todas validaciones y criterios de aceptación de las historias de usuario se cumplan. Pre-condiciones  El Administrador debe estar logueado Pasos y condiciones de ejecución El Administrador ingresa al módulo de Usuarios Se visualiza los datos de usuarios ingresados Click en "Nuevo Usuario", se despliega el formulario de ingreso de usuarios en donde se escribe los datos solicitados, y click en “Guardar Usuario” La edición y/o actualización de los datos de los usuarios registrados se podrá realizar y los cambios se reflejarán automáticamente Los cambios se guardarán con éxito Resultado esperado.  Se guardan todos los datos correspondientes al registro  El sistema muestra una notificación informando que la transacción se realizó exitosamente  Exitoso Falló Estado de prueba X Errores asociados: Ninguno Post-condiciones: El Usuario registrado puede acceder al sistema

Prueba de funcionalidad ID Caso de prueba: 05 Nombre caso de prueba: Administración de Bienes Módulo/sección a evaluar: Bienes Historia de usuario asociada: 5-6-7-8 Descripción: Verificar que el funcionamiento del Módulo de bienes se lleve a cabo con éxito y comprobar que todas validaciones y criterios de aceptación de las historias de usuario se cumplan. Pre-condiciones  El Administrador debe estar logueado Pasos y condiciones de ejecución El Administrador ingresa al módulo de Bienes, se podrá seleccionar las siguientes opciones “Marcas”, “Categorías” o “Bienes” Se visualiza los datos registrados según la opción seleccionada Según la opción seleccionada, Click en "Nuevo Registro", se despliega el formulario de ingreso de información en donde se escribe los datos solicitados, y click en “Guardar” La edición y/o actualización de los datos registrados se podrá realizar y los cambios se reflejarán automáticamente Los cambios se guardarán con éxito Resultado esperado.  Se guardan todos los datos correspondientes al registro  El sistema muestra una notificación informando que la transacción se realizó exitosamente


83 Exitoso Falló Estado de prueba X Errores asociados: Ninguno Post-condiciones: Los registros ingresados se guardan en la base de datos y se validan para su posterior uso. Prueba de funcionalidad ID Caso de prueba: 06 Nombre caso de prueba: Administración de Sistemas Módulo/sección a evaluar: Sistemas Historia de usuario asociada: 9 Descripción: Verificar que el funcionamiento del Módulo de sistemas se lleve a cabo con éxito y comprobar que todas validaciones y criterios de aceptación de las historias de usuario se cumplan. Pre-condiciones  El Administrador debe estar logueado Pasos y condiciones de ejecución El Administrador ingresa al módulo de Sistemas Se visualiza los datos de los sistemas ingresados Click en "Nuevo Sistema", se despliega el formulario de ingreso de sistemas en donde se escribe los datos solicitados, y click en “Registrar” La edición y/o actualización de los datos de los sistemas registrados se podrá realizar y los cambios se reflejarán automáticamente Los cambios se guardarán con éxito Resultado esperado.  Se guardan todos los datos correspondientes al registro  El sistema muestra una notificación informando que la transacción se realizó exitosamente Exitoso Falló Estado de prueba X Errores asociados: Ninguno Post-condiciones: Los registros ingresados se guardan en la base de datos y se validan para su posterior uso. Prueba de funcionalidad ID Caso de prueba: 07 Nombre caso de prueba: Administración de Asistencias Módulo/sección a evaluar: Historia de usuario asociada: 10-11-12 Asistencias Descripción: Verificar que el funcionamiento del Módulo de asistencias se lleve a cabo con éxito y comprobar que todas validaciones y criterios de aceptación de las historias de usuario se cumplan. Pre-condiciones  El Administrador debe estar logueado Pasos y condiciones de ejecución El Administrador ingresa al módulo de Asistencias, se podrá seleccionar las siguientes opciones “Asistencia Técnica”, “Asistencia de Sistemas” o “Mantenimiento” Se visualiza los datos registrados según la opción seleccionada Según la opción seleccionada, Click en "Nuevo Registro", se despliega el formulario de ingreso de información en donde se escribe los datos solicitados, y click en “Registrar” La edición y/o actualización de los datos registrados se podrá realizar y los cambios se reflejarán automáticamente Los cambios se guardarán con éxito Resultado esperado.  Se guardan todos los datos correspondientes al registro  El sistema muestra una notificación informando que la transacción se realizó exitosamente Exitoso Falló Estado de prueba X Errores asociados: Ninguno Post-condiciones: Los registros ingresados se guardan en la base de datos y se validan para su posterior uso.


84 Prueba de funcionalidad ID Caso de prueba: 08 Nombre caso de prueba: Administración de Asignaciones Módulo/sección a evaluar: Historia de usuario asociada: 13-14-15 Asignaciones Descripción: Verificar que el funcionamiento del Módulo de asignaciones se lleve a cabo con éxito y comprobar que todas validaciones y criterios de aceptación de las historias de usuario se cumplan. Pre-condiciones  El Administrador debe estar logueado Pasos y condiciones de ejecución El Administrador ingresa al módulo de Asignaciones, se podrá seleccionar las siguientes opciones “Asignación Temporal”, “Asignación Permanente” Se visualiza los datos registrados según la opción seleccionada Según la opción seleccionada, Click en "Nuevo Registro", se despliega el formulario de ingreso de información del funcionario en donde se escribe los datos solicitados, y click en “Registrar” Click en "Asignaciones" y se selecciona nueva asignacion, se despliega el formulario de datos generales para el acta Click en "Agregar Detalles" para seleccionar los bienes a asignar Una vez registrados la información solicitada y los bienes a asignar se selecciona "Generar Acta" La edición y/o actualización de los datos registrados se podrá realizar antes de generar el acta y los cambios se reflejarán automáticamente Los cambios se guardarán con éxito Resultado esperado.  Se guardan todos los datos correspondientes al registro  El sistema muestra una notificación informando que la transacción se realizó exitosamente Exitoso Falló Estado de prueba X Errores asociados: Ninguno Post-condiciones: Los registros ingresados se guardan en la base de datos y se validan para su posterior uso.

Prueba de funcionalidad ID Caso de prueba: 09 Nombre caso de prueba: Gestionar Agenda Historia de usuario asociada: 16 Módulo/sección a evaluar: Agenda Descripción: Verificar que el funcionamiento del Módulo Agenda se lleve a cabo con éxito y comprobar que todas validaciones y criterios de aceptación de las historias de usuario se cumplan. Pre-condiciones  El Administrador debe estar logueado Pasos y condiciones de ejecución El Administrador ingresa al módulo de Agenda Se visualiza la información de las actividades registradas Click en "Nuevo Registro", se despliega el formulario de ingreso de actividades en donde se escribe los datos solicitados, y click en “Guardar Agenda” La edición y/o actualización de los datos registrados se podrá realizar y los cambios se reflejarán automáticamente Si selecciona agenda se despliega el calendario con las tareas registradas en la fecha que se especificó. Los cambios se guardarán con éxito Resultado esperado.  Se guardan todos los datos correspondientes al registro  El sistema muestra una notificación informando que la transacción se realizó exitosamente Exitoso Falló Estado de prueba X Errores asociados: Ninguno Post-condiciones: Ninguno


85 Anexo 5. Carta de Impacto.


Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.