Sistema Web Utilizando Herramientas Open Sourse para el Control y Seguimiento de Proyectos 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 UTILIZANDO HERRAMIENTAS OPEN SOURCE PARA EL CONTROL Y SEGUIMIENTO DE PROYECTOS DE LA EMPRESA PÚBLICA MUNICIPAL DE AGUA POTABLE Y ALCANTARILLADO DE SANTO DOMINGO; PERIODO 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: BYRON GUSTAVO DEMERA VELIZ FRANKLIN GONZALO SAMPEDRO CAYO Director: MG. LUIS JAVIER ULLOA MENESES

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 UTILIZANDO HERRAMIENTAS OPEN SOURCE PARA EL CONTROL Y SEGUIMIENTO DE PROYECTOS DE LA EMPRESA PÚBLICA MUNICIPAL DE AGUA POTABLE Y ALCANTARILLADO DE SANTO DOMINGO; PERIODO 2017 – 2018

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

Autores: BYRON GUSTAVO DEMERA VELIZ FRANKLIN GONZALO SAMPEDRO CAYO

Luis Javier Ulloa Meneses, Mg.

DIRECTOR DE LA DISERTACIÓN DE GRADO

Fausto Orozco, Mg.

CALIFICADOR

José Luis Centeno, 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, Byron Gustavo Demera Veliz portador de la cédula de ciudadanía Nº 0802734004 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.

BYRON GUSTAVO DEMERA VELIZ CI 0802734004

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Franklin Gonzalo Sampedro Cayo portador de la cédula de ciudadanía Nº 1718965401 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 GONZALO SAMPEDRO CAYO CI 1718965401

AGRADECIMIENTO A nuestro padre celestial Dios, por permitirnos buena salud para culminar todas las metas en nuestra formación académica. A la Pontificia Universidad Católica del Ecuador por darnos la oportunidad de formar parte de ella y formarnos en sus aulas. Al Mg. Luis Ulloa nuestro tutor y guía que fue fundamental en el desarrollo del Trabajo de Titulación para que este se lleve a cabo de la mejor manera. A la Empresa Pública Municipal de Agua Potable y Alcantarillado que nos abrió sus puertas para desarrollar nuestro proyecto.

Byron Demera, Franklin Sampedro

DEDICATORIA El presente Trabajo de Titulación dedico a mis padres Gustavo y Narcisa por haberme brindado su apoyo incondicional en todo momento a lo largo de mi formación académica como en la vida misma. A mis hermanos por ese apoyo moral y esos consejos que no me permitieron decaer en ningún momento. A mis maestros por el conocimiento impartido que me permitieron formarme para llevar a cabo con éxito todos los retos académicos y laborales. A mis amigos, quienes fui conociendo en el camino de mi formación por su apoyo brindado cada vez que fue necesario. Byron Demera

A mis padres, hermanos y amigos que fueron el motor para iniciar y terminar esta carrera. A mi hija, para ser de ejemplo que en esta vida todo se puede con esfuerzo, trabajo y sacrificio.

Franklin Sampedro

vii

RESUMEN El presente trabajo de titulación tiene como objetivo principal implementar un sistema web para el control y seguimiento de los proyectos que se realizan en la Empresa Pública Municipal de Agua Potable y Alcantarillado de Santo Domingo de los Tsáchilas (EPMAPASD). El sistema denominado SCO (Sistema de Control de Obras) se ha desarrollado con la finalidad de automatizar los procesos de registro, administración y control de los proyectos (obras) que se realizaban de forma manual, además de facilitar el respaldo de los documentos digitalizados más importantes de un proyecto guardándolos en el servidor de la empresa. El sistema cuenta con tres módulos para su completa administración; cada uno de ellos acorde a los perfiles de usuarios definidos. El proyecto al ser de enfoque mixto se desarrolló bajo estos lineamientos realizando análisis tanto cuantitativo como cualitativo de la información recogida por medio de entrevistas y encuestas. Además, para su gestión se siguieron los lineamientos del marco de trabajo SCRUM dividiendo el flujo de su proceso por sprints; en cuanto al desarrollo de software se empleó el patrón de diseño MVC, se utilizó PHP para la codificación del sistema; como sistema gestor de base de datos se eligió MySQL y para la estructura y presentación de interfaces se utilizó HTML5 y el framework Materialize que contiene CSS3 y Javascript. Palabras clave: automatización, software, metodología.

viii

ABSTRACT The main objective of this titration work is to implement a web system for the control and monitoring of the projects carried out in the Empresa PĂşblica Municipal de Agua Potable y Alcantarillado de Santo Domingo de los TsĂĄchilas (EPMAPA-SD). The system called WCS (Work Control System) has been developed with the purpose of automating the processes of registration, administration and control of the projects (works) that were carried out manually, as well as facilitating the backup of the digitized documents of a project by saving them on the company's server. The system has three modules for its complete administration; each of them according to the defined user profiles. The project being a mixed approach was developed under these guidelines, performing both quantitative and qualitative analysis of the information collected through interviews and surveys. In addition, for its management the guidelines of the SCRUM framework were followed by dividing the flow of its process by sprints; In terms of software development, the MVC design pattern was used, PHP was used for system coding; MySQL was chosen as the database management system and HTML5 was used for the structure and presentation of interfaces and the Materialize framework containing CSS3 and Javascript. Keywords: automation, software, methodology.

ÍNDICE DE CONTENIDOS 1.

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

PLANTEAMIENTO DEL PROBLEMA ......................................................................... 3

2.1

Problema de Investigación ............................................................................................... 3

2.2

Justificación de la Investigación ....................................................................................... 4

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

Revisión de la Literatura o Fundamentos Teóricos .......................................................... 7

3.2

Antecedentes..................................................................................................................... 7

3.2.1 Investigaciones o Experiencias Empíricas Relacionadas con la Investigación. ............... 7 3.3

Ingeniería de Software ...................................................................................................... 9

3.3.1 Definición. ........................................................................................................................ 9 3.3.2 Proceso de Software. ........................................................................................................ 9 3.3.3 Paradigmas de Programación. ........................................................................................ 11 3.4

Base de datos .................................................................................................................. 25

3.4.1 Definición. ...................................................................................................................... 25 3.4.2 Base de datos relacional. ................................................................................................ 25 3.4.3 Modelo de Datos............................................................................................................. 26 3.4.4 Sistemas Gestores de Base de datos. .............................................................................. 27 3.5

Desarrollo de Aplicaciones Web .................................................................................... 29

3.5.1 Aplicaciones Web........................................................................................................... 29 3.5.2 Modelo Vista Controlador (MVC). ................................................................................ 30 3.5.3 Herramientas de desarrollo. ............................................................................................ 31 3.6

Administración de Proyectos .......................................................................................... 33

3.6.1 Proyectos. ....................................................................................................................... 33 4.

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

4.1

Enfoque / Tipo de Investigación..................................................................................... 36

4.1.1 Enfoque de Investigación. .............................................................................................. 36 4.1.2 Tipo de Investigación. .................................................................................................... 36 4.2

Población / Universo ...................................................................................................... 37

4.3

Muestra ........................................................................................................................... 37

4.4

Técnicas e Instrumentos de Recogida de Datos ............................................................. 38

4.4.1 Técnicas. ......................................................................................................................... 38 4.4.2 Instrumentos. .................................................................................................................. 38 4.5

Técnicas de análisis de datos .......................................................................................... 39

4.6

Análisis Metodologías Desarrollo de Software .............................................................. 39

4.6.1 Diferencias métodos Tradicionales vs Ágiles. ............................................................... 39 4.6.2 Comparativa Scrum vs XP. ............................................................................................ 40 4.6.3 Marco de Trabajo Scrum. ............................................................................................... 41 5.

RESULTADOS .............................................................................................................. 43

5.1

Análisis y Discusión de los Resultados .......................................................................... 43

5.1.1 Encuesta al personal del Departamento de Desarrollo de Proyectos de EPMAPA-SD. 43 5.2

Resultados de la Aplicación de Scrum Framework ........................................................ 51

5.2.1 El proceso Scrum............................................................................................................ 51 5.3

Análisis de Impacto. ....................................................................................................... 69

5.3.1 Impacto Tecnológico. ..................................................................................................... 70 5.3.2 Impacto Ambiental. ........................................................................................................ 71 5.3.3 Impacto Social. ............................................................................................................... 71 5.3.4 Impacto Económico. ....................................................................................................... 72 5.3.5 Impacto General. ............................................................................................................ 72 6.

DISCUSIÓN ................................................................................................................... 74

CONCLUSIONES .......................................................................................................... 76

RECOMENDACIONES ................................................................................................ 77

LISTA DE REFERENCIAS........................................................................................... 78

10.

GLOSARIO .................................................................................................................... 83

11.

ANEXOS ........................................................................................................................ 84

ÍNDICE DE TABLAS Tabla 1. Investigaciones previas ................................................................................................ 8 Tabla 2. Comparativa Métodos Tradicionales y Ágiles ........................................................... 39 Tabla 3. Comparativa Scrum vs XP ......................................................................................... 40 Tabla 4. Forma de entrega de información referente a proyectos ............................................ 43 Tabla 5. Conocimiento del progreso de un proyecto ............................................................... 44 Tabla 6. Importancia de la comunicación de los avances de los proyectos ............................. 45 Tabla 7. Conocimiento del supervisor de los proyectos .......................................................... 46 Tabla 8. Importancia de la automatización de la gestión de información. .............................. 47 Tabla 9. Implementación del sistema en la empresa................................................................ 48 Tabla 10. Experiencia con el uso de sistemas informáticos..................................................... 49 Tabla 11. Mejora de la productividad del personal.................................................................. 50 Tabla 12 Información General de la Entrevista ....................................................................... 52 Tabla 13 Product Backlog........................................................................................................ 55 Tabla 14 Sprint Backlog del sprint 1 ....................................................................................... 56 Tabla 15 Sprint Backlog del sprint 2 ....................................................................................... 60 Tabla 16 Sprint Backlog del sprint 3 ....................................................................................... 63 Tabla 17. Sprint Backlog 4 ...................................................................................................... 66 Tabla 18. Escala de los niveles de impactos ............................................................................ 70 Tabla 19. Impactos Tecnológicos. ........................................................................................... 70 Tabla 20. Impacto Ambiental .................................................................................................. 71 Tabla 21. Impacto Social ......................................................................................................... 71 Tabla 22. Impacto Económico ................................................................................................. 72 Tabla 23. Impacto General ....................................................................................................... 72

xii

ÍNDICE DE FIGURAS Figura 1. Esquema de contenidos del Marco Referencial .......................................................... 6 Figura 2. Modelo Cascada. ........................................................................................................ 9 Figura 3. Flujo de proceso – Modelo Incremental. .................................................................. 10 Figura 4. Flujo del proceso evolutivo. ..................................................................................... 11 Figura 5. Proceso MSF. ........................................................................................................... 14 Figura 6. Ubicación del Manifiesto Ágil en el tiempo............................................................. 15 Figura 7. Flujo del proceso XP ................................................................................................ 18 Figura 8. Proceso ICONIX ...................................................................................................... 19 Figura 9. Valores Scrum .......................................................................................................... 21 Figura 10. Roles Scrum............................................................................................................ 22 Figura 11. Proceso Scrum ........................................................................................................ 25 Figura 12. Forma de organización relacional .......................................................................... 26 Figura 13. Diagrama Entidad-Relación simplificado. ............................................................. 26 Figura 14. Representación de un SGBD .................................................................................. 27 Figura 15. Representación del entorno en tres niveles ............................................................ 30 Figura 16. Representación de los elementos del patrón MVC................................................. 31 Figura 17. Correlación de los elementos condicionantes de un proyecto ................................ 34 Figura 18. Forma de entrega de información referente a proyectos ........................................ 43 Figura 19. Conocimiento del progreso de un proyecto ............................................................ 44 Figura 20. Importancia de la comunicación de los avances de los proyectos. ......................... 45 Figura 21. Conocimiento del supervisor de proyectos............................................................. 46 Figura 22. Importancia de la automatización de la gestión de información. ........................... 47 Figura 23. Implementación del sistema en la empresa ............................................................ 48 Figura 24. Experiencias con el uso de sistemas informáticos .................................................. 49 Figura 25. Mejora de la productividad del personal ................................................................ 50 Figura 26. Prototipo interfaz de inicio ..................................................................................... 57 Figura 27. Prototipo del Login de Usuario .............................................................................. 57 Figura 28. Interfaz Principal del sistema ................................................................................. 58 Figura 29. Interfaz principal de administración ....................................................................... 58 Figura 30. Administración de Usuarios ................................................................................... 59 Figura 31. Formulario para ingresar nuevos usuarios. ............................................................. 59 Figura 32. Prototipo de la interfaz de Proyectos ...................................................................... 61 Figura 33. Codificación del apartado Proyectos. ..................................................................... 61 Figura 34. Interfaz formulario de ingreso de Proyectos. ......................................................... 62 Figura 35. Interfaz Estado del Proyecto ................................................................................... 62 Figura 36. Prototipo de interfaz con opciones complementarias ............................................. 64 Figura 37. Codificación del apartado Incrementos. ................................................................. 64 Figura 38. Opciones complementarias..................................................................................... 65 Figura 39. Interfaz formulario de Planillas. ............................................................................. 65 Figura 40. Interfaz formulario de prórrogas. ........................................................................... 65 Figura 41. Prototipo de interfaz con resumen del proyecto ..................................................... 67

xiii

Figura 42. Codificaciรณn del reporte general de proyectos ....................................................... 67 Figura 43. Interfaz de la presentaciรณn resumida de informaciรณn del proyecto ........................ 68 Figura 44. Reporte general de proyectos ................................................................................. 68 Figura 45. Reporte individual por proyecto ............................................................................. 69

xiv

ร NDICE DE ANEXOS Anexo 1. Carta de solicitud de informaciรณn. .......................................................................... 84 Anexo 2. Acta Entrega-Recepciรณn........................................................................................... 85 Anexo 3. Carta de Impacto. ..................................................................................................... 86 Anexo 4. Entrevista realizada al Sub-Gerente de Desarrollo de Infraestructura de EPMAPASD. ........................................................................................................................................... 87 Anexo 5. Encuesta realizada al personal de EPMAPA-SD. .................................................... 90 Anexo 6. Cronograma. ............................................................................................................. 92 Anexo 7. Presupuesto............................................................................................................... 93 Anexo 8. Modelo Lรณgico Base de Datos. ................................................................................ 94 Anexo 9. Historias de Usuario. ................................................................................................ 95

1. INTRODUCCIÓN En ambientes donde se presenta la recolección de datos y almacenamiento para cualquier tipo de trabajo, proyecto, obra o situación en general, obliga a la organización y gestión de la misma por medio de sistemas computacionales, ya que de la forma habitual como la que se maneja presenta inconvenientes al momento de revisar algún requerimiento e implica innecesario gasto ya sea de tipo económico o de tiempo. El Sistema web de control y seguimiento de proyectos de EPMAPA-SD nos brinda información necesaria y oportuna para el departamento de Subgerencia de Desarrollo de Infraestructura, con esto automatiza el registro de nuevos proyectos, el control y seguimiento de los mismos. En el desarrollo del presente trabajo de titulación se ha tomado en cuenta fuentes bibliográficas que sustentan todo lo mencionado en este documento. La “Pontificia Universidad Católica del Ecuador sede Santo Domingo” es un fuerte y muy importante pilar para esta investigación, ya que consta con una muy enriquecida y extensa biblioteca donde se ha recopilado información necesaria y concisa para anotar lo más relevante de esta investigación. El desarrollo de este trabajo se ha realizado de una manera ordenada para que el lector entienda en primera instancia todo lo que se va a tratar en este apartado. En la primera sección se relata una introducción breve previa al desarrollo de los siguientes puntos. En la segunda sección se presenta el Planteamiento del problema, en la cual estarán expuestos los antecedentes, problemática y justificación de la investigación. Se culmina este apartado exponiendo los objetivos de la investigación. En la tercera sección contamos con el marco referencial, donde precisamos todo lo entendido en temáticas necesarias para este trabajo como son: ingeniería de software, bases de datos, herramientas y aplicaciones web. En la cuarta sección exponemos las metodologías de investigación, donde se expondrá sobre el diseño, población, muestra, instrumentos y técnicas de análisis de datos y elección de metodologías de desarrollo de software.

En la quinta secciรณn finalizamos con el anรกlisis de los datos, para que con los resultados obtenidos redactar las conclusiones y recomendaciones satisfactorias de esta investigaciรณn.

2. PLANTEAMIENTO DEL PROBLEMA 2.1 Problema de Investigación La Empresa Pública Municipal de Agua Potable y Alcantarillado de Santo Domingo (EPMAPA-SD), es una empresa que desarrolla proyectos de construcción de alcantarillado y agua potable en la ciudad de una forma eficiente, pero al llevar el control de la información y documentos que genera cada proyecto desde su inicio a su fin tiene inconvenientes. El proceso que reiteradamente realizan al archivar la información en CD’s y revisarla cuando se requiera, se vuelve día a día muy pesado ya que como proyecto se debe inspeccionarlo fase a fase para que culmine de manera efectiva. Esta información al tenerla de manera rápida y precisa, es decir automatizada va a agilitar procesos posteriores, de esta forma contribuye a una mejor organización y optimización del tiempo y demás recursos de la empresa pública. El actual proyecto de investigación responderá a la siguiente problemática: ¿Cómo mejorar el control y seguimiento de los proyectos de EPMAPA-SD? Dicho esto, la presente investigación responderá a las siguientes preguntas directrices: 

¿Cuáles son los procesos que se realizan actualmente para el control y seguimientos de los proyectos?



¿Qué metodología de desarrollo de software es conveniente para la realización del sistema web?



¿Cuáles son las herramientas y recursos para el desarrollo del sistema web, que tenemos a disposición?

2.2 Justificación de la Investigación En la actualidad, en las empresas públicas como en las privadas existen proyectos a toda escala tanto así que se genera información desmedida pero muy importante para cada uno de los mismos; viéndose necesario trasladarse esta información a una forma más organizada y de fácil acceso para las personas involucradas con la misma. El control y seguimiento de un proyecto es muy importante, ya que dependen de muchos factores como: tiempo, presupuesto, materiales, diseños, personas encargadas de diferentes etapas, etcétera. Por tal motivo es de mayor importancia para estos sectores empresariales contar con un sistema de control y seguimiento de proyectos. La EPMAPA-SD sostiene que es muy importante tener la información de estos proyectos a la mano, de forma rápida y precisa, de esta forma mitigan el exhaustivo trabajo de revisar los archivos de manera rutinaria en la cual se pierde tiempo y se ocupan recursos innecesarios. Hay que tener consideración de que con un sistema de control y seguimiento de proyectos se va a generar una armonía entre las personas que organizan la información de los proyectos y las que necesitan la misma para auditar cada una de las fases que conlleva un proyecto y así aumentar la eficiencia de los procesos que requieren estos datos. En lo que respecta a la factibilidad, de la recopilación de información para entender los procesos que se generan en los proyectos, se ha dado de una forma estable con las personas involucradas en la empresa pública, con esto el curso de esta investigación se desarrolla con normalidad y en los tiempos especificados. Las herramientas para el desarrollo de la estructura tecnológicamente hablando están al alcance de las manos de los desarrolladores ya que se trabaja en herramientas OPEN SOURCE y no surgió ningún inconveniente para su adquisición y posterior uso. Este tema de investigación está relacionado con el objetivo 11 del Plan Nacional del Buen Vivir el cual establece: Asegurar la soberanía y eficiencia de los sectores estratégicos para la transformación industrial y tecnológica. 11.3 “l. Fortalecer la seguridad integral usando las TIC” (Secretaría Nacional de Planificación y Desarrollo [SEMPLADES], 2013, p. 324).

2.3 Objetivos de Investigación 2.3.1 Objetivo General. Implementar un sistema web para el control y seguimiento de proyectos de la Empresa Pública Municipal de Agua Potable y Alcantarillado de Santo Domingo, periodo 2017 - 2018. 2.3.2 Objetivos Específicos. 

Definir los procesos necesarios que llevan el control y seguimiento de los proyectos.



Comparar las metodologías de desarrollo de software adecuada para el proyecto.



Seleccionar las herramientas y los recursos open source convenientes para el desarrollo del sistema web.



Desarrollar el sistema web considerando las funcionalidades establecidas por el departamento de desarrollo de infraestructura de EPMAPA-SD.

3. MARCO REFERENCIAL El contenido del marco referencial (Figura 1) se ha esquematizado de la siguiente manera. Definición

Modelo Cascada

Proceso de Software

Modelo Incremental Modelo Evolutivo Definición Definición

Ingenieria de Software

Paradigmas de programación

Programación Estructurada Características

Programación Orientada a Objetos

Definición Características de la POO

Definición

Desarrollo Tradicional

