UNIVERSIDAD NACIONAL DE PIURA

FACULTAD DE INGENIERÍA INDUSTRIAL

ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA

TESIS
“DESARROLLO DE UN SISTEMA WEB PARA MEJORAR EL
CONTROL DE PAGOS CON FACTURACIÓN ELECTRÓNICA EN
LA I.E.P. PREMIUM – PIURA, 2020”

PARA OPTAR EL TITULO PROFESIONAL DE INGENIERO

INFORMÁTICO

PRESENTADA POR:
Br. LUIS ANTONIO, BARCO GARCIA
ASESOR:
Dr. MOISES DAVID SAAVEDRA ARANGO
CO ASESOR:
Ing. JOSE GUILLERMO RAMIREZ CORONADO

LÍNEA DE INVESTIGACIÓN:
SISTEMAS DE INFORMACIÓN

SUB LINEA:
COMPUTACIÓN

PIURA, PERÚ
2024

i
 UNIVERSIDAD NACIONAL DE PIURA
Facultad de Ingeniería Industrial
Escuela Profesional de Ingeniería Informática

TESIS

“DESARROLLO DE UN SISTEMA WEB PARA MEJORAR EL

CONTROL DE PAGOS CON FACTURACIÓN ELECTRÓNICA EN
LA I.E.P. PREMIUM – PIURA, 2020.”

________________________________________________
Bach. BARCO GARCÍA LUIS ANTONIO
TESISTA

_____________________________________________
Dr. MOISÉS DAVID SAAVEDRA ARANGO
ASESOR

________________________________________________
Ing. LUIS G. RAMÍREZ CORONADO
CO ASESOR

ii
iii
iv
v
vi
DEDICATORIA

Con gran aprecio dedico este proyecto de

investigación a Dios nuestro padre Todopoderoso a
quien le debemos todo lo que hemos logrado a lo
largo de nuestras vidas.
A mi papa Rodrigo Barco, a mis 2 pequeños hijos
Ian y Eithan, y a la casualidad más bonita de mi vida
Eliana M., quienes han sido motivo de superación
en el caminar de mis días y un gran apoyo en
momentos de dificultad.

vii
AGRADECIMIENTOS

Agradezco a mi papá, hermanos esposa e hijos

por estar junto a mí incondicionalmente.
A mi asesor de tesis Dr. Moisés David
Saavedra Arango por la guía brindada durante
el desarrollo del proyecto.

viii
 ÍNDICE GENERAL
ÍNDICE GENERAL .......................................................................................................................... ix
INDICE DE TABLAS ..................................................................................................................... xii
INDICE DE FIGURAS ................................................................................................................... xiv
RESUMEN...................................................................................................................................... xvi
ABSTRACT ................................................................................................................................... xvii
INTRODUCCIÓN ............................................................................................................................. 1
I. ASPECTOS DE LA PROBLEMÁTICA ................................................................................... 2
DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA ................................................ 2
FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN ......................................... 3
1.2.1. Pregunta general ......................................................................................................... 3
1.2.2. Preguntas específicas.................................................................................................. 3
JUSTIFICACIÓN E IMPORTANCIA DE LA INVESTIGACIÓN .................................. 3
OBJETIVOS ...................................................................................................................... 4
1.4.1. Objetivo general ......................................................................................................... 4
1.4.2. Objetivos específicos.................................................................................................. 4
DELIMITACIÓN DE LA INVESTIGACIÓN .................................................................. 4
1.5.1. Delimitación espacial ................................................................................................. 4
1.5.2. Delimitación temporal ................................................................................................ 4
II. MARCO TEÓRICO ................................................................................................................... 5
ANTECEDENTES DE LA INVESTIGACIÓN ................................................................ 5
BASES TEÓRICAS ........................................................................................................... 6
2.2.1. Facturación Electrónica (FE)...................................................................................... 6
2.2.2. Facturación Electrónica en el Perú ............................................................................. 7
2.2.3. Sistemas de Emisión de Comprobantes de Pago ........................................................ 8
2.2.4. Proceso de Homologación ........................................................................................ 11
2.2.5. Comprobantes de pago ............................................................................................. 11
2.2.6. Proveedor de Servicios Electrónicos – PSE ............................................................. 12
2.2.7. Operador de Servicios Electrónicos – OSE .............................................................. 12
2.2.8. Sistema informático.................................................................................................. 13
2.2.9. Aplicación Web ........................................................................................................ 13
2.2.10. Base de datos ............................................................................................................ 14
2.2.11. MySQL ..................................................................................................................... 14
2.2.12. Framework ............................................................................................................... 15
2.2.13. Metodologías de desarrollo de software ................................................................... 15
2.2.14. RUP .......................................................................................................................... 15
GLOSARIO DE TERMINOS BÁSICOS ........................................................................ 17
MARCO REFERENCIAL ............................................................................................... 19
2.4.1. Datos generales ........................................................................................................ 19

ix
 2.4.2. Visión ....................................................................................................................... 19
2.4.3. Objetivo general ....................................................................................................... 19
2.4.4. Objetivos específicos................................................................................................ 20
2.4.5. Creación ................................................................................................................... 20
2.4.6. Estructura orgánica ................................................................................................... 20
HIPÓTESIS ...................................................................................................................... 21
2.5.1. Hipótesis general ...................................................................................................... 21
2.5.2. Hipótesis especificas ................................................................................................ 21
DEFINICIÓN Y OPERACIONALIZACIÓN DE VARIABLES .................................... 21
2.6.1. Variable independiente ............................................................................................. 21
2.6.2. Variables dependientes ............................................................................................. 21
2.6.3. Operacionalización de variables ............................................................................... 22
2.6.4. Indicadores ............................................................................................................... 23
III. MARCO METODOLÓGICO .............................................................................................. 25
ENFOQUE Y DISEÑO .................................................................................................... 25
DISEÑO ........................................................................................................................... 25
NIVEL .............................................................................................................................. 25
TIPO ................................................................................................................................. 25
SUJETOS DE LA INVESTIGACIÓN............................................................................. 26
TÉCNICAS E INSTRUMENTOS ................................................................................... 26
MÉTODOS Y PROCEDIMIENTOS ............................................................................... 26
3.7.1. Desarrollo de la metodología RUP ........................................................................... 27
ASPECTOS ÉTICOS ....................................................................................................... 86
IV. RESULTADOS Y DISCUSIÓN .......................................................................................... 87
RESULTADOS ................................................................................................................ 87
4.1.1. Indicador: Nivel de satisfacción del usuario ............................................................ 87
4.1.2. Indicador: Usabilidad ............................................................................................... 88
4.1.3. Indicador: Confiabilidad .......................................................................................... 89
4.1.4. Indicador: Seguridad ................................................................................................ 90
4.1.5. Indicador: Tiempo promedio de consulta de historial de pagos ............................... 91
4.1.6. Indicador: Tiempo promedio de reporte de ingresos mensuales. ............................. 92
4.1.7. Indicador: Tiempo promedio para la emisión de comprobantes electrónicos. ......... 94
DISCUSIÓN .................................................................................................................... 96
4.2.1. Presentación de resultados........................................................................................ 96
4.2.2. Discusión .................................................................................................................. 99
CONCLUSIONES ......................................................................................................................... 101
RECOMENDACIONES ................................................................................................................ 102
REFERENCIAS BIBLIOGRÁFICAS ........................................................................................... 103
ANEXOS........................................................................................................................................ 105

x
ANEXO 1. Matriz básica de consistencia .................................................................................. 105
ANEXO 2. Matriz general de consistencia ................................................................................ 106
ANEXO 3. Instrumentos de recolección de datos ...................................................................... 107
ANEXO 5. Validación de instrumentos ..................................................................................... 114

xi
 ÍNDICE DE TABLAS
Tabla II.1. Fases de la Metodología RUP ..................................................................................... 17
Tabla II.2. Operacionalización de variables ................................................................................. 22
Tabla II.3. Indicadores de las variables ........................................................................................ 23
Tabla III.1. Visión del negocio ...................................................................................................... 27
Tabla III.2. Requerimientos funcionales ........................................................................................ 28
Tabla 3.III.3. Requerimientos no funcionales ................................................................................ 29
Tabla III.4. Especificación de caso de uso - Inicio de Sesión ....................................................... 31
Tabla III.4. Especificación de caso de uso - Inicio de Sesión (continuación) ............................... 32
Tabla III.5. Especificación de caso de uso - Registrar Apoderado ............................................... 32
Tabla III.6. Especificación de caso de uso - Registrar Estudiante ................................................ 33
Tabla III.7. Especificación de caso de uso - Matricular Estudiante ............................................. 34
Tabla III.8. Especificación de caso de uso - Emisión de Boletas .................................................. 35
Tabla III.8. Especificación de caso de uso - Emisión de Boletas (continuación) .......................... 36
Tabla III.9. Especificación de caso de uso - Consulta Historial de Pagos ................................... 36
Tabla III.9. Especificación de caso de uso - Consulta Historial de Pagos (continuación) ........... 37
Tabla III.10. Especificación de caso de uso - Enviar Resúmenes Diarios .................................... 37
Tabla III.10. Especificación de caso de uso - Enviar Resúmenes Diarios (continuación) ............ 38
Tabla III.11. Especificación de caso de uso - Generación de Grupo de Emergencia ................... 39
Tabla III.12. Especificación de caso de uso - Anulación de Comprobantes ................................. 40
Tabla III.12. Especificación de caso de uso - Anulación de Comprobantes (continuación) ......... 41
Tabla III.13. Especificación de caso de uso - Generación de notas Electrónicas......................... 41
Tabla III.13. Especificación de caso de uso - Generación de notas Electrónicas (continuación) 42
Tabla III.14. Especificación de caso de uso - Contingencia de Comprobantes ............................ 43
Tabla III.15. Especificación de caso de uso - Gestionar Usuarios ............................................... 43
Tabla III.15. Especificación de caso de uso - Gestionar Usuarios ............................................... 44
Tabla III.16. Especificación de caso de uso - Gestionar Sedes ..................................................... 44
Tabla III.17. Prueba de Unidad de caja negra sin valores – Registrar Apoderado...................... 85
Tabla III.18. Prueba de Unidad de caja negra con valores – Registrar Apoderado ..................... 85
Tabla III.19. Prueba de Unidad de caja negra sin valores – Registrar Estudiante ...................... 86
Tabla III.20. Prueba de Unidad de caja negra con valores – Registrar Estudiante ..................... 86
Tabla IV.1. Nivel de satisfacción de los usuarios del sistema ....................................................... 87
Tabla IV.2. Usabilidad del sistema ................................................................................................ 88
Tabla IV.3. Confiabilidad del sistema ........................................................................................... 89
Tabla IV.4. Seguridad del sistema ................................................................................................. 90
Tabla IV.5. Prueba de normalidad - Indicador Tiempo promedio de consulta de historial de pagos
.......................................................................................................................................................... 91
Tabla IV.6. Evaluación de normalidad - Indicador Tiempo promedio de consulta de historial de
pagos ................................................................................................................................................ 91
Tabla IV.7. Prueba de T-Student - Indicador Tiempo promedio de consulta de historial de pagos
.......................................................................................................................................................... 92
Tabla IV.8. Impacto del Indicador - Indicador Tiempo promedio de consulta de historial de pagos
.......................................................................................................................................................... 92
Tabla IV.9. Prueba de normalidad - Tiempo promedio de reporte de ingresos mensuales ........... 93
Tabla IV.10. Evaluación de normalidad – Tiempo promedio de reporte de ingresos mensuales . 93
Tabla IV.11. Prueba de T-Student - Tiempo promedio de reporte de ingresos mensuales ........... 93
Tabla IV.12. Impacto del Indicador - Tiempo promedio de reporte de ingresos mensuales ......... 94
Tabla IV.13. Prueba de normalidad - Tiempo promedio para la emisión de comprobantes
electrónicos ...................................................................................................................................... 94
Tabla IV.14. Evaluación de normalidad – Tiempo promedio para la emisión de comprobantes
electrónicos ...................................................................................................................................... 95
Tabla IV.15. Prueba de T-Student - Tiempo promedio para la emisión de comprobantes
electrónicos ...................................................................................................................................... 95
Tabla IV.16. Impacto del Indicador – Tiempo promedio para la emisión de comprobantes
electrónicos ...................................................................................................................................... 95

xii
Tabla IV.17. Valores de posicionamiento ...................................................................................... 96
Tabla 5.0.1. Matriz básica de consistencia .................................................................................. 105

xiii
 ÍNDICE DE FIGURAS
Figura II.1. Facturación Electrónica desde el portal de SUNAT ...................................................... 8
Figura II.2. Facturación Electrónica desde los sistemas del contribuyente .................................... 10
Figura II.3. Arquitectura de una aplicación Web............................................................................ 13
Figura 2.4. Fases de la metodología RUP ....................................................................................... 16
Figura 3.III.1. Diagrama de caso de uso - Modelo del negocio...................................................... 28
Figura 3.III.2. Caso de Uso – Funciones super administrador ....................................................... 29
Figura 3.III.3. Caso de Uso – Administrador ................................................................................. 29
Figura 3.III.4. Caso de Uso – Funciones contador ......................................................................... 30
Figura III.5. Diagrama de Secuencia - Inicio de sesión.................................................................. 45
Figura III.6. Diagrama de Secuencia - Registrar Apoderado ......................................................... 45
Figura III.7. Diagrama de Secuencia - Registrar Estudiante .......................................................... 46
Figura III.8. Diagrama de Secuencia - Matricular Estudiante ........................................................ 46
Figura III.9 Diagrama de Secuencia - Emisión de Boletas............................................................. 47
Figura III.10. Diagrama de Secuencia - Consulta Historial de Pagos ............................................ 47
Figura III.11. Diagrama de Secuencia - Enviar Resúmenes Diarios .............................................. 48
Figura III.12. Diagrama de Secuencia - Generación de Grupo de Emergencia.............................. 48
Figura III.13. Diagrama de Secuencia - Anulación de Comprobantes ........................................... 49
Figura III.14. Diagrama de Secuencia - Generación de notas Electrónicas ................................... 49
Figura III.15. Diagrama de Secuencia - Contingencia de Comprobantes ...................................... 50
Figura III.16. Diagrama de Secuencia - Gestionar Usuarios .......................................................... 50
Figura III.17. Diagrama de Secuencia - Gestionar Sedes ............................................................... 51
Figura III.18. Diagrama de Colaboración - Inicio de Sesión.......................................................... 51
Figura III.19. Diagrama de Colaboración - Registrar Apoderado .................................................. 52
Figura III.20. Diagrama de Colaboración - Registrar Estudiante ................................................... 52
Figura III.21. Diagrama de Colaboración - Matricular Estudiante................................................. 53
Figura III.22. Diagrama de Colaboración - Emisión de Boletas .................................................... 53
Figura III.23. Diagrama de Colaboración - Consulta Historial de Pagos ....................................... 54
Figura III.24. Diagrama de Colaboración - Enviar Resúmenes Diarios ......................................... 54
Figura III.25. Diagrama de Colaboración - Generación de Grupo de Emergencia ........................ 55
Figura III.26. Diagrama de Colaboración - Anulación de Comprobantes ...................................... 56
Figura III.27. Generación de notas Electrónicas ............................................................................ 56
Figura III.28. Diagrama de Colaboración - Contingencia de Comprobantes ................................. 57
Figura III.29. Diagrama de Colaboración - Gestionar Usuarios ..................................................... 57
Figura III.30. Diagrama de Colaboración - Gestionar Sedes.......................................................... 58
Figura III.31. Diagrama de Actividades – Inicio sesión ................................................................. 59
Figura III.32. Diagrama de Actividades - Registrar Apoderado .................................................... 59
Figura III.33. Diagrama de Actividades - Registrar Estudiante ..................................................... 60
Figura III.34. Diagrama de Actividades - Matricular Estudiante ................................................... 60
Figura III.35. Diagrama de Actividades - Emisión de Boletas ....................................................... 61
Figura III.36. Diagrama de Actividades - Consulta Historial de Pagos ......................................... 62
Figura III.37. Diagrama de Actividades - Enviar Resúmenes Diarios ........................................... 62
Figura III.38. Diagrama de Actividades - Generación de Grupo de Emergencia ........................... 63
Figura III.39. Diagrama de Actividades - Anulación de Comprobantes ........................................ 63
Figura III.40. Diagrama de Actividades - Generación de notas Electrónicas................................. 64
Figura III.41.Diagrama de Actividades - Contingencia de Comprobantes .................................... 64
Figura III.42. Diagrama de Actividades - Gestionar Usuarios ....................................................... 65
Figura III.43. Diagrama de Actividades - Gestionar Sedes ............................................................ 65
Figura III.44. Diagrama de clases................................................................................................... 66
Figura III.45. Diagrama de componentes – Usuarios ..................................................................... 67
Figura III.46. Diagrama de componentes – Menú Administrativo ................................................. 67
Figura III.47. Diagrama de colaboración – Menú Principal ........................................................... 68
Figura III.48. Diagrama de colaboración – Facturación electrónica .............................................. 68
Figura III.49. Mockup – Inicio de Sesión....................................................................................... 69
Figura III.50. Mockup – Pantalla principal .................................................................................... 69

xiv
Figura III.51. Mockup – Gestión de Apoderados y Estudiantes .................................................... 70
Figura III.52.Mockup – Registrar Apoderado ................................................................................ 70
Figura III.53. Mockup – Registrar Estudiante ................................................................................ 71
Figura III.54. Mockup – Matricular Estudiante.............................................................................. 71
Figura III.55. Mockup – Emisión de Boletas ................................................................................. 72
Figura III.56. Mockup – Consulta Historial de Pagos .................................................................... 72
Figura III.57. Mockup – Resúmenes Diarios ................................................................................. 73
Figura III.58. Mockup – Enviar Resúmenes Diarios ...................................................................... 73
Figura III.59. Mockup – Generación de Grupo de Emergencia ..................................................... 73
Figura III.60. Mockup – Anulación de Comprobantes ................................................................... 74
Figura III.61. Mockup – Ventana Anulación de Comprobantes .................................................... 74
Figura III.62. Mockup – Generación de notas Electrónicas ........................................................... 75
Figura III.63. Mockup – Contingencia de Comprobantes .............................................................. 75
Figura III.64. Mockup – Gestionar Usuarios.................................................................................. 76
Figura III.65. Mockup – Gestionar Sedes ...................................................................................... 76
Figura 3.III.66. Diagrama de base de datos .................................................................................... 77
Figura III.67. Diagrama de despliegue ........................................................................................... 78
Figura III.68. Pantalla - Inicio de Sesión ........................................................................................ 78
Figura III.69. Pantalla - Principal ................................................................................................... 79
Figura III.70. Pantalla – Gestión de Apoderados y Estudiantes ..................................................... 79
Figura III.71. Pantalla - Registrar Apoderado ................................................................................ 80
Figura III.72. Pantalla - Registrar Estudiante ................................................................................. 80
Figura III.73. Pantalla - Matricular Estudiante ............................................................................... 80
Figura III.74. Pantalla - Emisión de Boletas .................................................................................. 81
Figura III.75. Pantalla - Consulta Historial de Pagos ..................................................................... 81
Figura III.76. Pantalla - Resúmenes Diarios................................................................................... 81
Figura III.77. Pantalla – Enviar Resúmenes Diarios ...................................................................... 82
Figura III.78. Pantalla - Generación de Grupo de Emergencia ...................................................... 82
Figura III.79. Pantalla - Anulación de Comprobantes .................................................................... 82
Figura III.80. Pantalla - Ventana Anulación de Comprobantes...................................................... 82
Figura III.81. Pantalla - Generación de notas Electrónicas ............................................................ 83
Figura III.82. Pantalla - Contingencia de Comprobantes ............................................................... 83
Figura III.83. Pantalla - Gestionar Usuarios ................................................................................... 84
Figura III.84. Pantalla - Gestionar Sedes........................................................................................ 84

xv
 RESUMEN

La presente investigación tiene como objetivo, desarrollar un sistema web para mejorar el control
de pagos e integración con facturación electrónica en la Institución Educativa Privada PREMIUM.
La metodología de desarrollo de software que se utilizada fue RUP (Proceso Racional Unificado),
que consta de las siguientes fases de desarrollo: Inicio, Elaboración, Construcción y Transición, en
cada fase se diseñó los diagramas correspondientes.
Se observó que la institución educativa privada PREMIUM hasta antes del mes de marzo del año
2019 emitía sus comprobantes de pago electrónicos de forma manual. Antes que SUNAT notificara
que las instituciones educativas debían usar facturación electrónica, la institución empezó a usar el
portal de SUNAT para la emisión de sus comprobantes electrónicos, pero esta plataforma presenta
frecuentes inconvenientes que llegaban a perjudicar a la Institución en la tarea de emisión de
comprobantes, quienes realizaban esta labor lidiaban con la molestia de los padres de familia.
De los resultados se pudo concluir que, el nivel de satisfacción de los usuarios fue Bueno, la
Usabilidad y Confiabilidad fueron Muy Buenas, con respecto a la seguridad se aplicaron soluciones
que pudieron minimizar las vulnerabilidades. Con respectos al tiempos, se realizó una comparativa
antes y después de la implementación del sistema, obteniendo que el tiempo promedio de consulta
de historial de pagos se redujo 87.82% (01:46 minutos), el tiempo promedio de reporte de ingresos
mensuales se redujo 09:58 minutos (98.57%) y el tiempo promedio para la emisión de comprobantes
electrónicos de 00:54 minutos (77.70%).

Palabras clave: Sistema Web, Institución Educativa Privada, pagos, facturación electrónica, reporte
de ingresos, Proceso Racional Unificado

xvi
 ABSTRACT

The objective of this research is to develop a web system to improve the control of payments and
integration with electronic invoicing in the PREMIUM Private Educational Institution. The software
development methodology used was RUP (Rational Unified Process), which consists of the
following development phases: Start, Elaboration, Construction and Transition, in each phase the
corresponding diagrams were designed.
It was observed that the private educational institution PREMIUM until before March 2019 issued
its electronic payment vouchers manually. Before SUNAT notified that the educational institutions
had to use electronic invoicing, the institution began to use the SUNAT portal for the issuance of its
electronic vouchers, but this platform presents frequent inconveniences that came to harm the
Institution in the task of issuing vouchers, those who performed this work dealt with the annoyance
of the parents.
From the results it could be concluded that the level of satisfaction of the users was Good, the
Usability and Reliability were Very Good, with respect to the security, solutions were applied that
could minimize the vulnerabilities. With respect to time, a comparison was made before and after
the implementation of the system, obtaining that the average time to consult the payment history was
reduced by 87.82% (01:46 minutes), the average time to report monthly income was reduced by
09:58 minutes (98.57%) and the average time for the issuance of electronic receipts was reduced by
00:54 minutes (77.70%).

Key words: Web System, Private Educational Institution, payments, electronic invoicing, revenue
reporting, Unified Streamlined Process.

xvii
 INTRODUCCIÓN

En la era actual, la adopción y la integración de soluciones tecnológicas avanzadas representan

