Desarrollo e implementación de un sistema para la generación de turnos de los servicios del cuerpo 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

PORTADA

DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA PARA LA GENERACIÓN DE TURNOS DE LOS SERVICIOS DEL CUERPO DE BOMBEROS DEL GAD MUNICIPAL DEL CANTÓN DE SANTO DOMINGO DE LOS COLORADOS AÑO 2015

Trabajo de titulación previa a la obtención del título de Ingeniero de Sistemas y Computación

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

Autores: MANZANILLA ÁLVAREZ CRISTÓBAL FERNANDO OLIVO VEGA JULIO CÉSAR

Director: MG. RICHARD ESTALIN MAFLA TOBAR

Santo Domingo – Ecuador Agosto, 2016

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 PARA LA GENERACIÓN DE TURNOS DE LOS SERVICIOS DEL CUERPO DE BOMBEROS DEL GAD MUNICIPAL DEL CANTÓN DE SANTO DOMINGO DE LOS COLORADOS AÑO 2015 Línea de Investigación: Estudio, Diseño e Implementación de Software

Autores:

MANZANILLA ÁLVAREZ CRISTÓBAL FERNANDO OLIVO VEGA JULIO CÉSAR

Mg. Mafla Tobar Richard Estalin DIRECTOR DE LA DISERTACIÓN DE GRADO

Mg. Salazar Armijos Diego Ricardo CALIFICADOR

Mg. Córdova Gálvez Rodolfo Sirilo CALIFICADOR

Mg. Guaraca Moyota Margoth Elisa DIRECTOR DE LA ESCUELA DE SISTEMAS Santo Domingo – Ecuador Agosto, 2016

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD Yo, Cristóbal Fernando Manzanilla Álvarez portador de la cédula de ciudadanía No 171888572-4 declaro que los resultados obtenidos en la investigación que presento como informe final, previo 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.

Cristóbal Fernando Manzanilla Álvarez CI. 171888572-4

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD Yo, Julio César Olivo Vega portador de la cédula de ciudadanía No 210020014-2 declaro que los resultados obtenidos en la investigación que presento como informe final, previo 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.

Julio César Olivo Vega CI. 210020014-2

AGRADECIMIENTO Somos el deseo de emprendimiento, éxito, perseverancia, ética, liderazgo entre otros grandes rasgos humanos con los que nos ven nuestros docentes, somos el fruto de su vocación, la tierra donde con esmero y compromiso cultivan la semilla de la sabiduría, a ustedes estimados docentes que en cada mirada, palmada, sonrisa , dialogo tratan de trasmitir las pasión del conocimiento y la ética del profesionalismo, su cercanía, acompañamiento y carisma con el que hacen de su trabajo una conquista de grandes mentes han sido durante estos años un pilar fundamental para nuestra formación, hoy que estamos próximos a culminar los estudios universitarios recordamos con gratitud sus enseñanzas en la formación académica recibida. Queremos también dar un agradecimiento especial a nuestras familias que con su paciencia, confianza, amor y tiempo contribuyeron para que este anhelo sea una realidad que compartiremos juntos. Y finalmente es ese diálogo íntimo con Dios le agradecemos por las bendiciones vividas.

DEDICATORIA Con benevolencia dedicamos el trabajo realizado que ha significado un compromiso personal, a nuestros familiares padres, hermanos, esposas e hijos por el tiempo y apoyo brindado en la vida estudiantil, por ser esa fuente de motivación, voluntad, confianza y altruismo en nuestras vidas. El anhelo del conocimiento sin duda es un privilegio que enaltece el espíritu humano tras cada huella que deja la sana ambición de la sabiduría esta tesis está dedicado a aquellos compañeros con los que gozamos y construimos gratas experiencias en los salones de clase y pasillos universitarios, por esos momentos vividos, ideas compartidas, mano amiga con la que recorrimos los surcos del conocimiento.

vii

RESUMEN El presente proyecto de titulación pretende cubrir las necesidades del personal administrativo del Cuerpo de Bomberos del GAD Municipal de Santo Domingo con el fin de brindar adecuadamente al ciudadano servicios de prevención, capacitación, permisos de funcionamiento, entre otros que presta el referido Cuerpo de Bomberos, debido a la expansión urbana en las últimas décadas, la aglomeración de personas al Cuerpo de Bomberos es significativa y el sistema de atención actual es poco sofisticado en relación al empleo del tiempo y calidad en el servicio ofrecido, por esta razón se desarrolló e implementó el sistema informático denominado Turnos+, propuesta tecnológica orientada a resolver las necesidades que tiene el Cuerpo de Bomberos, administrando la atención de servicios mediante la entrega organizada de turnos. Para el desarrollo de la aplicación informática, se empleó la metodología de desarrollo en cascada mediante un enfoque cliente servidor para permitir el acceso multiusuario, como paradigmas de desarrollo se utilizó la POO (Programación Orientada a Objetos) mediante los lenguajes de desarrollo PHP, Angular con JavaScript estructurados bajo el patrón de diseño MVC (Modelo Vista Controlador). Una vez que se implementó Turnos+, se evidenció la mejora de la atención al cliente de manera ordenada y eficiente por parte de los funcionarios del Cuerpo de Bomberos.

viii

