ERS

CONTROL DE VERSIÓN
4

Versió Fecha Descripción Autor

n

v1.0 21/05/2025 Creado Alejandro Jaime Chaguay

Danna Guallan Cepeda
José Chimbolema Zuñiga
Katherine Farez Tigreros
V2.0 21/05/2025 revisado Danna Guallan Cepeda
José Chimbolema Zuñiga
Katherine Farez Tigreros
Alejandro Jaime Chaguay
V3.0 28/05/2025 editado Alejandro Jaime Chaguay
Danna Guallan Cepeda
José Chimbolema Zuñiga
Katherine Farez Tigreros
V4.0 07/06/2025 editado Alejandro Jaime Chaguay
Danna Guallan Cepeda
José Chimbolema Zuñiga
Katherine Farez Tigreros
V5.0 09/06/2025 revisado Alejandro Jaime Chaguay
Danna Guallan Cepeda
José Chimbolema Zuñiga
Katherine Farez Tigreros
V6.0 27/06/2025 revisado y finalizado Alejandro Jaime Chaguay
Danna Guallan Cepeda
José Chimbolema Zuñiga
Katherine Farez Tigreros

1
 ERS

TABLA DE CONTENIDOS

CONTROL DE VERSIÓN...................................................................................................................1
TABLA DE CONTENIDOS................................................................................................................. 1
1 Requisitos del sistema................................................................................................................ 2
1.1 Introducción..................................................................................................................... 2
1.1.1 Propósito................................................................................................................3
1.1.2 Ámbito del Sistema................................................................................................ 3
1.1.3 Personal involucrado..............................................................................................3
1.1.4 Definiciones, Acrónimos y Abreviaturas.................................................................4
1.1.5 Referencias.............................................................................................................4
1.1.6 Visión General del Documento.................................................................................4
2 Descripción General..................................................................................................................4
2.1 Objetivos del Sistema...................................................................................................... 4
2.1.1 Objetivo General.................................................................................................... 4
2.1.2 Objetivos específicos.............................................................................................. 4

2.2 Perspectiva del producto.................................................................................................5

2.3 Funciones del producto...................................................................................................6
2.4 Características de los Usuarios........................................................................................ 7
2.4.1 Perfil de usuario..................................................................................................... 7
2.4.2 Jerarquía de usuario.............................................................................................. 8
2.5 Restricciones................................................................................................................... 9
2.6 Suposiciones y Dependencias....................................................................................... 10
2.7 Requisitos futuros......................................................................................................... 10
3 Requisitos específicos............................................................................................................ 10
3.1 Interfaces Externas........................................................................................................10
3.1.1 Interfaces de usuario:...........................................................................................10
3.1.2 Interfaces de Hardware:...................................................................................... 11
3.1.3 Interfaces de Software:........................................................................................ 11
3.1.4 Interfaces de Comunicación:................................................................................ 11
¿Cómo se comunicará la aplicación con los datos?........................................................ 11
¿Cómo se comunicará la aplicación con los dispositivos? (Según el caso)..................... 11
3.2 Requerimientos Funcionales (RF)..................................................................................12
3.2.1 Priorización de Requerimientos Funcionales (RF)................................. 14

2
 ERS

3.3 Requerimientos Funcionales (RNF)............................................................................... 15

3.4 Requisitos de Rendimiento............................................................................................16
3.5 Restricciones de Diseño.................................................................................................17
3.6 Atributos del Sistema.................................................................................................... 17
3.7 Otros requisitos............................................................................................................. 17
4 Apéndice...................................................................................................................................17

1​ Requisitos del sistema

1.1​ Introducción

En toda institución pública es importante tener control sobre los procesos que se realizan, ya
que esto ayuda a que todo funcione bien, de forma ordenada y con buena calidad.​
Los procesos son todas las actividades que se hacen para lograr los objetivos de la institución,
y permiten saber cómo está trabajando cada área o departamento.

En el caso de la institución Velasco Ibarra, se ha visto que no hay un sistema adecuado para
gestionar las solicitudes de soporte técnico. Esto provoca retrasos, desorganización y hace
difícil llevar un control de los problemas que se presentan con los equipos, el internet o los
programas que se usan a diario.

Por eso, este proyecto busca desarrollar un sistema web que sirva para que los trabajadores
puedan pedir ayuda técnica fácilmente y el área de soporte pueda atender, organizar y dar
seguimiento a cada caso.​
Este sistema va a ayudar a que las respuestas sean más rápidas, que no se pierda información
y que se pueda llevar un mejor control de todo lo que pasa.

En resumen, se quiere crear una herramienta que facilite el trabajo tanto del personal como de
los técnicos, y que ayude a los jefes a tomar mejores decisiones sobre el uso de la tecnología en
la institución Velasco Ibarra.

1.1.1​ Propósito

El sistema busca optimizar y mejorar la atención del soporte técnico en la institución pública
Velasco Ibarra, facilitando el registro y seguimiento eficiente de las solicitudes de ayuda
técnica, tales como:

3
 ERS

Registro de incidencias: Los usuarios podrán ingresar fácilmente sus problemas relacionados
con equipos, redes o programas, detallando la situación y estableciendo su nivel de urgencia.​
Asignación de tareas: El sistema permitirá distribuir las solicitudes entre los técnicos de
manera automática o manual, según corresponda.​
Control y cierre de casos: Los técnicos tendrán la capacidad de actualizar el estado de cada
solicitud, documentar las acciones realizadas y finalizar los casos cuando estén resueltos.​
Administración de recursos: Se llevará un control de los dispositivos y licencias tecnológicas
disponibles, apoyando así el mantenimiento y la planificación.​
Reportes y análisis: Se generarán informes que mostrarán estadísticas sobre tiempos de
respuesta, tipos de problemas y desempeño del equipo técnico, facilitando la toma de
decisiones.

1.1.2​ Ámbito del Sistema

*Sistema de Soporte Técnico Velasco Ibarra (SSTVI)

*SSTVI será un sistema diseñado para mejorar la gestión y atención de las solicitudes
técnicas en la institución pública Velasco Ibarra, enfocándose en tres objetivos
principales: agilizar la atención de incidencias, optimizar el uso de recursos
tecnológicos y facilitar el acceso a la información sobre el estado de las solicitudes en
tiempo real.​

*Permitirá gestionar todos los aspectos relacionados con el soporte técnico,

incluyendo: registro de reportes de problemas, asignación de casos a técnicos,
seguimiento y actualización de estados, control de inventario de equipos y licencias, y
generación de reportes detallados para el análisis y la toma de decisiones.​

*Los beneficios del sistema serán: mejorar la eficiencia y rapidez en la solución de

problemas técnicos, reducir tiempos de espera y errores en la atención, mantener un
control actualizado de los recursos tecnológicos, y apoyar a los responsables en la
planificación y mejora continua del servicio de soporte técnico

4
 ERS

1.1.3 Personal involucrado

Nombres y Apellidos: Danna Liliana Guallan Cepeda

Rol: Jefa de Proyecto
e-mail: dguallanc@[Link] Teléfono: 0969207851
Instrucción: Ingeniera en Sistemas Computacionales
Tipo: Líder de equipo
Cargo: Jefa de proyecto
Responsabilidades: ●​ Planifica, supervisa, gestiona y controla los recursos
asignados para el desarrollo del proyecto Sistemas de
Soporte Técnico Velasco Ibarra (SSTVI).​

●​ Coordina al equipo de trabajo, asignando tareas y

facilitando una comunicación efectiva entre los
miembros del equipo técnico y administrativo.​

●​ Capacita al equipo de trabajo en metodologías

específicas de soporte técnico y gestión de servicios,
asegurando la correcta aplicación durante todas las
fases del proyecto.​

5
 ERS

●​ Gestiona riesgos asociados a la operación y

continuidad del sistema SSTVI, resolviendo problemas
de forma proactiva y aplicando planes de contingencia
cuando sea necesario.​

●​ Monitorea el avance y la calidad del proyecto SSTVI,

evaluando el cumplimiento de los requisitos técnicos y
funcionales mediante seguimientos continuos y
reportes de avance.​

●​ Se asegura de que el sistema cumpla con los estándares

de servicio y soporte técnico requeridos por la
institución Velasco Ibarra, aportando a la mejora
continua del mismo.

Nombres y Apellidos: Katherine Angelina Farez Tigreros

Rol: Analista de Requerimientos
e-mail: kfarezt@[Link] Teléfono: 0986397678
Instrucción: Ingeniera en Sistemas
Tipo: Equipo Técnico
Cargo: Analista de Requerimientos
Responsabilidades:
●​ Colabora en la planificación del proyecto Sistemas de
Soporte Técnico Velasco Ibarra (SSTVI), aportando
desde el análisis de requerimientos técnicos y
funcionales.​