un pilar fundamental para el fortalecimiento y la eficiencia operativa de organizaciones en
diversas áreas. La implementación de sistemas tecnológicos no sólo es un indicador de
innovación y avance, sino que también transforma radicalmente la forma en que las entidades
manejan sus procesos diarios. La tecnología moderna facilita la ejecución de tareas con una
velocidad y una exactitud sin precedentes, lo que tradicionalmente podría haber requerido
múltiples recursos y una inversión considerable de tiempo. Esta habilidad para realizar
operaciones de manera rápida y sin errores es ahora un símbolo distintivo de la modernidad y
una ventaja competitiva en el progreso hacia la excelencia operacional. En este contexto de
cambio constante, las herramientas tecnológicas no solo mejoran la productividad, sino que
también mejoran la calidad del trabajo realizado, permitiendo a las organizaciones escalar y
adaptarse a los desafíos emergentes con una flexibilidad y una resiliencia notables.
En este dinámico entorno, la Institución Educativa Privada PREMIUM se encuentra navegando
por un mar de desafíos operativos y financieros, que ponen a prueba su capacidad administrativa
y su agilidad en el manejo de procesos críticos. Uno de los pilares más significativos en su
estructura operacional, la gestión de los pagos estudiantiles, se ha visto obstaculizada por la
dependencia de métodos manuales y sistemas de registro fragmentados, que son propensos a
ineficiencias y errores. Esta situación, a menudo resulta en un flujo de trabajo discontinuo,
afectando negativamente la capacidad de la institución para mantener una gestión financiera ágil
y precisa, esencial para su estabilidad económica y su reputación académica.
Además, las interacciones con las autoridades fiscales, en particular el uso del sistema electrónico
de la SUNAT para la realización de trámites financieros, agregan una capa adicional de dificultad.
Las deficiencias técnicas del portal, que van desde fallos sistemáticos hasta una operación lenta
y poco intuitiva, complican aún más el panorama, imponiendo barreras administrativas que
impactan directamente en la gestión del tiempo y en la seguridad de las transacciones. Estos
inconvenientes tecnológicos y burocráticos requieren de una solución integral que pueda
simplificar estos procesos, reducir el margen de error y garantizar la conformidad con las
regulaciones gubernamentales, asegurando así una gestión fiscal sólida y confiable.
La necesidad de una solución que aborde estos problemas es evidente y urgente. Un sistema que
pueda consolidar la administración de pagos, que automatice y sincronice las operaciones
financieras, y que ofrezca una interfaz transparente y eficiente con entidades reguladoras, como
la SUNAT, no es solo deseable, sino fundamental para que la Institución Educativa Privada
PREMIUM continúe su camino hacia la excelencia educativa con la solidez financiera que
requiere el entorno educativo actual.
Este proyecto de investigación surge, por ende, como una iniciativa para contrarrestar estas
adversidades, no solo optimizando el proceso de gestión de pagos educativos sino que también
refine la generación de documentos fiscales necesarios. La implementación de este sistema busca
no solo cumplir con las expectativas de rapidez y eficiencia sino también ser un catalizador en la
transformación digital de la institución.
La evolución de este proyecto se desarrolló bajo la rigurosa supervisión de la metodología
Rational Unified Process (RUP). Este enfoque sistemático proporciona una estructura ordenada
para un desarrollo consistente y bien planificado. La metodología RUP, renombrada por su
modelo iterativo y su concentración en la arquitectura del sistema, resultó ser crucial para cumplir
con las necesidades específicas del centro educativo PREMIUM, así como para entregar
soluciones efectivas que coincidieran acorde con los deseos y requisitos de los participantes. La
aplicación de ciclos iterativos de RUP facilitó una adaptabilidad continua y escalonada frente a
los retos y variaciones durante el desarrollo, garantizando que cada fase aportara mejoras
significativas al resultado final. La implementación de RUP propició una gestión de calidad
exhaustiva, una administración de riesgos más eficiente y un uso más estratégico de los recursos,
lo que resultó en una solución con características de sólidez, confianza, así como fácil de manejar.

1
 I. ASPECTOS DE LA PROBLEMÁTICA

DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA

La Superintendencia Nacional de Aduanas y Administración Tributaria (SUNAT) ha establecido
una directiva crucial que impacta directamente a las instituciones educativas, centros culturales
privados y operadores de servicios de transporte, exigiéndoles la adopción de un sistema de
comprobantes de pago electrónicos (CPE), como facturas y boletas de venta, a partir de enero de
2020. La normativa que gobierna esta nueva medida es la resolución de superintendencia N° 318-
2017/SUNAT, que inicialmente había fijado el comienzo de la obligatoriedad de la emisión
electrónica para el primer día de enero de 2019. Sin embargo, para permitir una transición más fluida
y dar mayor tiempo para la adecuación a los sistemas electrónicos, el inicio obligatorio de esta
disposición fue prorrogada hasta el año 2020. Esta decisión refleja el compromiso de la SUNAT por
facilitar la integración progresiva de los contribuyentes al entorno digital, asegurando así una mejor
administración fiscal y promoviendo la transparencia en las transacciones comerciales.
Antes de la introducción de la mencionada normativa, la institución educativa privada
PREMIUM, hasta marzo de 2019, llevaba emitiendo, a razón de conceptos relacionados matrículas,
mensualidades y otros servicios, boletas, facturas como medios de comprobación electrónica a través
de un proceso manual. Este método, aunque funcional en sus inicios, comenzó a presentar desafíos
significativos en términos de tiempo de respuesta, generando preocupaciones tanto operativas como
en la experiencia del cliente, en este caso, los padres de familia. Frecuentemente, estos padres se
encontraban con la necesidad de esperar períodos prolongados para la obtención de un comprobante
que verificara sus pagos. En algunos casos, la espera se extendía tanto que se veían obligados a
retornar en días sucesivos para recoger los documentos necesarios, lo que generaba molestias y
perturbaba la confianza en los procedimientos administrativos de PREMIUM. En anticipación a los
cambios reglamentarios y en un esfuerzo por mejorar la satisfacción del cliente, PREMIUM tomó la
iniciativa de adoptar la plataforma de SUNAT para la expedición de documentos fiscales. Sin
embargo, la transición al sistema digital no estuvo exenta de desafíos, ya que la plataforma
presentaba inconvenientes técnicos que afectaban la emisión oportuna y correcta de los
comprobantes electrónicos, exacerbando las dificultades ya experimentadas y reforzando la
necesidad de un sistema más robusto y confiable para la gestión de las transacciones financieras de
la institución.
A pesar de que SUNAT aún no había notificado oficialmente la obligatoriedad de la facturación
electrónica para el sector educativo, PREMIUM tomó la iniciativa de integrar el portal de SUNAT
para la generación de estos comprobantes digitales. Sin embargo, la adopción de esta plataforma no
estuvo exenta de complicaciones; la frecuencia de los problemas técnicos aumentó, afectando la
eficiencia de la institución en la emisión de comprobantes y provocando inconvenientes para los
padres de familia, quienes en ocasiones se veían obligados a regresar en días posteriores para recoger
la documentación que validaba sus pagos.
La institución educativa PREMIUM, en su esfuerzo por controlar los pagos de los alumnos,
había establecido un sistema basado en múltiples hojas de cálculo de Excel, que se volvió
insostenible debido a su complejidad. Con distintos archivos para cada nivel académico y para cada
grado y sección, el proceso de verificar deudas se tornó excesivamente lento y propenso a errores,
especialmente cuando los pagos procesados electrónicamente no se actualizaban en tiempo real en
los registros de Excel. Este desajuste llevaba a inconsistencias en los historiales de pagos de los
alumnos. Adicionalmente, la generación del informe de ingresos mensuales se convertía en una tarea
hercúlea para el personal encargado, quien debía revisar y consolidar los pagos de cada archivo
correspondiente a cada nivel académico. Este procedimiento no solo era susceptible a fallos
humanos, además se enfrentaba con casos en los que se perdía información crucial debido a archivos
de Excel dañados y no recuperables. La institución reconocía la necesidad de una solución más
robusta y confiable para superar estos desafíos administrativos y contables.

2
 Debido a los desafíos previamente mencionados, el área de administración de la Institución
Educativa PREMIUM se vió en la imperiosa necesidad de adoptar un método que permita un manejo
sistematizado y ágil del control de pagos. La institución se encontraba en busca de implementar una
solución tecnológica que no solo refine la gestión de pagos, sino que también mantenga la integridad
de la facturación electrónica, que ya forma parte de sus operaciones cotidianas. La intención fue
desarrollar e integrar una plataforma web avanzada que consolide el módulo de gestión de pagos y
reportes de ingresos con mecanismo de emisión de facturas electrónicas, asegurando de esta forma
un proceso más fluido, rápido y eficiente. Esta plataforma estaría diseñada para optimizar los
procesos administrativos y financieros, garantizando una gestión eficaz cumpliendo con las
demandas actuales y prospectivas de la institución, marcando un hito en la modernización de sus
operaciones administrativas y contables.

FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN

1.2.1. Pregunta general
¿De qué manera el desarrollo de un sistema Web contribuirá al control de pagos y
facturación electrónica en la Institución Educativa Privada PREMIUM?

1.2.2. Preguntas específicas

 ¿De qué manera el sistema Web reducirá los tiempos de consulta de historial de pagos de
los alumnos en la Institución Educativa Privada PREMIUM?
 ¿De qué manera el sistema Web reducirá los tiempos de elaboración de reportes de ingresos
mensuales en la Institución Educativa Privada PREMIUM?
 ¿De qué manera el sistema Web reducirá los tiempos de emisión de facturación en la
Institución Educativa Privada PREMIUM?
JUSTIFICACIÓN E IMPORTANCIA DE LA INVESTIGACIÓN
En la actualidad, la institución educativa PREMIUM se enfrenta a retos en la emisión de facturas
electrónicas a través de la plataforma de SUNAT, así como en la administración de pagos
mediante hojas de cálculo de Excel. Estas dificultades surgen, en parte, debido a las frecuentes
interrupciones del servicio de SUNAT y la latencia en la obtención de recibos electrónicos por
parte de los padres y tutores. Este inconveniente se agrava por la presencia de datos incorrectos
o repetidos en los registros de Excel de los pagos.
Por estos motivos, se ha determinado como prioritaria la adopción de una solución digital
avanzada. Esta consistirá en la puesta en marcha de un portal web diseñado para optimizar la
revisión del historial financiero, la generación de informes de ingresos periódicos y la emisión
eficaz de recibos digitales.
Este avance tecnológico proyecta una notable mejora en la operatividad de los departamentos
de administración y finanzas. Se anticipa que el proyecto facilitará una administración más ágil
del historial de pagos estudiantiles y la generación de informes de ingresos, reduciendo
significativamente el tiempo dedicado a estas tareas.
Además, se tiene la visión de que la institución incorpore gradualmente nuevas tecnologías para
fortalecer sus rutinas operativas, redundando en beneficios para el equipo de gestión y los padres
o tutores de los alumnos.
Los principales beneficiados de esta iniciativa serán los miembros del personal en los
departamentos administrativo y financiero, al agilizar la verificación de pagos y la emisión de
informes de ingresos. En cuanto a los padres o tutores, se verán favorecidos indirectamente al
disminuir el tiempo de espera para la realización de pagos y la recepción inmediata de los recibos
electrónicos correspondientes.

3
OBJETIVOS

1.4.1. Objetivo general

Desarrollar un sistema web para mejorar el control de pagos e integración con

facturación electrónica en la Institución Educativa Privada PREMIUM.

1.4.2. Objetivos específicos

 Comparar los tiempos de consulta de historial de pagos de los alumnos, antes y después
de la implementación del módulo respectivo en el sistema Web mediante una búsqueda
por apoderado.
 Comparar los tiempos de elaboración de reportes de ingresos mensuales, antes y
después de la implementación del módulo respectivo en el sistema Web generando un
archivo en formato Excel.
 Comparar los tiempos de emisión de facturación, antes y después de la implementación
del módulo respectivo en el sistema Web emitiendo documentos electrónicos.

DELIMITACIÓN DE LA INVESTIGACIÓN
1.5.1. Delimitación espacial

El proyecto de investigación se realizará en la Institución Educativa Privada PREMIUM,

Piura - Piura – Piura.

1.5.2. Delimitación temporal

El tiempo en que se realizará el proyecto de investigación tendrá una duración de 6 meses

a partir de la aprobación del mismo.

4
 II. MARCO TEÓRICO

ANTECEDENTES DE LA INVESTIGACIÓN
 Choez (2017) llevó a cabo un estudio titulado "Desarrollo de un sistema de control de
inscripciones y facturación electrónica para la escuela 3 de Diciembre en Guayaquil" con el
propósito de obtener su grado en Sistemas de Información. El objetivo central fue la creación
de un sistema que gestione de manera eficiente y rápida los pagos e inscripciones de los
estudiantes. Utilizando Scrum como metodología de desarrollo de software, se logró un diálogo
constructivo dentro del grupo de trabajo y se proporcionó una visualización continua del
progreso del sistema a los usuarios finales. Los resultados indicaron que el sistema mejoró
significativamente la gestión de inscripciones y pagos en la entidad educativa.
 Rivera (2018) investigó el impacto de un sistema web en la facturación electrónica dentro de
J&S Consultores S.A.C para su tesis, titulada "Sistema web para la facturación electrónica en
J&S Consultores S.A.C", para graduarse como ingeniero de sistemas. El estudio tenía como
metas específicas medir el incremento en la eficiencia en la generación de documentos
electrónicos y la reducción de errores en la empresa. Empleando Scrum, esta metodología
permitió manejar de manera ágil proyectos de cualquier escala y complejidad, mejorando la
comunicación y entrega de valor oportuna a las partes interesadas. El estudio concluyó que el
sistema web elevó la eficiencia en la generación de documentos electrónicos y minimizó la tasa
de errores.
 Rodríguez (2019) llevó a cabo un estudio titulado "Plataforma web académica para la mejora
de los procedimientos de matrícula y contribuciones económicas en la entidad educativa Virgen
de la Asunción del Porvenir, ubicada en Trujillo". Este trabajo fue parte de su proyecto de
graduación en Ingeniería de Sistemas. El objetivo clave del proyecto fue la creación de un
sistema web avanzado para perfeccionar y sistematizar la administración académica, lo que
resultó en una notable agilización de las operaciones de la institución. Aplicando la metodología
RUP para forjar un programa informático logrando una impresionante reducción del 76% en la
demora de los trámites de matrícula y una notable disminución del 98.7% en la elaboración de
informes académicos y financieros, incrementando así considerablemente la satisfacción de los
usuarios finales.
 Córdova (2014) presentó su tesis "Implementación de un sistema de inscripciones y pagos para
el departamento de informática de la Universidad César Vallejo", con la finalidad de obtener
su título en Ingeniería de Estadística e Informática. El estudio fue desarrollado como parte
esencial de su requisito de graduación en la carrera de Ingeniería de Estadística e Informática.
El propósito del estudio fue la creación y puesta en marcha de un sistema computarizado
orientado a la administración eficiente y expedita de las transacciones financieras y el proceso
de matrícula de los alumnos adscritos al programa de certificación en ciencias computacionales
de dicha universidad. La selección de la metodología RUP, avalada por el Project Management
Institute por su transparencia y pertinencia en cada etapa de creación y desarrollo del sistema,
fue decisiva. El sistema resultante permitió programar distintas secciones en horarios variados,
adaptándose a la disponibilidad de profesores y alumnos, lo que condujo a una agilización en
el proceso de inscripciones y, por ende, un incremento en el número de inscripciones efectuadas
en un tiempo reducido.
 Bustamante y Pacheco (2018) investigaron las "Incidencias: Ventajas y desventajas de la
implementación del sistema de emisión electrónica frente al sistema tradicional de emisión en
los principales contribuyentes de Arequipa en 2018", buscando obtener su título en
Contabilidad. El estudio se enfocó en identificar los pros y contras de la emisión electrónica de
documentos en contraposición a los métodos convencionales de emisión de comprobantes.
Mediante una encuesta aplicada a un grupo selecto de 100 contribuyentes representativos, se
destacaron ventajas significativas del sistema electrónico, tales como la mejora en la eficiencia

5
 del registro de transacciones, la optimización de procedimientos operativos, el fomento de
prácticas sostenibles mediante la reducción del consumo de papel, así como un impacto positivo
en la disminución de la evasión de impuestos y la necesidad de auditorías fiscales frecuentes.
La investigación arrojó resultados concluyentes, indicando que la adopción de la facturación
electrónica promovida por la SUNAT no solo optimiza la supervisión tributaria, sino que
también se alinea con las demandas tecnológicas actuales de los contribuyentes, promoviendo
de esta manera una mayor adherencia a las obligaciones fiscales establecidas.
 Navarro (2017) elaboró la tesis "Sistema de facturación electrónica basado en la norma
ISO/IEC 19845:2015 para la gestión de comprobantes de pago en Acgenesys S.A.C.", con la
intención de obtener su grado en Ingeniería de Sistemas. La investigación se enfocó en
examinar, diseñar y poner en marcha un sistema de facturación electrónica destinado a la mejora
en la administración de los comprobantes de pago de la mencionada empresa. Acgenesys
S.A.C. se veía afectada por inconvenientes y desembolsos inesperados durante la generación
de dichos comprobantes. La meta principal del estudio fue inspeccionar la influencia de la
nueva solución en la reducción de eventos adversos y en la disminución de los gastos
operativos. El análisis final reveló que la implementación del nuevo sistema de facturación
electrónica ejerció una influencia positiva en la gestión de comprobantes de pago y contribuyó
significativamente a la mejora de la eficiencia operacional de la organización.
Escudero (2019) ejecutó su proyecto de grado "Implementación de un sistema de facturación
electrónica en Laboratorios BAGO S.A.C." para graduarse como Ingeniero de Sistemas e
Informática. La esencia de la tesis describió el proceso mediante el cual Laboratorios Bagó del
Perú S.A.C., en cumplimiento con las directivas de la SUNAT de convertirse en emisor
electrónico, introdujo un sistema de facturación electrónica. Optando por la metodología ágil
Scrum, se coordinó un equipo multifuncional que integró a profesionales de diversas disciplinas
involucradas en la facturación. Los hallazgos de la investigación subrayaron que el despliegue
efectivo de la facturación electrónica facilitó a la compañía no solo el acatamiento de los
requerimientos de la SUNAT en tiempo y forma, sino que también proporcionó una ventaja
estratégica, derivada de las múltiples fortalezas asociadas al proceso de facturación digital.

BASES TEÓRICAS
2.2.1. Facturación Electrónica (FE)
Representa una significativa contribución de América Latina a los esfuerzos
internacionales en materia fiscal, respaldando el control de la elusión fiscal, promoviendo
la claridad en asuntos fiscales a nivel global, y facilitando la modernización de las
administraciones tributarias mediante la digitalización, representado un hito significativo
en la modernización. Este proceso de modernización se remonta a la década de los 90,
cuando varias administraciones tributarias (AATT) latinoamericanas iniciaron su
transformación bajo la influencia de las ideas promovidas por el Consejo de Washington
y el enfoque de "reinvención del gobierno". Estas iniciativas buscaban mejorar la
eficiencia y transparencia de las instituciones públicas, centrando su atención en la
prestación de servicios orientados hacia los ciudadanos y en la optimización de
resultados.

Además, la FE se destaca como un recurso clave en la tercera revolución industrial,

caracterizada por la amplia recopilación y difusión de datos a gran escala. Con la
abundante información disponible, la Administración y Auditoría Tributaria (AATT)
puede incrementar la efectividad de los controles fiscales y optimizar la recaudación de
ingresos. Por ejemplo, mediante el análisis de riesgos, las AATT pueden identificar
patrones de comportamiento que sugieran posibles casos de evasión fiscal.

6
 El éxito de la ejecución de la FE en América Latina se refleja en su impacto positivo en
la recaudación fiscal, lo que ha llevado a su adopción en varios países. Desde su
comienzo en Chile en 2003, la FE se ha extendido a estados como Argentina, Brasil,
Ecuador, México, Perú y Uruguay. Además, otros países como Costa Rica, Colombia,
Guatemala, Panamá y Paraguay están gestionando implementación, mientras que
algunos han manifestado su intención de adoptar sistemas similares, como El Salvador,
Honduras, República Dominicana y Venezuela. Incluso, países fuera de América Latina,
como Corea, están considerando la posibilidad de implementar la FE en sus sistemas
tributarios.

A pesar de estas similitudes en la ejecución de la FE en América Latina, existen

diferencias significativas entre los sistemas de cada país. Estas diferencias pueden estar
relacionadas con aspectos técnicos, como el formato de los documentos electrónicos, así
como con cuestiones legales y administrativas. Sin embargo, todos estos sistemas
comparten características comunes, como la existencia de un formato estándar, la firma
digital de los documentos y la obligatoriedad de su uso, lo que contribuye a su eficacia
en el fortalecimiento de la vigilancia sobre la evasión de impuestos y el impulso hacia
una mayor transparencia en las obligaciones tributarias. (Escudero Llamocca, 2019)

2.2.2. Facturación Electrónica en el Perú

Representa una significativa evolución en la gestión tributaria peruana. Esta iniciativa no

solo busca modernizar los procesos comerciales y administrativos, sino también
fortalecer la transparencia y la eficiencia en las operaciones fiscales.
Al reemplazar el tradicional papel en la generación de documentos fiscales, como
facturas, boletas de venta, recibos por honorarios, notas de crédito y notas de débito, por
versiones electrónicas, el CPE introduce una mejora considerable en la agilidad y
precisión de las transacciones comerciales. Este cambio no solo reduce el uso de recursos
físicos, como papel y tinta, sino que también simplifica y estandariza los procedimientos
contables y tributarios tanto para los contribuyentes como para la SUNAT.
Al adoptar este sistema, los contribuyentes experimentan una mayor facilidad en la
generación y gestión de sus documentos de pago, ya que pueden realizar estos procesos
de manera electrónica, desde cualquier lugar con acceso a internet. Además, al eliminar
la necesidad de mantener registros físicos, se reduce el riesgo de pérdida, deterioro o
falsificación de documentos, lo que fortalece la seguridad y confiabilidad de las
transacciones comerciales.
Por otro lado, la implementación del CPE también beneficia a la SUNAT al facilitar la
fiscalización y el control tributario. Al contar con registros electrónicos precisos y
fácilmente accesibles, la SUNAT puede realizar un monitoreo más efectivo de las
actividades comerciales, identificar posibles irregularidades y combatir la evasión fiscal
de manera más eficiente. Esto se traduce en una mayor recaudación de impuestos y en
una mayor integridad del sistema tributario en su conjunto.
Tanto negocios en general como trabajadores independientes experimentan ventajas
tanto cualitativas como cuantitativas gracias al sistema de Comprobantes de Pago
Electrónicos (CPE). Impulsa la reducción de gastos, la administración efectiva de
recursos y la mejora de procesos, lo cual eleva la capacidad competitiva de estas
organizaciones. Además, impulsa el uso de la factura negociable o factoring electrónico,
especialmente a favor de las pequeñas y microempresas (PYME).

7
 Con este sistema tanto los contribuyentes como la Administración Tributaria encuentran
un proceso más ágil y eficiente para cumplir con sus responsabilidades fiscales, al
facilitar la gestión contable procesando automáticamente los datos de los documentos de
facturación digital. Esto contribuye a una mayor eficiencia, transparencia y cumplimiento
tributario en el país.(Barreix & Zambrano, 2018)
2.2.3. Sistemas de Emisión de Comprobantes de Pago
En Perú, este sistema consta de dos elementos centrales: Sistema de Emisión Electrónica
- Sol (Portal) y el Sistema de Emisión Electrónica integrado en los sistemas internos de
los contribuyentes.(De Velazco Borda, 2016)
Sistemas de emisión electrónica - SUNAT Operaciones en Línea (SOL)

Está alojado en el portal de la SUNAT, es una herramienta libre y gratuita que realiza de
manera muy sencilla la emisión de diversos recibos electrónicos: facturas, boletas de
venta, notas y recibos por honorarios. Este software está especialmente diseñado para
pequeñas y microempresas (PYME) con un volumen limitado de transacciones, también
para trabajadores autónomos que emiten recibos por honorarios. Su propósito consiste
en disminuir los gastos y simplificar el acatamiento de las cargas fiscales asociadas con
la emisión de comprobantes de pago.

Entre sus características principales destacan: gratuito y accesible a través de internet, la

generación automática de serie y número para los comprobantes electrónicos, no es
necesario que el emisor ni el receptor conserven físicamente los comprobantes
electrónicos, ya que la SUNAT los almacena de forma electrónica, posibilidad de
consultar y descargar los comprobantes electrónicos, capacidad para enviar una copia del
comprobante electrónico por correo electrónico, para las facturas y boletas de venta, el
sistema automatiza la generación del registro de ingresos y ventas de manera automática.
(Barreix & Zambrano, 2018)
El modelo de solución para el proceso de facturación electrónica mediante Operaciones
en Línea (SOL) se puede ilustrar a continuación:

Figura II.1. Facturación Electrónica desde el portal de SUNAT

Fuente: (Barreix & Zambrano, 2018)

8
En la Figura II.1. Facturación Electrónica desde el portal de SUNAT , La factura electrónica
fue creada por el emisor electrónico mediante portal web de la SUNAT, utilizando su
clave SOL (firma electrónica) para acceder al sistema. Este documento tiene plena
validez legal y es totalmente gratis para la persona inscrita en el portal SUNAT. Si el
receptor es electrónico, la factura se notificará automáticamente al buzón electrónico
establecido por la SUNAT para dicho propósito, aunque también se puede enviar por
correo electrónico si así se prefiere.
Sistemas de emisión electrónica desde los sistemas del contribuyente
Dirigido a grandes compañías o aquellas que necesitan generar unos grandes volúmenes
de comprobantes de pago electrónicos. Es el procedimiento mediante el cual los
contribuyentes emiten facturas, boletas de venta y notas (crédito y débito) directamente
a partir de sus propios sistemas, de acuerdo con lo estipulado en la Resolución de
Superintendencia N° 097-2012/SUNAT y sus modificaciones.
Entre las características clave destacan:
 La SUNAT tiene la facultad de elegir a ciertos aportantes para que utilicen