ABSTRACT The present research work aims to meet the needs of the administrative staff of the Cuerpo de Bomberos del GAD Municipal de Santo Domingo in order to provide the appropriate preventions services to the citizens, training, operating permission, among other services provided by the Cuerpo de Bomberos as result of the urban expansion in the last decades, the crowd of people in the Cuerpo de Bomberos is meaningful and the current attention system is not much sophisticated according to the time use and quality of the provided service, for this reason the computer system named Turnos+ was developed and implemented, technological proposal lead to solve the needs in the Cuerpo de Bomberos, managing the attention of services through the organized distribution of turns. For the development of the computer application, the waterfall methodology was applied with a focus customer server to allow the multiuser access, as paradigms of the development the POO (Object â&#x20AC;&#x201C; Oriented Programming) through the development languages PHP, Angular with JavaScrip structured with the MVC (Model View Controller). Once the Turnos+ system was developed, it was shown that the customer attention in an organized and efficient way was improved by the employees.

ÍNDICE DE CONTENIDOS PORTADA..................................................................................................................................I HOJA DE APROBACIÓN ....................................................................................................... II DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD ...................................... III DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD ......................................IV AGRADECIMIENTO .............................................................................................................. V DEDICATORIA ......................................................................................................................VI RESUMEN ............................................................................................................................ VII ABSTRACT.......................................................................................................................... VIII ÍNDICE DE CONTENIDOS ...................................................................................................IX ÍNDICE DE TABLAS ........................................................................................................... XII ÍNDICE DE FIGURAS ........................................................................................................ XIII ÍNDICE DE ANEXOS .......................................................................................................... XV 1.

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

PLANTEAMIENTO DEL PROBLEMA ......................................................................... 4

2.1. Antecedentes..................................................................................................................... 4 2.2. Problema de investigación ................................................................................................ 5 2.3. Justificación de la investigación ....................................................................................... 7 2.4. Objetivos de investigación ............................................................................................... 9 2.4.1. Objetivo General .............................................................................................................. 9 2.4.2. Objetivos específicos ........................................................................................................ 9

MARCO REFERENCIAL ............................................................................................. 10

3.1. Fundamentos teóricos ..................................................................................................... 10 3.1.1. Informática ..................................................................................................................... 10 3.1.2. Ingeniería de software .................................................................................................... 12 3.1.3. Base de datos .................................................................................................................. 26 3.1.4. Arquitectura Cliente – Servidor...................................................................................... 33 3.1.5. Ingeniería Web ............................................................................................................... 35 3.1.6. Herramientas de desarrollo web ..................................................................................... 35 3.1.7. Comparación de herramientas de desarrollo .................................................................. 35 3.1.8. Selección de las herramientas y lenguajes de programación .......................................... 37 3.2. Investigaciones o experiencias empíricas vinculadas con la investigación .................... 38 4.

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

4.1. Enfoque / Tipo de investigación ..................................................................................... 40 4.1.1. Diseño de la Investigación.............................................................................................. 40 4.1.2. Tipo de Investigación ..................................................................................................... 40 4.2. Población / Muestra ........................................................................................................ 43 a. La muestra ............................................................................................................................ 43 4.3. Técnicas e Instrumentos de recogida de datos ............................................................... 44 4.3.1. Entrevista ........................................................................................................................ 44 4.3.2. Encuesta .......................................................................................................................... 44 4.4. Técnicas de Análisis de Datos ........................................................................................ 45

RESULTADOS .............................................................................................................. 46

5.1. Discusión y análisis de resultados .................................................................................. 46 5.1.1. Análisis de la entrevista aplicada al analista de Sistemas .............................................. 46 5.1.2. Encuesta aplicada a la población Cuerpo de Bomberos del GAD Municipal del Cantón Santo Domingo ........................................................................................................................ 47 5.2. Proceso Cascada ............................................................................................................. 57 5.2.1. Análisis ........................................................................................................................... 57 5.2.2. Diseño ............................................................................................................................. 58 5.2.3. Codificación ................................................................................................................... 58 5.2.4. Pruebas ........................................................................................................................... 64 5.2.5. Implementación .............................................................................................................. 65 5.3. Conclusiones................................................................................................................... 66 5.4. Recomendaciones ........................................................................................................... 67 FUENTES BIBLIOGRÁFICAS .............................................................................................. 69 GLOSARIO ............................................................................................................................. 73 ANEXOS ................................................................................................................................. 75

xii

ÍNDICE DE TABLAS TABLA 1. COMPARATIVA ENTRE METODOLOGÍAS DE DESARROLLO DE SOFTWARE ............................................................................................................................ 19 TABLA 2. COMPARATIVA DE SOFTWARE SERVIDOR (HTTP) .................................. 36 TABLA 3. COMPARATIVA DE LENGUAJE DE PROGRAMACIÓN .............................. 36 TABLA 4. COMPARATIVA DE SISTEMAS GESTOR DE BASE DE DATOS ................ 37 TABLA 5. SUBTIPOS DE INVESTIGACIÓN DOCUMENTAL ......................................... 42 TABLA 6. TIPOS DE PREGUNTAS DEL CUESTIONARIO .............................................. 45 TABLA 7. ANÁLISIS DE LA PREGUNTA #1 ..................................................................... 47 TABLA 8. ANÁLISIS DE LA PREGUNTA #2 ..................................................................... 48 TABLA 9. ANÁLISIS DE LA PREGUNTA #3 ..................................................................... 49 TABLA 10. ANÁLISIS DE LA PREGUNTA #4 ................................................................... 50 TABLA 11. ANÁLISIS DE LA PREGUNTA #5 ................................................................... 51 TABLA 12. ANÁLISIS DE LA PREGUNTA #6 ................................................................... 52 TABLA 13. ANÁLISIS DE LA PREGUNTA #7 ................................................................... 53 TABLA 14. ANÁLISIS DE LA PREGUNTA #8 ................................................................... 54 TABLA 15. ANÁLISIS DE LA PREGUNTA #9 ................................................................... 55 TABLA 16. ANÁLISIS DE LA PREGUNTA #10 ................................................................. 56

xiii

ÍNDICE DE FIGURAS FIGURA 1. PROCESO DEL SOFTWARE - MODELO CASCADA .................................... 15 FIGURA 2. PROCESO DEL SOFTWARE - MODELO ESPIRAL ....................................... 16 FIGURA 3. FLUJO DEL PROCESO DEL SOFTWARE, FLUJO LINEAL Y PARALELO 17 FIGURA 4. PROCESO DEL SOFTWARE - MODELO INCREMENTAL .......................... 18 FIGURA 5. REPRESENTACIÓN DE CLASES EN UML .................................................... 21 FIGURA 6. REPRESENTACIÓN GRÁFICA: CASO DE USO – ACTOR .......................... 23 FIGURA 7. DIAGRAMA DE CASO DE USO ...................................................................... 24 FIGURA 8. DIAGRAMA DE CLASES, ESTRUCTURA ..................................................... 25 FIGURA 9. REPRESENTACIÓN DE LAS ENTIDADES DEL MODELO ENTIDAD RELACIÓN ............................................................................................................................. 30 FIGURA 10. ARQUITECTURA CLIENTE - SERVIDOR IMPLEMENTANDO APACHE .................................................................................................................................................. 34 FIGURA 11. HERRAMIENTAS UTILIZADAS.................................................................... 37 FIGURA 12. RESULTADO DE LA TABULACIÓN DE LA PREGUNTA NÚMERO 1. ... 47 FIGURA 13. RESULTADO DE LA TABULACIÓN DE LA PREGUNTA NÚMERO 2. ... 48 FIGURA 14. RESULTADO DE LA TABULACIÓN DE LA PREGUNTA NÚMERO 3. ... 49 FIGURA 15. RESULTADO DE LA TABULACIÓN DE LA PREGUNTA NÚMERO 4. ... 50

xiv

FIGURA 16. RESULTADO DE LA TABULACIÓN DE LA PREGUNTA NÚMERO 5. ... 51 FIGURA 17. RESULTADO DE LA TABULACIÓN DE LA PREGUNTA NÚMERO 6. ... 52 FIGURA 18. RESULTADO DE LA TABULACIÓN DE LA PREGUNTA NÚMERO 7. ... 53 FIGURA 19. RESULTADO DE LA TABULACIÓN DE LA PREGUNTA NÚMERO 8. ... 54 FIGURA 20. RESULTADO DE LA TABULACIÓN DE LA PREGUNTA NÚMERO 9. ... 55 FIGURA 21. RESULTADO DE LA TABULACIÓN DE LA PREGUNTA NÚMERO 10. . 56 FIGURA 22. MODELO FÍSICO DE LA BASE DE DATOS ................................................ 60 FIGURA 23. MODELO LÓGICO DE LA BASE DE DATOS .............................................. 61

ÍNDICE DE ANEXOS ANEXO 1. ENCUESTA A SERVIDORES PÚBLICOS DEL CUERPO DE BOMBEROS DEL GADM SANTO DOMINGO ANEXO 2. ESPECIFICACIÓN DE REQUERIMEINTOS DE SOFTWARE ANEXO 3. MODELADO Y ESTRUCTURA DE LA BASE DE DATOS ANEXO 4. PROGRAMACIÓN PHP ANEXO 5. MANUAL DE USUARIO ANEXO 6. PRUEBAS DEL SISTEMA ANEXO 7. CAPACITACIÓN DEL SISTEMA ANEXO 8. CARTA DE IMPACTO ANEXO 9. ACTA ENTREGA RECEPCIÓN

1. INTRODUCCIÓN El cuerpo de Bomberos del GAD Municipal de Santo Domingo de los Colorados ha visto la necesidad de implementar un sistema informático para la generación de turnos de los servicios que brindan a la ciudadanía, debido a que actualmente dicha institución carece de un sistema gestor de turnos que permita la manipulación de información de los ciudadanos y ofrezca una mejor atención, es por ello que el presente plan de disertación está orientado al análisis, diseño, codificación, pruebas e implementación de un sistema informático orientado a los servicios ofrecidos por el Cuerpo de Bomberos Municipal del cantón Santo Domingo Compañía Santa Martha. El servicio público del Cuerpo de Bomberos del GAD Municipal de Santo Domingo mantiene una constante demanda de asistencia a toda la población de la provincia, siendo gestores de ayuda comunitaria para la seguridad y salvaguardia de la vida misma. Una visión estratégica de las funciones que competen a las áreas, PRIMERA Y SEGUNDA JEFATURA conjuga la integración de la calidad y eficacia en el aporte individual y colectivo, contemplando la organización como punto de partida dentro del proceso de atención a los requerimientos de la ciudadanía, de esta forma nace la necesidad de desarrollar e implementar un sistema informático que contribuya a la mejora de la atención de los servicios que ofrece la institución y la organización de la misma. A continuación, se detallan las diferentes secciones por las que se constituye la presente disertación de grado. En el segundo capítulo en la sección 2.1 se plantea los antecedentes del problema de investigación, detalla los orígenes de la empresa pública y las limitaciones o necesidades en la prestación de servicio a la ciudadanía que constituyen el factor fundamental para la creación de un sistema de software funcional que cumpla con los requerimientos puntuales de asistencia

a la organización y atención al público que recure a la institución. En la sección 2.2 se describe el problema de investigación y se detalla la manera en que se va a dar solución al problema mencionado, dentro de esta sección se plantea las preguntas básicas de investigación, las mismas que permitirá obtener los objetivos del desarrollo del sistema desde una perspectiva interrogativa ejecutando un sistema secuencial de preguntas referidas a las características funcionales del software y a su respectiva aplicación en un contexto institucional determinado. En la sección 2.3 se detalla la justificación de la investigación, donde se argumenta el motivo por el cual se va a desarrollar el software, incluyendo un estudio en donde se determine la viabilidad del proyecto. En la sección 2.4 se plantea los objetivos de la investigación como son el objetivo general que establece los procesos y funcionamiento del sistema, así como los objetivos específicos en los que se puntualizan los métodos para desarrollar el sistema de acuerdo a la metodología a utilizarse. El tercer capítulo hace referencia a los fundamentos teóricos necesarios que sustentes los aspectos relevantes para el desarrollo e implementación del sistema informático. Seguidamente se presenta una visión global del problema estudiado, frente a las posibles herramientas de desarrollo que aportarán el mayor beneficio al sistema. El capítulo correspondientes a la metodología se detalla los tipos de investigación estudiados y se establece el tipo de investigación apropiado para el proyecto investigativo, de la misma manera esta sección contempla la definición de la población y muestra involucrada en el proceso de recolección de información primaria, así como también las técnicas e instrumentos de recogida y análisis de los datos empleados en el proceso respectivamente y finalmente se detalla la metodología en cascada que se utilizará para el desarrollo del sistema de software.

En el quinto capítulo se plasman los resultados obtenidos con la investigación, se describe la secuencia de actividades realizadas según la metodología de desarrollo de software escogida, todas sus etapas detallan paso a paso la creación de la aplicación informática Turnos+.

2. PLANTEAMIENTO DEL PROBLEMA 2.1. Antecedentes El Cuerpo de Bomberos del GAD Municipal de cantón Santo Domingo (CB-GADM-SD) es una empresa pública, con base principal en el cantón Santo Domingo, provincia Santo Domingo de los Tsáchilas, fue creada alrededor de los años cincuenta cuando Santo Domingo de los Colorados era una parroquia del cantón Quito. De acuerdo a la visión del Cuerpo de Bomberos, esta institución se constituirá en el 2017 en una entidad de excelencia y calidad en los servicios que brinda, mediante el mejoramiento continuo de sus procesos, 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. El 24 de agosto de 2001 fue aprobada por el Consejo del Gobierno Municipal la Ordenanza de institucionalización del Cuerpo de Bomberos del Gobierno Autónomo Descentralizado Municipal de Santo Domingo. Es así que al pasar del tiempo el Cuerpo de Bomberos se va consolidando como institución para estar alerta al servicio de la comunidad. La afluencia constante de personas que requieren el servicio del cuerpo de Bomberos exige procesos de atención al cliente más innovadores, la implementación de un software que genere turnos de atención, reporte estadístico y banco de datos, es un recurso favorable en el trabajo desarrollado por el personal para que ejecute satisfactoriamente sus actividades en relación a la calidad, eficiencia y eficacia, de esta manera se reduce el margen de inconvenientes en el proceso.

2.2. Problema de investigación El Cuerpo de Bomberos del GAD Municipal de Santo Domingo presta servicio de seguridad y prevención de siniestros a toda la población local, está organizado en diferentes departamentos que cumplen con funciones específicas tratando de cubrir y dar respuestas a las necesidades de la ciudadanía, la aglomeración de personas que asisten a solicitar los servicios del cuerpo de bomberos es significativa, el personal administrativo ha generado durante estos años documentos y formatos que funcionan como herramientas para la recepción de información, base de datos, entregas de datos, generación de turnos entre otras actividades que ayudan a la organización del proceso de prestación de servicio a la comunidad, los registros de atención al cliente y asignación de turnos diariamente son llevados de forma manual siendo esta una manera poco confiable de registrar información importante por las características y eventualidades como el deterioro propio del papel, letra poco legible incluso en casos extremos se ha presentado la pérdida de documentación a la vez que incide en un gasto a la empresa y causa un impacto negativo hacia el medio ambiente por el uso desmesurado y prescindible de papel; entre otros acontecimientos que no permiten contar con informes oportunos y seguros cuando la institución requiera de estos, al ser desarrollada la documentación de manera manual el tiempo empleado es mayor imposibilitando la atención a todos los ciudadanos, además de impedir al personal de realizar otras actividades afectando la productividad de los mismos, es así como la mala administración de los recursos de la empresa ha generado la interrogante de saber si es necesaria la automatización de dichos procesos. Los servidores públicos del cuerpo de bomberos ocasionalmente llevan registros de las actividades que diariamente desarrollan y la acumulación de documentos no permite tener una visión global del proceso ejecutado y una organización adecuada que permita establecer informes mensuales de las actividades y un control respectivo de las mismas.

El desarrollo e implementación del sistema de software Turnos+, cumple con los requerimientos, al mismo tiempo de ofrecer una respuesta rápida y efectiva a las necesidades correspondientes a los servicios que se ven en la necesidad de generar nuevos turnos. El software Turnos+ también facilita el almacenamiento masivo de información, para su clasificación y desarrollo se utilizará un sistema gestor de Base de datos llamado PostgreSQL. La falta de un sistema gestor de turnos para la prestación de servicios por parte del cuerpo de bomberos de la ciudad de Santo Domingo hacía la ciudadanía ha provocado un desmedido colapso de atención a la hora de brindar sus servicios, además de no es posible estimar tiempos ni si quiera aproximados para el establecimiento de un control de registros, merced de ello se genera el solapamiento en las actividades encargadas a los agentes de las instalaciones, por motivo que los trabajos los realiza de forma manual lo que a su vez provoca el embotellamiento entre dar solución a una necesidad y otra; partiendo desde este punto se plantean las preguntas básicas de la investigación tratando de solventar dichas necesidades en etapas posteriores, a continuación se detallan dichas interrogantes: 

¿Cuáles son los beneficios de la ejecución del sistema para la Gestión de Turnos de los Servicios ofrecidos a la ciudadanía para una mejor organización de los procesos de atención al cliente del Cuerpo de Bomberos del GAD Municipal del Cantón Santo Domingo?



¿La implementación del sistema informático mejorará la productividad del personal que labora en las áreas de atención a la ciudadanía?



¿El software implementado cumplirá con los beneficios de uso esperado en relación al uso del tiempo permitiendo organizar adecuadamente la prestación de un servicio a la comunidad?



¿Qué tipo de cambio percibirá la ciudadanía con la implementación del aplicativo en las instalaciones del cuerpo de bomberos?

2.3. Justificación de la investigación El creciente desarrollo urbano ha multiplicado las necesidades de seguridad en la sociedad, esto exige que empresas públicas y de protección ciudadana como el Cuerpo de bomberos tengan afluencia masiva de personas que a diario asisten a sus oficinas a solicitar los servicios de esta importante institución que cumple con unos de los roles más apremiantes en la comunidad, la protección a la ciudadanía frente a los desastres acontecidos. Los usuarios del servicio que presta esta entidad requieren de un trato especializado, los mismos que tienen que brindar seguridad y confianza, así como también una presentación idónea de la empresa en un marco de innovación y calidad en la asistencia. El talento humanos que labora en la entidad requiere de recursos y herramientas tecnológicas que ayuden a un mejor uso del tiempo y acceso a un ambiente de trabajo que desarrolle su potencial garantizando la ejecución de un trabajo de eficiencia y eficacia, para dar una respuesta a estas necesidades actuales se plantea el desarrollo e implementación de un sistema de información funcional, es así como nace Turnos+, una herramienta para la gestión de turnos; optimizar y organizar competentemente la atención en los servicios del Cuerpo de Bomberos del Cantón de Santo Domingo de los Colorados, servirá como estrategia para brindar las condiciones oportunas de equidad frente a las demandas de prevención , control y protección de la ciudadanía y un ambiente laboral idóneo en las áreas de primera jefatura y segunda jefatura. Los sistemas de software que viabilizan una mejor atención al cliente, en la actualidad son de gran importancia tanto en entidades públicas como en entidades privadas ya que buscan disponer de una adecuada gestión de los servicios o bienes ofrecidos a la comunidad, los

programas utilizados son soportes de sistematización e interpretación de información selecta para un proceso de evaluación continuo y efectivo. De acuerdo a lo expuesto anteriormente se concluye que la implementación de Turnos+ es un recurso indispensable para la gestión de los servicios ofrecidos a la ciudadanía, ya que constan como beneficiarios directos los servidores públicos del Cuerpo de Bomberos del GAD Municipal de Santo Domingo de los Colorados y la ciudadanía en general, en base al uso de los servicios que presta esta notable entidad pública. Con la implementación de Turnos+ se optimiza la distribución de actividades y administración de información fortaleciendo el sistema de comunicación y garantizando la igualdad en el trato porque mediante la red local y el empleo de una interfaz gráfica el cliente podrá visualizar en una pantalla la asignación de turnos y la atención de los mismos. La factibilidad del desarrollo del sistema se sustenta en los recursos con los que cuenta el Cuerpo de Bomberos, la estructura y organización existente, la aprobación y sobre todo la aceptación de las respectivas autoridades hacia la adopción de la tecnología como punto primordial en el desarrollo productivo, por otro lado Turnos+ ofrece un impacto positivo con el medio ambiente al llevar los registros de manera lógica, no solo se encuentran correctamente organizados sino también evita el desgaste innecesario de recursos físicos como papel y material complementario. Como es de conocimiento público el Gobierno Nacional del Ecuador aprobó en el año 2013 el “Plan Nacional del Buen Vivir”, mismo que consta con 12 objetivos donde se prevé construir una sociedad equitativa eliminando la mala distribución de los recursos del País; el proyecto de tesis, se alinea específicamente con el objetivo 11, “Asegurar la soberanía y eficiencia de los sectores estratégicos para la transformación industrial y tecnológica”.

2.4. Objetivos de investigación 2.4.1. Objetivo General Implementar un sistema informático para el manejo y generación de turnos de los servicios ofrecidos por el cuerpo de bomberos municipal a la ciudadanía del cantón Santo Domingo de los Colorados. 2.4.2. Objetivos específicos 

Analizar los procesos de atención del Cuerpo de Bomberos del GAD Municipal de Santo Domingo de los Colorados a la ciudadanía, respecto a la generación de turnos para especificar los requerimientos del software obteniendo la información la aplicación denominada Turnos+.



Diseñar los distintos modelos/entidades del sistema, además de los módulos del área de servicio al cliente.



Codificar los módulos del sistema Turnos+ en base a la información recolectada en la fase de análisis.



Ejecutar pruebas y análisis del funcionamiento del sistema.

 Entregar el sistema informático denominado Turnos+ al Cuerpo de Bomberos.

3. MARCO REFERENCIAL 3.1. Fundamentos teóricos En la presente sección se presentarán las conceptualizaciones de los termínanos que serán empleados en el desarrollo del sistema informático Pera el estudio de campo se empleará información de fuentes bibliográficas y lincográficas de distintos autores cuyos aportes han sido fundamentales para las técnicas de estudias requeridas en el desarrollo del software, tales como: Pressman Roger pilar fundamental para Ingeniería de software y temas afines con el desarrollo y control de sistemas de calidad; en cuanto información en base de datos, control y manipulación se cuenta con una gran comunidad de desarrolladore de PostgreSQL y MySQL. 3.1.1. Informática 3.1.1.1. Definición Es la disciplina que estudia el tratamiento automático de la información empleando dispositivos electrónicos. Para ello los sistemas informáticos deben realizar tres tareas fundamentales: 

Entrada de información; procesamiento o tratamiento de información; salida y/o presentación de resultados. (Desongles Corrales & Moya Arribas, 2006).

3.1.1.2. Hardware Conjunto de dispositivos físicos que permiten almacenar, procesar y comunicar los datos. Hace referencia a los dispositivos donde reside la base de datos, dispositivos de entrada y de salida y la misma computadora en sí. (Camazón, 2011).

3.1.1.3. Software Elemento lógico que se define como conjunto de órdenes e instrucciones escritas para llevar a cabo un objetivo (Camazón, 2011). Software es un conjunto de programas escritos para un ordenador, desarrollado y orientado a cumplir con tareas específicas, para ser implementado y ejecutado. 3.1.1.4. Usuarios Aquel individuo que hace uso de un servicio, sistema o equipo informático, donde sus tareas a realizar son, buscar información en un sistema, acceder a la información que muestra el sistema. Un usuario no siempre resulta ser una persona, esto significa, que el mismo sistema puede actuar como usuario y llevar a cabo tareas automáticas. 3.1.1.4.1 Tipos de usuario y características  Usuario administrador: Usuario con todos los privilegios de un sistema. Gestiona los recursos existentes en una aplicación informática.  Usuario registrado: Usuario con permisos específicos dentro de un sistema.  Usuario anónimo: Usuario con el único permiso de ver información. 3.1.1.4.2 Privilegios de usuarios Son los otorgados a un usuario o grupo de usuarios para realizar una determinada tare, por ejemplo:  Un usuario con permisos de solo lectura, comúnmente es aquel que navega por un sitio web.  El rol administrador podrá realizar cambios en el sistema.

3.1.2. Ingeniería de software 3.1.2.1. Definición Está formada por un conjunto de métodos (prácticas) y un arreglo de herramientas que permite a los profesionales elaborar software de cómputo de alta calidad (Pressman, 2010, pág. 1). Según Pressman, es una disciplina o área de la informática o ciencia de la computación, que ofrece técnicas y métodos para desarrollar y mantener sistemas informáticos. 3.1.2.2. Especificación de requerimientos de software (SRS) Requirements Specification Of Software en inglés, es el documento legal donde se especifican detalladamente los aspectos, conceptos y términos en el desarrollo de una aplicación informática, también se plasman los recursos que será necesarios para el buen funcionamiento del software, así como de toda información que sirva de soporte y guía para fases posteriores del proyecto. El uso del SRS es una de las buenas prácticas, para solucionar el solapamiento de falta de información de todas las partes involucradas en el desarrollo de todo sistema (Pressman, 2010). 3.1.2.3. Ciclo de vida del software El ciclo de vida del software define las distintas fases por las que atraviesa el mismo, garantizar que el software cumpla satisfactoriamente con los requerimientos solicitados por el usuario. Todo proyecto sigue con un proceso: planificación, estimación de recursos, control y evaluación del proyecto (Jaramillo, 2012). 3.1.2.3.1 Fases del ciclo de vida En el ciclo de vida del software se establecen las siguientes fases:

3.1.2.3.1.1. Análisis En esta fase es necesario la recolección de los requerimientos funcionales y no funcionales, para que el desarrollador comprenda la naturaleza de los programas a construirse, la función, comportamiento, rendimiento e interconexiones requeridos, de manera que se obtenga la información suficiente para brindar la solución. Esta etapa es conocida como la del “¿QUÉ se va a solucionar?” (Jaramillo, 2012). Pressman (2010) define a la etapa de análisis como el proceso de descubrimiento, refinamiento, modelado y especificación. Se analizan soluciones alternativas y se asignan a diferentes elementos del software. 3.1.2.3.1.2. Diseño La información recolectada es importante para poder determinar las estrategias a utilizar hacia la generación de dicha solución. Esta etapa es conocida bajo el “¿CÓMO se va a solucionar?” (Jaramillo, 2012). Por otro lado, Pressman (2010) asegura que, el diseño del software representa el establecimiento de las estructuras de datos, la arquitectura general del software, representaciones de interfaz y algoritmos. Generalmente la fase de diseño produce un diseño de datos, un diseño arquitectónico, un diseño de interfaz, y un diseño procedimental. 3.1.2.3.1.3. Codificación Actividad que permite convertir el diseño, las ideas y requerimientos recopilados en las etapas anteriores, en un símbolos, textos o traducidos legibles y entendibles para la máquina. La codificación comprende desde la generación de los ambientes virtuales hasta alcanzar y modelar los comportamientos a dichos ambientes.

3.1.2.3.1.4. Pruebas Las pruebas del software son lanzadas inmediatamente una vez que se construye el código. Pressman (2010) sustenta que la etapa de pruebas se centra en los procesos lógicos internos y externos del software, asegurando que todos los requerimientos se han comprobado, es decir, se aplican o se realizan las pruebas (de carga, de stress, de picos, etc) que se considere necesarias para detectar y evitar futuros errores. 3.1.2.3.1.5. Mantenimiento Todo sistema informático tiende a sufrir cambios, es por ello que un sistema bien estructurado desde su fase inicial no se verá afectado a la escalabilidad o transformación alguna en su vista o su funcionalidad, es por ello que en el desarrollo de software se espera que las aplicaciones informáticas se adecuen estrechamente a las necesidades del usuario (Pressman, 2010). 3.1.2.4. Metodologías de desarrollo de software Los nuevos conceptos y metodologías existentes en otras áreas del desarrollo de software surgen de la necesidad de desarrollar proyectos de una forma constituida y óptima. Estos nuevos conceptos derivaron en el proceso de software por etapas, de manera secuencial, que mejoró la metodología de desarrollo de software. Para obtener un software eficiente al final debe cumplir con periodos de entrega, para ello se hace una planificación total del proyecto, asignando rigurosamente roles, cronogramas de actividades, y funciones; una vez establecidos todos los parámetros comienza el ciclo de desarrollo del software (Sommerville, 2005).

La aplicación metodologías tradicionales son fuertemente utilizadas debido a que presentan gran robustez en las etapas y por tener una idea clara de lo que se va a desarrollar, el número de equipos involucrados y tiempos de entrega prestablecidos desde las primeras etapas hasta el final del desarrollo del software. Existe un sinnúmero de metodologías de desarrollo, pero, en el presente apartado se referencia únicamente el ámbito de las metodologías tradicionales. 3.1.2.4.1 Modelo en Cascada Es distinguido también como ciclo de vida clásico, por los procesos que atraviesa el software en su desarrollo, al finalizar una etapa se da paso a otra simulando una cascada. Este método organiza rígidamente las etapas del proceso para el desarrollo de software, por lo que para dar paso al inicio de una nueva etapa debe estar completamente terminada la fase anterior (Sommerville, 2005). El modelo en cascada toma las actividades fundamentales del proceso, y luego los representa como fases separadas del proceso, tal como especificación de requerimientos, diseño de software, implementación, pruebas, etcétera (Sommerville, 2005). El modelo de la cascada, sugiere un enfoque sistemático y secuencial para el desarrollo del software, que comienza con la especificación de los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado como se detalla en la siguiente figura (Pressman, 2010).

Figura 1. Proceso del software - Modelo Cascada Fuente: Pressman, R.S., (2010). Ingeniería del Software: Un enfoque práctico. México: Mc Graw Hill.

3.1.2.4.2 Modelo en espiral Propuesto por Barry Boehm, es un generador de modelo de proceso impulsado por el riesgo, que se usa para guiar la ingeniería concurrente con participantes múltiples de sistemas intensivos en software. Tiene dos características distintivas principales. La primera es el enfoque cíclico para el crecimiento incremental del grado de definición de un sistema y su implementación, mientras que disminuye su grado de riesgo. La otra es un conjunto de puntos de referencia de anclaje puntual para asegurar el compromiso del participante con soluciones factibles y mutuamente satisfactorias (Pressman, 2010). El modelo en espiral posee una diferencia ante los demás modelos, pues toman en cuenta el riesgo, donde un bucle representa un conjunto de actividades y estas se forman en una espiral. Cuando se ha cumplido una espiral se numeran todas las fuentes de riesgo, el siguiente paso es dar solución a los riesgos y así se da inicio a otra vuelta en espiral hasta llegar un momento en que el producto desarrollado sea aceptado y no necesite otro ciclo para seguir mejorándose.

Figura 2. Proceso del software - Modelo espiral Fuente: Pressman, R.S., (2010). Ingeniería del Software: Un enfoque práctico. México: Mc Graw Hill.

3.1.2.4.3 Modelo incremental El modelo incremental surge como respuesta a las deficiencias del modelo tradicional de cascada, comprende un conjunto de tareas reunidas en pequeñas etapas que se repiten hasta cumplir un objetivo, actualmente es muy utilizado, debido a que se relaciona con técnicas modernas de desarrollo de software. El desarrollo iterativo contiene varias etapas en cada incremento, las cuales inician con el análisis y terminan con la implementación y aprobación del sistema. Este modelo combina elementos de los flujos de proceso lineal y paralelo (ver en figura 3). En relación con la figura 4, el modelo incremental utiliza secuencias lineales en forma escalonada a medida que avanza el cronograma de actividades. En cada secuencia lineal se producen incrementos de software funcionales idóneos para la entrega al usuario final (PostgreSQL, 2010).

Figura 3. Flujo del proceso del software, Flujo lineal y paralelo Fuente: Pressman, R.S., (2010). Ingeniería del Software: Un enfoque práctico. México: Mc Graw Hill.

Figura 4. Proceso del software - Modelo incremental Fuente: Pressman, R.S., (2010). Ingeniería del Software: Un enfoque práctico. México: Mc Graw Hill.

Para una mejor comprensión de la operación de los modelos, se puede apreciar que la implementación del modelo incremental se realiza cuando los requerimientos iniciales del software están bien definidos, pero el alcance o entrega del proyecto imposibilita un proceso lineal. Por otro lado, la implementación del modelo incremental es viable cuando se desconoce que haya que otorgar rápidamente cierta funcionalidad del sistema, aunque esta sea limitada para los usuarios y que posteriormente la misma sea mejorarla en las entregas posteriores del sistema. 3.1.2.4.4 Comparativas entre metodologías de desarrollo de software Para un correcto desarrollo de software desde sus etapas iniciales se debe poseer varios manuales y conceptos que al integrarlos hacen que la implementación del proyecto sea o no exitoso. Cada metodología refleja etapas, utilización de herramientas y procesos diferentes, como se detalla en la tabla comparativa a continuación, la misma que detalla las ventajas que ofrece cada técnica de desarrollo:

19 Tabla 1. Comparativa entre metodologías de desarrollo de software Comparativa entre metodologías de desarrollo de software Metodologías de desarrollo de software Espiral

Cascada

Tiene el potencial para hacer un desarrollo rápido de versiones cada vez más completas

Requerimientos están bien definidos y tienen una estabilidad razonable

Toman en cuenta el riesgo en cada etapa

Número limitado de nuevos esfuerzos de desarrollo

Elaboración de proyectos largos, caros y complicados como por ejemplo la creación de sistemas operativos o sistemas de n módulos

Es óptimo en ocasiones cuando deben hacerse adaptaciones o mejoras bien definidas a un sistema ya existente

Flujo del proceso paralelo

Flujo del proceso lineal Incremental

Requerimientos iniciales del razonablemente bien definidos

software

están

Flujo del proceso lineal y paralelo

El alcance general del esfuerzo de desarrollo imposibilita un proceso lineal (poco tiempo para entrega) Nota. Elaborado por: F. Manzanilla; J. Olivo

Considerando la las principales características de las metodologías expuestas, se ha decidido por establecer como metodología de desarrollo de software para el sistema informático generador y control de turnos en el Cuerpo de Bomberos de la Ciudad de Santo Domingo de los Colorados, al modelo en cascada, esta elección tiene en cuenta aspectos como: el presente proyecto cuenta con requerimientos claramente definidos desde el inicio de proceso, desde la entrevista con el director del área de sistemas a cargo del proyecto, los tiempos de entrega son completamente razonables, y en cuanto equipo de desarrollo se cuenta con el apropiado de acuerdo a la dimensión del proyecto. 3.1.2.5. Paradigmas de programación 3.1.2.5.1 Definición Los paradigmas de programación representan una perspectiva a las buenas prácticas para el diseño de soluciones frente a una temática determinada. Cada paradigma es un caso de estudio diferente, cuenta con sus propias etapas o períodos que lo conforman para brindar una solución.

Sin embargo, los lenguajes de programación parten o se refuerzan de paradigmas para sustentar la construcción de un esqueleto funcional. 3.1.2.5.2 Programación estructurada Se fundamenta en el teorema del programa estructurado, que establece que cualquier programa con una entrada y una salida es semejante a un programa que contiene solo las tres estructuras lógicas: Trabaja secuencia, selección, e interacción. 3.1.2.5.3 Programación orientada a objetos Es un método de implementación donde los programas se organizan como una colección cooperativa de objetos, los objetos no son más que una representación de la instancia de clases, y cuyas clases se encuentran unidas mediante relaciones. Las principales características de este paradigma son la inclusión de técnicas como herencia, abstracción, polimorfismo y encapsulamiento. Un lenguaje orientado a objetos tiene tres características básicas: debe estar basado en objetos, basado en clases y capaz de soportar herencia de clases, además debe ofrecer las siguientes facilidades al desarrollador: 

Comprender mejor la calidad del producto; estimar la efectividad del proceso; mejorar la calidad del trabajo realizado en el nivel del proyecto

3.1.2.5.3.1. Objetos Es el pilar de toda programación orientada objetos, una representación tangible del mundo real, de algo que se puede extraer ciertas cualidades notables. Un objeto es algo que se visualiza, se utiliza y juega un rol dentro de la funcionalidad de un conjunto de operaciones. Si se programa con enfoque orientado a objetos, se intentan descubrir e implementar objetos que juegan un rol en el problema a resolver.

3.1.2.5.3.2. Clases Colección de variables y funciones que trabajan con otras entidades, su comportamiento es de ser intermediarias entre una abstracción y los clientes que vayan a utilizarla, de forma que la clase muestra: visión externa de comportamiento, que enfatiza la abstracción escondiendo su estructura y secretos de comportamiento, dicho en otras palabras, las clases no son más que como un conjunto de objetos que comparten una estructura y comportamiento en común. “Una clase es un concepto OO que encapsula los datos y abstracciones procedurales requeridos para describir el contenido y el comportamiento de alguna entidad del mundo real” (Pressman, 2010, pág. 744).

Figura 5. Representación de clases en UML Fuente: Pressman, R.S., (2010). Ingeniería del Software: Un enfoque práctico. México: Mc Graw Hill.

3.1.2.5.3.3. Atributos Los atributos se vinculan a las clases y describen a la misma de algún modo, entonces, un atributo puede tomar un valor definido en representación a la clase. Por ejemplo, suponga que una clase vehículo, que tiene un atributo color, tal atributo le da un representación abstracta de la realidad (Pressman, 2010).

3.1.2.6. Lenguaje UML y procesos de desarrollo 3.1.2.6.1 Definición El lenguaje UML (Lenguaje Unificado para la construcción de modelos) estandariza los artefactos y notación que se verán envueltos en el desarrollo de un sistema informático, esto incluye la especificación, visualización y construcción de los mismos en un sistema notacional destinado a los sistemas que utilizan los conceptos de orientación a objetos. El uso de lenguaje UML garantiza: 

Aumentar las probabilidades en la aceptación de la notación estándar del modelo, sin verse en la necesidad de un proceso oficial, es decir, no se requiere un estricto régimen de uso de herramientas y componentes por el mismo.



Permite variación y depende de las habilidades del personal, de la razón empírica de las partes involucradas en el desarrollo, de la naturaleza del proyecto, y de otros factores (Craig, 2003).

Para Pressman (2010), el uso del lenguaje UML en ingeniería de sistemas, es como los arquitectos de edificios crean planos para que los use una compañía constructora. Por otro lado, afirma que, si entiende el vocabulario del UML, entonces puede comprender y especificar con mucha más facilidad un sistema, y explicar su diseño a otros. 3.1.2.6.2 Casos de uso El caso de uso es un documento narrativo que describe la secuencia de los eventos por los que atravesará un actor, a menudo se los utiliza para complementar el proceso justificativo de un sistema. Estos no son necesariamente los requerimientos ni especificaciones funcionales del sistema, sino, especifican y narran de manera técnica los requerimientos para el desarrollo de software (Craig, 2003).

En la figura a continuación se observa la representación gráfica de los casos de uso. Dentro del lenguaje UML y caso de uso interviene un concepto importante que es el Actor. 

Actor: Es una entidad externa al sistema, la cual se encarga de generar los diferentes eventos dentro de las historias de caso de uso declaradas, en la figura a continuación se detalla gráficamente la relación del actor con el caso de uso.



Caso de uso: Relación directa con el actor para poder transitar de un estado a otro de tal modo que se determine la funcionalidad de la aplicación informática.

Figura 6. Representación gráfica: Caso de uso – Actor Elaborado por: F. Manzanilla; J. Olivo

3.1.2.6.2.1. Diagramas de caso de uso El diagrama de caso de uso explica gráficamente un conjunto de casos de uso y la relación que tienen los mismos con los actores. Dicha relación entre ellos está representada con líneas de comunicación, donde indica el flujo de la información.

Figura 7. Diagrama de caso de uso Fuente: Pressman, R.S., (2010). Ingeniería del Software: Un enfoque práctico. México: Mc Graw Hill.

3.1.2.6.2.2. Diagramas de clase Los diagramas de clase también pueden mostrar relaciones entre clases. Una clase que sea una subclase de otra clase se conecta con ella mediante una flecha con una línea sólida y con una punta triangular hueca, como indica la figura 8. La flecha apunta de la subclase a la superclase. En UML, tal relación se llama generalización. Una flecha con una línea punteada indica implementación de una interfaz. En UML, tal relación se llama realización (Pressman, 2010).

Figura 8. Diagrama de clases, estructura Fuente: Pressman, R.S., (2010). Ingeniería del Software: Un enfoque práctico. México: Mc Graw Hill.

3.1.2.6.2.3. Diagramas de secuencia En contraste con los diagramas de clase, que muestran la estructura estática de un componente de software, un diagrama de secuencia se usa para mostrar las comunicaciones dinámicas entre objetos durante la ejecución de una tarea. Este diagrama presenta el orden temporal en el que los mensajes son enviados entre los objetos para cumplir una acción. “Puede usarse un diagrama de secuencia para mostrar las interacciones en un caso de uso o en un escenario de un sistema de software” (Pressman, 2010, pág. 732). 3.1.2.6.2.4. Diagramas de estado El comportamiento de un objeto en un punto particular en el tiempo con frecuencia depende del estado del objeto; es decir, de los valores de sus variables en dicho momento. Un diagrama de estado UML modela los estados de un objeto, las acciones que se realizan dependiendo de dichos estados y las transiciones entre los estados del objeto (Pressman, 2010).

3.1.3. Base de datos 3.1.3.1. Definición Es una colección de datos estructurados, organizados y relacionados lógicamente entre sí. Datos e información no es lo mismo por lo que los datos atraviesan un proceso para convertirse en información, como consecuencia de este proceso se obtiene información relevante para cualquier empresa o institución. 3.1.3.2. Características de una base de datos 

Acceso concurrente por parte de múltiples usuarios.



Independencia lógica y física de los datos.



Redundancia mínima.



Integridad de los datos.



Consultas complejas optimizadas.



Seguridad de acceso y auditoría.



Respaldo y recuperación.



Acceso a través de lenguajes de programación estándar

3.1.3.3. Sistema gestor de base de datos Para María Victoria Nevado Cabello (2010) el Sistema Gestor de Base de Datos: Es el software que permite a los usuarios procesar, describir, administrar y recuperar los datos almacenados en una base de datos. En estos sistemas se proporciona un conjunto coordinado de programas, procedimientos y lenguajes que permiten a los distintos usuarios realizar sus tareas habituales con los datos, garantizando además la seguridad de los mismos. (p. 25)

El Sistema Gestor de Base de Datos es diseñado para gestionar grandes cantidades de información, por lo que uno de los objetivos principales es proporcionar una visión abstracta de los datos a los usuarios. Es decir, oculta la complejidad de cómo se almacenan y mantienen los datos en el sistema. Un SGBD integra los siguientes componentes: 

DDL (Data Definition Language/Lenguaje de Definición de Datos).



DML (Data Manipulation Language/Lenguaje de Manipulación de Datos).



QL (Query Language/Lenguaje de Consulta).

3.1.3.4. Lenguajes de Base de Datos Son lenguajes que permiten realizar diversos tipos de operaciones en la base de datos, es así que tenemos el lenguaje de definición de datos para especificar las estructuras y esquemas y el lenguaje de manipulación de datos para expresar las consultas a la base de datos y las modificaciones. 3.1.3.4.1 DDL (Data Definition Language) Acid, Marín, Medina, Pons y Vila (2009) define al Lenguaje de Definición de Datos (DDL) como un subconjunto del DSL (Data SubLanguage / Sub Lenguaje de Datos) destinado a la definición de estructuras de datos y esquemas en la base de datos. El Lenguaje de Definición de Datos permite precisar las estructuras donde se almacenarán los datos y al momento de consultarlos definir sus funciones y procedimientos. Las sentencias que incluye el DDL: 

CREATE: Permite crear una nueva base de datos, tablas, índices, usuarios o consulta almacenada.



ALTER: Permite realizar modificaciones a la estructura de un objeto.



DROP: Permite eliminar un objeto de la base de datos.



TRUNCATE: Permite borrar el contenido de una tabla.

3.1.3.4.2 DML (Data Manipulation Language) El Lenguaje de Manipulación de Datos (DML) es un subconjunto del DSL mediante el que podemos introducir datos en los esquemas, modificarlos, eliminarlos y consultarlos. También debe permitir consultar la estructura de los esquemas definidos en la base de datos (Acid et al, 2009: 25). El Lenguaje de Manipulación de Datos permite a los usuarios consultar, modificar, recuperar y manipular los datos que se encuentren en el Sistema Gestor de Base de Datos. Las sentencias que incluye el DML: 

SELECT: Permite consultar información almacenada en la base de datos.



INSERT: Permite insertar información a una tabla en una base de datos.



DELETE: Permite borrar información de una base de datos.



UPDATE: Permite actualizar información que se encuentra almacenada en la base de datos.

3.1.3.4.3 DCL (Data Control Language) El Lenguaje de Control de Datos incluye el control y la administración de la base de datos; su propósito es la seguridad de los datos y la calidad de los mismos, además del control del acceso de los usuarios a la base de datos. Los comandos que incluye el DCL: 

GRANT: permite dar permisos o privilegios a los usuarios para que accedan a la base de datos.



REVOKE: Permite eliminar los permisos o privilegios que fueron dados mediante el comando GRANT.

3.1.3.5. Modelo de Datos Un modelo de datos es una herramienta conceptual que se emplea para especificar datos, relaciones entre ellos, su semántica asociada y restricciones de integridad. Lo que permite pasar de un tema complejo que está claramente definido en el ambiente real, a una representación relativamente sencilla, un modelo permite satisfacer las necesidades del usuario final, representando de forma clara y no ambigua los elementos claves de los datos, en forma general es una abstracción de un objeto o hecho real más complejo. Los modelos de datos se pueden clasificar de acuerdo al nivel de abstracción de la siguiente manera: 

Modelo de Datos Conceptual: Fundamentalmente se usa en la etapa del Análisis, están orientados a la descripción de estructuras de datos y restricciones de integridad. Por ejemplo, el modelo Entidad – Relación.



Modelo de Datos Lógicos: Más que a la descripción de la realidad se enfocan en las operaciones y están implementadas en el manejador de base de datos. Por ejemplo, el Modelo Relacional.



Modelo de Datos Físicos: Son estructuras de datos a bajo nivel implementadas dentro del manejador de base de datos. Por ejemplo, las estructuras de Hash, árboles B+, etc.

3.1.3.5.1 Modelo Entidad Relación Es el modelo de datos conceptual más utilizado que permite representar en un diseño la realidad de la problemática de estudio. El modelo entidad relación permite describir la realidad mediante gráficos en los que se simbolizan la colección de objetos denominados entidades, sus atributos y como se relacionan entre sí.

Los elementos del Modelo Entidad Relación (MER) son entidad, atributo, relación y restricciones; los mismos que se fundamentan de la siguiente manera.

Figura 9. Representación de las entidades del modelo entidad relación Fuente: IthinkWeb, Diagrama Entidad-Relación, Recuperado de: http://www.ithinkweb.mx/capacita/bd_er.html

3.1.3.5.1.1. Entidad Entidad es una persona, lugar, cosa o hecho que representa un objeto del mundo real y se distingue de las demás. Una entidad puede ser concreta como un libro, personas, productos, pero también existen entidades abstractas como rutas de vuelo, préstamos, etc. Existen entidades fuertes y entidades débiles, las entidades fuertes no dependen de otra entidad para existir, las débiles si necesitan, además, van relacionados con la entidad fuerte. 3.1.3.5.1.2. Atributo Atributo son las propiedades que caracterizan a las entidades. Un valor unívoco en el caso de la entidad cliente seria el documento de identificación único. Los atributos poseen valores

específicos asignados que permite diferenciar de las otras entidades. Los atributos se representan mediante una elipse. 3.1.3.5.1.3. Relaciones Las relaciones son asociaciones entre dos o más entidades. Podremos tener relaciones unarias cuando una entidad se relaciona consigo mismo, binarias si dos entidades se relacionan y cuando tres entidades se relacionan entre sí, ternarias. Las relaciones se representan mediante un rombo, para su identificación dentro del mismo debe ir una expresión verbal. 3.1.3.5.1.4. Restricciones Las restricciones se aplican a los datos, las mismas son importantes porque ayudan asegurar la integridad de los datos. Las restricciones se expresan en forma de reglas, por ejemplo: 

El salario de un empleado puede tener valores que están entre 600 a 3500.



El promedio de calificaciones de un estudiante puede estar entre 0 a 4 puntos



Una clase puede tener uno y solo un maestro. (Coronel, Base de datos, diseño, implementación y Administración, 2011)

3.1.3.5.2 Modelo Relacional Modelo Relacional está basado en la teoría matemática de conjuntos y su objetivo es mantener la independencia de la estructura lógica respecto al modo de almacenamiento. El modelo relacional tiene las siguientes características: 

Flexibilidad, cada usuario puede definir los datos como le convenga.



Uniformidad, todos los datos se representan de la misma forma en la base de datos.



Sencillez, para definir la base de datos y realizar consultas sobre la misma.

3.1.3.6. MySQL MySQL es un sistema de gestión de base de datos relacional, multihilos y multiusuarios, utilizado en todo tipo de aplicaciones, en plataformas Linux, Windows y Macintosh, es multiplataforma. Entre sus características principales tenemos: 

MySQl está escrita en C y C++.



Emplea el lenguaje SQL.



Fácil de instalar en cualquier plataforma

3.1.3.7. PostgreSQL 3.1.3.7.1 Definición PostgreSQL es un sistema de gestión de bases de datos objeto-relacional, distribuido bajo licencia BSD y con su código fuente disponible libremente. Es el sistema de gestión de bases de datos de código abierto más potente del mercado y en sus últimas versiones no tiene nada que envidiarle a otras bases de datos comerciales (PostgreSQL, 2010).

diferencia

MySQL,

PostgreSQL

utiliza

modelo

cliente/servidor

usa multiprocesos en lugar de multihilos para garantizar la estabilidad del sistema, esto asegura que un fallo en uno de los procesos no afectará al resto y el sistema continuará funcionando sin complicaciones. 3.1.3.7.2 Características Entre otras, la característica más notable de PostgreSQL es su escalabilidad, es decir, funciona perfectamente con gran cantidad de datos y gran consumo de los mismos por parte de los usuarios paralelamente sin verse afectado el rendimiento entre una consulta y otra.



Generaliza los procedimientos y funciones que se encuentran incluidos en varios lenguajes de programación.



Capacidad para soportar datos binarios de gran escala como: gráficos, audios, videos, etc.



Soporte de datos binarios, geométricos, geoespaciales, etc.



Consta con su propio lenguaje de programación: pgsql

3.1.4. Arquitectura Cliente – Servidor 3.1.4.1. Definición Consiste en que el computador cliente solicite información al servidor (equipo remoto, situado en cualquier lugar), en el servidor se aloja información que puede ser extraída; un ejemplo claro que aloja un servidor es una página web. Dicho de otra forma, los clientes en este caso usuarios finales solicitan información al servidor de forma clara y precisa. 3.1.4.2. Cliente Es todo aquel requerimiento que se solicita al servidor, este puede convertirse en múltiples requerimientos que viajan a través de las redes hacia el servidor el cual convierte estos requerimientos en datos transparentes para el cliente. 3.1.4.3. Servidor La forma más sencilla de definir lo que es un servidor web; es un software diseñado para la transferencia de datos de hipertexto, es decir, páginas web completas. Los servidores web son conocidos por utilizar el protocolo http. Éste se encuentra a la espera de alguna petición, por ejemplo, al acceder a una página web el servidor http responde inmediatamente a la petición, enviando un código HTML mediante una transferencia de datos en red.

3.1.4.3.1 Apache 3.1.4.3.1.1.1 Definición Es un poderoso servidor http, servidor web, cuyo nombre proviene de la frase inglesa “a patchy server” y es completamente libre, por lo que es un software Open Source y con licencia GPL. La característica y a la vez ventajas más grandes de Apache, es que es un servidor web multiplataforma (Apache, 2015). 3.1.4.3.1.2. Características Entre las principales características de Apache, se encuentran las siguientes:  Soporte de seguridad SSL y TLS; puede realizar autentificación de datos utilizando SGDB; puede dar soporte a diferentes lenguajes, como Perl, PHP, Python y tcl, Multiplataforma

Figura 10. Arquitectura Cliente - Servidor implementando Apache Fuente: Cocheclub, Diagrama entidad relación de la base de datos, Recuperado de: http://laurel.datsi.fi.upm.es/~ssoo/DAW/Trabajos/2009-2010/009/func_es.shtml

3.1.5. Ingeniería Web 3.1.5.1. Definición S. Murugesan, Y. Deshpande, S, promotores iníciales del establecimiento de la Ingeniería Web, definen como: Proceso utilizado para crear, implantar y mantener aplicaciones y aplicaciones Web. Es la aplicación de metodologías sistemáticas, disciplinadas y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en la World Wide Web. 3.1.6. Herramientas de desarrollo web 3.1.6.1. PHP Según Marcos López Sanz, Juan Manuel Vara Mesa, Jénifer Verde Marín, Diana Marcela Sánchez Fúquene, Jesús Javier Jiménez Hernandéz, Valeria de Castro Martínez, (2012) PHP “es un lenguaje de script interpretado en el lado del servidor utilizado para la generación de páginas web dinámicas, embebidas en páginas HTML y ejecutadas en el servidor. PHP no necesita ser compilado para ejecutarse” (p.116). 3.1.7. Comparación de herramientas de desarrollo Un aspecto importante en el desarrollo de software parte desde la metodología que se usa, hasta tener un conocimiento profundo acerca de las herramientas óptimas, como lenguajes de programación, herramientas case, IDE de desarrollo, que facilitaran el trabajo al desarrollador. Es por esto que el presente contexto está destinado a la comparación de herramientas con la finalidad de establecer las ventajas y complicaciones que ofrecerán en el desarrollo de la aplicación informática.

 Apache vs IIS (Internet Information Server) Tabla 2. Comparativa de software servidor (HTTP) Comparativa de software servidor (HTTP) Apache

ISS

Software de uso libre

IIS que es un producto comercial bajo la licencia de Windows

Multiplataforma

Opera bajo plataformas Windows

Fácil instalación

Fácil instalación, viene preinstalado con Windows

Permite realizar multiinstancias al equipo servidor para obtener beneficios del mismo Gran comunidad de desarrolladores a cargo de soporte.

Número determinado de funciones lo que le hace poco flexible Soporte técnico a cargo del equipo Microsoft Corporation

Nota. Elaborado por: F. Manzanilla; J. Olivo

 PHP VS Java Tabla 3. Comparativa de lenguaje de programación Comparativa de lenguaje de programación PHP

ASP

Java

Lenguaje de programación multiplataforma

Opera bajo plataformas Windows

Lenguaje multiplataforma

Amplia documentación y muy completa en Internet (sitio web oficial).

Soporte técnico a cargo del equipo Microsoft Corporation

Soporte técnico a cargo del equipo Oracle

Lenguaje de programación de sintaxis simple, y fácil de comprender.

Estricto lenguaje de programación estandarizado

Sentencias exclusivas de Java para la programación

Excelente Web

Excelente para tecnologías web

Soporte nuevo para tecnologías web

Programación estructurada

Programación orientada a objetos

Seguridad del lado del servidor

Realiza la administración de memoria de forma automática

para

Programación objetos

tecnologías orientada

Seguridad e integridad de los datos

Nota. Elaborado por: F. Manzanilla; J. Olivo

 PostgreSQL VS MySQL Tabla 4. Comparativa de sistemas gestor de base de datos Comparativa de sistemas gestor de base de datos PostgreSQL

MySQL

Ideal para tecnologías Web ya que su desenvolvimiento está orientado a objetos permitiendo un rápido acceso a los datos

Aprovecha la potencia de sistemas multiprocesadores así como soportar gran cantidad de tipos de datos para las columnas

Cuenta con su programación

Lenguaje de programación estándar

propio

lenguaje

Multiplataforma

Portabilidad entre sistemas.

Mayor comprensión en la organización de registros a nivel lógico y conceptual

Introducción a esquemas poco apreciables

Excelente para trabajar con sistemas grandes

Gran rapidez de respuesta en sistemas medianos

Implementa el uso de multiprocesos en lugar de multihilos para procesar grandes bancos de datos

MySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuarios

Nota. Elaborado por: F. Manzanilla; J. Olivo

3.1.8. Selección de las herramientas y lenguajes de programación Servidor web Apache v2.2.21 Diseño web HTML5 + CSS3 IDE de desarrollo NetBeans 8.0.1 - Notepad++ Programación PHP 5.3 - SQL Motor de base de datos PostgreSQL

Figura 11. Herramientas utilizadas. Elaborado por: F. Manzanilla; J. Olivo

 Apache v2.2.21: Da a los desarrolladores la posibilidad levantar un equipo servidor desde cualquier ordenador, es decir permite mantener un ambiente de estructura cliente-servidor, en cualquier plataforma que se vaya a desarrollar.  PHP: Es un lenguaje de programación multiplataforma, orientado a objetos, y con una gran comunidad de desarrolladores dando soporte, se caracteriza por ser un lenguaje de programación de sintaxis simple, y fácil de comprender ante cualquier desarrollador.  PostgreSQL: Es una base de datos actualmente más reconocidas, permite mantener todos los registros correctamente ordenados, su ventaja rescatable es que es un sistema gestor de base de datos orientado a objetos permitiendo un rápido acceso a los datos mediante multi-procesos, por lo que es muy fácil de administrar. Es importante dar a notar que al igual que el resto de herramientas seleccionadas, PostgreSQL es una base de datos que opera bajo cualquier plataforma.  Investigaciones o experiencias empíricas vinculadas con la investigación Para la presente disertación de grado se realizaron varios estudios para conocer si actualmente existen entidades que han adoptado por la implementación de sistemas informáticos para la automatización de sus procesos, en este caso para la generación de turnos al momento de ofrecer un bien o servicio a la comunidad alrededor. Como resultado de este estudio se conoció que gran parte de las empresas de prestación de servicios han realizado la adquisición de productos informáticos que se encarguen de la automatización de ciertos procesos, dentro de los cuales se encuentra la generación de turnos en cuanto a la atención al cliente se refiere, sin embargo, estas aplicaciones requieren de un pago de licencias para su uso, es decir, prestan el servicio por el pago de licencias anuales,

dichos productos se encuentran a la ventas desde costos alrededor de $250 dependiendo del tipo de servicio a ofrecer. Uno de los principales proveedores de dispensadores de turnos electrónicos es Automasis, una empresa desarrolladora de software y equipos tecnológicos para la automatización de servicios. Si bien es cierto, los dispensadores de turnos electrónicos son altamente recomendados por lo que se ve que hay una alta flexibilidad, pertinencia y veracidad en el manejo de datos, lo cual permite brindar un servicio de calidad a los usuarios, sin embargo no permiten la adaptabilidad posterior del sistema a nuevos requerimientos exigidos por las entidades contratantes, lo cual cuestiona la adopción del producto o la construcción de un sistema propio con la capacidad de escalar y adaptarse a requerimientos futuros.

4. METODOLOGÍA DE LA INVESTIGACIÓN 4.1. Enfoque / Tipo de investigación 4.1.1. Diseño de la Investigación 4.1.1.1. Diseño experimental Bernal (2010) menciona: “la investigación experimental se caracteriza porque en ella el investigador actúa conscientemente sobre el caso de estudio” (p.118), dicho en otras palabras significa que el investigador adopta el diseño experimental como una técnica estadística que le permite identificar y cuantificar las causas de una acción provocada dentro de un estudio experimental, junto con este proceso intervienen los métodos cualitativos y cuantitativos con las responsabilidad de la interpretación y análisis proceso de investigación. El estudio corresponde a una categorización de enfoque cuantitativo basado en un cálculo estadístico desarrollado a partir de la información obtenida a través de los instrumentos de investigación aplicados al equipo que labora en el área administrativa y de los servicios públicos de control, prevención y protección social que brinda el Cuerpo de bomberos del GAD Municipal de Santo Domingo. El método cuantitativo se basa en la adquisición estadística de información objetiva que precisa detalles específicos cuantificables de la investigación. Su aplicación en la investigación es en los procesos de adquisiciones información como número de trabajadores, uso del tiempo en la atención al usuario del servicio, cantidad de datos, tiempo de espera entre otros. 4.1.2. Tipo de Investigación Para el estudio efectuado existen diferentes tipos de investigación, y evidentemente el tipo que se aplicó dependerá del campo en el cual se desarrolla la indagación. Para esta investigación se utilizaron los siguientes tipos:

4.1.2.1. Investigación aplicada También recibe el nombre de práctica o empírica. Se caracteriza porque busca la aplicación o utilización de los conocimientos que se adquieren. Se encuentra vinculada con la investigación básica pues depende de los resultados que dan paso al marco teórico. (Quezada Lucio, 2010, p.23) Aplicación: Se implementó los conocimientos adquiridos durante el periodo de estudio de la carrera universitaria, para el cual se estableció el lenguaje de programación, el tipo de arquitectura y base de datos a implementar para la solución de las necesidades planteadas. 4.1.2.2. Investigación de Campo En la investigación de campo el investigador se centra en el sitio donde se encuentra el objeto de estudio. Esta investigación toma como referencia la información recolectada que proviene de encuestas, entrevistas, cuestionarios y observaciones. Aplicación: La entrevista establecida con el director del Departamento de TIC del Cuerpo de Bomberos del GAD Municipal de Santo Domingo, también se aplicó una encuesta a los administradores de los departamentos para obtener la información necesaria sobre los aspectos de los procesos de atención a la ciudadanía para cumplir con el desarrollo del sistema. 4.1.2.3. Investigación Documental Según Quezada Lucio (2010) “la investigación documental es la que se realiza, como su nombre lo indica, apoyándose en fuentes de carácter documental, esto es, en documentos de cualquier especie” (p. 23).

42 Tabla 5. Subtipos de investigación documental Subtipos de Investigación documental

Investigación bibliográfica

Libros

Investigación hemerográfica

Artículos o ensayos de revistas y periódicos.

Investigación archivística

Archivos como cartas, oficios, circulares, expedientes, etc.

Nota. Fuente: Quezada Lucio, 2010, p.23

Aplicación: Esta investigación asistió en la construcción del marco referencial apoyándonos en fuentes de carácter documental, mediante la consulta en libros, artículos y archivos que contengan información que aporten a la investigación para la sustentación de la investigación. 4.1.2.4. Investigación Descriptiva Quezada Lucio (2010) expresa que la investigación descriptiva “utiliza el método de análisis, logra caracterizar un objeto de estudio o una situación concreta, señalar sus características o propiedades” (p. 23). Aplicación: Este tipo de investigación guio a los disertantes para describir los antecedentes del problema, el problema de investigación y la justificación de la investigación. La investigación descriptiva se limita hacer referencias de un hecho o fenómeno tal y como este se desarrolla, mediante el uso de signos numéricos que caracterizan al grupo investigado. En el estudio ejecutado a través de la recolección de datos trata de detallar en un tiempo determinado y de forma metódica las características de los servicios que brindan las áreas involucradas, las dificultades presentadas y la proyección funcional y eficiente del software implementado en relación a la prestación de servicios en: el uso oportuno del tiempo, eficacia, la comodidad, información efectiva entre otros aspectos fundamentales que ayudan a la organización de esta entidad pública.

4.2. Población / Muestra Conjunto de individuos, personas, animales, objetos, etc. con características similares y que son objeto de estudio, de los cuales se obtiene conclusiones propias. Según Quezada Lucio (2010) “la población constituye el conjunto de elementos que forman parte del grupo de estudio, por tanto, se refiere a todos los elementos que en forma individual podrían ser cobijados en la investigación” (p. 95). Aplicación: La población seleccionada para el desarrollo del proyecto será el personal administrativo que atiende en los diferentes departamentos de atención del GAD Municipal del Cuerpo de Bomberos de Santo Domingo de los Colorados la población está constituida por 30 funcionarios.

La muestra La mayoría de los investigadores aconseja que cuando la población o universo a investigarse no sobrepase las 30 o 40 unidades, no hay que determinar una muestra para aplicar el o los instrumentos de investigación que permitan captar información requerida, en estos casos es técnico y necesario desarrollar un CENSO, es decir aplicar los instrumentos para captar información a toda la población o universo motivo de estudio, siempre y cuando las condiciones lo permitan. (Posso Yépez 2009,136)

Aplicación: En la presente disertación de grado se utilizó una población finita, teniendo al personal administrativo como la población del GAD Municipal del Cuerpo de Bomberos de Santo Domingo de los Colorados no se aplica la fórmula de muestreo aleatorio simple. La muestra corresponde a la totalidad de 30 funcionarios, no hay que determinar una muestra para aplicar los instrumentos de investigación que permitan captar información requerida, la misma que será tomada para su respectivo análisis.

4.3. Técnicas e Instrumentos de recogida de datos Para la recolección de información y datos de forma fiable y precisa se determinó para esta investigación la utilización de las siguientes técnicas que tienen como principal instrumento el cuestionario aplicado en la encuesta a los servidores públicos. 4.3.1. Entrevista La Entrevista es la comunicación interpersonal establecida entre investigador y el sujeto de estudio a fin de obtener respuestas verbales para poder recopilar información de los interrogantes planteados sobre el tema propuesto para poder alcanzar los objetivos que ayudaran a la elaboración de la presente investigación. Aplicación: La técnica de la entrevista se la realizo al director del departamento de TIC, que supo aportar con valiosa información manejada internamente para poder desarrollar la base de datos y sus relaciones. Mediante el diálogo espontáneo puesto que las preguntas abiertas permitían que expresen sus expectativas del sistema a implementar. 4.3.2. Encuesta Es una técnica que permite recopilar información a un grupo significativo de personas mediante la utilización del instrumento llamado cuestionario y mediante un análisis de tipo cuantitativo obtener conclusiones. El cuestionario es grupo de preguntas abiertas, cerradas y dicotómicas que permiten recabar información variada. Un cuestionario muy corto, se pierde información y muy largo puede resultar tedioso. Aplicación: El instrumento de la encuesta es un recurso indispensable para la investigación, se aplicó al total de la muestra seleccionada obteniendo información significativa para la implementación del software desarrollado, la apertura, voluntad y accesibilidad del recurso humano es un punto importante porque garantiza una información confiable y verdadera, para

esto es necesario un previo dialogo explicando la finalidad del recurso aplicado sin intentar manipular las respuestas. Tabla 6. Tipos de preguntas del cuestionario Tipos de preguntas del cuestionario

Tipo de pregunta

Característica

Ejemplo

Abierta

No delimitan las alternativas de respuesta, el número de respuesta es muy elevado.

Edad (1 año, 10 años, 15 años, etc.)

Cerrada

Sus respuestas han sido delimitadas, es decir, se presentan las posibilidades de respuestas.

Edad: Adolescente Joven Adulto

Dicotómicas

Poseen dos alternativas de respuesta. Es una escala de la pregunta cerrada.

¿Usted trabaja?

Nota: Fuente. Quezada Lucio, 2010, p. 116

4.4. Técnicas de Análisis de Datos Consiste en organizar, describir y analizar los datos recogidos en la etapa de técnicas para recogida de datos. Una vez recogidos los datos, estos se someten a unas operaciones con la finalidad de alcanzar los objetivos del estudio. Aplicación: Con la información obtenida se procedió con el análisis cuantitativo que permite organizar los datos en una matriz de tabulación para ser analizados. Se seleccionó la estadística descriptiva que es la “ciencia que analiza serie de datos y trata de extraer conclusiones sobre el comportamiento de estas variables” (Quezada Lucio, 2010, p.167) y mediante la aplicación de Microsoft Excel que permite utilizar sus funciones estadísticas y gráficas, interpretar los datos y representarlos en gráficas de barras o de pastel.

5. RESULTADOS 5.1. Discusión y análisis de resultados En el siguiente apartado se detallan los resultados de acuerdo a la discusión de la entrevista realizada al Analista de Sistemas del Cuerpo de Bomberos del GAD Municipal del Cantón Santo Domingo, de igual forma se exponen los resultados obtenidos mediante la aplicación de las encuestas a la población de la institución, por la cual se pudo establecer algunos parámetros para el desarrollo de los módulos y validaciones de la aplicación. 5.1.1. Análisis de la entrevista aplicada al analista de Sistemas Se realizó una entrevista de carácter informal al director del departamento de TIC del Cuerpo de Bomberos del GAD Municipal del Cantón Santo Domingo, en la cual fue precedida por los estudiantes a cargo de la disertación de grado, donde exitosamente se logró recopilar y aclarar algunos aspectos importantes e información para el desarrollo del sistema. Pregunta al director del departamento de TIC: ¿Cómo se está realizando el proceso atención al cliente actualmente? Síntesis: La atención se realiza de forma verbal para los clientes que llegan a solicitar un servicio o de igual forma la gente que requiere ingresar a los departamentos administrativos, la cual existe un registro de forma manual que en la actualidad se considera un método obsoleto, para ello la institución se vería beneficiada con la implementación de un sistema para la generación de turnos y un registro de los clientes que solicitan los servicios de toda la institución. Análisis: La propuesta del desarrollo e implementación de un Sistema de Generación de Turnos de los Servicios dirigido a la atención al cliente del Cuerpo de Bomberos del GAD

Municipal del Cantón Santo Domingo la cual resolverá el inconveniente del registro de los clientes y generación de turnos de forma verbal. 5.1.2. Encuesta aplicada a la población Cuerpo de Bomberos del GAD Municipal del Cantón Santo Domingo Se realizó una encuesta al personal de los departamentos administrativos del Cuerpo de Bomberos del GAD Municipal del Cantón Santo Domingo del Cuartel General SANTA MARTHA ubicado en la Avenida Jacinto Cortez y Jorge Icaza para determinar el estado actual y pretensiones con respecto al proceso de atención al cliente. 5.1.2.1. Tabulación y análisis de la información Pregunta 1: ¿Considera usted que la atención al cliente en los departamentos es eficiente? Tabla 7. Análisis de la pregunta #1 Análisis de la pregunta #1 ALTERNATIVAS

FRECUENCIA

PORCENTAJE

80,00%

20,00%

100,00%

TOTAL Fuente: Cuerpo de Bomberos. GAD Municipal

PREGUNTA # 1

20% SI 80%

Figura 12. Resultado de la tabulación de la pregunta número 1. Fuente: Cuerpo de Bomberos. GAD Municipal Elaborado por: F. Manzanilla; J. Olivo

Análisis: Mediante la encuesta realizada a la Población del Cuerpo de Bomberos del GAD Municipal del Cantón Santo Domingo hemos podido establecer que de las 30 (100%) personas encuestadas, 24 (80%) considera que la atención al cliente en los departamentos es eficiente y 6 (20%) considera que no lo es. La información obtenida nos permite determinar que la asignación de turnos de manera verbal genera inconformidad en los usuarios, por lo que la automatización en la entrega de turnos permitirá obtener mayor eficiencia en la atención al cliente y garantizar su satisfacción. Pregunta 2: Considera usted que la forma actual de entrega de turnos para atención al cliente es: Tabla 8. Análisis de la pregunta #2 Título: Análisis de la pregunta #2 ALTERNATIVAS

FRECUENCIA

PORCENTAJE

Excelente.

3,33%

Muy bueno

20,00%

Bueno

10,00%

Regular

30,00%

Malo

36,67%

100%

TOTAL Fuente: Cuerpo de Bomberos. GAD Municipal

PREGUNTA # 2 3,33% Excelente. 20% 36,67%

Muy bueno Bueno

10%

30%

Figura 13. Resultado de la tabulación de la pregunta número 2. Fuente: Cuerpo de Bomberos. GAD Municipal Elaborado por: F. Manzanilla; J. Olivo

Regular Malo

Análisis: Con el levantamiento de información realizado mediante la encuesta dirigida a la población se determinó que 1 (3,33%) persona considera excelente la forma actual de entrega de turnos, 6 (20%) consideran que es Muy bueno, 3 (10%) lo consideran Bueno, 9 (30%) creen que es Regular. Los porcentajes obtenidos por los encuestados en esta pregunta nos garantizan que el Sistema para la generación de turnos de los servicios del Cuerpo de Bomberos del GAD Municipal del Cantón de Santo Domingo de los Colorados generará una mejor prestación del servicio y mayor Satisfacción en los usuarios. Pregunta 3: Cree usted que hay organización en la asignación de turnos para la atención al cliente. Tabla 9. Análisis de la pregunta #3 Análisis de la pregunta #3 ALTERNATIVAS

FRECUENCIA

PORCENTAJE

Siempre

3,33%

Casi siempre

13,33%

A veces

53,33%

Pocas veces

30,00%

100,00%

TOTAL Fuente: Cuerpo de Bomberos. GAD Municipal

PREGUNTA # 3 13,33% 30%

Siempre Casi siempre

3,33%

A veces 53,33%

Figura 14. Resultado de la tabulación de la pregunta número 3. Fuente: Cuerpo de Bomberos. GAD Municipal Elaborado por: F. Manzanilla; J. Olivo

Pocas veces

Análisis: Con el levantamiento de información realizado mediante la encuesta dirigida a la población se determinó que 1 (3,33%) persona considera excelente la forma actual de entrega de turnos, 6 (20%) consideran que es Muy bueno, 3 (10%) lo consideran Bueno, 9 (30%) creen que es Regular. Por consiguiente, se afirma que la forma en que se viene acarreando el trabajo provoca inconformidad para la atención de los turnos en los departamentos que brindan el cuerpo de bomberos del GAD Municipal del Cantón Santo Domingo. Pregunta 4: ¿Cuál de los siguientes departamentos de Segunda Jefatura cree que es el más solicitado por el cliente? Tabla 10. Análisis de la pregunta #4 Análisis de la pregunta #4 ALTERNATIVAS

FRECUENCIA

PORCENTAJE

Prevención

53,33%

Operaciones rural

10,00%

Operaciones urbana

23,33%

Caja

13,33%

100%

TOTAL Fuente: Cuerpo de Bomberos. GAD Municipal

PREGUNTA # 4 13,33%

Prevención Operaciones rural

23,33%

53,33% Operaciones urbana

10%

Figura 15. Resultado de la tabulación de la pregunta número 4. Fuente: Cuerpo de Bomberos. GAD Municipal Elaborado por: F. Manzanilla; J. Olivo

Caja

Análisis: Del total de la Población, 16 (53,33%) personas creen que el departamento de Prevención es el más solicitado por el cliente, 3 (10%) creen que Operaciones rural es más solicitado, 7 (23,33%) consideran a Operaciones urbanas el más solicitado y 4 (13,33%) consideraron a Caja como el más solicitado. Los porcentajes obtenidos nos dan como resultado que el departamento más solicitado es el de Prevención y con la automatización en la generación de turnos se mejorarán los tiempos de servicio para éste y los demás departamentos de la segunda jefatura del cuerpo de bomberos del GAD Municipal del Cantón Santo Domingo. Pregunta 5: ¿Cree usted que se mejoraría la atención con la implementación de un software que genere turnos para la atención al cliente? Tabla 11. Análisis de la pregunta #5 Análisis de la pregunta #5 ALTERNATIVAS

FRECUENCIA

PORCENTAJE

90,00%

10,00%

100%

TOTAL Fuente: Cuerpo de Bomberos. GAD Municipal

PREGUNTA # 5 10%

90%

Figura 16. Resultado de la tabulación de la pregunta número 5. Fuente: Cuerpo de Bomberos. GAD Municipal Elaborado por: F. Manzanilla; J. Olivo

Análisis: Del total de la población, 27 (90%) personas responden afirmativamente que es necesaria la implementación de una aplicación que se encargue de la administración del

proceso de generación de turnos para atención al cliente, mientras que 3 (10%) personas no estiman necesaria dicha implementación. Con el análisis de la información recolectada se puede demostrar la aceptación de la implementación de un sistema de generación de turnos de atención al cliente en el cuerpo de bomberos del GAD Municipal del Cantón Santo Domingo, la cual permite mejorar el servicio brindado a la comunidad. Pregunta 6: ¿Cree usted que es importante que el cliente evalué el rendimiento del recurso humano de atención del Cuerpo de Bomberos? Tabla 12. Análisis de la pregunta #6 Análisis de la pregunta #6 ALTERNATIVAS

FRECUENCIA

PORCENTAJE

36,67%

63,33%

100,00%

TOTAL Fuente: Cuerpo de Bomberos. GAD Municipal

PREGUNTA # 6

36,67% 63,33%

Figura 17. Resultado de la tabulación de la pregunta número 6. Fuente: Cuerpo de Bomberos. GAD Municipal Elaborado por: F. Manzanilla; J. Olivo

Análisis: Mediante la encuesta realizada a la población, 11 (36,67%) personas creen importante que el cliente evalúe el rendimiento del recurso humano de atención del Cuerpo de Bomberos, mientras que 19 (63,33%) no creen importante que se realice dicha evaluación por parte de los clientes. Estos resultados permiten reflejar que los empleados no desean ser evaluador por los clientes ya que el proceso de generación de turnos actual no es eficiente, el

sistema de Generación de Turnos no constará con el módulo de evaluación sobre el rendimiento del recurso humano ya que el sistema generará mayor eficiencia en la atención y satisfacción a los clientes. Pregunta 7: Desea usted que el sistema de generación de turnos controle referente a: Tabla 13. Análisis de la pregunta #7 Análisis de la pregunta #7 ALTERNATIVAS

FRECUENCIA

PORCENTAJE

Detallar el tiempo de atención por asesor

23,33%

Detallar el tiempo de espera por atención del turno

16,67%

Periodos de tiempo del cliente desde su entrada hasta que es atendido

60,00%

100%

TOTAL Fuente: Cuerpo de Bomberos. GAD Municipal

PREGUNTA # 7 Detallar el tiempo de atención por asesor 23,33% Detallar el tiempo de espera por atención del turno

60% 16,67%

Periodos de tiempo del cliente desde su entrada hasta que es atendido Figura 18. Resultado de la tabulación de la pregunta número 7. Fuente: Cuerpo de Bomberos. GAD Municipal Elaborado por: F. Manzanilla; J. Olivo

Análisis: Según la encuesta realizada, 7 (23,33%) personas desean que el sistema de Generación de Turnos para el cuerpo de bomberos del GAD Municipal del Cantón Santo Domingo se controle referente al detalle del tiempo de atención por asesor, 5 (16,67%) personas desean que se controle detallando el tiempo de espera por atención al turno, y 18 (60%) personas desean que se controle por Periodos de tiempo del cliente desde su entrada hasta que es atendido. La información obtenida nos permite obtener el requerimiento de control para el sistema de Generación de turnos y así mejorar los tiempos de atención a los clientes.

Pregunta 8: Cree usted que un sistema para generar turnos optimizará el tiempo de atención al cliente Tabla 14. Análisis de la pregunta #8 Análisis de la pregunta #8 ALTERNATIVAS

FRECUENCIA

PORCENTAJE

90,00%

10,00%

TOTAL 30 Fuente: Cuerpo de Bomberos. GAD Municipal

100,00%

PREGUNTA 8 10%

90%

Figura 19. Resultado de la tabulación de la pregunta número 8. Fuente: Cuerpo de Bomberos. GAD Municipal Elaborado por: F. Manzanilla; J. Olivo

Análisis: El 80% de la muestra responde que, mediante la implementación de un sistema de generación de turnos de atención al cliente, se optimizará el tiempo de atención y recursos que cuenta el cuerpo de bomberos del GAD Municipal del Cantón Santo Domingo, mientras que el otro 10% no lo considera como un punto de ayuda al sistema. De los datos obtenidos se escatima que la mayoría de la población ve la necesidad de optimizar los tiempos en el servicio ofrecido, dando una vez más apertura para la implementación de Turnos+. Pregunta 9: Cuál de los siguientes beneficios piensa usted que brinda el sistema de Generación de Turnos al cuerpo de bomberos.

55 Tabla 15. Análisis de la pregunta #9 Análisis de la pregunta #9 ALTERNATIVAS

FRECUENCIA

PORCENTAJE

Mejora la calidad de servicio

13,33%

Mejora la imagen institucional

50%

Acelera la productividad

23,33%

Reportes automáticas sobre el estado del servicio

13,33%

100%

TOTAL Fuente: Cuerpo de Bomberos. GAD Municipal

PREGUNTA 9 13,33%

13,33%

Mejora la calidad de servicio Mejora la imagen institucional

23,33%

Acelera la productividad 50%

Reportes automáticas sobre el estado del servicio

Figura 20. Resultado de la tabulación de la pregunta número 9. Fuente: Cuerpo de Bomberos. GAD Municipal Elaborado por: F. Manzanilla; J. Olivo

Análisis: A esta pregunta el 50%, responde que, mediante la implementación de un sistema de generación de turnos de atención al cliente, mejorará la imagen del cuerpo de bomberos del GAD Municipal del Cantón Santo Domingo, el 7% considera que se aceleraría la productividad de la empresa y un 4% considera que mejorará la calidad del servicio y mejorará la obtención de reportes del estado del servicio. La mitad de la población encuestada considera que la implementación de un sistema gestor de turnos mejorará la imagen de la entidad pública ofreciendo un mejor servicio a la ciudadanía.

Pregunta 10: Cree usted que el sistema de Generaciรณn de Turnos le brindarรก al cliente que usa los servicios del cuerpo de bomberos. Tabla 16. Anรกlisis de la pregunta #10 Anรกlisis de la pregunta #10 Alternativas

Frecuencia

Porcentaje

Menor tiempo de espera del cliente

40,00%

Igualdad de trato

23,33%

Asignaciรณn de turnos en funciรณn al tipo de servicio

13,33%

Mayor comodidad

23,33%

100%

TOTAL Fuente: Cuerpo de Bomberos. GAD Municipal

PREGUNTA 10 Menor tiempo de espera del cliente 23,33% Igualdad de trato 40% 13,33%

Asignaciรณn de turnos en funciรณn al tipo de servicio 23%

Mayor comodidad

Figura 21. Resultado de la tabulaciรณn de la pregunta nรบmero 8. Fuente: Cuerpo de Bomberos. GAD Municipal Elaborado por: F. Manzanilla; J. Olivo

Anรกlisis: A esta pregunta el 40%, responden que mediante la implementaciรณn de un sistema de generaciรณn de turnos de atenciรณn al cliente, brindarรก un menor tiempo de espera en la atenciรณn al cliente del cuerpo de bomberos del GAD Municipal del Cantรณn Santo Domingo, el 23% considera que existirรก igualdad de trato y mayor comodidad para el usuario que acuda a la peticiรณn de un servicio, mientras que el 13,33% estima que se obtendrรก una mejora en la atenciรณn de turnos en funciรณn al tipo de servicio ofrecido. Con los datos obtenidos se concluye que la mayorรญa de la poblaciรณn espera obtener mayores resultados en cuanto a al tiempo que serรก empleado con el trato al cliente.

5.2. Proceso cascada Las metodologías de desarrollo de software proporcionan a los desarrolladores garantizar una óptima construcción del producto en base a actividades, pasos y reglas ya comprobadas. A continuación, se detalla el proceso de desarrollo de Turnos+, Sistema Gestor de Turnos electrónicos para la implementación en el Cuerpo de Bomberos del GAD Municipal de Santo Domingo, se detalla desde su análisis con los servidores públicos de la entidad hasta su implementación en las instalaciones de la misma. 5.2.1. Análisis Como primera etapa de la metodología en cascada se encuentra el análisis de requerimientos del sistema por parte del usuario final (cliente).  Objetivo: Recolectar la información que de mayor importancia para el desarrollo del SRS (Ver anexo 2) para conocer qué objetivo se debe cubrir, y una posterior construcción de los diferentes ambientes con los que constará el sistema, es decir, plasmar los requerimientos del usuario en casos de uso. Previo a la obtención de dicho documento legal para dejar en constancia los requerimientos funcionales de la aplicación informática, el personal a cargo del Cuerpo de Bomberos acordó y accedió a las entrevistas con el equipo desarrollador (los disertantes), para tomar las decisiones y establecer los posibles ambientes que conformarían el sistema generador de turnos (ver anexo 2). Cabe recalcar que las entrevistas y encuestas fueron llevabas mediante un previo estudio de metodología de la investigación; en el anexo 1 se pueden apreciar los instrumentos de recolección de datos y su respectiva tabulación e interpretación de resultados en el primer punto de la sección de resultados, análisis e interpretación de los mismos.

5.2.2. Diseño Objetivo: Construir el SRS, con la descripción de la estructura relacional del sistema y la especificación de los comportamientos que tendrá frente a las acciones del usuario en la realización de sus actividades. Luego de las reuniones y entrevistas informales realizadas al equipo del área de sistemas del Cuerpo de Bomberos, se pudieron establecer los requerimientos y módulos soportados en el sistema, así como el acceso concedido a los diferentes perfiles que se instanciará en el mismo (Ver anexo 2). Partiendo de cada requerimiento funcional y no funcional adquirido, se derivó a la elaboración de los casos de uso estimados en el sistema, en ellos se detallan los actores y los diferentes escenarios entre los que el usuario se desenvolverá. Como un punto indispensable dentro del marco legal del documento de especificación de requerimientos de software se establece un acuerdo para todas las partes involucradas, donde se deja constancia y veracidad de cada proceso, evento, módulo y comportamiento que conformará a Trunos+, este documento asegura que el Cuerpo de Bomberos del GAD Municipal obtendrá como resultado final un sistema en base a los requerimientos brindados por la entidad, y asegura que los desarrolladores no podrán entregar menos de lo acordado (ver anexo 2, aprobación del SRS). 5.2.3. Codificación Objetivo: Generar la lógica del negocio como lenguaje legible para el ordenador, es decir, armar el esqueleto del código fuente del sistema en base a la información recolectada en las fases anteriores de la metodología en cascada, para ello se implementa el uso de prototipos con el fin de comprobar la estabilidad de los componentes desarrollados.

Como primer punto en la generación de código fuente se parte desde la construcción y generación de los diagramas de base de datos, diagramas lógico y físico, para obtener el script de la base de datos a partir de los mismos, en las figuras 22 y 23 se puede observar los diagramas correspondientes. Para una mejor comprensión la generación del script de base de datos se puede apreciar en el anexo 3. Para la estructura de las entidades con sus atributos en el desarrollo de la presente disertación se hizo uso de la herramienta case Power Designer, bajo licencia estudiantil, para la obtención de los presentes scripts, diagramas correspondientes de la base de datos y gracias a las ventajas de Power Designer, permite crear los casos de uso, procedimientos almacenados, triggers en la base de datos, etc. En base a estas acotaciones se considera que es una herramienta completamente indispensable en la implementación. En el anexo 3 se puede apreciar el script correspondiente a la creación de la base de datos, sus entidades y respectivas funciones de validación. Siguiendo con el uso de las buenas prácticas se vio la necesidad de generar un código SQL limpio, ordenado y estructurado, es decir, los archivos fuente de base de datos se generan con fines de obtener un software de calidad, aceptable, estable y entendible ante cualquier nuevo desarrollador que ingrese al equipo de trabajo. En los gráficos a continuación se presenta gráficamente el modelado de la base de datos obtenidos como resultado de la fase de codificación.

Figura 22. Modelo fĂsico de la base de datos Fuente: F. Manzanilla; J. Olivo

Figura 23. Modelo lรณgico de la base de datos Fuente: F. Manzanilla; J. Olivo

5.2.3.1. Codificación - Nivel de base de datos (PgSQL) En la etapa de codificación también se brinda la funcionalidad excepcional de validar la aplicación a nivel de base de datos, de este modo se asegura la integridad de la misma; se crean los procedimientos almacenados para optimizar tiempo en consultas, al igual que la implementación de triggers (disparadores en español) para realizar una pre y post-evaluación de los datos (ver anexo 3) con atributos especiales dentro del esqueleto de la base de datos. Si algo hay que recalcar de PostgreSQL es el manejo de su propio lenguaje de programación, PgSQL (ver anexo 3) con el cual es posible la construcción de los elementos anteriormente mencionados. A continuación, se detallan algunas de las entidades en el modelo de datos de Turnos+ en el motor de base de datos y algunas de las validaciones a nivel de PosgreSQL.  tb_parametros: Almacenamiento de información primaria para el sistema, reportes, información de contacto, etc. CREATE TABLE admin.tb_parametros( parametro_id serial primary key, -- id de registro parametro_key text not null, -- variable de entorno parametro_value text not null -- valor de variable de entorno );

 tb_personas: Entidad a cargo del almacenamiento de información personal de usuarios como: administrador, técnico de atención, información, etc. CREATE TABLE admin.tb_personas( persona_id serial primary key, -- id de registro persona_tipo_doc text not null default 'CC'::text, -- doocumento de identificación persona_doc_identidad text not null, -- doocumento de identificación persona_nombres text not null, -- nombres de la persona persona_apellidos text not null, -- apellidos de la persona persona_sexo text, -- sexo de la persona persona_imagen text default 'default.png'::text, persona_direccion text, -- dirección de contacto persona_telefono text, -- teléfono de contacto persona_correo text, -- correo de contacto persona_fingreso timestamp without time zone default current_timestamp(0) -- fecha de registro );

 admin.before_delete_tablas: Creación y llamado de funciones e implementación de triggers, en la base de datos para las validaciones correspondientes a las entidades, utilizando el lenguaje psql, incorporado en el motor de base de datos PostgreSQL

63 create or replace function admin.before_delete_tablas() returns trigger as $before_delete_tablas$ begin IF (TG_TABLE_NAME = 'tb_perfiles') THEN -- No permite eliminar perfiles del sistema (creados en datos.sql) if(OLD.perfil_id<4) then RAISE EXCEPTION 'No se puede eliminar el perfil "%", este un perfil del sistema!', OLD.perfil_nombre; end if; END IF; RETURN OLD; end; $before_delete_tablas$ language plpgsql;

 Triggers: Realizan la petición de un servicio de validación o acción frente a un estímulo realizado en las entidades del modelo del sistema. create trigger before_delete_tablas before delete on admin.tb_perfiles for each row execute procedure admin.before_delete_tablas();

5.2.3.2. Codificación - Nivel de aplicación (PHP) Se conoce bien que todo desarrollo de software debe tomar sus bases fundamentales del estándar que brinde los mejores beneficios dependiendo de la orientación del software que se pretende crear. Posteriormente en esta etapa es necesario ya haber establecido el lenguaje de programación, así como su metodología y componentes a usar, ya que de ello depende el versionamiento del sistema en primera instancia. Por otro lado, se crean las bibliotecas y componentes para optimizar los tiempos de desarrollo. En cuanto al patrón de diseño que se utilizó para resolver la problemática es MVC, Modelo Vista Controlador, entonces en la implementación se tiene un controlador como punto de origen para la gestión de peticiones, se encarga de gestionarlas de manera correcta a la misma vez que comprueba y valida las restricciones de seguridad, maneja los errores, mapeos de rutas y delega las peticiones a otros componentes de la aplicación para que estos se encarguen de generar la vista adecuada para la respuesta al usuario. A continuación, se presenta algunos de los objetos de entidades de la aplicación informática; posteriormente a ello, en el anexo 4 se

presenta la creación de los modelos y entidades según el patrón de diseño MVC, así también se detalla los recursos empleados ya sean internos o externos (librerías de terceros).  Conexión a la base de datos: Instancia dinámica de la base de datos de acuerdo a la parametrización del sistema. class connectDB { private $db; public $estado = false; public $mensaje = 'No se pudo completar la transacción.. '; // Método: Constructor, crea instancia de PDO public function __construct() { try { extract($this->getConfig('db')[session::$sysName]); $this->db = new \PDO("$driver:dbname=$db;host=$host", "$user", "$pass"); } catch(PDOException $e) { echo json_encode(array('mensaje'=>$e->getMessage(), 'estado'=>false)); exit; } }

 Autoloader de clases: Método reservado del lenguaje PHP para permitir la instancia dinámica de las clases necesarias en tiempo de ejecución de la aplicación. spl_autoload_register(function($clase){ $clase = str_replace("\\","/",$clase); if(!file_exists("$clase.php")) return FALSE; else require_once "$clase.php"; }); 5.2.4. Pruebas Objetivo: Comprobar el adecuado funcionamiento de los módulos del sistema, sus acciones y tareas asignadas a los diferentes tipos de usuario en el sistema en un entorno donde los usuarios se desenvolverán esperando obtener la funcionalidad esperada de los componentes del sistema. Esta es quizás la etapa más importante de la metodología en cascada, en esta se estiman los riesgos futuros que pudiese haber dado origen a complicaciones o interrupciones en el correcto uso de la aplicación, entonces, es aconsejable realizar todo tipo de pruebas en conjunto con el cliente (usuario final), debido a que él es el único que tiene el conocimiento necesario y la

potestad para asegurar si el comportamiento de los distinto módulos cumplen con lo requerido que se establecido en la etapa de análisis. Previo a la implementación del sistema se ejecutan una serie de pruebas al sistema, las cuales se detallan en el anexo 6, en dichas pruebas el sistema se enfrenta ante un ambiente real como todos los escenarios estimados. Cada prueba es estimada por el usuario y es el mismo el que se encuentra en la potestad de liberar cada versión siempre y cuando cumpla con la funcionalidad prometida y establecida en el documento de especificación del software. Dichas pruebas sirven también como retroalimentación para los desarrolladores, a medida que se van corrigiendo detalles leves que pudiesen existir en el testeo de la aplicación. 5.2.5. Implementación Objetivo: Poner en producción el software, configurar los recursos necesarios para el correcto funcionamiento de la aplicación. La implementación es la etapa final de la metodología en cascada. El software luego de haber atravesado y cumplido con las etapas anteriores finalmente está listo para ponerse en producción. Se implantan los niveles software y hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto, en esta fase se hace uso de un documento físico para la legalización de entrega del proyecto) ver anexo 9), donde en se centran todas las partes involucradas en el desarrollo del sistema, disertantes y director del departamento de TIC del Cuerpo de Bomberos del GAD Municipal de Santo Domingo. Durante la explotación del sistema de software pueden surgir cambios, bien para corregir errores o para introducir mejoras siempre y cuando no se salgan del marco legal establecido en

