Desarrollo e implementación de un sistema web con MVC para el control del mantenimiento preventivo 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

DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA WEB CON MVC PARA EL CONTROL DEL MANTENIMIENTO PREVENTIVO Y CORRECTIVO DE LOS BIENES DEL CUERPO DE BOMBEROS DEL GOBIERNO AUTÓNOMO DESCENTRALIZADO MUNICIPAL DE SANTO DOMINGO; PERIODO 2016 - 2017

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: HUGO FERNANDO SILVA ALVAREZ

Director: Mg. LUIS JAVIER ULLOA MENESES

Santo Domingo – Ecuador Agosto, 2017

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas

HOJA DE APROBACIÓN DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA WEB CON MVC PARA EL CONTROL DEL MANTENIMIENTO PREVENTIVO Y CORRECTIVO DE LOS BIENES DEL CUERPO DE BOMBEROS DEL GOBIERNO AUTÓNOMO DESCENTRALIZADO MUNICIPAL DE SANTO DOMINGO; PERIODO 2016 - 2017

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

Autor: HUGO FERNANDO SILVA ALVAREZ

Luis Javier Ulloa Meneses, Mg.

DIRECTOR DE LA DISERTACIÓN DE GRADO

Diego Ricardo Salazar Armijos, Mg.

CALIFICADOR

Willian Javier Ocampo Pazos, Mg.

CALIFICADOR

Margoth Elisa Guaraca Moyota, Mg.

DIRECTORA DE LA ESCUELA DE SISTEMAS

Santo Domingo – Ecuador Agosto, 2017

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Hugo Fernando Silva Álvarezportador de la cédula de ciudadanía Nº 2300275266 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniero de Sistemas y Computación son absolutamente originales, auténticos y personales.

En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legal y académica.

Hugo Fernando Silva Álvarez CI 230027526 - 6

RESUMEN

El presente proyecto de disertación de grado contempla como propósito generalmejorar los procesos correspondientes al mantenimiento preventivo y correctivo de losbienes del Cuerpo de Bomberos del Gobierno Autónomo Descentralizado Municipal deSanto Domingo de los Tsáchilas, a través del desarrollo de un sistema informático en unentorno web, de esta forma se realiza una administración adecuada de los registros de losbienes y se mejora el control de sus respectivos mantenimientos que lleva a cabo eldepartamento de Logística. La elaboración y composición del software SIS-CO (Sistema para el Control yMantenimiento de los Bienes) se encuentra distribuido en seis módulos que son:administración

del

sistema

que

permite

manejar

todos

los

parámetros

configuraciónglobal de la aplicación; personal, proveedores y bienes que son módulos que sirven pararegistrar los bienes con sus respectivas características; custodia que permite registrar lapersona a cargo del bien; y mantenimiento para cada bien registrado. En el presente documento se expone todas las herramientas y técnicas empleadas en el desarrollo del sistema SIS-CO. Se empleó la Metodología de Desarrollo de Software Scrum para gestionar el proyecto; y se utilizó el patrón de diseño MVC para la escritura del código fuente, además se empleó PostgreSQL como sistema gestor de base de datos. Se empleó el lenguaje de programación Python junto con el framework de desarrollo Django para la codificación del sistema, y en el front-end HTML5 y Bootstrap (CSS3) para el apartado visual y diseño de las interfaces.

ABSTRACT

The present project of degree dissertation contemplates as general purpose to improve the processes corresponding to the preventive and corrective maintenance of the Fire Department of the Decentralized Municipal Government of Santo Domingo de los Tsรกchilas, through the development of a computer system in an environment web, this way a proper administration of the records of the goods is carried out and the control of their respective maintenance that carries out the Logistics Department. The elaboration and composition of SIS-CO (System for the Control and Maintenance of Goods) software is distributed in six modules that are: administration of the system that allows to handle all the parameters and global configuration of the application; personnel, suppliers and goods that are modules that serve to register the goods with their respective characteristics; custody that allows registering the person in charge of the property; and maintenance for each registered good. This document describes all the tools and techniques used in the development of the SIS-CO system. The Scrum Software Development Methodology was used to manage the project; and the MVC design pattern was used for the writing of the source code, in addition PostgreSQL was used as database management system. The Python programming language was used in conjunction with the Django development framework for system coding, and in the front-end HTML5 and Bootstrap (CSS3) for the visual section and interface design.

ÍNDICE CONTENIDOS 1.

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

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

2.1. Antecedentes..................................................................................................................... 2 2.2. Problema de investigación ................................................................................................ 3 2.3. Justificación de la investigación ....................................................................................... 4 2.4. Objetivos de investigación ............................................................................................... 5 2.4.1.Objetivo General: .............................................................................................................. 5 2.4.2.Objetivos Específicos: ...................................................................................................... 5 3.

MARCO REFERENCIAL ............................................................................................... 6

3.1. Revisión de la literatura o fundamentos teóricos ............................................................. 6 3.1.1.Lenguaje de Programación ............................................................................................... 6 3.1.2.Base de datos................................................................................................................... 10 3.1.3.Lenguaje estructurado de consulta .................................................................................. 15 3.1.4.Ingeniería de Software .................................................................................................... 16 3.1.5.Metodología de Desarrollo ............................................................................................. 18 3.1.6.Aplicaciones Web ........................................................................................................... 24 3.1.7.Marco de referencia (Framework) .................................................................................. 26 3.1.8.Esquema Modelo – Vista – Controlador (MVC) ............................................................ 27 3.1.9.Gestión de Inventario ...................................................................................................... 28 3.1.10Depreciaciones ............................................................................................................... 29 3.1.11.Mantenimiento .............................................................................................................. 30 3.1.12.Mantenimiento Preventivo ............................................................................................ 30 3.1.13.Mantenimiento Correctivo ............................................................................................ 31 3.1.14.Normativa de los Bienes ............................................................................................... 31 4.

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

4.1. Diseño / Tipo de investigación ....................................................................................... 33 4.2. Población / Universo ...................................................................................................... 34 4.2.1.Población......................................................................................................................... 34 4.2.2.Muestra ........................................................................................................................... 34 4.3. Técnicas e Instrumentos de Recogida de datos .............................................................. 34 4.3.1.Técnicas .......................................................................................................................... 34

vii

4.3.2.Instrumento ..................................................................................................................... 34 4.4. Metodología de desarrollo de software .......................................................................... 35 4.4.1.SCRUM........................................................................................................................... 35 4.4.2.Componentes de SCRUM ............................................................................................... 35 4.4.3.Proceso de SCRUM ........................................................................................................ 36 4.4.4.Eventos de SCRUM ........................................................................................................ 37 5.

RESULTADOS .............................................................................................................. 42

5.1. Análisis y Discusión de los resultados ........................................................................... 42 5.1.1.Entrevista realizada al personal del Departamento de Logística .................................... 42 5.1.2.Entrevista realizada al personal del Departamento de Sistemas ..................................... 44 5.1.3.Encuesta personal del Departamento de Logística ......................................................... 45 5.1.4.Discusión de los resultados obtenidos en la encuesta ..................................................... 55 5.1.5.Discusión de los resultados obtenidos en la entrevista ................................................... 55 5.2. Aplicación de la metodología de desarrollo de software................................................ 56 5.2.1.Planificación ................................................................................................................... 56 5.2.2.Desarrollo de Software ................................................................................................... 60 5.3. Conclusiones................................................................................................................... 66 5.4. Recomendaciones ........................................................................................................... 67 LISTA DE REFERENCIA ...................................................................................................... 68 5.5. Fuentes de Información Bibliográficas .......................................................................... 68 5.6. Fuentes de Información Lincográficas ........................................................................... 69 5.7. Glosario .......................................................................................................................... 70 ANEXOS ................................................................................................................................. 71

viii

ÍNDICE TABLAS Tabla 1: Comparativa entre lenguajes de programación............................................................ 9 Tabla 2: Comparativa entre Sistemas Gestores de Base de Datos ........................................... 14 Tabla 3: Comparativa Métodos Ágiles y Métodos Tradicionales ........................................... 19 Tabla 4: Comparativa entre métodos ágiles ............................................................................. 23 Tabla 5: Control y registro de bienes ....................................................................................... 46 Tabla 6: Seguimiento de incidencias de bienes ....................................................................... 47 Tabla 7: Control de inventario ................................................................................................. 47 Tabla 8: Cantidad de personal que realiza los mantenimientos ............................................... 48 Tabla 9: Sistema informático para registrar bienes.................................................................. 49 Tabla 10: Sistema web ............................................................................................................. 50 Tabla 11: Sistema informático mejora el control y registro de bienes .................................... 51 Tabla 12: Aspectos que mejorarían con el sistema .................................................................. 52 Tabla 13: Implementación de un sistema................................................................................. 53 Tabla 14: Necesidad de un sistema para registrar mantenimientos ......................................... 54 Tabla 15: Product Backlog....................................................................................................... 56 Tabla 16: Sprint Backlog ......................................................................................................... 57

ÍNDICE FIGURA Figura 1: Porcentaje de aceptación de la pregunta 1................................................................ 46 Figura 2: Porcentaje de aceptación de la pregunta 2................................................................ 47 Figura 3: Porcentaje de aceptación de la pregunta 3................................................................ 48 Figura 4: Porcentaje de aceptación de la pregunta 4................................................................ 49 Figura 5: Porcentaje de aceptación de la pregunta 5................................................................ 50 Figura 6: Porcentaje de aceptación de la pregunta 6................................................................ 51 Figura 7: Porcentaje de aceptación de la pregunta 7................................................................ 52 Figura 8: Porcentaje de aceptación de la pregunta 8................................................................ 53 Figura 9: Porcentaje de aceptación de la pregunta 9................................................................ 54 Figura 10: Porcentaje de aceptación de la pregunta 10............................................................ 55 Figura 11: Historial de migraciones ......................................................................................... 60 Figura 12: Captura del historial del proyecto en GitKraken .................................................... 61 Figura 13: Diseño de Bases de Datos. ..................................................................................... 62 Figura 14: Sitio Administrativo del Sistema ............................................................................ 63 Figura 15: Menú principal de cada módulo. ............................................................................ 64 Figura 16: Interfaz de inicio del Sistema ................................................................................ 64 Figura 17: Interfaz de lista y búsqueda del módulo ................................................................. 65 Figura 18: Interfaz de detalle del módulo. ............................................................................... 65

ÍNDICE DE ANEXOS ANEXOS ................................................................................................................................. 71 ANEXO 1 Carta de Asignación de Proyecto ........................................................................... 72 ANEXO 2 Carta de Impacto .................................................................................................... 73 ANEXO 3 Acta de Entrega - Recepción.................................................................................. 74 ANEXO 4 Entrevista dirigida al Departamento de Logística .................................................. 75 ANEXO 5 Entrevista dirigida al Departamento de Sistemas .................................................. 76 ANEXO 6 Encuesta dirigida al Departamento de Logística ................................................... 77 ANEXO 7 Historias de Usuarios ............................................................................................. 78 ANEXO 8 Product Backlog ..................................................................................................... 91 ANEXO 9 Sprint Backlog ....................................................................................................... 92 9.1 Sprint 0 ............................................................................................................................... 92 9.2 Sprint 1 ............................................................................................................................... 93 9.3 Sprint 2 ............................................................................................................................... 94 9.4 Sprint 3 ............................................................................................................................... 95 9.5 Sprint 4 ............................................................................................................................... 96 9.6 Sprint 5 ............................................................................................................................... 97 ANEXO 10 Diccionario de Datos............................................................................................ 99

INTRODUCCIÓN

La presente tesis es una investigación que tiene por objetivo controlar el mantenimiento de los bienes que administra el Cuerpo de Bomberos de Santo Domingo a través de un software que monitoree la periodicidad para realizar dichos mantenimientos. Los datos se obtienen de los documentos donde se registran los mantenimientos y en otros donde se lleva un inventario de ellos mismo: Bienes de oficina. Las fuentes bibliográficas proceden de investigaciones delibros alcanzados de la Pontificia Universidad Católica del Ecuador sede Santo Domingo para todo alrededor del desarrollo de software, también se toma información de artículos científicos del área de Sistemas. Esta bibliografía se centra en las nuevas tendencias tanto en la selección de herramientas como para la construcción del software, para así poder tener un producto robusto y escalable. Este trabajo presenta los siguientes capítulos: En el capítulo I se presenta el planteamiento de la investigación, el problema,los objetivos, la justificación, los alcances y limitaciones que se presentan en dicha investigación, además delmarco teórico. También los objetivos y relevancia de la investigación. Seabordan los aspectos metodológicos. En el Capítulo II se abordan los aspectos teóricos con relación a la administra y mantenimiento de bienes, sus características y como los sistemas de información mejoran los procesos dentro de las instituciones. Se tratan aspectos como la metodología de desarrollo, patrón de desarrollo. Sedescribe también qué es un sistema web y como está diseñado. Se fundamenta por qué es necesario así como el uso de un patrón de arquitectura. En el Capítulo III se aborda los aspectos relacionados directa e indirectamente con el desarrollo de software. En especial se proponeel uso de herramientas modernas, robustas, ágiles y de software libre. En el Capítulo IV se ofrece la discusión e interpretación de los resultados. En el Capítulo V se presentan las conclusiones y recomendaciones de estaTesis.

2. 2.1.

PLANTEAMIENTO DEL PROBLEMA

Antecedentes Según la página oficial del Cuerpo de Bomberos del Gobierno Autónomo

DescentralizadoMunicipal de Santo Domingo es una institución dedicada a proteger la vida, los bienes y el medio ambiente en el contexto local, con los más altos niveles de calidad, previniendo toda clase de siniestros o flagelos a través de la capacitación ciudadana. Trabaja las 24 horas del día, los 365 días del año.Mitigando incendios con atención oportuna y equipos especializados, salvando víctimas en riesgo con materiales considerados peligrosos, llevando a cabo trabajo bomberil con disciplina y responsabilidad, trabajando siempre en equipo con profesionalismo y eficiencia para brindar una mejor atención en beneficio de la ciudadanía. El Cuerpo Bomberos del Gobierno Autónomo Descentralizado Municipal de Santo Domingo tiene como misión en el 2017 constituirse en una entidad de excelencia y calidad en los servicios que brinda, mediante el mejoramiento continuo de sus procesos para lo cual contará con talento humano altamente capacitado, infraestructura funcional y tecnología de primera, alcanzando la satisfacción de las necesidades de los usuarios e implementando la gestión de riesgos dentro de su zona de influencia. En la institución se detectóun deficiente control de los bienes, presentando inconsistencia en los datos de los equipos, en los registros e historial de los bienes que posee la institución, esto genera pérdida de tiempo en los procesos relacionados al departamento de sistemas como al de logística, da apertura a una demora en la búsqueda de los equipos. El inadecuado control del mantenimiento preventivo y correctivo de los bienes en la institución, hace que los usuarios que tienen la respectiva custodia notifiquen las incidencias en el momento que se presentan, esto resta productividad a los poseedores del equipo, como al departamento de sistemas porque se atiende estos mantenimientos improvisadamente. La cantidad de personal para el departamento de sistemas es insuficiente,porque se desempeñan en varios procesos, la inversión de tiempo en mantenimientos correctivos no es una forma adecuada de trabajo.Los mantenimientos preventivos no se realizan frecuentemente, solo se atiende a los equipos que presentan una falla en el instante que esta incidencia aparece, por lo tanto se resta productividad al departamento de sistemas.

El deficiente desempeño del manejo de la información de las incidencias informáticas que se presentan en el departamento de logística del Cuerpo de Bomberos, genera muchos más problemas que el tiempo que se invierte en realizar el mantenimiento correctivo del bien, se retrasan los procesos definidos en la institución, el personal pierde productividad más los contratiempo que se pueden presentar hasta corregir la incidencia, por estos motivos se plantea desarrollar un sistema informático que gestionará los mantenimientos preventivos y correctivos de los bienes.

2.2.

Problema de investigación El Cuerpo de Bomberos dispone de un sistema de inventario que no permite llevar un

control de los mantenimientos preventivos y correctivos de los bienes existentes en la institución, por tal motivo se requiere un sistema para este control en la institución. El control de los mantenimientos preventivos y correctivos no es adecuado para la institución, esto genera demora en la solución de las incidencias, retrasos en los procesos definidos, se pierde productividad tanto en el departamento de sistemas como en los usuarios que tienen el custodio de los bienes. El presente proyecto de investigación responderá a la problemática: ¿Cómo mejorar el control del mantenimiento preventivo y correctivo de los bienes del Cuerpo de Bomberos del GADM de Santo Domingo? La presente investigación pretende contestas las preguntas directrices: ¿Cuáles son las actividades y procesos para el registro de los bienes y sus respectivos mantenimientos preventivos y correctivos? ¿Cuáles son las metodologías y herramientas de desarrollo de software que se podrían aplicar para el sistema de control de mantenimientos? ¿Cuáles es la funcionalidad y patrón arquitectónico del sistema para el control de mantenimientos preventivos y correctivos?

2.3.

Justificación de la investigación Una aplicación compuesta por un servidor web, administra y atiende solicitudes de los

clientes enviando al módulo de lenguaje interpretado; una base de datos que almacena la información referente a los elementos insertados en la aplicación, se encarga de atender las peticiones del servidor web, interpretándolas y construyendo la respuesta va a ser enviada al cliente.(Berrospi, y otros, 2015, pág. 726). Un desarrollo de software correcto es necesario el acompañamiento de expertos de los procesos de la organización, para esto existen muchos modelos y metodologías para un desarrollo de software que cumpla los requerimientos solicitados y ofrecer un producto de calidad a la organización que utilizará el software.(Cendejas, Vega, Careta, Gutiérrez, & Ferreira, 2014, pág. 136). El presente trabajo de investigación se alinea con el objetivo número once del Plan Nacional del Buen Vivir, el cual menciona “Asegurar la soberanía y eficiencia de los sectores estratégicos para la transformación industrial y tecnológica”. Esto a través del desarrollo de un sistema informático, el cual permite realizar un control de los bienes y de los mantenimientos preventivos y correctivos de los mismos, en el departamento de logística en la institución.(Secretaría Nacional de Planificación y Desarrollo, 2013). Al no disponer de un sistema para el control del mantenimiento preventivo y correctivo de los bienes del Cuerpo de Bomberos del GADM de Santo Domingo, actualmente se lleva un control manual, el cual necesita ser automatizado como lo es un sistema para dicho control y así mejorar y mantener en el mejor estado posible los bienes, en los tiempos predefinidos. Esto no solo mejora el proceso, sino que acorta los tiempos invertidos en los procesos que se lleva manualmente, he aquí la importancia y justificación del desarrollo del sistema de información para mantener y aprovechar la vida útil de los bienes que dispone la institución. Dicho sistema permitirá realizar los mantenimientos de los bienes en los plazos definidos, y controlar de mejor manera el registro de dichos bienes, al realizarse con herramientas robustas, el sistema será escalable y no perderá rendimiento por manejar un gran volumen de datos; esto gracias al uso de herramientas de software libre así como las nuevas tecnologías que se utilizará.

2.4.

Objetivos de investigaciĂłn

2.4.1.

Objetivo General: Implementar un sistema web con modelo-vista-controlador (MVC) para el control del

mantenimiento preventivo y correctivo de los bienes del Cuerpo de Bomberos del GADM de Santo Domingo.

2.4.2.

Objetivos EspecĂficos: Determinar los diferentes procesos y actividades para el registro de los bienes y sus

mantenimientos. Definir las metodologĂas de desarrollo de software, herramientas y recursos para el sistema de control de mantenimientos. Desarrollar un sistema informĂĄtico para el control de los bienes y sus respectivos mantenimientos preventivos y correctivos.

MARCO REFERENCIAL

3.1.

Revisión de la literatura o fundamentos teóricos

3.1.1.

Lenguaje de Programación