●​ Identifica, recopila y analiza las necesidades de los

usuarios (stakeholders), asegurando que el sistema
cumpla con las expectativas y requerimientos reales.​

●​ Trabaja con los miembros clave del equipo y las partes

interesadas para alinear los objetivos del proyecto con
las metas institucionales, garantizando una estrategia
de gestión lógica y eficiente.​

●​ Apoya la toma de decisiones mediante el análisis de

datos, evaluación de alternativas e identificación de

6
 ERS

oportunidades de mejora dentro del sistema.​

●​ Elabora especificaciones detalladas sobre los requisitos

funcionales (qué debe hacer el sistema) y no
funcionales (cómo debe hacerlo), proporcionando
documentación clara y precisa.​

●​ Verifica que los requisitos definidos sean correctos,

completos, consistentes y comprensibles para todo el
equipo técnico involucrado en el desarrollo.

Nombres y Apellidos: Jose Francisco Chimbolema Zuñiga

Rol: Desarrollador de Software
e-mail: jchimbolemaz@[Link] Teléfono: 0958734743
Instrucción: Ingeniero de Software
Tipo: Equipo Técnico
Cargo: Desarrollador de Software
Responsabilidades: ●​ Diseñar, desarrollar y mantener las funcionalidades
del sistema Sistemas de Soporte Técnico Velasco Ibarra
(SSTVI), enfocándose en la lógica de negocio y la
arquitectura del backend.​

●​ Crear y administrar bases de datos relacionales y/o no

relacionales, asegurando la integridad, seguridad y
rendimiento de los datos.​

●​ Desarrollar APIs eficientes y seguras para garantizar

una correcta comunicación entre el frontend y el
backend del sistema.​

●​ Realizar pruebas unitarias y de integración, así como

depuración de errores en el código backend,
asegurando un funcionamiento estable y libre de
fallos.​

●​ Documentar el código desarrollado, facilitando su

comprensión y mantenimiento por parte del equipo

7
 ERS

técnico.​

●​ Colaborar con el equipo de analistas, diseñadores y

testers para asegurar que los requerimientos
funcionales y no funcionales se implementen
correctamente.

Nombres y Apellidos: Andres cepeda

Rol: Especialista en Pruebas y Soporte Técnico
e-mail: [Link]@[Link] Teléfono: 0978866748
Instrucción: Ingeniero en Sistemas
Tipo: Equipo Técnico
Cargo: Especialista en Pruebas y Soporte Técnico
Responsabilidades: ●​ Atender de manera oportuna y eficiente las solicitudes
de soporte técnico relacionadas con el sistema
Sistemas de Soporte Técnico Velasco Ibarra (SSTVI).​

●​ Diagnosticar y resolver fallas en equipos, software o

redes que afecten el funcionamiento del sistema o de
los usuarios dentro de la institución.​

●​ Brindar asistencia técnica, ya sea de forma remota o

presencial, garantizando soluciones efectivas a los
incidentes reportados por los usuarios.​

●​ Realizar pruebas funcionales y no funcionales para

validar el correcto funcionamiento del sistema antes de
su despliegue o actualización.​

●​ Registrar y mantener actualizada la información de las

solicitudes e incidentes en el sistema de soporte,
asegurando la trazabilidad y el historial de cada caso.​

●​ Colaborar con el equipo de desarrollo y análisis para

comunicar hallazgos relevantes y contribuir a la
mejora continua del sistema.

8
 ERS

1.1.4 Definiciones, Acrónimos y Abreviaturas

SOPORTE TÉCNICO

➢ USUARIO: Persona que trabaja en la institución y necesita ayuda con computadoras,

sistemas o equipos.​
➢ TÉCNICO: Persona encargada de solucionar problemas relacionados con la tecnología.​
➢ INCIDENCIA: Cualquier falla o problema que impida usar correctamente un equipo o
sistema.​
➢ SOPORTE: Ayuda que se da a los usuarios para resolver problemas técnicos.​
➢ SISTEMA DE SOPORTE TÉCNICO: Plataforma que permite registrar, organizar y dar
seguimiento a los reportes de fallas tecnológicas.​
➢ SOLICITUD: Registro que hace el usuario cuando necesita ayuda con un problema
técnico.

SISTEMA

➢ ERS: Especificación de Requisitos de Software.​

➢ SSTVI: Sistema de Soporte Técnico Velasco Ibarra.​
➢ INVENTARIO: Lista organizada de equipos, programas o recursos tecnológicos.​
➢ SEGUIMIENTO: Revisión constante del estado de una solicitud hasta que sea
solucionada.​
➢ GESTIÓN: Organización y control de las solicitudes de soporte para resolverlas de forma
ordenada.

1.1.5 Referencias
1.1.3​

Título del documento Referencia

Modelo de soporte técnico para la Ministerio de Finanzas del Ecuador. (2009). Manual
gestión de servicios tecnológicos en de Procedimientos para Soporte Técnico.
instituciones públicas nacionales Recuperado de
[Link]
Procedimientos-Soporte-Tecnico

Modelo de soporte técnico para la Torres Regalado, P. E. (2020). Modelo de soporte

gestión de servicios tecnológicos en la técnico para la gestión de servicios tecnológicos en
administración pública nacional la administración pública nacional. Revista
Odigos, 1(1), 81–93.
[Link]

Quipux – Sistema de gestión Innovafiles. (2024). Quipux Ecuador – Soporte

documental utilizado en el sector Quipux Gestión Documental. Recuperado de
público ecuatoriano [Link]
umental/

9
 ERS

Sistema de gestión de incidencias Aguirre, N. F. (2017). Sistema de gestión de

técnicas – Universidad de incidencias técnicas. Recuperado de
Cundinamarca [Link]

Acuerdo Ministerial 21-001 – Estatuto Ministerio de Producción, Comercio Exterior,

Orgánico Reformado MPCEIP Inversiones y Pesca. (2024). Acuerdo Ministerial
21-001 – Estatuto Orgánico Reformado MPCEIP.
Recuperado de
[Link]
rdo-Ministerial-21-001-Estatuto-Organico-Reforma
do-Mpceip

1.1.6 Visión General del Documento

Mejorar la eficiencia y organización del soporte técnico dentro de la institución pública

Velasco Ibarra, facilitando la atención de problemas tecnológicos en distintas áreas de
trabajo. Además, se busca que con el tiempo el sistema pueda ser actualizado y
mejorado para seguir apoyando una gestión técnica moderna, rápida y efectiva

2 Descripción General

2.1 Objetivos del Sistema

Con el desarrollo del sistema SSTVI se busca mejorar la calidad del servicio de
soporte técnico dentro de la institución pública Velasco Ibarra. Este proyecto representa
una oportunidad para modernizar la forma en que se atienden y gestionan los problemas
tecnológicos, beneficiando tanto al personal administrativo como técnico. El objetivo es
lograr una herramienta útil, práctica y bien aceptada por los usuarios.

2.1.1 Objetivo General

Diseñar e implementar un sistema web que permita registrar, organizar, asignar y dar
seguimiento a las solicitudes de soporte técnico en la institución pública Velasco Ibarra,
mejorando la atención de incidencias relacionadas con equipos, redes y sistemas
informáticos, y facilitando el trabajo del área técnica.

10
 ERS

2.1.2 Objetivos específicos

▪​ Agilizar la atención de solicitudes técnicas mediante un registro digital claro y

accesible.​

▪​ Optimizar la asignación de tareas entre los técnicos para una mejor

organización.​

▪​ Llevar un control actualizado del inventario de equipos y licencias de software.​

▪​ Facilitar la generación de reportes que ayuden en la toma de decisiones.​

▪​ Minimizar los tiempos de respuesta y reducir errores humanos en el proceso de

atención técnica.​

▪​ Aplicar conocimientos de desarrollo de software, soporte técnico e ingeniería de

sistemas para cumplir con los requisitos funcionales y no funcionales del
sistema.​

2.2 Perspectiva del producto

El sistema propuesto, Sistema de Soporte Técnico Velasco Ibarra (SSTVI), será una
herramienta digital diseñada para mejorar la forma en que se gestionan y resuelven los
problemas técnicos dentro de la institución pública Velasco Ibarra. Este sistema busca
optimizar el tiempo de atención, mantener una mejor organización del área técnica y
facilitar la comunicación entre los usuarios y el personal encargado del soporte.

SSTVI estará enfocado en las necesidades reales de la institución, con funciones

específicas para registrar incidencias, asignar tareas a los técnicos, dar seguimiento a
cada solicitud, y generar reportes útiles para la toma de decisiones. A diferencia de otras
soluciones genéricas, este sistema será adaptado a la estructura y procesos internos del
Velasco Ibarra, lo cual permitirá una implementación efectiva y útil.