obligatoriamente la factura electrónica, o pueden optar voluntariamente por
inscribirse al sistema presentando una solicitud de autorización a través de su clave
SOL.
 La condición de emisor electrónico en este sistema se obtiene al día siguiente de la
notificación de la resolución donde se aprueba la solicitud de adhesión voluntaria al
Sistema de Emisión Electrónica del contribuyente, o en los tiempos establecidos por
la normativa de la SUNAT que requiere su afiliación obligatoria al sistema.
 Antes de comenzar a emitir facturas electrónicas, es requisito el proceso de
homologación, donde se realizarán pruebas para garantizar la conformidad con los
estándares establecidos.
 La condición de emisor electrónico es definitiva y no se pierde en ninguna
circunstancia.
 Se generan en formato XML, siguiendo los patrones dados por la SUNAT.
 Utilizan firma digital para garantizar su autenticidad e integridad.
La "factura electrónica emitida desde los sistemas del contribuyente" involucra varios
pasos clave. En primer lugar, el contribuyente debe someterse al proceso de
homologación, donde implica resaltar satisfactoriamente un protocolo de pruebas que
consta de 99 casos de uso. Una vez aprobado este proceso, el contribuyente recibe la
autorización para poder realizar los comprobantes de pago electrónicos.
Una vez autorizado, el aportante tiene dos opciones para emitir los comprobantes
electrónicos:
Emisión directa por el contribuyente: El contribuyente puede generar los comprobantes
de pago electrónicos utilizando su propio sistema desarrollado internamente o mediante
el manejo del sistema de facturación electrónica proporcionada por SUNAT, conocida
como "facturador".
Emisión a través de un proveedor de servicios electrónicos (PSE): Alternativamente, el
contribuyente puede optar por que un tercero, denominado "proveedor de servicios
electrónicos" (PSE), emita los comprobantes en su nombre. Estos proveedores ofrecen
servicios especializados para la generación y gestión de facturas electrónicas, lo que
puede resultar conveniente para aquellos contribuyentes que prefieran externalizar esta
función o que no cuenten con los recursos técnicos para hacerlo internamente. El modelo
de solución para el desarrollo de facturación electrónica mediante los sistemas del
contribuyente se visualiza en el siguiente gráfico:

9
 Figura II.2. Facturación Electrónica desde los sistemas del contribuyente
Fuente: (SUNAT, 2020)

Según la Figura II.2 El emisor electrónico será responsable de gestionar la factura

electrónica mediante el uso de Internet. Para ello, tendrá que establecer un sistema interno
o recurrir a los servicios proporcionados por un proveedor de servicios electrónicos
(PSE). Es importante utilizar la firma digital en la factura electrónica para asegurar su
autenticidad y validez legal. Además, el emisor gestiona un servicio web en su página
que permita la consulta de los comprobantes de pago electrónicos emitidos en los últimos
doce meses.
Cuando el receptor es electrónico, la factura se notificará según lo acordado entre las
involucrados, típicamente de manera automatizada a través de un "web service" en sus
dispositivos informáticos. Sin embargo, cuando el receptor no tiene capacidad
electrónica, como en el caso de personas naturales consumidoras finales, la factura
electrónica debe contar con una versión impresa. Esta versión impresa debe ser entregada
físicamente y debe incluir un código de barras unidimensional, requisito establecido
desde el año 2018.
La adopción de este enfoque involucra una importante inversión en implementación, así
como la necesidad de contar con un equipo capacitado en aspectos contables e
informáticos para garantizar el correcto envío en línea de los documentos electrónicos.
Esto conlleva el desarrollo de una solución de software que se integre con el sistema ERP
de la empresa, automatizando el proceso completo que abarca desde la emisión y firma
digital de los comprobantes hasta su envío a la SUNAT, la recepción de la "Constancia
de Recepción" y su posterior entrega al cliente.
Si la empresa no puede implementar este procedimiento en los tiempos brindados por
SUNAT o si el análisis costo-beneficio no lo justifica, puede optar por contratar a un
PSE. Estas empresas especializadas pueden ofrecer economías de escala y experiencia
en el proceso, permitiendo que la empresa adquiera la información del módulo de
facturación de su ERP y transfiera el resto del proceso al PSE. (De Velazco Borda, 2016)

10
2.2.4. Proceso de Homologación

El trámite para obtener la certificación como Proveedor de Servicios Electrónicos,

conforme lo indicado en la Resolución de Superintendencia Nº 199-2015/SUNAT,
representa un hito esencial en la autorización. Este paso verifica que la generación y
transmisión de variados documentos electrónicos, incluyendo facturas, boletas, notas
de crédito y débito, así como resúmenes diarios y notificaciones de anulación, efectúen
con los lineamientos de la SUNAT.
Este proceso no solo asegura la adherencia a las normativas, sino que también implica
un examen riguroso del estándar UBL 2.0, sustentado por la Resolución de
Superintendencia Nº 097-2012/SUNAT, que constituye la piedra angular del esquema
de emisión de documentos de pago electrónicos. El inicio de este procedimiento
requiere que el contribuyente formule una petición oficial en el servicio de Operaciones
en Línea de la SUNAT.
Con la petición en curso, se establece una batería de pruebas, conocida como "set de
pruebas", que incluye escenarios predeterminados para la creación de toda clase de
documentos electrónicos. Cada escenario precisa los detalles y datos necesarios,
enfocándose mayormente en la secuencia y numeración, aunque se deja al criterio del
contribuyente el aporte adicional de cualquier otro dato.
Al concluir o expirar el tiempo de este trámite, y una vez revisada la satisfacción de las
condiciones requeridas, la SUNAT informa sobre el resultado de la autorización
mediante el buzón SOL del contribuyente.(Escudero Llamocca, 2019)

2.2.5. Comprobantes de pago

Se trata de un tipo de registro que puede presentarse en formato físico o electrónico, y

que tiene como propósito evidenciar la transacción de bienes, servicios o uso de
recursos. Este registro puede adoptar múltiples formatos, como facturas, recibos,
boletas, entre otros, y su función principal es validar y oficializar la transacción
comercial entre las partes involucradas, así como el traspaso de propiedad o la
prestación de servicios acordada. (Guevara Bernal, 2018)

a) Facturas

Se emplea en transacciones comerciales entre empresas o individuos que requieren

respaldar el pago del Impuesto General a las Ventas (IGV) en sus compras, con el
fin de aprovechar el "crédito fiscal" asociado. Además, el comprobante de pago se
considera un gasto o costo válido para propósitos tributarios.

b) Recibos por honorarios

Es utilizado por personas que ejercen de manera independiente cualquier

profesión, arte, ciencia u oficio.

c) Boleta de venta

Se utilizan en transacciones con personas finales, y no otorgan derecho a crédito

fiscal, no se permite justificar costos o gastos para fines tributarios.

11
 d) Liquidaciones de compra

Este comprobante se usa en transacciones con productores o acopiadores de

materias primas provenientes de actividades como agricultura, pesca artesanal,
extracción de madera, minería aurífera artesanal, artesanía, entre otras. Estos
productores o acopiadores, como pequeños mineros, artesanos o agricultores que
operan en áreas remotas y no tienen un Registro Único de Contribuyentes (RUC).

e) Tickets o cintas de máquina registradoras

Se utiliza en transacciones con consumidores finales y no acepta la reclamación

de crédito fiscal ni la justificación de gastos o costos para propósitos fiscales. No
obstante, si el comprador requiere justificar crédito fiscal o gastos para fines
tributarios, debe identificarse con su número de RUC, apellidos y nombres, o
denominación/razón social, especificando el monto del impuesto registrado en la
transacción
f) Guía de remisión del transportista

El transportista emite este instrumento cuyo fin es respaldar el traslado de artículos

a solicitud de terceros, en el que se debe incluir los detalles de la compañia
contratante, como su RUC y nombre completo o razón social.

g) Guía de remisión del remitente

Emitido por el remitente cuyo fin es respaldar el transporte de producto en el
contexto de compras, ventas y prestación de servicios que pueden implicar
transformación de bienes, arrendamiento, consignación y traslados entre diferentes
establecimientos de una misma empresa, entre otros escenarios.
2.2.6. Proveedor de Servicios Electrónicos – PSE

Desempeña un papel esencial al facilitar la transición de los emisores hacia la emisión

electrónica de comprobantes de pago. Sus responsabilidades incluyen implementar
plataformas tecnológicas adecuadas y gestionar todos los procesos relacionados con la
emisión, validación, firma y envío de los comprobantes electrónicos.

Además asegura la operatividad técnica, el PSE se encarga de asegurar que se cumplan

las normativas y regulaciones establecidas por la autoridad tributaria. Esto implica
asegurarse de que los comprobantes generados cumplan con los estándares y requisitos
exigidos, así como mantenerse al día con los cambios normativos que puedan surgir.
El respaldo y la experiencia proporcionados por el PSE son invaluables para los
emisores, ya que les permiten centrarse en sus actividades principales sin preocuparse
por la complejidad técnica y normativa asociada con la emisión electrónica de
comprobantes de pago. Además, el PSE ofrece servicios adicionales, como
almacenamiento seguro de los comprobantes, generación de informes y análisis de
datos, así como soporte técnico y legal. (Escudero Llamocca, 2019).
2.2.7. Operador de Servicios Electrónicos – OSE

Verifica que los comprobantes de pago electrónicos (CPE) cumplan con las exigencias
para ser generados a través del SEE-OSE, tras superar el proceso de inscripción y
homologación ante la SUNAT.(Escudero Llamocca, 2019)

12
2.2.8. Sistema informático

Constituye múltiples elementos interconectados, cuya función es procesar información

y llevar a cabo diversas tareas de manera coordinada. Fernández ( 2006) explica que, a
pesar de la diversidad de sistemas, en su gran mayoría se describen mediante un modelo
compuesto por cinco componentes principales: elementos de entrada, elementos de
salida, sección de transformación, mecanismos de control y objetivos.

2.2.9. Aplicación Web

Software que emplea navegadores web y tecnología online donde se llevan a cabo
distintas funciones para la cual ha sido diseñada.

Figura II.3. Arquitectura de una aplicación Web

Fuente: (MAXCDN one, 2017)
Estas son programadas utilizando lenguajes compatibles con el navegador, como
JavaScript y lenguaje de etiquetas.

Existen dos tipos principales de aplicaciones web: dinámicas y estáticas. Las webs
dinámicas requieren procesamiento del lado del servidor, que es el que realiza tareas
específicas solicitadas por el usuario antes de enviar la respuesta al navegador. Por otro
lado, las aplicaciones estáticas no requieren procesamiento en el servidor y se muestran
tal como están almacenadas en el servidor web.

Para que una aplicación web funcione correctamente, se requiere una infraestructura
específica. Esto incluye un servidor web que gestiona las solicitudes del cliente y
entrega las páginas web al navegador, un servidor de aplicaciones que realiza peticiones
del cliente, en muchos casos, una base de almacenamiento que gestionar los datos de la
aplicación.

La tecnología utilizada en el servidor de aplicaciones puede variar según las

necesidades y preferencias del desarrollador. Algunas de estas tecnologías incluyen
ASP.NET, ASP, ColdFusion, PHP y JSP, entre otras. Cada una de estas tecnologías
tiene sus propias características y ventajas, y la elección de una sobre otra dependerá
de las necesidades específicas de la aplicación y las habilidades del equipo de
desarrollo.

En resumen, las aplicaciones web son programas accesibles a través de un navegador

web, codificados generalmente en JavaScript y HTML. Pueden ser dinámicas o
estáticas, requiriendo un servidor web, un servidor de aplicaciones y, en ocasiones, una
base de datos para funcionar correctamente. La tecnología utilizada en el servidor de
aplicaciones puede variar, y la elección depende de las necesidades y preferencias del
proyecto.

13
 Beneficios de una aplicación Web
• Funcionan en diversas plataformas, sin importar el sistema operativo o el dispositivo,
siempre y cuando el navegador sea compatible.
• Se utiliza la misma versión de la aplicación, lo que elimina posibles problemas de
compatibilidad.
• No requieren instalación en el disco duro, lo que ayuda a evitar limitaciones de
espacio.
• Las aplicaciones web en modelos de suscripción reducen la piratería de
software.(MAXCDN one, 2017).

2.2.10. Base de datos (BD)

Conjunto organizado de información que se centra en un tema específico y que

proporciona una base sólida para diversas operaciones, como la consulta de datos, la
elaboración de conclusiones basadas en la información. Se considera que cualquier
colección de datos que cumpla con estos criterios puede ser clasificada como una base
de datos, incluso si no está almacenada en un medio informático.

En esencia, una BD es un repositorio estructurado de información que se organiza de

manera que sea fácilmente accesible y utilizable para los usuarios. Su objetivo principal
es proporcionar un recurso valioso para la gestión y análisis de datos, permitiendo a las
organizaciones gestionar eficazmente su información, extraer conocimientos relevantes
y tomar decisiones fundamentadas.

Las BD tienen gran capacidad para almacenar datos de manera organizada y coherente,
lo que facilita su recuperación y consulta según sea necesario. Además, las bases de
datos suelen estar diseñadas para ser escalables y adaptables, lo que significa que
pueden crecer y evolucionar junto con las necesidades cambiantes de la
organización.(Torres Remon, 2012).

Entonces se puede decir que una base de datos es un recurso vital para las
organizaciones, proporcionando un medio para almacenar, organizar y gestionar
información de manera eficiente.

Objetivos de los sistemas de base de datos

 Los datos y los programas de aplicación son independientes entre sí.

 Se minimiza la redundancia de datos.
 Se integran y sincronizan las bases de datos.
 Se asegura la protección y la capacidad de recuperación de los datos.
 La información es fácil de manejar.
 Existe un control centralizado sobre el sistema.

2.2.11. MySQL
Sistema de gestión de bases de datos relacional (SGBDR), es libre, conocido por su
rapidez, robustez y facilidad de uso, lo que lo convierte en una opción muy popular
donde se administra datos en redes, especialmente en entornos cliente/servidor. Su
amplia gama de herramientas y compatibilidad con varios lenguajes de programación
han contribuido a su popularidad. La disponibilidad de su código fuente para cualquier

14
 persona, lo que permite su modificación y distribución libremente, ha sido clave en su
amplia adopción y éxito en la comunidad de desarrolladores y empresas a nivel global.

MySQL es ampliamente reconocido por su estrecha integración con el servidor web

Apache y el lenguaje de programación PHP. Esta combinación ofrece una sólida y
escalable solución para el desarrollo de aplicaciones web dinámicas. La integración sin
problemas entre MySQL, Apache y PHP permite desarrollar sitios web basados en
datos de manera eficiente. Además, MySQL brinda particularidades avanzadas que
incluyen soporte para transacciones ACID, replicación de datos, indexación completa
de texto y gestión de permisos. Estas características hacen que MySQL sea una opción
muy atractiva para una variedad de aplicaciones, desde sitios web simples hasta
sistemas de gestión de bases de datos empresariales complejos. (Thibaud, 2006).
2.2.12. Framework

Se compone de elementos físicos y lógicos organizados de manera estructurada para

facilitar su reutilización en el diseño y desarrollo de sistemas de información nuevos.
(Minetto, 2007).

Los frameworks son esencialmente estructuras que ofrecen un conjunto de buenas

prácticas de desarrollo, encapsuladas en una serie de bibliotecas que trabajan juntas
bajo un esquema coherente de colaboración.

La principal ventaja de los frameworks radica en que ofrecen una estructura predefinida
y bien organizada para el desarrollo de sistemas..

Además, los frameworks suelen incluir una serie de funcionalidades comunes y

componentes reutilizables que pueden ser fácilmente adaptados y personalizados para
satisfacer las necesidades específicas de cada proyecto. (Gutierrez).

2.2.13. Metodologías de desarrollo de software

Son enfoques organizados y sistemáticos que buscan una mayor calidad y eficiencia del
desarrollo de software. Aunque no existe una metodología única que se aplique
universalmente a todos los proyectos, es crucial elegir y adaptar la metodología
apropiada para cada proyecto particular, considerando sus características y requisitos
específicos. (EcuRed:Enciclopedia cubana, 2017).

2.2.14. RUP

El Proceso Unificado de Rational (RUP) emerge como método de renombre en la

ingeniería de software, caracterizado por su enfoque detallado y estructurado de gestión
de proyectos de desarrollo de software. Este método no solo se centra en la asignación
eficiente de responsabilidades y tareas, sino que también garantiza el desempeño de
los requisitos de los usuarios, manteniendo el proyecto dentro de los márgenes de
tiempo y presupuesto. RUP se fundamenta en principios clave como la iteración, que
permite el desarrollo por fases y facilita la evaluación continua; la colaboración, que
asegura una comunicación efectiva entre los stakeholders; y un enfoque en la
arquitectura del sistema, donde subraya la importancia de una estructura sólida para el
desarrollo. Cada una de estas fases, desde la concepción hasta la transición, está

15
diseñada para optimizar los recursos y maximizar la calidad del software entregado.
Así, RUP se establece como un marco de referencia esencial para los equipos de
desarrollo, ofreciendo un equilibrio perfecto entre flexibilidad y control, lo cual es
crucial para el éxito en el competitivo entorno del desarrollo de software a nivel
mundial.
RUP se fundamenta en principios sólidos de ingeniería de software y prácticas
recomendadas, centrándose en la entrega iterativa e incremental de funcionalidades del
software. Esta metodología divide el desarrollo en ciclos cortos y repetitivos llamados
iteraciones, durante los cuales se construye, prueba y entrega una porción adicional de
funcionalidad del software. Esta metodología incremental posibilita una
retroalimentación temprana por parte de los usuarios y otras partes involucradas., lo
que ayuda a mitigar riesgos y a mantener el proyecto en curso hacia los objetivos
establecidos.
RUP ofrece una variedad de artefactos y guías que sirven como plantillas y modelos
para el desarrollo de software, incluyendo documentos, modelos, diagramas y otros
elementos para capturar y comunicar los requisitos, el diseño y la arquitectura del
proyecto. Además, define roles y responsabilidades dentro del equipo de desarrollo para
asegurar que cada miembro tenga claras sus funciones y contribuya al éxito del
proyecto.
Una característica distintiva de RUP es su flexibilidad y capacidad de adaptación a
diferentes contextos y tipos de proyectos. Aunque proporciona un marco de trabajo
estructurado, RUP puede ser personalizado y ajustado para cubrir las exigencias
específicas de cada organización y proyecto, permitiendo a los equipos utilizar las
partes más relevantes y útiles para su situación particular, evitando la rigidez y el exceso
de procesos. (Rueda Chacón, 2006 ).
Fases
Esta metodología está estructurada en cuatro fases secuenciales, cada una concluye con
una evaluación conocida como "Revisión del ciclo de vida de la finalización de la fase".
Esta revisión se lleva a cabo al final de cada fase para establecer si se han logrado los
objetivos definidos. Si la evaluación es satisfactoria, el proyecto avanza a la siguiente
fase.

Figura 2.4. Fases de la metodología RUP

Fuente: (Metología RUP, 2017)

16
 Muestra una sucesión de etapas, cada una de las cuales genera una iteración del
producto. Cada etapa está formada por un conjunto específico de iteraciones, las cuales
son:

Tabla II.1.
Fases de la Metodología RUP

Fases Descripción
Reconocer y estudiar las necesidades y los objetivos del cliente, y se lleva a cabo
una evaluación inicial de viabilidad técnica y económica del proyecto. Se
Inicio
establecen los recursos necesarios, se definen los roles y responsabilidades del
equipo, y se elabora un plan preliminar del sistema.
Se elabora un estudio más detallado de los requisitos y se define la arquitectura
del sistema. Se llevan a cabo iteraciones de desarrollo para validar y refinar los
Elaboración requisitos, y se mencionan los trances principales del proyecto. Al final de esta
fase, se debe tener una arquitectura establecida y una comprensión clara de los
requisitos y riesgos del proyecto.
Aquí se desarrolla y se prueba el sistema en función de la arquitectura definida en
la fase de Elaboración. Se llevan a cabo múltiples iteraciones de desarrollo para
construir y probar las diferentes partes del sistema, incorporando los cambios y
Construcción
mejoras necesarias conforme vaya avanzando el proyecto. Se implementa un
enfoque iterativo e incremental para desarrollar y refinar el software, lo que
permite una entrega de funcionalidades al cliente
En esta fase se prepara el sistema para su despliegue y entrega al cliente. Se
realizan diferentes pruebas para brindar calidad y el rendimiento del software, y
se lleva a cabo la capacitación del usuario final y el personal de soporte. Se
Transición desarrolla un plan de implementación y se realiza la migración de datos y la
instalación del sistema en producción. Además, se proporciona soporte continuo
al cliente y se realizan ajustes y mejoras según sea necesario después de la entrega
del sistema.

Nota. En conclusión se puede decir que las cuatro fases del Rational Unified Process
(RUP) proporcionan una estructura sistemática y disciplinada para el desarrollo de
software, desde la definición inicial del proyecto hasta su entrega y despliegue. Cada
fase tiene sus propios objetivos, actividades y entregables.

GLOSARIO DE TERMINOS BÁSICOS

Angular
Conjunto de utilidades JavaScript para desarrollo web donde un grupo de herramientas y
funciones pueden ser utilizadas para construir aplicaciones web en el navegador del cliente(Vega
Campos, 2018).
Certificado digital
Un documento digitalmente firmado y autenticado por una entidad de certificación que sujeta
una clave pública con la identificación de una persona o entidad jurídica.(De Velazco Borda,
2016)
Factura Electrónica
Un registro electrónico de transacciones comerciales de una entidad, que garantiza la
autenticidad, integridad y legibilidad en diversas circunstancias y ante todos los participantes
involucrados en el proceso en diferentes contextos. (Barreix & Zambrano, 2018)

17
Firma digital
Se emplea para verificar la autenticidad de un documento digital y certificar que no ha sufrido
alteraciones desde su versión original, similar a cómo se utiliza la firma en papel para asegurar
la autenticidad del documento físico. (Navarro Flores, 2017)
JavaScript
Tecnología centrada en el navegador, se refiere a herramientas y técnicas de programación
diseñadas para ejecutarse en el navegador del usuario, lo que permite la interacción directa con
la página web sin necesidad de comunicarse constantemente con el servidor. (Saavedra Arango,
2010).
Laravel
Conjunto de herramientas de código abierto destinado al desarrollo en PHP, con una filosofía
centrada en lograr un código expresivo y elegante, con el objetivo de crear aplicaciones y
servicios web.(Ramirez Coronado, 2017).
Modelo Cliente –Servidor
Arquitectura en la que la información se encuentra distribuida entre múltiples nodos o servidores,
permitiendo a los usuarios acceder a ella de manera transparente, independientemente de la
plataforma utilizada.(UDLAP, 2020)
PHP
Es un lenguaje de programación, cuya fuente es accesible y puede ser modificado por la
comunidad de desarrolladores. Este enfoque fomenta la colaboración y la mejora continua del
lenguaje. Al ser interpretado en el servidor, este lenguaje permite ejecutar código directamente
en el servidor web, lo que lo hace especialmente útil para la generación dinámica de contenido
web. Su naturaleza interpretada facilita el desarrollo rápido de aplicaciones web, ya que los
cambios pueden implementarse de manera ágil sin necesidad de compilar el código. Además, al
estar disponible en múltiples plataformas, este lenguaje es ampliamente utilizado en diversos
entornos de desarrollo web. (Cobo, Gómez, Pérez, & Rocha, 2005).
REST
Se trata de una arquitectura de desarrollo web que es compatible con cualquier cliente HTTP y
se destaca por su simplicidad en comparación con otras arquitecturas como XML-RPC o
SOAP.(Escudero Llamocca, 2019)
SOAP
Es un protocolo que permite realizar servicios web sin estado, a través TCP y con un formato
XML. (CHAKRAY, 2020)
SUNAT
Entidad pública descentralizada del sector de Economía y Finanzas. Posee personalidad jurídica
de derecho público, así como patrimonio propio y autonomía en sus funciones económicas,
administrativas, técnicas y financieras. Actualmente, opera como un pliego y unidad
ejecutora.(SUNAT, 2020)
UBL
Significa Lenguaje Universal de Negocios, es una norma diseñada para facilitar la automatización
del intercambio de datos financieros mediante el uso del lenguaje XML.(UBL ESPAÑA, 2020)
Web Services

