Sistema web para la gestión de los semáforos en la Empresa Minicipal de Trasporte Terrestre by Pontificia Universidad Católica del Ecuador sede Santo Domingo PUCE SD

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica - Escuela de Sistemas SISTEMA WEB PARA LA GESTIÓN DE LOS SEMÁFOROS EN LA EMPRESA PÚBLICA MUNICIPAL DE TRANSPORTE TERRESTRE, TRÁNSITO, SEGURIDAD VIAL Y TERMINALES TERRESTRES SANTO DOMINGO DURANTE EL PERÍODO 2017-2018. Trabajo de Titulación previo a la obtención del título de Ingeniero de Sistemas y Computación

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

Autores: ÉDISON MAURICIO CALLE CEDILLO FRANKLIN RAMIRO PÉREZ AGURTO Director: Mg. RODOLFO SIRILO CÓRDOVA GÁLVEZ

Santo Domingo – Ecuador Agosto, 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 LOS SEMÁFOROS EN LA EMPRESA PÚBLICA MUNICIPAL DE TRANSPORTE TERRESTRE, TRÁNSITO, SEGURIDAD VIAL Y TERMINALES TERRESTRES SANTO DOMINGO DURANTE EL PERÍODO 2017-2018. Línea de Investigación: Estudio, Diseño e Implementación de Software. Autores: ÉDISON MAURICIO CALLE CEDILLO FRANKLIN RAMIRO PÉREZ AGURTO

Rodolfo Sirilo Córdova Gálvez, Mg.

DIRECTOR DE LA DISERTACIÓN DE GRADO Fausto Ernesto Orozco Iguasnia, Mg.

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

CALIFICADOR Luis Javier Ulloa Meneses, Mg.

DIRECTOR DE LA ESCUELA DE SISTEMAS

Santo Domingo – Ecuador Agosto, 2018

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Édison Mauricio Calle Cedillo portador de la cédula de ciudadanía Nº 0803037647 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniero de Sistemas y Computación son absolutamente originales, auténticos y personales. En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legal y académica.

Édison Mauricio Calle Cedillo CI. 0803037647

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Franklin Ramiro Pérez Agurto portador de la cédula de ciudadanía Nº 1723278493 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniero de Sistemas y Computación son absolutamente originales, auténticos y personales. En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legal y académica.

Franklin Ramiro Pérez Agurto CI. 1723278493

AGRADECIMIENTO Agradezco a mis queridos padres y hermanos por su gran apoyo tanto económico como moral, por darme una carrera profesional para que la vida me conceda un mejor futuro, a pesar de las dificultades el tiempo les dio una sorpresa y han vuelto a confiar en mí. A mis compañeros de clases nuevos y antiguos quienes han compartido conmigo esta travesía de vida universitaria compartiendo ideas y conocimiento, tristezas y alegrías, a mi compañero de tesis por el gran apoyo y confianza brindada en poco tiempo. Édison Calle Expreso mis sinceros agradecimientos a mis padres y hermanos, por haber brindado todo el apoyo incondicional para culminar esta travesía de mi vida, ayudándome a cumplir con la meta que me propuse y motivándome a seguir siempre adelante. Un agradecimiento especial a Minyen Lee, ella pues, siendo la mayor motivación en mi vida encaminada al éxito, fue el ingrediente perfecto para poder lograr alcanzar esta dichosa y muy merecida victoria en la vida, el poder haber culminado este trabajo con éxito, y poder disfrutar del privilegio de ser agradecido, ser grato con esa persona que se preocupó por mí en cada momento y que siempre quiso lo mejor para mi porvenir; eres mi inspiración y mi motivación. Franklin Pérez

DEDICATORIA Dedico el presente trabajo de titulación a mis padres, por haberme impulsado a culminar mi carrera a lo largo de mi travesía como estudiante. Édison Calle Este trabajo de titulación se lo dedico a mis padres, por el motivo de cumplir con el anhelo de verme crecer como profesional. Dentro de mi recorrido por la vida me pude dar cuenta de que hay muchas cosas para las que soy bueno, encontré destrezas y habilidades que jamás pensé, se desarrollasen en mí; pero lo realmente importante es que pude descubrir que por más que disfrute trabajar solo, siempre obtendré un mejor resultado si lo realizo con la ayuda y compañía perfecta, por tal motivo, dedico a Minyen Lee este trabajo con el que he logrado culminar una etapa muy importante en mi vida. Franklin Pérez

vii

RESUMEN El presente trabajo de titulación es de vinculación con la sociedad, el cual comprende la investigación del desarrollo de un sistema web para la gestión de los semáforos en la Empresa Pública Municipal de Transporte Santo Domingo EPMT-SD, la que busca la manera de automatizar procesos manuales, optimizando recursos. El proyecto se enfocó en desarrollar e implementar un sistema web que permitió generar órdenes de mantenimiento con sus respectivos reportes y alertas de los semáforos en funcionamiento, automatizando la gestión de procesos que se llevaban a cabo en el departamento de tránsito. Se utilizó el marco de trabajo “Scrum” con sus fases para desarrollar el sistema web. Para el diseño del sistema se utilizó el lenguaje PHP versión 5.6.33 complementado con la Bootstrap 4.0; en el desarrollo del código se lo utilizó Sublime Text 3; para la fuente tipográfica se utilizó Font Awesome versión 5.0.8; para las alertas de mantenimiento se utilizó el plugin jQuery v3.3.1 y FullCalendar 3.9.0 que proporciona un calendario completo; para los reportes PDF de las órdenes de mantenimiento generados se utilizó Fpdf 1.81; la base de datos utilizada fue MariaDB 10.1.30 con el gestor MySQL Workbench 6.3 CE para manejar la administración de la base de datos a través de una interfaz gráfica de usuario y finalmente el servidor web Apache 2.4.29 que permitió el acceso al sistema a través de un navegador web, el cual se encuentra en un servidor que designó la EPMT-SD. Palabras claves: Investigación, automatización, software de código abierto.

viii

ABSTRACT The current titration work is of link with society, which includes the research of the development of a web system for the management of traffic lights in the Empresa PĂşblica Municipal de Transporte Santo Domingo EPMT-SD, which seeks to automate manual processes, optimizing resources. The project focused on developing and implementing a web system that allowed generating maintenance orders with their respective reports and alerts of the traffic lights in operation, automating the processes management that were carried out in the traffic department. The "Scrum" framework with its phases was used to develop the web system. For the design of the system the PHP language version 5.6.33 was used, complemented with the Bootstrap 4.0; Sublime Text 3 was used in the development of the code; Font Awesome version 5.0.8 was used for the typographic font; for maintenance alerts, the plugin jQuery v3.3.1 and Full Calendar 3.9.0 was used, which provides a complete calendar; for the PDF reports of the generated maintenance orders, Fpdf 1.81 was used; the database MariaDB 10.1.30 with the MySQL Workbench 6.3 CE manager was used in order to manage the database administration through a graphical user interface and finally the Apache 2.4.29 web server that allowed access to the system through a web browser which is located on a server that was designated by the EPMT-SD.

Keywords: Research, automation, open source software.

ÍNDICE DE CONTENIDOS 1. INTRODUCCIÓN ................................................................................................................. 1 2. PLANTEAMIENTO DEL PROBLEMA .............................................................................. 3 2.1. Problema de investigación .................................................................................................. 3 2.2. Justificación de la investigación ......................................................................................... 3 2.3. Objetivos de investigación .................................................................................................. 5 2.3.1. Objetivo General. ............................................................................................................. 5 2.3.2. Objetivos específicos. ...................................................................................................... 5 3. MARCO REFERENCIAL ..................................................................................................... 6 3.1. Antecedentes ....................................................................................................................... 6 3.2. Revisión de la literatura o fundamentos teóricos ................................................................ 8 3.2.1. Ingeniería de Software. .................................................................................................... 8 3.2.1.1. Desarrollo de software. ................................................................................................. 8 3.2.1.1.1. Conceptos básicos. ..................................................................................................... 8 3.2.1.1.2. Paradigma orientado a objetos. .................................................................................. 9 3.2.1.1.2.1. Características de POO. ........................................................................................ 10 3.2.2. Modelos de desarrollo ágil. ............................................................................................ 11 3.2.2.1. Programación Extrema (XP). ...................................................................................... 11 3.2.2.1.1. Proceso XP. .............................................................................................................. 12 3.2.2.1.2. Roles XP. ................................................................................................................. 12 3.2.2.1.3. Artefactos XP. .......................................................................................................... 12 3.2.2.2. Scrum. ......................................................................................................................... 13 3.2.2.2.1. Proceso Scrum. ........................................................................................................ 13 3.2.2.2.2. Roles Scrum. ............................................................................................................ 15 3.2.2.2.3. Artefactos Scrum. .................................................................................................... 16 3.2.2.2.4. Fases de Scrum. ....................................................................................................... 16 3.2.2.3. DSDM. ........................................................................................................................ 18 3.2.1. Comparación entre modelos ágiles. ............................................................................... 18 3.2.2.4. Modelado. ................................................................................................................... 19 3.2.2.4.1. Patrón MVC. ............................................................................................................ 19 3.2.2. Base de datos.................................................................................................................. 20 3.2.2.5. Lenguaje SQL. ............................................................................................................ 20 3.2.2.6. Diagrama entidad relación. ......................................................................................... 21

3.2.2.7. MySOL Workbench. ................................................................................................... 21 3.2.2.8. Normalización. ............................................................................................................ 22 3.2.2.8.1. Primera forma normal. ............................................................................................. 22 3.2.2.8.2. Segunda forma normal. ............................................................................................ 22 3.2.2.8.3. Tercera forma normal. ............................................................................................. 22 3.2.2.8.4. Cuarta forma normal. ............................................................................................... 23 3.2.2.9. Sistemas Gestores de Base de datos............................................................................ 23 3.2.2.9.1. MariaDB. ................................................................................................................. 23 3.2.2.9.2. PostgreSQL. ............................................................................................................. 23 3.2.2.9.3. DB2 Express-C. ....................................................................................................... 23 3.2.3. Comparación entre base de datos. .................................................................................. 24 3.2.4. Servicios web. ................................................................................................................ 25 3.2.4.1. Arquitectura de una página web. ................................................................................ 25 3.2.4.1.1. Cliente/Servidor. ...................................................................................................... 25 3.2.4.2. Tipos de páginas web. ................................................................................................. 26 3.2.4.2.1. Estáticas. .................................................................................................................. 26 3.2.4.2.2. Dinámicas. ............................................................................................................... 26 3.2.4.3. Diseño web.................................................................................................................. 26 3.2.4.3.1. Responsive Web Design. ......................................................................................... 27 3.2.4.4. Frameworks de diseño. ............................................................................................... 27 3.2.4.4.1. Materialize. .............................................................................................................. 27 3.2.4.4.2. Bootstrap. ................................................................................................................. 27 3.2.3. Herramienta de desarrollo web. ..................................................................................... 28 3.2.4.5. Editor de código SublimeText 3. ................................................................................ 28 3.2.4. Lenguajes de programación web. .................................................................................. 28 3.2.4.6. Front-End. ................................................................................................................... 28 3.2.4.6.1. HTML5 y CSS. ........................................................................................................ 28 3.2.4.6.2. JavaScript. ................................................................................................................ 29 3.2.4.7. Back-End..................................................................................................................... 29 3.2.4.7.1. PHP. ......................................................................................................................... 29 3.2.4.7.2. Python. ..................................................................................................................... 29 3.2.4.7.3. Java. ......................................................................................................................... 29 3.2.5. Comparación de lenguajes de desarrollo web. ............................................................... 30 4. METODOLOGÍA DE LA INVESTIGACIÓN ................................................................... 32

4.1. Enfoque/Diseño/Tipo de investigación ............................................................................. 32 4.1.1. Enfoque de investigación. .............................................................................................. 32 4.1.2. Diseño de investigación. ................................................................................................ 32 4.1.2.1. Diseño no experimental. ............................................................................................. 32 4.1.3. Tipo de investigación. .................................................................................................... 32 4.1.3.1. Investigación Exploratoria. ......................................................................................... 32 4.1.3.2. Investigación Descriptiva............................................................................................ 33 4.2. Población / Muestra .......................................................................................................... 33 4.2.1. Población........................................................................................................................ 33 4.2.2. Muestra. ......................................................................................................................... 33 4.3. Técnicas e instrumentos de recogida de datos .................................................................. 33 4.3.1. Técnicas de recogida de datos........................................................................................ 33 4.3.1.1. Entrevista. ................................................................................................................... 34 4.3.1.2. Encuesta. ..................................................................................................................... 34 4.3.1.3. Observación. ............................................................................................................... 34 4.4. Técnicas de Análisis de Datos .......................................................................................... 34 5. RESULTADOS.................................................................................................................... 36 5.1. Análisis situacional de la población para el uso del sistema ............................................ 36 5.1.1. Entrevista realizada al gerente de la empresa. ............................................................... 36 5.1.1.1. Discusión de la entrevista. .......................................................................................... 38 5.1.2. Encuesta realizada en la EPMT-SD. .............................................................................. 38 5.2. Propuesta de intervención ................................................................................................. 46 5.2.1. Fase de desarrollo del sistema utilizando el marco de trabajo Scrum. .......................... 47 5.2.1.1. Release Planning. ........................................................................................................ 47 5.2.1.2. Roles. .......................................................................................................................... 47 5.2.1.3. Eventos de Scrum. ...................................................................................................... 47 5.2.1.3.1. Product Backlog. ...................................................................................................... 50 5.2.1.3.2. Sprint 1. .................................................................................................................... 54 5.2.1.3.2.1. Sprint Planning...................................................................................................... 54 5.2.1.3.2.2. Sprint Backlog 1. .................................................................................................. 55 5.2.1.3.2.3. Burndown Chart Sprint 1. ..................................................................................... 56 5.2.1.3.2.4. Desarrollo del Sprint 1. ......................................................................................... 58 5.2.1.3.2.5. Sprint Retrospective 1. .......................................................................................... 61 5.2.1.3.2.6. Pruebas de Aceptación Sprint 1. ........................................................................... 61

xii

5.2.1.3.3. Sprint 2. .................................................................................................................... 64 5.2.1.3.3.1. Sprint Backlog 2. .................................................................................................. 64 5.2.1.3.3.2. Burndown Chart Sprint 2. ..................................................................................... 65 5.2.1.3.3.3. Desarrollo del Sprint 2. ......................................................................................... 67 5.2.1.3.3.4. Sprint Retrospective 2. .......................................................................................... 71 5.2.1.3.3.5. Pruebas de Aceptación Sprint 2. ........................................................................... 71 5.2.1.3.4. Sprint 3. .................................................................................................................... 73 5.2.1.3.4.1. Sprint Backlog 3. .................................................................................................. 73 5.2.1.3.4.2. Burndown Chart Sprint 3. ..................................................................................... 74 5.2.1.3.4.3. Desarrollo del Sprint 3. ......................................................................................... 76 5.2.2. Diseño relacional de la base de datos. ........................................................................... 84 5.2.3. Acta de entrega recepción. ............................................................................................. 86 5.3. Análisis del impacto.......................................................................................................... 86 5.3.1. Impacto Social. .............................................................................................................. 87 5.3.2. Impacto tecnológico. ...................................................................................................... 88 5.3.3. Impacto ambiental. ......................................................................................................... 88 5.3.4. Impacto económico. ....................................................................................................... 89 5.3.5. Impacto general. ............................................................................................................. 89 6. DISCUSIÓN DE RESULTADOS ....................................................................................... 90 6.1.1. Discusión de la entrevista. ............................................................................................. 90 6.1.2. Discusión encuestas. ...................................................................................................... 90 6.1.3. Discusión fase de desarrollo del software. ..................................................................... 90 7. CONCLUSIONES ............................................................................................................... 92 8. RECOMENDACIONES ...................................................................................................... 93 9. LISTA DE REFERENCIAS ................................................................................................ 94 10. GLOSARIO ....................................................................................................................... 98 11. ANEXOS ........................................................................................................................... 99

xiii

ÍNDICE DE TABLAS Tabla 1

Comparación entre modelos agiles. ...................................................................... 19

Tabla 2

Comparación de base de datos.............................................................................. 25

Tabla 3

Comparación de lenguajes de desarrollo web. ..................................................... 31

Tabla 4

Resultados obtenidos de la pregunta #1 de las encuestas. ................................... 39

Tabla 5

Resultados obtenidos de la pregunta #2 de las encuestas. ................................... 40

Tabla 6

Resultados obtenidos de la pregunta #3 de las encuestas. ................................... 40

Tabla 7

Resultados obtenidos de la pregunta #4 de las encuestas. ................................... 41

Tabla 8

Resultados obtenidos de la pregunta #5 de las encuestas. ................................... 42

Tabla 9

Resultados obtenidos de la pregunta #6 de las encuestas. ................................... 43

Tabla 10

Resultados obtenidos de la pregunta #7 de las encuestas. .................................... 44

Tabla 11

Resultados obtenidos de la pregunta #8 de las encuestas. .................................... 45

Tabla 12

Roles Scrum .......................................................................................................... 47

Tabla 13

Escala de complejidad. ......................................................................................... 48

Tabla 14

Product Backlog. .................................................................................................. 50

Tabla 15

Sprint Backlog 1 ................................................................................................... 55

Tabla 16

Burndown Chart Sprint 1...................................................................................... 56

Tabla 17

Prueba de aceptación 1. ........................................................................................ 61

Tabla 18

Prueba de aceptación 2. ........................................................................................ 61

Tabla 19

Prueba de aceptación 3. ........................................................................................ 62

Tabla 20

Prueba de aceptación 4. ........................................................................................ 62

Tabla 21

Prueba de aceptación 5. ........................................................................................ 63

Tabla 22

Sprint Backlog 2. .................................................................................................. 64

Tabla 23

Burndown Chart Sprint 2...................................................................................... 65

Tabla 24

Prueba de aceptación 6. ........................................................................................ 71

Tabla 25

Prueba de aceptación 7. ........................................................................................ 71

Tabla 26

Prueba de aceptación 8. ........................................................................................ 72

Tabla 27

Prueba de aceptación 9. ........................................................................................ 72

Tabla 28

Prueba de aceptación 10. ...................................................................................... 72

Tabla 29

Sprint Backlog 3. .................................................................................................. 73

Tabla 30

Burndown Chart Sprint 3...................................................................................... 74

Tabla 31

Niveles de Impacto. .............................................................................................. 86

Tabla 32

Impacto Social. ..................................................................................................... 87

xiv

Tabla 33

Impacto Tecnolรณgico. ........................................................................................... 88

Tabla 34

Impacto ambiental. ............................................................................................... 88

Tabla 35

Impacto econรณmico............................................................................................... 89

Tabla 36

Impacto general. ................................................................................................... 89

ÍNDICE DE FIGURAS Figura 1. Proceso de la metodología SCRUM. ........................................................................ 13 Figura 2. Patrón Modelo-Vista-Controlador ............................................................................ 20 Figura 3. Diagrama de procesos, actividades y tareas de la gestión de semáforos. ................. 38 Figura 4. Figura obtenida de la pregunta #1 de las encuestas. ................................................. 39 Figura 5. Figura obtenida de la pregunta #2 de las encuestas. ................................................. 40 Figura 6. Figura obtenida de la pregunta #3 de las encuestas. ................................................. 41 Figura 7. Figura obtenida de la pregunta #4 de las encuestas. ................................................. 42 Figura 8. Figura obtenida de la pregunta #5 de las encuestas. ................................................. 43 Figura 9. Figura obtenida de la pregunta #6 de las encuestas. ................................................. 44 Figura 10. Figura obtenida de la pregunta #7 de las encuestas. ............................................... 45 Figura 11. Figura obtenida de la pregunta #8 de las encuestas. ............................................... 46 Figura 12. Gráfico del Burndown Chart 1. .............................................................................. 57 Figura 13. Captura de pantalla del login. ................................................................................. 59 Figura 14. Captura de pantalla Lista personas. ........................................................................ 59 Figura 15. Captura de pantalla de ventana Agregar nueva persona. ........................................ 60 Figura 16. Captura de pantalla de alerta de Eliminar persona. ................................................ 60 Figura 17. Captura de pantalla de la ventana Editar persona. .................................................. 60 Figura 18. Gráfico del Burndown Chart 1. .............................................................................. 66 Figura 19. Captura de pantalla de Lista de usuarios. ............................................................... 68 Figura 20. Captura de pantalla Agregar nuevo usuario. .......................................................... 68 Figura 21. Captura de pantalla de Lista de avenidas. .............................................................. 68 Figura 22. Captura de pantalla de Agregar nueva avenida. ..................................................... 69 Figura 23. Captura de pantalla de Lista de direcciones. .......................................................... 69 Figura 24. Captura de pantalla de Agregar nueva dirección. ................................................... 69 Figura 25. Captura de pantalla de Editar dirección.................................................................. 70 Figura 26. Captura de pantalla de Lista de tipos de artículos. ................................................. 70 Figura 27. Captura de pantalla de Agregar tipo de artículo. .................................................... 70 Figura 28. Gráfico del Burndown Chart 3 ............................................................................... 75 Figura 29. Captura de pantalla de Lista de artículos. ............................................................... 77 Figura 30. Captura de pantalla de Agregar artículos. .............................................................. 77 Figura 31. Captura de pantalla de Lista de artículos activos. .................................................. 78 Figura 32. Captura de pantalla de Artículos activos. ............................................................... 78

xvi

Figura 33. Captura de pantalla de Activar artículo. ................................................................. 78 Figura 34. Captura de pantalla de Lista de vehículos. ............................................................. 80 Figura 35. Captura de pantalla de Agregar nuevo vehículo..................................................... 80 Figura 36. Captura de pantalla de Lista de órdenes de mantenimiento. .................................. 81 Figura 37. Captura de pantalla de Generar orden de mantenimiento. ..................................... 81 Figura 38. Captura de pantalla de Calendario de alertas de mantenimiento. ........................... 83 Figura 39. Captura de pantalla de Reporte de artículos. .......................................................... 84 Figura 40. Diseño relacional de la Base de Datos. .................................................................. 85

xvii

ร NDICE DE ANEXOS

Anexo 1.Hoja de requerimientos del sistema .......................................................................... 99 Anexo 2. Encuesta ................................................................................................................. 100 Anexo 3. Historias de Usuario. .............................................................................................. 102 Anexo 4. Retrospectiva 1. ...................................................................................................... 110 Anexo 5. Retrospectiva 2. ...................................................................................................... 111 Anexo 6. Carta de entrega recepciรณn. .................................................................................... 112 Anexo 7. Manual de usuario. ................................................................................................. 113 Anexo 8. Manual de instalaciรณn............................................................................................. 113 Anexo 9. Diccionario de datos. .............................................................................................. 113 Anexo 10. Carta de impacto................................................................................................... 114