la etapa de análisis y diseño. Por parte de los desarrolladores en el apartado de entregables los usuarios finales o clientes reciben la capacitación total de los diferentes módulos del sistema (ver anexo 7), además de los respectivos manuales de usuario (ver anexo 5), en el que se indica paso a paso cómo realizar cada tarea, los diferentes comportamientos del sistema frente a una acción del usuario y los ambientes en los que se involucrará el mismo dependiendo de sus acciones.

5.3. Conclusiones  La metodología de desarrollo en Cascada resultó ser la mejor opción, en el apartado de selección de herramientas en la fase de análisis, ya que es un modelo clásico dentro del ciclo de vida del desarrollo de software e implica un desarrollo rígido que se adaptó a las necesidades de nuestro trabajo de titulación.  La implementación de un documento legal (SRS) que sustente los requerimientos funcionales y no funcionales del sistema para el Cuerpo de Bomberos del GAD Municipal de Santo Domingo de los Colorados benefició a las partes relacionadas para ser implementadas en una aplicación funcional.  La etapa de pruebas por parte del personal involucrado permitió a los desarrolladores obtener la retroalimentación necesaria para la mitigar ciertas debilidades en los módulos del aplicativo y llevar a cabo un correcto control y gestión de calidad de software.  El uso del paradigma POO (Programación Orientada a Objetos) permitió que el desarrollo del proyecto se realice de manera ágil, ya que al construir una aplicación mediante objetos se puede hacer el uso de la reutilización de entidades (código), permitiendo optimizar el tiempo en construcción de las mismas.

 El uso del patrón de arquitectura de modelado de Software Modelo-Vista-Controlador (MVC) permitió tener una mayor escalabilidad del sistema y facilitó el mantenimiento en caso de solución de errores.  La implementación de la herramienta AngularJS fue de gran apoyo en el desarrollo de la aplicación informática, permitiendo optimizar el tiempo en la construcción de las vistas (front-end) de modo que permite crear módulos propios que se incorporen en toda la funcionalidad del sistema.  La capacitación al personal involucrado con el sistema informático fue concluida correctamente, merced de ello se asegura un adecuado funcionamiento del sistema.  El uso de herramientas de software libre para el desarrollo de Turnos+, permitieron la implementación sin la necesidad de asumir en gastos para el uso de estas herramientas.