18
Es un método de comunicación entre máquinas conectadas en red que facilita la interoperabilidad.
Implica el proceso mediante el cual un cliente envía una solicitud al servidor y este responde con
los datos solicitados, permitiendo la transferencia de información entre ambas partes.(ARSYS,
2020)

XML
El eXtensible Markup Language (XML), es un estándar de formato libre que posibilita la
estructuración de datos o información mediante etiquetas. (De Velazco Borda, 2016)

MARCO REFERENCIAL
2.4.1. Datos generales

 Institución Educativa Privada: “PREMIUM”

 Resolución de Autorización: RDR N°1169-2013 y RDR N° 4852-2018
 Modalidad: Educación Básica Regular
 Dirección: Calle Cuzco N° 317 Piura
 Distrito: Piura
 Provincia: Piura
 Departamento: Piura
 Propietario: Guido Manuel Chávez Herrera (representante legal de la Sociedad IEP
“ASUNCIÓN S.A.C”)
 Director: José Guadalupe Morales Quiroga
 Niveles Educativos Autorizados: Primaria (1° al 6° Grados) y Secundaria (1° al 5°
Año)
 Nivel Educativo Ampliación Inicial: Jardín II Ciclo 3, 4, 5 años.

2.4.2. Visión

En el año 2023 la Institución Educativa Privada Premium, brinda servicio educativo de

calidad, con un desarrollo integral del estudiante, e imparte una educación científica y
humanística fortaleciendo sus capacidades dentro de la práctica de valores para
coadyuvar a la solución de los problemas de su comunidad, contando con una
infraestructura moderna, acorde de las necesidades de los estudiantes, Personal
directivo, Jerárquico, Docentes y Administrativos, quienes están comprometidos con el
cambio, ejerciendo un liderazgo social democrático que integra a la familia y
comunidad educativa mediante un clima institucional óptimo.

2.4.3. Objetivo general

 Proponer y proclamar al carácter preuniversitario de esta institución, actuando de

acuerdo a la normatividad vigente.
 Considerar al estudiante como el centro del proceso educativo; el respeto a su
naturaleza Biológica, Psicológica y Moral.
 Fomentar la práctica de valores y virtudes.
 Promover en el estudiante el fortalecimiento de las capacidades comunicativas,
sociales y artísticas, el razonamiento lógico, la investigación científica, la
aprobación de la tecnología del conocimiento, así como aplicar estrategias de
aprendizaje y tomar decisiones.

19
  Formar ciudadanos probos, conscientes, críticos participativos, capaces de
construir con trabajo creador y comunitario una sociedad nueva, libre, justa y
fraterna, patrocinada de la dignidad humana, de la vida y la familia.

2.4.4. Objetivos específicos

 Elevar al nivel académico y la calidad del servicio educativo, que brinde en la

I.E.P.
 Lograr el cumplimiento al máximo de las competencias previstas en el P.C.I en los
niveles Inicial, Primaria y Secundaria.
 Emplear metodologías que conduzcan al análisis y a la reflexión.
 Promover la participación activa y directa a toda la comunidad educativa en todos
los aspectos de la tarea educativa.
 Promover y desarrollar la actividad artística e incentivar la recreación y el deporte.
 Brindar una formación académica de alto nivel que permita comprender, valorar y
crear cultura.
 Promover la formación del sentimiento de identidad nacional, manifestados en una
actitud de compromiso con los valores nacionales.
 Contribuir con la preservación del medio ambiente mediante la formación de la
conciencia ecológica en el estudiante.
 Promover prácticas democráticas para el aprendizaje de los principios y valores de
la participación y organización ciudadana y estimular la autonomía y la
responsabilidad.

2.4.5. Creación

La Institución Educativa Privada PREMIUM o Colegio Premium se creó un 26 de

octubre del 2012 por iniciativa de un grupo de profesionales con amplia experiencia en
la docencia preuniversitaria en la región y un grupo de empresarios que apuestan por la
educación. Nació con él lema “INGRESO SEGURO A LA UNIVERSIDAD” y con el
respaldo de la Academia preuniversitaria Premium, resumiendo así, el sentimiento
comprometido de todos los promotores, docentes y padres de familia.

2.4.6. Estructura orgánica

 Órganos de Dirección
o Promotora
o Dirección
 Órganos de Apoyo
o Asesores externos
o Área administrativa
o Secretaria
 Órganos de Coordinación
o Coordinación de Inicial
o Coordinación de Primaria
o Coordinación de Secundaria
o Coordinación de Formación y Orientación
o Coordinación de Actividades Académicas

20
  Órganos Técnicos Pedagógicos
o Docentes del Nivel Inicial
o Docentes del Nivel Primario
o Docentes del Nivel Secundario
o Auxiliares

 Órganos de Participación
o Consejo Estudiantil
o Comité de aulas, integradas por padres de familia, tutores o apoderados

HIPÓTESIS
2.5.1. Hipótesis general

El sistema web contribuirá al control de pagos y facturación electrónica, reduciendo los

tiempos de consulta de historial de pagos, elaboración de reportes de ingresos
mensuales y la emisión de facturas en la Institución Educativa Privada PREMIUM.

2.5.2. Hipótesis especificas

 Existe variación significativa en el tiempo de consulta de historial de pagos de los

alumnos en la Institución Educativa Privada PREMIUM, antes y después de la
implementación del sistema Web.
 Existe variación significativa en el tiempo de elaboración de reportes de ingresos
mensuales en la Institución Educativa Privada PREMIUM, antes y después de la
implementación del sistema Web.
 Existe variación significativa en el tiempo de emisión de facturación en la
Institución Educativa Privada PREMIUM, antes y después de la implementación
del sistema Web.

DEFINICIÓN Y OPERACIONALIZACIÓN DE VARIABLES

2.6.1. Variable independiente

Sistema Web
2.6.2. Variables dependientes

Mejora de los procesos que realizan el área de administración y contabilidad:

 Consulta de historial de pagos de alumno.
 Reportes de ingresos mensuales.
 Emisión de comprobantes electrónicos.

21
2.6.3. Operacionalización de variables
Tabla II.2.
Operacionalización de variables

Definición Conceptual Definición operacional Dimensiones Indicadores Ítems

VARIABLE Este conjunto de partes, Métrica de · Nivel de satisfacción de I1 (Tabla II.3. Indicadores
INDEPENDIENTE compuesto por hardware, calidad los usuarios del sistema. de las variables)
Sistema Web software y las personas que lo · Usabilidad
utilizan, se interconectan y · Confiabilidad
colaboran entre sí para · Seguridad
almacenar, procesar y gestionar
información con un propósito
compartido. En otras palabras,
constituye un sistema
informático, donde cada
componente desempeña un
papel fundamental en la
realización de tareas específicas
para alcanzar los objetivos
establecidos. (ALEGSA, 2016)
VARIABLE Procesos que realizan el área de Tiempo · Tiempo promedio de I1 (Tabla II.3. Indicadores
DEPENDENTE administración y contabilidad. consulta de historial de pagos. de las variables)
Mejora de los procesos · Tiempo promedio de I1 (Tabla II.3. Indicadores
que realizan las áreas reporte de ingresos de las variables)
de administración y mensuales. I1 (Tabla II.3. Indicadores
contabilidad. · Tiempo promedio para de las variables)
la emisión de comprobantes
electrónicos.

22
 2.6.4. Indicadores
Tabla II.3.
Indicadores de las variables

Ítem Indicador Definición Conceptual Definición Operacional Técnica Instrumentos

I1 Nivel de Es el nivel de estado de ánimo de un Se hará uso de la escala de LIKERT, la cual gradúa los ítems Encuesta Encuesta N° 01
satisfacción de los individuo que resulta de la comparación en 5 niveles.
usuarios del entre el rendimiento percibido del
sistema producto o servicio con sus expectativas.
I2 Usabilidad Es el nivel de calidad de la experiencia que Se hará uso de la escala de LIKERT, la cual gradúa los ítems Encuesta Encuesta N° 02
tiene un usuario cuando interactúa con el en 5 niveles.
sistema Web.
I3 Confiabilidad Es la capacidad de desempeñar una Se hará uso de la escala de LIKERT, la cual gradúa los ítems Encuesta Encuesta N° 03
función requerida, en condiciones en 5 niveles.
establecidas durante un período de tiempo
determinado.
I4 Seguridad La seguridad que se tiene en ser ejecutada Vulnerabilidades Observación Guías de
el sistema Web. Observación
I5 Tiempo promedio Es la medida de tiempo que se requiere 𝑁 Observación Guías de
(𝑇𝑓 − 𝑇𝑖)
de consulta de para consultar historial de pagos de cada 𝑇𝑝𝑟 = ∑ Observación
historial de pagos. alumno. 𝑁
𝑘=1
Tf: Tiempo final al consultar un historial de pago
Ti: Tiempo inicial al con
N: Número de historial de pagos.sultar un historial de pago

I6 Tiempo promedio Es la medida de tiempo que se requiere 𝑁 Observación Guías de

(𝑇𝑓 − 𝑇𝑖)
de reporte de para obtención de reportes de ingresos 𝑇𝑝𝑏 = ∑ Observación
ingresos mensuales por concepto de pagos 𝑁
𝑘=1
mensuales. (matricula, pensión, etc.). Tf: Tiempo final al obtener reporte de ingresos mensual
Ti: Tiempo inicial al obtener reporte de ingresos mensual
N: Número de reportes mensuales

I7 Tiempo promedio Es la medida de tiempo que se requiere 𝑁 Observación Guía de

(𝑇𝑓 − 𝑇𝑖)
para la emisión de para emitir un comprobante electrónico 𝑇𝑝𝑒𝑐 = ∑ Observación
comprobantes (factura o boleta). 𝑁
𝑘=1
electrónicos. Tf: Tiempo final al emitir un comprobante electrónico
Ti: Tiempo inicial al emitir un comprobante electrónico
N: Número de comprobantes electrónicos

23
24
 III. MARCO METODOLÓGICO
ENFOQUE

El enfoque cuantitativo adoptado en esta investigación se manifiesta en la precisión con la que

se han seleccionado y definido los indicadores clave, que no solo sirven de base para la
recolección sistemática de datos sino que también son vitales para cuantificar aspectos críticos
de la solución implementada. Estos indicadores están meticulosamente diseñados para medir el
tiempo invertido en las diferentes operaciones relacionadas al desarrollo acometido en la
institución educativa, creación de reportes, así como, la emisión de comprobantes de origen
digital.
La metodología cuantitativa permite entonces convertir estos procesos y percepciones en datos
numéricos que pueden ser analizados estadísticamente, lo que facilita la identificación de
mejoras operativas y la extensión de la adopción del sistema por parte de los participantes. De
esta forma, el enfoque no solo ofrece una medición de la eficiencia del sistema sino que también
proporciona una visión clara de su efectividad y recepción entre los actores involucrados.

DISEÑO
Se define como no experimental, basado en la implementación de métodos de seguimiento
directo, los cuales facilitan al investigador la documentación y el examen detallado de las
operaciones habituales vinculadas a la revisión de registros de pagos, generación de resúmenes
de ingresos y la producción de documentos de transacciones electrónicas en la I.E.P.
PREMIUM. Este enfoque posibilita una comprensión profunda de las operaciones cotidianas y
una medición exacta de los indicadores pertinentes a la variable dependiente, sin que el
investigador modifique o interfiera en el flujo natural de estas actividades. Es esencial que el
seguimiento de los procedimientos observados se realice de forma imparcial y libre de
influencias externas, lo que garantiza una representación precisa y veraz de los procedimientos
en su ambiente operativo natural.

NIVEL
En consonancia con el diseño no experimental, el nivel de investigación es eminentemente
descriptivo. Este nivel se caracteriza por su capacidad para documentar y detallar las
características actuales del sistema web y su interacción con los usuarios. Utilizando
representaciones gráficas como diagramas, se facilitará la visualización de los datos y la
estructura del sistema, lo que permitirá tanto a los interesados y a quienes dirigen el proceso
decisorio entender el funcionamiento del sistema y evaluar su impacto. Los diagramas
proporcionarán una herramienta analítica para descomponer, ilustrar y comunicar los
componentes y la arquitectura del sistema, así como para mostrar hallazgos de forma nítida, así
como accesible.

TIPO
Aplicada, lo que significa que el objetivo principal no se limita a la generación de
conocimientos teóricos, sino que se enfoca principalmente en la aplicación práctica de estos
conocimientos. Este estudio está diseñado para explorar cómo esta solución desarrollada influye
directamente sobre las operaciones cotidianas de la I.E.P. PREMIUM, específicamente en los
procesos de consulta de historial de pagos, generación de reportes de ingresos mensuales y
emisión de comprobantes electrónicos.

25
La intención es ir más allá de la comprensión conceptual de estos procesos y avanzar hacia la
mejora tangible y la optimización de las prácticas existentes. Al aplicar los hallazgos en un
contexto real, el estudio busca ofrecer soluciones prácticas y efectivas adaptados a los
requerimientos particulares del centro educativo, asegurando así una implementación efectiva
y una adopción exitosa del sistema propuesto.
De esta manera, la investigación aplicada pretende producir resultados inmediatos y aplicables,
con el propósito de resolver problemas específicos mejorando la labor financiera y
administrativa. Se prevé que los desenlaces de esta exploración no solo proporcionen evidencia
de la utilidad y el valor del nuevo sistema web sino que también faciliten la resolución de
estrategias fundamentada en información y el perfeccionamiento incesante de los
procedimientos organizacionales.

SUJETOS DE LA INVESTIGACIÓN
Comprenden el conjunto completo de documentos digitales y contables generados en el ámbito
administrativo y contable de la I.E.P. PREMIUM. Esto incluye, pero no se limita a, boletas
electrónicas, resúmenes diarios, libros contables y notas electrónicas. Cada uno de estos
elementos representa una faceta del flujo de trabajo administrativo y contable de la institución
y, como tales, son cruciales a fin de valorar la efectividad de la plataforma web instaurada.
TÉCNICAS E INSTRUMENTOS
En esta sección se da especial énfasis a la observación meticulosa como la piedra angular del
proceso de recopilación de datos. Para registrar con exactitud los intervalos temporales
asociados a las operaciones administrativas y financieras, se despliegan guías de observación
detalladas, cuya estructura se halla especificada en el Anexo 3. La importancia de estas guías
radica en su capacidad para inmortalizar la cronología operativa previa y sucesiva a la
integración del sistema web, contribuyendo así a la consistencia y exactitud en la acumulación
de información.
En un esfuerzo complementario, se adoptarán cuestionarios para calibrar el nivel de aprobación
del sistema entre los usuarios, los cuales fueron interpretados a través del NSI (Índice Neto de
Satisfacción), ofrecieron una perspectiva cuantitativa sobre la recepción y la aprobación del
sistema por parte de la comunidad de usuarios.

MÉTODOS Y PROCEDIMIENTOS
La inspección y el manejo de los datos recogidos se realizarán mediante el uso de una aplicación
de hoja de cálculo del paquete Microsoft Office Excel. Este recurso nos facilitará la ejecución
de operaciones matemáticas exactas y la disposición de la información de una forma propicia
para el análisis cuantitativo y la valoración comparativa pre y post la puesta en marcha del
sistema. Utilizando Excel, se estimarán las variaciones porcentuales, se diseñarán
representaciones visuales como gráficos y se compilarán los datos en tablas que sinteticen los
hallazgos, además de implementar el NSI para evaluar la medida de conformidad requerida.
Dicha metodología asegura un escrutinio minucioso y ordenado, promoviendo la neutralidad y
la exactitud de los descubrimientos del estudio.

26
3.7.1. Desarrollo de la metodología RUP
Esta metodología fue adoptada para el desarrollo del sistema, se distingue por su
estructura disciplinada y su enfoque iterativo, que divide el proceso en cuatro fases
claramente definidas: inicio, elaboración, construcción y transición. Cada una de estas
fases contribuye a la maduración progresiva del proyecto, asegurando que cada aspecto
del sistema esté alineado con las necesidades del negocio y las expectativas de los
usuarios.
3.7.1.1. Fase de inicio
En la fase inicial del desarrollo del sistema se definió una visión del negocio, centrada
en resolver retrasos en la emisión de comprobantes electrónicos y mejorar la eficiencia
administrativa. Se identificaron los perfiles de los usuarios, desde el Super
Administrador hasta el Contador, especificando sus funciones dentro del sistema. Este
paso inicial también incluyó el modelado de los procesos de negocio actuales, que se
documentaron en un diagrama de casos de uso. Se establecieron los requerimientos
funcionales y no funcionales, que van desde la gestión de usuarios hasta la generación
de reportes y la emisión de comprobantes. Estos requerimientos están diseñados para
garantizar que el sistema sea eficiente, intuitivo y robusto.
a) Visión del negocio
Tabla III.1.
Visión del negocio

Problema Grupo Soluciones

Problemas específicos
general afectado esperadas
Tiempos largos · Tiempos largos para la · Oficinas de · Reducir el tiempo
en la emisión de obtención de deudas. administración empleado en realizar
comprobantes · Pagos facturados y contabilidad la consulta de
electrónicos. electrónicamente no de la historial de pagos de
registrados. institución. alumnos.
· Historial de pagos de · Padres de · Reducir el
alumnos con información familia. tiempo empleado en
errónea. realizar la consulta de
· Tiempos largos al reportes de ingresos
obtener el reporte de mensuales.
ingresos mensual. · Mejorar la
eficiencia en la
emisión de
comprobantes
electrónicos.

b) Perfiles de Usuario
Los usuarios para el sistema web para el control de pagos e integración con
facturación electrónica de la Institución Educativa PREMIUM se pueden clasificar 3
perfiles de usuario descritos a continuación como actores del sistema.
 Super Administrador: Es el encargo de gestionar los usuarios en el sistema
(registrarlo, asignarles un rol con sus concernientes permisos), gestiona las sedes
que tenga la institución y además da solución a posibles errores que pueda surgir
en la utilización del sistema.
 Administrador: Es el encargado registrar apoderados, alumnos, emitir boletas,
consultar historial de pagos e ingresos mensuales.

27
  Contador: Es el encargado de enviar el resumen diario de boletas, generar
resúmenes de emergencia, anular comprobantes, generar notas electrónicas,
realizar contingencia de comprobantes y generar libro electrónico de ventas.
c) Modelado del Negocio
El modelado del negocio son los procesos que se realizan en la empresa, esto es
previo a establecer los requisitos del sistema a desarrollar.

Figura 3.III.1.
Diagrama de caso de uso - Modelo del negocio

d) Requerimientos del sistema

Tabla III.2.
Requerimientos funcionales

CÓDIGO DESCRIPCIÓN
RF - 01 El sistema Web permitirá gestionar usuarios.
RF - 02 El sistema Web permitirá gestionar sedes.
RF - 03 El sistema Web permitirá registrar un apoderado.
RF - 04 El sistema Web permitirá registrar estudiantes.
RF - 05 El sistema Web permitirá matricular estudiante.
RF - 06 El sistema Web permitirá emitir boletas.
RF - 07 El sistema Web permitirá consultar historial de pagos.
RF - 08 El sistema Web permitirá generar y enviar resúmenes diarios.
RF - 09 El sistema Web permitirá generar resúmenes de emergencia.
RF - 10 El sistema Web permitirá anular comprobante de pago.
RF - 11 El sistema Web permitirá generar notas electrónicas.
RF - 12 El sistema Web permitirá realizar contingencia de comprobantes.

28
Tabla 3.III.3.
Requerimientos no funcionales

CÓDIGO DESCRIPCIÓN
RNF - 01 El sistema Web gestor de base de datos utilizado es MySQL.
El sistema Web debe ser eficiente en el tiempo de consultas y
RNF - 02
reportes.
El sistema Web debe facilitar la emisión de comprobantes
RNF - 03
electrónicos.
RNF - 04 El sistema Web debe ser lo más intuitivo posible.

e) Diagramas de caso de uso

Los diagramas de casos de uso se utilizan para especificar la comunicación y el
comportamiento del sistema a través de la interacción del sistema con los usuarios y /
u otros sistemas.

 Módulo de Seguridad del Sistema

Figura 3.III.2. Caso de Uso – Funciones super administrador

 Módulo Administrativo

Figura 3.III.3. Caso de Uso – Administrador

29
 Módulo de Facturación Electrónica

Figura 3.III.4. Caso de Uso – Funciones contador

30
 3.7.1.2. Fase de elaboración
En esta fase se describe las especificaciones de los casos de uso, los diagramas de
secuencia, colaboración, actividades, clases, componentes, prototipos y diagrama de
base de datos.
a) Especificación de casos de uso
 Iniciar Sesión
Tabla III.4.
Especificación de caso de uso - Inicio de Sesión
CASO DE USO Iniciar sesión
ACTORES Superadministrador, Administrador, Contador
DESCRIPCIÓN Este caso de uso empieza cuando el Superadministrador,
Administrador o Contador desean ingresar al sistema de la empresa.
PRE-CONDICIÓN El usuario tiene que haber sido registrado en el Sistema.
CURSO NORMAL DE EVENTOS
ACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMA
1. El Superadministrador,
Administrador o Contador
ingresa a la página web a
través de un navegador, con
el siguiente link:
http://www.premiumfacturac
ionelectronica.com/app/#/
2. El sistema muestra el login con dos campos para completar, el
usuario y contraseña y el botón para ingresar al sistema:
“Acceder”.
3. El Superadministrador,
Administrador o Contador
ingresa su usuario y
contraseña para acceder al
sistema y da clic en
“Acceder”.
4. El sistema valida la información ingresada en la base de datos
y si es correcta y el usuario es Administrador, muestra la
pantalla de inicio, la cual contiene en la parte izquierda un
menú desplegable con los siguientes módulos:
“Administrativo” con opciones: “Conceptos de Pagos”,
“Gestión de Apoderados”, “Matricular Estudiantes”, “Registrar
Pagos” y “Reportes de Ventas”; “Facturación Electrónica”
con opción “Anulación de Comprobantes”; y la opción
“Cerrar Sesión” que dirigirá al Login del Sistema.
Si el usuario es Contador el menú sólo estará habilitado el
módulo de “Facturación Electrónica” con las opciones
“Anulación de Comprobantes”, “Contingencia”, “Libros
Electrónicos”, “Notas Electrónicas” y “Resumen Diario”.
Si el usuario es Superadministrador estarán habilitadas los
módulos: “Académico” con las opciones “Colegio” y “Sedes”,
“Pagos” con la opción “Conceptos”, “Recursos Humanos”
con las opciones “Apoderados” y “Estudiantes”, “Seguridad”
“Menú” y “Roles” y “Usuarios” con las opciones
“Administrar” y “Registrar”.
POST-CONDICIÓN El usuario ingresa al Sistema de manera satisfactoria.

31
 Tabla III.5.
Especificación de caso de uso - Inicio de Sesión (continuación)

En el punto 4. Si no coincide la información en la base de datos.

El sistema muestra mensaje: “Credenciales incorrectas”
CASO ALTERNO
Si el usuario no está registrado
Proceder al caso de uso “Gestión de Usuario”

 Registrar Apoderado
Tabla III.6.
Especificación de caso de uso - Registrar Apoderado

CASO DE USO Registrar Apoderado

ACTORES Administrador
Este caso de uso empieza cuando el Administrador desean
DESCRIPCIÓN
registrar un nuevo apoderado.
PRE-CONDICIÓN El Administrador Inicia sesión en el sistema.
CURSO NORMAL DE EVENTOS
ACCIÒN DE LOS ACTORES RESPUESTA DEL SISTEMA
1. El Administrador hace clic en el
módulo “Administrativo”
2. El sistema muestra un menú desplegable con las opciones
“Conceptos de Pagos”, “Gestión de Apoderados”,
“Matricular Estudiantes”, “Registrar Pagos” y “Reportes
de Ventas”.
3. El Administrador da clic en
“Gestión de Apoderados”
4. El sistema muestra en la pantalla “Gestión de Apoderados
y Estudiantes” con el listado de todos los apoderados y
estudiantes registrados.
5. El administrador da clic en botón
“Configuración” que está en el
listado de apoderados
6. El sistema muestra las opciones de “Agregar apoderado”,
“Importar apoderados” y “Actualizar lista”.
7. El administrador da clic en la
opción “Agregar apoderado”.
8. El sistema muestra la modal “Agregar apoderado” con los
campos requeridos (Nombres, Apellido, DNI) y opcionales
(celular, e-mail) para agregar un nuevo apoderado.
9. El Administrador ingresa los datos
solicitados y da clic en el botón
verde “Guardar”.
10. Si se realizó correctamente el registro de apoderado el
sistema muestra el mensaje: “Genial! Apoderado Creado
Correctamente”.
POST-CONDICIÓN El nuevo apoderado ha sido registrado en el sistema.
En el punto 10.
 Si hay datos requeridos incompletos.