1. INTRODUCCIÓN El presente trabajo de titulación comprende el desarrollo de un sistema web para la gestión de los semáforos en la Empresa Pública Municipal de Transporte Terrestre, Tránsito y Terminales Terrestres Santo Domingo, el cual busca automatizar procesos manuales, optimizando recursos como el tiempo y dinero, mediante la implementación de este sistema web cuyo propósito es generar ordenes de mantenimiento, alertas de manteniendo y la generación de reportes en base a las ordenes generadas; se lo realizó mediante 10 fases que se describen a continuación. Primera fase: introducción que describe las fases del trabajo de titulación. Segunda fase: planteamiento del problema, se comprende por el problema de investigación que constituye la idea principal en forma de preguntas. La justificación que tiene el por qué y para qué de la investigación, conjuntamente se relaciona con el objetivo del Plan Nacional del Buen Vivir PNBV y en la parte final se determinan los objetivos de investigación que se expresan en el desarrollo del trabajo de titulación. Tercera fase: marco referencial es la sustentación teórica que, a través de libros, artículos científicos e información bibliográfica se detallan las variables que conducirán al desarrollo del proyecto con la variable independiente y la dependiente. La variable independiente se constituye por la teoría necesaria, esta variable permitirá guiar en la elección de herramientas para el desarrollo del sistema y la variable dependiente contiene las actividades e información de la empresa, dando una orientación clara de lo que debe hacer el sistema. Cuarta fase: metodología de investigación, contiene un enfoque, diseño, tipo, población, muestra, técnicas e instrumentos de recogida de datos y técnica de análisis de datos. Quinta fase: resultados, contiene la presentación de cómo se lograron realizar los objetivos planteados utilizando como base los requerimientos recolectados con la entrevista y encuestas, interviniendo con los respectivos análisis de discusión de los mismos. Sexta fase: discusión de resultados, este contiene las discusiones de la entrevista, encuestas y la fase de desarrollo del software.

Séptima fase: contiene las conclusiones del trabajo de titulación que pudieron ser deducidas en base a los objetivos planteados. Octava fase: recomendaciones se realizan en base las conclusiones para que el lector tenga información adicional del trabajo de titulación. Novena fase: describe la lista de referencias que se encuentran en el trabajo de titulación. Décima fase: se muestran los términos que el usuario general no puede interpretar. Onceava fase: en este apartado se muestran los documentos que adjuntan dentro del trabajo de titulación.

2. PLANTEAMIENTO DEL PROBLEMA 2.1. Problema de investigación El presente proyecto de investigación responderá a la siguiente problemática: ¿Cómo mejorar la insuficiente gestión de los semáforos en la Empresa Pública Municipal de Transporte de la provincia de Santo domingo de los Tsáchilas? Tomando en cuenta este panorama, la presente investigación permitirá responder las siguientes preguntas directrices: ¿Cuáles son los procesos para el manejo de información del sistema en la Empresa Pública Municipal de Transporte”? ¿Cuáles son las funcionalidades que tendrá el sistema de gestión de semáforos en su fase de implementación? ¿Cuál es la metodología de desarrollo de software para la implementación del sistema de Gestión de semáforos?

2.2. Justificación de la investigación El tema del presente trabajo de titulación se centra en una problemática importante que tiene la empresa, como es el desarrollo de un sistema web para la gestión de semáforos en la Empresa Pública Municipal de Transporte Terrestre, Tránsito, Seguridad Vial y Terminales Terrestres Santo Domingo EPMT-SD, ya que no hay un sistema automatizado en esta área de servicio, con este desarrollo web, se da un control a los procesos que existen acerca de la gestión de los semáforos. La EPMT-SD podrá obtener eficiencia con la implementación del sistema web para la gestión de semáforos, ya que existe la necesidad de trabajar de manera actualizada, garantizando la seguridad y rapidez de la información con el fin de brindar un mejor servicio. El alcance del presente trabajo de titulación es solo crear ordenes de mantenimiento, alertas de mantenimiento de los artículos activos que poseen garantía y la generación de reportes de las órdenes que fueron generadas. Una vez que se definió lo que realizará el sistema Web, tuvo una gran aceptación por parte del personal de la empresa.

El personal del departamento de tránsito estará estrechamente relacionado con el sistema por motivos de vital importancia, dando solución a los inconvenientes que posee con respecto a la gestión de los semáforos para el acceso de la información que manejarán estos procesos; el beneficio directo será para la ciudad como tal, que indirectamente, brindará un servicio de calidad para las personas que conduzcan un vehículo y a los transeúntes al circular día a día por las calles, haciendo uso de los semáforos. Tomando en cuenta lo anteriormente mencionado, se facilitará una mejora del control de los semáforos con el fin de ayudar y satisfacer la organización de la información para facilitar su visualización. La presente investigación está relacionada con el objetivo 11 del Plan Nacional del Buen Vivir en el cual se constituye de Asegurar la soberanía y eficiencia de los sectores estratégicos para la transformación industrial y tecnológica con la política de “ Impulsar la calidad, la seguridad y la cobertura en la prestación de servicios públicos, a través del uso de las telecomunicaciones y de las TIC; especialmente para promover el acceso a servicios financieros, asistencia técnica para la producción, educación y salud” (Secretaria Nacional de Planificación y Desarrollo [SENPLADES], 2017). Durante la investigación que ha dado lugar a este trabajo de titulación, surgieron preguntas que fueron importantes para la motivación y desarrollo del proyecto. Al conocer los procesos dentro de la EPMT-SD, como disertantes se adquirió conocimientos del mundo laboral donde un Ingeniero de Sistemas y Computación se desenvuelve fácilmente creando software que brinde la satisfacción del cliente, obteniendo un producto confiable y de calidad; esto ayuda a la empresa con la toma de decisiones y resolviendo problemas frecuentes a través de la tecnología.

2.3. Objetivos de investigación 2.3.1. Objetivo General. Implementar un sistema web para la gestión de semáforos en la Empresa Pública Municipal de Transporte Terrestre, Tránsito, Seguridad Vial y Terminales terrestres Santo Domingo. 2.3.2. Objetivos específicos. •

Determinar los procesos que se llevan a cabo para el control de gestión de los semáforos en la EPMT-SD.

•

Definir la metodología de desarrollo de software, que se adapta al desarrollo del sistema de gestión de semáforos en la EPMT-SD.

•

Desarrollar el Sistema Web de gestión de semáforos.

3. MARCO REFERENCIAL 3.1. Antecedentes La presente investigación se ha realizado en la Empresa Pública Municipal de Transporte Terrestre, Tránsito y Terminales Terrestres Santo Domingo que se encuentra en la provincia Tsáchila cuya dirección se ubica en la Av. Abrahán Calazacón y Av. Río Toachi junto a la ex Fábrica de Ladrillos. El 22 de agosto de 2013, en la alcaldía de Víctor Manuel Quirola Maldonado, la Empresa Pública Municipal de Transporte Santo Domingo, inicia sus actividades en la matriculación de los vehículos de la provincia. La autonomía de esta entidad surge a partir de la provincialización del cantón Santo Domingo la cual permitió obtener beneficios a la población. La empresa posee múltiples funciones, las cuales permiten avanzar en la modernización de la ciudad como tal, llevando un mejor control de la urbe que es de gran importancia para todos quienes coexistimos, lo que trae consigo una responsabilidad que acarrea problemáticas como la deficiente gestión de semáforos debido al crecimiento constante de nuestra comunidad; esto incrementa la cantidad de información generada por las nuevas instalaciones semafóricas, que tienen como el afán de mejorar la circulación vehicular. Cada día laborable se registra nueva información en el departamento de Tránsito que está a cargo de los semáforos, lo cual se presenta como un nuevo reto por la cantidad de semáforos que están ubicados en diferentes sitios, los cuales el personal encargado no aplica los procedimientos de control, lo que conlleva a la perdida de la trazabilidad acerca de los equipos que existen en la zona urbana y rural. Además, se observó que la empresa no posee un sistema automatizado para el control y actualización de la información de todos los semáforos que existen en la ciudad, lo cual acarrea una mala realización en algunos de los informes manuales que podrían presentar inconsistencias. El control interno de la empresa es un elemento fundamental, en donde se determinó que no existe un plan de mantenimiento automatizado siendo esta una herramienta que se

debe aplicar en sus operaciones para asumir un control de los problemas de funcionamiento en los semáforos.

Debido a las observaciones anteriormente mencionadas se ha determinado la insuficiente gestión de los semáforos en la Empresa Pública Municipal de Transporte de la provincia de Santo domingo de los Tsáchilas; es un problema donde las ordenes de mantenimiento pierden trazabilidad ya que el seguimiento de las mismas es deficiente por el motivo de que existen hojas físicas, en conjunto con los artículos que se encuentran ya en funcionamiento o en bodega, se ve la necesidad de gestionar el problema detectado en el transcurso del tiempo y que se ha ido haciendo cada vez de mayor envergadura debido a los procedimientos donde toda la información generada no tiene un sistema automatizado que permita a la empresa llevar un control eficiente de los semáforos. La investigacion realizada por Guerrero, Damián, Flores y Llamas (2010), a nivel de centro América se dio una solución similar desarrollando una Plataforma para Gestión de la Red de Semáforos de Zonas Urbanas en la ciudad de Colima México, dado que este proyecto se enfocó a la necesidad de sistemas de control vial más eficientes. Según Ibarra y Piña (2011), a nivel nacional existen proyectos que gestionan los semáforos. Uno de ellos denominado Propuesta para el mejoramiento del transporte público urbano para la ciudad de Azogues con perspectivas hacia: la seguridad vehicular, contaminación ambiental y gestión del tránsito de la provincia de Cuenca para gestionar adecuadamente los flujos de tránsito y mejorar la seguridad vial en las carreteras. El proyecto Control y reprogramación de un controlador de tráfico por medio de la red de telefonía móvil según Espín y Saltos (2010), para su implementación en el área de semaforización de la policía nacional de la zona sur del distrito metropolitano de quito también realiza la gestión como factor principal para optimizar la regulación de intersecciones de la Red vial, mediante la apropiada duración y sincronización de las señales de semáforos, de acuerdo a volúmenes de vehículos y peatones.

3.2. Revisión de la literatura o fundamentos teóricos 3.2.1. Ingeniería de Software. “La ingeniería de software, es el conjunto de técnicas, métodos y herramientas que utilizamos en el desarrollo, implementación y mantenimiento de un sistema informático que permite elaborar software de calidad” (Pressman, 2010, p. 43). 3.2.1.1. Desarrollo de software. El desarrollo de software según Arias (2015), es una tarea que debe ser llevada a cabo de manera profesional, cumpliendo con los propósitos del negocio. Por ello es que la Ingeniería de Software al ser un conjunto de métodos, técnica y/o herramientas, ayuda a desarrollar proyectos de manera profesional aplicando buenas prácticas apropiadas acorde al ciclo de vida del software, es por medio de la Ingeniería de Software que se captan los requerimientos, se plantea el diseño, se realizan pruebas y se despliegue el software asegurando en cada momento mantener la calidad, cumpliendo con la satisfacción del usuario final (pp. 74-75). 3.2.1.1.1. Conceptos básicos. “Programa: es un software de aplicación y está conformado por varios factores con un mismo fin, siendo así un conjunto de instrucciones interrelacionadas entre sí para cumplir un objetivo específico en momentos determinados” (Moreno, 2013, p. 22). Variables: son símbolos que sirven para identificar elementos. Teniendo en cuenta a Moreno (2013), las variables son espacios de memoria en el cual puede almacenar, borrar o modificar valores del tipo que se desee para su posterior uso durante la ejecución de un programa y gracias a este reservo de memoria un programa puede realizar operaciones con distintos valores guardados (p. 9). “Vector: conocido también como array permite hacer referencia a un conjunto de variables utilizando diferentes dimensiones en un mismo nombre y para localizar cada valor que se encuentre dentro del array se itera” (Thierry, 2013, p. 23). Método: es el camino a seguir para llegar a un objetivo o fin, en la opinión de Flórez (2012) manifiesta que los métodos son servicios incluidos en la clase y pueden ser visibles y

utilizables del exterior de acuerdo a la seguridad del método, retorno de información, nombre del método y parámetros (pp. 26-27). Comunicación: como señala Piattini y sus colaboradores (2012) en esta fase se hace la recolección de requerimientos por parte del jefe de proyecto hacia el cliente, con el objetivo de que todos los integrantes del grupo de desarrollo estén informados de lo que se requiere y posteriormente realizar una planificación para el despliegue del sistema. En esta sección se especifican los requerimientos para realizar las características y funciones del sistema. (pp. 184-185). Planeación: es la parte donde se fija una meta, en el proceso de desarrollo de software ayuda para la toma de decisiones y laborar de manera eficiente y eficaz basándose como objetivo la calidad de software. Desde el punto de vista de Sommerville citado por Rosado, Quintero & Meneses (2012) deduce que divide los trabajos, evalúa el esfuerzo, recursos requeridos para el desarrollo e implementación (p. 26). Modelado: se manifiesta una perspectiva de cómo estará formado el sistema que se desea emplear junto con sus relaciones y si es necesario se reformula el bosquejo con más detalles, de acuerdo con Holmes & Kendall citado por Rosado et al. (2012) define que para una mejor comprensión de la problemática se apoya de documentación de los requerimientos los cuales ayudan a modular la problemática (p. 26). Construcción: “en esta sección se codifica el sistema utilizando los recursos necesarios como lenguajes de programación e iteraciones en el desarrollo, junto con las pruebas de cada módulo dependiendo de la metodología empleada” (Báez y Suárez, 2013, pp. 50-51). Despliegue: “una vez culminado el desarrollo del sistema con sus respectivas pruebas se pasa a la etapa de entrega del mismo al o los clientes, conocido también como transición y el consumidor examina el sistema para comprobar sus requerimientos” (Báez y Suárez, 2013, p. 55). 3.2.1.1.2. Paradigma orientado a objetos. Desde el punto de vista de López (2013) el paradigma orientado a objetos es una metodología de desarrollo que abarca estándares, teorías y métodos donde la organización de

sus componentes es mediante objetos, en los cuales cada uno de estos es perteneciente a una clase. Siendo así un modo de organizar el pensamiento de los desarrolladores. La programación orientada a objetos (POO) es un paradigma de desarrollo y su metodología es muy parecida a como hacemos las cosas acumulando sus iteraciones y objetos para el cumplimiento de un objetivo (p. 222). 3.2.1.1.2.1. Características de POO. Abstracción: se enfoca en recolectar características y apartar cualidades articulares de objetos que sirven como guías para realizar gestiones, comunicarse con otros objetos, cambiar su estado e informar, por tal razón, es un proceso clave para el análisis y diseño orientado a objetos. Encapsulamiento: esto permite agrupar métodos y variables de un objeto en una clase con un mismo método de abstracción. De acuerdo con Flores (2012) considera que es una característica que indica que los atributos que definen propiedades propias de la clase deben tener visibilidad prívate. De esta forma se ofrece seguridad a la información depositada en dichos atributos. Se puede indicar que es como una caja negra, porque se puede hacer uso de sus características y comportamiento sin necesidad de conocer como está estructurada internamente. Modularidad: esto se refiere en dividir algo complejo en partes pequeñas para reducir su complejidad, es decir en módulos, tienen relación con otros módulos, se pueden compilar por separado y así dar solución al problema. Principio de ocultación: como afirma Pérez (2015) varias veces se puede requerir del uso de estados o valores de variables para un proceso interno y estos no se desean que puedan ser modificados por externos, para esto surge la ocultación permitiendo el acceso solo a los métodos que estén dentro del mismo módulo (p. 13). Polimorfismo: según López (2013) significa varias formas y esta característica es una de las que ayuda a una ágil codificación por el motivo de que cuando se envían diferentes tipos de datos a una misma función, esta interpreta lo que debe hacer según los valores recibidos teniendo comportamientos diferentes a objetos distintos (p. 386).

Herencia: es crear nuevas clases a partir de una ya existen, es decir subclases que tengan un mismo estado y métodos, esto evita volver a escribir de nuevo el código, simplemente heredar de una clase ya existente a otra llamada clase hija, haciendo más sencilla la parte del polimorfismo. Recolección de basura: de acuerdo con Pérez (2015) también conocido

como

garbage collector es un método de POO que automáticamente destruye el valor en memoria asociada a todos los objetos que ya no tengan referencia, gracias a esto el desarrollador no debe preocuparse por la asignación o liberación de memoria (p. 14). 3.2.2. Modelos de desarrollo ágil. 3.2.2.1. Programación Extrema (XP). La programación extrema (XP) es una de las metodologías de desarrollo ágil que se usan para los proyectos por su alto grado de adaptabilidad. Según Navarro y colaboradores (2013) la programación extrema o Extreme Programing o XP por sus siglas en inglés, fue desarrollado por Kent Beck. Es uno de los métodos ágiles más renombrado, conocido y preferido para el desarrollo ágil de software. Es utilizado en proyectos pequeños o medianos con equipos de trabajo entre 2 a 10 miembros (p. 34). En caso de no cumplir con lo establecido tiene como desventaja su elevado costo. De acuerdo con Rosado et al. (2012) manifiesta que este tipo de metodología se centra en la simplicidad, la colaboración del cliente, el trabajo en conjunto, la reutilización de código entre otras afines al Manifiesto Ágil. XP hace uso de las buenas prácticas y su filosofía se basa en cuatro principios fundamentales los cuales son: •

Entregas de prototipos

•

Semana de 40 horas laborales

•

Colaboración activa del cliente

•

Programación en parejas

3.2.2.1.1. Proceso XP. El proceso de la metodología XP consiste en lo siguiente: •

El cliente define el valor de negocio a implementar.

•

El programador estima el esfuerzo necesario para su implementación.

•

El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo.

•

El programador construye ese valor de negocio.

•

Vuelve al primer paso.

3.2.2.1.2. Roles XP. •

Programadores: define tareas a partir de las historias, escriben las pruebas unitarias y producen el código del sistema (se requieren mínimo 2 programadores).

•

Tester: ayuda en la elaboración de pruebas funcionales y apoya al cliente a definir las historias de usuario.

•

Tracker: presenta una retroalimentación al equipo del proyecto, establece prioridades, explica las historias, tiene autoridad para decidir cuestiones relativas a las historias.

•

Coach: siendo el experto en XP, es el responsable del proceso global.

•

Cliente: escribe las historias de usuario, el proceso de negocio.

•

Gestor: planifica las reuniones, estable el vínculo entre los clientes y los programadores, siendo el principal encargado del proceso de XP.

•

Consultor: es un miembro externo del equipo quien provee conocimientos específicos para la elaboración del Sistema.

3.2.2.1.3. Artefactos XP. Los artefactos esenciales de XP son los siguientes: •

Historias de Usuario

13 •

Tareas de Ingeniería

•

Pruebas de aceptación

•

Pruebas unitarias y aceptación

•

Plan de entrega

•

Código

3.2.2.2. Scrum. Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversión. Se basa en construir primero la funcionalidad de mayor valor para el cliente siguiendo los principios de inspección continua, adaptación, auto-gestión e innovación. Según Schwaber y Sutherland (2016) es un cuadro de trabajo donde se utiliza varias técnicas y procesos, que son usados para encargarse del desarrollo de productos, el cuadro de trabajo se compone de lo siguiente: reglas de SCRUM que unen los eventos, roles y artefactos. Se fundamentan en la teoría de control de procesos empírica, explicando esto decimos que lo empírico representa el conocimiento que se obtiene a través de la experiencia y de la toma de decisiones (pág. 4). 3.2.2.2.1. Proceso Scrum.

Figura 1. Proceso de la metodología Scrum. Tomado de Diferencias entre Scrum y Xp por Isla Visual (2012). Recuperado el 11 de septiembre de 2017. Obtenido de: http://www.islavisual.com/articulos/desarrollo_web/diferencias-entre-scrum-y-xp.php

Product Backlog: conjunto de requisitos denominados historias descritos en un lenguaje no técnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de inversión considerando su beneficio y coste. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares. Es diseñado por el cliente o representante de la empresa, aunque puede contar con la participación de todos los roles antes mencionados para mantenerlo actualizado, se trata de una lista con los requisitos del proyecto debe contar con un tiempo estimado y priorizando tareas, debe estar escrito en un lenguaje entendible para todos los Involucrados, deben realizar una revisión antes de cada Sprint. En el product backlog es bien sabido que se tiene que priorizar las historias de usuarios y los requisitos no funcionales, en caso de existir las denominadas épicas las cuales son demasiado extensas para entrar en un sprint, estos suelen tener un etiquetado que ayuda a agruparlos conocido como tema. Los expertos recomiendan priorizar desde el punto de vista de épicas y tema. (Alvaréz, de las Heras, & Lasa, 2012, pp. 124-125) Sprint Planning: reunión durante la cual el Product Owner presenta las historias de usuario del Product Backlog por orden de prioridad. El equipo determina la cantidad de historias que puede comprometerse a completar en ese sprint y organizar cómo lo va a conseguir. “Es una reunión donde se planifica el sprint, se define el trabajo a realizar tomando en cuenta si se logra alcanzar las tareas mediante un consenso con el Scrum Master, con todo el equipo se divide las tareas entre sí de acuerdo al perfil profesional de cada miembro” (Alvaréz, de las Heras, & Lasa, 2012, p. 41). “El equipo refina los requisitos del cliente en tareas expresadas en un lenguaje más técnico, definiendo tiempo a cada tarea, se realiza al inicio de cada sprint” (Alvaréz, de las Heras, & Lasa, 2012, p. 41). “Cuando tenemos historias de usuario demasiadas complejas que impidan realizar el sprint, se debe dividir hasta tener unidades manejables” (Alvaréz, de las Heras, & Lasa, 2012, p. 152). Sprint: iteración de duración prefijada durante la cual el equipo trabaja para convertir las historias del Product Backlog a las que se ha comprometido, en una nueva versión del software totalmente operativo. Sprint Backlog: lista de las tareas necesarias para llevar a cabo las historias del sprint.

En el tablero del Sprint Backlog se encuentran ubicadas las tareas a realizar en el proyecto, es la forma más simple de mostrar que vamos a realizar y mantener actualizado el sprint, se ubica en un lugar visible para todos, existen cuatro estados para cada tarea en el tablero. Daily sprint meeting: reunión diaria de máximo quince minutos en la que el equipo se sincroniza para trabajar de forma coordinada. Cada miembro comenta que hizo el día anterior, que hará hoy y si hay impedimentos. “Es un tiempo de sincronización de los integrantes del equipo, sirve para compartir el avance y las ideas acerca del proyecto en ese momento, en caso de tener problemas grandes no deben utilizar esta reunión, para solucionar el inconveniente debe convocar a una reunión extra” (Alvaréz, de las Heras, & Lasa, 2012, p. 41). Retrospectiva: reunión que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas mediante una demonstración del producto. Posteriormente, en la retrospectiva, el equipo analiza qué se hizo bien, qué procesos serían mejorables y discute acerca de cómo perfeccionarlos. Como señala Deemer y colaboradores (2009), se pueden utilizar los siguientes gráficos de esfuerzo pendiente: días pendientes para completar los requisitos del producto o proyecto (product burndown chart), realizado a partir del Backlog product. Horas pendientes para completar las tareas de la iteración (sprint burndown chart), realizado a partir de la lista de tareas de la iteración, además de presentar una versión beta del sistema (pp. 12-15). 3.2.2.2.2. Roles Scrum. Scrum Master: dirige al equipo para cumplir las reglas y procesos de la metodología, trabajando con el dueño del producto. “Es la persona que lidera el equipo, guiándolo en el cumplimiento de los objetivos pactados con el cliente, respetando la metodología” (Alvaréz, de las Heras, & Lasa, 2012, pp. 40-42). Product Owner (Cliente): “representante de la empresa o el cliente que va a usar el software, está encargado de entregar los requisitos, indicando el orden como se debe llevar a cabo en el proyecto” (Alvaréz, de las Heras, & Lasa, 2012, pp. 40-42). Scrum Team: es el equipo de trabajo con conocimientos técnicos necesarios para que

