Web Service para el control de Documentos Electrónicos de Emproservis CÏA. LTDA. En Santo Domingo

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas

WEB SERVICE PARA EL CONTROL DE DOCUMENTOS ELECTRÓNICOS DE EMPROSERVIS CÍA. LTDA. EN 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.

Autor: MARCOS KLENDER CARRASCO GONZAGA

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 WEB SERVICE PARA EL CONTROL DE DOCUMENTOS ELECTRÓNICOS DE EMPROSERVIS CÍA. LTDA. EN SANTO DOMINGO; PERIODO 2017 – 2018

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

Autor: MARCOS KLENDER CARRASCO GONZAGA

Luis Javier Ulloa Meneses, Mg.

f.

DIRECTOR DE LA DISERTACIÓN DE GRADO

Jon Azcona Esteban, Mg.

f.

CALIFICADOR

Willian Javier Ocampo Pazos, Mg.

f.

CALIFICADOR

Luis Javier Ulloa Meneses, Mg.

f.

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

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, CARRASCO GONZAGA MARCOS KLENDER portador de la cédula de ciudadanía N.º 2300679244 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 legar y académica.

Carrasco Gonzaga Marcos Klender CI. 2300679244

iv

AGRADECIMIENTO

A mis padres, quienes me han apoyado incondicionalmente, me han brindado un sinnúmero de oportunidades y han sido un ejemplo a seguir. A mis abuelitos, quienes siempre me han dado su cariño cuando lo he necesitado. Y a mi hermano, quien me llena de alegría siempre que está conmigo. No estaría aquí si no fuera por cada uno de ellos.

A mi enamorada y amigos, quienes siguen a mi lado a pesar de los obstáculos y el tiempo, demostrando que aún existen personas que valen la pena. ¡Gracias a todos!

Carrasco Gonzaga Marcos Klender

v

DEDICATORIA

A mis padres y abuelos.

Carrasco Gonzaga Marcos Klender

vi

RESUMEN

El presente trabajo de titulación comprende el desarrollo de un web service enfocado al control de los documentos electrónicos de Emproservis Cía. Ltda., en la ciudad de Santo Domingo. Este sistema solventa un problema cotidiano que se presenta en la empresa, permitiendo a los usuarios acceder a sus documentos electrónicos de manera remota mediante una interfaz simple, sencilla y adaptable a todo tipo de dispositivos, de manera que no se requiera la intervención manual por parte de los empleados. En este documento se detallan todos los procesos que se llevaron a cabo para el desarrollo del sistema, así como también la combinación de la metodología XP y el marco de trabajo SCRUM que apoyó dicho desarrollo.

Por otra parte, también se detallan las técnicas e instrumentos utilizados para la recolección y análisis de los datos pertinentes. Todo el software que se utiliza es open source, tal como lo solicitó la empresa, con el fin de reducir los costos de desarrollo y evitar el pago de licencias.

El web service fue desarrollado en un entorno Linux, utilizando Laravel como framework de desarrollo, Bootstrap para el diseño de las interfaces y PostgreSQL como gestor de base de datos; además, se empleó la plataforma Github para facilitar la creación de respaldos del código y el control de las versiones del sistema, haciendo uso de repositorios Git alojados en la web.

Palabras claves: Web Service, Documentación Electrónica, Laravel, XP, SCRUM.

vii

ABSTRACT

The current titration work includes the development of a web service focused on the control of electronic documents of Emproservis Ltd. Co. in Santo Domingo de los Colorados.

This system solves a daily problem that occurs in the company, allowing users to access their electronic documents remotely through a simple interface that is adaptable to all types of devices, so that manual intervention of the employees is not required. This document details all the processes that were carried out for the development of the system, as well as the combination of the XP methodology and the SCRUM framework that supported this development. On the other hand, the techniques and instruments used for the collection and analysis of the pertinent data are also detailed. All software used is open source, as requested by the company in order to reduce development costs and avoid the payment of licenses. The web service was developed in a Linux environment, using Laravel as a development framework, Bootstrap for the design of interfaces and PostgreSQL as a database manager; in addition, the Github platform was used to facilitate the creation of code backups and control of system versions, using Git repositories hosted on the web.

Keywords: Web Service, Electronic Documentation, Laravel, XP, SCRUM

viii

ÍNDICE DE CONTENIDOS 1.

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

2.

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

2.1.

Problema de Investigación ........................................................................................ 2

2.2.

Justificación de la Investigación................................................................................ 3

2.3.

Objetivos de Investigación ........................................................................................ 4

2.3.1.

Objetivo General. ...................................................................................................... 4

2.3.2.

Objetivos Específicos. ............................................................................................... 4

3.

MARCO REFERENCIAL........................................................................................... 5

3.1.

Antecedentes ............................................................................................................. 5

3.2.

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

3.2.1.

Web Service. ............................................................................................................. 7

3.2.2.

Ingeniería de Software............................................................................................... 7

3.2.2.1.

Procesos de Software................................................................................................. 7

3.2.2.1.1 Modelo en Cascada. .................................................................................................. 7 3.2.2.1.2 Desarrollo Incremental. ............................................................................................. 8 3.2.2.2.

Desarrollo Ágil de Software. ..................................................................................... 8

3.2.2.2.1 Procesos Ágiles. ........................................................................................................ 8 3.2.2.2.2 Modelos Ágiles de Proceso. ...................................................................................... 9 3.2.2.3.

Programación Extrema (XP). .................................................................................... 9

3.2.2.3.1 Valores XP. ............................................................................................................... 9 3.2.2.3.2 Prácticas XP. ........................................................................................................... 11 3.2.2.3.3 Proceso XP. ............................................................................................................. 12 3.2.2.4.

Scrum....................................................................................................................... 13

3.2.2.4.1 Equipo Scrum. ......................................................................................................... 13 3.2.2.4.2 Artefactos Scrum. .................................................................................................... 14 3.2.2.4.3 Eventos Scrum. ........................................................................................................ 14 3.2.3.

Desarrollo Web........................................................................................................ 15

3.2.3.1.

Lenguajes................................................................................................................. 15

3.2.3.1.1 Back-End. ................................................................................................................ 16 3.2.3.1.2 Front-End................................................................................................................. 16 3.2.3.2.

Arquitectura. ............................................................................................................ 17

ix

3.2.3.2.1 Modelo Cliente/Servidor. ........................................................................................ 17 3.2.3.2.2 Modelo de Múltiples Capas. .................................................................................... 18 3.2.3.2.3 Modelo-Vista-Controlador. ..................................................................................... 18 3.2.4.

Base de Datos. ......................................................................................................... 18

3.2.4.1.

Sistema Gestor de Base de Datos. ........................................................................... 19

3.2.4.2.

Lenguaje SQL.......................................................................................................... 21

3.2.4.3.

Modelado de Datos. ................................................................................................. 21

3.2.5.

Documentos Electrónicos. ....................................................................................... 21

3.2.5.1.

Tipología de los Documentos Electrónicos. ............................................................ 21

3.2.5.2.

Medios Electrónicos. ............................................................................................... 22

3.2.6.

Proceso Contable. .................................................................................................... 22

3.2.6.1.

Comprobantes. ......................................................................................................... 22

3.2.6.2.

Clasificación de Comprobantes. .............................................................................. 22

3.2.7.

Gestión de Documentos........................................................................................... 23

3.2.7.1.

Gestión..................................................................................................................... 23

3.2.7.2.

Documentación. ....................................................................................................... 23

3.2.8.

Digitalización. ......................................................................................................... 23

3.2.8.1.

Archivos Digitales. .................................................................................................. 24

3.2.8.2.

Ventajas de la Información Digital. ........................................................................ 24

4.

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

4.1.

Diseño/Tipo de Investigación .................................................................................. 25

4.1.1.

Enfoque de la Investigación. ................................................................................... 25

4.1.2.

Diseño de la Investigación. ..................................................................................... 25

4.1.2.1.

Diseño Exploratorio Secuencial (DEXPLOS). ....................................................... 25

4.1.3.

Tipos de Investigación............................................................................................. 26

4.1.3.1.

Investigación Bibliográfica. .................................................................................... 26

4.1.3.2.

Investigación Descriptiva. ....................................................................................... 26

4.1.3.3.

Investigación Aplicada. ........................................................................................... 26

4.2.

Población/Universo ................................................................................................. 26

4.3.

Muestra .................................................................................................................... 27

4.4.

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

4.4.1.

Entrevista. ................................................................................................................ 28

4.4.2.

Encuesta................................................................................................................... 28

x

4.5.

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

4.6.

Metodología de Desarrollo de Software .................................................................. 28

4.6.1.

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

4.6.2.

Características de la Programación Extrema (XP). ................................................. 31

4.6.3.

Características de Scrum. ........................................................................................ 32

4.6.4.

Combinando XP y Scrum. ....................................................................................... 33

5.

RESULTADOS ......................................................................................................... 34

5.1.

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

5.1.1.

Análisis de la Entrevista. ......................................................................................... 34

5.1.2.

Análisis de las Encuestas. ........................................................................................ 36

5.2.

Propuesta de Intervención – Web Service (v1.0) .................................................... 47

5.2.1.

Ciclo de Vida XP. .................................................................................................... 47

5.2.2.

Fase I: Exploración. ................................................................................................. 47

5.2.2.1.

Gestión de Tareas. ................................................................................................... 50

5.2.2.2.

Gestión de Versiones. .............................................................................................. 51

5.2.3.

Sprint 1. ................................................................................................................... 51

5.2.3.1.

Fase II: Planeación. ................................................................................................. 51

5.2.3.2.

Fase III: Diseño. ...................................................................................................... 52

5.2.3.3.

Fase IV: Codificación. ............................................................................................. 55

5.2.3.4.

Fase V: Pruebas. ...................................................................................................... 57

5.2.4.

Sprint 2. ................................................................................................................... 59

5.2.4.1.

Fase II: Planeación. ................................................................................................. 59

5.2.4.2.

Fase III: Diseño. ...................................................................................................... 59

5.2.4.3.

Fase IV: Codificación. ............................................................................................. 62

5.2.4.4.

Fase V: Pruebas. ...................................................................................................... 64

5.2.5.

Sprint 3. ................................................................................................................... 65

5.2.5.1.

Fase II: Planeación. ................................................................................................. 65

5.2.5.2.

Fase III: Diseño. ...................................................................................................... 65

5.2.5.3.

Fase IV: Codificación. ............................................................................................. 68

5.2.5.4.

Fase V: Pruebas. ...................................................................................................... 70

5.2.6.

Fase VI: Muerte del Proyecto. ................................................................................. 70

5.3.

Evaluación de Impacto del Proyecto ....................................................................... 71

5.3.1.

Impacto Tecnológico. .............................................................................................. 72

xi

5.3.2.

Impacto Social. ........................................................................................................ 73

5.3.3.

Impacto Econรณmico. ................................................................................................ 74

5.3.4.

Impacto General. ..................................................................................................... 75

6.

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

7.

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

8.

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

9.

GLOSARIO ............................................................................................................... 81

10.

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

xii

ÍNDICE DE TABLAS Tabla 1. Características de los SGBD ...................................................................................... 20 Tabla 2. Comparativa entre XP y Scrum ................................................................................. 29 Tabla 3. Cualidades relevantes de XP y Scrum ....................................................................... 30 Tabla 4. Características aplicables de XP ................................................................................ 31 Tabla 5. Características aplicables de Scrum ........................................................................... 32 Tabla 6. Disponibilidad de un dispositivo móvil ..................................................................... 36 Tabla 7. Uso del navegador en un dispositivo móvil ............................................................... 38 Tabla 8. Disponibilidad de una computadora personal ............................................................ 39 Tabla 9. Uso del navegador en una computadora personal ..................................................... 40 Tabla 10. Inconvenientes con el personal ................................................................................ 41 Tabla 11. Inconvenientes con la entrega de documentos ......................................................... 42 Tabla 12. Retraso en la entrega de documentos ....................................................................... 43 Tabla 13. Acceso a los documentos electrónicos..................................................................... 44 Tabla 14. Descarga de los documentos electrónicos ............................................................... 44 Tabla 15. Desarrollo de una página web .................................................................................. 45 Tabla 16. Página web con diseño responsivo .......................................................................... 46 Tabla 17. Roles Scrum ............................................................................................................. 47 Tabla 18. Product Backlog Final (v1.2) ................................................................................... 48 Tabla 19. Rangos Fibonacci ..................................................................................................... 49 Tabla 20. Sprint 1 – Tarjeta CRC 1 ......................................................................................... 52 Tabla 21. Sprint 1 – Tarjeta CRC 2 ......................................................................................... 53 Tabla 22. Sprint 2 – Tarjeta CRC 3 ......................................................................................... 60 Tabla 23. Sprint 2 – Tarjeta CRC 4 ......................................................................................... 60 Tabla 24. Sprint 2 – Tarjeta CRC 5 ......................................................................................... 60 Tabla 25. Sprint 3 – Tarjeta CRC 6 ......................................................................................... 66 Tabla 26. Sprint 3 – Tarjeta CRC 7 ......................................................................................... 66 Tabla 27. Sprint 3 – Tarjeta CRC 8 ......................................................................................... 66 Tabla 28. Niveles de Impacto .................................................................................................. 71 Tabla 29. Impacto Tecnológico ............................................................................................... 72 Tabla 30. Impacto Social ......................................................................................................... 73 Tabla 31. Impacto Económico ................................................................................................. 74 Tabla 32. Impacto General ....................................................................................................... 75

xiii

ÍNDICE DE FIGURAS Figura 1. El proceso de la Programación Extrema. ................................................................. 12 Figura 2. Flujo del proceso Scrum. .......................................................................................... 15 Figura 3. Vista general del Modelo Cliente/Servidor. ............................................................. 17 Figura 4. Disponibilidad de un dispositivo móvil.................................................................... 37 Figura 5. Uso del navegador en un dispositivo móvil. ............................................................ 38 Figura 6. Disponibilidad de una computadora personal. ......................................................... 39 Figura 7. Uso del navegador en una computadora personal. ................................................... 40 Figura 8. Inconvenientes con la entrega de documentos. ........................................................ 42 Figura 9. Retraso en la entrega de documentos. ...................................................................... 43 Figura 10. Desarrollo de una página web. ............................................................................... 45 Figura 11. Página web con diseño responsivo. ........................................................................ 46 Figura 12. Tablero en Trello. ................................................................................................... 50 Figura 13. Perfil en Github. ..................................................................................................... 51 Figura 14. Sprint 1 – Sprint Backlog. ...................................................................................... 52 Figura 15. Maqueta de la historia de usuario 1. ....................................................................... 53 Figura 16. Maqueta de la historia de usuario 2. ....................................................................... 54 Figura 17. Conexión a la base de datos (PostgreSQL). ........................................................... 55 Figura 18. Controlador para la visualización de las facturas. .................................................. 56 Figura 19. Vista de las facturas. ............................................................................................... 56 Figura 20. Controlador para la conversión y descarga en formato PDF. ................................. 57 Figura 21. Prueba unitaria automatizada. ................................................................................ 57 Figura 22. Sprint 1 – Burndown Chart..................................................................................... 58 Figura 23. Sprint 2 – Sprint Backlog. ...................................................................................... 59 Figura 24. Maqueta de la historia de usuario 3. ....................................................................... 61 Figura 25. Maqueta de la historia de usuario 4. ....................................................................... 61 Figura 26. Maqueta de la historia de usuario 5. ....................................................................... 62 Figura 27. Controlador para la búsqueda de documentos por número. ................................... 62 Figura 28. Vista de la opción de búsqueda. ............................................................................. 63 Figura 29. Vista del perfil de usuario....................................................................................... 63 Figura 30. Controlador para editar la información del usuario. ............................................... 63 Figura 31. Controlador para la conversión y descarga en formato XML. ............................... 64

xiv

Figura 32. Sprint 2 – Burndown Chart..................................................................................... 64 Figura 33. Sprint 3 – Sprint Backlog. ...................................................................................... 65 Figura 34. Maqueta de la historia de usuario 6. ....................................................................... 67 Figura 35. Maqueta de la historia de usuario 8. ....................................................................... 67 Figura 36. Controladores para el inicio de sesión. ................................................................... 68 Figura 37. Seeder para la creación automática de usuarios. .................................................... 68 Figura 38. Vista del inicio de sesión. ....................................................................................... 69 Figura 39. Vista del restablecimiento de contraseña. .............................................................. 69 Figura 40. Sprint 3 – Burndown Chart..................................................................................... 70

xv

ÍNDICE DE ANEXOS Anexo 1: Carta de Asignación del Proyecto ............................................................................ 84 Anexo 2: Acta de Entrega-Recepción del Proyecto ................................................................. 85 Anexo 3: Carta de Impacto ...................................................................................................... 86 Anexo 4: Modelo de Entrevista ............................................................................................... 87 Anexo 5: Modelo de Encuesta ................................................................................................. 90 Anexo 6: Historias de Usuario ................................................................................................. 92 Anexo 7: Pruebas de Aceptación – Sprint 1 .......................................................................... 100 Anexo 8: Pruebas de Aceptación – Sprint 2 .......................................................................... 102 Anexo 9: Pruebas de Aceptación – Sprint 3 .......................................................................... 105 Anexo 10: Manual Técnico .................................................................................................... 108 Anexo 11: Manual de Usuario ............................................................................................... 114 Anexo 12: Presupuesto del Proyecto ..................................................................................... 121

1

1. INTRODUCCIÓN El presente proyecto se enfoca en el desarrollo de un web service para el control de los documentos electrónicos de Emproservis, mismo que facilita el acceso a los mismos por parte de los clientes desde cualquier dispositivo con acceso a internet, organizando distintos tipos de documentos en un solo lugar y permitiendo la descarga en caso de que sea necesario. Así mismo, facilita a los administradores el control de estos documentos tanto como sea requerido, a fin de evitar retrasos en los procesos que deba realizar la empresa.

Además, cabe mencionar que este proyecto se ha fundamentado en base a diferentes fuentes bibliográficas, como lo son: los libros facilitados por la biblioteca de la “Pontificia Universidad Católica del Ecuador, Sede Santo Domingo”, artículos científicos obtenidos de reconocidas bibliotecas virtuales e información recabada de irrefutables sitios web. Todo el material recopilado ha sido sometido a un minucioso análisis con el fin de extraer información legítima y relevante para el desarrollo de la actual investigación.