3.1.1.1. Lenguaje de computadora Los lenguajes naturales como el inglés o el español son comprendidos por las personas, pero las computadoras procesan información por señales eléctricas, por el hecho de que son dispositivos electrónicos y dichas señales son digitales las cuales representan ceros y unos; cero cuando es bajo voltaje y uno cuando es alto voltaje y por esto es llamado lenguaje máquina a la secuencia de dígitos, cada bit o dígito binario en conjunto se conoce como código binario o número binario. La unidad básica es el bit y la secuencia de ocho bits es el byte. (Joyanes, 2013, pág. 13). 3.1.1.2. Lenguajes de programación Los lenguajes básicos de computadoras como el lenguaje máquina provee de instrucciones en bits, pero cada fabricante de procesadores utiliza su propio conjunto de códigos binarios y por tal motivo no es el mismo lenguaje máquina entre las computadoras, pero resulta muy complicado generar códigos binarios para cada operación que se quiera realizar y por esto se empezó a crear lenguajes ensambladores para que la tarea de programar sea más sencilla, aunque es mucho más fácil escribir código ensamblador la computadora no la puede ejecutar directamente, es necesario traducir esto a lenguaje máquina. El siguiente salto en la programación fue el diseño y construcción de lenguajes de alto nivel y así reducir la dificultad que trae programar en lenguaje ensamblador; aparecieron lenguajes como C, C++, Java, Basic, Python y al igual que sucede con ensamblador estos lenguajes deben traducirse por medio de un compilador o intérprete a lenguaje máquina.(Joyanes, 2013, págs. 14-16). 3.1.1.3. Programación orientada a objetos La programación orientada a objetos es un paradigma de que posee cuatro características principales: abstracción que permite simplificar el concepto real y eliminar aspectos no relevantes; encapsulamiento que es el ocultamiento de información no necesaria para otros objetos; herencia: puede compartir atributos y métodos de otros objetos;

polimorfismo: que permite implementar varias formas de un mismo método. Ventajas que provee esto es la facilidad de reusar código y diseño, implementando seguridad gracias al encapsulamiento y tener un código más legible. (Guardati, 2014, págs. 1-4). 3.1.1.4. Python Actualmente Python es uno de los lenguajes de programación más robustos por su facilidad de uso, librería estándar y la cantidad de librerías adicionales que existen gracias a la contribución de la comunidad de desarrolladores de software, a las personas que optan por desarrollar sus proyectos con esta herramienta. Es un lenguaje de propósito general considerado de muy alto nivel por su sintaxis clara y concisa; admite diferentes tipos de paradigmas

como:

programación

procedural,

imperativa

orientada

objetos,

frecuentemente se emplea en la programación científica, de sistemas o aplicaciones web así como en el desarrollo de aplicaciones de escritorio con interfaz gráfica, en la integración de componentes escritos en diferentes lenguajes de programación hasta en el desarrollo de videojuegos. (Fernández, 2013, págs. 1-3). 3.1.1.5. Principales Características de Python Una de las principales características que es interpretado y otra, multiplataforma, esto nos dice que no necesita ser compilado para ejecutarse, necesita un intérprete para leer y entender que debe realizar con el código fuente y al ser multiplataforma permite ejecutar el mismo script en diferentes sistemas operativos; hasta ahora vemos que es un lenguaje interpretado, pero internamente Python se encarga de generar archivos binarios a partir del código fuente automáticamente, y se le llama bytecode, con una extensión .pyc entonces cuando se ejecuta un script este lee el fichero .py, genera el código el bytecode y lo ejecuta; todo esto se realiza por eficiencia, como esto es un proceso automático, el programador no tiene que preocuparse por esto. (Fernández, 2013, págs. 4-14). 3.1.1.6. PHP PHP son las siglas de PHP Hypertext Pre-Procesor, es un lenguaje de programación interpretado creado en 1994, actualmente The PHP Group se encarga de su desarrollo y mantenimiento. Al ser un lenguaje interpretado, emplea un intérprete que procesa el código para luego ser mostrado al usuario. Es el lenguaje más utilizado para el desarrollo de sitios web, usado frecuentemente en aplicaciones del lado del servidor. (Cibelli, 2012, págs. 1-2).

3.1.1.7. Principales características de PHP Entre las características más relevantes de PHP destaca por ser software libre y multiplataforma (GNU/Linux, MacOS, Windows), además, otorga la libertad de elegir el servidor web con el cual se va a trabajar. Con PHP se generan páginas web de forma dinámica. Otra característica destacada está en su capacidad de ser compatible con una amplia lista de base de datos. Además, posee otras características como el soporte tanto para programación procedimental como orientada a objetos, el código php puede ser incrustado junto al código html, permite la comunicación con otros servidores a través de protocolos, procesamiento de texto, creación de ficheros pdf o xml, entre otras características que se pueden extender a través de librerías. (The PHP Group, 2017). 3.1.1.8. ASP.NET ASP.NET es la plataforma de Microsoft que proporciona un entorno de desarrollo unificado, el cual provee todos los recursos necesarios para la construcción de aplicaciones web. Estas aplicaciones son accesibles por el cliente a través de un navegador web, el cual solicita todos los componentes que conforman la aplicación ASP.NET al servidor web, frecuentemente IIS (Internet InformationServices), el cual devuelve el resultado como código html al usuario final. El código de la aplicación puede ser de cualquier lenguaje que sea compatible con el framework .NET, como lo es C# o Visual Basic.(Ceballos, 2013, págs. 742-743). C# es un lenguaje de programación que pertenece a la familia de .NET Framework. Es un lenguaje orientado a objetos y componentes, su sintaxis se deriva de C/C++. Cuenta con un garbagecollector y control de errores a través de excepciones. (Arias, 2015, pág. 15). 3.1.1.9. Principales características de ASP.NET ASP.NET destaca por lograr separar tanto la capa de presentación como la de lógica de negocio, consiguiendo de este modo desarrollar aplicaciones web multicapa. Al ser una tecnología de Microsoft y formar parte del .NET framework, disfruta de todas las virtudes que éste admita, permitiendo usar el conjunto de clases y librerías que el framework posea, además, el código se escribe en cualquier lenguaje que sea compatible con el mismo. La velocidad de acceso a una página de una aplicación y su rendimiento mejora conforme se vayan accediendo a la misma. ASP.NET provee formularios web y servicios web para el desarrollo web. Por otro lado, añadiendo mecanismos que guarden el estado de la aplicación, se facilita el mantenimiento y administración de la misma.(Ceballos, 2013, pág. 744)

3.1.1.10. Comparativa entre lenguajes de programación A continuación se realiza una comparativa entre los lenguajes de programación antes expuestos, describiendo criterios o características diferenciadoras entre cada uno de ellos.

Tabla 1: Comparativa entre lenguajes de programación [a] [b]

Característica

[c]

Python

[d] [e] [f]

PHP

ASP.NET

Plataforma de uso

Multiplataforma

Entornos Windows

Tipo de Software

Open-source

Comercial

Tipo de Lenguaje

Interpretado

Compilado

Propósito

Amplia cobertura de campos (de propósito general)

De propósito general (enfocado al desarrollo web)

Enfocado al Desarrollo web

   Usabilidad

Paradigmas

Sintaxis Servidores Web soportados

Desarrollo web Computación científica Desarrollo de software y videojuegos  Programación de red  Desarrollo de aplicaciones GUI  Administración de sistemas Multiparadigma. Total integración de la programación orientada a objetos Sintaxis limpia y sencilla. Fácil de aprender Apache, Tornado, CherryPy, Nginx entre otros servidores web compatibles con WSGI.

  

Desarrollo Web (server side) Desarrollo de Scripts en línea de comandos Desarrollo de aplicaciones de escritorios (PHP GTK)

  

Desarrollo de aplicaciones de consola Desarrollo Web Desarrollo basado en Windows forms

Multiparadigma. Soporte del paradigma orientado a objetos

Orientado a objetos y componentes

Parecida a C/Perl

Derivada del C/C++

Apache, Lighttp, LiteSpeed Web Server, Nginx, entre otros

Servidor IIS (Internet InformationServices)

Nota: Fuente:[a] Fernández, A. (2013). Python 3 al descubierto (Segunda ed.). México: AlfaomegaGrupo Editor.[b] Python Software Foundation. (2017). About Python. Obtenido de https://www.python.org/about/[c]The PHP Group. (2017). ¿Qué puede hacer PHP? Obtenido de http://php.net/manual/es/intro-whatcando.php[d]Arias, Á. (2015). Aprende a programar en C#.Middletown: CreatespaceIndependent Publishing Platform[e]Ceballos, J. (2013). Enciclopedia de Microsoft Visual C#. Interfaces gráficas y aplicaciones para Internet con Windows Forms y ASP.NET. México: Alfaomega.[f]Ramírez, F. (2012). Aprenda practicando ASP.NET usando Visual Studio 2012. México: Alfaomega

Se ha seleccionado el lenguaje de programación Python porque es un lenguaje robusto, fácil de mantener cualquier tipo de software que se desarrolle, posee una gran comunidad, es escalable y la curva de aprendizaje es corta, esto permite que sea fácil de leer el código fuente porque tiene una sintaxis limpia y sencilla, permite usar varios paradigmas como la programación estructurada, orientación a objetos y funcional, permitiendo mezclar las ventajas de cada una de ellas; su completa integración del paradigma orientado a objetos,

la facilidad de uso, y amplio propósito de uso, además de ser compatible con una amplia variedad de servidores web a través de WSGI. Python al ser un lenguaje interpretado y multiplaforma proporciona portabilidad y provee la posibilidad de usar librerías de C, porque tiene implementación en este lenguaje. 3.1.2.

Base de datos

3.1.2.1. Base de datos relacionales Se las define como un depósito de datos o colección de estos con una redundancia controlada y una estructura que muestre las interrelaciones y restricciones que también se encuentran en el mundo real, estos datos deben estar independientes de las aplicaciones para poder compartir. (Piñeiro, 2013, pág. 3). 3.1.2.2. Modelos de datos Existen muchos modelos de datos aplicables cada uno en diferentes circunstancias en el proceso de creación de base de datos, estos son: diseño conceptual, diseño lógico y diseño físico, cada uno de estos se ocupan en las fases del diseño de base de datos. Modelo Conceptual: es el primero que se emplea en la creación de base de datos, también son llamados modelos lógicos, independiente del tipo de base de datos. Modelo Físico: Es la última fase del diseño de la base de datos y consiste en crear dentro de un Sistema Gestor de Base de Datos todo los elementos de la base de datos. (Piñeiro, 2013, págs. 11-16). 3.1.2.3. Modelo Entidad Relación Es el modelo más utilizado en la actualidad para realizar el diseño o modelado conceptual de una base de datos, fue propuesto por Peter Chen en 1976 y está compuesto por estos elementos: Entidad: puede ser cualquier objeto del cual se desea almacenar información en la base datos. Relación: cualquier interrelación que se pueda definir con otras entidades, toda relación debe tener las siguientes características:

Nombre: debe tener un nombre único en el esquema. Grado: se refiere al número de entidades que participan en una relación. Relación binaria: solo se relacionan 2 entidades. Relación reflexiva: se relaciona una entidad con la misma. Relación ternaria, cuaternaria, etc.: donde se relacionan 3, 4, n entidades. Tipo de correspondencia, se puede dar de 1:1 donde se asocia una ocurrencia con otra única ocurrencia; 1:N donde una ocurrencia se relaciona con varias ocurrencias de otra entidad. N:M cuando varias ocurrencias se relacionan con varias ocurrencias. (Piñeiro, 2013, págs. 69-70). Sistema gestor de base de datos DBMS (Database Management System) o sistema gestor de base de datos (SGBD) es un tipo de software especializado y dedicado a servir de interfaz entre la base de datos, el software y el usuario, entonces podemos decir que es una colección de datos relacionados entre sí con una estructura definida y organizada, esta colección se la llama base de datos, y su propósito es manejar de manera clara, simple y ordenada un conjunto de datos que serán relevantes para la organización. (Valderrey, 2013, pág. 31). 3.1.2.4. Objetivos del SGBD Los objetivos más relevantes a cumplir por el SGBD son: Abstracción de la información: facilitan el almacenamiento físico de los datos, no importa si una base de datos ocupa pocos o muchos archivos, esto es transparente para el usuario. Independencia: consiste en la capacidad de modificar el esquema ya sea lógico o físico de la base de datos sin tener que hacer modificaciones en las aplicaciones que la utilizan. Consistencia: cuando no se ha logrado eliminar la redundancia, es importante revisar que esta información se actualice coherentemente, en otras palabras se tienen que actualizar simultáneamente todos los datos redundante.

Seguridad: la información almacenada puede llegar a ser muy preciada, y por tal motivo los SGBD deben garantizar que se den los permisos adecuados a cada usuario y grupos de usuarios. Manejo de transacciones: es un programa que se ejecuta como una sola operación, para garantizar que después de una falla regresa al estado inicial, como si no se hubiese ejecutado. Tiempo de respuesta: minimizar el tiempo de respuesta para obtener la información solicitada y guardar los cambios realizados. (Valderrey, 2013, págs. 33-34). 3.1.2.5. Ventajas e inconvenientes de los SGBD Dentro de las ventajas tenemos las siguientes: Brindan facilidad para manipular grandes volúmenes de información. Garantiza que los cambios serán siempre consistentes, gracias al manejo de políticas de respaldo, sin importar si hay errores. Disminuye tiempos invertidos en el desarrollo y así aumentan la calidad del software desarrollado, siempre y cuando sea bien elaborado. Proveen interfaces y le3enguajes de consulta que facilitan la obtención de datos. Comúnmente es necesario tener a uno o más personas para la administración de la base de datos, tanto para la parte lógica como física, esto aumenta los costos de operación. Cuando se usa una base de datos con pocos datos y pocos usuarios es mejor optar por manejar los datos en una hoja de cálculo. Muchas veces el software muy complejo requiere de personas que conozcan esta complejidad para aprovechar al máximo. La gran cantidad de funciones convierten a los SGBD en un software de gran tamaño y esto requiere una gran cantidad de memoria para poder ejecutarse y trabajar óptimamente. El hardware para ejecutar SGBD generalmente es robusto y por tal motivo, también es costoso. (Valderrey, 2013, pág. 36).

3.1.2.6. PostgreSQL PostgreSQL es un sistema gestor de base de datos objeto-relacional de código abierto. Es la base de datos más potente que existe entre las opciones libres y posee más de una década de activo desarrollo y mantenimiento. Se destaca por ser una base de datos muy fiable, segura, potente, estable y multiplataforma, capaz de ejecutarse en la mayoría de sistemas operativos del tipo Unix, GNU/Linux y Windows. Es totalmente adaptable y configurable, provee soporte para varios lenguajes de programación en procedimientos almacenados y cumple con las propiedades ACID. Es altamente compatible con los tipos de datos del SQL: 2008 y posee una gran cantidad de características y extensiones que amplían sus funcionalidades avanzadas. (The PostgreSQL Global Development Group , 2017). 3.1.2.7. MariaDB MariaDB es un sistema gestor de base de datos open-source, desarrollada por los creadores originales de MySQL. La finalidad de este sistema gestor fue la de ofrecer un reemplazo o alternativa “libre” y compatible con todas las características y funcionalidades que ofrece MySQL. Trabaja de igual modo que MySQL, es decir, todos los comandos, librerías, APIs entre otras características de MySQL son completamente compatibles con MariaDB, además, éste último añade nuevas características y mejoras como por ejemplo: más soporte para motores de almacenamiento, mejoras en el rendimiento y nuevas extensiones (GIS), por mencionar algunas. El desarrollo, actualización y mantenimiento está a cargo de la amplia comunidad de desarrolladores de MariaDB. (MariaDB Foundation, 2017). 3.1.2.8. SQL Server SQL Server es el sistema gestor de base de datos perteneciente a la familia de productos de software de Microsoft. SQL Server se encuentra disponible en varias versiones que dependiendo de su orientación y uso poseerán o no limitaciones, es así que de modo general se tiene la versión Developer, Web, Express y Enterprise, siendo esta última la versión completa. (Salazar, 2013, págs. 10-13). Este sistema gestor en sus versiones más recientes permite crear aplicaciones OLTP, soporte de Business Intelligence, provee escalabilidad y seguridad avanzada, mejoras en rendimiento y la posibilidad de probar SQL Server en sistemas Linux y MacOS con la versión SQL Server v.Next. (Microsoft Corporation, 2017).

3.1.2.9. Comparativa entre Sistemas Gestores de Base de Datos Tabla 2: Comparativa entre Sistemas Gestores de Base de Datos Característica

[a] [b]

PostgreSQL

[c] [d]

MariaDB

[e] [f]

SQL Server

Tipo de Software

Open-Source

Comercial

Desarrollador

The PostreSQL Global Development Group

MariaDB Foundation

Microsoft Corporation

Plataforma

Multiplataforma

Instalación/Recursos

Código Fuente o Paquetes Binarios de instalación, con o sin GUI dependiendo de la plataforma. Requerimientos medios y consumo moderado de recursos

Código Fuente o Paquetes Binarios de instalación dependiendo de la plataforma. Requerimientos mínimos de instalación y consumo mínimo

Cumplimiento de propiedades ACID

Máximo tamaño de la base de datos

Ilimitada

Seguridad

Base de datos con amplias características de seguridad gracias al control de acceso por roles de usuario y privilegios, e implementada en varios niveles.

Solo en determinados motores de almacenamiento (InnoDB, PBXT) Depende del motor de almacenamiento (MyISAM 256 TB; InnoDB 64TB)

A través de parches de seguridad que despliega la comunidad

Windows

Instalación por medio de ejecutable. Requisitos de instalación dependen de la versión. Requiere componentes extras para su uso. Consumo grande de recursos Si

Limitada por la versión del software Últimas ediciones con características avanzadas de seguridad Cada versión posee diferentes formas de seguridad. SQL Server maneja autenticación y autorización.

Nota:Fuente: [a] The PostgreSQL Global Development Group. (2017). About PostgreSQL. Obtenido de https://www.postgresql.org/about/[b]Martínez, R. (2013). 10 razones para utilizar PostgreSQL. Obtenido de http://www.postgresql.org.es/10_razones[c]MariaDBFoundation. (2017). AboutMariaDB. Obtenido de https://mariadb.org/about/[d]MariaDB. (2017). Knowledge Base. Obtenido de https://mariadb.com/kb/en[e]Microsoft Corporation. (2017). SQL Server 2016. Obtenido de https://www.microsoft.com/es-es/sql-server/sql-server-2016features[f]Microsoft Corporation. (2017). Editions and supported features of SQL Server. Obtenido de https://docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2016

Se ha escogido como gestor de base de datos a PostgreSQL dado que provee un enorme potencial por su tiempo que lleva en desarrollo y mantenimiento, posee varias extensiones que nos proporciona más y mejores funcionalidades, es un DBMS muy robusto,estable y seguro dado a que su robustez al manejar una gran cantidad de volúmenes de datos y transacciones; es multiplataforma esto proporciona soporte para varios lenguajes de programación; en la institución como requerimiento se necesita hacer uso de PostgreSQL.

3.1.3.

Lenguaje estructurado de consulta

3.1.3.1. Lenguaje estructurado de consulta (SQL) SQL significa StructuredQueryLanguage, en español lenguaje estructurado de consulta y se basa sobre el álgebra relacional donde se realiza las consultas como si fueran preguntas y las relaciones son vistas como un conjunto de tuplas. También nos sirve para la administración de la base de datos; gracias al Instituto de Normalización Americano (ANSI) que estableció una normativa oficial y ha permitido que un programa escrito en cualquier lenguaje de programación contenga código SQL, de esta forma interactúa con la base de datos.(Orbegozo, 2013, pág. 68). 3.1.3.2. Lenguaje SQL El lenguaje SQL incluye las siguientes categorías dentro de las sentencias SQL: DDL (Data DefinitionLanguage) o en español lenguaje de definición de datos es utilizado para crear, alterar o borrar elementos como esquemas, tablas, columnas, vistas y secuencias en una base de datos y entre sus sentencias o comandos característicos están: CREATE, ALTER, DROP. Pueden variar un poco entre los sistemas gestores de base de datos el verbo, pero su función es la misma. DML (Data ModificationLanguage) o lenguaje de modificación de datos se emplea específicamente en tareas como manipulación de datos o interrogación en esquemas ya creados y los ejemplos característicos de instrucciones para este son: SELECT, INSERT, UPDATE y DELETE. DCL (Data Control Language) o lenguaje de control de datos utilizado en el control de acceso a datos en una base de datos, puede otorgar o quitar permisos a usuarios, así se controla los privilegios; sus sentencias características son: GRANT, REVOKE. (Pérez, MySQL Diseño, Programación y Aministración de Bases de Datos, 2015, pág. 37). 3.1.3.3. Lenguaje procedural / Lenguaje estructurado de consulta (PL/SQL) Es un lenguaje de programación incrustado por Oracle para su base de datos, soporta y extiende la funcionalidad del SQL, con características propias del cualquier lenguaje de programación como variables, sentencias de control de flujo, bucles, etc. Toda esta