desarrollen el proyecto de manera conjunta llevando a cabo las historias de usuario a las que se comprometieron al inicio de cada sprint. “Son el grupo de profesionales multidisciplinarios con conocimientos científicos, encargado de llevar a cabo cada tarea de la construcción del proyecto” (Alvaréz, de las Heras, & Lasa, 2012, pp. 40-42). 3.2.2.2.3. Artefactos Scrum. •

Sprint: nombre que recibe cada iteración de desarrollo. Es el núcleo central que genera el avance por tiempos prefijados.

•

Product Backlog: es una lista ordenada de todo lo que podría ser necesario para el producto, y la única fuente de requerimientos para cualquier cambio a realizarse. Contiene todas las características, funcionalidades, requerimientos, mejoras y correcciones del producto, y otros atributos como descripción, ordenación y estimación. Evoluciona a medida que el producto y el entorno en el que será usado también lo hacen.

•

Sprint Backlog: es la recopilación de ítems del Product Backlog, negociados entre el Product Owner y el Scrum Team en la ceremonia de planificación, reunión que se realiza al comienzo del Sprint. Y que el Scrum Team se compromete a construir durante el Sprint en curso

•

Burndown Chart: “es una gráfica que demuestra cómo está avanzando, si se encuentra atrasado o adelantado el proyecto, en las fechas estimadas existen dos tipos de graficas: la primera indica el avance de cada sprint y la segunda indica la totalidad del proyecto” (Brito, Sosa, & Héctor, 2011, p. 53).

•

Incremento: resultado final de cada Sprint.

3.2.2.2.4. Fases de Scrum. Fase de planificación: son indagaciones previas abarcando tanto la visión como el estudio ya que se trata de un nuevo sistema y no de mejora de uno ya existente, sirven de guía al investigador facilitándole hacer comparaciones y tener idea clara sobre cómo se trató el problema en esa oportunidad, debe detallar lo más claro, que es lo que se realiza y como va ser su resultado final, explicar que se va a producir, como lo va a sacar adelante y quien lo va a ejecutar.

Como señala Deemer, Benefield, Craig y Vodde (2009), el Sprint inicial es una lista de tareas que el equipo de trabajo se ha propuesto realizar al finalizar el primer sprint, esta lista se construye a partir de las tareas que conforman el Product Backlog, seleccionándolas por su nivel de prioridad, donde se presenta diagramas de: clases, casos de usos, secuencia y una aproximación de la base de datos (pp. 7-10). Fase de desarrollo: son ciclos de trabajos repetitivos como también determina el cumplimiento de funcionalidad, calidad y tiempo. Si la lista de requerimientos cambia, es necesario mostrar los cambios realizados, pero solo ese fragmento del listado. Entrega de los Sprint Backlog son las metas propuestas para los ciclos de desarrollo. Reporte del Sprint Review Meeting documenta el trabajo completando y no completado registrando problemas encontrados haciendo adaptaciones necesarias, para ir re-planificando el proyecto. Reporte del Sprint Retrospective, su objetivo es la mejorar de manera continua de la productividad y la calidad del producto que se desarrolla, el equipo observa cómo ha sido su manera de trabajar durante la iteración, para examinar si está o no consiguiendo los objetivos a los que se comprometió al inicio de la iteración y si el incremento del producto que acaba de indicar al cliente era lo que él esperaba o no. Fase de finalización: en esta fase se debe hacer una presentación del producto final, es decir, su lanzamiento donde se describe al software, su aplicación y requerimientos necesarios para utilizar el producto como: espacio en disco, memoria RAM mínima, sistema operativo, programas necesarios para su utilización del sistema. Si la lista de requerimientos ha cambiado, entonces es necesario mostrar los cambios realizados, pero solo fragmentos del listado. Se pueden utilizar los gráficos de esfuerzo pendiente como días pendientes para completar los requisitos del producto o proyecto (Product Burndown Chart), realizado a partir del Product Backlog, se ubican las horas pendientes para completar las tareas de ingeniería. Reporte del Sprint Retrospective, son las respuestas del equipo en un formulario resumen, los puntos que merezcan atención como ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad.

Manual de usuario, se le entregará al cliente un documento, el cual pretende ser una guía rápida sobre cómo usar las funciones principales del sistema, dicho documento contará con una sección para resolver posibles problemas que se presenten y este puede ser entendido por cualquier usuario principiante, como así también serles útil a usuarios avanzados. El texto puede venir acompañado de algunas imágenes o tener alguna sección de anexos para que el usuario tenga elementos gráficos que lo ayuden a tener una mejor guía sobre algún problema en específico. “Se entregará un CD/DVD que contenga los siguientes elementos: el Código Fuente o el/los archivos ejecutables o similares o el manual de usuario o el manual del sistema” (Deemer, Benefield, Craig, & Vodde, 2009, pp. 15-18). 3.2.2.3. DSDM. Por sus siglas en inglés Dynamic Systems Development Method, es la metodología del desarrollo de sistemas dinámicos que se centra en entregar el producto final rápidamente controlando los procesos al mismo tiempo con el proyecto y sus estructuras orientadas a objetos. (Caracheo, 2014) 3.2.1. Comparación entre modelos ágiles. La comparación tuvo como objetivo diferenciar los modelos agiles más destacadas XP, Scrum y DSDM para el desarrollo de software. En base a la documentación mostrada anteriormente, se utilizaron las siguientes características para determinar el modelo de desarrollo óptimo que se adapte al presente trabajo de titulación. Con los siguientes parámetros se comparó los modelos ágiles, si estos cumplen: •

El 100% de la característica escogida para el trabajo de titulación: 10 puntos.

•

Al menos el 50% de la característica, es decir, cumple con los parámetros, pero no en su totalidad: 5 puntos.

•

No cumple con la característica: 0 puntos.

La comparación se analizó con las siguientes características: •

Trabajo en equipo: programación en pareja que permite desarrollar el software en equipo involucrando al cliente durante el desarrollo.

•

Desarrollo Incremental e Iterativo: describe el proceso de desarrollo.

•

Calidad: describe la funcionabilidad, eficiencia y portabilidad del modelo.

•

Comunicación: permite al equipo de trabajo con el usuario durante el proceso de desarrollo

•

Resultados: entregables y desarrollo final del proyecto a corto plazo.

Tabla 1 Comparación entre modelos agiles. Característica Trabajo en equipo Desarrollo Incremental e Iterativo Calidad Comunicación Resultados Total Porcentaje

XP 10 5 5 5 10 35/50 70%

SCRUM 10 10 10 10 10 50/50 100%

DSDM 5 10 5

20/50 40%

Nota: Adaptado de Análisis, diseño y desarrollo de un sistema informático para la obtención de indicadores de sostenibilidad: ambientales y sociales para la producción de leche en fincas del cantón Cayambe. Universidad Politécnica Salesiana, Quito, p 21 por Medina, P., & Calvopiña E. (2016).

De acuerdo a las características analizadas en la Tabla 1, se toma la decisión de utilizar el modelo ágil Scrum, ya que se ajusta a los parámetros requeridos para el desarrollo del presente trabajo de titulación, este cumple con el 100% las características seleccionas frente al 70% de XP y 40% del modelo DSM. 3.2.2.4. Modelado. 3.2.2.4.1. Patrón MVC. Según Camarena, Trueba, Martínez y López (2012), afirma que el patrón Modelo Vista Controlador es una arquitectura de diseño que es muy frecuentada al realizar aplicaciones con interfaces gráficas de usuario. La característica principal es la separación de los datos, el modelo y la lógica de negocio. Al realizar esta separación se hace uso del principio del Modelo de Capas, al separar la Vista del Modelo y el Controlador que las relaciona, manteniéndose de este modo la integridad e independencia entre las divisiones o

capas. Son varias las ventajas que trae el emplear este tipo de patrón, como por ejemplo diseñar varias vistas para un mismo modelo, los cambios se replican fácilmente en las interfaces, facilidad de sustitución de interfaces entre otras (p. 240).

Figura 2. Patrón Modelo Vista Controlador Tomado de Automatización de la codificación del patrón modelo vista controlador (MVC) en proyectos orientados a la Web. Ciencias Exactas y Aplicadas, p. 40 por Camarena, J., Trueba, A., Martínez, M., & López, M. (2012).

3.2.2. Base de datos. De acuerdo con el análisis de Sigüenza (2015), la base de datos se puede definir con un conjunto de información relacionada, agrupada o estructurada de acuerdo con los requerimientos que se han obtenido en el Análisis. Los aspectos a tomar en cuenta en las bases de datos son la velocidad que tendrá para acceder a los datos almacenados, el tamaño de los datos y la facilidad de accesos de la información. Para un diseño de la base de datos se utiliza el diagrama Entidad-Relación que está compuesto por entidades, relaciones y atributos. Son dibujos que ayudan al entendimiento relacional (pp. 33-37). 3.2.2.5. Lenguaje SQL. Como asegura Pérez (2015), los lenguajes de consulta estructurada (Structured Query Language) es un lenguaje para la gestión de base de datos ayudando a que los sistemas sean dinámicos permitiendo interactuar con los usuario y fue estipulado por D. D. Chamberli en la última década de los 70 en el cual se lo conocía como SEQUEL (Structured English Query Language) diseñado acoplado con el prototipo de bases de datos relacional System R. de IBM, luego comenzaron a salir varias firmas comerciales para SQL como consecuencia de

esto el Instituto de Normalización Americano ANSI estableció una normativa en la cual los productos acepten a SQL embebido (p. 32). DML: como señala López, Castellano & Ospino (2013) DML (Data Manipulation Languaje) lenguaje de manipulación de datos permite realizar cuatro operaciones en la base de datos como seleccionar utilizando SELECT, INSERT para insertar un registro, UPDATE que actualiza datos y DELETE para borrarlos (p. 16). DDL: el lenguaje de definición de datos (Data Difinition Language) las sentencias dentro de este lenguaje son CREATE, DROP, ALTER y RENAME las cuales hacen las acciones de crear, borrar, alterar y cambiar de nombre a objetos (Reinosa, Maldonado, Muñoz, Damiano y Abrutsky, 2014, p. 106). DCL: el lenguaje de control de datos (Data Control Language) permite al administrador gestionar a los usuarios el acceso a los datos de la base de datos, esto gracias a las sentencias GRANT y REVOKE que son de ayuda para auditoría de la base de datos (López et al., 2013, p. 17). 3.2.2.6. Diagrama entidad relación. Según López (2013), este modelo consiste en representar el problema mediante un diagrama, el cual fue propuesto por Peter P. Chen a mediados de los años 70 con el fin de realizar una representación conceptual de los datos y las relaciones existentes, siendo así una manera sencilla de representar el mundo real agrupados en entidades donde cada una de estas representa la información de personas, cosas, etc. Las entidades se las representa mediante rectángulos con una sola línea si es una entidad fuerte y con doble línea en caso de ser una entidad débil con su nombre dentro y solo pueden estar una vez en todo el diagrama. Y para realizar una correspondencia entre las entidades se usan las relaciones emitidas mediante correspondencia o participación para poder identificar si es una entidad fuerte o débil (pp. 4244). 3.2.2.7. MySOL Workbench. Según Oracle (2016), workbench es una herramienta para el modelado, diseño, desarrollo, generación y administración de base de datos, además incorpora todos los componentes necesarios para realizar los modelos entidad relación y a partir de estos generar

el script mysql, caso contrario, en el que se desee codificar, el software incluye autocompletado, color de resaltado en sintaxis, reutilización de fragmentos SQL e historial de ejecución. 3.2.2.8. Normalización. Desde el punto de vista de Reinosa et al. (2014) la normalización es uno de los parámetros más importantes en el diseño de base de datos y se lo puede definir como el modelado de la base de datos relacional, su estructura relacional válida, como está estructurada los datos por el concepto de atributo, que estos no poseen una estructura interna, eliminación de redundancia de datos, facilita el control de la manipulación de datos y tiene una estructura lógica que sea fácil de mantener y entender (pp. 64-65). 3.2.2.8.1. Primera forma normal. Como indica Piñeiro (2013), en esta primera forma normal hace referencia a que los componentes sean atómicos, en otras palabras, que no tengan grupos repetidos como un atributo o conjunto de atributos con datos múltiples, y para eliminar esta cuestión se puede optar por agregar una nueva entidad relacionada a la afectada (pp. 51-52). 3.2.2.8.2. Segunda forma normal. Según López et al. (2013) define que un diseño se encuentra en la segundo forma normal si cumple con la primera forma y cada uno de los atributos de una entidad corresponde directamente con la principal, esto quiere decir que si tenemos una entidad débil la cual tiene la clave de otra entidad fuerte, esta entidad débil no debe tener los atributos de la entidad fuerte (p. 76). 3.2.2.8.3. Tercera forma normal. Para cumplir con el diseño de la tercera forma normal como afirma Piñeiro (2013) además de cumplir con la segunda forma no debe tener dependencia transitiva, lo que quiere decir es que, si un atributo de la entidad depende de otro atributo que no es la clave primaria, entonces no está cumpliendo con la tercera forma y para solucionarlo se debe crear otra entidad teniendo como clave primaria al atributo de dependencia (p. 54).

3.2.2.8.4. Cuarta forma normal. De acuerdo con Piñeiro (2013) se encarga de los atributos multivaluados, esto significa que ocasionan problemas en el mantenimiento de las relaciones a las cuales representa, por ejemplo, una relación R (X, Y, Z) donde X + Y y X Z se encuentra doble dependencia, para solucionarlo se crean relaciones independientes como R (X, Y) y R (X, Z) (pp. 56-57). 3.2.2.9. Sistemas Gestores de Base de datos. 3.2.2.9.1. MariaDB. MariaDB Foundation (2016), asegura que es un SGBD del tipo no privativa, es decir, que es open-source (software desarrollado y distribuido libremente). MariaDB fue desarrollada por los fundadores originales de MySQL, además, se trata de un reemplazo directo a MySQL (actualmente de Oracle) garantizando permanecer open-source. Al ser un fork directo de MySQL, posee una alta compatibilidad con este último dado que posee las mismas estructuras, interfaces, bibliotecas, etc., lo que facilita poder cambiar de un servidor por otro directamente. Es escalable, robusto, posee grandes mejoras respecto a MySQL y muchas más herramientas que lo hacen muy versátil al usarlo. 3.2.2.9.2. PostgreSQL. De acuerdo con Pérez y Ávila (2014), este sistema es considerado como el más avanzado en el mundo por su gestión de base de datos objeto-relacional, multiusuario, centralizado y de propósito general. Tiene características útiles cuando concibe una herramienta de mapeo de objeto relacional (ORM) para servir como intermediario entre la base de datos y el modelo orientado a objetos. Incluye comportamientos para el manejo de las colecciones de registros en los campos de las tablas o más conocido como Non-First Normal Form (pp. 3-4). 3.2.2.9.3. DB2 Express-C. Según Ibm (2018), DB2 Express-C es la edición gratuita de la base de datos DB2 para Linux, Windows, Solaris, y Mac. Es fácil de usar y proporciona una base sólida para compilar e implementar aplicaciones desarrolladas con C/C++, Java ™, .NET, PHP, Ruby on Rails, Python y otros lenguajes de programación, proporciona capacidades avanzadas de administración y análisis de datos para cargas de trabajo transaccionales y de

almacenamiento. Las características avanzadas como BLU Acceleration, pureScale, un conjunto de herramientas, optimización de almacenamiento, administración de cargas de trabajo, compresión procesable e ingesta continua de datos ayudan a garantizar un alto rendimiento, conocimientos accionables, disponibilidad continua y confiabilidad. 3.2.3. Comparación entre base de datos. La comparación tuvo como objetivo diferenciar las bases de datos MariaDB, PostgreSQL y DB2 Express-C para el desarrollo de software. De acuerdo a la documentación mostrada anteriormente, se utilizaron las siguientes características para determinar la mejor base de datos para el sistema web. Con los siguientes parámetros se comparó los sistemas gestores de base de datos, si estos cumplen: •

El 100% de la característica escogida para el trabajo de titulación: 10 puntos.

•

Al menos el 50% de la característica, es decir, cumple con los parámetros, pero no en su totalidad: 5 puntos.

•

No cumple con la característica: 0 puntos. La comparación se analizó con las siguientes características:

•

Rendimiento: gestiona cargas de trabajo exigentes.

•

Confiabilidad: requerimiento indiscutible y probablemente el más importante para el desarrollo de la misma en tiempo real.

•

Almacenamiento: capacidad de almacenar datos para la distribución uniforme de rendimiento y capacidad.

•

Seguridad: es el proceso de controlar el acceso a los recursos dentro la base de datos.

•

Recuperación de desastres: capacidad de respaldo de información que brinda procedimientos de recuperación de datos.

•

Open Source: describe si la base de datos posee código abierto.

•

Licencia libre: detalla si la base de datos es de uso gratuito.

Tabla 2 Comparación de base de datos. Característica

SGBD MariaDB

Rendimiento Confiabilidad Almacenamiento Seguridad Recuperación de desastres Open Source Licencia libre Total Porcentaje

10 5 5 5 10 10 45/70 64.3%

PostgreSQL 10 10 10 10 5 10 10 65/70 92.8%

DB2 Express-C 10 10 5 10 5 5 10 55/70 78.5%

Fuente: Investigacion de campo.

De acuerdo a las características analizadas en la Tabla 2, se obtuvo el sistema gestor de base de datos PostgreSQL como ganador, ya que cumple de las características con el 92.8% ajustándose a los requerimientos del desarrollo, frente al 64.3% de MariaDB y 78.5% de DB2 Express-C. 3.2.4. Servicios web. Como señala Vega y Umaña (2014), son servicios inteligentes que entrelazan servicios la ejecución y el armado entre varios servicios. Los servicios web son eficientes al momento de trabajar con desarrollos dirigidos por modelos, su grado de compatibilidad es alto con diferentes aplicaciones, manejan el concepto de multiplataforma, su instalación se puede dar en la mayoría de plataformas conocidas en la web (pp. 98-99). 3.2.4.1. Arquitectura de una página web. 3.2.4.1.1. Cliente/Servidor. La arquitectura Cliente/Servidor es el modelo más conocido y empleado al desarrollo de aplicaciones informáticas. Como señala Cusick (2013) actualmente muchos de los sistemas, en especial la mayoría de las aplicaciones web, se desarrollan bajo este tipo de arquitectura cliente/servidor. La característica principal de esta arquitectura es la separación en capas (capa cliente y capa servidor) en donde la capa del cliente realiza peticiones de información o servicios a la capa del servidor y este envía la respuesta al cliente, es más, pueden comunicarse con otros clientes o servidores (p. 139).

Desde el punto de vista de Ferrer (2014), Es una variante del modelo cliente/servidor en el cual se añade una capa intermediaria entre el cliente y el servidor. En otras palabras, la parte del servidor se divide en dos (servidor de aplicaciones y servidor de datos) consiguiendo de este modo compartir la carga de trabajo. En esta arquitectura la capa del cliente se dedica a la presentación de información y envío de peticiones de recursos a la capa siguiente que es la capa del servidor de aplicaciones, en esta capa se procesa la lógica del negocio, es decir sirve de nexo entre la capa de presentación y la capa de datos, esta última normalmente es un servidor de datos que proporciona los datos que el servidor de aplicación solicita (pp. 23-24). 3.2.4.2. Tipos de páginas web. 3.2.4.2.1. Estáticas. Según Zofio (2013), las aplicaciones web estáticas se caracterizan por ser básicamente informativas o de solo lectura, es decir que se limitan a presentar información de forma permanente al usuario final, además no poseen una interacción directa con el usuario final. En este tipo de web estático, las páginas poseen links o enlaces que redirigen al usuario hacia otras páginas web debido a su incapacidad para la interacción entre usuario y página visitada; las webs estáticas poseen un enfoque netamente informativo. Los foros de ayuda en línea son un claro ejemplo de web estática (p. 7). 3.2.4.2.2. Dinámicas. Como afirma Zofio (2013), las Webs dinámicas se caracterizan principalmente por soportar interactividad con el usuario final. Son comúnmente denominadas aplicaciones web por el motivo de la interacción del usuario con los datos que se generan en la página. Debido a que existe una comunicación fluida entre la aplicación y el usuario, la información que se presenta a este último es a partir de peticiones que el usuario realice a la aplicación, de este modo se mantiene actualizada la información mostrada. Empleando la web dinámica se puede gestionar base de datos, enviar formularios, jugar en línea, chatear, etc. (p. 7). 3.2.4.3. Diseño web. Mavlanova, Benbunan, Koufaris, y Lang (2015), afirman que el diseño web es la forma de aplicar estructuras y técnicas que hacen posible que las páginas de una aplicación

web se vinculen y muestren información. Para el diseño, muchos sitios en internet ofrecen plantillas pre-fabricadas, pero en muchos casos, los amantes del diseño prefieren aplicar sus propios estilos, ya sea pagando por un trabajo a la medida o realizándolos ellos mismos. La parte del diseño y contenido hablan por el aplicativo web. Si está bien diseñado, se denotará el profesionalismo, cuidado y dedicación que se dio al diseño, y por ende, dará una sensación más realista al usuario final (p. 22). 3.2.4.3.1. Responsive Web Design. Manso, Cañizares y Febles (2016), aseguran que el Responsive Web Design (RWD) es una metodología de combinación de diseños, plantillas y una exigente forma de uso del script de cascada CSS con el fin de que los dispositivos de los usuarios que interactúen con un sitio en el que se haya elaborado con RWD no pierdan la información que están revisando ya que lo que busca RWD es que todo sitio web se adapte a los diferentes tipos de pantallas que pueden existir. EL uso de esta metodología posibilita el mantenimiento en un futuro, elimina la creación de otro sitio web para móviles, ya que el mismo sitio web se adapta al dispositivo sin perder la confiablidad de la información, y los compones se moverán en el sitio para la interacción con los usuarios (pp. 103-104). 3.2.4.4. Frameworks de diseño. 3.2.4.4.1. Materialize. Materialize (2016), señala que es un framework de diseño web basado en el modelo Material Design de Google. Materialize ofrece componentes HTML, CSS, JS que brindan un diseño moderno y adaptativo al front-end de los sitios web. Facilita una amplia documentación y ejemplos de código para quienes estén iniciandose con el framework. Con la aplicación de los principios de Material Design se consigue desarrollar aplicaciones universales y mejorar la experiencia de usuario. De igual forma se presenta elementos mejor diseñados y más agradables basándose en una perspectiva Material (espacio-movimiento) del mundo. 3.2.4.4.2. Bootstrap. Bootstrap (2016), señala que es el más popular para el diseño y construcción de aplicaciones web. Contiene una serie de herramientas como HTML, CSS Y Javascript que