En lo que respecta a la estructura, este trabajo está conformado por seis fases, las cuales se definen brevemente a continuación.

Capítulo uno, Introducción, aquí se presenta una visión general del proyecto de investigación, así como también su importancia y los temas que abarcó su respectivo desarrollo.

Capítulo dos, Planteamiento del Problema, abarca los antecedentes, la definición y justificación de la investigación y el planteamiento de los objetivos (general y específicos).

Capítulo tres, Marco Referencial, recopila toda la información extraída y analizada de las diferentes fuentes bibliográficas utilizadas. Trata temas puntuales con respecto al tema del presente trabajo de disertación, explicando generalidades y procedimientos fundamentales.

Capítulo cuatro, Metodología de la Investigación, abarca el tipo, enfoque y diseño de investigación que se ha utilizado en el presente proyecto, así como también las técnicas de recogida y análisis de datos y la metodología de desarrollo de software empleada.

Capítulo cinco, Resultados, aquí se analiza y se presenta toda la información resultante de las técnicas y herramientas de recogida de datos descritas en la fase anterior.

Capítulo seis, Lista de Referencias, recopila todas las fuentes bibliográficas utilizadas.

2

2. PLANTEAMIENTO DEL PROBLEMA 2.1. Problema de Investigación La presente investigación se ha realizado en EMPROSERVIS CÍA. LTDA., una empresa importadora, distribuidora y comercializadora de productos para el área automotriz, como: llantas, baterías, lubricantes, grasas, filtros, combustible, entre otros; con matriz con la ciudad de Santo Domingo de los Tsáchilas. Son representantes oficiales para Ecuador, de las marcas BRIDGESTONE, FIRESTONE, VALVOLINE, POWERTRAC, WINRUN, TOP CAR, MRF y ENERGÍA TOTAL. Mediante la visita a la empresa, se observó que en el departamento de sistemas existe un deficiente control y entrega de los documentos electrónicos debido a que este proceso se realiza manualmente, lo cual provoca que la mayoría de clientes no reciban los documentos que necesitan. Esto también afecta a las operaciones que la empresa realiza a partir de estos documentos, puesto que los empleados ocupan mayor tiempo en solventar el manejo de los mismos. Por la problemática anterior surge la siguiente pregunta: ¿Cómo mejorar el control de los documentos electrónicos de Emproservis?

Emproservis es una empresa importadora, distribuidora y comercializadora de productos para el área automotriz, por lo que es evidente que manejan una gran cantidad de transacciones y documentos. Es fundamental para una empresa el llevar un control adecuado de sus documentos, una buena organización y un acceso eficiente a los mismos.

Dado el problema antes mencionado, la presente investigación responderá las siguientes preguntas directrices: ¿Cuáles son los procesos para el acceso y el manejo de información de los documentos electrónicos de Emproservis? ¿Cuáles son las metodologías y herramientas de desarrollo de software que se pueden aplicar en el web service? ¿Qué tipo de software se puede utilizar para evitar el pago de licencias?

3

2.2. Justificación de la Investigación Los Web Services ofrecen una alternativa de software independiente en cuanto a la plataforma, basada en estándares para la integración de aplicaciones, la automatización de procesos de negocio y la publicación de la información de diversas fuentes. La calidad en Web Service es vital para una organización que busca apalancarse en la integración. Contar con una infraestructura integrada, segura, escalable y disponible disminuye costos y permite compartir información de manera confiable (Pérez, Mendoza & Grimán, 2015).

De acuerdo con Millan y Palma (2011), los servicios web son ampliamente consumidos en los ámbitos educativos y empresariales, dado que ofrecen interacción con diferentes comunidades y servicios en línea, eliminando así las barreras geográficas al permitir la disponibilidad de la información al alcance de los clientes. Por este motivo se ha optado por el desarrollo de un servicio web que permita solventar los problemas de disponibilidad de los documentos electrónicos.

El presente proyecto de investigación es importante para Emproservis Cia. Ltda., debido a que permite la automatización y gestión de la documentación electrónica, en función a la tecnología de información y comunicación (TIC).

Por parte de la empresa Emproservis se ha recibido total aceptación y compromiso para el presente proyecto de investigación a través del documento que ha sido entregado y firmado por el encargado del departamento de sistemas, Ing. Deiby Morocho, quien ha brindado la información necesaria para el desarrollo del mismo.

En lo referente al PNBV, esta investigación trabaja directamente con el objetivo 11, el cual asegura la soberanía y eficiencia de los sectores estratégicos para la transformación industrial y tecnológica, enfocándose en la meta 11.4 que busca alcanzar un índice de digitalización de 56,4.

El desarrollo del web service brindará varios beneficios, desde el acceso a la información hasta la organización, distribución y control de los documentos electrónicos.

Además, cabe destacar que el automatizar los procesos de entrega de documentos y permitir acceder a ellos de forma digital beneficia al medio ambiente, evitando el uso de recursos físicos tales como impresiones extras y fotocopias.

4

2.3. Objetivos de Investigación 2.3.1. Objetivo General.

Desarrollar un web service para el control de los documentos electrónicos de Emproservis Cia. Ltda. en Santo Domingo; periodo 2017 – 2018.

2.3.2. Objetivos Específicos. 

Determinar los procesos que intervienen en el acceso y el manejo de la información de los documentos electrónicos de Emproservis.



Establecer la metodología de desarrollo de software y las herramientas necesarias para aplicarlas en el web service.



Desarrollar el sistema informático haciendo uso de software open source.

5

3. MARCO REFERENCIAL 3.1. Antecedentes Mediante un meticuloso análisis de diferentes investigaciones se han encontrado muchas soluciones previas referentes al tema a tratar, mismas que servirán como guía para realizar la presente investigación. A continuación, se profundizarán las cinco investigaciones más relevantes, mismas que fueron recabadas desde diferentes repositorios universitarios.

Empezando por la tesis de grado de los autores Blanco y Muñoz (2013), que se titula “Desarrollo del sistema web para la administración de documentos digitalizados para Imexsa”, afirman que en la actualidad es sumamente importante que toda empresa que maneje grandes volúmenes de documentos haga uso de la tecnología y la digitalización, de manera que permita gestionar todo tipo de información de manera remota y organizada. La metodología que se ha utilizado para el desarrollo del software ha sido XP y en lo que respecta al producto, se ha empleado PHP como lenguaje de programación y MySQL como gestor de base de datos.

De acuerdo con Negrete (2016), en su tesis de grado titulada “Desarrollo de un sistema web de facturación electrónica con comunicación al servicio de rentas internas para la empresa Expertweb Cía. Ltda.”, manifiesta que el uso de las tecnologías es fundamental para poner todo tipo de información a disposición de los clientes, siempre y cuando se haga uso de interfaces limpias, claras y accesibles, brindando un manejo cómodo y sencillo del sistema web. Debido a las diferentes necesidades que se han presentado, se ha empleado la metodología DSDM (Dynamic Systems Development Method), la misma que permite describir el problema y la justificación del proyecto orientándose principalmente a la parte del negocio. Esta metodología provee un marco de trabajo que consiste en tres fases: fase del pre-proyecto, fase del ciclo de vida del proyecto y fase del post-proyecto. Resulta relevante destacar que, en ciertas circunstancias, existe la posibilidad de integrar contenido de otros métodos como RUP o XP. En la tesis de grado titulada “Desarrollo de un sistema web de control de citas para un hospital del día”, el autor Aguilera (2013) enuncia que los sistemas web que permitan automatizar procesos en la empresa siempre serán bienvenidos siempre que sean seguros.

Debido a que dichos sistemas manejan información delicada y confidencial, deben contar con la seguridad necesaria para que los datos permanezcan íntegros y ocultos al público. Dentro del software empleado para el desarrollo del producto, se encuentra el framework Kohana, el

6

cual hace uso del PHP como lenguaje de programación e implementa el patrón de ModeloVista-Controlador (MVC). También se apoya en la librería JavaScript de JQuery, misma que facilita el manejo de eventos, creación de animaciones e interacciones vía AJAX. Por último, se ha utilizado MySQL como sistema gestor de base de datos debido a la fácil conectividad y buena optimización que presenta al hacer uso del framework anteriormente mencionado.

De igual forma, el autor Calderón (2016), en su tesis de grado titulada “Portal web para la gestión y administración de la Casa Hogar San Carlos” evidencia que el uso de la web es una importante solución para todas las problemáticas de dar a conocer los productos y servicios que ofrecen las empresas, brindando disponibilidad de la información las 24 horas y evitando que los clientes deban solicitar físicamente dichos servicios. En este caso, se ha utilizado el framework CodeIgniter, mismo que hace uso de PHP como lenguaje de programación. En el apartado del diseño, se ha optado por utilizar plantillas basadas en Bootstrap para facilitar la creación de interfaces de usuario. Con la finalidad de realizar pruebas de manera local, se ha elegido a Filezilla como cliente FTP para poder subir archivos al servidor una vez desarrollados y a WampServer por ser un servidor independiente de la plataforma; cabe destacar que ambos pertenecen al software libre. Por último, la metodología utilizada en el desarrollo de software ha sido el Proceso Unificado (UP), la cual se enfoca en los casos de uso, centrándose en la arquitectura y caracterizándose por ser iterativo e incremental.

Por otra parte, en la tesis de grado titulada “Diseño e implementación del voto electrónico mediante el uso de una aplicación web para las elecciones de la federación de estudiantes de la Pontifica Universidad Católica del Ecuador”, los autores Calvopiña y García (2016) manifiestan que el patrón de arquitectura MVC les ha permitido organizar de mejor manera el desarrollo de su software, separando las interfaces de usuario de la lógica de negocio.

En este trabajo se emplea XP como metodología ágil de desarrollo de software, a la cual la han dividido en seis fases: exploración, planificación, iteraciones, producción, mantenimiento y fin del proyecto. Los autores señalan que dichas fases pueden ser agrupadas de acuerdo a las necesidades de cada producto; en este caso, han hecho énfasis en la fase de iteraciones, donde han empleado diagramas UML para visualizar, especificar, construir y documentar el sistema.

En lo que respecta al software, se ha utilizado PHP como principal lenguaje de programación, apoyado por JavaScript, JQuery para manipulación de las páginas HTML y PostgreSQL, como gestor de base de datos. Debido a que se ha buscado evitar el pago de licencias, PostgreSQL fue elegida como la mejor alternativa gracias a que es distribuida bajo su propia licencia libre.

7

3.2. Revisión de la Literatura o Fundamentos Teóricos 3.2.1. Web Service.

Un web service es un repositorio de software que puede ser utilizado bajo protocolos web, los cuales se han popularizado con el crecimiento del internet y su gran utilidad a manera de “caja negra”. No se debe confundir a un servicio web con un portal web, pues los portales web son sitios regulares a los que se puede ingresar mediante un navegador y los servicios web son sistemas que proveen múltiples funciones alojadas en servidores remotos, además de ser independientes del lenguaje con el que fueron desarrollados (Rodríguez, Crasso, Zunino & Campo, 2010; Millan & Palma, 2011).

3.2.2. Ingeniería de Software.

La ingeniería de software se interesa por todos los aspectos de la producción de software, empezando desde las etapas más tempranas del sistema hasta el mantenimiento que se le da después de implementar el software. Además, no sólo se interesa en los procesos técnicos del desarrollo de software, también lo hace con la administración del proyecto y el desarrollo de herramientas, aplicando teorías y métodos donde sea adecuado para obtener resultados de la calidad requerida dentro de una fecha establecida (Sommerville, 2011, p. 7).

3.2.2.1. Procesos de Software.

Los procesos en la ingeniería de software utilizan modelos, los cuales fueron propuestos para ordenar el caos en el desarrollo de software. Estos modelos han proporcionado una estructura útil al trabajo y constituyen un mapa razonablemente eficaz para los equipos de software. Los modelos más utilizados se definen a continuación (Pressman, 2010, p. 33).

3.2.2.1.1 Modelo en Cascada.

Este modelo, también conocido como ciclo de vida clásico, sugiere un enfoque secuencial para el desarrollo de software, comenzando con la especificación de los requerimientos por parte del cliente, a través de la planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado. Actualmente, de la aplicación de este modelo surgen varios inconvenientes, el más evidente es que en los proyectos reales es muy raro que se siga un flujo secuencial, además de que es difícil que el cliente enuncie en forma explícita todos los requerimientos desde un inicio (Pressman, 2010, pp. 33-34).

8

3.2.2.1.2 Desarrollo Incremental.

El desarrollo incremental busca diseñar una implementación inicial del software, exponer la idea al usuario y luego desarrollar diferentes versiones hasta dar con el sistema adecuado. Cada versión del sistema incorpora algunas de las funciones que requiere el cliente; generalmente, en las primeras versiones se incluyen las funciones más importantes del proyecto. Este modelo, a diferencia del modelo en cascada, se adapta de mejor manera a la mayoría de los sistemas empresariales, comerciales y personales (Sommerville, 2011, p. 33).

3.2.2.2. Desarrollo Ágil de Software.

Según Vlaanderen, Jansen, Brinkkemper & Jaspers (2011), en los últimos años se ha introducido los principios ágiles como una de las mayores innovaciones en las metodologías de software. Uno de los puntos fuertes de la metodología ágil es que el trabajo se vuelve dinámico, aceptando los cambios que se puedan dar a lo largo del desarrollo, colaborando con los clientes y eligiendo al software por encima de la documentación exhaustiva. Dicha metodología da paso a los equipos ágiles, cuyo potencial se ve reflejado en la toma de decisiones y en el apoyo que se brindan entre los integrantes del equipo, a diferencia de lo complejo que llegarían a ser estos procedimientos de forma individual (Drury, Conboy & Power, 2012).

3.2.2.2.1 Procesos Ágiles.

Son métodos que le permiten al equipo de desarrollo enfocarse en el software en lugar del diseño y la documentación innecesaria. Un método ágil permite que el desarrollo de un producto sea incremental, es decir, en un inicio crear un software sencillo que vaya adoptando nuevas características a medida que va progresando su desarrollo.

A diferencia de otros métodos, aquí no se crean partes del producto por separado para al final unir todos los módulos desarrollados, sino que se desarrollarán características funcionales contemplando el producto desde un inicio. Además, se debe tomar en cuenta que para que un método pueda considerarse ágil debe poder adaptarse a los cambios que puedan surgir en el transcurso del desarrollo de un producto (Álvarez, de las Heras del Dedo, & Lasa, 2012, p. 34).

9

3.2.2.2.2 Modelos Ágiles de Proceso.

En la ingeniería de software existen decenas de metodologías, modelos y herramientas, muchas de ellas ya obsoletas. En su momento, cada una de ellas tuvo gran acogida y respaldo, pero poco a poco fueron reemplazadas por nuevas metodologías que se enfocaban en lo moderno y adaptativo. Según Pressman (2010) se han propuesto muchas metodologías de las cuales las que están en uso en toda la industria son las siguientes: 

Programación Extrema (XP)



Scrum



Cristal



Desarrollo adaptativo de software (DAS)



Método de desarrollo de sistemas dinámicos (MDSD)

Siendo XP la metodología más utilizada en el desarrollo de software (p. 68).

3.2.2.3. Programación Extrema (XP).

La Programación Extrema es una de las metodologías ágiles más utilizadas en el desarrollo de software cuyos requisitos son poco complejos o cambiantes. Se aplica mayormente en equipos de desarrollo pequeños o medianos, llevando una clara orientación tanto con los desarrolladores como con los clientes o usuarios finales. En esta metodología los programadores trabajan en pares, desarrollando pruebas para cada función que quieran implementar (conocidas como tareas). Todas las pruebas que se realicen deben funcionar correctamente antes de integrar una nueva característica en el sistema (Álvarez et al., 2012, p.

49).

3.2.2.3.1 Valores XP. Los valores son descripciones de cómo debe enfocarse el desarrollo de un software.

Según Álvarez et al. (2012), los cinco valores que guían el desarrollo en la metodología XP son: la comunicación, simplicidad, retroalimentación, valentía y respeto. A continuación, se detallan brevemente cada uno de los valores XP.

10

Comunicación: Se hace énfasis en mantener una comunicación estrecha e informal tanto entre desarrolladores como con el cliente a fin de recabar información relevante para progresar en el desarrollo del software. Aquí se socializan las fortalezas y deficiencias del equipo de desarrollo para apoyarse mutuamente. De esta manera se busca evitar la documentación voluminosa e innecesaria como medio de comunicación.

Simplicidad: La manera más eficaz de desarrollar un software es simplificar todo procedimiento que se lleve a cabo. Aquí los desarrolladores priorizan la creación de las necesidades inmediatas y evitan preocuparse por las del futuro, de esta manera optimizan el tiempo y los recursos utilizados. Es importante no confundir un diseño simple con simplista, debido a que no es lo mismo optimizar líneas de código que hacer un sistema poco escalable.

Retroalimentación: Este valor se relaciona directamente con la comunicación y la simplicidad. Es sumamente importante llevar una estrecha comunicación con el cliente, de manera que el equipo de desarrollo conozca la opinión del mismo acerca del software que se va realizando, con el fin de evitar trabajo innecesario y desperdiciar recursos. A su vez, mientras más simple sea un sistema más fácil será opinar sobre él, de modo que se pueda detectar posibles fallos en la estructura de manera casi inmediata.

Valentía: También conocido como coraje. Es necesario de tener valentía a la hora de tomar decisiones y más aún cuando se daba comunicar con el cliente o con sus compañeros de trabajo, de manera que las opiniones sean claras y concisas. Hace falta de coraje para aceptar errores y también para hacerlos notar, afrontando sin miedo todos los cambios que se puedan dar durante el desarrollo del producto. Además, se pueden presentar ocasiones donde el desconocimiento puede echar para atrás alguna característica que se desee implementar y aquí es donde un desarrollador valiente debe tomar la iniciativa.

Respeto: Todos los valores anteriormente mencionados se relacionan directamente con el respeto, dado que es un valor imprescindible en cualquier equipo de trabajo. Es importante valorar el trabajo, las opiniones y los aportes de cada uno de los integrantes del equipo, de manera que exista una gran confianza entre ellos. Además, se debe tener en cuenta de que el trabajo propio puede afectar a los demás y viceversa, por ende, es preciso respetar a todos aquellos que interactúen con el producto, desde el cliente hasta el equipo de desarrollo.

11

