Desarrollo Web para la gestión interna de vehículos en el GAD Provincial de Santo Domingo

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas

DESARROLLO WEB PARA LA GESTIÓN INTERNA DE VEHÍCULOS EN EL GAD PROVINCIAL DE SANTO DOMINGO DE LOS TSÁCHILAS Trabajo de titulación previo a la obtención del título de Ingenieros de Sistemas y Computación Línea de Investigación: Estudio, Diseño e Implementación de Software Autores: FRANCISCO ALBERTO ARROYO LARRIVA XAVIER ALAN SOTO ESPINOSA

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 WEB PARA LA GESTIÓN INTERNA DE VEHÍCULOS EN EL GAD PROVINCIAL DE SANTO DOMINGO DE LOS TSÁCHILAS Línea de Investigación: Estudio, Diseño e Implementación de Software Autores: FRANCISCO ALBERTO ARROYO LARRIVA XAVIER ALAN SOTO ESPINOSA

Richard Estalin Mafla Tobar, Mg.

f.

DIRECTOR DEL TRABAJO DE TITULACIÓN Rodolfo Sirilo Córdova Gálvez, Mg.

f.

CALIFICADOR Luis Javier Ulloa Meneses, Mg

f.

CALIFICADOR Margoth Elisa Guaraca Moyota, Mg.

f.

DIRECTOR DE LA ESCUELA DE SISTEMAS

Santo Domingo – Ecuador Agosto, 2016

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD Por parte de, Xavier Alan Soto Espinosa portador de la cédula de ciudadanía No. 2300210636, y de Francisco Alberto Arroyo Larriva portador de la cédula de ciudadanía No. 1724658461, declaramos que los resultados obtenidos en la investigación que presentamos como informe final, previo la obtención del Grado de Ingenieros de Sistemas y Computación, son absolutamente originales, auténticos y personales.

En tal virtud, declaramos 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 nuestra exclusiva responsabilidad legal y académica.

Xavier Alan Soto Espinosa CI. 230021063-6

Francisco Alberto Arroyo Larriva CI. 172465846-1

iv

AGRADECIMIENTO Agradecemos en primera instancia a Dios por brindarnos su fuerza en el día a día para creer en lo que parecía imposible finalizar. Además de protegernos constantemente de los males que habitan en el mundo.

A la Pontificia Universidad Católica Sede Santo Domingo por ser nuestro segundo hogar al habernos aceptados como sus estudiantes y formarnos como profesionales competentes para desenvolvernos en cualquier situación que nos encontremos.

A nuestros docentes quienes nos brindaron de sus conocimientos impartidos, así también de su amistad y confianza desde los inicios de nuestra formación en la universidad.

Y para finalizar damos las gracias a nuestros padres, familiares y seres queridos que nos han proporcionado con su amor, apoyo y comprensión que sirvieron como motivación para seguir adelante y triunfar en las dificultades que se han presentado.

v

DEDICATORIA El siguiente trabajo de tesis se encuentra dirigido, en primera instancia a nuestros padres, quienes han sido la guía y camino para llegar a esta etapa de nuestra carrera además, de que nos inculcaron desde temprana edad valores éticos y principios morales, los cuales permiten que avancemos día a día en nuestras vidas, a pesar de nuestras adversidades. No obstante su apoyo ha sido incondicional en esta travesía profesional, las palabras de aliento indispensables en todo momento.

Por todo esto les dedicamos con todo el amor, cariño, esfuerzo, respeto y ganas para seguir siempre adelante

vi

RESUMEN El presente proyecto de titulación establece la metodología aplicada a la creación e implementación de un sitio web para la gestión interna del GAD Provincial; institución del estado que brinda sus servicio a la ciudad de Santo Domingo. Se ha desarrollado el proyecto con el fin de automatizar los procesos del departamento de Gestión Vehicular que conlleva a solucionar conflictos de integridad, duplicidad y seguridad de la información, que posee en la actualidad esta institución. El software permite el control automático del ingreso y salida de los vehículos y conductores mediante la recolección de información de un dispositivo biométrico. Se automatizo la generación de los documentos habilitantes para la salida de los vehículos y la realización de distintos informes para el proceso de auditoría. Se aplicó la metodología cascada en conjunto con las buenas prácticas de programación en el desarrollo del software. En la etapa de análisis del sistema se hizo mediante la investigación de campo enfocada al departamento de Gestión Vehicular siendo la encuesta el instrumento de recolección de datos. Continuando la etapa de análisis de requisitos se realizó una entrevista al Ing. Pablo Guillen que ocupa el cargo de director del departamento de TI y al Ing. Víctor Carrera que desempaña el cargo de Director del Departamento de Gestión Vehicular en la cual se abstrajo los principales requisitos del sistema. Como principal resultado del proyecto fue la automatización de los procesos y la generación electrónica de los documentos, permitiendo un control óptimo.

vii

ABSTRACT This current documentation establishes the methodology applied for the creation and implements of a website for internal management of the Provincial GAD; state institution that provides its service to the city of Santo Domingo. The project has been developed in order to automate processes Vehicle Management Department involved to resolve conflicts of integrity, duplicity and information security that currently owns this institution. The software enables automatic control of the entry and exit of vehicles and drivers by collecting information from a biometric device. Enabling the generation of output documents for vehicles and conducting various reports to the audit process was automated. Waterfall methodology was applied together with good programming practices in software development. At the stage of system analysis it was done through field research focused Vehicle Management Department being the survey data collection instrument. Following with the stage of the analysis of requirements, an interview was carried out with the engineer Pablo Guillen, who holds the position of director of IT and engineer Victor Carrera, who plays the role of Director of Traffic Management in which the main system requirements are abstracted. The main result of the project was the automation of processes and the generation of electronic documents, allowing optimal control.

viii

ÍNDICE DE CONTENIDOS

HOJA DE APROBACIÓN ........................................................................................................ii DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD ...................................... iii AGRADECIMIENTO .............................................................................................................. iv DEDICATORIA ........................................................................................................................ v RESUMEN ............................................................................................................................... vi ABSTRACT .............................................................................................................................vii ÍNDICE DE CONTENIDOS ................................................................................................. viii ÍNDICE DE FIGURAS............................................................................................................ xv ÍNDICE DE TABLAS ............................................................................................................ xvi ÍNDICE DE ANEXOS ..........................................................................................................xvii 1.

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

2. PLANTEAMIENTO DEL PROBLEMA .............................................................................. 2 2.1. Antecedentes ....................................................................................................................... 2 2.2. Problema de investigación .................................................................................................. 3 2.2.1. Preguntas Básicas ........................................................................................................................ 3

2.3. Justificación de la investigación ......................................................................................... 4 2.4. Objetivos de la investigación .............................................................................................. 5 2.4.1.

Objetivo General ..................................................................................................................... 5

2.4.2.

Objetivos Específicos ............................................................................................................. 5

ix 3.

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

3.1.

Revisión de la literatura o fundamentos teóricos ......................................................... 6

3.1.1.

Concepto de Software ............................................................................................................ 6

3.1.1.1.

Clasificación del software ....................................................................................................... 6

3.1.1.1.1. Software de Sistemas ............................................................................................................. 6 3.1.1.1.2. Software de aplicación ............................................................................................................ 6 3.1.1.1.3. Software baso en inteligencia artificial.................................................................................... 6 3.1.1.1.4. Software de aplicación web .................................................................................................... 7 3.1.1.1.5. Software Libre ......................................................................................................................... 7 3.1.2.

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

3.1.3.

Modelos de desarrollo de software ......................................................................................... 8

3.1.4.

Modelo General de Procesos ................................................................................................. 8

3.1.5.

Modelo lineal secuencial ......................................................................................................... 8

3.1.5.1.

Ingeniería y modelado de sistemas/ Información ................................................................... 8

3.1.5.2.

Análisis de los requerimientos ................................................................................................ 9

3.1.5.2.1. Diseño ..................................................................................................................................... 9 3.1.5.2.2. Código ..................................................................................................................................... 9 3.1.5.2.3. Prueba .................................................................................................................................... 9 3.1.5.2.4. Mantenimiento ........................................................................................................................ 9 3.1.6.

Modelo de construcción de Prototipos..................................................................................10

3.1.7.

SGBD (Sistema gestor de Base de Datos) ..........................................................................11

3.1.8.

Lenguajes de programación .................................................................................................12

3.1.9.

PHP .......................................................................................................................................12

3.1.10.

AJAX .....................................................................................................................................12

x 3.1.11.

JAVASCRIPT ........................................................................................................................13

3.1.12.

Protocolo HTTP ....................................................................................................................13

3.1.13.

JQuery ..................................................................................................................................13

3.1.14.

CSS .......................................................................................................................................13

3.1.15.

Apache ..................................................................................................................................14

3.1.16.

HTML ....................................................................................................................................14

3.1.17.

MySQL ..................................................................................................................................14

3.1.18.

¿Qué es una base de datos? ...............................................................................................14

3.1.18.1. Diseño o modelado de una base de datos ...........................................................................14 3.1.18.2. Modelo relacional ..................................................................................................................15 3.1.18.3. Modelo jerárquico .................................................................................................................15 3.1.18.4. Modelo de red .......................................................................................................................15 3.1.19.

¿Qué es un servidor? ...........................................................................................................15

3.1.20.

Servidor FTP .........................................................................................................................15

3.1.21.

Modelo cliente-servidor .........................................................................................................15

3.1.22.

Metodología de Desarrollo de software ................................................................................16

3.1.23.

Metodología cascada ............................................................................................................16

3.1.24.

Modelo evolutivo ...................................................................................................................18

3.1.25.

¿Qué es una red informática? ..............................................................................................18

3.1.26.

Métodos ágiles ......................................................................................................................19

3.1.27.

Principios de los métodos ágiles ..........................................................................................19

3.1.28.

Metodología de Scrum ..........................................................................................................20

3.1.29.

El proceso de Scrum ............................................................................................................20

3.1.30.

Estándar ACID para base de datos ......................................................................................21

xi 3.1.31.

DSL .......................................................................................................................................21

3.1.32.

DML ......................................................................................................................................21

3.1.33.

DLC .......................................................................................................................................21

3.1.34.

Postgresql .............................................................................................................................22

3.1.35.

Pgadmin3xzsxz .....................................................................................................................22

3.1.36.

Modelo vista controlador .......................................................................................................22

3.1.37.

Concepto de gestión vehicular .............................................................................................22

4.

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

4.1.

Enfoque/Tipo de investigación .................................................................................. 24

4.2.

Población ................................................................................................................... 24

4.3.

Muestra ...................................................................................................................... 24

4.4.

Instrumentos para recogida de datos .......................................................................... 25

4.5.

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

4.6.

Comparación de metodologías .................................................................................. 26

4.7.

Comparación Bases de datos ..................................................................................... 26

5.

RESULTADOS ......................................................................................................... 27

5.1.

Discusión y Análisis de los resultados....................................................................... 27

5.1.1.

Encuesta ..................................................................................................................... 27

5.1.2.

Entrevista ..............................................................................................................................27

5.1.3.

Especificación de requerimientos de sistemas. (SRS) .........................................................27

5.1.4.

Diagrama de Gantt................................................................................................................28

5.1.5.

Especificación de Diseño de Software (SDS) ......................................................................28

xii 5.1.6.

Fase de Codificación. ...........................................................................................................29

5.1.7.

Fase de pruebas. ..................................................................................................................29

5.1.8.

Manual de Usuario. ...............................................................................................................29

5.2.

Conclusiones .............................................................................................................. 30

5.3.

Límites y Recomendaciones ...................................................................................... 30

REFERENCIAS BIBLIOGRÁFICAS..................................................................................... 31 Bibliográficas ........................................................................................................................... 31 GLOSARIO ............................................................................................................................. 34 Diagrama físico de la base de datos .......................................................................................... 1 Diagrama lógico de la base de datos .......................................................................................... 2 Prototipos de interfaces .............................................................................................................. 3 Prototipo de interfaz para el menú administrador- usuarios ...................................................... 3 Prototipo de la interfaz administración-sistema......................................................................... 4 Prototipo de interfaz control-vehículos ...................................................................................... 5 Prototipo para la generación de informes .................................................................................. 7 Prototipo para el despacho de combustible ................................................................................ 7 Diagramas de secuencia ............................................................................................................. 9 Diagrama de secuencia para la inserción de una custodia ......................................................... 9 Diagrama de secuencia para la inserción de una orden ........................................................... 10 Diagrama de secuencia para el ingreso de un registro diario ................................................... 11 Historial de Versiones ................................................................................................................ 3 Información del Proyecto ........................................................................................................... 3

xiii Aprobaciones ............................................................................................................................. 3 Resumen Ejecutivo .................................................................................................................... 4 Alcance de las Pruebas............................................................................................................... 4 Elementos de Pruebas ................................................................................................................ 4 Nuevas Funcionalidades a Probar .............................................................................................. 4 Pruebas de Regresión ................................................................................................................. 4 Funcionalidades a No Probar ..................................................................................................... 4 Enfoque de Pruebas (Estrategia) ................................................................................................ 4 Criterios de Aceptación o Rechazo ............................................................................................ 5 Criterios de Aceptación o Rechazo ............................................................................................ 5 Pruebas ....................................................................................................................................... 5 Generación de Custodias............................................................................................................ 5 Generación de Orden de Salida.................................................................................................. 6 Registro de Movilización ......................................................................................................... 13 Recursos ................................................................................................................................... 20 Requerimientos de Entornos – Hardware ................................................................................ 20 Requerimientos de Entornos – Software.................................................................................. 20 Herramientas de Pruebas Requeridas....................................................................................... 20 Personal 20 Entrenamiento .......................................................................................................................... 21 Referencias ............................................................................................................................... 21

xiv Administración .......................................................................................................................................11 Sistema 12 Administración de Usuarios ..................................................................................................................14 Administración WebMail........................................................................................................................16 Papelera 17 Fuentes 18 Control

21

Servidores .............................................................................................................................................21 Servidores públicos ...............................................................................................................................24 Administración de vehículos .................................................................................................................25 Custodia 28 Orden de Salida ....................................................................................................................................31 Registro de Movilización Diario .............................................................................................................33 Estación 37 Estación de Combustible ......................................................................................................................37

xv

ร NDICE DE FIGURAS Figura 1 Modelo de construcciรณn de prototipos ...................................................................... 10 Figura 2 Sistemas Gestor de Bases de Datos ........................................................................... 11 Figura 3 Fundamentos de PHP ............................................................................................... 12 Figura 4 Modelo Evolutivo ...................................................................................................... 18 Figura 5 Modelo evolutivo....................................................................................................... 18 Figura 6 Modelo Scrum ........................................................................................................... 20 Figura 7 Encuesta Pregunta 1 .................................................................................................. 38 Figura 8 Encuesta Pregunta 2 .................................................................................................. 39 Figura 9 Encuesta Pregunta 3 .................................................................................................. 40 Figura 10 Encuesta Pregunta 4 ................................................................................................ 41 Figura 11 Encuestas Pregunta 5 ............................................................................................... 42 Figura 12 Encuesta Pregunta 6 ................................................................................................ 43 Figura 13 Encuesta Pregunta 7 ................................................................................................ 44 Figura 14 Encuesta Pregunta 8 ................................................................................................ 45 Figura 15 Encuesta Pregunta 9 ................................................................................................ 46 Figura 16 Encuesta Pregunta 10 .............................................................................................. 47

xvi

ÍNDICE DE TABLAS Tabla 1. Comparación de Metodologías .................................................................................. 26 Tabla 2. Comparación Bases de Datos .................................................................................... 26 Tabla 3. Pregunta 1 ................................................................................................................. 38 Tabla 4. Pregunta 2 ................................................................................................................. 39 Tabla 5. Pregunta 3 ................................................................................................................. 40 Tabla 6. Pregunta 4 ................................................................................................................. 41 Tabla 7. Pregunta 5 ................................................................................................................. 42 Tabla 8. Pregunta 6 ................................................................................................................. 43 Tabla 9. Pregunta 7 ................................................................................................................. 44 Tabla 10. Pregunta 8 ............................................................................................................... 45 Tabla 11. Pregunta 9 ............................................................................................................... 46 Tabla 12. Pregunta 10 ............................................................................................................. 47

xvii

ÍNDICE DE ANEXOS ANEXO 1. ENCUESTA .......................................................................................................... 37 ANEXO 2. Entrevista del Software ......................................................................................... 48 ANEXO 3. Fase de Requerimientos-SRS................................................................................ 54 ANEXO 4. Fase de Planificación ............................................................................................ 74 ANEXO 5. Fase de Diseño ...................................................................................................... 77 ANEXO 6: Fase de Codificación ............................................................................................. 78 ANEXO 7. Fase de prueba....................................................................................................... 80 ANEXO 8. Manual de usuario ................................................................................................. 81

1. INTRODUCCIÓN A medida que la tecnología avanza mejoran los procesos que se llevan de forma manual; los sistemas informáticos traen consigo grandes ventajas como: la automatización, incrementos en los recursos y costos en una empresa. Estos beneficios radican en que puede tener un mayor control de la información de forma inmediata y saber en qué forma se ejecutan los procesos y la utilización de los recursos.

La utilización de una aplicación web como una herramienta, que nos brinda información para mejorar el beneficio en una empresa, proporcionando un rendimiento y solvencia de la misma con procesos que sean rápidos, prácticos y eficaces. La aplicación web tiene diversas formas de adaptarse como por ejemplo en: plataformas y sistemas informáticos. A continuación, se presentará un proyecto creado con bases esenciales de la informática que tiene la finalidad de dar un soporte para la gestión y control interno de los vehículos en el GAD Provincial de Santo Domingo de los Tsáchilas, junto con un lector biométrico necesario para el reconocimiento físico y dactilar de los conductores.

Los lectores biométricos permiten el reconocimiento único de una persona basado en rasgos físicos, tomando en cuenta que los más usados son con reconocimiento de huella dactilar, facial, geometría de la mano, reconocimiento del iris o retina del ojo, etc.

El sistema de control vehicular mediante una aplicación web requiere tener en cuenta la información que se va ingresar y saber que cada uno de estos datos genera otros módulos de trabajo; la prioridad de uso del sistema para el GAD Provincial de Santo Domingo de los Tsáchilas es agilizar y llevar un mejor control de la ruta de los conductores y vehículos, con su respectiva documentación.

2

2. PLANTEAMIENTO DEL PROBLEMA La carencia de un sistema integrado para la gestión de procesos de entrada y salida de vehículos en el GAD Provincial de Santo Domingo de los Tsáchilas, el cual no ha sido automatizado, manteniendo un control de sus procesos de forma manual y de una forma no tan óptima en cuanto a agilidad y mejora de dichas actividades.