facilita el desarrollo adaptativo y móvil. Está disponible en su página oficial para su descarga gratuita. Posee un amplio soporte y documentación por parte del equipo desarrollador, además agiliza el diseño front-end de la aplicación, está diseñado para soportar varios dispositivos, reduce la carga de trabajo y posee varias características, funcionalidades y componentes personalizables. 3.2.3. Herramienta de desarrollo web. 3.2.4.5. Editor de código SublimeText 3. SublimeText (2016), afirma que es un editor de texto y de código fuente que se destaca por su solidez, elegancia, flexibilidad y alto rendimiento a la hora de su ejecución. Está disponible en su página oficial para su descarga y evaluación de forma gratuita, además ofrece una versión de pago para su uso continuo, aunque la versión de prueba no posee una fecha límite de vencimiento y funciona completamente Algunas de las características principales son su amplia documentación y soporte por parte de su equipo de desarrollo, modo libre de distracciones, carga de plugins, fácil organización e intercambio entre proyectos, restauración y guardado instantáneo de los cambios, soporte multiplataforma entre otros. 3.2.4. Lenguajes de programación web. 3.2.4.6. Front-End. 3.2.4.6.1. HTML5 y CSS. Gauchat (2013), señala que HyperText Markup Language, es un lenguaje de programación diferente a los comunes, dado que no emplea instrucciones sino un conjunto de etiquetas que organiza el documento final, lo cual deriva en la flexibilidad al interactuar con la Web. HTML5 (evolución del HTML) proporciona estructura, estilo y funcionalidad, lo cual se ve reflejado en el navegador en donde se ejecuta (p. 25). Se debe incluir un diseño que sea amigable con el usuario final porque es quien lo utilizara dependiendo de su presentación el usuario permanecerá en la aplicación, Es así como menciona Gauchat (2013) que se debe combinar estos dos aspectos, el diseño (funcionalidad) y la estructura (organización), de este modo HTML se fusiona con CSS, combinando la estructura que la pone HTML y los estilos o presentación que los coloca CSS.

Las hojas de estilo o CSS ayudan a enriquecer el aspecto visual de una aplicación web eligiendo entre una multitud de opciones de presentación como colores, tipos y tamaños de letra, etc. (p. 57). 3.2.4.6.2. JavaScript. Sprimont, Ricci y Nicastro (2014) aseguran que el desarrollo web de un sitio o aplicación es necesario hacer uso de lenguajes de programación orientado a la web. Uno de los leguajes es JavaScript el cual es orientado a objetos, permite realizar funciones. JavaScript mejora la apariencia y funcionalidad de una aplicación web, permite mostrar mensajes de alerta hacia el usuario, además otra de las funcionales es que puede extender librerías de C++ (p. 77). 3.2.4.7. Back-End. 3.2.4.7.1. PHP. Ali y Agarwal (2016) señalan que Hypertext Preprocessor, es un lenguaje de programación open-source frecuentemente utilizado para desarrollar aplicaciones enfocadas a la web. PHP es un lenguaje muy flexible del lado del servidor dado que provee un entorno de desarrollo capaz de manejar gran cantidad de transacciones y procesamiento de documentos en línea de forma rápida. Otra característica importante es que brinda soporte para el paradigma orientado a objetos (p. 593). 3.2.4.7.2. Python. Guzdial, Vidal, y Ericson (2013) afirman que Python es un lenguaje bastante popular que se utiliza con mucha frecuencia para la programación web y multimedia. Es un lenguaje muy sencillo de aprender, fácil de leer y muy flexible, pero no muy eficiente, también es un buen lenguaje para escribir programas que funcionen dentro de una aplicación, como el lenguaje de manipulación de imágenes GIMP, o la herramienta de creación de contenido 3D llamada Blender (p. 103). 3.2.4.7.3. Java. Según Oracle (2018), Java es un lenguaje de programación, es muy rápido, seguro y fiable, desde portátiles hasta centros de datos, desde consolas para juegos hasta súper

computadoras, desde teléfonos móviles hasta Internet, Java está en todas partes. Java Runtime Environment (JRE) es lo que se obtiene al descargar el software de Java. JRE está formado por Java Virtual Machine (JVM), clases del núcleo de la plataforma Java y bibliotecas de la plataforma Java de soporte. JRE es la parte de tiempo de ejecución del software de Java, que es todo lo que necesita para ejecutarlo en el explorador web. Según Sznajdleder (2013), manifiesta que uno de los lenguajes de programación que tiene mayor importancia sobre los demás es Java, por lo que es dominante en la creación de aplicaciones empresariales, elaboración de videojuegos, sitios Web. Java es multiplataforma, lo que significa que las aplicaciones programadas con este lenguaje pueden correr en cualquier sistema operativo y hardware. Esto lo posiciona como el lenguaje de programación más versátil de al menos los últimos 15 años (p.54). 3.2.5. Comparación de lenguajes de desarrollo web. La comparación tuvo como objetivo diferenciar los lenguajes de desarrollo web. De acuerdo a la documentación mostrada anteriormente, se utilizaron las siguientes características para determinar el mejor lenguaje de desarrollo web. Con los siguientes parámetros se comparó los lenguajes de desarrollo, si estos cumplen: •

El 100% de la característica escogida para el trabajo de titulación: 10 puntos.

•

Al menos el 50% de la característica, es decir, cumple con los parámetros, pero no en su totalidad: 5 puntos.

•

No cumple con la característica: 0 puntos. La comparación se analizó con las siguientes características:

•

Madurez: modelo de evaluación de los procesos relativos al desarrollo e implementación de software

•

Tamaño y grado de actividad de la comunidad: describe si la comunidad de programadores es grande para resolver problemas comunes que se pueden presentar en el desarrollo.

•

Disponibilidad de aplicaciones y librerías de terceros: describe las herramientas base para construir el sistema.

•

Curva de aprendizaje: describe el grado de éxito obtenido durante el aprendizaje del lenguaje de desarrollo web en el transcurso del tiempo.

•

Escalabilidad: describe si el lenguaje de desarrollo puede adaptarse sin perder calidad.

Tabla 3 Comparación de lenguajes de desarrollo web. Característica Grado de madurez. Tamaño y grado de actividad de la comunidad. Disponibilidad de librerías y aplicaciones de terceros. Curva de aprendizaje. Escalabilidad. Total Porcentaje

Lenguajes de desarrollo web PHP Pyton Java 10 10 10 10 5 45/50 90%

10 5 5 5 10 35/50 70%

10 10 5 5 5 35/70 70%

Fuente: Adaptado de Cómo seleccionar una plataforma de desarrollo para un proyecto web por Montoro, S. (2013). Recuperado el 10 de mayo de 2018. Obtenido de: https://lapastillaroja.net/2013/10/como-seleccionar-plataforma-tecnologica

De acuerdo a las características analizadas en la Tabla 3, el lenguaje que cumple con las características en un 90% es PHP, el cual es seleccionado para el desarrollo del sistema web, frente al 70% de Python y Java.

4. METODOLOGÍA DE LA INVESTIGACIÓN 4.1. Enfoque/Diseño/Tipo de investigación 4.1.1. Enfoque de investigación. El proyecto de investigación tiene un enfoque mixto. Cuantitativo para el análisis de los resultados matemáticos obtenidos de las encuestas sobre la factibilidad de desarrollo del sistema web y cualitativo para el estudio de los resultados atreves de una entrevista donde se obtuvieron los procesos de gestión de los semáforos. 4.1.2. Diseño de investigación. 4.1.2.1. Diseño no experimental. En este tipo de investigación no hay condiciones, ni estímulos a los cuales se expongan los sujetos del estudio, los sujetos son observados en su ambiente natural, se basa en la búsqueda empírica y sistemática en la que el científico no posee control directo de las variables independientes, debido a que sus manifestaciones ya han ocurrido o que son inherentemente no manipulables, además se hacen inferencias sobre las relaciones entre las variables, sin intervención directa sobre la variación simultánea de las variables independiente y dependiente (Hernández, Fernández, & Baptista, 2014, pág. 163)

Con este diseño se observaron y analizaron los procesos que se llevaban en la gestión de los semáforos en el departamento de tránsito, donde se obtuvo un registro de los requerimientos específicos para el desarrollo del sistema de gestión de semáforos. 4.1.3. Tipo de investigación. 4.1.3.1. Investigación Exploratoria. Pretende dar una visión general, aproximada, respecto a una determinada realidad. Se realiza fundamentalmente cuando el tema elegido ha sido poco explorado y reconocido, y cuando más aún, sobre él, es difícil formular hipótesis precisas o de cierta generalidad. Suele surgir también cuando aparece un nuevo fenómeno que por su novedad no admite una descripción sistemática o cuando los recursos del investigador resultan insuficientes para emprender un trabajo más profundo. (Hernández, Fernández, & Baptista, 2014, pág. 91)

Esta investigación se utilizó al principio del proyecto en la reunión con el Product Owner, donde se levantó información sobre sus procesos con sus respectivas tareas y actividades.

4.1.3.2. Investigación Descriptiva. Tiene como función la capacidad para seleccionar características, rasgos, propiedades importantes del objeto de estudio y la descripción detallada de sus partes, para ser sometido a análisis, es considerado el más popular dentro del campo de la investigación, permite utilizar técnicas como: encuesta, entrevista, observación. (Bernal, 2010, p. 113)

Esta investigación permitió obtener características importantes de la problemática planteada para la recolección, comprobación y estudio de los datos de la gestión de semáforos.

4.2. Población / Muestra 4.2.1. Población. La población es el grupo de individuos, objetos o medidas que comparten una característica que es objeto de estudio en un área geográfica delimitada, en un momento determinado, de la cual se desea explotar resultados de manera estadística para aportar a nuestra investigación con los resultados obtenidos. (Borda, 2013, p. 147) La población en la EPMT-SD consiste de un gerente general y cinco personas

asignadas para las actividades de gestión de semáforos. 4.2.2. Muestra. La muestra es un subconjunto de la población o universo en el cual vamos a realizar el estudio mediante la recolección de datos que se tienen que especificar con anterioridad. La idea de realizar este proceso de encontrar la muestra es para que el resultado reportado en la muestra se pueda generalizar a la población o universo haciendo que sea estadísticamente representativa. (Hernández, Fernández, & Baptista, 2014, p. 173)

Como señala Posso, (2009) cuando una población no sobrepasa de 30 a 40 individuos no se debería determinar la muestra. Para el presente proyecto como muestra se utilizó a toda la población del departamento de tránsito encargados de la gestión de los semáforos.

4.3. Técnicas e instrumentos de recogida de datos 4.3.1. Técnicas de recogida de datos. A continuación, se muestran las técnicas utilizadas para la obtención de datos concretos y necesarios.

4.3.1.1. Entrevista. Con esta técnica se tiene contacto directo con las personas que consideremos fuente de información, permite obtener información verbal de parte de las personas encargadas del proceso, la realiza un entrevistador con el ánimo de obtener datos o requerimientos que aporten a desarrollar una perspectiva más clara de las actividades de los sujetos de investigación, se realiza un cuestionario de preguntas abiertas, para ir anotando las respuestas a las preguntas planteadas. (Borda, 2013, pág. 62)

Se entrevistó al analista de tránsito Ing. Edison Barahona, principal encargado de la gestión de semáforos, de quién se obtuvo la información de los procesos que se automatizaron en el sistema web. 4.3.1.2. Encuesta. Es la técnica de recolección de datos más usada en el campo de la investigación, a pesar que actualmente le restan credibilidad por el sesgo de las personas encuestadas, permite obtener y elaborar datos de modo rápido y eficaz, mediante un cuestionario o grupo de preguntas previamente diseñado. (Bernal, 2010, pág. 194)

La encuesta realizada al personal del departamento de tránsito, permitió obtener la información sobre la factibilidad del proyecto mediante la elaboración de un banco de preguntas. 4.3.1.3. Observación. Es una técnica de recoger información en la cual los investigadores conviven durante un tiempo con los sujetos de investigación, compone un registro visual de los procesos que suceden, la idea de hacer esto es reconstruir la dinámica de los procesos observados, además es un complemento porqué con este podemos añadir detalles que nos contemplaron en los demás instrumentos de recogida de datos. (Borda, 2013, pág. 62)

Para comprender la problemática se procedió a visitar las instalaciones de la EPMTSD y se analizó cuidadosamente cada uno de los procesos que se realizaban en el área de gestión de semáforos, se pudo constatar que todo el procedimiento se lo realizaba de manera manual.

4.4. Técnicas de Análisis de Datos El análisis de datos consiste en una serie de procesos que permiten tabular e interpretar la información obtenida por medio de diferentes técnicas e instrumentos de recogida de datos, con el fin de realizar un estudio preliminar de los problemas planteados y formular resultados (Bernal, 2010).

Una vez obtenidos los datos se procedió a realizar el análisis y estudio de los mismos, para ello se utilizaron técnicas de estadística básica como tabulaciones e interpretación de datos y la elaboración de gráficos a través de Excel.

5. RESULTADOS 5.1. Análisis situacional de la población para el uso del sistema 5.1.1. Entrevista realizada al gerente de la empresa. Mediante la entrevista que se realizó al gerente de la EPMT-SD encargado de semaforización se pudo recolectar la información necesaria; para entender los procesos que se llevan a cabo en el área de semáforos, se realizaron las siguientes preguntas que se muestran a continuación. •

¿Qué procesos que se deben automatizar dentro del departamento de semáforos? En la entrevista se recabó información en donde se determinó los siguientes

procesos para automatizar: o Ingreso de usuarios con sus respectivos roles o Tabla de usuarios o Tabla de roles o Ingreso de direcciones o Tabla de direcciones o Tabla de tipos de artículos o Ingreso de artículos o Tabla de artículos o Ingreso de artículos activos o Tabla de artículos activos o Orden de mantenimientos o Generar alertas o Generar reportes •

¿Cómo se maneja los procesos actualmente que se deben automatizar dentro del departamento de semáforos? La gestión de los semáforos se realiza de forma manual, es decir, sus datos se

llenan en una hoja de cálculo Excel y en Word los documentos que requieren informes más detallados para su registro.

•

¿Cuantas personas son encargadas de llevar a cabo estos procesos? En el departamento de semaforización se designan 5 personas dependiendo si el

trabajo de campo no es grande caso contrario se envían más personal. •

¿Qué control se tiene en el cumplimiento de todos los procesos designados? Los empleados encargados de estos procesos se manejan de acuerdo a las ordenes

generadas por el gerente, además de esto no se posee ningún control que garantice el cumplimiento de todos los procesos. •

¿Considera que hay un buen control de mantenimiento para los semáforos que están a cargo la empresa? Si, el control se lo realiza eficientemente, pero la información que se genera cada

día no se encuentra albergada en un solo sistema. •

¿Cree usted que la metodología actual que lleva la empresa para el control de mantenimiento de los semáforos es adecuada? No, ya que existen falencias al registrar todo el inventario de nuestra área.

•

¿Considera usted que se debe automatizar la gestión de los semáforos activos y pasivos que tiene la empresa? Si, se podría ser más eficaz con toda la información que se maneja en la empresa.

•

¿Cuántos responsables existen actualmente manejando esta información? o Gerente de semaforización o Encargado de Bodega o Empleados del departamento o Secretaria

•

¿Cómo gerente del departamento de semáforos estaría dispuesto a brindar la información necesaria para el desarrollo del nuevo sistema que se va a implementar? En la realización de la pregunta, el gerente mostró una respuesta segura y

afirmativa, la cual permitirá la realización de este proyecto.

•

¿Considera importante la implementación de un sistema web para la gestión de semáforos de la empresa? Es muy importante contar con un sistema que nos permita controlar la gestión de

los semáforos como tal. 5.1.1.1. Discusión de la entrevista. Con la entrevista realizada al analista de tránsito Ing. Edison Barahona, se obtuvo de manera más específica lo procesos, actividades y tareas que realiza el departamento en la gestión de los semáforos como se muestra en la Figura 3.

Figura 3. Diagrama de procesos, actividades y tareas de la gestión de semáforos. Adaptado de investigación de campo.

Con la información recolectada se procedió a realizar los requerimientos del sistema que se muestra en el Anexo 1. 5.1.2. Encuesta realizada en la EPMT-SD. En la visita de campo que se llevó a cabo en la EPMT-SD, se procedió a realizar una encuesta a las personas que estarían directamente relacionadas con el software para

determinar si están de acuerdo con su gerente en la implementación de un sistema web que automatice los procesos de la gestión semafórica del departamento de tránsito. Con la encuesta que se muestra en el Anexo 2, realizada al gerente, secretaria y empleados del departamento de tránsito de la EPMT-SD, se logró recolectar la siguiente información: Pregunta 1. ¿Considera que hay un buen control de mantenimiento en los semáforos que están a cargo la empresa? Tabla 4 Resultados obtenidos de la pregunta 1 de las encuestas. ALTERNATIVA FRECUENCIA SI 2 NO 3 TOTAL 5

PORCENTAJE 40% 60% 100%

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

PREGUNTA 1 60% 60%

40%

50% 40% 30% 20% 10% 0%

Figura 4. Figura obtenida de la pregunta 1 de las encuestas. Adaptado a la investigación de campo

Análisis: En la pregunta los resultados obtenidos, se observa que el 60% de las personas encuestadas consideran que el control de los mantenimientos no funciona correctamente y el 40% señalan que hay un buen control.

Pregunta 2. ¿Cómo llevan el control de mantenimiento de los semáforos en la empresa? Tabla 5 Resultados obtenidos de la pregunta 2 de las encuestas. ALTERNATIVA FRECUENCIA Manual 4 Sistematizada 1 Otros métodos Ninguno TOTAL 5

PORCENTAJE 80% 20%

100%

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

PREGUNTA 2 80% 80% 70% 60% 50% 40%

20%

30% 20%

10% 0%

Manual

Sistematizado

Otros Metodos

0% Ninguno

Figura 5. Figura obtenida de la pregunta 2 de las encuestas. Adaptado a la investigación de campo

Análisis: En la pregunta los resultados obtenidos, se observa que el 80% de las personas encuestadas consideran que la manera de controlar los mantenimientos se realiza de manera manual y el 20% piensan que se lleva dentro de algún sistema que como puede ser Excel o en Word que asegura la trazabilidad de la información. Pregunta 3. ¿Cree usted que el procedimiento actual que lleva la empresa para el control de mantenimiento de semáforos es adecuado? Tabla 6 Resultados obtenidos de la pregunta 3 de las encuestas. ALTERNATIVA FRECUENCIA SI 3 N0 2 TOTAL 5 Nota: Datos Obtenidos de la investigación de campo.

PORCENTAJE 60% 40% 100%

PREGUNTA 3 60% 60%

40%

50% 40% 30% 20% 10% 0%

Figura 6. Figura obtenida de la pregunta 3 de las encuestas. Adaptado a la investigación de campo.

Análisis: En la pregunta los resultados obtenidos, se observa que el 60% de las personas encuestadas consideran que el procedimiento es el adecuado ya que cada día hay trabajo para los empleados que deben cumplir y el 40% piensan que lo contrario. Pregunta 4. ¿Cómo considera usted la implementación de un sistema para el control de mantenimiento de semáforos para la empresa? Tabla 7 Resultados obtenidos de la pregunta 4 de las encuestas. ALTERNATIVA FRECUENCIA No es importante Poco Importante Importante 3 Muy Importante 2 TOTAL 5 Nota: Datos Obtenidos de la investigación de campo.

PORCENTAJE

60% 40% 100%

PREGUNTA 4 60% 60% 50%

40%

40% 30% 20% 10% 0%

0% No es importante

0% Poco Importante

Importante

Muy Importante

Figura 7. Figura obtenida de la pregunta 4 de las encuestas. Adaptado a la investigación de campo.

Análisis: En la pregunta los resultados obtenidos, se observa que el 60% de las personas encuestadas consideran que es importante y el 40% muy importante la implantación que permita controlar los mantenimientos de los semáforos. Esta pregunta es de mucha importancia ya que se observó que el personal encuestado necesita un sistema para automatizar este proceso. Pregunta 5. ¿Considera que implementación de un sistema web para la gestión de semáforos de la empresa es adecuado? Tabla 8 Resultados obtenidos de la pregunta 5 de las encuestas. ALTERNATIVA FRECUENCIA SI 5 NO 0 TOTAL 5 Nota: Datos Obtenidos de la investigación de campo.

PORCENTAJE 100% 0% 100%

PREGUNTA 5 100% 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%

0% SI

Figura 8. Figura obtenida de la pregunta 5 de las encuestas. Adaptado a la investigación de campo.

Análisis: En la pregunta los resultados obtenidos, se observa que el 100% de las personas encuestadas consideran de vital importancia un nuevo sistema que maneje la gestión de los semáforos. Pregunta 6. ¿Considera usted que este sistema mejoraría el control de mantenimiento en los semáforos activos que tiene la empresa? Tabla 9 Resultados obtenidos de la pregunta 6 de las encuestas. ALTERNATIVA FRECUENCIA SI 4 NO 1 TOTAL 5 Nota: Datos Obtenidos de la investigación de campo.

PORCENTAJE 80% 20% 100%

PREGUNTA 6 80% 80% 70% 60% 50% 40%

20%

30% 20% 10% 0%

Figura 9. Figura obtenida de la pregunta 6 de las encuestas. Adaptado a la investigación de campo.

Análisis: En la pregunta los resultados obtenidos, se observa que el 80% de las personas encuestadas consideran que si, ya que los controles se realizarían más adecuadamente garantizando la trazabilidad de todos los puntos que requieran un mantenimiento y el 20% dice que no mejoraría. Pregunta 7. ¿Ha tenido inconveniente con los mantenimientos de los semáforos activos en la empresa? Tabla 10 Resultados obtenidos de la pregunta 7 de las encuestas. ALTERNATIVA FRECUENCIA Si 4 No 1 TOTAL 5 Nota: Datos Obtenidos de la investigación de campo.

PORCENTAJE 80% 20% 100%

PREGUNTA 7 80% 80% 70% 60% 50% 40%

20%

30% 20% 10% 0%

Figura 10. Figura obtenida de la pregunta 7 de las encuestas. Adaptado a la investigación de campo.

Análisis: En la pregunta los resultados obtenidos, se observa que el 80% de las personas encuestadas consideran que si ha tenido algún tipo de problema a la hora de brindar el mantenimiento respectivo de los semáforos y el 20% dice que no ha tenido ningún inconveniente. Pregunta 8. ¿Cree usted que el sistema web para la gestión de semáforos les

ahorraría tiempo y gasto económico a la empresa? Tabla 11 Resultados obtenidos de la pregunta 8 de las encuestas. ALTERNATIVA FRECUENCIA SI 5 NO TOTAL 5 Nota: Datos Obtenidos de la investigación de campo.

PORCENTAJE 100% 100%

PREGUNTA 8 100% 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%

0% SI