MSF

Metodología de desarrollo de software

CCMI Introducción

Definicion XP Base de Datos Relacional

Esquema de contenidos

Modelo de Datos

Desarrollo Ágil ICONIX Modelo Entidad Relacion

Base de datos

Scrum

Definición Sistemas Gestores de Base de datos

Funciones de un SGBD

MySQL

Normalización

Ejemplos de SGBD

SQL Server Oracle Cliente/Servidor

Aplicaciones Web

Desarrollo de Aplicaciones Web

Modelo Vista Controlador (MVC) Herramientas de Desarrollo

Arquitectura Aplicaciones Web

Arquitectura en Tres Capas

Servidor Web

Apache

Lenguaje de Scripting

PHP MaterializeCSS

Diseño de interfaces web HTML5 y CSS3 Definición Administración de Proyectos

Proyectos

Características de los proyectos

Fases de un proyecto

Figura 1. Esquema de contenidos del Marco Referencial.

3.1 Revisión de la Literatura o Fundamentos Teóricos 3.2 Antecedentes La presente investigación se ha realizado en la EPMAPA-SD, la cual provee a los ciudadanos servicios de calidad de agua potable y alcantarillado, fomentando una cultura de uso apropiado de los recursos y la preservación del medio ambiente. EPMAPA-SD fue creada mediante ordenanza publicada en el registro oficial N. -126 del 14 de febrero de 1985 en la administración del extinto alcalde Darío Kanyat Cortez, creada como entidad de autonomía financiera y administrativa, entro a funcionar en 1986. El primer gerente fue Marco Hermes de la Cruz Bastidas. La situación presente de control y seguimiento de proyectos de esta empresa pública es de manera obsoleta ya que se registra toda la información de cada proyecto en CD’s, los mismos que son archivados en armarios de oficina donde tras su etiquetación y membrete son identificados para luego ordenarlos en función del tiempo de inicio de cada proyecto. El problema se presenta cuando el personal que necesite los requerimientos que conforman los proyectos incurre en reproducir el mismo material para revisar información que necesitan de forma inmediata para su control o seguimiento. Aprovechando el uso de internet en toda su infraestructura tecnológica se puede acceder a la comunicación de forma inmediata entre todos los departamentos de desarrollo de proyectos y así reducir las causas del inconveniente al guardar la información en medios digitales, con esto tendríamos superado factores críticos como el tiempo y el personal utilizado. 3.2.1 Investigaciones o Experiencias Empíricas Relacionadas con la Investigación. En el presente apartado se pretende realizar una pequeña revisión literaria de las investigaciones que se han realizado previo a la presente (Tabla 1), con la finalidad de que estas sirvan de guía y a su vez brindar credibilidad al presente documento.

8 Tabla 1. Investigaciones previas

Autor/res

Título de la Investigación

Quishpe Pila, Jorge Paul

Automatización del seguimiento de proyectos y contratos realizados en el Instituto Superior de Investigaciones (ISI), en la Facultad de Ingeniería en Geología, Minas, Petróleos y Ambiental.

Alejandro Ventura, Cecilia Sandra

Yépez Chicaiza, Jhonny Leiser

Paladines Morales, Diana Carolina Pantoja Sánchez Jefferson Fernando

Camacho Zapata, Jeremy Renato Palma Rivera, Alex Darío

Implementación de un sistema de información, control y seguimiento de obras civiles para el departamento de obras públicas del gobierno autónomo descentralizado municipal del Cantón La Libertad Sistema de planificación, seguimiento y control de proyectos académicos y su vinculación con el sector productivo para la Unidad de Educación Continua de la Facultad de Ciencias Administrativas. Desarrollo e implementación de un sistema de gestión de proyectos para el departamento de sistemas del CONCLISAN CIA. LTDA. en la provincia de Santo Domingo de los Tsáchilas Desarrollo e implementación de una aplicación para la gestión de la información del Centro de Faenamiento Municipal del Cantón Pedro Vicente Maldonado GADMCPVM para el Departamento de Gestión y Desarrollo Sustentable durante el periodo 20152016

Nota: Datos obtenidos de la investigación documental.

Centro de Educación Superior Universidad Central del Ecuador

Año: 2013

Universidad Estatal Península de Santa Elena

Año: 2015 Universidad Central del Ecuador

Año: 2015

Pontificia Universidad Católica del Ecuador

Año: 2016

Pontificia Universidad Católica del Ecuador

Año 2016

Descripción El Trabajo de Graduación consiste en la creación de un sistema informático web para automatizar los procesos (que son llevados manualmente en el ISI-FIGEMPA) referente a los proyectos y contratos como son el registro, seguimiento, control de recursos y administración de los mismo, empleando tecnología actualizada La Tesis de Grado comprende en automatizar los procesos de administración de la información en referido departamento, dado que este carecía de un sistema informático que les facilite acceso y brinde información de forma ágil y rápida de las obras civiles que se realizaban. El Trabajo de Graduación tiene como fin último el permitir registrar, controlar y dar seguimiento a los proyectos académicos (que se los administraba de forma manual) generados en la Unidad de Educación Continua de la FCA, brindando información rápida y oportuna para la toma de decisiones El Trabajo de Titulación comprende el desarrollo de un sistema web utilizando herramientas open-source para CONCLISAN que permita automatizar los procesos referidos al control y seguimiento de los proyectos realizados en el departamento de sistemas, optimizando recursos y tiempo El Trabajo de Titulación tiene como finalidad permitir la gestión y administración de la información que generaba el Centro de Faenamiento del Departamento de Gestión y Desarrollo Sustentable del GAD Municipal de Pedro Vicente Maldonado. Con la aplicación del sistema se resuelve la problemática de llevar de forma manual toda su información del departamento y demás procesos derivados de dicha información.

3.3 Ingeniería de Software 3.3.1 Definición. La Ingeniería de Software es una rama de la Ingeniería que involucra varios aspectos referentes al desarrollo y mantenimiento de un software. No solo la elaboración del producto es importante sino también conocer cómo se lo ha realizado. Al ser una ingeniería, utiliza enfoques semejantes, como por ejemplo: el sistemático, disciplinado y cuantificable, que son empleados en el desarrollo de sus artefactos, con ello se asegura que el producto cumpla con los requerimientos, sea sostenible y confiable (Braude & Bernstein, 2016, p. 2). 3.3.2 Proceso de Software. 3.3.2.1. Modelo cascada. Es el más conocido y el más antiguo en lo que respecta al ciclo de vida del software (Figura 2). Es usado ampliamente en empresas gubernamentales y en grandes compañías. Lo característico de este modelo es el flujo secuencial (lineal) de su proceso y en un solo sentido, es decir, no se inicia una nueva etapa del proceso mientras no se haya finalizado completamente la anterior. Además, este modelo posee una amplia y extensa planificación y documentación. Los pasos o etapas que componen el modelo cascada son: Análisis de Requerimientos, Diseño, Codificación, Pruebas y Mantenimiento (Alshamrani & Bahattab, 2015, pp. 106-107).

Figura 2. Modelo Cascada. Adaptado de Morien, R., 2014. Back to Basics: In Support of Agile Development. En I. Ghani, W. Nasir Wan Kadir, & M. Nazir Ahmad (Edits.), Handbook of Research on Emerging Advancements and Technologies in Software Engineering, pp. 279292. Recuperado de https://ebookcentral.proquest.com

3.3.2.2. Modelo incremental. Llega como una alternativa y solución a las limitaciones que posee el Modelo Cascada, dado que el usuario no siempre especifica adecuadamente los requerimientos en las primeras etapas y una comunicación fluida con el cliente siempre es buena en el hecho de que se reciben comentarios con frecuencia para mejorar el producto. Lo particular de este modelo es su forma de trabajo puesto que el software se desarrolla y entrega por incrementos (fases) continuos (Figura 3). Se mantienen las etapas del modelo cascada con la diferencia de que éstas se repiten cuantas veces se realicen incrementos (Cusick, 2013, pp. 41-42)

Figura 3. Flujo de proceso – Modelo Incremental. Adaptado de “Durable Ideas in Software Engineering: Concepts, Methods and Approaches from My Virtual Toolbox” por Cusick, J., 2013. Recuperado de https://ebookcentral.proquest.com

3.3.2.3. Modelo evolutivo. El software evoluciona con el tiempo. El Modelo Evolutivo llega para adaptarse a los cambios o evoluciones que sufre un producto con el paso del tiempo. Este modelo es iterativo y se desarrollan versionen más completas del producto (Figura 4). Otra característica a destacar de este modelo es la elaboración de prototipos del software a manera del primer sistema, esto se realiza con la finalidad de poder identificar y comprender de mejor manera los requerimientos (Pressman, 2010, pp. 36-38)

Figura 4. Flujo del proceso evolutivo. Adaptado de “Ingeniería del Software: Un enfoque práctico” por Pressman, R., 2010, McGraw-Hill.

3.3.3 Paradigmas de Programación. 3.3.3.1. Definición. Un paradigma de programación describe la forma en como representa la realidad el desarrollador a través de código fuente en la construcción de software. En otras palabras, se relaciona con el modelo, forma o estilo de programación. En la actualidad existen varios paradigmas, cada uno diferente de otro, con sus ventajas y desventajas particulares, entre los que destacan el paradigma estructurado y el orientado a objetos. 3.3.3.2. Paradigma estructurado. 3.3.3.2.1 Definición. También conocida como programación imperativa, es considerado como el primer paradigma formal dado que se basa en la tecnología de la máquina de Von Newman, y después de más de 70 años aún sigue vigente. Siendo estructurado, se basa en tres estructuras de control como son las secuenciales, las condicionales y las iterativas (ciclos). Este paradigma dio paso a nuevas formas de programación que lo mejoraron notablemente (Trejos, 2013, p. 144) 3.3.3.2.2 Características. A continuación se describen las características más relevantes del paradigma estructurado: 

Variables: representan un estado del programa y su valor que es asignado en memoria puede cambiar durante la ejecución del programa.



Tipos de Datos: describen al grupo de valores junto con las relaciones y operaciones que estos poseen.



Expresiones: relacionado con una sentencia de asignación para cambiar el valor de una variable y a su vez el estado de un programa.



Estructuras de control: para seleccionar una opción e iterar sentencias. (Perez, 2015, p. 10)

3.3.3.3. Programación orientada a objetos. 3.3.3.3.1 Definición. La programación orientada a objetos (POO) es una nueva forma totalmente diferente a los clásicos enfoques de programar. En él, el principio básico es el objeto y su comportamiento (métodos). A diferencia de los paradigmas clásicos, la programación orientada a objetos emplea nuevas técnicas como herencia, polimorfismo, etc., consiguiendo una mejor resolución de los problemas, además de aportar con más modularidad y reutilización de código (Moreno, 2014, p. 38) 3.3.3.3.2 Características. De acuerdo con Pérez (2015) las características más destacadas son las siguientes: 

Objeto: considerados entidades, está asociado a la forma de representar la realidad, pueden ser tangibles o intangibles y poseen un lugar y espacio.



Clase: contiene o está formado por objetos con las mismas características, es decir, aporta con los datos (atributos) y métodos de los objetos.



Abstracción: es el procedimiento por el cual el programador modela la realidad en forma computacional, en ese caso identificando las características, objetos y clases que formarán parte del programa o sistema a desarrollar.



Encapsulamiento: encubrimiento de la parte interna de una clase, el usuario no necesariamente necesita conocer como ésta implementa los métodos de los objetos.



Modularidad: consiste en el principio de dividir un programa en pequeñas partes o “módulos” para trabajar y entenderlo de mejor manera



Jerarquización: es la forma en cómo se estructuran las clases, es decir agrupar por jerarquía clases mayores (superclases) y menores (subclases). Este término se relaciona con Herencia.



Concurrencia/Persistencia: varios objetos actúan en el mismo instante y perdurar en el tiempo (pp. 7-9).

3.3.3.4. Metodología de desarrollo de software. 3.3.3.4.1 Definición. Una metodología de desarrollo de software es aquella que engloba procedimientos, técnicas, herramientas, entre otros aspectos involucrados en el proceso de elaborar e implementar software. Éstas poseen fases y sub-fases, basándose en una filosofía en particular permitiendo diferenciar una de otra (Amaya, 2013, p. 112). Existen varios grupos de metodologías de desarrollo de software, entre los cuales se destacan las metodologías tradicionales (también conocidas como métodos pesados) y las metodologías ágiles. 3.3.3.4.2 Desarrollo tradicional. 3.3.3.4.2.1 Definición. Las metodologías tradicionales, son aquellas que se caracterizan por ser disciplinadas, seguir un proceso riguroso, secuencial e invariable, usadas frecuentemente en proyectos muy grandes (Amaya, 2013, p. 31). Este tipo de metodologías no se adaptan a los cambios, ponen un especial énfasis en la especificación completa de requerimientos, una planificación total del trabajo, definición de roles, artefactos y exhaustiva documentación (Brito, Sosa, & Héctor, 2015, pp. 29-30). 3.3.3.4.2.2 MSF. Microsoft Solutions Framework (MSF) se creó a partir del trabajo conjunto de varios grupos de negocio del gigante informático Microsoft y Microsoft Consulting Services. Es una metodología que provee modelos, técnicas, entre otros aspectos que facilitan el desarrollo de proyectos multiplataforma. Está enfocada en los modelos del proceso y del equipo que

controlan la planificación, desarrollo y gestión del proyecto (Figura 5). MSF es flexible, adaptable, escalable y se puede usar con cualquier tecnología. Las etapas de MSF se resumen en: Visión, Planificación, Desarrollo, Estabilización e Implantación (Brito, Sosa, & Héctor, 2015, p. 13).

Figura 5. Proceso MSF. Adaptado de “Microsoft Solutions Framework (MSF) Overview” por Microsoft, 2017. Recuperado de https://msdn.microsoft.com/enus/library/jj161047(v=vs.120).aspx

3.3.3.4.2.3 CMMI. La Integración de Modelos de Madurez y Capacidades (CMMI por sus siglas en inglés) fue desarrollado por el Software Engineering Institute (SEI) y nace como necesidad para dar solución a la combinación de varios CMMs. En la actualidad se encuentra en la versión 1.3 y cubre 3 áreas o “constelaciones” de interés: Adquisición, Desarrollo y Servicios. CMMI para el Desarrollo (CMMI for Development) abarca las actividades involucradas en la elaboración de servicios o productos, e integra varias disciplinas o prácticas tales como la gestión del proceso, del proyecto, ingeniería de software, de hardware y de sistemas. (Software Engineering Institute, 2010, pp. 10-18) 3.3.3.4.3 Desarrollo ágil. 3.3.3.4.3.1 Introducción. El desarrollo Ágil (Agile) se caracteriza por llevar un flujo de proceso iterativo (iteraciones cortas que pueden durar 2 a 4 semanas) en lo que respecta al ciclo de vida del desarrollo de software. Se diferencia del desarrollo tradicional dado que ofrece funcionalidad

a través de pequeñas entregas -denominados incrementos- en periodos de tiempo más cortos (Davis, 2013, pág. 201). Todo lo que respecta a la concepción, desarrollo, principios y valores Agile se encuentra plasmado en el Manifiesto Ágil (Agile Manifesto). 3.3.3.4.3.1.1 Manifiesto ágil. Todo gira en torno al año 2001 cuando un grupo de 17 expertos desarrolladores de software se reúnen en Snowbird, Utah, con la finalidad de intercambiar conocimientos y enfoques de desarrollo de software que en aquel entonces era muy diverso. El consenso al que llegaron estos profesionales se ve reflejado en el Manifiesto Ágil (Figura 6) en donde se expresa las bases, principios y valores que fundamentan el desarrollo ágil (Agile Alliance, 2017). De acuerdo con el Manifiesto Ágil se valoran: 

Individuos e iteraciones sobre los procesos y herramientas



Software funcional sobre documentación completa



Colaboración con el cliente sobre la negociación de un contrato fijo



Respuesta al cambio sobre el seguimiento de un plan.

Figura 6. Ubicación del Manifiesto Ágil en el tiempo. Adaptado de “Developing Information Systems: Practical guidance for IT professionals” por Girvan, L., T. Ahmed, J. Cox, & J. Cadle, 2014, pp. 8-34. Recuperado de https://ebookcentral.proquest.com

3.3.3.4.3.1.2 Técnicas del desarrollo ágil. Está claro que el Manifiesto Ágil expresa los principios y valores primordiales que alinean al resto de métodos agiles a cumplir su filosofía, pero en cuento a los conceptos claves referentes al desarrollo ágil, existen algunas técnicas que son comunes entre metodologías ágiles. A continuación se describen las más destacadas:



Comunicación: se emplea una frecuente y continua comunicación con el cliente para dar seguimiento al proyecto. El cliente examina y provee sugerencias.



Desarrollo Iterativo/Incremental: el proyecto se ejecuta en periodos de tiempo cortos (Iteraciones) y se realizan pequeñas entregas (Incrementos) del producto.



Enfoque en la calidad: se asegura la calidad del código aplicando varias técnicas entre ellas pruebas unitarias y de integración (Stephens, 2015, pp. 313-316).



Historias de Usuario: forma por la cual se divide el trabajo del equipo, y que contribuye al valor del producto en general



Equipo y Reuniones Diarias: el equipo es un grupo pequeño de personas que combinan esfuerzos para el logro del proyecto. Las reuniones diarias se realizan con el objetivo de informar del avance de las actividades del proyecto. (Agile Alliance, 2017)

3.3.3.4.3.2 Extreme programming. 3.3.3.4.3.2.1 Descripción. En su momento, Extreme Programming (XP) fue el más conocido e importante método ágil, pero más que una metodología, se lo considera como la colección de varias prácticas ágiles que trabajan en conjunto. Dado su forma de trabajo (enfocado en el proceso de desarrollo) XP no proporciona un marco de gestión que indique cómo debe administrarse un proyecto ágil, como si lo hace Scrum. En ocasiones suele combinarse XP con Scrum para complementar dicha carencia (Cobb, 2015, pp. 77-78). 3.3.3.4.3.2.2 Valores XP. XP siendo un método ágil posee un grupo de cinco valores que sostienen sus prácticas y funcionamiento en general. Estos valores de acuerdo con Stephens (2015) son los siguientes: 

Comunicación: el cliente comunica al equipo de desarrollo los requerimientos del sistema, de esta forma todos poseen una visión y objetivos en común.



Simplicidad: se promueve los diseños simples de la aplicación (solución) y sólo si es necesario se agregan más características más adelante.



Re-alimentación: el cliente provee feedback por medio de revisiones periódicas de la dirección y funcionalidad de la aplicación.



Coraje: valentía para afrontar varios sucesos o eventos como refactorizar código, diseñar soluciones simples, proveer feedback, entre otros.



Respeto: hace referencia al respecto con uno mismo y hacia los demás miembros del equipo, respetando sus sugerencias y comentarios (p. 319).

3.3.3.4.3.2.3 Prácticas XP. XP fue un método ágil que se popularizó rápidamente entre los desarrolladores dado que muchos de los principios y prácticas que lo conformaban fueron llevados o puestos en marcha a un nivel extremo (Babar, Brown, & Mistrik, 2013, pp. 13-14). Algunas de las prácticas más importantes de esta metodología son las siguientes: 

Juego de Planeación.



Pequeñas Entregas.



Diseño simple.



Programación en parejas.



Integración continua.



Cliente en el sitio.

3.3.3.4.3.2.4 Roles XP. En XP el trabajo se realiza en Equipo. Dentro de este grupo de personas se encuentran definidos los roles y responsabilidades que cada miembro desempeña. A continuación se presentan los principales roles de XP: 

Cliente: define los requerimientos de usuario y proveer del feedback necesario para que el desarrollo mantenga su rumbo.



Tracker: encargado de monitorear el progreso de los miembros del equipo.



Programador: determina la arquitectura del sistema y escribe su código.



Coach: ayuda a que el equipo se auto-organice y trabaje de forma adecuada.



Tester: apoya al cliente en la elaboración y ejecución de las pruebas de aceptación, además informa si no se ha cumplido algún requisito.



Administrador: encargado de la configuración y mantenimiento de toda la parte técnica (ordenadores, redes, etc.) que emplean los miembros del equipo (Stephens, 2015, p. 318)

3.3.3.4.3.2.5 Proceso XP. Es iterativo donde cada una de sus etapas se repite con cada nuevo inicio de ciclo. Empezando por la Planeación donde se recolectan Historias de Usuario y se crea el Plan de Entregas y de Iteración, pasando por el Diseño, luego por la Codificación aplicando programación en parejas e integración continua del sistema, para finalizar en las Pruebas. A continuación se presenta un diagrama de flujo (Figura 7) según Wells (2000) del proceso XP:

Figura 7. Flujo del proceso XP. Adaptado de “The Rules of Extreme Programming” por Wells, D., 2000. Recuperado de http://www.extremeprogramming.org/rules.html