2.1. Antecedentes En el transcurso de los años, la innovación en el ámbito tecnológico crece a pasos agigantados, en efecto, la necesidad de estar siempre a la vanguardia en este ámbito, que aporta sistemas ideales para realizar procesos de forma más ágil, ya sean empresas estatales o gubernamentales. Es de vital importancia brindar transparencia y rapidez a los procesos, los cuales permiten la utilización de sistemas informáticos, a su vez son una herramienta primordial dentro de cualquier área de la empresa.

Por otro lado, Santo Domingo de los Tsáchilas con más de cuarenta años de pertenecer como cantón a la provincia de Pichincha alcanza su provincialización el 6 de noviembre de 2007.

Puesto que, es una de las provincias más jóvenes del Ecuador, el GAD Provincial de Santo Domingo de los Tsáchilas no logra la automatización de todos sus procesos internos.

El departamento de Tecnología de la Información y de la Comunicación del GAD Provincial de Santo Domingo de los Tsáchilas posee un servicio web interno, en el cual tienen automatizados varios procesos administrativos, financieros, de seguridad, entre otros.

El Departamento de Gestión Vehicular del GAD Provincial de Santo Domingo de los Tsáchilas se conforma por: Sr. Víctor Carrera como Director, Sr. Pablo Muñoz como Subdirector y Sr. Rody Verduga como secretario.

3 Este departamento utiliza los siguientes procesos: Gestión de custodias, Gestión de órdenes de salida, Gestión de registros diarios y Gestión de combustible en forma de ficheros físicos.

2.2. Problema de investigación El departamento de Gestión vehicular del GAD provincial de santo domingo de los Tsáchilas registra sus procesos y guarda información en documentos físicos conocidos como ficheros, el uso de sistemas de almacenamiento de ficheros permite que personal no autorizado sea capaz de manipularlos sin ningún control, afectando así a la integridad de la información; pueden existir más de un fichero con la misma información este inconveniente es conocido como duplicidad de la información, otra dificultad que genera este sistema es que los ficheros se pueden dañar o perder con el paso del tiempo. Todos estos aspectos negativos provocan que los tiempos de búsqueda sean excesivamente altos y la calidad de la información recogida escasa.

2.2.1. Preguntas Básicas ¿De qué modo facilitará la aplicación informática, la gestión y el control de la información en el departamento de Gestión Vehicular perteneciente al GAD Provincial de Santo Domingo de los Tsáchilas? ¿Cuál será el mecanismo a utilizar para realizar un seguimiento de control de información en la gestión vehicular? ¿Qué parámetros se tomarán en cuenta para el diseño, arquitectura y modelado de las bases de datos, interfaces y demás módulos del sistema web para la Gestión Vehicular y cumplir con los requisitos del GAD Provincial?

4

2.3. Justificación de la investigación Mediante este proyecto se fomenta la vinculación con la sociedad gracias al convenio interinstitucional que mantiene el GAD Provincial de Santo Domingo de los Tsáchilas con la PUCESD, siendo fieles a los valores éticos y profesionales de ambas instituciones, fortaleciendo el desarrollo de la Provincia.

El GAD Provincial de Santo Domingo de los Tsáchilas al ser una empresa del estado sus procesos deben ser transparentes y correctos por esto, es indispensable el uso del sistema para gestionar la información de forma inmediata, como en el caso de alguna auditoria dentro de la empresa. Todo esto está orientado al Plan Nacional del Buen Vivir en el objetivo 11 que dice: “Asegurar la soberanía y eficiencia de los sectores estratégicos para la transformación industrial y tecnológica” propuesto por la SENPLADES, específicamente a la meta 11.5 “Alcanzar un índice de gobierno electrónico de 0,65” haciendo referencia a que la información gubernamental se registre de forma electrónica.

El objetivo proyecto es suplir la necesidad de tener un control automático sobre el ingreso y salida de los vehículos institucionales, un registro electrónico de todos los permisos internos con los que circulan y su futuro acoplamiento al sistema de posicionamiento vehicular interno que se maneja en la actualidad para la visualización de los datos reales y completos de los vehículos pertenecientes al GAD Provincial de Santo Domingo de los Tsáchilas.

El Software permitirá al departamento de Gestión Vehicular mantener una mejor organización con los documentos que se generan, ahorrando tiempo en las consultas y manteniendo un respaldo histórico electrónico, aparte del respaldo físico. Se encuentra alojado en un servidor destinado para su funcionamiento y una de sus mayores virtud es que al ser un sistema desarrollado con software libre, no necesitó costos elevados para su instalación en el

5 ambiente de trabajo; la empresa cuenta con gente capacitada para dar mantenimiento y solución a diversos problemas, lo cual facilita gastos al momento de supuestos fallas.

2.4. Objetivos de la investigación 2.4.1. Objetivo General Implementar un sitio web dinámico que permita la gestión vehicular para mejorar los procesos internos en el GAD Provincial de Santo Domingo de los Tsáchilas.

2.4.2. Objetivos Específicos 

Realizar una investigación de campo que permita la extracción de datos e información principal para el proyecto utilizando los respectivos instrumentos.



Desarrollar un SRS (especificaciones requerimiento de software) que abarque todos los requisitos del GAD Provincial Santo Domingo de los Tsáchilas.



Realizar un diagrama de Gantt con los hitos del proyecto de software.



Elaborar un SDS (especificaciones de diseño de software) para la visualización del comportamiento del software.



Desarrollar el software según las especificaciones recogidas en el SRS y SDS.



Presentar un informe de pruebas para determinar la calidad del software.



Implementar el software en el GAD Provincial de Santo Domingo de los Tsáchilas.

6

3.

MARCO REFERENCIAL

En el marco referencial se encuentra el conjunto de teorías necesarias para cualquier investigación sea cuantitativa, cualitativa o mixta; tiene como función sustentar teóricamente el estudio e investigación a realizar.

3.1.

Revisión de la literatura o fundamentos teóricos

3.1.1. Concepto de Software Son todos los componentes lógicos e intangibles que posee un ordenador. (Pérez Villa J. D., 2014) 3.1.1.1. Clasificación del software En el libro ingeniería de software un enfoque práctico; el autor clasifica al software en dominios de aplicación. (Pressman, 2010).

3.1.1.1.1. Software de Sistemas Es un conjunto de programas escritos para dar servicios a otros programas.

3.1.1.1.2. Software de aplicación Programas aislados que resuelven una necesidad específica de negocios.

3.1.1.1.3. Software baso en inteligencia artificial Hace uso de algoritmos no numéricos para resolver algoritmos complejos que no son fáciles de tratar computacionalmente o con el análisis directo.

7 3.1.1.1.4. Software de aplicación web Llamadas “Webapp”, se centra en redes agrupando una amplia gama de aplicaciones.

3.1.1.1.5. Software Libre Software libre es aquel que respeta las 4 libertades principales, ejecutar, copiar, modificar, distribuir. (GNU, 2015) 3.1.2. Concepto de Ingeniería de Software “La ingeniería de software es la aplicación de un enfoque sistémico, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del software”. (Boehm, 1996) La ingeniería de software es una técnica multicapas, donde le fundamento es la capa de proceso. El proceso de la ingeniería de software es la unión de mantiene juntas las capas de tecnología y que permite un desarrollo racional y oportuno de la ingeniería de software.

(Guerrero Peña, 2007) El trabajo de la ingeniería de software se puede dividir en tres fases que son: 

Fase de definición: Se identifica la información que va a ser procesada, su función,

comportamiento, interfaces, restricciones de diseño y que criterios de validación son necesario para definir un sistema. 

Fase de desarrollo: Se enfoca al diseño de la estructura de datos y la implementación

a un lenguaje de programación, para dar paso a un tiempo de pruebas. 

Fase de mantenimiento: Se enfoca a la corrección de errores y dar adaptación de las

evoluciones del software.

8 3.1.3. Modelos de desarrollo de software Enfocados a resolver problemas reales, que deben incorporar procesos métodos y herramientas. Se encuentra en 4 etapas distintas: 

Definición del problema: Se identifica y se aclara el problema específico para darle

solución. 

Desarrollo Técnico: Se presenta el problema con una solución tecnológica, como puede

ser documentos, programas, datos entre otros. 

Integración de soluciones: Estas dos etapas se dividen las fases y los pasos genéricos de

ingeniería de software. 

Integración de soluciones y estado actual: Estas dos etapas se dividen en fases y los pasos

genéricos de ingeniería de software. (Guerrero Peña, 2007) 3.1.4. Modelo General de Procesos Se puede referir a los procesos como una colección de actividades de trabajo, acciones y tareas que se deben llevar a cabo dentro de la construcción de software hasta tener el producto terminado. Una general para la ingeniería de software define cinco actividades estructurales: comunicación, planeación, modelado, construcción y despliegue. (Guerrero Peña, 2007) 3.1.5. Modelo lineal secuencial 3.1.5.1. Ingeniería y modelado de sistemas/ Información “El trabajo comienza estableciendo requisitos de todos los elementos y asignando el software al nivel de modelado que requiera implementar. Esta visión del sistema es esencial cuando el software se deben interconectar con otros elementos.” (Guerrero Peña, 2007)

9 3.1.5.2. Análisis de los requerimientos En este punto es importante toda la información de los requisitos del software, para poder tener especificar la naturaleza y construcción del software. Es la parte fundamental en la cual se debe tener estipulado claramente las necesidades del cliente y la información exacta de lo que se va a seguir haciendo en todo el desarrollo del software.

3.1.5.2.1. Diseño El diseño de software es la parte donde ya teniendo todas las especificaciones del cliente, podemos proceder a la construcción de lo que sería la estructura de datos, arquitectura de software, representación de la interfaz y detalle procedimental (algoritmo). (Guerrero Peña, 2007) 3.1.5.2.2. Código En este proceso se debe llevar a cabo la construcción del programa en un lenguaje de máquina, la generación de código se realiza mecánicamente. (Guerrero Peña, 2007) 3.1.5.2.3. Prueba Se debe a los procesos funcionales del software y su implementación en el ámbito de desarrollo para el que fue creado. Se debe tener resultados reales de la funcionalidad de lo que requirió en sus inicios. (Guerrero Peña, 2007) 3.1.5.2.4. Mantenimiento Se realizarán cambios en la evolución del software, que serán evidentes en todo software.

El soporte y mantenimiento vuelve a utilizar cada una de las fases procedentes a un programa ya existentes y no a uno nuevo. (Guerrero Peña, 2007)

10 3.1.6. Modelo de construcción de Prototipos “Es una manera útil de extraer los requerimientos del cliente e identificar y eliminar las partes riesgosas de un proyecto” (Guerrero Peña, 2007) “El desarrollador tal vez no esté seguro del a eficiencia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que deba adoptar la interacción entre el humano y la máquina.” (Pressman, 2010) El paradigma de hacer prototipos comienza en comunicación. Este empieza desde la conceptualización del proyecto en conjunto con otras personas y se define los objetos generales del software, identificar cualquier requerimiento que defina cualquier área que sea importante.

Se planea rápidamente una iteración para hacer el prototipo, y se lleva a cabo el modelado. Éste se centra en la representación de aquellos aspectos del software que serán visibles para los usuarios finales. El diseño de rápido lleva a la construcción de un prototipo. Éste se entrega y es evaluado por los participantes, que dan retroalimentación para mejorar los participantes requerimientos. La iteración ocurre a medida de que el prototipo es afinado para satisfacer las necesidades de distintos participantes, y al mismo tiempo le permite a usted entender mejor lo que se necesita hacer. El ideal es que el prototipo sirva como mecanismo para identificar los requerimientos del software. Si va a construirse un prototipo, pueden utilizarse fragmentos de programas existentes o aplicar herramientas que permitan generar rápidamente programas que funcionen.

Figura 1. Modelo de construcción de prototipos Fuente: Pressman, R. (2010). Ingeniería del software un enfoque práctico.

Connecticut: University of Connecticut.

11 3.1.7. SGBD (Sistema gestor de Base de Datos) Está constituido por un paquete de software cuyo cometido es la gestión del acceso de la BD. Para mantener la perspectiva esencial del cometido de un SGBD debemos considerar que, de forma simplificada, el SGBD atiende la petición de los usuarios en los siguientes términos: 

El usuario solicita una operación sobre la BD.



El SGBD analizara la corrección de la operación de la operación en términos de la sintaxis

del lenguaje proporcionado e interpretará su significado basándose en la definición de los esquemas y en las transformaciones entre niveles que tenga almacenados. 

Una vez que identifica todos los objetos que intervienen en la petición y sea desglosada

las operaciones que se han de efectuar sobre cada uno de ellos, se determina la forma más adecuada para acometer con las modificaciones o recuperaciones pertinentes desde los niveles más externos a los más internos. Elabora lo que se denomina el plan de ejecución. 

Por último desencadena la ejecución de dicho plan, con la que obtenemos como resultado,

dependiendo del tipo de operaciones solicitadas, una modificación en la estructura en el nivel externo o conceptual una validación del contenido de la BD o de la recuperación de una serie de contenido de BD expresado en término del esquema de usuario desde el que se formula la petición. (Pons Capote, Introducción a las bases de datos: el modelo relacional, 2005)

Figura 2. Sistemas Gestor de Bases de Datos Fuente: Pons Capote, O. (2005). Introducción a las bases de datos: el modelo relacional.

12 3.1.8. Lenguajes de programación En el libro de Introducción a C, se define lenguajes de programación como un conjunto de símbolos y caracteres que se combinan entre sí, siguiendo las reglas de una sintaxis predefinida con el objetivo de transmitir instrucciones a un ordenador (Marco A Peña Basturdo; Jose M Cela Espin, 2001).

3.1.9. PHP Lenguaje de programación para el desarrollo web, el Procesador de Hipertexto PHP es un lenguaje interpretado; permite hacer cambios en su código fuente y ponerlos a prueba rápidamente. (V, 2015)

Figura 3.Fundamentos de PHP Vaswani, V. (2010). Fundamentos de PHP. México.

3.1.10. AJAX Ajax es un acromio de Asynchronus JavaScrip And XML, es la suma de varias tecnologías para la comunicación asíncrona de nuestro navegador con el servidor. Mediante este formato las peticiones y respuestas se ejecutan en segundo plano y únicamente se modifican secciones de las páginas sin la necesidad de recargarlas (Gómez, Html5, Css3, Javascript, 2013).

13 3.1.11. JAVASCRIPT JavaScript es un lenguaje de programación creado inicialmente por Brendan Eich en el año de 1995; cabe recalcar que este lenguaje de programación no es una extensión de Java más bien el nombre fue dado a una estrategia de marketing.

JavaScript es un

lenguaje interpretado, dando a entender que no es necesario una

compilación previa a su ejecución, siendo el navegador quien lo interpreta y ejecuta directamente, generalmente usado para la validación de datos. (Gómez, 2013) Orós Cabello (2013) da una definición y dice que: “es un lenguaje de programación con el objetivo de integrarse en HTML y fácil de creación de páginas interactivas sin necesidad de utilizar scripts de GGI o JAV”. (Orós Cabello, 2013) 3.1.12. Protocolo HTTP “Es el protocolo de transferencia de hipertexto, es el encargado de transferir el código HTML de una página Web a nuestro navegador; asimismo, HTTP establece la forma y modo de la que se establece las comunicaciones entre cliente y servidor” (Rubiales Gómez, 2013).

3.1.13. JQuery Es un conjunto de librerías JavaScript que han sido diseñadas específicamente para simplificar el desplazamiento de un documento HTML, la animación, la gestión de eventos y las interacciones Ajax. (blog.udemy.com, s.f.)

3.1.14. CSS Los documentos CSS son conocidos generalmente como hojas de estilas en cascada siendo este un lenguaje que define el aspecto, la presentación y posición que tendrán los distintos

14 elementos de una página web, con esto se logra separar la estructura de la página HTML de su presentación. (Gómez, HTML5, CSS3 Y JAVASCRIPT) 3.1.15. Apache Apache es un servidor web HTTP multiplataforma y de código abierto, perteneciente a Apache Software Fundation (ASF) que es una organización de desarrollo de software sin fines de lucro. (apache, s.f.)

3.1.16. HTML “Es un lenguaje de descripciones de hipertexto compuesto por una serie de comandos, marcas, o etiquetas, también denominadas “Tags” que permiten definir la estructura lógica de un documento web y establecer los atributos del mismo. (Cobo, Gómez, Perez, & Rocha, 2008) 3.1.17. MySQL Es una Base de datos, soporta el lenguaje SQL y la conexión de varios usuarios, pero, en general, se utiliza para aplicaciones de tamaño pequeño-medio. (Pavón Puertas, 2011) 3.1.18. ¿Qué es una base de datos?

Es una estructura computarizada, compartida e integrada que guarda un conjunto de datos del usuario final, metadatos.

3.1.18.1. Diseño o modelado de una base de datos Se refiere a las actividades que se concentran en el diseño de la estructura de la base de datos que se usará para guardar y administrar datos del usuario final.

15 3.1.18.2. Modelo relacional Es un concepto matemático conocido como relación en donde las tablas se relacionan entre sí compartiendo un atributo. (Coronel, 2011) 3.1.18.3. Modelo jerárquico Está organizado por niveles los cuales manejan grandes cantidades de datos, donde los niveles más altos tienen mayor prioridad. (Coronel, 2011) 3.1.18.4. Modelo de red Fue creado para representar complejas relaciones de datos en forma más efectiva que el modelo jerárquico, mejorando la operación de una base de datos e imponiendo un estándar de base de datos. (Coronel, 2011) 3.1.19. ¿Qué es un servidor?

Es un ordenador que posee un programa que realiza una o varias operaciones proporcionando información a un conjunto de clientes.

3.1.20. Servidor FTP Mediante el protocolo FTP se gestiona la trasferencia de información, archivos, documentos, entre otros mediante una plataforma servidora con dicho protocolo, el cual nos permita hace consultas de la página web mediante un servidor HTTP. (Quijada López, 2014) 3.1.21. Modelo cliente-servidor Es el modelo por el cual se comunican 2 ordenadores conectados a internet donde el cliente realiza solicitudes de servicio. (Forouzan, 2002)

16 3.1.22. Metodología de Desarrollo de software Son modelos que buscan generar un flujo en los procesos implicados para el desarrollo de software. (Pressman, 2010) 3.1.23. Metodología cascada Es una metodología de desarrollo de software donde su enfoque es sistemático y secuencial.

(Pressman, 2010) Las etapas del modelo en cascada reflejan directamente las actividades fundamentales del desarrollo: ● Análisis y definición de requerimientos Se realizan consultas al usuario para definir los servicios, las restricciones y metas finales; estos deben ser pulidos y estar detallados para la especificación del sistema. En este proceso se genera el SRS. ● Diseño del sistema y del software Mediante los requerimientos estos son asignados como procesos de hardware o software, para definir en cual orientar como sistema global. En esta parte se pretende identificar y definir los procesos fundamentales de software y sus relaciones. Como producto tenemos el SDS. ● Implementación y prueba de unidad En esta etapa se desarrolla el software según el diseño previamente generado. La prueba de unidad consiste en verificar que cada unidad realice sus tareas de acuerdo a lo propuesto.