Figura 11. Figura obtenida de la pregunta 8 de las encuestas. Adaptado a la investigación de campo

Análisis: En la pregunta los resultados obtenidos, se observa que el 100% de las personas encuestadas consideran que ahorrarían mucho tiempo con toda la gestión que requiere al momento de realizar los mantenimientos y que en su efecto también el gasto que implicaría el no realizar este procedimiento, se beneficiaría, debido a que ya se tiene un mejor control sobre todos los puntos semafóricos.

5.2. Propuesta de intervención El desarrollo del sistema se lo realizó con el marco de trabajo Scrum y para la programación del mismo se utilizó el lenguaje de desarrollo web PHP. En base a la Tabla 2 se determinó que el sistema gestor de base de datos PostgreSQL es el mejor para aplicar al proyecto de Gestión de semáforos ya que reúne las características que se adaptan a los requerimientos de desarrollo. De acuerdo a las reuniones con gerente de Informática y redes, informó que la empresa maneja la información con el sistema gestor MariaDB, por lo que se procedió a la selección de esta base de datos para el desarrollo del sistema.

5.2.1. Fase de desarrollo del sistema utilizando el marco de trabajo Scrum. Para dar inicio con el proceso de desarrollo utilizando el marco de trabajo Scrum, se debe tener en cuenta que el siguiente marco trabajo es incremental- iterativo, en el manifiesto ágil se hace énfasis que posee cuatro valores que, si se requiere se puede disponer cambios, el cual se favorece el agrado del cliente basándose en la adaptación y transparencia del proyecto. 5.2.1.1. Release Planning. En la reunión con el Product Owner, los roles se definen para cada usuario que va a estar involucrado en el desarrollo del sistema, dejando aclarado este punto, si hay alguna falla o se ve en la necesidad de realizar una mejora en el Sprint se buscará la mejor solución en la siguiente iteración, ya que una vez iniciado el desarrollo del producto no se podrá modificar el tiempo. 5.2.1.2. Roles. En la primera reunión aplicando el marco de trabajo SCRUM, se definieron en base al desarrollo del producto los roles de cada involucrado. Tabla 12 Roles Scrum Product Owner Scrum Master Development Team

ROLES DEL EQUIPO SCRUM Ing. Edison Barahona Sr. Franklin Pérez Sr. Edison Calle

Nota: En la designación de los roles de la EPMT-SD, el gerente Ing. Edison Barahona responsable el departamento de semáforos, se asignó como el responsable del negocio. Adaptado de Investigación de campo.

El Product Owner es el designado por la empresa, encargado de la toma de decisiones, y que tiene una visión clara sobre las necesidades del desarrollo. Una vez definido los roles que constituyen una gran responsabilidad en el desarrollo del producto, se da inicio con los siguientes eventos, que describen a continuación: 5.2.1.3. Eventos de Scrum. El producto de vinculación está dividido en 3 sprint los mismos que fueron acordados en las reuniones con el Product Owner, el Scrum Master y el equipo de desarrollo. Para desarrollar este evento Scrum, se utilizó una estimación de tiempo de cuatro semanas

para cada Sprint, trabajando los cinco días laborables; una vez definido el sprint, este no podrá ser modificado. Al final de cada Sprint se entrega una parte funcional al Product Owner y se realiza la retrospectiva, la misma que se tomará en cuenta en el siguiente Sprint de ser el caso. Dentro de las historias de usuario se aplicó en base a la complejidad de desarrollo, la estimación más adecuada que se ajusta al tiempo de cada Sprint Backlog. La métrica utilizada en este proceso fue “Puntos de historia” y se utilizó la técnica de la serie Fibonacci “0, 1, 1, 2, 3, 5, 8, 13, 21, …”, como se detalla en la siguiente tabla la cual consta de la siguiente escala de complejidad. Tabla 13 Escala de complejidad. Escala

Complejidad de Desarrollo

De 1 a 9 De 10 a 13 De 21 en adelante

Bajo Medio Alto

Nota: Escalad de complejidad. Adaptado de Investigación de campo.

En la tabla de product backlog se describe para la primera columna el número de Sprint, la segunda columna el nombre de la Historia de Usuario, en la tercera columna la Estimación, en la cuarta columna se encuentran las Tareas de Ingeniería, la quinta columna se muestra la Estimación de tarea que significa los puntos de desarrollo que requiere el producto y finalmente la última columna del Estado de realización de las tareas, ejemplo, ver Tabla 14. En la tabla del Sprint backlog que se mostraran a continuación tenemos en la primera columna el número de sprint, en la segunda columna el nombre de la historia, en la tercera la estimación de la historia, en la cuarta columna se encontrará la categoría, en la quinta se mostrará la tarea de ingeniería que poseen cada historia, en la sexta columna se encuentra la estimación de tarea que significa los puntos de desarrollo de cada tarea y por último está el estado en que se encuentra la tarea. Estas son las partes que conformaran las tablas de cada sprint y como ejemplo, ver la Tabla 15. Para el desarrollo de la tabla del Burndown Chart, que se muestra después de la tabla del Sprint Backlog, se tiene en la primera columna el número y la estimación del Sprint, en la siguiente columna las tareas de ingeniera, en la tercera columna se encuentra los puntos de las tareas de ingeniera, y las siguientes veinte columnas corresponden los días de desarrollo en el cual se realizarán los avances del producto; en estas columnas se escriben

cada día los avances de los puntos de estimación, como ejemplo, ver en la Tabla 16. Después se muestra la gráfica Burndown Chart, como ejemplo, ver Figura 12 donde se observara una línea de color verde recta, que estará inclinada la cual representa el tiempo definido previamente con el Product Owner de cuatro semanas que tomará el desarrollo; y de color rojo mostrará la línea de progreso del Sprint, que nos dará una mejor perspectiva del avance del proyecto, observando si esta sobrepasa la línea de estimación, nos indicará que el producto se está tardando y si está por debajo de la misma, índica que se culminado antes de lo estimado. Para el siguiente evento Scrum que es la reunión retrospectiva que se muestra como ejemplo en el Anexo 4, se describe como una herramienta del marco de trabajo Scrum, que pertenece a la familia de marcos de trabajo de desarrollo ágil, se realiza en cada iteración (denominado Sprint en Scrum), justo después de la reunión de revisión de la iteración (Sprint Review Meeting) con el dueño del Producto (Product Owner). En esta reunión deben revisarse tres aspectos, lo que salió bien durante la iteración (aciertos), lo que no salió tan bien (errores) y las mejoras que pudieran hacerse en la próxima iteración para evitar errores y mantener aciertos. Como parte final de los eventos Scrum se muestra la tala de prueba de aceptación que se realizaron una por una de las historias, en ella se muestran toda la información con respecto a la funcionalidad del producto, como ejemplo, ver Tabla 17. Finalizando con la descripción de los eventos Scrum, el desarrollo del producto se realizará en base al formato descrito anteriormente para cada uno de los 3 Sprint que se definió con el Product Owner.

5.2.1.3.1. Product Backlog. Tabla 14 Product Backlog. Nº Historia

Sprint Asignado

Historia

Estimación

Prioridad

Ingreso al Sistema

Ingresar usuario

Ingreso de nueva persona

100

roles

Product Backlog Riesgo de Escenario de Prueba desarrollo DADO el ingreso del usuario y la contraseña sean correctos, CUANDO pulse el botón de ingresar ENTONCES abrirá la ventana gestión semafórica. DADO el ingreso del usuario sean incompletos o incorrectos, Medio CUANDO pulso el botón ingresar ENTONCES se muestra mensaje de error. DADO el ingreso del usuario CUANDO pulso la opción de iniciar sesión ENTONCES el sistema permitirá guardar el nombre de usuario. DADO el ingreso completo del rol CUANDO pulse el botón de guardar ENTONCES se visualizará en la lista de roles de usuario. Medio DADO el ingreso del rol duplicado CUANDO pulso el botón guardar ENTONCES no se guardarán los datos y se muestra mensaje de error. DADO el menú principal en formulario Persona CUANDO haga clic en Lista personas ENTONCES muestra ventana Personas de la EPMT-SD DADO el menú principal en formulario Persona CUANDO haga clic en Agregar usuario ENTONCES muestra la ventana de ingresar datos del usuario. DADO los datos de persona CUANDO pulse el botón de estado activo ENTONCES aparecerá en la lista para crear orden de mantenimiento Bajo DADO los datos de persona CUANDO pulse el botón de estado inactivo ENTONCES no aparecerá en la lista para crear orden de mantenimiento DADO el ingreso de persona con correo duplicado CUANDO pulso el botón aceptar ENTONCES mostrara mensaje de correo ya en uso. DADO el ingreso del usuario con datos vacíos o incompletos CUANDO pulso la opción guardar ENTONCES no se guardaran los datos y se muestra mensaje de error.

Estado

Realizado

51 Tabla 14 (Cont.)

Nº Historia

Sprint Asignado

Historia

Estimación

Prioridad

Modificación de datos

Estado de usuario

Ingreso de nuevo usuario

100

Ingresar avenidas

Ingresar nueva dirección

Product Backlog Riesgo de Escenario de Prueba desarrollo DADO los datos del formulario CUANDO pulse el icono de eliminar ENTONCES aparecerá el mensaje de confirmación. Bajo DADO los datos del formulario CUANDO pulse el icono de editar ENTONCES se redirigirá a la ventada de editar datos. DADO los datos del usuario CUANDO pulse el botón de estado activo ENTONCES el usuario tiene acceso al sistema. Bajo DADO los datos del usuario CUANDO pulse el botón de estado inactivo ENTONCES el usuario no tiene acceso al sistema. DADO el menú principal en formulario Usuario CUANDO haga clic en Lista usuarios ENTONCES muestra ventana Usuarios del sistema DADO el menú principal en formulario Usuario CUANDO haga clic en Agregar usuario ENTONCES muestra la ventana de ingresar Alto datos del usuario. DADO el ingreso de usuario con correo duplicado CUANDO pulso el botón guardar ENTONCES no se guardarán los datos y se muestra mensaje de error. DADO el ingreso completo de avenida CUANDO pulse el botón de guardar ENTONCES se visualizará en la lista de avenidas. DADO el ingreso de avenida duplicado CUANDO pulso el botón guardar ENTONCES no se guardarán los datos y se muestra mensaje Bajo de error. DADO el ingreso de avenida con datos vacíos CUANDO pulso la opción guardar ENTONCES no se guardaran los datos de la avenida y se muestra mensaje de error. DADO el ingreso avenida principal y secundaria CUANDO pulse el botón de guardar ENTONCES se visualizará la dirección. DADO el ingreso avenida principal y secundaria sea duplicado CUANDO pulso el botón guardar ENTONCES no se guardarán la Medio dirección y se muestra mensaje de error. DADO el ingreso avenida principal o secundaria estén vacíos o incompletos CUANDO pulso la opción guardar ENTONCES no se guardara la dirección y se muestra mensaje de error.

Estado

Realizado

52 Tabla 14 (Cont.)

Nº Historia

Sprint Asignado

Estimación

Prioridad

Modificar direcciones

Registro de tipo artículos

Registro de nuevo artículo

Historia

Cantidad de artículos en inventario

Product Backlog Riesgo de Escenario de Prueba desarrollo DADO el menú de direcciones CUANDO haga clic en mostrar todo ENTONCES se visualizará la lista de todas las direcciones registradas. DADO la dirección seleccionada CUANDO pulso el botón ver ENTONCES muestra la información de la dirección. Medio DADO la dirección seleccionada CUANDO pulso el botón editar ENTONCES habilita los casilleros de avenidas para modificar la dirección. DADO el ingreso avenida principal y secundaria CUANDO pulse el botón de guardar ENTONCES se visualizará la dirección. DADO el menú de Tipo de artículo CUANDO pulso la pestaña de Lista tipo de artículo ENTONCES abrirá la ventana Tipo de artículos DADO el menú de Tipo de artículo CUANDO pulso la pestaña Agregar tipo de artículo ENTONCES se visualizará en la ventana Bajo Ingresar de tipo de artículo. DADO el ingreso de los datos de Tipo de artículo CUANDO pulso aceptar ENTONCES se visualizará en la ventana de Tipo de artículo DADO el menú de Artículo CUANDO pulso el pestaña de Lista artículo ENTONCES abrirá la ventana lista de Artículos DADO el menú de Artículo CUANDO pulso la pestaña Agregar Medio artículo ENTONCES se visualizará en la ventana Ingresar artículo. DADO el ingreso de los datos del artículo CUANDO pulso aceptar ENTONCES se visualizará en la ventana Artículo. DADO el menú de Artículo activos CUANDO pulse la pestaña de Lista artículo activos ENTONCES desplegara la ventana con la cantidad en inventario. DADO el menú Activar artículo CUANDO pulse la pestaña Lista artículos activos ENTONCES mostrara ventana de artículos activos Medio DADO el menú Activar artículo CUANDO pulso la pestaña Activar artículo ENTONCES mostrara ventana Seleccionar artículo para activar. DADO el ingreso a Activar artículo CUANDO pulso el número de código ENTONCES se visualizará la ventana para llenar campos.

Estado

Realizado

Realizado Realizado Realizado Realizado

53 Tabla 14 (Cont.)

Nº Historia

Sprint Asignado

Historia

Ingreso de vehículos

Estimación

Prioridad

Órdenes de manteniendo

100

Ver estado de orden de manteniendo

Reportes de órdenes de mantenimiento

Nota: Product Backlog ultima versión. Adaptado de Investigación de campo.

Product Backlog Riesgo de Escenario de Prueba desarrollo DADO el menú de Vehículo CUANDO pulse la pestaña de Lista vehículo ENTONCES mostrara la ventana de Vehículos de la EPMT-SD. DADO el menú de Vehículo CUANDO pulse la pestaña de Agregar Bajo vehículo ENTONCES mostrara la ventana de Ingresar nuevo vehículo. DADO el ingreso de datos del vehículo CUANDO pulse Aceptar ENTONCES mostrara la ventana de Vehículos de la EPMT-SD DADO el menú de Orden de mantenimiento CUANDO pulse la pestaña de Lista orden ENTONCES mostrara la ventana de Ordenes de mantenimiento DADO el menú de Orden de mantenimiento CUANDO pulse la pestaña de Nueva orden ENTONCES mostrara la ventana Orden de manteamiento. DADO el ingreso de datos de la Orden de manteniendo CUANDO pulse Aceptar ENTONCES mostrará la ventana de Ordenes de Alto mantenimiento. DADO el menú de Orden de mantenimiento CUANDO pulse la pestaña de Alertas de mantenimiento ENTONCES mostrará la ventana con el calendario de las alertas de mantenimiento. DADO el ingreso a Alertas de manteniendo CUANDO pulse sobre la fecha ENTONCES mostrara la ventana de con la descripción de alerta DADO el menú de Orden de mantenimiento CUANDO pulse la pestaña Lista orden ENTONCES mostrara las ordenes con sus respectivos estados. Bajo DADO el ingreso a Lista orden CUANDO pulso el icono de código ENTONCES abrirá la ventana con el estado “Completo” o “Pendiente”. DADO el menú de Reporte CUANDO pulse la pestaña Ordenes de mantenimiento ENTONCES mostrara un PDF de las ordenes con sus Bajo estados filtrados

Estado Realizado

Realizado Realizado

Realizado

5.2.1.3.2. Sprint 1. 5.2.1.3.2.1. Sprint Planning. La reunión que se realizó con el Product Owner se definieron las características que tendrá el producto, ver Anexo 3, donde se obtuvo una visión clara del desarrollo con las historias de usuario.

5.2.1.3.2.2. Sprint Backlog 1. Tabla 15 Sprint Backlog 1 Nº Sprint

Historia

Estimación

Ingreso al sistema

Ingresar roles usuario

Ingreso de nueva persona

Modificación de datos

Estado de usuario

Categoría Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo

Tareas de Ingeniería Interfaz de Login Conexión de la Base de datos con PHP Validación del Login (usuario y contraseña) Codificación de mensajes de alertas en el Login Modelamiento BD de tabla roles de usuario Codificación de roles Validación de roles Creación del formulario "Persona" Interfaz de las pestañas "Lista persona" Interfaz de las pestañas "Agregar persona" Modelamiento BD de tabla “persona” Validación de “Persona” Codificación de mensajes para persona ingresada Codificación del icono eliminar y editar para todas las interfaces Codificación de mensaje de alerta "Eliminar Usuarios" Creación de botón “Estado” en la formulario “Usuario” Codificación del botón con dos estados desplegables Modelamiento de BD para el estado de usuario Validación del “Estado” de usuario

Nota: Versión final del Sprint Backlog 1.Adaptado de Investigación de campo

Estimación de tarea

Estado

4 3 5 1 4 4 5 4 5 5 3 2 2 7 1 1 2 1 1

Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado

5.2.1.3.2.3. Burndown Chart Sprint 1.

28/11/2017

27/11/2017

24/11/2017

23/11/2017

22/11/2017

20/11/2017

2 3

17/11/2017

16/11/2017

15/11/2017

14/11/2017

13/11/2017

2 3

10/11/2017

09/11/2017

07/11/2017

06/11/2017

03/11/2017

2 1

21/11/2017

08/11/2017

Estimació n

02/11/2017

Sprint 1

01/11/2017

Total Puntos

Tabla 16 Burndown Chart Sprint 1.

4 3 5 1 4 4 5 4 5 5 3 2 2 7

2 3

2 1 2

2 2

2 3 2 2 3

1 1 2 1 1 60 58 55 50 45 41 36 34 32 30 27 22 17 15 10 8 6 60 57 54 51 48 45 42 39 36 33 30 27 24 21 18 15 12

Nota: Versión Final de Burndown Chart Sprint 1. Adaptado de Investigación de Campo.

1 1 1

5 9

3 6

1 1 1 3

1 0 0

Burndown Chart 1 70

0 1

10 Restante

Figura 12. Grรกfico del Burndown Chart 1.

12 Estimado

5.2.1.3.2.4. Desarrollo del Sprint 1. En la historia Nº1 correspondiente al Login del sistema web de la EPMT-SD, el Product Owner solicita el acceso tenga encriptación pertinente, y al loguearse muestre la interfaz correspondiente a su rol de usuario ver Figura 13. En caso de haber olvidado la contraseña se crea el seleccionable que “¿Ha olvidado su contraseña?” donde a una nueva ventana donde le indicara completar su correo electrónico y el nombre de usuario. La historia Nº2 llamada Ingresar roles usuario (corresponde únicamente al usuario root del sistema), trata sobre la incorporación de permisos de acceso a la información para cada uno de los usuarios; esta historia se utilizará para mostrar una lista de los roles que tendrá el sistema, al momento esta historia queda solamente en realizada en líneas de código. La historia Nº3 denominada “Ingreso de nueva persona”, se crea la pestaña “Lista de personas” donde muestra la ventana “Personas de la EPMT-SD” con todas las personas registradas, ver Figura 14 y la pestaña “Agregar nueva persona” se crea para darle la asignación de tipo de persona en el sistema, la cual, si es “usuario” podrá ser utilizado para crear un nuevo usuario con los permisos que tenga su rol en el sistema. De lo contrario, será “empleado” donde utilizará sus datos únicamente para ingresar las órdenes de mantenimiento, ver Figura 15. La historia Nº4 nombrada “Modificación de datos” se crea en base a los requerimientos del Product Owner para poder realizar la respectiva actualización de los registros que se encuentran en los formularios. Esta historia está enfocada a ser reutilizada para los futuros formularios que muestren los datos registrados en el sistema, ya que su funcionalidad abarca el icono de “eliminar” con la acción de poder eliminar el registro seleccionado mostrándonos un una pequeña ventana que nos pide la confirmación, como ejemplo de esta acción tenemos la Figura 16 y el icono de “editar” para realizar algún cambio que ya se encuentre realizado dentro de los datos ya registrados, este icono al hacer clic, permite al usuario mostrar la ventana con los datos que se desea modificar, el ejemplo se lo muestra en la Figura 17. La historia Nº5 descrita como Estado de usuario cumple con una funcionalidad Activo o Inactivo que el Product Owner solicitó, hasta finalizar con esta historia únicamente queda realizada en líneas de código. Esta función fue solicitada debido a que la EPMT-SD puede dar de baja temporalmente a sus empleados por motivos que lo determina el Gerente General.

Al culminar este primer Sprint, se realizó una reunión con el Product Owner Ing. Edison Barahona, que tuvo como finalidad la entrega de la primera parte funcional del sistema. Se supo manifestar que el desarrollo de este proyecto tiene mucha aceptación, donde se expresó también, que, en este avance, quedó muy conforme con lo entregado, dando así la satisfacción de continuar con el desarrollo del producto.

Figura 13. Captura de pantalla del login.

Figura 14. Captura de pantalla Lista personas.

Figura 15. Captura de pantalla de ventana Agregar nueva persona.

Figura 16. Captura de pantalla de alerta de Eliminar persona.

Figura 17. Captura de pantalla de la ventana Editar persona.

5.2.1.3.2.5. Sprint Retrospective 1. El Product Owner tiene la opción de asistir o no a esta reunión; por lo que es una oportunidad para el equipo de desarrollo poder hablar sin disimulos de los éxitos y fracasos, siendo importante para el equipo el analizar su propio desempeño e identificar estrategias para mejorar sus procesos, ver Anexo 4. De forma similar, el Scrum Master (quien es el coach del equipo Scrum) puede observar impedimentos comunes que están afectando al equipo y tomar acciones para resolverlos La reunión usualmente se restringe a dos horas diarias. 5.2.1.3.2.6. Pruebas de Aceptación Sprint 1. Tabla 17 Prueba de aceptación 1. Prueba de Aceptación 1 Código: 001 Nombre caso de prueba: Ingreso al sistema. Módulo/sección a evaluar: Módulo de ingreso al sistema.

Historia de usuario asociada: 1

Descripción: En esta sección el product Owner de la EPMT-SD , puede ingresar al sistema de acuerdo al rol de usuario asignado. Pre-condiciones * El product owner debe ingresar a la url del sistema. Pasos y condiciones de ejecución * El product owner debe ingresar al sistema (usuario y contraseña). * El product owner debe ingresar a la ventana principal. Éxito: Si Falló: No Estado de prueba: Errores asociados: Ninguno Acción final: La información de los usuarios o empleados se guardaron en la base de datos. Nota: Los datos se obtuvieron en base a la investigación de campo.

Tabla 18 Prueba de aceptación 2. Prueba de Aceptación 2 Código: 002 Nombre caso de prueba: Ingreso roles de usuario Módulo/sección a evaluar: Módulo de ingreso de roles Historia de usuario asociada: 2 Descripción: En esta sección el product Owner de la EPMT-SD , puede asignar los roles del sistema de acuerdo a lo estipulado en con el equipo de desarrollo. Pre-condiciones * El root debe ingresar nuevo rol. * El product owner debe asignar rol al nuevo usuario. Pasos y condiciones de ejecución * El product owner debe ingresar al sistema (usuario y contraseña). * El product owner debe ingresar la información de un nuevo usuario o empleado. Éxito: Si Falló: No Estado de prueba: Errores asociados: Ninguno Acción final: La información de los usuarios o empleados se guardaron en la base de datos. Nota: Los datos se obtuvieron en base a la investigación de campo.