3.3.3.4.3.3 ICONIX. 3.3.3.4.3.3.1 Descripción. Iconix fue descrito por Doug Rosenberg y Kendall Scott. Es un caso especial dentro del desarrollo tradicional, dado que su proceso de desarrollo se encuentra entre RUP (que es complejo) y XP (que es simple) sin llegar a parecerse a éste último. Iconix a diferencia de los métodos tradicionales, se diferencia en sus etapas dado que se realizan de una forma menos compleja y simplificada (Amavizca , García, Jiménez, Duarte , & Vázquez , 2014, p. 3)

3.3.3.4.3.3.2 Etapas ICONIX. Las etapas que conforman el proceso Iconix son: Análisis de Requerimientos, AnálisisDiseño previo, Diseño e Implementación. Entre las características más relevantes de Iconix destaca su flujo de proceso iterativo/incremental, trazabilidad (seguimiento) entre los artefactos producidos y el soporte de UML (Figura 8) (dinámica de los casos de uso, etc.) (Amavizca , García, Jiménez, Duarte , & Vázquez , 2014, p. 3)

Figura 8. Proceso ICONIX. Adaptado de “Aplicación de la metodología semiágil ICONIX para el desarrollo de software: implementación y publicación de un sitio WEB para una empresa SPIN-OFF en el Sur de Sonora, México” por Amavizca, L., García, A., Jiménez, E., Duarte, G., & Vázquez, J., 2014, Twelfth LACCEI Latin American and Caribbean Conference for Engineering and Technology, p. 10. Recuperado de http://www.laccei.org/LACCEI2014Guayaquil/RefereedPapers/RP246.pdf

3.3.3.4.3.4 Scrum. 3.3.3.4.3.4.1 Descripción. Es un enfoque ágil mayormente conocido y empleado en la actualidad. Además, introduce conceptos propios que gestiona cómo el trabajo es planificado y llevado a cabo por un pequeño pero multidisciplinario equipo (Girvan, 2014, p. 30). El marco de Scrum (Scrum Framework) ofrece una conjunto de roles, valores, artefactos, actividades que está centrado en las personas, posee un enfoque holístico y se puede adaptar a cualquier entorno de trabajo, sea este de TI o no. Scrum se anuncia oficialmente en el año 1995 por parte de sus creadores Jeﬀ Sutherland y Ken Schwaber (Levy, Short, & Measey, 2015, p. 132)

Permite administrar proyectos de desarrollo de software con enfoques incremental e iterativo proporcionando técnicas sencillas, como la inspección y adaptación, en lugar de otras más específicas. Las entregas del producto se realizan a través de sprints (iteraciones) que pueden durar entre 2 a 4 semanas. (Babar, Brown, & Mistrik, 2013, p. 12). Scrum permite la entrega de software por iteraciones, prioriza en cada sprint las características de mayor valor en el negocio y permite la interacción con los usuarios comerciales que validan la usabilidad, calidad e importancia del software (Cooke, 2012, pp. 44-45). 3.3.3.4.3.4.2 Principios Scrum. Scrum se basa en la teoría del empirismo, y esta a su vez tiene tres pilares fundamentales que se describen a continuación: 

Transparencia: todas las partes esenciales del proceso son visibles para los responsables del resultado, todos comparten un lenguaje común.



Inspección: se inspecciona con frecuencia los artefactos y el progreso del proyecto para identificar posibles variaciones arriesgadas.



Adaptación: capacidad de realizar ajustes a procesos desviados con el objetivo de minimizar desvíos mayores (Schwaber & Sutherland, 2017, p. 5).

3.3.3.4.3.4.3 Valores Scrum. Todos los miembros participantes del equipo Scrum incorporan y comparten un conjunto de valores que los ayudan a desarrollar un trabajo colaborativo y multifuncional. Mientras todos pongan en vivencia cada uno de los valores y actúen a partir de ellos el equipo se unifica, se reducen los conflictos y existen bases sólidas para orientar el equipo. Los valores (Figura 9) se resumen en Compromiso, Enfoque, Apertura, Respecto y Coraje (Cobb, 2015, pp. 51-54). 

Compromiso y Enfoque: compromiso para hacer todo lo necesario por cumplir un objetivo y enfoque para concentrarse y hacer lo comprometido sin distracciones.



Apertura: es un valor muy importante en las personas y que evidencia el grado de madurez que poseen para desarrollar equipos colaborativos y de alto desempeño.



Respeto: otro valor importante de Scrum. Es común que en equipos de alto rendimiento existan diferentes puntos de vista, el respeto se enfoca en ello, en escuchar las distintas opiniones y llegar a un acuerdo mutuo.



Coraje: por último, se requiere valentía para poder aplicar Scrum (que es desafiante), para superar barreras personales y para encarar la realidad de forma abierta e integra.

Figura 9. Valores Scrum. Adpatado de “What is Scrum?” por Scrum, 2017. Recuperado de https://www.scrum.org/resources/what-is-scrum

3.3.3.4.3.4.4 Roles Scrum. El Equipo Scrum (Figura 10) posee tres roles bien definidos. En base a Stephens (2015) se realiza la descripcion de los mismos: 

Product Owner: es el encargado de representar a los stakeholders, usuarios entre otros. Es el responsable de escribir las Historias de Usuario, priorizarlas y especificar los objetivos del proyecto. Es el único que puede cancelar una iteración si es necesario. También sirve como nexo entre los stakeholders y el equipo de desarrollo. Algunos de sus deberes son: -

Definir requerimientos, además comprobar que el producto los cumpla.

Priorizar los requerimientos y apoyar en la selección de requerimientos a implementar en la siguiente iteración.

Se encarga de la planificación y de los lanzamientos.

Mantener informado de los avances del proyecto a los stakeholders.



Team Member (Equipo de Desarrollo): son las personas que pertenecen al equipo multidisciplinario y auto-organizado que durante cada iteración llevan a cabo las tareas relacionadas con las actividades para desarrollar software (análisis, diseño, codificar, documentas, entre otras)



Scrum Master: es el encargado de facilitar el trabajo en el equipo librándolo de posibles barreras. Busca que el equipo aplique las buenas prácticas, lo incita a mejorar y ocasionalmente lidera las reuniones. No hay que confundirlo con un “Administrador de Proyectos” dado que el equipo se auto organiza (pp. 327-328).

Figura 10. Roles Scrum. Adaptado de “Scrum Roles Demystified” por Scrum Alliance, 2016. Recuperado de https://www.scrumalliance.org/agile-resources/scrum-rolesdemystified

3.3.3.4.3.4.5 Eventos Scrum. El evento y parte fundamental de Scrum es el Sprint, éste a su vez es un contenedor de los demás eventos que suceden durante la ejecución del mismo. Un sprint tiene una duración máxima (fija) que puede ser de un mes o menos y no puede modificarse durante su ejecución. Como resultado del sprint se crea un “incremento” del producto con mucho potencial de lanzamiento. Cada sprint empieza de forma inmediata luego de que otro haya finalizado (Schwaber & Sutherland, 2017, p. 9). A continuación se realiza una breve descripción de los eventos restantes de acuerdo a Schwaber & Sutherland (2017):



Planificacion del Sprint: se crea un plan con la colaboracion de todo el Equipo Scrum donde se especifica el trabajo a realizar durante determinado sprint. Si el sprint es corto, este evento no toma mucho tiempo. El Scrum Master es el encargado de velar por el cumplimiento de este evento en el tiempo estimado.



Objetivo del Sprint: en esta parte se establece la meta que se debe cumplir en el sprint. Ayuda a que el equipo de desarrollo sepa por qué se construye dicho incremento y brinda cierta flexibilidad respecto a la funcionalidad del mismo



Scrum Diario: es una reunion diaria que realiza el Equipo de Desarrollo y toma alrederor de quince minutos, donde se planifica lo que se realizará en el dia, mejorando la comunicación, colaboracion y seguimiento de los progresos



Revisión del Sprint: se realiza al finalizar el sprint. Es una reunion informal donde el Equipo Scrum junto con los stakeholders dialogan sobre lo que se ha realizado durante el sprint. En esta reunión se presenta el incremento terminado, se responden interrogantes, se obtiene feedback y se presenta el Product Backlog actualizado y revisado, listo para el siguiente sprint.



Retrospectiva del Sprint: es en este evento donde el Equipo Scrum puede inspeccionarse a sí mismo, es una reunión donde se abordan los aspectos positivos durante del proceso. Se lo realiza al finalizar el sprint y antes de comenzar uno nuevo (pp. 9-14).

3.3.3.4.3.4.6 Artefactos Scrum. Los artefactos que se generan en Scrum son resultado del trabajo y representan valor de varias formas, y estos se conjugan con los tres pilares de Scrum, así, todos pueden tener el mismo conocimiento del artefacto. Entre los artefactos generados se encuentran: 

Lista de Productos: también conocido como Product Backlog, es una lista ordenada de todos los requisitos necesarios para la construcción del producto. El Product Owner es el responsable de este artefacto. Esta lista no es completa, sino que en un principio solo posee los requerimientos más entendidos, y va modificándose conforme el producto y su entorno también evolucionen.



Lista de pendientes: o denominado Sprint Backlog, es una lista más específica que contiene los elementos del Product Backlog que se realizarán en un sprint. Es por medio de esta que se evidencia todo el trabajo que el Equipo de Desarrollo llevará a cabo en un sprint. La lista pertenece al Equipo de Desarrollo y solo éste puede modificarla.



Incremento: es el resultado de la unión de los elementos finalizados del Product Backlog y que se desarrollaron durante un sprint y que se sumas a los incrementos anteriores, con la característica de que el incremento entregado esta “terminado”, es decir, que es potencialmente utilizable.

3.3.3.4.3.4.7 Proceso Scrum. Scrum Framework es simple de entender, a diferencia de otros enfoques que poseen un amplio grupo de componentes. Scrum no se debe entender como metodología (no lo es) sino más bien como la aplicación del método científico empírico donde se emplea el enfoque heurístico con respeto, auto organización y capacidad de resolución de problemas (Scrum, 2017). A continuación (Figura 11) se presenta cómo es el ciclo de trabajo o proceso Scrum: 1.

Sprint 0: es la etapa más importante dado que aquí arranca el proceso, el Product Owner crea las bases del proyecto, arma el equipo, provee recursos, determina plazos y entrega los requerimientos que se plasman en el Product Backlog.

Después de ello se comienza a trabajar por sprints según las dimensiones y naturaleza del proyecto.

El sprint inicia con la tarea de planificación (Sprint Planning) seleccionando los requerimientos del Product Backlog a realizar durante el sprint. Después se los subdivide en tareas y se crea la lista de pendientes (Sprint Backlog) que se realizarán en la iteración.

En el tiempo de duración del sprint se realizan las reuniones diarias, también conocidas como Daily Scrum.

Al final del sprint se realiza la revisión del mismo (Sprint Review) donde se inspecciona el resultado entregado, y después el Sprint Retrospective como punto de auto-evaluación (Álvarez, De las Heras del Dedo, & Lasa, 2012, pp. 59-60)

Figura 11. Proceso Scrum. Adaptado de “What is Scrum?” por Scrum, 2017. Recuperado de https://www.scrum.org/resources/what-is-scrum

3.4 Base de datos 3.4.1 Definición. Cuando una empresa opta por usar un sistema informático para automatizar sus procesos, el equipo de desarrollo comienza con la creación del software que abarque todas las necesidades que el cliente desea. Para complementar el funcionamiento del sistema, y que este sea dinámico, se emplea una base de datos que almacene y respalde la información. Una Base de Datos se define como una colección de datos que se los ha definido y estructurado de una determinada forma como resultado de un proceso más específico con la finalidad de prevenir la repetición que podría producirse al momento de almacenar datos. El almacenamiento se lo realizaría en cualquier forma o medio de almacenamiento, por ejemplo un disco duro, etc. (Reinosa, Maldonado, Muñoz, Damiano, & Abrutsky, 2012, p. 3) 3.4.2 Base de datos relacional. Una base de datos relacional (Figura 12) es un tipo de base de datos fundamentada en el concepto matemático de relación, se encuentra formada por tablas y se caracteriza por integrarlas adecuadamente y resolver de mejor manera los problemas de redundancia de datos, pudiendo utilizar cualquier campo como clave primaria. Su utilización es sencilla, actúa sobre las tablas y permite realizar complejas consultas (Valderrey, 2014, pp. 28-29)

Figura 12. Forma de organización relacional. Adaptado de “Administración de sistemas gestores de bases de datos” por Valderrey, P., 2014. Recuperado de https://ebookcentral.proquest.com

3.4.3 Modelo de Datos. Una base de datos como su nombre lo indica, está conformada por datos que han sido abstraídos de una realidad particular y posteriormente modelados. Se entiende por modelo de datos al conjunto de herramientas conceptuales que permiten la descripción, especificar relaciones y restricciones que existen entre los datos. El modelo permite realizar una representación de la realidad y se refleja a través de un esquema (Hueso, 2014, p. 24). 3.4.3.1. Modelo entidad relación (MER). El MER es empleado para la especificación de datos de manera global (Figura 13). La realidad es representada por medio de objetos conocidos como entidades, los cuales tienen características que los diferencian de otros. Los elementos que posee el esquema o diagrama entidad/interrelación son: entidad -objeto real o abstracto-, los atributos -características o propiedades de las entidades- y las relaciones –asociación de entidades- (Hueso, 2014, p. 24)

Figura 13. Diagrama Entidad-Relación simplificado.

3.4.4 Sistemas Gestores de Base de datos. 3.4.4.1. Definición. Los Sistemas de Gestión de Base de Datos (SGBD) o también conocidos como Database Management System (DBMS) son una capa de software que controla todos los accesos a la base de datos, estos pueden emplearse en diferentes entornos ya sea de forma académica, bancaria, empresarial, etc. (Reinosa et al., 2012, p. 4). Un SGBD (Figura 14) provee de una interfaz que permite la interaccion entre los usuarios y la base de datos puesto que los usuarios acceden a esta ultima por medio de las aplicaciones. (Hueso, 2014)

Figura 14. Representación de un SGBD. Adaptado de “Base de Datos” por Hueso, L., 2014. Recuperado de https://ebookcentral.proquest.com

3.4.4.2. Funciones de un SGBD. Un SGBD posee varias funciones que le permiten al administrador crear y dar mantenimiento a una base de datos. De acuerdo con Valderrey (2014) las funciones más destacadas son las siguientes: 

Creación, definición y acceso a la base de datos.



Manipulación de datos.



Respaldar y recuperar información.



Manejo y optimización de las transacciones.



Preservar integridad y consistencia de los datos (pp. 40-41)

3.4.4.3. Ejemplos de SGBD. 3.4.4.3.1 MySQL. MySQL es la base de datos de código abierto más usada y popular a nivel mundial. Este sistema de gestión de base de datos provee de amplias y avanzadas características para aquellas personas que desarrollan aplicaciones web y servicios integrados. Sus potentes funciones se vuelven sencillas dado que MySQL es fácil de configurar y de usar. La versión 5.7 es tres veces más rápida a sus antecesoras y MySQL Community Edition es mantenida por una amplia comunidad activa de desarrolladores (MySQL, 2017). 3.4.4.3.2 SQL Server. La base de datos Microsoft SQL Server es un SGBD del tipo relacional que es propiedad y alternativa propuesta por el gigante informático Microsoft. Los lenguajes de consulta empleados son el ANSI SQL y el T-SQL. Posee varias características como soporte para procedimientos almacenados, seguridad, escalabilidad, potente interfaz de usuario para la administración, facilita el trabajo en modo cliente-servidor y sistemas distribuidos. (Valderrey, 2014, p. 112) 3.4.4.3.3 Oracle. Oracle Database es propiedad del gigante de las bases de datos Oracle. Este SGBD posee una amplia gama de características y prestaciones que la posicionan como la base de datos número uno en el mundo. Posee varias ediciones (la mayoría de pago) de base de datos (Cloud, Enterprise, Standard, Express, Personal) para diferentes propósitos, usos y entornos de ejecución, cada una bien diferenciada. Oracle Express Edition es la edición básica (y limitada) que es libre de usar y distribuir (Oracle, 2017). 3.4.4.4. SQL. El lenguaje SQL fue desarrollado para ser utilizado específicamente en bases de datos, y de forma particular aquellas que siguen el modelo relacional, aunque recientemente se lo ha añadido en el modelado de objetos resultando en estructuras objeto-relacional. IBM lo desarrolló en 1970 y desde entonces progreso ha sido tal hasta el punto de ser empleado en la industria y considerado como estándar formal por parte de la ISO (Taylor, 2013, p. 5)

El Lenguaje de Consulta Estructurado (Structured Query Language) se encuentra normalizado por el Instituto Americano de Normalización (ANSI). El lenguaje a su vez se subdivide en tres sub-lenguajes o grupos que son: DML (Data Manipulation Language), DDL (Data Definition Language) y DCL (Data Control Language). (Hueso, 2014, p. 56) 3.4.4.5. Normalización. La normalización es un proceso que se emplea para realizar el control de redundancia (repetición) de datos en una base de datos. Este proceso consiste en una serie de reglas que se relacionan directamente, cada regla se la denomina “Forma Normal” y cada regla antecesora es base para la regla sucesora. Para proceder con la siguiente forma normal, la base de datos debe cumplir obligatoriamente la regla anterior, y así sucesivamente. Para que el diseño de una base de datos sea considerado correcto, es necesario que al menos cumpla con las tres primeras reglas (Chicano, 2013, pp. 104-105)

3.5 Desarrollo de Aplicaciones Web 3.5.1 Aplicaciones Web. Son la agrupación de software codificado en un lenguaje de programación determinado, y que el usuario emplea para acceder a servicios web de Internet o Intranet a través de un navegador web. Han tenido gran acogida debido a su independencia del sistema operativo, su información está centralizada, y no es necesario instalar nada. (Cardador, 2014, pp. 132-136). 3.5.1.1. Arquitectura Aplicaciones Web. 3.5.1.1.1 Cliente/Servidor. Este tipo de arquitectura se caracteriza por repartir el trabajo en dos partes: una que es el cliente y otra que es el servidor. La parte del cliente se encarga de realizar solicitudes (de servicios) y el servidor se encarga de darles respuesta. En esta arquitectura la información se encuentra centralizada, permitiendo con ello que el diseño y mantenimiento del sistema sea más sencillo, además las responsabilidades se separan (Ferrer, 2014, p. 21)

3.5.1.1.2 Entornos en tres capas. Este tipo de arquitectura (Figura 15) es una modificación del entorno cliente/servidor en donde se añade un nivel extra que es intermediario. Se mantiene el nivel Cliente que es quien solicita los recursos por medio de una interfaz de usuario; el nuevo nivel intermedio o Servidor de Aplicaciones que provee al cliente lo solicitado, y por último el Servidor de Datos que provee de datos al Servidor de Aplicaciones. Algunas ventajas de esta arquitectura es su flexibilidad, mayor seguridad y alto rendimiento (Ferrer, 2014, pp. 23-24)

Figura 15. Representación del entorno en tres niveles. Adaptado de “Implantación de Aplicaciones Web” por Ferrer, J., 2014. Recuperado de https://ebookcentral.proquest.com

3.5.2 Modelo Vista Controlador (MVC). El patrón Modelo-Vista-Controlador (Figura 16) se introdujo en 1970 en Xerox Parc por parte de Trygve Reenskaug con la finalidad de acercar el modelo mental del usuario al modelo digital del ordenador. MVC es empleado frecuentemente en el desarrollo de aplicaciones web dado que permite combinar tecnologías y dividir la aplicación en tres categorías o capas principales. (Pop & Altar, 2014, pp. 1173-1174) 

Modelo: contiene la lógica de negocio



Vista: presenta los datos en el modelo (interfaz de usuario)



Controlador: facilita la interacción del usuario.

Figura 16. Representación de los elementos del patrón MVC. Adaptado de “Patrón Modelo-Vista-Controlador” por Fernández, Y., & Díaz, Y., 2012, pp. 47-57. Recuperado de http://revistatelematica.cujae.edu.cu/index.php/tele/article/view/15/10