integración realizada por Oracle, pero la comunidad de software libre también implementaron a su competidor PostgreSQL, sus componentes son los siguientes: Bloques: unidades básicas en la programación de PL/SQL Unidades léxicas: secuencias de características permitidas que componen los programas. Variables: espacios de memoria que pueden contener valores de datos. Tipos: elementos que pueden ser usados por las columnas de la base de datos y definen el tipo de datos permitidos en el lenguaje PL/SQL y en la base de datos. Expresiones y operadores: componente que permiten unir las variables PL/SQL, estos definen como se asignan y manipulan los valores a las variables. Funciones: aparte de los tipos, definen funciones predefinidas de SQL y convierten en utilizable en PL/SQL. Estructuras de control PL/SQL: ayudan a controlar el comportamiento del bloque a medida que se va ejecutando, incluye órdenes condicionales y bucles, se combinan con variables y otorga flexibilidad a PL/SQL. Registros: semejantes a las estructuras del lenguaje C, provee de un mecanismo para manejar variables diferentes, pero relacionadas, como si fueran una unidad. Tablas y matrices: similares a las matrices del lenguaje C, se las maneja de la misma forma, pero su implementación es diferente, para poder declarar una tabla, se define su tipo. Cursores: la sentencia SELECT no debe devolver más de una fila, pero de ser necesario se usa un cursor para extraer individualmente cada fila.(Pérez, ORACLE 12c/11g/10g. Programación PL/SQL a través de ejemplos, 2015, pág. 31). 3.1.4.

Ingeniería de Software

3.1.4.1. Inicios de la Ingeniería de Software La ingeniería de software aparece en el informe de la conferencia de la OTAN en 1968, en la que mencionan un acuerdo general e indican que esta se encuentra en estado de

desarrollo superficial en comparación con otras ramas de la ingeniería establecidas; desde entonces ha evolucionado considerablemente en los últimos años.(Sánchez, Sicilia, & Rodríguez, 2012, pág. 16). 3.1.4.2. Conceptos Básicos de la Ingeniería de Software Esta trata principalmente con actividades que realizan las personas, y estas a su vez producen, usan, o modifican artefactos. Dichas actividades no son improvisadas, son parte de planes, métodos, especificaciones y modelos. Existe una terminología básica, como las actividades y artefactos, métodos especificaciones y modelos, y procesos y ciclos de vida. (Sánchez, Sicilia, & Rodríguez, 2012, pág. 19). 3.1.4.3. Actividades y Artefactos Las actividades hacen referencia a la forma en la que se desarrolla una actividad, esta sucede en un intervalo de tiempo determinado y se diferencia por los elementos que participan en dicha actividad, sintetizando se definiría a una actividad como un proceso que se presenta en un tiempo y espacio determinado y en el cual un agente actúa con unos objetivos determinados. Mientras que un artefacto se refiere a elementos que se crean en las actividades, tales como documentos, diagramas, etc. Resumiendo es algo palpable que es creado con un propósito práctico en las actividades que realiza una agente. Es importante diferenciar entre el resultado conceptual y el documento que se muestra, por tal motivo la realidad se concreta en términos de actividades de los participantes y los artefactos que utilizan, transforman o producen. (Sánchez, Sicilia, & Rodríguez, 2012, págs. 19-20). 3.1.4.4. Métodos, Especificaciones y Modelos. Un método es la especificación de una serie de acciones orientadas a cumplir un propósito, los métodos definen el orden y la forma de llevar a cabo las actividades; mientras que la metodología es un conjunto de métodos coherentes y relacionados por unos principios comunes. Una especificación es una descripción detallada y precisa de algo que existe o existirá, de una situación ya sea presente o futura. (Sánchez, Sicilia, & Rodríguez, 2012, pág. 21).

3.1.4.5. Procesos y Ciclos de Vida El ciclo de vida de un producto o proyecto de software es la evolución del este desde el inicio que aparece como idea hasta que el momento en el que deja de utilizarse, se puede describir de acuerdo a las actividades que se realizan dentro del mismo. Y un proceso software es un grupo congruente de políticas, estructuras organizativas, tecnologías, procedimiento y artefactos que se necesitan para concebir, desarrollar, implantar y mantener un producto software. (Sánchez, Sicilia, & Rodríguez, 2012, pág. 22). 3.1.5.

Metodología de Desarrollo

3.1.5.1. Modelo Cascada Este modelo es el mayor representante de los modelos predictivos en el mundo de la ingeniería de software, aunque en la actualidad sean pocos los desarrolladores que lo emplean. Se caracteriza por ser un modelo secuencial, es decir, no se avanza hacia la siguiente etapa hasta que se cumple totalmente la etapa anterior. Funciona adecuadamente cuando los requerimientos se detallan anticipadamente y no varían durante la etapa de desarrollo, igualmente si el equipo de trabajo tiene experiencias con proyectos similares y se cuenta con el tiempo necesario para cumplir cada una de las etapas secuencialmente. Otra característica que destaca es que sus etapas se pueden o no subdividir si se lo desea. (Stephens, 2015, págs. 270-271). 3.1.5.2. Manifiesto Ágil Se publica en el 2001 el manifiesto ágil, gracias a un conjunto de personas relevantes dentro del mundo del desarrollo de software y plasmaron ideas que se han convertido en fundamentales para desarrollar proyectos de una manera ágil, se fundamentan en cuatro puntos: Valorar a individuos y sus iteraciones: nada sustituye a las personas, a las cuales hay que dar toda la importancia y ponerlas en el primer plano. Valorar más el software (producto) que funciona: documentar el trabajo tiene tanta importancia como el trabajo: el producto. Valorar más la colaboración con el cliente: la forma más productiva para realizar un trabajo es obtener la confianza y colaboración de la persona que encarga dicho trabajo. Valorar más la respuesta al cambio: apreciar la incertidumbre como parte básica del trabajo,

19 por tal motivo la adaptación y flexibilidad no es una amenaza, sino una virtud.(Álvarez, de las Heras, & Lasa, 2012, pág. 21).

3.1.5.3. Metodologías Ágiles Gracias al manifiesto ágil las metodologías ágiles ha estado creciendo y extendiéndose, además de una sistematización y organización donde se ha creado organizaciones como la Agile Alliance internacional o en España la Agile-Spain. Se aplican en muchos campos estos métodos ágiles, algunos se concentran en la forma más productiva para el desarrollo de aplicaciones informáticas, en cambio otras reflejan procesos definidos por la empresa; esta influencia afecta la forma de realizar los proyectos para tener capacidad de adaptación y flexibilidad aplicada en relaciones formales entre empresas. De todas estas sobresale SCRUM por su difusión, es un método ampliamente utilizado y ha mostrado que se puede aplicar sin problemas en todo tipo de proyectos.(Álvarez, de las Heras, & Lasa, 2012, pág. 24).

3.1.5.4. Comparativa Métodos Ágiles y Métodos Tradicionales Son varias las características que diferencian claramente los Métodos Ágiles de los Métodos Tradicionales, y respecto al tema se han realizado varios estudios que muestran los puntos en que difieren. A continuación se presenta una comparativa que se expone en el artículo “Review of Agile Software DevelopmentMethodologies” de ManojWadhwa y NidhiSharma, que servirá de apoyo y sustento para la elección de una metodología determinada. Tabla 3: Comparativa Métodos Ágiles y Métodos Tradicionales TraditionalApproaches

Agile Approaches

Developers do waitinguntilthearchitectureisready

Thewholeteamisworking at thesame time ontheiteration. Goodcoordinationbetweenteammembers

Tooslowtoprovidefixestousser

Providequickrespondstouserfeedback

No communicationwithintheteam, novicesstay in theirrooms and try tounderstandthings.

High level of communication readinggroups, meetings.

Documents and neededtosolveanissue

5 minutes discussionmaysolvethe problema

reviewmeetings

are

and

interaction,

Everyis up front, everythingisbigbeforeyoustat

Thefocus i son whetercustomerrequirements are met in thecurrentiteration

Restricted Access toarchitecture

Thewholeteaminfluences and understandthearchitecture. Everybodywill be to do designpresentation.

20 In thistypetheenvironmentistaken as stable and predictable

In thistypetheenvironmentistaken difficulttopredict

turbulent

Sequential and synchronousprocess

Concurrent and asynchronousprocess

Optimizationisthegoal

Adaption, flexibility, responsivenessisthegoal

Itisnot flexible

Itis more flexible

and

Nota: Fuente: Wadhwa, M., &Sharma, N. (2015). Review of Agile Software DevelopmentMethodologies. Advances in ComputerScience and InformationTechnology, 2(4), 370-374. Obtenido de http://www.krishisanskriti.org/vol_image/04Jul201511075614%20%20%20%20%20%20%20%20Nidhi%20sharma%20%2 0%20%20%20%20%20%20%20%20%20%20%20%20%20%20370-374.pdf

La selección de una metodología ágil en el presente proyecto es apropiada porque otorga la posibilidad de adaptación a cambios por la flexibilidad que estas dan y permiten una forma de trabajo fluida y eficientemente en ambientes o proyectos donde los requerimientos son ambiguos o cambiantes, que necesitan un desarrollo de software veloz, para el cliente es una ventaja porque al ser una metodología incremental puede ver cómo avanza y evoluciona cada funcionalidad que requiere. 3.1.5.5. Scrum Scrum propone un entorno de trabajo donde se haya soporte a la innovación, con esta metodología se obtiene resultados con calidad y en cortas iteraciones que van entre una y cuatro semanas, las cuales se llaman Sprint; se basa en los siguientes principios: Inspección y adaptación: los Sprints son iteraciones que pueden durar como mínimo una semana y máximo cuatro, al finalizar cada iteración se entrega un producto terminado, por ejemplo un software que se pueda poner en producción, se enseña al cliente para que opine el cliente sobre este, después se reúne el equipo para analizar forma como se está trabajando, con dos puntos de vista: que se ha hecho y como se está construyendo, para mejorar en cada iteración.(Álvarez, de las Heras, & Lasa, 2012, pág. 39). Auto-organización y colaboración: El equipo es el único que gestiona y organiza al mismo, esta libertad conlleva una responsabilidad y un gran compromiso de todo el grupo, esta autoorganización funcionará siempre y cuando haya colaboración y espíritu de equipo. Los líderes y clientes colaboran de igual manera con el equipo de desarrollo para ayudar a su trabajo, resolver inquietudes y así suprimir posibles inconvenientes o dificultades.(Álvarez, de las Heras, & Lasa, 2012, pág. 39).

Priorización: es clave no perder tiempo y dinero en algo que no importa inmediatamente para el producto, por esto se debe priorizar los requisitos para reflejar el valor del negocio. Mantener un latido: es muy preciado mantener un ritmo para optimizar el trabajo, a nivel del

21 día a día así como a nivel del Sprint; esto permite que el equipo sea predecible al mismo tiempo que aprenderá a estimar la cantidad de trabajo que puede comprometerse. Una de las principales características de Scrum es que en cada iteración se realiza planificación, análisis, creación, y comprobación de lo que se entregará al final del Sprint.(Álvarez, de las Heras, & Lasa, 2012, pág. 39).

Roles en el equipo: los roles representan una responsabilidad en el proceso y no dentro de la organización. ProductOwner: es el dueño del producto, el responsable desde la visión del negocio. Scrum Master: es el responsable de que el equipo sea productivo y asistiéndolo en todo momento para cumplir el objetivo y garantizar que se acate los principios de Scrum. Equipo: encargados de la construcción el producto. Artefactos: los Backlog es el artefacto donde anotan los requerimientos y tareas, el ProductOwner, equipo y Scrum Master. El Burndown Chart es una gráfica en la que se presenta el progreso del avance del proyecto para esto se puede usar una pizarra, un archivo de Excel, o alguna herramienta que permita graficar. ProductBacklog: donde contiene todos los requisitos del cliente priorizados y estimado, y el propietario de este es el ProductOwner, aunque todos los artefactos se deben orientar; está escrito en lenguaje de lenguaje de negocio y hay que revisar las priorización antes de empezar cada Sprint. Sprint Backlog: es la elección de requerimientos del ProductBacklog para el Sprint y que se ha separado en tareas por el equipo para manifestar los requerimientos del cliente en un lenguaje técnico, es propiedad del equipo. Burndown Chart: es una gráfica presenta el trabajo pendiente del equipo, hay dos tipos de gráficas destacadas, la que está vinculada con el Sprint y la que esta enlazada con la totalidad del proyecto. Reuniones en Scrum: se aconseja una duración de quince a diez minutos para el Daily Meeting, mientras que para las demás reuniones se recomienda una hora por semana como en el caso del Sprint Planning, Sprint Review y Retrospective, estableciendo límites de tiempo para optimizar el contenido y no divagar. Planificación del Sprint (Sprint Planning): En esta reunión se planifica el Sprint, y al

finalizar esta se debe un objetivo claro y compartido sobre el trabajo que hay que realizar para la siguiente iteración y con un Sprint Backlog apropiado. La Reunión Diaria (Daily Meeting): “es la situación donde se sincroniza el equipo, cada miembro habla acerca del estado que se encuentra el trabajo que está elaborando”. (Álvarez, de las Heras, & Lasa, 2012, pág. 41).

Revisión del Sprint (Sprint Review): al terminar el Sprint, el equipo analiza el estado del trabajo con el ProductOwner y con cualquier persona que pueda contribuir con información útil, no se debe invertir mucho tiempo, se la debe realizar informalmente; es la oportunidad de mejorar la manera en la que se está construyendo. Retrospectiva del equipo: luego de la Review, el equipo se agrupa para buscar la mejora continua en su trabajo y examinar aspectos que impiden mejorar el rendimiento, es el lugar para analizar cómo mejorar lo que estamos trabajando.(Álvarez, de las Heras, & Lasa, 2012, pág. 41).

3.1.5.6. XP Extreme Programming (XP) o Programación Extrema es un método ágil que permite desarrollar software cuando los requerimientos son cambiantes, por este motivo, es un método que se adapta muy bien a los cambios, permitiendo añadir nuevos requisitos o funcionalidades al proyecto sin que estas nuevas incorporaciones impacten en la calidad. El desarrollo de proyectos aplicando esta metodología se realiza con equipos de trabajos pequeños o medianos. Bajo la modalidad de trabajo de XP se consigue resultados rápidos del producto final.(Álvarez, de las Heras, & Lasa, 2012, pág. 49) Ésta metodología promueve el trabajo en equipo, el cual es la parte fundamental en el desarrollo de un proyecto, consiguiendo que todos los miembros del equipo de desarrollo se sientan a gusto en un buen ambiente de trabajo. Otras características importantes de XP son la colaboración y comunicación continua que se tiene con el cliente (retroalimentación), la simplicidad en el diseño y desarrollo del producto, establecer buenas relaciones interpersonales y la aceptación de los cambios.(Brito, Dailyn, & Héctor, 2015, pág. 15) La forma de trabajo en XP es a través de iteraciones y la entrega del producto se realiza por medio de incrementos. Generalmente las iteraciones son pequeñas y

frecuentemente se realizan en colaboración con el cliente, de este modo se consigue que el producto que se vaya entregando satisfaga las necesidades y especificaciones del cliente. Al comenzar cada iteración se planifica el trabajo que se va a realizar, después, las actividades de análisis, diseño, desarrollo y pruebas se realizan de forma simultánea. (Álvarez, de las Heras, & Lasa, 2012, págs. 49-50). 3.1.5.7. Comparativa entre métodos ágiles Los métodos ágiles son similares en varios aspectos dado que se basan y comparten los principios del manifiesto ágil. Las diferencias que surgen entre una y otra metodología ágil radican en las prácticas que cada una manejan. Existen varios estudios acerca de la comparativa entre métodos ágiles que se han realizado actualmente, a continuación se presenta una tabla comparativa que se muestra en el artículo “EmpiricalStudy of Agile Software DevelopmentMethodologies: A ComparativeAnalysis”. Tabla 4: Comparativa entre métodos ágiles Parameters

ScrumbasedDevelopment

Extreme Programming (XP)

KanbanMethodology

DesignPrincipl e

ComplexDesign

Simplification of Code&Accommodaton of unexpectedChangesthroughRe factoring

Limitstheamount of WorkinProgress&ensuresWasteR eduction

Nature of CustomerIntera ction

Notcompulsorilyon-site

On-siteCustomerInteraction

Notcompulsorilyon-sit

DesignComple xity

Complexdesign

Simple design

Simple visual design

Project Coordinator

Scrum Master

XP Coach

TeamWork

Roles Assigned

3 Pre-defined roles: ProductOwner, Scrum Master &DevelopmentTeam

No prescribed roles

ProcessOwners hip

Scrum Master

Teamownership

ProductOwners hip

ProductOwnerisresponsiblef orproduct

Groupresponsibility of product

TeamCollabora tion

Cross functionalteams

Selforganizingteams

Teamcomprises of specialized

24 resources

WorkflowAppr oach

Iterations (sprints)

No iterations. Taskflowdevelop

Short iterations

Requirements Management

RequirementsManaged in form of artifactsthrough Sprint Backlog&ProductBacklog

Managed in form of StoryCards

ManagedusingKanbanBoar ds

ProductDeliver y

Delivery as per Time boxedsprints

ContinuousDelivery

Continuousdelivery

CodingStandar ds

No codingstandards

Codingstandards are used

No codingstandards

TestingApproa ch

No formal approachusedfortesting

Test drivendevelopment, includingacceptancetesting

Testing done afterimplementation of eachworkproduct

Accommodatio n of

Amenabletochangeeven in later

Changesnotallowed in sprints

Changes

Changesallowed at any time

stages of development

Nota: Fuente: Matharu, G., Mishra, A., Singh, H., & Upadhyay, P. (2015). Empirical Study of Agile Software Development Methodologies:

Comparative

Analysis.

ACM

SIGSOFT

Software

Engineering

Notes,

40(1).

doi:10.1145/2693208.2693233

Se ha seleccionado la metodología de desarrolloScrum dado que es una metodología ágil, que permite una adaptación a cambios en los requerimientos o la implementación de nuevos

requerimientos

construcción

software,

también

permite

gestionarapropiadamente el desarrollo de un proyecto, provee un trabajo colaborativo y multifuncional entre los miembros del equipo. 3.1.6.

Aplicaciones Web

3.1.6.1. Lenguaje de etiquetado (HTML) El lenguaje de marcas HTML permite que el navegador interprete una estructura para ser mostrada el contenido que quiere ser mostrado, y hace uso de archivos con extensión .html o .htm estos se escriben en texto plano, como tal la idea es mostrar texto, HTML significa Hyper Text MarkupLanguage, en español lenguaje de marcado de híper texto y sirve para describir contenido, estructura las páginas web. (Zofío, 2013, pág. 19).

3.1.6.2. Hojas de estilos (CSS) CSS en español significa hojas de estilo en cascada, aparece para dar estilo a los elementos del HTML, dado que este solo muestra texto y genera una estructura, hay que dotarle de estilo y formato al contenido del HTML por medio de CSS y así se separa la parte visual del contenido mostrado en una página web. (Zofío, 2013, pág. 40). 3.1.6.3. Lenguaje de script de navegador (JAVASCRIPT) Es un lenguaje de programación interpretado, por eso no se compila para su ejecución, el mismo navegador interpreta al cargar el HTML junto con los archivos CSS, esta integración permite una mejor y mayor funcionalidad a las páginas web y mejorar bastante la interacción que tiene el usuario al acceso a los sitios en línea, junto con este lenguaje han aparecido tecnología (librerías) que dan la posibilidad de dinámica del contenido así como la interacción del usuario en el uso de aplicaciones web. (Zofío, 2013, pág. 53). 3.1.6.4. Desarrollo de aplicaciones web Gracias a la aparición del internet se crearon infinidades de posibilidades de acceso desde cualquier página web, y esto significaba un desafío para los desarrolladores de aplicaciones, los avances tecnológicos permitieron el desarrollo de aplicaciones rápidas, ligeras y robustas para el uso en red. La arquitectura cliente – servidor, existe una aplicación cliente que es la interfaz con la que interactúa el cliente, cuando se hacen cambios hay que realizar la actualizaciones en estas, pero con las aplicaciones web el usuario no necesita actualizar o hacer algún cambio cuando quiera actualizar la aplicación.(Zofío, 2013, pág. 8). La generación de aplicaciones web representa la repetitiva ejecución de aplicaciones y esto involucra estructuras de información, generación de diferentes componentes y tareas de despliegue y puesta a punto de las aplicaciones. (Daza, Parra, & Espinosa, 2016, pág. 26). 3.1.6.5. Arquitectura Cliente Servidor Se identifica tres tipos de capas fundamentales que son las siguientes: capa de presentación, capa de la lógica de negocio y capa de persistencia (almacenamiento de datos). Estos modelos arquitectónicos de programación se dividen en función de la ubicación de donde se ejecutarán:

Capa de presentación: Encargada de la presentación que se da al usuario y con la que el mismo interactúa, en la mayoría de los casos se ubica en el cliente, se centra en el formateo de la información que se presenta al usuario, también captura sus acciones. Capa de negocio: esta conoce y administra las funcionalidades del sistema o aplicación web (lógica, reglas de negocio), recibe las solicitudes del usuario y también desde ahí responde apropiadamente con la información procesadamente previamente, se la puede programar en el lado del servidor, así como en el lado del cliente. Capa de persistencia o de datos: aquí residen los datos y se encarga de acceder a estos, generalmente está formada ya sea por uno o más sistemas gestores de base de datos, los cuales realizan las administración de los datos, reciben las solicitudes tanto para el almacenamiento como para la recuperación de datos. (López, y otros, 2014, pág. 15). 3.1.6.6. Programación en el servidor Un lenguaje de programación en el lado del servidor es ejecutado ya sea pre compilado o interpretado en el servidor, existen varias alternativas para implementar y ejecutar en el lado del servidor, una de estas es el uso de los lenguajes de scripting como: PHP, ASP, Per, JSP, Python, etc. Sus características es que es interpretado y se fusiona con el código HTML. Hablando específicamente de Python, es un lenguaje multiplataforma y orientado a objetos, se lo usa para realizar cualquier tipo de aplicaciones desde aplicaciones de escritorio hasta aplicaciones web, ofrece ventas como rapidez en el desarrollo, se ha hecho muy popular en la actualidad por la cantidad de librerías, tipos de datos, funciones incorporadas así se genera programas con sencillez y velocidad, además es un lenguaje libre, no hay necesidad de ningún software de pago adicional como construir software, incluso para el ámbito empresarial. (López, y otros, 2014, págs. 17 - 18). 3.1.7.

Marco de referencia (Framework)

3.1.7.1. Características de un Framework Los lenguajes de programación para el servidor han ido adquiriendo tecnologías particulares para permitir simplicidad en el desarrollo determinadas tareas que son comunes entre las aplicaciones web, como por ejemplo l manejo de usuarios y sus controles correspondientes, o el motor de plantillas para la generación de vistas, asegurando llevar una

programación orientada a objetos, por tal motivo casi todos los lenguajes de programación han desarrollado librerías para realizar estas tareas que son generales, así es como aparecen los Frameworks, que incorporan funciones, librerías y en algunos casos estructuras o patrones de desarrollos como el MVC. El conjunto estándar de conceptos y tecnologías que dan un soporte definido, habitualmente se emplea para esto una serie de módulos, estos facilitan organizar y desarrollar software, generalmente los Frameworks soportan bibliotecas de uno o más lenguajes, por ejemplo en el desarrollo web es común manejar un lenguaje de programación base en el lado del servidor y tener un motor de plantillas que maneja los archivos HTML junto con este lenguaje para ofrecer contenido dinámico. Así es como facilitan el desarrollo, agrupación y organización de componentes de cualquier proyecto. (López, y otros, 2014, pág. 236). 3.1.7.2. Frameworks Web Para el desarrollo de aplicaciones web complejas, los Frameworks web nos ofrecen diversas herramientas para facilitar el desarrollo, no solo agilizando este sino el mantenimiento, actualmente es fácil encontrar para cada lenguaje estos Frameworks, unos de los más conocidos y utilizado en Python es Django que ayudan a no solo desarrollar ágilmente las aplicaciones, si no que asegura que se use una orientación a objetos, y se use patrones eficientes en la arquitectura. (Fernández, 2013, pág. 215). 3.1.8.

Esquema Modelo – Vista – Controlador (MVC)

3.1.8.1. Modelo de separación lógico En contraste con los modelos físicos cuando nos referimos al modelo arquitectónico lógico o la arquitectura lógica de los sistemas de información como la manera de dividir el software para obtener un mejor desempeño del sistema, uno de los mejores arquitecturas para el desarrollo de páginas web es el uso de arquitecturas en capas, esta división no implica que cada capa se ejecute en diferentes equipos. Una de las ventajas de usar esta arquitectura es: desarrollar las capas al mismo tiempo, aplicaciones más robustas por el encapsulamiento, mantenimiento y soporte más simple, mayor flexibilidad y asegura la escalabilidad. (López, y otros, 2014, pág. 96). 3.1.8.2. Modelo – Vista – Controlador

Es uno de los esquemas más seguidos e implementados en la construcción de software, busca separar una aplicación en tres componentes principales: Modelo: en esta parte se implementa la lógica de la aplicación, es la representación de la información con la que opera, generalmente devuelven y almacenan el estado del modelo en una base de datos. Vista: despliega la interfaz de usuario, y esta interfaz es construida de acuerdo al modelo de datos, en el caso de aplicaciones web se construye por el conjunto de páginas web que muestran y recogen la información que se muestra al usuario. Controlador: maneja la interacciónrealizada con el usuario, trabaja en conjunto con el modelo y selecciona la vista para mostrar la información.(López, y otros, 2014, pág. 96). 3.1.9.

Gestión de Inventario

3.1.9.1. Inventario En las empresas tiene un papel muy importante los inventarios porque son indispensables en los procesos productivos, en estos se ve reflejada parte de la inversión de la empresa, y por tales motivos tener un control de inventario es un factor determinante para el éxito de una institución. (García, 2014, pág. 274). 3.1.9.2. Concepto de Inventario El término inventario se usa para ser relacionado con una lista de bienes materiales, así como los intangibles; tales como derechos ya sean a las personas o la comunidad hechos en orden y precisión. (García, 2014, pág. 274). 3.1.9.3. Administración de Inventarios La administración de inventarios es un conjunto de técnicas y procedimientos que tienen como finalidad establecer y mantener cantidades de favorables de bienes de cualquier tipo, de esta forma se minimizan costos y se contribuye a que la empresa u organización cumplan con sus objetivos. (García, 2014, pág. 274). 3.1.9.4. Importancia de la Administración de Inventarios La importancia de esto permite tener un eficaz control sobre los inventarios y se basa

en las siguientes ideas: Es esencial para mejorar el servicio que se brinda a los clientes. Sin este control, no se puede producir el máximo de eficiencia. El costo del mantenimiento de inventarios depende de la pericia que se controlen. “Una estimación del costo del mantenimiento que oscila entre un diez y un veinte y cinco por ciento del valor de los inventarios de la empresa, también depende de las condiciones especiales que tienen las empresas”. (García, 2014, pág. 274). 3.1.9.5. Clasificación de los Inventarios Los inventarios comúnmente siguen la siguiente forma: Materias primas: es toda clase de materiales comprados por el fabricante, que serán sujetos a procesos de manufactura o alteración físico y/o químico, previamente a ser comercializados. Producción en Proceso: Aquellos en los que ya se han realizado transformaciones, pero los cuales todavía necesitan otras operaciones para quedar finalizados. Productos Terminados: Son los que fueron sometidos a los tratamientos necesarios y cubren los requisitos de calidad para destinarlos a la comercialización. Otros Inventarios: Los cuales son necesarios para el funcionamiento y conservación tanto en la fábrica como en las oficinas. Generalmente son aquellos artículos que no forman parte del producto transformado en forma directa, pero son indispensables para la empresa o institución. (García, 2014, págs. 274 - 275). 3.1.10. Depreciaciones Los activos fijos como edificios, muebles, equipos, etc. Pierden valor ya sea por el uso o por obsolescencia, por tal motivo se reduce su potencial de servicio; el proceso de establecer Gasto a el Costo de un activo fijo durante el tiempo que se utiliza el activo se le conoce como depreciación. Los porcentajes de depreciación son los siguientes:

Para inmuebles con excepción de los terrenos tiene un 5% anual. Para Instalaciones, equipo y muebles posee el 10% anual. Para toda clase de vehículos y transporte un 20% anual. Para los equipos de cómputo y software tiene 33% anual. Por esta razón es importante darle mantenimientos a los bienes para prolongar lo mejor posible su vida útil productividad que es el periodo de tiempo en el que el activo aporta a los ingresos. (Bravo, 2011, págs. 170 - 171). 3.1.11. Mantenimiento 3.1.11.1. Concepto de Mantenimiento El mantenimiento representa una inversión dentro de un periodo de tiempo mediano o largo esto origina ganancias no solo para la empresa o institución, si no que se verán ganancias y aumento de la producción, también se origina un ahorro que equivale a tener trabajadores o empleados sanos y los registros de accidentes bajarán. El mantenimiento se puede dividir en dos grandes grupos: Mantenimientos Preventivos

y Mantenimientos

Correctivos. (Velásquez & Custodio, 2011, pág. 104). 3.1.11.2. Gestión del Mantenimiento En la gestión de mantenimientos se diferencias dos actividades fundamentales que son: Mantenimiento Preventivo y Mantenimiento Correctivo; el primero, mantenimiento preventivo está compuesto por una serie de controles periódicos de los equipos, realizando varias tareas como limpieza, ajuste, comprobación, o reemplazo de partes para mantener funcionando correctamente un equipo, y tener un estado óptimo de funcionamiento. Mientras que el Mantenimiento Correctivo se lo realiza en un equipo para restaurar restablecer el estado operacional después que se presenta una falla; este tipo de mantenimiento no es planificado y se lo realiza cuando existe un reporte de esto por parte del personal que hace uso del equipo. (Primero, Diaz, García, & González-Vargas, 2015, pág. 82). 3.1.12. Mantenimiento Preventivo 3.1.12.1. Concepto de Mantenimiento Preventivo

El mantenimiento preventivo resulta innovador tomando una visión tradicional, en la actualidad todavía sigue muy generalizada, con una idea orientada a tener a los mantenimientos como elementos apartados, y no como un componente que es parte de una totalidad con una actividad que realizar. (Rey, 2014, pág. 31). 3.1.12.2. Plan de Mantenimiento Preventivo Esto permite definir la estrategia del mantenimiento más apropiado para ser usadas sobre los equipos, en diferencia a no aplicar el plan. Se puede encontrar los fallos juzgados como graves definiendo: el tipo de mantenimiento que se realizará, el contenido y la descripción de las tareas, la frecuencia o intervalos entre los mantenimientos. (Rey, 2014, pág. 31). 3.1.13. Mantenimiento Correctivo En la actualidad se usa el mantenimiento en componentes considerados como cruciales en el funcionamiento del sistema, y se descuida hasta que aparecen fallas en componentes no críticos, ese momento es cuando se aplica el mantenimiento correctivo sobre el equipo para volver a darle funcionalidad lo más rápido posible.(Rey, 2014, pág. 31). Para todos los mantenimientos correctivos que son aplicados es imprescindible definir un plan de actividades para corregir la falla que se presente, además de designar un responsable que lleve a cabo el mantenimiento correctivo necesario para el equipo que lo necesite en un periodo corto de tiempo, esto es parte del seguimiento que se debe realizar. (Rey, 2014, pág. 39). 3.1.14. Normativa de los Bienes Según las Normas de Control Interno de la Contraloría General del Estado en la sección de Administración Financiera sobre el Almacenamiento y distribución dice: Los bienes ingresarán físicamente a través de

almacén o bodega, antes de ser

utilizados. El Sistema de registro indica: Se debe permitir el control, identificación, destino y ubicación de las existencias y los bienes de larga duración, para controlar los retiros, traspasos o bajas de los bienes.

Para la Identificación y protección menciona: Permitir una fácil identificación, organización y protección de las existencias de suministro y bienes de larga duración, así como el control, localización e identificación. En cuanto a la Custodia habla de: La entidad a través de la unidad respectiva, designa la custodia de los bienes; aquellos bienes que son utilizados por varias personas, será responsabilidad del Jefe de la Unidad Administrativa definir su custodia. En el apartado de Baja de bienes por obsolescencia, pérdida, robo o hurto nos dice: Los bienes que por diversas causas han perdido utilidad para la entidad o hayan sido motivo de pérdida, robo o hurto, serán dados de baja de manera oportuna. (Contraloría General del Estado, 2009).

4. 4.1.

METODOLOGÍA DE LA INVESTIGACIÓN

Diseño/Tipo de investigación El trabajo de investigación hará uso de un enfoque mixto para resolver la

problemática, donde se usará el método cuantitativo para basarse en los resultados obtenidos de las encuestas y posteriormente el método cualitativo que permite interpretar dichos resultados, las técnicas para la recolección de datos fueron la observación, encuesta y la entrevista con su respectivo tipo de investigación: exploratoria, aplicada y descriptiva. El diseño de investigación que se realizará será el no experimental con la finalidad de no realizar manipulaciones con las variables, para así poder estudiarlas naturalmente como se presentan y para su desarrollo se hará uso de los tipos de investigación como: Investigación exploratoria: al principio se la utiliza, porquese asiste a la institución donde se obtiene toda la información directamente de la persona experta en el proceso, esta es la que conoce y lo lleva a cabo, así se recopila la información necesaria, requerimientos para desarrollar de forma correcta en el sistema. Investigación aplicada: por el motivo que no solo se desarrolla el sistema, sino que al finalizar el proyecto se implementa dicho sistema que agilizará el proceso del control del mantenimiento preventivo y correctivo de los bienes para así mejor la productividad del personal de la institución. Investigación descriptiva: este tipo de investigación facilita la especificación de características, propiedades y atributos más relevantes de cualquier tipo de fenómeno que se desee analizar, así da la posibilidad de recoger, comprobar y estudiar los datos obtenidos del problema del control del mantenimiento preventivo y correctivo de los bienes como el inventario de los mismo y el registro de los mantenimientos, así se busca depurar el proceso que se lleva manualmente.

4.2.

Población/Universo

4.2.1.

Población La población está conformada por el departamento de bienes, y en total se trabajará

con 3 personas, las cuales serán la población con la cual se obtendrá toda la información necesaria para el proyecto. 4.2.2.

Muestra De acuerdo a lo dicho anteriormente tenemos una población muy pequeña para lo cual

es procedente que la muestra se trabaje con el cien por ciento de la población, esto representa una ventaja porque evita que la presencia de un sesgo al escoger una muestra.

4.3.

Técnicas e Instrumentos de Recogida de datos

4.3.1.

Técnicas Estas permiten determinar que requerimientos son importantes para la solución del

problema mediante la recolección de datos. De todos los tipos de técnicas para recolección de datos, en este trabajo se usará estas: La encuesta la cual se basa de un cuestionario de acuerdo a la información que se desea obtener de las personas que conforman la muestra, en este caso también es la población. La entrevista permite obtener información directamente con las personas que usarán el sistema y las cuales conocen el proceso que se automatizará. La observación no estructurada proporciona reconocimiento y anotación de datos, en base a normas generales, aquí se pudo comprobar cómo se lleva el proceso del control del mantenimiento de los bienes el cual es el problema de investigación. 4.3.2.

Instrumento El instrumento que se utilizará será el cuestionario tanto para la entrevista como para

la encuesta.

El cuestionario se formuló de 8 preguntas las cuales se las aplica al departamento de bienes y otro cuestionario de 5 preguntas para el departamento de sistemas del Cuerpo de Bomberos de Santo Domingo.

4.4.

Metodología de desarrollo de software

4.4.1.

SCRUM Es una metodología de desarrollo de software ágil, con un enfoque iterativo

incremental y dispuesta a cualquier modificación, donde un cambio es considerado una oportunidad de mejorar, el cliente es parte del proceso y tiene que estar comprometido con el objetivo; iterativa, que favorece al cambio y a la satisfacción del cliente y su base son principios de inspección y adaptación. Para controlar el proceso tiene puntos claves: La transparencia, significa que el equipo tiene que ser honesto, en otras palabras debe compartir las dificultades y aportar para que se desarrolle de la mejor manera posible. La inspección es frecuentemente revisada para encontrar oportunidades de mejora. La adaptación permite que se acuerde con el equipo aplicar cambio para mejorar cada sprint, así se adapta al cliente y al equipo de trabajo. (Álvarez, de las Heras, & Lasa, 2012, págs. 58 - 62). 4.4.2.

Componentes de SCRUM Los eventos: actividades que se realizan dentro del ciclo principal de SCRUM,

llamado Sprint que involucran seis actividades (Sprint Planning, Sprint Execution, Daily Meeting, Sprint Review, Sprint Retrospective, Refinement), estas se repiten hasta dentro de cada sprint hasta finalizar el producto. Se reconocen tres roles: Scrum Master encargado que la metodología de desarrollo de software se desarrolle correctamente. ProductOwner responsable de definir qué se debe hacer del producto para que sea de valor a la organización y al equipo de desarrollo.

DevelopmentTeam es el Equipo de Desarrollo, un grupo de personas de diferentes áreas que trabajan en conjunto para el desarrollo del producto. ParaSCRUM existen tres artefactos: El ProductBacklog que es una lista de funcionalidades que va a tener el producto. El Sprint Backlog es una lista de tareas a desarrollar por sprint. El ProductIncrement, es un producto con nuevas funcionalidades, y que puede ser puesto en producción.(Álvarez, de las Heras, & Lasa, 2012, págs. 63 - 68). 4.4.3.

Proceso de SCRUM Se alimenta de una reunión, donde se reúne a las personas con experiencia en el

producto que se quiere desarrollar y define sus características de aquí sale dos elementos: El ProductOwner, es una persona que queda emporada por la organización para tomar las decisiones que se crea conveniente y debe tener clara la visión de lo que el producto aportara a la organización. El ProductBacklog es la lista de características del producto. El primer evento se crea es el Sprint Planning se divide en dos partes: El Refinement (refinamiento) se toma las características que se tiene del producto y detallarlas de manera que sea clara para el equipo de trabajo. El Tasking divide las características en tareas para el equipo. Después de este Sprint Planning sale el Sprint Backlog que es la cantidad de tareas que se realizaran para el tiempo definido para el sprint, a esto se compromete el equipo, debe estar dentro del margen de tiempo de dicho Sprint y la persona que define este tiempo es el cliente de esta manera sabe cada cuanto va a recibir un incremento al producto. Ahora con este compromiso se pasa al desarrollo, o ejecución del sprint que tiene una duración máxima de cuatro semanas, si se pasa de este tiempo, deja de ser SCRUM. Para revisar el avance se realiza el DailyMeeting es una reunión diaria con una

duraciónmáxima de 15 minutos, donde se habla lo que se ha hecho desde el día anterior, dificultades que se han presentado y lo que se hará antes de la próximareunión, así se mantiene al Scrum Master informado y puede llevar un control de los avances de cada tarea del Sprint Backlog. En general la ejecución del sprint tiene como objetivo desarrollar un ProductIncrement (incremento al producto), en otras palabras es lo que ya está desarrollado más la parte que se está desarrollando en el Sprint actual, cada incremento es funcional, un software que pueda ser puesto en producción Ahora con el incremento, tenemos el Sprint Review que su objetivo es verificar el avance que se ha tenido en el desarrollo, indicar lo que falta por cumplir, que es lo que se hará a continuación y en algunas veces definir si pasa a producción; es importante invitar a la reunión a todos los interesados en el producto a cualquier comentario. Sprint Retrospective (retrospectiva) es el evento final de SCRUM, aquí se revisa el desempeño del equipo en la metodología, la guía el Scrum Master y busca verificar que es lo que se ha hecho bien, que no se debe seguir haciendo y que se debe mejorar de lo que se ha hecho. El Refinement (refinamiento) se lo puede realizar en cualquier momento, bajo la administración del ProductOwner y este consiste en aclarar inquietudes de funcionalidades esperadas, incluir nuevas funcionalidades, temas técnicos, quitar funcionalidades que ya no se apliquen, entre otros.(Álvarez, de las Heras, & Lasa, 2012, págs. 70 - 76). 4.4.4.

Eventos de SCRUM Antes de empezar se realizar un ReleasePlanning, es la primera reunión que hace el

ProductOwner con las personas funcionales que tienen las características que debe tener el producto y como se van modificando estas con el proceso, y cada evento tiene una duración fija, si algo sale mal en el Sprint se buscan oportunidades de mejoras y no a responsables; una vez iniciado el Sprint, su duración no puede ser modificada, porque el mismo equipo ya sabe cómo estimar el tiempo que se demorará, el ProductBacklog se expresa en forma de historias de usuario. Sprint Planning: Es una reunión que tiene dos partes: el refinamiento que trata de