17 ● Integración y prueba de sistema Los programas o módulos individuales son agrupados para hacer uno integrado y se prueban como un sistema completo, para así ver su funcionalidad completa. Una vez completo esto y de tener probado, el producto es liberado al cliente. ● Operación y mantenimiento Suele ser la fase más larga de todo el ciclo, donde el sistema se instala y se pone en el ambiente de trabajo. En este se evidencian los errores y falencias que no se detectaron en anteriores etapas del ciclo de vida; se procederá a mejorar y cubrir los nuevos requerimientos que se vayan presentando.

“En principio, el resultado de cada fase consiste en uno o más documentos que se autorizaron (“firmaron”). La siguiente fase no debe iniciar sino hasta que termine la fase previa. En la práctica, dichas etapas se traslapan y se nutren mutuamente de información. En la codificación se descubren problema de diseño, y así sucesivamente.” (Somerville, 2014).

Se debe tener en cuenta que el proceso de software no es netamente lineal, sino que implica retroalimentación de otra, siendo así que su documentación cambie en anteriores etapas si se efectúan cambios. Hay ciertas veces en que se debe seguir con otros pasos dentro de una etapa porque aún no son beneficiosos y se deja para posteriores etapas, porque pueden generar grandes cambios significativos.

En cada proceso que se realiza se genera documentación, por ello todos sus procesos y cambios son visibles. Según Somerville I. (2014), el modelo cascada solo debe usarse cuando los requerimientos se entiendan bien y sea improbable el cambio radical durante el desarrollo del sistema.

18

Figura 4. Modelo Evolutivo Fuente: Ian Somerville software, i. d. (2014). Mexico: Pearson Educacion.

3.1.24. Modelo evolutivo Son sistemas complejos que evolucionan con el tiempo, mediante iteraciones permitiendo el cambio del producto. (Pressman, 2010)

Figura 5. Modelo evolutivo Fuente: Pressman, R. (2010). Ingeniería del software un enfoque práctico. Connecticut: University of Connecticut.

3.1.25. ¿Qué es una red informática?

Siendo una descripción sencilla se podría definir a una red informática como un conjunto de ordenadores conectados entre sí. La conexión entre ellas puede ser de forma física y lógica.

(Black, 2010)

19 3.1.26. Métodos ágiles Los métodos ágiles están basados en el manifiesto ágil, publicado en el 2001 por un conjunto de desarrolladores de software relevantes en el mundo, fundamentado en 4 puntos: Valorar a individuos y sus iteraciones: El objetivo de este es poner primer plano a las personas, antes que a las herramientas de desarrollo.

Valorar más el software que funciona: El objetivo de este es generar un mayor grado de importancia en el producto que en la documentación que nos llevó a crearlo.

Valorar más la colaboración con el cliente: Lo importante es establecer un marco de confianza y colaboración con el cliente más que con el contrato.

Valorar más la respuesta al cambio: Esto nos permite adaptarnos a los cambios que surgen durante el desarrollo del proyecto generando una metodología flexible en vez de seguir un plan rígido y sin capacidad de aceptar cambios en los tiempos necesarios. (Álvarez Garcia & de las Heradas, Métodos ágiles y Scrum, 2012)

3.1.27. Principios de los métodos ágiles  Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.  Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar una ventaja competitiva al cliente  Entregamos software funcional frecuentemente entre dos semanas y dos meses, de preferencia al periodo de tiempo más corto posible.  Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.  Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan y confiarles la ejecución del trabajo.  La conversación cara a cara es el método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros.  El software funcional es la medida principal de progreso.  Los procesos ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.  La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.  La simplicidad o el arte de maximizar la cantidad de trabajo no realizado es esencial.  Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.  A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia. (Álvarez Garcia, De las Heradas, & Gómez, Métodos Ágiles y Scrum, 2012)

20 3.1.28. Metodología de Scrum Establece un marco de trabajo basado en equipos auto-gestionados, generando resultados de calidad en un tiempo de 1-4 semanas, denominados Sprints. Basado en los siguientes principios: Inspección y adaptación. Al finalizar cada Sprint se genera un producto que es entregado al cliente y así comenzar el proceso de realimentación.

Auto-organización y colaboración. Mediante este principio se busca que el equipo adquiera responsabilidad sobre sus obligaciones y un gran nivel de compromiso, apoyándose mutuamente para resolver dudas y eliminar impedimentos.

Priorización. Es necesario tener los requisitos priorizados según el valor del negocio, así impedimos pérdida de recursos. (Álvarez Garcia & de las Heradas, Métodos ágiles y Scrum, 2012)

3.1.29. El proceso de Scrum Sprint 0: Es una etapa de duración variable y la más importante durante la metodología, en la cual se define la misión del trabajo, las herramientas que se usarán y el equipo de trabajo.  Definimos las condiciones: Alcance del proyecto, recursos- financiación, personas, herramientas- necesarias, marco temporal para la entrega de resultados y saber si es viable el desarrollo del proyecto.  Contenido del trabajo: Para definir el contenido del trabajo se genera la primera versión del producto llamada Product Backlog, que contiene la visión de los requisitos principales: Funcionalidades o resultados, productos generados, iteración con el cliente.

Sprint: Sigue una secuencia precisa de reuniones, un calendario para las entregas en los cuales iremos desarrollando el producto. (Álvarez Garcia, De las Heradas, & Gómez, Métodos Ágiles y Scrum, 2012)

Figura 6 Modelo Scrum Fuente: Álvarez García, A., & de las Heradas, R. (2012). Métodos ágiles y Scrum.

21 3.1.30. Estándar ACID para base de datos Es un estándar que garantiza que las transacciones de las bases de datos se realicen de forma confiable definido en 1970 por Jim Gray.

Atomicidad: Si una operación consiste en una serie de pasos todos ellos ocurren o ninguno Consistencia (Integridad): Solo se ejecutarán transacciones que lleven a la base de datos de un estado válido a otro.

Aislamiento: Que dos transacciones sobre la misma operación sean independientes garantizado la visibilidad de los cambios producidos por una operación siendo el parámetro esencial la hora.

Durabilidad: Una vez realizada la operación no se podrá cambiar aunque falle el sistema y la información sobreviva de alguna manera. (DOS IDEAS. Personas y Software, 2013)

3.1.31. DSL Provenientes del inglés, data sub lenguaje la arquitectura ANSI/SPARC recomienda que los SGDB deben disponer de un lenguaje específico orientado a los datos que aporte los mecanismos necesarios para gestionar las tareas de definición, control y manipulación de datos; debe estar implementado en el propio SGDB. (Pons Capote, Marín Ruiz, Medina Rodríguez, Acid Carrillo, & Vila Miranda , 2009) DLL: (del inglés, Data Definition Lenguaje) o sub lenguaje de definición de datos. Sub conjunto del DSL destinado a la definición de estructuras de datos y esquemas en la Base de Datos.

Create: Nos permite crear un objeto dentro de la base de datos.

Drop: Nos permite eliminar un objeto dentro de la base de datos.

Alter: Nos permite modificar un objeto dentro de la base de datos. (Pons Capote, Marín Ruiz, Medina Rodríguez, Acid Carrillo, & Vila Miranda , 2009)

3.1.32. DML Proveniente del inglés, data manipulation lenguaje) o sub lenguaje de manipulación de datos, sub conjunto de DSL mediante el cual podemos introducir datos en los esquemas, modificarlos, eliminarlos y consultarlos, también se puede consultar la estructura de los esquemas en la Base de Datos.

Insert: Nos permite ingresar un registro en una tabla de la BD. Update: Nos permite modificar los datos de un registro de una tabla.

Delete: Nos permite eliminar un registro de una tabla en la base de datos.

Select: Nos permite hacer consulta a una tabla en la base de datos. (Pons Capote, Marín Ruiz, Medina Rodríguez, Acid Carrillo, & Vila Miranda , 2009)

3.1.33. DLC Proveniente del inglés, data control lenguaje o sub lenguaje de control de datos, que nos permite gestionar los requisitos de acceso a los datos y otras tareas administrativas sobre la BD. GRANT: Permite dar permisos a uno o varios usuarios o roles para realizar tareas determinadas.

22 REVOKE: Permite eliminar permisos que previamente se han concedido con GRANT. (Pons Capote, Marín Ruiz, Medina Rodríguez, Acid Carrillo, & Vila Miranda , 2009)

3.1.34. Postgresql Es una base de datos relacional y distribuido, que ha liberado su código. Utiliza el modelo cliente servidor y usa multiprocesos en vez de multihilos garantizando la estabilidad del sistema ya que si falla un proceso no afecta al resto y el sistema continúa funcionando.

Sus características principales son:  Es una base de datos que cumple con el estándar ACID.  Integridad referencial.  Tablespace (es un directorio)  Copias de seguridad en caliente.  Unicode.  Juego de caracteres internacionales.  Completa documentación.  Procedimientos almacenados. (PostgreSQL, 2010)

3.1.35. Pgadmin3xzsxz Es un software gestor de base de datos libre, multiplataforma, que nos permite administrar la base de datos Postgresql de forma gráfica a partir de la versión 7.3. (Pgadmin, 2008) 3.1.36. Modelo vista controlador Permite distribuir las funcionalidades de una aplicación interactiva donde el grado de acoplamiento entre los objetos de la aplicación debe ser mínimo.

Modelo: Encapsula la información que maneja el sistema, incluyendo la información del negocio y la lógica de acceso a los mismos.

Vista: Es la interfaz de usuario. Reenvían la entrada del usuario al controlador.

Controlador: Recibe las entradas de la vista, modifica el modelo y produce cambios en la vista.

(Martínez, Valderas Aranda, & Oscar Pastor López, 2010)

3.1.37. Concepto de gestión vehicular La palabra gestión es la acción de administrar un objeto, mientras que la palabra vehicular hace referencia a un vehículo. En conclusión se puede derivar que la expresión gestión vehicular significa la administración de un conjunto de vehículos. La gestión vehicular o también conocida como gestión de flotas, podemos referirnos que es un sistema que tiene como objetivo permitir a una empresa de transportes controlar los vehículos o maquinarias de su propiedad, organizar estas unidades en flotas,

23 programar y controlar mantenciones preventivas y/o correctivas, controlar el kilometraje recorrido (o las horas trabajadas) y el consumo de combustible, controlar y administrar las llantas utilizadas por sus vehículos, tener un control de los seguros tomados para las flotas o vehículos y de los siniestros acaecidos, controlar los conductores utilizados, controlar las fechas de vencimiento de las revisiones técnicas de los vehículos y los vencimientos de las licencias de conducir de los conductores, registrar ingresos mediante la venta de servicios/fletes o mediante la disponibilidad de equipos para que sean utilizados por empresas clientes y, finalmente, obtener informes de los resultados obtenidos en la operación de cada uno de los vehículos.

Los vehículos dentro de una empresa, son los activos fijos como herramienta de trabajo para el personal de una entidad. Su cuidado y conservación de ser una preocupación constante de la administración, garantizando mediante un control el buen uso de tales unidades.

La utilización de los vehículos, por necesidades del servicio, en días no laborables requiere la autorización expresa del nivel superior del solicitante. Esto tiene el propósito de disminuir la posibilidad de que los vehículos sean utilizados en actividades distintas a los fines que corresponde.

24

4. METODOLOGÍA DE LA INVESTIGACIÓN 4.1.

Enfoque/Tipo de investigación

El diseño de investigación está basado en los enfoques de campo y aplicado, en la sección de campo se realizó una investigación mixta dado que el método cuantitativo se desarrolló a través de una encuesta. En la sección cualitativa desarrollamos una entrevista con los directores de los departamentos de Gestión Vehicular y TIC del GAD Provincial de Santo Domingo.

El diseño aplicado está basado en un enfoque de investigación y acción debido a que el objetivo de la investigación es determinar un problema, definir métodos de solución y aplicarlos para obtener un cambio en la situación actual que presenta el GAD Provincial de Santo Domingo de los Tsáchilas.

Como guía para el desarrollo del software se aplicó el modelo cascada, el cual orienta de inicio a fin la documentación y los pasos para la construcción e implementación del sistema.

4.2.

Población

La cantidad total que se determinó para el Plan de Disertación de Grado es el personal del GAD Provincial de Santo Domingo de los Tsáchilas perteneciente a las áreas de Gestión Vehicular concretamente los conductores, personal administrativo.

4.3.

Muestra

Para definir y determinar la muestra se tomaron dos grupos: el departamento de gestión vehicular y el departamento de Sistemas del GAD Provincial de Santo Domingo de los Tsáchilas que al ser grupos pequeños no se aplicará fórmula porque dicha población es ínfima; es decir, en total los dos departamentos dan un total de 30 personas.

25 La población que se tomó de muestra en el proyecto fueron los departamentos de gestión vehicular y el departamento de Sistemas del GAD Provincial de Santo Domingo de los Tsáchilas.

Miguel Ángel Posso menciona en el libro de Metodología para el Trabajo de Grado “…La mayoría de investigadores aconseja que cuando la población o universo a investigarse no sobrepasa 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...” (Posso Yépez, 2006) Los miembros del departamento de Gestión Vehicular son 30 personas, por lo tanto, cumple con la referencia de Miguel Ángel Posso concluyendo que nuestra muestra es toda la población.

4.4.

Instrumentos para recogida de datos

Como técnica de recogida de información se utilizó la entrevista, aplicada a los directores de los dos departamentos (Gestión vehicular y Sistemas) para establecer las funcionalidades principales del sistema y los requisitos en el diseño de arquitectura; esta información se encuentra planteada en el SRS (Anexo 3).

También se aplicó una encuesta a los choferes, guardias y personal administrativo del departamento de Gestión Vehicular para medir el grado de aceptación que tiene el proceso de gestión vehicular actual; al mismo tiempo, saber que tan reacios están sobre la automatización de este proceso.

4.5.

Técnicas de análisis de datos

Se realizará un análisis estadístico a la encuesta mediante los gráficos de pastel, con la finalidad de tener una mayor visualización del problema

26

4.6.

Comparación de metodologías

Tabla 1.

Comparación de Metodologías Cascada Fase de análisis detallada Proyectos Cortos Se tiene claro lo que se pide Poca interacción con el cliente Modelo Lineal

Prototipo Mayor integración del cliente Modelo en espiral Entrega de una funcionalidad en cada iteración Reducción de costos en diseño Mayor claridad en el progreso de desarrollo de software

SCRUM Gran cantidad de personal Método ágil Reuniones diaria Entregas de prototipos en tiempos cortos Mayor iteración del cliente

Pocos Recursos Fuente: (Pressman, 2010) y (Somerville, 2014)

El GAD Provincial de Santo Domingo de los Tsáchilas, tiene ya definidos los procesos a automatizar con los estándares a manejar, por lo tanto, se utilizará para el desarrollo de software la metodología cascada.

4.7.

Comparación Bases de datos

Tabla 2.

Comparación Bases de Datos

Gestor de Base de Datos Postgresql Motor de base de Libre Base de Datos distribuido Base de robustas Facilidad de discriminar mayúsculas de minúsculas

Gestor de bases de datos MySql Motor de base de Libre Problema de estabilidad Problema de seguridad Problema en la codificación de Trigers

Fuente: (Pons Capote, Marín Ruiz, Medina Rodríguez, Acid Carrillo, & Vila Miranda , 2009)

Dado las siguientes características se escogió a Postgresql como el gestor de base de datos siendo su seguridad y robustez las principales razones para seleccionarlo.

27

5.

5.1.

RESULTADOS

Discusión y Análisis de los resultados

5.1.1. Encuesta La encuesta fue realizada de 16:00 PM a 17:00 PM debido que en este horario los trabajadores del departamento del Gad Provincial firman las salida de su día laboral. El proceso se llevó de forma ágil ya que los directores del departamento nos brindaron el apoyo al momento de realizar la encuesta siendo esta una condición para finalizar su jornada.

Dentro de la encuesta realizada se dio a notar que los trabajadores del departamento de gestión del GAD provincial sienten que sistema están manejando actual necesita una mejoría.

(Anexo 1) 5.1.2. Entrevista Se analizó los objetivos principales del sistema, su funcionamiento y en que arquitectura estará basada, mediante la realización de una entrevista a los directores de los departamentos de Gestión Vehicular y TIC siendo estos el Ing. Víctor Carrera e Ing. Pablo Guillen respectivamente.

Se obtuvo una idea general de la estructura de la base de datos y los distintos actores que maneja el sistema y la comunicación entre distintos módulos del sistema. (Anexo 2) 5.1.3. Especificación de requerimientos de sistemas. (SRS) Siendo el SRS uno de los documentos más importantes para un desarrollo de software basa en el ciclo de vida cascada nos tomamos en realizarlo. Tuvimos inconvenientes al momento de definir el alcance del Proyecto de Software ya que el GAD Provincial requería un software de

28 gestión vehicular con distintos módulos que no se iban a poder implementar en el tiempo predefinido combinando la línea de investigación de desarrollo e implementación de software con desarrollo de componentes electrónicos.

Se llegó a un acuerdo durante las reuniones para generar el módulo de control de ingreso y salida vehicular con la respectiva documentación necesaria. Todo esto se refleja en el SRS. (Anexo 3) 5.1.4. Diagrama de Gantt Se desarrolló un diagrama de Gantt con los principales hitos del proyecto para poder dar seguimiento al avance de este, hubo problemas con las fechas donde ya se debía tener resuelto la fase de especificaciones de requisitos, debido a los excesivos requerimientos que pedían y estos no se podían ajustar al tiempo en que teníamos que entregar el proyecto.

Se llegó al acuerdo de disminuir los requerimientos de software, siendo este escalable, permitiendo adaptaciones nuevos módulos que satisfagan los requerimientos excluidos inicialmente. (Anexo 4) 5.1.5. Especificación de Diseño de Software (SDS) Para las interfaces se definió que estas tienen que ser intuitivas para los distintos actores del sistema, se debatió entre realizarlas de forma manual en html5 y utilizar una plantilla predefinida, llegando a la conclusión que el uso de la plantilla es la mejor opción debido al poco tiempo que se posee para el desarrollo del software.

La base de datos deberá ser escalaba y robusta, para conseguirlo se la implementó en Postgrest utilizando triggers para la sección de seguridad y Json para la comunicación entre el Back-End y el Front-End

29 Se documentó los diseños físicos y lógicos de la base de datos, se hicieron prototipos de interfaces y se desarrollaron diagrama de secuencia de las principales funcionalidades dentro del SDS. (Anexo 5) 5.1.6. Fase de Codificación.

Para el Front-End se decidió utilizar Jquery, html5, scc3 para la sección de interfaces, mientras que en el Back-End utilizamos Postgrest, php, pdo y namespaces siendo estas dos últimas, apis de php. Mientras para la comunicación entre ellos se utilizó Json.

Se generó el código funcional del programa orientado al modelo vista controlador. (Anexo 6) 5.1.7. Fase de pruebas.