3.5.3 Herramientas de desarrollo. 3.5.3.1. Servidor Web. 3.5.3.1.1 Definición. Es un programa que se instala y configura para que el servicio este operativo, éste debe tener acceso al exterior aunque no es necesario. (Granados, 2014, p. 228). El servidor web se encarga de atender todas las solicitudes respecto a archivos o sitos web que el cliente solicita por medio de un navegador web. Esta comunicación entre el servidor web y el navegador web se realiza por medio del protocolo http (Cardador, 2014, p. 71) 3.5.3.1.1.1 Apache. Es un servidor http -web- que puede ejecutarse en varios sistemas operativos. Se caracteriza por ser software open-source (código abierto), robusto, poseer amplia documentación, varias prestaciones configurables y contar una gran comunidad activa que lo mantiene y brinda soporte. Es muy flexible y personalizable, cuenta con varios módulos y puede ser usado para diferentes propósitos. (López, y otros, 2014, p. 28) 3.5.3.2. Lenguaje de Guión. También denominado lenguaje de script se caracteriza por no ser compilado, es decir, que su código es leído y ejecutado línea por línea por el intérprete que viene integrado en el lenguaje, sin tener que pasar por un compilador como sucede con otros tipos de lenguajes. Al trabajar de este modo la ejecución y presentación de resultados es rápida. Este tipo de lenguajes son generalmente utilizados para el desarrollo web (Ollero, 2015, pp. 35-36)

3.5.3.2.1 PHP (Php Hypertext Preprocessor). PHP es un lenguaje open-source generalmente usado para el desarrollo de aplicaciones web. Se ejecuta en el lado del servidor y se puede usar combinándolo con HTML. Su sintaxis es simple y posee varias características que lo hacen un lenguaje potente y flexible. Es multiplataforma, soporta orientación a objetos, es compatible con varias bases de datos y con la mayoría de servidores web (The PHP Group, 2017) 3.5.3.3. Diseño de interfaces web. 3.5.3.3.1 MaterializeCSS. Materialize es un framework para el diseño front-end con capacidades responsivas que se basa en la filosofía Material Design de Google. Se enfoca en la experiencia de usuario y la vuelve simple y sencilla. Provee componentes del CSS y Javascript, además de poseer un amplio abanico de elementos visuales que enriquecen sus características y se enfocan en el sector de los dispositivos móviles. (Chang & Wang, 2017) Igualmente desde su página oficial se puede encontrar documentación y tutoriales referentes al uso de sus componentes. 3.5.3.3.2 HTML5 y CSS3. HTML (HyperText Markup Language) es un lenguaje de marcado para hipertexto desarrollado por Tim Berners-Lee en 1989. Su versión más reciente -5- añadiendo nuevas características como el soporte e incorporación de nuevos códec multimedia, mejora en el manejo de formularios, creación de contenido dinámico como tablas. (Contreras, 2016, pp. 2634). No es un lenguaje de programación, se lo utiliza básicamente para la construcción de una página web, definiendo la estructura y el cómo quiere que se presenten los diferentes elementos que agrupan el contenido de la página (Mozilla , 2017) Con la presentación del html como estándar aparecieron las hojas de estilo, estas separan el contenido visual de la estructura de un documento html, funcionando como una extensión del mismo. CSS (Cascading Style Sheets) son hojas de estilo en cascada que especifican un lenguaje para fijar formatos y estilos que poseerán los documentos. En la actualidad se encuentra en el nivel 3 -CSS3-. (López & Alcayde, 2014, pp. 143-146)

3.6 Administración de Proyectos 3.6.1 Proyectos. 3.6.1.1. Definición. Existe una amplia y variada revisión acerca del significado del término proyecto dado que se presta a entenderse en diferentes entornos y contextos, pero en el presente documento se lo entenderá en el sentido de la gestión de proyectos. De acuerdo con Cleland y William R. King citado por González, Alba, & Ordieres (2014) un proyecto se define como la unión de recursos, sean estos humanos y no humanos, que se encuentran agrupados en una organizción temporal con la finalidad de alcanzar un objetivo determiando desarrollando servicios o productos únicos (p. 9) Los proyectos son realizados frecuentemente por empresas de diferente propósito, pero cada proyecto que se realiza no es igual a otro. Muchos de los proyectos se ejecutan con el objetivo de conseguir un producto o servicio que perdure en el tiempo. Cada proyecto tiene un principio y un fin, y muchos de ellos pueden generar impactos económicos, sociales, etc., dependiendo del entorno en que se desarrollan (González, Alba, & Ordieres, 2014, p. 10) 3.6.1.2. Características de los proyectos. Entre las características principales que tiene un proyecto, de acuerdo con Rojas (2009) encontramos las siguientes: 

Temporalidad: todo proyecto tiene un inicio y un tiempo final de entrega.



Propósito: un proyecto se realiza con una finalidad determinada.



Procedurales: todo proyecto conlleva un proceso que se ejecuta en determinado orden y que se divide en varias etapas independientes.



Únicos: algunos proyectos son únicos dado que se los realiza una sola vez o no se han realizado antes (como una boda, un nuevo producto, etc.)



Recursos: los proyectos emplean recursos (económicos, humanos, materiales, entre otros) para su realización, estos recursos son limitados (pp. 9-10)

Los proyectos se ejecutan en función de tres factores como son (Figura 17) el tiempo, dinero y calidad, los cuales, estando en equilibrio manejan la dinámica del proyecto y brindan un sostén a los procesos y tareas que se realizan en el proyecto, logrando con ello que el proyecto no se salga de rumbo y cumpla sus objetivos.

Figura 17. Correlación de los elementos condicionantes de un proyecto. Adaptado de “Gerencia de la Construcción” por Rojas, M., 2009. Recuperado de https://ebookcentral.proquest.com

3.6.1.3. Fases de un proyecto. Desde una perspectiva general, las fases de un proyecto son las siguientes: 

Fase de Planificación: se define el equipo de trabajo que estará presente durante la ejecución del proyecto. Una adecuada planificación brinda solidez y seguridad en el proyecto.



Fase de Ejecución: aquí se llevan a cabo todos los procesos y tareas que se consideran darán vida al proyecto. Durante la ejecución se realizan las tareas de asignación y gestión de recursos que se emplearán en la obra.



Fase de Entrega: es la parte final del proyecto. Aquí se cumple con la fecha límite del proyecto y se finaliza con la entrega (y funcionamiento dependiendo del caso) del mismo al cliente. (Palladino, 2014, p. 27)

3.6.1.4. Dirección de proyectos. La administración de proyectos es una rama de la Administración que se centra en el adecuado funcionamiento de un proyecto. El director o administrador es el encargado de que el proyecto cumpla cada una de sus etapas o fases de forma eficiente y con los objetivos

establecidos. La administración de proyectos en la actualidad resulta muy importante para naciones, organizaciones y empresas tanto en el hecho de que aportan rentabilidad y mejoran las formas de hacer negocio. (Torres Hernández & Torres Martínez, Administración de proyectos, 2014, pp. 20-21) 3.6.1.4.1 Control. Es la última fase que se lleva a cabo luego de haber cumplido un proceso, el control supone la inspección, comprobación, regulación y comprobación del mismo. Se relaciona con la ejecución de tareas para la consecución de resultados reales respecto a los resultados previamente planificados. Desde el punto de vista administrativo, el control es la entidad capaz de regular y equilibrar un sistema. (Torres Hernández & Torres Martínez, Planeación y Control, 2014, pp. 245-254) 3.6.1.5. Importancia de la tecnología en las organizaciones. La aplicación de las tecnologías (sistemas de información) en las empresas y organizaciones cumplen un papel muy importante, ya sea en el cumplimiento de procesos como en el de estrategias. En este punto, no se puede tratar a los sistemas de información como una parte complementaria de una organización sino más bien converger la estrategia de negocio con la estrategia del sistema. (Marco Simó & Marco Galindo, 2013, pp. 206-209) La integración de tecnologías en la organización conlleva a que esta adquiera una ventaja competitiva en el mercado que se desenvuelva, añadiendo un valor adicional al producto o servicio ofrecido con el fin de satisfacer las necesidades del cliente (Hidalgo, León, & Pavón, 2013, pp. 37-39)

4. METODOLOGÍA DE LA INVESTIGACIÓN 4.1 Enfoque / Tipo de Investigación 4.1.1 Enfoque de Investigación. El enfoque de investigación que se ha seleccionado para la presente investigación es el enfoque mixto, dado que es aquel en donde se combinan los procesos y técnicas de investigación cualitativa como cuantitativa. El método o enfoque mixto abarca la colección de procesos sistemáticos y empíricos que derivan en el estudio, análisis y discusión de los datos cualitativos y cuantitativos, todo ello con la finalidad de comprender de mejor manera el fenómeno de estudio (Hernández, Fernández, & Baptista, 2014, pp. 534). Las investigaciones con enfoques mixtos son consideradas como multimetódicas en donde la investigación coloca especial énfasis en un enfoque (cualitativo-cuantitativo) o en ambos. De acuerdo con Chen citado por Hernández et al (2014) estos métodos permiten analizar el fenómeno de estudio de forma más amplia y completa, en donde se puede mantener la estructura original de los métodos cuantitativos-culitativos o adaptarlos a la forma de la investigación (pp. 534-535). 4.1.2 Tipo de Investigación. 4.1.2.1. Investigación documental. La investigación documental se caracteriza por la búsqueda o recopilación de información en medios documentales como libros, publicaciones periódicas, archivos, impresos, sistemas computarizados, entre otros (Baena, 2014, p. 12). En el presente documento se aplica este tipo de investigación dado que se realiza la recolección de información acerca de los proyectos y de los procesos involucrados en el control y seguimiento de los mismo, también en el desarrollo y sustento del marco referencial, así como de igual forma establecer las bases de las herramientas tecnológicas a utilizar en la elaboración del sistema y de la metodología de desarrollo de software a emplear.

4.1.2.2. Investigación de campo. La investigación de campo tiene como fin último la recolección de datos referentes al fenómeno de estudio y posteriormente llevar un registro ordenado de los mismos (Baena, 2014, p. 12). En el presente trabajo, este tipo de investigación ayuda a los investigadores a recopilar datos e información del fenómeno de estudio acudiendo a la empresa en cuestión, empleando la observación como técnica de investigación y el registro de los datos recabados. 4.1.2.3. Investigación aplicada. También conocida como utilitaria, es el tipo de investigación donde se pone en práctica el conocimiento teórico general con la característica de resolver necesidades del hombre. Es decir, se resuelven problemas de forma práctica que se aplican a una situación en particular (Baena, 2014, p. 11). En el presente documento se refleja este tipo de investigación en la aplicación de los conocimientos teóricos, técnicos y especializados que se han adquirido en el transcurso de la carrera, así como los conseguidos en la investigación acción y documental para el desarrollo del sistema y del presente trabajo.

4.2 Población / Universo La población, de acuerdo con Jany citado por Bernal (2010) es el conjunto de entidades o elementos que poseen caracterisitcas semejantes, son considerados unidad de análisis y sobre los cuales se desea concluir algo (p. 160). La población a considerar en la presente investigación es el personal de la Sub-Gerencia de Desarrollo de Infraestructura de EPMAPASD y demás participantes (Departamento de Operación y Mantenimiento de proyectos) que influyen en el problema, sumando un total de 20 personas.

4.3 Muestra Una muestra, de forma general se entiende como la parte representativa de una determinada cantidad. Desde una perspectiva enfocada en la investigación, la muestra es un subconjunto de un grupo de estudio (población) que ha sido seleccionado con la intención de estudiar y analizar las características similares que posee el total del colectivo. (Niño, 2011, p. 55). Debido a una cuestión de ahorro de recursos, en muchas de las investigaciones se decide determinar el tamaño de la muestra cuando la población es mayor a 50 elementos (Gómez, y otros, 2017, p. 61)

4.4 Técnicas e Instrumentos de Recogida de Datos Las técnicas e instrumentos para la recolección de los datos en la presente investigación han sido determinados de acuerdo al enfoque de investigación seleccionado (mixto) en donde se combinan procedimientos y técnicas de los métodos cuantitativos y cualitativos. 4.4.1 Técnicas. 

Documental: permite recuperar y analizar información que se encuentra relacionada con el contexto de estudio. Los instrumentos son determinados por la fuente documental empleada. (Borda, 2013, p. 62)



Observación: es la técnica más usada. El investigador observa y registra los sucesos y características del objeto de estudio. El investigador puedo o no participar en los eventos.



Entrevista: utilizadas para recolectar información del tipo verbal, esta puede generarse por medio de una charla, conversación entre el entrevistador y el entrevistado, con el fin de conocer y comprender de mejor manera los sujetos de estudio (Borda, 2013, pp. 62-63). La entrevista se generó en un horario acordado con el Director del Departamento de Sub-Gerencia de Desarrollo de Infraestructura, en la cual nos indicó cual era el flujo de información generada por este grupo.



Encuesta: forma donde se solicita información a determinadas personas (encuestadas) por medio de la resolución de un cuestionario de preguntas.

4.4.2 Instrumentos. 

Fichas Bibliográficas: de acuerdo a la técnica documental



Apuntes de observación: para la Observación



Esquema abierto de preguntas: para la Entrevista



Cuestionarios: para la Encuesta

4.5 Técnicas de análisis de datos Entre las técnicas de análisis de datos se ha empleado la estadística descriptiva. La Estadística Descriptiva permite analizar y resumir datos e información provenientes de una muestra en particular para posteriormente ser organizados y presentados por medio de tablas y/o figuras (Cruz, Olivares, & González, 2014, p. 189). Como herramienta de soporte se ha empleado programas de cómputo para realizar las tareas descritas. Además, se procedió a la lectura y análisis del material recopilado y de los registros llevados a cabo durante las entrevistas y observaciones con el objetivo de levantar información, conocer el manejo de los procesos, los inconvenientes y dificultades presentados durante los mismos, y las características o funcionalidades principales que la solución (software) debe poseer.

4.6 Análisis Metodologías Desarrollo de Software 4.6.1 Diferencias métodos Tradicionales vs Ágiles. Como primer punto se empieza por comprender el panorama general de las metodologías de desarrollo de software y luego de un amplio y posterior análisis de información bibliográfica recabada, se presenta a continuación la (Tabla 2) en donde se expondrán y compararán las características más relevantes de estos dos paradigmas. Tabla 2. Comparativa Métodos Tradicionales y Ágiles Parámetros

Desarrollo Tradicional

Desarrollo Ágil

Proyectos grandes

Proyectos pequeños

Especificación de

Requerimientos

Requerimientos poco claros,

Requerimientos

iniciales/escaza variabilidad

inciertos, creativos

Cascada, espiral u otra

Iterativo/incremental

Tamaño del proyecto

Modelo de Desarrollo

Equipo de desarrollo Enfoque de proceso

variante Roles bien definidos por

Auto-organizados y multifuncionales

especialización Enfocado en el proceso

Enfocado en las personas

Nota: Adaptado de Aitken, A., & Ilango, V. (2013). A Comparative Analysis of Traditional Software Engineering and Agile Software Development. En System Sciences (HICSS), 2013 46th Hawaii International Conference (pp. 4751-4760). Maui: IEEE. Recuperdo de https://pdfs.semanticscholar.org/6fb5/bf372782860a799cd8e9a94e77b371a9c2d2.pdf. Špundak, M. (2014). Mixed agile/traditional project management methodology – reality or illusion? Procedia-Social and Behavioral Sciences, 119, 939-948. Recuperado de 10.1016/j.sbspro.2014.03.105. Elshandidy, H., & Mazen, S. (2013). Agile and Traditional Requirements Engineering: A Survey. International Journal of Scientific & Engineering Research, 4(9), 473-482. Recuperado de https://www.researchgate.net/profile/Heba_Elshandidy/publication/258046916_Agile_and_Traditional_Requirements_En gineering_A_Survey/links/00b49526bcfd9a7bdc000000/Agile-and-Traditional-Requirements-Engineering-A-Survey.pdf

Los métodos ágiles presentan significativas ventajas respecto a los tradicionales. Considerando los criterios expuestos, y de acuerdo a la magnitud del proyecto y la forma de los requerimientos, se ha seleccionado las metodologías agiles por acoplarse efectivamente a la presente investigación y forma de trabajo del equipo. 4.6.2 Comparativa Scrum vs XP. Siguiendo la misma línea del apartado anterior, se procede a realizar la comparación entre Scrum y XP (Tabla 3). Se selecciona XP para la comparativa dado que es el método ágil mejor conocido en las comunidades de desarrollo, y Scrum por ser el método ágil mayormente utilizado por las organizaciones (58 %) arriba del híbrido de XP (10%) según VersionOne (2017) Tabla 3. Comparativa Scrum vs XP Criterios Tamaño del proyecto Administración del proyecto Enfoque en el proyecto

Scrum

Cualquier dimensión

Pequeños

Admite prácticas

No admite prácticas

Aspectos Administrativos y de

Aspectos técnicos

productividad Colaboración con el cliente Equipo de desarrollo Requerimientos

No necesariamente en el sitio

En el sitio

Equipos multifuncionales

Equipos auto-organizados

Artefactos Scrum

Historia de Usuario

Nota: Adaptado de Matharu, G., Mishra, A., Singh, H., & Upadhyay, P. (2015). Empirical study of agile software development methodologies: A comparative analysis. ACM SIGSOFT Software Engineering Notes, 40(1). doi:10.1145/2693208.2693233. Anwer, F., Aftab, S., Muhammad, S., & Waheed, U. (2017). Comparative Analysis of Two Popular Agile Process Models: Extreme Programming and Scrum. International Journal of Computer Science and Telecommunications, 8(2), 1-7. Recuperado de http://www.ijcst.org/Volume8/Issue2/p1_8_2.pdf.

Después del estudio y análisis de las metodologías comparadas, los investigadores llegan a la conclusión de seleccionar Scrum debido a su sencillez, poca complejidad, enfoque, forma de trabajo del equipo y con el cliente. Se integra adecuadamente a las características del presente proyecto y permite la administración correcta del mismo, priorizando la productividad y funcionalidad de la solución y no incurrir en aspectos técnicos que quedan en segundo plano.

4.6.3 Marco de Trabajo Scrum. 4.6.3.1. Roles y responsabilidades. 

Product Owner: dueño del producto (representante de la empresa) -

Responsabilidad: describir funcionalidades del sistema, conocedor de los aspectos del negocio, testear el sistema.



Scrum Master: facilitador del proyecto -

Responsabilidad: Guiar el trabajo del equipo. Facilitar apoyo, ayuda y comprueba que exista productividad en el mismo.



Equipo de desarrollo: desarrolladores -

Responsabilidad: desarrollo de la aplicación, cumplir con los objetivos del sprint, entregar funcionalidad en el incremento.

4.6.3.2. Artefactos a emplear. 

Product Backlog: lista de requerimientos (historias de usuario).



Sprint Backlog: lista de historias de usuario a realizar en una iteración, seleccionadas por el equipo de desarrollo.



Incremento: parte o porción del producto final con alta probabilidad de funcionalidad.

4.6.3.3. Resumen del flujo de trabajo. El flujo de trabajo en Scrum es sencillo, iterativo (sprint) e incremental, en donde intervienen los roles, eventos y artefactos del framework. Para una mejor comprensión se presenta a continuación (de forma resumida) la forma de trabajo en Scrum: 

El Product Owner escribe las funcionalidades en el Product Backlog.



El Product Owner prioriza (ordena) como quiere que se construya el software.



El equipo estima la complejidad de las funcionalidades.



Se selecciona las funcionalidades (trabajo) que se realizará en el Sprint. Se realiza el Sprint Backlog.



El Sprint es llevado a cabo, en donde se realizan los Daily Scrum.



El Sprint finaliza con un Review, donde se presenta el producto realizado en ese sprint al Product Owner.



Para finalizar se realiza una Retrospective (auto-evaluación) del sprint y del equipo. Se preparan para el siguiente Sprint y el proceso se repite.

5. RESULTADOS 5.1 Análisis y Discusión de los Resultados 5.1.1 Encuesta al personal del Departamento de Desarrollo de Proyectos de EPMAPASD. Por medio de la aplicación de las encuestas al personal del Departamento de Proyectos de EPMAPA-SD, se ha recabado información vital que permitió al equipo de trabajo entender de mejor manera los procesos que se realizan y la problemática que se genera. A continuación se muestra los resultados obtenidos 1.

¿Cree usted que la forma de solicitar información de un proyecto dentro del Departamento de Desarrollo de EPMAPA-SD se realiza con facilidad y de manera rápida?

Tabla 4. Forma de entrega de información referente a proyectos Opciones

Número de personas

Porcentaje

10 %

90 %

TOTAL

100 %

Nota: Datos obtenidos de la encuesta aplicada al personal del Departamento de Desarrollo de Proyectos y otros de EPMAPASD

¿Cree usted que la forma de solicitar información de un proyecto dentro del Departamento de Desarrollo de EPMAPA-SD se realiza con facilidad y de manera rápida?

10% si no 90%

Figura 18. Forma de entrega de información referente a proyectos.

Análisis: de acuerdo con los datos obtenidos en la encuesta, se observa que el 90% de los encuestados reconoce que la manera en cómo se solicita y entrega información de un determinado proyecto no se realiza de manera adecuada, es poco eficiente y se evidencia en las observaciones que se han realizado en la institución, registrando la problemática generada. 2.

¿Conoce el avance que posee un proyecto en particular durante la ejecución del mismo?