62 Tabla 19 Prueba de aceptación 3. Prueba de Aceptación 3 Código: 003 Nombre caso de prueba: Ingreso de nueva persona Módulo/sección a evaluar: Módulo de ingreso de persona

Historia de usuario asociada: 3

Descripción: En esta sección el product owner de la EPMT-SD , puede ingresar una nueva persona al sistema con su respectivo tipo (usuario o empleado). Pre-condiciones * El product owner debe ingresar nueva persona * El product owner debe completar todos los campos en blanco. Pasos y condiciones de ejecución * El product owner debe ingresar a la pestaña agregar persona. * El product owner debe ingresar la información de un nuevo usuario o empleado. Éxito: Si Falló: No Estado de prueba: Errores asociados: Ninguno Acción final: La información de los usuarios o empleados se guardaron en la base de datos. Nota: Los datos se obtuvieron en base a la investigación de campo.

Tabla 20 Prueba de aceptación 4. Prueba de Aceptación 4 Código: 004 Nombre caso de prueba: Modificación de datos Módulo/sección a evaluar: Módulo de modificar datos.

Historia de usuario asociada: 4

Descripción: En esta sección el product owner de la EPMT-SD , puede modificar los datos del formulario, de acuerdo a la selección, donde podrá eliminar o editar el registro que se muestra en la pantalla. Pre-condiciones * El product owner debe dirigirse al formulario deseado. * El product owner debe dar clic en el icono eliminar. * El product owner debe confirmar o cancelar la eliminación. * El product owner debe dar clic en el icono editar. Pasos y condiciones de ejecución * El product owner debe seleccionar el registro que va a eliminar o editar. * El product owner debe puede modificar, buscar, eliminar o generar un reporte de la información de los usuarios o empleados registrados. Éxito: Si Falló: No Estado de prueba: Errores asociados: Ninguno Acción final: La información de los usuarios o empleados se guardaron en la base de datos. Nota: Los datos se obtuvieron en base a la investigación de campo.

63 Tabla 21 Prueba de aceptación 5. Prueba de Aceptación 5 Código: 005 Nombre caso de prueba: Estado de usuario Módulo/sección a evaluar: Módulo de estado de usuario.

Historia de usuario asociada: 5

Descripción: En esta sección el product owner de la EPMT-SD , puede asignar un estado al usuario que se va a registrar o se encuentra registrado. Pre-condiciones * El product owner debe ingresar al formulario de “Usuario” * El product owner debe ingresar a la pestaña “Lista usuario” * El product owner debe asignar o editar el estado del usuario. Pasos y condiciones de ejecución * El product owner debe hacer clic en el botón desplegable para dar el estado al usuario. Éxito: Si Falló: No Estado de prueba: Errores asociados: Ninguno Acción final: La información de los usuarios o empleados se guardaron en la base de datos. Nota: Los datos se obtuvieron en basa a la investigación de campo.

5.2.1.3.3. Sprint 2. 5.2.1.3.3.1. Sprint Backlog 2. Tabla 22 Sprint Backlog 2. Nº Historia Sprint

Estimación

Ingreso de nuevo usuario

Ingresar Avenidas

Ingresar nueva dirección

Modificar direcciones

Registro de tipo de artículo

Tareas de Ingeniería Creación del formulario "Usuario" Interfaz de las pestañas "Lista usuarios" Interfaz de las pestañas "Agregar usuario" Modelamiento BD de tabla “usuario” Validación de “usuario” Codificación de mensajes ingreso de usuario correctamente Modelamiento BD de tablas para avenidas Creación del formulario "Avenidas" Interfaz de “Lista avenidas” Interfaz de Avenidas principales Interfaz de Avenidas principales Validación de avenidas Modelamiento BD de tabla de nueva dirección Creación del formulario “Dirección” Interfaz "Agregar dirección" e “Lista Direcciones” Validación de direcciones Codificación a nivel de base de datos para modificar direcciones Codificación en el formulario “Direcciones” Interfaz de "Editar dirección" Codificación de mensaje de modificación Creación del formulario “Tipo de artículo” Modelamiento de BD de tablas para tipo de artículo Interfaz tipo de artículo e interfaz de agregar tipo de artículo Codificación del formulario agregar nuevo tipo de artículo

Nota: Versión final del Sprint Backlog 1. Adaptado de Investigación de campo.

Estimación de tarea 4 5 5 3 2 2 1 2 2 1 1 1 3 3 4 3 3 4 3 3 1 1 2 1

Estado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado

5.2.1.3.3.2. Burndown Chart Sprint 2.

Estimac ión

26/12/2017

25/12/2017

22/12/2017

21/12/2017

20/12/2017

19/12/2017

18/12/2017

15/12/2017

14/12/2017

13/12/2017

12/12/2017

11/12/2017

08/12/2017

07/12/2017

06/12/2017

05/12/2017

04/12/2017

01/12/2017

30/11/2017

Sprint 2

29/11/2017

Total Puntos

Tabla 23 Burndown Chart Sprint 2

Tareas de Ingeniería Creación del formulario "Usuario" Interfaz de las pestañas "Lista usuario" Interfaz de las pestañas "Agregar usuario" Modelamiento BD de tabla “usuario” Validación de “usuario” Codificación de mensajes ingreso de usuario correctamente Modelamiento BD de tablas para avenidas Creación del formulario "Avenidas" Interfaz de “Lista avenidas” Interfaz de Avenidas principales Interfaz de Avenidas principales Validación de avenidas Modelamiento BD de tabla de nueva dirección Creación del formulario “Dirección” Interfaz "Agregar dirección" e “Lista Direcciones” Validación de direcciones Codificación a nivel de Base de datos Codificación en el formulario “Direcciones” Interfaz de "Editar dirección" Codificación de mensaje de modificación Creación del formulario “Tipo de artículo” Modelamiento de BD de tablas para tipo de artículo Interfaz tipo de artículo e interfaz de agregar tipo de artículo Codificación del formulario agregar nuevo tipo de artículo Restante Estimado

4 2 2 5 3 1 1 5 4 1 3 3 2 2 2 2 1 1 2 2 2 2 1 1 1 1 1 1 3 3 3 3 4 2 2 3 3 3 3 4 3 1 3 2 3 1 1 2 1 60 58 56 53 52 47 43 41 36 34 28 23 18 15 12 11 9 60 57 54 51 48 45 42 39 36 33 30 27 24 21 18 15 12

Nota: Versión Final de Burndown Chart Sprint 2. Adaptado de Investigación de Campo.

1 3 1 1 2 8 9

3 6

1 3

1 0 0

Burndown Chart 2 70

0 1

10 Restante

Figura 18. Grรกfico del Burndown Chart 1.

12 Estimado

5.2.1.3.3.3. Desarrollo del Sprint 2. La historia Nº6 que corresponde al Ingreso de nuevo usuario, esta historia se crea en base a los requerimientos del Product Owner para la administración de los usuarios que tendrán accesos al sistema, ver Figura 19. La pestaña de “Agregar nuevo usuario” interactuará con el Product Owner para realizar nuevos ingresos como se muestra en la Figura 20 y también tendrá la facilidad de poder eliminar usuarios o a su vez poder editar algún dato requerido. En la historia Nº7 denominada Ingresar avenidas, se visualizará en la pestaña de “Lista de avenidas” donde almacenara todos los datos que se registraran previamente, ver Figura 21. Para poder agregar una nueva avenida se crean el formulario en el cual se podrá digitar manualmente la avenida, ver Figura 22. La historia Nº8 nombrada Ingresar nueva dirección, muestra en una ventana las direcciones existentes, ver Figura 23, esta consiste en agregar una nueva dirección al sistema para que el Product Owner pueda generar una ordenes de mantenimiento o de activación de artículos que se verá más adelante en el desarrollo del producto. Esta funcionalidad se activa una vez agregadas las avenidas principales y secundarias, ver Figura 24, donde se podrá desplegar fácilmente una nueva dirección para tener de referencia en el sistema. La historia Nº9 llamada Modificar direcciones posee la capacidad de poder eliminar una dirección o editar los datos que por alguna razón pueden tener inconsistencias o errores de tipeo en las direcciones que ya se encuentran habilitadas en la ventana de direcciones, ver Figura 25. La historia Nº10 descrita como Registro de tipo de artículo es un requerimiento del Product Owner que consiste en ingresar los datos de cada tipo de artículo que puede existir en la bodega de semáforos, ver Figura 26. En la pestaña que dirige a la ventana de Ingresar tipo de artículo, ver Figura 27, se podrá completar los datos necesarios del artículo. Para la entrega de la parte funcional del Sprint 2 se realizó una reunión con el Product Owner, el cual indicó que está conforme con el avance del producto ya que se ha respetado el orden de desarrollo y todo el sistema se encuentra en una etapa avanzada. Sin más observaciones el Product Owner obtiene la segunda parte funcional del sistema dando así por culminado el segundo Sprint.

Figura 19. Captura de pantalla de Lista de usuarios.

Figura 20. Captura de pantalla Agregar nuevo usuario.

Figura 21. Captura de pantalla de Lista de avenidas.

Figura 22. Captura de pantalla de Agregar nueva avenida.

Figura 23. Captura de pantalla de Lista de direcciones.

Figura 24. Captura de pantalla de Agregar nueva direcciรณn.

Figura 25. Captura de pantalla de Editar dirección.

Figura 26. Captura de pantalla de Lista de tipos de artículos.

Figura 27. Captura de pantalla de Agregar tipo de artículo.

5.2.1.3.3.4. Sprint Retrospective 2. El Product Owner tiene la opciรณn de asistir o no a esta reuniรณn; por lo que es una oportunidad para el equipo de desarrollo poder hablar sin disimulos de los รฉxitos y fracasos, siendo importante para el equipo el analizar su propio desempeรฑo e identificar estrategias para mejorar sus procesos, ver Anexo 5. De forma similar, el Scrum Master (quien es el coach del equipo Scrum) puede observar impedimentos comunes que estรกn afectando al equipo y tomar acciones para resolverlos. La reuniรณn usualmente se restringe a dos horas diarias. 5.2.1.3.3.5. Pruebas de Aceptaciรณn Sprint 2. Tabla 24 Prueba de aceptaciรณn 6. Prueba de Aceptaciรณn 6 Cรณdigo: 006 Nombre caso de prueba: Ingreso de nuevo usuario Mรณdulo/secciรณn a evaluar: Mรณdulo de Ingreso de usuarios Historia de usuario asociada: 6 Descripciรณn: En esta secciรณn el product Owner de la EPMT-SD, puede ingresar al sistema para agregar, editar o eliminar usuarios. Pre-condiciones * El product owner debe estar logueado. * El product owner debe tener la informaciรณn de los usuarios. Pasos y condiciones de ejecuciรณn * El product owner debe ingresar a usuarios * El product owner debe ingresar la informaciรณn de un nuevo usuario * El product owner debe puede modificar, buscar, eliminar o generar un reporte de informaciรณn de los usuarios registrados. ร xito: Si Fallรณ: No Estado de prueba: Errores asociados: Ninguno Acciรณn final: La informaciรณn de los usuarios se guardaron en la base de datos. Nota: Los datos se obtuvieron en base a la investigaciรณn de campo.

Tabla 25 Prueba de aceptaciรณn 7. Prueba de Aceptaciรณn 7 Cรณdigo: 007 Nombre caso de prueba: Ingreso avenidas Mรณdulo/secciรณn a evaluar: Mรณdulo de avenidas Historia de usuario asociada: 7 Descripciรณn: En esta secciรณn el product Owner de la EPMT-SD , puede ingresar las avenidas al sistema ya sean principales o secundarias. Pre-condiciones * El product owner debe ingresar nueva avenida Pasos y condiciones de ejecuciรณn * El product owner debe ingresar a avenidas * El product owner debe elegir entre agregar avenida principal o secundaria * El product owner debe puede modificar, buscar, eliminar la informaciรณn de las avenidas. ร xito: Si Fallรณ: No Estado de prueba: Errores asociados: Ninguno Acciรณn final: La informaciรณn de las avenidas se guardaron en la base de datos. Nota: Los datos se obtuvieron en base a la investigaciรณn de campo.

72 Tabla 26 Prueba de aceptación 8. Prueba de Aceptación 8 Código: 008 Nombre caso de prueba: Ingresar nueva dirección Módulo/sección a evaluar: Módulo de direcciones Historia de usuario asociada: 8 Descripción: En esta sección el product owner de la EPMT-SD , puede ingresar una nueva dirección para su uso dentro del sistema. Pre-condiciones * El product owner debe ingresar nueva dirección Pasos y condiciones de ejecución * El product owner debe ingresar a la pestaña agregar dirección * El product owner debe puede modificar, buscar, eliminar o generar un de la información de las direcciones ingresadas. Éxito: Si Falló: No Estado de prueba: Errores asociados: Ninguno Acción final: La información de las direcciones se guardaron en la base de datos. Nota: Los datos se obtuvieron en base a la investigación de campo.

Tabla 27 Prueba de aceptación 9. Prueba de Aceptación 9 Código: 009 Nombre caso de prueba: Modificar direcciones Módulo/sección a evaluar: Direcciones Historia de usuario asociada: 9 Descripción: En esta sección el product owner de la EPMT-SD, puede modificar la información registrada de las direcciones. Pre-condiciones * El product owner debe dar clic en el icono editar. * El product owner debe confirmar o cancelar la eliminación. Pasos y condiciones de ejecución * El product owner debe ingresar al “Lista direcciones” * El product owner debe seleccionar que dirección va a editar o eliminar. Éxito: Si Falló: No Estado de prueba: Errores asociados: Ninguno Acción final: La información de direcciones guardaron en la base de datos. Nota: Los datos se obtuvieron en base a la investigación de campo.

Tabla 28 Prueba de aceptación 10. Prueba de Aceptación 10 Código: 010 Nombre caso de prueba: Registro de tipo de artículo Módulo/sección a evaluar: Módulo Tipo de artículo. Historia de usuario asociada: 10 Descripción: En esta sección el product owner de la EPMT-SD, puede ingresar nuevo tipo de artículo para el inventario dentro del sistema. Pre-condiciones * El product owner debe ingresar a la pestaña tipo de artículo Pasos y condiciones de ejecución * El product owner debe ingresar toda la información respecto al nuevo tipo de artículo para el sistema. * El product owner debe puede modificar, buscar, eliminar la información de los tipos de artículos. Éxito: Si Falló: No Estado de prueba: Errores asociados: Ninguno Acción final: La información de los tipos de artículos se guardaron en la base de datos. Nota: Los datos se obtuvieron en basa a la investigación de campo.

5.2.1.3.4. Sprint 3. 5.2.1.3.4.1. Sprint Backlog 3. Tabla 29 Sprint Backlog 3. Nº Historia Sprint

Estimación

Registro de nuevo Artículos

Cantidad de artículos en inventario

Ingreso de vehículos

Ordenes de manteniendo

Ver estado de orden de manteniendo

Reportes ordenes de mantenimiento

Categoría

Tareas de Ingeniería

Estimación de tarea 2 3 3 2 2 1 1 2 2 1 1 1 1 1 2 2 11 4 3 3 4

Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado Realizado

Estado

Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo

Creación del formulario "Artículo" Interfaz de las pestañas "Lista artículo" Interfaz de las pestañas "Agregar artículo" Modelamiento BD de tabla “artículo” Validación de “artículo” Codificación de mensajes de ingreso de artículo correctamente Modelamiento BD de tablas para Artículos activos Creación del formulario "Artículos activos" Interfaz de “Lista artículo activo” Interfaz de “Activar artículo” Interfaz de llenar campos para activar artículo Validación de artículos Modelamiento BD de tabla vehículo Creación del formulario “Vehículo” Interfaz “Lista vehículo” Interfaz “Agregar vehículo” Relaciones de tablas BD para orden de manteamiento Creación del formulario “Orden mantenimiento” Interfaz “Lista orden” Interfaz “Nueva orden” Creación del estado de orden en “Lista Orden”

Desarrollo

Codificación de estados

Realizado

Desarrollo Desarrollo Desarrollo Desarrollo

Creación de formulario “Reporte” Interfaz de reporte “Orden de mantenimiento” Codificación la ventana “Reporte” Generación de PDF

1 1 2 1

Realizado Realizado Realizado Realizado

Nota: Versión final del Sprint Backlog 3. Adaptado de Investigación de campo

5.2.1.3.4.2. Burndown Chart Sprint 3.

Nota: Versión Final de Burndown Chart Sprint 3. Adaptado de Investigación de Campo.

23/01/2018

3 2

22/01/2018

15/01/2018

19/01/2018

12/01/2018

18/01/2018

11/01/2018

1 1 3

17/01/2018

10/01/2018

16/01/2018

09/01/2018

05/01/2018

2 3

04/01/2018

03/01/2018

02/01/2018

01/01/2018

2 3 3 2 2 1 1 2 2 1 1 1 1 1 2 1 11 4 3 3 4 4 1 1 2 1 60 60

08/01/2018

Tareas de Ingeniería Creación del formulario "Artículo" Interfaz de las pestañas "Lista artículo" Interfaz de las pestañas "Agregar artículo" Modelamiento BD de tabla “artículo” Validación de “artículo” Codificación de mensajes de ingreso de artículo correctamente Modelamiento BD de tablas para Artículos activos Creación del formulario "Artículos activos" Interfaz de “Lista artículo activo” Interfaz de “Activar artículo” Interfaz de llenar campos para activar artículo Validación de artículos Modelamiento BD de tabla vehículo Creación del formulario “Vehículo” Interfaz “Lista vehículo” Interfaz “Agregar vehículo” Relaciones de tablas BD para orden de manteamiento Creación del formulario “Orden mantenimiento” Interfaz “Lista orden” Interfaz “Nueva orden” Creación del estado de orden en “Lista Orden” Codificación de estados Creación de formulario “Reporte” Interfaz de reporte “Orden de mantenimiento” Codificación la ventana “Reporte” Generación de PDF Restante Estimado

29/12/2017

Estimación

28/12/2017

Sprint 3

27/12/2017

Total Puntos

Tabla 30 Burndown Chart Sprint 3.

2 2 1 1 2 2 1 1 1 1 1

3 3 1

3 2

2 1 1 2

59 58 57 52 48 47 42 37 36 31 29 26 21 19 16 12 57 54 51 48 45 42 39 36 33 30 27 24 21 18 15 12

7 9

3 6

1 3

1 0 0

Burndown Chart 3 70

0 1

10 Restante

Figura 28. Grรกfico del Burndown Chart 3

12 Estimado

5.2.1.3.4.3. Desarrollo del Sprint 3. La historia Nº11 nombrada Registro de nuevo Artículo consiste en mostrar los artículos que podrán ser utilizado por el Product Owner como se observa en la Figura 29 para tener de manera ordenada la información respecto a todos nuevos artículos que ingresan al sistema y en la Figura 30 se ingresan sus respectivas cantidades y garantía. La historia Nº12 denominada Cantidad de artículos en inventario trata sobre la activación de los artículos que se encuentran dentro del inventario; en que consiste esta historia, una vez ingresada la información en la Figura 30 cuando se agregaron la cantidad de artículos en la historia anterior; esta tiene la funcionalidad de que los artículos puedan ser asignados a una dirección o un punto específico. En la Figura 31 se observa los artículos que se encuentran en funcionamiento. Para activar el artículo se debe seleccionar el número del código como se muestra en la Figura 32, el cual dará paso al formulario de Activar artículo con todos los campos requeridos como se muestra en la Figura 33. La historia Nº13 denominada Ingreso de vehículos es creada para complementarse más adelante con las ordenes de mantenimiento, siendo su funcionalidad el asignar un vehículo dentro de una nueva orden. Para ello se procese a mostrar la lista de todos los vehículos registrados, ver Figura 34 y para registrar uno nuevo se llenan los campos que se muestran en la Figura 35. La historia Nº14 nombrada Ordenes de manteniendo, es la historia de usuario más importante solicitada en base a los requerimientos del Product Owner, donde se une toda la información que se ha registrado en las anteriores historias para así mostrar una sola ventana, ver Figura 36 las ordenes de mantenimiento. Para generar una orden basta con completar los datos que se observan en la Figura 37 logrando así la llevar un excelente control sobre lo que el Product Owner desea hacer el seguimiento. Al haber activado un artículo se habrá generado automáticamente por medio del sistema las alertas de mantenimiento como se muestra en la Figura 38. La historia Nº15 llamada Ver estado de orden de manteniendo posee la capacidad de poder ver si una orden de mantenimiento, ver en Figura 36, se ha completado o si aún sigue como pendiente con los colores verde o rojo respectivamente, esta historia hace un resumen sobre lo que se ha cumplido o no con las órdenes de mantenimiento.

La historia Nº16 llamada Reportes de órdenes de mantenimiento posee la capacidad de mostrar las ordenes de mantenimiento con un filtro de completo o pendiente, ver Figura 39, dentro una ventana la cual permite generar Lista o guardar un PDF con el reporte.

Figura 29. Captura de pantalla de Lista de artículos.

Figura 30. Captura de pantalla de Agregar artículos.

Figura 31. Captura de pantalla de Lista de artículos activos.

Figura 32. Captura de pantalla de Seleccione artículo para su activación.

Figura 33. Captura de pantalla de Activar artículo.