El sistema podrá utilizarse desde computadoras, tablets o celulares, gracias a su diseño

web responsivo y su interfaz sencilla. Esto permitirá que los usuarios se adapten
rápidamente y puedan acceder al sistema sin complicaciones. SSTVI se construirá
siguiendo buenas prácticas de desarrollo y tomando en cuenta normas actuales, para

11
 ERS

asegurar que sea confiable, fácil de usar y cumpla con los objetivos de calidad y
eficiencia que la institución necesita.

Descripción: [Indicar brevemente el desglose de la gráfica, centrado en el flujo de datos de

entrada y salida de las entidades externas al proceso 0].

Descripción:Este es un diagrama de contexto del Sistema de Soporte Técnico Velasco Ibarra.

Muestra cómo interactúan tres actores principales: el Usuario, el Técnico de Soporte y el
Administrador del Sistema con el Sistema central.

12
 ERS

●​ El Usuario realiza solicitudes (como incidencias, ayuda o estado del caso), envía
información y recibe respuestas como informes, soluciones y notificaciones.​

●​ El Técnico de Soporte aporta con datos técnicos, estrategias de solución, registros de

fallas, historial de incidencias, y también recibe información del caso asignado y
alertas.​

●​ El Administrador del Sistema consulta y entrega datos del usuario, resultados de

implementación, criterios y límites permitidos.​

En conjunto, este diagrama permite visualizar claramente el flujo de información entre los
actores y el sistema, asegurando una gestión estructurada de incidencias técnicas.

Diagrama Nivel 1

13
 ERS

14
 ERS

Descripción:Este es un Diagrama de Nivel 1 del Sistema de Soporte Técnico, que

descompone el proceso general en cuatro subprocesos principales:

1.​ Gestión de Ingreso y Validación de Incidencias (1.0): Recibe solicitudes de los

usuarios, valida la información y registra la incidencia. También responde con
confirmaciones y soluciones frecuentes.​

2.​ Procesamiento y Asignación de Casos (2.0): Se encarga de analizar las

incidencias validadas, generar un número de casos, priorizar y asignar al técnico
correspondiente.​

3.​ Ejecución y Cierre del Caso (3.0): El técnico implementa la solución, valida su
funcionamiento y, si es aceptada, se notifica el cierre del incidente.​

4.​ Monitoreo y Reporte de Incidencias de Red (4.0): Supervisa el estado de la red,

detecta fallas y genera reportes técnicos para apoyar la solución de incidencias.​

El diagrama también muestra cómo se conectan las bases de datos (Usuarios,

Incidencias, Casos y Monitoreo de Red) con cada proceso, asegurando el flujo
adecuado de información.

2.3 Funciones del producto

[Link] GESTIÒN DE INGRESO Y VALIDACIÒN DE INCIDENCIAS

15
 ERS

Descripción:El diagrama representa el proceso de Gestión de Incidencias dentro del

sistema SSTVI, estructurado en tres subprocesos principales: Registro de Incidencias
(1.1), Control de Incidencias Registradas (1.2) y Seguimiento de Incidencias y Cierres
(1.3). Cada uno de estos subprocesos interactúa con diferentes almacenes de datos y
usuarios para garantizar un adecuado manejo de las incidencias técnicas reportadas.

En primer lugar, el proceso inicia cuando un usuario realiza una solicitud de ayuda. Esta
petición llega al módulo 1.1, donde se recopilan los datos del usuario desde el
repositorio "USUARIOS" y se procede al registro de la incidencia. Una vez registrada, se
envía una confirmación al usuario y se guarda en el repositorio "INCIDENCIAS".
Además, el sistema verifica si la incidencia corresponde a un caso frecuente, lo que da
paso al siguiente proceso.

En el subproceso 1.2, se realiza el control de las incidencias registradas. Aquí se valida

la información ingresada y, si corresponde, se consulta el repositorio de "PREGUNTAS

16
 ERS

FRECUENTES" para buscar posibles soluciones. Este módulo también atiende nuevas
solicitudes de incidencia y genera informes sobre las incidencias gestionadas.

Finalmente, en el subproceso 1.3 se lleva a cabo el seguimiento y cierre de incidencias.

El usuario puede consultar el estado de su solicitud, y el sistema responde con el
estado actualizado o con la notificación del cierre de la incidencia. Este subproceso
también interactúa con el repositorio "INCIDENCIAS", actualizando la información
según sea necesario.

En conjunto, este diagrama muestra de forma estructurada cómo el sistema maneja,

controla y da seguimiento a las incidencias reportadas por los usuarios, asegurando
una atención organizada y eficiente.

DIAGRAMA 1 SUB PROCESOS

1.1

17
 ERS

Descripción: Este diagrama descompone el subproceso 1.1 "Registro de Incidencias" en tres

actividades principales: recepción, verificación y registro de la incidencia. El objetivo es
asegurar que toda solicitud de ayuda se reciba adecuadamente, se verifiquen los datos
involucrados y se registre formalmente como una incidencia en el sistema.

1.​ 1.1.1 Recepción de Solicitudes de Ayuda​

○​ El proceso inicia cuando un usuario realiza una solicitud de ayuda.​

○​ Esta solicitud es registrada en el módulo de Recepción de Solicitudes, donde

se almacena una copia en el repositorio de RECEPCIONES.​

○​ Luego, la solicitud se transmite al siguiente subproceso para su validación.​

2.​ 1.1.2 Verificación de Datos de Usuario/Incidencia​

○​ En este punto, el sistema consulta la base de datos de USUARIOS para validar

la información personal y asegurarse de que la solicitud proviene de un usuario
registrado.​

○​ También se verifican los detalles de la solicitud provenientes del módulo de

recepciones.​

○​ Una vez validados los datos, se da paso al registro formal.​

3.​ 1.1.3 Registro de la Incidencia​

○​ Con los datos ya verificados, la información de la incidencia es almacenada en

el repositorio de INCIDENCIAS.​

○​ Finalmente, se emite una confirmación de registro al usuario, cerrando así el

subproceso.

1.2

18
 ERS

Descripción:El diagrama representa el flujo de atención de una incidencia dentro del sistema
ERS, desglosado en tres procesos principales que gestionan desde la recepción de la solicitud
hasta la generación del informe final.

Todo inicia cuando un usuario realiza una solicitud de incidencia o una solicitud de solución de
incidencia. Esta solicitud ingresa al primer proceso (1.2.1), denominado “Validar existencia de
incidencia”, donde se revisa si realmente se trata de una incidencia válida. Una vez validada, los
datos de la solicitud son enviados al almacén de datos llamado INCIDENCIAS, donde queda
registrado el incidente.

Luego, el proceso continúa con la etapa 1.2.2, titulada “Verificar incidencia frecuente”. Aquí se
revisa si la incidencia reportada ya ha ocurrido anteriormente o si existe alguna solución
registrada en la base de datos de PREGUNTAS FRECUENTES. Si la incidencia es común, se puede
resolver directamente con la información disponible en ese repositorio.

Si la incidencia no corresponde a una solución frecuente o requiere atención especial, se

procede al último proceso, el 1.2.3, denominado “Generar informe de incidencia”. Este proceso
se encarga de elaborar un documento detallado sobre la incidencia, el cual se registra en el

19
 ERS

almacén de datos llamado INFORMES y luego se entrega al usuario como informe de incidencia
solicitada.

En resumen, el diagrama muestra cómo el sistema valida, verifica y documenta cada incidencia,
utilizando distintos almacenes de datos para asegurar el registro, la reutilización de
información y la trazabilidad de los casos atendidos.

1.3

Descripción:Este diagrama representa el proceso de seguimiento, actualización y cierre de

incidencias dentro del sistema. Está compuesto por tres subprocesos principales que permiten
gestionar el estado de una incidencia desde su asignación hasta su cierre definitivo.

El flujo inicia cuando el usuario realiza una solicitud de estado o de cierre de una incidencia.
Esta solicitud es recibida por el proceso 1.3.1: Asignación y seguimiento de incidencia, el cual
se encarga de consultar las incidencias pendientes almacenadas en la base de datos de

20
 ERS

INCIDENCIAS. En este paso, se asigna la incidencia al equipo correspondiente y se genera un

informe de incidencia que se transfiere al proceso siguiente.

El proceso 1.3.2: Monitoreo de estado de incidencia recibe la incidencia asignada y realiza un

seguimiento de su evolución. Toda la información generada durante el monitoreo se guarda
como registro de actualización de la incidencia, el cual es enviado nuevamente a la base de
datos de INCIDENCIAS para mantener actualizada la información del caso.