5.4. Recomendaciones  Investigar sobre los modelos y arquitecturas de softwares que brinden a los desarrolladores la capacidad de optimizar los recursos empleados en las fases del desarrollo.  Adoptar las buenas prácticas en el desarrollo de aplicaciones informáticas, tomando en cuenta las nuevas tecnologías en el mercado que faciliten el desarrollo de los mismos.  Realizar la capacitación a los usuarios del sistema para su correcto uso y garantizar un buen funcionamiento y mejoras en el servicio a los clientes.  Impulsar a los estudiantes de la carrera de sistemas de la PUCE – SD a seguir desarrollando proyectos de investigación vinculados a la comunidad del cantón Santo Domingo para generar un impacto positivo.

 En el transcurso de un lapso de tiempo encuestar a la ciudadanía que acude a los servicios del Cuerpo de Bomberos para comprobar si se obtuvo un impacto positivo o negativo en cuanto a la prestación de servicios de la aplicación Turnos+.  Con la visión de nuevas aplicaciones o adaptaciones de módulos al sistema es necesario tener en cuenta los modelos de estudio incorporados a Turnos+, ya que al ser una aplicación escalar se estima una correcta unión con otros sistemas.

FUENTES BIBLIOGRÁFICAS  Fuentes bibliográficas Amaro, S., & Valverde, J. (2007). Metodologías Ágiles. Trujillo. Bernal, C. A. (2010). Metodología de la Investigación. Colombia: Pearson Educación, S.A. Bootsrap. (Abril de 2015). Bootstrap. Obtenido de http://getbootstrap.com/ Camazón, J. (2011). Sistemas Operativos Monopuestos. Madrid: Editorial Editex, S.A. Clarke, J. (2012). SQL Injection Attacks and Defense. United States of America: Elsevier, Inc. Coronel, C., Morris, S., & Rob, P. (2011). Bases de Datos, Diseño, Implementación y Administración. Mexco, D.F.: Cengage Learning Editores, S.A. Craig, L. (2003). UML y PATRONES. Una introducción al análisis y diseño orientados a objetos y al proceso unificado. Madrid: Pearson Education. Date, C. J. (2001). Introducción a los sistemas de base de datos. Mexico: Pearson Educación, S.A. Desongles Corrales, J., & Moya Arribas, M. (2006). Conceptos básicos de la informática. España: Editoria MAD, S.L. Gibert, M., & Pérez, O. (s.f.). Base de datos en PostgreSQL.