tomar el ProductBacklog que trae el ProductOwner y entender el objetivo, él porque, detallar aquellos que no están claros para el equipo de trabajo. La duración es de ocho horas para un Sprint de un mes, y así proporcionalmente. El Tasking se hace sobre las actividades o funcionalidades que se considera que se alcanza a desarrollar en el tiempo definido para el Sprint, se toma las funcionalidades, se las divide en tareas, estas a su vez se estiman y en base a esto se logra el Sprint Backlog, es el compromiso del incremento al producto que tendremos al final del Sprint por lo general se usa una técnica de estimación llamada PlanningPoker, se usa sobre el ProductBacklog donde se dan puntos a las características y funcionalidades, consiste el escoger el que menos trabajo conlleva, se lo puntúa y a partir de este comparar y puntuar las otras funcionalidades, se atiende por prioridades. También debe revisarse una o dos características adicionales para el caso de finalizar el desarrollo antes de tiempo, solo si queda tiempo del establecido. Después de realizar el Sprint Backlog nos da un resultado, que es la velocidad del equipo, cuántos puntos del ProductBacklog estimamos mediante la técnica del PlanningPoker es nuestra velocidad; también depende de la cantidad e integrantes del equipo y esto puede variar entre los Sprint, nos da un marco de trabajo, para los próximos Sprint Planning tengamos certeza de cuantas funcionalidades debemos estimar o dividir en tareas. La Planificacióndebe contener los demás eventos involucrados, con el compromiso del Sprint Backlog, no se puede asumir que el equipo va a estar trabajando cien por ciento en las actividades, ya que debe tener otras actividades o proyectos que están trabajando, tiempo personal. Las actividades no pueden pasar de ocho horas, de ser el caso se debe dividir de acuerdo a la consideración del equipo, y estar de acuerdo con lo que se definió en el Sprint Backlog, porque es el compromiso de entrega al final del Sprint, es importante aclarar el concepto de terminado, y cuando se considera así una actividad. Daily Meeting: son reuniones que se deben realizar diariamente y tienen una duración de quince minutos, aquí se resuelven las siguientes preguntas por cada miembro del equipo de desarrollo: ¿Qué se he hecho desde la última reunión? ¿Qué inconveniente he tenido o existe algún riesgo a revisar?

¿Qué planeo hacer antes de la próxima reunión? Estas preguntas están relacionadas a la transparencia, para contar el avance al equipo, y se puede realizar sin la presencia del ProductOwner o el Scrum Master, pero siempre se debe realizar Sprint Execution: aquí los objetivos de calidad no se degradan, el software que se entrega debe ser de calidad, y va a pasar a producción, las deudas técnicas se documentan para incluirlas en el ProductBacklog por agilitar la construcción del software podemos dejar o pasar por alto algunas cosas que se puedan mejorar, esto debe quedar registrado en el ProductBacklogy con el visto bueno del ProductOwner para más adelante se atiendan, no se realiza cambios que puedan comprometer riesgo del alcance del Sprint, porque este es el que da la pauta de lo que se entrega, si se incluye tareas que no estaban consideradas en el Sprint no se puede hacer, sin autorización del ProductOwner. El Refinement se puede realizar en cualquier momento, a pesar de que en la reunión del Sprint Planning se hace algo de refinamiento, lo mismo pasa en la construcción, porque es ahí donde salen más dudas, por lo tanto se puede

hacer pequeñas reuniones con el fin de

atender inquietudes adicionales que aparecen en el proceso de desarrollo. Se recomienda usar técnicas como el Burn Down Chart para medir el desempeño, esto lo realiza el Scrum Master para verifica como avanza el equipo de desarrollo y el Tablero Kanban para controlar tareas y tiene tres columnas, en la cual consta de lo que está por hacer, lo que se está haciendo y lo que está terminado. Todas las tareas parten de lo que está por hacerse y cuando la finaliza la pasa a la columna de terminado. Solo el ProductOwner puede cancelar un Sprint, así el equipo vea que no va a alcanzar a realizar el Sprint, no se cancela, y solo se aborta si el producto ya no se quiera construir, el alcance del Sprint puede ser renegociado con el ProductOwner a pesar de haber comenzado el Sprint, si hay tareas que se comprometieron a entregar, pasen para el siguiente Sprint Sprint Review: básicamente es una reunión donde se revisa las funcionalidades que se desarrollaron en el Sprint a los involucrados, se les explica que elemento del ProductBacklogfueron terminados, muestra lo que se comprometió en el Sprint Planning se hizo y fue marcado como terminado, queda abierto a opiniones frente a lo desarrollado, y pueden hacer cualquier tipo de comentario de mejora o eliminar cosas, porque la metodología

lo permite; el ProductOwner evalúa los comentarios para ver si se incorporan en el ProductBacklog. Se realiza una preparación previa para organizar quien presenta cada cosa, como se presentará, cual es el orden, etc. Con el objetivo de llevar la reunión de la mejor manera para mostrar el avance y con que se va a continuar, aquí se invita a los principales interesados como aquellos que participaron al comienzo, el levantamiento del ProductBacklog, así como aquellos que creemos que pueden aportar en el software. Es importante que todo el equipo de trabajo esté presente, para que cada integrante del equipo esté enterado de los comentarios, oportunidades de mejora o defectos que encuentran las personas en el producto entregado. El ProductBacklog puede afectarse por decisión del ProductOwner para incluirlos y así hacer cambios sobre el software, aparte de mostrar lo que se hizo, también se muestra que falta por hacer y lo que se mostrará en la próxima reunión de revisión para crear expectativa en los interesados, y vean que la metodología tiene un buen avance con respecto al desarrollo de las funcionalidades. Sprint Retrospective: su objetivo es revisar el desempeño del proceso SCRUM en cuanto a individuos, relaciones, eventos y herramientas; verifica el proceso, como se hizo el trabajo, si se realizaron todos los eventos en el tiempo que debieron hacerse e identifica las áreas de mejoras, crear un plan para la integración de dichas mejoras. Esta reunión los integrantes deben contestar a tres preguntas: ¿Qué hemos hecho bien del proceso de SCRUM? ¿Qué debemos mejorar? ¿Qué no debemos seguir haciendo? Estas preguntas están alineadas a los tres objetivos: Revisar el desempeño. Identificar las áreas de mejoras. Crear un plan. También se revisa cual fue el resultado obtenido, si el plan estuvo acorde al

resultado o debe revisarse el proceso de estimación. Es la principal actividad para el proceso de inspección y adaptación, estas son parte fundamental del proceso de SCRUM, y su principal actividad la revisión del proceso y la autoevaluación, para responder a estas preguntas cada persona debe autoevaluarse como cree que fue su desempeño en el proceso. Su duración debe de ser de tres horas para un Sprint de un mes, y así proporcionalmente. Refinement: Este se puede dar en cualquier momento o sitio del Sprint, principalmente saliendo de la retrospectiva y de la revisión, el refinamiento del ProductBacklog es un paso necesario, porque nos permite revisar la lista de características del producto para validar las prioridades del inicio o debe bajar para dar paso a otras que aparecieron como por ejemplo capacitaciones o deuda técnica que en conceso y aprobación delProductOwner se incluyan dentro del nuevo ProductBacklog y debe ser estimado otra vez, se escogerán los elementos para el Sprint Planning y a partir de este se escoge elementos que se transformará en el Sprint Backlog. El refinamiento incluye el ingresar elementos al ProductBacklog como los defectos, mejoras, actividades de capacitación, estudios de casos, temas de seguridad de arquitectura, desempeño, etc. Este refinamiento puede darse en cualquier momento del Sprint

y el

responsable por refinar el ProductBacklog es el ProductOwner, porque es el dueño de este evento, por lo tanto cualquier elemento que salga o entre debe ser revisado y aprobado por este, siempre debe estar dispuesto a aclarar inquietudes del equipo de desarrollo, de esta forma de estar presto ayudar al equipo y resolver cualquier inquietud, también ayuda el Scrum Master buscando el tiempo libre o solicitando al jefe que se le asigne tiempo para resolver las inquietudes, siendo pequeñas reuniones o con llamadas telefónicas o correos. El refinamiento puede darse a nivel de Sprint para así aclarar algo que no quedo bien explicado en el Sprint Planning, en otras palabras cuando se construye el software se generan dudas y estas hacen parte del refinamiento porque pueden afectar las historias de usuario que se han levantado con el fin de ser más detallados al momento de construir el software.(Álvarez, de las Heras, & Lasa, 2012, págs. 70 - 76).

RESULTADOS

5.1.

Análisis y Discusión de los resultados

5.1.1.

Entrevista realizada al personal del Departamento de Logística El resultado que se obtuvo por medio del levantamiento de información de la

realización de la entrevista al personal del departamento de logística del Cuerpo de Bomberos del Gobierno Autónomo Descentralizado de Santo Domingo (Ver Anexo 4): ¿Qué tan importante es la implementación de un sistema para el control de mantenimiento de los bienes de la institución? Respuesta Analista de Control de Bienes: Muy importante. Respuesta Bodega: Es importante para la correcta disponibilidad y descargas de las mismas, para un mayor control de los bienes inherentes a la institución. Interpretación:Se puede constatar que hay una buena disposición para la implementación de dicho sistema, porque se mejoraría el control de los bienes y la productividad del departamento. ¿Cómo se realiza el proceso inventario de los bienes y sus respectivos mantenimientos? Respuesta Analista de Control de Bienes: El sistema procesa datos los mismos que son verificados en cada sitio y se regresa al sistema e ingresan cambios (custodio). Respuesta Bodega: Mediante el programa OLYMPO y el mantenimiento mediante sesiones remotas. Interpretación:El sistema que tienen en funcionamiento procesa los datos para después verificarlos en los sitios donde están ubicados los bienes, luego registran los cambios en el sistema. ¿Cuál sería la estimación de bienes que maneja la institución? Respuesta Analista de Control de Bienes: 4’800.000 USD.

Respuesta Bodega: Un promedio de 4 a 5 millones de dólares. Interpretación:aproximadamente se maneja dos mil bienes valorados en cerca de cinco millones de dólares, por lo que es necesario realizar un seguimiento de estos. ¿Cuál es la estimación de tiempo utilizado en estos procesos? Respuesta Analista de Control de Bienes: 2 meses. Respuesta Bodega: De dos a tres meses para constatación. Interpretación: El proceso es lento, lo que indica que la herramienta no automatiza al cien por ciento el control de inventarios y a su vez los bienes. ¿Tienen un control de los bienes así como de sus mantenimientos? Respuesta Analista de Control de Bienes: Si. Respuesta Bodega: Si contamos. Interpretación:Se lleva un control pero no es tan completo ni automatizado, se debe pegar etiquetas con códigos de barras para el registro e identificación de dichos bienes. ¿Existe alguna herramienta tecnológica? Respuesta Analista de Control de Bienes: No. Respuesta Bodega: Impresión de etiquetas con códigos de barra para cada bien. Interpretación:Existe una herramienta pero la cual solo permite llevar un control de cierto tipo de bienes, así como de sus respectivos mantenimientos ¿Qué inconvenientes presenta dicha herramienta? Respuesta Analista de Control de Bienes: (sin respuesta) Respuesta Bodega: Personas despegan las etiquetas, pero se realiza otras la etiquetación. Interpretación:Las etiquetas se desgastan o son despegadas por las personas y no se puede leer los códigos de barras, por lo que se incurre en más tiempo de lo definido.

¿Cuál es el tiempo invertido para obtener resultados totales? Respuesta Analista de Control de Bienes: Se requiere de mucho tiempo (6 meses). Respuesta Bodega: De dos a tres meses. Interpretación:Se observa que hay una clara demora en obtener resultados que van de los tres meses a los seis meses. ¿Qué problemas se presentan en el proceso de registro de bienes? Respuesta Analista de Control de Bienes: No hay problema al momento de registrar. Respuesta Bodega: Ninguno. Interpretación:Se evidencia que no hay problemas para el registro de los bienes en el departamento de logística. ¿Qué problemas se presentan en el proceso de registro de mantenimientos? Respuesta Analista de Control de Bienes: Las órdenes de compras. Respuesta Bodega: Ninguno. Interpretación:Se percibe que solo existen problemas cuando se debe realizar una liquidación de compra para registrar mantenimientos por parte de externos. 5.1.2.

Entrevista realizada al personal del Departamento de Sistemas El resultado obtenido mediante la entrevista (Ver Anexo 5), realizada al departamento

de sistemas del Cuerpo de Bomberos del Gobierno Autónomo Descentralizado de Santo Domingo fue lo siguiente: ¿Cuáles son las características del servidor que tienen en uso? Respuesta: Server HP, 2 procesadores Xeon 2.59 Ghz, 32 Gb RAM, 2 Tb HDD SAS. Server HP, 2 procesadores Xeon 2.59 Ghz, 16 Gb RAM, 1 Tb HDD SAS. Presentan dos servidores con similares características técnicas: Server HP Dual Quadprocessor Intel Xeon 2.59Ghz, 32Gb de memoria RAM, 2Tb HDD SAS; el otro

servidor varia en 16Gb de memoria RAM y 1Tb HDD SAS ¿Qué sistema operativo (OS) está instalado en el servidor? Respuesta: Linux Ubuntu Server 14.04 64 bits. Windows Server 2014 64 bits. Actualmente tienen instalado en un servidor Ubuntu Server 14.04 de 64 bits, mientras en el otro corre Windows Server 2014 de 64 bits. ¿Cuál es el servidor web disponible para la implementación de un software? Respuesta: PHP Apache 2.4. Se encuentra instalado y configurado apache 2.4 con una implementación de PHP para la programación en el servidor. ¿Cuál es el sistema gestor de base de datos (DBMS) utilizado en el servidor? Respuesta: PostgreSQL 9.1.9. Solo se hace uso de PostgreSQL versión 9.1.9 en los dos servidores, es un requerimiento en la institución el uso de este sistema gestor de base de datos. ¿Cuál es el porcentaje de uso de software libre en el departamento de logística y de sistemas? Respuesta: 70%. Interpretación: Se percibe un alto porcentaje en el uso de software libre en toda la institución, aproximadamente un 70 por ciento.

5.1.3.

Encuesta personal del Departamento de Logística La encuesta (Ver Anexo 6), se la aplicó al personal deldepartamento de logística y al

departamento de sistemas del Cuerpo de Bomberos del Gobierno Autónomo Descentralizado de Santo Domingo, a 3 personas que participan en el proceso de registro y control de bienes, así como el control y seguimiento de los mantenimientos de los mismos.

¿Cree usted que se realiza un buen control y registro de todos los bienes de la institución?

Tabla 5: Control y registro de bienes Variable

Frecuencia

Porcentaje

33.33%

66.67%

Nota: Porcentaje de aceptación de la pregunta 1.Fuente: Investigación de campoCBGADM.

Se realiza un buen control y registro de todos los bienes SI 33,33%

NO 66,67%

Figura 1: Porcentaje de aceptación de la pregunta 1 Fuente: Encuesta al personal del Departamento de Logística del CBGADM.

Análisis: De acuerdo a los resultados obtenidos solo un tercio de la población considera que se lleva un buen control y registro de los bienes que tiene la institución, el resto de la población considera que no se realiza un buen control y registro de todos los bienes. 2.

¿Considera que se realiza registro o seguimiento de las incidencias con respecto a bienes?

47 Tabla 6: Seguimiento de incidencias de bienes Variable

Frecuencia

Porcentaje

100%

Nota: Porcentaje de aceptación de la pregunta 2.Fuente: Investigación de campoCBGADM.

Se realiza registro o seguimiento de las incidencias SI 0%

NO 100% SI NO

Figura 2: Porcentaje de aceptación de la pregunta 2. Fuente: Encuestas al personal del Departamento de Logística del CBGADM.

Análisis:En los resultados se muestra un cien por ciento de la población que indica que no se realiza un registro de las incidencias que se presentan en los bienes de la institución. 3.

¿Cree usted que se tiene un control de inventario?

Tabla 7: Control de inventario Variable

Frecuencia

Porcentaje

33.33%

66.67%

Nota: Porcentaje de aceptación de la pregunta 3.Fuente: Investigación de campoCBGADM.

Se tiene un control de inventario SI 33,33%

NO 66,67%

Figura 3: Porcentaje de aceptación de la pregunta 3. Fuente: Encuestas al personal del Departamento de Logística del CBGADM.

Análisis:Se puede observar que casi la mayoría de la población piensa que no se tiene un control sobre el inventario. 4.

¿Considera que el personal que realiza los mantenimientos es suficiente?

Tabla 8: Cantidad de personal que realiza los mantenimientos Variable

Frecuencia

Porcentaje

100%

Nota: Porcentaje de aceptación de la pregunta 4.Fuente: Investigación de campoCBGADM.

El personal que realiza los mantenimientos es suficiente SI 0%

NO 100% SI NO

Figura 4: Porcentaje de aceptación de la pregunta 4. Fuente: Encuestas al personal del Departamento de Logística del CBGADM.

Análisis:En las encuestas se ve reflejado que no se cuenta con personal suficiente para realizar los mantenimientos ya sean preventivos o correctivos en la institución. 5.

¿Cuenta con un sistema informático para registro y control de cualquier tipo de bien?

Tabla 9: Sistema informático para registrar bienes Variable

Frecuencia

Porcentaje

33.33%

66.67%

Nota: Porcentaje de aceptación de la pregunta 5.Fuente: Investigación de campoCBGADM.

Cuenta con un sistema informático para registro y control de cualquier tipo de bien SI 33,33%

NO 66,67%

Figura 5: Porcentaje de aceptación de la pregunta 5. Fuente: Encuestas al personal del Departamento de Logística del CBGADM.

Análisis:Según los resultados obtenidos en las encuestas dos tercios de la población indican que no se cuenta con personal suficiente para realizar los mantenimientos ya sean preventivos o correctivos en la institución. 6.

¿Ha usado algún sistema informático orientado a la web en la institución?

Tabla 10: Sistema web Variable

Frecuencia

Porcentaje

66.67%

33.33%

Nota: Porcentaje de aceptación de la pregunta 6.Fuente: Investigación de campoCBGADM.

Ha usado algún sistema informático orientado a la web en la institución NO 33,33%

SI 66,67%

Figura 6: Porcentaje de aceptación de la pregunta 6. Fuente: Encuestas al personal del Departamento de Logística del CBGADM.

Análisis:Las respuestas indican que la mayoría de personas del departamento hacen uso de sistemas informáticos orientados a la web. 7.

¿Cree usted que un sistema informático mejoraría el control y el registro de los bienes de la institución y sus respectivos mantenimientos?

Tabla 11: Sistema informático mejora el control y registro de bienes Variable

Frecuencia

Porcentaje

100%

Nota: Porcentaje de aceptación de la pregunta 7.Fuente: Investigación de campoCBGADM.

Un sistema informático mejoraría el control y el registro de los bienes y sus mantenimientos NO 0,00%

SI 100,00% SI NO

Figura 7: Porcentaje de aceptación de la pregunta 7. Fuente: Encuestas al personal del Departamento de Logística del CBGADM.

Análisis:De acuerdo al personal del departamento se mejoraría el control y registro de los bienes, así como el seguimiento de los mantenimientos de los mismos. 8.

¿Qué aspectos considera que se mejorarían con el sistema para el control de mantenimientos?

Tabla 12: Aspectos que mejorarían con el sistema Variable

Frecuencia

Porcentaje

Reduciría los tiempos de respuesta

66.67%

Aumentaría la productividad

33.33%

Reduciría la cantidad de mantenimientos

Nota: Porcentaje de aceptación de la pregunta 8.Fuente: Investigación de campoCBGADM.

Aspectos considera queReduciría se mejorarían con el sistema la de para el controlcantidad de mantenimientos Aumentaría la productividad 33,33%

mantenimientos 0%

Reduciría los tiempos de respuesta 66,67% Reduciría los tiempos de respuesta

Aumentaría la productividad

Reduciría la cantidad de mantenimientos

Figura 8: Porcentaje de aceptación de la pregunta 8. Fuente: Encuestas al personal del Departamento de Logística del CBGADM.

Análisis:Según los resultados obtenidos el 66.67% del personal considera que se mejoraran los tiempos de respuestas y un tercio de la población cree que se aumentaría la productividad en la institución. 9.

¿Considera que la implementación de un sistema para el registro de los bienes optimizaría la verificación de los mismos?

Tabla 13: Implementación de un sistema Variable

Frecuencia

Porcentaje

66.67%

33.33%

Nota: Porcentaje de aceptación de la pregunta 9.Fuente: Investigación de campoCBGADM.