3.2.2.3.2 Prácticas XP. Las prácticas en XP pueden definir la forma en cómo los equipos de desarrollo trabajan día a día. De acuerdo con Álvarez et al. (2012), el adoptar una o varias de estas prácticas dependerá de la situación en la que el equipo se encuentre. Existen muchas prácticas en la metodología XP y sus usos no son obligatorios, lo que sí es que algunas pueden resultar imprescindibles en el desarrollo de un software, como las que se definen a continuación.

Historias: Son una descripción corta de las funcionalidades que necesita el cliente y que contiene la prioridad, la estimación y el riesgo de desarrollarlas. Deben redactarse en lenguaje informal y de forma explícita, con el fin de que el cliente exprese los requerimientos de su sistema. También deben contener un criterio de aceptación para poder determinar cuando la historia de usuario sea completada.

Ciclos semanales de 40 horas: Se propone trabajar en iteraciones semanales donde el cliente decida qué historias se desarrollarán cada semana. Las largas jornadas de trabajo no son garantía de que un sistema estará terminado antes ni de que tendrá una calidad óptima, es por esto que XP se basa en 40 horas laborales por semana. De esta forma se evita la fatiga de los desarrolladores, asegurando una dedicación plena en el proyecto.

Programación en parejas: Esta práctica propone que el código lo desarrollen dos personas en un mismo ordenador. Esto no siempre tiene es aceptado por parte del equipo de desarrollo, peor aun cuando es la primera vez que se plantea. Una vez que se aplica, programar en parejas brinda grandes beneficios como detectar o evitar errores de programación inmediatamente, tener dos puntos de vista diferentes a la hora de desarrollar una funcionalidad y compartir opiniones respecto a lo que se está desarrollando en el momento.

Participación real de los clientes: Debe considerarse a todas aquellas personas involucradas con el producto como parte del equipo y es importante que la comunicación sea activa entre cada una de sus partes. Dado que el cliente es quien necesita del sistema, es necesario que haya una estrecha comunicación sobre las funcionalidades requeridas y, en ocasiones, puede ser útil que una persona se enfoque en transmitir las peticiones recogidas.

12

3.2.2.3.3 Proceso XP. La programación extrema consta de cuatro actividades estructurales (ver Figura 1): Planeación, Diseño, Codificación y Pruebas. A continuación, se explican dichas actividades.

La Planeación comienza recabando la información necesaria para empezar con el desarrollo del sistema, creando las historias de usuarios iniciales y el plan de iteración. El Diseño guía la implementación de una historia de usuario; aquí se utilizan las tarjetas CRC y se hace uso del principio MS (mantenlo sencillo) para todo en lo que se esté trabajando. Luego, en la etapa de Codificación, se desarrollan pruebas unitarias para cada una de las historias y se estimula la programación en parejas; cuando el código está terminado se le aplica una prueba unitaria, a fin de retroalimentar el avance del producto. Finalmente, en la etapa de Pruebas se realizan las pruebas de aceptación, de manera que se verifique el funcionamiento del incremento de software que se ha realizado en la iteración (Álvarez et al., 2012, pp. 62-65).

Figura 1. El proceso de la Programación Extrema. Adaptado de “Ingeniería de Software: Un Enfoque Práctico” por R. Pressman, 2010, p. 62.

13

3.2.2.4. Scrum.

Scrum es un marco de trabajo que comprende varios procesos y técnicas orientadas a la gestión del desarrollo de productos complejos. Busca generar resultados de calidad en iteraciones cortas (generalmente de 2 a 4 semanas), en las cuales el equipo de desarrollo hace uso de los eventos, artefactos y reglas asociadas. Cabe destacar que Scrum emplea un enfoque incremental que se adapta a los cambios que afecten al sistema, además de basarse en la experiencia para predecir y controlar riegos en el desarrollo (Scrum Alliance, 2017).

A pesar de que Scrum surgió como un modelo para el desarrollo de productos más generales, también se aplica en proyectos de software donde los requerimientos varían a medida que se desarrolla el sistema, donde la innovación y la adaptabilidad son parte fundamental del desarrollo y cuando se necesitan pequeñas liberaciones funcionales. Además, aquí se hace especial énfasis en el alineamiento entre el cliente y el equipo de desarrollo, de modo que el sistema se enriquezca de las aportaciones de todos los involucrados (Brito, Sosa, & Héctor, 2015, pp. 40-42).

3.2.2.4.1 Equipo Scrum.

El equipo Scrum se compone de tres roles: Product Owner, Development Team y Scrum Master. A continuación, se dará un breve resumen de lo que conlleva cada uno de estos roles y la manera en cómo se relacionan entre sí.

El Product Owner es una única persona responsable de optimizar el trabajo que realizan los desarrolladores y de gestionar el Product Backlog (este es un artefacto que se lo definirá más adelante). Se lo puede entender como el cliente que solicita el producto, pero también puede ser un intermediario entre los que requieran el producto y el equipo de desarrollo. El Development Team son todos aquellos encargados de realizar el producto que necesita el cliente. El equipo no tiene jerarquía y su tamaño óptimo es de tres a nueve integrantes. Por último, el Scrum Master es el encargado de asegurar que todo el equipo entienda y adopte la teoría, prácticas y reglas de Scrum a la perfección (Navarro, Fernández, & Morales, 2013).

14

3.2.2.4.2 Artefactos Scrum.

El proceso Scrum utiliza varios elementos que están al alcance de todo el equipo Scrum, los principales que son denominados como artefactos son: el Product Backlog y el Sprint Backlog. Estos artefactos se definirán a continuación: El Product Backlog es una lista dinámica y ordenada que contiene todos los requisitos del producto que el cliente necesita. Es gestionada por el Product Owner, quien enumera las características, funcionalidades y mejoras que necesita. Cabe destacar que esta lista evoluciona a medida que lo hace también el producto. Por otro lado, el Sprint Backlog es una lista de pendientes que contiene las historias de usuario y tareas que el equipo ha decidido abarcar a lo largo del sprint, destacando las actividades necesarias para alcanzar el objetivo del sprint.

3.2.2.4.3 Eventos Scrum.

De acuerdo al Scrum Alliance (2017), existen eventos ya predefinidos que buscan regular y garantizar la calidad del proceso Scrum (ver Figura 2), de manera que se apliquen en el tiempo determinado. Estos eventos se detallarán a continuación.

Sprint: Es el tiempo en el cual se debe desarrollar un incremento del producto y se puede definir como el contenedor del resto de eventos. Es recomendable que el sprint dure cuatro semanas y que el incremento desplegado al final del período sea totalmente funcional.

Sprint Planning: Se trata de una reunión donde se realiza la planificación para el sprint de un mes. Dicha reunión va dirigida a todo el equipo Scrum, dura máximo ocho horas y deberá responder dos cuestiones: qué puede realizarse en el sprint actual y cómo se conseguirá culminar el trabajo establecido (desarrollar un incremento funcional).

Daily Scrum: Se trata de una reunión diaria donde los involucrados planifican lo que harán en las próximas 24 horas. Dicha reunión va dirigida únicamente al equipo de desarrollo, se recomienda que dure alrededor de 15 minutos y deberá responder tres cuestiones: qué actividades hizo el día anterior, qué actividades realizará el día de hoy y qué inconvenientes se han presentado que puedan retrasar el desarrollo del producto.

15

Sprint Review: Se trata de una reunión informal donde se revisa el Product Backlog, se explica qué elementos se han realizado y cuáles no y se determina si el incremento se ha desarrollado con éxito. Dicha reunión va dirigida a todo el equipo Scrum y a las personas externas interesadas en el producto, se recomienda que dure alrededor de cuatro horas y su objetivo también es definir los elementos que conformen el siguiente Product Backlog.

Sprint Retrospective: Para algunos, se trata de la reunión más importante de Scrum donde se analiza la forma de trabajar del equipo, destacando los puntos fuertes y débiles que se presentan para luego buscar una solución a estos inconvenientes. Dicha reunión va dirigida al equipo Scrum, se recomienda que dure alrededor de tres horas y se realiza después del Sprint Review y antes del Sprint Planning del siguiente mes.

Figura 2. Flujo del proceso Scrum. Adaptado de “Ingeniería de Software: Un Enfoque Práctico” por R. Pressman, 2010, p. 70.

3.2.3. Desarrollo Web. 3.2.3.1. Lenguajes.

Los lenguajes que se utilizan en el desarrollo web pueden clasificarse en dos grupos: El lenguaje Back-End que trabaja en el lado del servidor y el lenguaje Front-End que trabaja en el lado del cliente. Más adelante se explicará a detalle cada uno de los lenguajes utilizados.

16

3.2.3.1.1 Back-End. PHP: El lenguaje PHP (Hypertext Preprocessor) es uno de los lenguajes de programación más populares del desarrollo web. Este lenguaje cuanta con diferentes características que lo hacen único, como lo son su rendimiento, su disponibilidad multiplataforma, su facilidad de uso, su distribución libre a través de internet y el respaldo de una numerosa comunidad. Cabe destacar que se lo conoce como un lenguaje interpretado, pues no hay necesidad de compilarlo para comprobar los cambios que se realicen en el código fuente, esto gracias al administrador de memoria y caché que incorpora (Vaswani, 2012, pp. 4-7).

3.2.3.1.2 Front-End. HTML: El lenguaje HTML (Hyper Text Markup Language) es un lenguaje estandarizado en la creación de páginas web. Este lenguaje utiliza etiquetas que definen el contenido que se mostrará en el documento, además describe la estructura de la página web.

Cabe destacar que este no es un lenguaje de programación sino un lenguaje interpretado, pues no hace falta compilar el código para observar los cambios que se han realizado; aquí el navegador es el encargado de interpretar el documento HTML (W3Schools, 2017).

CSS: El lenguaje CSS (Cascading Style Sheets) facilita el control de cómo los elementos

de

un

documento

HTML

son

desplegados

en

pantalla,

separando

independientemente el diseño de su estructura (HTML). Este también es un lenguaje estandarizado y su objetivo es agilizar el diseño de las páginas web, adaptándolas a diferentes dispositivos. Básicamente, CSS es un conjunto de reglas y valores asociados a propiedades de estilo que definen la manera de presentar un documento (Peña, 2010, pp. 46-47).

JavaScript: Es un lenguaje interpretado, compacto y muy flexible, el cual se encarga de generar funcionalidades en el documento HTML que no podría realizar por sí mismo. No se debe confundir este lenguaje con Java, pues son completamente diferentes; JavaScript tiene funcionalidades más sencillas que Java (además de una sintaxis menos compleja), por ejemplo, las variables en JavaScript pueden almacenar cualquier tipo de dato, a diferencia de Java que se debe declarar un tipo de dato específico para que lo almacene (López J. , 2014, pp. 16-17).

17

3.2.3.2. Arquitectura.

En el desarrollo de aplicaciones y entornos web además de considerar los requerimientos y restricciones existente también se debe tener en cuenta la distribución de sus elementos. Para ello, la arquitectura define la estructura de cómo se implementará dicho software. A continuación, se definirán las siguientes arquitecturas principales.

3.2.3.2.1 Modelo Cliente/Servidor.

Este modelo, también conocido como modelo de dos capas, se basa en la idea de que el servidor es quien provee de servicios y el cliente es aquel que los solicita. Este tipo de arquitectura no necesita de otra capa que realice algún procesamiento lógico pues se comunican directamente (ver Figura 3). Aquí el cliente es quien inicia el intercambio de datos enviando solicitudes al servidor, de manera que responda con la información requerida; usualmente se utiliza el lenguaje HTML para organizar de forma visual la información del lado del cliente (Kappel, Pröll, Reich, & Retschitzegger, 2011, pp. 72-73).

Figura 3. Vista general del Modelo Cliente/Servidor. Adaptado de “Desarrollo Web en Entorno Servidor” por M. López, J. Vara, J. Verde, D. Sánchez, J. Jiménez y V. Castro, 2012, p. 14.

18

3.2.3.2.2 Modelo de Múltiples Capas.

Este modelo permite organizar un servicio o aplicación web en n número de capas según sea necesario. Generalmente, estas estructuras consisten de tres capas, como lo son: la capa de datos, la cual provee el acceso a la información. La capa de negocio, donde se reciben las peticiones de parte del usuario y se envían las respuestas adecuados luego de procesar la información. Y la capa de presentación, la cual muestra la información solicitada en una interfaz gráfica amigable para el usuario (Kappel et al., 2011, pp. 73-74).

3.2.3.2.3 Modelo-Vista-Controlador.

El Modelo-Vista-Controlador (MVC) es el patrón de diseño más recomendado en el desarrollo de aplicaciones interactivas, dado que distribuye las funcionalidades del sistema en diferentes objetos. Para entender de mejor manera el proceso que realiza este modelo, se definirá las tres abstracciones que realiza: modelo, vista y controlador.

En el modelo se encuentra la información y los procesos lógicos del sistema. Es quien avisa a la vista cuando se ha producido algún cambio en los datos y permite acceder a ellos. La vista es la interfaz que muestra la información al usuario, misma que se actualiza cuando se hayan modificado los datos para que puedan ser observados; cabe destacar que puede haber varias vistas de un mismo modelo. Y el controlador es quien responde las peticiones del usuario, realizando cambios en el modelo y actualizando la vista según los eventos que se hayan producido (Roldán, Valderas, & Pastor, 2014, pp. 137-138).

3.2.4. Base de Datos.

Una base de datos es una colección de información que se almacena de manera estructurada en tablas para su posterior procesado. Cada tabla está formada por filas y columnas, a dichas filas se las conoce como registros y a las columnas se las conoce como campos. Tomando como ejemplo la base de datos de una empresa, cada fila puede almacenar la información de muchas personas (registros) y cada columna almacena un dato en concreto (campos) de manera que la información sea coherente y legible (López, 2014, p. 370).

19

3.2.4.1. Sistema Gestor de Base de Datos.

Un sistema gestor de base de datos (SGBD) es un tipo de software especializado que facilita el uso, consulta y manipulación de una base de datos mediante herramientas gráficas o potentes lenguajes de programación. Estos sistemas permiten a los usuarios un alto grado de manejo de las bases de datos, garantizando la integridad y el respaldo de la información y ofreciendo conectarse con el exterior (López, Castellano, & Ospino, 2014, pp. 14-15).

A continuación, se detallarán algunos de los sistemas gestores más utilizados.

MariaDB: Es uno de los más populares SGBD en el mundo, dado que Wikipedia, WordPress.com y Google lo utilizan. Entre las características que lo destacan del resto están su compatibilidad con MySQL, su velocidad, escalabilidad, versatilidad e inclusión de GIS y JSON entre sus funciones. Fue creada por los desarrolladores originales de MySQL y se distribuye bajo la licencia GPL versión 2, la cual garantiza la libertad de modificar y distribuir libremente el software tanto como desee el usuario (MariaDB Foundation, 2017).

Oracle Database: Es un sistema gestor de base de datos relacional que implementa características orientadas a objetos como la herencia y el polimorfismo, por lo que se lo conoce como Object-relational Database Management System (ORDBMS). Brinda una interfaz gráfica completamente funcional sin dejar de lado el uso del lenguaje SQL, ofrece una gran integridad de los datos y un robusto sistema de respaldos en la nube. Cabe destacar que la mayor parte de sus funcionalidades son de pago (Oracle Corporation, 2017).

PostgreSQL: Es un potente sistema gestor de base de datos orientado a objetos que funciona en la mayoría de sistemas operativos. Obedece a las propiedades ACID, acrónimo que define las propiedades de las transacciones de una base de datos. Está diseñado para trabajar en entornos que manejen grandes volúmenes de datos, es escalable, estable y cuenta con interfaces nativas para trabajar con diferentes lenguajes de programación. Además, es distribuida bajo su propia licencia libre, la cual permite el uso, copia, modificación y distribución del software sin coste alguno (PostgreSQL Global Development Group, 2017).

A continuación, se muestra una tabla comparativa entre los sistemas gestores anteriormente mencionados con la finalidad de observar detalladamente las diferentes características que hacen destacar a cada uno de ellos:

20 Tabla 1.

Características de los SGBD MariaDB a

Característica

Open-Source

Licencia

MariaDB Foundation

Desarrollador

Lanzamiento

Sistemas Operativos

Oracle Database b

Comercial

PostgreSQL c

Open-Source

PostgreSQL

Oracle

Global

Development Group

2009

1980

1989

FreeBSD, Linux, Solaris,

AIX, HP-UX, Linux, OS

FreeBSD, HP-UX,

Windows

X, Solaris, Windows,

Linux, NetBSD,

z/OS

OpenBSD, OS X,

Soportados

Solaris, Unix, Windows

Ada, C, C#, C++, D,

C, C#, C++, Clojure,

.Net, C, C++, Delphi,

Eiffel, Erlang, Go,

Cobol, Delphi, Eiffel,

Java, Perl, PHP, Python,

Haskell, Java, JavaScript

Erlang, Fortran, Groovy,

Tcl

Lenguajes de

(Node.js), Objective-C,

Haskell, Java,

Programación

OCaml, Perl, PHP,

JavaScript, Lisp,

Soportados

Python, Ruby, Scheme,

Objective C, OCaml,

Tcl

Perl, PHP, Python, R, Ruby, Scala, Tcl, Visual Basic

Nota:

a

Adaptado de “About MariaDB" por MariaDB Fundation, 2017.

b

Adaptado de “Database Concepts” por Oracle

Corporation, 2017. Adaptado de “About PostgreSQL” por PostgreSQL Global Development Group, 2017. c

21

3.2.4.2. Lenguaje SQL. El lenguaje SQL (Structured Query Language) es un lenguaje específico de domino estandarizado por la ISO que permite el acceso y manipulación de las bases de datos. Surgió principalmente para solventar los problemas que generaba la inconsistencia de los datos y la falta de comunicación entre diferentes aplicaciones. Este lenguaje hace uso de instrucciones SQL, también llamadas consultas, que se dividen en tres categorías: DML, DDL y DCL. La primera categoría es el lenguaje DML o lenguaje de manipulación de datos, permite insertar, modificar o eliminar información. La segunda es el lenguaje DDL o lenguaje de definición de datos, permite crear y manipular las tablas donde se guardará la información. Por último, el lenguaje DCL o lenguaje de control de datos, permite al administrador gestionar el acceso a la información que posee la base de datos (López J. , 2014, pp. 372-373).

3.2.4.3. Modelado de Datos.