Pressman, R. S. (2010). Ingeniería de software. Un enfoque práctico. México: Mc Graw Hill. Ramos, A., & Ramos, J. (2011). Aplicaciones WEB. Madrid: Ediciones Paraninfo, S.A. S. Murugesan, Y. D. (2016). Web Engineering: A New Discipline for Development of Web-Based Systems. Springer 2001. Senplades. (2013). Plan Nacional para el Buen Vivir 2013-2017. Quito. Sommerville, I. (2005). Ingeniería del software. Madrid: Pearson Educación, S.A. Vélez, J., Peña, A., Gortázar, F., & Ángel, S. (2011). Diseñar y programar, todo es empezar: Una introducción a la programación orientada a objetos usando UML y Java. Madrid: Dykinson.  Fuentes lincográficas Alvarez, S. (7 de Febrero de 2006). Desarrollo web, tu mejor ayuda para aprender a hacer webs. Recuperado de Tipos de lenguaje de programación: http://www.desarrolloweb.com/articulos/2358.php Apache. (29 de 01 de 2015). Apache HTTP Server Project. Recuperado de https://httpd.apache.org/ Barrios, C., León, J., & Romero, Y. (2011). METODOLOGÍA DE PRESSMAN. Recuperado

https://sisteminformacii.wikispaces.com/METODOLOG%C3%8DA+DE+P RESSMAN+-+2DA+PARTE

Culturación. (Enero de 2011). Culturacion. Recuperado de ¿Qué es apache?: http://culturacion.com/que-es-apache/ Escuela Politécnica Nacional. (Mayo de 2011). Escuela Politécnica Nacional. Recuperado

http://bibdigital.epn.edu.ec/bitstream/15000/3823/1/CD-

3595.pdf Explorable Psycology Experiments. (15 de Noviembre de 2014). Investigación Experimental.

Obtenido

https://explorable.com/es/investigacion-

experimentalEscuela Politécnica Nacional. (Mayo de 2011). Escuela Politécnica

Nacional.

Recuperado

http://bibdigital.epn.edu.ec/bitstream/15000/3823/1/CD-3595.pdf Explorable Psycology Experiments. (15 de Noviembre de 2014). Investigación Experimental.Recuperado

https://explorable.com/es/investigacion-

experimental Grupo experimental de Núcleos y Partículas. (15 de Noviembre de 2014). Programación orientada a objetos: Clases y Objetos. Recuperado de http://fpsalmon.usc.es/genp/doc/cursos/poo/clases.html ITIL.

(s.f.).

ITIL

Gestión

servicio

TI.

Recuperado

http://itilv3.osiatis.es/estrategia_servicios_TI.php Jaramillo, E. (2012). Universidad Nacional de Colombia. Recuperado de DE LOS PROBLEMAS

LOS

PROGRAMAS:

http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060024/Lecciones/C apitulo%20I/problemas.htm

jQuery. (28 de 4 de 2015). jQuery write less, do more. Recuperado de http://blog.jquery.com/ MySQL Hispano. (29 de Mayo de 2003). Normalizaciรณn de bases de datos. Recuperado

http://www.eet2mdp.edu.ar/alumnos/MATERIAL/MATERIAL/info/infonor ma.pdf PostgreSQL. (2 de 10 de 2010). Sobre PostgreSQL | www.postgresql.org.es. Recuperado de http://www.postgresql.org.es/sobre_postgresql Webmaster Creativo - Herramientas para Webmasters. (11 de Juio de 2012). Hosting: definicion y tipos | Webmastercreativo -Herramientas para Webmasters. Recuperado tipos/

http://www.webmastercreativo.com/hosting-definicion-y-

GLOSARIO  Framework Es un ambiente de trabajo para desarrollo que dependiendo del lenguaje de programación incorpora distintos tipos de componentes que facilitan el desarrollo de aplicaciones.  MVC El Modelo Vista Controlador es un patrón de arquitectura de software, que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones.  DB (Data Base) Es un acrónimo que se utiliza para referirse a base de datos.  SGBD Es acrónimo que se utiliza para referirse a Sistema Gestor de Base de Datos. Un sistema gestor de base de datos (SGBD) es un conjunto de programas que permiten el almacenamiento, modificación y extracción de la información en una base de datos, además de proporcionar herramientas para añadir, borrar, modificar y analizar los datos.  PostgreSQL Es un sistema gestor de bases de datos relacional orientado a objetos y libre, publicado bajo la licencia PostgreSQL.

 Bootstrap Es un framework o conjunto de herramientas de software libre para diseño de sitios y aplicaciones web. Contiene plantillas de diseño con tipografía, formularios, botones, cuadros, menús de navegación y otros elementos de diseño basado en HTML y CSS, así como, extensiones de JavaScript opcionales adicionales.  POO La programación orientada a objetos es un paradigma de programación que viene a innovar la forma de obtener resultados. Los objetos manipulan los datos de entrada para la obtención de datos de salida específicos, donde cada objeto ofrece una funcionalidad especial.  PHP Es un lenguaje de programación de uso general de código del lado del servidor originalmente diseñado para el desarrollo web de contenido dinámico.  AngularJS Es un framework MVC de JavaScript para el desarrollo de interfaces en aplicaciones web.  JSON (JavaScript Object Notation) Es un formato de texto ligero para el intercambio de datos, es un subconjunto de la notación literal de objetos de JavaScript, aunque hoy, debido a su amplia adopción como alternativa a XML, se considera un formato de lenguaje independiente.

ANEXOS

ANEXO 1. ENCUESTA A SERVIDORES PÃ&#x161;BLICOS DEL CUERPO DE BOMBEROS DEL GADM SANTO DOMINGO

PONTIFICIA UNIVERSIDAD CATOLICA DEL ECUADOR SEDE SANTO DOMINGO

El motivo de la siguiente encuesta, es conocer la opinión del personal operativo con respecto al desarrollo e implementación de un sistema para la generación de turnos de los servicios del GAD Municipal del cuerpo de bomberos a la ciudadanía del cantón de Santo domingo de los Colorados, con el fin de obtener datos sobre el proceso que se lleva actualmente. INSTRUCCIONES Marque con una X en la respuesta seleccionada. NOTA La presente encuesta tiene como fin de investigar los servicios de atención. 1. Considera usted que la atención al cliente en los departamentos es eficiente. SI

2. Considera usted que la forma actual de entrega de turnos para atención al cliente es:

□ □ □ □ □

Excelente. Muy bueno Bueno Regular Malo

3. Cree usted que hay organización en la asignación de turnos para la atención al cliente:

□ □ □ □

Siempre Casi siempre A veces Pocas veces

4. ¿Cuál de los siguientes departamentos de Segunda Jefatura cree que es el más solicitado por el cliente?

□ □ □ □

Prevención Operaciones rurales Operaciones urbanas Otros _________________________________________________________

5. ¿Cree usted que se mejoraría la atención con la implementación de un software que genere turnos para la atención al cliente?

6. ¿Cree usted que es importante que el cliente evalué el rendimiento del recurso humano de atención del Cuerpo de Bomberos?

7. Desea usted que el sistema de generación de turnos controle referente a:

□ □ □ □

Detallar el tiempo de atención por asesor Detallar el tiempo de espera por atención del turno Periodos de tiempo del cliente desde su entrada hasta que es atendido Otros _________________________________________________________

8. Cree usted que un sistema para generar turnos optimizará el tiempo de atención al cliente. SI

9. Cuál de los siguientes beneficios piensa usted que brinda el sistema de Generación de Turnos al cuerpo de bomberos.

□ □ □ □

Mejora la calidad de servicio Mejora la imagen institucional Acelera la productividad Reportes automáticas sobre el estado del servicio

10. Cree usted que el sistema de Generación de Turnos le brindara al cliente que usa los

servicios del cuerpo de bomberos.: (marque con una X una o varias opciones)

□ □ □ □

Menor tiempo de espera del cliente Igualdad de trato Asignación de turnos en función al tipo de servicio Mayor comodidad

ANEXO 2. ESPECIFICACIÃ&#x201C;N DE REQUERIMEINTOS DE SOFTWARE

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica - Escuela de Sistemas

ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE (SRS) DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA PARA LA GENERACIÓN DE TURNOS DE LOS SERVICIOS DEL CUERPO DE BOMBEROS DEL GAD MUNICIPAL DEL CANTÓN DE SANTO DOMINGO DE LOS COLORADOS AÑO 2015

Trabajo de titulación previa a la obtención del título de Ingeniero de Sistemas y Computación

Autores:

MANZANILLA CRISTOBAL FERNANDO OLIVO VEGA JULIO CESAR

Director:

MG. RICHARD ESTALIN MAFLA TOBAR

Santo Domingo – Ecuador Julio, 2016

APROBACIÓN DEL DOCUMENTO DE ESPECIFICACIÓN DE REQUERIMIENTOS DEL SISTEMA

Santo Domingo, 22 julio de 2016

El documento de especificación de requerimientos del sistema, para el proyecto “DESARROLLO

E IMPLEMENTACIÓN DE UN SISTEMA PARA

LA GENERACIÓN DE TURNOS DE LOS SERVICIOS DEL CUERPO DE BOMBEROS DEL GAD MUNICIPAL DEL CANTÓN DE SANTO DOMINGO DE LOS COLORADOS AÑO 2015”, ha sido redactado en su totalidad por los disertantes en calidad de desarrolladores de la aplicación informática en base a los requerimientos expuestos por el área de sistemas del cuerpo de Bomberos del GAD Municipal de Santo Domingo. El documento es validado por el Director del área de sistemas.

Ing. Edwin Villamarin DIRECTOR DEL ÁREA DE SISTEMAS DEL CUERPO DE BOMBEROS DEL GAD MUNICIPAL DE SANTO DOMINGO

Julio César Olivo Vega DISERTANTE

Cristóbal Fernando Manzanilla Álvarez DISERTANTE

HISTORIA DE REVISIONES Fecha

Versión

Descripción

Autor

03/12/2015

1.0

Desarrollo e Implementación de un Sistema de turnos para atención al cliente del Cuerpo de Bomberos del GAD del cantón Santo Domingo.

- Julio Olivo - Fernando Manzanilla

15/01/2016

1.1

Rediseño por cambios administrativos - Julio Olivo en el Cuerpo de Bomberos del GAD - Fernando Manzanilla del cantón Santo Domingo.

20/01/2016

1.2

Cambios en los Perfiles de los usuarios para un mayor control del sistema.

- Julio Olivo - Fernando Manzanilla

ÍNDICE DE CONTENIDO HISTORIA DE REVISIONES ................................................................................................ III ÍNDICE DE CONTENIDO .....................................................................................................IV 1.

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

1.1. Propósito ........................................................................................................................... 1 1.2. Alcance del producto ........................................................................................................ 1 1.3. Personal involucrado ........................................................................................................ 2 1.4. Definiciones, acrónimos y abreviaturas ........................................................................... 2 1.5. Referencias ....................................................................................................................... 3 1.6. Resumen ejecutivo............................................................................................................ 3 2.

DESCRIPCIÓN GENERAL ............................................................................................ 5

2.1. Perspectiva del producto................................................................................................... 5 2.2. Funcionalidad del software............................................................................................... 5 2.2.1. Administración del sistema .............................................................................................. 5 2.2.2. Actividades del Administrador ......................................................................................... 5 2.2.3. Actividades del servidor público ...................................................................................... 6 2.3. Características de los usuarios .......................................................................................... 6 2.4. Restricciones..................................................................................................................... 8 2.5. Suposiciones y dependencias ........................................................................................... 8 3.

REQUISITOS ESPECÍFICOS ......................................................................................... 9

3.1. Interfaz .............................................................................................................................. 9

3.2. Requisitos Funcionales ..................................................................................................... 9 3.3. Requisitos comunes de las interfaces ............................................................................. 13 3.3.1. Interfaces de usuario ....................................................................................................... 13 3.3.2. Interfaz de hardware ....................................................................................................... 14 3.3.3. Interfaz de software ........................................................................................................ 14 3.3.4. Interfaz de comunicación ............................................................................................... 14 3.4. Restricciones de diseño .................................................................................................. 15 3.4.1. Estándares a seguir ......................................................................................................... 15 4.

CASOS DE USO ............................................................................................................ 16

4.1. Caso de uso específicos .................................................................................................. 16 4.1.1. Sesiones de usuario......................................................................................................... 16 4.1.2. Módulo usuarios ............................................................................................................. 18 4.1.3. MODULO JEFATURA.................................................................................................. 21 4.2. Módulo servicios ............................................................................................................ 27

1. INTRODUCCIÓN En el presente documento se explicará y analizará los requisitos del “Sistema para la Generación de Turnos de los Servicios”, desarrollado para el “Cuerpo de Bomberos del GAD Municipal del Cantón Santo Domingo” ubicado en la ciudad de Santo Domingo. Se adopta la guía de requerimientos de software de la IEEE Std. 830-1993.

1.1. Propósito Este documento tiene como propósito dar a conocer el funcionamiento general del proyecto de un “Sistema para la Generación de Turnos de los Servicios” que está dirigido a la atención al cliente del “Cuerpo de Bomberos del GAD Municipal del Cantón Santo Domingo” y a los estudiantes desarrolladores del proyecto. Además, permite una mejor organización y optimizar los procesos de atención al cliente por parte de los departamentos, la cual nos permitirá tener los reportes y registro de los clientes que atiende diariamente.

1.2. Alcance del producto El desarrollo e implementación del Sistema para la Generación de Turnos de los Servicios permitirá facilitar la asignación de turnos y reportes de los ciudadanos que solicitan los servicios prestados por parte de la institución, mejorando la atención en los departamentos de atención a la ciudadanía. Otro beneficio es obtener una herramienta que optimice los procesos de atención a la ciudadanía por parte del Cuerpo de Bomberos del GAD Municipal del Cantón Santo Domingo.

1.3. Personal involucrado Nombre

Julio Cesar Olivo Vega

Rol

Analista, documentador, diseñador, programador

Categoría Profesional

Disertante – PUCESD

Responsabilidad

Análisis de requerimientos, análisis de información, documentar manuales de instalación, diseñar interfaces de usuario, programación de Turnos+

Información de contacto

Nombre

Cristóbal Fernando Manzanilla Álvarez

Rol

Analista, documentador, diseñador, programador

Categoría Profesional

Disertante - PUCESD

Responsabilidad

Análisis de requerimientos, análisis de información, documentar manuales de instalación, diseñar interfaces de usuario, programación de Trunos+

Información de contacto

Nombre

MG. RICHARD ESTALIN MAFLA TOBAR

Rol

Consultor externo

Categoría Profesional

Tutor – PUCESD

Responsabilidad

Análisis de Turnos+ (validaciones constructivas)

Información de contacto

1.4. Definiciones, acrónimos y abreviaturas NOMBRE Trunos+

DESCRIPCIÓN Nombre del sistema: “Control de servicios de transporte terrestre”

SGT Usuario

Clave o nombre del usuario

Contraseña

Clave del usuario

Data Base

Base de datos (banco de datos que se utilizará para almacenar los registros)

PostgreSQL

Motor de base de datos, para almacenar la información del sistema

Apache

Aplicación para simular un servidor y permitir el acceso al sistema

PHP

JavaScript SRS

Lenguaje de programación para sitios web, al igual que HTML gran parte de sitios web están complementados con php, se lo puede reconocer por la extensión “.php” Lenguaje de programación basado en scripts, principalmente es implementado para complementar a otros lenguajes de programación. Ej. HTML Especificaciones de requerimientos de software, es un documento en la cual explicaremos el funcionamiento del software

IEEE

Institute of Electrical and Electronics Engineers

UML

Lenguaje de Modelado Unificado

1.5. Referencias Para el desarrollo del SRS el equipo de desarrollo se ha basado en los siguientes modelos:  Análisis Estructurado Moderno. Edward Yourdon (2011)  Ingeniería del software, Un enfoque práctico. Roger Pressman (2010)  830-1984d del IEEE para la Especificación de Requerimientos Software Más referencias ver fuentes bibliográficas en la lista de fuentes de consulta de la disertación.

1.6. Resumen ejecutivo La intensión de este sistema es la de permitir una mejor atención a la ciudadanía, brindando mayor agilidad y orden al momento de generar turnos de atención para los departamentos; de igual manera tener un reporte general de los servicios solicitados. El presente proyecto está realizado por estudiantes de la PUCE-SD de la escuela de Sistemas con conocimientos en el ámbito de programación y desarrollo de software. El documento está dividido en 3 secciones:



La sección 1 se enfoca en la explicación, propósito, alcance y descripción del documento.



La sección 2 se enfoca a la descripción general del sistema, donde la información está orientada al usuario potencial.



La sección 3 se enfoca en los requisitos específicos, donde se emplean términos técnicos orientados principalmente a los desarrolladores y programadores.

2. DESCRIPCIÓN GENERAL 2.1. Perspectiva del producto El Sistema para la Generación de Turnos de los Servicios facilitan la asignación de turnos y reportes de los ciudadanos, mediante el manejo de información que requiere el usuario la cual manifestara en el área de información el operador genera un turno según los departamentos y los servicios que presta a la ciudadanía. Además, el sistema contara con un reporte de los turnos generados diariamente, semanal y mensualmente la cual ayudara con la gestión departamental para la asignación de operadores en las áreas de servicios según las exigencias.

2.2. Funcionalidad del software 2.2.1. Administración del sistema  Parametrización del sistema 

Información del departamento

2.2.2. Actividades del Administrador  Módulo de usuarios 

Ingresar usuario



Modificar usuario 

Restablecimiento de contraseña



Deshabilitar cuenta de usuario



Reporte de usuarios

 Módulo de permisos (roles) 

Asignar permisos a usuarios



Revocar permisos a usuarios



Módulo de sucursales 

Ingresar sucursal



Administrar sucursal



Reporte de sucursales

Módulo de servicios 

Ingresar módulos



Administrar módulos



Ingresar servicios



Administrar servicios



Reporte de módulos



Reporte de servicios

2.2.3. Actividades del servidor público  Módulo de atención 

Visualizar turnos



Atender turnos



Reporte de turnos

2.3. Características de los usuarios Tipo de usuario

Administrador

Formación

Actividades

Administración de la información del sistema, usuarios, sucursales, servicios y módulos del sistema

Tipo de usuario

Servidor público

Formación

Actividades

Realizar la atención de turnos

El sistema contará con tres tipos de usuarios: 

Súper Administrador, conformado por el director del departamento de TIC, será el responsable de la administración del sistema en general, él no posee restricciones a ninguno de los módulos.



Administrador, conformado por la persona encargada del departamento de Talento Humano o Gerencia, será el/la responsable de administrar los usuarios, jefaturas, departamentos, servicios para las respectivas áreas de atención y generar los respectivos reportes.



Técnico de Atención, son los encargados de los departamentos de atención a la ciudadanía dependiendo del área de servicio.

Operador, el encargado de generar los turnos para los departamentos según las necesidades de la ciudadanía.

Técnico de Atención

ATENCIÓN

GENERAR TURNO

MÓDULOS

Administrador

SERVICIOS

SUCURSALES

Súper Administrador

ROLES

PERFILES

USUARIOS

MÓDULOS

X X

2.4. Restricciones El sistema respecto a la seguridad deberá considerar el uso de sesiones para limitar el acceso a los módulos y usuarios no autorizados. Prohibido el uso y reproducción del software sin autorización, el cual está protegido por leyes de autor.

2.5. Suposiciones y dependencias Es necesario en versiones futuras incluir un reporte de calificación por el servicio prestado a la ciudadanía.

3. REQUISITOS ESPECÍFICOS En esta sección se tienen con más detalle los requerimientos específicos del sistema a desarrollar, así mismo se presenta la funcionalidad a la que responderá cada módulo.

3.1. Interfaz La interfaz gráfica del sistema deberá ser intuitiva, de manera que el usuario final identifique rápidamente los componentes y las secciones del sistema. Además, deberá contar con los colores identificativos de la institución y ser fácil de operar. A continuación, se presenta los requerimientos funcionales y no funcionales que darán paso al desarrollo de los correctos módulos del sistema, detalladas más adelante.

3.2. Requisitos Funcionales Identificación de requerimiento

RF01

Nombre de requerimiento

Administración del sistema

Características

El sistema contará con un apartado para acceder a su información y administrarla, la que constará de:  Administración de información de contacto y de sistema  Administración de informes

Descripción de requerimiento

El sistema devolverá una interfaz para la actualización de información, la cual incluye información de contacto, información del sistema e imágenes de interfaces.

Requerimiento no funcional

-RNF01 -RNF03 -RNF04

Prioridad del requerimiento

Media

Identificación de requerimiento

RF02

Nombre de requerimiento

Autentificación de usuario

Características

Todo usuario debe identificarse para acceder al sistema

Descripción de requerimiento

El sistema devolverá una interfaz de acuerdo al nivel de acceso del usuario

Requerimiento no funcional

-RNF01 -RNF03

Prioridad del requerimiento

Alta

Identificación de requerimiento

RF03

Nombre de requerimiento

Registrar usuario

Características

Los usuarios deben ser registrados para acceder al sistema

Descripción de requerimiento

El sistema permitirá al usuario (rol - administrador) registrar a otros usuario (administradores, técnico de atención, etc). El usuario tendrá los datos principales como Nombre, Documento de identidad, etc.  Una vez registrado el usuario, este podrá acceder con su número de documento de identidad como usuario y contraseña, donde posteriormente estará en la libertad de cambiarlos.

Requerimiento no funcional

-RNF01 --RNF04

Prioridad del requerimiento

Media

Identificación de requerimiento

RF04

Nombre de requerimiento

Administración de usuarios

Características

Actualizar la información de usuario (usuario y contraseña) y/o deshabilitar cuenta

Descripción de requerimiento

El sistema permitirá al administrador gestionar la información de la cuenta de los usuarios, esta actividad servirá en el caso de que algún usuario haya olvidado su contraseña o identificación de usuario.  Cuando se realice este proceso inmediatamente el usuario o contraseña restablecidos volverá a su estado inicial (número de documento de identidad)  El usuario tendrá un aparatado para administrar su información

Requerimiento no funcional

-RNF01 -RNF04

Prioridad del requerimiento

Medio

Identificación de requerimiento

RF05

Nombre de requerimiento

Informe de usuarios

Características

Generar un informe de los usuarios (administrador, técnico de atención, etc)

Descripción de requerimiento

El sistema permite al administrador generar un reporte de usuarios.

Requerimiento no funcional

-RNF01 -RNF04

Prioridad del requerimiento

Medio

Identificación de requerimiento

RF06

Nombre de requerimiento

Registro de sucursales

Características

El administrador podrá registrar nuevas sucursales con su respectiva información

Descripción de requerimiento

El administrador ingresa una sucursal, posteriormente se realizan las respectivas validaciones (ruc, dirección, ciudad, representante legal, etc) para proceder a almacenar la información en los registros.  Razón social  Documento de registro único

Requerimiento no funcional

-RNF01 -RNF03 -RNF04

Prioridad del requerimiento

Alto

Identificación de requerimiento

RF07

Nombre de requerimiento

Administración de sucursales

Características

El administrador podrá gestionar la información de las sucursales

Descripción de requerimiento

En la administración de sucursales se realizará el cambio o actualización de datos respectivos a la misma, su deshabilitación en el sistema e incremento de servicios y módulos.  Habilitar/deshabilitar módulos  Habilitar/deshabilitar servicios  Administrar representante legal

Requerimiento no funcional

-RNF01 -RNF03 -RNF04

Prioridad del requerimiento

Media

Identificación de requerimiento

RF08

Nombre de requerimiento