El sistema muestra mensaje “Completar campo requerido”
CASO ALTERNO
 Si los datos ingresados ya están registrados en el sistema.
El sistema muestra mensaje “El valor del campo DNI ya está en
uso”

 Registrar Estudiante

32
Tabla III.7.
Especificación de caso de uso - Registrar Estudiante

CASO DE USO Registrar Estudiante

ACTORES Administrador
Este caso de uso empieza cuando el Administrador desean
DESCRIPCIÓN
registrar un nuevo estudiante.
PRE-CONDICIÓN El Administrador registra apoderado en el sistema.
CURSO NORMAL DE EVENTOS
ACCIÒN DE LOS ACTORES RESPUESTA DEL SISTEMA
1. El Administrador hace clic
en el módulo
“Administrativo”
2. El sistema muestra un menú desplegable con las
opciones “Conceptos de Pagos”, “Gestión de
Apoderados”, “Matricular Estudiantes”, “Registrar
Pagos” y “Reportes de Ventas”.
3. El Administrador da clic en
“Gestión de Apoderados”
4. El sistema muestra en la pantalla “Gestión de
Apoderados y Estudiantes” con el listado de todos los
apoderados y estudiantes registrados.
5. El administrador selecciona
un apoderado.
Y da clic en botón
“Configuración” que está en
el listado de estudiantes
6. El sistema muestra las opciones de “Agregar
estudiante”, “Importar estudiantes” y “Actualizar
lista”.
7. El administrador da clic en
la opción “Agregar
estudiante”.
8. El sistema muestra la modal “Agregar estudiante” con
los campos requeridos (Nombres, Apellidos, Sede)
para agregar un nuevo estudiante.
9. El Administrador ingresa
los datos solicitados y da
clic en el botón verde
“Guardar”.
10. Si se realizó correctamente el registro del estudiante,
el sistema muestra el mensaje: “Genial! Estudiante
Creado Correctamente”.
POST-CONDICIÓN El nuevo estudiante ha sido registrado en el sistema.
En el punto 6.
 Si el apoderado no tiene estudiantes registrados.
El sistema mostrará lista vacía “No hay estudiantes
CASO ALTERNO registrados”
En el punto 10.
 Si hay datos requeridos incompletos.
El sistema muestra mensaje “Completar campo requerido”

33
  Matricular Estudiante
Tabla III.8.
Especificación de caso de uso - Matricular Estudiante

CASO DE USO Matricular Estudiante

ACTORES Administrador
Este caso de uso empieza cuando el Administrador desean
DESCRIPCIÓN
matricular a un estudiante.
PRE-CONDICIÓN El Administrador registra estudiante en el sistema.
CURSO NORMAL DE EVENTOS
ACCIÒN DE LOS ACTORES RESPUESTA DEL SISTEMA
1. El Administrador hace clic en
el módulo “Administrativo”
2. El sistema muestra un menú desplegable con las opciones
“Conceptos de Pagos”, “Gestión de Apoderados”,
“Matricular Estudiantes”, “Registrar Pagos” y “Reportes
de Ventas”.
3. El Administrador da clic en
“Matricular Estudiantes”
4. El sistema muestra en la pantalla “Registro de Matriculas
por Sede”, las sedes, y los niveles académicos (inicial,
prima y secundaria).
5. El Administrador selecciona
un nivel académico (inicial,
prima o secundaria).
6. El sistema muestra listado de los alumnos matriculados en
el nivel seleccionado.
7. El administrador da clic en
botón “Matricular
Estudiante”.
8. El sistema muestra la modal “Matricular un estudiante” con
un listado de estudiantes no matriculados, opción de
búsqueda de estudiante y cronograma de matrícula.
9. El Administrador selecciona el
estudiante a matricular,
habilita los conceptos de pago
para asignar en el cronograma
de matrícula y da clic en el
botón “Registrar Matrícula”.
10. Si se realizó correctamente la matricula del estudiante, el
sistema muestra el mensaje: “Genial! Matrícula registrada
correctamente.”
POST-CONDICIÓN El estudiante ha sido matriculado en el sistema.
 Si no se ha registrado ningún alumno.
El sistema muestra mensaje “Error. La sede seleccionada no
tiene estudiantes registrados”.
En el punto 6.
 Si el sistema no tiene estudiantes matriculados.
El sistema mostrará lista vacía “Aún no hay estudiantes
CASO ALTERNO matriculados, para la sede y el nivel seleccionado”
En el punto 9.
 El Administrador puede realizar búsqueda del alumno por su
nombre.
 Si el Administrador no selecciona un estudiante a matricular.
El sistema muestra mensaje “Error. Por favor seleccione un
estudiante antes de continuar”

34
  Emisión de Boletas
Tabla III.9.
Especificación de caso de uso - Emisión de Boletas

CASO DE USO Emisión de boletas

ACTORES Administrador
Este caso de uso empieza cuando el Administrador desean emitir
DESCRIPCIÓN
una boleta de pago
PRE-CONDICIÓN El Administrador matricula estudiante.
CURSO NORMAL DE EVENTOS
ACCIÒN DE LOS ACTORES RESPUESTA DEL SISTEMA
1. El Administrador hace clic
en el módulo
“Administrativo”
2. El sistema muestra un menú desplegable con las opciones
“Conceptos de Pagos”, “Gestión de Apoderados”, “Matricular
Estudiantes”, “Registrar Pagos” y “Reportes de Ventas”.
3. El Administrador da clic en
“Registrar Pagos”
4. El sistema muestra en la pantalla “Historial de Pagos”, opción
de búsqueda por DNI de apoderado y Año.
5. El Administrador ingresa
número de DNI de
apoderado, año y da clic en el
botón “Buscar”.
6. El sistema muestra los datos del apoderado (Apellidos y
nombres, DNI, Celular/Teléfono, Email) y listado de los
alumnos del apoderado.
7. El administrador selecciona
un estudiante
8. El sistema muestra en la pantalla una tabla de “Historial de
pagos de: (alumno seleccionado)”, con el monto de Deuda total,
además, se muestran las columnas de Concepto, F. Cobro, F.
Vencimiento, Costo (S/.), Abonado (S/.), Deuda (S/.), Pagos.
9. El Administrador se ubica en
la fila del concepto a pagar,
en la columna de “Pagos” y
da clic en el botón amarillo
“Pagar”.
10. El sistema muestra la modal “Concepto: Matricula” con la
opción de ingresar un monto para cancelar.
11. El Administrador ingresa
monto para cancelar
12. Si se realizó correctamente el pago, el sistema muestra
comprobante de pago y se actualizan los datos en el historial de
pagos.
13. El Administrador imprime
comprobante de pago.
POST-CONDICIÓN Comprobante de pago emitido correctamente.

35
Tabla III.10.
Especificación de caso de uso - Emisión de Boletas (continuación)
En el punto 6.
 Si el alumno está matriculado,
Se muestra el dato en verde “Matriculado”
 Si el alumno no está matriculado
Se muestra el dato en rojo “No matriculado”
En el punto 7. Si el estudiante no está matriculado.
 El administrador selecciona un estudiante
El sistema muestra mensaje “Advertencia. (nombre de estudiante) no se
encuentra matriculado”. Y no se puede realizar un pago.
En el 10. Si el concepto seleccionado tiene una deuda menor a la deuda total.
CASO ALTERNO  El sistema muestra la modal “Concepto: Matricula” con la opción de ingresar
un monto para cancelar y una tabla con los datos de los pagos anteriores.
Continua en el punto 11.
En el punto 11.
El Administrador puede ingresa monto total o menor al total a pagar.
En el punto 11.
 Si el Administrador ingresa un monto mayor al total a pagar.
El sistema muestra mensaje en letras rojas “El monto máximo a abonar es…”
En el punto 13.
El administrador también puede descargar el comprobante de pago en formato
PDF.

 Consultar Historial de Pagos

Tabla III.11.
Especificación de caso de uso - Consulta Historial de Pagos

CASO DE USO Consultar Historial de Pagos

ACTORES Administrador
Este caso de uso empieza cuando el Administrador desean consultar el
DESCRIPCIÓN
historial de pagos de un estudiante.
PRE-CONDICIÓN El Administrador matricula estudiante.
CURSO NORMAL DE EVENTOS
ACCIÒN DE LOS ACTORES RESPUESTA DEL SISTEMA
1. El Administrador hace clic
en el módulo
“Administrativo”
2. El sistema muestra un menú desplegable con las opciones
“Conceptos de Pagos”, “Gestión de Apoderados”, “Matricular
Estudiantes”, “Registrar Pagos” y “Reportes de Ventas”.
3. El Administrador da clic en
“Registrar Pagos”
4. El sistema muestra en la pantalla “Historial de Pagos”, opción de
búsqueda por DNI de apoderado y Año.
5. El Administrador ingresa
número de DNI de
apoderado, año y da clic en el
botón “Buscar”.
6. El sistema muestra los datos del apoderado (Apellidos y nombres,
DNI, Celular/Teléfono, Email) y listado de los alumnos del
apoderado.
6. El administrador selecciona
un estudiante

36
 Tabla III.12.
Especificación de caso de uso - Consulta Historial de Pagos (continuación)

7. El sistema muestra en la pantalla una tabla de “Historial de pagos de: (alumno

seleccionado)”, con el monto de Deuda total, además, se muestran las
columnas de Concepto, F. Cobro, F. Vencimiento, Costo (S/.), Abonado (S/.),
Deuda (S/.), Pagos.
8. El Administrador da clic en
el botón “Configuración”
9. EL sistema muestra las opciones “Exportar a Excel” y “Imprimir PDF”
10. El administrador selecciona
la opción “Exportar a Excel”
11. El sistema descarga automáticamente el archivo en formato Excel del
Historial de pagos del estudiante seleccionado.
POST-CONDICIÓN Reporte de Historial de Pagos
En el punto 6.
 Si el alumno está matriculado,
Se muestra el dato en verde “Matriculado”
 Si el alumno no está matriculado
Se muestra el dato en rojo “No matriculado”
En el punto 7. Si el estudiante no está matriculado.
 El administrador selecciona un estudiante
CASO ALTERNO El sistema muestra mensaje “Advertencia. (nombre de estudiante) no se encuentra
matriculado”. Y no se puede consultar historial de pagos.
En el punto 11
El administrador selecciona la opción “Imprimir PDF”
En el punto 12.
El sistema muestra una ventana de impresión con el archivo en formato PDF del
Historial de pagos del estudiante, seleccionado.

 Enviar Resúmenes Diarios

Tabla III.13.
Especificación de caso de uso - Enviar Resúmenes Diarios

CASO DE USO Enviar Resúmenes Diarios

ACTORES Contador
DESCRIPCIÓN Este caso de uso empieza cuando el Contador desea Enviar Resumen Diario.
PRE-CONDICIÓN El Contador Inicia sesión en el sistema.
CURSO NORMAL DE EVENTOS
ACCIÒN DE LOS ACTORES RESPUESTA DEL SISTEMA
1. El Administrador hace clic en el
módulo “Facturación
Electrónica”
2. El sistema muestra un menú desplegable con las opciones “Anulación de
comprobantes”, “Contingencia”, “Libros electrónicos”, “Notas
Electrónicas”, “Resumen Diario”.
3. El Contador da clic en “Resumen
Diario”
4. El sistema muestra en la pantalla “Resumen de Boletas Diarias de la Sede
Principal” con una tabla con los campos: Fecha Resumen, Generación,
Grupodass, Correlativo Actual, Total, Docs. Emitidos Docs.
Anulados, Estado. Y los resúmenes generados con anterioridad.

37
 Tabla III.14.
Especificación de caso de uso - Enviar Resúmenes Diarios (continuación)
5. El Contador da clic en el botón
“Filtrar”
6. El sistema muestra una pequeña ventana con los campos: Sede, Años y
Mes.
7. El Contador selecciona sede, año,
mes y da clic en el botón
“Consultar”
8. El sistema muestra en la tabla, con los datos de los resúmenes diarios
según el mes seleccionado.
9. El Contador da clic en el botón
“Generar Resumen”
10. El sistema muestra una ventana “Generar Resumen Diario” con un campo
fecha.
11. El Contador selecciona la fecha
del resumen a generar y da clic en
botón verde “Generar”.
12. Si se realizó correctamente, el sistema muestra mensaje “Éxito. Se generó
correctamente”.
El resumen generado aparecerá en la tabla de la pantalla “Resumen de
Boletas Diarias de la Sede Principal”.
13. Para enviar el resumen, el contador
da clic en el botón “Visualizar” en
la misma fila del resumen a enviar.
14. El sistema muestra ventana con tabla y en ella los datos (correlativo,
nombre, nro. boletas, anulados, fecha y hora de envío, ticket, estado,
respuesta SUNAT) del resumen seleccionado
Y los botones “Enviar resumen” y “Volver a generar grupos”.
15. El contador da clic en el botón
“Enviar resumen”
16. El sistema muestra una ventana con el mensaje: “El envío del resumen
diario es irreversible ¿Seguro que desea enviarlo?
17. EL contador da clic en el botón
verde “Continuar”
18. El sistema muestra el mensaje “¡Genial! Resumen diario enviado
correctamente”
POST-CONDICIÓN Resumen Diario generado
En el punto 7. Si el mes seleccionado no se ha generado resúmenes diarios.
En el punto 8.
El sistema muestra la tabla vacía con el mensaje: “Aún no ha generado
resúmenes diarios para el mes seleccionado”
En el punto 11. Si en fecha seleccionada ya se generó anteriormente un
resumen diario.
En el punto 12
El sistema muestra mensaje “Advertencia. Ya existe un resumen con la fecha
(fecha seleccionada)”.
CASO ALTERNO En el punto 11. Si la fecha seleccionada no tiene boletas emitidas.
En el punto 12
El sistema muestra mensaje “Advertencia. No se puede generar un resumen
diario para el (fecha seleccionada), porque no tiene boletas registradas para
este día.
En el punto 18 después de enviar el resumen diario, el contador da clic en botón
“Visualizar” en la misma fila del resumen enviado. El sistema muestra ventana
con tabla y en ella los datos (correlativo, nombre, nro. boletas, anulados, fecha
y hora de envío, ticket, estado, respuesta SUNAT) del resumen seleccionado
Y los botones “Consultar” y “Reenviar

38
  Generación de Grupo de Emergencia

Tabla III.15.
Especificación de caso de uso - Generación de Grupo de Emergencia

CASO DE USO Generación de Grupo de Emergencia

ACTORES Contador
Este caso de uso empieza cuando el Contador desea Generar
DESCRIPCIÓN
Grupo de Emergencia.
PRE-CONDICIÓN Resumen diario enviado
CURSO NORMAL DE EVENTOS
ACCIÒN DE LOS ACTORES RESPUESTA DEL SISTEMA
1. El Administrador hace
clic en el módulo
“Facturación
Electrónica”
2. El sistema muestra un menú desplegable con las opciones
“Anulación de comprobantes”, “Contingencia”, “Libros
electrónicos”, “Notas Electrónicas”, “Resumen Diario”.
3. El Contador da clic en
“Resumen Diario”
4. El sistema muestra en la pantalla “Resumen de Boletas
Diarias de la Sede Principal” con una tabla con los campos:
Fecha Resumen, Generación, Grupodass, Correlativo
Actual, Total, Docs. Emitidos Docs. Anulados, Estado.
Y los resúmenes generados con anterioridad.
5. El contador da clic en el
botón “Visualizar” en la
misma fila del resumen a
generar grupo de emergencia.
6. El sistema muestra ventana con tabla y en ella los datos
(correlativo, nombre, nro. boletas, anulados, fecha y hora de
envío, ticket, estado, respuesta SUNAT) del resumen
seleccionado.
Y el botón “Generar grupos de emergencia”
7. El contador da clic en el
botón rojo “Generar grupos
de emergencia”
8. El sistema muestra el mensaje: Los grupos de emergencia
son generados cuando se realizan ventas luego de enviarse el
resumen diario ¿Está seguro que desea generar grupos de
emergencia?”
9. EL contador da clic en el
botón verde “Continuar”
10. El sistema muestra el mensaje: “¡Genial! Todas las boletas
electrónicas en la fecha (fecha seleccionada) se encuentran
enviadas”.
POST-CONDICIÓN Grupo de emergencia generado
En el punto 6
CASO ALTERNO El sistema mostrará botón “Generar grupos de emergencia” sólo
si el resumen fue enviado anteriormente.

39
  Anulación de Comprobantes

Tabla III.16.
Especificación de caso de uso - Anulación de Comprobantes

CASO DE USO Anulación de comprobantes

ACTORES Contador o Administrador
Este caso de uso empieza cuando el Contador o
DESCRIPCIÓN
Administrador desea Anular comprobante.
PRE-CONDICIÓN Comprobante emitido
CURSO NORMAL DE EVENTOS
ACCIÒN DE LOS ACTORES RESPUESTA DEL SISTEMA
1. El Administrador hace clic en el módulo
“Facturación Electrónica”
2. El sistema muestra un menú desplegable con las
opciones “Anulación de comprobantes”,
“Contingencia”, “Libros electrónicos”, “Notas
Electrónicas”, “Resumen Diario”.
3. El Contador da clic en “Anulación de
comprobantes”
4. El sistema muestra en la pantalla “Anulación de
Comprobantes de la Sede Principal” con un botón
“Filtrar”
5. El contador da clic en el botón “Filtrar”
6. El sistema muestra ventana de opciones Sede, Año,
Mes y un botón “Consultar”
7. El contador selecciona el campo Sede.
8. El sistema despliega listado de las Sedes registradas.
9. El contador selecciona una sede de la lista.
El contador selecciona el campo Año.
10. El sistema despliega listado de los últimos años.
11. El contador selecciona un año.
El contador selecciona campo Mes.
12. El sistema despliega listado de los meses
13. EL contador selecciona un mes y da clic en el
botón “Consultar”
14. El sistema muestra tabla con los comprobantes
emitidos y las columnas Fecha y Hora, Serie,
Correlativo, Cliente, Total, Seleccionar (casillas
para marcar). Y el botón rojo “Anular (n)
documentos”
15. El contador se ubica en la columna
Seleccionar, fila del comprobante a anular y
marcará la casilla.
Da clic en el botón “Anular (n)
documentos”
16. Muestra ventana “Seleccionar motivo de anulación”
con los campos Motivo y Descripción. Y el botón
“Anular Comprobante”.
17. El contador selecciona el campo Motivo.
18. El sistema despliega listado de posibles Motivos
19. El contador selecciona un motivo de la lista.
El contador en el campo Descripción, escribe
descripción del motivo y da clic en el botón
“Anular Comprobantes”

40
Tabla III.17.
Especificación de caso de uso - Anulación de Comprobantes (continuación)
20. El sistema muestra mensaje “El proceso de
anulación es irreversible ¿Seguro que desea anular
(n) documentos”, y dos opciones “Continuar” y
“Cancelar”
21. EL contador da clic en el botón “Aceptar”
22. El sistema muestra el mensaje: “Los documentos se
enviaron para ser anulados por SUNAT”.
POST-CONDICIÓN Comprobante anulado
En el punto 14 Si no hay comprobantes emitidos en el
tiempo seleccionado
El sistema muestra en la pantalla el mensaje “No se han
encontrado Comprobantes aceptados”.
Y contador debe seleccionar otras opciones de fecha.
En los puntos 9, 11, 13 Si el contador no ha seleccionado
o ha seleccionado algún campo incorrecto
CASO ALTERNO En el punto 14
El sistema muestra mensaje de advertencia “Seleccione
campo de la lista”.
En el punto 19
La Descripción del motivo de anulación, es opcional
En el punto 21
Si el contador selecciona el botón cancelar el sistema
regresa a la pantalla punto 16.

 Generación de notas Electrónicas

Tabla III.18.
Especificación de caso de uso - Generación de notas Electrónicas

CASO DE USO Generación de notas Electrónicas

ACTORES Contador
Este caso de uso empieza cuando el Contado desea
DESCRIPCIÓN
Generación de notas Electrónicas
PRE-CONDICIÓN Comprobante emitido
CURSO NORMAL DE EVENTOS
ACCIÒN DE LOS ACTORES RESPUESTA DEL SISTEMA
1. El Administrador hace clic en el módulo
“Facturación Electrónica”
2. El sistema muestra un menú desplegable con las
opciones “Anulación de comprobantes”,
“Contingencia”, “Libros electrónicos”, “Notas
Electrónicas”, “Resumen Diario”.
3. El Contador da clic en “Notas Electrónicas”
4. El sistema muestra en la pantalla “Nota de Venta”
con los campos Documentos contables, Numeración
y un botón de búsqueda.
Además, el Tipo y Motivo de venta, con los campos
Nota electrónica, Motivo de Nota. También muestra
la Descripción del motivo, con el campo
Descripción. Cliente y el Importe Total a devolver
(S/):

41
 Tabla III.19.
Especificación de caso de uso - Generación de notas Electrónicas (continuación)
5. El contador selecciona el tipo de Documento
contable e ingresa la numeración del documento y da
clic en el botón “Buscar”
6. El sistema completa el nombre del Cliente y la
cantidad del Importe Total a devolver (S/)
7. El contador selecciona el campo Nota electrónica.
8. El sistema despliega lista de tipos de nota (Nota de
crédito o Nota de débito).
9. El contador selecciona un tipo de nota de la lista.
Selecciona el campo Motivo de Nota
10. El sistema despliega listado de enunciados de
Motivos.
Listado de motivos para Nota de crédito: Anulación
de la operación, Anulación por error en el RUC,
Corrección por error en la descripción, Descuento
global, Descuento por ítem, Devolución total,
Bonificación, Disminución en el valor, Devolución
por ítem.
Listado de motivos para Nota de débito: Intereses
por mora, Aumento en el valor, Penalidades.
11. El contador selecciona del listado un Motivo de
Nota. El contador en el campo Descripción escribe
descripción del motivo y da clic en el botón “Pagar”
12. Muestra ventana “Registrar Pago” con los datos del
Total a Pagar, el campo Importe de Recibo y los
botones “Registrar Venta” y “Aún no”
13. EL contador ingresa Importe Recibido y da clic en el
botón “Registrar Venta”
14. El sistema muestra el mensaje: “Nota de Venta
realizada”
POST-CONDICIÓN Nota de venta realizada
En el punto 5 Si el contador ingresa la numeración del
documento incorrecta.
En el punto 6 El sistema muestra mensaje:
“¡Advertencia! No se ha encontrado la venta”
En el punto 11
La Descripción del motivo de anulación, es opcional
En el punto 11 El botón “Registrar Venta” se activa
cuando la cantidad de importe recibido es igual o mayor
al Total a Pagar.
En el punto 13
Si el contador selecciona el botón “Aún no” el sistema
regresa a la pantalla punto 6.
CASO ALTERNO
Si del listado de Motivos de Nota de crédito, el contador
selecciona las opciones: Corrección por error en la
descripción, Descuento global, Descuento por ítem,
Bonificación, Disminución en el valor, Devolución por
ítem. Y todos los Motivos de Nota de débito.
El sistema muestra campo Concepto Subtotal.
El contador ingresa nuevo monto. Y da clic en el botón
“Pagar”. Continúa punto 12.
En el punto 11 Si el contador no selecciona un campo y
da clic en el botón “Pagar”.
El sistema muestra mensaje: “¡Advertencia! Debe
escribir un motivo”

42
  Contingencia de Comprobantes
Tabla III.20.
Especificación de caso de uso - Contingencia de Comprobantes

CASO DE USO Contingencia de Comprobantes

