Departamento de Tecnologia de La Informacion UG
Departamento de Tecnologia de La Informacion UG
Departamento de Tecnologia de La Informacion UG
PROYECTO DE TITULACIÓN
Previa a la obtención del Título de:
TUTOR:
Ing. Erick González Linch M. Sc.
GUAYAQUIL – ECUADOR
2017
REPOSITORIO NACIONAL EN CIENCIA Y TECNOLOGÍA
FICHA DE REGISTRO DE TESIS
TITULO
“SISTEMA WEB DE CONTROL Y MONITOREO DE REQUERIMIENTOS DIRIGIDOS
HACIA LA DIRECCIÓN DE GESTIÓN TECNOLÓGICA DE LA INFORMACIÓN DE LA
UNIVERSIDAD DE GUAYAQUIL, COMO PARTE DEL PROCESO DE GESTIÓN DE
VENTANILLA ÚNICA.”
AUTORES/ES: REVISORES:
Katherine Roxana Yager Velarde Francisco Contreras MBA.
Andrés David Paladines García Jorge Zambrano, M. Gs.
FACULTAD: Ciencias Matemáticas y
INSTITUCIÓN: Universidad de Guayaquil
Físicas
CARRERA: Ingeniería en Sistemas Computacionales
N. DE PAGS: 127
FECHA DE PUBLICACIÓN: JULIO 2017
Atentamente
Ing. Eduardo Santos Baquerizo, M.Sc. Ing. Roberto Crespo Mendoza M.G.s
DECANO DE LA FACULTAD Sc.
CIENCIAS MATEMATICAS Y DIRECTOR (E)
FISICAS CISC
Nombre y Apellidos
PROFESOR TUTOR DEL PROYECTO
DE TITULACION
_______________________________________
_______________________________________
II
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
C.I.__0931131890____________
III
CERTIFICADO DE ACEPTACIÓN DEL TUTOR
CERTIFICO:
Presentado por:
Tutor: ____________________________
Ing. Erick González Linch M. Sc.
IV
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERIA EN SISTEMAS
COMPUTACIONALES
V
2. Autorización de Publicación de Versión Electrónica del
Proyecto de Titulación
Publicación electrónica:
3. Forma de envío:
DVDROM CDROM X
VI
ÍNDICE GENERAL
APROBACION DEL TUTOR .............................................................................. III
DEDICATORIA (KATHERINE ROXANA YAGER VELARDE) ...........................IV
AGRADECIMIENTO (KATHERINE ROXANA YAGER VELARDE) ....................V
DEDICATORIA (ANDRÉS PALADINES GARCÍA) ............................................VI
AGRADECIMIENTO (ANDRÉS PALADINES GARCÍA) ...................................VII
TRIBUNAL PROYECTO DE TITULACIÓN ......................................................VIII
CERTIFICADO DE ACEPTACIÓN DEL TUTOR ................................................IV
ÍNDICE GENERAL ............................................................................................VII
ABREVIATURAS ...............................................................................................IX
ÍNDICE DE CUADROS........................................................................................X
ÍNDICE DE GRÁFICOS ......................................................................................XI
Resumen ............................................................................................................ 1
Abstract .............................................................................................................. 2
INTRODUCCIÓN ................................................................................................. 3
CAPÍTULO I ........................................................................................................ 5
EL PROBLEMA................................................................................................... 5
PLANTEAMIENTO DEL PROBLEMA................................................................. 5
Ubicación del Problema en un Contexto .....................................................5
Situación conflicto nudos críticos................................................................5
Causas y consecuencias del problema .......................................................7
Delimitación del problema .............................................................................8
Formulación del problema.............................................................................8
Evaluación del problema ...............................................................................8
OBJETIVOS ........................................................................................................ 9
Objetivo general ..............................................................................................9
Objetivos específicos .....................................................................................9
Alcances del problema .................................................................................... 10
Justificación e importancia ............................................................................. 11
Metodología del proyecto ............................................................................... 12
Supuestos y restricciones .............................................................................. 14
Supuestos ...................................................................................................... 14
Restricciones ................................................................................................ 14
Plan de Calidad (Pruebas a realizar) .............................................................. 15
Pruebas funcionales ........................................................................................ 15
Pruebas no funcionales .................................................................................. 15
CAPÍTULO II ..................................................................................................... 17
MARCO TEÓRICO ............................................................................................ 17
ANTECEDENTES DEL ESTUDIO ..................................................................... 17
FUNDAMENTACIÓN TEÓRICA........................................................................ 18
Ventanilla única ............................................................................................ 18
Ticket .............................................................................................................. 18
VII
Servidor web ................................................................................................. 18
Open Source.................................................................................................. 19
Apache HTTPD .............................................................................................. 19
PHP ................................................................................................................. 20
Laravel............................................................................................................ 20
Base de datos relacional ............................................................................. 22
SQL Server .................................................................................................... 23
GitLab ............................................................................................................. 24
Composer ...................................................................................................... 25
Versionamiento ............................................................................................. 25
JQuery ............................................................................................................ 25
Dashboard ..................................................................................................... 26
Highcharts - JavaScript Charts ................................................................... 27
FUNDAMENTACIÓN LEGAL............................................................................ 29
Ley de propiedad Intelectual ....................................................................... 29
Software Libre ............................................................................................... 29
PREGUNTA CIENTÍFICA A CONTESTARSE .................................................. 31
CAPÍTULO III .................................................................................................... 33
PROPUESTA TECNOLÓGICA ......................................................................... 33
• Análisis de factibilidad ...................................................................... 33
- Factibilidad Operacional ................................................................... 33
- Factibilidad técnica ............................................................................ 34
- Factibilidad Legal ............................................................................... 36
- Factibilidad Económica ..................................................................... 37
Detalle de los Costos del proyecto................................................................. 37
Beneficios de económicos del proyecto ........................................................ 42
• Etapas de la metodología del proyecto ................................................ 43
Concepción. .................................................................................................. 43
Elaboración. .................................................................................................. 46
Construcción. ................................................................................................ 53
Transición. ..................................................................................................... 57
• Entregables del proyecto ...................................................................... 57
CRITERIOS DE VALIDACIÓN DE LA PROPUESTA ........................................ 58
Entrevista a el líder de proyectos de la Dirección de Gestión Tecnológica de
la Información .................................................................................................. 58
Conclusión de la entrevista ......................................................................... 61
CAPÍTULO IV .................................................................................................... 62
VIII
Criterios de aceptación del producto o Servicio ........................................... 62
Conclusiones ................................................................................................... 65
Recomendaciones ........................................................................................... 66
BIBLIOGRAFÍA ................................................................................................. 67
ANEXOS ........................................................................................................... 68
ABREVIATURAS
UG Universidad de Guayaquil
Html Lenguaje de Marca de salida de Hyper Texto
http Protocolo de transferencia de Hyper Texto
Ing. Ingeniero
VUE Ventanilla Única Ecuatoriana
RUP Proceso Unificado Racional
UML Lenguaje Unificado de modelado
SQL Structured Query Language
PHP Hypertext Preprocessor
IX
ÍNDICE DE CUADROS
X
ÍNDICE DE GRÁFICOS
XI
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS
CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES
Resumen
1
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS
CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES
Abstract
This project consists of the development and implementation of a web system aimed at
the management, monitoring and control of the requirements directed to the
Information Technology Management Department of the University of Guayaquil. Using
this system, it is intended to improve care times, as well as, in turn, provide a better
service to all people who come to the windows of this department to make their
respective requests.
2
INTRODUCCIÓN
3
• Ministerio de Agricultura, Ganadería, Acuacultura y Pesca (MAGAP)
• Agencia Ecuatoriana de Aseguramiento de la Calidad del Agro
(AGROCALIDAD)
• Subsecretaría de Acuacultura (SA)
• Subsecretaría de Pesqueros (SRP)
• Instituto Nacional de Pesca (INP)
Es importante llevar a cabo esta implementación debido a que los constantes retrasos
en la resolución de las gestiones significan una molestia para el usuario final, además
esto servirá para que los operadores puedan llevar un control del tiempo que toma dar
solución a cada gestión y así poder modificarlos para cada fase del proceso, también
ayudaría al usuario solicitante a tener una referencia de donde se encuentra su
solicitud y cuando poder acercarse para dar continuidad a la gestión.
El capítulo uno mostrará cual es el planteamiento del problema para mostrarnos una
visión más clara de cómo se compone a través de la situación conflicto nudos críticos,
sus causas consecuencias y la delimitación, además de los objetivos del proyecto y la
metodología a aplicar.
El capítulo dos mostrará los conceptos que se deben tener en cuenta para un mayor
entendimiento de este proyecto, cuáles son las tecnologías aplicadas y como servirán
de apoyo para el desarrollo del sistema.
4
CAPÍTULO I
EL PROBLEMA
Al no contar con una adecuada gestión documental, se ven afectados varios procesos
que dependen a su vez de una circulación ágil de información entre todas las áreas
productoras.
La búsqueda de información que reside en documentación con un alto tiempo de
antigüedad se torna muy ineficiente por la gestión inadecuada con que fueron
5
organizados, viéndose que los requerimientos que se llevan a cabo en la Dirección de
Gestión Tecnológica de la Información no cuentan con un registro adecuado, ni un
control o seguimiento que permita una pronta solución, lo cual lleva retrasos en la
entrega de la gestión realizada, generando molestias en los usuarios solicitantes.
6
Causas y consecuencias del problema
Causas Consecuencias
7
Delimitación del problema
Campo: Administrativo/Académico
Área: Tecnológica
Aspecto: Resolución del problema mediante aplicativo web.
Tema: Sistema web de control y monitoreo de requerimientos dirigidos hacia la
Dirección de Gestión Tecnológica de la Información de la Universidad de Guayaquil,
como parte del proceso de Gestión de Ventanilla Única.
¿Un sistema web podrá mejorar las gestiones que se llevan a cabo en el área de
Dirección de Gestión Tecnológica de la Información de la Universidad de Guayaquil,
contribuyendo a la satisfacción del usuario y facilidad para el operador?
Evidente: Esta herramienta de trabajo permitirá disminuir los tiempos de espera de las
gestiones, logrando así una solución oportuna de tal manera que el usuario quede
satisfecho con las labores del área de la Dirección de Gestión Tecnológica de la
Información.
8
Concreto: Esta herramienta permitirá una gestión oportuna y precisa para el operador,
esta plataforma web estará compuesta por una interfaz clara y amigable para los
usuarios tanto internos como externos.
OBJETIVOS
Objetivo general
Objetivos específicos
• Analizar los procesos relacionados al servicio brindado por el personal del área
con las solicitudes que reciban en recepción mediante la recopilación de
información con respecto a las actividades que se desarrollan en el
departamento para conocer los tiempos reales y manejo de la documentación.
• Diseñar la estructura del sistema de control de las gestiones, por medio de
diagramas y casos de uso, para definir los procesos principales en el desarrollo
del sistema.
9
• Desarrollar el prototipo de la aplicación web mediante la utilización de
herramientas tecnológicas para realizar el registro de las etapas de cada
proceso de atención al usuario del área.
• Capacitar al personal administrativo a través de la inducción sobre el manejo
de la nueva herramienta y puedan ser usadas de la mejor forma posible.
10
● El aplicativo será implantado en el área de recepción de la Dirección de Gestión
Tecnológica de la Información de la Universidad de Guayaquil.
• El aplicativo web permitirá que el personal realice las respectivas asignaciones de
responsabilidades hacia los documentos.
Justificación e importancia
Con la culminación de este proyecto se brindará un servicio más rápido y una mayor
eficiencia en relación a los tiempos y capacidad laboral, promoviendo estas prácticas
hacia nuevas áreas de la Universidad de Guayaquil.
Como resultado, los beneficiarios serán los usuarios que se acerquen a las ventanillas
de la Dirección de Gestión Tecnológica de la Información de la Universidad de
Guayaquil, ya que podrán conocer tanto el tiempo aproximado de su gestión, como
también tendrán una referencia de la fase en la que se encuentre su solicitud.
Este proyecto ayudará al área de desarrollo a sentar bases para sus nuevos proyectos
siguiendo estándares de programación a través del marco de trabajo (FrameWork)
denominado Laravel.
11
Metodología del proyecto
El Proceso Unificado Racional RUP por las siglas Rational Unified Process, (Krutchen,
2003), lo define como un modelo de proceso derivado del UML, esta metodología de
desarrollo de proyectos se basa en que los modelos de procesos que son
convencionales, y que en realidad presentan una sola visión de cada proceso.
Según Sommerville Ian (2011) existen tres perspectivas que por lo general se
describen, estas son:
• Perspectiva dinámica, fases del modelo.
• Perspectiva estática, actividades del proceso.
• Perspectiva práctica, buenas prácticas durante el proceso.
RUP, busca trabajar como un modelo de fases, se asemeja al modelo cascada pero a
difiere en que estas fases se encuentran vinculadas a la empresa o usuario final.
El proyecto se basará en las cuatro fases que propone RUP, las cuales estarán
estrechamente vinculadas con la Dirección de Gestión Tecnológica de la Información
de la Universidad de Guayaquil.
12
GRÁFICO N° 1 Fases de RUP
La Transición. - En esta última etapa, se realiza la liberación del producto junto con la
entrega del mismo al usuario de tal manera que este pueda usarla. Durante esta fase,
se incluirán las tareas de marketing, empaquetado, instalación, capacitación, soporte,
mantenimiento, manuales de usuario entre otros, implica la implementación del
software en el ambiente real y que este funcione de manera correcta.
13
El objetivo de obtener un software de calidad se logra basándose este proyecto en las
buenas prácticas que propone esta metodología tales como las que se muestran en el
siguiente gráfico.
Supuestos y restricciones
Supuestos
Restricciones
14
• Se debe plantear los requerimientos de una manera clara par que esta
metodología sea efectiva y sobre todo debe existir una correcta
retroalimentación con el usuario.
• La base de datos MSSQL Server debe estar actualizada a la versión 2008 R2.
• El contenedor de aplicaciones debe ser apache 2.0.
• La versión de PHP mínima aceptable es la 5.6.0.
• Deberán ser usados los usuarios ya existentes dentro de las bases de la
Universidad de Guayaquil, los cuales serán designados a ser funcionarios,
administradores o auditores.
Pruebas funcionales
Estas pruebas son basadas en el cumplimiento de los requerimientos para los que fue
desarrollada la aplicación.
Dentro de estas pruebas, se tienen pruebas unitarias, casos de uso y pruebas con los
usuarios finales.
Pruebas no funcionales
15
Con estas pruebas durante y posterior al desarrollo del proyecto, se pretende detectar
posibles casos a mejorar en el software con el objetivo de que este sea un producto de
calidad.
16
CAPÍTULO II
MARCO TEÓRICO
ANTECEDENTES DEL ESTUDIO
El avance tecnológico es una herramienta muy importante, que será utilizada a favor
del proyecto para determinar una solución integral, con esto se pretende alcanzar una
mejora en cuanto a la gestión de requerimientos, esta metodología de trabajo se
enfoca en la atención de las gestiones de manera universal, es decir, todas las
ventanillas estarán prestas a funcionar de manera genérica para atender cualquier tipo
de solicitud cubriendo todas las necesidades de los usuarios.
17
FUNDAMENTACIÓN TEÓRICA
Para tener un mayor entendimiento del contexto del proyecto debemos tener en
cuenta las siguientes definiciones.
Ventanilla única
Ticket
Tomando este concepto como premisa, una tiquetera es un sistema, que administra y
distribuye turnos.
El presente proyecto se basa en ciertos aspectos en una tiquetera que busca que el
usuario final obtenga un turno y un tiempo específico en el cual será solucionado su
requerimiento, para de estar forma respetar el orden secuencial de cada usuario que
se acerque a la ventanilla única.
Servidor web
18
Transfer Protocol (HTTP) con el cual se transfieren datos de hipertexto, ya sean estas
HTML (HyperText Markup Language), PHP (Hypertext Processor), JSP(JavaServer
Pages), entre otros.
Estos hipertextos son aquellos que dan lugar a figuras, enlaces a imágenes,
formularios y herramientas usadas tanto por el usuario como del servidor.
Open Source
Apache HTTPD
19
Este contenedor será el de aplicaciones sobre el cual se implementará la página web,
ya que esta es una herramienta open source y además es utilizada en los desarrollos
de la Dirección de Gestión Tecnológica de la Información, por lo que se pretende
seguir los estándares y lineamientos.
PHP
The PHP Group, en su página oficial “php.net”, menciona que PHP (Hypertext
Preprocessor), es un lenguaje de programación interpretado cuya sintaxis tiene mucho
en común con C++ o JAVA, es utilizado en su mayoría para el desarrollo de páginas
web ya que en la generación dinámica de estas ha alcanzado la popularidad, además
de ser un lenguaje sencillo, pero que se integra muy bien con el diseño de html, otra
de las razones que ha vuelto popular a este lenguaje es que con este se puede
generar pdf, xml, gráficos.
Laravel
20
también como el aspecto de la seguridad como la autenticación, enrutamiento y el
almacenamiento en caché dentro de una página web.
Esta librería será aplicada en el presente proyecto, es una herramienta que posee
varias características que la vuelven un apoyo significativo, además el presente
desarrollo pretende basarse en los lineamientos que se llevan a cabo actualmente
para proyectos de la Dirección de Gestión Tecnológica de la Información, y de esta
manera poder acoplarse de la mejor manera a su entorno de trabajo.
21
GRÁFICO N° 3 Características de Laravel
Amazon Web Services afirma que “una base de datos relacional es una recopilación
de elementos de datos con relaciones predefinidas entre ellos.”
Este modelo relacional es el más utilizado por las facilidades que brinda a los
desarrolladores si lo comparamos con otros modelos como el jerárquico y de red, al
poseer estas características importantes se considera que una base de datos
relacional es el modelo ideal a aplicar en este desarrollo.
22
GRÁFICO N° 4 Ventajas de una base de datos Relacional
SQL Server
Según el libro “Introducing Microsoft SQL Server 2016”, es un sistema propietario, de
gestión de base de datos. Dicha base puede ser probada durante 180 días que otorga
la compañía como descarga de evaluación.
23
GRÁFICO N° 5 Características de SQL Server
GitLab
24
Composer
Composer es una herramienta que se maneja bajo consola, existen distribuciones para
Linux, Windows y Mac os, su uso se basa en la gestión de las dependencias en PHP,
permitiendo la declaración de bibliotecas utilizadas en un proyecto, a su vez se
encarga de la instalación y actualización de las mismas.
Versionamiento
JQuery
Según la página oficial JQuery, es una librería muy útil ya que permite manipular el
contenido web, a través de un proceso llamado DOM (Document Object Model),
además, contiene múltiples funciones de JavaScript, que facilitarán el manejo de
eventos, Ajax y animación, siendo compatible con múltiple navegadores.
Este proyecto maneja tablas, formularios, alertas, entre otros componentes, lo cual
hace que se requiera de eventos y animaciones, por lo que utilizaremos como apoyo a
esta librería ya que brinda funcionalidades útiles y sencillas de aplicar.
25
GRÁFICO N° 6 Ventajas de jQuery
Dashboard
Es importante que este proyecto cuente con un módulo de datos estadísticos para
que en futuras ocasiones se puedan tomar decisiones con respecto a las gestiones
26
que se lleven a cabo durante el proceso de los requerimientos, un Dashboard es
un elemento completo que brinda información de manera clara y oportuna.
GRÁFICO N° 7 Dashboard
Según Highcharts en su página oficial, indica que es una librería la cual ofrece una
gran variedad gráficos estadísticos basados en JavaScript, entre las facilidades o
ventajas de esta librería son: 100% responsive, es decir que el tamaño de los
gráficos serán adaptables a la página del navegador; los gráficos son
personalizables, por lo que se podrán alterar el color, las animaciones, eventos y
funcionalidades. También es accesible debido a que se encuentra suficiente
información en la web con respecto a las implementaciones de las diferentes
funcionalidades que ofrece la herramienta, todos estos beneficios la convierten en
una destacada opción para poder elaborar el Dashboard del aplicativo web.
27
Este proyecto utilizará esta librería de gráficos para poder elaborar el Dashboard
del sistema, al ser esta muy completa y con diseños elegantes, la convierten en el
elemento perfecto a implementar en la aplicación web.
28
FUNDAMENTACIÓN LEGAL
Parágrafo Primero
De los programas de ordenador
Art. 28.- Los programas de ordenador se consideran obras literarias y se protegen
como tales. Dicha protección se otorga independientemente de que hayan sido
incorporados en un ordenador y cualquiera sea la forma en que estén expresados, ya
sea en forma legible por el hombre (código fuente) o en forma legible por máquina
(código objeto), ya sean programas operativos y programas aplicativos, incluyendo
diagramas de flujo, planos, manuales de uso, y en general, aquellos elementos que
conformen la estructura, secuencia y organización del programa.
Dicho titular está además legitimado para ejercer en nombre propio los derechos
morales sobre la obra, incluyendo la facultad para decidir sobre su divulgación.
El productor tendrá el derecho exclusivo de realizar, autorizar o prohibir la realización
de modificaciones o versiones sucesivas del programa, y de programas derivados del
mismo.
Las disposiciones del presente artículo podrán ser modificadas mediante acuerdo
entre los autores y el productor.
Software Libre
Según el Decreto Ejecutivo No. 1014 emitido el 10 de abril de 2008, se declara que el
uso de software libre, es importante para el gobierno ecuatoriano ya que con este se
pretende alcanzar soberanía y autonomía tecnológica, así como un ahorro de recursos
públicos.
29
De esta manera se pretende seguir los lineamientos del estado ya que la Universidad
de Guayaquil es una institución pública es por esto que se detalla a continuación lo
que se decreta en el numeral 9 del artículo 171 de la Constitución Política de la
República
Artículo 1.- Establecer como política pública para las Entidades de la Administración
Pública Central la utilización de Software Libre en sus sistemas y equipamientos
informáticos.
Para efectos de este decreto se comprende como seguridad nacional, las garantías
para la supervivencia de la colectividad y la defensa del patrimonio nacional.
Artículo 5.- Tanto para software libre como software propietario, siempre y cuando se
satisfagan los requerimientos, se debe preferir las soluciones en este orden:
a) Nacionales que permitan autonomía y soberanía tecnológica.
30
b) Regionales con componente nacional.
c) Regionales con proveedores nacionales.
d) Internacionales con componente nacional.
e) Internacionales con proveedores nacionales.
f) Internacionales.
31
DEFINICIONES CONCEPTUALES
Hamachi.- Es una red virtual de servicios con el que se puede acceder remotamente a
la red del negocio (servidor) con una conexión a internet.
SQL.- Structured Query Language, es un lenguaje que se utiliza para hacer consultas
recuperar y actualizar la información en la base de datos.
32
CAPÍTULO III
PROPUESTA TECNOLÓGICA
• Análisis de factibilidad
- Factibilidad Operacional
El objetivo que persigue es investigar si el sistema será utilizado por los usuarios.
Algunas de las preguntas que es interesante plantearse pueden ser:
“¿Existe apoyo suficiente para el proyecto por parte de la administración? ¿Y por
parte de los usuarios?
33
¿Los métodos que actualmente se emplean en la empresa son aceptados por
todos los usuarios?
¿Los usuarios han participado en la planeación y en el desarrollo del proyecto?”
Por tanto, basándose sobre estas premisas, este proyecto solucionará los
problemas antes mencionados de manera eficaz. Si no se realiza este proyecto,
los problemas en los tiempos y pérdida de documentación, seguirán
produciéndose debido a una falta de control por parte de la misma entidad.
- Factibilidad técnica
Por la parte de Hardware los equipos necesarios que serán proveídos por la
Universidad de Guayaquil para la implementación del sistema de control y monitoreo
de los requerimientos como parte del proceso de gestión de las ventanillas únicas son:
34
CUADRO N° 2 Recursos de Hardware
RECURSOS DE HARDWARE
Cantidad Equipos
1 Servidor de pruebas: Dell T300 CPU Xeon 3325, 4GB Ram ecc, 380 GB
RAID 0.
35
Para la parte de Software se cuenta con la siguiente tecnología para el desarrollo del
proyecto:
CUADRO N° 3 Recursos de Software
RECURSOS DE SOFTWARE
NetBeans, PHP Storm, SQL Server Management Studio, Xampp, Windows, Mac
OS X.
- Factibilidad Legal
La factibilidad legal del proyecto cabe mencionar que este se alinea a los estándares
de la Universidad de Guayaquil tanto técnica como social, el presente proyecto busca
contribuir con el bienestar de todos aquellos quienes forman parte de esta institución,
apegándose a la misión y visión generando así desarrollo sustentable y con innovación
social.
Este desarrollo forma parte de un macro proyecto denominado cero papel que en
conjunto con el equipo de gestión Documental, busca disminuir el uso de papel como
parte de las gestiones de la Dirección de Gestión Tecnológica de la Información de la
Universidad de Guayaquil, contribuyendo de esta manera con el medio ambiente.
36
Otro punto importante es el uso de software libre para el desarrollo del proyecto y de
esta manera nos regimos al Decreto Ejecutivo No. 1014 emitido el 10 de Abril de 2008,
en donde se declara que el uso de software libre es necesario e importante para el
Gobierno ecuatoriano y de esta forma se busca alcanzar independencia tecnológica,
además de un ahorro de recursos públicos.
- Factibilidad Económica
A continuación, se define cuáles son los costos de los recursos que conforman el
desarrollo e implementación del presente proyecto.
Hardware
Software
37
CUADRO N° 5 Recurso Humano
Recurso Humano
38
CUADRO N° 7 Recursos de Hardware
Recursos de Hardware
39
CUADRO N° 8 Recursos de Software
Recursos de Software
NetBeans $0
PHP Storm $0
Xampp $0
Windows $0
Mac OS X $0
Según podemos observar en el cuadro No. 8 los recursos de software no poseen costo
ya que en este proyecto se basó en el uso de software libre.
40
CUADRO N° 9 Otros Costos
Otros Costos
Recursos de Software $0
Total $3860
41
Beneficios de económicos del proyecto
Podemos determinar en este análisis que los costos totales del desarrollo e
implementación no son elevados y que los beneficios que otorga el proyecto en sí, lo
vuelve viable económicamente, además de la rentabilidad a largo plazo que se
42
obtendrá como el ahorro en materiales y tiempo de atención a los usuarios.
Concepción.
43
GRÁFICO N° 9 Proceso actual de atención de requerimientos en ventanillas
44
Es importante recalcar que en el proyecto interviene algunos de los procesos del
flujo, pero no en todos, como por ejemplo en el archivo y escaneo de la
documentación, parte en la que interviene el proyecto de gestión documental que
son los procesos del inicio y final de todo lo que involucra la gestión, la parte
intermedia en la que el requerimiento es llevado a otros responsables y sumillado
respectivamente en cada parte del proceso hasta llegar a la completa solución y
validación del mismo. Lo que pretende agilizar y disminuir en tiempo de atención al
cliente, este proyecto de control y monitoreo, quedando el nuevo flujo de la
siguiente manera:
45
El siguiente gráfico muestra el esquema general del sistema, el cual pretende
mostrar una visión general del funcionamiento del software una vez implementado
en el área de Dirección de Gestión Tecnológica de la Información.
Elaboración.
En esta fase se muestran los casos de uso correspondientes al desarrollo del
sistema, se mostrarán las especificaciones de casos de uso y su respectivo gráfico
además del diseño de las pantallas.
46
GRÁFICO N° 11 Función general del software
47
2.- Lista de requerimientos
El siguiente gráfico nos muestra, el caso de uso del listado de requerimientos
creados y su ingreso, ver anexo 1 (cuadro no.3, no. 4, no. 5, no. 6 y no. 7), del
caso de uso que se muestra a continuación.
48
GRÁFICO N° 14 Ingresar nuevo requerimiento/Caso de uso
49
sistema, ver anexo 1 (cuadro no.11 y no.12), del caso de uso que se muestra a
continuación.
50
7.- Lista de gestiones
El siguiente gráfico nos muestra, el caso de uso el listado de las gestiones que se
realizan a lo largo del día por medio del sistema, ver anexo 1 (cuadro no.17, no.18,
no.19 y no.20), del caso de uso que se muestra a continuación.
51
9.- Detalle de gestión
El siguiente gráfico nos muestra, se muestra el detalle de las gestiones que se
soliciten en las ventanillas, ver anexo 1 (cuadro no.23), del caso de uso que se
muestra a continuación.
GRÁFICO N° 20 Detalle de gestión /Caso de uso
52
GRÁFICO N° 22 Enviar correo /Caso de uso
Construcción.
En esta fase se realizó el desarrollo del proyecto web, a continuación, se detallaran los
módulos con una descripción de lo que realiza cada uno de ellos:
53
Este módulo fue desarrollado con el fin de crear y gestionar todos los requerimientos
que pueden ser realizados por las ventanillas de la Dirección de Gestión Tecnológica
de la Información de la Universidad de Guayaquil. A su vez, desde aquí, se maneja el
submódulo para la creación de las fases correspondientes para cada uno de los
requerimientos creados previamente.
54
GRÁFICO N° 25 Módulo estadístico
55
GRÁFICO N° 26 Seguimiento de requerimientos
Tiempos de Desarrollo
56
Transición.
• Se realiza la presentación del producto final con los directores de las áreas
interesadas para recibir su aprobación.
57
CRITERIOS DE VALIDACIÓN DE LA PROPUESTA
Para determinar los criterios de validación del presente proyecto, se elaboró una
entrevista, que servirá para determinar el nivel de la aceptación del usuario del sistema
frente al aplicativo web, se realizó un total de 13 preguntas, clasificadas en cuatro
grupos, Usabilidad, Funcionalidad, Confiabilidad, Eficiencia.
La presente entrevista tiene como objetivo, medir la satisfacción del usuario final con
respecto al producto final, que se llevará a cabo como piloto en las instalaciones de la
Dirección de Gestión Tecnológica de la Información.
El proyecto como tal es muy importante ya que con él se puede tener un control
acerca de todas las peticiones que llegan a la Universidad de Guayaquil en cada una
de las áreas.
58
2. ¿Cómo cree usted que el proyecto de “Control y monitoreo de requerimientos
dirigidos hacia la dirección”, mejorará la gestión de los requerimientos en las
ventanillas Única de la Universidad de Guayaquil?
Pienso que sí, porque anteriormente existía un sistema que brindaba un poco esta
funcionalidad pero que fue retirado porque no era completo, y sería bastante
importante ya que las personas tendrían a la mano toda esa información en cada
requerimiento de cada solicitud.
En realidad sí, ya que el sistema es bastante sencillo y completo, cumple con todas las
especificaciones para lograr un nivel de satisfacción y comodidad en el usuario al
hacer uso de este.
5. ¿Al observar la ejecución de la aplicación, está de acuerdo a que este sigue los
lineamientos respectivos al concepto de ventanilla única?
Sí, sigue todas las definiciones propias de una ventanilla únicas y los flujos.
6. ¿Qué opinión tiene usted acerca del proyecto de ventanilla única enfocado como
producto final?
59
Es de bastante agrado y de aceptación por parte de los usuarios de ventanillas
secretarios o recepcionistas, ya que en su defecto van a saber los pasos de cada
requerimiento y van a poder brindar esa información a los solicitantes.
7. ¿Cree usted que el sistema ha sido elaborado de tal forma que sea entendible
para los usuarios finales?
El proyecto tiene como plan, tener todos los procesos captados dentro de un sistema y
que a su vez cada requerimiento solicitado sea atendido mediante los pasos o fases
definidos en el mismo.
60
12. ¿Opina usted que las mejoras en el tiempo de gestión de los requerimientos son
importantes para la satisfacción de los usuarios de las ventanillas únicas?
Sí, porque de esta manera podemos tener una idea real de los tiempos que toman
cada uno de los requerimientos y a su vez brindar esta información a nuestros
solicitantes.
Sí, porque es muy necesario el uso de notificaciones dentro del sistema, para
mantener siempre informado al usuario sobre el estado de los requerimientos que
tenga asignados
Conclusión de la entrevista
Como conclusión de la entrevista realizada al líder de proyectos de la Dirección de
Gestión Tecnológica de la Información, se puede determinar que este proyecto es
necesario e importante para la Universidad de Guayaquil, beneficiará al personal
administrativo como al usuario solicitante, también se obtuvo como respuesta en la
entrevista que el producto final es de calidad y que es aceptado por el personal del
área, y que además ayudara en los proceso de los requerimientos para que se lleven
de una mejor manera.
Este proyecto cumple con todas las especificaciones para lograr un nivel de
satisfacción en el usuario final, y se visualiza en el futuro como un sistema que pueda
ser utilizado en todas las áreas de la Universidad de Guayaquil.
61
CAPÍTULO IV
Para que el proyecto cumpla con las bases para la aceptación el proyecto debe
cumplir con las fases de la metodología aplicada, de esta manera se demuestra que
se cumplió de forma concreta con las definiciones y con cada etapa para el desarrollo
de esta nueva herramienta, a continuación, en el cuadro no.12 muestra cada una de
las etapas y el nivel de cumplimiento de cada una de estas.
Concepción 100%
Elaboración 100%
Construcción 100%
Transición 100%
Para que el sistema cuente con la aceptación del usuario, se cumplió todos los
requerimientos establecidos al inicio del proyecto, según este alcance a continuación
se muestra una tabla con los criterios de aceptación que se tuvo en cada una de estos
requerimientos.
62
CUADRO N° 13 Criterios de aceptación
CRITERIOS DE ACEPTACIÓN
Descripción del Criterios de aceptación Nivel de
requerimiento cumplimiento
Contará con un módulo • Indicar las fases totales del proyecto con
para que el usuario que su respectivo estado (concluido,
solicita una gestión pueda pendiente, en curso).
ingresar y observar en qué • Mostrar información del requerimiento 100%
parte del proceso se como, nombre del requerimiento,
encuentra este, pudiendo nombre del solicitante, resultado de la
así saber si este ya obtuvo gestión.
una solución oportuna. • Código QR que servirá de identificador
del usuario solicitante.
63
definición de los procesos.
64
Conclusiones
65
Recomendaciones
66
BIBLIOGRAFÍA
67
ANEXOS
CRITERIOS DE ACEPTACIÓN
Nombre de la tarea Inicio Fin Recursos
68
documento de tesis Paladines
Fuente: Propia
69
Anexo No.2: Entrevista con el líder de proyectos del DGTI.
Universidad de Guayaquil
Facultad de Ciencias Matemáticas y Físicas
Carrera de Ingeniería en Sistemas
Tema: SISTEMA WEB DE CONTROL Y MONITOREO DE REQUERIMIENTOS
DIRIGIDOS HACIA LA DIRECCIÓN DE GESTIÓN TECNOLÓGICA DE LA
INFORMACIÓN DE LA UNIVERSIDAD DE GUAYAQUIL, COMO PARTE DEL
PROCESO DE GESTIÓN DE VENTANILLA ÚNICA
La presente entrevista tiene como objetivo, medir la satisfacción del usuario final con
respecto al producto final, que se llevará a cabo como piloto en las instalaciones de la
Dirección de Gestión Tecnológica de la Información.
70
2. ¿Cómo cree usted que el proyecto de “Control y monitoreo de requerimientos
dirigidos hacia la dirección”, mejorará la gestión de los requerimientos en las
ventanillas Única de la Universidad de Guayaquil?
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
5. ¿Al observar la ejecución de la aplicación, está de acuerdo a que este sigue los
lineamientos respectivos al concepto de ventanilla única?
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
6. ¿Qué opinión tiene usted acerca del proyecto de ventanilla única como producto
final?
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
7. ¿Cree usted que el sistema ha sido elaborado de tal forma que sea entendible
para los usuarios finales?
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
71
8. ¿Tiene claro el objetivo del proyecto de gestión de requerimientos de las
ventanillas únicas?
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
12. ¿Opina usted que las mejoras en el tiempo de gestión de los requerimientos son
idóneas para la satisfacción de los usuarios de las ventanillas únicas?
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
72
Anexo No.3: Especificaciones de casos de uso del sistema.
Prioridad Esencial
Frecuencias de uso Siempre
Reglas de negocio
Requisitos especiales
Asunciones
Notas
Fuente: Propia
73
CUADRO Nº 2 - Especificaciones Cerrar sesión
Nombre
Inicio de sesión / Cerrar sesión
Paquete
Gestionar sesiones
Creado por Katherine Yager
Andrés Paladines Actualizado por Katherine Yager
Fecha de creación
12/03/2017 Última actualización 14/04/2017
Actores
Usuarios en general
Descripción
Cierra la sesión el el sistema
Disparador
Pre condiciones
Que el usuario tenga una sesión activa en el sistema
Post condiciones
Excepciones
Estas credenciales no coinciden con nuestros registros
Inclusiones
Prioridad
Esencial
Frecuencias de uso
Siempre
Reglas de negocio
Requisitos especiales
Asunciones
Notas
Fuente: Propia
74
CUADRO Nº 3 - Especificaciones Crear nuevo requerimiento
Nombre
Lista de requerimientos / Crear nuevo requerimiento
Paquete
Requerimientos
Creado por Katherine Yager
Andrés Paladines Actualizado por Katherine Yager
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Administrador
Descripción
Se presentará la ventana para crear un nuevo requerimiento
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones administrador
Post
condiciones
Flujo normal 1. El usuario da click en el botón para crear un nuevo requerimiento
2. Se abre una nueva ventana
Flujo
alternativo
Excepciones En el caso de que el usuario no realice ningún tipo de interacción con
la ventana, la sesión automáticamente caducará por lo que el usuario
nuevamente tendrá que iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias
de uso Cada vez que se necesite agregar un nuevo requerimiento al sistema
Reglas de
negocio
Requisitos
especiales
Asunciones
Notas
Fuente: Propia
75
CUADRO Nº 4 - Especificaciones Lista de requerimientos / Detalle
Nombre
Lista de requerimientos / Detalle
Paquete
Requerimientos
Creado por Katherine Yager
Andrés Paladines Actualizado por Katherine Yager
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Administrador
Descripción
Se presentará la información detallada del requerimiento
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones administrador
Post
condiciones
Flujo normal 1. El usuario da click en el botón
2. Se abre una nueva ventana que mostrará los detalles del
requerimiento
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de Cada vez que se necesite conocer la información detallada del
uso requerimiento por parte del administrador.
Reglas de
negocio
Requisitos
especiales
Asunciones
Notas
Fuente: Propia
76
CUADRO Nº 5 - Especificaciones Lista de requerimientos / Editar
Nombre
Lista de requerimientos / Editar
Paquete
Requerimientos
Creado por Katherine Yager
Andrés Paladines Actualizado por Katherine Yager
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Administrador
Descripción Se presentará la información detallada del requerimiento, pero esta
podrá ser editada y actualizada en la base
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones administrador
Post
condiciones
Flujo normal 1. El usuario da click en el botón
2. Se abre una nueva ventana que mostrará la pantalla de edición
del requerimiento
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de Cada vez que se necesite editar la información detallada del
uso requerimiento por parte del administrador.
Reglas de
negocio
Requisitos
especiales
Asunciones
Notas
Fuente: Propia
77
CUADRO Nº 6 - Especificaciones Lista de requerimientos / Fases
Nombre
Lista de requerimientos / Fases
Paquete
Requerimientos
Creado por Katherine Yager
Andrés Paladines Actualizado por Katherine Yager
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Administrador
Descripción Se presentará la una lista de todas las fases vinculadas a este
requerimiento
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones administrador
Post
condiciones
Flujo normal 1. El usuario da click en el botón
2. Se abre una nueva ventana que mostrará la lista de fases para el
requerimiento seleccionado
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de Cada vez que se necesite conocer la información detallada del
uso requerimiento por parte del administrador
Reglas de
negocio
Requisitos
especiales
Asunciones
Que el requerimiento esté creado
Notas
Fuente: Propia
78
CUADRO Nº 7 - Especificaciones Lista de requerimientos / Eliminar
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones administrador
Post
condiciones
Flujo normal 1. El usuario da click en el botón
2. Se presenta un mensaje para confirmación del requerimiento
3. Se acepta y se elimina.
Flujo
alternativo 1. Se cancela y no se realizan cambios
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de Cada vez que se necesite eliminar un requerimiento por parte del
uso administrador
Reglas de El requerimiento no debería poder ser eliminado si ya se han
negocio realizado gestiones con este
Requisitos
especiales
Asunciones
Que el requerimiento esté creado
Notas
Fuente: Propia
79
CUADRO Nº 8 - Especificaciones Ingresar nuevo requerimiento / Guardar
Nombre
Ingresar nuevo requerimiento / Guardar
Paquete
Requerimientos
Creado por Katherine Yager
Andrés Paladines Actualizado por Katherine Yager
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Administrador
Descripción
En esta ventana se realiza la creación de un nuevo requerimiento
Disparador Una vez creado el requerimiento, se retorna a la lista de
requerimientos y una alerta nos indica que este se ha creado
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones administrador
Post
condiciones
Flujo normal 1. El usuario da click en el botón para crear un nuevo requerimiento
2. Se abre una nueva ventana
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso Cada vez que se necesite agregar un nuevo requerimiento al sistema
Reglas de
negocio
Requisitos
especiales
Asunciones
Notas
Fuente: Propia
80
CUADRO Nº 9 - Especificaciones Ingresar nuevo requerimiento / Regresar
Nombre
Ingresar nuevo requerimiento / Regresar
Paquete
Requerimientos
Creado por Katherine Yager
Andrés Paladines Actualizado por Katherine Yager
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Administrador
Descripción
Nos retorna a la lista de requerimientos
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones administrador
Post
condiciones
Flujo normal 1. El usuario da click en el botón para regresar
2. Se presenta nuevamente la lista de requerimientos
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones
Notas
Fuente: Propia
81
CUADRO Nº 10 - Especificaciones Detalle requerimiento / Regresar
Nombre
Detalle de requerimiento / Regresar
Paquete
Requerimientos
Creado por Katherine Yager
Andrés Paladines Actualizado por Katherine Yager
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Administrador
Descripción
Nos retorna a la lista de requerimientos
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones administrador
Post
condiciones
Flujo normal 1. El usuario da click en el botón para regresar
2. Se presenta nuevamente la lista de requerimientos
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones
Notas
Fuente: Propia
82
CUADRO Nº 11 - Especificaciones Edición del requerimiento/Guardar
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones administrador
Post
condiciones
Flujo normal 1. Se realizan los cambios necesarios
2. El usuario da click en el botón para guardar
3. Se retorna a la lista de requerimientos
4. Se presenta mensaje indicando que el requerimiento se
actualizó
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana,
la sesión automáticamente caducará por lo que nuevamente
tendrá que iniciar sesión
Inclusiones
Prioridad Esencial
Frecuencias
de uso Cuando se necesite editar la información de un requerimiento
Reglas de
negocio
Requisitos
especiales
Asunciones
Notas
Fuente: Propia
83
CUADRO Nº 12 - Especificaciones Edición del requerimiento / Regresar
Nombre
Edición de requerimiento / Regresar
Paquete
Requerimientos
Creado por Katherine Yager
Andrés Paladines Actualizado por Katherine Yager
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Administrador
Descripción
Nos retorna a la lista de requerimientos
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones administrador
Post
condiciones
Flujo normal 1. El usuario da click en el botón para regresar
2. Se presenta nuevamente la lista de requerimientos
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones
Notas
Fuente: Propia
84
CUADRO Nº 13 - Especificaciones Lista de fases por requerimiento /
Guardar
Nombre
Lista de fases por requerimiento / Guardar
Paquete
Requerimientos / Fases
Creado por Katherine Yager
Andrés Paladines Actualizado por Andrés Paladines
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Administrador
Descripción Se realizará el guardado de la información previamente insertada en
los campos vacíos
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones administrador
Post
condiciones
Flujo normal 1. El usuario da click en el botón
2. Se abre una nueva ventana que mostrará la lista de fases para el
requerimiento seleccionado
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de Cada vez que se necesite conocer la información detallada del
uso requerimiento por parte del administrador
Reglas de
negocio
Requisitos
especiales
Asunciones
Que el requerimiento esté creado
Notas
Fuente: Propia
85
CUADRO Nº 14 - Especificaciones Lista de fases por requerimiento /
Editar
Nombre
Lista de fases por requerimiento / Editar
Paquete Requerimientos / Fases
Creado por Katherine Yager
Andrés Paladines Actualizado por Andrés Paladines
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores Administrador
Descripción Se actualizan los datos respectivos de una fase
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones administrador
Post
condiciones
Flujo normal 1. El usuario da click en el botón editar
2. Se cargan los datos de la fase en los campos de la izquierda
3. Se modifican
4. Se presiona el botón guardar y se actualizan en base
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá
que iniciar sesión
Inclusiones
Prioridad Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones Que el requerimiento esté creado
Notas
Fuente: Propia
86
CUADRO Nº 15 - Especificaciones Lista de fases por requerimiento /
Eliminar
Nombre
Lista de fases por requerimiento / Eliminar
Paquete
Requerimientos / fases
Creado por Katherine Yager
Andrés Paladines Actualizado por Andrés Paladines
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Administrador
Descripción
Se realiza la eliminación de una fase
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones administrador
Post
condiciones
Flujo normal 1. El usuario da click en el botón eliminar
2. Se presenta un mensaje de confirmación
3. Se acepta y se elimina la fase
Flujo 1. El usuario da click en el botón eliminar
alternativo 2. Se presenta un mensaje de confirmación
3. Se cancela y causar cambios
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones
Que el requerimiento esté creado
Notas
Fuente: Propia
87
CUADRO Nº 16 - Especificaciones Lista de fases por requerimiento /
Regresar
Nombre
Lista de fases por requerimiento / Regresar
Paquete
Requerimientos
Creado por Katherine Yager
Andrés Paladines Actualizado por Katherine Yager
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Administrador
Descripción
Nos retorna a la lista de requerimientos
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones administrador
Post
condiciones
Flujo normal 1. El usuario da click en el botón para regresar
2. Se presenta nuevamente la lista de requerimientos
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones
Notas
Fuente: Propia
88
CUADRO Nº 17 - Especificaciones Lista de gestiones / Nueva gestión
Nombre
Lista de gestiones / Nueva gestión
Paquete
Gestiones
Creado por Katherine Yager
Andrés Paladines Actualizado por Andrés Paladines
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Funcionario
Descripción
Muestra la vista para crear una nueva gestión
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones funcionario
Post
condiciones
Flujo normal 1. El usuario da click en el botón de nueva gestión
2. Pasará a la vista para creación de una nueva gestión
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones
Que el requerimiento esté creado
Notas
Fuente: Propia
89
CUADRO Nº 18 - Especificaciones Lista de gestiones / Detalle
Nombre
Lista de gestiones / Detalle
Paquete
Gestiones
Creado por Katherine Yager
Andrés Paladines Actualizado por Andrés Paladines
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Funcionario
Descripción
Muestra una vista con la información detallada de la gestión
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones funcionario
Post
condiciones
Flujo normal 1. El usuario da click en el botón de detalle
2. Pasará a la vista de detalle de gestión
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones
Que el requerimiento esté creado
Notas
Fuente: Propia
90
CUADRO Nº 19 - Especificaciones Lista de gestiones / Gestionar
Nombre
Lista de gestiones / Gestionar
Paquete
Gestiones
Creado por Katherine Yager
Andrés Paladines Actualizado por Andrés Paladines
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Funcionario
Descripción
Muestra la vista para crear una nueva gestión
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones funcionario
Post
condiciones
Flujo normal 1. El usuario da click en el botón gestionar
2. Pasará a la vista para editar los datos de la gestión de una
gestión
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones
Que el requerimiento esté creado
Notas
Fuente: Propia
91
CUADRO Nº 20 - Especificaciones Lista de gestiones / Gestionar
Nombre
Lista de gestiones / Generar ticket
Paquete
Gestiones
Creado por Katherine Yager
Andrés Paladines Actualizado por Andrés Paladines
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Funcionario
Descripción
Muestra la vista para generación de un nuevo ticket
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones funcionario
Post
condiciones
Flujo normal 1. El usuario da click en el botón de generar ticket
2. Pasará a la vista para generación de ticket
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones
Que el requerimiento esté creado
Notas
Fuente: Propia
92
CUADRO Nº 21 - Especificaciones Creación de gestión / Guardar
Nombre
Creación de gestión / Guardar
Paquete
Gestiones
Creado por Katherine Yager
Andrés Paladines Actualizado por Andrés Paladines
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Funcionario
Descripción
Realiza la creación de una nueva gestión
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones funcionario
Post
condiciones
Flujo normal 1. Se ingresan los datos respectivos
2. El usuario da click en el botón de guardar
3. El sistema guarda los datos
4. Regresa a la lista de gestiones
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones
Que exista al menos un tipo de requerimiento creado
Notas
Fuente: Propia
93
CUADRO Nº 22 - Especificaciones Creación de gestión / Regresar
Nombre
Creación de gestión / Regresar
Paquete
Requerimientos
Creado por Katherine Yager
Andrés Paladines Actualizado por Katherine Yager
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Administrador
Descripción
Se retorna a la lista de requerimientos
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones funcionario
Post
condiciones
Flujo normal 1. El usuario da click en el botón para regresar
2. Se presenta nuevamente la lista de gestiones
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones
Notas
Fuente: Propia
94
CUADRO Nº 23 - Especificaciones Detalle de gestión / Regresar
Nombre
Detalle de gestión / Regresar
Paquete
Requerimientos
Creado por Katherine Yager
Andrés Paladines Actualizado por Katherine Yager
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Administrador
Descripción
Se retorna a la lista de requerimientos
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones funcionario
Post
condiciones
Flujo normal 1. El usuario da click en el botón para regresar
2. Se presenta nuevamente la lista de gestiones
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones
Notas
Fuente: Propia
95
CUADRO Nº 24 - Especificaciones Enviar correo / Enviar
Nombre
Generación de ticket / Generar ticket
Paquete
Gestiones
Creado por Katherine Yager
Andrés Paladines Actualizado por Andrés Paladines
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Funcionario
Descripción
Realiza la generación del envío de correo.
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones funcionario
Post
condiciones
Flujo normal 1. El usuario da click en el botón de enviar
2. Se información de la gestiónenviará por correo electrónico al
solicitante.
3. Se retorna a la lista de gestiones
4. Se presenta mensaje de correo enviado
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones
Que el requerimiento esté creado
Notas
Fuente: Propia
96
CUADRO Nº 25 - Especificaciones Enviar correo / Regresar
Nombre
Enviar correo / Regresar
Paquete
Gestiones
Creado por Katherine Yager
Andrés Paladines Actualizado por Andrés Paladines
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Funcionario
Descripción
Regresa al listado de gestiones
Disparador
Pre Que el usuario tenga una sesión abierta y que tenga el rol de
condiciones funcionario
Post
condiciones
Flujo normal 1. Se presiona el botón de regresar
2. Se presenta la vista con la lista de gestiones
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá que
iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones
Notas
Fuente: Propia
97
CUADRO Nº 26 - Especificaciones Seguimiento de gestiones/ Ver
Nombre
Seguimiento de getiones / Regresar
Paquete
Gestiones
Creado por Katherine Yager
Andrés Paladines Actualizado por Andrés Paladines
Fecha de
creación 12/03/2017 Última actualización 14/04/2017
Actores
Usuario solicitante
Descripción Permite visualizar las fases y el resultado de gestión de lo solicitado
en las ventanillas únicas.
Disparador
Pre
condiciones Que el usuario de click en el link enviado al correo.
Post
condiciones
Flujo normal
1.-Se presenta la vista con la lista de gestiones
Flujo
alternativo
Excepciones Si el usuario no realiza ningún tipo de interacción con la ventana, la
sesión automáticamente caducará por lo que nuevamente tendrá
que iniciar sesión
Inclusiones
Prioridad
Esencial
Frecuencias de
uso
Reglas de
negocio
Requisitos
especiales
Asunciones
Notas
Fuente: Propia
98
Anexo No.4: Actas de reunión con personal de DGTI.
Fuente: Propia
99
Elaboración: Andrés Paladines García – Katherine Yager Velarde
Fuente: Propia
100
Elaboración: Andrés Paladines García – Katherine Yager Velarde
Fuente: Propia
101
Elaboración: Andrés Paladines García – Katherine Yager Velarde
Fuente: Propia
102
Elaboración: Andrés Paladines García – Katherine Yager Velarde
Fuente: Propia
103
Elaboración: Andrés Paladines García – Katherine Yager Velarde
Fuente: Propia
104
Elaboración: Andrés Paladines García – Katherine Yager Velarde
Fuente: Propia
105
Elaboración: Andrés Paladines García – Katherine Yager Velarde
Fuente: Propia
106
Anexo No.5: Acta de recepción y aprobación de código fuente del proyecto.
107
Anexo No.6: Acta de entrega y recepción definitiva.
108
Anexo No.7: Carta de Implementación.
109
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
MANUAL DE USUARIO
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
ÍNDICE
INTRODUCCIÓN............................................................................................................ 3
SISTEMA WEB DE CONTROL Y MONITOREO DE REQUERIMIENTOS. ...... 3
Menú principal. .............................................................................................................. 4
Administración de Requerimientos ............................................................................... 5
Listado de Requerimientos............................................................................. 5
Ingresar Requerimiento................................................................................... 6
Detalle de Requerimiento ............................................................................... 6
Editar Requerimiento ......................................................................................... 7
Fases del Requerimiento ................................................................................. 7
Listado de las fases de los requerimientos .......................................... 9
Gestión de Requerimientos ......................................................................................... 10
Ingresar Gestión ................................................................................................. 11
Detalle de la Gestión ........................................................................................ 11
Gestionar Requerimiento .............................................................................. 12
Enviar Correo ........................................................................................................ 12
Historial ................................................................................................................... 13
Estadísticas ............................................................................................................ 14
Seguimiento del requerimiento ................................................................. 15
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
INTRODUCCIÓN.
El presente manual tiene como objetivo mostrar de forma detallada las funcionalidades y
características del actual sistema de SISTEMA WEB DE CONTROL Y MONITOREO DE
REQUERIMIENTOS, permite visualizar la interfaz gráfica con que el usuario interactúa y su
operatividad, ya que en él se explica detalladamente las estructuras de las pantallas, así
como las funciones básicas.
Por consiguiente, el usuario obtendrá información valiosa que le permitirá aprovechar
todas las bondades que le ofrece el Sistema.
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
Menú principal.
Una vez dentro del sistema el usuario observará el menú principal en donde constatará
en una de las pestañas la descripción de “Monitoreo de Gestiones”, a la que se deberá
dar click para observar sus respectivos módulos, como podremos observar a
continuación:
Sistema de Control y
Monitoreo de Gestiones
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
Administración de Requerimientos
En esta sección se podrá administras todo aquello referente a los requerimientos y sus
fases que intervienen hasta dar solución a la petición del usuario solicitante.
Listado de Requerimientos
Ingreso de nuevo
Editar requerimiento requerimiento. Descripción del
Ver detalle del
requerimiento ingresado. requerimiento.
ingresado en el
sistema.
Tiempo configurado
Configurar fases. Eliminar del requerimiento.
requerimiento.
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
Ingresar Requerimiento
Pantalla en la que se configura el requerimiento con su respectiva descripción.
Regresar a la Guardar el
pantalla anterior. requerimiento.
Ingresar descripción del
requerimiento.
Detalle de Requerimiento
Opción para visualizar datos como nombre y descripción del requerimiento.
Descripción del
Nombre del requerimiento. Regresar a la pantalla
requerimiento. anterior.
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
Editar Requerimiento
Opción para visualizar editar los datos del requerimiento.
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
Nombre del
requerimiento.
Nombre de la
fase
Descripción de
la fase.
En esta opción se podrán crear todas las fases que intervienen en la gestión de un
requerimiento, con su respectivo tiempo, que indicara la finalización de cada fase.
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
Gestión de Requerimientos
En esta sección se realizará la gestión de los requerimientos dirigidos a la Dirección de
gestión tecnológica de la información.
Ingresar nueva
gestión.
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
Ingresar Gestión
Detalle de la Gestión
Descripción de
la Gestión.
Nombre del
requerimiento
Nombre del
usuario
solicitante
Correo del
Regresar a la pantalla usuario
anterior. solicitante.
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
Gestionar Requerimiento
En esta opción se realizarán todos los movimientos que intervienen para la resolución
de una petición hecha por los usuarios en ventanilla.
Fase siguiente
y usuario al
que se va a
derivar.
Historial
de fases.
Observac
ión de la
fase
gestiona
Sumilla
da.
de la
fase
gestiona
da.
Estado de
la fase.
Búsqueda de Regresar a la pantalla Guardar gestión de
documento asociado anterior. la fase.
al requerimiento.
Enviar Correo
Envío de correo con datos de la gestión a los usuarios finales.
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
Nombre del
requerimie
nto.
Nombre
del
solicitante.
Correo del
solicitante.
Historial
En esta opción se podrá visualizar todos los requerimientos solicitados por ventanillas
únicas, por medio de filtros como:
-Número de documento
-Descripción
-Solicitante
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
Fecha inicio de
gestión.
Fecha fin de
gestión.
Buscar en el
historial.
Estadísticas
Opción que permite observar datos con respecto a las gestiones realizadas en el
transcurso del año.
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
Gestiones
realizadas en el
mes.
Porcentaje total
de
requerimientos
solicitados.
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
MANUAL DE USUARIO Pág.
DE REQUERIMIENTOS
Código QR para
Imprimir observar información
información del del requerimiento.
requerimiento.
Nombre del
requerimiento.
Nombre del
solicitante.
Descripción
del
requerimiento
.
Descripción
de la
gestión.
Resultado de
la gestión.
Fecha de
Elaborado Por Conformado Por Aprobado Por
Aprobación
Katherine Yager/Andrés Día Mes Año
Paladines
UNIVERSIDAD DE GUAYAQUIL
MANUAL TÉCNICO
Previa a la obtención del Título de:
TUTOR:
Ing. Erick González Linch M Sc.
GUAYAQUIL – ECUADOR
2017
ÍNDICE GENERAL
ÍNDICE DE CUADROS ............................................................................................... 3
ÍNDICE DE GRÁFICOS.............................................................................................. 3
MANUAL TÉCNICO ................................................................................................... 4
PÁGINA WEB REQUERIMIENTOS .................................................................... 4
INTRODUCCIÓN ...................................................................................................... 4
BASE DE DATOS .................................................................................................... 4
DICCIONARIO DE DATOS .................................................................................... 4
ESTRUCTURA DE LAS TABLAS ........................................................................ 9
NOMENCLATURAS DE LOS OBJETOS UTILIZADOS ................................ 10
TABLAS .............................................................................................................. 10
CAMPOS ............................................................................................................. 10
SCRIPTS DE CREACIÓN PARA LAS TABLAS ............................................. 10
ESTRUCTURACIÓN DE LA TABLA REQUERIMIENTO .......................... 10
ESTRUCTURACIÓN DE LA TABLA REQUERIMIENTO_FASES ........... 11
ESTRUCTURACIÓN DE LA TABLA REQUERIMIENTO_GESTION ...... 12
ESTRUCTURACIÓN DE LA TABLA MOVIMIENTOS_GESTION ............ 12
ARQUITECTURA DE LA PÁGINA WEB .......................................................... 14
DETALLE SOBRE LA FUNCIONALIDAD DEL SISTEMA ............................ 15
CÓDIGO FUENTE DE LA APLICACIÓN .......................................................... 15
REQUERIMIENTOS MÍNIMOS DE HARDWARE ............................................ 15
REQUERIMIENTOS MÍNIMOS DE SOFTWARE ............................................. 16
CASOS DE USO DEL SISTEMA ........................................................................ 16
CÓDIGO FUENTE DEL SISTEMA .................... ¡Error! Marcador no definido.
ÍNDICE DE CUADROS
ÍNDICE DE GRÁFICOS
GRÁFICO N° 1 - Estructura de las tablas del sistema .............................................. 9
GRÁFICO N° 2 - Arquitectura .................................................................................. 14
GRÁFICO N° 3 - Función general del sistema ......................................................... 16
GRÁFICO N° 4 - Inicio de sesión/Caso de uso ......................................................... 17
GRÁFICO N° 5 - Lista de requerimientos/Caso de uso .......................................... 17
GRÁFICO N° 6 - Ingresar nuevo requerimiento/Caso de uso ............................... 18
GRÁFICO N° 7 - Detalle de requerimiento/Caso de uso ........................................ 18
GRÁFICO N° 8 - Edición del requerimiento/Caso de uso ...................................... 19
GRÁFICO N° 9 - Lista de fases por requerimiento /Caso de uso .......................... 19
GRÁFICO N° 10 - Lista de gestiones /Caso de uso .................................................. 20
GRÁFICO N° 11 - Creación de gestión /Caso de uso .............................................. 20
GRÁFICO N° 12 - Detalle de gestión /Caso de uso .................................................. 21
GRÁFICO N° 13 - Enviar correo /Caso de uso ........................................................ 21
GRÁFICO N° 14 - Enviar correo /Caso de uso ........................................................ 21
MANUAL TÉCNICO
INTRODUCCIÓN
BASE DE DATOS
La base de datos manipulada a través del sistema web tiene por nombre “modulos” y
su motor de base de datos es SQL Server 2008 R2, cuya estructura se detalla a
continuación.
DICCIONARIO DE DATOS
DICCIONARIO DE DATOS
BASE DE DATOS: MODULOS
ESQUEMA: MONITOREO GESTIONES
1 id Id del PK int no
requerimiento
DICCIONARIO DE DATOS
BASE DE DATOS: MODULOS
ESQUEMA: MONITOREOGESTIONES
1 id Id de la fase PK int no
1 Id Id del PK int no
requerimiento
DICCIONARIO DE DATOS
BASE DE DATOS: MODULOS
ESQUEMA: MONITOREOGESTIONES
1 id Id del PK int no
requerimiento
3 id_fases FK Int no
4 id_gestion FK Int no
5 usuario_crea nvarchar(25) no
6 usuario_destino nvarchar(25) no
7 usuario_origen nvarchar(25) no
8 usuario_tarea_pendiente nvarchar(25) no
9 sumillado nvarchar(300) no
10 observacion nvarchar(300) no
TABLAS
Los nombres de las tablas han sido escritos en formato “CamelCase”, mostrando una
descripción de lo que se va a manejar en ese campo, seguido por un guion bajo y
luego una descripción en minúsculas de la tabla hija, en caso de que esta exista.
Un ejemplo, es la tabla Requerimiento, esta tabla guarda los datos referentes a un tipo
de requerimiento gestionable por el aplicativo.
CAMPOS
Son los nombres de las columnas, estos se escriben en minúsculas, estos indican una
descripción de lo que esta almacenando dicho campo.
Un ejemplo de campo, es el id, este campo es usado en todas las tablas y especifica
el identificador único de cada uno de los registros ingresados en la tabla.
GRÁFICO N° 2 - Arquitectura
Esta aplicación web fue realizada usando contenedor de aplicaciones web Apache,
motor de base de datos MSSQL Server, lenguaje de programación PHP bajo el
framework laravel. Para el desarrollo, fue utilizado el programa PHPStorm.
El framework Laravel ayuda a mantener la parte visible para el usuario (front end) y la
parte que se maneja de manera transparente para el usuario (back end) separadas de
manera eficiente y segura. A su vez, en el back end, se manejan las secciones de las
clases entidad (simbolizan las tablas en la base de datos), clases repositorio
(interactúan entre la base y el controlador) y las clases controlador (intercambian
información entre el back end y el front end).
La estructura de este framework, ayuda a la elaboración de la aplicación de manera
colaborativa, mejorando los tiempos de desarrollo y reduciendo los conflictos que se
puedan crear.
Este sistema web está diseñado para satisfacer el uso de múltiples roles, dependiendo
del rol que tenga el usuario, la interfaz se encargara de mostrar las opciones
correspondientes a dicho rol.
En este desarrollo, los usuarios utilizados, tienen 3 roles principales; Administrador,
funcionario y usuario externo.
El usuario administrador, se encarga de crear las plantillas para los requerimientos que
se crearán cada vez que se ingrese una solicitud.
El usuario funcionario, es aquel usuario que recibe las solicitudes y las procesa en el
sistema.
El usuario externo, es el solicitante, aquella persona que entrega un documento o
solicitud a un funcionario. Este usuario tendrá una opción para la visualización sobre
estado de su requerimiento.