A continuación, el proceso 1.3.3: Generación de informe y cierres recopila los datos

actualizados desde la administración de incidencias para generar el informe final. Este proceso
también se encarga de brindar al usuario la información sobre el estado de su incidencia y, si
corresponde, emite la confirmación de cierre de la incidencia.

Este diagrama permite visualizar cómo el sistema asegura un control completo del ciclo de vida
de cada incidencia, desde su asignación y seguimiento, hasta su actualización, documentación
final y cierre formal. A través de los distintos almacenes de datos y procesos, se garantiza que
toda la información sea registrada y accesible para los usuarios y administradores del sistema.

DIAGRAMA DE 2.0

21
 ERS

Descripción:Este diagrama muestra el flujo de gestión de casos en un sistema, específicamente

en la fase que abarca desde la recepción del caso hasta su validación y clasificación. Está
compuesto por tres subprocesos principales: Recibir caso, Validar información del caso y
Clasificar tipo de caso.

El proceso inicia con el subproceso 2.1: Recibir caso, donde el usuario completa un formulario
web y puede adjuntar documentos o evidencias relacionadas. Esta información es enviada
como solicitud del caso al sistema. Una vez validado el contenido mínimo necesario, se acepta
el caso y se genera un número de caso, quedando registrado en el sistema para su
seguimiento.

Luego, el proceso continúa con el subproceso 2.2: Validar información del caso, que se encarga
de verificar que los datos ingresados sean correctos, suficientes y estén debidamente
respaldados. Si es necesario, se solicita información adicional al solicitante o a alguna entidad

22
 ERS

externa. Una vez completada la verificación, se emite la validación de la información que es

registrada en el sistema.

Con la información validada, el flujo llega al subproceso 2.3: Clasificar tipo de caso, donde se
analiza la naturaleza del caso, sus parámetros y su nivel de prioridad. Con base en esto, el
sistema deriva automáticamente el caso al área correspondiente. Además, se pueden generar
soluciones sugeridas según el tipo de caso identificado.

Todo el flujo está respaldado por un almacén de datos central denominado Sistema, que actúa
como repositorio de información en cada una de las fases: aceptación, validación y clasificación
del caso.

DIAGRAMA 2.1 SUB PROCESOS

Descripción: El Diagrama 2.1 de Subprocesos representa la secuencia y relación entre tres

subprocesos clave para la gestión de casos dentro de un sistema automatizado. Estos
subprocesos son: recopilación de información del caso, evaluación de la importancia del caso y
seguimiento del caso.

23
 ERS

El primer subproceso, 2.1.1 Recopilar información del caso, tiene como objetivo reunir todos
los datos necesarios para iniciar el tratamiento del caso. Esta información proviene del
formulario inicial del usuario, los detalles específicos del caso, resúmenes automáticos
generados por el sistema y consultas a bases de datos externas, como los historiales. Una vez
recopilada, la información es validada y enviada al sistema para su procesamiento. En esta
etapa también se puede rechazar o aceptar el caso, y se notifica al usuario según corresponda.

El segundo subproceso, 2.1.2 Importancia del caso, evalúa la criticidad del caso con base en
reglas internas de evaluación y criterios preestablecidos. El sistema proporciona la información
recopilada para determinar el nivel de urgencia y prioridad del caso. Si se considera necesario,
se emiten recomendaciones de atención inmediata. El resultado de esta evaluación es el nivel
de prioridad asignado, que regresa al sistema para su seguimiento.

El tercer subproceso, 2.1.3 Seguimiento del caso, se encarga de coordinar y registrar las
acciones relacionadas con el tratamiento del caso. A partir de la información procesada, se
asigna personal encargado, se registran avances, intervenciones y se generan alertas en caso de
plazos vencidos o falta de movimiento. Además, se proporciona retroalimentación tanto al
usuario como a otras partes afectadas.

Todos los subprocesos están interconectados mediante un sistema central que actúa como eje
de coordinación, canalizando información entre etapas y facilitando la gestión integral del caso.
Este enfoque estructurado permite una atención más eficiente, organizada y oportuna.

24
 ERS

2.2

Descripción:El Diagrama 2.2 de Subprocesos describe las actividades necesarias para procesar
y validar la información relacionada con un caso dentro de un sistema de gestión. Este proceso
se divide en tres subprocesos principales: validación de información recibida, registro de la
información del caso y resolución de información válida.

El primer subproceso, 2.2.1 Validar información recibida, se encarga de revisar la información

proporcionada por el usuario, incluyendo la documentación adjunta relacionada con el caso.
Una vez validada, esta información se retroalimenta al sistema o al área correspondiente. Este
paso también incluye la recolección de datos del caso e información recibida, así como la
notificación o informe del resultado del proceso de validación.

A continuación, el subproceso 2.2.2 Registro de información del caso permite formalizar y

actualizar los datos del caso dentro del sistema. Se realiza una comprobación de información,
se crea o actualiza el historial del caso y se registra con base en casos similares previos. Como
salida, se confirma al solicitante o al sistema que el registro fue exitoso. Esta etapa asegura que
la información validada esté correctamente integrada en la base de datos del sistema.

Por último, el subproceso 2.2.3 Resolución de información válida se enfoca en dar seguimiento
y gestionar el caso con base en la información verificada. Aquí se asigna el personal o unidad
de respuesta correspondiente, considerando las reglas de atención y políticas establecidas. Se
registra el tiempo de resolución, se determina la prioridad del caso, y se asegura que el caso
quede registrado con datos completos y válidos para su atención.

Durante todo el proceso, el sistema actúa como eje central, gestionando el flujo de información
entre los subprocesos y almacenando los registros necesarios para el seguimiento y control del
caso.

2.3

25
 ERS

Descripción:Este diagrama describe el proceso de verificación, evaluación y clasificación de

casos, asegurando que cada caso registrado sea sometido a un análisis estructurado antes de
proceder con su gestión. El proceso se divide en tres secciones principales.

La primera sección, Verificación de Integridad de los Datos (2.3.1), consiste en revisar la fecha
de creación del caso, validar el número de identificación del solicitante y comprobar que el
formato de los datos registrados sea correcto. En caso de detectar campos inválidos o
incompletos, se generan alertas para corregir la información. Si los datos son correctos, el caso
avanza a la siguiente fase.

La segunda sección, Evaluación de Prioridades del Caso (2.3.2), se encarga de analizar el nivel
de urgencia declarado, verificar la categoría del incidente y la prioridad asignada. Con base en
estos factores, se ordena el caso según su importancia y necesidad de atención, asignándole
una regla de prioridad específica para guiar su gestión.

26
 ERS

Finalmente, en la sección de Identificación del Tipo de Caso (2.3.3), se asigna una clasificación
específica al caso, se define la ruta de atención adecuada y se describe detalladamente el
problema reportado. Además, se determina la causa principal de la incidencia y se envía toda
esta información para su correcta gestión y resolución.

DIAGRAMA 3.0

Descripción:El Diagrama 3.0 representa el proceso de resolución y cierre de incidentes a través

de tres subprocesos fundamentales: implementación de la solución, validación de la solución
aplicada y finalización del incidente. Este flujo garantiza que los incidentes reportados se
gestionen de manera eficiente, controlada y con trazabilidad de cada paso.

El primer subproceso, 3.1 Implementar Solución de Incidente, comienza una vez que se ha
identificado un incidente (ID). En esta etapa, se definen y utilizan los recursos operativos
disponibles junto con una estrategia de solución previamente establecida. Esta estrategia es
ejecutada y registrada en el sistema, lo que da lugar a una solución en funcionamiento y un

27
 ERS

registro de ejecución operativa. Toda la ejecución es documentada y enviada al sistema de

soluciones para su posterior validación.

Luego, el subproceso 3.2 Validar Solución Aplicada se encarga de verificar que la solución
implementada cumple con los criterios de aceptación. El sistema proporciona el estado de la
solución implementada y el resultado de su ejecución, permitiendo emitir un informe de
validación. Si la solución es aceptada, se valida formalmente y se actualiza el estado del
incidente. El resultado de esta validación es crucial para proceder al cierre del caso.

Finalmente, el subproceso 3.3 Finalización de Incidente tiene como propósito formalizar el

cierre del incidente. Una vez que la solución ha sido validada, el sistema confirma el estado
actualizado y se registra la finalización del incidente. Este proceso emite como salidas: la
confirmación de la incidencia registrada, el caso de incidente cerrado y la notificación de cierre
correspondiente.

Durante todo el proceso, el sistema de soluciones y el módulo de finalización actúan como

intermediarios que gestionan el flujo de información entre los subprocesos. Este modelo
asegura que las soluciones sean implementadas con control, validadas adecuadamente y que
cada incidente quede documentado y cerrado correctamente.