ACTORES Contador
Este caso de uso empieza cuando el Contador desea realizar
DESCRIPCIÓN
Contingencia de Comprobantes.
PRE-CONDICIÓN Comprobante emitido
CURSO NORMAL DE EVENTOS
ACCIÒN DE LOS ACTORES RESPUESTA DEL SISTEMA
1. El Administrador hace clic en el
módulo “Facturación Electrónica”
2. El sistema muestra un menú desplegable con las opciones
“Anulación de comprobantes”, “Contingencia”, “Libros
electrónicos”, “Notas Electrónicas”, “Resumen Diario”.
3. El Contador da clic en
“Contingencia”
4. El sistema muestra en la pantalla “Contingencia de
Comprobantes” con los campos Fecha de Emisión,
Documento contable, Serie, Correlativo, Apoderado,
Alumno, Concepto
5. El contador completa todos los
campos y da clic en el icono “Venta”
6. El sistema completa tabla con las columnas: concepto,
Subtotal, Total, según el Concepto seleccionado. Y el botón
“Pagar”
7. EL contador da clic en el botón
“Pagar”
8. Muestra ventana “Registrar Pago” con los datos del Total a
Pagar, el campo Importe de Recibo y los botones “Registrar
Venta” y “Aún no”
9. EL contador ingresa Importe Recibido
y da clic en el botón “Registrar
Venta”
10. Si se realizó correctamente el pago, el sistema muestra
comprobante de pago.
POST-CONDICIÓN Comprobante registrado
En el punto 5 El contador puede seleccionar más de un concepto.
CASO ALTERNO
En el punto 6 El sistema agrega nuevo concepto en la tabla.

 Gestionar Usuarios
Tabla III.21.
Especificación de caso de uso - Gestionar Usuarios

CASO DE USO Gestionar Usuarios

ACTORES Super Administrador
Este caso de uso empieza cuando el Super administrador desea
DESCRIPCIÓN
realizar Registrar Usuario
PRE-CONDICIÓN Iniciar sesión
CURSO NORMAL DE EVENTOS
ACCIÒN DE LOS ACTORES RESPUESTA DEL SISTEMA
1. El Super Administrador hace clic en el
módulo “Usuarios”

43
 Tabla III.22.
Especificación de caso de uso - Gestionar Usuarios

2. El sistema muestra un menú desplegable con las opciones

“Administrar”, “Registrar”
3. El Super Administrador da clic
en “Registrar”
4. El sistema muestra en la pantalla “Registrar Usuario” con los
campos Nick, Contraseña, Repita Contraseña, Rol de usuario. Y
los botones “Registrar usuario” y “Cancelar”.
5. El Super Administrador ingresa
los datos solicitados y da clic en
el botón “Registrar usuario”.
6. Si se realizó correctamente el registro del Usuario, el sistema
muestra el mensaje: “¡Éxito! Usuario registrado Correctamente”.
POST-CONDICIÓN Usuario registrado
En el punto 6.
CASO ALTERNO  Si hay datos requeridos incompletos.
El sistema muestra mensaje “Completar campo requerido”

 Gestionar Sedes
Tabla III.23.
Especificación de caso de uso - Gestionar Sedes

CASO DE USO Gestionar Sedes

ACTORES Super Administrador
Este caso de uso empieza cuando el Super administrador desea realizar
DESCRIPCIÓN
Registrar Usuario
PRE-CONDICIÓN Iniciar sesión
CURSO NORMAL DE EVENTOS
ACCIÒN DE LOS ACTORES RESPUESTA DEL SISTEMA
1. El Super Administrador hace clic
en el módulo “Académico”
2. El sistema muestra un menú desplegable con las opciones
“Colegio”, “Sedes”
3. El Super Administrador da clic
en “Sedes”
4. El sistema muestra en la pantalla “Mantenimiento de Sede” con
una tabla de todas las sedes y las columnas: Nombre, Colegio,
Operaciones Modificar y Eliminar. Y los botones +Agregar Sede
y Registros Inhabilitados.
5. El Super Administrador ingresa
da clic en el botón “+Agregar
Sede”.
6. El sistema muestra ventana “Registrar Sede” con los campos:
Nombre, Colegio. Y los botones “Registrar Sede y “Cancelar”
7. El Super Administrador ingresa
los datos solicitados y da clic en
el botón “Registrar Sede”.
8. Si se realizó correctamente el registro del Usuario, el sistema
muestra el mensaje: “¡Éxito! Sede Creado Correctamente”.
POST-CONDICIÓN Sede registrada
En el punto 8.
CASO ALTERNO  Si hay datos requeridos incompletos.
El sistema muestra mensaje “Completar campo requerido”

44
 b) Diagramas de Secuencia
 Inicio de sesión

Figura III.5. Diagrama de Secuencia - Inicio de sesión

 Registrar Apoderado

Figura III.6. Diagrama de Secuencia - Registrar Apoderado

45
 Registrar Estudiante

Figura III.7. Diagrama de Secuencia - Registrar Estudiante

 Matricular Estudiante

Figura III.8. Diagrama de Secuencia - Matricular Estudiante

46
 Emisión de Boletas

Figura III.9 Diagrama de Secuencia - Emisión de Boletas

 Consulta Historial de Pagos

Figura III.10. Diagrama de Secuencia - Consulta Historial de Pagos

47
 Enviar Resúmenes Diarios

Figura III.11. Diagrama de Secuencia - Enviar Resúmenes Diarios

 Generación de Grupo de Emergencia

Figura III.12. Diagrama de Secuencia - Generación de Grupo de Emergencia

48
 Anulación de Comprobantes

Figura III.13. Diagrama de Secuencia - Anulación de Comprobantes

 Generación de notas Electrónicas

Figura III.14. Diagrama de Secuencia - Generación de notas Electrónicas

49
 Contingencia de Comprobantes

Figura III.15. Diagrama de Secuencia - Contingencia de Comprobantes

 Gestionar Usuarios

Figura III.16. Diagrama de Secuencia - Gestionar Usuarios

50
 Gestionar Sedes

Figura III.17. Diagrama de Secuencia - Gestionar Sedes

c) Diagramas de Colaboración
 Inicio de Sesión

Figura III.18. Diagrama de Colaboración - Inicio de Sesión

51
 Registrar Apoderado

Figura III.19. Diagrama de Colaboración - Registrar Apoderado

 Registrar Estudiante

Figura III.20. Diagrama de Colaboración - Registrar Estudiante

52
 Matricular Estudiante

Figura III.21. Diagrama de Colaboración - Matricular Estudiante

 Emisión de Boletas

Figura III.22. Diagrama de Colaboración - Emisión de Boletas

53
 Consulta Historial de Pagos

Figura III.23. Diagrama de Colaboración - Consulta Historial de Pagos

 Enviar Resúmenes Diarios

Figura III.24. Diagrama de Colaboración - Enviar Resúmenes Diarios

54
 Generación de Grupo de Emergencia

Figura III.25. Diagrama de Colaboración - Generación de Grupo de Emergencia

55
 Anulación de Comprobantes

Figura III.26. Diagrama de Colaboración - Anulación de Comprobantes

 Generación de notas Electrónicas

Figura III.27. Generación de notas Electrónicas

56
 Contingencia de Comprobantes

Figura III.28. Diagrama de Colaboración - Contingencia de Comprobantes

 Gestionar Usuarios

Figura III.29. Diagrama de Colaboración - Gestionar Usuarios

57
 Gestionar Sedes

Figura III.30. Diagrama de Colaboración - Gestionar Sedes

58
 d) Diagramas de Actividades
 Iniciar sesión

Figura III.31. Diagrama de Actividades – Inicio sesión

 Registrar Apoderado

Figura III.32. Diagrama de Actividades - Registrar Apoderado

59
 Registrar Estudiante

Figura III.33. Diagrama de Actividades - Registrar Estudiante

 Matricular Estudiante

Figura III.34. Diagrama de Actividades - Matricular Estudiante

60
 Emisión de Boletas

Figura III.35. Diagrama de Actividades - Emisión de Boletas

61
 Consulta Historial de Pagos

Figura III.36. Diagrama de Actividades - Consulta Historial de Pagos

 Enviar Resúmenes Diarios

Figura III.37. Diagrama de Actividades - Enviar Resúmenes Diarios

62
 Generación de Grupo de Emergencia

Figura III.38. Diagrama de Actividades - Generación de Grupo de Emergencia

 Anulación de Comprobantes

Figura III.39. Diagrama de Actividades - Anulación de Comprobantes

63
 Generación de notas Electrónicas

Figura III.40. Diagrama de Actividades - Generación de notas Electrónicas

 Contingencia de Comprobantes

Figura III.41.Diagrama de Actividades - Contingencia de Comprobantes

64
 Gestionar Usuarios

Figura III.42. Diagrama de Actividades - Gestionar Usuarios

 Gestionar Sedes

Figura III.43. Diagrama de Actividades - Gestionar Sedes

65
e) Diagrama de Clases

Figura III.44. Diagrama de clases

66
 f) Diagrama de Componentes

Figura III.45. Diagrama de componentes – Usuarios

Figura III.46. Diagrama de componentes – Menú Administrativo

67
Figura III.47. Diagrama de colaboración – Menú Principal

Figura III.48. Diagrama de colaboración – Facturación electrónica

68
g) Mockups y prototipos de pantallas
A continuación, se presentan los mockups principales del sistema de registro
civil:

Figura III.49. Mockup – Inicio de Sesión

Figura III.50. Mockup – Pantalla principal

69
Figura III.51. Mockup – Gestión de Apoderados y Estudiantes

Figura III.52.Mockup – Registrar Apoderado

70
Figura III.53. Mockup – Registrar Estudiante

Figura III.54. Mockup – Matricular Estudiante

71
 Figura III.55. Mockup – Emisión de Boletas

Figura III.56. Mockup – Consulta Historial de Pagos

72
 Figura III.57. Mockup – Resúmenes Diarios

Figura III.58. Mockup – Enviar Resúmenes Diarios

Figura III.59. Mockup – Generación de Grupo de Emergencia

73
Figura III.60. Mockup – Anulación de Comprobantes

Figura III.61. Mockup – Ventana Anulación de Comprobantes

74
Figura III.62. Mockup – Generación de notas Electrónicas

Figura III.63. Mockup – Contingencia de Comprobantes

75
Figura III.64. Mockup – Gestionar Usuarios

Figura III.65. Mockup – Gestionar Sedes

76
 h) Diagrama de base de datos

Figura 3.III.66. Diagrama de base de datos

77
3.7.1.3. Fase de construcción
En esta fase se diseña el diagrama de despliegue mostrando la arquitectura del sistema
de registro civil.

a) Diagrama de despliegue

Figura III.67. Diagrama de despliegue

b) Capturas de pantalla

Figura III.68. Pantalla - Inicio de Sesión

78
 Figura III.69. Pantalla - Principal

Figura III.70. Pantalla – Gestión de Apoderados y Estudiantes

79
 Figura III.71. Pantalla - Registrar Apoderado

Figura III.72. Pantalla - Registrar Estudiante

Figura III.73. Pantalla - Matricular Estudiante

80
 Figura III.74. Pantalla - Emisión de Boletas

Figura III.75. Pantalla - Consulta Historial de Pagos

Figura III.76. Pantalla - Resúmenes Diarios

81
Figura III.77. Pantalla – Enviar Resúmenes Diarios

Figura III.78. Pantalla - Generación de Grupo de Emergencia

Figura III.79. Pantalla - Anulación de Comprobantes

Figura III.80. Pantalla - Ventana Anulación de Comprobantes

82
Figura III.81. Pantalla - Generación de notas Electrónicas

Figura III.82. Pantalla - Contingencia de Comprobantes

83
Figura III.83. Pantalla - Gestionar Usuarios

Figura III.84. Pantalla - Gestionar Sedes

84
 3.7.1.4. Fase de transición
En esta fase se realizan las pruebas de caja negra del sistema Web para comprobar el
funcionamiento de los distintos módulos que contiene el mismo.

a) Pruebas de Caja Negra

Tabla III.24.
Prueba de Unidad de caja negra sin valores – Registrar Apoderado

3 PRUEBA DE UNIDAD DE CAJA NEGRA SIN VALORES

Caso de
Registro de Apoderado
Prueba
Objetivos Comprobar que realiza el registro de apoderado de manera correcta
Resultado
No permitir el registro de información por errores de parámetros y de duplicidad de códigos.
Esperado
Condiciones de entrada
Valores(tipos)
N°
Entrada Tipo Equivalencia válida Equivalencia no válida
1 Nombres Parámetro Tipo carácter con una longitud menor igual a 50 Tipo Numérico
2 Apellidos Parámetro Tipo carácter con una longitud menor igual a 50 Tipo Numérico
Tipo carácter con una longitud igual a 8 o igual a Tipo carácter con una
3 DNI Parámetro
11 longitud menor igual a 7
Tipo carácter con una
4 Celular Parámetro Tipo carácter con una longitud menor igual a 9
longitud menor igual a 8

Tipo carácter que tenga

5 Email Parámetro Tipo carácter con una longitud menor igual a 50
@dominio.com

Condiciones de ejecución
N° Paso Condiciones
1 No existe concordancia con los tipos de datos del registro de apoderado.
2 Existe concordancia con los tipos de datos del registro de apoderado.

Tabla III.25.
Prueba de Unidad de caja negra con valores – Registrar Apoderado

PRUEBA DE UNIDAD DE CAJA NEGRA CON VALORES

RESULTADO
N° PARÁMETROS VALORES SALIDA ESPERADA SALIDA REAL
OBTENIDO
No registrar los datos y
Mensaje de error por ingreso
1 Nombres AX652 desplegar un mensaje de ÉXITO
de dato incorrecto
error
No registrar los datos y
Mensaje de error por ingreso
2 Apellidos "65JS" desplegar un mensaje de ÉXITO
de dato incorrecto
error
No registrar los datos y
Mensaje de error por ingreso
3 DNI “JSJH8281623572” desplegar un mensaje de ÉXITO
de dato incorrecto
error
Registro exitoso del dato al Almacenamiento de dato
4 Celular 99542099 ÉXITO
sistema satisfactorio para el sistema.
Registro exitoso del dato al Almacenamiento de dato
5 Email [email protected] ÉXITO
sistema satisfactorio para el sistema.

85
Tabla III.26.
Prueba de Unidad de caja negra sin valores – Registrar Estudiante
4 PRUEBA DE UNIDAD DE CAJA NEGRA SIN VALORES
Caso de
Registro de Estudiante
Prueba
Objetivos Comprobar que realiza el registro de estudiante de manera correcta
Resultado
No permitir el registro de información por errores de parámetros y de duplicidad de códigos.
Esperado
Condiciones de entrada
Valores(tipos)
N°
Entrada Tipo Equivalencia válida Equivalencia no válida
1 Nombres Parámetro Tipo carácter con una longitud menor igual a 50 Tipo Numérico

2 Apellidos Parámetro Tipo carácter con una longitud menor igual a 50 Tipo Numérico
Condiciones de ejecución
N° Paso Condiciones
1 No existe concordancia con los tipos de datos del registro de estudiante.
2 Existe concordancia con los tipos de datos del registro de estudiante.

Tabla III.27.
Prueba de Unidad de caja negra con valores – Registrar Estudiante

PRUEBA DE UNIDAD DE CAJA NEGRA CON VALORES

RESULTADO
N° PARÁMETROS VALORES SALIDA ESPERADA SALIDA REAL
OBTENIDO
No registrar los datos y
Mensaje de error por ingreso
1 Nombres AX652 desplegar un mensaje de ÉXITO
de dato incorrecto
error
No registrar los datos y
Mensaje de error por ingreso
2 Apellidos "65JS" desplegar un mensaje de ÉXITO
de dato incorrecto
error
No registrar los datos y
Mensaje de error por ingreso
3 DNI “JSJH8281623572” desplegar un mensaje de ÉXITO
de dato incorrecto
error
Registro exitoso del dato al Almacenamiento de dato
4 Celular 99542099 ÉXITO
sistema satisfactorio para el sistema.
Registro exitoso del dato al Almacenamiento de dato
5 Email [email protected] ÉXITO
sistema satisfactorio para el sistema.

ASPECTOS ÉTICOS
En el desarrollo de esta investigación, se mantuvo un manejo riguroso y ético de los datos
suministrados por los departamentos respectivos. El investigador asumió un compromiso
inquebrantable con la confidencialidad, asegurando que los datos recabados se utilizaron
exclusivamente para propósitos de investigación y no se sometieron a ninguna alteración o uso
indebido. Se establecieron protocolos estrictos para evitar la divulgación no autorizada de la
información, y se sostuvo una comunicación transparente con la institución educativa, garantizando
que cualquier uso de los datos fuera del ámbito de la investigación contara con la aprobación previa
y explícita de la misma. Este proceder demostró el respeto por la privacidad y completitud de los
datos organizacionales, y subrayó la responsabilidad ética con la que se condujo el investigador en
todas las fases del estudio.

86
 IV. RESULTADOS Y DISCUSIÓN
RESULTADOS
4.1.1. Indicador: Nivel de satisfacción del usuario
La encuesta para evaluar el nivel de satisfacción (NS) de los usuarios después de la
implementación del sistema Web, fue aplicada a 2 trabajadores (área de administración y
contabilidad) de la I.E.P. PREMIUM – Piura. A continuación, se muestran los datos tabulados:
Tabla IV.1.
Nivel de satisfacción de los usuarios del sistema

Muy en En No estoy Muy de

Preguntas De acuerdo
desacuerdo desacuerdo seguro acuerdo
El sistema se encuentra disponible para
2
realizar mis labores cotidianas.
La información que me brinda el sistema es
2
confiable.
Las consultas y reportes que me brinda el
sistema son exactas y no se presentan 2
inconsistencias.
La información que se gestiona en el sistema
es de suma importancia para mi trabajo
2
diario; sin el apoyo de este sistema no podría
realizar mis labores.
Muchas veces el cumplimiento de mis
responsabilidades se ven afectadas porque el
2
sistema no me proporciona información
confiable y oportuna.
La funcionalidad ofrecida por el sistema
apoya de manera completas los procesos
1 1
propios de las oficinas de administración y
contabilidad.
El sistema contiene funciones que abarcan las
necesidades particulares de las oficinas de
1 1
administración y contabilidad que deben
llevar a cabo.
La navegación en el sistema es fácil. 2
La búsqueda de información y selección de
2
un elemento en el sistema es sencilla.
La apariencia del sistema es estética y
1 1
agradable, facilitando el trabajo cotidiano

La manera como se comunica el sistema

conmigo en la medida que trabajo con el 2
(mensajes, advertencias, etc.) es entendible.

El sistema presenta errores continuamente

2
mientras se opera con él.
Cuando se solicita información al sistema,
este despliega dicha información en el tiempo 2
esperado.
En general se encuentra satisfecho con el
1 1
sistema.
Total 0 4 0 10 14

87
 (𝐴 ∗ 0) + (𝐵 ∗ 25) + (𝐶 ∗ 50) + (𝐷 ∗ 75) + (𝐸 ∗ 100)
𝑁𝑆 =
𝑁
Donde:
𝑨 = 𝐸𝑠 𝑒𝑙 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎𝑠 𝑝𝑎𝑟𝑎 𝑀𝑢𝑦 𝑒𝑛 𝑑𝑒𝑠𝑎𝑐𝑢𝑒𝑟𝑑𝑜
𝑩 = 𝐸𝑠 𝑒𝑙 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎𝑠 𝑝𝑎𝑟𝑎 𝐸𝑛 𝑑𝑒𝑠𝑎𝑐𝑢𝑒𝑟𝑑𝑜
𝑪 = 𝐸𝑠 𝑒𝑙 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎𝑠 𝑝𝑎𝑟𝑎 𝑁𝑜 𝑒𝑠𝑡𝑜𝑦 𝑠𝑒𝑔𝑢𝑟𝑜
𝑫 = 𝐸𝑠 𝑒𝑙 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎𝑠 𝑝𝑎𝑟𝑎 𝐷𝑒 𝑎𝑐𝑢𝑒𝑟𝑑𝑜
𝑬 = 𝐸𝑠 𝑒𝑙 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎𝑠 𝑝𝑎𝑟𝑎 𝑀𝑢𝑦 𝑑𝑒 𝑎𝑐𝑢𝑒𝑟𝑑𝑜
𝑵 = 𝐸𝑠 𝑙𝑎 𝑠𝑢𝑚𝑎 𝑑𝑒 𝑡𝑜𝑑𝑎𝑠 𝑙𝑎𝑠 𝑎𝑛𝑡𝑒𝑟𝑖𝑜𝑟𝑒𝑠 (𝐴 + 𝐵 + 𝐶 + 𝐷 + 𝐸)
Reemplazando valores:
(0 ∗ 0) + (4 ∗ 25) + (0 ∗ 50) + (10 ∗ 75) + (14 ∗ 100)
𝑁𝑆 =
28
𝑵𝑺 = 𝟖𝟎. 𝟑𝟔
4.1.2. Indicador: Usabilidad
La encuesta para evaluar la Usabilidad del sistema, se aplicó a 2 trabajadores (área de
administración y contabilidad) de la I.E.P. PREMIUM – Piura. A continuación, se muestran los
datos tabulados:
Tabla IV.2.
Usabilidad del sistema

Muy Muy
Preguntas Difícil Regular Fácil
difícil fácil
¿Qué tan fácil considera el proceso de gestión de conceptos de pagos, en el
2
sistema Web?
¿Qué tan fácil considera el proceso de gestión de apoderados, en el sistema
1 1
Web?
¿Qué tan fácil considera el proceso de gestión de estudiantes, en el sistema
1 1
Web?
¿Qué tan fácil considera el proceso de matrícula de estudiantes, en el sistema
1 1
Web?
¿Qué tan fácil considera el proceso de registro de pagos, en el sistema Web? 2
¿Qué tan fácil considera el proceso de consulta de historial de pagos de
1 1
estudiantes, en el sistema Web?
¿Qué tan fácil considera el proceso de elaboración de reporte de pagos, en el
1 1
sistema Web?
¿Qué tan fácil considera el proceso de anulación de documentos electrónicos,
1 1
en el sistema Web?
¿Qué tan fácil considera el proceso de contingencia de documentos
1 1
electrónicos, en el sistema Web?
¿Qué tan fácil considera el proceso de emisión de libros contables, en el
1 1
sistema Web?
¿Qué tan fácil considera el proceso de emisión de notas electrónicas, en el
2
sistema Web?
¿Qué tan fácil considera el proceso de generación de resúmenes diarios, en el
2
sistema Web?
Total 0 0 2 10 12

88
 (𝐴 ∗ 0) + (𝐵 ∗ 25) + (𝐶 ∗ 50) + (𝐷 ∗ 75) + (𝐸 ∗ 100)
𝑈𝑠𝑎𝑏 =
𝑁
Donde:
𝑨 = 𝐸𝑠 𝑒𝑙 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎𝑠 𝑝𝑎𝑟𝑎 𝑀𝑢𝑦 𝑑𝑖𝑓í𝑐𝑖𝑙
𝑩 = 𝐸𝑠 𝑒𝑙 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎𝑠 𝑝𝑎𝑟𝑎 𝐷𝑖𝑓í𝑐𝑖𝑙
𝑪 = 𝐸𝑠 𝑒𝑙 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎𝑠 𝑝𝑎𝑟𝑎 𝑅𝑒𝑔𝑢𝑙𝑎𝑟
𝑫 = 𝐸𝑠 𝑒𝑙 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎𝑠 𝑝𝑎𝑟𝑎 𝐹á𝑐𝑖𝑙
𝑬 = 𝐸𝑠 𝑒𝑙 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎𝑠 𝑝𝑎𝑟𝑎 𝑀𝑢𝑦 𝑓á𝑐𝑖𝑙
𝑵 = 𝐸𝑠 𝑙𝑎 𝑠𝑢𝑚𝑎 𝑑𝑒 𝑡𝑜𝑑𝑎𝑠 𝑙𝑎𝑠 𝑎𝑛𝑡𝑒𝑟𝑖𝑜𝑟𝑒𝑠 (𝐴 + 𝐵 + 𝐶 + 𝐷 + 𝐸)

Reemplazando valores:
(0 ∗ 0) + (0 ∗ 25) + (2 ∗ 50) + (10 ∗ 75) + (12 ∗ 100)
𝑈𝑠𝑎𝑏 =
24
𝑼𝒔𝒂𝒃 = 𝟖𝟓. 𝟒𝟐

4.1.3. Indicador: Confiabilidad

La encuesta para evaluar la Confiabilidad del sistema, se aplicó a 2 trabajadores (área de
administración y contabilidad) de la I.E.P. PREMIUM – Piura. A continuación, se muestran los
datos tabulados:
Tabla IV.3.
Confiabilidad del sistema