El software se implantó en un servidor de pruebas del GAD Provincial de Santo Domingo de los Tsáchilas, teniendo aquí iteración con el resto de los sistemas que ellos poseen pero sin afectarlos.

Se realizaron informe de pruebas sobre las funcionalidades principales del sistema (Anexo 7) 5.1.8. Manual de Usuario.

Se generó un manual de usuario donde se especifica el funcionamiento de cada botón.

(Anexo 8)

30

5.2. 

Conclusiones

El proyecto presentado es una herramienta de trabajo óptima para el control de la gestión interna de vehículos del GAD Provincial de Santo Domingo de los Tsáchilas, ofreciendo un servicio eficiente y ágil, cumpliendo con las exigencias del cliente.



Una de sus ventajas es la implementación del sistema biométrico en conjunto con la aplicación web ya que solventará muchos problemas de organización de la empresa y facilitara el controlo a los conductores, también brindará seguridad en sus procesos. .

5.3. 

Límites y Recomendaciones

Una limitante es que el dispositivo biométrico tiene que generar un archivo .txt con el siguiente formato: CedulaChofer, año-mes-dia hh:mm:ss



Se recomienda que el dispositivo biométrico sea portable o a su vez, esté ubicado en un lugar estratégico.



El sistema implementado al Departamento de Gestión Vehicular del GAD Provincial de Santo Domingo de los Tsáchilas es aplicable a cualquier organización pública o privada, siempre y cuando maneje una estructura similar de control vehicular.

31

REFERENCIAS BIBLIOGRÁFICAS Bibliográficas Álvarez Garcia, A., & de las Heradas, R. (2012). Métodos ágiles y Scrum. Obtenido de http://www.agilemanifesto.org/iso/es/ Álvarez Garcia, A., De las Heradas, R., & Gómez, C. (2012). Métodos Ágiles y Scrum. Grupo Hayana. apache. (s.f.). apache.org. Obtenido de apache.org: http://apache.org/foundation/how-itworks.html Black, U. (2010). Manual Imprenscindible de Redes. blog.udemy.com. (s.f.). Obtenido de https://blog.udemy.com/jquery-vs-javascript-2-cual-es-ladiferencia-en-definitiva/ Boehm, B. (1996). Anclaje del Proceso de Software.

Cobo, A., Gómez, P., Perez, D., & Rocha, R. (2008). PHP Y MYSQL tecnologias para desarrollo web. Madrid, España: Dias de Santos.

Coronel, C. S. (2011). Base de Datos-Diseño, Implementación y administración. Mexico: C y C. DOS

IDEAS.

Personas

y

Software.

(19

de

febrero

de

2013).

Obtenido

de

http://www.dosideas.com/noticias/base-de-datos/973-acid-en-las-bases-de-datos.html Forouzan, B. (2002). Transmisión de Datos y Redes de Comunicación. Mexico.

GNU.

(05

de

Septiembre

de

2015).

http://www.gnu.org/philosophy/free-sw.es.html

GNU.

Obtenido

de

GNU:

32 Gómez, M. R. (2013). Html5, Css3, Javascript. En M. R. Gómez, Html5, Css3, Javascript (pág.

252). Grupo Anayala.

Gómez, M. R. (2013). Html5, Css3, Javascript. En M. R. Gómez, Html5, Css3, Javascript (pág.

161). Grupo Anayala.

Gómez, M. R. (s.f.). HTML5, CSS3 Y JAVASCRIPT. En M. R. Gómez, HTML5, CSS3 Y JAVASCRIPT (pág. 160).

Guerrero Peña, D. A. (2007). Elementos Básicos de Ingeniería de software. Medellín, Colombia: Instituto Tecnológico Metropolitano, Edición Textos Académicos.

Martínez, D., Valderas Aranda, P., & Oscar Pastor López. (2010). Enfoque práctico.

AlfaOmega Grupo Editor.

Mysql. (s.f.). LINK https://www.mysql.com/products/workbench/. Obtenido de LINK https://www.mysql.com/products/workbench/.

Orós Cabello, J. (2013). Guía Práctica de HTML, JavaScript y CSS. Mexico: Alfaomega RAMA. Pavón Puertas, J. (2011). Creación de un portal con PHP y MySQL. Mexico DF, Mexico: ALFAOMEGA Grupo.

Pérez Villa, J. (2014). Guías visuales-Introducción a la informática.

Pérez Villa, J. D. (2014). Guías visuales - Introducción a la informática.

Pgadmin. (2008). Obtenido de http://www.guia-ubuntu.com/index.php?title=PgAdmin_III Pons Capote, O. (2005). Introducción a las bases de datos: el modelo relacional.

33 Pons Capote, O., Marín Ruiz, N., Medina Rodríguez, J., Acid Carrillo, S., & Vila Miranda , M. A. (2009). Libro introducción a las bases de datos.

PostgreSQL. (2010). Obtenido de http://www.postgresql.org.es/sobre_postgresql Pressman, R. (2010). Ingeniería del software un enfoque práctico. Connecticut: University of Connecticut.

Quijada López, J. (2014). Domine PHP y MySQL. Mexico: Mxr. Rubiales Gómez, M. (2013). HTML,CSS Y JavaScript. España: ANAYA MULTIMEDIA. software, i. d. (2014). Ian Somerville. Mexico: Pearson Educacion.

V, V. (01 de 2015). Fundamentos de PHP. Mexico: Editorial SA. Obtenido de PHP.

34

GLOSARIO Ciclo de vida del software: Con frecuencia se usa como otro nombre para el proceso de software; originalmente se acuñó para referirse al modelo en cascada del proceso de software.

Componentes: Unidad de software independiente y portable que está completamente definido y al que se accede a través de un conjunto de interfaces.

Flujo de procesos: Definición detallada de un trabajo empresarial que tiene la intención de lograr ciertas actividades.

Gestión: Acción o efecto de administrar.

Hardware: Parte física y tangible del computador.

Ingeniería de sistemas: Proceso que se ocupa de especificar un sistema, integrar sus componentes y probar que el sistema satisface sus requerimientos. La ingeniería de sistemas se ocupa de todo el sistema socio técnico, no sólo del software de sistemas.

35 Interfaz: Especificación de los atributos y las operaciones asociados con el componente de software. La interfaz se usa como medio para acceder a la funcionalidad del componente.

Mantenimiento: Proceso de hacer cambios a un sistema después de ponerlo en operación.

Seguridad: Capacidad de un sistema para protegerse a sí mismo contra intrusión accidental o deliberada.

La seguridad incluye confidencialidad, integridad y disponibilidad.

Sistema Sociotécnico: Sistema (incluye hardware y componentes de software) con procesos operacionales definidos, que siguen operadores humanos y que funciona dentro de una organización. Por lo tanto, recibe influencia de políticas, procedimientos y estructuras organizacionales.

Servidor: Programa que proporciona servicio a otros programas (cliente).

Software: Parte lógica e intangible del computador.

XML: Extended Markup Language, es decir, lenguaje de marcas extensible. XML es un lenguaje de marca de texto que soporta el intercambio de datos estructurados. Cada campo de datos está delimitado por etiquetas que ofrecen información acerca de dicho campo. Ahora XML se usa ampliamente y se ha convertido en la base de protocolos para servicios Web.

36 MULTIPLATAFORMA: Dicho de una aplicación o de un producto informático: Que puede ser utilizado por distintos sistemas o entornos.

SRS: Documento de Especificación de Requerimientos de Software.

SDS: Documento de Especificación de diseño de Software MANUAL DE USUARIO: Se trata de una guía que ayuda a entender el funcionamiento de algo, o bien que educa a sus lectores acerca de un tema de forma ordenada y concisa. Un usuario es, por otra parte, la persona que usa ordinariamente algo o que es destinataria de un producto o de un servicio.

SPRINT: Es un ciclo dentro del modelo Scrum

37

ANEXO 1. ENCUESTA

38 1. ¿Considera usted que es importante llevar un control sobre el ingreso y salida del personal de transporte?

Tabla 3.

Pregunta 1 SI

NO

30

0

Elaborado por: Xavier Soto y Francisco Arroyo

NO; 0; 0%

SI; 30; 100%

Figura 7. Pregunta 1 Elaborado por: Xavier Soto y Francisco Arroyo

Estos datos nos demuestran, cual es la prioridad máxima, en cuanto a llevar un control de la actividad principal. La aceptación total en un “si” es debida a que este control tanto a los conductores como a la parte administrativa del GAD es la actividad principal que se debe controlar en su trabajo diario.

39 2. ÂżCree usted que el sistema actual necesita mejoras?

Tabla 4.

Pregunta 2 SI

NO

30

0

Elaborado por: Xavier Soto y Francisco Arroyo

NO; 0; 0%

SI; 30; 100%

Figura 8 Encuesta Pregunta 2 Elaborado por: Xavier Soto y Francisco Arroyo

Este tipo de procesos que se realizan en la Actualidad en el departamento de control vehicular del GAD lo hacen de forma manual y sus procesos son muy lentos y muy ajetreados, es por ello que existe la aceptaciĂłn rotunda.

40 3. ¿Considera que el registro electrónico será más eficiente que el que se maneja actualmente?

Tabla 5.

Pregunta 3 SI

NO

17

13

Elaborado por: Xavier Soto y Francisco Arroyo

NO; 13; 43% SI; 17; 57%

Figura 9. Encuesta Pregunta 3 Elaborado por: Xavier Soto y Francisco Arroyo

Si podemos apreciar tendremos un 57% que dice que sí y un 34% que no; estos valores son altos en cuanto a buscar una totalidad en aceptación, esto se debe a que las personas y su aceptación por lo nuevo, con lo poco que se ha conversado, evidencian que ellos ya saben cuál es el proceso y se sienten seguro con ello, es por ello que tenemos un alto porcentaje en el “No”.

41 4. ¿Cree usted que el registro electrónico permitirá llevar un mejor control sobre el ingreso y salida del personal de transporte?

Tabla 6.

Pregunta 4 SI

NO

25

5

Elaborado por: Xavier Soto y Francisco Arroyo

NO; 5; 17%

SI; 25; 83%

Figura 10 Encuesta Pregunta 4 Elaborado por: Xavier Soto y Francisco Arroyo

Los valores presentados, justificando el Si” con un 83% ya que se tiene un registro inmediato y preciso con el sistema; el no con un 17% demuestra que una negación al uso del sistema, como pudimos conversar con algunos conductores podemos saber que esto viene de las personas que niegan el control biométrico, el cual según ellos brindaba un cierto miedo por lo que al timbrar necesitan ser puntuales.

42 5. ¿Considera usted que se debe cambiar la forma de llevar los procesos de control de los vehículos actualmente?

Tabla 7.

Pregunta 5 SI

NO

24

6

Elaborado por: Xavier Soto y Francisco Arroyo

NO; 6; 20%

SI; 24; 80%

Figura 11 Encuestas Pregunta 5 Elaborado por: Xavier Soto y Francisco Arroyo

Ya que todos sus procesos son manuales y un poco tediosos de realizar, dentro del departamento tardan mucho con el papeleo de estos procesos; los pierden mucho tiempo al final de su día con la revisión de sus datos, además es una carga económica el uso de papeles y la movilización de esos documentos a otros departamentos. Por ello existe una aceptación en cuanto a esta pregunta planteada en el cuestionario para que exista un cambio en esto.

43 6. Si la respuesta anterior es si cualifique según su criterio la calidad del control si se lo maneja de forma electrónica Tabla 8.

Pregunta 6 Excelente

Bueno 5

Normal 18

Malo 7

Pésimo 0

0

Elaborado por: Xavier Soto y Francisco Arroyo

Pesimo; Malo; 0;0;0% 0% Normal; 7; 23% Excelente; 5; 17%

Bueno; 18; 60%

Figura 12 Encuesta Pregunta 6 Elaborado por: Xavier Soto y Francisco Arroyo

Enfocado en estos estos puntos cualitativos, se puede tener que entre excelente, normal y bueno, existen los valores más concretos para analizar con un porcentaje de 23% en normal y bueno quiere decir que esto con un nivel de óptimo para ser aceptado, una cierta porción de lo encuentran en excelente por las facilidades que va a brindar.

44 7. ¿Le gustaría a usted que se implemente el uso de nuevas tecnologías al control actual de ingreso y salida de vehículos?

Tabla 9.

Pregunta 7 SI

NO

24

6

Elaborado por: Xavier Soto y Francisco Arroyo

NO; 6; 20%

SI; 24; 80%

SI

NO

Figura 13. Encuesta Pregunta 7 Elaborado por: Xavier Soto y Francisco Arroyo

La aceptación tiene un alto índice en cuanto a los conductores, pero como se ha mencionado en la justificación de preguntas anteriores siempre existe un miedo con la llegada de la nueva modalidad en la que se pretende llevar el control, por eso se representa en este 20%.

45 8. Califique el actual sistema de control sobre la gestión vehicular Tabla 10.

Pregunta 8 Excelente

Bueno

Normal 16

3

Malo 7

Pésimo 4

0

Elaborado por: Xavier Soto y Francisco Arroyo

Malo; 4

Excelente; 3 Pesimo; 0

Normal; 7

Bueno; 16

Figura 14. Encuesta Pregunta 8 Elaborado por: Xavier Soto y Francisco Arroyo

Esta es una de las preguntas que se toma más en cuenta, debido a que se trata de llevar el mismo control mediante el sistema que fue solicitado. El nivel de calificación que obtiene mediante la encuesta es “Bueno” ya que se lleva de forma correcta todos los procesos y tiene su aceptación muy alta porque nunca ha tenido inconveniente en cómo se la ha llevado por años.

46 9. ¿Cree adecuado el uso de un control biométrico para gestión de ingreso y salida de vehículos?

Tabla 11.

Pregunta 9 SI

NO

18

10

Elaborado por: Xavier Soto y Francisco Arroyo

NO; 10

SI; 18

Figura 15 Encuesta Pregunta 9 Elaborado por: Xavier Soto y Francisco Arroyo

El sistema biométrico brinda gran seguridad al sistema y también es una forma más práctica para llevar la información.

El análisis de estos resultados demuestra una aceptación por parte de los conductores, pero también es un valor notorio de un “No”, debido a que las personas supieron expresar su desacuerdo por la impuntualidad de ellos mismos, el sistema biométrico cuenta con gran respaldo en esa área.

47 10. ¿Qué tan familiarizados está usted en el uso de nuevas tecnologías?

Tabla 12.

Pregunta 10 Suficiente

Bastante 3

Normal 8

Poco

Deficiente

16

3

0

Elaborado por: Xavier Soto y Francisco Arroyo

Deficiente; 0 Suficiente; 3 Poco; 3 Bastante; 8

Normal; 16

Figura 16 Encuesta Pregunta 10 Elaborado por: Xavier Soto y Francisco Arroyo

Se quería saber el grado de conocimiento, en cuanto a tecnología por parte de los choferes, ya que como esto será un cambio tecnológico se podría tener inconvenientes y también con la idea a futuro pensar como seria las explicaciones del sistema con las respuestas de esta pregunta. Se puede hacer notoria que el conocimiento o el uso de tecnología en los conductores es alta ya que fluctúa en normal y bastante con superioridad esto nos da apertura para poder enfocarnos en el uso de la tecnología con el sistema.

48

ANEXO 2. Entrevista del Software

49 Antecedentes Se desarrollará un sistema para la gestión vehicular del GAD Provincial, se busca los requerimientos del software.

PREGUNTAS PERSONALES 1. ¿Cómo se maneja actualmente el proceso del ingreso y salida de los vehículos en el parqueadero del GAD Provincial?

El departamento de gestión vehicular está en un punto externo al departamento de TIC, este tiene sus propios procesos. Los vehículos son adjudicados a un chofer con una custodia y se realiza documentación de ello, salen con una orden de movilización el cual tiene un destino, estos salen solos o también con personal autorizado como técnicos que firmarán la salida con el guardia. El guardia se encarga de llevar un control de la entrada y salida de los automotores y adjunta en una hoja la información del vehículo. ¿Tienen algún tipo de subprocesos o documentación que se lleva en el ingreso y salida de vehículos en el parqueadero del GAD Provincial?

Todos los procesos que realiza un chofer o que involucre la salida o ingreso de un vehículo son documentados.     

Custodia Orden de movilización Orden de salida Registro diario de movilización Combustible (no funcional)

¿Qué tipo de sistema necesitan implementar?

Un sistema que automatice los procesos y documentación de todo lo que se realiza en el control y gestión de los vehículos. En cuanto a documentación eliminar papeleo y agilitar procesos;

50 respecto al control de vehículos que todo se realice en un sistema web que pueda ser manipulado por el personal capacitado en el departamento de gestión vehicular. Implementar un control óptimo para los choferes ya que esto no realiza procesos transparentes con su documentación. Se pide implementar un sistema biométrico para controlar ese problema. ¿Existe algún tipo de inconveniente que se trabaje con nuestros propios métodos de programación?, ¿Existe alguna sugerencia?

El sistema debe ser un sistema web y dinámico; la sugerencia es que se trabaje con ciertos parámetros de validación de formato en el nombre de los procesos de datos de la programación y base de datos. ¿Qué tipo de arquitectura manejan dentro del departamento de TIC, para la posterior implementación?

La infraestructura del DTI del GAD cuenta con diversas áreas de trabajo financiero, administrativo y seguridad por el cual cuenta con buenas instalaciones de red y servidores. Las especificaciones del DTI no se pueden dar, pero la parte del servicio web tiene su propio servidor, el servidor esta en CENTOS, donde estará implementado posteriormente el sistema y estará como un módulo adjunto para la administración de un profesional. ¿Qué hará el sistema? (Pregunta puntual) PRINCIPAL 

Login

PROCESOS  

Custodia .- asignación de un vehículo a un chofer(datos del chofer y del vehículo) Orden de movilización.- origen, destino datos de detalle del asunto

51   

Orden de salida.- datos de salida, horarios y detalles.

Registro diario de movilización.- detalles y datos principales Combustible (no funcional).-cantidad y detalles

NOTA: Todos los procesos llevarán documentación y un control con validación en los campos en los que sean de llenado OTROS 

Biométrico

¿Existen varios módulos de operación?

De todos los mencionados el único módulo aparte del sistema o que es nuevo es el del sistema biométrico, externo al sistema están anexados sistemas como el de Quipux que trabajan alterno a los procesos que realicen en la petición de automotores. ¿Dónde está el lugar del sistema que necesita para funcionar?

Se pide un sistema web para tenerlo tanto en el departamento de TIC como en el de Gestión vehicular. ¿Quién usará el sistema?    

Un administrador del departamento de TIC (súper usuario) Administrador del departamento de Gestión Vehicular (administrador) Secretario Guardia

¿Hay restricciones ambientales como temperatura, humedad o interferencia magnética?

El GAD Provincial solventará problemas en cuanto al sistema. ¿La entrada proviene de uno o más sistemas?