Tabla 5. Conocimiento del progreso de un proyecto Opciones

Número de personas

Porcentaje

TOTAL

100

Nota: Datos obtenidos de la encuesta aplicada al personal del Departamento de Desarrollo de Proyectos y otros de EPMAPASD

¿Conoce el avance que posee un proyecto en particular durante la ejecución del mismo?

15% SI NO 85%

Figura 19. Conocimiento del progreso de un proyecto.

Análisis: a través de la encuesta se obtiene como resultado en la presente pregunta que el 85 % de los encuestados desconoce el avance que posee un proyecto mientras éste se ejecuta, con lo cual no pueden tener la certeza de si un proyecto está en ejecución o no, esto se suma a la problemática antes descrita, es decir la dificultad al entregar información solicitada de un determinado proyecto.

¿Cree usted que es importante conocer los avances de todos los proyectos de manera general dentro de la empresa pública?

Tabla 6. Importancia de la comunicación de los avances de los proyectos Opciones

Número de personas

Porcentaje

100 %

TOTAL

100 %

Nota: Datos obtenidos de la encuesta aplicada al personal del Departamento de Desarrollo de Proyectos y otros de EPMAPASD

¿Cree usted que es importante conocer los avances de todos los proyectos de manera general dentro de la empresa pública?

0% SI NO 100%

Figura 20. Importancia de la comunicación de los avances de los proyectos.

Análisis: por medio de la aplicación de la encuesta, se comprueba con la siguiente pregunta que el total de encuestados (100 % de las personas) no conoce los avances de forma general que poseen todos los proyectos que se desarrollan en la empresa. Ello provoca que el personal no cuente con información al instante, real y actualizada sobre todos los proyectos, generando retrasos de tiempo mientras se consulta dicha información.

¿Conoce de forma directa quién fiscaliza un proyecto en determinado lapso de tiempo?

Tabla 7. Conocimiento del supervisor de los proyectos Opciones

Número de personas

Porcentaje

100 %

TOTAL

100 %

Nota: Datos obtenidos de la encuesta aplicada al personal del Departamento de Desarrollo de Proyectos y otros de EPMAPASD

¿Conoce de forma directa quién fiscaliza un proyecto en determinado lapso de tiempo?

0% si no 100%

Figura 21. Conocimiento del supervisor de proyectos.

Análisis: a través de la encuesta aplicada se obtiene como resultado de que el 100 % de los encuestados no conoce quien es la persona encargada de supervisar o fiscalizar determinados proyectos, generando con ello un total desconocimiento de información importante. Con el desarrollo del sistema se pretende dar solución a ello con la generación de reportes.

¿Cree usted que es necesario automatizar la gestión de proyectos dentro de la empresa pública?

Tabla 8. Importancia de la automatización de la gestión de información. Opciones

Número de personas

Porcentaje

95 %

TOTAL

100%

Nota: Datos obtenidos de la encuesta aplicada al personal del Departamento de Desarrollo de Proyectos y otros de EPMAPASD

¿Cree usted que es necesario automatizar la gestión de proyectos dentro de la empresa pública?

5% SI NO 95%

Figura 22. Importancia de la automatización de la gestión de información.

Análisis: de acuerdo con los datos obtenidos en la encuesta se observa que el 95 % de las personas encuestadas creen que es necesario automatizar la forma en cómo se gestiona la información referente a los proyectos, que a la fecha de realizar la presente encuesta se llevaba a cabo de forma manual, lo cual es poco eficiente y obsoleto. Con el desarrollo del sistema se modernizará la forma en cómo se maneja la información de los proyectos e la empresa.

Según su criterio. ¿Está de acuerdo con la implementación de un sistema que permita la gestión de los proyectos dentro de la empresa?

Tabla 9. Implementación del sistema en la empresa Opciones

Número de personas

Porcentaje

100 %

TOTAL

100 %

Nota: Datos obtenidos de la encuesta aplicada al personal del Departamento de Desarrollo de Proyectos y otros de EPMAPASD

Según su criterio. ¿Está de acuerdo con la implementación de un sistema que permita la gestión de los proyectos dentro de la empresa?

0% SI NO 100%

Figura 23. Implementación del sistema en la empresa.

Análisis: de acuerdo con los datos obtenidos en la encuesta, se observa que la totalidad de los encuestados (100 %) está de acuerdo con el desarrollo e implementación del sistema informático a desarrollar. Con él, la gestión de la información se realizará de forma digital, respaldando los archivos físicos que se posea, con una entrega rápida, completa, personalizada y oportuna de la información de los proyectos de la empresa.

¿Ha tenido alguna experiencia previa empleando algún tipo de sistema que permita gestionar información de forma digital?

Tabla 10. Experiencia con el uso de sistemas informáticos. Opciones

Número de personas

Porcentaje

75 %

25 %

TOTAL

100 %

Nota: Datos obtenidos de la encuesta aplicada al personal del Departamento de Desarrollo de Proyectos y otros de EPMAPASD

¿Ha tenido alguna experiencia previa empleando algún tipo de sistema que permita gestionar información de forma digital?

25% SI NO 75%

Figura 24. Experiencias con el uso de sistemas informáticos.

Análisis: con los resultados obtenidos de la encuesta se evidencia que el 75 % (quince personas) si posee experiencia en el manejo de algún sistema informático. Por otro lado, cinco personas (25 %) no poseen experiencia. Por medio de las capacitaciones del sistema y la entrega de los respectivos manuales de usuario al personal correspondiente, servirán de ayuda y minimizarán los inconvenientes que puedan generarse con la utilización del sistema web.

Con la implementación del sistema. ¿Cree usted que se reducirá el tiempo de respuesta y aumentará la productividad del personal a cargo del sistema?

Tabla 11. Mejora de la productividad del personal Opciones

Número de personas

Porcentaje

80 %

20 %

TOTAL

100 %

Nota: Datos obtenidos de la encuesta aplicada al personal del Departamento de Desarrollo de Proyectos y otros de EPMAPASD

Con la implementación del sistema. ¿Cree usted que se reducirá el tiempo de respuesta y aumentará la productividad del personal a cargo del sistema?

20% SI 80%

Figura 25. Mejora de la productividad del personal.

Análisis: de acuerdo con los resultados obtenidos por medio de la encuesta, se concluye que el 80 % de los encuestados tienen la apreciación de que la forma de llevar a cabo los procesos de gestión de la información de los proyectos mejorará con la implementación del sistema web, a su vez que se hace un mejor uso del tiempo y de recursos tecnológicos.

5.1.1.1. Discusión de los resultados obtenidos en la encuesta. Después del respectivo análisis de la encuesta aplicada tanto al personal del Departamento de Desarrollo de Infraestructura como al Departamento de Operación y Mantenimiento de Proyectos se concluye que la empresa realizaba sus operaciones de manejo (gestión) de la información de todos los proyectos de forma poco eficiente, en su gran mayoría de forma manual, con lo cual se evidencia la necesidad de emplear un sistema informático que brinde soporte en dichos procesos y automatice la gestión de la información, mejorando de tal forma su administración y organización.

5.2 Resultados de la Aplicación de Scrum Framework 5.2.1 El proceso Scrum. Como se ha explicado anteriormente en el apartado 4.6.3.3 del presente documento, la forma de trabajo de Scrum es incremental y se trabaja por sprint. El primer paso importante dentro de Scrum es el llamado “Sprint 0” en donde empieza la ejecución del proyecto como tal. Es una etapa donde se realiza la recopilación de información necesaria para la ejecución del proyecto, el Dueño del Producto (Product Owner) crea las bases del mismo, se define el Equipo de Trabajo y se especifican los requerimientos (iniciales en un principio) que debe poseer el sistema detallándolos en el Product Backlog. 5.2.1.1. Sprint 0. 5.2.1.1.1 Entrevista realizada al Sub-Gerente. La entrevista (Ver Anexo 4) realizada al Sub-Gerente del Departamento de Desarrollo de Infraestructura se realizó bajo la pauta de preguntas abiertas que giraron en torno al conocimiento de la problemática y descripción de los procesos y detalles importantes respecto a la administración de la información de los proyectos que se realizan en EMAPA-SD. A continuación se presenta información general (Tabla 12) de la entrevista y un resumen de la misma:

52 Tabla 12 Información General de la Entrevista Entrevista dirigida al Sub-Gerente del Departamento de Desarrollo de Infraestructura EPMAPA-SD

Objetivo de la Entrevista: La presente entrevista se realiza con la finalidad de conocer todos los parámetros que intervienen dentro de la realización de un proyecto realizado en EPMAPA-SD. Lugar de la entrevista: Empresa Pública Municipal de Alcantarillado y Agua Potable - Santo Domingo Entrevistado: Ing. Elvis Escudero

Cargo: Sub-Gerente de Desarrollo de Infraestructura

Entrevistador: Franklin Sampedro

Fecha y Hora: 03 de enero de 2018 – 15:00 p.m.

Nota: Datos obtenidos de la entrevista aplicada al Sub-Gerente de Desarrollo de Proyectos de EPMAPA-SD

Resumen: como resultado de la entrevista se obtiene la recopilación de información importante que servirá de ayuda a los investigadores para entender de mejor manera la naturaleza de los procesos que se llevan a cabo dentro de los departamentos involucrados. A su vez que se conocen aspectos y detalles valiosos referentes a los proyectos como son: el tiempo de duración (entre 120 a 160 días), las personas involucradas en administrar la información de los proyectos (el fiscalizador y el Sub-Gerente), el supervisor de los proyectos (fiscalizador), la persona encargada de dar seguimiento a los proyectos (subgerente) y las personas que brindan apoyo en los procesos antes descritos (personal del Departamento de Desarrollo de Infraestructura y Departamento de Operación y Mantenimiento de Proyectos) Respecto a la forma en cómo se maneja la información de los proyectos, ésta es llevada a cabo de manera manual, donde toda la documentación que es generada por un proyecto es almacenada de manera física (papel) al igual que en CD’s almacenando en ellos sólo la información relevante, la cual es escaneada y exportada en archivos .pdf. Todo ello se deposita en archivadores y folders que ocupan un lugar específico dentro de los departamentos. Con relación al desarrollo del sistema, se indicó que la aplicación debe contar con la posibilidad de generar reportes de diferente tipo, donde se evidencie: porcentaje de avance de obra total, porcentaje de avance económico, número de proyectos ejecutados con recepción provisional y definitiva, proyectos en etapa de ejecución, proyectos ejecutados en determinado año, y la ficha general del proyecto.

5.2.1.1.2 Descripción de los procesos. 5.2.1.1.2.1 Situación actual (aspectos del negocio). A continuación se realiza una breve explicación de cómo es el manejo actual de la empresa respectos a los procesos de gestión de la información de los proyectos: Consideraciones Iniciales. 1.

La documentación de los proyectos arriban a los departamentos de Desarrollo de Infraestructura y al de Operación y Mantenimiento de Proyectos para su revisión.

Después de ello pasa al Departamento de Contabilidad donde se asigna el presupuesto para cada planilla.

Retorna nuevamente al departamento de origen (Infraestructura u Operación) y se asigna un fiscalizador.

Solicitud de información. 

La persona que necesite información de un determinado proyecto se acerca al subgerente del departamento para solicitar la información requerida.



El asistente del subgerente se dirige al archivador correspondiente y busca la carpeta de acuerdo a lo solicitado (nombre, año, etc.)



La carpeta posee los archivos físicos del proyecto junto con CD’s.



El subgerente recepta la carpeta, busca la información y realiza una fotocopia del documento solicitado.

5.2.1.1.2.2 Propuesta. Con el desarrollo del sistema se pretende automatizar todos los procesos previamente descritos y que se realizan de forma manual, a su vez de brindar modernización a la empresa con el empleo de tecnologías open-source en sus operaciones. De igual forma se realizarán validaciones adicionales que permitan el control y seguimiento de los proyectos, además se proveerá de características especiales que signifiquen una mejora en la forma de administrar la información de los proyectos mediante el uso del sistema. Todas estas características se

reflejarán en las historias de usuario correspondientes y en los productos (entregables) que se den del sistema. 5.2.1.1.3 Definición del equipo de trabajo. Tomando como base los roles Scrum, el equipo de trabajo queda definido de la siguiente manera: 

Product Owner: Ing. Elvis Escudero



Scrum Master: Mg. Luis Ulloa



Equipo de desarrollo: Byron Demera – Franklin Sampedro

5.2.1.1.4 Selección de herramientas tecnológicas. En cuanto a la selección de herramientas de desarrollo se tomó en consideración como punto importante que sea software open-source, la experiencia del equipo de desarrollo con dichas herramientas y la facilidad de aprendizaje (curva de aprendizaje) al momento de implementar nuevas características. De este modo quedan las siguientes: 

Base de Datos: MySQL Community 5.7.21



Lenguaje de Script: PHP



Servidor web: Apache



Framework de diseño: Materialize – HTML5 + CSS3 + JS

5.2.1.1.5 Product Backlog. El Product Backlog es donde el Product Owner especifica los requerimientos (que se evidencian en las Historias de Usuario) que debe poseer el sistema (Tabla 13). A continuación se muestra la lista de productos en su primera versión donde se detalla los requerimientos iniciales: Tabla 13 Product Backlog

Numero de Historia 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Product Backlog Historia de Usuario Interfaz principal de inicio del sistema Login de Usuarios Creación de usuarios Actualización de usuarios Restablecimiento de contraseña Caducidad de la sesión Registro de proyecto Almacenamiento de información digitalizada de proyectos Modificación de un proyecto Visualización de información digitalizada de cada proyecto Visualización del informe de estado de cada proyecto Eliminación de un proyecto Acceso a opciones complementarias para un proyecto Generación de Planillas por cada proyecto Generación de informe individual por planilla Ingreso de Incrementos en el proyecto Ingreso de prórrogas en el proyecto Presentación resumida de los datos del proyecto Ingreso de Actas de Finalización de cada proyecto Reporte general de proyectos Reporte individual de proyectos Reporte de fiscalizadores

Nota: versión 2.0 del Product Backlog. Datos obtenidos de la investigación de campo

Prioridad Alta Alta Alta Alta Alta Alta Alta Media Media Media Media Media Media Media Media Media Media Baja Baja Baja Baja Baja

5.2.1.2. Sprint 1. 5.2.1.2.1 Sprint Planning. La actividad de planificación del sprint sirve para seleccionar las historias de usuario a realizar en el presente sprint (Tabla 14), con ello se genera el sprint Backlog. Tabla 14 Sprint Backlog del sprint 1 Sprint Backlog 1 Objetivo del Sprint: Desarrollar y desplegar funcionalidad respecto a interfaces principales y administración de usuarios HU EST-HU TAREAS DE INGENIERÍA EST-TI ESTADO Interfaz principal de inicio del sistema

Creación de usuarios

Modificación de usuarios

Restablecimiento de Contraseña

Caducidad de la sesión

Crear diseño web para presentar pantalla de inicio al sistema Verificación y validación de la funcionalidad

Configuración del entorno de trabajo Creación de entidades en la base de datos relacionadas con la historia de usuario Verificación del diseño de la base de datos Crear interfaces de usuario para el acceso al sistema Codificación de la funcionalidad (HU) requerida Actualización del diseño de la base de datos Verificación del diseño de la base de datos Crear el diseño del formulario para el ingreso de nuevos usuarios Codificación de la funcionalidad (HU) requerida Comprobación del diseño creado Actualización del diseño de la base de datos Verificación del diseño de la base de datos Crear el diseño del formulario para la actualización de usuarios Codificación de la funcionalidad (HU) requerida Comprobación del diseño creado Actualización del diseño de la base de datos Verificación del diseño de la base de datos Crear el diseño del formulario para restaurar contraseñas Codificación de la funcionalidad (HU) requerida Comprobación del diseño creado Configuración parámetros inicio de sesión

2 3

Codificación del control de caducidad de sesión Verificación y validación de la funcionalidad.

Nota: Datos obtenidos de la investigación de campo

1 3

Terminado

4 4 2 4 Terminado 8 3 2 3 1 Terminado 3 4 2 1 2 Terminado 2 1 1

Terminado

5.2.1.2.2 Sprint Execution. En la ejecución (Figuras 26 y 27) se ha realizado pequeños prototipos del incremento (de sistema) a crear durante el sprint y se empieza con la codificación de los mismos.

Figura 26. Prototipo interfaz de inicio.

Figura 27. Prototipo del Login de Usuario.

5.2.1.2.3 Sprint Review. La revisi贸n del sprint se realiza presentando el incremento del producto final hasta el cumplimiento de todas las historias de usuario seleccionadas para realizarse durante el sprint. Se presentan las interfaces (Figuras 28, 29, 30 y 31) correspondientes a cada historia de usuario con su correspondiente funcionalidad, todo ello con la revisi贸n del Product Owner y posterior aprobaci贸n.

Figura 28. Interfaz Principal del sistema.

Figura 29. Interfaz principal de administraci贸n.

Figura 30. Administración de Usuarios.

Figura 31. Formulario para ingresar nuevos usuarios.

5.2.1.2.4 Sprint Retrospective. Es en esta etapa (retrospective) donde se evalúan puntos a mejorar y consideraciones generales respecto al equipo de trabajo y al desarrollo de la aplicación. Se concluye que gracias a Scrum se puede realizar trabajos de forma distribuida, sin necesidad de estar el equipo de desarrollo en un mismo lugar, y con la capacidad de realizar integraciones del sistema sin problema alguno. De igual forma se valora la utilidad del framework Materialize dado que permite crear interfaces más intuitivas y adaptativas.

5.2.1.3. Sprint 2. 5.2.1.3.1 Sprint Planning. El Sprint Backlog (Tabla 15) que recoge las historias de usuario del sprint 2 relacionadas con la administración de proyectos. Tabla 15 Sprint Backlog del sprint 2 Sprint Backlog 2 Objetivo del Sprint: Desarrollar y desplegar funcionalidad respecto a la administración de proyectos ESTHU TAREAS DE INGENIERÍA EST-TI ESTADO HU Actualización del diseño de la base de datos 4 Verificación del diseño de la base de datos 2 Registro de Crear el diseño del formulario para el ingreso de 21 4 Terminado proyecto nuevos proyectos Codificación de la funcionalidad requerida 8 Comprobación del diseño creado 3 Configuración del entorno de trabajo 1 Configuración del espacio y ruta del archivo que la Almacenamiento 2 base de datos recibirá. de información 8 Terminado Verificación del diseño de la base de datos 2 digitalizada de Crear interfaces de usuario para el acceso al sistema 2 proyectos Codificación de la funcionalidad (HU) requerida 1 Actualización del diseño de la base de datos 1 Verificación del diseño de la base de datos 2 Modificación de Crear el diseño del formulario para la modificación de 8 2 Terminado un proyecto un proyecto Codificación de la funcionalidad (HU) requerida 2 Comprobación del diseño creado 1 Actualización del diseño de la base de datos 1 Visualización de Verificación del diseño de la base de datos 1 información Diseñar el formulario para la visualización de los 5 1 Terminado digitalizada de archivos subidos al servidor cada proyecto Codificación de la funcionalidad (HU) requerida 1 Comprobación del diseño creado 1 Actualización del diseño de la base de datos 2 Visualización del Verificación del diseño de la base de datos 3 informe de Crear el diseño del formulario para visualizar el 13 1 Terminado estado de cada estado del proyecto proyecto Codificación de la funcionalidad (HU) requerida 3 Comprobación del diseño creado 4 Verificación del diseño de la base de datos 1 Eliminación de Diseño de interfaz de eliminación 2 8 Terminado un proyecto Codificación de la funcionalidad (HU) 3 Comprobación y validación de la funcionalidad 2 Nota: Datos obtenidos de la investigación de campo

5.2.1.3.2 Sprint Execution. Se presenta un prototipo del ingreso de proyectos (Figuras 32 y 33) y se empieza con la respectiva codificaciรณn de las historias de usuario contenidas en el sprint Backlog.

Figura 32. Prototipo de la interfaz de Proyectos.

Figura 33. Codificaciรณn del apartado Proyectos.

5.2.1.3.3 Sprint Review. Interfaz para el ingreso de datos y archivos digitales (Figura 34) correspondientes a los proyectos.

Figura 34. Interfaz formulario de ingreso de Proyectos.

Tabla para la visualización de datos y acciones de los proyectos (Figura 35)

Figura 35. Interfaz Estado del Proyecto.

5.2.1.3.4 Sprint Retrospective. La Retrospectiva en el presente sprint consistió en constatar la satisfacción del cliente con el producto, y en acoger pequeñas sugerencias respecto a las interfaces de usuario.