Muy Muy
Preguntas Deficiente Regular Bueno
deficiente Bueno
¿Considera confiable la validación de datos al ingresar al sistema
2
Web?
Al realizar una búsqueda ¿Considera confiables los resultados
2
obtenidos del sistema Web?
Al realizar una consulta de historial de pagos ¿Considera confiables
2
los resultados obtenidos del sistema Web?
Al realizar un reporte ¿Considera confiables los resultados
1 1
obtenidos del sistema Web?
Al realizar emitir un documento contable ¿Considera confiables los
2
resultados obtenidos del sistema Web?
Al anular un comprobante de pago ¿Considera confiables los
1 1
resultados obtenidos del sistema Web?
Al emitir documentos electrónicos respaldados por un certificado
digital ¿Considera confiables los resultados obtenidos del sistema 2
Web?
Total 0 0 1 6 7

(𝐴 ∗ 0) + (𝐵 ∗ 25) + (𝐶 ∗ 50) + (𝐷 ∗ 75) + (𝐸 ∗ 100)

𝐶𝑜𝑛𝑓𝑖𝑎𝑏 =
𝑁

89
 Donde:
𝑨 = 𝐸𝑠 𝑒𝑙 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎𝑠 𝑝𝑎𝑟𝑎 𝑀𝑢𝑦 𝑑𝑖𝑓í𝑐𝑖𝑙
𝑩 = 𝐸𝑠 𝑒𝑙 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎𝑠 𝑝𝑎𝑟𝑎 𝐷𝑖𝑓í𝑐𝑖𝑙
𝑪 = 𝐸𝑠 𝑒𝑙 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎𝑠 𝑝𝑎𝑟𝑎 𝑅𝑒𝑔𝑢𝑙𝑎𝑟
𝑫 = 𝐸𝑠 𝑒𝑙 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎𝑠 𝑝𝑎𝑟𝑎 𝐹á𝑐𝑖𝑙
𝑬 = 𝐸𝑠 𝑒𝑙 𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎𝑠 𝑝𝑎𝑟𝑎 𝑀𝑢𝑦 𝑓á𝑐𝑖𝑙

𝑵 = 𝐸𝑠 𝑙𝑎 𝑠𝑢𝑚𝑎 𝑑𝑒 𝑡𝑜𝑑𝑎𝑠 𝑙𝑎𝑠 𝑎𝑛𝑡𝑒𝑟𝑖𝑜𝑟𝑒𝑠 (𝐴 + 𝐵 + 𝐶 + 𝐷 + 𝐸)

Reemplazando valores:
(0 ∗ 0) + (0 ∗ 25) + (1 ∗ 50) + (6 ∗ 75) + (7 ∗ 100)
𝐶𝑜𝑛𝑓𝑖𝑎𝑏 =
14
𝑪𝒐𝒏𝒇𝒊𝒂𝒃 = 𝟖𝟓. 𝟕𝟏

4.1.4. Indicador: Seguridad

La guía de observación para de medir el nivel de seguridad fue utilizada por el equipo de
desarrollo del sistema web para mejorar el control de pagos con facturación electrónica en la
I.E.P. PREMIUM. A continuación, se presenta la información obtenida.
Tabla IV.4.
Seguridad del sistema

Control
Marque
Vulnerabilidad Solución Observación
con una
(X)
 Uso del ORM Eloquent La mayoría de
 Uso de Reglas de validación (Form Request o el Helper las soluciones
Validator) fueron
 Evitar en lo mínimo el uso de Raw Queries aplicadas en la
SQL Injection X aplicación
 Uso de Query parametrizadas para el lado
 Desactivar el Reporte de Errores en producción, para evitar del servidor
mostrar información sensible en caso haya un inconvenientes
con una consulta SQL.
 Validar el ingreso de datos en los inputs users Se aplicaron
algunas
 Usar XSS Middleware en el archivo de rutas del servidor
soluciones
XSS (Cross Site  Usar DOMSanitizer para prevenir automáticamente XSS
en angular X
Scripting)
 No permitir el acceso de elementos del DOM directamente
 Uso de mecanismos de interpolación en angular para
mostrar información 

90
4.1.5. Indicador: Tiempo promedio de consulta de historial de pagos
4.1.5.1. Definición de variables
TPCHPA: Tiempo promedio de consulta de historial de pagos, antes de la
implementación del sistema Web.
TPCHPD: Tiempo promedio de consulta de historial de pagos, después de la
implementación del sistema Web.

4.1.5.2. Hipótesis estadísticas

Hipótesis Nula (H - 0): El tiempo promedio de consulta de historial de pagos antes de
la implementación del sistema Web, es menor que el tiempo promedio de consulta de
historial de pagos después de la implementación del sistema Web.
Hipótesis Alternativa (H - 1): El tiempo promedio de consulta de historial de pagos
después de la implementación del sistema Web, es menor que el tiempo promedio de
consulta de historial de pagos antes de la implementación del sistema Web.

4.1.5.3. Nivel de significancia

El nivel de significancia (α) seleccionada para la prueba de hipótesis es del 5% (α =
0.05 = 5%). Por lo tanto, el nivel de confianza (1- α = 0.95) será de 95%.

4.1.5.4. Prueba de normalidad

Para la elección de una prueba estadística se debe corroborar en primera instancia si la
muestra posee una distribución normal. Para se usó la prueba de Shapiro-Wilk dado
que la muestra es menor de 30.
• P – Valor > α = H0: Los datos provienen de una distribución normal.
• P – Valor < α = H1: Los datos no provienen de una distribución normal
Tabla IV.5.
Prueba de normalidad - Indicador Tiempo promedio de consulta de historial de
pagos

Shapiro - Wilk
Indicador
Estadístico Gl Sig. (P-Valor)
TPCHPA 0.910512818 0.06518597
38
TPCHPD 0.907833613 0.05796494

Tabla IV.6.
Evaluación de normalidad - Indicador Tiempo promedio de consulta de historial de
pagos

Evaluación de Normalidad
P-valor (TPCHPA) = 0.06518597 P-valor > α Se acepta H0
P-valor ( TPCHPD ) = 0.05796494 P-valor > α Se acepta H0

91
 En la evaluación de normalidad en ambas variables dado el que valor es mayor a alfa,
se acepta H0, es decir que los datos provienen de una distribución normal.

4.1.5.5. Prueba T-Student

Al tener como muestra proveniente de una distribución normal y poseer un valor
pequeño (20) se optó por la prueba T-Student para comprobar su valor significativo.
Tabla IV.7.
Prueba de T-Student - Indicador Tiempo promedio de consulta de historial de pagos

TEST MEDIA T gl Sig. (bilateral)

ANTES 2.00
43.32 38 5,8954E-30
DESPUÉS 0.24

Se puede observar que el P-valor = 0.000, siendo menor a α (P-valor < α) se rechaza la
hipótesis nula (H0), a partir de estos resultados se puede afirmar que existe una mejora
significativa en cuanto al Tiempo promedio de consulta de historial de pagos después
de la implementación del sistema.

4.1.5.6. Impacto del indicador

Tabla IV.8.
Impacto del Indicador - Indicador Tiempo promedio de consulta de historial de pagos

IMPACTO ANTES DESPUÉS MEJORA

min 0:02:00 0:00:15 0:01:46
% 100 12.18 87.82

4.1.6. Indicador: Tiempo promedio de reporte de ingresos mensuales.

4.1.6.1. Definición de variables
TPRIMA: Tiempo promedio de reporte de ingresos mensuales, antes de la
implementación del sistema Web.
TPRIMD: Tiempo promedio de reporte de ingresos mensuales, después de la
implementación del sistema Web.

4.1.6.2. Hipótesis estadísticas

Hipótesis Nula (H - 0): Tiempo promedio de reporte de ingresos mensuales antes de
la implementación del sistema Web, es menor que el tiempo promedio de reporte de
ingresos mensuales después de la implementación del sistema Web.
Hipótesis Alternativa (H - 1): Tiempo promedio de reporte de ingresos mensuales
después de la implementación del sistema Web, es menor que el tiempo promedio de
reporte de ingresos mensuales antes de la implementación del sistema Web.

92
4.1.6.3. Nivel de significancia
El nivel de significancia (α) seleccionada para la prueba de hipótesis es del 5% (α =
0.05 = 5%). Por lo tanto, el nivel de confianza (1- α = 0.95) será de 95%.

4.1.6.4. Prueba de normalidad

Para la elección de una prueba estadística se debe corroborar en primera instancia si la
muestra posee una distribución normal. Para se usó la prueba de Shapiro-Wilk dado
que la muestra es menor de 30.
• P – Valor > α = H0: Los datos provienen de una distribución normal.
• P – Valor < α = H1: Los datos no provienen de una distribución normal
Tabla IV.9.
Prueba de normalidad - Tiempo promedio de reporte de ingresos mensuales

Shapiro – Wilk
Indicador
Estadístico Gl Sig. (P-Valor)
TPRIMA 0.91239036 0.070793998
38
TPRIMD 0.90538173 0.052081099

Tabla IV.10.
Evaluación de normalidad – Tiempo promedio de reporte de ingresos mensuales

Evaluación de Normalidad
P-valor (TPRIMA) = 0.070793998 P-valor > α Se acepta H0
P-valor ( TPRIMD ) = 0.052081099 P-valor > α Se acepta H0

En la evaluación de normalidad en ambas variables dado el que valor es mayor a alfa,

se acepta H0, es decir que los datos provienen de una distribución normal.

4.1.6.5. Prueba T-Student

Al tener como muestra proveniente de una distribución normal y poseer un valor
pequeño (20) se optó por la prueba T-Student para comprobar su valor significativo.
Tabla IV.11.
Prueba de T-Student - Tiempo promedio de reporte de ingresos mensuales

TEST MEDIA T gl Sig. (bilateral)

ANTES 10.12
275.34 38 2,5469E-59
DESPUÉS 0.14

Se puede observar que el P-valor = 0.000, siendo menor a α (P-valor < α) se rechaza la
hipótesis nula (H0), a partir de estos resultados se puede afirmar que existe una mejora
significativa en cuanto al Tiempo promedio de reporte de ingresos mensuales después
de la implementación del sistema.

93
 4.1.6.6. Impacto del indicador
Tabla IV.12.
Impacto del Indicador - Tiempo promedio de reporte de ingresos mensuales

IMPACTO ANTES DESPUÉS MEJORA

min 0:10:07 0:00:09 0:09:58
% 100 1.43 98.57

4.1.7. Indicador: Tiempo promedio para la emisión de comprobantes

electrónicos.
4.1.7.1. Definición de variables
TPECEA: Tiempo promedio para la emisión de comprobantes electrónicos, antes de
la implementación del sistema Web.
TPECED: Tiempo promedio para la emisión de comprobantes electrónicos, después
de la implementación del sistema Web.

4.1.7.2. Hipótesis estadísticas

Hipótesis Nula (H - 0): El tiempo promedio para la emisión de comprobantes
electrónicos antes de la implementación del sistema Web, es menor que el tiempo
promedio para la emisión de comprobantes electrónicos después de la implementación
del sistema Web.
Hipótesis Alternativa (H - 1): El tiempo promedio para la emisión de comprobantes
electrónicos después de la implementación del sistema Web, es menor que el tiempo
promedio para la emisión de comprobantes electrónicos antes de la implementación del
sistema Web.
4.1.7.3. Nivel de significancia
El nivel de significancia (α) seleccionada para la prueba de hipótesis es del 5% (α =
0.05 = 5%). Por lo tanto, el nivel de confianza (1- α = 0.95) será de 95%.

4.1.7.4. Prueba de normalidad

Para la elección de una prueba estadística se debe corroborar en primera instancia si la
muestra posee una distribución normal. Para se usó la prueba de Shapiro-Wilk dado
que la muestra es menor de 30.
• P – Valor > α = H0: Los datos provienen de una distribución normal.
• P – Valor < α = H1: Los datos no provienen de una distribución normal
Tabla IV.13.
Prueba de normalidad - Tiempo promedio para la emisión de comprobantes
electrónicos

Shapiro - Wilk
Indicador
Estadístico Gl Sig. (P-Valor)
TPECEA 0.905566141 0.052501316
38
TPECED 0.927749075 0.13974687

94
Tabla IV.14.
Evaluación de normalidad – Tiempo promedio para la emisión de comprobantes
electrónicos

Evaluación de Normalidad
P-valor (TPECEA) = 0.052501316 P-valor > α Se acepta H0
P-valor ( TPECED ) = 0.13974687 P-valor > α Se acepta H0

En la evaluación de normalidad en ambas variables dado el que valor es mayor a alfa,

se acepta H0, es decir que los datos provienen de una distribución normal.

4.1.7.5. Prueba T-Student

Al tener como muestra proveniente de una distribución normal y poseer un valor
pequeño (20) se optó por la prueba T-Student para comprobar su valor significativo.
Tabla IV.15.
Prueba de T-Student - Tiempo promedio para la emisión de comprobantes
electrónicos

TEST MEDIA T gl Sig. (bilateral)

ANTES 1.16
25.368 38 1,2836E-20
DESPUÉS 0.26

Se puede observar que el P-valor = 0.000, siendo menor a α (P-valor < α) se rechaza la
hipótesis nula (H0), a partir de estos resultados se puede afirmar que existe una mejora
significativa en cuanto al Tiempo promedio para la emisión de comprobantes
electrónicos después de la implementación del sistema Web.

4.1.7.6. Impacto del indicador

Tabla IV.16.
Impacto del Indicador – Tiempo promedio para la emisión de comprobantes
electrónicos

IMPACTO ANTES DESPUÉS MEJORA

min 0:01:07 0:00:16 0:00:54
% 100 22.30 77.70

95
DISCUSIÓN
4.2.1. Presentación de resultados
4.2.1.1. Nivel de satisfacción del usuario
El valor obtenido del NS (Nivel de Satisfacción) se evalúa de acuerdo a los rangos
establecidos en la Tabla IV.17.
Valores de posicionamiento. Según el cálculo realizado el NS tiene un valor de 80.36
que se ubica entre el rango [72 a 84] lo que significa que el nivel de satisfacción de los
usuarios que utilizan el sistema Web para el control de pagos con facturación
electrónica es Bueno.
Tabla IV.17.
Valores de posicionamiento

PUNTUACIÓN TIPO DE
FINAL SERVICIO
85 a 100 Muy Bueno
72 a 84 Bueno
65 a 71 Regular
55 a 64 Malo
< 54 Muy Malo

4.2.1.2. Usabilidad
El valor obtenido de la Usabilidad se evalúa de acuerdo con los rangos establecidos en
la Tabla IV.17.
Valores de posicionamiento. Según el cálculo realizado la Usabilidad tiene un valor de
85.42 que se ubica entre el rango [85 a 100] lo que significa que el nivel de usabilidad
del sistema según los usuarios que utilizan sistema Web para para el control de pagos
con facturación electrónica es Muy Bueno.
4.2.1.3. Confiabilidad
El valor obtenido de la Confiabilidad se evalúa de acuerdo a los rangos establecidos en
la Tabla IV.17.
Valores de posicionamiento. Según el cálculo realizado la Confiabilidad tiene un valor
de 85.71 que se ubica entre el rango [85 a 100] lo que significa que el nivel de usabilidad
del sistema según los usuarios que utilizan sistema Web para para el control de pagos
con facturación electrónica es Muy Bueno.

4.2.1.4. Seguridad
Al desarrollar y hacer el uso del sistema se encontraron 2 potenciales vulnerabilidades,
las cuales fueron solucionadas y controladas.
Una de ellas fue SQL Injection se aplicaron la mayoría de las soluciones en el sistema
Web para el lado del servidor: uso del ORM Eloquent, de Reglas de validación (Form
Request o el Helper Validator), de Query parametrizadas, evitando en lo mínimo el uso
de Raw Queries y desactivando el Reporte de Errores en producción, para evitar mostrar
información sensible en caso haya un inconveniente con una consulta SQL. Otra
vulnerabilidad fue XSS (Cross Site Scripting) se aplicaron algunas soluciones:
validación de ingreso de datos en los inputs users, usando XSS Middleware en el
archivo de rutas del servidor, también uso DOMSanitizer para prevenir

96
automáticamente XSS en angular, uso de mecanismos de interpolación en angular para
mostrar información y no permitiendo el acceso de elementos del DOM directamente

4.2.1.5. Tiempo promedio de consulta de historial de pagos

En el Gráfico IV.1. Impacto del Indicador - Tiempo promedio de consulta de historial
de pagos se muestra el resultado de Tiempo promedio de consulta de historial de pagos
expresado en minutos en un tiempo antes y después de la implementación del sistema,
donde para consulta de historial de pagos sin el sistema, se empleó promedio de 02:00
minutos y después de la implementación del sistema, 00:15 minutos. El tiempo
disminuyó 01:46 minutos, lo que equivale al 87.82% de mejora.
TIEMPO PROMEDIO DE CONSULTA DE
HISTORIAL DE PAGOS
00:02:18
00:02:00
00:02:01 00:01:46
00:01:44
00:01:26
00:01:09
00:00:52
00:00:35
00:00:15
00:00:17
00:00:00

ANTES DESPUES MEJORA

Gráfico IV.1. Impacto del Indicador - Tiempo promedio de consulta de historial de

pagos

4.2.1.6. Tiempo promedio de reporte de ingresos mensuales

En el Gráfico IV.2. Impacto del Indicador - Tiempo promedio de reporte de ingresos
mensuales, se muestra el resultado de Tiempo promedio de reporte de ingresos
mensuales expresado en minutos en un tiempo antes y después de la implementación
del sistema, donde para generar reporte de ingresos mensuales sin el sistema, se empleó
promedio de 10:07 minutos y después de la implementación del sistema, 00:09 minutos.
El tiempo disminuyó 09:58 minutos, lo que equivale al 98.57% de mejora.

97
 T I E M P O P R O M E D I O D E R E P O RT E D E
INGRESOS MENSUALES
ANTES DESPUES MEJORA

00:11:31 00:10:07 00:09:58

00:10:05
00:08:38
00:07:12
00:05:46
00:04:19
00:02:53
00:01:26 00:00:09
00:00:00

Gráfico IV.2. Impacto del Indicador - Tiempo promedio de reporte de ingresos

mensuales

4.2.1.7. Tiempo promedio para la emisión de comprobantes electrónicos.

En el Gráfico IV.3. Impacto del Indicador - Tiempo promedio para la emisión de
comprobantes electrónicos se muestra el resultado del Tiempo promedio para la
emisión de comprobantes electrónicos expresado en minutos en un tiempo antes y
después de la implementación del sistema, donde para emitir comprobante electrónico
sin el sistema, se empleó promedio de 01:07 minutos y después de la implementación
del sistema, 00:16 minutos. El tiempo disminuyó 00:54 minutos, lo que equivale al
77.70% de mejora.

TIEMPO PROMEDIO PARA LA EMISIÓN DE

COMPROBANTES ELECTRÓNICOS
ANTES DESPUES MEJORA

00:01:26
00:01:10
00:01:09
00:00:54
00:00:52

00:00:35
00:00:16
00:00:17

00:00:00

Gráfico IV.3. Impacto del Indicador - Tiempo promedio para la emisión de

comprobantes electrónicos

98
4.2.2. Discusión

La transición de la institución educativa PREMIUM hacia la Facturación Electrónica

(FE) ha marcado un hito en su modernización administrativa y fiscal, alineándose con la
digitalización tributaria que ha sido una tendencia predominante en América Latina desde
los años noventa. Este progreso no solo abarca el ámbito de la facturación, sino que
también se extiende a la supervisión de operaciones fiscales más amplias, como las
nóminas y la mercadería en tránsito. Tras la finalización del desarrollo se pudo apreciar
índice de satisfacción del usuario de 80.36, clasificado como 'Bueno'. Este dato apoya la
presunción de que el sistema sería un factor clave en la optimización del manejo de pagos
y procesos de facturación electrónica, alineándose con los propósitos centrales del estudio
y reafirmando la suposición particular vinculada al juicio favorable de los participantes.
La usabilidad obtenida ha sido evaluada con una puntuación sobresaliente de 85.42,
lo cual no solo cae dentro de la categoría de 'Muy Bueno', sino que también excede las
expectativas iniciales de la investigación. Esta alta calificación resalta el éxito del sistema
en proporcionar una experiencia de usuario optimizada, donde la navegación, la
interacción y la realización de tareas esenciales se ejecutan con notable facilidad y
eficiencia. Es precisamente esta facilidad de uso la que ha permitido que los procesos
administrativos y contables, que tradicionalmente podrían ser complejos y tediosos, se
conviertan en tareas manejables y eficientes.
La importancia de la usabilidad del sistema no puede subestimarse, ya que es un factor
determinante en la adopción y aceptación de la tecnología por parte del personal. Un
sistema con alta usabilidad no solo mejora la eficiencia operativa, sino que también
disminuye el tiempo de asimilación de conocimientos para los nuevos integrantes y reduce
la resistencia al cambio, facilitando así la transición a nuevos procesos digitales. Además,
una interfaz intuitiva y eficiente es esencial para minimizar los errores de entrada de datos,
a su vez, esto enriquece la fidelidad y el valor de los datos que se obtienen.
En el ámbito de la confiabilidad, el sistema ha demostrado ser excepcionalmente
robusto, con una calificación de 85.71, también considerada 'Muy Buena'. Esta alta
confiabilidad asegura que los usuarios pueden contar con la meticulosidad y la pertinencia
temporal de la información para tomar decisiones fundamentadas. En una institución
educativa, donde la precisión de la información es fundamental para la gestión eficaz, la
confiabilidad del sistema es indispensable. Los datos precisos y confiables son críticos
para mantener la integridad de las operaciones financieras, la conducción de recursos y la
programación de acciones futuras.
La seguridad del sistema ha sido fortalecida significativamente mediante la
identificación y corrección de vulnerabilidades críticas, tales como inyecciones SQL y
XSS. Estas mejoras en la seguridad son fundamentales, ya que protegen contra el acceso
no autorizado y garantizan la confidencialidad e integridad de los datos sensibles de los
alumnos y el personal. Una administración de seguridad diligente es vital para conservar
la confianza del conjunto de usuarios y mitigar el riesgo de perjuicios a la reputación o
consecuencias financieras adversas derivadas de vulnerabilidades de seguridad.
La mejora de los tiempos de procesos clave tras la culminación del desarrollo
propuesto inicialmente dentro del I.E.P. PREMIUM – Piura es un testimonio contundente
del progreso alcanzado en las dinámicas administrativas y de gestión tributaria. La
optimización temporal en la consulta del historial de pagos, que ahora se realiza 1:46
minutos más rápido, refleja un incremento del 87.82% en la celeridad del sistema. Esta
agilidad es aún más notable en la elaboración de informes de ingresos mensuales, donde
se ha logrado una disminución de 9:58 minutos, equivalentes a una mejora del 98.57%.
Tales cifras no solo evidencian una considerable aceleración en la realización de tareas

99
administrativas sino que también subrayan el valor añadido del papel de los sistemas en
documentación digital en la renovación de procedimientos administrativos en el contexto
regional.
Adicionalmente, la emisión de comprobantes electrónicos muestra una notable
eficiencia, con una reducción de 54 segundos por operación, lo que representa una mejora
sustancial del 77.70%. Este avance pone de relieve la habilidad del sistema para
incrementar la rapidez en operaciones esenciales, como la emisión de registros digitales, y
ratifica la realización de las metas establecidas respecto al mejoramiento de estos procesos.
La introducción del sistema web marca un avance significativo en la adaptación de
PREMIUM a las corrientes modernas de fiscalidad y subraya la importancia de la
Facturación Electrónica en la eficacia administrativa y la satisfacción de los usuarios. Estas
mejoras no solo destacan la capacidad del sistema de incrementar la rapidez y la exactitud
en las tareas diarias sino que también reflejan el impacto positivo de la implementación
tecnológica en la recaudación de impuestos y la evolución de las operaciones tributarias.
La institución, al adoptar estas innovaciones, no solo avanza en su desarrollo interno sino
que también contribuye a la transformación digital en curso en la región, marcando un hito
en la digitalización y modernización de la gestión tributaria en el Perú

100
 CONCLUSIONES

Después del desarrollo el sistema se concluye que:

1. Se diseñó una arquitectura de programa para un sistema Web y de sus interfaces de usuario
se obtuvo que tras la implementación, el valor obtenido del NS (Nivel de Satisfacción) fue
80.36 que se ubica entre el rango [72 a 84] lo que significa que el nivel de satisfacción de
los usuarios que utilizan el sistema Web para el control de pagos con facturación electrónica
es Bueno.