La tabla de choferes tendrá que ser exportada del sistema de talento humano.

52 ¿La salida va a uno o más sistemas?

No alimenta a ningún sistema, pero la información alimenta al área administrativa del GAD Provincial. ¿Existe una manera prestablecida en que deben ser guardados los datos?

En cuanto al sistema cada información tiene su parámetro para la documentación, solo en la parte del biométrico la información debe ser guardada con el formato estandarizado de los demás biométricos del GAD Provincial. ¿Debe retenerse algún dato por algún período de tiempo?     

Custodia Orden de movilización Orden de salida Registro diario de movilización Vehículo

Deben estar siempre en la base de datos del sistema hasta una posterior modificación ¿Qué recursos materiales, personales o de otro tipo se requieren para construir, utilizar y mantener el sistema?

Personal capacitado en biométricos. ¿Existe un límite sobre la cantidad de dinero a gastar en el desarrollo o en hardware y software?

Ninguno ¿Debe controlarse el acceso al sistema o a la información?

Se debe validar el control de ingreso mediante usuario y contraseña. ¿Cómo se podrán aislar los datos de un usuario de los de otros?

53 Mediante sección de usuario. ¿Con qué frecuencia deben hacerse copias de respaldo?

Cada 3 meses backups de la base de datos del sistema.

54

ANEXO 3. Fase de Requerimientos-SRS

55

Especificación de requisitos de software

Proyecto: Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Santo Domingo De los Tsáchilas.

Julio del 2016

Instrucciones para el uso de este formato

Este documento especifica los requisitos del software.

Está basado y es conforme con el estándar IEEE Std 830-1998.

Las secciones que no se consideren aplicables al sistema descrito podrán de forma justificada indicarse como no aplicables (NA).

Notas: Los textos en color azul son indicaciones que deben eliminarse y, en su caso, sustituirse por los contenidos descritos en cada apartado.

La sangría de los textos dentro de cada apartado se genera automáticamente al pulsar Intro al final de la línea de título.

El índice del documento es una tabla de contenido que MS Word actualiza tomando como criterio los títulos del documento.

Una vez terminada su redacción debe indicarse a Word que actualice todo su contenido para reflejar el contenido definitivo.

Ficha del documento Fecha

Versión

Descripción

Autor Arroyo Francisco y

27/01/2015

0.1

25/05/2016

0.2

Cambio en el diseño general, nuevas especificaciones

Xavier Arroyo Francisco y Soto Xavier

27/05/2016

0.3

Estructuración de Graficas

Arroyo Francisco y Soto Xavier Soto

Documento validado por las partes en fecha:

Por la comunidad

Por la universidad

Gobierno Autónomo Descentralizado de

Pontificia Universidad Católica del Ecuador

Santo Domingo de los Tsáchilas

Sede Santo Domingo

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 4 Santo Domingo De los Tsáchilas, PUCE SD

Contenido

Especificación de requisitos de software

FICHA DEL DOCUMENTO

3

CONTENIDO

4

1

6

INTRODUCCIÓN

1.1

Propósito

6

1.2

Alcance

6

1.3

Personal involucrado

7

1.4

Definiciones, acrónimos y abreviaturas

7

1.5

Referencias 8

1.6

Resumen 8

2

DESCRIPCIÓN GENERAL 8

2.1

Perspectiva del producto 8

2.2

Funcionalidad del producto

9

2.3

Características de los usuarios

9

2.4

Restricciones

10

2.5

Suposiciones y dependencias

10

2.6

Requerimientos Futuros

10

3

11

DESCRIPCIÓN GLOBAL

46

3.1 Requisitos comunes de las interfaces 3.1.1 Interfaces de usuario

46 3.1.2

46

Interfaces de hardware Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 5 3.1.3 3.1.4

Santo Domingo De los Tsáchilas, PUCE SD Interfaces de software Interfaces de comunicación

46 46

3.2

Requisitos funcionales Especificación de requisitos de software

46

3.3

Requisitos no funcionales

48

3.3.1 3.3.2 3.3.3 3.3.4

Requisitos de rendimiento Seguridad Fiabilidad Disponibilidad

3.3.5 3.3.6

Mantenibilidad Facilidad de Uso

49 48

Tiempo de Aprendizaje

49

3.3.6.1

48 48 48 48

3.3.6.2 de Elaboración de Presupuesto del Proyecto 3.3.7 Tiempo Portabilidad 3.3.8 Interfaces 3.3.8.1 Interfaces de Software

49 49 49

4

54

4.1

APÉNDICE

Historial de Cambios

54

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 6 Santo Domingo De los Tsáchilas, PUCE SD

1 Introducción

Especificación de requisitos de software

Este documento es una Especificación de Requisitos Software (ERS) para el Sistema de información para la gestión de procesos y control de inventarios. Esta especificación se ha estructurado basándose en las directrices dadas por el estándar IEEE Práctica Recomendada para Especificaciones de Requisitos Software ANSI/IEEE 830, 1998.

1.1

Propósito

Definir los requerimientos necesarios para el funcionamiento óptimo en cuanto a interfaces, sistema y soluciones del control de vehículos del GAD. También establece las pautas y actividades que deben desarrollarse para garantizar la calidad del producto a desarrollar. Para ello se indicará para cada actividad los atributos de Calidad relevante, los métodos de evaluación y los responsables.

El software, servirá para que la Gobierno Autónomo Descentralizado (GAD) lleve un control automatizado de la entrada y salida de vehículos del parqueadero. El sistema registrará la información de los vehículos, como es la placa, marca, además de la hora de ingreso y salida del estacionamiento, documentación pertinente con la aplicación web entre otros, este sistema se utilizara con un sistema biometría que ayudar para poder llevar un control más exacto de los datos del chofer y de los vehículos en su salida, es claro decir que la documentación se la llevara de mejor orden.

Como principal objetivo del sistema es la automatización del control, permitiendo de esta manera reducir el tiempo que normalmente se suele llevar haciéndolo de forma manual.

1.2

Alcance

El documento cubre la especificación de la entidad GAD cuya finalidad consiste en la automatización de las principales actividades que se desarrollan dentro del control de información y documentación de ingreso y salida de vehículos con sus respectivas órdenes. Entre las principales características del producto se encuentran: • • • • • • • •

Ingresar, modificar, consultar conductor Ingresar, modificar, consultar y eliminar vehículo Genera, modificar, eliminar y consultar orden de movilización Asignación Vehículo/Chofer se puede ingresar, modificar, consultar y eliminar Ingreso biométrico Historial biométrica Ingresar, modificar, consultar usuario Ingresar, modificar, consultar Solicitud vehículo Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 7 Santo Domingo De los Tsáchilas, PUCE SD

1.3

Personal involucrado Especificación de requisitos de software

Nombre Rol Categoría Profesional Responsabilidad

Francisco Arroyo Analista, diseñador y programador Estudiante Universitario Análisis de información, diseño y programación del

Información de contacto

Sistema faarroyol@pucesd.edu.ec

Nombre Rol Categoría Profesional Responsabilidad

Leonardo Mendoza Analista, diseñador y programador Estudiante Universitario Análisis de información, diseño y programación del

Información de contacto

Sistema xasotoe@pucesd.edu.ec

1.4

Definiciones, acrónimos y abreviaturas Nombre

Descripción

Usuario Persona que usará el sistema para gestionar procesos GAD Gobierno Autónomo Descentralizado ERS RF

Especificación de Requisitos Software Requerimiento Funcional

Herramientas CASE: Aplicaciones informáticas que nos permiten ayudar en todos los aspectos de ciclo de vida del software, en tareas como el proceso de realizar el diseño del proyecto, cálculo de costes, documentación, etc. Permite aumentar nuestra productividad en el desarrollo del mismo y reducir el coste en términos de tiempo y dinero.

Son aplicaciones software que respaldan el desarrollo y el mantenimiento del software.

Permiten comúnmente:      

Generación de Código.

Modelamiento de Datos.

Desarrollo mediante UML. Refactorización Administración de la Configuración Control de Revisión.

Data Base Management Systems – Gestores de Bases de Datos: Aplicaciones dedicadas a servir de interfaz entre las bases de datos, el usuario y las aplicaciones clientes que las utilizan. Se compone de un lenguaje de definición de datos, de un lenguaje de manipulación de datos y un lenguaje de consulta. El propósito de estas aplicaciones es de manejar de manera clara, sencilla y ordenada un conjunto de datos.

Entre estas tenemos:

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 8 Santo Domingo De los Tsáchilas, PUCE SD

  

1.5

Postgres Especificación de requisitos de software Oracle Sybase Mysql PostreSql

Referencias Título del Documento

Referencia

Standard IEEE 830 - 1998 IEEE PgAdmin Postgres 1. Documento de Visión del Proyecto 2. Documentos de Especificaciones de Casos de Uso 3. Modelo de desarrollo Cascada 4.

IS-1(2001) – Proyecto de Ingeniería de Software

5. IS-2 (2001) - Modelo de Calidad

1.6

Resumen

Este documento consta de tres secciones. En la primera sección se realiza una introducción al mismo y se proporciona una visión general de la especificación de recursos del sistema.

En la segunda sección del documento se realiza una descripción general del sistema, con el fin de conocer las principales funciones que éste debe realizar, los datos asociados y los factores, restricciones, supuestos y dependencias que afectan al desarrollo, sin entrar en excesivos detalles.

Por último, la tercera sección del documento es aquella en la que se definen detalladamente los requisitos que debe satisfacer el sistema.

2 Descripción general 2.1

Perspectiva del producto

El sistema será un producto diseñado para trabajar en entornos W EB, lo que permitirá su utilización de forma rápida y eficaz, manejara el área de administración, control y seguridad de datos.

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 9 Santo Domingo De los Tsáchilas, PUCE SD

2.2

Funcionalidad del producto Especificación de requisitos de software

2.3

Características de los usuarios

Tipo de usuario Formación Actividades

Administrador General TSU en Informática Control y manejo del sistema en general

Tipo de usuario Formación Actividades

Secretarios Digitador Digitador de datos del sistema

Tipo de usuario Formación Actividades

Guardia Digitador Participación activa en cursos y foros

Tipo de usuario Formación Actividades

Jefe del departamento Digitador Observa e indaga información y se preinscribe en los cursos Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 10 Santo Domingo De los Tsáchilas, PUCE SD

.

2.4

Restricciones        

Especificación de requisitos de software

Interfaz para ser usada con internet.

Uso de Dominio (X) Lenguajes y tecnologías en uso: HTML, JAVA, PHP, Postgres.

Los servidores deben ser capaces de atender consultas concurrentemente.

El sistema se diseñará según un modelo cliente/servidor.

El sistema deberá tener un diseño e implementación sencilla, independiente de la plataforma o del lenguaje de programación. el hardware de uso externo debe ser manipulable para los técnicos y no debe ser usado por personas no autorizadas.

Uso de personal estrictamente autorizado.

.

2.5

Suposiciones y dependencias



Se asume que los requisitos aquí descritos son estables



Los equipos en los que se vaya a ejecutar el sistema deben cumplir los requisitos antes indicados para garantizar una ejecución correcta de la misma En caso de falla del sistema se deben guiar en manuales de usuario y uso del sistema para mayor facilidad, en cuanto a la corrección de errores.

Se debe tener una fuente de energía para el biométrico y una persona encargada en el caso de que no exista conexión con el servidor para la toma de datos.

 

2.6

Requerimientos Futuros



Un biométrico adecuado para la salida de información de forma más rápida e implementar una fuente de energía externa en caso de algún apagón.



Se debe tener conexiones con el sistema sin latencia.

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 11 Santo Domingo De los Tsáchilas, PUCE SD

Especificación de requisitos de software 3 Descripción Global

Diagrama general de caso de uso

RF1. Login

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 12 Santo Domingo De los Tsáchilas, PUCE SD RF1.1 Ingreso Especificación de requisitos de software

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

ACTORES

PRECONDICIONES

INGRESO Requerimiento Funcional

N° REQUERIMIENTO

RF1.1.

los usuarios tendrán poner su usuarios y contraseñas al momento de logearse al sistema Administrador General, guardia, Secretario, Super Usuario

FRECUENCIA

Siempre

Los usuarios tienen que estar creados con sus respectivas contraseñas. los usuarios tienen que estar logueados al sistema de talento Humano del GAD Provincial

FLUJO NORMAL

ACCIÓN DEL ACTOR 1.

El actor hace clic en el botón que redirecciona al login del sistema 3. ingresa usuario y contraseña 4. hace clic en el botón ingresar

ACCIÓN DEL SISTEMA 2 Despliega la página para ingresar usuario y contraseña.

5. el sistema carga la información en el controlador 6. el controlador válida en la base de datos que el usuario y contraseña sea correcto 7. el controlador carga la información correspondiente del usuario desde la base de datos

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 13 Santo Domingo De los Tsáchilas, PUCE SD

FLUJO ALTERNATIVO

Especificación de requisitos de software ACCIÓN DEL ACTOR ACCIÓN DEL SISTEMA 7. en caso de no existir el usuario en la base de datos, el sistema muestra un mensaje diciendo error de usuario y contraseña

POSTCONDICIONES

El controlador despliega la página de inicio del sistema

FECHA CREACIÓN

10-nov-2015

TÉCNICO RESPONSABLE

Xavier Soto

FECHA IMPLEMENTACIÓN

15-dic-2015

RF2 Vehículo

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 14 Santo Domingo De los Tsáchilas, PUCE SD RF2.1. Ingreso Especificación de requisitos de software

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

PRECONDICIONES

FLUJO NORMAL

INGRESO Requerimiento Funcional

N° REQUERIMIENTO

RF2.1.

Los actores podrán ingresar vehículos al sistema.

Administrador General, Secretario, Súper Usuario

FRECUENCIA

Ocasionalmente

Los usuarios tienen que estar logeados al sistema de Talento Humano del GAD Provincial Los usuarios tienen que estar logeados al sistema.

ACCIÓN DEL ACTOR 1 el actor hace clic en el menú control 3. el actor hace clic en la opción Unidades y Conductores 6. hace clic en la opción vehículos 8. el actor selecciona agregar vehículo 10. Ingresa los datos específicos de los vehículos 11 el actor hace clic en guardar

ACCIÓN DEL SISTEMA 2. el controlador despliega el menú control 4 el controlador valida que tenga permisos para ingresar a Unidades y Conductores 5 el controlador carga la ventana de Unidades y Conductores 7. el controlador despliega la interfaz de vehículos 9. el controlador despliega la ventana modal para agregar vehículos 12 el controlador valida que la información ingresada cumpla con los requerimientos 13 el controlador guarda el registro

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 15 Santo Domingo De los Tsáchilas, PUCE SD

Especificación de requisitos de 14software el controlador cierra la ventana modal y nos redirecciona a la ventana de Vehículos con un mensaje que dice guardado exitoso FLUJO ALTERNATIVO

POSTCONDICIONES

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

13. el usuario hace el cambio respectivo de la información del Vehículo que estamos ingresando 14. el usuario hace clic en guardar

5. el controlador muestra un mensaje de error diciendo que no se tiene permisos 12. el controlador muestra un mensaje diciendo que la información no es correcta o que falta algún campo obligatorio en llenar 15 el controlador valida que la información ingresada cumpla con los requerimientos 16 el controlador guarda el registro 17 el controlador cierra la ventana modal y nos redirecciona a la ventana de Vehículos con un mensaje que dice guardado exitoso

En el sistema se almacena la información del vehículo

FECHA CREACIÓN

10-nov-2015

TÉCNICO RESPONSABLE

Xavier Soto

FECHA IMPLEMENTACIÓN

15-dic-2015

RF2.2. Modificación

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 16 Santo Domingo De los Tsáchilas, PUCE SD

Especificación de requisitos de software DESCRIPCIÓN DEL CASO DE USO NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN ACTORES

PRECONDICIONES

FLUJO NORMAL

FLUJO ALTERNATIVO

POSTCONDICIONES

FECHA CREACIÓN

MODIFICAR Requerimiento Funcional

N° REQUERIMIENTO

RF2.2.

Los actores podrán modificar vehículos al sistema.

Administrador General, Secretario, Súper Usuario

FRECUENCIA

Ocasionalmente

Los usuarios tienen que estar logeados al sistema de Talento Humano del Gad Provincial Los usuarios tienen que estar logeados al sistema.

El vehículo esté agregado al sistema.

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú control 3. el actor hace clic en la opción Unidades y Conductores 6. hace clic en la opción vehículo 8. hace clic en el botón editar dentro del registro del vehículo 10 modifica los datos del vehículo 11 el actor hace clic en la opción guardar

2. el controlador despliega el menú control 4 el controlador valida que tenga permisos para ingresar a Unidades y Conductores 5 el controlador carga la ventana de Unidades y Conductores 7. el controlador despliega la interfaz de vehículos 9. el controlador despliega la ventana modal para editar el vehículo 12.el controlador valida que los campos sean correctos 13. el controlador guarda el registro 14. el controlador cierra la ventana modal y refresca la interfaz de vehículos

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

El sistema muestra un mensaje diciendo que se ha ingresado correctamente la orden de movilización.

Sistema carga nuevamente el módulo de generación de orden de movilización, vacío.

10-nov-2015

FECHA IMPLEMENTACIÓN

15-dic-2015

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 17 Santo Domingo De los Tsáchilas, PUCE SD

TÉCNICO

Xavier Soto Especificación de requisitos de software

RESPONSABLE RF2.3. Eliminación Lógica

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

ACTORES

PRECONDICIONES

FLUJO NORMAL

Eliminación Lógica Requerimiento Funcional

N° REQUERIMIENTO

RF2.3.

Los actores tendrán la opción de hacer un eliminado lógico de la base de datos.

Administrador General, Secretario, Súper Usuario

FRECUENCIA

Ocasionalmente

Los usuarios tienen que estar logeados al sistema de Talento Humano del Gad Provincial Los usuarios tienen que estar logeados al sistema.

El vehículo este agregado ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú control 3. el actor hace clic en la opción Unidades y Conductores 6. hace clic en la opción

2. el controlador despliega el menú control 4 el controlador valida que tenga permisos para ingresar a Unidades y Conductores Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 18 Santo Domingo De los Tsáchilas, PUCE SD

Especificación de requisitos de vehículos 5 software el controlador carga la ventana de 8 el actor hace clic en la opción Unidades y Conductores eliminar vehículo 7. el controlador despliega la interfaz de vehículos 8. el controlador valida que el vehículo no tenga ninguna orden asignada valida 9. el controlador cambia el estado del vehículo a eliminado 10. el controlador refresca la interfaz de vehículo FLUJO ALTERNATIVO

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 5. el controlador muestra un mensaje de error diciendo que no se tiene permisos 9. el controlador muestra un mensaje diciendo que el vehículo no puede ser eliminado

POSTCONDICIONES

Dentro de la base de datos el campo de estado el vehículo debe cambiar a eliminado.

FECHA CREACIÓN

10-nov-2015