El modelar los datos se define como la interpretación de un problema abstrayendo sus cualidades para posteriormente tratarlas de manera aislada, de modo que sea posible construir todos los objetos de una base de datos. Para satisfacer las diferentes necesidades que supone una base de datos se utilizan tres tipos de modelados de datos: conceptual, lógico y físico.

El modelo conceptual es aquel que representa el problema tal cual es y puede comunicarse con el usuario que no es experto en informática; aquí se encuentra el Modelo Entidad/Relación. A su vez, el modelo lógico es más difícil de entender y dependerá de la implementación de la base de datos; aquí se encuentra el Modelo Relacional. Finalmente, el modelo físico es la aplicación del modelo lógico en un SGBD específico, generalmente implementado con el lenguaje SQL (López et al., 2014, pp. 40-41).

3.2.5. Documentos Electrónicos.

3.2.5.1. Tipología de los Documentos Electrónicos.

Una correcta denominación que se le puede otorgar a los documentos electrónicos es un tipo de documento específico creador a partir de instrumentos informáticos. Estos documentos pueden ser de carácter público, privado, mercantil y oficial; también son llamados documentos informáticos y presentan información elaborada o procesada electrónicamente, brindando enormes posibilidades de almacenamiento y difusión (Bennasar, 2010, p. 50)

22

3.2.5.2. Medios Electrónicos.

Los medios electrónicos son los instrumentos por donde los archivos digitales son difundidos en grandes cantidades sin restricción geográfica. En la actualidad, casi todas las empresas optan por utilizar sistemas electrónicos o informáticos debido a la agilidad que brinda a la hora de comunicar y compartir información. Como ejemplo de estos medios electrónicos están: el fax, el correo electrónico, servicios en la nube, etcétera (Morueco, 2013, p. 303).

3.2.6. Proceso Contable.

El Proceso Contable, también conocido como Ciclo Contable, es una secuencia de pasos que empieza cuando se origina la transacción hasta que se presentan los Estados Financieros. Aquí se utilizan los comprobantes o documentos fuente para registrar y respaldar toda operación contable que realiza la empresa, por lo que se definirá brevemente lo que son estos documentos y cómo se clasifican (Bravo, 2011, p. 33).

3.2.6.1. Comprobantes.

Los comprobantes son documentos que justifican, controlan y registran las operaciones comerciales o transacciones que realiza un ente económico, diseñados según la información que se necesita. Son sumamente importantes en el registro de la contabilidad que debe llevar una empresa, pues constituyen una prueba fiable de las operaciones realizadas. Algunos ejemplos de estos son: facturas, notas de débito, notas de crédito, remisiones, roles de pago, comprobantes de venta, letras de cambio, cheques, entre otros (Díaz, 2011, p. 360).

3.2.6.2. Clasificación de Comprobantes.

De acuerdo con Bravo (2011), los comprobantes pueden clasificarse en dos tipos: documentos negociables y documentos no negociables. Los negociables son aquellos que se utilizan para garantizar una obligación, una deuda, un financiamiento, etc. Está sujeta a diferentes formalidades legales, las cuales deben llevarse cuidadosamente. Y los no negociables son aquellos que se usan a diario en la contabilidad que lleva la empresa. Son fundamentales para que se lleve un control adecuado de las operaciones comerciales (p. 35).

23

3.2.7. Gestión de Documentos.

La gestión de documentos, tanto de los archivos de papel como los archivos electrónicos, es esencial en la organización y homogenización del trabajo. Esta gestión lo que busca es la centralizar los archivos existentes, organizarlos de manera adecuada y definir mecanismos para que la locación de documentos se realice de forma sencilla, rápida y segura, todo esto con el fin de evitar entorpecer o retrasar las actividades de la empresa y, naturalmente, reducir costos administrativos y materiales (Fincowsky, 2014, pp. 59-60).

3.2.7.1. Gestión.

La gestión se puede definir como un proceso organizado que busca alcanzar un objetivo específico, para lo cual se realizan acciones relacionadas con la administración. Para conseguir un resultado óptimo en la gestión de alguna necesidad se debe poner en práctica los conocimientos, aptitudes y herramientas necesarias para cubrir los requerimientos de la empresa. Cabe aclarar que es imprescindible conocer y desarrollar adecuadamente la gestión de algún proyecto según la naturaleza de la operación (Rubio, 2011, p. 17).

3.2.7.2. Documentación.

Un documento es una entidad física utilizada para escribir y registrar información para almacenarla o procesarla posteriormente. Naturalmente, las empresas son quienes mayores volúmenes de documentos generan, los cual crece exponencialmente con el paso de los años y provocan una fuerte inversión monetaria en equipos, personas y procesos para la producción de papel. En la actualidad se está optando por digitalizar estos documentos con el fin de manejar eficazmente la organización de toda la información que las empresas necesitan, por ello se definirá brevemente este tema más adelante (Mushhad, Gilani, Ahmed & Abbas, 2013).

3.2.8. Digitalización.

Es el proceso de conversión de datos analógicos en digitales, también se puede definir como la conversión de un documento físico en un documento digital. Ciertos tipos de datos (como sonidos e imágenes) son definidos como fenómenos continuos o analógicos; para usar todo el potencial que nos brindan las computadoras se deben transformar estos tipos de datos analógicos. A continuación, se definirá de manera detallada lo que son los archivos digitales y las ventajas que supone utilizar esta información digital (Savage & Vogel, 2014, p. 25-26).

24

3.2.8.1. Archivos Digitales.

Las computadoras utilizan el código binario como lenguaje universal, es decir, toda instrucción o aplicación está representada por ceros y unos. Un archivo digital es la conversión de este código binario en un sinnúmero de formatos disponibles. Entre los aspectos que caracterizan a estos archivos son: el tamaño, la extensión, la compatibilidad y conversión del archivo. Cabe destacar el tamaño de un archivo se mide por el número de bytes que lo compone y no se debe confundir con el número de bits, los cuales son utilizados generalmente para medir la velocidad de transferencia electrónica (Savage & Vogel, 2014, p. 23).

3.2.8.2. Ventajas de la Información Digital.

Gracias a las computadoras podemos (de manera virtual) realizar cualquier proceso con la información digital que se encuentre disponible. El avance tecnológico brinda ventajas significativas respecto al uso del material digital, entre los cuales está: La reproducción, lo cual estipula que la información puede ser copiada las veces que sean necesarias sin comprometer la calidad de la misma. La edición, que permite modificar los archivos digitales tanto como guste el usuario; el ejemplo que mejor se acopla a esta ventaja es la edición de texto o fotografía, esta última requiere mayor trabajo por parte del computador.

La integración, que no es más que el almacenar y permitir el acceso a un archivo desde cualquier dispositivo, permitiendo conservarlo intacto para su posterior uso. Y la distribución, que permite la difusión de la información a través de diferentes medios de comunicación, de manera que todo el mundo sea capaz de acceder a ella (Savage & Vogel, 2014, pp. 32-33).

25

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

El presente trabajo de disertación posee un enfoque mixto, puesto que combina métodos cuantitativos y cualitativos a lo largo de su desarrollo. El objetivo de este enfoque es responder al planteamiento del problema juntando los procesos de recolección, análisis y vinculación de datos cuantitativos y cualitativos, haciendo uso de las fortalezas que ambos enfoques presentan y tratando de minimizar sus debilidades (Hernández, Fernández, & Baptista, 2014, p. 532).

Respecto a lo anteriormente mencionado, el enfoque cuantitativo es aplicado al analizar los resultados obtenidos de las encuestas que se realizaron a los clientes de la empresa. Así mismo, el enfoque cualitativo es aplicado mediante las entrevistas que se realizaron a las personas que conforman el departamento de sistemas de la empresa, con el fin recabar la información y las funcionalidades necesarias para el desarrollo del web service.

4.1.2. Diseño de la Investigación.

4.1.2.1. Diseño Exploratorio Secuencial (DEXPLOS).

Este diseño es propio del enfoque mixto e implica una fase inicial de recolección y análisis de datos cualitativos seguida de otra donde se tome en cuenta los datos cuantitativos.

El diseño exploratorio secuencial trabaja en dos modalidades: derivativa y comparativa.

Para la presente investigación se aplicó la modalidad derivativa, la cual empieza trabajando con los datos cualitativos para posteriormente hacerlo con los datos cuantitativos.

Se optó por utilizar el DEXPLOS, puesto que se inició con la aplicación de las entrevistas para explorar el planteamiento del problema para luego proceder con la elaboración y aplicación de las encuestas en base a la información anteriormente recogida, con el fin de preparar una interpretación final de la investigación (Hernández, Fernández, & Baptista, 2014, pp. 551-552).

26

4.1.3. Tipos de Investigación.

4.1.3.1. Investigación Bibliográfica.

El presente proyecto utiliza la investigación bibliográfica, pues se ha apoyado en diversas fuentes bibliográficas, como libros, artículos científicos y renombradas páginas web, con el fin de evidenciar que la información que ha sido presentada sea fidedigna. Además, se ha cuidado minuciosamente que las fuentes utilizadas sean confiables y que toda la información recabada sea referenciada conforme a las Normas APA (6ta. Edición).

4.1.3.2. Investigación Descriptiva.

La investigación descriptiva busca identificar, narrar y explicar las características o propiedades que posee el objeto de estudio, así como también puede describir un sistema, prototipo o modelo que se esté desarrollando (Bernal, 2014, p. 113). En este caso, este tipo de investigación se aplica con el objetivo de detallar las causas y consecuencias de la problemática estudiada, haciendo uso de las entrevistas y encuestas para recoger la información requerida.

4.1.3.3. Investigación Aplicada.

El presente trabajo de investigación también utiliza la investigación aplicada, pues busca aplicar los conocimientos adquiridos durante la formación profesional en el desarrollo del proyecto planteado. Cabe destacar que este tipo de investigación constituye el enlace entre la teoría necesaria para el desarrollo del software requerido y el producto final desarrollado.

4.2. Población/Universo La población es un conjunto de elementos con características similares que conforman el universo de estudio, mismo que puede ser finito o infinito (Arias, 2012, p. 81). En la presente investigación se considera como población al número de clientes y las personas que conforman el departamento de sistemas de la empresa, los cuales son 1000 y 2 personas respectivamente.

Debido a que se conoce que la población total son 1002 personas, se la puede definir como una población finita. De acuerdo con Sierra (1991) citado por Arias (2012, p. 82), una población finita es una agrupación de individuos de la que se conoce la cantidad total de unidades que la integran. Se puede decir también que una población finita está conformada por un número menor a cien mil unidades, hablando desde un punto de vista estadístico.

27

4.3. Muestra Puesto que se conoce que la poblaciĂłn objetivo es finita, se aplicarĂĄ la fĂłrmula que propone Arias (2012) para este caso, misma que se presenta a continuaciĂłn:

đ?‘›=

đ?‘ ∗ đ?‘?2 ∗ đ?‘† 2 (đ?‘ ∗ đ?‘’ 2 ) + (đ?‘? 2 ∗ đ?‘† 2 )

Donde: 

n es el tamaĂąo de la muestra (poblaciĂłn a la que se aplicarĂĄn las encuestas).



N es el nĂşmero de elementos que conforman la poblaciĂłn total.



Z es el nivel de confianza, para un nivel del 95% el valor de Z es 1.96.



S es la desviaciĂłn estĂĄndar que en caso de no conocerla tiene un valor de 0.5.



e es el margen de error aceptable que debe ir entre 1% y 5%.

Ahora se aplica la fĂłrmula en funciĂłn a la poblaciĂłn del presente proyecto de investigaciĂłn, con un margen de error del 5% y tomando los valores de 1.96 y 0.5 para los valores de Z y S respectivamente, tenemos que:

đ?‘›=

1002 ∗ 1.962 ∗ 0.52 (1002 ∗ 0.052 ) + (1.962 ∗ 0.52 ) đ?‘›=

962.3208 3.4654

đ?‘› = 277.69 Por lo tanto, el nĂşmero muestral de esta investigaciĂłn es de 278 personas.

28

4.4. Técnicas e Instrumentos de Recogida de Datos 4.4.1. Entrevista.

La entrevista es una técnica orientada a establecer la comunicación directa con las personas que son consideradas fuente de información (Bernal, 2014, p. 194). En este caso, será aplicada a las dos personas que conforman el departamento de sistemas de la empresa. Cabe destacar que su uso será guiado por un banco de preguntas flexible, de modo que permita obtener la información necesaria para el iniciar con el desarrollo del web service.

4.4.2. Encuesta.

La encuesta es una técnica que permite interrogar a los individuos mediante un cuestionario preparado con el propósito de obtener información respecto al tema de estudio. Es una de las técnicas de recogida de datos más utilizadas (Bernal, 2014, p. 194). En este caso, se elaborará un cuestionario de diez preguntas que se aplicará a los clientes de la empresa, con el fin de analizar el impacto que genera el desarrollo del web service.

4.5. Técnicas de Análisis de Datos En lo que respecta al análisis cualitativo, la información recogida mediante las entrevistas y las posteriores reuniones con el cliente sirvieron para plasmar las funcionalidades del sistema. Por otro lado, para el análisis cuantitativo se utilizó la herramienta computacional SPSS; dicha herramienta permite utilizar tablas de distribución de frecuencias e histogramas para representar los resultados que generó la información recabada a través de las encuestas.

4.6. Metodología de Desarrollo de Software Anteriormente se ha fundamentado que las metodologías ágiles permiten trabajar de manera dinámica, pues se adaptan a los cambios que se presentan a lo largo del desarrollo de un producto. Partiendo de esta premisa, se determina que la metodología de desarrollo que mejor se ajusta a las necesidades del software es la combinación de XP y SCRUM, gracias a que la Programación Extrema se enfoca en las prácticas de desarrollo de software y Scrum apunta todos los aspectos de la administración de proyectos.

A continuación, se detallará el por qué se ha optado por combinarlas.

29

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

Antes de explicar el por qué se ha optado por combinar XP y Scrum, en la siguiente tabla se muestra un breve resumen de los criterios más relevantes que posee cada una de ellas.

Tabla 2.

Comparativa entre XP y Scrum Criterio

Programación Extrema (XP) a

Scrum b

Denominación

Metodología Ágil

Marco de Trabajo

Enfoque

Iterativo e incremental

Iterativo e incremental

Equipo de Desarrollo

De 2 a 12 integrantes

De 3 a 9 integrantes

Modo de Trabajo

Programación por parejas

No especifica

Objetivo

Desarrollo de software

Gestión de producto

No fijos

No fijos

Requerimientos Funcionales

Tiempo de Iteración

Nota:

a

De 1 a 3 semanas

De 2 a 6 semanas (4 semanas recomendadas)

Adaptado de “Scrum y XP desde las Trincheras” por H. Kniberg, 2015.

Definitive Guide to Scrum: The Rules of the Game” por Scrum Alliance, 2017.

b

Adaptado de “The Scrum Guide, The

30

En primer lugar, es necesario aclarar que Scrum es un marco de trabajo, a diferencia de la Programación Extrema, la cual es una metodología ágil. Ambas opciones son frecuentemente utilizadas en el desarrollo de software ágil, pero son pocas las situaciones en las que se decide combinarlas. En la actualidad se puede decir que no se contraponen, más bien que se complementan siempre y cuando se utilice lo mejor de cada una de ellas. A continuación, se detallarán las prácticas, eventos y artefactos que cubren las necesidades del producto: Tabla 3.

Cualidades relevantes de XP y Scrum Programación Extrema (XP)

Scrum

Estándares de Codificación

Product Backlog

Diseño Simple

Sprint Backlog

Refactorización

Daily Scrum

Integración Continua

Sprint Review

Pruebas

Sprint Retrospective

Nota: Adaptado de “Scrum y XP desde las Trincheras” por H. Kniberg, 2015.

También se hará uso de las historias de usuario, instrumento que sirve para recabar las funcionalidades que necesita el cliente, así como también la prioridad, la estimación y el riesgo de desarrollarlas. Es necesario destacar que estas historias son consideradas una buena práctica en el desarrollo ágil de software y no pertenecen a ninguna metodología en específico.

El cliente también ha dictado varios criterios de aceptación, los cuales sirven como escenario de pruebas para determinar si se ha cumplido con el objetivo de cada historia. Este cumplimiento se ve evidenciado en las pruebas de aceptación, documentos donde constan las condiciones de ejecución y el resultado esperado de cada historia de usuario; adicionalmente, una vez que la prueba de aceptación se haya superado con éxito, el Product Owner procederá a firmar el documento para corroborar que acepta el resultado esperado.

31

4.6.2. Características de la Programación Extrema (XP).

En lo que respecta a la metodología ágil XP, se ha buscado extraer las características que cubran las funcionalidades del sistema, como lo son: historias de usuario, diseño simple, refactorización e integración continua. Para simplificar la descripción del uso de cada una de ellas se ha realizado la siguiente tabla.

Tabla 4.

Características aplicables de XP Programación Extrema (XP)

Estándares de Codificación

Aquí se ha especificado un estilo y formato para el código fuente. Esta práctica mantiene el código consistente, facilitando la lectura, interpretación y refactorización que se pueda dar en un futuro.

Se ha hecho especial énfasis en mantener el código lo más simple posible, Diseño Simple

priorizando las historias de usuario planeadas y evitando dar importancia a las funcionalidades que se implementen a futuro.

Se han realizado cambios pertinentes en el código para mantenerlo limpio y Refactorización

legible, con el objetivo de que sea más fácil añadir características sin alterar la funcionalidad del sistema.

Aquí se establece que cada tarea realizada se ha integrado al sistema, haciendo Integración Continua

uso de las pruebas unitarias a fin de corroborar que el agregado no perjudica las funcionalidades existentes.

Se han realizado tres tipos de pruebas: Unitarias, las que se realizaron con mayor Pruebas

frecuencia; Integración, ejecutadas al incluir nuevas funcionalidades; Aceptación, realizadas por el usuario. Este patrón de pruebas está basado en la Pirámide de Mike Cohn.

Nota: Adaptado de “Scrum y XP desde las Trincheras” por H. Kniberg, 2015.

32

4.6.3. Características de Scrum.

Al tratarse del marco de trabajo Scrum, es mejor explicar por separado las características y el proceso que ha sido empleado, empezando por la siguiente tabla.

Tabla 5.

Características aplicables de Scrum Scrum

Aquí se han enlistado todas las historias de usuario que el Product Owner ha Product Backlog

definido, organizándolas de acuerdo a la prioridad, la estimación y el riesgo de desarrollo que se ha estimado.