3.1

28
 ERS

Descripción:El diagrama describe el proceso de implementación y ejecución de una solución para una
incidencia, organizado en tres etapas clave que aseguran una correcta aplicación y seguimiento
de la solución.

La primera etapa, Alistar Recursos Validados (3.1.1), consiste en verificar que los recursos
necesarios para la implementación estén disponibles y sean válidos para el entorno específico.
Se confirma la disponibilidad de estos recursos y se preparan todos los elementos requeridos
para ejecutar la solución de manera efectiva.

En la segunda etapa, Ejecutar la Solución (3.1.2), se aplican las instrucciones detalladas en el

plan de implementación. Durante esta fase, todas las acciones realizadas son documentadas
cuidadosamente, así como cualquier resultado o efecto que ocurra después de la ejecución,
garantizando un seguimiento completo del proceso.

Finalmente, en la etapa de Registrar la Ejecución (3.1.3), se recopilan y almacenan todos los

datos obtenidos durante la ejecución. Se generan informes que contienen evidencia y detalles
sobre la implementación y se documentan los resultados finales del proceso para su análisis y
evaluación posterior.

Adicionalmente, el diagrama incluye dos módulos de datos importantes: D RECURSOS, que

contiene información sobre los recursos utilizados en la implementación, y D EJECUCIÓN, que
almacena los registros de las acciones realizadas y los resultados obtenidos durante el proceso.

3.2

29
 ERS

Descripción: Este diagrama representa el proceso de verificación, validación y cumplimiento en

la gestión de la ejecución de soluciones, estructurado en tres fases clave que aseguran la
correcta aplicación y evaluación de cada solución implementada.

La primera fase, Verificación de Ejecución (3.2.1), consiste en comprobar que la ejecución de la

solución se haya realizado conforme al plan previamente definido. Para ello, se revisan los
registros de ejecución y la evidencia generada durante el proceso, elaborándose un informe
detallado que documenta el desarrollo y cumplimiento del plan.

En la segunda fase, Comprobación de Resultados (3.2.2), se evalúan los resultados obtenidos

tras la ejecución de la solución. Estos resultados se comparan con los criterios de éxito
establecidos para determinar la efectividad de la solución. Con base en este análisis, se genera
un informe técnico que refleja el desempeño y la efectividad del proceso aplicado.

Finalmente, en la fase de Validación de Cumplimiento (3.2.3), se verifica que los reportes

validados cumplan con los requisitos y estándares previamente establecidos. Se documenta el
estado de cumplimiento y se emite un reporte final que confirma la aprobación de la solución
conforme a los estándares definidos.

El diagrama también incorpora dos módulos adicionales: DE VERIFICACIÓN, que almacena los
resultados de la verificación y la evidencia de la ejecución, y D VALIDACIÓN, donde se registran
los reportes evaluados y el estado documentado de la solución.

3.3

30
 ERS

Descripción:El diagrama describe el proceso de verificación, documentación y notificación del

cierre de incidentes dentro de un sistema de gestión, organizado en tres partes principales que
garantizan el cierre adecuado y la comunicación efectiva del estado final de cada incidente.

La primera parte, Verificación del Cierre del Incidente (3.3.1), consiste en revisar la información
relativa a la resolución del incidente para asegurar que cumple con los criterios establecidos. Si
el cierre es correcto, se registra la aprobación correspondiente y se genera un informe con las
observaciones finales sobre el caso.

La segunda parte, Documentación del Cierre del Incidente (3.3.2), se encarga de almacenar
toda la información relacionada con el incidente y su resolución en la base de datos. Además,
se registra el archivo del caso para futuras referencias y se elabora un informe documentado
que refleja el historial completo del incidente.

Finalmente, en la parte de Notificación del Cierre del Incidente (3.3.3), se envía una
notificación oficial sobre el cierre a los destinatarios pertinentes. Se verifica que esta
notificación haya sido emitida correctamente y, posteriormente, se registra el caso como
cerrado en el sistema de gestión.

El diagrama también incluye dos módulos de datos clave: D CIERRES, que almacena los
registros de incidentes cerrados, y D NOTIFICACIÓN, donde se guarda la información de las
notificaciones enviadas.

Diagrama de 4.0

31
 ERS

Descripción:El proceso de gestión de fallos en una red comienza con la supervisión automática
de red, que se encarga de monitorear constantemente el estado operativo de los equipos. Este
sistema detecta de manera automática cualquier fallo, registra información relevante, aplica
reglas de monitoreo y límites previamente definidos, y genera alertas que son enviadas al
equipo técnico para su atención.

Una vez detectado un fallo, se inicia la fase de registro y análisis, donde cada incidencia es
registrada en una base de datos, clasificada según su gravedad, y convertida en un informe que
puede ser notificado a los responsables correspondientes. A continuación, se procede con el
monitoreo de red, donde se confirma la existencia del fallo y se evalúa su impacto sobre el
funcionamiento general de la red. Durante este proceso, se vuelve a clasificar la incidencia para
facilitar su análisis técnico y su posterior resolución.

Posteriormente, en la etapa de gestión de la incidencia de red, se actualiza de forma continua

el estado de la incidencia a medida que se aplican soluciones. Además, se documentan todas
las acciones técnicas realizadas para resolver el problema. Finalmente, en la fase de

32
 ERS

notificación y atención de red, se informa al equipo técnico sobre las incidencias registradas, se
asigna un responsable para su resolución y se documenta el estado final de la incidencia,
incluyendo las medidas adoptadas para su cierre.

SUBPROCESOS 4.1

Descripción:Este diagrama representa un sistema integral de monitoreo y gestión de fallas en

dispositivos, estructurado en tres procesos principales, cada uno con funciones específicas y
complementarias.

El primer proceso, Identificación Rápida de Fallas (4.1.1), se encarga de detectar fallos en los
dispositivos utilizando condiciones predefinidas. Cuando se identifica una anomalía, el sistema
genera alertas automáticamente, registra las fallas detectadas y envía información actualizada
al módulo de Incidencias, permitiendo una respuesta ágil ante los problemas.

33
 ERS

En paralelo, el proceso de Monitoreo Constante de Dispositivos (4.1.2) supervisa en tiempo

real el estado operativo de los dispositivos. Este monitoreo continuo permite generar reportes
de estado y emitir alertas inmediatas en caso de detectar fallos. La información recopilada se
comparte tanto con el módulo de Incidencias como con el módulo de Dispositivos, asegurando
que todas las áreas relevantes cuenten con datos precisos y actualizados sobre el estado y el
funcionamiento de los equipos.

El tercer proceso, Avisos Automáticos por Errores (4.1.3), se activa una vez detectados eventos
anómalos. Este módulo registra los errores y genera listas detalladas de fallos. Luego, envía
alertas al personal técnico a través de una lista de contactos previamente definida. Además, la
lista de errores generada es enviada directamente al módulo de Dispositivos, lo que permite
mantener un registro actualizado de problemas conocidos.

En cuanto a los módulos adicionales, el módulo de Incidencias recibe información sobre fallas
recientes y el estado de los equipos. También comparte esta información con el proceso de
Identificación Rápida de Fallas, cerrando el ciclo de retroalimentación. Por su parte, el módulo
de Dispositivos recibe reportes detallados del estado y funcionamiento de los equipos, y a su
vez envía las listas de errores generadas hacia el módulo de Avisos Automáticos por Errores
para su gestión.

4.2

34
 ERS

Descripción: El diagrama representa el proceso de supervisión y clasificación de fallas en

equipos, el cual se divide en tres secciones principales que trabajan de forma coordinada para
asegurar un control eficiente de los errores detectados.

La primera sección, Supervisión Continua del Funcionamiento (4.2.1), se encarga de monitorear

en tiempo real el estado operativo y las señales de los dispositivos. Este monitoreo constante
permite registrar el funcionamiento actual de cada equipo y enviar esa información a la sección
correspondiente de equipos (D EQUIPOS). En caso de detectar una falla, el sistema genera
automáticamente una alerta o registra la incidencia para su posterior análisis.

A continuación, en la sección de Clasificación por Tipo y Gravedad (4.2.2), las fallas detectadas
son agrupadas según su tipo específico y el nivel de gravedad que representan. Este proceso
permite organizar la información de manera eficiente y generar informes detallados con una
descripción clara de los errores. Los datos clasificados son enviados a la sección de fallas (D

35
 ERS

FALLAS), que también puede solicitar información organizada para otros procesos de gestión y
resolución.

Finalmente, en la sección de Generación de Reportes de Fallas (4.2.3), se elabora un listado de