Considera que la implementación de un sistema para el registro de los bienes optimizaría la verificación de los mismos NO 33,33%

SI 66,67%

Figura 9: Porcentaje de aceptación de la pregunta 9. Fuente: Encuestas al personal del Departamento de Logística del CBGADM.

Análisis: La mayoría de la población cree que se mejoraría el registro de los bienes en la institución con un sistema informático destinado a esta tarea. 10.

¿Considera que es necesario un sistema para el registro de los mantenimientos para llevar un control de los mantenimientos preventivos y correctivos en la institución?

Tabla 14: Necesidad de un sistema para registrar mantenimientos Variable

Frecuencia

Porcentaje

100%

Nota: Porcentaje de aceptación de la pregunta 10.Fuente: Investigación de campoCBGADM.

Es necesario un sistema para el registro de los mantenimientos para llevar un control NO 0,00%

SI 100,00% SI NO

Figura 10: Porcentaje de aceptación de la pregunta 10. Fuente: Encuestas al personal del Departamento de Logística del CBGADM.

Análisis: Todo el personal tiene en cuenta la necesidad de llevar un registro y a su vez un control de los mantenimientos ya sea preventivo o correctivo que se realicen en la institución. 5.1.4.

Discusión de los resultados obtenidos en la encuesta Los resultados obtenidos en las encuestas indican que es necesario mejorar y

automatizar los procesos de mantenimiento preventivo y correctivo, así como su registro y seguimiento en el departamento de logística; el desarrollo e implementación de un sistema web para el control de los mantenimientos busca dar solución estos problemas que se presentan. 5.1.5.

Discusión de los resultados obtenidos en la entrevista En la entrevista para la determinación de procesos se observa que el actual sistema

procesa los datos después de verificarlos en los sitios donde están ubicados, luego se registra todos esos cambios en el sistema, pero este proceso es lento esto demuestra que no se automatiza totalmente el control de inventario; para el registro de los bienes físicamente se los marca con etiquetas con el código de barras del bien en el inventario, así se identifica a cada bien y esta se registrará también en el sistema. La herramienta utilizada solo permite llevar un registro de ciertos tipos de bienes pero no un buen control de los mantenimientos de los mismos, otro inconveniente es que se

desgastan las etiquetas que identifican físicamente a los bienes y genera más tiempo la identificación. Para la obtención de resultados se observa que se invierte de tres a seis meses.

5.2.

Aplicación de la metodología de desarrollo de software

5.2.1.

Planificación

5.2.1.1. RealeasePlanning

La primera reunión que se debe realizar es un ReleasePlanning, esta se realizó con el ProductOwner y las personas que conocen o tienen las características que tendrá el producto, si falla un Sprint no se busca responsables, solo oportunidades de mejoras. Un Sprint iniciado no puede cambiar su duración porque el equipo ya sabe cómo estimar el tiempo que tardará. 5.2.1.2. Sprint Planning

Gracias al Ing. Edwin Villamarín que fue el ProductOwner, se hizo una reunión en la cual se discutió y analizó las historias de usuarios (Ver Anexo 7) para mejorarlas en el Sprint 0, de esta manera fue posible la elaboración del ProductBacklog (Ver Anexo 8); la duración de cada Sprint se definió de cuatro semanas para desarrollar las historias de usuario asignadas a cada uno de los Sprints. Se Ordenó las funcionalidades en base a la prioridad que propuso el ProductOwner. Las historias de usuarios son descritas por el ProductOwner, en un lenguaje informal y se las estima y prioriza. Tabla 15: ProductBacklog

Número 1 2 3 4 5 6 7 8

ProductBacklog Historia Acceso de usuarios Ingreso de empleado Buscar y editar datos del empleado Eliminar empleado Acceso de administrador Ingreso de usuario Agregar y editar permisos de usuarios Eliminar usuario

Prioridad 100 100 95 95 95 95 95 90

Estimación 13 8 13 13 13 8 5 5

57 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Acceso total al módulo personal Ingreso de proveedor Buscar y editar datos del proveedor Eliminar proveedor Acceso total al módulo proveedor Ingreso de bienes Buscar y editar datos del bien Eliminar bienes Acceso total al módulo bienes Ingreso de custodias Buscar y editar datos de la custodia Eliminar custodias Acceso total al módulo custodia Ingreso de mantenimientos Buscar y editar datos del mantenimiento Mantenimiento realizado Acceso total al módulo mantenimiento

90 90 85 85 85 85 80 75 75 75 75 70 70 70 70 65 65

13 8 13 13 13 13 13 13 5 8 13 13 8 21 8 8 5

Nota: Última versión del ProductBacklog.Fuente: Silva, H. (2017). Investigación de campo. PUCE SD.

Para la estimación de las historia de usuario se procedió a estimar haciendo uso de la serie Fibonacci la cual consiste en dar la valoración midiendo la complejidad de la historia, particularmente en este caso se acortó la serie del uno al veinte y uno, donde 1, 2 y 3 es poco compleja; 5 y 8 medianamente compleja; 13 y 21 compleja. La planificación anteriormente descrita se la realizó antes de iniciar cada Sprint (Sprint Planning) y es donde se selecciona las historias de usuario que serán parte de cada Sprint Backlog, manteniendo la prioridad que considere el ProductOwner. También en esta reunión se puede modificar o agregar historias de usuarios en el ProductBacklog. Tabla 16: Sprint Backlog Historia

Acceso de usuarios

Ingreso de empleado

Estimació n

Categoría

Tarea

Estimación

Estado

Desarrollo

Configuración del O.S. para instalar Django 1.8

Realizado

Desarrollo

Instalación y configuración de PostgreSQL 9.6

Realizado

Diseño

Crear diseño de la base de datos de la historia

Realizado

Diseño

Validar diseño de la base de datos

Realizado

Desarrollo

Migrar modelo a la base de datos

Realizado

Desarrollo

Crear diseño web para el acceso de usuarios

Realizado

Desarrollo

Validar diseño y acceso de usuarios

Realizado

Diseño

Crear diseño de la base de datos de la historia

Realizado

Diseño

Validar diseño de la base de datos

Realizado

Desarrollo

Crear diseño web para el formulario

Realizado

Diseño

Validar diseño e ingreso de datos en formulario Crear diseño de la base de datos de la historia

Diseño

Validar diseño de la base de datos

Realizado

Desarrollo

Crear diseño web para listar y la buscar

Realizado

Desarrollo

Crear diseño web para el formulario

Realizado

Desarrollo

Validar diseño de listar, buscar y editar datos

Realizado

Diseño

Crear diseño de la base de datos de la historia

Realizado

Diseño

Validar diseño de la base de datos

Realizado

Desarrollo

Crear diseño web para listar y eliminar

Realizado

Desarrollo

Validar diseño de listar y eliminar datos Agregar avance al sistema de control de versión

Realizado

Desarrollo Buscar y editar datos del empleado

Eliminar empleado

Desarrollo

Realizado

Nota: Sprint Backlog del Sprint cero.Fuente: Silva, H. (2017). Investigación de campo. PUCE SD. Objetivo del Sprint: Crear y publicar versión básica del módulo personal.

Durante el desarrollo del Sprint no se pueden realizar cambios en los objetivos del Sprint y al final del mismo se realiza una revisión con los interesados invitados por el ProductOwner y el mismo identifica lo que se ha hecho y lo que no se ha hecho, también el equipo menciona los problemas se encontraron y como se resolvieron. 5.2.1.3. Daily Meeting

Son reuniones que se realizan cada día, su duración va de cinco a diez minutos, básicamente se expone lo que se ha hecho desde la última reunión, los inconvenientes que se han presentado o algún riesgo que se deba revisar y lo que se planea realizar para la siguiente reunión. Se hizo usó de la herramienta de gestión de tareas Trello. Aquí se actualizaba el trabajo y avance día a día, a su vez se reflejaba en los cuadros de avance diario, Ver Anexo 9, o revisar la url: https://trello.com/b/n8LhGFNM/sis-co 5.2.1.4. Sprint Execution

No se puede rebajar la calidad de los objetivos del Sprint y todo software que se entrega debe estar listo para ponerse en producción; los requerimientos que no se han desarrollado deben ser registrados o documentados para incluirlas en el ProductBacklog y solo se realizan más adelante con la revisión y autorización del ProductOwner, quien determinará cuando serán atendidas, para no realizar cambios que comprometan al alcance del Sprint. 5.2.1.5. Refinement

A pesar de haber hecho un refinamiento en el Sprint Planning; también se puede realizar algo en el desarrollo de software porque en esta parte pueden aparecer inquietudes adicionales, para atender a estas se puede hacer pequeñas reuniones para aclarar estas dudas. Solo el ProductOwner puede cancelar un Sprint, sin importar si el equipo no pueda alcanzar a realizar el Sprint, no se va a cancelar si no decide hacerlo el ProductOwner; y solo se aborta si el producto no se quiera construir, el alcance del Sprint puede ser renegociado con el ProductOwner aunque ya se haya iniciado dicho Sprint, y si existen tareas que se comprometieron a entregar pasan al Sprint siguiente. 5.2.1.6. Sprint Review

El ProductOwner analiza el estado actual del ProductBacklog y realiza una estimación de fechas basándose en el progreso actual; todo el grupo hace una colaboración para la continuación a modo de revisión, estos aportes son importantes para las siguientes reuniones de los Sprint Planning.Al final de la revisión del Sprint se tiene un resultado que es una nuevo ProductBacklog de mayor valor el siguiente Spint. Se realiza una preparación previa para decidir quien presentará cada parte, cómo y en qué orden se hará para llevar la reunión de una mejor manera, mostrando el avance y con que se continuará, aquí el ProductOwner invita a los principales interesados como a los que participaron anteriormente en el levantamiento del ProductBacklog, también a aquellos que puedan aportar en el software; todo el equipo debe estar presente de esta manera cada miembro estará al tanto de los comentarios, mejoras o defectos que encuentran las personas en el producto entregado. Aquí se puede afectar al ProductBacklog por la decisión del ProductOwner de incluir cambios y ahí realizar cambios sobre el software, aparte de indicar lo que se hizo también se debe mencionar lo que hace falta por hacer y lo que se mostrará en la próxima reunión de revisión para crear una expectativa a los interesados sobre cómo se avanza en la metodología y como se genera un buen avance con respecto al desarrollo de funcionalidades. 5.2.1.7. Sprint Retrospective

La Retrospectiva del Sprint permite al equipo un autoanálisis para revisar el desempeño del proceso SCRUM, de esta manera crear un plan de mejoras para el siguiente Sprint y el propósito de esto es: revisar todo respecto a personas, relaciones,

procesos,herramientas utilizadas, identificar y ordenar los temas principales que se presentaron, como se hizo el trabajo y si se realizaron todos los eventos en el tiempo definido. También se analiza el resultado obtenido, si el plan estuvo acorde al producto o debe revisarse la estimación realizada, esta es la principal tarea del proceso de revisión y autoevaluación; cada persona debe autoevaluarse con respecto a su desempeño en el proceso, la duración establecida fue de una hora porque se definió Sprints de cuatro semanas. 5.2.2.

Desarrollo de Software Para el desarrollo de cada Sprint significa un módulo para cada uno de estos se hace el

diseño de bases de datos para el módulo, a medida que se avanza con los Sprints se va unión los diseños de bases de datos para al final del último Sprint tener una base de datos en una versión final y con sus respectivas relaciones entre cada una de las tablas. Como se puede observar se muestra las migraciones que se han hecho en la base de datos, la herramienta provee un sistema de control de versión para el manejo de los cambios realizados sobre los modelos que se sincronizan con la base de datos.

Figura 11: Historial de migraciones Fuente: Código fuente del software.

Para el desarrollo y seguimiento del proyecto se utilizó el sistema de control de versiones Git que provee mantenimiento de versiones de aplicaciones cuando tienen muchos archivos en el código fuente, junto con un repositorio creado en github.com esto permite llevar un historial de los avances que se realizan en el código fuente del proyecto y de esta manera tener backups del proyecto. El software que permite realizar estas sincronizaciones es GitKraken en GNU/Linux; es una herramienta de libre, con esta aplicación podemos sincronizar el código fuente con el repositorio fácilmente a través de una interfaz gráfica, también se puede acceder a las versiones anteriores sincronizadas desde la misma aplicación, sin necesidad de acceder directamente a github.com; la figura siguiente reemplaza al gráfico del producto, para el control de versiones del software.

Figura 12: Captura del historial del proyecto en GitKraken Fuente: Aplicación GitKraken usada para el proyecto.

Al final del desarrollo del sistema se tiene un diseño de bases de datos con todas las tablas de los diferentes módulos relacionadas, en cada Sprint se realizó un planteamiento de tablas con sus respectivas relaciones para que el módulo funcione correctamente, y a medida que crecía el número de tablas de la base de datos se hacia las respectivas relaciones para integrarla en un solo diseño, de esta manera se obtiene una sola base de datos del sistema. Tener un buen diseño de base de datos mejora considerablemente la consistencia e integridad de los datos, se reduce la redundancia de la información y se evitar que las

búsquedas arrojen información incorrecta o errónea. Una base de datos es el cimiento, columna de cualquier tipo de aplicación. Con este diseño se pudo elaborar el diccionario de datos (Ver Anexo 10).

Figura 13: Diseño lógico de la base de datos. Fuente: Última versión del diseño de la base de datos del sistema.

Para el desarrollo de la aplicación se empleó el Django que proporciona muchas características y ventajas como las seguridades tanto en el manejo de usuarios, sus permisos y sesiones de los mismos, así como protección contra ataques de inyección de código SQL, ataques de sitio cruzado (CSRF) y muchas utilidades implementadas, listas para usar. Django permite un desarrollo rápido de aplicaciones web, fomenta un diseño limpio, pragmático y la reutilización de código. La versión empleada es 1.8.18 LTS la cual tiene soporte hasta el año 2018, LTS por sus siglas Long TermSupport, soporte de larga duración, también se utilizó Python 3.5 esto permite que se migre fácilmente a futuras versiones. La interfaz administrativa del sistema hace uso del sitio administrativo que provee Django, en el cual se debe registrar los modelos de la base de datos y configurar los parámetros necesarios para que entre en funcionamiento, como resultado de esto se tiene un

sitio totalmente independiente del proyecto, y se conserva la programación orientada a objetos que menciona la reutilización de código y la filosofía del Framework, no repetir código. Este sitio de administración es potente y se encuentra listo para ponerse en producción y se puede agregar, ver, editar y eliminar información de la base de datos también se registra todos los movimientos o cambios que se realice con el usuario, a esta interfaz solo pueden acceder quienes sean super-usuario y tengan los respectivos permisos; los usuarios del sistema no tendrán acceso a menos que se les otorgue los privilegios necesarios. También cuenta con un diseño predefinido que facilita al usuario su manejo y mejora la comunicación e interacción con el mismo.

Figura 14: Sitio Administrativo del Sistema Fuente: Sistema desarrollado (SIS-CO).

Para el diseño de las interfaces del sistema se utilizó el Framework Bootstrap 3.3.6 una de las principales características es la rapidez para crear diseño web, también emplea el responsive web design (diseño web adaptable) por tal motivo todos los elementos creados se adaptan a la perfección a cualquier tipo de dispositivo y a sus diferentes tamaños de pantallas,

no importa si se visualiza desde una computadora, una tablet, o un smartphone siempre se tiene una interfaz fĂĄcil de utilizar.

Figura 15: MenĂş principal de cada mĂłdulo. Fuente: Sistema desarrollado (SIS-CO).

Figura 16: Interfaz de inicio del Sistema Fuente: Sistema desarrollado (SIS-CO).

Figura 17: Interfaz delista y búsqueda del módulo Fuente: Sistema desarrollado (SIS-CO).

Figura 18: Interfaz de detalle del módulo. Fuente: Sistema desarrollado (SIS-CO).

5.3. 

Conclusiones Con la implementación del sistema SIS-CO se optimizan los procesos referentes al mantenimiento de bienes como el registro y el seguimientode los mantenimientos de los mismos; esto reduce los tiempos de repuesta invertidos en los procesos del Departamento de Logística;aumenta la productividad en la institución y permite un mejor control sobre el inventario y el seguimiento de los bienes.



De acuerdo al análisis realizado previamente y la experiencia adquirida en el desarrollo del presente trabajo de investigación se usa SCRUM porque gestiona adecuadamente un proyecto que tiene requerimientos dinámicos y en los cuales se requiera un rápido despliegue, esto es posible gracias al manejo de sprints cortos de desarrollo que dan como resultados entregables totalmente funcionales del producto final.



Las herramientas utilizadas en el desarrollo de software permiten un desarrollo rápido de aplicaciones, gracias a la integración que ofrece el framework Django con PostgreSQL; el lenguaje Pyhton es potente en comparación con otros lenguajes de la misma categoría, permite escribir código fácilmente legible y mantenible; las versión usada fue Django 1.8 y PostgreSQL 9.6 y Bootstrap 3.3para realizar las interfaces.



Se construyó rápidamente la aplicación gracias al uso de Django, la versión utilizada fue 1.8.18, provee muchas seguridades listas para usar y compatibilidad con varios sistemas gestores de bases de datos; mejora significativamente la velocidad del desarrollo de software con un equipo mínimo de desarrolladores.

5.4. 

Recomendaciones La participación del cliente es un aspecto que no se debe dejar pasar por alto, de esto depende que se realice un producto acorde a las necesidades o requerimientos del negocio; no solo hace falta que esté involucrado, también se requiere que se tenga una buena comunicación con el mismo.



La metodología de desarrollo SCRUM es más eficiente si se desarrolla con un grupo de 3 personas como mínimo, porque se requiere ciertas tareas que se realicen desde diferentes perspectivas.



Entender la lógica del negocio es fundamental al momento de plasmar las funcionalidades en el desarrollo de software, así se ajusta a las necesidades del cliente.



Solo usar versiones de soporte de larga duración de Django, y antes de migrar a una versión actualizada del Framework, realizar pruebas previamente para verificar la compatibilidad del software desarrollado, aunque no se debería presentar problemas porque se desarrolló en con una versión LTS.



Realizar capacitaciones con las personas que usarán el sistema, como con el administrador, para que sepa cómo funciona el software, el administrador deberá usar el sitio administrativo solo para revisión de información.

LISTA DE REFERENCIA 5.5.

Fuentes de Información Bibliográficas

Álvarez, A., de las Heras, R., & Lasa, C. (2012). Métodos Ágiles y Scrum. Madrid: EDICIONES ANAYA MULTIMEDIA. Arias, Á. (2015). Aprende a programar en C#. Middletown: Createspace Independent Publishing Platform. Berrospi, V., Rodriguez, J., Bobadilla, J., Liberto, C., Díaz, C., & Quipan, C. (2015). Desarrollo de un servicio en línea para la gestión tecnológica en salud. Revista Peruana de Medicina Experimental y Salud Pública, 32(4), 724-730. Bravo, M. (2011). Contabilidad General (Décima ed.). Quito: Editora ESCOBAR impresores. Brito, K., Dailyn, S., & Héctor, K. (2015). Selección de Metodologías de Desarrollo de Software para Aplicaciones Web. San Bernardino: Editorial Académica Española. Ceballos, J. (2013). Enciclopedia de Microsoft Visual C#. Interfaces gráficas y aplicaciones para Internet con Windows Forms y ASP.NET. México: Alfaomega. Cendejas, J., Vega, C., Careta, A., Gutiérrez, O., & Ferreira, H. (2014). Diseño del modelo integral colaborativo para el desarrollo ágil de software en las empresas de la zona centro-occidente en México. Revista Electrónica Nova Scientia, 7(13), 133-148. Cibelli, C. (2012). PHP Programación Web avanzada para profesionales. Buenos Aires: Alfaomega. Daza, A., Parra, J., & Espinosa, L. (2016). Metodología de representación de software orientada al desarrollo ágil de aplicaciones: Un enfoque arquitectural. Redes de Ingeniería, 7(1), 26-33. Fernández, A. (2013). Python 3 al descubierto (Segunda ed.). México: Alfaomega Grupo Editor. García, J. (2014). Contabilidad de Costos. México: McGRAW-HILL/INTERAMERICANA EDITORES, S.A. DE C.V. Guardati, S. (2014). Estructura de datos orientada a objetos: Algoritmos con C++. México: Pearson Educación. Joyanes, L. (2013). Fundamentos generales de programación. México: McGraw Hill. López, M., Vara, J., Verde, J., Sánchez, D., Jiménez, J., & de Castro, V. (2014). Desarrollo Web en Entorno Servidor. Madrid: RA-MA, S.A. Editorial y Publicaciones. Orbegozo, B. (2013). Gestión de bases de datos con SQL, MySQL y Access. Curso práctico (Primera ed.). México: Alfaomega Grupo Editor, S.A. Pérez, M. (2015). MySQL Diseño, Programación y Aministración de Bases de Datos. San Bernardino: Createspace. Pérez, M. (2015). ORACLE 12c/11g/10g. Programación PL/SQL a través de ejemplos. San Bernardino: Createspace.