Aquí, en cambio, se han enlistado las historias de usuario que se realizarán a lo Sprint Backlog

largo del sprint. Este artefacto también hace uso del gráfico Burndown Chart para mostrar el tiempo que hace falta para completar las funcionalidades y medir el desempeño realizado.

Esta reunión es indispensable para verificar el trabajo realizado el día anterior, Daily Scrum

visualizar las tareas que se desarrollarán a lo largo del día e identificar algún obstáculo que se haya presentado.

Esta reunión se realiza al final de cada sprint con el objetivo de verificar las tareas Sprint Review

se han realizado, las que no y el por qué, de manera que se corrijan estas falencias para el próximo sprint.

Esta reunión se produce a fin de analizar detenidamente el trabajo realizado a lo Sprint Retrospective

largo del sprint. De esa manera se han detallado los puntos fuertes y débiles del proceso que se lleva a cabo.

Nota: Adaptado de “Scrum y XP desde las Trincheras” por H. Kniberg, 2015.

33

4.6.4. Combinando XP y Scrum.

La combinación de las características descritas anteriormente mejora todo el proceso de desarrollo de software, empezando por el levantamiento de la información. Las historias de usuario facilitan la tarea de recopilar las funcionalidades del cliente y se consideran una excelente alternativa a los Sprint Backlog Items convencionales.

Haciendo referencia a XP, se considera que el ciclo de vida que propone esta metodología es el adecuado para el producto, en vista de que se enfoca totalmente al desarrollo de software. Tomando en consideración que el Development Team sólo lo conforma el autor, se deduce que algunas prácticas XP no pueden ser aplicadas (como la programación en parejas, por ejemplo), pero las demás prácticas mencionadas anteriormente sí, debido a que brindan grandes beneficios para el desarrollo del producto y la calidad de vida del programador.

Un código limpio, simple y legible facilita enormemente los procesos de refactorización e integración del software, además de que lo hace escalable a futuro. De igual manera, las pruebas realizadas a lo largo del desarrollo son fundamentales para la entrega de un producto funcional que cumpla las expectativas del cliente; por otra parte, dicho desarrollo fue dividido en sprints, por lo cual se puede observar lo bien que SCRUM puede complementar a XP. En lo que respecta a SCRUM, los artefactos como el Product Backlog organiza las historias de usuario de acuerdo a la prioridad que el cliente les haya otorgado; de la misma forma, el Sprint Backlog organiza las tareas de ingeniería que componen cada historia de usuario y lleva un control sobre el desarrollo de cada una de ellas. Los eventos también resultan indispensables en el desarrollo del producto, puesto que permiten verificar diariamente el trabajo realizado y las tareas pendientes, analizar los problemas que han surgido, las posibles soluciones que se pueden aplicar y las mejoras que se pueden poner en práctica posteriormente.

34

5. RESULTADOS 5.1. Discusión y Análisis de los Resultados 5.1.1. Análisis de la Entrevista.

A través de la aplicación de la entrevista realizada al encargado del departamento de sistemas de Emproservis (ver Anexo 4), se recabaron las respuestas a las interrogantes planteadas, mismas que se transcribieron a continuación: a) ¿Cuántas personas están a cargo del departamento de sistemas?

Dos personas. b) ¿Qué tipo de cargo ustedes desempeñan en la empresa?

Mi cargo es jefe de sistemas, lo que corresponde a mis responsabilidades son: administrar los servidores, sistemas operativos, radio enlaces, gestionar la compra e implementación de nuevas tecnologías, proyectos de desarrollo e implementación de software, administrar el ERP de la empresa, capacitar a los usuarios, entre otras.

Los cargos de mi asistente son: dar soporte a los usuarios, mantenimiento de los computadores y llevar a cabo los requerimientos solicitados por los usuarios. c) ¿Cómo es el proceso de gestión de los documentos en la empresa?

Cada vez que un usuario sea persona de facturación o en este caso, de pagos, ellos generan retenciones y de forma automática, vía correo electrónico, se envían al proveedor o al cliente. En este caso, llega el RIDE y el archivo XML. d) ¿Cuál es el proceso de entrega de documentos hacia los clientes?

Mediante correo electrónico. e) ¿La empresa cuenta con un sitio web? ¿qué información presenta?

Emproservis cuenta con una aplicación web, pero esta solamente es de información y servicios que ofrece la compañía. De ahí, no existe un portal que permita descargar los archivos de facturación.

35

f) ¿Tienen algún inconveniente con la gestión de documentos?

Sí, en este momento se presentan inconvenientes de que los proveedores y clientes nos dicen que no les llegan las retenciones, facturas y notas de crédito; también hay veces que se envían mal los correos electrónicos o ingresan mal la dirección de correo y no le llegan los documentos al destinatario, esto es un problema tremendo para nosotros. g) ¿Cuál sería el enfoque que tendría el web service?

En este caso, que el propio cliente o proveedor pueda descargar sus documentos electrónicos sin necesidad de que nosotros tengamos que enviárselos. Él dispondrá el momento y la hora que vaya descargar y nosotros evitaríamos ese problema que actualmente tenemos. h) ¿De qué maneras deberían compartirse los documentos?

Los documentos deben ser cargados a la web de forma automática, digamos, en un horario y entonces el proveedor o cliente simplemente descargaría sus documentos. i) ¿Tiene alguna preferencia respecto a los lenguajes y sistema operativo con los que desee que se desarrolle el web service?

De preferencia que sea con open source, que sean lenguajes que no tengamos que pagar ninguna licencia y la base de datos de igual manera, para evitar costos adicionales y enfocarnos en sí en el tema de soporte. El lenguaje de la base de datos puede ser PostgreSQL o MariaDB y el lenguaje de programación puede ser PHP, esas serían las herramientas que puedes utilizar.

El sistema operativo de preferencia que sea Linux. j) En caso de que se implemente el web service, ¿cuántos usuarios estima que harán uso de la misma como administradores?

Como administradores serían solamente dos personas. k) En caso de que se implemente el web service, ¿cuántos usuarios estima que harán uso de la misma como clientes?

Unas 1000 personas.

36

Conclusión: De acuerdo con las respuestas recabadas en la entrevista se concluye que Emproservis tiene inconvenientes con la entrega de los documentos electrónicos hacia sus clientes, pues los correos electrónicos no siempre llegan a sus destinatarios. La solución propuesta es sumamente necesaria, dado que permitirá a los clientes acceder y descargar sus documentos en formato PDF y XML. El encargado de sistemas de la empresa, en función de Product Owner, ha solicitado que para el desarrollo del web service se empleen herramientas open source, que para base de datos se utilice PostgreSQL y como sistema operativo se utilice cualquier distribución de Linux. Finalmente, se establece que serán dos personas las que se encargarán del web service como administradores y que 1000 clientes harán uso de la misma.

5.1.2. Análisis de las Encuestas.

A través de la aplicación de las encuestas realizadas a los clientes de Emproservis (ver Anexo 5), se ha recabado la información necesaria para corroborar el desarrollo del presente proyecto. A continuación, se analizarán cada una de las preguntas formuladas demostrando los resultados en tablas de frecuencias con sus respectivos gráficos: a) ¿Dispone usted de un dispositivo móvil (Smartphone)?

Tabla 6.

Disponibilidad de un dispositivo móvil Opciones Sí No Total Nota: Datos obtenidos de la investigación de campo.

Frecuencia 245 33 278

Porcentaje 88,13 11,87 100,00

37

Figura 4. Disponibilidad de un dispositivo móvil. Datos obtenidos de la investigación de campo.

Interpretación: La mayoría de los clientes de la empresa (88,13%) respondieron que sí disponen de un dispositivo móvil; por otra parte, los clientes restantes (11,87%) contestaron que no disponen de este tipo de dispositivo. Por ende, se concluye que resulta factible desarrollar el web service de manera que se adapte a todo tipo de resoluciones.

38

b) ¿Sabe usted utilizar el navegador en su dispositivo móvil?

Tabla 7.

Uso del navegador en un dispositivo móvil Opciones Sí No Total

Frecuencia 209 69 278

Porcentaje 75,18 24,82 100,00

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

Figura 5. Uso del navegador en un dispositivo móvil. Datos obtenidos de la investigación de campo.

Interpretación: Gran parte de los clientes de la empresa (75,18%) saben utilizar el navegador en un dispositivo móvil; al mismo tiempo, los clientes restantes (24,82%) respondieron que no saben utilizar el navegador en estos dispositivos. Por lo tanto, se concluye que el diseño responsivo del web service será sumamente útil para todos aquellos clientes que quieran acceder al mismo desde el navegador de sus dispositivos móviles.

39

c) ¿Dispone usted de una computadora personal?

Tabla 8.

Disponibilidad de una computadora personal Opciones Sí No Total

Frecuencia 251 27 278

Porcentaje 90,29 9,71 100,00

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

Figura 6. Disponibilidad de una computadora personal. Datos obtenidos de la investigación de campo.

Interpretación: La mayoría de los clientes de la empresa (90,29%) aseguran que poseen una computadora personal; por lo contrario, los clientes restantes (9,71%) contestaron que no disponen de una computadora. Por esta razón se concluye que el web service podrá ser utilizada por casi todos los clientes de la empresa.

40

d) En caso de disponer de una computadora personal, ¿sabe usted utilizar el navegador?

Tabla 9.

Uso del navegador en una computadora personal Opciones Sí No Total

Frecuencia 275 3 278

Porcentaje 98,92 1,08 100,00

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

Figura 7. Uso del navegador en una computadora personal. Datos obtenidos de la investigación de campo.

Interpretación: Casi la totalidad de los clientes de la empresa (98,92%) saben utilizar el navegador desde una computadora; por otra parte, los clientes restantes (1,08%) respondieron que no saben utilizar el navegador. Por consiguiente, se concluye que casi todos los clientes de la empresa podrán hacer uso del web service sin complicación alguna.

41

e) ¿Tiene algún inconveniente con el personal de la empresa?

Tabla 10.

Inconvenientes con el personal Opciones Sí No Total

Frecuencia 0 278 278

Porcentaje 0,00 100,00 100,00

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

Interpretación: En este caso, todos los clientes de la empresa (100%) aseguran de que no tienen ningún inconveniente con el personal de la empresa, por lo que se deduce que los clientes están satisfechos con la atención brindada por parte de los empleados.

42

f) ¿Existen inconvenientes con la entrega de sus documentos electrónicos por parte de la empresa?

Tabla 11.

Inconvenientes con la entrega de documentos Opciones Sí No Total

Frecuencia 268 10 278

Porcentaje 96,40 3,60 100,00

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

Figura 8. Inconvenientes con la entrega de documentos. Datos obtenidos de la investigación de campo.

Interpretación: Casi la totalidad de los clientes de la empresa (96,40%) respondieron que existen inconvenientes con la entrega de sus respectivos documentos electrónicos; por otro lado, los clientes restantes (3,60%) contestaron que no tienen ningún problema con la entrega de sus documentos. Por ende, se concluye que se presentan conflictos en la entrega de los documentos electrónicos de casi todos los clientes.

43

g) ¿Existe retraso en la entrega de sus documentos electrónicos?

Tabla 12.

Retraso en la entrega de documentos Opciones Sí No Total

Frecuencia 274 4 278

Porcentaje 98,56 1,44 100,00

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

Figura 9. Retraso en la entrega de documentos. Datos obtenidos de la investigación de campo.

Interpretación: Casi todos los clientes de la empresa (98,56%) aseguran que existe retraso en la entrega de sus respectivos documentos electrónicos; al mismo tiempo, los clientes restantes (1,44%) respondieron que no han tenido ningún tipo de retraso con dicha entrega. Por esta razón, se concluye que la entrega de los documentos electrónicos por parte de la empresa presenta retrasos en casi la totalidad de las ocasiones.

44

h) ¿Existe alguna plataforma que le permita acceder a sus documentos electrónicos?

Tabla 13.

Acceso a los documentos electrónicos Opciones Sí No Total

Frecuencia 0 278 278

Porcentaje 0,00 100,00 100,00

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

Interpretación: En este caso, la totalidad de los clientes de la empresa (100%) respondieron que no existe ninguna plataforma que les permita tener acceso a sus respectivos documentos electrónicos. Por consiguiente, se concluye que el desarrollo del web service es vital para proveer el acceso necesario a los clientes que lo requieran. i) ¿Puede usted descargar sus documentos electrónicos?

Tabla 14.

Descarga de los documentos electrónicos Opciones Sí No Total

Frecuencia 0 278 278

Porcentaje 0,00 100,00 100,00

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

Interpretación: En este caso, todos los clientes de la empresa (100%) aseguran que no pueden descargar sus documentos electrónicos de ninguna manera en caso de que lo requieran.

Por ende, se concluye que el desarrollo del web service resultará sumamente útil para permitir a los clientes descargar sus documentos en cualquier momento y desde cualquier dispositivo.

45

j) ¿Está de acuerdo con el desarrollo de una página web le ayude a consultar, organizar y descargar sus documentos electrónicos?

Tabla 15.

Desarrollo de una página web Opciones Sí No Total

Frecuencia 276 2 278

Porcentaje 99,28 0,72 100,00

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

Figura 10. Desarrollo de una página web. Datos obtenidos de la investigación de campo.

Interpretación: Casi la totalidad de los clientes de la empresa (99,28%) contestaron que están de acuerdo con el desarrollo de una página web que permita la consulta, organización y descarga de sus documentos electrónicos; por otra parte, los clientes restantes (0,72%) están en desacuerdo acerca del desarrollo de la página. Por esta razón, se concluye que el desarrollo del web service será bien recibido por casi todos los clientes que hagan uso de la misma.

46

k) ¿Está de acuerdo con que la página web pueda ser utilizada tanto en computadora como en un dispositivo móvil?

Tabla 16.

Página web con diseño responsivo Opciones Sí No Total

Frecuencia 256 22 278

Porcentaje 92,09 7,91 100,00

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

Figura 11. Página web con diseño responsivo. Datos obtenidos de la investigación de campo.

Interpretación: Casi todos los clientes de la empresa (92,09%) están de acuerdo con que la página web se adapte tanto a computadoras como a dispositivos móviles; por lo contrario, los clientes restantes (7,91%) respondieron que no están de acuerdo con esta característica. Por lo tanto, se concluye que desarrollar el web service con un diseño responsivo será bien recibido por casi la totalidad de los clientes de la empresa.

47

5.2. Propuesta de Intervención – Web Service (v1.0) 5.2.1. Ciclo de Vida XP. Para todo el proceso de desarrollo, XP propone seis fases: Exploración, Planeación, Diseño, Codificación, Pruebas y Muerte del Proyecto. De igual manera, Scrum propone el uso de diferentes artefactos y eventos propios del marco de trabajo, los mismos que serán muy útiles a lo largo del ciclo de vida del software.

Es necesario destacar que el trabajo realizado para el desarrollo del producto se ha dividido en sprints, lo cual facilita la organización global de cada uno de ellos haciendo uso de las herramientas que brinda Scrum.

5.2.2. Fase I: Exploración.

Para empezar, es necesario definir los roles de las personas involucradas en el proyecto, como se muestran en la siguiente tabla: Tabla 17.

Roles Scrum Rol

Usuario

Product Owner

Ing. Deiby Alexander Morocho Calva

Development Team

Marcos Klender Carrasco Gonzaga

Scrum Master

Mg. Luis Javier Ulloa Meneses

En esta primera fase se ha buscado realizar una reunión de planificación con el Product Owner, el cual realiza la función de intermediario entre los interesados y el equipo de desarrollo para recolectar las funcionalidades que la empresa necesita, con la finalidad de que se puedan plantear las historias de usuario que son de interés para la entrega del producto.

48

Luego de realizar dicha reunión, se recabó la información necesaria para iniciar con el desarrollo del producto. A pedido del Product Owner, se deberá utilizar PHP como lenguaje principal del producto y PostgreSQL como gestor de base de datos. Todo esto debe ser desarrollado en un entorno Linux con el fin de asegurar el funcionamiento del producto en los dispositivos que dispone la empresa. Al mismo tiempo, se ha elaborado el Product Backlog, mismo que comprende las historias de usuario que el cliente ha descrito y priorizado de manera que queden ordenados del más necesario al menos relevante. Cabe recalcar que el lenguaje utilizado es más técnico debido a que el Product Owner es Ingeniero en Sistemas.

En lo que respecta al patrón arquitectónico de software, se empleó el Modelo-VistaControlador (MVC), debido a que el software se desarrollará utilizando el framework Laravel, en su versión 5.5, y este hace uso del patrón anteriormente mencionado.

Tabla 18.

Product Backlog Final (v1.2) ID

PRIORIDAD

DESCRIPCIÓN

ESTIMACIÓN

1

100

Visualización de documentos

21

2

90

Descarga en PDF

21

3

80

Búsqueda de documentos

13

4

70

Perfil de usuario

8

5

60

Descarga en XML

21

6

50

Login

21

7

40

Creación automática de usuarios

13

8

30

Restablecer contraseña vía email

8

Cada una de las historias de usuario se encuentran adjuntadas al final del documento (ver Anexo 6).

49

Una vez que se han establecido las prioridades de las historias de usuario, el Development Team procede a estimar la complejidad de cada una de ellas haciendo uso de los puntos de historia, métrica utilizada en las metodologías de desarrollo ágil. Esto último se logra asignando un valor estimado (haciendo uso de la serie Fibonacci) de acuerdo a la experiencia del desarrollador; dichos valores son asignados a las historias de usuario y se pueden observar en la tabla anterior. A continuación, se presentan los rangos de estimaciones que se pueden aplicar en el desarrollo, basados en la experiencia propia.

Tabla 19.

Rangos Fibonacci Rangos

Descripción

1–5

Estimación Corta

8 – 13

Estimación Media

21 – 34

Estimación Larga

55+

Épica

Posteriormente, se calcula que la velocidad de desarrollo del equipo es de 44 puntos de historia y la duración de cada sprint será de cuatro semanas.

Es necesario destacar que el Product Owner ha facilitado un respaldo de la base de datos de la empresa con la cual se procederá a trabajar, misma que contiene múltiples tablas, relaciones y una gran cantidad de registros; en consecuencia, no será posible realizar ningún diseño de la base de datos debido a la vasta cantidad de información que alberga y a la confidencialidad de dichos datos.

50

5.2.2.1. Gestión de Tareas.