5.2.1.4. Sprint 3. 5.2.1.4.1 Sprint Planning. El Sprint Backlog (Tabla 16) que recoge las historias de usuario del sprint 3 relacionadas con la administración complementaria de proyectos y generación de planillas. Tabla 16 Sprint Backlog del sprint 3 Sprint Backlog 3 Objetivo del Sprint: desarrollar y desplegar funcionalidad respecto a administración complementaria del proyecto y generación de informe de planillas. HU ESTTAREAS DE INGENIERÍA EST-TI ESTADO HU 5 Configuración del entorno de trabajo 1 Terminado Acceso a Creación de entidades en la base de datos 1 opciones relacionadas con la historia de usuario complementaria Verificación del diseño de la base de datos 1 s para un Crear interfaces de usuario para el acceso a las 1 proyecto opciones complementarias Codificación de la funcionalidad (HU) requerida 1 21 Creación de entidades en la base de datos 4 Terminado Generación de relacionadas con la historia de usuario Planillas por Verificación del diseño de la base de datos 2 cada proyecto Crear el diseño del formulario para completar la 4 información de las planillas generadas Codificación de la funcionalidad (HU) requerida 8 Comprobación del diseño creado 3 8 Configuración del entorno de trabajo 1 Terminado Generación de informe individual de las planillas

Ingreso de Incrementos en el proyecto

Ingreso de prórrogas en el proyecto

Utilización de librería para exportación de documentos digitales Creación del diseño y Codificación de la funcionalidad (HU) requerida Comprobación y validación de la funcionalidad

Actualización del diseño de la base de datos Verificación del diseño de la base de datos Crear el diseño del formulario para el ingreso de incrementos de un proyecto Codificación de la funcionalidad (HU) requerida Comprobación del diseño creado Actualización del diseño de la base de datos Verificación del diseño de la base de datos Crear el diseño del formulario para el ingreso de prórrogas Codificación de la funcionalidad (HU) requerida Comprobación del diseño creado

2 3 2

Nota: Datos obtenidos de la investigación de campo

3 1

4 2 2 3 2 4 2

Terminado

5.2.1.4.2 Sprint Execution. Se presenta un pequeño prototipo del ingreso de proyectos, y se empieza con la respectiva codificación de las historias de usuario contenidas en el sprint Backlog (Figuras 36 y 37).

Figura 36. Prototipo de interfaz con opciones complementarias.

Figura 37. Codificación del apartado Incrementos.

5.2.1.4.3 Sprint Review. Se presentan las interfaces (Figuras 38, 39 y 40) con la funcionalidad descrita en la Historia de Usuario.

Figura 38. Opciones complementarias.

Figura 39. Interfaz formulario de Planillas.

Figura 40. Interfaz formulario de prĂłrrogas.

5.2.1.4.4 Sprint Retrospective. La retrospectiva de este sprint nos da como resultado el haber cumplido el plazo del sprint y con la funcionalidad aportada en el incremento correspondiente. AdemĂĄs, se implementaron las pequeĂąas sugerencias respecto a las interfaces dadas en el sprint anterior.

5.2.1.5. Sprint 4. 5.2.1.5.1 Sprint Planning. El Sprint Backlog (Tabla 17) que recoge las historias de usuario del sprint 4 relacionadas con la el ingreso de actas y generación de informes. Tabla 17. Sprint Backlog 4 Sprint Backlog 4 Objetivo del Sprint: desarrollo y despligue de la funcionalidad respecto al ingreso de actas y generación de informes. HU

EST-HU

TAREAS DE INGENIERÍA

EST-TI

Verificación del diseño de la base de datos Presentación resumida de los datos del proyecto

Ingreso de Actas de Recepción de cada proyecto

Reporte general de proyectos

Reporte individual de proyectos

Reporte de fiscalizadores

Crear el diseño del formulario presentación de la información

para

1 la

2 Terminado

Codificación de la funcionalidad requerida

Comprobación del diseño creado

Actualización del diseño de la base de datos Verificación del diseño de la base de datos Crear el diseño del formulario para el ingreso de nuevos proyectos Codificación de la funcionalidad requerida Comprobación del diseño creado Configuración del entorno de trabajo Utilización de librería para exportación de documentos digitales Creación del diseño y Codificación de la funcionalidad (HU) requerida

2 3

Comprobación y validación de la funcionalidad

Configuración del entorno de trabajo

Utilización de librería para exportación de documentos digitales Creación del diseño y Codificación de la funcionalidad (HU) requerida

2 Terminado 3

3 Terminado 5 3

Configuración del entorno de trabajo

Utilización de librería para exportación de documentos digitales Creación del diseño y Codificación de la funcionalidad (HU) requerida Comprobación y validación de la funcionalidad

Terminado

4 2 1

Comprobación y validación de la funcionalidad

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

ESTADO

2 3 2

Terminado

5.2.1.5.2 Sprint Execution. Se realiza un pequeño prototipo las interfaces, y se empieza con la respectiva codificación de las historias de usuario contenidas en el sprint Backlog (Figuras 41 y 42).

Figura 41. Prototipo de interfaz con resumen del proyecto.

Figura 42. Codificación del reporte general de proyectos.

5.2.1.5.3 Sprint Review. En la etapa de revisiรณn del sprint 4 se presentรณ la codificaciรณn del resumen solicitado por el Product Owner y de los reportes (informes) que necesitaba el sistema para complementar su funcionamiento (Figuras 43, 44 y 45).

Figura 43. Interfaz de la presentaciรณn resumida de informaciรณn del proyecto.

Figura 44. Reporte general de proyectos.

Figura 45. Reporte individual por proyecto.

5.2.1.5.4 Sprint Retrospective. La finalidad de la retrospectiva en este último sprint ha sido para realizar una autoevaluación del equipo de desarrollo, destacando de forma general todos los aspectos que han permitido que el equipo funcione de manera adecuada y cumpla con los objetivos del sprint, y por ultimo ver la funcionalidad completa del sistema. Además se evidencia la integración y funcionamiento final de todos los componentes del sistema que los desarrolladores han realizado durante el transcurso del proyecto.

5.3 Análisis de Impacto. La evaluación del impacto que se realiza sobre un determinado proyecto sirve para determinar qué tipo de efecto se manifiesta sobre el entorno en que se ha desarrollado. Son varios los factores a considerar cuando se aborda un análisis de impactos, pero en la presente investigación se ha trabajado con los siguientes indicadores: tecnológico, social, económico y ambiental. A continuación se presenta (Tabla 18) en donde se muestra la escala de valoración de los impactos y su equivalencia.

70 Tabla 18. Escala de los niveles de impactos Nivel -3 -2 -1 0 1 2 3

DescripciĂłn Impacto de alto nivel negativo Impacto de medio nivel negativo Impacto de bajo nivel negativo No hay impacto Impacto de bajo nivel positivo Impacto de medio nivel positivo Impacto de alto nivel positivo

Nota: Adaptado de MetodologĂa para el trabajo de grado (tesis y proyectos) por Posso, M., 2009 ÎŁ

El nivel de impacto total (NI) se lo determina de la siguiente manera: đ?&#x2018; đ??ź = đ?&#x2018; Â° Es decir: Nivel de Impacto = total sumatoria de impactos (ÎŁ) dividido para la cantidad de indicadores (đ?&#x2018; Â°) 5.3.1 Impacto TecnolĂłgico. Este impacto (Tabla 19) permite identificar los factores tecnolĂłgicos que se mejoran en la empresa. Tabla 19. Impactos TecnolĂłgicos. Indicadores

-3

Niveles de Impacto -1 0 1

-2

ď&#x192;ź -

Equivalencia

â&#x2C6;&#x2018;=5

Sumatoria Resultado

3 ď&#x192;ź

Avance TecnolĂłgico AutomatizaciĂłn y OrganizaciĂłn de procesos e informaciĂłn Total

5 = 2.5 2 Impacto de Alto Nivel Positivo đ?&#x2018; đ??ź =

Nota: Tomado de los datos obtenidos de la investigaciĂłn de campo.

AnĂĄlisis: con el desarrollo e implementaciĂłn del proyecto se genera un avance tecnolĂłgico en la empresa dado que se la moderniza, haciendo que sus procesos se automaticen y se los lleve de manera digital, consiguiendo con ello que tanto los procesos como su informaciĂłn estĂŠn organizados y disponibles, su acceso sea mĂĄs rĂĄpido y exista fiabilidad en sus operaciones.

5.3.2 Impacto Ambiental. Este impacto (Tabla 20) permite identificar los factores ambientales con que contribuye el sistema dentro de la empresa. Tabla 20. Impacto Ambiental Niveles de Impacto Indicadores Menor uso de materiales de oficina (papeles, carpetas, etc.) Total

-3

-2

-1

ď&#x192;ź -

â&#x2C6;&#x2018;=3 2 đ?&#x2018; đ??ź = = 2 1 Impacto de Medio Nivel Positivo

Sumatoria Resultado Equivalencia

Nota: Tomado de los datos obtenidos de la investigaciĂłn de campo.

AnĂĄlisis: se tiene un impacto positivo respecto al ser amigable con el medio ambiente, dado que al emplear un sistema informĂĄtico se emplearĂĄ en menor medida folios, esferos, carpetas, etc., todo aquellos materiales que eran utilizados en la gestiĂłn documental. 5.3.3 Impacto Social. Este impacto (Tabla 21) analiza los aspectos sociales que se mejoran dentro del personal de la empresa. Tabla 21. Impacto Social Niveles de Impacto Indicadores

-3

-2

-1

ď&#x192;ź

Mejora las actividades del trabajo ď&#x192;ź

Facilidad de buscar informaciĂłn

ď&#x192;ź

Resguardo de la informaciĂłn -

Total

Sumatoria Resultado Equivalencia

â&#x2C6;&#x2018;=7 8 đ?&#x2018; đ??ź = = 2.6 3 Impacto de Alto Nivel Positivo

Nota: Tomado de los datos obtenidos de la investigaciĂłn de campo.

AnĂĄlisis: con el sistema se mejora la productividad de la persona, se hace un uso eficiente del tiempo y las actividades se reducen.

5.3.4 Impacto EconĂłmico. Este impacto (Tabla 22) permite identificar la contribuciĂłn en el aspecto econĂłmico que realiza el sistema en la empresa. Tabla 22. Impacto EconĂłmico Niveles de Impacto Indicadores

-3

-2

-1

ď&#x192;ź

Ahorro en materiales de oficina ď&#x192;ź

Ahorro en software a la medida -

Total

â&#x2C6;&#x2018;=5 5 đ?&#x2018; đ??ź = = 2.5 2 Impacto de alto nivel positivo

Sumatoria Resultado Equivalencia Nota: Tomado de los datos obtenidos de la investigaciĂłn de campo.

AnĂĄlisis: se ahorra en los materiales de oficina, el dinero destinado a ello puede ser utilizado en otras actividades empresariales. AdemĂĄs, el costo del software es cero por el hecho de ser un convenio con la colectividad (Comunidad) 5.3.5 Impacto General. El impacto general (Tabla 23) unifica los anĂĄlisis de cada impacto anteriormente mencionado, obteniendo un anĂĄlisis general. Tabla 23. Impacto General Niveles de Impacto Indicadores

-3

-2

-1

3 ď&#x192;ź

Impacto TecnolĂłgico ď&#x192;ź

Impacto Ambiental Impacto Social

ď&#x192;ź

Impacto EconĂłmico

ď&#x192;ź

Total

Sumatoria Resultado Equivalencia Nota: Tomado de los datos obtenidos de la investigaciĂłn de campo.

â&#x2C6;&#x2018; = 11 11 đ?&#x2018; đ??ź = = 2.75 4 Impacto de alto nivel positivo

AnĂĄlisis: El impacto general del proyecto (en si del sistema) es altamente positivo, evidenciando que se marca una diferencia entre el antes y el despuĂŠs con la llegada del sistema para realizar los procesos administrativos y de control respecto a los proyectos.

6. DISCUSIÓN Después de haber estudiado, descrito y analizado todos los resultados que se han obtenido en la presente investigación, tanto resultados metodológicos como resultados de la aplicación de Scrum, se procede a realizar la discusión de los mismos de acuerdo con la temática de la investigación, al mismo tiempo que suponga futuras líneas de investigación. En conformidad con la problemática planteada en la presente investigación se deriva el estudio realizado por parte de los investigadores en el Departamento de Desarrollo de Infraestructura de EPMAPA –SD en donde, a partir de la convivencia y posterior levantamiento de información se evidencia la carencia de un soporte tecnológico (sistema informático) que lleve el control de los proyectos realizados por la empresa. A través de la muestra seleccionada en el departamento y de acuerdo con los resultados obtenidos en la investigación de campo se comprueba que la gran mayoría de las personas experimentan dificultad con el acceso a la información referente a los proyectos, ya sea para identificar su estado de avance, personal encargado del mismo, entre otra información vital que, hasta antes de realizar el presente trabajo de grado, se realizaba de manera manual, consultando en los archivadores físicos, donde la información era propensa a perderse o deteriorarse. Conforme a lo anterior se puede decir que tanto las personas encargadas de las actividades antes expuestas, sienten la necesidad de implementar un sistema informático que automatice y mejore la manera en cómo se llevan los procesos que se realizan en dicho departamento. Además que beneficie a la empresa de forma que el tiempo se optimice y de este modo la productividad del personal no se vea comprometida. Asimismo se denota una amplia mayoría respecto al manejo de sistemas informáticos en donde la tendencia es positiva al tener una buena acogida frente a la implementación de los mismos. Por otro lado, con respecto a los resultados de la aplicación de metodologías de desarrollo de software, y en el caso de la presente investigación, el empleo de un marco de trabajo (framework) que los investigadores han descrito en el presente documento, se determina utilizar uno con enfoque ágil, como es el caso de Scrum, que de acuerdo con la indagación y las tablas comparativas que se han realizado, es la más empleada en la actualidad y es aquella que brindan grandes beneficios y un modelo de desarrollo flexible y adaptable.

Scrum ha resultado ser el mejor aliado en lo que respecta la gestión del desarrollo de un proyecto de software (aunque es aplicable a cualquier ámbito) dándonos un marco de trabajo en donde se puede trabajar de forma amigable, donde las cuestiones técnicas del desarrollo quedan en segundo plano y no se pierde tiempo en ello. Está claro que Scrum ha brindado la capacidad de trabajar de forma remota a los investigadores, aprovechando el espacio de trabajo y el tiempo útil dedicado al desarrollo de software, a diferencia de otras metodologías que no lo permiten. Los artefactos y por supuesto la forma de trabajo de Scrum (por medio de sprints de corta duración) ha permitido desarrollar un sistema informático

que cumpla con las

especificaciones dadas por el cliente, y que este último posea un producto funcional al final de cada sprint para que pueda revisarlo y a su vez ponerlo en producción si así lo decide. Dado la terminación del desarrollo, se puede constatar que el software cumple a cabalidad las expectativas del cliente, y se constata que éste a su vez provoca un impacto positivo en el funcionamiento de la empresa. En relación a las limitaciones y/o dificultades que se hicieron presentes en la investigación, fue el poco tiempo disponible para realizar el desarrollo del sistema y su posterior análisis de impacto en la empresa en cuestión. Otra limitación que se tuvo ha sido conseguir que todos los empleados del departamento estén presentes durante el desarrollo de la Encuesta dado que cada uno tiene funciones específicas y no coincidían los tiempos. Para futuros trabajos en la misma línea de investigación, se sugiere realizar un análisis de métodos ágiles y herramientas ágiles para el desarrollo de software, dado que así se conocería si existe alguna relación favorable que simplifique el tiempo de desarrollo de sistemas.

7. CONCLUSIONES 

Se concluye que con el desarrollo y posterior implementación del sistema en el

Departamento de Desarrollo de Infraestructura de la Empresa Pública de Agua Potable y Alcantarillado los procesos correspondientes a la administración y gestión de proyectos se realizan de forma automatizada y de forma más eficiente, consiguiendo con ello la optimización del tiempo y un mejor control sobre los proyectos y su información. 

Se determina que Scrum es un marco de trabajo ágil que se adapta a proyectos

de cualquier escala, principalmente en aquellos donde los requerimientos son cambiantes. Scrum pone especial énfasis en la gestión del proyecto y deja a un lado (y a criterio del equipo de desarrollo) los aspectos técnicos que se involucran en el desarrollo. Es un marco de trabajo que se desarrolla por medio de sprints de corta duración (1 a 4 semanas) en donde cada finalización del sprint se entrega un producto totalmente funcional y operativo. 

Las herramientas empleadas ayudaron a un rápido desarrollo y despliegue del

sistema informático, gracias a la facilidad de uso, de aprendizaje, portabilidad y flexibilidad que posee el lenguaje php para el desarrollo web; la base de datos MySQL por ser escalable, potente y sencilla; apache web server por ser un servidor que brinda un rendimiento superior a otros del mercado; y MaterializeCSS por ofrecer librerías y componentes que permiten realizar un apartado visual amigable con el usuario final. 

Se desarrolló el sistema web acorde a lo establecido en las funcionalidades con

un diseño agradable para los usuarios, haciendo fácil su uso de tal manera que los mismos puedan trabajar sin inconvenientes.

8. RECOMENDACIONES 

Seleccionar las metodologías de desarrollo de software haciendo un análisis

previo y conforme a la naturaleza del proyecto a desarrollar. 

Escoger herramientas de desarrollo open-source, que brindan las mismas

(incluso superiores) prestaciones a software de pago. 

Estudiar a fondo y comprender adecuadamente todos los aspectos relacionados

con el marco de trabajo Scrum, como los roles involucrados, las actividades y los artefactos generados, y de esta manera aplicarlo correctamente en un determinado proyecto. 

Recoger todas las sugerencias que surjan en las Revisiones y Retrospectivas que

se llevan a cabo al finalizar un sprint, con la finalidad de realizar la mejora continua en el equipo de trabajo.

9. LISTA DE REFERENCIAS Agile

Alliance. (2017). Agile 101: A Short https://www.agilealliance.org/agile101/

History

Agile.

Obtenido

Aitken, A., & Ilango, V. (2013). A Comparative Analysis of Traditional Software Engineering and Agile Software Development. System Sciences (HICSS), 2013 46th Hawaii International Conference (págs. 4751-4760). Maui: IEEE. Obtenido de https://pdfs.semanticscholar.org/6fb5/bf372782860a799cd8e9a94e77b371a9c2d2.pdf Alejandro, C. (2015). Implementación de un sistema de información, control y seguimiento de obras civiles para el departamento de obras públicas del gobierno autónomo descentralizado municipal del Cantón La Libertad. (tesis de grado), Universidad Estatal Península de Santa Elena, La Libertad, Ecuador. Obtenido de http://repositorio.upse.edu.ec/handle/46000/2489 Alshamrani, A., & Bahattab, A. (2015). A Comparison Between Three SDLC Models Waterfall Model, Spiral Model, and Incremental/Iterative Model. International Journal of Computer Science Issues, 12(1), 106-111. Obtenido de http://www.ijcsi.org/papers/IJCSI-12-1-1-106-111.pdf Álvarez, A., De las Heras del Dedo, R., & Lasa, C. (2012). Métodos Ágiles y Scrum. Madrid: Anaya. Amavizca , L., García, A., Jiménez, E., Duarte , G., & Vázquez , J. (2014). Aplicación de la metodología semi-ágil ICONIX para el desarrollo de software: implementación y publicación de un sitio WEB para una empresa SPIN-OFF en el Sur de Sonora, México. Twelfth LACCEI Latin American and Caribbean Conference for Engineering and Technology (LACCEI’2014), (pág. 10). Guayaquil. Obtenido de http://www.laccei.org/LACCEI2014-Guayaquil/RefereedPapers/RP246.pdf Amaya, Y. (2013). Metodologías ágiles en el desarrollo de aplicaciones para dispositivos móviles. Estado actual. Revista de Tecnología, 111-123. Obtenido de https://dialnet.unirioja.es/descarga/articulo/6041502.pdf Anwer, F., Aftab, S., Muhammad, S., & Waheed, U. (2017). Comparative Analysis of Two Popular Agile Process Models: Extreme Programming and Scrum. International Journal of Computer Science and Telecommunications, 8(2), 1-7. Obtenido de http://www.ijcst.org/Volume8/Issue2/p1_8_2.pdf Babar, M., Brown, A., & Mistrik, I. (Edits.). (2013). Agile software architecture: aligning agile processes and software architectures. Waltham, Massachusetts: Elsevier Science. Obtenido de https://ebookcentral.proquest.com Baena, G. (2014). Metodología de la Investigación. México: Grupo Editorial Patria. Obtenido de https://ebookcentral.proquest.com Bernal, C. (2010). Metodología de la Investigación. Colombia: Pearson Educación. Borda, M. (2013). El proceso de Investigación: Visión general de su desarrollo. Barranquilla: Editorial Universidad del Norte.