A continuación, se muestra el código fuente que permitió automatizar la activación de los artículos y el cálculo de las horas de garantía de cada artefacto que se ingresa al sistema. require_once "../clases/conexion.php"; if (isset($_SESSION["session_usuario"])) { $u = new Consultas(); $nom = $u->saluda_al_usuario($_SESSION["session_usuario"]); $usua = $_SESSION["session_usuario"]; $cart = $_GET["id"]; $arti = new Consultas(); $reg = $arti->get_codigo_articulo("$cart"); $r = new Consultas(); $direc = $r->direccion(); if (isset($_POST["grabar"]) and $_POST["grabar"] == "si") { $punto = $_POST["f_direcion"]; $ref = $_POST["f_ref"]; $rb = $_POST["f_rbor"]; $re = $_POST["f_resquina"]; $det = $_POST["f_det"]; $hi = $_POST["f_hora_ini"]; $hf = $_POST["f_hora_fin"]; $f = $_POST["f_fech_inicio"]; $g = $_POST["f_gar"]; //llama a la clase conectar que hace la conexión de la base de datos $conec = new Conectar(); $cb = $conec->BDD(); //inserta en la tabla de artículos activos los datos traídos del formulario para activar articulo $comprobacion = mysqli_query($cb, "INSERT INTO articulos_activos (artact_codigo, art_codigo, dir_codigo, artact_referencia, artact_referencia_borde, artact_referencia_esquina, artact_detalle, artact_hora_inicio, artact_hora_final, artact_fecha_instalacion, artact_garantia, artact_mantenimiento, artact_estado, usuario) VALUES (NULL, '$cart', '$punto', '$ref', '$rb', '$re', '$det', '$hi', '$hf', '$f', '$g',now(), 'Activo', '$usua')"); if ($comprobacion != 0) { //extrae la ultima clave primaria ingresada $idact = mysqli_insert_id($cb); //calcula total de horas de trabajo del ultimo articulo activado mysqli_query($cb, "CALL calcular_hora('$hi','$hf','$idact')"); //calcula el tiempo de mantenimiento en los que trabajan las 24 hora mysqli_query($cb, "UPDATE articulos_activos SET artact_mantenimiento=DATE_ADD(artact_fecha_instalacion,INTERVAL artact_garantia MONTH) where artact_total_horas=0 AND artact_codigo='$idact'"); //calcula el tiempo de mantenimiento en los que trabajan menos de 24 horas mysqli_query($cb, "UPDATE articulos_activos SET artact_mantenimiento=DATE_ADD(artact_fecha_instalacion,INTERVAL ((((24/artact_total_horas)*10000)*artact_garantia)*30) DAY) where artact_total_horas>0 AND artact_codigo='$idact'"); //crea alertas a partir de los articulos mysqli_query($cb, "CALL crea_alerta('$idact','$usua')"); echo "<script type='text/javascript'> alert('Artíulo activado..'); history.go(-1); window.history.back(); </script>"; } else { echo "<script type='text/javascript'> alert('Articulo no activado..'); history.go(-1); window.history.back(); </script>"; } } ?>

Mediante el disparador que se muestra a continuación se pudo actualizar las cantidades de los artículos que se han activado.

CREATE TRIGGER `resta_articulo` AFTER INSERT ON `articulos_activos` FOR EACH ROW update articulos set art_cantidad=art_cantidad-1 where art_codigo=NEW.art_codigo

Figura 34. Captura de pantalla de Lista de vehículos.

Figura 35. Captura de pantalla de Agregar nuevo vehículo.

Figura 36. Captura de pantalla de Lista de órdenes de mantenimiento.

Figura 37. Captura de pantalla de Generar orden de mantenimiento.

Para automatizar el proceso de generar las órdenes de mantenimiento se utilizó el siguiente código fuente: <?php require_once "../clases/conexion.php"; if (isset($_SESSION["session_usuario"])) { $u = new Consultas(); $nom = $u->saluda_al_usuario($_SESSION["session_usuario"]); $user = $_SESSION["session_usuario"]; //imprime datos de las personas activas en el formulario para su selección de tareas $p = new Consultas(); $obj = $p->imprime_personas(); //imprime los vehiuclos activos en el formulario para su seleccion $r = new Consultas(); $d = $r->imprimir("vehiculo"); //imprime direcciónes en el formulario para su selección $punt = new Consultas(); $dir = $punt->direccion(); //extrae los datos del formulario mediante el método post

82 if (isset($_POST["grabar"]) and $_POST["grabar"] == "si") { ini_set('display_errors', 0); $sal = $_POST["f_slc"]; $frm = $_POST["f_frm"]; $proy = $_POST["f_pro"]; $sen = $_POST["f_se"]; $veh = $_POST["f_ve"]; $cho = $_POST["f_cho"]; $punto = $_POST["f_dirp"]; $activ = $_POST["f_actividad"]; //realiza la conexiรณn a la base de datos $conec = new Conectar(); $cb = $conec->BDD(); if ($_POST["f_per"] != "") { $empleados = $_POST["f_per"]; $comprueba = mysqli_query($cb, "SELECT *FROM tmp WHERE tmp_user='$user'"); if (mysqli_num_rows($comprueba) != 0) { //inserta datos a la tabla de encabezado de la orden de mantenimiento $insr = mysqli_query($cb, "INSERT INTO ordman_encabezado VALUES(null,'$sal','$frm','$proy','$sen',now(),'$veh','$cho','$punto','$activ','Pendiente','$user')"); //toma la ultima clave primaria ingresada $idl = mysqli_insert_id($cb); if ($insr == 1) { foreach ($empleados as $idper) { //inserta a la tabla de mantenimiento personas las personas escogidas para la orden de mantenimiento $inempl = mysqli_query($cb, "INSERT INTO mantenimiento_persona VALUES(null,'$idl','$idper')"); } if ($idl and $inempl) { $sql = mysqli_query($cb, "SELECT *FROM articulos_activos, tmp WHERE articulos_activos.artact_codigo=tmp.tmp_articulo"); while ($row = mysqli_fetch_array($sql)) { $art = $row['tmp_articulo']; $acti = $row['tmp_actividad']; if ($acti == 'Baja') { mysqli_query($cb, "INSERT INTO ordman_cuerpo VALUES(null,'$idl','$art','$acti','$user')"); mysqli_query($cb, "UPDATE articulos_activos SET artact_estado='Inactivo' WHERE artact_codigo='$art'"); mysqli_query($cb, "UPDATE alertas SET aler_fecha_atendida=now(),aler_estado='Finalizada' WHERE artact_codigo='$art'"); } mysqli_query($cb, "INSERT INTO ordman_cuerpo VALUES(null,'$idl','$art','$acti','$user')"); } mysqli_query($cb, "DELETE FROM tmp WHERE tmp_user='$user'"); echo "<script type='text/javascript'> alert('Dato registrado'); </script>"; } } else { mysqli_query($cb, "DELETE FROM ordman_encabezado WHERE ordman_codigo='$idl'"); echo "<script type='text/javascript'> alert('Datos no registrados'); </script>"; } } else { echo "<script type='text/javascript'> alert('No hay Actividades'); </script>";

83 } } else { mysqli_query($cb, "DELETE FROM tmp WHERE tmp_user='$user'"); echo "<script type='text/javascript'> alert('No hay personas seleccionadas'); </script>"; } } ?>

Figura 38. Captura de pantalla de Calendario de alertas de mantenimiento.

A continuación, se muestra el código fuente que permitió mostrar las alertas de mantenimiento dentro de un calendario y que a su vez lleva a cabo el seguimiento de los artículos que se encuentran en funcionamiento. <script> $(document).ready(function() { $('#calendar_alerta').fullCalendar({ header: { left: 'prev,next today', center: 'title', right: 'month,agendaWeek,agendaDay,listWeek' }, defaultDate: new Date(), navLinks: true, // can click day/week names to navigate views editable: true, eventLimit: true, dayClick: function(fecha,event,view){ }, events: [ <?php for ($i = 0; $i < count($reg); $i++) { ?> { id:"<?php echo $reg[$i]["aler_codigo"]; ?>", title:" Alerta, <?php echo $reg[$i]["tipart_nombre"] ?>", descripcion:"<?php echo "Alerta creada: " . $reg[$i]["tipart_nombre"] . " " .

84 $reg[$i]["tipart_tecnologia"] . " " . $reg[$i]["tipart_caracteristicas"] . " " . $reg[$i]["tipart_color"] . " <br> Cumple su vida útil: " . $reg[$i]["artact_mantenimiento"] . "<br> Ubicada: " . $reg[$i]["aprincipal"] . ", " . $reg[$i]["asecundaria"] . "<br> Referencia: " . $reg[$i]["artact_referencia"] . "<br>Borde:" . $reg[$i]["artact_referencia_borde"] . " Esquina:" . $reg[$i]["artact_referencia_esquina"] . "<br> Estado: " . $reg[$i]["aler_estado"] ?>", start:"<?php echo $reg[$i]["alerta"]; ?>", end:"<?php echo $reg[$i]["artact_mantenimiento"]; ?>" }, <?php } ?> ], eventClick:function(calEvent,jsEvent,view){ $('#tituloEvento').html(calEvent.title); $('#desEvento').html(calEvent.descripcion); $('#f_ID').val(calEvent.id); $("#alertamodal").modal(); } }); }); </script>

Figura 39. Captura de pantalla de Reporte de artículos.

No se realiza la retrospectiva ni las pruebas de aceptación ya que en esta etapa se entrega el producto final. 5.2.2. Diseño relacional de la base de datos. Una vez obtenido los requerimientos que proporcionó el Product Owner, se procedió a estructurar los diferentes módulos del sistema, los cuales estuvieron sujetos a cambios durante el desarrollo de los Sprint, ya que en las reuniones se interactuaba con el Product Owner, el cual manifestaba su opinión para mejorar sistema. Tomando en cuenta lo dicho se precedió a realizar el esquema de la base de datos como se muestra en la Figura 40.

Figura 40. DiseĂąo relacional de la Base de Datos. Adaptado de sistema gestor WorkBench de Base de Datos MySQL.

5.2.3. Acta de entrega recepciĂłn. Para constancia de la entrega del sistema, se realizĂł el documento que se adjunta en el Anexo 6. Para el presente trabajo de titulaciĂłn el manual de usuario ver Anexo 7, manual de instalaciĂłn ver Anexo 8 y el diccionario de datos, ver Anexo 9.

5.3. AnĂĄlisis del impacto Los impactos dentro del trabajo de titulaciĂłn se promedian para determinar si el proyecto ha tenido un impacto negativo o positivo despuĂŠs de la implementaciĂłn. Para determinar el mismo se identifican varios factores dentro del grupo, que en este caso es la poblaciĂłn del departamento de trĂĄnsito de la EPMT-SD. A continuaciĂłn, se muestra la fĂłrmula y la tabla que determinan los diferentes impactos y los indicadores numĂŠricos de cada uno. đ?&#x2018;ľđ?&#x2018;° = Donde:

â&#x2C6;&#x2018; đ?&#x2018;ľâ&#x2C6;&#x2DC;

NI = Nivel de impacto â&#x2C6;&#x2018;= Sumatoria de los niveles đ?&#x2018; â&#x2C6;&#x2DC; = Cantidad de Indicadores

Tabla 31 Niveles de Impacto Nivel

DescripciĂłn del Impacto

-3

Alto nivel negativo

-2

Medio nivel negativo

-1

Bajo nivel negativo

Sin Impacto

Bajo nivel positivo

Medio nivel positivo

Alto nivel positivo

Nota: Adaptado de â&#x20AC;&#x153;MetodologĂas para trabajo de grado: Tesis y Proyectosâ&#x20AC;? por Posso (2009).

Los impactos que se analizaron para determinar el impacto general son: social, tecnolĂłgico, ambiental y econĂłmico.

A continuación, se muestra la fórmula y la tabla que determinan los diferentes impactos y los indicadores numéricos de cada uno. 5.3.1. Impacto Social. Tabla 32 Impacto Social. Indicadores Mantenimientos preventivos Ayuda reducir accidentes de transito TOTAL SUMATORIA RESULTADO Nota: Fuente Investigación de campo.

-3

-2

Nivel de Impacto -1 0 1

2 X

3 X 6

∑=6 6 NI = = 3 2 Alto nivel positivo

Análisis: La EPMT-SD está muy pendiente en los artículos activos para su mantenimiento preventivo, el sistema de gestión de semáforos con las alertas creadas automáticamente, facilita detectar en qué punto y qué artículo está próximo a su mantenimiento. Con los mantenimientos preventivos dados a tiempo en los artículos activos, ayuda a reducir accidentes de tránsito, como también las llamadas constantes del ECU 911. Para la EPMT-SD es muy importante mantener un nivel alto de confidencialidad de la información ya que existe información delicada dentro del departamento de tránsito como el inventario y la información de datos personales de los empleados. Esta información debe mantenerse accesible únicamente a las personas autorizadas lo cual se controla con los perfiles de usuario o privilegios.

5.3.2. Impacto tecnológico. Tabla 33 Impacto Tecnológico Indicadores

-3

-2

Procesos Confidencialidad de la Información Reportes TOTAL SUMATORIA

Nivel de Impacto -1 0 1

2 X X 4

X 3

∑=7 7 NI = = 2,3 3 Medio nivel positivo

RESULTADO Nota: Fuente Investigación de campo.

Análisis: Se tomó la decisión de automatizar los procesos usando la tecnología, evitando la redundancia de datos llevados de forma manual, agilitando la búsqueda de artículos activos ubicados en diferentes partes de la urbe. La confidencialidad de la información, se puede comprobar con la facilidad al mantener los datos privados dentro de la empresa. La generación de reportes es importante para la empresa ya que ayuda a la toma de decisiones. 5.3.3. Impacto ambiental. Tabla 34 Impacto ambiental. Indicadores Impresión de hojas Materiales de oficina TOTAL SUMATORIA RESULTADO Nota: Fuente Investigación de campo.

-3

-2

Nivel de Impacto -1 0 1

2 X 2

3 X 3

∑=5 5 NI = = 2,5 2 Medio nivel positivo

Análisis: Como el sistema se encuentra en la web, se genera un impacto positivo para no Lista las hojas ya que posee todos los procesos son automatizados.

Los materiales de oficina como lápices, hojas, esferos, etc., se redujeron en vista de que ya no es necesario llevar los procesos manuales. 5.3.4. Impacto económico. Tabla 35 Impacto económico. Indicadores

-3

-2

Suministro de Oficina TOTAL SUMATORIA

Nivel de Impacto -1 0 1

2 X 2

∑=2 2 NI = = 2 1 Medio nivel positivo

RESULTADO Nota: Fuente Investigación de campo.

Análisis: Disminución de la compra de suministro de oficina debido a que ya no se requiere la utilización de los mismos. 5.3.5. Impacto general. Tabla 36 Impacto general. Indicadores Impacto social Impacto tecnológico Impacto ambiental Impacto económico TOTAL SUMATORIA RESULTADO Nota: Fuente Investigación de campo.

-3

-2

Nivel de Impacto -1 0 1

2 X X X X 8

∑=8 8 NI = = 2 4 Medio nivel positivo

Análisis: Con el análisis de impacto social, tecnológico, ambiental y económico, se determinó que obtuvo un impacto de medio nivel positivo, ya que se automatizaron los procesos de la gestión de los semáforos que se llevaban a cabo de forma manual. Como constancia de la implementación del sistema web y funcionamiento del mismo, la empresa entrega una carta del impacto generado, ver Anexo 10.

6. DISCUSIÓN DE RESULTADOS 6.1.1. Discusión de la entrevista. Con la información que proporcionó el gerente del departamento de tránsito, se nos dio a conocer que existen tres roles que estarían dentro del sistema y cada uno deberá tener sus privilegios de acuerdo a los permisos que tengan respecto a su rol. Para poder determinar si el proyecto es viable se procedió a realizar una encuesta a los representantes de cada área en el departamento de tránsito. En la entrevista donde se trató los diferentes puntos se determinó que el departamento de tránsito de la EPMT-SD los procesos en la gestión de semáforos se llevaban a cabo de manera manual, por lo tanto, se percibió la necesidad de un sistema que automatice los procesos de la gestión de semáforos, brindando de manera ágil la búsqueda de información. 6.1.2. Discusión encuestas. De acuerdo a las preguntas planteadas, una vez obtenida la información de las encuestas aplicadas en el departamento de tránsito de la EPMT-SD, al gerente, la secretaria y los empleados que realizan la gestión de semáforos, se determinó que es muy importante crear un sistema web donde se automatice los procesos que estas personas realizan diariamente, dando solución a la problemática del departamento. 6.1.3. Discusión fase de desarrollo del software. A continuación, se realiza una discusión sobre cada una de las etapas que se dividió el desarrollo del sistema. El Product Backlog permitió obtener los requerimientos de la funcionalidad del sistema, abarcando las historias de usuario correspondientes a los Sprint de desarrollo del sistema. En la reunión del Sprint Planning se pudo constatar que la comunicación con el equipo de desarrollo y el dueño del producto fue de vital importancia para la planificación del tiempo que abarcaría la culminación de todo el proyecto. El desarrollo del sistema se lo realizó en tres Sprint en base a la planificación previa con el dueño del producto; lo que nos permitió dividir las historias de usuario que se

realizaron dentro de los tres meses de desarrollo, lo cual sirvió para no perder trazabilidad de los avances de las tareas de ingeniería que se iban realizando diariamente. Al concluir cada Sprint se pudo entregar una parte funcional al dueño del producto. La ventaja del marco de trabajo que se pudo observar en el desarrollo del sistema, fue la realización de reuniones diarias de no más de quince minutos para hacer un análisis de los avances del día de trabajo anterior, esto permitió al equipo de desarrollo observar que se iba cumpliendo con las tareas propuestas para cada Sprint. Las Retrospectivas que se presentaron al final de los Sprint con el equipo de desarrollo, Scrum Master y el dueño del producto, permitieron mostrar en una lista todas las tareas que se cumplieron, las cuales indicaron, que no hubo observaciones de la parte funcional entregada al dueño del producto, pudiendo avanzar con la siguiente iteración del desarrollo. Las pruebas de aceptación abarcaron la aceptación de la funcionalidad del sistema las cuales permitieron mostrar en conjunto con el Scrum Master el avance de desarrollo. Estas fueron de vital importancia para continuar con la siguiente iteración del producto.

7. CONCLUSIONES •

La información obtenida mediante una entrevista al Product Owner basada en una serie de preguntas y afirmaciones, permitió determinar los procesos de gestión de semáforos que fueron automatizados en el departamento de tránsito; estos procesos dieron los lineamientos a los requerimientos del sistema web.

•

Con el análisis comparativo de metodologías ágiles realizadas en la presente investigación, mediante una tabla comparativa de las características principales y asignando las ponderaciones de acuerdo a parámetros, se finiquitó que el marco de trabajo Scrum fue el que se adaptó al desarrollo del sistema web de gestión de semáforos.

•

El marco de trabajo Scrum de acuerdo a su desarrollo ágil iterativo incremental en conjunto con las buenas prácticas de trabajo colaborativo, permitió el desarrollo del sistema web de gestión de semáforos, cabe indicar que la entrega de partes funcionales al finalizar cada Sprint fue de vital importancia para cumplir con los tiempos establecidos.

8. RECOMENDACIONES •

El entrevistador debe llevar una guía clara y precisa de las preguntas a realizar para obtener los procesos que se deberán automatizar en el sistema; se sugiere como buena práctica grabar en audio la entrevista.

•

Realizar un análisis comparativo de metodologías en base a las características del producto a desarrollar y seleccionar la metodología a utilizar de acuerdo a los parámetros de calificación establecidos.

•

Utilizar el marco de trabajo Scrum, ya que su enfoque de gestión ágil proporciona la administración de proyectos de desarrollo de software, facilitando el flujo de información y comunicación entre el equipo de trabajo con el Product Owner.

9. LISTA DE REFERENCIAS Ali, S. and Agarwal, U. (2016). IJAR - Indian Journal of Applied Research - A Standard Program to Classify Books/Documents according to Colon Scheme of Classification (6° ed.). Using PHP Environment. Recuperado el 10 de mayo de 2018. Obtenido de: https://www.worldwidejournals.com/indian-journal-of-applied-research(IJAR)/file.php?val=April_2016_1459582487__187.pdf Álvarez, A., De las Heras del Dedo, R. & Lasa, C. (2012). Métodos Ágiles y Scrum. Madrid: Ediciones Anaya Multimedia. Avante, E. (2018). Comparativas metodologías ágiles vs tradicionales. Avante. Recuperado el 12 de septiembre de 2017. Obtenido de: http://www.avante.es/comparativametodologias-agiles-vs-tradicionales/ Arias, A. (2015). Aprende sobre la Ingeniería de Software. Middletown: IT Campus Academy. Caracheo, A. (2014). Metodología del desarrollo para sistemas de información basados en Web.

Recuperado

mayo

2018.

Obtenido

de:

http://ri.uaq.mx/xmlui/handle/123456789/2525 Báez, C., & Suárez, M. (2013). Proceso de desarrollo de Software. Boyacá: Búhos Editores Ltda. Bernal, C. (2010). Metodología de la investigación. Pearson Educación de México, S.A. de C.V. Recuperado el 11 de noviembre de 2017. Obtenido de: http://www.sidalc.net/cgibin/wxis.exe/?IsisScript=EARTH.xis&method=post&formato=2&cantidad=1&expresio n=mfn=022575 Borda Pérez, M. (2013). El proceso de investigación: visión general de su desarrollo. Universidad del Norte. Brito, K., Sosa, D., & Héctor, K. (2011). Selección de Metodologías de Desarrollo para Aplicaciones Web. Saarbucken: Académica Española. Recuperado el 15 de noviembre de 2017. Obtenido de: http://www.redalyc.org/pdf/3783/378343672004.pdf

Deemer, P., Benefield, G., craig, L, & Vodde, B. (2009). Información básica de Scrum. Recuperado

septiembre

2017.

Obtenido

de:

http://www.goodagile.com/scrumprimer/scrumprimer_es.pdf Espín, F., & Saltos, J. (2010). Control y reprogramación de un controlador de tráfico por medio de la red de telefonía móvil, para su implementación en el área de semaforización de la policía nacional de la zona sur del distrito metropolitano de Quito, Quito. Flórez, H. (2012). Programación orientada a objetos usando Java. Bogotá D. C: ECOE Ediciones. Guerrero, J., Reyes, D, Cortes F., & Virgen L. (2010). Plataforma para Gestión de la Red de Semáforos de Zonas Urbanas, 12–18. Recuperado el 12 de septiembre de 2017. Obtenido de: http://www.iiisci.org/journal/CV$/risci/pdfs/MJ354ET.pdf Guzdial, M., Vidal Romero Elizondo, A. and Ericson, B. (2013). Introducción a la computación y programación con Python. México: Pearson. Hernández Sampieri, R., Fernández Collado, C., Baptista Lucio, P., Méndez Valencia, S. and Mendoza Torres, C. (2014). Metodología de la investigación. México, D.F.: McGrawHill Education. Ibarra, C., & Piña, J. M. (2011). Propuesta para el mejoramiento del transporte público urbano para la ciudad de Azogues con perspectivas hacia: la seguridad vehicular, contaminación ambiental y gestión del tránsito. Ibm, C. (2018). IBM developerWorks: Download: IBM Db2 Express-C. Recuperado el 10 de mayo

2017.

Obtenido

de:

https://www.ibm.com/developerworks/downloads/im/db2express/index.html Isla Visual. (2012). Diferencias Entre Scrum y Xp. Recuperado el 11 de septiembre de 2017, Obtenido

de:

http://www.islavisual.com/articulos/desarrollo_web/diferencias-entre-

scrum-y-xp.php López, L. (2013). Metodología de la programación Orientada a Objetos (2° ed.). México: Alfaomega.

Measey, P. (2015). Agile Foundations: Principles, practices andframeworks. Swindon: The British Computer Society. Medina, P., & Calvopiña E. (2016). Análisis, diseño y desarrollo de un sistema informático para la obtención de indicadores de sostenibilidad: ambientales y sociales para la producción de leche en fincas del cantón Cayambe. Universidad Politécnica Salesiana, Quito. Montoro, S. (2013). Cómo seleccionar una plataforma de desarrollo para un proyecto web | La Pastilla Roja. Lapastillaroja.net. Recuperado el 10 de mayo de 2018. Obtenido de: https://lapastillaroja.net/2013/10/como-seleccionar-plataforma-tecnologica/ Moreno, J. (2013). Programación. Bogotá: Ra-ma. Navarro, A., Fernández, J., & Morales, J. (2013). Revisión de metodologías ágiles para el desarrollo de software Prospectiva, ll (2), 30-39. Recuperado el 15 de septiembre de 2017. Obtenido de: https://dialnet.unirioja.es/servlet/artículo?codigo=4752083 Oracle, C. (2018). ¿Qué es Java y para qué es necesario?. Recuperado el 10 de mayo de 2018. Obtenido de: https://www.java.com/es/download/faq/whatis_java.xml Pérez, M. (2015). MySQL Diseño, Programación y Administración de Bases de Datos. San Bernardino: Paperback. Piattini, M., García, F., Rodríguez, I., & Pino, F. (2012). Calidad de Sistemas de Información. México D. F.: Alfaomega. Pressman, R. (2010). Ingeniería del software. México: McGraw-Hill. Posso, M. A. (2009). Metodología para el trabajo de grado: Tesis y Proyectos (4° ed.). Ibarra: NINA Comunicaciones. Rosado, A., Quintero, A., & Meneses, C. (2012). Desarrollo ágil de software aplicando programación extrema. Revista ingenio UFPSO. Secretaria Nacional de Planificación y Desarrollo [SENPLADES], (2017). Objetivo 11. Asegurar la soberanía y eficiencia de los sectores estratégicos para la transformación industrial y tecnológica - Plan Nacional 2013 - 2017. Recuperado el 20 de septiembre de 2017. Obtenido de: http://www.buenvivir.gob.ec/objetivo-11.-asegurar-la-soberania-

y-eficiencia-de-los-sectores-estrategicos-para-la-transformacion-industrial-ytecnologica Schwaber, K. and Sutherland, J. (2017). Scrum Alliance - The Scrum Guide. Scrumalliance.org.

Recuperado

septiembre

2017.

https://www.scrumalliance.org/learn-about-scrum/the-scrum-guide Sznajdleder, P. (2013). Java a fondo. MĂŠxico: Alfaomega Grupo Editor. Thierry, G. (2013). Java 7 Bases del lenguaje y de la programaciĂłn orientada a objetos. Barcelona: Ediciones ENI.

10. GLOSARIO Apache: servidor web con licencia libre de uso. Se puede utilizar en muchas plataformas, y mantiene un excelente rendimiento. Framework: es un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática. HTTP: protocolo de transferencia de hipertexto y es el protocolo de comunicación que permite las transferencias de información en la World Wide Web. IP: significa Internet Protocol y es un número que identifica de manera única a un dispositivo dentro de una red. MySQL: sistema gestor de base de datos, de código abierto. Scrum: marco de trabajo de desarrollo de software ágil. Sublime Text: editor código fuente que es compatible para todos los sistemas operativos y se lo puede descargar de forma gratuita de su página web.

11. ANEXOS Anexo 1. Hoja de requerimientos del sistema

Hoja de requerimientos del sistema Santo Domingo 27 de octubre de 2017 Requerimientos funcionales • • • • • • • • • • • • •

El sistema debe permitir realizar el ingreso y control de usuarios al sistema. El sistema permitirá guardar las contraseñas encriptadas. El sistema permitirá gestionar personal para usar sus datos en la creación de usuarios y asignar personal para las órdenes de mantenimiento. El sistema permitirá gestionar las avenidas, que serán utilizadas para la creación de nuevas direcciones. Este sistema permitirá registrar tipos de artículos. El sistema nos permitirá llevar un control de cantidad de los artículos existentes en mini bodega. El sistema permite activar artículos en las direcciones creadas con sus respectivas referencias. Una vez activado un artículo, el sistema nos creara alertas de mantenimientos en cada artículo con 4 días antes de la fecha de cumplimiento su vida útil. Se gestionarán los vehículos que se utilizarán para dar mantenimiento a los artículos activos. El sistema permitirá crear órdenes de mantenimiento para los artículos activos en una dirección. El sistema permitirá crear un calendario de alertas de mantenimiento. El sistema deberá generar reportes de los artículos y de las órdenes de mantenimiento. El sistema proporcionará mensajes de error informativos orientados al usuario final.

Requerimientos no funcionales. • • • • •

El sistema debe contar con una interfaz amigable para el usuario. El sistema permitirá optimizar los procesos. Se realizará manual de usuario, técnico y de instalación. El sistema debe estar alojado dentro del servidor de la EPMT-SD. La aplicación web poseerá un diseño responsive con el fin de garantizar la adecuada visualización en múltiples computadores personales, dispositivos, tabletas y teléfonos inteligentes.

100

Anexo 2. Encuesta ENCUESTA Fecha: 28 de octubre de 2017 La siguiente encuesta va dirigida al personal que labora en el área de sistemas de la EMPRESA PÚBLICA MUNICIPAL DE TRANSPORTE TERRESTRE, TRÁNSITO, SEGURIDAD VIAL Y TERMINALES TERRESTRES SANTO DOMINGO DURANTE EL PERÍODO 2017-2018, y tiene como finalidad recolectar información para realizar el trabajo de titulación denominado: “SISTEMA WEB PARA LA GESTIÓN DE LOS SEMÁFOROS EN LA EMPRESA PÚBLICA MUNICIPAL DE TRANSPORTE TERRESTRE, TRÁNSITO, SEGURIDAD VIAL Y TERMINALES TERRESTRES SANTO DOMINGO DURANTE EL PERÍODO 2017-2018”;

1. ¿Considera que hay un buen control de mantenimiento para los semáforos que están a cargo la empresa? SI

2. ¿Cómo llevan el control de mantenimiento de los semáforos en la empresa? Manual Sistematizada Otros Métodos Ninguno

3. ¿Cree usted que el procedimiento actual que lleva la empresa para el control de mantenimiento de los semáforos es adecuado? SI

4. ¿Cómo considera usted que la implementación de un sistema para el control de mantenimiento de semáforos para la institución? No es Importante Poco Importante Importante Muy Importante 5. ¿Considera importante la implementación de un sistema web para la gestión de semáforos de la empresa?

101

6. ¿Considera usted que este sistema mejoraría el control de mantenimiento en los semáforos activos que tiene la empresa? SI

7. ¿Ha tenido inconveniente con los mantenimientos de los semáforos activos en la empresa? SI

8. ¿Cree usted que el sistema web para la gestión de semáforos les ahorraría tiempo y gasto económico a la empresa? SI

Nota: La información obtenida será utilizada explícitamente para fines académicos.

102

Anexo 3. Historias de Usuario. Historia de Usuario Número: 1

Usuario: Todos

Nombre historia: Ingreso al Sistema Prioridad en negocio: 90

Riesgo en desarrollo: medio

Puntos estimados: 13

Sprint asignado: 1

Programador responsable: Franklin Pérez y Edison Calle Descripción: COMO usuario QUIERO ingresar el usuario y la contraseña, PARA poder acceder al sistema. Escenario de prueba: DADO el ingreso del usuario y la contraseña sean correctos, CUANDO pulse el botón de ingresar ENTONCES abrirá la ventana gestión semafórica. DADO el ingreso del usuario sean incompletos o incorrectos, CUANDO pulso el botón ingresar ENTONCES se muestra mensaje de error. DADO el ingreso del usuario CUANDO pulso la opción de iniciar sesión ENTONCES el sistema permitirá guardar el nombre de usuario.

Historia de Usuario Número: 2

Usuario: root

Nombre historia: Ingresar roles usuario Prioridad en negocio: 90

Riesgo en desarrollo: medio

Puntos estimados: 13

Sprint asignado: 1

Programador responsable: Franklin Pérez y Edison Calle Descripción: COMO root QUIERO ingresar nuevo rol PARA controlar los permisos de usuarios. Escenario de prueba: DADO el ingreso completo del rol CUANDO pulse el botón de guardar ENTONCES se visualizará en la lista de roles de usuario. DADO el ingreso del rol duplicado CUANDO pulso el botón guardar ENTONCES no se guardarán los datos y se muestra mensaje de error.

103

Historia de Usuario Usuario: administrador

Número: 3 Nombre historia: Ingreso de nuevo persona Prioridad en negocio: 100

Riesgo en desarrollo: bajo

Puntos estimados: 21

Sprint asignado: 1

Programador responsable: Franklin Pérez y Edison Calle Descripción: COMO administrador QUIERO ingresar datos de nueva persona PARA visualizar en la pantalla. Escenario de prueba: DADO el menú principal en formulario Persona CUANDO haga clic en Lista personas ENTONCES muestra ventana Personas de la EPMT-SD DADO el menú principal en formulario Persona CUANDO haga clic en Agregar usuario ENTONCES muestra la ventana de ingresar datos del usuario. DADO los datos de persona CUANDO pulse el botón de estado activo ENTONCES aparecerá en la lista para crear orden de mantenimiento DADO los datos de persona CUANDO pulse el botón de estado inactivo ENTONCES no aparecerá en la lista para crear orden de mantenimiento DADO el ingreso de persona con correo duplicado CUANDO pulso el botón aceptar ENTONCES mostrara mensaje de correo ya en uso. DADO el ingreso del usuario con datos vacíos o incompletos CUANDO pulso la opción guardar ENTONCES no se guardaran los datos y se muestra mensaje de error.

Historia de Usuario Número: 4

Usuario: administrador

Nombre historia: Modificación de datos Prioridad en negocio: 80

Riesgo en desarrollo: medio

Puntos estimados: 8

Sprint asignado: 1

Programador responsable: Franklin Pérez y Edison Calle Descripción: COMO administrador QUIERO eliminar o editar los datos de los formularios PARA parar mantener actualizado el sistema. Escenario de prueba: DADO los datos del formulario CUANDO pulse el icono de eliminar ENTONCES aparecerá el mensaje de confirmación. DADO los datos del formulario CUANDO pulse el icono de editar ENTONCES se redirigirá a la ventada de editar datos.

104

Historia de Usuario Número: 5

Usuario: administrador

Nombre historia: Estado de usuario Prioridad en negocio: 70

Riesgo en desarrollo: bajo

Puntos estimados: 5

Sprint asignado: 1

Programador responsable: Franklin Pérez y Edison Calle Descripción: COMO administrador QUIERO asignar el estado de usuario PARA que acceda al sistema. Escenario de prueba: DADO los datos del usuario CUANDO pulse el botón de estado activo ENTONCES el usuario tiene acceso al sistema. DADO los datos del usuario CUANDO pulse el botón de estado inactivo ENTONCES el usuario no tiene acceso al sistema.

Historia de Usuario Número: 6

Usuario: administrador

Nombre historia: Ingreso de nuevo usuario Prioridad en negocio: 100

Riesgo en desarrollo: alto

Puntos estimados: 21

Sprint asignado: 2

Programador responsable: Franklin Pérez y Edison Calle Descripción: COMO administrador QUIERO ingresar datos del nuevo usuario PARA visualizar en la pantalla. Escenario de prueba: DADO el menú principal en formulario Usuario CUANDO haga clic en Lista usuarios ENTONCES muestra ventana Usuarios del sistema DADO el menú principal en formulario Usuario CUANDO haga clic en Agregar usuario ENTONCES muestra la ventana de ingresar datos del usuario. DADO el ingreso de usuario con correo duplicado CUANDO pulso el botón guardar ENTONCES no se guardarán los datos y se muestra mensaje de error.

105

Historia de Usuario Número: 7

Usuario: administrador

Nombre historia: Ingresar avenidas Prioridad en negocio: 40

Riesgo en desarrollo: bajo

Puntos estimados: 8

Sprint asignado: 2

Programador responsable: Franklin Pérez y Edison Calle Descripción: COMO administrador QUIERO ingresar nueva avenida PARA crear dirección. Escenario de prueba: DADO el ingreso completo de avenida CUANDO pulse el botón de guardar ENTONCES se visualizará en la lista de avenidas. DADO el ingreso de avenida duplicado CUANDO pulso el botón guardar ENTONCES no se guardarán los datos y se muestra mensaje de error. DADO el ingreso de avenida con datos vacíos CUANDO pulso la opción guardar ENTONCES no se guardaran los datos de la avenida y se muestra mensaje de error.

Historia de Usuario Número: 8

Usuario: administrador

Nombre historia: Ingresar nueva dirección Prioridad en negocio: 50

Riesgo en desarrollo: medio

Puntos estimados: 13

Sprint asignado: 2

Programador responsable: Franklin Pérez y Edison Calle Descripción: COMO administrador QUIERO ingresar nueva dirección PARA agregar puntos semafóricos del sistema. Escenario de prueba: DADO el ingreso avenida principal y secundaria CUANDO pulse el botón de guardar ENTONCES se visualizará la dirección. DADO el ingreso avenida principal y secundaria sea duplicado CUANDO pulso el botón guardar ENTONCES no se guardarán la dirección y se muestra mensaje de error. DADO el ingreso avenida principal o secundaria estén vacíos o incompletos CUANDO pulso la opción guardar ENTONCES no se guardara la dirección y se muestra mensaje de error.

106

Historia de Usuario Número: 9

Usuario: administrador

Nombre historia: Modificar direcciones Prioridad en negocio: 50

Riesgo en desarrollo: medio

Puntos estimados: 13

Sprint asignado: 2

Programador responsable: Franklin Pérez y Edison Calle Descripción: COMO administrador QUIERO editar o eliminar datos de las direcciones PARA visualizar en el sistema. Escenario de prueba: DADO el menú de direcciones CUANDO haga clic en mostrar todo ENTONCES se visualizará la lista de todas las direcciones registradas. DADO la dirección seleccionada CUANDO pulso el botón ver ENTONCES muestra la información de la dirección. DADO la dirección seleccionada CUANDO pulso el botón editar ENTONCES habilita los casilleros de avenidas para modificar la dirección. DADO el ingreso avenida principal y secundaria CUANDO pulse el botón de guardar ENTONCES se visualizará la dirección.

Historia de Usuario Número: 10

Usuario: administrador

Nombre historia: Registro de tipo artículos Prioridad en negocio: 30

Riesgo en desarrollo: baja

Puntos estimados: 5

Sprint asignado: 2

Programador responsable: Franklin Pérez y Édison Calle Descripción: COMO administrador QUIERO agregar, editar y eliminar el tipo de artículos PARA agregar a artículos. Escenario de prueba: DADO el menú de Tipo de artículo CUANDO pulso la pestaña de Lista tipo de artículo ENTONCES abrirá la ventana Tipo de artículos DADO el menú de Tipo de artículo CUANDO pulso la pestaña Agregar tipo de artículo ENTONCES se visualizará en la ventana Ingresar de tipo de artículo. DADO el ingreso de los datos de Tipo de artículo CUANDO pulso aceptar ENTONCES se visualizará en la ventana de Tipo de artículo

107

Historia de Usuario Número: 11

Usuario: administrador

Nombre historia: Registro de tipo Artículos Prioridad en negocio: 50

Riesgo en desarrollo: Alta

Puntos estimados: 13

Sprint asignado: 3

Programador responsable: Franklin Pérez y Édison Calle Descripción: COMO administrador operativo QUIERO agregar, editar y eliminar artículos PARA visualizar en el sistema. Escenario de prueba: DADO el menú de Artículo CUANDO pulso la pestaña de Lista artículo ENTONCES abrirá la ventana lista de Artículos DADO el menú de Artículo CUANDO pulso la pestaña Agregar artículo ENTONCES se visualizará en la ventana Ingresar artículo. DADO el ingreso de los datos del artículo CUANDO pulso aceptar ENTONCES se visualizará en la ventana Artículo.

Historia de Usuario Número: 12

Usuario: administrador

Nombre historia: Cantidad de artículos en inventario Prioridad en negocio: 30

Riesgo en desarrollo: medio

Puntos estimados: 5

Sprint asignado: 3

Programador responsable: Franklin Pérez y Édison Calle Descripción: COMO administrador administrativo QUIERO acceder al inventario PARA visualizar lo existente en bodega. Escenario de prueba: DADO el menú de Artículo activos CUANDO pulse la pestaña de Lista artículo activos ENTONCES desplegara la ventana con la cantidad en inventario. DADO el menú Activar artículo CUANDO pulse la pestaña Lista artículos activos ENTONCES mostrara ventana de artículos activos DADO el menú Activar artículo CUANDO pulso la pestaña Activar artículo ENTONCES mostrara ventana Seleccionar artículo para activar. DADO el ingreso a Activar artículo CUANDO pulso el número de código ENTONCES se visualizará la ventana para llenar campos.

108

Historia de Usuario Número: 13

Usuario: administrador

Nombre historia: Ingreso de vehículos Prioridad en negocio: 40

Riesgo en desarrollo: bajo

Puntos estimados: 8

Sprint asignado: 3

Programador responsable: Franklin Pérez y Edison Calle Descripción: COMO administrador QUIERO ingresar vehículos, PARA asignar en las ordenes de mantenimiento. Escenario de prueba: DADO el menú de Vehículo CUANDO pulse la pestaña de Lista vehículo ENTONCES mostrara la ventana de Vehículos de la EPMT-SD. DADO el menú de Vehículo CUANDO pulse la pestaña de Agregar vehículo ENTONCES mostrara la ventana de Ingresar nuevo vehículo. DADO el ingreso de datos del vehículo CUANDO pulse Aceptar ENTONCES mostrara la ventana de Vehículos de la EPMT-SD

Historia de Usuario Número: 14

Usuario: administrador

Nombre historia: Ordenes de manteniendo Prioridad en negocio: 100

Riesgo en desarrollo: alto

Puntos estimados: 21

Sprint asignado: 3

Programador responsable: Franklin Pérez y Édison Calle Descripción: COMO administrador QUIERO generar ordenes de mantenimiento PARA Lista y asignar el trabajo a los empleados. Escenario de prueba: DADO el menú de Orden de mantenimiento CUANDO pulse la pestaña de Lista orden ENTONCES mostrara la ventana de Ordenes de mantenimiento DADO el menú de Orden de mantenimiento CUANDO pulse la pestaña de Nueva orden ENTONCES mostrara la ventana Orden de manteamiento. DADO el ingreso de datos de la Orden de manteniendo CUANDO pulse Aceptar ENTONCES mostrara la ventana de Ordenes de mantenimiento. DADO el menú de Orden de mantenimiento CUANDO pulse la pestaña de Alertas de mantenimiento ENTONCES mostrara la ventana con el calendario de las alertas de mantenimiento. DADO el ingreso a Alertas de manteniendo CUANDO pulse sobre la fecha ENTONCES mostrara la ventana de con la descripción de alerta.

109

Historia de Usuario Usuario: administrador

Número: 15 Nombre historia: Ver estado de orden de manteniendo Prioridad en negocio: 30

Riesgo en desarrollo: bajo

Puntos estimados: 8

Sprint asignado: 3

Programador responsable: Franklin Pérez y Edison Calle. Descripción: COMO administrador QUIERO generar el estado de orden mantenimiento PARA visualizar en la lista de órdenes. Escenario de prueba: DADO el menú de Orden de mantenimiento CUANDO pulse la pestaña Lista orden ENTONCES mostrara las ordenes con sus respectivos estados. DADO el ingreso a Lista orden CUANDO pulso el icono de código ENTONCES abrirá la ventana con el estado “Completo” o “Pendiente”.

Historia de Usuario Número: 16

Usuario: secretaria

Nombre historia: Reportes de órdenes de mantenimiento Prioridad en negocio: 60

Riesgo en desarrollo: bajo

Puntos estimados: 5

Sprint asignado: 3

Programador responsable: Franklin Pérez y Edison Calle. Descripción: COMO secretaria QUIERO generar reportes de la gestión de semáforos PARA tener los respaldos legalizados. Escenario de prueba: DADO el menú de Reporte CUANDO pulse la pestaña Ordenes de mantenimiento ENTONCES mostrara un PDF de las ordenes con sus estados filtrados

110

Anexo 4. Retrospectiva 1. Formulario de Reunión de Sprint Retrospective 1. Información con el nombre de proyecto y reunión: Sistema web para la gestión de semáforos en la EPMT-SD Pontificia Universidad Católica del Ecuador, sede Santo Domingo Nº Sprint o Iteración: 1 Lugar: Mg. Rodolfo Córdova y Sr. Franklin Pérez., Sr Edison Calle Fecha : 1/11/2017 Personas convocadas y que asistieron: ¿Que salió bien en cada iteración? (Aciertos) ¿Que no salió bien en cada iteración? (Errores) ¿Cómo mejorar?(recomendaciones) Interfaz de Login Conexión de la Base de datos con PHP Validación del Login (usuario y contraseña) Codificación de mensajes de alertas en el Login Modelamiento BD de tabla roles de usuario Codificación de roles Validación de roles Creación del formulario "Persona" Interfaz de las pestañas "Lista persona" Interfaz de las pestañas "Agregar persona" Modelamiento BD de tabla “persona” Validación de “Persona” Codificación de mensajes para persona ingresada Codificación del icono eliminar y editar para todas las interfaces Codificación de mensaje de alerta "Eliminar Usuarios" Creación de botón “Estado” en la formulario “Usuario” Codificación del botón con dos estados desplegables Modelamiento de BD para el estado de usuario Validación del “Estado” de usuario Nota: Se recomienda utilizar viñetas para enumerar aciertos o errores. El formulario puede extenderse lo necesario para registrar información.

________________________________ Sr. Franklin Pérez.

________________________________ Sr. Edison Calle

111

Anexo 5. Retrospectiva 2. Formulario de Reunión de Sprint Retrospective 1. Información con el nombre de proyecto y reunión: Sistema web para la gestión de semáforos en la EPMT-SD Pontificia Universidad Católica del Ecuador, sede Santo Domingo Nº Sprint o Iteración: 2 Lugar: Mg. Rodolfo Córdova y Sr. Franklin Pérez., Sr Edison Calle Fecha : 2/11/2017 Personas convocadas y que asistieron: ¿Que salió bien en cada iteración? (Aciertos) ¿Que no salió bien en cada iteración? (Errores) ¿Cómo mejorar?(recomendaciones) Creación del formulario "Usuario" Interfaz de las pestañas "Lista usuario" Interfaz de las pestañas "Agregar usuario" Modelamiento BD de tabla “usuario” Validación de “usuario” Codificación de mensajes ingreso de usuario correctamente Modelamiento BD de tablas para avenidas Creación del formulario "Avenidas" Interfaz de “Lista avenidas” Interfaz de Avenidas principales Interfaz de Avenidas principales Validación de avenidas Modelamiento BD de tabla de nueva dirección Creación del formulario “Dirección” Interfaz "Agregar dirección" e “Lista Direcciones” Validación de direcciones Codificación a nivel de Base de datos para modificar direcciones Codificación en el formulario “Direcciones” Interfaz de "Editar dirección" Codificación de mensaje de modificación Creación del formulario “Tipo de artículo” Modelamiento de BD de tablas para tipo de artículo Interfaz tipo de artículo e interfaz de agregar tipo de artículo Codificación del formulario agregar nuevo tipo de artículo Nota: Se recomienda utilizar viñetas para enumerar aciertos o errores. El formulario puede extenderse lo necesario para registrar información. ________________________________ Sr. Franklin Pérez.

________________________________ Sr. Edison Calle

112

Anexo 6. Carta de entrega recepciรณn.

113

Anexo 7. Manual de usuario. Se adjunta archivo en el CD. Anexo 8. Manual de instalaciรณn. Se adjunta archivo en el CD. Anexo 9. Diccionario de datos. Se adjunta archivo en el CD.

114

Anexo 10. Carta de impacto.