Con el objetivo de llevar un control preciso de las historias de usuario y sus respectivas tareas de ingeniería, se ha empleado un software para la gestión de tareas llamado Trello (ver Figura 12). Este software hace uso del sistema Kanban (sistema de tarjetas) en una interfaz web que ha facilitado la gestión del desarrollo del proyecto de acuerdo a la organización que propone Scrum, donde se controla el trabajo pendiente y se organiza el trabajo terminado.

Figura 12. Tablero en Trello. Adaptado de “Tablero Trello” por Atlassian, 2018.

51

5.2.2.2. Gestión de Versiones.

Para facilitar los procesos de respaldo del sistema y gestionar las versiones que se vayan desarrollando, se optó por utilizar Github, una excelente plataforma enfocada al desarrollo colaborativo de software (ver Figura 13). Github utiliza Git, un sistema de control de versiones que permite alojar repositorios en la web, permitiendo crear una copia local del código y respaldarla para su posterior revisión, uso y gestión; además, permite volver a versiones anteriores del sistema en caso de que se haya presentado algún error. Se adjunta una captura de mi

perfil

en

Github

donde

se

encuentra

el

sistema,

bajo

el

nombre

de

“Electronic_Documentation”.

Figura 13. Perfil en Github. Adaptado de “Repositorio Electronic_Documentation” por Github Inc., 2018.

5.2.3. Sprint 1.

5.2.3.1. Fase II: Planeación.

Para empezar, se han elegido las dos primeras historias de usuario de acuerdo a la prioridad que tienen en el Product Backlog, cuyos puntos de estimación suman un total de 42 puntos, lo cual no supera la velocidad de desarrollo del equipo (44 puntos). Por consiguiente, se ha creado el Sprint Backlog en base a las historias de usuario elegidas (ver Figura 14), dividiéndolas en tareas de ingeniería para llevar un mejor control del trabajo pendiente.

52 OBJETIVO DEL SPRINT

Visualizar los documentos electrónicos y permitir la descarga de los mismos en formato PDF.

SPRINT BACKLOG

SPRINT

HISTORIA

EST

Visualización de documentos

21

Descarga en PDF

21

1

CATEGORÍA

TAREA

EST

RESPONSABLE

ESTADO

Diseño Diseño Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Diseño Diseño Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo

Aplicar la técnica de maquetación Creación de las páginas HTML Configuración de PostgreSQL Conexión con la base de datos Creación de los controladores Validación de las consultas Configuración de las vistas Aplicar la técnica de maquetación Añadir íconos a las páginas Creación del controlador Extracción de datos tipo bytea Conversión de base64 a PDF Eliminar archivos públicos Previsualización del PDF Validación de las consultas

2 3 4 2 3 4 3 2 3 2 3 4 3 2 2

Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco

Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo

Figura 14. Sprint 1 – Sprint Backlog.

5.2.3.2. Fase III: Diseño.

La fase de diseño se enfoca en el uso de las tarjetas CRC (Clase-ResponsabilidadColaborador). Estas tarjetas ayudan a identificar y organizar fácilmente las clases más relevantes para los requerimientos de un sistema; además, se dividen en tres secciones: en la parte superior se encuentra el nombre de la clase, en la parte izquierda se enlistan todas las acciones que la clase pueda realizar (responsabilidades) y en la parte derecha, otras clases que interactúen con la actual (colaboradores), ayudándola a llevar a cabo sus responsabilidades. A continuación, se muestran las tarjetas CRC relevantes para el primer sprint: Tabla 20.

Sprint 1 – Tarjeta CRC 1 Clase: Documentos Responsabilidad

Colaborador

Mostrar los documentos electrónicos Ordenar los documentos cronológicamente Organizar los documentos según su tipo

Conexión

53 Tabla 21.

Sprint 1 – Tarjeta CRC 2 Clase: PDF Responsabilidad

Colaborador

Previsualizar los documentos

Conexión

Descargar los documentos en PDF

Documentos

Esta fase también se ha apoyado de la herramienta web Moqups, misma que permite realizar diagramas, maquetas y prototipos de diseño con la finalidad de mostrarle al Product Owner una visión clara de lo que el sistema llegará a ser. A continuación, se presentan las maquetas realizadas para ambas historias de usuario.

Figura 15. Maqueta de la historia de usuario 1.

54

Figura 16. Maqueta de la historia de usuario 2.

55

5.2.3.3. Fase IV: Codificación.

Aquí es donde se desarrollan las funcionalidades del sistema, escribiendo el código fuente necesario para cumplir con lo detallado en las historias de usuario. Cabe mencionar que diariamente se ha realizado el evento Daily Scrum, reunión que ayudó a verificar el trabajo realizado el día anterior, visualizar las tareas que se desarrollarán a lo largo del día e identificar los obstáculos que se han presentado. En lo que respecta a la codificación realizada, se presentan a continuación los puntos más relevantes del desarrollo del presente sprint:

Figura 17. Conexión a la base de datos (PostgreSQL).

56

Figura 18. Controlador para la visualizaciรณn de las facturas.

Figura 19. Vista de las facturas.

57

Figura 20. Controlador para la conversión y descarga en formato PDF.

5.2.3.4. Fase V: Pruebas.

Es necesario aclarar que, a lo largo de la fase anterior, se realizaron pruebas unitarias automatizadas con el objetivo de verificar que el desarrollo continuo no afecta a otras funcionalidades (ver Figura 21). Según la Pirámide de Cohn, las pruebas unitarias constituyen el 70% de todas las pruebas realizadas, seguidas por las pruebas de integración, que constituyen el 20% y finalmente, las pruebas de aceptación, las cuales abarcan el 10% del total.

Un punto importante respecto a las pruebas unitarias es que no se documentan, pero a continuación se mostrará solamente el ejemplo de una prueba unitaria ejecutada exitosamente:

Figura 21. Prueba unitaria automatizada.

58

Retomando esta última fase del sprint, se utilizó el evento Sprint Review, reunión en compañía del Product Owner donde se realizó la demostración del incremento, explicando las funcionalidades desarrolladas; además, esta reunión se apoyó de las pruebas de aceptación (ver Anexo 7), las cuales sirven como constancia de que el incremento fue desarrollado con éxito.

Una vez terminado el desarrollo del sprint, como resultado del control de las tareas de ingeniería y del trabajo restante de cada historia de usuario se obtendrá el gráfico de avance, también conocido como Burndown Chart (ver Figura 22), el cual permite apreciar la velocidad a la que se están completando los requisitos. A continuación, se adjunta el Burndown Chart del sprint 1, donde la línea azul representa el avance ideal del trabajo y la roja, el avance realizado.

Sprint Burndown Chart 45,0 40,0

Puntos de Historia

35,0 30,0 25,0 20,0 15,0 10,0 5,0 0,0 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

Días Figura 22. Sprint 1 – Burndown Chart.

Finalmente, también se realizó el evento Sprint Retrospective, reunión cuyo objetivo es el de analizar detenidamente el trabajo realizado a lo largo del sprint. El punto débil observado en el presente sprint fue la inexperiencia al momento de desarrollar ciertas tareas; mientras que, los puntos fuertes fueron la experiencia en la programación de PHP y el manejo del sistema operativo Ubuntu (específicamente, el manejo del bash).

59

5.2.4. Sprint 2.

5.2.4.1. Fase II: Planeación.

Siguiendo con el siguiente sprint, se procedió a elegir las tres siguientes historias de usuario que constan en el Product Backlog, cuya suma total de puntos de estimación no sobrepasa la velocidad de desarrollo del equipo (42 puntos de 44). A continuación, se muestra el Sprint Backlog que corresponde con este sprint (ver Figura 23): OBJETIVO DEL SPRINT

Mejorar la interacción del usuario con sus documentos y añadir la descarga ellos en formato XML.

SPRINT BACKLOG

SPRINT

HISTORIA

EST

Búsqueda de documentos

13

Perfil de usuario

8

Descarga en XML

21

2

CATEGORÍA

TAREA

EST

RESPONSABLE

ESTADO

Diseño Diseño Desarrollo Desarrollo Desarrollo Diseño Diseño Desarrollo Desarrollo Diseño Diseño Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo

Aplicar la técnica de maquetación Modificación de las páginas HTML Creación de los controladores Validación de las consultas Modificación de las vistas Aplicar la técnica de maquetación Creación de las páginas HTML Visualización y edición de datos Cambio de contraseña Aplicar la técnica de maquetación Añadir íconos a las páginas Creación del controlador Validación de las consultas Extracción de la base de datos Conversión de string a XML Creación de archivos XML Función de descarga directa

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

Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco

Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo

Figura 23. Sprint 2 – Sprint Backlog.

5.2.4.2. Fase III: Diseño.

Tomando en consideración las clases creadas en el anterior sprint y de acuerdo a las nuevas historias de usuario elegidas, las tarjetas CRC correspondientes al presente sprint son:

60 Tabla 22.

Sprint 2 – Tarjeta CRC 3 Clase: Búsquedas Responsabilidad

Colaborador

Buscar los documentos electrónicos

Conexión

Ordenar los documentos cronológicamente

Documentos

Tabla 23.

Sprint 2 – Tarjeta CRC 4 Clase: Perfil Responsabilidad

Colaborador

Mostrar la información del usuario Actualizar la información del usuario

Conexión

Cambiar la contraseña

Tabla 24.

Sprint 2 – Tarjeta CRC 5 Clase: XML Responsabilidad

Colaborador Conexión

Descargar los documentos en XML Documentos

De igual manera, las maquetas diseñadas para cada una de las historias son:

61

Figura 24. Maqueta de la historia de usuario 3.

Figura 25. Maqueta de la historia de usuario 4.

62

Figura 26. Maqueta de la historia de usuario 5.

5.2.4.3. Fase IV: Codificación.

El código fuente escrito para desarrollar las funcionalidades del sprint son:

Figura 27. Controlador para la búsqueda de documentos por número.

63

Figura 28. Vista de la opción de búsqueda.

Figura 29. Vista del perfil de usuario.

Figura 30. Controlador para editar la información del usuario.

64

Figura 31. Controlador para la conversión y descarga en formato XML.

5.2.4.4. Fase V: Pruebas.

En la Sprint Review del presente sprint, se procedió a realizar la respectiva demostración del incremento realizado, donde el Product Owner confirmó el desarrollo exitoso del mismo, tal y como se demuestra en las pruebas de aceptación (ver Anexo 8).

El Burndown Chart correspondiente a los avances del presente sprint es (ver Figura 32):

Sprint Burndown Chart 45,0 40,0

Puntos de Historia

35,0 30,0 25,0 20,0 15,0 10,0 5,0 0,0 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

Días Figura 32. Sprint 2 – Burndown Chart.

Finalmente, al realizar la Sprint Retrospective se analizó, como punto débil el casi nulo manejo con archivos en formato XML; mientras que, como punto fuerte se destacan mejoras a la hora de crear controladores, gracias a la experiencia adquirida en el sprint anterior.

65

5.2.5. Sprint 3.

5.2.5.1. Fase II: Planeación.

Continuando con este sprint, se procedió a elegir las tres siguientes historias de usuario que constan en el Product Backlog, cuya suma total de puntos de estimación tampoco sobrepasa la velocidad de desarrollo del equipo (42 puntos de 44). Debido a que no quedan más historias de usuario por elegir, se concluye que este será el último sprint por desarrollar (ver Figura 33).

A continuación, se muestra el Sprint Backlog correspondiente al presente sprint: OBJETIVO DEL SPRINT

Brindar el acceso de los usuarios al sistema, permitiendo restablecer sus contraseñas.

SPRINT BACKLOG

SPRINT

HISTORIA

EST

Login

21

Creación automática de usuarios

13

Restablecer contraseña vía email

8

3

CATEGORÍA

TAREA

Diseño Aplicar la técnica de maquetación Diseño Creación de la interfaz login Desarrollo Creación de controladores Desarrollo Inicio de sesión con RUC o CI Desarrollo Validación del formulario Desarrollo Encriptación de contraseñas Desarrollo Redirección de la página principal Desarrollo Número de intentos limitado Desarrollo Creación del modelo Desarrollo Creación del seeder Desarrollo Modificación de las migraciones Desarrollo Creación de usuarios Desarrollo Validación para evitar redundancia Diseño Aplicar la técnica de maquetación Diseño Creación de página HTML Desarrollo Configuración del .env Desarrollo Modificación de controladores

EST

RESPONSABLE

ESTADO

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

Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco Klender Carrasco

Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo Completo

Figura 33. Sprint 3 – Sprint Backlog.

5.2.5.2. Fase III: Diseño.

Las tarjetas CRC que corresponden a este sprint son las siguientes:

66 Tabla 25.

Sprint 3 – Tarjeta CRC 6 Clase: Login Responsabilidad

Colaborador

Solicitar credenciales Conexión Ingresar al sistema

Tabla 26.

Sprint 3 – Tarjeta CRC 7 Clase: Usuarios Responsabilidad

Colaborador

Extraer información necesaria Conexión Crear usuarios automáticamente Login Encriptar contraseñas

Tabla 27.

Sprint 3 – Tarjeta CRC 8 Clase: Contraseña Responsabilidad

Colaborador Conexión

Restablecer contraseña Login Ingresar al sistema Usuarios

Debido a que la historia de usuario número 7 es completamente técnica y no requiere de interfaz gráfica, no aplicará la técnica de maquetación. Por ende, se muestran a continuación las maquetas diseñadas para las historias 6 y 8 respectivamente:

67

Figura 34. Maqueta de la historia de usuario 6.

Figura 35. Maqueta de la historia de usuario 8.

68

5.2.5.3. Fase IV: Codificación.

Aquí se procede a mostrar el código fuente relevante para el presente sprint:

Figura 36. Controladores para el inicio de sesión.

Figura 37. Seeder para la creación automática de usuarios.

69

Figura 38. Vista del inicio de sesiĂłn.

Figura 39. Vista del restablecimiento de contraseĂąa.

70

5.2.5.4. Fase V: Pruebas.

Finalmente, se realizó el Sprint Review junto con el Product Owner, donde se concluyó que las funcionalidades del sprint fueron desarrolladas satisfactoriamente, lo cual se puede observar en las pruebas de aceptación respectivas (ver Anexo 9).

El Burndown Chart correspondiente a los avances del presente sprint es (ver Figura 40):

Sprint Burndown Chart 45,0 40,0

Puntos de Historia

35,0 30,0 25,0 20,0 15,0 10,0 5,0 0,0 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

Días Figura 40. Sprint 3 – Burndown Chart.

Y más adelante, se procedió a ejecutar la Sprint Retrospective, donde se pudo observar que el punto débil presentado en este sprint fue la inexperiencia a la hora de programar el seeder que crea los usuarios automáticamente; así mismo, el punto fuerte analizado fue la facilidad de búsqueda de diferentes soluciones en la documentación oficial de Laravel, lo cual facilitó algunas tareas (como la modificación de los parámetros para el inicio de sesión).

5.2.6. Fase VI: Muerte del Proyecto.

Una vez que el Product Backlog no tiene más historias de usuario y todas las funcionalidades requeridas fueron desarrolladas satisfactoriamente, se da por terminado el ciclo de vida del software. En esta última fase se realiza la documentación final que corrobora la entrega y aceptación del sistema por parte del Product Owner, lo cual está adjuntado como el Acta de Entrega-Recepción del Proyecto (ver Anexo 2) y la Carta de Impacto (ver Anexo 3).

71

5.3. EvaluaciĂłn de Impacto del Proyecto El anĂĄlisis de impacto es esencial para determinar si el presente proyecto de disertaciĂłn de grado ha sido acogido de manera positiva o negativa por parte de la poblaciĂłn a la que va dirigida su desarrollo. A continuaciĂłn, se muestra la fĂłrmula utilizada y la tabla que especifica los niveles de impacto junto con sus respectivos indicadores numĂŠricos: đ?‘ đ?‘–đ?‘Łđ?‘’đ?‘™ đ?‘‘đ?‘’ đ??źđ?‘šđ?‘?đ?‘Žđ?‘?đ?‘Ąđ?‘œ = đ?‘†đ?‘˘đ?‘šđ?‘Žđ?‘Ąđ?‘œđ?‘&#x;đ?‘–đ?‘Ž đ?‘‡đ?‘œđ?‘Ąđ?‘Žđ?‘™ đ?‘‘đ?‘–đ?‘Łđ?‘–đ?‘‘đ?‘–đ?‘‘đ?‘Ž đ?‘?đ?‘Žđ?‘&#x;đ?‘Ž đ?‘™đ?‘Ž đ??śđ?‘Žđ?‘›đ?‘Ąđ?‘–đ?‘‘đ?‘Žđ?‘‘ đ?‘‘đ?‘’ đ??źđ?‘›đ?‘‘đ?‘–đ?‘?đ?‘Žđ?‘‘đ?‘œđ?‘&#x;đ?‘’đ?‘ đ?‘ đ??ź =

∑ đ?‘ ∘

Tabla 28.

Niveles de Impacto Nivel

DescripciĂłn

-3

Impacto de alto nivel negativo

-2

Impacto de medio nivel negativo

-1

Impacto de bajo nivel negativo

0

No hay impacto

1

Impacto de bajo nivel positivo

2

Impacto de medio nivel positivo

3

Impacto de alto nivel positivo

Nota: Adaptado de “MetodologĂ­a para el Trabajo de Grado: Tesis y Proyectosâ€? por M. Ă . Posso, 2013.

Es necesario analizar el impacto tecnolĂłgico, social y econĂłmico del presente proyecto para determinar el impacto general del mismo.

72

5.3.1. Impacto TecnolĂłgico.

Tabla 29.

Impacto TecnolĂłgico Nivel de Impacto -3

-2

-1

0

1

2

3

Indicadores SistematizaciĂłn de procesos

✓

Control de documentos electrĂłnicos

✓

Disponibilidad del servicio

✓

DiseĂąo y desarrollo de interfaz

✓

Seguridad y confiabilidad del sistema

✓

Total

15

Sumatoria ∑ Total

∑ = 15 đ?‘ đ??ź = 15â „5 = 3

Resultado Nivel de Impacto

Impacto de alto nivel positivo

Nota: Adaptado de “MetodologĂ­a para el Trabajo de Grado: Tesis y Proyectosâ€? por M. Ă . Posso, 2013.

AnĂĄlisis El control de los documentos electrĂłnicos y todos los procesos que abarca se realizan de forma manual, lo cual afecta a los empleados de la empresa. La automatizaciĂłn de dichos procesos resulta sumamente Ăştil debido a la optimizaciĂłn del tiempo y trabajo de los empleados, permitiendo un servicio de calidad para los clientes.