Braude, E., & Bernstein, M. (2016). Software Engineering: Modern Approaches. Long Grove, Illinois: Waveland Press. Obtenido de https://ebookcentral.proquest.com Brito, K., Sosa, D., & Héctor, K. (2015). Selección de Metodologías de Desarrollo para Aplicaciones Web. USA: Editorial Académica Española. Camacho, J., & Palma, A. (2016). Desarrollo e implementación de una aplicación para la gestión de la información del Centro de Faenamiento Municipal del Cantón Pedro Vicente Maldonado GADMCPVM para el Departamento de Gestión y Desarrollo Sustentable durante el periodo 2015-2016. (tesis de grado), Pontificia Universidad Católica del Ecuador, Santo Domingo, Ecuador. Obtenido de https://issuu.com/pucesd/docs/palma_-_camacho_ Cardador, A. (2014). Implantación de aplicaciones web en entornos internet, intranet y extranet (MF0493_3). Málaga, España: IC Editorial. Obtenido de https://ebookcentral.proquest.com Chang,

A., & Wang, A. (2017). https://www.patreon.com/materialize

Materialize:

Overview.

Obtenido

Chicano, E. (2013). Utilización de las bases de datos relacionales en el sistema de gestión y almacenamiento de datos: UF0348. Málaga, España: IC Editorial. Obtenido de https://ebookcentral.proquest.com Cobb, C. (2015). The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach. Hoboken, New Jersey: John Wiley & Sons, Inc. Obtenido de https://ebookcentral.proquest.com Contreras, M. (2016). Desarrollo de Aplicaciones Web Multiplataforma. Madrid, España: Ministerio de Educación de España. Obtenido de https://ebookcentral.proquest.com Cooke, J. (2012). Everything you want to know about Agile. Cambridgeshire, UK: IT Governance Publishing. Obtenido de https://ebookcentral.proquest.com Cruz, C., Olivares, S., & González, M. (2014). Metodología de la Investigación. México: Grupo Editorial Patria. Obtenido de http://ebookcentral.proquest.com Cusick, J. (2013). Durable Ideas in Software Engineering: Concepts, Methods and Approaches from My Virtual Toolbox. New York: Bentham E-Books. Obtenido de https://ebookcentral.proquest.com Davis, B. (2013). Mastering Software Project Requeriments: A Framework for Successful Planning, Development & Alignment. USA: J.Ross Publishing. Obtenido de https://ebookcentral.proquest.com Elshandidy, H., & Mazen, S. (2013). Agile and Traditional Requirements Engineering: A Survey. International Journal of Scientific & Engineering Research, 4(9), 473-482. Obtenido de https://www.researchgate.net/profile/Heba_Elshandidy/publication/258046916_Agile _and_Traditional_Requirements_Engineering_A_Survey/links/00b49526bcfd9a7bdc0 00000/Agile-and-Traditional-Requirements-Engineering-A-Survey.pdf

Fernández, Y., & Díaz, Y. (2012). Patrón Modelo-Vista-Controlador. Telem@tica, 11(1), 4757. Obtenido de http://revistatelematica.cujae.edu.cu/index.php/tele/article/view/15/10 Ferrer, J. (2014). Implantación de Aplicaciones Web. Madrid, España: Ra-Ma. Girvan, L. (2014). Lifecycle Types and Their Rationales. En T. Ahmed, J. Cox, & J. Cadle (Ed.), Developing Information Systems: Practical guidance for IT professionals (págs. 8-34). Swindon, UK: BCS. Obtenido de https://ebookcentral.proquest.com Gómez, C., Álvarez, G., Romero, A., Castro, F., Vega, V., Comas, R., & Velázquez, M. (2017). La investigación científica y las formas de titulación: Aspectos conceptuales y prácticos. Quito: Editorial Jurídica del Ecuador. González, M., Alba, E., & Ordieres, M. (2014). Ingeniería de proyectos. Madrid, España: Dextra Editorial. Obtenido de https://ebookcentral.proquest.com Granados, L. (2014). Desarrollo de aplicaciones web en el entorno servidor (UF1844). Málaga, España: IC Editorial. Obtenido de https://ebookcentral.proquest.com Hernández, R., Fernández, C., & Baptista, M. (2014). Metodología de la Investigación. México: McGrawHill. Hidalgo, A., León, G., & Pavón, J. (2013). La gestión de la innovación y la tecnología en las organizaciones. Madrid: Difusora Larousse - Ediciones Pirámide. Obtenido de https://ebookcentral.proquest.com Hueso, L. (2014). Base de Datos. Madrid, España: RA-MA Editorial. Obtenido de https://ebookcentral.proquest.com Levy, R., Short, M., & Measey, P. (2015). Agile foundations: principles, practices and frameworks. Swindon: BSC. Obtenido de https://ebookcentral.proquest.com López, J., & Alcayde, A. (2014). Construcción de páginas web. Madrid, España: RA-MA Editorial. Obtenido de https://ebookcentral.proquest.com López, M., Vara, J., Verde, J., Sánchez, D., Jiménez, J., & de Castro, V. (2014). Desarrollo Web en Entorno Servidor. Madrid, España: RA-MA. Marco Simó , J., & Marco Galindo, M. (2013). Sistemas de información (en las organizaciones). Barcelona, España: Editorial UOC. Matharu, G., Mishra, A., Singh, H., & Upadhyay, P. (2015). Empirical study of agile software development methodologies: A comparative analysis. ACM SIGSOFT Software Engineering Notes, 40(1). doi:10.1145/2693208.2693233 Microsoft. (2017). Microsoft Solutions Framework (MSF) Overview. Obtenido de https://msdn.microsoft.com/en-us/library/jj161047(v=vs.120).aspx Moreno, J. (2014). Programación. https://ebookcentral.proquest.com

Madrid:

RA-MA

Editorial.

Obtenido

Morien, R. (2014). Back to Basics: In Support of Agile Development. En I. Ghani, W. Nasir Wan Kadir, & M. Nazir Ahmad (Edits.), Handbook of Research on Emerging Advancements and Technologies in Software Engineering (págs. 279-292). Hershey, Pensilvania: IGI Global. Obtenido de https://ebookcentral.proquest.com Mozilla . (2017). What is HTML? Obtenido de https://developer.mozilla.org/enUS/docs/Learn/HTML/Introduction_to_HTML/Getting_started MySQL. (2017). Why MySQL? Obtenido de https://www.mysql.com/why-mysql/ Niño, V. (2011). Metodología de la investigación. Bogotá: Ediciones de la U. Ollero, C. (2015). Metodología de programación en páginas web. Madrid: Editorial CEP. Obtenido de https://ebookcentral.proquest.com Oracle.

(2017). Oracle Database Editions. Obtenido https://docs.oracle.com/database/121/DBLIC/editions.htm#DBLIC109

Paladines, D., & Pantoja, J. (2016). Desarrollo e implementación de un sistema de gestión de proyectos para el departamento de sistemas del CONCLISAN CIA. LTDA. en la provincia de Santo Domingo de los Tsáchilas. (tesis de grado), Pontificia Universidad Católica del Ecuador, Santo Domingo, Ecuador. Obtenido de https://issuu.com/pucesd/docs/trabajo_de_titulacion__paladines_-_ Palladino, E. (2014). Administración y gestión de proyectos. Buenos Aires, Argentina: Espacio Editorial. Obtenido de https://ebookcentral.proquest.com Perez, M. (2015). Lenguajes de Programación Orientada a Objetos. San Bernardino: CreateSpace. Pop, D.-P., & Altar, A. (2014). Designing an MVC Model for Rapid Web Application Development. Procedia Engineering, 69, 1172-1179. doi:10.1016/j.proeng.2014.03.106 Posso, M. (2009). Metodología para el trabajo de grado ( tesis y proyectos ). Ibarra: Cámara Ecuatoriana del Libro - Núcleo de Pichincha. Pressman, R. (2010). Ingeniería del Software: Un enfoque práctico. México: McGraw-Hill. Quishpe, J. (2013). Automatización del seguimiento de proyectos y contratos realizados en el Instituto Superior de Investigaciones (ISI), en la Facultad de Ingeniería en Geología, Minas, Petróleos y Ambiental. (tesis de grado), Universidad Central del Ecuador, Quito, Ecuador. Obtenido de http://www.dspace.uce.edu.ec/handle/25000/1363 Reinosa, E., Maldonado, C., Muñoz, R., Damiano, L., & Abrutsky, M. (2012). Base de Datos. Buenos Aires, Argentina: Alfaomega. Rojas, M. (2009). Gerencia de la Construcción. Bogotá, Colombia: Ecoe Ediciones. Obtenido de https://ebookcentral.proquest.com

Schwaber, K., & Sutherland, J. (2017). The Definitive Guide to Scrum: The Rules of the Game. Obtenido de http://www.scrumguides.org/docs/scrumguide/v2017/2017-ScrumGuide-US.pdf#zoom=100 Scrum. (2017). What is Scrum? . Obtenido de https://www.scrum.org/resources/what-is-scrum Scrum

Alliance. (2016). Scrum Roles Demystified. Obtenido https://www.scrumalliance.org/agile-resources/scrum-roles-demystified

Software Engineering Institute. (2010). CMMI para Desarrollo, Versión 1.3. Obtenido de https://www.sei.cmu.edu/library/assets/whitepapers/Spanish%20Technical%20Report %20CMMI%20V%201%203.pdf Špundak, M. (2014). Mixed agile/traditional project management methodology – reality or illusion? Procedia-Social and Behavioral Sciences, 119, 939-948. Obtenido de 10.1016/j.sbspro.2014.03.105 Stephens, R. (2015). Beginning Software Engineering. Indianapolis: John Wiley & Sons, Inc. Obtenido de https://ebookcentral.proquest.com Taylor, A. (2013). SQL for dummies (Octava ed.). Hoboken, New Jersey, USA: John Wiley & Sons, Inc. Obtenido de https://ebookcentral.proquest.com The PHP Group. (2017). ¿Qué puede hacer PHP? Obtenido de http://php.net/manual/es/introwhatcando.php Torres Hernández, Z., & Torres Martínez, H. (2014). Administración de proyectos. México: Grupo Editorial Patria. Obtenido de https://ebookcentral.proquest.com Torres Hernández, Z., & Torres Martínez, H. (2014). Planeación y Control. México: Grupo Editorial Patria. Obtenido de https://ebookcentral.proquest.com Trejos, O. (2013). Propuesta Metodológica para desarrollar un programa con programación estructurada a partir del paradigma funcional. Ciencia e Ingeniería NeoGranadina, 23(2), 137-156. Valderrey, P. (2014). Administración de sistemas gestores de bases de datos. Madrid, España: RA-MA Editorial. Wells,

D. (2000). The Rules of Extreme Programming http://www.extremeprogramming.org/rules.html

Obtenido

Yépez, J. (2015). Sistema de planificación, seguimiento y control de proyectos académicos y su vinculación con el sector productivo para la Unidad de Educación Continua de la Facultad de Ciencias Administrativas. (tesis de grado), Universidad Central del Ecuador, Quito, Ecuador. Obtenido de http://www.dspace.uce.edu.ec/handle/25000/4346

10. GLOSARIO Apache: servidor web open-source (código abierto), multiplataforma y de uso gratuito. Es el programa encargado de atender y gestionar las peticiones que realizan los usuarios al acceder a un sitio o sistema web. EPMAPA: siglas representativas de la Empresa Pública Municipal de Agua Potable y Alcantarillado. Framework: también denominado entorno o marco de trabajo, es una estructura general de software empleada en la creación de sistemas informáticos acelerando su desarrollo. Materialize: framework de diseño web que se basa en la filosofía Material Design de Google. Provee características responsivas (adaptables al dispositivo) e interfaces de usuario ligeras y minimalistas. MVC: siglas del patrón Modelo-Vista-Controlador que es una forma o estilo de arquitectura de software en la cual se divide la aplicación en tres partes: el Modelo (lógica de negocio), la Vista (interfaces de usuario) y el Controlador (interacción del usuario) MySQL: sistema gestor de base de datos del tipo relacional. Provee un amplio abanico de características que la vuelven la base de datos más utilizada en el mundo PHP: siglas del PHP Hypertext Preprocessor (procesador de hipertexto), es un lenguaje de script que se ejecuta del lado del servidor, usado generalmente en el desarrollo web. SCRUM: metodología de desarrollo de software ágil. Sprint: en el contexto de las metodologías de desarrollo de software ágil, un sprint es un periodo de tiempo corto, generalmente no mayor a 4 semanas en donde se construye un incremento de software funcional. Stakeholders: es todo aquel grupo de personas que no participan directamente del proceso de desarrollo de un determinado proyecto, pero que deben ser tomadas en cuenta dado que son las personas interesadas en el mismo.

11. ANEXOS Anexo 1. Carta de solicitud de informaciรณn.

Anexo 2. Acta Entrega-Recepciรณn.

Anexo 3. Carta de Impacto.

Anexo 4. Entrevista realizada al Sub-Gerente de Desarrollo de Infraestructura de EPMAPA-SD.

PONTIFICIA UNIVERSIDAD CATร LICA DEL ECUADOR SEDE SANTO DOMINGO

ESCUELA DE SISTEMAS.

Entrevista dirigida al Sub-Gerente del Departamento de Desarrollo de Infraestructura de EPMAPA-SD

Objetivo de la Entrevista La presente entrevista se realiza con la finalidad de conocer todos los parรกmetros que intervienen dentro de la realizaciรณn de un proyecto realizado en EPMAPA-SD.

Datos Generales de la Entrevista:

Lugar de la entrevista: ____________________________________________________ Entrevistado: _________________

Cargo: _________________________________

Entrevistador: ________________

Fecha y Hora: ___________________________

1. ¿Cómo se gestiona un proyecto dentro del Departamento de Desarrollo de Infraestructura de EPMAPA-SD? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

2. ¿Cómo acceden a la información de los proyectos las personas interesadas en los mismos? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

3. ¿Cuál es el tiempo estimado de duración de un determinado proyecto? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

4. ¿Cuántas personas están involucradas en el proceso de control de la información de los proyectos? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

5. ¿Cómo se realiza el proceso de seguimiento de los proyectos? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

6. ¿Quién es la persona encargada de controlar y/o ejercer el seguimiento de los proyectos? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

7. ¿Dónde se encuentra toda la información referente a los proyectos? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

8. ¿Qué tipo de archivos se documentan en un determinado proyecto? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

9. ¿Qué tipo de reportes cree usted que debe emitir el sistema y que elementos deben contener? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

Anexo 5. Encuesta realizada al personal de EPMAPA-SD.

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO ESCUELA DE SISTEMAS.

Encuesta dirigida al personal del Departamento de Desarrollo de Infraestructura de EPMAPA-SD

Objetivo de la Encuesta La presente encuesta se realiza con la finalidad de conocer todos los parámetros que intervienen dentro de la realización de un proyecto realizado en EPMAPA-SD.

Instrucciones previas: 

Lea cuidadosamente todas las preguntas del cuestionario. Su información será confidencial y con fines académicos.



Todas las preguntas son de opción múltiple y sólo puede seleccionar una única alternativa.



Marque

con

check

()

respuesta

que

seleccione

1. ¿Cree usted que la forma de solicitar información de un proyecto dentro del Departamento de Desarrollo de EPMAPA-SD se realiza con facilidad y de manera rápida? ☐ SI

☐ NO

2. ¿Conoce el avance que posee un proyecto en particular durante la ejecución del mismo? ☐ SI

☐ NO

3. ¿Cree usted que es importante conocer los avances de todos los proyectos de manera general dentro de la empresa pública? ☐ SI

☐ NO

4. ¿Conoce de forma directa quién fiscaliza un proyecto en determinado lapso de tiempo? ☐ SI

☐ NO

5. ¿Cree usted que es necesario automatizar la gestión de proyectos dentro de la empresa pública? ☐ SI

☐ NO

6. Según su criterio. ¿Está de acuerdo con la implementación de un sistema que permita la gestión de los proyectos dentro de la empresa? ☐ SI

☐ NO

7. ¿Ha tenido alguna experiencia previa empleando algún tipo de sistema que permita gestionar información de forma digital? ☐ SI

☐ NO

8. Con la implementación del sistema. ¿Cree usted que se reducirá el tiempo de respuesta y aumentará la productividad del personal a cargo del sistema? ☐ SI

☐ NO

Anexo 6. Cronograma. CRONOGRAMA INVESTIGACIÓN APLICADA III 2017-02

ETAPAS (Especificar las actividades planificadas)

09/2017 10/2017 11/2017 12/2017 01/2018 02/2018 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

Socialización con el tutor responsable de IAIII Socialización del tema con la empresa EPMAPA-SD Elaboración del plan de trabajo de titulación Entrega del plan de trabajo de titulación Investigación de metodología Desarrollo de metodología Recopilación de información Selección de herramientas a utilizar Desarrollo de marco teórico Tabulación de información Creación de la base de datos Aprobación de la base de datos Diseño del sistema Aprobación del sistema Elaboración del sistema Pruebas del sistema Aprobaciones finales Entrega del sistema INVESTIGACIÓN APLICADA IV 2018-01 03/2018 ETAPAS (Especificar las actividades planificadas)

difusión

Entrega del Trabajo de Titulación para corrección de lectores Recepción del 100% de las correcciones Realizar las correcciones Entrega del correcciones

100%

05/2018

06/2018

07/2018

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1

Trabajo de Titulación al 100% Inicia proceso académica

04/2018

las

08/2018

2 3 4 1 2 3 4

93 Entrega de carta de impacto, certificaciรณn del tema, abstract, anillados, CDs.

Anexo 7. Presupuesto. RECURSOS

Desarrolladores

VALOR UNITAR IO 0,00

Computadoras

700,00

1400,00

Impresora

200,00

Tinta

10,00

40,00

Hojas

4,00

Esferos

0,50

4,00

Viรกticos

150,00

300,00

Internet

25,00

100,00

RECURSOS A UTILIZAR HUMANOS

MATERIALES

DESCRIPCIร N

CANT .

VALOR TOTAL 0,00

FINANCIEROS

OTROS GASTOS TOTAL

2048,00

Anexo 8. Modelo Lรณgico Base de Datos.

Anexo 9. Historias de Usuario. Historia de usuario Número: 1

Nombre: Interfaz principal de inicio del sistema

Usuario: todos Prioridad en negocio: Alta

Sprint asignado: 1

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Como un usuario quiero poder visualizar una interfaz de inicio para poder acceder al sistema

Observaciones: la interfaz debe contener imágenes representativas de la empresa. Criterios de Aceptación:  DADO la configuración previa del sistema, CUANDO el usuario abra un navegador web y digite la dirección correspondiente al sistema en la barra de direcciones, Entonces el sistema presentará la interfaz de presentación del sistema

Historia de usuario Número: 2

Nombre: Login de Usuario

Usuario: SuperAdmin/Fiscalizador/Veedor Prioridad en negocio: Alta

Sprint asignado: 1

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Como SuperAdmin/Fiscalizador/Veedor registrado quiero poder visualizar una interfaz de inicio para poder acceder al sistema de acuerdo a mi usuario registrado Observaciones: el inicio de sesión debe contener validaciones Criterios de Aceptación:  DADO el acceso a la interfaz de presentación del sistema, CUANDO el usuario SuperAdmin/Fiscalizador/Veedor presionen sobre el botón “Ir al Login”, Entonces el sistema lo redirigirá a la interfaz de inicio de sesión (Login de Usuario)  DADO el correcto ingreso de Usuario y Contraseña, CUANDO el usuario SuperAdmin/Fiscalizador/Veedor presione el botón “Ingresar”, ENTONCES el sistema lo redirigirá al panel principal  DADO el ingreso incorrecto de Usuario o Contraseña, CUANDO el usuario SuperAdmin/Fiscalizador/Veedor presione el botón “Ingresar”, ENTONCES el sistema mostrará un mensaje de error notificando del inconveniente.

Historia de usuario Número: 3

Nombre: Creación Usuarios

Usuario: SuperAdmin Prioridad en negocio: Alta

Sprint asignado: 1

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Como SuperAdmin quiero poder añadir nuevos usuarios en el sistema para que estos puedan administrarlo de acuerdo a sus permisos

Observaciones: el registro debe realizarse por medio de un formulario solicitando los datos básicos para identificar a cada usuario. Debe permitir seleccionar el perfil que poseerá el usuario registrado Criterios de Aceptación:  DADO el ingreso completo de los datos del usuario en el formulario de registro, CUANDO el usuario SuperAdmin presione sobre el botón “Guardar”, ENTONCES el sistema procederá a guardar los datos y presentará el mensaje “Usuario creado” confirmando la operación  DADO el ingreso incompleto (o en blanco) de los datos del usuario en el formulario de registro, CUANDO el usuario SuperAdmin presione sobre el botón “Guardar”, ENTONCES el sistema alertará al usuario de los campos del formulario de registro que hacen falta rellenar, resaltándolos en rojo.  DADO el ingreso repetido de datos (cédula, user, etc.) de usuario en el formulario de registro, CUANDO el usuario SuperAdmin presione sobre el botón “Guardar”, ENTONCES el sistema mostrará un mensaje de alerta informando de los campos repetidos.