TÉCNICO RESPONSABLE

Xavier Soto

FECHA IMPLEMENTACIÓN

15-dic-2015

RF2.4. Consultas

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 19 Santo Domingo De los Tsáchilas, PUCE SD

Especificación requisitos de USO software DESCRIPCIÓNde DEL CASO DE NOMBRE

INGRESO

TIPO REQUERIEMIENTO DESCRIPCIÓN ACTORES

PRECONDICIONES

Requerimiento Funcional

RF2.4.

Los actores podrán consultar todos los vehículos.

Administrador General, Secretario, Súper Usuario

FRECUENCIA

Ocasionalmente

Los usuarios tienen que estar logeados al sistem a de Talento Humano del Gad Provincial Los usuarios tienen que estar logeados al sistema.

FLUJO NORMAL

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú control 3. el actor hace clic en la opción Unidades y Conductores 6. hace clic en la opción vehículos 8 el actor comienza a escribir en la opción buscar

2. el controlador despliega el menú control 4 el controlador valida que tenga permisos para ingresar a Unidades y Conductores 5 el controlador carga la ventana de Unidades y Conductores 7. el controlador despliega la interfaz de vehículos 9. el controlador va mostrando los vehículos que tengan en sus campos información similar a la que el conductor va escribiendo

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

FLUJO ALTERNATIVO

POSTCONDICIONES

N° REQUERIMIENTO

.

FECHA CREACIÓN

10-nov-2015

TÉCNICO RESPONSABLE

Xavier Soto

FECHA IMPLEMENTACIÓN

15-dic-2015

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 20 Santo Domingo De los Tsáchilas, PUCE SD RF3.Custodia Especificación de requisitos de software

F3.1. Ingreso

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

INGRESO Requerimiento Funcional

N° REQUERIMIENTO

RF3.1.

Los actores podrán generar una custodia

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 21 Santo Domingo De los Tsáchilas, PUCE SD

ACTORES

PRECONDICIONES

FLUJO NORMAL

FLUJO ALTERNATIVO

Especificación de requisitos de software FRECUENCIA Administrador General, Secretario, Súper Usuario

ocasionalmente

Los usuarios tienen que estar creados con sus respectivas contraseñas. los usuarios tienen que estar logueados al sistema de talento Humano del Gad Provincial ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú control 3. el actor hace clic en la opción Custodias 6 el actor hace clic en nueva custodia 9. el actor selecciona al conductor y vehículo disponibles para asignar custodia 10 ingresa el detalle de la custodia 11 hace clic en la opción guardar registro

2. el controlador despliega el menú control 4. el controlador valida que tenga permisos de ingresar a custodia 5 el controlador despliega la interfaz de custodia 7 el controlador busca los vehículos y conductores que no tengan custodia en la base de datos 8 el controlador muestra la ventana modal para ingresa la custodia 12 el controlador valida que los datos sean correctos 13. el controlador guarda el registro 14 el controlador cierra la ventana modal 15. el controlador refresca la interfaz de custodia

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 5 controlador muestra un mensaje de error al no poseer permisos 13 el controlador muestra un mensaje de error diciendo que los datos no son válidos .

POSTCONDICIONES

En la base de datos, se almacena el registro de la nueva custodia

FECHA CREACIÓN

10-nov-2015

TÉCNICO RESPONSABLE

Xavier Soto

FECHA IMPLEMENTACIÓN

15-dic-2015

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 22 Santo Domingo De los Tsáchilas, PUCE SD F3.2. Modificación Especificación de requisitos de software

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

PRECONDICIONES

FLUJO NORMAL

Modificación Requerimiento Funcional

N° REQUERIMIENTO

RF3.2.

El usuario podrá hacer el cambio temporal de la custodia.

Administrador General, Secretario, Súper Usuario

FRECUENCIA

rara vez

Los usuarios tienen que estar creados con sus respectivas contraseñas. los usuarios tienen que estar logueados al sistema de talento Humano del Gad Provincial ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú control 3. el actor hace clic en la opción Custodias 6 el actor hace clic en modificar custodia 8 el actor selecciona que campo de la custodia quiere modifica.

10 el actor selecciona una opción de las múltiples que se le van a dar para editar ese campo 11 el actor le da a guardar

2. el controlador despliega el menú control 4. el controlador valida que tenga permisos de ingresar a custodia 5 el controlador despliega la interfaz de custodia 7 el controlador carga la ventana modal para modificar la custodia 9 la ventana modal carga

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 23 Santo Domingo De los Tsáchilas, PUCE SD

Especificación de requisitos de software todas las opciones disponibles para ese campo 12 el controlador guarda la información en los campos designados para eso.

13 el controlador cambia el estado a custodia temporal 14 el controlador recarga la interfaz de custodia FLUJO ALTERNATIVO

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 5 controlador muestra un mensaje de error al no poseer permisos .

POSTCONDICIONES

Mientras la custodia esté en estado temporal todas las órdenes de salida que se generen tendrán la información de los datos temporales

FECHA CREACIÓN

10-nov-2015

TÉCNICO RESPONSABLE

Xavier Soto

FECHA IMPLEMENTACIÓN

15-dic-2015

RF3.3. Eliminación Lógica

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 24 Santo Domingo De los Tsáchilas, PUCE SD

Especificación requisitos de USO software DESCRIPCIÓNde DEL CASO DE NOMBRE TIPO REQUERIMIENTO DESCRIPCIÓN ACTORES

PRECONDICIONES FLUJO NORMAL

FLUJO ALTERNATIVO

ELIMINACIÓN LÓGICA Requerimiento Funcional

N° REQUERIMIENTO

RF3.3.

La custodia de los usuarios serán eliminados del sistema Administrador General, Secretario, Súper Usuario

FRECUENCIA

Siempre

Las custodias de los usuarios tienen que estar creados en el sistema para poder ser eliminados.

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1. El actor hace clic en el botón de menú de control 3. El actor hace clic en custodia 6. El actor se dirige al final de la tabla de cada custodia donde estará el botón eliminar 7. El actor da clic en el botón eliminar 10.El actor responde si al mensaje de si desea eliminar la custodia

2 El sistema despliega el menú custodia 4.El controlador valida si hay permisos para entrar a la custodia 5. el sistema carga la información de las custodias en la nueva interfaz desplegando las opciones para trabajar sobre cada custodia 8. el controlador válida en la base de datos la información de la custodia que va a eliminar 9. el sistema carga en una ventana de aviso de si desea eliminar la custodia 11. ventana de confirmación de que se ha eliminado la custodia

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA Eliminará el registro y llevará un registro histórico

POSTCONDICIONES

FECHA CREACIÓN

TÉCNICO RESPONSABLE

Se elimina la custodia y no aparecen en la tabla custodia nuevamente, se eliminará del sistema. Se lleva registro histórico de lo eliminado.

10-nov-2015

FECHA IMPLEMENTACIÓN

15-dic-2015

Francisco Arroyo

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 25 Santo Domingo De los Tsáchilas, PUCE SD

RF3.4. Consultas

Especificación de requisitos de software

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

PRECONDICIONES

FLUJO NORMAL

FLUJO

Consulta Requerimiento Funcional

N° REQUERIMIENTO

RF3.4.

se podrá consultar todos las custodias generadas Administrador General, Secretario, Súper Usuario

FRECUENCIA

Ocasionalmente

Los usuarios tienen que estar creados con sus respectivas contraseñas. los usuarios tienen que estar logueados al sistema de talento Humano del Gad Provincial ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú control 3. el actor hace clic en la opción Custodias 6 el actor tipea los datos que desea buscar

2. el controlador despliega el menú control 4. el controlador valida que tenga permisos de ingresar a custodia 5 el controlador despliega la interfaz de custodia 7 el controlador paralelamente va todas las custodias que tengan esa esa información

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 26 Santo Domingo De los Tsáchilas, PUCE SD

ALTERNATIVO

Especificación de requisitos de software muestra un mensaje de 5 controlador error al no poseer permisos

POSTCONDICIONES FECHA CREACIÓN

10-nov-2015

TÉCNICO RESPONSABLE

Xavier Soto

FECHA IMPLEMENTACIÓN

15-dic-2015

RF4 Orden de Salida

RF4.1 Ingreso

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 27 Santo Domingo De los Tsáchilas, PUCE SD

Especificación requisitos deUSO software DESCRIPCIÓNde DEL CASO DE NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN ACTORES

PRECONDICIONES FLUJO NORMAL

FLUJO ALTERNATIVO

INGRESAR Requerimiento Funcional

N° REQUERIMIENTO

RF4.1

Los actores podrán generar una orden de salida Administrador General, Secretario, Super Usuario

FRECUENCIA

Diaria

Los actores tienen que estar creados con sus respectivas contraseñas.

Debe existir una custodia previamente de chofer y vehículo.

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú control 3. el actor hace clic en la opción Orden de Salida 6 el actor da clic en Nueva orden de salida 8. el actor selecciona los datos de la custodia a la cual se le va a generar la orden de salida 10. el usuario Guarda la orden de salida

2. el controlador despliega el menú control 4. el controlador valida que tenga permisos de ingresar a Orden de Salida 5 el controlador despliega la interfaz de Orden de salida 7 el controlador presenta una nueva interfaz para el ingreso de una nueva orden de salida donde se desplegaran campos a llenar 9. El controlador valida los datos de la orden en caso de no ser Completados, presentará un mensaje.

10. el controlador agrega la orden de salida en la base

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 9. controlador muestra un mensaje de error al no validarse todo los campos 10. implementa en la base de tos

POSTCONDICIONES FECHA CREACIÓN

TÉCNICO RESPONSABLE

10-nov-2015

FECHA IMPLEMENTACIÓN

15-dic-2015

Francisco Arroyo

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 28 Santo Domingo De los Tsáchilas, PUCE SD

RF4.2 Modificación Especificación de requisitos de software

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

PRECONDICIONES

FLUJO NORMAL

Modificación Requerimiento Funcional

N° REQUERIMIENTO

RF4.2

Se modifica el destino de la orden de Salida Administrador General, Secretario, Súper Usuario

FRECUENCIA

Ocasionalmente

Los usuarios tienen que estar creados con sus respectivas contraseñas. los usuarios tienen que estar logueados al sistema de talento Humano del Gad Provincial ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú control 3. el actor hace clic en la opción Orden de Salida 6 el actor hace clic en el botón editar Orden de Salida 8. el actor llena los datos a ser modificados

2. el controlador despliega el menú control 4. el controlador valida que tenga permisos de ingresar a Orden de Salida 5 el controlador despliega la interfaz de Orden de Salida 7 el controlador despliega la ventana modal de la Orden de Salida 9. el controlador valida los datos 10 el controlador guarda el registro 11 el controlador refresca la interfaz de orden de salida.

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 29 Santo Domingo De los Tsáchilas, PUCE SD

Especificación de requisitos de software FLUJO ALTERNATIVO

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 5 controlador muestra un mensaje de error al no poseer permisos 10 el controlador envía un mensaje diciendo que los datos almacenados no son correctos

POSTCONDICIONES

Se almacena en la base de datos la información del registro modificado

FECHA CREACIÓN

10-nov-2015

TÉCNICO RESPONSABLE

Xavier Soto

FECHA IMPLEMENTACIÓN

15-dic-2015

RF4.3 Eliminación Lógica

DESCRIPCIÓN DEL CASO DE USO NOMBRE

Eliminación lógica

TIPO REQUERIEMIENTO

Requerimiento Funcional

DESCRIPCIÓN ACTORES

N° REQUERIMIENTO

RF4.3

Se realiza la eliminación de la orden de salida Administrador General, Secretario, Súper Usuario

FRECUENCIA

Ocasionalmente

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 30 Santo Domingo De los Tsáchilas, PUCE SD

PRECONDICIONES FLUJO NORMAL

de requisitos de software DebeEspecificación existir una custodia para poder ser adjudicada a una orden de salida.

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú control 3. el actor hace clic en la opción Orden de Salida 6 el actor hace clic en el botón eliminar Orden de Salida 8. el actor da clic en eliminar

2. el controlador despliega el menú control 4. el controlador valida que tenga permisos de ingresar a Orden de Salida 5 el controlador despliega la interfaz de Orden de Salida 7 el controlador despliega la ventana modal de si desea eliminar la orden de salida 9. el controlador valida los datos 10 el controlador elimina la orden de salida.

11 el controlador refresca la interfaz de orden de salida.

FLUJO ALTERNATIVO

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 5 controlador muestra un mensaje de error al no poseer permisos

POSTCONDICIONES

FECHA CREACIÓN

TÉCNICO RESPONSABLE

Se eliminará la orden de salida de la interfaz, no constara en la base pero si en un historial.

10-nov-2015

FECHA IMPLEMENTACIÓN

15-dic-2015

Francisco Arroyo

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 31 Santo Domingo De los Tsáchilas, PUCE SD RF4.4 Consulta Especificación de requisitos de software

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

PRECONDICIONES

FLUJO NORMAL

Consulta Requerimiento Funcional

N° REQUERIMIENTO

RF4.4.

se podrá consultar todas las Orden de Salida generadas Administrador General, Secretario, Super Usuario

FRECUENCIA

Ocasionalmente

Los usuarios tienen que estar creados con sus respectivas contraseñas. los usuarios tienen que estar logueados al sistema de talento Humano del Gad Provincial ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú control 3. el actor hace clic en la opción Orden de Salida 6 el actor tipea los datos que desea buscar

2. el controlador despliega el menú control 4. el controlador valida que tenga permisos de ingresar a Orden de Salida 5 el controlador despliega la interfaz de Orden de Salida 7 el controlador paralelamente va

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 32 Santo Domingo De los Tsáchilas, PUCE SD

Especificación de requisitos de software todas las custodias que tengan esa esa información FLUJO ALTERNATIVO

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 5 controlador muestra un mensaje de error al no poseer permisos

POSTCONDICIONES FECHA CREACIÓN

10-nov-2015

TÉCNICO RESPONSABLE

Xavier Soto

FECHA IMPLEMENTACIÓN

15-dic-2015

RF5 Registro Diario

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 33 Santo Domingo De los Tsáchilas, PUCE SD

RF5.1 Ingreso

Especificación de requisitos de software

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

PRECONDICIONES

FLUJO NORMAL

Ingreso Requerimiento Funcional

N° REQUERIMIENTO

RF5.1

un nuevo registro Diario de un vehículo Administrador General, Guardia, Secretario, Super Usuario

FRECUENCIA

Siempre

Los usuarios tienen que estar creados con sus respectivas contraseñas. los usuarios tienen que estar logueados al sistema de talento Humano del Gad ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú control 3. el actor hace clic en la opción Registro de Movimientos 6 el actor hace clic en nuevo Registro de Movimientos 8 el actor selecciona el número de orden de la cual se va a crear el nuevo registro 9 llena los datos del registro 10 el actor le da al botón guardar

2. el controlador despliega el menú control 4. el controlador valida que tenga permisos de ingresar a Registro de Movimientos 5 el controlador despliega la interfaz de Registro de Movimientos 7 el controlador despliega la ventana modal del registro de movimiento 11 el controlador valida los

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 34 Santo Domingo De los Tsáchilas, PUCE SD

Especificación de requisitos de software datos a ingresar 12 el controlador almacena la información 13 el refresca la interfaz FLUJO ALTERNATIVO

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 5 controlador muestra un mensaje de error al no poseer permisos 12 el controlador envía un mensaje diciendo que no se puede crear el registro

POSTCONDICIONES

Se almacena dentro de la base de datos la información del registro

FECHA CREACIÓN

10-nov-2015

TÉCNICO RESPONSABLE

Xavier Soto

FECHA IMPLEMENTACIÓN

15-dic-2015

RF5.2 Modificación

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 35 Santo Domingo De los Tsáchilas, PUCE SD DESCRIPCIÓN DEL CASO DE USO NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN ACTORES

PRECONDICIONES

FLUJO NORMAL

FLUJO ALTERNATIVO

Especificación de requisitos de software Modificación Requerimiento Funcional

N° REQUERIMIENTO

RF5.2

Se podrá modificar la información de un registro diario Administrador General, Guardia, Secretario, Super Usuario

FRECUENCIA

Siempre

Los usuarios tienen que estar creados con sus respectivas contraseñas. los usuarios tienen que estar logueados al sistema de talento Humano del Gad Provincial El registro no debe ser aprobado todavía ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú control 3. el actor hace clic en la opción Registro de Movimientos 6 el actor hace clic en botón modificar del registro 8 el actor modifica la información del registro 9 el actor hace clic en la opción guardar

2. el controlador despliega el menú control 4. el controlador valida que tenga permisos de ingresar a Registro de Movimientos 5 el controlador despliega la interfaz de Registro de Movimientos 7 el controlador despliega la ventana modal del registro de movimiento 10 el controlador valida los datos a ingresar 11 el controlador almacena la información 12 el controlador cierra la ventana modal 13 el refresca la interfaz de Registro de Movimientos

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 5 controlador muestra un mensaje de error al no poseer permisos 11 el controlador muestra un mensaje de error diciendo que los datos a almacenar son inválidos

POSTCONDICIONES

se almacenan la información en la base de datos con un estado temporal hasta ser validada con el biométrico y aceptada por un usuario distinto

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 36 Santo Domingo De los Tsáchilas, PUCE SD FECHA CREACIÓN

10-nov-2015

FECHA IMPLEMENTACIÓN Especificación de requisitos de software

TÉCNICO RESPONSABLE

Xavier Soto

15-dic-2015

RF5.3 Eliminación Lógica

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

PRECONDICIONES

FLUJO NORMAL

Eliminación Lógico Requerimiento Funcional

N° REQUERIMIENTO

RF5.3

se podrá eliminar los registros de movilización Administrador General, Secretario, Super Usuario

FRECUENCIA

Ocasionalmente

Los usuarios tienen que estar creados con sus respectivas contraseñas. los usuarios tienen que estar logueados al sistema de talento Humano del Gad Provincial El registro no debe ser aprobado todavía ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú 2. el controlador despliega el menú control control 3. el actor hace clic en la opción 4. el controlador valida que tenga

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 37 Santo Domingo De los Tsáchilas, PUCE SD

Especificación de requisitos de software Registro de movilización permisos de ingresar a Registro de 6 El actor da clic en el botón movilización eliminar 5 el controlador despliega la interfaz 8.El actor da clic en eliminar de Orden de movilización 7 el controlador despliega ventana modal de si desea eliminar Registro de movilización 9.el controlado valida los datos 10.el controlador elimina el registro de movilización 11.el controlador refresca la interfaz de orden de salida FLUJO ALTERNATIVO

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 5 controlador muestra un mensaje de error al no poseer permisos

POSTCONDICIONES

FECHA CREACIÓN

TÉCNICO RESPONSABLE

Se elimina la información en la base de datos con un estado eliminado, estos son llevados con un registro histórico.

10-nov-2015

FECHA IMPLEMENTACIÓN