Registro de representante legal

Características

La sucursal debe contar con un representante legal para que se pueda realizar operaciones en la misma, esta operación se realiza dentro del módulo de usuarios

Descripción de requerimiento

En el módulo de usuarios se puede realizar el levantamiento de un nuevo usuario con las características de representante legal, esto equivale a un nuevo rol permiso de acceso  El documento de identidad no puede ser duplicado

Requerimiento no funcional

-RNF01 -RNF03 -RNF04

Prioridad del requerimiento

Media

Identificación de requerimiento

RF09

Nombre de requerimiento

Administración de representante legal

Características

Es posible administrar la información de un representante legal de una sucursal, esta administración se realiza dentro de la gestión de usuarios

Descripción de requerimiento

En el módulo de usuarios se procede a gestionar la información del representante, y/o dar de baja en el sistema.

Requerimiento no funcional

-RNF01 -RNF03 -RNF04

Prioridad del requerimiento

Media

Identificación de requerimiento

RF10

Nombre de requerimiento

Informe de sucursales

Características

Generar un informe de los sucursales registradas en el sistema

Descripción de requerimiento

El administrador ingresa al módulo respectivo y procede a generar el tipo de informe que desee.

Requerimiento no funcional

-RNF01 -RNF04

Prioridad del requerimiento

Media

Identificación de requerimiento

RF11

Nombre de requerimiento

Registro de módulos y servicios

Características

Registrar servicios ofrecidos en el sistema y módulos (ventanillas de atención) para ser habilitadas en las sucursales

Descripción de requerimiento

El administrador ingresa al módulo de servicios y realiza el respectivo ingreso de la entidad, se realizan las validaciones correspondientes para proceder a guardar el registro.

Requerimiento no funcional

-RNF01 -RNF03 -RNF04

Prioridad del requerimiento

Media

Identificación de requerimiento

RF12

Nombre de requerimiento

Administración de servicios y módulos

Características

Unidad debe haber sido ingresada para poder administrarla

Descripción de requerimiento

Se permitirá realizar cambios en datos actuales de la unidad.

Requerimiento no funcional

-RNF01 -RNF03 -RNF04

Prioridad del requerimiento

Media

Identificación de requerimiento

RF13

Nombre de requerimiento

Informe de servicios

Características

Los reportes son generados en base a las peticiones del usuario

Descripción de requerimiento

El administrador ingresa al módulo de servicios y procede a generar el tipo de informe que desee.

Requerimiento no funcional

-RNF01 -RNF04

Prioridad del requerimiento

Media

Identificación de requerimiento

RF14

Nombre de requerimiento

Atención de turnos

Características

El usuario técnico en atención deberá asistir a los clientes en el trámite que deseen realizar.

Descripción de requerimiento

El usuario ingresa al módulo de atención y procede a visualizar los turnos pendientes en el sistema, los turnos deben presentarse en base a la acción que realiza el módulo.

Requerimiento no funcional

-RNF01 -RNF03 -RNF04

Prioridad del requerimiento

Media

Identificación de requerimiento

RF15

Nombre de requerimiento

Informe de turnos

Características

Los usuarios deben haber sido ingresados para poder visualizar los reportes

Descripción de requerimiento

El usuario ingresa al módulo de turnos y procede a generar el tipo de informe que desee.

Requerimiento no funcional

-RNF01 -RNF04

Prioridad del requerimiento

Media

3.3. Requisitos comunes de las interfaces 3.3.1. Interfaces de usuario Consiste en un conjunto de ventanas complementadas con el uso de formularios para acceder y administrar la información de los distintos módulos del sistema, como elementos de los formularios se tienen: botones, etiquetas, listas desplegables y cuadros de texto. Los distintos

elementos serán diseñados específicamente para el presente ejemplo, es decir, contarán con un único propósito que será de brindar la mejor experiencia al usuario. 3.3.2. Interfaz de hardware Como un apartado especial para el óptimo desenvolvimiento del sistema los equipos de los usuarios deberán contar con ciertos requerimientos mínimos:  Adaptadores de red (wifi o puerto físico alámbrico), para acceder al sistema mediante la arquitectura cliente-servidor.  Procesador de 1.66 GHz o superior, se estima como un procesador de escasos recursos, pero que posee la suficiente capacidad para soportar el sistema en ejecución.  Memoria mínima 512 MB, cabe recalcar que los recursos que consumirá el sistema no accederán los 15 MB. 3.3.3. Interfaz de software Los requerimientos mínimos del sistema deberán ser:  Sistema operativo (Windows, Linux, Mac, etc).  Navegador: Mozilla, Chrome, Safari, etc.  Software de visualización de archivos “pdf” Nota: Una recomendación de los desarrolladores es usar el navegador Google Chrome; debido a que el navegador es de los más completos en la actualidad y soporta de mejor manera los elementos de HTML5. 3.3.4. Interfaz de comunicación Se ha implementado la arquitectura cliente-servidor se comunica mediante protocolos estándares en Internet, siempre que exista una red local.  Redes LAN

 Conexión red (cable cruzado)  Internet

3.4. Restricciones de diseño 3.4.1. Estándares a seguir Para el diseño se basa principalmente en los formatos de:  Estándar del IEEE 830.  Análisis Estructurado Moderno de Edward Yourdon.  En cuanto a base de datos; modelo Entidad/Relación  Interfaz de usuario sencillo y minimalista

4. CASOS DE USO 4.1. Caso de uso específicos 4.1.1. Sesiones de usuario Las sesiones de usuario son una parte fundamental dentro de la aplicación informática, con esta se controlará los cambios realizados en el sistema, así como para el monitoreo de historial de información, para ello es importante registrar el acceso de los usuarios al sistema, donde se implementan 2 requerimientos no funcionales. 

Ingreso al sistema: Acción necesaria para poder acceder a los módulos del sistema y su información.

DESCRIPCIÓN DEL CASO DE USO NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN

ACTORES

PRECONDICIONES FLUJO NORMAL

FLUJO ALTERNATIVO

Iniciar Sesión Requerimiento no RNF-01 N° Funcional REQUERIMIENTO El sistema debe permitir el ingreso del nombre de usuario y contraseña para realizar las diferentes funciones de acuerdo al tipo de usuario.  Administrador Siempre FRECUENCIA  Usuario  Turnos El usuario debe estar registrado en el sistema. ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA 1. El usuario ingresa al sistema. 2. El sistema devuelve una interfaz 3. El usuario para poder iniciar solicitando el usuario sesión ingresa su respectivo: y Contraseña  Usuario 5. El sistema verifica  Contraseña. que el usuario exista y 4. El usuario da clic en el botón que la contraseña sea Login. correcta 6. El sistema despliega la interfaz principal de acuerdo al tipo de usuario ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA  El usuario no ingresa datos en  El sistema muestra un los campos mensaje de error

17  El usuario ingresa usuario o contraseña incorrectos  El usuario ingresa datos que no cumplen con el formato establecido  Si el usuario ingresa correctamente su usuario y contraseña accederá a todas las herramientas del sistema de acuerdo al POSTCONDICIONES tipo de usuario.  Si el usuario ingresa erróneamente tres veces consecutivas su usuario o contraseña el sistema bloqueará temporalmente la cuenta del usuario por 15 minutos. 04-ene-2016 21-ene-2016 FECHA CREACIÓN FECHA IMPLEMENTACIÓN Fernando Manzanilla – Julio Olivo TÉCNICO RESPONSABLE



Cierre de sesión de usuario: Es necesario que cada usuario después de culminar con sus labores diarias debe dar por terminada su estancia en el sistema, es decir deberá cerrar su sesión en el sistema para que proteger sus datos y a la información de la entidad.

DESCRIPCIÓN DEL CASO DE USO NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN ACTORES

PRECONDICIONES FLUJO NORMAL

POSTCONDICIONES FECHA CREACIÓN TÉCNICO RESPONSABLE

Cerrar Sesión Requerimiento no N° REQUERIMIENTO RNF-02 Funcional El sistema debe permitir al usuario cerrar sesión en cualquier momento.  Administrador Siempre FRECUENCIA  Usuario  Turnos  El usuario debe estar registrado en el sistema.  El usuario debe haber iniciado sesión. ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA 1. El usuario da clic en la 2. El sistema limpia toda la opción Cerrar Sesión información de sesión del del menú ubicado en la usuario. parte superior de la 3. El sistema despliega la interfaz. interfaz de Iniciar sesión del sistema. Al cerrar sesión el sistema volverá a la interfaz de Iniciar Sesión para que el usuario pueda acceder nuevamente al sistema. 03-ene-2016

FECHA IMPLEMENTACIÓN Fernando Manzanilla – Julio Olivo

21-ene-2016

4.1.2. Módulo usuarios Turnos plus al ser un sistema generador dinámico de turnos, depende de un usuario para poder complementar su correcto funcionamiento, es esa actividad donde se requiere de la implementación de usuario al sistema, con la finalidad de encargarse de las actividades que la aplicación informática no puede llevar a cabo sola. 

Crear usuarios: Acción de suma importancia para proceder a dar permisos de acceso a distintas entidades que interactúen en el sistema.

DESCRIPCIÓN DEL CASO DE USO NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN ACTORES PRECONDICIONES FLUJO NORMAL

Nuevo Usuario Requerimiento RF-01 N° REQUERIMIENTO Funcional El administrador del sistema tendrá la posibilidad de crear usuarios, que serán los encargados de las áreas de atención. Administrador Siempre FRECUENCIA El administrador debe haberse logueado e ingresar al módulo de Usuarios. ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA 1. El usuario da clic en la 2. El sistema devuelve una opción NUEVO, interfaz solicitando el ingreso ubicada en la barra de de los datos correspondientes botones. para la creación de un nuevo 3. El usuario ingresa la participante. información requerida 4. El sistema verifica si todos los 4. El usuario da clic en el campos fueron llenados botón Guardar. correctamente. 6. Guarda los datos en la respectiva base de datos

ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA  El usuario no ingresa  El sistema muestra un mensaje datos en los campos de error  El usuario ingresa número de cédula ya registrado anteriormente o no válido POSTCONDICIONES Si el administrador crea correctamente el usuario, el sistema mostrara el Modulo Usuario con sus diferentes opciones. 21-ene-2016 FECHA CREACIÓN 20-dic-2015 FECHA IMPLEMENTACIÓN Julio Olivo y Fernando Manzanilla TÉCNICO RESPONSABLE FLUJO ALTERNATIVO



Guardar usuarios: Acción inmediata al momento de registrar un nuevo usuario:

DESCRIPCIÓN DEL CASO DE USO Guardar Usuario Requerimiento RF-02 N° REQUERIMIENTO Funcional El administrador del sistema tendrá la posibilidad de guardar usuarios, que serán los encargados de las áreas de atención. Administrador Siempre ACTORES FRECUENCIA PRECONDICIONES El administrador debe crear e ingresar los datos del usuario. ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA FLUJO NORMAL 1. El usuario culmina el 2. El sistema verifica los datos ingreso de los datos. estén ingresados correctamente.  Número de Cédula 3. El usuario ingresa da  Nombres clic en la opción  Apellidos GUARDAR, ubicada  Correo Electrónico en la barra de botones  Dirección  Teléfono 4. El sistema almacena los datos en la base de datos y despliega un mensaje “DATOS GUARDADOS” ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA FLUJO ALTERNATIVO  El usuario no ingresa  El sistema muestra un mensaje datos en los campos de error  El usuario ingresa número de cédula ya registrado anteriormente o no válido  El usuario ingresa datos que no cumplan con el formato establecido para el campo. POSTCONDICIONES Si el administrador ingresa los datos correctamente del usuario, se podrá guardar los datos en la base de datos. 21-ene-2016 FECHA CREACIÓN 20-dic-2015 FECHA IMPLEMENTACIÓN Julio Olivo y Fernando Manzanilla TÉCNICO RESPONSABLE NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN

20 

Administración de cuentas de usuario

DESCRIPCIÓN DEL CASO DE USO NOMBRE

Administrar Usuario

TIPO REQUERIEMIENTO DESCRIPCIÓN

Requerimiento RF-03 N° REQUERIMIENTO Funcional El administrador del sistema tendrá la posibilidad de modificar los usuarios, que serán los encargados de las áreas de atención. Administrador Ocasional FRECUENCIA

ACTORES PRECONDICIONES

FLUJO NORMAL

FLUJO ALTERNATIVO

POSTCONDICIONES

FECHA CREACIÓN TÉCNICO RESPONSABLE

El administrador debe estar logueado y el usuario debe estar previamente registrado en la base de datos y ser seleccionado del reporte de los usuarios. ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA 1. El administrador da clic en reporte de usuarios. 3. Dar clic en el usuario seleccionado y da clic en el botón MODIFICAR. 5. Se modifica los campos necesarios y se da clic en GUARDAR. ACCIÓN DEL ACTOR

2. El sistema devuelve una interfaz de reporte con el listado de los usuarios registrados en la base de datos. 4. El sistema devuelve los datos del usuario y los habilita para la edición. 6. Guarda los datos en la respectiva base de datos y refresca la información del reporte. ACCIÓN DEL SISTEMA

 El administrador no  El sistema muestra un mensaje ingresa datos en los de error campos  El administrador no selecciona un usuario del reporte.  El administrador ingresa datos que no cumplan con el formato establecido para el campo. Si el administrador modifica correctamente el usuario, el sistema mostrara el Modulo de Usuario con sus diferentes opciones. 20-dic-2015 21-ene-2016 FECHA IMPLEMENTACIÓN Julio Olivo y Fernando Manzanilla

4.1.3. MODULO JEFATURA El aplicativo Turnos+ se caracteriza por jerarquizar a los diferentes departamentos del cuerpo de Bomberos del GAD Municipal en jefaturas, las mismas que se presentan como una organización dentro de la entidad. Es necesario comprender el proceso que conlleva esta acción dentro de las sucursales de la entidad. 

Ingresar jefaturas

DESCRIPCIÓN DEL CASO DE USO Nueva Jefatura Requerimiento RF-04 N° REQUERIMIENTO Funcional El administrador del sistema tendrá la posibilidad de crear Jefatura, que son las principales áreas administrativas. Administrador Ocasional ACTORES FRECUENCIA PRECONDICIONES El administrador debe haberse logueado e ingresar al módulo de Jefatura. ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA FLUJO NORMAL 1. El usuario da clic en 2. El sistema devuelve una la opción NUEVO, interfaz solicitando el ingreso ubicada en la barra de de los datos correspondientes botones. para la creación de una nueva 3. El usuario ingresa jefatura.  Número de 4. El sistema verifica si todos los Jefatura campos fueron llenados  Encargado correctamente.  Descripción 6. Guarda los datos en la 5. El administrador da respectiva base de datos clic en el botón Guardar. ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA FLUJO ALTERNATIVO  El administrador no  El sistema muestra un mensaje ingresa datos en los de error campos POSTCONDICIONES Si el administrador crea correctamente la Jefatura, el sistema mostrara el Modulo Jefatura con sus diferentes opciones. 21-ene-2016 FECHA CREACIÓN 20-dic-2015 FECHA IMPLEMENTACIÓN Julio Olivo y Fernando Manzanilla TÉCNICO RESPONSABLE NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN

22 

Guardar información de jefaturas

DESCRIPCIÓN DEL CASO DE USO NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN ACTORES PRECONDICIONES FLUJO NORMAL

Guardar Jefatura Requerimiento RF-05 N° REQUERIMIENTO Funcional El administrador del sistema tendrá la posibilidad de guardar Jefatura. Administrador Siempre FRECUENCIA El administrador debe llenar los datos de la Jefatura. ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1. El administrador 2. El sistema verifica los datos culmina el ingreso de estén ingresados los datos. correctamente.  Número de Jefatura  Encargado 3. El administrador  Descripción ingresa da clic en la 4. El sistema almacena los datos opción GUARDAR, en la base de datos y despliega ubicada en la barra de un mensaje “DATOS botones GUARDADOS” FLUJO ALTERNATIVO

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

 El usuario no ingresa  El sistema muestra un mensaje datos en los campos de error POSTCONDICIONES Si el administrador ingresa los datos correctamente del Jefatura, se podrá guardar los datos en la base de datos. 21-ene-2016 FECHA CREACIÓN 20-dic-2015 FECHA IMPLEMENTACIÓN Julio Olivo y Fernando Manzanilla TÉCNICO RESPONSABLE



Modificar la información de jefaturas

DESCRIPCIÓN DEL CASO DE USO Modificar Jefatura Requerimiento RF-06 N° REQUERIMIENTO Funcional El administrador del sistema tendrá la posibilidad de modificar las Jefatura. Administrador Ocasional ACTORES FRECUENCIA PRECONDICIONES El administrador debe estar logueado y el usuario debe estar previamente registrado en la base de datos y ser seleccionado del reporte de los usuarios. ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA FLUJO NORMAL 1. El administrador da 2. El sistema devuelve una interfaz clic en reporte de de reporte con el listado de Jefaturas. Jefaturas registradas en la base 3. Dar clic en la Jefatura de datos. seleccionada y da clic 4. El sistema devuelve los datos de en el botón la Jefatura y los habilita para la MODIFICAR. edición. 5. Se modifica los 6. Guarda los datos en la campos necesarios y respectiva base de datos y se da clic en refresca la información del GUARDAR. reporte. ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA FLUJO ALTERNATIVO  El administrador no  El sistema muestra un mensaje ingresa datos en los de error campos.  El administrador no selecciona un usuario del reporte. POSTCONDICIONES Si el administrador modifica correctamente la Jefatura, el sistema mostrara el Modulo de Jefatura con sus diferentes opciones. 21-ene-2016 FECHA CREACIÓN 20-dic-2015 FECHA IMPLEMENTACIÓN Julio Olivo y Fernando Manzanilla TÉCNICO RESPONSABLE NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN



Asignar departamentos a las jefaturas: La característica fundamental de las jefaturas es, alojar uno o más departamentos que ofrezcan distintos servicios a la comunidad, por lo tanto, es necesario un servicio que se encargue de la asignación de los departamentos a las jefaturas.

DESCRIPCIÓN DEL CASO DE USO NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN

ACTORES PRECONDICIONES FLUJO NORMAL

FLUJO ALTERNATIVO

Nuevo Departamentos Requerimiento Funcional

N° REQUERIMIENTO

RF-07

El administrador del sistema tendrá la posibilidad de crear Departamentos, que son los encargados de la atención al ciudadano. Administrador

FRECUENCIA

Siempre

El administrador debe haberse logueado e ingresar al módulo de Departamento. ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1. El administrador da clic 2. El sistema devuelve una en la opción NUEVO, interfaz solicitando el ingreso ubicada en la barra de de los datos correspondientes botones. para la creación de un nuevo 3. El administrador departamento. ingresa 4. El sistema verifica si todos los  Nombre del campos fueron llenados departamento. correctamente.  Selecciona a que 6. Guarda los datos en la jefatura respectiva base de datos pertenece. 5. El administrador da clic en el botón Guardar. ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA

 El administrador no  El sistema muestra un mensaje ingresa datos en los de error campos POSTCONDICIONES Si el administrador crea correctamente el departamento, el sistema mostrara el Modulo departamento con sus diferentes opciones. FECHA CREACIÓN TÉCNICO RESPONSABLE

20-dic-2015

21-ene-2016 FECHA IMPLEMENTACIÓN

Julio Olivo y Fernando Manzanilla



Guardar información de departamentos: Es necesario proceder a la validación del ingreso de datos, posterior a ello y solamente si se ha cumplido con las validaciones se asienta el registro de un nuevo departamento.

DESCRIPCIÓN DEL CASO DE USO NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN ACTORES PRECONDICIONES FLUJO NORMAL

Guardar Departamentos Requerimiento Funcional

N° REQUERIMIENTO

RF-08

El administrador del sistema tendrá la posibilidad de guardar Departamentos. Administrador

FRECUENCIA

Siempre

El administrador debe llenar los datos del Departamento. ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

2. El administrador 3. El sistema verifica los datos culmina el ingreso de estén ingresados los datos. correctamente.  Nombre del departamento.  Selecciona a que jefatura 3. El administrador pertenece. ingresa da clic en la  Descripción opción GUARDAR, 4. El sistema almacena los datos ubicada en la barra de en la base de datos y despliega botones un mensaje “DATOS GUARDADOS” FLUJO ALTERNATIVO

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

 El usuario no ingresa  El sistema muestra un mensaje datos en los campos de error POSTCONDICIONES Si el administrador ingresa los datos correctamente del departamento, se podrá guardar los datos en la base de datos. FECHA CREACIÓN TÉCNICO RESPONSABLE

20-dic-2015

21-ene-2016 FECHA IMPLEMENTACIÓN

Julio Olivo y Fernando Manzanilla



Modificar información de departamentos

DESCRIPCIÓN DEL CASO DE USO NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN ACTORES PRECONDICIONES

FLUJO NORMAL

FLUJO ALTERNATIVO

Modificar departamento Requerimiento Funcional

N° REQUERIMIENTO

RF-09

El administrador del sistema tendrá la posibilidad de modificar los departamentos. Administrador

FRECUENCIA

Ocasional

El administrador debe estar logueado y el departamento debe estar previamente registrado en la base de datos y ser seleccionado del reporte de los departamentos. ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1. El administrador da clic 2. El sistema devuelve una en reporte de interfaz de reporte con el listado departamentos. de los departamentos de la base 3. Dar clic en la de datos. departamento 4. El sistema devuelve los datos seleccionado y da clic del departamento y los habilita en el botón para la edición. MODIFICAR. 6. Guarda los datos en la 5. Se modifica los campos respectiva base de datos y necesarios y se da clic refresca la información del en GUARDAR. reporte. ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA

 El administrador no  El sistema muestra un mensaje ingresa datos en los de error campos.  El administrador no selecciona un departamento del reporte. POSTCONDICIONES Si el administrador modifica correctamente el departamento, el sistema mostrara el Modulo de departamentos con sus diferentes opciones. FECHA CREACIÓN TÉCNICO RESPONSABLE

20-dic-2015

FECHA IMPLEMENTACIÓN

Julio Olivo y Fernando Manzanilla

21-ene-2016



Dar de baja departamentos en el sistema

DESCRIPCIÓN DEL CASO DE USO NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN ACTORES PRECONDICIONES FLUJO NORMAL

FLUJO ALTERNATIVO

Eliminar Departamentos. Requerimiento Funcional

N° REQUERIMIENTO

RF-10

El administrador del sistema tendrá la posibilidad de eliminar Departamentos. Administrador

FRECUENCIA

Ocasional

El administrador debe estar logueado y el departamento debe estar previamente registrado en la base de datos. ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1. El administrador da clic en reporte de departamentos.

2. El sistema devuelve una interfaz de reporte con el listado de los departamentos registrados. 4. El sistema elimina el departamento seleccionada y despliega un mensaje ACCIÓN DEL SISTEMA

3. Dar clic en la Jefatura seleccionada y da clic en el botón ELIMINAR. ACCIÓN DEL ACTOR

 El administrador no  El sistema muestra un selecciona un mensaje de error departamento del reporte. POSTCONDICIONES Si el administrador elimina correctamente el departamento, el sistema mostrara el Modulo de Departamentos con sus diferentes opciones. FECHA CREACIÓN TÉCNICO RESPONSABLE

20-dic-2015

21-ene-2016 FECHA IMPLEMENTACIÓN

Julio Olivo y Fernando Manzanilla

4.2. Módulo servicios Los distintos departamentos que conforman a las jefaturas del Cuerpo de Bomberos del GAD Municipal de Santo Domingo, se estructuran de los servicios ofrecidos en ellos, para este proceso se detalla a continuación los procesos a realizar.



Creación de nuevos servicios: Los servicios que se desea ofrecer a la comunidad deben estar ligados a un departamento, y poder brindarlo a la comunidad, el proceso es el siguiente.

DESCRIPCIÓN DEL CASO DE USO NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN

ACTORES PRECONDICIONES FLUJO NORMAL

FLUJO ALTERNATIVO

Nuevo Servicio Requerimiento Funcional

N° REQUERIMIENTO

RF-11

El administrador del sistema tendrá la posibilidad de crear Servicios, que son las prestaciones que brindan cada departamento. Administrador

FRECUENCIA

Siempre

El administrador debe haberse logueado e ingresar al módulo de Servicios. ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1. El administrador da clic en la opción NUEVO, ubicada en la barra de botones. 3. El administrador ingresa 5. El administrador da clic en el botón Guardar.

2. El sistema devuelve una interfaz solicitando el ingreso de los datos correspondientes para la creación de un nuevo servicio. 4. El sistema verifica si todos los campos fueron llenados correctamente. 6. Guarda los datos en la respectiva base de datos

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

 El administrador no  El sistema muestra un mensaje ingresa datos en los de error campos POSTCONDICIONES Si el administrador crea correctamente el Servicio, el sistema mostrara el Modulo Servicios con sus diferentes opciones. FECHA CREACIÓN TÉCNICO RESPONSABLE

20-dic-2015

21-ene-2016 FECHA IMPLEMENTACIÓN

Julio Olivo y Fernando Manzanilla



Guardar información de servicios

DESCRIPCIÓN DEL CASO DE USO NOMBRE

Guardar Servicios

TIPO REQUERIEMIENTO

Requerimiento Funcional

DESCRIPCIÓN

ACTORES PRECONDICIONES FLUJO NORMAL

RF-12

N° REQUERIMIENTO

El administrador del sistema tendrá la posibilidad de guardar Servicios. Administrador

FRECUENCIA

Siempre

El administrador debe llenar los datos del Servicios. ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