Historia de usuario Número: 4

Nombre: Actualización de Usuarios

Usuario: SuperAdmin Prioridad en negocio: Alta

Sprint asignado: 1

Riesgo en desarrollo: Media

Puntos estimados: 3

Descripción: - Como SuperAdmin quiero poder modificar y/o actualizar los datos ingresados y el perfil correspondiente a un determinado usuario para poder mantener la información del mismo al día

Observaciones: el proceso debe simplificarse empleando interfaces amigables y se debe notificar de que la actualización se realizó con éxito. Criterios de Aceptación:  DADO la selección de un usuario determinado, CUANDO el usuario SuperAdmin presione sobre el botón “Editar”, ENTONCES el sistema abrirá el formulario de edición de usuarios.  DADO el ingreso completo de los datos en el formulario de edición, CUANDO el usuario SuperAdmin presione sobre el botón “Actualizar”, ENTONCES el sistema procederá a actualizar los datos y presentará el mensaje “Usuario Actualizado” confirmando la operación  DADO el ingreso incompleto (o en blanco) de los datos en el formulario de edición, CUANDO el usuario SuperAdmin presione sobre el botón “Actualizar”, ENTONCES el sistema alertará al usuario de los campos del formulario de registro que hacen falta rellenar, resaltándolos en rojo.  DADO el ingreso repetido de datos (cédula, user, etc.) en el formulario de edición, CUANDO el usuario SuperAdmin presione sobre el botón “Actualizar”, ENTONCES el sistema mostrará un mensaje de alerta informando de los campos repetidos.

Historia de usuario Número: 5

Nombre: Restablecimiento de contraseña

Usuario: SuperAdmin/Fiscalizador/Visor Prioridad en negocio: Alta

Sprint asignado: 1

Riesgo en desarrollo: Media

Puntos estimados: 8

Descripción: - Como SuperAdmin/Fiscalizador/Visor quiero restablecer la contraseña por medio de e-mail para acceder al sistema en caso de pérdida de password.

Observaciones: se enviará una contraseña temporal al correo electrónico registrado. Criterios de Aceptación:  DADO la pérdida de la Contraseña, CUANDO el usuario SuperAdmin/Fiscalizador/Visor presione sobre el botón “Restablecer Contraseña”, ENTONCES el sistema solicitará el correo electrónico que el usuario proporciono al registrarlo en el sistema para enviar la clave de acceso temporal.

100

Historia de usuario Número: 6

Nombre: Caducidad de la sesión

Usuario: SuperAdmin/Fiscalizador/Visor Prioridad en negocio: Alta

Sprint asignado: 1

Riesgo en desarrollo: Media

Puntos estimados: 5

Descripción: - Como SuperAdmin/Fiscalizador/Visor quiero que el sistema cierre automáticamente la sesión abierta para controlar el uso no autorizado del sistema

Observaciones: el sistema cerrará la sesión automáticamente luego de haber transcurrido 10 min de inactividad en el sistema Criterios de Aceptación:  DADO el acceso correcto al sistema, CUANDO el usuario SuperAdmin/Fiscalizador/Visor no lo utilice por aproximadamente 10 min, ENTONCES el sistema cerrará la sesión automáticamente para salvaguardar el uso no autorizado del mismo.

101

Historia de usuario Número: 7

Nombre: Registro de proyectos

Usuario: /Fiscalizador/ Prioridad en negocio: Alta

Sprint asignado: 2

Riesgo en desarrollo: Media

Puntos estimados: 21

Descripción: - Como /Fiscalizador quiero poder ingresar los proyectos que se realizan en la empresa para poder mantener un respaldo (registro) digital de los mismos.

Observaciones: el registro debe realizarse por medio de un formulario solicitando los datos generales que posee un proyecto. Al finalizar el ingreso se debe notificar el correcto ingreso del proyecto Criterios de Aceptación:  DADO el ingreso completo de los datos en el formulario de registro de proyectos, CUANDO el usuario Fiscalizador presione sobre el botón “Guardar”, ENTONCES el sistema procederá a guardar los datos y presentará el mensaje “Proyecto Registrado” confirmando la operación  DADO el ingreso incompleto (o en blanco) de los datos en el formulario de registro de proyectos, CUANDO el usuario Fiscalizador presione sobre el botón “Guardar”, ENTONCES el sistema alertará al usuario de los campos del formulario de registro de proyectos que hacen falta rellenar, resaltándolos en rojo.  DADO el ingreso repetido de en el formulario de registro de proyectos, CUANDO el usuario Fiscalizador presione sobre el botón “Guardar”, ENTONCES el sistema mostrará un mensaje de alerta informando de los campos repetidos.

102

Historia de usuario Número: 8

Nombre: Almacenamiento de información digitalizada de proyectos

Usuario: /Fiscalizador/ Prioridad en negocio: Media

Sprint asignado: 2

Riesgo en desarrollo: Baja

Puntos estimados: 8

Descripción: - Como /Fiscalizador/ quiero poder subir los ficheros (archivos digitales) que poseen los proyectos para complementar la información y mantener un respaldo de los mismos.

Observaciones: configurar el espacio y la ruta para el resguardo de los archivos digitales. El sistema solo deben permitir subir los archivos más relevantes que genera un proyecto determinado Criterios de Aceptación:  DADO el ingreso al formulario de registro de proyectos, CUANDO el usuario Fiscalizador seleccione el documento y presione “Subir”, ENTONCES el sistema abrirá el explorador del sistema operativo para permitir elegir el documento que se subirá al sistema guardándose en el servidor

103

Historia de usuario Número: 9

Nombre: Modificación de un proyecto

Usuario: /Fiscalizador/ Prioridad en negocio: Media

Sprint asignado: 2

Riesgo en desarrollo: Baja

Puntos estimados: 8

Descripción: - Como /Fiscalizador/ quiero poder modificar los datos de los proyectos para actualizar su información en caso de una equivocación.

Observaciones: se debe controlar las fechas de inicio (validar los documentos complementarios de cada proyecto) Criterios de Aceptación:  DADO la selección de un proyecto determinado, CUANDO el usuario Fiscalizador presione sobre el botón “Editar”, ENTONCES el sistema abrirá el formulario de edición de proyectos.  DADO el ingreso completo de los datos en el formulario de actualización de proyectos, CUANDO el usuario Fiscalizador presione sobre el botón “Actualizar”, ENTONCES el sistema procederá a actualizar los datos y mostrará el mensaje “Proyecto Actualizado”  DADO el ingreso incompleto (o en blanco) de los datos en el formulario de actualización de proyectos, CUANDO el usuario Fiscalizador presione sobre el botón “Actualizar”, ENTONCES el sistema alertará al usuario de los campos del formulario de actualización de proyectos que hacen falta rellenar, resaltándolos en rojo.  DADO la selección de nuevas fechas del proyecto en el formulario de actualización de proyectos, CUANDO el usuario Fiscalizador modifique las fechas, ENTONCES el sistema muestra la siguiente notificación: “Si se cambian las fechas, se generarán nuevas planillas”

104

Historia de usuario Número: 10

Nombre: Visualización de digitalizada de cada proyecto

información

Usuario: /Fiscalizador/ Prioridad en negocio: Media

Sprint asignado: 2

Riesgo en desarrollo: Baja

Puntos estimados: 5

Descripción: - Como /Fiscalizador/ quiero poder visualizar los archivos digitales subidos al sistema para poder comprobar/verificar que sean los correctos.

Observaciones: el acceso a estos archivos debe ser fácil, intuitiva y sencilla de usar. Criterios de Aceptación:  DADO la selección de un proyecto determinado, CUANDO el usuario Fiscalizador presione sobre el botón “Ver”, ENTONCES el sistema mostrará los tipos de documentos y permitirá ver los respectivos archivos digitales que se han subido al sistema

105

Historia de usuario

Número: 11

Nombre: Visualización del informe de estado de cada proyecto

Usuario: /Fiscalizador/ Prioridad en negocio: Media

Sprint asignado: 2

Riesgo en desarrollo: Media

Puntos estimados: 13

Descripción: - Como /Fiscalizador/ quiero poder visualizar el estado de un proyecto para poder verificar y controlar el avance de los mismos.

Observaciones: el sistema debe proporcionar el porcentaje de avance de la obra, el porcentaje de avance económico y los días restantes para su finalización. Criterios de Aceptación:  DADO la selección de un proyecto determinado, CUANDO el usuario Fiscalizador presione sobre el botón “Informe”, ENTONCES el sistema mostrará una ventana modal con información resumida del avance del proyecto seleccionado

106

Historia de usuario Número: 12

Nombre: Eliminación de un proyecto

Usuario: /Fiscalizador/ Prioridad en negocio: Media

Sprint asignado: 3

Riesgo en desarrollo: Baja

Puntos estimados: 8

Descripción: - Como /Fiscalizador/ quiero poder eliminar un proyecto para cambiar su estado y poder actualizarlo hasta nueva orden

Observaciones: el sistema no debe realizar la eliminación lógica del proyecto, sino un cambio de estado (activo/desactivado). Criterios de Aceptación:  DADO la selección de un proyecto determinado, CUANDO el usuario Fiscalizador presione sobre el botón “Eliminar”, ENTONCES el sistema desactivará la visualización (presentación) del proyecto en el sistema y lo mantendrá inactivo.

107

Historia de usuario Número: 13

Nombre: Acceso a opciones complementarias para un proyecto

Usuario: /Fiscalizador/ Prioridad en negocio: Media

Sprint asignado: 3

Riesgo en desarrollo: Baja

Puntos estimados: 5

Descripción: - Como /Fiscalizador/ quiero poder acceder a las opciones complementarias del sistema para poder completar la información de los proyectos ingresados.

Observaciones: el sistema debe permitir el acceso a las opciones complementarias de forma independiente, a través de un botón desde la lista general de proyectos. Criterios de Aceptación:  DADO la selección de un proyecto determinado, CUANDO el usuario Fiscalizador presione sobre el botón “Acceder”, ENTONCES el sistema lo redirigirá a la sección de opciones complementarias del proyecto seleccionado

108

Historia de usuario

Número: 14

Nombre: Generación de Planillas por cada proyecto

Usuario: /Fiscalizador/ Prioridad en negocio: Media

Sprint asignado: 3

Riesgo en desarrollo: Media

Puntos estimados: 21

Descripción: - Como /Fiscalizador/ quiero que el sistema genere automáticamente las planillas determinadas, para de este modo ir completando las planillas con los reajustes convenidos.

Observaciones: el sistema debe generar un máximo de 5 planillas por cada proyecto ingresado, debe generarse acorde a la planificación (fechas) del proyecto e ir calculando su avance. Criterios de Aceptación:  DADO el acceso a la información complementaria de un proyecto determinado, CUANDO el usuario Fiscalizador presione sobre el botón “Planillas”, ENTONCES el sistema mostrará de forma ordenada el número de planillas generadas automáticamente para el proyecto seleccionado  DADO la selección de la planilla de un proyecto determinado, CUANDO el usuario Fiscalizador presione sobre el botón de la planilla, ENTONCES el sistema desplegará el formulario de registro de planillas del proyecto solicitando toda la información correspondiente.  DADO el ingreso completo de los datos en el formulario de registro de planillas, CUANDO el usuario Fiscalizador presione sobre el botón “Ingresar”, ENTONCES el sistema procederá a guardar los datos y presentará el mensaje “Planilla Registrado” confirmando la operación  DADO el ingreso incompleto (o en blanco) de los datos en el formulario de registro de proyectos, CUANDO el usuario Fiscalizador presione sobre el botón “Guardar”, ENTONCES el sistema alertará al usuario de los campos del formulario de registro de proyectos que hacen falta rellenar, resaltándolos en rojo.

109

Historia de usuario Número: 15

Nombre: Generación de informe individual de las planillas

Usuario: /Fiscalizador/ Prioridad en negocio: Media

Sprint asignado: 3

Riesgo en desarrollo: Media

Puntos estimados: 8

Descripción: - Como Fiscalizador/Visor quiero que el sistema genere reportes individuales de las planillas creadas, para poder imprimirlo y observar la información detallada de la planilla

Observaciones: el sistema debe generar los informe en formato .pdf , debe contener elementos gráficos representativos de la empresa.

Criterios de Aceptación:  DADO el ingreso (registro) de una planilla determinada, CUANDO el usuario Fiscalizador/Visor cambie el estado “Cancelado” a “Sí” de la planilla, ENTONCES el sistema activará el botón “Imprimir” y permitirá la generación del reporte individual por planilla registrada

110

Historia de usuario Número: 16

Nombre: Ingreso de Incrementos en el proyecto

Usuario: /Fiscalizador/ Prioridad en negocio: Media

Sprint asignado: 3

Riesgo en desarrollo: Media

Puntos estimados: 13

Descripción: - Como /Fiscalizador/ quiero poder ingresar los incrementos generados en el proyecto para poder tener constancia del tipo de incremento, numero de incrementos y monto por incremento.

Observaciones: el sistema debe permitir alojar (subir) el archivo digital que justifica dicho incremento.

Criterios de Aceptación:  DADO el acceso a la información complementaria de un proyecto determinado, CUANDO el usuario Fiscalizador presione sobre el botón “Incrementos”, ENTONCES el sistema desplegará el formulario de registro de Incrementos permitiendo seleccionar entre tres tipos.  DADO la selección del tipo de incremento y posterior ingreso de los datos en el formulario de registro, CUANDO el usuario Fiscalizador presione sobre el botón “Digital”, ENTONCES el sistema abrirá el explorador de archivos del sistema operativo para seleccionar el documento digitalizado que respalda dicha forma de incremento  DADO el ingreso completo de datos en el formulario de registro de Incrementos, CUANDO el usuario Fiscalizador presione sobre el botón “+1” ENTONCES el sistema procederá a guardar los datos y presentará el mensaje “Incremento Registrado” confirmando la operación  DADO el ingreso incompleto (o en blanco) de los datos en el formulario de registro de Incrementos, CUANDO el usuario Fiscalizador presione sobre el botón “+1”, ENTONCES el sistema alertará al usuario de los campos del formulario de registro de proyectos que hacen falta rellenar, resaltándolos en rojo.

111

Historia de usuario Número: 17

Nombre: Ingreso de prórrogas en el proyecto

Usuario: /Fiscalizador/ Prioridad en negocio: Media

Sprint asignado: 3

Riesgo en desarrollo: Media

Puntos estimados: 13

Descripción: - Como /Fiscalizador/ quiero poder ingresar las prórrogas generadas en el proyecto para tener constancia del tipo de prorroga que es, numero de prórrogas realizados y los días que conllevan dichas prorrogas.

Observaciones: el sistema debe permitir alojar (subir) el archivo digital que justifica dicha prorroga.

Criterios de Aceptación:  DADO el acceso a la información complementaria de un proyecto determinado, CUANDO el usuario Fiscalizador presione sobre el botón “Prórrogas”, ENTONCES el sistema desplegará el formulario de registro de Prórrogas permitiendo guardarlas de acuerdo a dos tipos.  DADO el ingreso de los datos en el formulario de registro, CUANDO el usuario Fiscalizador presione sobre el botón “Digital”, ENTONCES el sistema abrirá el explorador de archivos del sistema operativo para seleccionar el documento digitalizado que respalda la prórroga del proyecto.  DADO el ingreso completo de datos en el formulario de registro de Incrementos, CUANDO el usuario Fiscalizador presione sobre el botón “Agregar Ampliación” o sobre “Agregar Suspensión” ENTONCES el sistema procederá a guardar los datos de acuerdo a la opción seleccionada y presentará el mensaje “Prórroga Registrada”  DADO el ingreso incompleto (o en blanco) de los datos en el formulario de registro de Incrementos, CUANDO el usuario Fiscalizador presione sobre el botón “Agregar Ampliación” o sobre “Agregar Suspensión” , ENTONCES el sistema alertará al usuario de los campos del formulario de registro de proyectos que hacen falta rellenar, resaltándolos en rojo.

112

Historia de usuario Número: 18

Nombre: Presentación resumida de los datos del proyecto

Usuario: /Fiscalizador/Visor Prioridad en negocio: Baja

Sprint asignado: 4

Riesgo en desarrollo: Baja

Puntos estimados: 8

Descripción: - Como /Fiscalizador/Visor quiero poder visualizar la información detallada y relevante de un proyecto para poder tener a primera mano dicha información.

Observaciones: el resumen de dicha información debe aparecer en la sección de opciones complementarias, para cada proyecto Criterios de Aceptación:  DADO la selección de un proyecto, CUANDO el usuario Fiscalizador/Visor accedan a la información complementaria de un proyecto determinado, ENTONCES el sistema desplegará un resumen con la información correspondiente al proyecto elegido

113

Historia de usuario Número: 19

Nombre: Ingreso de Actas de Recepción de cada proyecto

Usuario: Fiscalizador/ Prioridad en negocio: Media

Sprint asignado: 4

Riesgo en desarrollo: Baja

Puntos estimados: 13

Descripción: - Como Fiscalizador/ quiero poder ingresar (subir) el archivo digital correspondiente al Acta de Finalización del proyecto para poder llevar un registro y constancia de culminación de los proyectos.

Observaciones: el sistema debe proporcionar las opciones de subir el Acta de Recepción Provisional y el Acta de Recepción Definitiva Criterios de Aceptación:  DADO el acceso a la información complementaria de un proyecto determinado, CUANDO el usuario Fiscalizador presione sobre el botón “Actas”, ENTONCES el sistema desplegará el formulario de registro de Actas permitiendo seleccionar entre dos tipos de actas a guardar.  DADO la selección del tipo de Actas, CUANDO el usuario Fiscalizador presione sobre el botón “Digital”, ENTONCES el sistema abrirá el explorador de archivos del sistema operativo para seleccionar el documento digitalizado que respaldará dicha información.  DADO la selección del Acta, CUANDO el usuario Fiscalizador presione sobre el botón “Subir”, ENTONCES el sistema procederá a guardar en el servidor el archivo digital del Acta seleccionada.

114

Historia de usuario Número: 20

Nombre: Reporte general de proyectos

Usuario: Fiscalizador/ Prioridad en negocio: Bajo

Sprint asignado: 4

Riesgo en desarrollo: Baja

Puntos estimados: 8

Descripción: - Como Fiscalizador/Visor quiero poder visualizar un reporte general de todos los proyectos (su información, estado, etc.) para tener conocimiento global de los mismos y poder tomar decisiones

Observaciones: el sistema debe generar los informe en formato .pdf, debe contener elementos gráficos representativos de la empresa. Criterios de Aceptación:  DADO el acceso al módulo de proyectos, CUANDO el usuario Fiscalizador presione sobre el botón “Información General”, ENTONCES el sistema desplegará una ventana modal para seleccionar el rango de fechas para la generación del reporte  DADO la selección del rango de fechas, CUANDO el usuario Fiscalizador presione sobre el botón “Reporte”, ENTONCES el sistema abrirá una nueva pestaña del navegador web para mostrar el reporte solicitado en formato pdf

115

Historia de usuario Número: 21

Nombre: Reporte individual de proyectos

Usuario: Fiscalizador/Visor Prioridad en negocio: Baja

Sprint asignado: 4

Riesgo en desarrollo: Media

Puntos estimados: 13

Descripción: - Como Fiscalizador/Visor quiero poder visualizar un reporte individual y detallado de cada uno de los proyectos ingresados en el sistema para tener conocimientos específicos de cada uno de ellos y poder tomar decisiones.

Observaciones: el sistema debe generar los informe en formato pdf, debe contener elementos gráficos representativos de la empresa.

Criterios de Aceptación:  DADO el acceso al módulo de proyectos, CUANDO el usuario Fiscalizador/Visor seleccione un proyecto determinado y haga clic en el botón “Reporte”, ENTONCES el sistema abrirá una nueva pestaña del navegador web para mostrar el reporte solicitado en formato pdf

116

Historia de usuario Número: 22

Nombre: Reporte de fiscalizadores

Usuario: Fiscalizador/Visor Prioridad en negocio: Baja

Sprint asignado: 4

Riesgo en desarrollo: Baja

Puntos estimados: 8

Descripción: - Como Fiscalizador/Visor quiero poder visualizar un reporte individual de cada fiscalizador en donde se muestre toda la información referente a los proyectos que ha tenido a cargo, para poder generar un documento y tomar decisiones con la información.

Observaciones: el sistema debe generar los informe en formato pdf debe contener elementos gráficos representativos de la empresa. Criterios de Aceptación:  DADO el acceso al módulo de fiscales, CUANDO el usuario Fiscalizador seleccione un fiscal determinado y haga clic en el botón “Reporte”, ENTONCES el sistema abrirá una nueva pestaña del navegador web para mostrar el reporte solicitado en formato pdf