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