las fallas que requieren atención o resolución. Durante este proceso, se analiza la frecuencia
con la que ocurren los errores detectados, lo que permite identificar patrones recurrentes. Con
base en esta información, se genera un reporte estructurado que incluye detalles técnicos y
estadísticos de cada falla registrada.

4.3

Descripción:El diagrama describe el flujo de trabajo para la recepción, asignación y

seguimiento de reportes de fallas en un sistema, dividiéndose en tres secciones principales que
permiten gestionar de manera eficiente cada etapa del proceso.

36
 ERS

La primera sección, Recepción de Reportes (4.3.1), comienza con la notificación de una falla
por parte del usuario o del sistema de monitoreo. Una vez recibida la notificación, el reporte se
registra formalmente en el sistema de gestión, y se confirma su registro para asegurar que la
incidencia ha sido correctamente documentada y está lista para ser atendida.

A continuación, en la etapa de Asignación de Técnico (4.3.2), se notifica la existencia de un

nuevo reporte de falla, incluyendo todos los detalles necesarios para su atención.
Seguidamente, se asigna un técnico responsable de resolver el problema, y esta asignación
queda registrada en el sistema. Además, se realiza una solicitud formal de asignación para
asegurar la trazabilidad del proceso, y, una vez resuelta la incidencia, se confirma el cierre del
caso.

Finalmente, en la sección de Seguimiento y Cierres (4.3.3), se informa sobre el estado actual de

la reparación al sistema o a las partes involucradas. Una vez completada la solución, se
actualiza el registro con la información final y se procede al cierre formal del caso, dejando
constancia de todas las acciones realizadas durante el proceso.

2.4 Características de los Usuarios

37
 ERS

38
 ERS

2.4.1 Perfil de usuario

En esta subsección se describen los perfiles específicos de los usuarios que interactúan
con el Sistema de Soporte Técnico Velasco Ibarra (SSTVI). Esta descripción tiene como
objetivo definir claramente los roles, responsabilidades y niveles de participación de
cada usuario dentro del sistema, con el fin de asegurar una correcta operación, evitar
ambigüedades y facilitar la implementación y el uso eficiente de la plataforma.

Representante: Danna Liliana Guallan Cepeda

Cargo : Jefa de proyecto
Tipo: Lider de equipo
Rol: Planificadora y coordinadora del proyecto SSTVI
Responsabilidades:
Planificar y supervisar el desarrollo del sistema
SSTVI.
Coordinar al equipo de trabajo técnico y
administrativo.
Capacitar al equipo en metodología de soporte.
Gestionar riesgos y asegurar el cumplimiento de
estándares.
Comentarios: Comunicación directa con autoridades y responsable de área.

39
 ERS

Representante: Katherine Angeline Farez Tigreros

Cargo : Analista del sistema
Tipo: Equipo técnico
Rol:
Analista de requerimientos

Responsabilidades:
• Analizar y documentar los requisitos del sistema.

• Identificar necesidades de usuarios.

• Alinear metas institucionales con funcionalidades del

sistema.

• Redactar especificaciones funcionales y no

funcionales.

Comentarios: Es puente clave entre usuarios y equipo de desarrollo.

Representante: José Francisco Chimbolema Zuñiga

Cargo : Desarrollador de lógicas y estructuras
Tipo: Interno
Rol: Desarrollador de Software
Responsabilidades: • Diseñar y desarrollar el sistema.
• Crear y mantener la base de datos.
• Desarrollar APIs para el sistema.
• Realizar pruebas y depurar errores.

Comentarios: Enlace entre la lógica del sistema y su funcionalidad técnica.

Representante: Alejandro Roberto Jaime Chaguay

Cargo : Especialista en Soporte Técnico
Tipo: Equipo Técnico
Rol: Técnico en pruebas y soporte
Responsabilidades: • Atender y diagnosticar solicitudes de soporte.
• Registrar y actualizar casos en el sistema.
• Brindar soporte técnico remoto y presencial.
• Garantizar la trazabilidad de cada caso.

Comentarios: Ayuda a validar el funcionamiento real del sistema en campo.

40
 ERS

2.4.2 Jerarquía de usuario

2.5 Restricciones
El desarrollo e implementación del Sistema de Soporte Técnico Velasco Ibarra (SSTVI) estará
condicionado por una serie de restricciones técnicas, organizativas y de seguridad, propias del
entorno institucional público en el que será utilizado. A continuación, se detallan las principales
restricciones del proyecto:

● Políticas institucionales:

El SSTVI se regirá por las políticas internas establecidas por la institución pública Velasco
Ibarra, especialmente en lo relacionado con la confidencialidad de la información, la calidad del

41
 ERS

servicio y la seguridad tecnológica. Además, el sistema deberá cumplir con las normativas y
leyes nacionales vigentes, como la Ley Orgánica de Protección de Datos Personales en Ecuador,
y las directrices emitidas por organismos como el MINTEL.

● Limitaciones de hardware:

El sistema requerirá ser ejecutado en equipos con una capacidad mínima de procesamiento (Intel
Core i3 o superior), 4 GB de memoria RAM y 250 GB de almacenamiento. Además, será
necesario contar con una conexión a internet estable para acceder a la plataforma de manera
eficiente. Se establecerá un límite de 10 MB para los archivos adjuntados a las solicitudes, con
el fin de evitar sobrecargas del servidor.

● Funciones de control y seguridad:

El sistema contará con un módulo de seguridad que permitirá asignar roles y permisos
específicos a los usuarios (administrador, técnico y usuario final). Cada usuario deberá
autenticarse con un nombre de usuario y una contraseña. Se habilitarán funciones de
recuperación de contraseña mediante correo electrónico institucional y se mantendrá un registro
detallado de accesos y acciones dentro del sistema, con fines de auditoría y trazabilidad.

● Lenguaje de programación y tecnologías utilizadas:

El desarrollo del sistema se realizará utilizando el lenguaje de programación Python, bajo el

framework Django para el backend. Se empleará HTML, CSS y JavaScript para el diseño del
frontend, y la base de datos será gestionada con PostgreSQL. Estas tecnologías permiten una
solución escalable, segura y de fácil mantenimiento, compatible con diferentes navegadores y
dispositivos.

● Validación del sistema:

El SSTVI será sometido a pruebas funcionales, de integración y de usuario, con el objetivo de

verificar que cumple con los requerimientos establecidos. Estas pruebas garantizarán la calidad,
estabilidad y eficiencia del sistema antes de su implementación definitiva.

● Seguridad de la información:

Se implementarán medidas de seguridad como el uso de HTTPS, encriptación de contraseñas,

control de acceso y copia de seguridad periódica de la base de datos. Asimismo, se contará con

42
 ERS

un firewall y protección antivirus para prevenir accesos no autorizados o pérdida de

información.

● Tiempo de desarrollo:

El desarrollo del sistema tendrá una duración máxima de 6 meses, divididos en las
siguientes fases:

●​ Fase 1: Análisis de requerimientos (1 mes)​

●​ Fase 2: Diseño del sistema y base de datos (1 mes)​

●​ Fase 3: Desarrollo e implementación de funcionalidades (2 meses)​

●​ Fase 4: Pruebas, validación y corrección (1 mes)​

●​ Fase 5: Capacitación y despliegue final (1 mes)​

● Costo de inversión:

El proyecto contará con un presupuesto máximo de $10.000 USD, el cual cubrirá los
siguientes rubros:

●​ Contratación del personal técnico​

●​ Licencias de software necesarias​

●​ Servidores o infraestructura en la nube​

●​ Capacitaciones para usuarios y técnicos​

●​ Soporte técnico post implementación y mantenimiento inicial​

6 2.6 Suposiciones y Dependencias

El desarrollo y correcto funcionamiento del Sistema de Soporte Técnico Velasco

Ibarra (SSTVI) está basado en una serie de suposiciones y condiciones externas que
deben cumplirse para garantizar que el sistema opere de manera adecuada dentro de la
institución pública. A continuación, se detallan:

43
 ERS

●​ Capacitación del personal:​

Se asume que los usuarios (personal administrativo, docentes y técnicos)
recibirán la capacitación necesaria para utilizar el sistema SSTVI correctamente,
lo cual asegurará su aprovechamiento y reducirá errores por mal uso.​

●​ Independencia de otros sistemas:​

El sistema SSTVI funcionará de forma autónoma y no requerirá integraciones
directas con sistemas externos. Toda su lógica, base de datos y funcionalidades
estarán contenidas dentro de su propia arquitectura Cliente/Servidor.​

●​ Requisitos estables:​
Se parte del supuesto de que los requisitos funcionales y no funcionales
definidos en este documento han sido validados por las partes interesadas y se
mantendrán estables una vez aprobado el documento. Cualquier modificación
posterior deberá ser aprobada por el equipo técnico y los responsables
institucionales.​