15-dic-2015

Francisco Arroyo

RF5.4 Consulta

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 38 Santo Domingo De los Tsáchilas, PUCE SD

DESCRIPCIÓNde DEL CASO DE Especificación requisitos de USO software NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN

ACTORES

PRECONDICIONES

FLUJO NORMAL

FLUJO ALTERNATIVO

Consulta Requerimiento Funcional

N° REQUERIMIENTO

RF5.4

se podrá consultar todos los casos de movilización , tomando como dato principal la orden de movilización Administrador General, Secretario, Super Usuario

FRECUENCIA

Ocasionalmente

Los usuarios tienen que estar creados con sus respectivas contraseñas. los usuarios tienen que estar logueados al sistema de talento Humano del Gad Provincial ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú control 3. el actor hace clic en la opción Registro de movilización 6 el actor tipea los datos que desea buscar

2. el controlador despliega el menú control 4. el controlador valida que tenga permisos de ingresar a Registro de Movilización 5 el controlador despliega la interfaz de Registro de movilización 7 el controlador paralelamente va todas los Registro de movilización que tengan esa esa información

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 5 controlador muestra un mensaje de error al no poseer permisos

POSTCONDICIONES FECHA CREACIÓN

TÉCNICO RESPONSABLE

10-nov-2015

FECHA IMPLEMENTACIÓN

15-dic-2015

Francisco Arroyo

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 39 Santo Domingo De los Tsáchilas, PUCE SD RF6 Usuario Especificación de requisitos de software

RF6.1 Ingreso

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

Ingreso Requerimiento Funcional

N° REQUERIMIENTO

RF6.1

Se podrá ingresar (Crear) usuarios, asignar un rol predefinido.

Super Usuario

FRECUENCIA

Ocasionalmente

PRECONDICIONES FLUJO NORMAL

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú 2. el controlador despliega el menú administración administración

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 40 Santo Domingo De los Tsáchilas, PUCE SD

delarequisitos de el software 3. el Especificación actor hace clic en opción 4. controlador valida que tenga Usuarios permisos de ingresar Usuarios 6 el actor tipea los datos que 5 el controlador despliega la interfaz de desea buscar custodia 7 el controlador paralelamente va todas las custodias que tengan esa esa información FLUJO ALTERNATIVO

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 5 controlador muestra un mensaje de error al no poseer permisos

POSTCONDICIONES FECHA CREACIÓN

10-nov-2015

TÉCNICO RESPONSABLE

Xavier Soto

FECHA IMPLEMENTACIÓN

15-dic-2015

RF6.2 Modificación ++

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

Modificación Requerimiento Funcional

N° REQUERIMIENTO

RF6.2

el usuario puede modificar los permisos y características del usuario Super Usuario

FRECUENCIA

Ocasionalmente

PRECONDICIONES FLUJO NORMAL

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú Administración

2. el controlador despliega el menú Administración Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 41 Santo Domingo De los Tsáchilas, PUCE SD

3. elEspecificación actor hace clicde enrequisitos la opción de4.software el controlador valida que tenga Usuarios permisos de ingresar a Usuarios 6 el actor hace clic en el botón 5 el controlador despliega la interfaz editar del menú del usuario de Usuarios 8 el actor edita los datos 7 el controlador despliega la ventana 9 el actor hace clic en guardar modal para editar los datos del usuario 10 el controlador valida los datos 11 el controlador guarda la información 12 el controlador cierra la ventana modal 13 el controlador refresca la interfaz de usuario FLUJO ALTERNATIVO

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 5 controlador muestra un mensaje de error al no poseer permisos

POSTCONDICIONES

se debe almacenar en la base de datos los cambios en los permios

FECHA CREACIÓN

10-nov-2015

TÉCNICO RESPONSABLE

Xavier Soto

FECHA IMPLEMENTACIÓN

15-dic-2015

RF6.3 Eliminación Lógica

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 42 Santo Domingo De los Tsáchilas, PUCE SD DESCRIPCIÓN DEL CASO DE USO NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN

ACTORES PRECONDICIONES

FLUJO NORMAL

FLUJO ALTERNATIVO

Eliminación Lógica de requisitos de software Especificación Requerimiento Funcional

N° REQUERIMIENTO

RF6.3

se podrá eliminar el usuario

Super Usuario

FRECUENCIA

Ocasionalmente

Los usuarios tienen que estar creados con sus respectivas contraseñas. los usuarios tienen que estar logueados al sistema de talento Humano del Gad Provincial ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú Administración 3. el actor hace clic en la opción Usuarios 6 el actor hace clic en el botón eliminar del menú del usuario 8 el actor acepta para eliminar

2. el controlador despliega el menú Administración 4. el controlador valida que tenga permisos de ingresar a Usuarios 5 el controlador despliega la interfaz de Usuarios 7 el controlador despliega la ventana modal para eliminar los datos del usuario 9 el controlador guarda el cambio de estado 10 el controlador cierra la venta modal

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 5 controlador muestra un mensaje de error al no poseer permisos

POSTCONDICIONES

se cambia el estado del usuario dentro de la base de datos

FECHA CREACIÓN

10-nov-2015

TÉCNICO RESPONSABLE

Xavier Soto

FECHA IMPLEMENTACIÓN

15-dic-2015

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 43 Santo Domingo De los Tsáchilas, PUCE SD

RF6.4 Consulta

Especificación de requisitos de software

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

FLUJO NORMAL

FLUJO ALTERNATIVO

Consulta Requerimiento Funcional

N° REQUERIMIENTO

RF6.4

se podrá consultar todos las custodias generadas Super Usuario

FRECUENCIA

Ocasionalmente

Los usuarios tienen que estar creados con sus respectivas contraseñas. los usuarios tienen que estar logueados al sistema de talento Humano del Gad Provincial ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú Administración 3. el actor hace clic en la opción Usuarios 6 el actor tipea los datos que desea buscar

2. el controlador despliega el menú Administración 4. el controlador valida que tenga permisos de ingresar a Usuarios 5 el controlador despliega la interfaz de Usuarios 7 el controlador paralelamente va mostrando todos las Usuarios que tengan esa esa información

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 5 controlador muestra un mensaje de error al no poseer permisos

POSTCONDICIONES FECHA CREACIÓN

10-nov-2015

FECHA IMPLEMENTACIÓN

15-dic-2015

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 44 TÉCNICO

Santo Domingo De los Tsáchilas, PUCE SD Xavier Soto

RESPONSABLE Especificación de requisitos de software RF7 Tabla Persona

RF7.1 Actualización

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 45 Santo Domingo De los Tsáchilas, PUCE SD DESCRIPCIÓN DEL CASO DE USO NOMBRE TIPO REQUERIEMIENTO DESCRIPCIÓN ACTORES

PRECONDICIONES

FLUJO NORMAL

FLUJO ALTERNATIVO

Actualización Especificación de requisitos de software Requerimiento Funcional

N° REQUERIMIENTO

RF3.4.

se podrá actualizar los datos en la tabla persona Administrador General, Secretario, Super Usuario

FRECUENCIA

Ocasionalmente

Los usuarios tienen que estar creados con sus respectivas contraseñas. los usuarios tienen que estar logueados al sistema de talento Humano del Gad Provincial ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA

1 el actor hace clic en el menú control 3. el actor hace clic en la opción Custodias 6 el actor tipea los datos que desea buscar

2. el controlador despliega el menú control 4. el controlador valida que tenga permisos de ingresar a custodia 5 el controlador despliega la interfaz de custodia 7 el controlador paralelamente va todas las custodias que tengan esa esa información

ACCIÓN DEL ACTOR

ACCIÓN DEL SISTEMA 5 controlador muestra un mensaje de error al no poseer permisos

POSTCONDICIONES FECHA CREACIÓN

10-nov-2015

TÉCNICO RESPONSABLE

Xavier Soto

FECHA IMPLEMENTACIÓN

15-dic-2015

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 46 Santo Domingo De los Tsáchilas, PUCE SD

3.1

Requisitos comunes de las interfaces

.

Especificación de requisitos de software

3.1.1

Interfaces de usuario

La interfaz con el usuario consistirá en un conjunto de ventanas con botones, listas y campos de textos. Ésta deberá ser construida específicamente para el sistema propuesto y, será visualizada desde un navegador de internet.

3.1.2

Interfaces de hardware

Será necesario disponer de equipos de cómputos en perfecto estado con las siguientes características:     

3.1.3  

3.1.4

Adaptadores de red.

Procesador de 1.66GHz o superior.

Memoria mínima de 256Mb. Mouse.

Teclado.

Interfaces de software Sistema Operativo: W indows XP o superior.

Explorador: Mozilla o Chrome.

Interfaces de comunicación

Los servidores, clientes y aplicaciones se comunicarán entre sí, mediante protocolos estándares en internet, siempre que sea posible. En caso de la comunicación del biométrico se podrá tener que extraer la información del biométrico y debe ser ingresado por el guardia o algún personal autorizado del ingreso de datos en el sistema.

3.2

Requisitos funcionales

• Ingresar conductor 

En este se detallaran todo lo que es el ingreso de los datos del conductor, tendrá todo los datos que tiene la licencia y también la información del área donde labora.

• Modificar conductor 

Se puede hacer la modificación de los datos del conductor

• Consultar conductor  Se puede ver los datos que tiene el chofer para un análisis.

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 47 Santo Domingo De los Tsáchilas, PUCE SD • Genera orden de movilización 

Especificación requisitos de de software En este se detallaran todo eldedocumento movilización del conductor con su respectivo chofer y su técnico encargado.

• Modificar movilización 

Se puede hacer la modificación de los datos de la movilización.

• Consultar movilización 

Se puede ver los datos que tiene la movilización.

• Ingresar vehículo 

En este se detallaran todo lo que es el ingreso de los datos del vehículo, tendrá todo los datos que tiene la matrícula y también la información del área donde labora.

• Modificar vehículo 

Se puede hacer la modificación de los datos del vehículo

• Consultar vehículo 

Se puede ver los datos que tiene el vehículo para un análisis.

• Ingresar Asignación Vehículo/Chofer   

En este se detallaran todo la asignación del vehículo y el chofer.

Modificar Vehículo/Chofer Se puede hacer la modificación de los datos del vehículo/chofer.

• Consultar Vehículo/Chofer 

Se puede ver los datos que tiene el chofer y el vehículo para un análisis.

• Ingreso biométrico 

Se ingresa los datos del chofer en el dispositivo biométrico y se validan en la base de datos.

• Historial biométrica 

Se puede ver el historial de los choferes.

• Ingresar, modificar, consultar usuario  Se pueden hacer los procesos principales y tener sesiones para los usuarios independientemente y saber cómo trabajan.

• Ingresar, modificar, consultar Solicitud vehículo Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 48 Santo Domingo De los Tsáchilas, PUCE SD



Se pueden hacer los procesos principales y tener los datos de solicitud de vehículo Especificación de requisitos de software mediante los anteriores ingresos de datos ya expuestos como vehículo y chofer.

3.3

Requisitos no funcionales 3.3.1 Requisitos de rendimiento



Garantizar que el diseño de las consultas u otro proceso no afecte el desempeño de la base de datos, ni considerablemente el tráfico de la red.

3.3.2 Seguridad 

Garantizar la confiabilidad, la seguridad y el desempeño del sistema informático a los diferentes usuarios. En este sentido la información almacenada o registros realizados podrán ser consultados y actualizados permanente y simultáneamente, sin que se afecte el tiempo de respuesta.



Garantizar la seguridad del sistema con respecto a la información y datos que se manejan tales sean documentos, archivos y contraseñas.



Facilidades y controles para permitir el acceso a la información al personal autorizado a través de Internet, con la intención de consultar y subir información pertinente para cada una de ellas.

3.3.3 Fiabilidad 

El sistema debe tener una interfaz de uso intuitiva y sencilla



La interfaz de usuario debe ajustarse a las características de la web de la institución, dentro de la cual estará incorporado el sistema de gestión de procesos y el inventario

3.3.4 Disponibilidad 

La disponibilidad del sistema debe ser continua con un nivel de servicio para los usuarios de 7 días laborables, garantizando un esquema adecuado que permita la posible falla en cualquiera de sus componentes, contar con una contingencia, generación de alarmas.

3.3.5 Mantenibilidad 

El sistema debe disponer de una documentación fácilmente actualizable que permita realizar operaciones de mantenimiento con el menor esfuerzo posible



La interfaz debe estar complementada con un buen sistema de ayuda (la administración puede recaer en personal con poca experiencia en el uso de aplicaciones informáticas).

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 49 Santo Domingo De los Tsáchilas, PUCE SD

3.3.6 Facilidad de Uso Especificación de requisitos de software

3.3.6.1 Tiempo de Aprendizaje 

No se ha establecido ningún curso de aprendizaje, solo se contará con un manual de uso.

3.3.6.2 

Tiempo de Elaboración de Presupuesto del Proyecto

A través del sistema, se reducirá el tiempo de planeación de procesos manuales que realizan en el GAD en cuanto al ingreso y salida de datos de vehículos, se prevé que se puede agilitar procesos en un 95% de estos, este proyecto se forma con un tiempo de avance que es de 10 meses en generar.

3.3.7 Portabilidad 

El sistema será implantado bajo la plataforma de Windows.

3.3.8 Interfaces 3.3.8.1

Interfaces de Software

PROTOTIPO

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 50 Santo Domingo De los Tsáchilas, PUCE SD

Especificación de requisitos de software

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 51 Santo Domingo De los Tsáchilas, PUCE SD

Especificación de requisitos de software

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 52 Santo Domingo De los Tsáchilas, PUCE SD

Especificación de requisitos de software

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 53 Santo Domingo De los Tsáchilas, PUCE SD

Especificación de requisitos de software

Descripción de requisitos del sofware

Sistema Web para la Gestión interna de Vehículos en el GAD Provincial de Pág. 54 Santo Domingo De los Tsáchilas, PUCE SD

Especificación de requisitos de software

4 Apéndice 4.1

Historial de Cambios

Fecha

Versión

Descripción

Autor

27/01/2015

0.1

Creación

Arroyo Francisco y Xavier

25/05/2016

0.2

Arroyo Francisco y Xavier

27/05/2016

0.3

Cambio en el diseño general, nuevas especificaciones Estructuración de Graficas

27/05/2016

0.4

Restructuración de Formato

Arroyo Francisco y Xavier

Arroyo Francisco y Xavier

Descripción de requisitos del sofware

74

ANEXO 4. Fase de Planificaciรณn

75

76

77

ANEXO 5. Fase de Diseño

74

ESPECIFICACIONES DEL DISEÑO DE SOFTWARE (SDS)

Francisco Arroyo y Xavier Soto PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR 15 de agosto del 2016

75

Contenido Diagrama físico de la base de datos ........................................................................................... 1 Diagrama lógico de la base de datos .......................................................................................... 2 Prototipos de interfaces .............................................................................................................. 3 Prototipo de interfaz para el menú administrador- usuarios ...................................................... 3 Prototipo de la interfaz administración-sistema......................................................................... 4 Prototipo de interfaz control-vehículos ...................................................................................... 5 Prototipo para la generación de informes .................................................................................. 7 Prototipo para el despacho de combustible ................................................................................ 7 Diagramas de secuencia ............................................................................................................. 9 Diagrama de secuencia para la inserción de una custodia ......................................................... 9 Diagrama de secuencia para la inserción de una orden ........................................................... 10 Diagrama de secuencia para el ingreso de un registro diario ................................................... 11

1

Diagrama fĂ­sico de la base de datos

2

Diagrama lรณgico de la base de datos

3

Prototipos de interfaces Prototipo de interfaz para el menĂş administrador- usuarios

4

Prototipo de la interfaz administraciรณn-sistema

5

Prototipo de interfaz control-vehĂ­culos

Prototipo de interfaz control-custodia

6

7

Prototipo para la generaciรณn de informes

Prototipo para el despacho de combustible

8

9

Diagramas de secuencia Diagrama de secuencia para la inserciรณn de una custodia

10

Diagrama de secuencia para la inserciรณn de una orden

11

Diagrama de secuencia para el ingreso de un registro diario

Firma de aprobación del SDS

______________________

_______________________

Ing. Pablo Guillén Director de Tecnologías

Ing. Ángel Chela Analista de Tecnologías

78

ANEXO 6: Fase de Codificaciรณn

79

Constructor de la clase ConnectDB

80

ANEXO 7. Fase de prueba

1

Plan de Pruebas de Software Desarrollo web para la gestión interna de vehículos del Gad Provincial de Santo Domingo de los Tsáchilas Fecha: 14/08/2016

2

Tabla de contenido Historial de Versiones .............................................................................................................3 Información del Proyecto ........................................................................................................3 Aprobaciones .......................................................................................................................... 3 Resumen Ejecutivo ................................................................................................................. 4 Alcance de las Pruebas............................................................................................................4 Elementos de Pruebas .............................................................................................................4 Nuevas Funcionalidades a Probar ........................................................................................... 4 Pruebas de Regresión ..............................................................................................................4 Funcionalidades a No Probar ..................................................................................................4 Enfoque de Pruebas (Estrategia) ............................................................................................. 4 Criterios de Aceptación o Rechazo ......................................................................................... 5 Criterios de Aceptación o Rechazo ......................................................................................... 5 Pruebas ....................................................................................................................................5 Generación de Custodias.........................................................................................................5 Generación de Orden de Salida............................................................................................... 6 Registro de Movilización ......................................................................................................13 Recursos ................................................................................................................................ 20 Requerimientos de Entornos – Hardware .............................................................................20 Requerimientos de Entornos – Software............................................................................... 20 Herramientas de Pruebas Requeridas.................................................................................... 20 Personal …………………………………………………………………………………….20 Entrenamiento ....................................................................................................................... 21 Referencias ............................................................................................................................ 21

3

Historial de Versiones Fecha 14/08/2016

Versión 1.0

Autor Xavier Soto y Francisco Arroyo

Organización Gad Provincial

Descripción Pruebas generales del sistema

Información del Proyecto Empresa / Organización Gad Provincial Proyecto Fecha de preparación 14/08/2016 Cliente Gad Provincial Patrocinador principal Gerente / Líder de Proyecto Gerente / Líder de Pruebas de Software

Aprobaciones Nombre y Apellido

Cargo

Departamento u Organización

Fecha

Firma

4

Resumen Ejecutivo Propósito del siguiente plan de Pruebas de Software es analizar que cada módulo del software cumpla con las especificaciones solicitadas.

Alcance de las Pruebas Elementos de Pruebas Se analizara que los módulos de custodia, orden de salida, registro diario, entrega de combustible, cumplan las funciones de ingresar, modificar, eliminar, y contengan el campo de auditoria.

Nuevas Funcionalidades a Probar No existen nuevas funcionalidades a probar.

Pruebas de Regresión Que la interacción entre las distintas paginas sea la correcta.

Funcionalidades a No Probar