2. El valor obtenido de la Usabilidad fue 85.42 que se ubica entre el rango [85 a 100] lo que
significa que el nivel de usabilidad del sistema según los usuarios que utilizan sistema Web
para para el control de pagos con facturación electrónica es Muy Bueno.

3. El valor obtenido de la Confiabilidad fue 85.71 que se ubica entre el rango [85 a 100] lo
que significa que el nivel de usabilidad del sistema según los usuarios que utilizan sistema
Web para para el control de pagos con facturación electrónica es Muy Bueno.

4. Al evaluar el nivel de Seguridad se encontraron 2 potenciales vulnerabilidades (SQL

Injection, XSS (Cross Site Scripting), para controlar se aplicaron soluciones logrando
minimizarlas y optimizando la seguridad del sistema Web.

5. Se redujo el Tiempo promedio de consulta de historial de pagos un 87.82% (01:46

minutos), lo que significa que el sistema Web facilita dicha labor en el área administrativa
de la I.E.P. PREMIUM.

6. El tiempo promedio de reporte de ingresos mensuales se redujo 09:58 minutos (98.57%).

Esto es de relevancia debido a que es una tarea primordial para llevar el control de los pagos.

7. Asimismo, con la implementación se obtuvo una reducción del tiempo promedio para la
emisión de comprobantes electrónicos de 00:54 minutos (77.70%). Esto es de relevancia
ya que en una tarea diaria que se realiza varias veces al día.

101
 RECOMENDACIONES

 Para maximizar la comodidad y accesibilidad en el proceso de pagos, se sugiere la creación

de un aplicativo para dispositivos móviles exclusivo para que los padres de familia realizar
pagos de manera eficiente y segura en cualquier momento y desde cualquier lugar. La
implementación de esta solución tecnológica no solo facilitará las transacciones sino que
también promoverá una mayor puntualidad en los pagos, al integrarse de manera flexible a la
vida cotidiana de los usuarios.

 Se sugiere la integración de un sistema de notificaciones automáticas para alertar a los padres

de familia sobre las próximas fechas de pago. Este mecanismo proactivo puede implementarse
ofreciendo recordatorios oportunos que faciliten el cumplimiento de los plazos de pago. Esta
estrategia no solo mejorará la puntualidad en los pagos, sino que también contribuirá a una
comunicación más efectiva y directa entre la institución y las familias, reforzando la relación
y el compromiso de ambas partes.

 A fin de dotar al proceso de pago de mayor accesibilidad, es crucial ofrecer múltiples métodos
de pago. Esto incluye, pero no se limita a, tarjetas de crédito/debito, transferencias bancarias,
y plataformas de pago en línea. Al diversificar las opciones disponibles, se facilita la
adaptación de la tecnología a sus necesidades y preferencias, eliminando así barreras
potenciales al pago oportuno y eficiente.

 Asimismo, se recomienda encarecidamente el establecimiento herramientas de chat

instantáneo o correo electrónico. Esta práctica no solo optimiza la confirmación de
transacciones para los padres de familia, sino que también mejora la eficiencia operativa,
reduciendo la carga administrativa y asegurando un registro digital inmediato y seguro de
cada transacción realizada.

 Se aconseja además la creación de un Dashboard de inteligencia de negocios, diseñado para

ofrecer una visión holística y detallada de los datos operacionales y financieros de la
institución. Esta herramienta estratégica debería permitir un análisis profundo y la generación
de insights accionables, facilitando así la toma de decisiones informadas. Al visualizar
tendencias, identificar áreas de mejora y anticiparse a los cambios del mercado, el Dashboard
se convertirá en un recurso invaluable para el fortalecimiento y la agilidad organizacional.

102
 REFERENCIAS BIBLIOGRÁFICAS
ALEGSA. (2016). Obtenido de http://www.alegsa.com.ar/Dic/sistema_informatico.php
ARSYS. (2020). Obtenido de https://www.arsys.es/blog/programacion/diseno-web/web-services-
desarrollo/
Barreix, A., & Zambrano, R. (2018). FACTURA ELECTRÓNICA EN AMÉRICA LATINA.
Bustamante Aquino, Y. H., & Pacheco Vizcarra, F. D. (2018). INCIDENCIAS: VENTAJAS Y
DESVENTAJAS DE LA IMPLEMENTACIÓN DEL SISTEMA DE EMISIÓN
ELECTRÓNICA FRENTE AL SISTEMA DE EMISIÓN FISICA EN PRINICIPALES
CONTRIBUYENTES EN LA CIUDAD DE AREQUIPA. Arequipa, Perú.
CHAKRAY. (2020). Obtenido de https://www.chakray.com/es/que-diferencias-hay-entre-rest-y-soap/
Choez Choez, R. N. (2017). DESARROLLAR UN SISTEMA DE CONTROL DE MATRICULACIÓN
Y PAGO CON FACTURA ELECTRÓNICA DE LA ESCUELA 3 DE DICIEMBRE DE LA
CIUDAD GUAYAQUIL. Guayaquil, Ecuador.
Cobo, A., Gómez, P., Pérez, D., & Rocha, R. (2005). PHP Y MySQL Tecnologías para el desarrollo de
aplicaciones web. Ediciones Díaz de Santos.
Córdova Forero, J. A. (2014). IMPLEMENTACIÓN DE UN SISTEMA DE MATRÍCULAS Y PAGOS
PARA EL CENTRO DE INFORMÁTICA DE LA UNIVERSIDAD CÉSAR VALLEJO.
Lima, Perú.
De Velazco Borda, J. L. (2016). LA FACTURACIÓN ELECTRÓNICA EN EL PERÚ. LIDERA, 4-10.
EcuRed:Enciclopedia cubana. (04 de Abril de 2017). Obtenido de
https://www.ecured.cu/Metodologias_de_desarrollo_de_Software
Escudero Llamocca, A. R. (Mayo de 2019). IMPLEMENTACIÓN DEL SISTEMA DE
FACTURACIÓN ELECTRÓNICA EN LABORATORIOS BAGO DEL PERÚ. Lima, Perú.
Guevara Bernal, I. (2018). PROPUESTA PARA LA IMPLEMENTACIÓN DE SISTEMA DE
EMISIÓN ELECTRÓNICA DE COMPROBANTES DE PAGO, PARA LOS CLIENTES
DEL ESTUDIO CONTABLE JUAN ERNESTO ARIAS CASTILLA - JEAC, DISTRITO DE
LIMA, 2018. Lima, Perú.
Gutierrez, J. J. (s.f.). ¿ Qué es un framework Web? Obtenido de
www.lsi.us.es/~javierj/investigacion_ficheros/Framework.pdf
MAXCDN one. (2017). Obtenido de MAXCDN one: https://www.maxcdn.com/one/visual-
glossary/web-application/
Minetto, E. L. (2007). Framework para el desenvolvimiento en PHP. NOVATEC.
Navarro Flores, T. K. (2017). SISTEMA DE FACTURACIÓN ELECTRÓNICA PARA LA GESTIÓN
DE COMPROBANTES DE PAGO BASADO EN ISO/IEC19845:2015 EN ACGENESYS
S.A.C. Lima, Perú.
Ramirez Coronado, L. G. (2017). Análisis comparativo del tiempo de ejecución de una aplicación web
desarrollada en diferentes marcos de trabajo utilizados en el lado del servidor y en lado del
cliente. 135. Piura, Perú.
Rivera Salinas, J. C. (2018). SISTEMA WEB PARA EL PROCESO DE FACTURACIÓN
ELECTRÓNICA EN LA EMPRESA J&S CONSULTORES S.A.C. Lima, Perú.
Rodriguez Carbajal, A. D. (2019). SISTEMA ACADÉMICO WEB PARA LA MEJORA DE
PROCESOS DE MATRÍCULAS Y PAGOS DE LA INSTITUCIÓN EDUCATIVA VIRGEN
DE LA ASUNCIÓN DEL PORVENIR - TRUJILLO. Trujillo, Perú.

103
Rueda Chacón, J. R. (Abril de 2006). Aplicación de la Metodología RUP para el desarrollo rápido de
aplicaciones basado en el estandar J2EE. Guatemala.
Saavedra Arango, M. D. (2010). Programación Web Dinámica. PIURA: J.D.D &SERVICE.
SUNAT. (2020). Obtenido de http://www.sunat.gob.pe/institucional/quienessomos/index.html
Thibaud, C. (2006). Mysql 5 Instalación, Implementación, Administración, Programación. España:
Ediciones ENI.
Torres Remon, M. A. (2012). Programación Transact con SQL Server 2012. Lima: Macro E.I.R.L.
UBL ESPAÑA. (2020). Obtenido de http://www.ubl.org.es/que-es-ubl-2/
UDLAP. (2020). Obtenido de
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/marquez_a_bm/capitulo5.pdf
Vega Campos, J. J. (2018). Estudio comparativo de tiempo de ejecución de los frameworks de lado
cliente basados en los estándares ECMASCRIPT 5, 6 y 7, para el desarrollo de aplicaciones
web. 142. Piura, Perú.

104
 ANEXOS
ANEXO 1. Matriz básica de consistencia
Título del proyecto:
“DESARROLLO DE UN SISTEMA WEB PARA MEJORAR EL CONTROL DE PAGOS CON
FACTURACIÓN ELECTRÓNICA EN LA I.E.P. PREMIUM – PIURA”.
Nombre del Tesista:
Br. LUIS ANTONIO, BARCO GARCÍA

Tabla 5.0.1.
Matriz básica de consistencia

PREGUNTAS OBJETIVOS HIPÓTESIS

¿De qué manera el desarrollo Desarrollar un sistema web El sistema web contribuirá al
de un sistema Web contribuirá para mejorar el control de control de pagos y facturación
al control de pagos y pagos e integración con electrónica, reduciendo los
facturación electrónica en la facturación electrónica en la tiempos de consulta de historial
G Institución Educativa Privada Institución Educativa Privada de pagos, elaboración de
PREMIUM? PREMIUM. reportes de ingresos mensuales
y la emisión de facturas en la
Institución Educativa Privada
PREMIUM.
¿De qué manera el sistema Web Comparar los tiempos de Existe variación significativa
reducirá los tiempos de consulta de historial de pagos en el tiempo de consulta de
consulta de historial de pagos de los alumnos, antes y después historial de pagos de los
de los alumnos en la Institución de la implementación del alumnos en la Institución
E1
Educativa Privada PREMIUM? módulo respectivo en el Educativa Privada PREMIUM,
sistema Web mediante una antes y después de la
búsqueda por apoderado. implementación del sistema
Web.
¿De qué manera el sistema Web Comparar los tiempos de Existe variación significativa
reducirá los tiempos de elaboración de reportes de en el tiempo de elaboración de
elaboración de reportes de ingresos mensuales, antes y reportes de ingresos mensuales
E2 ingresos mensuales en la después de la implementación en la Institución Educativa
Institución Educativa Privada del módulo respectivo en el Privada PREMIUM, antes y
PREMIUM? sistema Web generando un después de la implementación
archivo en formato Excel. del sistema Web.
¿De qué manera el sistema Web Comparar los tiempos de Existe variación significativa
reducirá los tiempos de emisión emisión de facturación, antes y en el tiempo de emisión de
de facturación en la Institución después de la implementación facturación en la Institución
E3 Educativa Privada PREMIUM? del módulo respectivo en el Educativa Privada PREMIUM,
sistema Web emitiendo antes y después de la
documentos electrónicos. implementación del sistema
Web.

105
 ANEXO 2. Matriz general de consistencia
Título: “DESARROLLO DE UN SISTEMA WEB PARA MEJORAR EL CONTROL DE PAGOS CON FACTURACIÓN ELECTRÓNICA EN LA I.E.P. PREMIUM – PIURA”.
Nombre del Tesista: Br. LUIS ANTONIO BARCO GARCÍA
PROBLEMA OBJETIVOS HIPÓTESIS VARIABLES METODOLOGÍA
GENERAL GENERAL GENERAL VARIABLE INDEPENDIENTE ENFOQUE
¿De qué manera el desarrollo de un Desarrollar un sistema web para El sistema web contribuirá al · Tiempo promedio de consulta El enfoque de la investigación es
sistema Web contribuirá al control mejorar el control de pagos e control de pagos y facturación de historial de pagos. cuantitativo.
de pagos y facturación electrónica integración con facturación electrónica, reduciendo los Sistema Web DISEÑO
en la Institución Educativa Privada electrónica en la Institución tiempos de consulta de historial de DIMENSIONES: El diseño de la investigación es no
PREMIUM? Educativa Privada PREMIUM. pagos, elaboración de reportes de · Métrica de calidad experimental.
ingresos mensuales y la emisión de INDICADORES: NIVEL
facturas en la Institución Educativa · Nivel de satisfacción de los El nivel de investigación es
Privada PREMIUM. usuarios del sistema. descriptivo.
· Usabilidad TIPO
ESPECÍFICOS ESPECÍFICOS ESPECÍFICAS · Confiabilidad La investigación es de tipo
1. ¿De qué manera el sistema Web 1.Comparar los tiempos de 1. Existe variación significativa en · Seguridad aplicada.
reducirá los tiempos de consulta de consulta de historial de pagos de el tiempo de consulta de historial VARIABLES DEPENDIENTE TÉCNICAS E
historial de pagos de los alumnos los alumnos, antes y después de la de pagos de los alumnos en la Mejora de los procesos que INSTRUMENTOS
en la Institución Educativa Privada implementación del módulo Institución Educativa Privada realizan las áreas de · Observación
PREMIUM? respectivo en el sistema Web PREMIUM, antes y después de la administración y contabilidad. · Encuestas
mediante una búsqueda por implementación del sistema Web. DIMENSIONES: · Guías de observación
apoderado. · Tiempo · Microsoft Excel
2. ¿De qué manera el sistema Web 2.Comparar los tiempos de 2. Existe variación significativa en INDICADORES: POBLACIÓN Y MUESTRA
reducirá los tiempos de elaboración de reportes de ingresos el tiempo de elaboración de · Tiempo promedio de consulta · Documentos contables emitidos
elaboración de reportes de ingresos mensuales, antes y después de la reportes de ingresos mensuales en de historial de pagos. en el área de administración y
mensuales en la Institución implementación del módulo la Institución Educativa Privada · Tiempo promedio de reporte de contabilidad
Educativa Privada PREMIUM? respectivo en el sistema Web PREMIUM, antes y después de la ingresos mensuales. · Personal de las áreas de
generando un archivo en formato implementación del sistema Web. · Tiempo promedio para la administración y contabilidad.
Excel. emisión de comprobantes
electrónicos.
3. ¿De qué manera el sistema Web 3.Comparar los tiempos de 3. Existe variación significativa
reducirá los tiempos de emisión de emisión de facturación, antes y en el tiempo de emisión de
facturación en la Institución después de la implementación del facturación en la Institución
Educativa Privada PREMIUM? módulo respectivo en el sistema Educativa Privada PREMIUM,
Web emitiendo documentos antes y después de la
electrónicos. implementación del sistema Web.

106
ANEXO 3. Instrumentos de recolección de datos

GUÍA DE OBSERVACIÓN N° 01
TIEMPO PROMEDIO DE CONSULTA DE HISTORIAL DE PAGOS

La presente guía de observación se utiliza con la intención de medir el tiempo promedio en la

operación de consulta de historial de pagos.
Instrucciones: Para el llenado de la tabla se deberá registrar la hora en que se comienza a
realizar la operación y la hora en que finaliza.

N° Registro Rango de Tiempo Tiempo de

Hora de Inicio Hora de Fin Registro
(minutos)
1
2
3
4
5
6
Tiempo promedio de registro
Fecha de registro: ___/___/_____
Observaciones:
__________________________________________________________________________
______________________________________________________________________
Evaluador: _______________________________________________________________

Verificado [ ] Procesado [ ] Archivado [ ]

107
 GUÍA DE OBSERVACIÓN N° 02
TIEMPO PROMEDIO DE CONSULTAS DE REPORTES DE INGRESOS MENSUALES

La presente guía de información se utiliza con la intención de medir el tiempo promedio en la

operación de consulta de reportes de ingresos mensuales.
Instrucciones: Para el llenado de la tabla se deberá registrar la hora en que se comienza a
realizar la operación y la hora en que finaliza.

N° Registro Rango de Tiempo Tiempo de

Hora de Inicio Hora de Fin Registro
(minutos)
1
2
3
4
5
6
Tiempo promedio de registro
Fecha de registro: ___/___/_____
Observaciones:
__________________________________________________________________________
______________________________________________________________________
Evaluador: _______________________________________________________________

Verificado [ ] Procesado [ ] Archivado [ ]

108
 GUÍA DE OBSERVACIÓN N° 03
TIEMPO PROMEDIO DE EMISIÓN DE COMPROBANTES ELECTRÓNICOS

La presente guía de observación se utiliza con la intención de medir el tiempo promedio en la

operación de emisión de comprobantes electrónicos.
Instrucciones: Para el llenado de la tabla se deberá registrar la hora en que se comienza a
realizar la operación y la hora en finaliza.

N° Registro Rango de Tiempo Tiempo de

Hora de Inicio Hora de Fin Registro
(minutos)
1
2
3
4
5
6
Tiempo promedio de registro
Fecha de registro: ___/___/_____
Observaciones:
__________________________________________________________________________
______________________________________________________________________
Evaluador: _______________________________________________________________

Verificado [ ] Procesado [ ] Archivado [ ]

109
 GUÍA DE OBSERVACIÓN N° 04
NIVEL DE SEGURIDAD DEL SISTEMA WEB

La presente guía de observación se utiliza con la intención de medir el nivel de seguridad del
sistema Web para mejorar el control de pagos con facturación electrónica en la I.E.P.
PREMIUM – PIURA, 2020
Instrucciones: Para el llenado de la tabla se deberá registrar por cada vulnerabilidad la
solución aplicada y marcar con (X) si esta fue controlada.
Control
Vulnerabilidad Solución Observación
Marque con una (X)

Fecha de registro: ___/___/_____

Observaciones:
__________________________________________________________________________
______________________________________________________________________
Evaluador: _______________________________________________________________

Verificado [ ] Procesado [ ] Archivado [ ]

110
 ENCUESTA N° 01

NIVEL DE SATISFACCIÓN DE USUARIOS

Con el propósito de determinar la importancia y calidad del sistema web desarrollado,

deseamos conocer su punto de vista sobre dicho sistema. El éxito de dicho proceso depende
de su objetividad y colaboración. Solicitamos tener en cuenta la siguiente escala establecida
para su valoración.
1. Muy en desacuerdo
2. En desacuerdo
3. No estoy seguro
4. De acuerdo
5. Muy de acuerdo

Para responder señale con una X la opción o la casilla elegida.

Preguntas: Nivel de satisfacción de usuarios
1 2 3 4 5
1. El sistema se encuentra disponible para realizar mis labores cotidianas.
2. La información que me brinda el sistema es confiable. 1 2 3 4 5
Las consultas y reportes que me brinda el sistema son exactas y no se 1 2 3 4 5
3.
presentan inconsistencias.
La información que se gestiona en el sistema es de suma importancia 1 2 3 4 5
4. para mi trabajo diario; sin el apoyo de este sistema no podría realizar
mis labores.
Muchas veces el cumplimiento de mis responsabilidades se ven 1 2 3 4 5
5. afectadas porque el sistema no me proporciona información confiable
y oportuna.
1 2 3 4 5
La funcionalidad ofrecida por el sistema apoya de manera completas
6.
los procesos propios de las oficinas de administración y contabilidad.
1 2 3 4 5
El sistema contiene funciones que abarcan las necesidades particulares
7.
de las oficinas de administración y contabilidad que deben llevar a cabo.
8. La navegación en el sistema es fácil. 1 2 3 4 5
La búsqueda de información y selección de un elemento en el sistema 1 2 3 4 5
9.
es sencilla.
La apariencia del sistema es estética y agradable, facilitando el trabajo 1 2 3 4 5
10
cotidiano
La manera como se comunica el sistema conmigo en la medida que 1 2 3 4 5
11.
trabajo con el (mensajes, advertencias, etc.) es entendible.
1 2 3 4 5
12. El sistema presenta errores continuamente mientras se opera con él.
Cuando se solicita información al sistema, este despliega dicha 1 2 3 4 5
13.
información en el tiempo esperado.
14. En general se encuentra satisfecho con el sistema. 1 2 3 4 5

111
 ENCUESTA N° 02

NIVEL DE USABILIDAD

Objetivo: Medir el nivel de Usabilidad el cual se basa en la calidad de la experiencia que tiene un usuario
cuando interactúa con el sistema Web.
Con el propósito de determinar la importancia y calidad del sistema web desarrollado, deseamos
conocer su punto de vista sobre dicho sistema. El éxito de dicho proceso depende de su objetividad y
colaboración. Solicitamos tener en cuenta la siguiente escala establecida para su valoración.
1. Muy difícil
2. Difícil
3. Regular
4. Fácil
5. Muy fácil

Para responder señale con una X la opción o la casilla elegida.

Preguntas Usabilidad
¿Qué tan fácil considera el proceso de gestión de conceptos de pagos,
1 1 2 3 4 5
en el sistema Web?
¿Qué tan fácil considera el proceso de gestión de apoderados, en el
2 1 2 3 4 5
sistema Web?
¿Qué tan fácil considera el proceso de gestión de estudiantes, en el
3 1 2 3 4 5
sistema Web?
¿Qué tan fácil considera el proceso de matrícula de estudiantes, en el
4 1 2 3 4 5
sistema Web?
¿Qué tan fácil considera el proceso de registro de pagos, en el sistema
5 1 2 3 4 5
Web?
¿Qué tan fácil considera el proceso de consulta de historial de pagos
6 1 2 3 4 5
de estudiantes, en el sistema Web?
¿Qué tan fácil considera el proceso de elaboración de reporte de pagos,
7 1 2 3 4 5
en el sistema Web?
¿Qué tan fácil considera el proceso de anulación de documentos
8 1 2 3 4 5
electrónicos, en el sistema Web?
¿Qué tan fácil considera el proceso de contingencia de documentos
9 1 2 3 4 5
electrónicos, en el sistema Web?
¿Qué tan fácil considera el proceso de emisión de libros contables, en
10 1 2 3 4 5
el sistema Web?
¿Qué tan fácil considera el proceso de emisión de notas electrónicas,
11 1 2 3 4 5
en el sistema Web?
¿Qué tan fácil considera el proceso de generación de resúmenes
12 1 2 3 4 5
diarios, en el sistema Web?

112
 ENCUESTA N° 03

CONFIABILIDAD

Objetivo: Medir el nivel de Confiabilidad, se refiere a la capacidad de desempeñar una función

requerida, en condiciones establecidas durante un período de tiempo determinado
Con el propósito de determinar la importancia y calidad del sistema web desarrollado, deseamos
conocer su punto de vista sobre dicho sistema. El éxito de dicho proceso depende de su objetividad y
colaboración. Solicitamos tener en cuenta la siguiente escala establecida para su valoración.
1. Muy deficiente
2. Deficiente
3. Regular
4. Bueno
5. Muy Bueno

Para responder señale con una X la opción o la casilla elegida.

Preguntas Confiabilidad

¿Considera confiable la validación de datos al ingresar al sistema

1 1 2 3 4 5
Web?

Al realizar una búsqueda ¿Considera confiables los resultados

2 1 2 3 4 5
obtenidos del sistema Web?

Al realizar una consulta de historial de pagos ¿Considera confiables

3 1 2 3 4 5
los resultados obtenidos del sistema Web?

Al realizar un reporte ¿Considera confiables los resultados obtenidos

4 1 2 3 4 5
del sistema Web?

Al realizar emitir un documento contable ¿Considera confiables los

5 1 2 3 4 5
resultados obtenidos del sistema Web?

Al anular un comprobante de pago ¿Considera confiables los

6 1 2 3 4 5
resultados obtenidos del sistema Web?

Al emitir documentos electrónicos respaldados por un certificado

7 digital ¿Considera confiables los resultados obtenidos del sistema 1 2 3 4 5
Web?

113
ANEXO 5. Validación de instrumentos
GUÍA DE OBSERVACIÓN N° 01

114
GUÍA DE OBSERVACIÓN N° 02

115
GUÍA DE OBSERVACIÓN N° 03

116
GUÍA DE OBSERVACIÓN N° 04

117
ENCUESTA N° 01

118
ENCUESTA N° 02

119
ENCUESTA N° 03

120