●​ Conocimientos básicos de tecnología:​

Se presupone que los usuarios del sistema tienen conocimientos básicos sobre el
uso de computadoras, navegación por internet y llenado de formularios en línea.​

●​ Cumplimiento de normas de seguridad:​

El sistema SSTVI cumplirá con los lineamientos institucionales de seguridad
informática, protección de datos y buenas prácticas de desarrollo seguro.​

●​ Dependencia de infraestructura tecnológica:​

El sistema dependerá del correcto funcionamiento de la red interna de la
institución, de la conectividad a internet y de los servidores donde se alojará el
sistema y su base de datos.​

●​ Compatibilidad multiplataforma:​
Se asume que los usuarios pueden acceder al sistema desde distintos
dispositivos y sistemas operativos (Windows, Linux, Android, iOS). Por eso, el
sistema será desarrollado con un diseño responsivo y multiplataforma, para
garantizar su accesibilidad desde computadoras, tablets o teléfonos móviles.

2.7 Requisitos futuros

44
 ERS

Los siguientes requisitos no serán implementados en la primera versión del sistema

SSTVI, pero se consideran posibles mejoras o ampliaciones para futuras versiones del
sistema, en función de las necesidades de la institución y del avance tecnológico:

●​ Integración con sistemas de gestión documental institucional (como Quipux):​

En futuras versiones, se podrá integrar el sistema SSTVI con plataformas
gubernamentales como Quipux para mantener un registro oficial y automatizado
de los reportes técnicos y sus resoluciones.​

●​ Sistema de notificaciones automáticas:​

Se añadirá la posibilidad de enviar notificaciones por correo electrónico o
mensajes internos cuando una solicitud cambie de estado (pendiente, en proceso,
resuelto), tanto para técnicos como para usuarios.​

●​ Módulo de encuestas de satisfacción del usuario:​

Se podrá incluir un sistema de encuestas breves para que los usuarios valoren la
atención recibida, ayudando a medir la calidad del soporte técnico brindado.​

●​ Sistema de respaldo automático y recuperación de datos:​

Se desarrollará una funcionalidad que realice respaldos periódicos de la base de
datos, permitiendo restaurar la información en caso de fallas o pérdida de datos.​

●​ Compatibilidad con firma electrónica institucional:​

En versiones futuras, los técnicos y responsables podrán firmar digitalmente
informes o reportes técnicos, cumpliendo con las normativas de validación
electrónica.​

●​ Módulo de analítica avanzada e inteligencia artificial:​

Se podría implementar un módulo de análisis predictivo que identifique
patrones de fallos recurrentes y proponga mejoras de forma automatizada,
utilizando herramientas de inteligencia artificial.

3 Requisitos específicos

3.1 Interfaces externas:

El sistema web de soporte técnico interno para la institución pública Velasco Ibarra
contará con diversas interfaces externas para garantizar una adecuada interacción con
los usuarios, el entorno institucional y los servicios necesarios para su funcionamiento.

45
 ERS

Interfaz de usuario: El sistema dispondrá de una interfaz web amigable y responsiva,

accesible desde navegadores modernos como Google Chrome, Mozilla Firefox y
Microsoft Edge. Esta interfaz permitirá a los usuarios registrar solicitudes de soporte
técnico, consultar el estado de sus incidencias, recibir respuestas del personal técnico y
acceder a notificaciones del sistema.

Interfaz de hardware: El sistema funcionará en los servidores de la red interna

institucional y podrá ser accedido desde computadoras de escritorio o portátiles
conectadas a dicha red. En caso de requerirse, se permitirá la impresión de reportes
mediante la conexión con impresoras disponibles en la institución.

Interfaz de software: En futuras versiones, el sistema podrá integrarse con otros

sistemas existentes en la institución, tales como bases de datos de usuarios o sistemas de
inventario. Asimismo, se contempla la posibilidad de implementar autenticación
unificada mediante servicios como Active Directory.

Interfaz de comunicación: La comunicación entre el cliente (navegador web) y el

servidor se realizará mediante los protocolos HTTP y HTTPS, garantizando la
transmisión segura de los datos. Además, se utilizará un servicio de correo electrónico
(SMTP) para el envío de notificaciones automáticas al personal técnico y a los usuarios
solicitantes.

Interfaz de red: El acceso al sistema estará restringido inicialmente a la red interna de

la institución pública Velasco Ibarra, asegurando la confidencialidad de la información.
En caso de requerir acceso externo, éste deberá ser autorizado y protegido mediante
mecanismos de autenticación segura.

3.1.1 Interfaces de usuario:

La interfaz gráfica del sistema SISOTEC-VI será desarrollada siguiendo los principios de
usabilidad, presentando pantallas claras, intuitivas y fáciles de comprender para todo el personal
de la institución educativa Velasco Ibarra. El diseño permitirá una navegación sencilla por los
módulos del sistema, como el registro de incidencias, seguimiento de solicitudes, gestión de
usuarios y generación de reportes, reduciendo errores y facilitando el trabajo diario. El sistema
incluirá:

● Un manual de usuario digital, con pasos detallados para utilizar cada función del sistema
correctamente.

● Una sección de ayuda en línea, disponible en todo momento para resolver dudas comunes.

46
 ERS

● Un diseño visual coherente y profesional, adaptado al entorno educativo, que inspire

confianza y facilite la interacción.

● Interfaz adaptable a diferentes dispositivos (PC, tablet o celular), gracias a un diseño web
responsivo, accesible desde cualquier lugar con conexión a internet.

3.1.2 Interfaces de Hardware:

El sistema SISOTEC-VI se ejecutará en estaciones de trabajo del personal administrativo y

técnico de la institución pública Velasco Ibarra, y requerirá las siguientes especificaciones
mínimas y recomendadas: Requisitos para equipos cliente (usuarios y técnicos):

● Memoria RAM mínima: 2 GB

● Memoria RAM recomendada: 4 GB

● Procesador mínimo: Dual-Core 2.0 GHz o similar

● Procesador recomendado: Intel Core i3 o superior

● Espacio en disco mínimo: 500 MB libres

● Espacio recomendado: 1 GB libres

● Resolución de pantalla mínima: 1280x720 (HD)

● Conectividad: Acceso a internet con conexión estable (mínimo 5 Mbps) Requisitos para
servidor (en caso de implementación local):

● Servidor de base de datos: MySQL o PostgreSQL, con mínimo 4 GB RAM y 100 GB de

almacenamiento

● Servidor de aplicaciones: Compatible con tecnologías web como HTML, CSS, JavaScript y
PHP (u otro lenguaje de servidor según implementación)

● Servidor web: Apache o Nginx

● Sistema operativo del servidor: Linux Ubuntu Server 20.04 LTS o superior En caso de
implementarse en la nube, estos servidores pueden ser provistos por plataformas como AWS,
Google Cloud o Azure.

47
 ERS

3.1.3 Interfaces de Software:

El desarrollo y ejecución del sistema SISOTEC-VI se apoyará en los siguientes componentes de

software:

●Lenguajes de desarrollo web: HTML5, CSS3, JavaScript

●Bibliotecas y frameworks frontend: Bootstrap 5 para la interfaz de usuario y diseño responsivo

●Lenguaje de servidor (si aplica): PHP u otro lenguaje utilizado en el backend (según
implementación)

●Base de datos: MySQL o PostgreSQL (versión 5.7 o superior)

●Entorno de desarrollo (IDE): Visual Studio Code

●Servidor web: Apache o Nginx, según el entorno de despliegue

●Sistema operativo recomendado: Linux Ubuntu 20.04 LTS o superior

●Navegadores compatibles: Google Chrome, Mozilla Firefox, Microsoft Edge (últimas

versiones)

●Sistema de control de versiones: Git (repositorio alojado en GitHub o GitLab)

●Comunicación cliente-servidor: JavaScript (AJAX o Fetch API), para solicitudes asíncronas

entre frontend y backend

3.1.4 Interfaces de comunicación:

¿Cómo se comunicará la aplicación con los datos?

● La aplicación se conectará a la base de datos (MySQL o PostgreSQL) mediante lenguaje del

lado del servidor (como PHP, en caso de estar implementado), permitiendo ejecutar consultas
SQL para obtener, insertar, actualizar o eliminar información. En el frontend, se podrá usar
JavaScript con técnicas como AJAX o Fetch API para enviar y recibir datos de forma asíncrona,
sin necesidad de recargar la página.

48
 ERS

¿Cómo se comunicará la aplicación con los dispositivos? (Según el caso)

El sistema no interactúa directamente con dispositivos físicos o sensores. Toda la comunicación

se realiza entre el cliente (navegador web) y el servidor mediante el protocolo HTTP/HTTPS,
asegurando la transferencia segura de información.