El diseĂąo de una interfaz simple e intuitiva es esencial para que los clientes puedan usar el sistema con total libertad, poniendo a disposiciĂłn de los usuarios todos sus documentos.

El sistema posee una robusta seguridad y confiabilidad en su funcionamiento, lo que asegura la calidad del servicio bajo cualquier condiciĂłn que se presente.

73

5.3.2. Impacto Social.

Tabla 30.

Impacto Social Nivel de Impacto -3

-2

-1

0

1

2

3

Indicadores Accesibilidad a la documentaciĂłn

✓

Confidencialidad de la informaciĂłn

✓

Mejoramiento de servicios

✓

Total

9

Sumatoria ∑ Total Resultado Nivel de Impacto

∑=9 đ?‘ đ??ź = 9â „3 = 3 Impacto de alto nivel positivo

Nota: Adaptado de “MetodologĂ­a para el Trabajo de Grado: Tesis y Proyectosâ€? por M. Ă . Posso, 2013.

AnĂĄlisis La accesibilidad a la documentaciĂłn facilita enormemente el proceso de entrega de los mismos, permitiendo al usuario ingresar al sistema sin restricciĂłn alguna.

La confidencialidad de la informaciĂłn es vital en la empresa, debido a que se manejan datos personales de los clientes (como cĂŠdula de identidad, correo electrĂłnico, etcĂŠtera). Para cumplir con ello, toda esta informaciĂłn se encuentra encriptada y restringida para el pĂşblico.

El sistema proporciona una mejora significativa en los servicios que brinda la empresa, puesto que no hace falta que los empleados realicen las tareas de entrega de la documentaciĂłn.

74

5.3.3. Impacto EconĂłmico.

Tabla 31.

Impacto EconĂłmico Nivel de Impacto -3

-2

-1

0

1

2

3

Indicadores UtilizaciĂłn de software open source

✓

DisminuciĂłn de recursos a utilizar

✓

Aumento de la calidad de servicio

✓

Total

9

Sumatoria ∑ Total Resultado Nivel de Impacto

∑=9 đ?‘ đ??ź = 9â „3 = 3 Impacto de alto nivel positivo

Nota: Adaptado de “MetodologĂ­a para el Trabajo de Grado: Tesis y Proyectosâ€? por M. Ă . Posso, 2013.

AnĂĄlisis El sistema utiliza software open source, es decir, software que no ha requerido el pago de ninguna licencia propietaria; ademĂĄs, permite el ahorro de los recursos que la empresa utilizaba anteriormente en el manejo de la documentaciĂłn electrĂłnica, misma que se realizaba de forma manual por parte de los empleados haciendo uso de material fĂ­sico (impresiones).

75

5.3.4. Impacto General.

Tabla 32.

Impacto General Nivel de Impacto -3

-2

-1

0

1

2

3

Indicadores Impacto TecnolĂłgico

✓

Impacto Social

✓

Impacto EconĂłmico

✓

Total

9

Sumatoria ∑ Total Resultado Nivel de Impacto

∑=9 đ?‘ đ??ź = 9â „3 = 3 Impacto de alto nivel positivo

Nota: Adaptado de “MetodologĂ­a para el Trabajo de Grado: Tesis y Proyectosâ€? por M. Ă . Posso, 2013.

Gracias a los anĂĄlisis de impacto tecnolĂłgico, social y econĂłmico, se determina que el sistema web para el control de los documentos electrĂłnicos de Emproservis Cia. Ltda.

Proporciona un impacto de alto nivel positivo, dado que se automatizan los procesos de manejo y entrega de los documentos hacia los clientes y proveedores de la empresa.

Para corroborar el anĂĄlisis anterior se adjunta la carta de impacto (ver Anexo 3).

76

6. CONCLUSIONES 

Una vez que se implemente el web service se solventará uno de los mayores inconvenientes de la empresa, como es el control de los documentos electrónicos. Tanto los clientes como proveedores que necesiten revisar o descargar su documentación podrán acceder al sistema desde cualquier dispositivo las 24 horas del día; ya no habrá necesidad de ocupar el tiempo del personal de la empresa para este tipo de tareas.



Gracias a las historias de usuarios utilizadas como instrumento de recolección de datos (funcionalidades) se logró recabar toda la información necesaria para el desarrollo del sistema; y junto con la frecuente comunicación con el Product Owner, se generó la retroalimentación necesaria para solventar cualquier error que se presentó a lo largo de los sprints, dando como resultado un producto confiable, robusto y funcional.



La combinación de la metodología XP y el marco de trabajo Scrum supuso una gran ayuda en el proceso de desarrollo del software. Los procesos y el ciclo de vida ideal que propone XP junto con los eventos y artefactos Scrum fueron de vital importancia para que el desarrollo sea versátil y limpio, de manera que permita realizar cualquier cambio en el producto que surja a lo largo de los sprints, sin necesidad de comprometer las funcionalidades ya desarrolladas.



El uso de software open source contribuyó en gran medida al desarrollo del sistema, evitando la necesidad de pagar licencias propietarias por servicios que se pueden conseguir de manera gratuita. Las licencias del software utilizado permiten la libertad de uso, modificación y distribución sin costo alguno.

77

7. RECOMENDACIONES 

Priorizar la disponibilidad del sistema para que funcione adecuadamente las 24 horas del día, de manera que ningún usuario se vea afectado independientemente de la hora en la que se conecte. Además, se recomienda estudiar la posibilidad de automatizar más procesos en la empresa, para optimizar el trabajo de los empleados y brindar un mejor servicio a los clientes.



Recabar toda la información necesaria con respecto al hardware y software que se utilizará en el desarrollo del producto. Una vez analizado el entorno de trabajo que dispone el desarrollador y el equipo o equipos en los cuales el cliente hará uso del producto, se puede proceder a dar inicio al desarrollo del mismo. De igual manera, es necesario mantener una buena comunicación con el cliente, de manera que se solventen las dudas a medida que aparezcan.



Es necesario elegir bien la metodología de desarrollo de software que mejor se adapte a los requerimientos del cliente y que pueda cubrir las necesidades del producto. En caso de combinar la metodología XP y el marco de trabajo Scrum, se recomienda analizar las cualidades más relevantes de ambas partes para emplear las más adecuadas tanto para el proyecto como para el producto.



Se debe tomar muy en cuenta el tipo de licencias del software que se utiliza, especialmente el open source, debido a que pueden presentar ciertas limitaciones por parte del autor. Cabe resaltar que el software open source no es lo mismo que el software libre y no tienen la necesidad de ser 100% gratuitos.

78

8. LISTA DE REFERENCIAS Aguilera, M. (2013). Desarrollo de un sistema web de control de citas, para un hospital del día. (Trabajo de grado). Pontificia Universidad Católica del Ecuador, Quito, Ecuador. Álvarez, A., de las Heras del Dedo, R., & Lasa, C. (2012). Métodos Ágiles y Scrum. Madrid: Anaya Multimedia.

Arias, F. (2012). El Proyecto de Investigación: Introducción a la Metodología Científica.

Caracas: Episteme.

Atlassian. (2018). Tablero Trello. Obtenido de https://trello.com/b/lZ7ApRPF/web-servicepara-el-control-de-documentos-electrónicos-de-emproservis-cia-ltda Bennasar, A. (2010). La Validez del Documento Electrónico y su Eficacia en Sede Procesal.

España: Lex Nova.

Bernal, C. (2014). Metodología de la Investigación: Administración, Economía, Humanidades y Ciencias Sociales. México: Pearson Educación.

Blanco, F. & Muñoz, R. (2013). Desarrollo del sistema web para la administración de documentos digitalizados para Imexsa. (Trabajo de grado). Pontificia Universidad Católica del Ecuador, Quito, Ecuador.

Bravo, M. (2011). Contabilidad General. España: Escobar Impresores.

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

Calderón, C. (2016). Portal web para la gestión y administración de la Casa Hogar San Carlos. (Trabajo de grado). Universidad Regional Autónoma de los Andes, Riobamba, Ecuador.

Calvopiña, A. & García, S. (2016). Diseño e implementación del voto electrónico mediante el uso de una aplicación web, para las elecciones de la federación de estudiantes de la Pontificia Universidad Católica del Ecuador. (Trabajo de grado). Pontificia Universidad Católica del Ecuador, Quito, Ecuador.

Díaz, H. (2011). Contabilidad General: Enfoque Práctico con Aplicaciones Informáticas.

Bogotá: Pearson Educación.

Drury, M., Conboy, K. & Power, K. (2012). Obstacles to decision making in agile software development teams. Journal of Systems and Software, 85(6), 1239-1254. doi: 10.1016/j.jss.2012.01.058 Fincowsky, E. (2014). Organización de Empresas. México: McGraw-Hill.

Github, Inc. (2018). Repositorio Electronic_Documentation. Obtenido de https://github.com/MarcosKlender/Electronic_Documentation

79

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

México: McGraw-Hill.

Kappel, G., Pröll, B., Reich, S., & Retschitzegger, W. (2011). Web Engineering: The Discipline of Systematic Development of Web Applications. United States: John Wiley & Sons.

Kniberg, H. (2015). Scrum y XP desde las Trincheras. Estados Unidos: C4Media Inc. López, I., Castellano, M., & Ospino, J. (2014). Bases de Datos. México: Alfaomega Grupo Editor.

López, J. (2014). Domine JavaScript. México: Alfaomega Grupo Editor.

López, J. (2014). Domine PHP y MySQL. México: Alfaomega Grupo Editor.

López, M., Vara, J., Verde, J., Sánchez, D., Jiménez, J., & de Castro, V. (2012). Desarrollo Web en Entorno Servidor. Madrid: RA-MA. MariaDB Foundation. (2017). About MariaDB. Obtenido de https://mariadb.org/about/ Millan, C. & Palma, J. (Mayo, 2011). El Portal Web Género México. Trabajo presentado en XL Jornadas Mexicanas De Biblioteconomía de la Asociación Mexicana de Bibliotecarios A.C., Acapulco, México.

Morueco, R. (2013). Manual Práctico de Administración. Bogotá: Ediciones de la U. Mushhad, S., Gilani, M., Ahmed, J. & Abbas, M. A. (Agosto, 2013). Electronic document management: a paperless university model. Trabajo presentado en 2nd IEEE International Conference on Computer Science and Information Technology (ICCSIT) de la IEEE, Beijing, China. doi: 10.1109/ICCSIT.2009.5234679 Navarro, A., Fernández, J., & Morales, J. (2013). Revisión de metodologías ágiles para el desarrollo de software. PROSPECTIVA, 11(2), 30-39.

Negrete, J. (2016). Desarrollo de un sistema web de facturación electrónica con comunicación al servicio de rentas internas, aplicado a la empresa Expertweb. Cía.

Ltda. (Trabajo de grado). Pontificia Universidad Católica del Ecuador, Quito, Ecuador.

Oracle Corporation. (2017). Database Concepts. Obtenido de https://docs.oracle.com/database/122/CNCPT/toc.htm Peña, Ó. (2010). CSS. Madrid: Anaya Multimedia.

Pérez, M., Mendoza, L. E., & Grimán, A. (2015). Modelo para estimación de la calidad de un Web Service. In XXXI Conferencia Latinoamericana de Informática, Cali, Colombia (pp. 989-1000).

80

Posso, M. Á. (2013). Metodología para el Trabajo de Grado: Tesis y Proyectos. Ibarra: NINA Comunicaciones.

PostgreSQL Global Development Group. (2017). About PostgreSQL. Obtenido de https://www.postgresql.org/about/ Pressman, R. (2010). Ingeniería de Software: Un Enfoque Práctico. México: McGraw-Hill.

Rodriguez, J. M., Crasso, M., Zunino, A. & Campo, M. (2010). Improving web service descriptions for effective service discovery. Science of Computer Programming, 75(11), 1001-1021. doi: 10.1016/j.scico.2010.01.002 Roldán, D., Valderas, P., & Pastor, Ó. (2014). Aplicaciones Web: Un Enfoque Práctico.

México: Alfaomega Grupo Editor.

Rubio, A. (2011). Proyectos Archivísticos: Modelos de Elaboración. Bogotá: Ediciones de la U. Savage, T., & Vogel, K. (2014). An Introduction to Digital Multimedia. United States: Jones & Bartlett Learning.

Secretaría Nacional de Planificación y Desarrollo. (2013). Plan Nacional del Buen Vivir: Objetivo 11. Recuperado de http://www.buenvivir.gob.ec/objetivo-11.-asegurar-lasoberania-y-eficiencia-de-los-sectores-estrategicos-para-la-transformacion-industrialy-tecnologica Scrum Alliance. (Noviembre de 2017). The Scrum Guide, The Definitive Guide to Scrum: The Rules of the Game. Obtenido de http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-GuideUS.pdf#zoom=100 Sommerville, I. (2011). Ingeniería de Software. México: Pearson Educación.

Vaswani, V. (2012). Fundamentos de PHP. México: McGraw-Hill.

Vlaanderen, K., Jansen, S., Brinkkemper, S. & Jaspers, E. (2011). The agile requirements refinery: Applying SCRUM principles to software product management. Information and Software Technology, 53(1), 58-70. doi: 10.1016/j.infsof.2010.08.004 W3Schools. (2017). HTML Introduction. Obtenido de https://www.w3schools.com/html/html_intro.asp

81

9. GLOSARIO BASH Su nombre es un acrónimo de Bourne-Again Shell. Es un programa informático que permite ejecutar las instrucciones que introduzcamos en la consola. Fue escrito para el proyecto GNU y es el intérprete de comandos por defecto en la mayoría de las distribuciones de Linux.

BOOTSTRAP Es un framework de diseño open source, inicialmente desarrollado por Twitter, que facilita el diseño de sitios y aplicaciones web; además, permite crear webs con diseño adaptable.

FRAMEWORK También conocido como entorno o marco de trabajo, es una estructura software compuesta de componentes personalizables e intercambiables para el desarrollo de una aplicación.

HTTP Su nombre es un acrónimo de HyperText Transfer Protocol. Es un protocolo de red que se utiliza para publicar páginas web. HTTP es la base sobre la cual se fundamenta Internet.

INCREMENTO Se lo puede definir como una entrega parcial del producto software que se está desarrollando.

KANBAN Kanban es una palabra de origen japonés que significa tarjeta. Es una técnica creada por Toyota y se utiliza para controlar el avance de un trabajo gestionando las tareas a realizar.

LARAVEL Es un framework de desarrollo open source que facilita el desarrollo de aplicaciones y servicios web con PHP. Es simple, modular, extensible y está enfocado en la arquitectura MVC. LINUX Es un sistema operativo libre basado en Unix. Entre sus características más importantes está el ser un sistema multitarea, multiusuario, multiplataforma y multiprocesador. Todo su código fuente puede ser utilizado, modificado y redistribuido libremente por cualquier persona.

82

MVC Su nombre es un acrónimo Model-View-Controller. Es un patrón de arquitectura de software cuyo objetivo es separar los datos de una aplicación, la interfaz de usuario y la lógica de control en tres componentes distintos que son el modelo, la vista y el controlador.

OPEN SOURCE Es un término que se refiere al software distribuido bajo una licencia que permite al usuario el acceso al código fuente. Dependiendo del tipo de licencia bajo la cual se adquiera el software, posibilitará el estudio, modificación y redistribución del mismo con total libertad.

PHP Es un lenguaje de código abierto muy popular especialmente adecuado para el desarrollo web, se ejecuta en el lado del servidor y puede ser incrustado en páginas HTML. POSTGRESQL Es un sistema de gestión de bases de datos objeto-relacional open source, publicado bajo su propia licencia PostgreSQL, similar a las licencias BSD o MIT. ROL Es el papel o función que un individuo o cosa realiza en un determinado contexto.

SCRUM Es un marco de trabajo que comprende varios procesos y técnicas orientadas a la gestión del desarrollo de productos complejos. Busca generar resultados de calidad en iteraciones cortas.

SOFTWARE Es la parte lógica del computador, representada por todos los componentes lógicos necesarios que hacen posible la realización de tareas, en términos resumidos es todos los programas, aplicaciones de un computador.

SPRINT Es el tiempo en el cual se debe desarrollar un incremento del producto y se puede definir como el contenedor del resto de eventos. Es recomendable que el sprint dure cuatro semanas.

83

TRELLO Es una herramienta para la organización de tareas basada en la metodología Kanban, la cual propone un sistema de uso colaborativo, ideal para la coordinación de equipos de trabajo.

UBUNTU Ubuntu es una de las distribuciones Linux más populares del mercado, siendo también una excelente alternativa a los sistemas operativos Windows y OS X. Está basado en Debian e incluye Unity, su propio entorno de escritorio que brinda una experiencia de usuario sencilla.

XP (EXTREME PROGRAMMING) Es una metodología ágil utilizada en el desarrollo de software cuyos requisitos son poco complejos o cambiantes. Se aplica mayormente en equipos de desarrollo pequeños o medianos.

84

10. ANEXOS Anexo 1: Carta de Asignaciรณn del Proyecto

85

Anexo 2: Acta de Entrega-Recepciรณn del Proyecto

86

Anexo 3: Carta de Impacto

87

Anexo 4: Modelo de Entrevista

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO ESCUELA DE SISTEMAS PERIODO 2017 – 2018 Entrevista dirigida a quienes conforman el Departamento de Sistemas.

El objetivo de la presente entrevista es recopilar información acerca de los procesos correspondientes a la gestión de documentos que maneja la institución, con la finalidad de especificar los requerimientos iniciales para el desarrollo del proyecto.

ENTREVISTADOR

LUGAR DE LA ENTREVISTA

FECHA Y HORA

NOMBRE DEL ENTREVISTADO

CARGO

RESUMEN DE LA ENTREVISTA

88

1) ¿CUÁNTAS PERSONAS ESTÁN A CARGO DEL DEPARTAMENTO DE SISTEMAS?

2) ¿QUÉ TIPO DE CARGO USTEDES DESEMPEÑAN EN LA EMPRESA?

3) ¿CÓMO ES EL PROCESO DE GESTIÓN DE LOS DOCUMENTOS EN LA EMPRESA?

4) ¿CUÁL ES EL PROCESO DE ENTREGA DE DOCUMENTOS HACIA LOS CLIENTES?