69 Piñeiro, J. (2013). Base de datos relacionales y modelado de datos. España: Ediciones Paraninfo, S.A. Primero, D., Diaz, J., García, L., & González-Vargas, A. (2015). MANUAL PARA LA GESTIÓN DEL MANTENIMIENTO CORRECTIVO DE EQUIPOS BIOMÉDICOS EN LA FUNDACIÓN VALLE DEL LILI. Revista Ingeniería Biomédica, 9(18), 81-87. Rey, F. (2014). Elaboración y optimización de un plan de mantenimiento preventivo. Técnica Industrial(308), 30-41. Salazar, F. (2013). Aprenda SQL Server 2012. México: Alfaomega. Sánchez, S., Sicilia, M., & Rodríguez, D. (2012). INGENIERÍA DEL SOFTWARE Un enfoque desde la guía SWEBOK (Primera ed.). México: Alfaomega Grupo Editor, S.A. Secretaría Nacional de Planificación y Desarrollo. (2013). Plan Nacional para el Buen Vivir. Quito. Stephens, R. (2015). Beginning Software Engineering. Indianápolis: John Wiley & Sons, Inc. Valderrey, P. (2013). Administración de sistemas gestores de bases de datos (Primera ed.). Bogotá: Ecoe Ediciones. Velásquez, E., & Custodio, Á. (2011). Sistema para la gestión del mantenimiento para un control supervisorio basado en software libre. Universidad, Ciencia y Tecnología, 15(59), 103-113. Zofío, J. (2013). Aplicaciones Web. Madrid: MACMILLAN IBERIA.

5.6.

Fuentes de Información Lincográficas

MariaDB Foundation. (2017). About MariaDB. Obtenido de https://mariadb.org/about/ Microsoft Corporation. (2017). SQL Server 2016. Obtenido de https://www.microsoft.com/es-es/sqlserver/sql-server-2016-features The PHP Group. (2017). ¿Qué puede hacer PHP? Obtenido de http://php.net/manual/es/introwhatcando.php The PostgreSQL Global Development Group . (2017). About PostgreSQL. Obtenido de https://www.postgresql.org/about/ Contraloría General del Estado. (2009). Normas de Control Interno para las entidades, organismos del sector público y personas jurídicas de derecho privado que dispongan de recursos públicos.Obtenido de http://www.oas.org/juridico/PDFs/mesicic5_ecu_ane_cge_12_nor_con_int_400_cge.pdf

5.7.

Glosario Apache: Es un servidor web con una licencia libre de uso. Se puede utilizar en

muchas plataformas, y mantiene un excelente rendimiento. Bootstrap: Framework para facilitar diseño de páginas web adaptativas, este proyecto fue liberado por Twitter. CBGADM:Cuerpo

Bomberos

del

Gobierno

Autónomo

Descentralizado

Municipal. Django: Es un framework para facilitar el desarrollo web de sitios complejos de código abierto y escrito en Python y usado en todas las partes del framework, respeta el patrón MVC, provee una aplicación de administración. Framework: Es un conjunto de librerías y módulos que sirven de base para la organización y desarrollo de software, manteniendo un patrón de diseño. HTML: Lenguaje de marcado utilizado en el desarrollo de páginas web, sus siglas: HyperTextMarkupLanguage. HTTP: Es un protocolo de transferencia de hipertexto y es el que permite la comunicación en la World Wide Web. (HyperText Transfer Protocol). IP: Significa Internet Protocol y es un número que identifica de manera única a un dispositivo dentro de una red. Javascript: Lenguaje de programación principalmente usado en el desarrollo de páginas web dinámicas, integrado en los navegadores web donde se interpreta y ejecuta. JQuery: Es una librería de Javascript para el desarrollo web y permite mejorar la interactividad a una página web Python: Lenguaje de programación de código abierto, multi-plataforma, multipropósito y multi-paradigma, se puede integrar con Apache para servir aplicaciones web. SCRUM: Metodología de desarrollo de software ágil y se adapta fácilmente a los cambios o nuevos requerimientos.

ANEXOS

ANEXO 1Carta de Asignaciรณn de Proyecto

ANEXO 2Carta de Impacto

ANEXO3Acta de Entrega - Recepciรณn

ANEXO4Entrevista dirigida al Departamento de Logística

Pontificia Universidad Católica del Ecuador Sede Santo Domingo Escuela de Ingeniería de Sistemas

ENTREVISTA DEPARTAMENTO DE LOGISTICA 1. Que tan importante es la implementación de un sistema para el control de mantenimiento de los bienes de la institución?

2. Como se realiza el proceso inventario de los bienes y sus respectivos mantenimientos?

3. Cuál sería la estimación de bienes que maneja la institución?

4. Cuál es la estimación de tiempo utilizado en estos procesos?

5. Tienen un control de los bienes así como de sus mantenimientos? (En caso de ser negativa pasar a la pregunta 6, si es afirmativa contestar literales a y b)

a. Existe alguna herramienta tecnológica?

b. Que inconvenientes presenta dicha herramienta?

6. Cuál es el tiempo invertido para obtener resultados totales?

7. Que problemas se presentan en el proceso de registro de bienes?

8. Que problemas se presentan en el proceso de registro de mantenimientos?

ANEXO5Entrevista dirigida al Departamento de Sistemas

Pontificia Universidad Católica del Ecuador Sede Santo Domingo Escuela de Ingeniería de Sistemas

ENTREVISTA DEPARTAMENTO DE SISTEMAS

1. Cuáles son las características del servidor que tienen en uso?

2. Qué sistema operativo (OS) está instalado en el servidor?

3. Cuál es el servidor web disponible para la implementación de un software?

4. Cuál es el sistema gestor de base de datos (DBMS) utilizado en el servidor?

5. Cuál es el porcentaje de uso de software libre en el departamento de logística y de sistemas?

ANEXO6 Encuesta dirigida al Departamento de Logística LA PRESENTE ENCUESTA TIENE POR OBJETIVO AVERIGUAR LA POSIBILIDAD DE CREACIÓN DE UN SISTEMA PARA EL CONTROL DEL MANTENIMIENTO PREVENTIVO Y CORRECTIVO

1. ¿Cree usted que se realiza un buen control y registro de todos los bienes de la institución? SI

2. ¿Considera que se realiza registro o seguimiento de las incidencias con respecto a bienes? SI

3. ¿Cree usted que se tiene un control de inventario? SI

4. ¿Considera que el personal que realiza los mantenimientos es suficiente? SI

5. ¿Cuenta con un sistema informático para registro y control de cualquier tipo de bien? SI

6. ¿Ha usado algún sistema informático orientado a la web en la institución? SI

7. ¿Cree usted que un sistema informático mejoraría el control y el registro de los bienes de la institución y sus respectivos mantenimientos? SI

8. ¿Qué aspectos considera que se mejorarían con el sistema para el control de mantenimientos? Reduciría los tiempos de respuesta Aumentaría la productividad Reduciría la cantidad de mantenimientos

9. ¿Considera que la implementación de un sistema para el registro de los bienes optimizaría la verificación de los mismos? SI

10. ¿Considera que es necesario un sistema para el registro de los mantenimientos para llevar un control de los mantenimientos preventivos y correctivos en la institución? SI

ANEXO7Historias de Usuarios Historia de Usuario Número: 1

Usuario:Analista de bienes / bodeguero

Nombre historia:Acceso de usuarios Prioridad en negocio: 100

Riesgo en desarrollo:Bajo

Puntos estimados:13

Sprint asignada:0

Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO ingresar usuario y contraseña PARA acceder a la interfaz de usuario. Escenario de prueba: DADO el ingreso correcto de usuario y contraseña CUANDO hago clic en el botón inicia sesiónENTONCES se accede al menú principal. DADO el ingreso incorrecto de usuario y contraseña CUANDO hago clic en el botón ingresar ENTONCES se presenta un mensaje de error. DADO el ingreso del campo usuario o contraseña vacío o incompleto CUANDO hago clic en el botón ingresar ENTONCES se muestra un mensaje de error y se vuelve a pedir los datos faltantes.

Historia de Usuario Número: 2

Usuario:Analista de bienes / bodeguero

Nombre historia:Ingreso de empleado Prioridad en negocio: 100

Riesgo en desarrollo: Bajo

Puntos estimados:8

Sprint asignada:0

Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO ingresar datos del empleado PARA visualizar en pantalla. Escenario de prueba: DADO el ingreso completo de los datos del empleado CUANDO hago clic en el botón guardar ENTONCES se visualiza en la lista de empleados. DADO el ingreso del empleado con cédula incorrecta o duplicada CUANDO hago clic en el botón guardar ENTONCES no se guardan los datos del empleado y se muestran errores. DADO el ingreso del empleado con datos vacíos o incompletos CUANDO hago clic en el botón guardar ENTONCES no se guardan los datos del empleado y se muestran errores.

Historia de Usuario Número: 3

Usuario:Analista de bienes / bodeguero

Nombre historia:Buscar y editar datos del empleado Prioridad en negocio: 95

Riesgo en desarrollo: Media

Puntos estimados:13

Sprint asignada:0

Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO buscar los datos del empleado PARA revisar y modificar los datos del empleado. Escenario de prueba: DADO una lista de empleados CUANDO escribo datos del empleado en el cuadro de búsqueda ENTONCES se muestra la información. DADO el empleado seleccionado CUANDO hago clic en la información del empleado ENTONCES se muestra toda la información del empleado. DADO la edición de datos del empleado CUANDO hago clic en guardar ENTONCES se presenta mensaje de confirmación. DADO los datos del empleado incompletos o vacíos CUANDO hago clic en guardar ENTONCES se muestran los errores en los campos vacíos.

Historia de Usuario Número: 4

Usuario:Analista de bienes / bodeguero

Nombre historia:Eliminar empleado Prioridad en negocio: 95

Riesgo en desarrollo: Media

Puntos estimados:13

Sprint asignada:0

Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO eliminar empleados PARA dar de baja al empleado en la nómina. Escenario de prueba: DADO los datos del empleado CUANDO hago clic en el botón eliminar ENTONCES se desactiva al empleado. DADO la lista de todos los empleados CUANDO hago clic en eliminar ENTONCES se muestra un mensaje de confirmación de eliminación y se desactiva al empleado.

Historia de Usuario Número: 5

Usuario: Administrador

Nombre historia:Acceso de administrador Prioridad en negocio: 95

Riesgo en desarrollo: Alta

Puntos estimados:13

Sprint asignado:1

Programador responsable:Hugo Silva Descripción: COMO administrador QUIERO ingresar usuario y contraseña PARA acceder a la administración del sistema. Escenario de prueba: DADO el ingreso correcto de usuario y contraseña CUANDO haga clic en el botón ingresar ENTONCES se accede al menú principal de la administración. DADO el ingreso incorrecto de usuario y contraseña CUANDO hago clic en el botón ingresar ENTONCES se presenta un mensaje de error. DADO el ingreso del campo usuario o contraseña vacío o incompleto CUANDO hago clic en el botón ingresar ENTONCES se muestra un mensaje de error y se vuelve a pedir los datos faltantes.

Historia de Usuario Número: 6

Usuario: Administrador

Nombre historia:Ingreso de usuario Prioridad en negocio: 95

Riesgo en desarrollo: Alta

Puntos estimados:8

Sprint asignado:1

Programador responsable:Hugo Silva Descripción: COMO administrador QUIERO ingresar datos del usuario PARA que accedan al sistema. Escenario de prueba: DADO en ingreso completo de los datos del usuario CUANDO haga clic en el botón crear ENTONCES se crea usuario para el sistema. DADO el ingreso de datos de usuario repetido CUANDO haga clic en el botón crear ENTONCES no se crea el usuario y se muestran errores. DADO el ingreso de datos vacíos o incompleto de usuario CUANDO haga clic en el botón crear ENTONCES no se crea el usuario y se muestra errores.

81 Historia de Usuario Número: 7

Usuario: Administrador

Nombre historia:Agregar y editar permisos de usuarios Prioridad en negocio: 95

Riesgo en desarrollo: Alta

Puntos estimados:5

Sprint asignado:1

Programador responsable:Hugo Silva Descripción: COMO administrador QUIERO agregar y editar permisos a usuarios PARA controlar los permisos de los usuarios. Escenario de prueba: DADO una lista de permisos seleccionados CUANDO haga clic en el botón guardar ENTONCES se agregan los permisos seleccionados al usuario. DADO un ingreso de permisos modificados CUANDO haga clic en el botón guardar ENTONCES se cambian los permisos del usuario.

Historia de Usuario Número: 8

Usuario: Administrador

Nombre historia:Eliminar usuario Prioridad en negocio: 90

Riesgo en desarrollo: Alta

Puntos estimados:5

Sprint asignado:1

Programador responsable:Hugo Silva Descripción: COMO administrador QUIERO eliminar usuarios del sistema PARA dar de baja al usuario del sistema. Escenario de prueba: DADO los datos del usuario CUANDO haga clic en eliminar ENTONCES se desactiva al usuario del sistema. DADO la lista de todos los usuarios CUANDO selecciono y hago clic en eliminar ENTONCES se muestra un mensaje de confirmación de eliminación y se desactiva al o los usuarios.

Historia de Usuario Número: 9

Usuario: Administrador

Nombre historia:Acceso total al módulo personal Prioridad en negocio: 90

Riesgo en desarrollo: Media

Puntos estimados:13

Sprint asignado:1

Programador responsable:Hugo Silva Descripción: COMO administrador QUIERO revisar el personal PARA acceder al módulo personal sin restricciones. Escenario de prueba: DADO el menú principal CUANDO haga clic en personal ENTONCES se muestra una lista de todos los empleados activos y desactivados. DADO una lista de todos los empleados CUANDO escribo datos del empleado en el cuadro de búsqueda ENTONCES se muestra la información. DADO el empleado seleccionado CUANDO hago clic en la información del empleado ENTONCES se muestra toda la información del empleado. DADO el ingreso completo de los datos del empleado CUANDO hago clic en el botón guardar ENTONCES se visualiza en la lista de empleados. DADO los datos del empleado CUANDO hago clic en el botón eliminar ENTONCES se desactiva al empleado.

Historia de Usuario Número: 10 Usuario:Analista de bienes / bodeguero Nombre historia:Ingreso de proveedor Prioridad en negocio: 90 Riesgo en desarrollo: Bajo Puntos estimados:8 Sprint asignado:2 Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO ingresar datos del proveedor PARA visualizar en pantalla. Escenario de prueba: DADO el ingreso completo de los datos del proveedor CUANDO hago clic en el botón guardar ENTONCES se visualiza en la lista de proveedores. DADO el ingreso del proveedor con ruc incorrecto o duplicado CUANDO hago clic en el botón guardar ENTONCES no se guardan los datos del proveedor y se muestran errores. DADO el ingreso del proveedor con datos vacíos o incompletos CUANDO hago clic en el botón guardar ENTONCES no se guardan los datos del proveedor y se muestran errores.

Historia de Usuario Número: 11

Usuario:Analista de bienes / bodeguero

Nombre historia:Buscar y editar datos del proveedor Prioridad en negocio: 85

Riesgo en desarrollo: Media

Puntos estimados:13

Sprint asignada:2

Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO buscar los datos del proveedor PARA revisar y modificar los datos del proveedor. Escenario de prueba: DADO una lista de proveedores CUANDO escribo datos del proveedor en el cuadro de búsqueda ENTONCES se muestra la información. DADO el proveedor seleccionado CUANDO hago clic en la información del empleado ENTONCES se muestra toda la información del proveedor. DADO la edición de datos del proveedor CUANDO hago clic en guardar ENTONCES se presenta mensaje de confirmación. DADO los datos del proveedor incompletos o vacíos CUANDO hago clic en guardar ENTONCES se muestran los errores en los campos vacíos.

Historia de Usuario Número: 12

Usuario:Analista de bienes / bodeguero

Nombre historia:Eliminar proveedor Prioridad en negocio: 85

Riesgo en desarrollo: Bajo

Puntos estimados:13

Sprint asignada:2

Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO eliminar proveedores PARA dar de baja al proveedor en la nómina. Escenario de prueba: DADO los datos del proveedor CUANDO hago clic en el botón eliminar ENTONCES se desactiva al proveedor. DADO la lista de todos los proveedores CUANDO hago clic en eliminar ENTONCES se muestra un mensaje de confirmación de eliminación y se desactiva al proveedor.

Historia de Usuario Número: 13

Usuario: Administrador

Nombre historia:Acceso total al módulo proveedor Prioridad en negocio: 85

Riesgo en desarrollo: Bajo

Puntos estimados:13

Sprint asignado:2

Programador responsable:Hugo Silva Descripción: COMO administrador QUIERO revisar los proveedores PARA acceder al módulo proveedor sin restricciones Escenario de prueba: DADO el menú principal CUANDO haga clic en proveedor ENTONCES se muestra una lista de todos los proveedores activos y desactivados. DADO una lista de todos proveedores CUANDO escribo datos del proveedor en el cuadro de búsqueda ENTONCES se muestra la información. DADO el proveedor seleccionado CUANDO hago clic en la información del proveedor ENTONCES se muestra toda la información del proveedor. DADO el ingreso completo de los datos del proveedor CUANDO hago clic en el botón guardar ENTONCES se visualiza en la lista de proveedores. DADO los datos del proveedor CUANDO hago clic en el botón eliminar ENTONCES se desactiva al proveedor.

Historia de Usuario Número: 14

Usuario:Analista de bienes / bodeguero

Nombre historia:Ingreso de bienes Prioridad en negocio: 85

Riesgo en desarrollo: Medio

Puntos estimados:13

Sprint asignado:3

Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO ingresar datos del bien PARA visualizar en pantalla. Escenario de prueba: DADO el ingreso completo de los datos del bien CUANDO hago clic en el botón guardar ENTONCES se visualiza en la lista de bienes. DADO el ingreso del bien con código incorrecto o duplicado CUANDO hago clic en el botón guardar ENTONCES no se guardan los datos del bien y se muestran errores. DADO el ingreso del bien con datos vacíos o incompletos CUANDO hago clic en el botón guardar ENTONCES no se guardan los datos del bien y se muestran errores.

Historia de Usuario Número: 15

Usuario:Analista de bienes / bodeguero

Nombre historia:Buscar y editar datos del bien Prioridad en negocio: 80

Riesgo en desarrollo: Media

Puntos estimados:13

Sprint asignada:3

Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO buscar los datos del bien PARA revisar y modificar los datos del bien. Escenario de prueba: DADO una lista de bienes CUANDO escribo datos del bien en el cuadro de búsqueda ENTONCES se muestra la información. DADO el bien seleccionado CUANDO hago clic en la información del bien ENTONCES se muestra toda la información del bien. DADO la edición de datos del bien CUANDO hago clic en guardar ENTONCES se presenta mensaje de confirmación. DADO los datos del bien incompletos o vacíos CUANDO hago clic en guardar ENTONCES se muestran los errores en los campos vacíos.

Historia de Usuario Número: 16

Usuario:Analista de bienes / bodeguero

Nombre historia:Eliminar bienes Prioridad en negocio: 75

Riesgo en desarrollo: Bajo

Puntos estimados:13

Sprint asignada:3

Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO eliminar bienes PARA dar de baja al bien en la lista de bienes. Escenario de prueba: DADO los datos del bien CUANDO hago clic en el botón eliminar ENTONCES se desactiva al bien. DADO la lista de todos los bienes CUANDO hago clic en eliminar ENTONCES se muestra un mensaje de confirmación de eliminación y se desactiva al bien.

Historia de Usuario Número: 17

Usuario: Administrador

Nombre historia:Acceso total al módulo bienes Prioridad en negocio: 75

Riesgo en desarrollo: Bajo

Puntos estimados:5

Sprint asignado:3