49
 ERS

3.2 Requerimientos Funcionales (RF)

50
 ERS

51
 ERS

52
 ERS

53
 ERS

54
 ERS

55
 ERS

56
 ERS

57
 ERS

58
 ERS

Alejandro

59
 ERS

60
 ERS

61
 ERS

62
 ERS

63
 ERS

64
 ERS

65
 ERS

66
 ERS

67
 ERS

Katherine

68
 ERS

69
 ERS

70
 ERS

71
 ERS

72
 ERS

73
 ERS

Danna

74
 ERS

75
 ERS

76
 ERS

77
 ERS

78
 ERS

79
 ERS

80
 ERS

81
 ERS

82
 ERS

3.3 Requerimientos Funcionales (RNF)

José

83
 ERS

Alejandro

84
 ERS

Katherine

RNF-031 Tiempo máximo de implementación de solución

Versión 1.0 27/06/2025
Autores Katherine Farez
Fuentes DFD Proceso 3.1
Descripción El sistema deberá permitir que la solución al incidente sea
implementada en un tiempo máximo de 30 minutos desde su
selección, garantizando eficiencia operativa según el SLA
establecido.
Prioridad Alta
Estado En construcción
Estabilidad Alta
Comentarios Este requisito asegura el cumplimiento de los tiempos operativos
definidos y la continuidad del servicio.

85
 ERS

RNF-032 Tiempo máximo de validación de solución

Versión 1.0 27/06/2025
Autores Katherine Farez
Fuentes DFD Proceso 3.2
Descripción El sistema deberá permitir validar la solución implementada en un
tiempo máximo de 15 minutos, asegurando el cumplimiento de los
SLA de atención y calidad del servicio.
Prioridad Alta
Estado En construcción
Estabilidad Alta
Comentarios Este requisito asegura eficiencia operativa en la validación y cierre
de incidentes según los procesos definidos.

RNF-033 Tiempo máximo de cierre de incidente

Versión 1.0 27/06/2025
Autores Katherine Farez
Fuentes DFD Proceso 3.3
Descripción El sistema deberá permitir finalizar el incidente validado en un
tiempo máximo de 10 minutos, asegurando eficiencia operativa y
cumplimiento de SLA en el proceso de cierre.
Prioridad Alta
Estado En construcción
Estabilidad Alta
Comentarios Este requisito garantiza agilidad en el cierre de casos y
notificación al usuario según los tiempos operativos definidos.

86
 ERS

Danna

87
 ERS

3.4 Requisitos de Rendimiento

El sistema deberá cumplir con los siguientes requisitos de rendimiento para asegurar
una experiencia de uso eficiente y adecuada dentro del entorno institucional:

1.​ Tiempo de respuesta: El sistema deberá responder a las acciones del usuario
(como cargar formularios, consultar solicitudes o enviar datos) en un tiempo no
mayor a 3 segundos en condiciones normales de red interna.​

2.​ Concurrencia de usuarios: El sistema deberá soportar al menos 30 usuarios

concurrentes sin afectar el rendimiento, considerando que múltiples empleados
pueden registrar o atender solicitudes al mismo tiempo.​

3.​ Disponibilidad: El sistema deberá estar disponible el 95% del tiempo durante el
horario laboral institucional (de lunes a viernes, de 08:00 a 17:00), exceptuando
las horas destinadas al mantenimiento programado.​

4.​ Carga de datos: Las consultas realizadas por los usuarios (por ejemplo,
búsquedas de solicitudes anteriores o generación de reportes) deberán ejecutarse
en un tiempo máximo de 5 segundos, incluso cuando la base de datos contenga
un volumen moderado de solicitudes históricas.​

5.​ Optimización en la red interna: El sistema debe estar optimizado para operar
eficientemente en la red local de la institución, minimizando el consumo de
ancho de banda y asegurando un uso fluido sin necesidad de conexión a Internet.​

88
 ERS

3.5 Restricciones de Diseño

El sistema web estará sujeto a las siguientes restricciones de diseño que deben ser consideradas
durante su desarrollo e implementación:

1.​ Plataforma Web: El sistema deberá ser desarrollado como una aplicación web
accesible mediante navegadores compatibles, por lo que no se desarrollarán versiones
de escritorio ni móviles nativas. Su diseño deberá ser responsivo para adaptarse a
diferentes tamaños de pantalla.​

2.​ Lenguajes y Tecnologías: Se deberá utilizar una arquitectura cliente-servidor. En el

lado del cliente se empleará HTML, CSS y JavaScript, y en el lado del servidor se podrá
utilizar un framework como Laravel (PHP), Django (Python) o [Link], según los
recursos técnicos del equipo de desarrollo y la compatibilidad con la infraestructura
existente.​

3.​ Base de Datos: El sistema utilizará un sistema gestor de base de datos relacional como
MySQL o PostgreSQL, con estructura normalizada para facilitar el mantenimiento y la
integridad de los datos.​

4.​ Estándares Institucionales: El diseño del sistema debe respetar las políticas y
lineamientos tecnológicos definidos por la institución pública Velasco Ibarra,
incluyendo el uso de servidores internos, formatos de reporte aprobados y mecanismos
de respaldo definidos por el área de tecnologías de la información.​

5.​ Compatibilidad: El sistema deberá ser compatible con navegadores modernos

actualizados en versiones estables. No se garantizará compatibilidad con versiones
antiguas o navegadores obsoletos.​

6.​ Seguridad por diseño: El sistema deberá aplicar principios de seguridad desde la etapa
de diseño, incluyendo control de accesos, gestión de roles, validación de formularios y
protección contra ataques comunes como inyecciones SQL y cross-site scripting (XSS).

3.6 Atributos del Sistema

El sistema web deberá cumplir con los siguientes atributos de calidad para garantizar su
correcto funcionamiento, facilidad de uso y sostenibilidad a largo plazo dentro de la
institución:

89
 ERS

1.​ Usabilidad: La interfaz del sistema debe ser intuitiva, clara y fácil de utilizar
por personal administrativo y técnico sin necesidad de capacitación
especializada. Se empleará un diseño organizado, con menús simples y
formularios bien estructurados.​

2.​ Mantenibilidad: El sistema deberá estar diseñado de manera modular,

facilitando las tareas de mantenimiento, corrección de errores y actualización de
funcionalidades por parte del equipo técnico de la institución.​

3.​ Seguridad: Deberá garantizar la protección de los datos de los usuarios, control
de accesos mediante roles (técnico, solicitante, administrador) y validaciones
para evitar accesos no autorizados o manipulación de información sensible.​

4.​ Fiabilidad (Confiabilidad): El sistema debe operar correctamente durante

largos periodos sin fallos, asegurando la integridad de la información registrada
en solicitudes y reportes.​

5.​ Portabilidad: El sistema debe ser accesible desde cualquier equipo conectado a
la red institucional, sin necesidad de instalar programas adicionales. Solo se
requerirá un navegador actualizado.​

6.​ Eficiencia: El sistema debe utilizar los recursos del servidor y de la red interna
de forma optimizada, evitando tiempos prolongados de espera o sobrecarga de
procesamiento.​

7.​ Escalabilidad: El diseño debe permitir que el sistema pueda adaptarse

fácilmente a una mayor cantidad de usuarios o funcionalidades en el futuro, sin
necesidad de rediseñar por completo.

3.7 Otros requisitos

Además de los requerimientos funcionales, no funcionales y de diseño, se identifican

los siguientes requerimientos adicionales relevantes para la correcta implementación y
gestión del sistema:

1.​ Capacitación inicial: Se deberá realizar una sesión de inducción o capacitación

básica al personal de soporte técnico y usuarios administrativos para garantizar
el uso adecuado del sistema durante su etapa de implementación.​

90
 ERS

2.​ Soporte técnico: El sistema deberá contar con documentación técnica básica y
una guía de usuario. Además, se designará un responsable institucional para
brindar soporte de primer nivel en caso de incidentes o dudas sobre el uso del
sistema.​

3.​ Respaldo de información: El sistema deberá integrarse con la estrategia de

respaldo institucional. Se programará un respaldo automático diario de la base
de datos para evitar la pérdida de información.​

4.​ Implementación progresiva: La puesta en marcha del sistema podrá realizarse

en fases, comenzando con las áreas administrativas más críticas y extendiéndose
gradualmente a otras dependencias de la institución.​

5.​ Idioma: Toda la interfaz y documentación del sistema estará en español, usando
un lenguaje técnico claro pero comprensible para los usuarios no especializados.​

6.​ Soporte a navegadores: Se recomienda el uso de navegadores actualizados. El

sistema no garantiza compatibilidad con navegadores antiguos ni versiones
desactualizadas.

91