5) ¿LA EMPRESA CUENTA CON UN SITIO WEB? ¿QUÉ INFORMACIÓN PRESENTA?

6) ¿TIENEN ALGÚN INCONVENIENTE CON LA GESTIÓN DE DOCUMENTOS?

89

7) ¿CUÁL SERÍA EL ENFOQUE QUE TENDRÍA EL WEB SERVICE?

8) ¿DE QUÉ MANERAS DEBERÍAN COMPARTIRSE LOS DOCUMENTOS?

9) ¿TIENE ALGUNA PREFERENCIA RESPECTO A LOS LENGUAJES Y SISTEMA OPERATIVO CON LOS QUE DESEE QUE SE DESARROLLE EL WEB SERVICE?

10)EN CASO DE QUE SE IMPLEMENTE EL WEB SERVICE, ¿CUÁNTOS USUARIOS ESTIMA QUE HARÁN USO DE LA MISMA COMO ADMINISTRADORES?

11)EN CASO DE QUE SE IMPLEMENTE EL WEB SERVICE, ¿CUÁNTOS USUARIOS ESTIMA QUE HARÁN USO DE LA MISMA COMO CLIENTES?

90

Anexo 5: Modelo de Encuesta

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO ESCUELA DE SISTEMAS PERIODO 2017 – 2018

Encuesta dirigida a los clientes de Emproservis Cía. Ltda.

El objetivo de la presente encuesta es recopilar información acerca de los inconvenientes que se presentan en la empresa con el actual manejo de la documentación y el impacto que supone el desarrollo de un web service para el control de documentos electrónicos.

Por favor, lea detenidamente cada pregunta y conteste con una (x) las respuestas.

12)¿DISPONE USTED DE UN DISPOSITIVO MÓVIL (SMARTPHONE)? o Sí. o No.

13)¿SABE USTED UTILIZAR EL NAVEGADOR EN SU DISPOSITIVO MÓVIL? o Sí. o No.

14)¿DISPONE USTED DE UNA COMPUTADORA PERSONAL? o Sí. o No.

15)EN CASO DE DISPONER DE UNA COMPUTADORA PERSONAL, ¿SABE USTED UTILIZAR EL NAVEGADOR? o Sí. o No.

91

16)¿TIENE ALGÚN INCONVENIENTE CON EL PERSONAL DE LA EMPRESA? o Sí. o No.

17)¿EXISTEN INCONVENIENTES CON LA ENTREGA DE SUS DOCUMENTOS ELECTRÓNICOS POR PARTE DE LA EMPRESA? o Sí. o No.

18)¿EXISTE RETRASO EN LA ENTREGA DE SUS DOCUMENTOS ELECTRÓNICOS? o Sí. o No.

19)¿EXISTE ALGUNA PLATAFORMA QUE LE PERMITA ACCEDER A SUS DOCUMENTOS ELECTRÓNICOS? o Sí. o No.

20)¿PUEDE USTED DESCARGAR SUS DOCUMENTOS ELECTRÓNICOS? o Sí. o No.

21)¿ESTÁ DE ACUERDO CON EL DESARROLLO DE UNA PÁGINA WEB LE AYUDE A CONSULTAR, ORGANIZAR Y DESCARGAR SUS DOCUMENTOS ELECTRÓNICOS? o Sí. o No.

22)¿ESTÁ DE ACUERDO CON QUE LA PÁGINA WEB PUEDA SER UTILIZADA TANTO EN COMPUTADORA COMO EN UN DISPOSITIVO MÓVIL? o Sí. o No.

92

Anexo 6: Historias de Usuario HISTORIA DE USUARIO Número: 1

Usuario: Cliente/Proveedor

Nombre Historia: Visualización de documentos Prioridad en Negocio: 100

Riesgo en Desarrollo: Medio

Puntos Estimados: 21

Sprint: 1

Programador Responsable: Marcos Klender Carrasco Gonzaga Descripción: COMO cliente QUIERO ver todos mis documentos electrónicos organizados PARA acceder a ellos fácilmente.

Escenarios de Prueba: DADA la visualización de todos los documentos electrónicos CUANDO pulse en alguna pestaña y se encuentre uno o más ENTONCES se muestran todos los documentos requeridos en orden cronológico.

DADA la visualización de todos los documentos electrónicos CUANDO pulse en alguna pestaña y no se encuentre ninguno ENTONCES se muestra un mensaje de aviso.

93

HISTORIA DE USUARIO Número: 2

Usuario: Cliente/Proveedor

Nombre Historia: Descarga en PDF Prioridad en Negocio: 90

Riesgo en Desarrollo: Alto

Puntos Estimados: 21

Sprint: 1

Programador Responsable: Marcos Klender Carrasco Gonzaga Descripción: COMO cliente QUIERO poder descargar mis documentos electrónicos en formato PDF PARA guardarlos en mi computadora.

Escenarios de Prueba: DADA la selección del documento electrónico CUANDO pulse en el botón PDF ENTONCES se previsualiza el documento seleccionado donde puede descargarlo o imprimirlo.

94

HISTORIA DE USUARIO Número: 3

Usuario: Cliente/Proveedor/Administrador

Nombre Historia: Búsqueda de documentos Prioridad en Negocio: 80

Riesgo en Desarrollo: Medio

Puntos Estimados: 13

Sprint: 2

Programador Responsable: Marcos Klender Carrasco Gonzaga Descripción: COMO cliente QUIERO ingresar datos de mis documentos PARA encontrar solamente los que necesite.

Escenarios de Prueba: DADO el ingreso de las fechas requeridas CUANDO pulse el botón “Búsqueda” ENTONCES se muestran los documentos emitidos entre esas fechas.

DADO el ingreso del número de documento CUANDO pulse el botón “Búsqueda” ENTONCES se muestra el documento requerido.

DADO el ingreso del número de documento CUANDO pulse el botón “Búsqueda” ENTONCES se muestra el documento requerido VALOR DADO el ingreso del número de RUC/CI por parte del administrador CUANDO pulse el botón “Búsqueda” ENTONCES se muestran todos los documentos que le corresponden al RUC/CI.

95

HISTORIA DE USUARIO Número: 4

Usuario: Cliente/Proveedor

Nombre Historia: Perfil de usuario Prioridad en Negocio: 70

Riesgo en Desarrollo: Bajo

Puntos Estimados: 8

Sprint: 2

Programador Responsable: Marcos Klender Carrasco Gonzaga Descripción: COMO cliente QUIERO editar mi información personal y contraseña PARA llevar un control de mi perfil.

Escenarios de Prueba: DADA la edición de la información personal CUANDO pulse el botón “Actualizar Información” ENTONCES se muestra un aviso de confirmación.

DADA la edición de la información personal CUANDO pulse el botón “Cambiar Contraseña” ENTONCES se muestra un aviso de confirmación.

96

HISTORIA DE USUARIO Número: 5

Usuario: Cliente/Proveedor

Nombre Historia: Descarga en XML Prioridad en Negocio: 60

Riesgo en Desarrollo: Medio

Puntos Estimados: 21

Sprint: 2

Programador Responsable: Marcos Klender Carrasco Gonzaga Descripción: COMO cliente QUIERO poder descargar mis documentos electrónicos en formato XML PARA guardarlos en mi computadora.

Escenarios de Prueba: DADA la selección del documento electrónico CUANDO pulse en el botón XML ENTONCES se descarga el documento seleccionado directamente.

97

HISTORIA DE USUARIO Número: 6

Usuario: Cliente/Proveedor

Nombre Historia: Login Prioridad en Negocio: 50

Riesgo en Desarrollo: Medio

Puntos Estimados: 21

Sprint: 3

Programador Responsable: Marcos Klender Carrasco Gonzaga Descripción: COMO cliente QUIERO ingresar mi RUC/CI y contraseña PARA acceder al sistema con los respectivos privilegios.

Escenarios de Prueba: DADO el ingreso del RUC/CI y contraseña CUANDO pulse el botón “Iniciar Sesión” ENTONCES se muestra la página principal.

DADO el ingreso del RUC/CI y contraseña incompletos y/o incorrectos CUANDO pulse el botón “Iniciar Sesión” ENTONCES se muestra un mensaje de error.

DADO el ingreso del RUC/CI y contraseña incorrectos tres veces seguidas CUANDO pulse el botón “Iniciar Sesión” ENTONCES se bloquea el inicio de sesión durante 1 minuto.

98

HISTORIA DE USUARIO Número: 7

Usuario: Administrador

Nombre Historia: Creación automática de usuarios Prioridad en Negocio: 40

Riesgo en Desarrollo: Alto

Puntos Estimados: 13

Sprint: 3

Programador Responsable: Marcos Klender Carrasco Gonzaga Descripción: COMO administrador QUIERO crear usuarios PARA que hagan uso del sistema.

Escenarios de Prueba: DADA la creación de usuarios CUANDO realice una consulta a la base de datos ENTONCES se visualizan los nuevos usuarios.

99

HISTORIA DE USUARIO Número: 8

Usuario: Cliente/Proveedor

Nombre Historia: Restablecer contraseña vía email Prioridad en Negocio: 30

Riesgo en Desarrollo: Alto

Puntos Estimados: 8

Sprint: 3

Programador Responsable: Marcos Klender Carrasco Gonzaga Descripción: COMO cliente QUIERO recuperar mi contraseña PARA poder iniciar sesión.

Escenarios de Prueba: DADA la recuperación de la contraseña CUANDO ingrese mi correo electrónico y pulse el botón “Enviar Link al Correo” ENTONCES se envía un email de recuperación.

DADA la recuperación de la contraseña CUANDO ingrese al link, ingrese mi nueva contraseña y pulse el botón “Reestablecer Contraseña” ENTONCES se inicia mi sesión normalmente.

100

Anexo 7: Pruebas de Aceptación – Sprint 1

101

102

Anexo 8: Pruebas de Aceptación – Sprint 2

103

104

105

Anexo 9: Pruebas de Aceptación – Sprint 3

106

107

108

Anexo 10: Manual Técnico

La presente guía de instalación está dirigida al súper usuario del sistema, mismo que solicitó el desarrollo de este software. De acuerdo a lo solicitado por parte del cliente, él será el encargado de llevar a cabo diferentes pruebas para su posterior implementación en la empresa. Así mismo, se asume que el lector cuenta con los conocimientos y habilidades necesarias para desenvolverse en el entorno Linux y en el framework de desarrollo Laravel.

Requerimientos 

PHP >= 7.0.0



Laravel 5.5



PostgreSQL 9.6

Dependencias 

OpenSSL PHP Extension



PDO PHP Extension



Mbstring PHP Extension



Tokenizer PHP Extension



XML PHP Extension



Ctype PHP Extension



JSON PHP Extension

109

Instalación de PHP Como viene siendo costumbre en los entornos Linux, lo primero que debemos hacer es actualizar los repositorios de la distribución e instalar todas las actualizaciones disponibles antes de descargar e instalar PHP o algún otro componente. Para ello, desde el bash del sistema se debe ejecutar los siguientes comandos:

Una vez actualizado el sistema, lo siguiente será instalar PHP 7.1 junto con todos los paquetes necesarios. Esto se logra ejecutando el siguiente comando:

Al finalizar la instalación se puede comprobar la versión de PHP instalada ejecutando:

Y el comando anterior deberá mostrar un mensaje similar a este:

110

Instalación de PostgreSQL Esta instalación es relativamente sencilla, lo más importante aquí para el funcionamiento del proyecto es la creación del rol y la base de datos en el sistema gestor.

Ubuntu incluye PostgreSQL por defecto y para instalarlo junto con los paquetes más comunes del mismo, se debe ejecutar el comando que se muestra a continuación:

Ahora, es necesario habilitar el servidor PostgreSQL de manera que se ejecute cada vez que iniciemos el sistema operativo. Para ello, son necesarios los siguientes comandos:

Luego de ejecutar el último comando, debe mostrarse el siguiente mensaje:

Una vez verificada la correcta instalación de PostgreSQL, se procederá a ingresar a la cuenta Postgres que se creó automáticamente ejecutando los siguientes comandos:

111

Ahora sólo falta crear el rol y la base de datos, para lo cual ejecutaremos lo siguiente:

La empresa ha solicitado la ejecución de un respaldo en la base de datos creada anteriormente. Para ello, es necesario copiar el archivo “GDG_DEV_20-04-2017.backup” en cualquier directorio y asegurarse que se encuentra ahí, tal como se muestra a continuación:

Finalmente, para ejecutar el respaldo se debe utilizar el siguiente comando:

El tiempo que demora en finalizar este proceso dependerá del tamaño del archivo que se esté respaldando; en este caso, el tiempo puede rondar los 30 minutos debido al tamaño del archivo, 37.6 GB. Una vez finalizado este respaldo, se puede dar por terminada la instalación.

112

Instalación de Laravel Laravel utiliza Composer, un manejador de dependencias para PHP muy robusto, mismo que permitirá instalar el framework y todas las dependencias enlistadas anteriormente.

Para instalar la versión más reciente de Composer se deben ejecutar los siguientes comandos:

Ahora Composer habrá sido descargado e instalado en el directorio actual. Se recomienda actualizar la ubicación para que Composer funcione de manera global y poder utilizar sus comandos desde cualquier lugar. Para ello se necesita el siguiente comando:

Gracias a que el producto hace uso del sistema de control de versiones Github, sólo basta con clonarlo vía HTTPS instalando Git y utilizando el comando clone seguido de la URL:

Con

esto

descargaremos

el

proyecto

en

una

carpeta

llamada

“Electronic_Documentation”. Ahora debemos ingresar a ese directorio y actualizar las dependencias necesarias, tal como se muestra a continuación:

Ahora el proyecto ha sido instalado correctamente, pero la autenticación de usuarios no

113

funcionará hasta migrar las tablas necesarias a la base de datos. Dichas tablas están descritas en los modelos de Laravel y el comando necesario para la migración es el siguiente:

Una vez que las migraciones se hayan realizado, procedemos a ejecutar la semilla que extraerá la información necesaria de la base de datos de la empresa y creará las cuentas de los usuarios del sistema automáticamente. Esto se realiza con el siguiente comando:

Finalmente, el proyecto estará listo para ser utilizado. Primero se debe levantar el servidor que Laravel trae preinstalado y luego, se debe acceder al link que muestra en pantalla.

A continuación, se mostrará el comando y un ejemplo utilizando el navegador Opera:

114

Anexo 11: Manual de Usuario

El presente documento está dirigido a todos los usuarios finales del sistema, como los clientes, proveedores y personal de la empresa. El objetivo de esta guía es la de encaminar a los usuarios en el mejor uso del web service para el control de los documentos electrónicos, mostrando claramente todas las funcionalidades disponibles.

Pantalla de Inicio La pantalla de inicio que se muestra al ingresar al sistema está compuesta de un formulario para el inicio de sesión, el cual requiere el ingreso del RUC/CI y la contraseña.

Inicio de Sesión Para iniciar sesión es necesario llenar los campos respectivos; en este caso, debe escribir su número de RUC o CI y su contraseña, luego pulse el botón “Iniciar Sesión”.

Visualización de Documentos Una vez iniciada la sesión, se mostrará una página que consta de un encabezado con diferentes opciones, pestañas que dividen los documentos a mostrar y una tabla que enlista los documentos encontrados. La búsqueda se basa en el número de RUC o CI del usuario actual.

115

Los documentos que se muestran dependerán de la pestaña seleccionada, por ejemplo, si desea ver las retenciones disponibles, haga clic en la pestaña “Retención”.

En caso de que no se encuentre ningún documento de la categoría seleccionada, se mostrará un mensaje que confirme la inexistencia de los documentos, de la siguiente manera.

116

Descarga de PDF La tabla donde se muestran los documentos cuenta con la opción de visualización de dicho documento como PDF. Para usar esta función, se debe dar clic en la opción correspondiente y luego de esto, el documento se mostrará en una nueva pestaña.

Encabezado El encabezado es donde se encuentran las opciones del sistema, para navegar a dichas páginas sólo hace falta hacer clic en la opción deseada. Como se muestra a continuación.

117

Búsqueda de Documentos Para empezar a buscar documentos específicos debe dar usted de clic en la opción “Búsqueda de documentos” que se encuentra a la derecha, como se ve en la imagen.

Esto desplegará las opciones de búsqueda disponibles para usted.

Como primera opción se encuentra la “Búsqueda por número de documento”. Al dar clic en esta opción, la página pasará a mostrar un cuadro donde puede escribir el número que corresponda al documento que desee encontrar. Se adjunta un ejemplo del mismo.

Como segunda opción está la “Búsqueda por valor”. Esta opción permite buscar los documentos de acuerdo al valor total de los mismos. De igual manera, se adjunta un ejemplo.

118

Como última opción se encuentra la “Búsqueda por fecha de emisión”. Esta opción permite buscar todos los documentos de un día específico, siguiendo el formato de mes/día/año.

119

Perfil de Usuario Para acceder al perfil del usuario debe dar clic en la opción “Mi Perfil” que se encuentra en el encabezado de la página. Luego, se mostrará la siguiente página.

Esta página cuenta con dos opciones: editar su información personal y cambiar su contraseña. Para actualizar la información de su perfil basta con dar clic en el botón “Editar información” y actualizar su información. Una vez hecho esto, proceda a dar clic en el botón “Actualizar información”; caso contrario, de clic en el botón “Cancelar”.

Para cambiar la contraseña de su usuario, de clic en la opción “Cambiar contraseña”, esto mostrará una página donde se solicite el ingreso de su nueva contraseña. Para validar que la contraseña se ha ingresado correctamente, es necesario escribirla dos veces en los cuadros asignados. Una vez hecho esto, proceda a dar clic en el botón “Cambiar contraseña”; caso contrario, de clic en el botón “Cancelar”.

120

Cerrar Sesión Para cerrar sesión basta con dar clic en la opción “Cerrar Sesión” que se encuentra en el encabezado de la página. Acto seguido, la página de inicio se mostrará automáticamente.

Recuperar Contraseña En caso de que olvide su contraseña, en la pantalla de inicio se muestra la opción “¿Olvidó su contraseña?”. Al dar clic en esta opción se mostrará la siguiente página.

Aquí deberá ingresar su correo electrónico y dar clic en el botón “Enviar Link al Correo”. Acto seguido, un email será enviado a la dirección de correo ingresada y en dicho email se adjunta la información necesaria para reestablecer su contraseña.

121

Anexo 12: Presupuesto del Proyecto