Web Service para el control de Documentos Electrónicos de Emproservis CÏA. LTDA. En Santo Domingo by Pontificia Universidad Católica del Ecuador sede Santo Domingo PUCE SD

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas

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.

DIRECTOR DE LA DISERTACIÓN DE GRADO

Jon Azcona Esteban, Mg.

CALIFICADOR

Willian Javier Ocampo Pazos, Mg.

CALIFICADOR

Luis Javier Ulloa Meneses, Mg.

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

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, 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

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

DEDICATORIA

A mis padres y abuelos.

Carrasco Gonzaga Marcos Klender

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

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

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

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

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

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

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

5.3.2.

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

5.3.3.

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

5.3.4.

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

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

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

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

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

Í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. 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. 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?

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.

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.

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

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.

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).

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).

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.

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.

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.

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.

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).

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.

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.

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

documento

HTML

son

desplegados

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).

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.

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).

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:

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

Adaptado de “Database Concepts” por Oracle

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

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)

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).

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).

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).

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).

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.

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:

đ?&#x2018;&#x203A;=

đ?&#x2018; â&#x2C6;&#x2014; đ?&#x2018;?2 â&#x2C6;&#x2014; đ?&#x2018;&#x2020; 2 (đ?&#x2018; â&#x2C6;&#x2014; đ?&#x2018;&#x2019; 2 ) + (đ?&#x2018;? 2 â&#x2C6;&#x2014; đ?&#x2018;&#x2020; 2 )

Donde: ď&#x201A;ˇ

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

ď&#x201A;ˇ

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

ď&#x201A;ˇ

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

ď&#x201A;ˇ

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

ď&#x201A;ˇ

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:

đ?&#x2018;&#x203A;=

1002 â&#x2C6;&#x2014; 1.962 â&#x2C6;&#x2014; 0.52 (1002 â&#x2C6;&#x2014; 0.052 ) + (1.962 â&#x2C6;&#x2014; 0.52 ) đ?&#x2018;&#x203A;=

962.3208 3.4654

đ?&#x2018;&#x203A; = 277.69 Por lo tanto, el nĂşmero muestral de esta investigaciĂłn es de 278 personas.

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.

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

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

Requerimientos Funcionales

Tiempo de Iteración

Nota:

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.

Adaptado de “The Scrum Guide, The

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.

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.

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.

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.

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.

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.

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

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.

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