Programador responsable:Hugo Silva Descripción: COMO administrador QUIERO revisar los bienes PARA acceder al módulo bienes sin restricciones. Escenario de prueba: DADO el menú principal CUANDO haga clic en bienes ENTONCES se muestra una lista de todos los bienes activos y desactivados. DADO una lista de todos bienes CUANDO escribo datos del bien en el cuadro de búsqueda ENTONCES se muestra la información. DADO el bien seleccionado CUANDO hago clic en la información del bien ENTONCES se muestra toda la información del bien. DADO el ingreso completo de los datos del bien CUANDO hago clic en el botón guardar ENTONCES se visualiza en la lista de bien. DADO los datos del bien CUANDO hago clic en el botón eliminar ENTONCES se desactiva al bien.

Historia de Usuario Número: 18

Usuario:Analista de bienes / bodeguero

Nombre historia:Ingreso de custodias Prioridad en negocio: 75

Riesgo en desarrollo: Medio

Puntos estimados:8

Sprint asignado:4

Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO ingresar datos del empleado y el bien PARA visualizar la custodia. Escenario de prueba: DADO el ingreso completo de los datos del empleado y el bien CUANDO hago clic en el botón guardar ENTONCES se visualiza en la lista de custodias. DADO el ingreso del empleado o el bien con datos vacíos o incompletos CUANDO hago clic en el botón guardar ENTONCES no se guardan los datos de la custodia y se muestran errores.

Historia de Usuario Número: 19

Usuario:Analista de bienes / bodeguero

Nombre historia:Buscar y editar datos de la custodia Prioridad en negocio: 75

Riesgo en desarrollo: Media

Puntos estimados:13

Sprint asignada:4

Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO buscar los datos de la custodia PARA revisar y modificar los datos de la custodia. Escenario de prueba: DADO una lista de custodias CUANDO escribo datos del empleado o el bien en el cuadro de búsqueda ENTONCES se muestra la información. DADO la custodia seleccionada CUANDO hago clic en la información de la custodia ENTONCES se muestra toda la información de la custodia. DADO la edición de datos de la custodia CUANDO hago clic en guardar ENTONCES se presenta mensaje de confirmación. DADO los datos del empleado o el bien incompleto o vacío CUANDO hago clic en guardar ENTONCES se muestran los errores en los campos vacíos.

Historia de Usuario Número: 20

Usuario:Analista de bienes / bodeguero

Nombre historia:Eliminar custodias Prioridad en negocio: 70

Riesgo en desarrollo: Medio

Puntos estimados:13

Sprint asignada:4

Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO eliminar custodias PARA dar de baja al bien o reasignarlo. Escenario de prueba: DADO los datos de la custodia CUANDO hago clic en el botón eliminar ENTONCES se desactiva la custodia. DADO la lista de todas las custodias CUANDO hago clic en eliminar ENTONCES se muestra un mensaje de confirmación de eliminación y se desactiva la custodia.

Historia de Usuario Número: 21

Usuario: Administrador

Nombre historia:Acceso total al módulo custodia Prioridad en negocio: 70

Riesgo en desarrollo: Medio

Puntos estimados:8

Sprint asignado:4

Programador responsable:Hugo Silva Descripción: COMO administrador QUIERO revisar las custodias PARA acceder al módulo custodia sin restricciones. Escenario de prueba: DADO el menú principal CUANDO haga clic en custodia ENTONCES se muestra una lista de todas las custodias activas y desactivadas. DADO una lista de todas las custodias CUANDO escribo datos del empleado o el bien en el cuadro de búsqueda ENTONCES se muestra la información. DADO la custodia seleccionada CUANDO hago clic en la información de la custodia ENTONCES se muestra toda la información de la custodia. DADO el ingreso completo de los datos de la custodia CUANDO hago clic en el botón guardar ENTONCES se visualiza en la lista de custodias. DADO los datos de la custodia CUANDO hago clic en el botón eliminar ENTONCES se desactiva la custodia.

Historia de Usuario Número: 22

Usuario:Analista de bienes / bodeguero

Nombre historia:Ingreso de mantenimientos Prioridad en negocio: 70

Riesgo en desarrollo: Medio

Puntos estimados:21

Sprint asignado:5

Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO ingresar datos del bien y el diagnostico PARA visualizar en pantalla el mantenimiento. Escenario de prueba: DADO el ingreso completo de los datos del bien y el diagnostico CUANDO hago clic en el botón guardar ENTONCES se visualiza en la lista de mantenimientos. DADO el ingreso completo de los datos del bien y el diagnostico con fechas incorrectas o vacías CUANDO hago clic en el botón guardar ENTONCES no se guardan los datos del mantenimiento y se muestran errores.

Historia de Usuario Número: 23

Usuario:Analista de bienes / bodeguero

Nombre historia:Buscar y editar datos del mantenimiento Prioridad en negocio: 70

Riesgo en desarrollo: Media

Puntos estimados:8

Sprint asignada:5

Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO buscar los datos del bien PARA revisar y modificar los datos del mantenimiento. Escenario de prueba: DADO una lista de mantenimientos CUANDO escribo datos del bien en el cuadro de búsqueda ENTONCES se muestra la información. DADO el mantenimiento seleccionado CUANDO hago clic en la información del bien ENTONCES se muestra toda la información del mantenimiento. DADO la edición de datos del mantenimiento CUANDO hago clic en guardar ENTONCES se presenta mensaje de confirmación. DADO los datos del mantenimiento incompletos o vacíos CUANDO hago clic en guardar ENTONCES se muestran los errores en los campos vacíos.

Historia de Usuario Número: 24

Usuario:Analista de bienes / bodeguero

Nombre historia:Mantenimiento realizado Prioridad en negocio: 65

Riesgo en desarrollo: Medio

Puntos estimados:8

Sprint asignada:5

Programador responsable:Hugo Silva Descripción: COMO analista o bodeguero QUIERO marcar como realizado los mantenimientos PARA eliminar de la lista de mantenimientos. Observaciones: DADO los datos del mantenimiento CUANDO haga clic en el botón realizado ENTONCES se desactiva al mantenimiento. DADO la lista de todos los mantenimientos CUANDO haga clic en el botón realizado ENTONCES se muestra un mensaje de confirmación.

Historia de Usuario Número: 25

Usuario: Administrador

Nombre historia:Acceso total al módulo mantenimiento Prioridad en negocio: 65

Riesgo en desarrollo: Medio

Puntos estimados:5

Sprint asignado:5

Programador responsable:Hugo Silva Descripción: COMO administrador QUIERO revisar el mantenimiento PARA acceder al módulo mantenimiento sin restricciones. Escenario de prueba: DADO el menú principal CUANDO haga clic en mantenimiento ENTONCES se muestra una lista de todos los mantenimientos ingresados y realizados. DADO una lista de todos los mantenimientos CUANDO escribo datos del bien en el cuadro de búsqueda ENTONCES se muestra la información. DADO el mantenimiento seleccionado CUANDO hago clic en la información del mantenimiento ENTONCES se muestra toda la información del mantenimiento. DADO el ingreso completo de los datos del mantenimiento CUANDO hago clic en el botón guardar ENTONCES se visualiza en la lista de mantenimientos. DADO los datos del mantenimiento CUANDO hago clic en el botón realizado ENTONCES se desactiva al mantenimiento.

ANEXO 8ProductBacklog

ProductBacklog Número Historia Prioridad Estimación 1 Acceso de usuarios 100 13 2 Ingreso de empleado 100 8 3 Buscar y editar datos del empleado 95 13 4 Eliminar empleado 95 13 5 Acceso de administrador 95 13 6 Ingreso de usuario 95 8 7 Agregar y editar permisos de usuarios 95 5 8 Eliminar usuario 90 5 9 Acceso total al módulo personal 90 13 10 Ingreso de proveedor 90 8 11 Buscar y editar datos del proveedor 85 13 12 Eliminar proveedor 85 13 13 Acceso total al módulo proveedor 85 13 14 Ingreso de bienes 85 13 15 Buscar y editar datos del bien 80 13 16 Eliminar bienes 75 13 17 Acceso total al módulo bienes 75 5 18 Ingreso de custodias 75 8 19 Buscar y editar datos de la custodia 75 13 20 Eliminar custodias 70 13 21 Acceso total al módulo custodia 70 8 22 Ingreso de mantenimientos 70 21 23 Buscar y editar datos del mantenimiento 70 8 24 Mantenimiento realizado 65 8 25 Acceso total al módulo mantenimiento 65 5

ANEXO 9 Sprint Backlog 9.1 Sprint 0 9.1.1 Sprint Backlog SPRINT BACKLOG Nº

Historia

Acceso de usuarios

Ingreso de empleado

Buscar y editar datos del empleado

Eliminar empleado

Objetivo del Sprint: Crear y publicar versión básica del módulo personal.

Estimación Categoría

Tarea

Responsable Estimación

Estado

Desarrollo

Configuración del O.S. para instalar Django 1.8

Hugo Silva

Realizado

Desarrollo

Instalación y configuración de PostgreSQL 9.6

Hugo Silva

Realizado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Migrar modelo a la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para el acceso de usuarios

Hugo Silva

Realizado

Desarrollo

Validar diseño y acceso de usuarios

Hugo Silva

Realizado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para el formulario

Hugo Silva

Realizado

Desarrollo

Validar diseño e ingreso de datos en formulario

Hugo Silva

Realizado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para listar y la buscar

Hugo Silva

Realizado

Desarrollo

Crear diseño web para el formulario

Hugo Silva

Realizado

Desarrollo

Validar diseño de listar, buscar y editar datos

Hugo Silva

Realizado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para listar y eliminar

Hugo Silva

Realizado

Desarrollo

Validar diseño de listar y eliminar datos

Hugo Silva

Realizado

Desarrollo

Agregar avance al sistema de control de versión

Hugo Silva

Realizado

93 9.1.2 Sprint Burndown Chart

Sprint Burndown Chart - Sprint 0

50 45

Puntos de Historia

40 35 30 25 20 15 10 5 0 1

Días

9.2 Sprint 1 9.2.1 Sprint Backlog SPRINT BACKLOG Nº

Historia

Objetivo del Sprint: Crear y publicar versión básica del módulo de administración.

Estimación Categoría Diseño

Acceso de administrador

Agregar y editar permisos de usuarios

Eliminar usuario

Realizado

Hugo Silva

Realizado

Hugo Silva

Realizado

Desarrollo

Registrar modelo en el panel de admin Crear superuser desde el manage del proyecto Sincronización del admin con la base de datos

Hugo Silva

Realizado

Diseño

Configuración de parámetros del admin

Hugo Silva

Realizado

Validar configuraciones

Hugo Silva

Realizado

Configuración de parámetros del admin

Hugo Silva

Realizado

Validar configuraciones

Hugo Silva

Realizado

Configuración de parámetros del admin

Hugo Silva

Realizado

Validar configuraciones

Hugo Silva

Realizado

Registrar modelo en el panel de admin Configurar parámetros en el modelo del admin

Hugo Silva

Realizado

Hugo Silva

Realizado

Validar configuraciones Agregar avance al sistema de control de versión

Hugo Silva

Realizado

Hugo Silva

Realizado

Desarrollo

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

Acceso total al módulo personal

Estado

Diseño

Ingreso de usuario

Crear Configuraciones para el panel de admin

Responsable Estimación Hugo Silva

Tarea

Desarrollo Desarrollo Desarrollo

94 9.2.2 Sprint Burndown Chart

Sprint Burndown Chart - Sprint 1

50 45

Puntos de Historia

40 35 30 25 20 15 10 5 0 1

Días

9.3 Sprint 2 9.3.1 Sprint Backlog SPRINT BACKLOG

Nº

Historia

Ingreso de 10 proveedor

Buscar y editar 11 datos del proveedor

Eliminar proveedor

Acceso total al 13 módulo proveedor

Objetivo del Sprint: Crear y publicar versión básica del módulo de proveedores.

Estimación Categoría

Tarea

Responsable Estimación

Estado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Migrar el modelo a la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para el formulario

Hugo Silva

Realizado

Desarrollo

Validar diseño e ingreso de datos en formulario

Hugo Silva

Realizado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para listar y la buscar

Hugo Silva

Realizado

Desarrollo

Crear diseño web para el formulario

Hugo Silva

Realizado

Desarrollo

Validar diseño de listar, buscar y editar datos

Hugo Silva

Realizado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para listar y eliminar

Hugo Silva

Realizado

Desarrollo

Validar diseño de listar y eliminar datos

Hugo Silva

Realizado

Diseño

Registrar modelo en el panel de admin

Hugo Silva

Realizado

Desarrollo

Configurar parámetros en el modelo del admin

Hugo Silva

Realizado

Desarrollo

Validar configuraciones

Hugo Silva

Realizado

Desarrollo

Agregar avance al sistema de control de versión

Hugo Silva

Realizado

95 9.3.2 Sprint Burndown Chart

Sprint Burndown Chart - Sprint 2

50 45

Puntos de Historia

40 35 30 25 20 15 10 5 0 1

Días

9.4 Sprint 3 9.4.1 Sprint Backlog SPRINT BACKLOG Nº Historia Estimación

Ingreso de bienes

Buscar y editar 15 datos del bien

Eliminar bienes

Acceso total al 17 módulo bienes

Objetivo del Sprint: Crear y publicar versión básica del módulo de bienes. Categoría

Tarea

Responsable Estimación

Estado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Migrar el modelo a la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para el formulario

Hugo Silva

Realizado

Desarrollo

Validar diseño e ingreso de datos en formulario

Hugo Silva

Realizado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para listar y la buscar

Hugo Silva

Realizado

Desarrollo

Crear diseño web para el formulario

Hugo Silva

Realizado

Desarrollo

Validar diseño de listar, buscar y editar datos

Hugo Silva

Realizado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para listar y eliminar

Hugo Silva

Realizado

Desarrollo

Validar diseño de listar y eliminar datos

Hugo Silva

Realizado

Diseño

Registrar modelo en el panel de admin

Hugo Silva

Realizado

Desarrollo

Configurar parámetros en el modelo del admin

Hugo Silva

Realizado

Desarrollo

Validar configuraciones

Hugo Silva

Realizado

Desarrollo

Agregar avance al sistema de control de versión

Hugo Silva

Realizado

96 9.4.2 Sprint Burndown Chart

Sprint Burndown Chart - Sprint 3

50 45

Puntos de Historia

40 35 30 25 20 15 10 5 0 1

Días

9.5 Sprint 4 9.5.1 Sprint Backlog SPRINT BACKLOG Nº

Historia

Ingreso 18 de custodias

Buscar y editar 19 datos de la custodia

Eliminar custodias

Acceso total al módulo custodia

Objetivo del Sprint: Crear y publicar versión básica del módulo de custodia.

Estimación Categoría

Tarea

Responsable Estimación

Estado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Migrar el modelo a la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para el formulario

Hugo Silva

Realizado

Desarrollo

Validar diseño e ingreso de datos en formulario

Hugo Silva

Realizado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para listar y la buscar

Hugo Silva

Realizado

Desarrollo

Crear diseño web para el formulario

Hugo Silva

Realizado

Desarrollo

Validar diseño de listar, buscar y editar datos

Hugo Silva

Realizado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para listar y eliminar

Hugo Silva

Realizado

Desarrollo

Validar diseño de listar y eliminar datos

Hugo Silva

Realizado

Diseño

Registrar modelo en el panel de admin

Hugo Silva

Realizado

Desarrollo

Configurar parámetros en el modelo del admin

Hugo Silva

Realizado

Desarrollo

Validar configuraciones

Hugo Silva

Realizado

Desarrollo

Agregar avance al sistema de control de versión

Hugo Silva

Realizado

97 9.5.2 Sprint Burndown Chart

Sprint Burndown Chart - Sprint 4

50 45

Puntos de Historia

40 35 30 25 20 15 10 5 0 1

Días

9.6 Sprint 5 9.6.1 Sprint Backlog SPRINT BACKLOG Nº

Historia Estimación

Ingreso de manteni mientos

Buscar y editar datos del manteni miento

Manteni miento 24 realizad o

Acceso total al módulo manteni miento

Objetivo del Sprint: Crear y publicar versión básica del módulo de mantenimiento. Categoría

Tarea

Responsable

Estimación

Estado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Migrar el modelo a la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para el formulario

Hugo Silva

Realizado

Desarrollo

Validar diseño e ingreso de datos en formulario

Hugo Silva

Realizado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para listar y la buscar

Hugo Silva

Realizado

Desarrollo

Crear diseño web para el formulario

Hugo Silva

Realizado

Desarrollo

Validar diseño de listar, buscar y editar datos

Hugo Silva

Realizado

Diseño

Crear diseño de la base de datos de la historia

Hugo Silva

Realizado

Diseño

Validar diseño de la base de datos

Hugo Silva

Realizado

Desarrollo

Crear diseño web para listar y desactivar alerta

Hugo Silva

Realizado

Desarrollo

Validar diseño de listar y eliminar datos

Hugo Silva

Realizado

Diseño

Registrar modelo en el panel de admin

Hugo Silva

Realizado

Desarrollo

Configurar parámetros en el modelo del admin

Hugo Silva

Realizado

Desarrollo

Validar configuraciones

Hugo Silva

Realizado

Desarrollo

Agregar avance al sistema de control de versión

Hugo Silva

Realizado

98 9.6.2 Sprint Burndown Chart

Sprint Burndown Chart - Sprint 5

50 45

Puntos de Historia

40 35 30 25 20 15 10 5 0 1

DĂas

ANEXO 10Diccionario de Datos

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas

DICCIONARIO DE DATOS

DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA WEB CON MODELO/VISTA/CONTROLADOR (MVC) PARA EL CONTROL DEL MANTENIMIENTO PREVENTIVO Y CORRECTIVO DE LOS BIENES DEL CUERPO DE BOMBEROS DEL GOBIERNO AUTÓNOMO DESCENTRALIZADO MUNICIPAL DE SANTO DOMINGO; PERIODO 2016 - 2017 Disertación de Grado previa a la obtención del título de Ingeniería de Sistemas y Computación

Línea de Investigación:

Estudio, Diseño e Implementación de Software

Autor: HUGO FERNANDO SILVA ALVAREZ

Director: Mg. LUIS JAVIER ULLOA MENESES Santo Domingo – Ecuador Agosto, 2017

100

En el diccionario de datos se encuentran detallados de forma lógica todos los elementos que forman parte y hará uso el sistema para el control del mantenimiento preventivo y correctivo de los bienes del cuerpo de bomberos. En él se muestra a manera de lista el nombre, descripción, tipo de datos, entre otros aspectos relevantes de los datos que pertenecen al sistema SIS-CO, con la finalidad de evitar ambigüedad en la definición los mismos. Para un mejor entendimiento, se procede a dividir la especificación del diccionario de datos en dos partes: la primera en base al apartado de Autenticación y Autorización; y la segunda en torno al manejo de las tablas y funcionalidades del Sistema de Inventario.

# 1 2 3 4 5 6 7 8

Nombre de la tabla auth_group

Sección

auth_group_permissions auth_permission auth_user auth_user_groups auth_user_user_permissions django_admin_log

Autenticación y Autorización

django_content_type django_migrations

Descripción

Tablas destinadas a la parte de administración, configuración y manejo del sistema. Se controla inicios de sesión, usuarios, grupos, permisos, log’s, sesiones, migraciones entre otros.

9 10 django_session 11 sistemaInventario_baja 12 sistemaInventario_bien 13 sistemaInventario_custodia 14 sistemaInventario_departamento 15 sistemaInventario_mantenimiento 16 sistemaInventario_motivobaja 17 sistemaInventario_persona 18 sistemaInventario_proveedor 19 sistemaInventario_tipobien 20 sistemaInventario_tipomantenimiento

Sistema de Inventario

Tablas destinadas al control de los mantenimientos preventivos y correctivos de los bienes (inventario) de la institución.

101

Autenticación y Autorización 

Tabla auth_group



Tabla auth_group_permissions

102



Tabla auth_permission



Tabla auth_user



Tabla auth_user_groups

103

ď&#x201A;ˇ

Tablaauth_user_user_permissions

ď&#x201A;ˇ

Tabla django_admin_log

104



Tabla django_content_type



Tabla django_migrations



Tabla django_session

105

Sistema de Inventario 

Tabla sistemaInventario_baja



Tabla sistemaInventario_bien

106



Tabla sistemaInventario_custodia



Tabla sistemaInventario_departamento



Tabla sistemaInventario_motivobaja

107



Tabla sistemaInventario_mantenimiento



Tabla sistemaInventario_persona



Tabla sistemaInventario_tipobien

108

ď&#x201A;ˇ

Tabla sistemaInventario_proveedor

ď&#x201A;ˇ

Tabla sistemaInventario_tipomantenimiento