3. El administrador 5. El sistema verifica los datos culmina el ingreso de estén ingresados correctamente. los datos.  Nombre del servicio.  Selecciona a que departamento pertenece. 7. El administrador  Descripción ingresa da clic en la 6. El sistema almacena los datos opción GUARDAR, en la base de datos y despliega ubicada en la barra un mensaje “DATOS de botones GUARDADOS” FLUJO ALTERNATIVO

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

 El usuario no ingresa  El sistema muestra un mensaje datos en los campos de error POSTCONDICIONES Si el administrador ingresa los datos correctamente del Servicio, se podrá guardar los datos en la base de datos. FECHA CREACIÓN

TÉCNICO RESPONSABLE

20-dic-2015

21-ene-2016 FECHA IMPLEMENTACIÓN

Julio Olivo y Fernando Manzanilla



Modificar información de servicios

DESCRIPCIÓN DEL CASO DE USO NOMBRE

Modificar Servicio

TIPO REQUERIEMIENTO

Requerimiento Funcional

DESCRIPCIÓN ACTORES PRECONDICIONES

FLUJO NORMAL

FLUJO ALTERNATIVO

N° REQUERIMIENTO

RF-13

El administrador del sistema tendrá la posibilidad de modificar los Servicios. Administrador

FRECUENCIA

Ocasional

El administrador debe estar logueado y el Servicio debe estar previamente registrado en la base de datos y ser seleccionado del reporte. ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1. El administrador da 2. El sistema devuelve una clic en reporte de interfaz de reporte con el servicio. listado de los departamentos de 3. Dar clic en la servicio la base de datos. seleccionado y da clic 4. El sistema devuelve los datos en el botón del departamento y los habilita MODIFICAR. para la edición. 5. Se modifica los 6. Guarda los datos en la campos necesarios y respectiva base de datos y se da clic en refresca la información del GUARDAR. reporte. ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA

 El administrador no  El sistema muestra un mensaje ingresa datos en los de error campos.  El administrador no selecciona un servicio del reporte. POSTCONDICIONES Si el administrador modifica correctamente el servicio, el sistema mostrara el Modulo de Servicios con sus diferentes opciones. FECHA CREACIÓN TÉCNICO RESPONSABLE

20-dic-2015

21-ene-2016 FECHA IMPLEMENTACIÓN

Julio Olivo y Fernando Manzanilla



Eliminación de servicios

DESCRIPCIÓN DEL CASO DE USO NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN ACTORES PRECONDICIONES FLUJO NORMAL

Eliminar Servicios. Requerimiento Funcional

N° REQUERIMIENTO

El administrador del sistema tendrá la posibilidad de eliminar Servicios. Administrador

FRECUENCIA

Ocasional

El administrador debe estar logueado y el servicio debe estar previamente registrado en la base de datos. ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1. El administrador da clic en reporte de Servicios.

2. El sistema devuelve una interfaz de reporte con el listado de los servicios en la base de datos. 4. El sistema elimina el servicio seleccionada y despliega un mensaje “SERVICO ELIMINADO” ACCIÓN DEL SISTEMA

3. Dar clic en el servicio seleccionado y da clic en el botón ELIMINAR.

FLUJO ALTERNATIVO

RF-14

ACCIÓN DEL ACTOR

 El administrador no  El sistema muestra un selecciona un servicio del mensaje de error reporte. POSTCONDICIONES Si el administrador elimina correctamente el Servicio, el sistema mostrara el Modulo de Servicios con sus diferentes opciones. FECHA CREACIÓN TÉCNICO RESPONSABLE

20-dic-2015

21-ene-2016 FECHA IMPLEMENTACIÓN

Julio Olivo y Fernando Manzanilla



Generación de reportes

DESCRIPCIÓN DEL CASO DE USO NOMBRE

Generar Reporte

TIPO REQUERIEMIENTO

Requerimiento Funcional

DESCRIPCIÓN

ACTORES PRECONDICIONES

FLUJO NORMAL

N° REQUERIMIENTO

El administrador del sistema tendrá la posibilidad de generar reportes de atención, de acuerdo a la fecha, departamento y usuario. Administrador

FRECUENCIA

Ocasional

El administrador debe haberse logueado e ingresar al Módulo de Reportes. ACCIÓN DEL ACTOR 1. El administrador deberá seleccionar las referencias para el reporte las cuales son los siguientes datos:  Fecha de inicio  Fecha de fin  Departamento  Usuario.

FLUJO ALTERNATIVO

RF-15

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 2. Seleccionar Generar reporte, mensaje de reporte generado.

ACCIÓN DEL SISTEMA

 El administrador no  El sistema muestra un mensaje selecciona un servicio de error del reporte.

POSTCONDICIONES Si el administrador genera el reporte correctamente de acuerdo a las características del reporte, el sistema exporta el reporte en formato PDF. FECHA CREACIÓN

TÉCNICO RESPONSABLE

20-dic-2015

21-ene-2016 FECHA IMPLEMENTACIÓN

Julio Olivo y Fernando Manzanilla



Generación de turnos

DESCRIPCIÓN DEL CASO DE USO NOMBRE

Siguiente Turnos

TIPO REQUERIEMIENTO

Requerimiento Funcional

DESCRIPCIÓN

ACTORES

PRECONDICIONES

FLUJO NORMAL

N° REQUERIMIENTO

El Técnico de Atención de los departamentos tendrá la posibilidad de solicitar turnos, que serán asignados por el módulo de generar turnos. Técnico de Atención

FRECUENCIA

Siempre

El Técnico de Atención debe haberse logueado e ingresar en el módulo de Atención y deben existir turnos generados para el departamento. ACCIÓN DEL ACTOR 1. El Técnico de atención deberá ingresar al módulo de atención y solicitar un turno. 2. El técnico visualiza los datos del ciudadano que solicita los servicios y presta los servicios y selecciona el detalle del servicio

FLUJO ALTERNATIVO

RF-18

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 2. El sistema verifica que existan turnos generados y lo visualiza en el monitor de turnos.

4. Mensaje de finalizado.

turno

ACCIÓN DEL SISTEMA

 El técnico de atención no  El sistema acumula el selecciona siguiente turno. contador de turnos en espera.

POSTCONDICIONES Si el operador del módulo de Generar Turno ha generado algún turno del departamento, el sistema visualizara el turno generado y que departamento pertenece.

FECHA CREACIÓN

TÉCNICO RESPONSABLE

20-dic-2015

21-ene-2016 FECHA IMPLEMENTACIÓN

Julio Olivo y Fernando Manzanilla



Reportar estado de usuario

DESCRIPCIÓN DEL CASO DE USO NOMBRE

Estado del Usuario

TIPO REQUERIEMIENTO

Requerimiento Funcional

DESCRIPCIÓN

ACTORES PRECONDICIONES

FLUJO NORMAL

N° REQUERIMIENTO

El Técnico de Atención podrá cambiar su estado de atención de Disponible y Ocupado, según las necesidades de los funcionarios. Técnico de Atención

FRECUENCIA

Siempre

El técnico de atención debe estar ingresado en el módulo de Atención y en caso de que el usuario necesita ausentarse del puesto de trabajo. ACCIÓN DEL ACTOR 1. El Técnico de atención deberá seleccionar un estado de atención.  Atendiendo  Ocupado o Alimentación o SSHH o Otros

FLUJO ALTERNATIVO

RF-19

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 2. El sistema verifica si hay turnos pendientes y despliega un mensaje del número de turnos que faltan por atender en su departamento. 3. El técnico deberá estar en estado disponible para poder solicitar turno de atención. ACCIÓN DEL SISTEMA

 El técnico de atención no  El sistema acumula el contador selecciona el estado de turnos en espera. disponible. POSTCONDICIONES Luego de la atender todos los turnos se podrá cerrar el módulo de atención. FECHA CREACIÓN TÉCNICO RESPONSABLE

20-dic-2015

21-ene-2016 FECHA IMPLEMENTACIÓN

Julio Olivo y Fernando Manzanilla

35 

Módulo de generar turnos

DESCRIPCIÓN DEL CASO DE USO NOMBRE

Nuevo Turnos Requerimiento Funcional

TIPO REQUERIEMIENTO DESCRIPCIÓN

ACTORES PRECONDICIONES

N° REQUERIMIENTO

El Operador que fue creado con el tipo de departamento de Generar Turno tendrá la posibilidad de crear turnos de atención, que se generaran de acuerdo a departamento o tipo de servicio. Operador

FRECUENCIA

Siempre

El usuario debe haberse logueado y de acuerdo al tipo de área del usuario se desplegara el menú y los módulos de atención deben estar habilitados para poder generar un turno. ACCIÓN DEL ACTOR

FLUJO NORMAL

ACCIÓN DEL SISTEMA

El usuario de información deberá registrar la información de los ciudadanos que solicitan un turno de atención, al cual se le solicitara los siguientes datos:      FLUJO ALTERNATIVO

RF-20

Cédula Nombre Apellido Descripción de atención. Área de atención ACCIÓN DEL ACTOR

4. Mensaje de error en caso de no haber llenado algún campo 5. Mensaje de error en el caso de ingresar un ciudadano que ya solicito algún servicio anteriormente y existente en la base de datos.

ACCIÓN DEL SISTEMA

POSTCONDICIONES Los módulos de atención deben estar habilitados para poder generar un turno. FECHA CREACIÓN

TÉCNICO RESPONSABLE

20-dic-2015

21-ene-2016 FECHA IMPLEMENTACIÓN

Julio Olivo y Fernando Manzanilla

ANEXO 3. MODELADO Y ESTRUCTURA DE LA BASE DE DATOS

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica - Escuela de Sistemas

MODELADO DE LA BASE DE DATOS

DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA PARA LA GENERACIÓN DE TURNOS DE LOS SERVICIOS DEL CUERPO DE BOMBEROS DEL GAD MUNICIPAL DEL CANTÓN DE SANTO DOMINGO DE LOS COLORADOS AÑO 2015

Trabajo de titulación previa a la obtención del título de Ingeniero de Sistemas y Computación

Autores:

MANZANILLA ÁLVAREZ CRISTÓBAL FERNANDO OLIVO VEGA JULIO CÉSAR

Director:

MG. RICHARD ESTALIN MAFLA TOBAR

Santo Domingo – Ecuador Julio, 2016

1. DIAGRAMAS DE LA BASE DE DATOS 1.1. Modelo fÃsico de la base de datos

1.2. Modelo lรณgico de la base de datos

1.3. Creaciรณn de a base de datos y entidades /*==============================================================*/ /* Table: cliente */ /*==============================================================*/ create table cliente ( cli_id int4 not null, cli_cedularuc varchar(14) null, cli_nombre varchar(50) null, cli_apellido varchar(50) null, cli_direccion varchar(200) null, cli_telefono varchar(50) null, cli_creadopor varchar(100) null, cli_fechacreacion date null, cli_modificadopor varchar(100) null, cli_fechamodificacion date null, constraint pk_cliente primary key (cli_id) ); /*==============================================================*/ /* Index: cliente_pk */ /*==============================================================*/ create unique index cliente_pk on cliente ( cli_id ); /*==============================================================*/ /* Table: departamento */ /*==============================================================*/ create table departamento ( dep_id int4 not null, jef_id int4 null, dep_nombre varchar(50) null, dep_creadopor varchar(100) null, dep_fechacreacion date null, dep_modificadopor varchar(100) null, dep_fechamodificacion date null, constraint pk_departamento primary key (dep_id) ); /*==============================================================*/ /* Index: departamento_pk */ /*==============================================================*/ create unique index departamento_pk on departamento ( dep_id ); /*==============================================================*/ /* Index: relationship_2_fk */ /*==============================================================*/ create index relationship_2_fk on departamento ( jef_id ); /*==============================================================*/ /* Table: jefatura */ /*==============================================================*/ create table jefatura ( jef_id int4 not null, suc_id int4 null, jef_nombre varchar(100) null, jef_creadopor varchar(100) null, jef_fechacreacion date null, jef_modificadopor varchar(100) null, jef_fechamodificacion date null, constraint pk_jefatura primary key (jef_id) );

/*==============================================================*/ /* Index: jefatura_pk */ /*==============================================================*/ create unique index jefatura_pk on jefatura ( jef_id ); /*==============================================================*/ /* Index: relationship_10_fk */ /*==============================================================*/ create index relationship_10_fk on jefatura ( suc_id ); /*==============================================================*/ /* Table: perfil */ /*==============================================================*/ create table perfil ( per_id int4 not null, per_nombre varchar(50) null, per_activo varchar(2) null, per_creadopor varchar(100) null, per_fechacreacion date null, per_modificadopor varchar(100) null, per_fechamodificacion date null, constraint pk_perfil primary key (per_id) ); /*==============================================================*/ /* Index: perfil_pk */ /*==============================================================*/ create unique index perfil_pk on perfil ( per_id ); /*==============================================================*/ /* Table: secuencia */ /*==============================================================*/ create table secuencia ( sec_id int4 not null, dep_id int4 null, sec_secuencia int4 null, constraint pk_secuencia primary key (sec_id) ); /*==============================================================*/ /* Index: secuencia_pk */ /*==============================================================*/ create unique index secuencia_pk on secuencia ( sec_id ); /*==============================================================*/ /* Index: relationship_12_fk */ /*==============================================================*/ create index relationship_12_fk on secuencia ( dep_id );

8 /*==============================================================*/ /* Table: servicio */ /*==============================================================*/ create table servicio ( ser_id int4 not null, dep_id int4 null, ser_nombre varchar(50) null, ser_creadopor varchar(100) null, ser_fechacreacion date null, ser_modificadopor varchar(100) null, ser_fechamodificacion date null, constraint pk_servicio primary key (ser_id) ); /*==============================================================*/ /* Index: servicio_pk */ /*==============================================================*/ create unique index servicio_pk on servicio ( ser_id ); /*==============================================================*/ /* Index: relationship_11_fk */ /*==============================================================*/ create index relationship_11_fk on servicio ( dep_id ); /*==============================================================*/ /* Table: sucursal */ /*==============================================================*/ create table sucursal ( suc_id int4 not null, suc_nombre varchar(100) null, suc_direccion varchar(200) null, suc_telefono varchar(50) null, suc_creadopor varchar(100) null, suc_fechacreacion date null, suc_modificadopor varchar(100) null, suc_fechamodifica date null, constraint pk_sucursal primary key (suc_id) ); /*==============================================================*/ /* Index: sucursal_pk */ /*==============================================================*/ create unique index sucursal_pk on sucursal ( suc_id ); /*==============================================================*/ /* Table: turno */ /*==============================================================*/ create table turno ( tur_id int4 not null, cli_id int4 null, sec_id int4 null, tur_turno int4 null, tur_estado varchar(20) null, tur_fecha date null, tur_detalle varchar(20) null, constraint pk_turno primary key (tur_id) );

9 /*==============================================================*/ /* Index: turno_pk */ /*==============================================================*/ create unique index turno_pk on turno ( tur_id ); /*==============================================================*/ /* Index: relationship_5_fk */ /*==============================================================*/ create index relationship_5_fk on turno ( cli_id ); /*==============================================================*/ /* Index: relationship_7_fk */ /*==============================================================*/ create index relationship_7_fk on turno ( sec_id ); /*==============================================================*/ /* Table: usuario */ /*==============================================================*/ create table usuario ( usu_id int4 not null, per_id int4 null, dep_id int4 null, usu_activo varchar(2) null, usu_estado varchar(10) null, usu_cedula varchar(10) null, usu_nombre varchar(50) null, usu_apellido varchar(50) null, usu_direccion varchar(200) null, usu_telefono varchar(50) null, usu_correo varchar(100) null, usu_usuario varchar(50) null, usu_clave varchar(50) null, usu_creadopor varchar(100) null, usu_fechacreacion date null, usu_modificadopor varchar(100) null, usu_fechamodificacion date null, constraint pk_usuario primary key (usu_id) ); /*==============================================================*/ /* Index: usuario_pk */ /*==============================================================*/ create unique index usuario_pk on usuario ( usu_id ); /*==============================================================*/ /* Index: relationship_8_fk */ /*==============================================================*/ create index relationship_8_fk on usuario ( per_id );

1.4. CreaciĂłn de triggers (disparadores) Los disparadores (triggers en inglĂŠs) se implementan para realizar distintos tipos de validaciones o acciones a nivel de base de datos, en este proceso se acoplan los tiggers creados

para asegurar la integridad de los datos almacenados, ej.: Validar los campos que no pueden ser duplicados, uno de ellos es el número de entidad, cédula o pasaporte. 

A continuación, se presentan los triggers implementados en Turnos+, así como de respectiva información. Validaciones en los campos de administración, para evitar la duplicación de datos principales.

create or replace function admin.before_insert_tablas() returns trigger as $before_insert_tablas$ begin IF (TG_TABLE_NAME = 'tb_personas') THEN if((select count(*) from admin.tb_personas where lower(persona_doc_identidad)=lower(NEW.persona_doc_identidad))>0) then RAISE EXCEPTION 'El número de documento de identificación "%" y se ha registrado!', NEW.persona_doc_identidad; end if; ELSIF (TG_TABLE_NAME = 'tb_usuarios') THEN if((select count(*) from admin.tb_usuarios where lower(usuario_login)=lower(NEW.usuario_login))>0) then RAISE EXCEPTION 'El usuario "%" ya se ha registrado', NEW.usuario_login; end if; ELSIF (TG_TABLE_NAME = 'tb_perfiles') THEN if((select count(*) from admin.tb_perfiles where lower(perfil_nombre)=lower(NEW.perfil_nombre))>0) then RAISE EXCEPTION '"%" y se ha registrado', NEW.perfil_nombre; end if; END IF; RETURN NEW; end; $before_insert_tablas$ language plpgsql; -- ------------------------------- INVOCA AL LLAMADO DE LOS TRIGGER ------------------------------create trigger before_insert_tablas before insert on admin.tb_personas for each row execute procedure admin.before_insert_tablas(); create trigger before_insert_tablas before insert on admin.tb_usuarios for each row execute procedure admin.before_insert_tablas(); create trigger before_insert_tablas before insert on admin.tb_perfiles for each row execute procedure admin.before_insert_tablas(); -- TRIGGER #: 3 -- NOMBRE: before_update_tablas -- EVENTO: BEFORE UPDATE (ANTES DE ACTUALIZAR) -- DESCRIPCIÓN:Valida que ciertos datos no hayan sido ingresados anteriormente, en el caso de ser registrado -envía un mensaje de alerta como resultado de la transacción y cancela la edición del registro create or replace function admin.before_update_tablas() returns trigger as $before_update_tablas$ begin IF (TG_TABLE_NAME = 'tb_personas') THEN -- Cédula de identidad única if(OLD.persona_doc_identidad<>NEW.persona_doc_identidad) THEN if((select count(*) from admin.tb_personas where lower(persona_doc_identidad)=lower(NEW.persona_doc_identidad) and OLD.persona_id<>NEW.persona_id)>0) then

11 RAISE EXCEPTION 'La cédula % ya está registrada!', NEW.persona_doc_identidad; end if; END IF; ELSIF(TG_TABLE_NAME = 'tb_perfiles') THEN -- Nombre de perfil único if(OLD.perfil_nombre<>NEW.perfil_nombre) THEN if((select count(*) from admin.tb_perfiles where lower(perfil_nombre)=lower(NEW.perfil_nombre) and OLD.perfil_id<>NEW.perfil_id)>0) then RAISE EXCEPTION '% ya es un perfil registrado', NEW.perfil_nombre; end if; END IF; ELSIF(TG_TABLE_NAME = 'tb_usuarios') THEN -- Identificación de usuario (login) único if(OLD.usuario_login<>NEW.usuario_login) THEN if((select count(*) from admin.tb_usuarios where lower(usuario_login)=lower(NEW.usuario_login) and OLD.usuario_id<>NEW.usuario_id)>0) then RAISE EXCEPTION 'El usuario % ya se ha registrado', NEW.usuario_login; end if; if((select count(*) from admin.tb_personas where lower(persona_doc_identidad)=lower(NEW.usuario_login) and OLD.persona_id<>NEW.fk_persona_id)>0) then RAISE EXCEPTION 'El usuario % ya se ha registrado', NEW.usuario_login; end if; END IF; END IF; return new; end; $before_update_tablas$ language plpgsql; -- ------------------------------- INVOCA AL LLAMADO DE LOS TRIGGER ------------------------------create trigger before_update_tablas before update on admin.tb_personas for each row execute procedure admin.before_update_tablas(); create trigger before_update_tablas before update on admin.tb_perfiles for each row execute procedure admin.before_update_tablas(); create trigger before_update_tablas before update on admin.tb_usuarios for each row execute procedure admin.before_update_tablas(); -- ------------------------------------------------------------------------------------------------- TRIGGER #: 4 -- NOMBRE: before_delete_tablas -- EVENTO: BEFORE DELETE (ANTES DE ELIMINAR) -- DESCRIPCIÓN:Principalmente se encarga validar que los datos a registrar no hayan sido relacionados o no sean protegisdos por el sistema create or replace function admin.before_delete_tablas() returns trigger as $before_delete_tablas$ begin IF (TG_TABLE_NAME = 'tb_perfiles') THEN -- No permite eliminar perfiles del sistema (creados en datos.sql) if(OLD.perfil_id<4) then RAISE EXCEPTION 'No se puede eliminar el perfil "%", este un perfil del sistema!', OLD.perfil_nombre; end if; END IF; RETURN OLD; end; $before_delete_tablas$ language plpgsql; -- ------------------------------- INVOCA AL LLAMADO DE LOS TRIGGER ------------------------------create trigger before_delete_tablas before delete on admin.tb_perfiles

12 for each row execute procedure admin.before_delete_tablas();



Acciones posteriores al ingreso de datos en el schema de administración. create or replace function admin.after_insert_tablas() returns trigger as $after_insert_tablas$ begin IF (TG_TABLE_NAME = 'tb_usuarios') THEN INSERT INTO admin.tb_usuario_permiso values(NEW.usuario_id,1),(NEW.usuario_id,2),(NEW.usuario_id,3),(NEW.usua rio_id,4),(NEW.usuario_id,5); if(NEW.fk_perfil_id=2) then -- Administrador INSERT INTO admin.tb_usuario_permiso values(NEW.usuario_id,103),(NEW.usuario_id,104), (NEW.usuario_id,201),(NEW.usuario_id,202),(NEW.usuario_id,203); elsif(NEW.fk_perfil_id=3) then -- Atención en ventanilla INSERT INTO admin.tb_usuario_permiso values (NEW.usuario_id,601); elsif(NEW.fk_perfil_id>3) then -- Otros end if; END IF; INSERT INTO admin.tb_actividad(evento,tabla,fk_usuario_id)values('Insertar',quote_id ent(TG_TABLE_NAME),NEW.fk_usuario_id); RETURN NULL; end; $after_insert_tablas$ language plpgsql; -- ------------------------------- INVOCA AL LLAMADO DE LOS TRIGGER ------------------------------create trigger after_insert_tablas after insert on admin.tb_usuarios for each row execute procedure admin.after_insert_tablas();

ANEXO 4. PROGRAMACIÃ&#x201C;N PHP

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica - Escuela de Sistemas A DA

PROGRAMACIÓN PHP

DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA PARA LA GENERACIÓN DE TURNOS DE LOS SERVICIOS DEL CUERPO DE BOMBEROS DEL GAD MUNICIPAL DEL CANTÓN DE SANTO DOMINGO DE LOS COLORADOS AÑO 2015

Trabajo de titulación previa a la obtención del título de Ingeniero de Sistemas y Computación

Autores:

MANZANILLA ÁLVAREZ CRISTÓBAL FERNANDO OLIVO VEGA JULIO CÉSAR

Director:

MG. RICHARD ESTALIN MAFLA TOBAR

Santo Domingo – Ecuador Julio, 2016

PROGRAMACIÓN PHP