Enfoque de Pruebas (Estrategia) La estrategia a seguir es desarrollar una tabla y donde se analiza los requisitos funcionales y los parámetros para su correcto funcionamiento, en una columna ira la descripción del requisito a probar, en la siguiente si este esta implementado correctamente y finalmente en la última se realizara una toma de pantalla donde se evidencie el funcionamiento del requisito.

5

Criterios de Aceptación o Rechazo Criterios de Aceptación o Rechazo Para aceptar el informe se deberá cumplir que la totalidad de los requisitos analizados cumplan las especificaciones del usuario

Pruebas Generación de Custodias Descripción de Cumple Prueba

especificado

Se despliega la SI ventana para

modal ingresar

una custodia Carga la lista de Si conductores disponibles

Carga la lista de Si vehículos disponibles

lo Imagen

6

Se almacena el Si registro de la custodia

en

estado

de

pendiente Despliega

el Si

documento

de

custodia

a

imprimir automรกticamente

Generaciรณn de Orden de Salida Descripciรณn de Cumple Prueba

especificado

Se despliega la SI ventana

modal

para generar una orden de salida

lo Imagen

7

Carga la lista de Si custodias, si en esta no se ha podido encontrar tiene un botรณn para refrescar

la

informaciรณn

Ingresar la fecha Si de creaciรณn de la orden de salida

8

Ingresar la fecha Si de expiraciรณn de la

orden

de

salida

Permite ingresar Si el

origen

de

destino de salida

9

Permite ingresar Si el

origen

de

destino al que se dirige

Genera informe

un Si de

la

Orden de salida reciĂŠn creada

Se despliega el Si menĂş

para

visualizar informes

de

Ăłrdenes generales por fechas

rango

de

10

Se

puede Si

seleccionar fecha y hora de forma dinámica

Aprobación

de

orden de salida, Ingresa

fecha

límite para ver los registros

de

aprobaciones.

Generación

de si

informe

de

órdenes por fecha orden de salida,

11

Historial

de Si

cambios de las Ăłrdenes

de

movilizaciĂłn Detalle

de

la Si

orden de salida, desde registro de la orden

Detalle

de

la Si

orden de salida, desde

custodia

relacionada

Detalle VehĂ­culo custodia relacionada

de Si desde

12

Detalles

del Si

vehículo

en

registro

el de

combustible

Detalles

del Si

vehículo

en

registro custodia

el de

y

sus

estados que ha tenido Detalles

del Si

vehículo

en

el

registro

de

historial

de

cambios Detalle

de

la Si

orden de salida, para la impresión de la orden

13

Registro de Movilización Descripción de Cumple Prueba

especificado

Se despliega la SI ventana

modal

para generar un registro

de

movilización, generación automática.

Carga

la Si

información de horario de salida

lo Imagen

14

Ingresar la fecha Si de creaciĂłn de la orden de salida

Ingresar

el Si

kilometraje

de

salida

del

vehĂ­culo para el registro.

15

Funcionario

de Si

movilizaciรณn

Observaciรณn del Si registro movilizaciรณn

de

16

Genera informe

un Si de

la

movilizaci贸n

Generaci贸n

de Si

informes individuales

por

Aprobaci贸n

de

orden de salida Aprobaci贸n

de Si

orden de salida, Ingresa fecha de inicio

17

Aprobación

de

orden de salida, Ingresa

fecha

límite para ver los registros

de

aprobaciones.

Aprobación

de No

orden de salida, generación

de

informe.

Historial

de Si

cambios de las órdenes movilización

de

18

Detalle

de

la Si

orden de salida, desde registro de la orden

Detalle

de

la Si

orden de salida, desde

custodia

relacionada

Detalle

de Si

VehĂ­culo

desde

custodia relacionada

Detalles vehĂ­culo

del Si en

registro combustible

el de

19

Detalles

del Si

vehĂ­culo

en

registro custodia

el de

y

sus

estados que ha tenido Detalles

del Si

vehĂ­culo

en

el

registro

de

historial

de

cambios Detalle

de

la No

orden de salida, para la impresiĂłn de la orden

20

Recursos Requerimientos de Entornos – Hardware Para realizar las pruebas se necesitara un computador que posea mínimo 4g de RAM y que tenga de procesador un I5

Requerimientos de Entornos – Software  

Base de datos del sistema Software Principal

Herramientas de Pruebas Requeridas Por acuerdo con el Gad Provincial no se utilizaran herramientas para las pruebas.

Personal Dos (2) analistas de pruebas. Xavier Soto y Francisco Arroyo.

21

Entrenamiento No hay necesidades de entrenar a los analistas del sistema dado que ya poseen la información necesaria para realizar las pruebas.

Referencias  

.

SRS (especificaciones de requisitos de software) SDS (especificaciones de diseño de software)

81

ANEXO 8. Manual de usuario

1

MANUAL DE USUARIO SISTEMA DE LA GESTIÓN VEHICULAR INTERNA

“Sistema para el Gestión y Control Vehicular en el GAD de Santo Domingo de lo Tsáchilas”

2

Escuela de Sistemas Pontificia Universidad Catรณlica Del Ecuador Sede Santo Domingo

3

Índice

Instalación ......................................................................................................................... 5 Requisitos………………………………………………………………………………..5 Instalación de la aplicación ............................................................................................... 5 Manejo de la aplicación .................................................................................................... 6 Login……………………………………………………………………………………..6 Interfaces Dentro del Sistema ........................................................................................... 9 Inicio………………………………………………………………………………………………………..9 Administración .......................................................................................................................................11 Sistema…………………………………………………………………………………………………...12 Administración de Usuarios ..................................................................................................................14 Administración WebMail........................................................................................................................16 Papelera…………………………………………………………………………………………………... .......17 Fuentes…………………………………………………………………………………………………... ........18 Control…………………………………………………………………………………………………... ..........21 Servidores .............................................................................................................................................21 Servidores públicos ...............................................................................................................................24 Administración de vehículos .................................................................................................................25 Custodia…………………………………………………………………………………………………... .......28 Orden de Salida ....................................................................................................................................31

4

Registro de Movilización Diario .............................................................................................................33 Estación…………………………………………………………………………………………………...37 Estación de Combustible ......................................................................................................................37

5

Instalación

Es un proceso el cual deberá llevarse con las especificaciones del ERS para una correcta instalación, siempre y cuando se tenga en cuenta los temas aquí tratados: requisitos e instalación del Sistema.

Requisitos Esta aplicación se trata de una herramienta de accesibilidad web y realiza una serie de procesos para la gestión y los procesos de ingreso y salida de vehículos en el GAD Provincial de Santo Domingo, fue creado con las condiciones y peticiones de usuario. Es necesario contar con un servidor para instalar el servidor web; el servidor debe brindar sostenibilidad y seguridad web, el entorno debe ser óptimo para el sistema de preferencia trabajar sobre una base Centos 6.4 o superior. En la parte de usuario se debe disponer de un ordenador con un sistema operativo compatible con cualquier navegador y acceso a internet.

Es recomendable tener actualizado el navegador con la última versión disponible ya que esta aplicación utiliza algunos procedimientos que pueden no funcionar en versiones antiguas).

Instalación de la aplicación

No definida la instalación en el servidor

6

Manejo de la aplicaciรณn Login Una vez instalada la aplicaciรณn en el servidor, se procederรก ingresar desde una computadora como usuario a la direcciรณn del sitio web que se brinda para el acceso, Al acceder a la direcciรณn se nos presentara la primera interfaz llamada login, la cual permite acceso al usuario dentro del sistema.

7

A continuación, los componentes del login y su ingreso.

Tabla de componentes: NOMBRE

Usuario

IMAGEN

DESCRIPCIÓN

Especificaciones

Ingresar

Debe estar creado

Nombre

de en el sistema para

Usuario

logearse Debe ingresar la

Ingresar contraseña Password

Password

de asignada

del

Usuario usuario Proceso

para

Recuperar recuperar Restaurar Contraseña

la

contraseña del contraseña usuario mediante webmail

8

Ingreso Iniciar Sección

usuario

del al Acceso al sistema

sistema

Logotipo

del

Logo

Sin acción GAD Provincial

PASOS: 1. Ingresar al sistema web.

2. Se desplegará una ventana “Acceso a GAD Municipal” esta es el login (descrito en tabla de componentes).

3. Ingresar Usuario.

4. Ingresar Password. a. En caso de no recordar su contraseña ir pasos alternativos descritos más abajo.

5. Iniciar Sección

PASOS ALTERNATIVOS Restaurar Contraseña: Se enviará mediante webmail para restablecer contraseña y se presentara dicha ventana con un aviso en la esquina inferior derecha.

9

Interfaces Dentro del Sistema Dentro del sistema tendremos toda la parte funcional del sitio web en el cual detallaremos cada uno de sus procesos y sus usos para el usuario.

Inicio Se presenta como la ventana al acceder como usuario en el cual nos permitirรก visualizar todo lo que contiene dicho sistema web.

10

Se detallara de forma general cada uno de los botones ya que estaran especificados tabien de forma particular en la parte inferior con sus respectivas funciones Tabla de componentes:

11

NOMBRE

IMAGEN

Parametrización del Sitio Administración de Usuarios Administración de webmail

Papelera

Inicio

Administración de vehículos

Administración

Nombre

Imagen

Descripción

Especificaciones

Menú

Contiene todas las Las interfaces son

Administración

interfaces para la las siguientes: administración

    

Sistema Usuarios Web Mail Papelera Fuentes

12

Sistema

Tabla de componentes Nombre

Imagen

Descripción

especificaciones

Datos

despliega la interfaz Sin acción

Presentació

para gestionar los

n

datos y reportes

de

Reportes Cambiar

Es una imagen con

imagen

botón para

desplegable cambiar

la



Presenta un botón cambiar imagen

13

imagen

del

sitio

web

Contactos

Presenta los datos del

contacto

Sin acción

principal

Información

Presentan los datos

del contacto

del

contacto

en

general

Información

Permite cambiar las

de reportes

imágenes iconos

de y

especificados

los logos



Razón social



RUC/CC/D NI



Slogan



Ciudad



Dirección



Teléfono



Correo electrónico



Departamen to

Puede cambiar: 

Logo



Imagen principal

14

Administración de Usuarios

Tabla de componentes Nombre Tabla

Imagen de

administración de usuarios

Descripción

especificaciones

Es en esta Campos: tabla

que

contiene todo



Datos personales -Perfil

los -Cédula

datos de los usuarios

-Nombre -Dirección -Teléfono -Correo

15



Datos Usuario -Usuario -Perfil -Fecha Registro -Estado

Informe

Esto es un Presenta un video para descargar botón para general informes generales de todo

los

datos de las tablas Usuario

Botón para Ingresa

un

nuevo

agregar un usuario con todos sus

Actualizar

nuevo

campos para constar en

Usuario

el sistema.

Permite

Actualizar

actualizar la tabla informativa

16

de

los

Usuario Busca

Buscar

un Sin acción

usuario que contenga lo que

se

escribe

Administración WebMail

Tabla de componentes Nombre Vehículos

Imagen

Descripción Presenta toda

Sin acción la

información de

especificaciones

los

17

vehículos del webmail Conductores

Presenta toda

Sin acción la

información de

los

conductores

Papelera

18

Fuentes

Tabla de componentes Nombre Marcas

Imagen

Descripciรณn especificaciones Presenta todo

Presenta todo los los campos de la tabla

datos de las maracas y pueden marcas

Modelos

en crear mรกs a partir de

tablas

esta ventana.

Presenta

Presenta todo los

todo

los campos de la tabla

datos de los modelos y pueden

19

modelos en crear más a partir de

Licencias

tablas

esta ventana.

Presenta

Presenta todo los

todo

los campos de la tabla

datos de las licencias y pueden marcas

Actualizar

en crear más a partir de

tablas

esta ventana.

Permite

Actualizar

actualizar la tabla informativa de

los

Usuario Buscar

Busca

un Sin acción

usuario que contenga lo que

se

escribe Tabla

Especifica

Marcas

la marcas

tabla

Contiene: 

ID



CODE



MARCA



EDITAR

20

Editar

Edita

Marcas,

campos de de

Modelos

cada una de modificar.

Licencias

Paginación

las Acción en cada una las

tablas

a

las tablas

Esta

Presentación de las

presenta

tablas de datos en

cada una de páginas distintas. las páginas de registro guardado Nuevo

Crea

Licencia

nueva

una Botón

Licencia

Nuevo

Crea

Marca

nueva marca

una Botón

de

carro Nuevo

Crea

Modelo

nuevo

un Botón

modelo de carro

21

Control

Nombre Menú control

Imagen

Descripción

especificaciones

Contiene todas las Las interfaces son interfaces para el las siguientes: control

    

Servidores

Servidores Vehículos Custodias Orden de salida Registro de movilización

22

Tabla de componentes:

Nombre Conductores

Imagen

Descripción despliega

especificaciones la

interfaz para gestionar los conductores Tabla

una tabla con

Conductor

toda los datos

  

informativos



del conductor

   

Informe

Genera

un

informe

con

todos

los

conductores Buscar

Busca registro contenga

un que lo

que se escribe

Cedula Id Nombre 1 Nombre 2 Apellido paterno Apellido materno Estado Licencia

23

Actualizar

Permite actualizar

la

tabla informativa de

los

conductores

24

Servidores pĂşblicos

Tabla de componentes: Nombre Informe

Imagen

DescripciĂłn

especificaciones

Genera

un

informe

con

todos

los

conductores Buscar

Busca registro contenga

un que lo

que se escribe Actualizar

Permite actualizar tabla

la

25

informativa de

los

conductores Tabla

Se

visualiza

Personal

los

datos

personales del Personal del Gad

Administración de vehículos

Tabla de componentes: Nombre Informe

Imagen

Descripción Genera

Especificaciones un

informe con todos los vehículos

26

Buscar

Busca un registro que contenga lo que se escribe

Actualizar

Permite actualizar la

tabla

informativa de los vehículos Nuevo

Permite

Vehículo

creación

la de

un

nuevo vehículo en la base de datos Tabla

Visualiza todo los

datos

datos

vehículos

vehículos

Tabla

Visualiza

datos

información

Propietario

correspondiente

de

los

la

los propietarios de los vehículos

27

Detalles de

Visualiza

registro

información

la Estado

del

registro

correspondiente a

Última edición

los detalles del Usuario

registro

edito Menú

Muestra todo los opciones

del

registro Editar

Nos permite la edición

del

Registro Historial

Nos muestra el

de

historial

Cambios

cambios de ese

de

registro Detalle de

Nos permite ver la

Registro

información detallada

del

registro en otra pagina

que

28

Nos permite la

Eliminar

eliminaciรณn

del

registro

Custodia

Tabla de contenidos: Nombre Informe

Imagen

Descripciรณn

especificaciones

Genera un informe con todas las custodias

Buscar

Busca un registro que contenga lo escribe

que se

29

Actualizar

Permite actualizar la tabla informativa de las custodias

Nueva custodia

Permite la creación de una nueva custodia en la base de datos

Tabla Vehículo

Nos

muestra

la Nos

muestra

la

información básica del placa del vehículo vehículo en la custodia Datos Conductor

Nos

muestra

la Cedula o RUC

información básica del conductor en la custodia Nombre Detalle Registro

Nos

muestra

la Los estados de la

información del registro custodia variar

Menú

Muestra

todo

opciones del registro

los

pueden

30

Custodia Temporal

Nos permite realizar una Cambia el estado de la custodia a

custodia temporal

temporal Historial

de

Cambios

Nos muestra el historial de

cambios

de

ese

registro Detalle de Registro

Nos permite ver la información

detallada

del registro en otra pagina Eliminar

Nos permite cambiar el estado de la custodia a suspendida

Impresión

Nos permite imprimir la custodia

Visualización

Nos permite visualizar Solo

aparecerá

la información de una cuando el estado de custodia temporal

la

custodia

temporal Aprobación

Nos permite cambiar el estado de la custodia a aprobada

sea

31

Orden de Salida

Tabla de contenidos: Nombre Informe

Imagen

Descripciรณn Genera un informe con todas las ordenes de salida

Buscar

Busca un registro que contenga lo que se escribe

Actualizar

Permite actualizar la tabla informativa de las ordenes de salida

Nueva Orden

Nos permite la creaciรณn de una nueva orden de salida

Especificaciรณn

32

Tabla

Datos

Nos

muestra

la Cedula o RUC

información básica del

Conductor

conductor

en

la Nombre

custodia Tabla Detalle

Nos

muestra

la Numero de orden

información detallada de la orden de salida Fecha

de

concesión

Fecha

de

expiración Tabla

Detalle

Registro

Nos muestra el detalle del registro como los usuarios

Tabla Vehículo

Nos

muestra

la Nos muestra la

información básica del placa del vehículo vehículo en la custodia Menú

Nos

muestra

las

opciones que tenemos sobre cada orden de salida

33

Nos permite imprimir

Impresiรณn

la custodia Historial

de

Cambios

Nos muestra el historial de cambios de ese registro

Aprobaciรณn

Nos permite cambiar el estado de la orden de salida

Registro de Movilizaciรณn Diario

34

Nombre Informe

Imagen

Descripciรณn

especificaciones

Genera un informe con todas

los

registros

diarios cargados en la tabla Buscar

Busca un registro que contenga

lo

que

se

actualizar

la

escribe

Actualizar

Permite

tabla informativa de las custodias

35

Nueva entrada

Nos

permite

la

generación de un nuevo registro Cargar registros

Nos permite validar el archivo del controlador biométrico

Tabla Salida

Nos

visualiza

la Kilometra

información de salida del chofer Fecha de registro de la salida Tabla Llegada

Nos

visualiza

la Kilometra

información de llegada del chofer Fecha de registro de la llegada Tabla orden de

Nos

visualiza

la Numero de orden

salida

información de la orden de salida Lugar de destino

Funcionario

Nos

visualiza

responsable

información

la del

36

funcionario con el que salió el vehículo Motivo de salida

Nos visualiza el motivo por el cual el vehículo salió Nos

Observación

muestra

alguna

observación extra que se le

haya

hecho

al

vehículo Detalle Registro

de

Nos

visualizamos Los estados son

información de control llegada, salida del registro

Editar

Nos permite editar el Los registro

datos

de

llegada del registro

37

Estaciรณn Estaciรณn de Combustible

Nombre Informe

Imagen

Descripciรณn Genera un informe con todas las entregas cargados en la tabla

Buscar

Busca un registro que contenga lo que se escribe

Actualizar

Permite actualizar la tabla informativa de las custodias

especificaciones

38

Nueva Entrega

Nos permite generar una nueva entrega de combustible

Tabla Despacho

Nos

muestra

la Tipo

información

del combustible

despacho

del

de

combustible Cantidad

en

galones Tabla vehículo

Nos

muestra

información

la Código del

vehículo al cual se despachó combustible Detalle Registro

Nos

placa

muestra Estado

información para la auditoria del registro Fecha de última edición

usuario