Como ya se ha explicado anteriormente los diferentes módulos que conforman el sistema, así como las herramientas que se utilizan para la concesión del mismo, como resultado se presenta en este apartado el resultado final, donde intervienen las entidades, objetos, características y métodos de los mismos. <?php namespace api; use app as ini; class app { public static function AutoLoader(){ // Obtener configuración personalizada de PHP v5.5 require_once 'app/conf.ini.php'; // CREATE RESTFULL extract(self::getURI()); ini_set("error_log", "src/debug/$sys-app-php-error.log"); if(!in_array($sys,loadCongf('sudo')))return301("Acceso no autorizado"); // AUTOLOADER DE CLASES spl_autoload_register(function($clase){ $clase = str_replace("\\","/",$clase); if(!file_exists("$clase.php")) return FALSE; else require_once "$clase.php"; }); try{ new ini\route($sys); } catch(Exception $e) { echo $e->getMessage(); // Captura errores, en caso de existir } exit; } private static function getURI(){ $params=explode("/",$_GET['_url']); if(count($params)>=3 || isset($_GET['qry'])){ $request=array('sys'=>$params[1],'db'=>$params[2]); if(count($params)>3)$request['serial']=$params[3]; return $request; } return301('Parámetros inclompletos!'); } }

2. INSTANCIA DE LA APLICACIÓN Como en toda aplicación POO que se sustente en el uso las buenas prácticas, se obtiene un constructor que permite realizar la primera instancia del proyecto, en las siguientes líneas se presenta la clase principal de la aplicación donde se iniciara el resto las clases para dar la funcionalidad del modelo, así como de una instancia automática de la clase de conexión hacia la base de datos: <?php namespace app; /** * Description of connectDB * connectDB.php hereda la conexión de la base de datos junto con los métodos de acceso a los registros del sistema, * este proceso se ha realizado de forma semi-automatizada ya que se ha realizado procesos con recursividad * con la finalidad de optimizar recursos (memoria en sistema en el caso de generar variables auxiliares) */ // Clase hija, Hereda métodos de clase de model, lo que le permite acceder a los métodos aún cuando estos no sean // declarados en la presente clase class connectDB { private $db; public $estado = false; public $mensaje = 'No se pudo completar la transacción.. '; // Método: Constructor, crea instancia de PDO public function __construct() { try { extract($this->getConfig('db')[session::$sysName]); $this->db = new \PDO("$driver:dbname=$db;host=$host", "$user", "$pass"); } catch(PDOException $e) { echo json_encode(array('mensaje'=>$e->getMessage(), 'estado'=>false)); exit; } } // Método: Restablecer los mensaje de respuesta de conexión private function resetMessage(){ $this->estado = false; $this->mensaje = 'No se pudo completar la transacción.. '; } // Realiza la consulta comprobando si existen errores private function testErrorPDO($sql){

$this->resetMessage(); $sql = $this->prepare($sql); $sql->execute(); $myError = $sql->errorInfo(); if($myError[0]!=0){ echo json_encode(array('mensaje'=>$this>mensaje.$myError[2],'estado'=>false)); exit; } return $sql; } // Ejecuta las consultas sql public function consulta($sql){ return $this->testErrorPDO($sql); } // Test de consulta activando pruebas de error (mensajes db) public function prepare($sql){ $this->db->setAttribute(\PDO::ATTR_ERRMODE, \PDO::ERRMODE_WARNING); return $this->db->prepare($sql); } // ************************************* findAll AutoSQL ************************************** protected function findAll($str){ $sql = $this->testErrorPDO($str); return $sql->fetchAll(\PDO::FETCH_ASSOC); } protected function findOne($str){ $sql = $this->testErrorPDO($str); return $sql->fetch(\PDO::FETCH_ASSOC); } // Retorna el listado de registro a partir de un "string" public function fetch_str($str, $type='fetch'){ $sql = $this->testErrorPDO($str); return $sql->$type(\PDO::FETCH_ASSOC); } // Retorna el listado de registro a partir de una consulta sql anterior public function fetch_sql($sql, $type='fetch'){ return $sql->$type(\PDO::FETCH_ASSOC); } // Retorna el nuemero de registros de una consulta sql anterior public function num_rows($sql, $auto=false){ if($auto) $sql = $this->consulta($sql); return $sql->rowCount(); } // Realiza la consulta sql, preparando los mensaaje que serรกn presentados con la respuesta public function execute($sql){ $this->resetMessage(); $sql = $this->prepare($sql); $exec = $sql->execute();

$this->estado = ($exec > 0 ? true : false); $this->mensaje = ($exec< 1 ? $this->mensaje.$sql->errorInfo()[2] : 'Transacción completa!'); } // Método: Realiza consultar unitarias (principalmente para ejecutar en una transacción) public function executeSingle($sql){ $this->execute($sql); return $this->setJSON($this->mensaje, $this->estado); } (……) }

ANEXO 5. MANUAL DE USUARIO

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica - Escuela de Sistemas

MANUAL DE USUARIO DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA PARA LA GENERACIÓN DE TURNOS DE LOS SERVICIOS DEL CUERPO DE BOMBEROS DEL GAD MUNICIPAL DEL CANTÓN DE SANTO DOMINGO DE LOS COLORADOS AÑO 2015

Trabajo de titulación previa a la obtención del título de Ingeniero de Sistemas y Computación

Autores:

MANZANILLA ÁLVAREZ CRISTÓBAL FERNANDO OLIVO VEGA JULIO CÉSAR

Director:

MG. RICHARD ESTALIN MAFLA TOBAR

Santo Domingo – Ecuador Julio, 2016

ÍNDICE DE CONTENIDOS 1.

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

FUNCIONES DEL SISTEMA .................................................................................... 2

2.1. Aspectos generales ....................................................................................................... 2 2.2. Botones del sistema ...................................................................................................... 3 2.3. Inicio de sesión ............................................................................................................. 4 2.3.1. Proceso para iniciar sesión en el sistema ..................................................................... 4 2.3.2. Problemas al iniciar sesión ........................................................................................... 5 2.4. Página Principal ........................................................................................................... 5 2.4.1. Menú de Interfaz .......................................................................................................... 6 2.5. Perfil Administrador..................................................................................................... 7 2.5.1. Usuarios ....................................................................................................................... 8 2.5.2. Asignación de Permisos ............................................................................................. 11 2.5.3. Departamentos............................................................................................................ 12 2.5.4. Servicios ..................................................................................................................... 14 2.5.5. Configurar Sitio.......................................................................................................... 16 2.5.6. Sucursales y Jefaturas ................................................................................................ 17 2.5.7. Cerrar Sesión .............................................................................................................. 19

iii

ÍNDICE DE FIGURAS FIGURA 1. MENSAJE DE ÉXITO .......................................................................................... 2 FIGURA 2. MENSAJE SIN ÉXITO ......................................................................................... 2 FIGURA 3. INTERFAZ DE INICIO DE SESIÓN. .................................................................. 4 FIGURA 4. MENSAJE DE CREDENCIALES CORRECTAS. ............................................... 5 FIGURA 5. PÁGINA PRINCIPAL ........................................................................................... 6 FIGURA 6. MENÚ DE LAS INTERFACES. ........................................................................... 7 FIGURA 7. MENÚ DE ADMINISTRACIÓN. ......................................................................... 7 FIGURA 8. USUARIOS: MODULO DE USUARIOS ............................................................. 8 FIGURA 9. FORMULARIO INGRESO NUEVO USUARIO ................................................. 9 FIGURA 10. REGISTRO DE USUARIO EXITOSO ............................................................... 9 FIGURA 11. REGISTRO DE USUARIO SIN ÉXITO........................................................... 10 FIGURA 12. MENSAJE DE ÉXITO. ..................................................................................... 10 FIGURA 13. DESHABILITAR USUARIO ............................................................................ 11 FIGURA 14. ADMINISTRACIÓN DE PERMISOS. ............................................................. 12 FIGURA 15. MENSAJE DE ÉXITO ASIGNACIÓN DE PERMISOS.................................. 12 FIGURA 16. INGRESO NUEVO DEPARTAMENTO. ......................................................... 13

FIGURA 17. MENSAJE DE ÉXITO DEPARTAMENTO NUEVO. ..................................... 13 FIGURA 18. TABLA DE DEPARTAMENTOS. ................................................................... 13 FUENTE: LOS AUTORES. .................................................................................................... 13 FIGURA 19. MODIFICAR DEPARTAMENTO. .................................................................. 14 FUENTE: LOS AUTORES. .................................................................................................... 14 FIGURA 20. MENSAJE DE ÉXITO MODIFICACIÓN DE DEPARTAMENTO. ............... 14 FUENTE: LOS AUTORES. .................................................................................................... 14 FIGURA 21. INGRESAR NUEVO SERVICIO. .................................................................... 15 FIGURA 22. MENSAJE DE ÉXITO NUEVO SERVICIO. ................................................... 15 FUENTE: LOS AUTORES. .................................................................................................... 15 FIGURA 23. TABLA DE SERVICIOS .................................................................................. 15 FIGURA 24. MODIFICAR SERVICIO .................................................................................. 16 FIGURA 25. MENSAJE DE ÉXITO MODIFICAR SERVICIO. .......................................... 16 FIGURA 26. CONFIGURACIÓN DEL SITIO....................................................................... 16 FIGURA 27. NUEVA SUCURSAL ........................................................................................ 17 FIGURA 28. MENSAJE DE ÉXITO NUEVA SUCURSAL ................................................. 17 FIGURA 29. TABLA DE SUCURSALES. ............................................................................ 18

FIGURA 30. MODIFICAR SUCURSAL. ............................................................................. 18 FIGURA 31. MENSAJE DE Ã&#x2030;XITO MODIFICAR SUCURSAL ......................................... 18

1. INTRODUCCIÓN El presente manual tiene el objetivo facilitar la interacción del usuario con el Sistema para la generación de turnos de los servicios del Cuerpo de Bomberos del GAD Municipal del cantón de Santo Domingo de los Colorados, además indica cada una de las funciones que realizan los diferentes módulos del sistema. El manual de usuario fue elaborado utilizando términos e interfaces considerando que todos los usuarios que harán uso del sistema tienen las habilidades y conocimientos básicos de computación. El Sistema para la generación de turnos de los servicios del Cuerpo de Bomberos del GAD Municipal del cantón de Santo Domingo de los Colorados es una aplicación que permitirá mejorar el servicio de atención a la ciudadanía que requiere de los servicios de prevención, capacitación, trámites de permisos de funcionamiento, entre otros.

2. FUNCIONES DEL SISTEMA 2.1. Aspectos generales 1. Navegador Web: Permite el ingreso al sistema de Generación de Turnos, se recomienda el uso de navegadores web actualizados a su última versión disponible. 2. Campos obligatorios: Los campos del Sistema de Generación de turnos son de carácter obligatorio para el correcto funcionamiento, caso contrario desplegará un mensaje indicando que la información está incompleta. 3. Notificación de alerta: Se desplegará una notificación en la pantalla indicando el resultado de la operación: o Proceso exitoso: El sistema desplegará una notificación de color verde en el centro de la ventana del navegador, indicando un mensaje de éxito.

Figura 24. Mensaje de éxito Fuente: Los Autores.

o Proceso sin éxito: El sistema desplegará una notificación con el mensaje de error en la pantalla.

Figura 25. Mensaje sin Éxito Fuente: Los Autores.

2.2. Botones del sistema

Nuevo: Despliega el formulario donde se va a ingresar la información para un nuevo registro.

Cerrar: Cancela proceso que se vaya a ejecutar.

Guardar: Guarda la información ingresada correctamente en los formularios del sistema.

Editar: Permite realizar la modificación de la información existente en el sistema.

Deshabilitar: Deshabilita a los usuarios ingresados en el sistema.

Permite asignar privilegios a los usuarios del sistema.

Permite buscar en los formularios del sistema.

Refresca toda la información ingresada en los formularios del sistema.

Imprimir: Permite generar un reporte de la información desplegada en la página.

2.3. Inicio de sesión Al ingresar al sistema primero se muestra la pantalla en donde se solicitan las credenciales de acceso al usuario para iniciar sesión.

Figura 26. Interfaz de inicio de sesión. Fuente: Los Autores

2.3.1. Proceso para iniciar sesión en el sistema A continuación se detalla los pasos a seguir para iniciar sesión en el sistema: 1. Ingresar correctamente el email, Usuario ID o Doc. Identidad registrado en el sistema. 2. Ingresar correctamente la contraseña. 3. Clic en el botón “Sign In”, se realiza la validación del usuario y contraseña ingresados sean correctos, caso contrario despliegan un mensaje error.

Figura 27. Mensaje de Credenciales Correctas. Fuente: Los autores.

2.3.2. Problemas al iniciar sesión 1. Usuario incorrecto: La identificación del usuario por defecto es su número de cédula, en este caso deberá ingresar nuevamente su identificación de manera correcta para poder autenticarse. 2. Contraseña incorrecta: Si el usuario no recuerda la contraseña que cambió en la configuración de su perfil, este deberá pedir al usuario administrador reestablecer su contraseña, la misma que por defecto será su número de cédula.

2.4. Página Principal Una vez ingresadas correctamente las credenciales de acceso para iniciar sesión, se despliega la interfaz principal del sistema compuesta por un diseño amigable para la fácil interacción del usuario con el sistema.

Figura 28. Página Principal Fuente: Los autores

2.4.1. Menú de Interfaz En cada interfaz existe un menú que mostrara cada una de las actividades que los usuarios podrán realizar, estas actividades serán activadas de acuerdo al rol del usuario, las opciones son: A. Inicio: Permite regresar al usuario a la pantalla principal. B. Atención: Despliega la pantalla para el servicio de atención a los clientes. C. Clientes: Despliega el formulario de los clientes registrados en el sistema. D. Administración: Despliega las opciones asignadas para la administración del sistema como: Grupos, Usuarios, Sistema, Departamentos y Sucursales. E. Información: Muestra toda la información referente a los turnos asignados a los clientes.

A B C D E

Figura 29. Menú de las interfaces. Fuente: Los autores.

2.5. Perfil Administrador Las tareas del Administrador están relacionadas con la administración de usuarios, perfiles y administración del Sistema. A continuación, se indicará las tareas que el administrador puede realizar.

Figura 30. Menú de Administración. Fuente: Los autores.

2.5.1. Usuarios Permite el ingreso de nuevos usuarios al sistema, además permite la modificación o deshabilitación de los usuarios existentes en el sistema. Además, incorpora la función de asignar roles.

Figura 31. Usuarios: Modulo de usuarios Fuente: Los autores

2.5.1.1. Registro de un nuevo usuario En el formulario para el registro de un nuevo usuario en el sistema se muestran los campos más importantes para obtener la información del nuevo usuario: 

Apellidos: Ingresar los apellidos del nuevo usuario.



Nombre: Ingresar los nombres del nuevo usuario.



Documento de Identificación: Ingresar el núm1ero de identificación del nuevo usuario.



Correo electrónico: Ingresar el correo del nuevo Usuario.



Teléfono de contacto: Ingresar el número de contacto del nuevo usuario.



Dirección: Ingresar la dirección del domicilio del nuevo usuario.



Sexo: Ingresar el sexo del usuario.



Perfil: Asignar el perfil del nuevo usuario en el sistema.

1. Para el ingreso del nuevo usuario damos clic en el botón “Nuevo Usuario” ubicado en la parte superior derecha de la pantalla y se mostrará el formulario para el ingreso de la información.

Figura 32. Formulario Ingreso nuevo usuario Fuente: Los Autores

Cuando todos los campos están ingresados correctamente, presionar el botón

guardar y se registrará con éxito. Caso contrario se mostrará un mensaje de error.

Figura 33. Registro de usuario exitoso Fuente: Los Autores.

Figura 34. Registro de Usuario sin éxito Fuente: Los Autores.

2.5.1.2. Modificación de Usuario Para modificar la información de un usuario del sistema se deben seguir los siguientes pasos: 1. Dar clic en el botón “Modificar Usuario” en la ventana de usuarios. 2. Modificar la información necesaria y dar clic en el botón guardar, una vez realizado esto se desplegará el mensaje de éxito.

Figura 35. Mensaje de éxito. Fuente: Los Autores.

2.5.1.3. Activar/Desactivar Para desactivar un usuario se consulta al usuario y se da clic en el botón “Deshabilitar usuario” y luego se mostrará un mensaje de confirmación.

Figura 36. Deshabilitar Usuario Fuente: Los Autores.

2.5.2. Asignación de Permisos El sistema permite asignar permisos a los usuarios sin importar el perfil que estos tengan dentro del sistema. Para asignar los permisos se deben seguir los siguientes pasos. 1. Consultar el usuario al que se desea asignar permisos en la tabla de usuarios. Dar clic en el botón “Asignar Permisos” y se mostrará la ventana de asignación.

Figura 37. Administración de permisos. Fuente: Los Autores

2. Seleccionar los permisos que se desean asignar e inmediatamente se mostrará un mensaje de éxito.

Figura 38. Mensaje de éxito asignación de permisos Fuente: Los Autores.

2.5.3. Departamentos Constarán todos los departamentos a los que los clientes acudirán a recibir su servicio, estos departamentos recibirán su turno por parte del sistema. 2.5.3.1. Crear Nuevo Departamento Para crear un nuevo departamento se deberán seguir los siguientes pasos: 1. Presionar en el botón “Nuevo Departamento” y se mostrará el formulario de ingreso.

Figura 39. Ingreso nuevo departamento. Fuente: Los Autores.

2. Una vez ingresada la información, presionar en el botón guardar y se mostrará un mensaje de éxito.

Figura 40. Mensaje de éxito departamento nuevo. Fuente: Los Autores.

2.5.3.2. Modificar Departamento Para modificar el departamento se deberá realizar los siguientes pasos: 1. Consultar el departamento a modificar en la tabla de departamentos.

Figura 41. Tabla de Departamentos. Fuente: Los Autores.

2. Una vez seleccionado el departamento dar clic en el botón modificar y se desplegará el formulario de registro.

Figura 42. Modificar Departamento. Fuente: Los Autores.

3. Una vez modificada la información dar clic en el botón guardar y se mostrará un mensaje de éxito.

Figura 43. Mensaje de éxito modificación de departamento. Fuente: Los Autores.

2.5.4. Servicios Se determinan los servicios para los departamentos ingresados en el sistema, a partir de esta información el sistema generará los turnos. 2.5.4.1. Nuevo Servicio Para crear un nuevo departamento se deberán seguir los siguientes pasos: 1. Presionar en el botón “Nuevo Departamento” y se mostrará el formulario de ingreso.

Figura 44. Ingresar nuevo Servicio. Fuente: Los Autores.

2. Una vez ingresada la información, presionar en el botón guardar y se mostrará un mensaje de éxito.

Figura 45. Mensaje de éxito nuevo servicio. Fuente: Los Autores.

2.5.4.2. Modificar Servicio Para modificar el servicio se deberá realizar los siguientes pasos: 1. Consultar el servicio a modificar en la tabla de departamentos.

Figura 46. Tabla de Servicios Fuente: Los Autores.

2. Una vez seleccionado el servicio dar clic en el botón modificar y se desplegará el formulario de registro.

Figura 47. Modificar Servicio Fuente: Los Autores.

3. Una vez modificada la información dar clic en “Guardar” y se mostrará un mensaje de éxito.

Figura 48. Mensaje de éxito modificar servicio. Fuente: Los Autores.

2.5.5. Configurar Sitio Permite modificar la información que contendrá el sistema y se visualizará en algunos reportes del sistema.

Figura 49. Configuración del Sitio Fuente: Los Autores

2.5.6. Sucursales y Jefaturas Permite ingresar la información al sistema de las Sucursales y Jefaturas que tiene el Cuerpo de Bomberos del GAD Municipal del cantón de Santo Domingo de los Colorados. 2.5.6.1. Nueva Sucursal Para crear una nueva sucursal se deberán seguir los siguientes pasos: 1. Presionar en el botón “Nueva Sucursal” y se mostrará el formulario de ingreso.

Figura 50. Nueva Sucursal Fuente: Los Autores.

2. Una vez ingresada la información, presionar en el botón guardar y se mostrará un mensaje de éxito.

Figura 51. Mensaje de éxito nueva sucursal Fuente: Nueva Sucursal.

2.5.6.2. Modificar Sucursal Para modificar la sucursal se deberá realizar los siguientes pasos: 1. Consultar la sucursal a modificar en la tabla de departamentos.

Figura 52. Tabla de Sucursales. Fuente: Los Autores.

2. Una vez seleccionado la sucursal dar clic en el botón modificar y se desplegará el formulario de registro.

Figura 53. Modificar Sucursal. Fuente: Los Autores.

3. Una vez ingresada la información a modificar dar clic en el botón “Guardar” y se mostrará un mensaje de éxito.

Figura 54. Mensaje de éxito modificar sucursal Fuente: Los Autores.

2.5.7. Cerrar Sesión Cualquier usuario que desee cerrar sesión deberá seguir los siguientes pasos: 1. Dar clic en la parte del usuario en el menú principal.

2. Luego se desplegará una ventana donde se mostrará la opción “Salir”

3. Dar clic en el botón “Salir” y se mostrará un mensaje de confirmación

ANEXO 6. PRUEBAS DEL SISTEMA

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica - Escuela de Sistemas

PRUEBAS DEL SISTEMA DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA PARA LA GENERACIÓN DE TURNOS DE LOS SERVICIOS DEL CUERPO DE BOMBEROS DEL GAD MUNICIPAL DEL CANTÓN DE SANTO DOMINGO DE LOS COLORADOS AÑO 2015

Trabajo de titulación previa a la obtención del título de Ingeniero de Sistemas y Computación

Autores:

MANZANILLA ÁLVAREZ CRISTÓBAL FERNANDO OLIVO VEGA JULIO CÉSAR

Director:

MG. RICHARD ESTALIN MAFLA TOBAR

Santo Domingo – Ecuador Julio, 2016

APROBACIÓN DEL DOCUMENTO DE PRUEBAS DEL SISTEMA

Santo Domingo, 22 de julio de 2016

El documento de pruebas de funcionamiento del sistema Turnos+ (Sistema Gestor de Turnos), para el proyecto “DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA PARA LA GENERACIÓN DE TURNOS DE LOS SERVICIOS DEL CUERPO DE BOMBEROS DEL GAD MUNICIPAL DEL CANTÓN DE SANTO DOMINGO DE LOS COLORADOS AÑO 2015”, ha sido elaborado en base a las pruebas realizadas en colaboración con el personal encargado del área de sistemas y servidores públicos involucrados en el servicio de atención al cliente. En el documento consta la verificación y aprobación del correcto funcionamiento del sistema Turnos+ de acuerdo a los objetivos y requerimiento establecidos en el documento de Especificación de Requerimientos del Sistema (SRS). El documento es validado por el Director del área de sistemas.

Ing. Edwin Villamarin DIRECTOR DEL ÁREA DE SISTEMAS DEL CUERPO DE BOMBEROS DEL GAD MUNICIPAL DE SANTO DOMINGO

Julio César Olivo Vega DISERTANTE

Cristóbal Fernando Manzanilla Álvarez DISERTANTE

DOCUMENTO DE PRUEBAS DEL SISTEMA El presente documento de pruebas tiene como propósito verificar que el sistema Turnos+ cumple satisfactoriamente con los requerimientos definidos por la Dirección de Sistemas en el documento de Especificación de Requerimientos del Sistema (SRS).

Señale con un visto (✓) o una equis (x) de acuerdo a los resultados obtenidos:

N°

PRUEBA

Ingresar al sistema

Cerrar sesión

Recuperar contraseña de usuario

Administrar información del sistema

Administrar información general

Administrar permisos de acceso

Acceder con el perfil correspondiente

Navegación fluida por los módulos

Gestión de turnos en tiempo real

Generar informes

Visualizar manuales de usuario

VERIFICADO

OBSERVACIÓN

Verificado y validado por:

Ing. Edwin Villamarin DIRECTOR DEL ÁREA DE SISTEMAS DEL CUERPO DE BOMBEROS DEL GAD MUNICIPAL DE SANTO DOMINGO

ANEXO 7. CAPACITACIÃ&#x201C;N DEL SISTEMA

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica - Escuela de Sistemas

CAPACITACIÓN DEL PERSONAL EN LA ADMINISTRACIÓN DEL SISTEMA DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA PARA LA GENERACIÓN DE TURNOS DE LOS SERVICIOS DEL CUERPO DE BOMBEROS DEL GAD MUNICIPAL DEL CANTÓN DE SANTO DOMINGO DE LOS COLORADOS AÑO 2015

Trabajo de titulación previa a la obtención del título de Ingeniero de Sistemas y Computación

Autores:

MANZANILLA ÁLVAREZ CRISTÓBAL FERNANDO OLIVO VEGA JULIO CÉSAR

Director:

MG. RICHARD ESTALIN MAFLA TOBAR

Santo Domingo – Ecuador Julio, 2016

CAPACITACIÓN DEL PERSONAL EN LA ADMINISTRACIÓN DEL SISTEMA

Santo Domingo, 22 de julio de 2016

Se realizó una explicación sobre el manejo y administración de cada uno de los módulos que conforman el sistema Turnos+ (Sistema Gestor de Turnos) al personal a cargo del sistema, es decir, se capacitó a la Dirección de Sistemas y al personal técnico especializado en servicio al cliente del Cuerpo de Bomberos del Gobierno Autónomo Descentralizado de Santo Domingo. A continuación, se presenta el listado del personal capacitado:

Apellidos y Nombres

Cédula de identidad

Firma

Ing. Edwin Villamarin DIRECTOR DEL ÁREA DE SISTEMAS DEL CUERPO DE BOMBEROS DEL GAD MUNICIPAL DE SANTO DOMINGO

ANEXO 8. CARTA DE IMPACTO

CARTA DE IMPACTO

ANEXO 9. ACTA ENTREGA-RECEPCIÃ&#x201C;N

ACTA DE ENTREGA – RECEPCIÓN

Santo Domingo, 22 de julio de 2016

En la ciudad de Santo Domingo, a los 22 días del mes de julio del 2016, se reúnen por una parte el Ing. Edwin Villamarin, Director del Área de Sistemas del Cuerpo de Bomberos del Gobierno Autónomo Descentralizado Municipal de Santo Domingo, y los Srs. Julio César Olivo Vega y Cristóbal Fernando Manzanilla Álvarez en calidad de estudiantes de la Pontificia Universidad Católica del Ecuador Sede Santo Domingo quienes convienen en suscribir la presente Acta Entrega – Recepción del sistema Turnos+ (Sistema Gestor de Turnos), realizado en base a las necesidades establecidas por el Cuerpo de Bomberos del GAD Municipal de Santo Domingo, en lo referente al software (SRS), implementado el día viernes, 22 de julio de 2016 en horarios de trabajo de 08H00 a 17H00.

El sistema consta con la aprobación por parte de los encargados del área de sistemas y personal especializado en servicio y atención al cliente, quienes han hecho uso de la misma y aprobaron su interfaz (presentación), funcionamiento y recepción de manuales de instalación y usuario.

Recepción

Ing. Edwin Villamarin Director del Área de Sistemas del Cuerpo de Bomberos del GAD Municipal Santo Domingo

Disertantes

Julio César Olivo Vega CC. 210020014-2

Cristóbal Fernando Manzanilla Álvarez CC. 171888572-4