Aplicación web para la gestión de la información de los

Programas Sociales en la Municipalidad Provincial del Callao

Tesis para optar el Título de Ingeniero de Sistemas y Cómputo

Josue Giomar Pajuelo Carlevarino

Asesor:
Dr. Santiago Gonzales Sánchez

Lima – Perú
Abril de 2019

1
 ÍNDICE

ÍNDICE DE FIGURAS ........................................................................................................... 4

ÍNDICE DE TABLAS ............................................................................................................. 9
RESUMEN ............................................................................................................................ 10
ABSTRACT .......................................................................................................................... 11
INTRODUCCIÓN ................................................................................................................ 12
CAPÍTULO I: PLANTEAMIENTO DEL PROBLEMA ................................................... 13
1.1. Situación Problemática............................................................................................... 13
1.2. Problema de la investigación ...................................................................................... 15
Problema General ............................................................................................................ 15
Problemas Específicos ..................................................................................................... 15
1.3. Objetivos ..................................................................................................................... 16
Objetivo General ............................................................................................................. 16
Objetivos Específicos ...................................................................................................... 16
1.4. Justificación ................................................................................................................ 16
1.5. Alcance ........................................................................................................................ 17
CAPÍTULO II: MARCO TEÓRICO ................................................................................... 18
2.1. Antecedentes de la investigación ................................................................................ 18
2.2. Bases teóricas .............................................................................................................. 20
2.3. Glosario de términos .................................................................................................. 32
CAPÍTULO III: VARIABLES E HIPÓTESIS .................................................................... 34

3.1. Variables e Indicadores .............................................................................................. 34

a. Identificación de Variables .......................................................................................... 34
b. Operacionalización de Variables .................................................................................. 34
3.2. Hipótesis...................................................................................................................... 34
Hipótesis General ............................................................................................................ 34
Hipótesis Específicas....................................................................................................... 34
CAPÍTULO IV: METODOLOGÍA PARA EL DESARROLLO DE LA INVESTIGACIÓN
............................................................................................................................................... 35

4.1. Adaptación de la metodología AUP ........................................................................... 35

4.2. Iteraciones................................................................................................................... 38
CAPÍTULO V: SOLUCIÓN TECNOLÓGICA................................................................... 42

5.1. Fase de Inicio .............................................................................................................. 42

a. Modelo de casos de uso de negocio .............................................................................. 42
b. Diagrama de actividades de negocio ............................................................................ 44

2
 c. Matriz de requerimientos ............................................................................................. 49
5.2. Fase de Elaboración.................................................................................................... 52
a. Diagrama de casos de uso de sistema ........................................................................... 52
b. Especificaciones de casos de uso de sistema ................................................................ 55
c. Arquitectura de la aplicación ....................................................................................... 75
5.3. Fase de Construcción.................................................................................................. 78
a. Modelo de base de datos .............................................................................................. 78
b. Diagramas de componentes ......................................................................................... 80
c. Nuevos requerimientos ................................................................................................ 92
d. Diagramas de despliegue ........................................................................................... 100
5.4 Aplicación web ........................................................................................................... 102
CAPÍTULO VI: RESULTADOS........................................................................................ 130

a. Resultados respecto a la efectividad............................................................................ 130

b. Resultados respecto a la mantenibilidad .................................................................... 132
c. Resultados respecto a la usabilidad ............................................................................. 134
d. Resultados respecto a la disponibilidad ...................................................................... 138
e. Resultados respecto a las metas de negocio................................................................. 140
f. Resultados respecto a los indicadores de variables dependientes ............................... 141
CONCLUSIONES .............................................................................................................. 145

RECOMENDACIONES ..................................................................................................... 146

REFERENCIAS BIBLIOGRÁFICAS ............................................................................... 147

ANEXOS ............................................................................................................................. 150

3
 ÍNDICE DE FIGURAS

Figura 2.1. - Transacción Web ................................................................................................ 21

Figura 2.2. - Comprensión de la organización, administración y tecnología ............................ 22
Figura 2.3. - Procesos de RUP comparado con los procesos de AUP ...................................... 24
Figura 2.4. - Fases y Disciplinas de AUP ................................................................................ 25
Figura 2.5. - Áreas semánticas de UML .................................................................................. 27
Figura 2.6. - Efectividad desde el punto de vista de la organización ........................................ 28
Figura 2.7. - Características de la usabilidad ........................................................................... 29
Figura 2.8. - Características de la mantenibilidad .................................................................... 32
Figura 5.1. - Diagrama de casos de uso de negocio ................................................................. 44
Figura 5.2. - Diagrama de actividades de negocio para el proceso de gestión de solicitudes,
primera parte .......................................................................................................................... 45
Figura 5.3. - Diagrama de actividades de negocio para el proceso de gestión de solicitudes,
segunda parte ......................................................................................................................... 45
Figura 5.4. - Diagrama de actividades de negocio para el proceso de evaluación de beneficiarios.
............................................................................................................................................... 46
Figura 5.5. - Diagrama de actividades de negocio para el proceso de evaluación de beneficiarios
............................................................................................................................................... 47
Figura 5.6. - Diagrama de actividades de negocio para el proceso de controlar el almacén ...... 48
Figura 5.7. - Diagrama de actividades de negocio para el proceso de controlar el almacén
mejorado ................................................................................................................................ 48
Figura 5.8. - Diagrama de casos de uso de sistema .................................................................. 54
Figura 5.9. - Prototipo de Formulario de Registro de Solicitud ................................................ 56
Figura 5.10. - Prototipo de formulario de ficha de datos (Información General) ..................... 58
Figura 5.11. - Prototipo de formulario de ficha de datos (Titular) ........................................... 58
Figura 5.12. - Prototipo de formulario de ficha de datos (Dirección actual) ............................ 59
Figura 5.13. - Prototipo de formulario de ficha de datos (Condiciones de vivienda) ................ 59
Figura 5.14. - Prototipo de formulario de ficha de datos (Composición Familiar) .................... 60
Figura 5.15. - Prototipo de formulario de acta de supervisión ................................................ 60
Figura 5.16. - Prototipo de formulario de cambio de estado .................................................. 61
Figura 5.17. - Prototipo de ventana de asistencia de beneficiarios ......................................... 63
Figura 5.18. - Prototipo de ventana de asistencia de transeúntes .......................................... 64
Figura 5.19. - Prototipo de formulario de registro de transeúnte ........................................... 65
Figura 5.20. - Prototipo de bandeja de productos en el almacén ............................................ 66
Figura 5.21. - Prototipo de formulario de registro de productos ............................................ 67
Figura 5.22. – Prototipo de bandeja de kárdex ....................................................................... 68
Figura 5.23. - Prototipo de registro de kárdex ........................................................................ 69

4
Figura 5.24. - Prototipo de pantalla para generar reporte ...................................................... 70
Figura 5.25. - Prototipo de bandeja de productos en el almacén ............................................ 72
Figura 5.26. - Arquitectura de la aplicación ............................................................................ 73
Figura 5.27. - Comportamiento modular de la arquitectura ..................................................... 74
Figura 5.28. - Estructura general de la aplicación .................................................................... 74
Figura 5.29. - Estructura dentro del directorio protected ......................................................... 75
Figura 5.30. - Modelo de base de datos para la gestión del padrón de beneficiarios ................. 76
Figura 5.31. - Modelo de base de datos para el control del almacén ........................................ 77
Figura 5.32. - Modelo de base de datos para la gestión de usuarios ......................................... 77
Figura 5.33. - Modelo de base de datos MASTER ................................................................... 78
Figura 5.34. - Diagrama de componentes (main) .................................................................... 78
Figura 5.35. - Diagrama de componentes (paquete extensions) ............................................... 79
Figura 5.36. - Diagrama de componentes (entornos) ............................................................... 79
Figura 5.37. - Diagrama de componentes (componentes generales) ......................................... 80
Figura 5.38. - Diagrama de componentes (modelos) ............................................................... 81
Figura 5.39. - Diagrama de componentes (controladores) ....................................................... 82
Figura 5.40. - Diagrama de componentes (bandeja de solicitudes) ........................................... 82
Figura 5.41. - Diagrama de componentes (nueva solicitud) ..................................................... 83
Figura 5.42. - Diagrama de componentes (ficha de datos) ....................................................... 84
Figura 5.43. - Diagrama de componentes (acta de supervisión) ............................................... 84
Figura 5.44. - Diagrama de componentes (entregas a beneficiarios) ........................................ 85
Figura 5.45. - Diagrama de componentes (entregas a transeúntes) ........................................... 86
Figura 5.46. - Diagrama de componentes (bandeja de movimientos del almacén) ................... 86
Figura 5.47. - Diagrama de componentes (kárdex) .................................................................. 87
Figura 5.48. - Diagrama de componentes (productos) ............................................................. 87
Figura 5.49. - Diagrama de componentes (reportes) ................................................................ 88
Figura 5.50. - Diagrama de componentes (dashboard) ............................................................ 89
Figura 5.51. - Diagrama de componentes (interfaz) ................................................................ 90
Figura 5.52. - Nueva tabla en el modelo de base datos ............................................................ 92
Figura 5.53. - Diagrama de componentes para la bandeja de fichas retiradas ........................... 93
Figura 5.54. - Prototipo cambio a la pantalla de asistencia de transeúntes ............................... 94
Figura 5.55. - Prototipo pantalla de búsqueda de atención de transeúntes ................................ 94
Figura 5.56. - Diagrama de componentes para la búsqueda de atenciones a un transeúnte ....... 95
Figura 5.57. - Cambio en la tabla KARDEX en el modelo de base de datos ............................ 96
Figura 5.58. - Prototipo de menú principal con nuevos reportes .............................................. 97
Figura 5.59. - Diagrama de despliegue (entorno desarrollo) .................................................... 98
Figura 5.60. - Diagrama de despliegue (entorno pre-producción) ............................................ 98

5
Figura 5.61. - Diagrama de despliegue (entorno producción) .................................................. 99
Figura 5.62. - Interfaz de inicio de sesión ............................................................................. 101
Figura 5.63. - Interfaz inicial ................................................................................................ 102
Figura 5.64. - Menú de opciones de gráficos estadísticos ...................................................... 103
Figura 5.65. - Gráfico estadístico mostrado en la aplicación .................................................. 103
Figura 5.66. - Interfaz de registro de solicitud ....................................................................... 104
Figura 5.67. - Mensajes de búsqueda de persona ................................................................... 105
Figura 5.68. - Interfaz de bandeja de fichas aprobadas .......................................................... 105
Figura 5.69. - Interfaz de bandeja de fichas reprobadas ......................................................... 106
Figura 5.70. - Interfaz de ficha de datos (resumen) ............................................................... 106
Figura 5.71. - Interfaz de ficha de datos (titular) ................................................................... 107
Figura 5.72. - Interfaz de ficha de datos (condiciones de la vivienda) .................................... 107
Figura 5.73. - Interfaz de ficha de datos (dirección actual) .................................................... 108
Figura 5.74. - Interfaz de ficha de datos (composición familiar) ............................................. 108
Figura 5.75. - Formulario de registro de beneficiario ............................................................ 109
Figura 5.76. - Interfaz de cambio de estado de ficha ............................................................. 110
Figura 5.77. - Interfaz de cambio de estado de ficha ............................................................. 111
Figura 5.78. - Interfaz de composición familiar .................................................................... 112
Figura 5.79. - Interfaz de asistencia de beneficiarios ............................................................. 112
Figura 5.80. - Lista de beneficiarios activos .......................................................................... 113
Figura 5.81. - Interfaz de asistencia de transeúntes ............................................................... 113
Figura 5.82. - Lista de transeúntes registrados ...................................................................... 114
Figura 5.83. - Lista de transeúntes registrados ...................................................................... 114
Figura 5.84. - Interfaz de lista de movimientos del almacén .................................................. 115
Figura 5.85. - Formulario de registro de movimientos del almacén ....................................... 116
Figura 5.86. - Formulario de datos de movimientos del almacén ........................................... 117
Figura 5.87. - Interfaz de generación de reportes .................................................................. 118
Figura 5.88. - Reporte de entrega de raciones alimentarias por grupo beneficiario ................. 118
Figura 5.89. - Reporte de control del almacén ....................................................................... 119
Figura 5.90. - Reporte de control del almacén en formato kárdex .......................................... 119
Figura 5.91. - Reporte de estado de almacén ......................................................................... 120
Figura 5.92. - Reporte de padrón de beneficiarios ................................................................. 121
Figura 5.93. - Interfaz de lista de verificadores ..................................................................... 121
Figura 5.94. - Formulario de registro de verificadores ........................................................... 122
Figura 5.95. - Interfaz de lista de productos del almacén ....................................................... 122
Figura 5.96. - Formulario de registro de productos ............................................................... 123
Figura 5.97. - Interfaz de listado de un ítem de mantenimiento n .......................................... 123

6
Figura 5.98. - Formulario de registro de ítem ........................................................................ 124
Figura 5.99. - Interfaz de actualización de capacidad de raciones alimentarias ...................... 124
Figura 5.100. - Gráfico de evolución del padrón de beneficiarios por grupo .......................... 125
Figura 5.101. - Gráfico de beneficiarios por distrito .............................................................. 125
Figura 5.102. - Gráfico de beneficiarios por ficha ................................................................. 126
Figura 5.103. - Gráfico de titulares por grupo ....................................................................... 126
Figura 5.104. - Gráfico estadístico de parentescos con el titular ............................................ 126
Figura 5.105. - Gráfico de cobertura de seguros de salud ...................................................... 127
Figura 6.1. - Resultado de facilidad de aprendizaje de la aplicación según encuesta .............. 132
Figura 6.2. - Resultado de sintetizabilidad de la aplicación según encuesta ........................... 133
Figura 6.3. - Resultado de consistencia de la aplicación según encuesta ................................ 133
Figura 6.4. - Resultado de flexibilidad de la aplicación según encuesta ................................. 134
Figura 6.5. - Resultado de robustez de la aplicación según encuesta ...................................... 134
Figura 6.6. - Resultado de recuperabilidad de la aplicación según encuesta ........................... 135
Figura 6.7. - Resultado de tiempos de respuesta de la aplicación según encuesta ................... 135
Figura 6.8. - Resultado de adecuación a las tareas de la aplicación según encuesta ................ 136
Figura 6.9. - Resultado de disminución de la carga cognitiva de la aplicación según encuesta
............................................................................................................................................. 136
Figura 6.10. - Cantidad de beneficiarios faltantes por mes .................................................... 138
Figura 6.11. - Volumen de datos manejados ......................................................................... 139
Figura 6.12. - Cantidad de registros en el módulo de gestión de solicitudes ........................... 140
Figura 6.13. - Cantidad de registros en el módulo de control de entregas .............................. 140
Figura 6.14. - Cantidad de registros en el módulo de control del almacén ............................. 141

7
 ÍNDICE DE TABLAS

Tabla 1.1. - Raciones alimentarias distribuidas en el año 2015 ................................................. 14

Tabla 1.2. - Raciones alimentarias distribuidas en el año 2016 ................................................ 14
Tabla 1.3. - Inversión en el PCA realizada por modalidad ....................................................... 15
Tabla 2.1. - Tabla comparativa de metodologías ..................................................................... 26
Tabla 4.1. - Adaptación de la metodología AUP ..................................................................... 36
Tabla 4.2. - Artefactos de la fase de inicio .............................................................................. 37
Tabla 4.3. - Artefactos de la fase de elaboración ..................................................................... 37
Tabla 4.4. - Artefactos de la fase de construcción ................................................................... 37
Tabla 4.5. - Artefactos de la fase de transición ........................................................................ 38
Tabla 4.6. - Iteraciones por fase .............................................................................................. 38
Tabla 4.7. - Detalle de las iteraciones ..................................................................................... 38
Tabla 4.8. - Hitos ................................................................................................................... 39
Tabla 4.9. - Actividades y objetivo (I0) .................................................................................. 39
Tabla 4.10. - Actividades y objetivo (I1) ................................................................................ 40
Tabla 4.11. - Actividades y objetivo (I2) ................................................................................ 40
Tabla 4.12. - Actividades y objetivo (I3) ................................................................................ 40
Tabla 4.13. - Actividades y objetivo (I4) ................................................................................ 40
Tabla 4.14. - Actividades y objetivo (I5) ................................................................................ 41
Tabla 4.15. - Actividades y objetivo (I6) ................................................................................ 41
Tabla 5.1. - Casos de uso de negocio ...................................................................................... 42
Tabla 5.2. - Actores de negocio .............................................................................................. 43
Tabla 5.3. - Matriz de requerimientos funcionales .................................................................. 49
Tabla 5.4. - Matriz de requerimientos no funcionales .............................................................. 51
Tabla 5.5. - Casos de uso de sistema ....................................................................................... 52
Tabla 5.6. - Actores de sistema ............................................................................................... 53
Tabla 5.7. - ECUS01 .............................................................................................................. 55
Tabla 5.8 - ECUS02 ............................................................................................................... 56
Tabla 5.9. - ECUS03 ............................................................................................................... 61
Tabla 5.10. - ECUS04 ............................................................................................................. 62
Tabla 5.11. - ECUS05 ............................................................................................................. 63
Tabla 5.12. - ECUS06 ............................................................................................................. 65
Tabla 5.13. - ECUS07 ............................................................................................................ 67
Tabla 5.14. - ECUS08 .............................................................................................................. 69
Tabla 5.15. – ECUS09 ............................................................................................................. 71
Tabla 5.16. – ECUS10 ........................................................................................................... 72

8
Tabla 5.17. - Nuevos requerimientos (I2) ............................................................................... 90
Tabla 5.18. - Nuevos requerimientos (I3) ............................................................................... 93
Tabla 5.19. - Nuevos requerimientos (I4) ............................................................................... 95
Tabla 5.20. - Versiones de la aplicación ............................................................................... 100
Tabla 5.21. - Navegadores web para ejecutar la aplicación ................................................... 100
Tabla 6.1. - Indicador de eficacia de la aplicación ................................................................. 128
Tabla 6.2. - Indicador de eficacia de código .......................................................................... 128
Tabla 6.3. - Indicador de eficiencia de la aplicación en relación a tiempos de respuesta ........ 129
Tabla 6.4. - Valores para el cálculo de la media de volumen por módulo .............................. 131
Tabla 6.5. - Valores para el cálculo de la media de número de líneas por módulo .................. 131
Tabla 6.6. - Límites del indicador de mantenibilidad ............................................................ 132
Tabla 6.7. - Tipologías de valores de evaluación ................................................................... 132
Tabla 6.8. - Disponibilidad de los componentes de la aplicación ........................................... 137
Tabla 6.9. - Resultados de corrección de datos erróneos en el padrón de beneficiarios .......... 138
Tabla 6.10. - Resultados de corrección de datos erróneos en el control del almacén .............. 138
Tabla 6.11. - Resultados de reducción de tiempo de generación de reportes .......................... 139
Tabla 6.12. - Resultados sobre la cantidad de registros manipulados o modificados .............. 141

9
 RESUMEN
La Municipalidad Provincial del Callao es una institución pública dedicada a prestar servicios de
calidad promoviendo el desarrollo integral y sostenible en la Provincia Constitucional del Callao,
la institución cuenta con la Gerencia General de Programas Sociales como área encargada de velar
por los programas de apoyo social y complementación alimentaria, como los Programas de
Comedor del Pueblo o el Programa de Vaso de Leche. La gerencia presenta problemas para
gestionar la información, en su mayoría entregada por los ciudadanos, ya que se utilizan
formularios manuales y hojas de cálculo, esto conlleva a problemas de información incompleta e
incorrecta, y demora en visualizar la información mediante reportes y estadísticas. El presente
trabajo busca resolver este problema mediante la adaptación de una metodología de desarrollo e
implementación de una aplicación web para gestionar la información. La metodología
seleccionada fue AUP, esta metodología fue adaptada para el trabajo de la Gerencia de
Informática para asegurar que la aplicación web sea de calidad y se adecúe a los proceso de la
Gerencia General de Programas Sociales. Los resultados obtenidos mediante la operación de
variables y realización de encuestas indican que la aplicación web cumple con los indicadores de
efectividad, mantenibilidad, usabilidad y disponibilidad propuestos. La implementación de una
aplicación web influyó positivamente en la gestión de la información del Programa Comedor del
Pueblo de la Gerencia General de Programas Sociales.
Palabras clave: aplicación web, gestión de la información, AUP, efectividad, mantenibilidad,
usabilidad, disponibilidad.

10
 ABSTRACT
The Provincial Municipality of Callao is a public institution dedicated to providing quality
services promoting integral and sustainable development in the Constitutional Province of Callao,
the institution has the Social Programs General Department as an area in charge of overseeing
social support programs and food complementation, such as the Programa Comoedor del Pueblo
or the Programa Vaso de Leche. This department presents problems to manage information,
mostly delivered by citizens, since they use manual forms and spreadsheets, this leads to problems
of incomplete and incorrect information, and delays in viewing the information through reports
and statistics. The present work seeks to solve this problem by adapting a methodology of
development and implementation of a web application to manage the information. The
methodology selected was AUP, this methodology was adapted for the work of the IT Department
to ensure that the web application is of quality and is adapted to the process of the Social Programs
General Department. The results obtained through the operation of variables and conducting
surveys indicate that the web application complies with the indicators of effectiveness,
maintainability, usability and availability proposed. In conclusion, the implementation of a web
application positively influenced the information management of the Programa Comedor del
Pueblo of the Social Programs General Department.
Key words: web application, information management, AUP, effectiveness, maintainability,
usability, availability.

11
 INTRODUCCIÓN
La Municipalidad Provincial del Callao es una institución pública dedicada a prestar servicios de
calidad promoviendo el desarrollo integral y sostenible en la Provincia Constitucional del Callao,
la institución se encuentra conformada por diferentes gerencias que gestionan la información, en
su mayoría entregada por los ciudadanos, utilizando formularios manuales y hojas de cálculo, esto
conlleva a problemas de información incompleta e incorrecta, y demora en visualizar la
información mediante reportes y estadísticas.
El presente trabajo busca mejorar la manera en la que se gestiona la información del Programa
Comedor del Pueblo en la Gerencia General de Programas Sociales, mediante la implementación
de sistemas de información con aplicaciones web. La solución tecnológica resuelve la tarea
mediante el registro de información completa, la posibilidad de mostrar opciones de
categorización de datos y validación de estos, y generación automática de gráficos estadísticos y
reportes.
El trabajo se organiza en los siguientes capítulos:
Capítulo I: Se describe la situación problemática, el problema general, los problemas específicos,
objetivo general, objetivos específicos, justificación y alcance.
Capítulo II: Se describe el marco teórico, que incluye los antecedentes de la investigación, las
bases teóricas y el glosario de términos.
Capítulo III: Se describe las variables, indicadores, hipótesis general e hipótesis específicas del
trabajo de investigación.
Capítulo IV: Se describe la adaptación de la metodología de desarrollo de software seleccionada.
Capítulo V: Se describe la solución tecnológica, abarca la elaboración de artefactos a lo largo del
desarrollo de software y la demostración de la aplicación desarrollada.
Capítulo VI: Se describen los resultados obtenidos.
Finalizando, con las conclusiones y recomendaciones.

12
 CAPÍTULO I: PLANTEAMIENTO DEL PROBLEMA

1.1. Situación Problemática

La Municipalidad Provincial del Callao es una institución pública dedicada a prestar servicios de
calidad promoviendo el desarrollo integral y sostenible en la Provincia Constitucional del Callao,
a través de procesos simplificados que respondan a la generación de valor público, basados en la
participación ciudadana y la transparencia. La institución cuenta con la Gerencia General de
Programas Sociales como área encargada de velar por los programas de apoyo social y
complementación alimentaria, como los Programas de Comedor del Pueblo o el Programa de
Vaso de Leche.
El reglamento de la ley N° 25307, actualizada en el 2002, establece que las Municipalidades
deben contar con un libro padrón con información primordial sobre los beneficiarios. En
concordancia con tal ley, la Municipalidad Provincial del Callao viene ofreciendo el servicio de
apoyo alimentario a las familias de menores recursos. Estas familias pasan por un proceso de
evaluación realizado por un encargado seleccionado por la Municipalidad, y proveer la
información necesaria para que pueda ser aprobada su solicitud y pertenecer al Libro Padrón.
Asimismo, la Ordenanza Municipal N° 032-2017 que modifica el artículo 152° del Texto Único
del Reglamento de Organizaciones y Funciones, establece las funciones de la Gerencia General
de Programas Sociales, donde se resalta: 1) Establecer lineamientos de gestión y medidas
necesarias para el cumplimiento de los objetivos y de las fases operativas de los programas
sociales y/o presupuestales, 2) Supervisar y evaluar los procesos de identificación, selección,
reconocimiento y registro de los usuarios o beneficiarios de los centros de atención de los
programas sociales de apoyo alimentario y su actualización, 3) Remitir información sobre la
ejecución del Programa de Vaso de Leche y otros programas sociales de apoyo alimentario. Por
lo tanto la Gerencia General de Programas Sociales necesita de herramientas que la apoyen con
el cumplimiento de sus funciones.
La información recolectada por los evaluadores es manejada de forma manual, dichos documentos
son susceptibles a contener datos faltantes o erróneos; sin embargo, como la familia o la persona
está en condiciones de pertenecer al padrón de beneficiarios es aprobada. Ya que los trabajadores
de la Gerencia General de Programas Sociales no cuentan con herramientas informáticas que los
ayuden a gestionar su información se vuelve una tarea laboriosa tener información válida de los
beneficiarios. Asimismo, se tiene que tener información detallada de la cantidad de personas a las
que se les entrega raciones alimentarias, esta tarea se realiza de forma ineficiente mediante
documentos presentados de forma muy informal, los cuáles los coordinadores reciben para
realizar un informe en cuadros de hojas de cálculo.

13
En la tabla 1.1 y tabla 1.2, se precisa la información sobre las raciones alimentarias distribuidas
en los años 2015 y 2016 de acuerdo a la transparencia de información pública brindada a los
ciudadanos. De acuerdo a las figuras el Programa Comedor del Pueblo distribuye 650 raciones
alimentarias dividiendo los beneficiarios en 7 grupos distintos. Sin embargo, con la información
recolectada inicialmente se ha notado que de más de 600 beneficiarios, entre el 20% y 30% no
han sido categorizados como tal, y no se cuentan con datos que validen la categoría a la que
pertenecen. La cantidad de beneficiarios que se tienen y la capacidad máxima de beneficiarios es
variable de acuerdo al presupuesto que se le asigne al Programa de Comedor del Pueblo.

RACIÓN RACIÓN
GRUPO BENEFICIARIO %
DIARIA ANUAL
Niños de 7 años a 13 años 64 15,857 10%
Adolescentes de 14 años a 17 años 42 9,876 6%
Madres(incluye niños infantes, menores de 7 años) 140 38,479 23%
Desempleados de 18 a 60 años 120 30,243 18%
Tercera Edad de 61 años a más 160 41,600 25%
Discapacitados 80 19,495 12%
Caso Social (Asistencia Social) 35 9,100 6%
TOTAL 650 164,650 100%
Tabla 1.1 – Raciones alimentarias distribuidas en el año 2015 (Municipalidad Provincial del
Callao, 2016)
RACIÓN RACIÓN
GRUPO BENEFICIARIO %
DIARIA ANUAL
Niños de 7 años a 13 años 61 3,782 9%
Adolescentes de 14 años a 17 años 21 1,302 3%
Madres(incluye niños infantes, menores de 7 años) 83 5,146 13%
Desempleados de 18 a 60 años 72 4,464 11%
Tercera Edad de 61 años a más 299 18,538 46%
Discapacitados 95 5, 890 15%
Caso Social (Asistencia Social) 19 1,178 3%
TOTAL 650 40,300 100%
Nótese el considerable incremento del porcentaje de atención al grupo beneficiario de tercera
edad.
Situación que nos demuestra el gran porcentaje de ancianos en riesgo, abandonados,
enfermos; que no cuentan con ningún apoyo.
Tabla 1.2 – Raciones alimentarias distribuidas en el año 2016 (Municipalidad Provincial del
Callao, 2017)

La Gerencia General de Programas Sociales cuenta con un almacén del cual se realizan
movimientos en el stock diariamente. Los formularios donde se registran los datos de los
movimientos también son manejados manualmente y se han detectados errores en los documentos
que se reflejan en la gestión de la información del almacén, lo cual puede llevar a un recorte del
presupuesto de la gerencia.

14
La Gerencia General de Programas Sociales no sólo se encarga de velar por el programa de
Comedores Populares sino también como otros programas a beneficio del pueblo como el
Programa de Vaso de Leche, cuyos flujos de trabajo no han sido tratados. Aun así, la Gerencia
General de Programas Sociales tiene como objetivo ampliar el presupuesto del programa de
Comedores Populares para poder aumentar la cantidad de personas que pueden ayudar de forma
diaria. En la tabla 1.3 se puede ver que la gerencia maneja un presupuesto considerable, pero sin
embargo entregan información incorrecta producto de la mala gestión. Donde se ve que en la
información entregada el número de personas con discapacidad atendidas en el Programa de
Complementación Alimentaria en diferentes modalidades en todo el año 2015 es cero.

Nº DE
PRESUPUESTO Nº DE
MODALIDAD Nº DE Nº DE PERSONAS
EJECUTADO CENTOS
DE BENEFICIARIOS BEEFICIARIOS CON
DURANTE EL DE
EJECUCIÓN PROGRAMADOS ATENDIDOS DISPACIDAD
AÑO 2015 – S/ ATENCIÓN
ATENDIDAS
Comedores
5,602,394.74 25,785 25,785 0 351
Populares
PANTBC 566,475.62 695 695 0 44
Dentro del
Convenios presupuesto de 1,330 1,330 0 6
comedores
Dentro del
Actas de
presupuesto de 2,003 2,003 298 36
Compromiso
comedores
Total S/ 6,168,870.36 29,998 29,998 298 443

Tabla 1.3 – Inversión en el PCA realizada por modalidad (Municipalidad Provincial del
Callao, 2017)

1.2. Problema de la investigación

Problema General

¿En qué medida la aplicación web influye en la gestión de la información de los Programas
Sociales en la Municipalidad Provincial del Callao?

Problemas Específicos

 ¿En qué medida el nivel de efectividad de la aplicación web influye en la gestión de la

información de los Programas Sociales en la Municipalidad Provincial del Callao?
 ¿En qué medida el nivel de mantenibilidad de la aplicación web influye en la gestión de la
información de los Programas Sociales en la Municipalidad Provincial del Callao?
 ¿En qué medida el nivel de usabilidad de la aplicación web influye en la gestión de la
información de los Programas Sociales en la Municipalidad Provincial del Callao?
 ¿En qué medida el nivel de disponibilidad de la aplicación web influye en la gestión de la
información de los Programas Sociales en la Municipalidad Provincial del Callao?

15
1.3. Objetivos

Objetivo General

Determinar la influencia de la aplicación web en la gestión de la información de los Programas

Sociales en la Municipalidad Provincial del Callao.

Objetivos Específicos

 Determinar la influencia del nivel de efectividad de la aplicación web en la gestión de la

información de los Programas Sociales en la Municipalidad Provincial del Callao.
 Determinar la influencia del nivel de mantenibilidad de la aplicación web en la gestión de la
información de los Programas Sociales en la Municipalidad Provincial del Callao.
 Determinar la influencia del nivel de usabilidad de la aplicación web en la gestión de la
información de los Programas Sociales en la Municipalidad Provincial del Callao.
 Determinar la influencia del nivel de disponibilidad de la aplicación web en la gestión de la
información de los Programas Sociales en la Municipalidad Provincial del Callao.

1.4. Justificación
Los programas de alimentación-nutrición son verdaderamente importantes, puesto que cumplen
una doble función. La primera, aliviando la pobreza al mejorar la calidad de vida de las personas
en dicha situación. La segunda, al reducir la pobreza, al existir un claro vínculo entre una buena
alimentación y una buena salud, particularmente en los primeros años de vida. Se ha determinado
que la salud en la infancia y juventud temprana tienen un importante impacto sobre el nivel de
vida futuro de las personas. Entre los programas estatales relacionados con la alimentación, los
que más destacan son el Vaso de Leche y los Comedores populares. (Vásquez, 2006)
El trabajo de investigación surge como respuesta a la problemática de gestión de información que
presenta la Gerencia General de Programas Sociales de la Municipalidad Provincial del Callao y
tiene como finalidad implementar un sistema informático en dicha gerencia que mejore la gestión
de la información mediante controles en el registro de la información y generación automática de
reportes y estadísticas.
La presente investigación busca servir como base no para proyectos de similar naturaleza, no sólo
para gerencias encargadas en velar por los programas sociales sino también para unidades
municipales provinciales o distritales que deseen implementar sistemas de información de manera
gerencial. La implementación de la solución permite mejorar los servicios que los organismos
gubernamentales brindan a los ciudadanos debido a que se puede acceder a la información de
manera más sencilla y rápida, asimismo ya que se tiene con información bien estructurada y
validada, se puede contar con reportes y estadísticas precisas que sirven de apoyo a la toma de
decisiones.

16
1.5. Alcance
 Análisis del problema de control de información del Programa de Comedor del Pueblo.
 Planteamiento de la información y categorización que se debe manejar.
 Estudio y evaluación de metodologías de desarrollo de software.
 Adaptación e implementación de la metodología seleccionada para la construcción del
sistema planteado.
 Modelado utilizando el Lenguaje Unificado de Modelado (UML) para la realización de
documentación.
 Construcción de prototipos y presentación de los mismos.
 La implementación del sistema de gestión de la información con los módulos de fichas de
beneficiarios, entrega de raciones, almacén, reportes y mantenimiento en la Gerencia
General de Programas Sociales de la Municipalidad Provincial del Callao.
 La aplicación contará con los siguientes módulos:
a) Inicio: muestra información del sistema.
b) Gestión de Solicitudes: permite registrar y mantener informaciones respecto a las
solicitudes y ficha de datos de los beneficiarios.
c) Control de Entregas: se realiza el registro de la asistencia de los beneficiarios al
comedor del pueblo así como las personas externas al padrón llamados transeúntes.
d) Control de Almacén: se realiza el registro de los movimientos de productos del
almacén.
e) Reportes: permite generar diferentes tipos de reportes solicitados por los usuarios.
f) Mantenimiento: permite registrar y actualizar ítems necesarios para el funcionamiento
del sistema

17
 CAPÍTULO II: MARCO TEÓRICO

2.1. Antecedentes de la investigación

Lozano, H. (2017). Análisis y desarrollo de un sistema web para la gestión kárdex de un
almacén. Tesis para optar el grado de máster en ingeniería web en la Universidad
Politécnica de Madrid, Madrid, España.
El autor busca optimizar los tiempos, recursos y acceso a la información de manera confiable,
precisa y oportuna, para ello propone el desarrollo de un sistema web para la automatización del
proceso kárdex, que facilite de una forma máxima la gestión del mismo almacén de una compañía,
implementando herramientas tecnológicas de libre distribución, tales como: html5, css3, php,
jquery, etc., que permitan comunicar, informar y relacionar las actividades diarias que se realizan
de una manera más rápida y directa. El resultado es un producto de software funcional, en cuyo
desarrollo se pudo demostrar la validez de la metodología aplicada siendo fuerte en la facilidad
de implantación y agilidad en cuanto a cambios, con lo cual se cumplió con los objetivos
planteados por el autor. El trabajo del autor se relaciona al proyecto propuesto en una de las
funcionalidades planteadas para la aplicación web, siendo esta el control del almacén mediante
kardex, además las ideas del autor en cuanto a identificación de requerimientos pueden ser
utilizadas como bases para el desarrollo de la aplicación web.

Huanca, C. (2015). Sistemas de información para la administración de programas sociales

(SIAPS) en la Municipalidad Provincial de Azángaro. Tesis para optar el título de Ingeniero
Estadístico e Informático en la Universidad Nacional del Altiplano, Puno, Perú.
El autor aborda la problemática del incremento de nuevos programas sociales y nuevos
beneficiarios, de forma que no se cuenta con información a tiempo real de los programas sociales
realizados. Esto genera múltiples deficiencias en el manejo e integración de la información como
llevar el control administrativo, registro, procesamiento, distribución, control documentario y
personal administrativo en la gerencia a cargo. Tiene como objetivo general desarrollar e
implementar un sistema de información (SIAPS) para la automatización de los procesos de
administración de recursos y apoyos sociales en la Gerencia de Desarrollo Social. Finalmente se
logró construir un producto robusto con planes a cambios futuros, reutilización de código, además
la interacción con diferentes lenguajes, que permite a la Gerencia de Desarrollo Social de la
Municipalidad Provincial de Azángaro realizar sus labores para beneficio de la población.

18
Alva, R. (2014). Análisis, diseño e implementación de un sistema de información para el apoyo
al proceso de toma de decisiones en la ejecución de proyectos sociales de una municipalidad
provincial. Tesis para optar el título de Ingeniero Informático en la Pontificia Universidad
Católica del Perú, Lima, Perú.
La problemática que aborda la autora es la forma en la que la información se recoge mediante
registros manuales y hojas de cálculo, los cuales son poco confiables y muchas veces
inconsistentes, careciendo de un historial de los beneficiarios, lo cual dificulta enormemente
contar con información a nivel gerencial que permita tomar decisiones acertadas y oportunas en
la gestión de los programas sociales. Por lo tanto, estableció como objetivo general la
implementación de un Sistema de Información Gerencial que permita gestionar la información
del Programa Social de Vaso de Leche y el Programa de Complementación Alimentaria. Como
resultados, se realizó el modelado del proceso de negocio de la unidad ejecutora de los programas
sociales, así como la arquitectura del software basándose en los requerimientos de la organización.
Asimismo, se elaboró una herramienta de Balanced Scorecard para el establecimiento de
indicadores de gestión y sus mecanismos de control, delimitando su periodo, frecuencia y formas
de monitoreo de manera que se optimizó la gestión de la información manejada, lográndose la
aceptación de los usuarios finales.

Bonilla, C. y Guerrero E. (2014). Evaluación del programa municipal “Comedores

Populares” de la Municipalidad Provincial de Lambayeque. Caso: Distrito Lambayeque. Año
2007 – 2012. Tesis para optar el título de Economista en la Universidad Católica Santo
Toribio de Mogrovejo, Chiclayo, Perú.
Las autoras tienen como objetivo evaluar la eficacia del Programa Social “Comedores Populares”
donde no ha habido un seguimiento al programa para conocer si existe una adecuada gestión. En
su investigación analizan una base de datos obtenida del Sistema de Focalización de Hogares
(SISFOH) de manera manual para realizar una evaluación de la condición socioeconómica de los
beneficiarios de los Comedores Populares en el distrito de Lambayeque. Finalmente las autoras
elaboraron una serie de estadísticas de gestión donde denotan que los programas sociales, al
carecer de un sistema de evaluación y monitoreo de su funcionamiento, trajeron consigo que el
manejo de padrón de beneficiarios sean limitados. Se concluye que el programa social de
comedores populares en el distrito de Lambayeque cuenta con subcobertura de beneficiarios
debido a la falta de herramientas que faciliten la gestión de dichos programas.

19
Hernández, J. & de la Cruz, A (2011). Sistema de apoyo a la gestión del departamento de
dirección de desarrollo comunitario de la Ilustre Municipalidad de San Nicolás. Tesis para
obtener el título de ingeniero de ejecución en computación e informática en la Universidad
del Bío-Bío, Región del Bío Bío, Chile.
Los autores abordan el problema de existen en las atenciones de los ciudadanos respecto a los
tiempos y confiabilidad de la información ocurridos por el uso de la información en registros
manuales y planillas de Excel. Los autores proponen el desarrollo de un sistema de escritorio que
permite al personal realizar los registros de la información y un aplicativo web que permita a los
ciudadanos visualizar el estado de sus trámites. Los autores concluyen con la implementación de
las aplicaciones mencionadas, logrando satisfacer correctamente los requerimientos de los
usuarios de los departamentos de Asistencia Social y Vivienda. En relación a los ciudadanos la
aplicación web para conocer oportunamente las tramitaciones que los ciudadanos han efectuado
en las áreas correspondientes tomó una gran aceptación.
2.2. Bases teóricas
2.2.1. Aplicación Web
Surgen como alternativa a la necesidad de confeccionar páginas dinámicas, mejorando el
rendimiento de las páginas web estáticas. Las soluciones vienen principalmente por dos vías. Por
un lado se diseñan sistemas de ejecución de módulos más integrados con el servidor, que evitan
que éste tenga que instanciar y ejecutar multitud de programas. La otra vía consiste en dotar al
servido de un intérprete de algún lenguaje de programación (RXML, PHP, VBScript, etc.) que
nos permita incluir las páginas en el código de manera que el servidor sea quien lo ejecute,
reduciendo así los tiempos de respuesta. Una de las tecnologías que más éxito ha obtenido y una
de las que más se utiliza en Internet es el lenguaje de programación interpretado por el servidor
PHP. Se trata de un lenguaje que permite incrustar HTML en los programas, con una sintaxis que
proviene de C y Perl. Debido a su facilidad de aprendizaje, su sencillez y potencia, se convirtió
en una herramienta muy utilizada para el desarrollo de proyectos web. (Mateu, 2004)

Una aplicación web típica, (Martín & Martín, 2014), contiene los siguientes componentes:

 Un navegador, por ejemplo Internet Explorer, Mozilla Firefox o Google Chrome.

 Un servidor web, como Apache o IIS (Internet Information Server), que proporciona el
servicio de conexión entre la base de datos y los clientes.
 Un servidor de base de datos, como MSSQL, MySQL u Oracle, que almacenará la
información a acceder.
 Una aplicación que accede a los datos, como por ejemplo una aplicación realizada en PHP o
en ASAP. Esta aplicación contendrá las instrucciones necesarias para interactuar con la base
de datos.

20
En la siguiente figura 2.1 se puede ver una transacción web con base de datos, en la que se hace
una petición HTTP a un servidor web. (Martín & Martín, 2014)

Figura 2.1. – Transacción Web (Martín & Martín, 2014)

2.2.2. Gestión de la Información

Surge como el manejo de inteligencia corporativa de una organización, que permite reaccionar
ante cambios de su entorno apoyándose en el uso de la información y de los recursos de
información disponibles. Donde los elementos involucrados pueden ser resumidos en tres grupos:
los que competen a la información como fuente/recurso (procesos productivos al interior de las
organizaciones), los relacionados con los usuarios y servicios de información y los que conforman
el canal de comunicación entre usuarios y la fuente. Esta situación nos lleva a las concepciones
más recientes defendidas por la Gestión de la Información, en el sentido de que las organizaciones
deben ser consideradas fundamentalmente como sistemas de información. Obviamente, es
fundamental entender que lo que se debe gestionar es la información y no la tecnología. El
conocimiento y la inteligencia potenciados por la información son lo importante, el soporte que
contenga, es menos importante. El obtener un resultado de las tecnologías de la información
dependerá de cuán inteligentemente se gestionen. Y parte de esa inteligencia consiste en pasar a
entender que la función de las tecnologías de información es gestionar mejor la información, para
convertirla en conocimiento, personal u organizacional. Pero, para conseguirlo, tenemos primero
que entender que transferir información es muy poco útil, y que la clave está en que los sistemas
de información nos permitan intercambiar información o sea transaccionarla. (Rodríguez, 2012)

2.2.3. Sistemas de Información Gerenciales

Para comprender por completo los sistemas de información, se debe conocer las dimensiones más
amplias de organización, administración y tecnología de la información de los sistemas, junto con

21
su poder para proveer soluciones a los desafíos y problemas en el entorno de negocios. Como se
muestra en la Figura 2.2, se refieren a esta comprensión más extensa de los sistemas de
información, que abarca un entendimiento de los niveles gerenciales y organizacionales de los
sistemas, así como de sus dimensiones técnicas, como alfabetismo en los sistemas de información.
Por consiguiente, Los sistemas de información gerenciales son una parte integral de las
organizaciones. Sin duda, para algunas compañías como las empresas de reportes crediticios, no
habría negocio sin un sistema de información. Los elementos clave de una organización son: su
gente, su estructura, sus procesos de negocios, sus políticas y su cultura. (Laudon & Laudon,
2004)

Figura 2.2. – Comprensión de la organización, administración y tecnología (Laudon &

Laudon, 2004)

2.2.4. Manifiesto Ágil

Herrera & Valencia (2007) explican: el manifiesto ágil es un documento que resume en cuatro
valores y doce principios las mejores prácticas para el desarrollo de software, basados en la
experiencia de 17 industriales del software, en procura de desarrollos más rápidos conservando
su calidad. El manifiesto hace énfasis en cuatro valores principales que deben soportar el
desarrollo de software:
a) Los individuos e interacciones por encima de los procesos y las herramientas.
b) Software funcionando por encima de la documentación.
c) La colaboración del cliente por encima de la negociación del contrato.
d) La respuesta al cambio por encima del seguimiento de un plan.

Bajo este concepto se referencia a las características que hacen la diferencian entre un proceso
ágil y uno tradicional, y constituyen las ideas centrales del desarrollo ágil. Nuestra mayor
prioridad es satisfacer al cliente mediante entregas tempranas y continuas de software con valor.
(Herrera & Valencia, 2007)

22
 Bienvenidos los cambios a los requerimientos, incluso los tardíos. Los procesos ágiles
aprovechan los cambios para la ventaja competitiva del cliente.
 Liberar frecuentemente software funcionando, desde un par de semanas a un par de meses,
con preferencia por los periodos más cortos. Las personas del negocio y los desarrolladores
deben trabajar juntos diariamente a lo largo del proyecto.
 Construir proyectos en torno a individuos motivados. Darles el entorno y apoyo que necesiten,
y confiar en ellos para que consigan hacer su trabajo.
 El método más efectivo y eficiente de compartir información a, y dentro de un equipo de
desarrollo, es la conversación cara a cara.
 El software funcionando es la medida de progreso.
 Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores
y usuarios deberían ser capaces de mantener relaciones cordiales.
 La atención continua a la excelencia técnica y al buen diseño incrementa la agilidad.
 La simplicidad –el arte de maximizar la cantidad de trabajo no hecho- es esencial.
 Las mejores arquitecturas, requerimientos y diseños emergen de los equipos auto-
organizados.
 En intervalos regulares, el equipo reflexiona sobre cómo volverse más efectivo, entonces
afina y ajusta su comportamiento como corresponde.

2.2.5. Proceso Unificado Ágil (AUP)

El Proceso Unificado Ágil (AUP) es un enfoque de modelado híbrido creado por Scott Ambler
combinando el Proceso Unificado Racional (RUP) con los métodos ágiles (AM). Scott Ambler
trabaja para el grupo IBM Methods como líder de práctica para el desarrollo ágil. Combinando
RUP con AM, Ambler creó un sólido marco de trabajo que puede ser aplicado a todo tipo de
proyectos de software, grandes o pequeños. Los métodos ágiles proveen valores, principios y
prácticas para AUP. El manifiesto ágil muestra los que son estos valores y principios. (Edeki,
2013)
Edeki explica, cuando Ambler creó AUP, centró el diseño alrededor de los siguientes principios:
 La mayoría de personas no leen documentación detallada. Sin embargo, necesitarán guía y
entrenamiento.
 El proyecto debería ser descrito en unas cuantas páginas.
 AUP se ajusta a los valores y principios descritos por la Alianza Ágil.
 El proyecto debe centrarse en entregar valor esencial en vez de aspectos innecesarios.
 Los desarrolladores deben ser libres de usar las herramientas con las que mejor se adapten.
 AUP es adaptado mediante herramientas HTML comunes

23
Se considera como un marco de trabajo extensible que puede ser adaptado a organizaciones o
proyectos específicos, y se caracteriza por la utilización de los casos de uso, porque se centra en
la arquitectura y porque es iterativa e incremental. AUP, es una metodología que adopta muchas
técnicas ágiles utilizadas en XP y las formalidades de RUP, y su objetivo es adaptarse a las
necesidades del proyecto, contrario a la filosofía de las metodologías tradicionales. (Alcides &
Graciela, 2017)
Alcides y Graciela explican que AUP a diferencia de RUP considera el modelado, la
implementación, las pruebas, el despliegue, la gestión de configuración, la administración del
proyecto y el entorno, como etapas suficientes para hacer de esta metodología de fácil y rápido
entendimiento por todo el grupo de desarrollo. Además, utiliza técnicas ágiles: test driven
development (TDD), agile model driven development (AMDD), agile change management y
database refactoring.
AUP combina algunos de los flujos de trabajo básico de RUP. AUP combina el flujo de modelado
de negocio, el flujo de requerimientos, y el flujo de análisis y diseño en un solo flujo de modelado,
que también contiene la parte de gestión de cambios de la Gestión de cambios y configuración de
RUP, que en AUP es el flujo de configuración. La razón detrás de este cambio es que en los
proyectos ágiles los requerimientos son revisados al inicio de cada iteración, y los nuevos
requerimientos son agregados o los existentes son modificados. (Hansmann & Stober, 2009)

Figura 2.3. – Procesos de RUP comparado con los procesos de AUP (Hansmann & Stober,
2009)

24
Como se explica, AUP consiste en cuatro fases y siete disciplinas. Al igual que la metodología
RUP, AUP contiene las fases de iniciación, elaboración, construcción y transición. Todas las
disciplinas de AUP son ejecutadas de manera iterativa, la cuales el equipo de desarrollo debe
construir, validar y entregar para satisfacer las necesidades del usuario.
En la figura 2.4 se muestra las fases y disciplinas de la metodología representadas de una manera
gráfica.

Figura 2.4. – Fases y Disciplinas de AUP (Ambler, 2005)

Siguiendo las ideas anteriores sobre selección de metodología de desarrollo de software, se

comparó AUP junto con el Proceso Unificado Racional (RUP) y Programación Extrema (XP)
según los siguientes criterios para el presente trabajo.

 Flexibilidad: permite utilizar los elementos necesarios del marco de trabajo para realizar el
sistema.

 Arquitectura: la metodología permite usar el diseño de la arquitectura para conceptualizar y

evolucionar el sistema que se está desarrollando.

 Participación del Cliente: maneja una mayor relación con el cliente, el cliente interactúa con
el proyecto, la planificación y la realización de cada cambio o problema localizado.
 Control de calidad: se realiza la evaluación de la calidad y cumplimiento del proceso de
acuerdo al planeamiento realizado.
 Documentación: documentación del diseño con el objetivo de facilitar su mejora, indicar
cómo están conformado los artefactos, la funcionalidad, restricciones etc.
 Entregables: la metodología controla la manera en la que se realizan las entregas de parte
del sistema con el fin de agregar funcionalidad.

25
 Orientado a casos de uso: uso de casos de uso para describir las acciones y reacciones de un
sistema a la hora de interactuar con un usuario, definir los límites de un sistema y las
relaciones con su entorno.
 Planificación: se sigue un plan para la gestión del desarrollo del proyecto que se utilizarán
para completar las actividades que se realizarán para completar el proyecto.
 Requerimientos: la metodología maneja de forma simple y detallada la captura y gestión de
los requerimientos; los requerimientos son la principal fuente de información a partir de la
cual se realiza el diseño, la implementación y las pruebas.
 Respuesta al cambio: agilidad para tomar decisiones respecto a las nuevas características
que pueden afectar al proceso de desarrollo del proyecto; el cambio es algo frecuente que se
da en el desarrollo de software.
 Tiempo: Agilidad en el tiempo de desarrollo del sistema.

Se realiza un cuadro comparativo teniendo en cuenta los criterios mencionados.

Metodologías
Criterios
AUP RUP XP
Flexibilidad 5 4 5
Arquitectura 4 4 5
Participación del Cliente 4 3 5
Control de Calidad 4 5 4
Documentación 4 5 3
Entregables 4 4 5
Orientado a casos de uso 5 5 0
Planificación 3 5 3
Requerimientos 4 4 5
Respuesta al cambio 4 3 5
Tiempo 5 2 5
TOTAL 46 44 45
Tabla 2.1. – Tabla comparativa de metodologías. Fuente: elaboración propia

Ya que AUP ofrece mayores ventajas para el presente caso se opta por utilizar dicha metodología
para el desarrollo del presente trabajo de investigación.

2.2.6. Leguaje Unificado de Modelado (UML)

El objetivo de UML es a los arquitectos de sistemas, ingenieros de software y desarrolladores de
software con herramientas para el análisis, diseño e implementación de sistemas basados en
software así como para el modelado de negocio y procesos similares. Uno de los objetivos
primarios de UML es avanzar el estado de la industria actual desarrollando herramientas de
modelado visual de objetos. La siguiente figura muestra una delineación más detallada de las
áreas semánticas de UML y dentro de éstas sus categorías. (Object Management Group, UML,
2017)

26
 Figura 2.5. – Áreas semánticas de UML. (Object Management Group, UML, 2017)

2.2.7. Calidad de Software

La calidad se puede expresar como efectividad, flexibilidad, corrección, confiabilidad,
mantenibilidad, portabilidad, usabilidad, seguridad e integridad. La calidad del software se puede
medir y varía de un programa a otro según para las funciones que se ha elaborado, por ejemplo el
software que se desarrolla para el control de aparatos médicos debe de ser confiable "cero fallas"
un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras
que un producto de software que es utilizado durante un periodo de 5 años necesita ser confiable,
mantenible y flexible para que de esta manera se puedan disminuir los costos de mantenimiento
que pueda existir durante el tiempo de su explotación. Al hablar de calidad del producto o calidad
total no precisamente se refiere a lograr una calidad perfecta, es cierto que se requiere calidad en
todo, tanto en el proceso como en el producto final, pero la perfección es algo de lo que se debe
hablar hasta que al menos la calidad total haya sido alcanzada. Por lo tanto para lograr la calidad
en el producto primero que nada es necesario comprender desde el principio del proyecto las
necesidades reales y completas de los usuarios con tanto detalle como sea posible
(requerimientos) mientras más claras y detalladas sean más fáciles de solucionar e implementar
van a ser. (Ayala, 2010)
En estos momentos de mayor competencia la calidad juega un papel muy importante como ventaja
competitiva ante competidores y clientes. Las metodologías ágiles nos están proporcionando un
marco en el que lograr una calidad satisfactoria es parte integral del proceso de desarrollo. Las
herramientas que nos están poniendo a disposición de los desarrolladores son el punto de entrada
a un cambio de paradigma que aumentará la calidad de los desarrollos. Técnicas como el

27
desarrollo guiado por las pruebas (TDD), y aún más otro concepto que se está instaurando, el
desarrollo guiado por las pruebas de aceptación (ATDD), serán las piezas fundamentales sobre
las que se pueda elaborar un producto garantizando su integridad y calidad durante todo su ciclo
de vida. Se busca integrar el control de la calidad en el propio proceso de desarrollo. Es más, se
busca que la única posibilidad de desarrollo sea creando cosas que funcionen correctamente, que
cumplan con una definición de producto acabado en la que participan, colaboratívamente, el
equipo de desarrollo y el cliente o dueño de producto. Se integra en el equipo a cualquier persona
involucrada, como pueden ser personas responsables del testeo de software, pues comparten el
mismo objetivo que el resto del equipo. Otra cuestión fundamental es el cumplimiento de las
expectativas del cliente. Por ello la creación del software en iteraciones y de manera incremental,
base de todas las metodologías ágiles, permite alinear esas expectativas con el avance del
proyecto. Uno de los principios básicos define que el grado de progreso de un proyecto
únicamente se mide por el software creado que funciona. Es decir, software que ya proporciona
valor al cliente, y que es potencialmente utilizable por él. (Díaz, 2009)

a. Efectividad
La norma ISO 25000 de calidad define la efectividad como “la capacidad del producto software
para permitir a los usuarios alcanzar objetivos especificados con exactitud y complexión, en un
contexto de uso especificado”, es decir, la efectividad se constituye en el indicador para evidenciar
si la TI implementada en la organización satisface las expectativas Corporativas de la forma más
óptima. Desde la perspectiva de la administración, la efectividad implica la organización óptima
de cinco elementos: producción, eficiencia, satisfacción, adaptabilidad y desarrollo, aspectos que
se deben considerar en el momento de evaluar la efectividad de la TI como herramienta para
desarrollar las funciones administrativas a nivel empresarial. La efectividad de la TI forma parte
fundamental de la calidad de uso, como lo menciona la ISO 25000 (2005) (Ver Figura 6); además,
esta nueva tecnología implica una dependencia cada vez más generalizada de varios dispositivos
técnicos a un sistema de tratamiento de la información, es decir, el fundamento de la TI se
encuentra reflejado en el auge de los sistemas de información, y por tanto se convierte en un punto
importante la valoración de la efectividad de la TI. (Riascos, 2008)

Figura 2.6. – Efectividad desde el punto de vista de la organización. (Riascos, 2008)

La calidad de un sistema, aplicación o producto es tan buena como los requisitos que detallan el
problema, el diseño que modela la solución, el código que transfiere a un programa ejecutable y
las pruebas que ejercita el software para detectar errores. Un buen ingeniero del software emplea

28
mediciones que evalúan la calidad del análisis y los modelos de diseño, así como el código fuente
y los casos de prueba que se han establecido al aplicar la ingeniería del software. Para obtener
esta evaluación de calidad, el ingeniero debe utilizar medidas técnicas, que evalúan la calidad con
objetividad, no con subjetividad. Asimismo, un buen administrador de proyectos debe evaluar la
calidad objetivamente y no subjetivamente. A medida que el proyecto progresa el administrador
del proyecto siempre debe valorar la calidad. Aunque se pueden recopilar muchas medidas de
calidad, el primer objetivo en el proyecto es medir errores y defectos. Las métricas que provienen
de estas medidas proporcionan una indicación de la efectividad de las actividades de control y de
la garantía de calidad en grupos o en particulares. Por ejemplo los errores detectados por hora de
revisión y los errores detectados por hora de prueba suministran una visión profunda de la eficacia
de cada una de las actividades envueltas en la métrica. Así los datos de errores se pueden utilizar
también para calcular la eficiencia de eliminación de defectos en cada una de las actividades del
marco de trabajo del proceso. (Gonzales, 2001)

b. Usabilidad

El estándar ISO9126-1(2001), presenta dos modelos de calidad. La primera referida a la calidad

interna y externa y la segunda a la calidad en uso. Una de las características descritas en la
ISO/IEC 9126 (2001) viene a ser la usabilidad, definiéndola como la capacidad del producto
software de ser entendido, aprendido y usado por los usuarios bajo condiciones específicas.
(Alfonzo & Mariño, 2013)

Figura 2.7. – Características de la usabilidad (Alfonzo & Mariño, 2013)

Según Moreno y Sánchez (2003) la usabilidad de los sistemas software se suele evaluar sobre el
sistema finalizado, intentando asignar valores a los atributos de usabilidad clásicos:
 Aprendizaje: rapidez y facilidad con las que los usuarios pueden realizar trabajo
productivo con un sistema que no conocen, junto con la facilidad con la que se recuerda
la forma en la que se debe operar con el sistema.

29
  Eficiencia en el uso: el número de tareas por unidad de tiempo que el usuario puede
realizar con el sistema.
 Fiabilidad: también llamada “fiabilidad en el uso”, se refiere al porcentaje de errores
cometidos por el usuario en el uso del sistema y el tiempo que se tarda en recuperarse de
estos errores.
Mascheroni, Greiner, Depozo & Estayno (2013) explican, la medición de la usabilidad de una
aplicación es un proceso que lleva tiempo y en muchos casos resulta muy costosa. Por ello, la
mayoría de los desarrolladores de software no la abordan con la profundidad requerida, y en el
peor de los casos, ni siquiera la tienen en cuenta. Los resultados indican que si bien las empresas
no desconocen la importancia de la usabilidad en la calidad del software, las prácticas
promovidas por la IU no se encuentran incorporadas en la mayoría de los procesos de
desarrollo.

c. Disponibilidad

La disponibilidad de un sistema es la probabilidad de que el sistema esté en disposición de

funcionar para proporcionar los servicios a los usuarios que lo soliciten. La disponibilidad y
fiabilidad de un sistema son propiedades que están estrechamente relacionadas y que pueden
expresarse como probabilidades numéricas. Si bien estas dos propiedades guardan una estrecha
relación, no se puede deducir que los sistemas fiables estarán siempre disponibles y viceversa.
Una diferencia adicional entre estas características es que la disponibilidad no depende
simplemente del sistema en sí, sino también del tiempo necesario para reparar los defectos que
hicieron que el sistema dejara de estar disponible. Por ello, si un sistema A falla una vez al año,
y un sistema B falla una vez al mes, entonces A claramente es más fiable que B. Sin embargo, si
el sistema A tarda tres días en recuperarse después de un fallo, y B tarda 10 minutos en
reinicializarse. La disponibilidad de B a lo largo del año es mucho mejor que la del sistema A.
(Sommerville, 2005)
Guzman (2018) explica, la disponibilidad es una de las características de las arquitecturas
empresariales que mide el grado con el que los recursos del sistema están disponibles para su uso
por el usuario final a lo largo de un tiempo dado. Ésta no sólo se relaciona con la prevención de
caídas del sistema (también llamadas tiempos fuera de línea, downtime u offline), sino incluso
con la percepción de “caída” desde el punto de vista del usuario: cualquier circunstancia que nos
impida trabajar productivamente con el sistema desde tiempos de respuesta prolongados, escasa
asistencia técnica o falta de estaciones de trabajo disponibles es considerada como un factor de
baja disponibilidad. Las bases de datos y el auge de Internet han permitido la colaboración y el
intercambio de información desde cualquier parte del mundo, ampliando el alcance de las
aplicaciones de bases de datos en todas las organizaciones y comunidades. Ahora bien, si bien es

30
cierto que la redundancia asegura un alto grado de la disponibilidad de los sistemas, también es
cierto que debido a los altos costos en los que se incurriría por la duplicación de cada una de las
partes sería conveniente primeramente definir los requerimientos de disponibilidad, el tiempo
tolerante a fallos o los períodos sin operación del sistema aceptados.

d. Mantenibilidad

La mantenibilidad es la facilidad con la que un sistema de software puede ser modificado y es un

atributo que afecta de manera crucial al costo de desarrollo del mismo. La literatura muestra
estudios sobre mantenibilidad y la alteración de este parámetro cuando los programas
evolucionan. En la actualidad las empresas han estado demandado sistemas de software que sean
apegados a la mayoría de los requerimientos de los usuarios y a los estándares de calidad, esto ha
incrementado el tamaño de los sistemas de software y su complejidad. Este hecho hace que los
sistemas se vuelvan difíciles de mantener y por ende incrementar costos. En la actualidad las
empresas han estado demandado sistemas de software que sean apegados a la mayoría de los
requerimientos de los usuarios y a los estándares de calidad, esto ha incrementado el tamaño de
los sistemas de software y su complejidad. Este hecho hace que los sistemas se vuelvan difíciles
de mantener y por ende incrementar costos. En esta dirección, es de suma importancia dirigir los
esfuerzos en la formación de estudiantes universitarios cuyo rol será el de desarrolladores de
software. De forma que al concluir los estudios los ingenieros de software sean capaces de realizar
sistemas de software o programas informáticos de calidad bajo estrictas metodologías y siguiendo
estándares que intentan minimizar la probabilidad de presentar defectos. Estos lineamientos se
deben seguir en todas las etapas de desarrollo de software (ingeniería de requerimientos, diseño,
programación, pruebas, etc.). Por lo que el objetivo del ingeniero de software es producir
programas funcionales (que hagan lo que se supone deben hacer), correctos (sin defectos) y
mantenibles (susceptibles de evolucionar ante los cambios manteniendo las dos cualidades
anteriores) y que cumplan con los más altos estándares de calidad en programación [3]. No es
suficiente que el programa sea funcional de acuerdo con el objetivo por el que fue creado, sino
que debe cumplir con una serie de características que lo hagan claro, entendible, flexible y
susceptible de ser mantenido. De acuerdo con Rikard y Coleman, la mantenibilidad es uno de los
atributos más importantes del software. (Pérez-Gonzáles, Martínez, Nava, Núñez, Vázquez &
Flores, 2015)
Según Rodríguez, Pedreira y Fernández (2015), la calidad del software está adquiriendo durante
los últimos años una gran importancia, principalmente debido a que el software está presente en
prácticamente todo lo que nos rodea y se hace necesario asegurar su correcto funcionamiento. Sin
embargo, hasta ahora la mayor parte de los estudios se han centrado en evaluar la calidad de los
procesos de desarrollo, y aunque existen trabajos centrados en la calidad del producto software,

31
no existe todavía una propuesta completa para la evaluación y certificación de la calidad del
producto software, basada en la nueva familia de normas ISO/IEC 25000.
En la siguiente figura se muestran las características de la mantenibilidad según el estándar
ISO9126-1.

Figura 2.8. – Características de la mantenibilidad. (Alfonzo & Mariño, 2013)

2.3. Glosario de términos

 Programas Sociales: Los programas sociales (desde la perspectiva de las políticas públicas de
lucha contra la pobreza) son estrategias que tienen el estado para aliviar las carencias o
reforzar capacidades clave de una determinada población. Respecto a la estrategia de alivio
contra la pobreza los programas sociales proveen bienes y servicios a las poblaciones más
pobres y vulnerables, mientras que como estrategia de reforzamiento de capacidades
fomentan la acumulación de capital humano a fin de mejorar su desempeño económico y
social. (Quispe, 2017)
 Comedores Populares: Los comedores populares son unidades económicas de servicios de
preparación y expendio de alimentos, que aportan a la reducción de los costos del consumo
alimentario de sus usuarios a partir de cuatro elementos: 1) la compra de alimentos y
materiales a mayor escala, 2) la captación de subsidios del Estado sea en alimentos y/o en
dinero, 3) el subsidio de fuerza de trabajo por parte de las mujeres organizadas, y 4) la lógica
de subsistencia que rige su funcionamiento, la cual se dirige exclusivamente a reponer los
factores de producción no subsidiados. (Angulo, 2009)
 Libro Padrón o Padrón de Beneficiarios: Documento de control en el cual constan el nombre,
actividad, domicilio, fecha de admisión de los integrantes, llamados beneficiarios, de un
comedor popular, así como el cargo dirigencial en el caso de aquellas personas que ejerzan
alguno. (Decreto Supremo N° 041-2002-PCM el Reglamento de la ley Nº 25307)
 Kardex: Documento que lleva el registro de los movimientos de cada unidad de un almacén,
su valor de compra, la fecha de adquisición, el valor de salida de cada unidad y la fecha en la

32
 que se retira del inventario. (Távara, 2014) En el caso de la Municipalidad Provincial del
Callao, también lleva el registro de un documento de entrada o salida y su número distintivo.
 Framework Yii: Es un marco de trabajo de desarrollo de aplicaciones de alto desempeño
escrito en PHP. Ayuda a construir aplicaciones web de pequeña a gran escala. (Makarov,
2011)
 Patrón Modelo-Vista-Controlador: Es una paradigma que divide las partes que conforman
una aplicación en el Modelo, las Vistas y los Controladores, permitiendo una implementación
por separado de cada elemento, garantizando así la actualización y mantenimiento del
software de forma sencilla y reduciendo espacio de tiempo.

33
 CAPÍTULO III: VARIABLES E HIPÓTESIS

3.1. Variables e Indicadores

a. Identificación de Variables
 Variable Independiente:
V1: Aplicación web.
 Variable Dependiente:
V2: Gestión de la información de los Programas Sociales en la Municipalidad
Provincial del Callao.
b. Operacionalización de Variables
 Indicadores Variable Independiente
 Nivel de efectividad.
 Nivel de mantenibilidad.
 Nivel de usabilidad.
 Nivel de disponibilidad.
 Indicadores Variable Dependiente:
 Volumen de la datos manejada.
 Cantidad de errores en la información manejada.
 Cantidad de registros manipulados o modificados.
 Porcentaje de información categorizada en relación al tiempo previo a la
implementación del sistema.
3.2. Hipótesis

Hipótesis General

La aplicación web influye significativamente en la gestión de la información en la Municipalidad

Provincial del Callao.

Hipótesis Específicas

 El nivel de efectividad de la aplicación web influye significativamente en la gestión de la

información de los Programas Sociales en la Municipalidad Provincial del Callao.
 El nivel de mantenibilidad de la aplicación web influye significativamente en la gestión de la
información de los Programas Sociales en la Municipalidad Provincial del Callao.
 El nivel de usabilidad de la aplicación web influye significativamente en la gestión de la
información de los Programas Sociales en la Municipalidad Provincial del Callao.
 El nivel de disponibilidad de la aplicación web influye significativamente en la gestión de la
información de los Programas Sociales en la Municipalidad Provincial del Callao.

34
 CAPÍTULO IV: METODOLOGÍA PARA EL DESARROLLO DE LA
INVESTIGACIÓN

4.1. Adaptación de la metodología AUP

Al igual que RUP, el proceso de desarrollo con AUP está compuesto por las cuatro fases: Inicio,
Elaboración Construcción y Transición; sin embargo AUP agrupa las diferentes disciplinas para
agilizar el proceso de desarrollo. A continuación se hace mención de las fases de desarrollo para
AUP (Fernández & Cardeli, 2014).

 Fase de Inicio: donde se identifican los principales casos de uso y requerimientos. Se

concreta la idea, la visión del producto, cómo se enmarca en el negocio, y su alcance.

 Fase de elaboración: Se completan los casos de uso. Se planifican las actividades necesarias
y los recursos requeridos, especificando las características y el diseño de la arquitectura. En
esta etapa el objetivo es determinar la arquitectura óptima.

 Fase de construcción: Se basa en la elaboración de un producto totalmente operativo y en la

elaboración del manual de usuario. Construir el producto de acuerdo a la arquitectura hasta
que el producto está listo para ser enviado a la comunidad de usuarios. En esta etapa el
objetivo es llevar a obtener la capacidad operacional inicial.

 Fase de transición: El objetivo es llegar a obtener el despliegue del proyecto. Se realiza la

instalación del producto en el cliente y se procede al entrenamiento de los usuarios.

Lisana (2014) describe las disciplinas de AUP de la siguiente manera.

 Modelado: El objetivo es entender la organización, definir el problema y las necesidades del
usuario para identificar la mejor solución.
 Implementación: El objetivo es transformar el modelo en código ejecutable y realizar el
nivel básico de pruebas, particularmente pruebas unitarias.
 Pruebas: El objetivo es encontrar defectos, para validar que el sistema trabaja como lo
planificado y satisface los requerimientos del sistema.
 Despliegue: El objetivo es integrar el sistema en la organización del usuario.
 Gestión de configuración: El objetivo es configurar el acceso al proyecto. Esto incluye hacer
un versionado y gestionar los cambios en el proyecto.
 Gestión de proyecto: Incluye gestión de riesgos, dirigir al personal y coordinar con personas
y sistemas fuera del enfoque del proyecto para asegurar que se entregue en el tiempo debido.
 Entorno: El objetivo es establecer herramientas adecuadas para asegurar el éxito del proceso
de desarrollo.

35
La elección de los artefactos se realizó tomando en cuenta la presentación de la documentación
para futuras auditorías a la Gerencia de Informática de la Municipalidad Provincial del Callao, así
como artefactos útiles que ayuden a establecer la mantenibilidad del sistema desarrollado. En la
tabla 4.1 se muestra cuáles son los artefactos mencionados.

Fases
Inicio Elaboración Construcción Transición
 Modelo de  Casos de uso del  Modelo de
casos de uso de sistema base de datos
negocio  Especificaciones
 Diagrama de de caso de uso
Modelado
actividades de de sistema
negocio
 Matriz de
requerimientos
 Código fuente
Disciplinas

Implementació
n
Pruebas
 Arquitectura de  Diagrama de  Producto
la aplicación componentes
Despliegue
 Diagrama de
despliegue
Gestión de la
configuración
Gestión de
proyecto
Entorno
Tabla 4.1. – Adaptación de la metodología AUP. Fuente: Elaboración propia.

36
 FASE DE INICIO
Disciplina Artefacto Descripción
Representa la vista general de los requerimientos
Modelo de casos de uso
Modelado funcionales del sistema, además presenta los
de negocio
interesados principales. (Ambler, 2010)
Describe la lógica de actividades de las reglas de
negocio, este artefacto puede considerarse el
Diagrama de actividades equivalente a los diagramas de flujo y diagramas
Modelado
de negocio de flujo de datos (Ambler, 2010). Este artefacto es
representado específicamente al flujo de negocio
actual, previo a la implementación del sistema.
Describe la funcionabilidad que debe tener el
sistema así como también con aspectos técnicos
Modelado Matriz de requerimientos
como desempeño, confiabilidad y disponibilidad.
(Ambler, 2010)
Tabla 4.2. – Artefactos de la fase de inicio. Fuente: Elaboración propia.

FASE DE ELABORACIÓN

Disciplina Artefacto Descripción

Representa la vista general la funcionabilidad
Diagrama de casos de uso de
Modelado del sistema en base a los requerimientos
sistema
identificados.
Especificaciones de casos de Describe de manera textual los detalles de los
Modelado
uso de negocio casos de uso identificados.
La arquitectura provee la base en la que los
sistemas son construidos y el diagrama de
arquitectura define la visión en la cual la
Despliegue Arquitectura de la aplicación
arquitectura está basada. El enfoque de la
arquitectura puede ser una sola aplicación o una
familia de aplicaciones. (Ambler, 2010)

Tabla 4.3. – Artefactos de la fase de elaboración. Fuente: Elaboración propia.

FASE DE CONSTRUCCIÓN
Disciplina Artefacto Descripción
Los modelos de datos son utilizados para diseñar
los esquemas internos de la base de datos,
Modelado Modelo de base de datos representando tablas de datos, columnas de datos
dentro de las tablas y las relaciones entre las
tablas. (Ambler, 2010)
Constituye las líneas de código desarrolladas a lo
Implementación Código fuente largo del proyecto y después de ser
implementado.
Permiten modelar componentes software de alto
nivel y las interfaces para esos componentes.
Despliegue Diagrama de componentes Además pueden reflejar la evolución de los
nuevos requerimientos o cambios en los procesos
del proyecto. (Ambler, 2010)

37
 Los diagramas de despliegue muestra el
hardware del sistema, el software instalado en el
hardware y el middleware usado para conectar
Despliegue Diagrama de despliegue las maquinas unas de otras. Se debería utilizar
este diagrama para aplicaciones que están
desplegadas en diferentes máquinas. (Ambler,
2010)
Tabla 4.4. – Artefactos de la fase de construcción. Fuente: Elaboración propia.

FASE DE TRANSICIÓN

Disciplina Artefacto Descripción

Aplicación web desplegada y lista para que el
Despliegue Producto
usuario acceda.

Tabla 4.5. – Artefactos de la fase de transición. Fuente: Elaboración propia.

Además se considera artefactos de mantenimiento del sistema como solicitudes de cambios o
mejoras por parte de los usuarios y sus respectivas actas de conformidad.
4.2. Iteraciones

Las iteraciones representan un proceso de actividades necesarias para el desarrollo del producto.
La tabla 4.6 muestra la cantidad de iteraciones que se realizan por fase en el desarrollo del
proyecto parte de los usuarios y sus respectivas actas de conformidad.

Inicio Elaboración Construcción Transición

Iteración preliminar
I1 I2 I3 I4 I5 I6
(I0)

Tabla 4.6. – Iteraciones por fase. Fuente: Elaboración propia.

La tabla 4.7 describe en detalle cada iteración establecida. Como se puede observar se hace un
desarrollo de prototipos incremental de forma iterativa, donde en cada presentación se aumenta
el módulo que ha sido desarrollado.

Fase Iteración Descripción

Proceso de establecimiento de la visión del
proyecto y análisis de alcance y objetivos.
Inicio Iteración preliminar (I0) También se realiza el análisis de negocio. Finaliza
con el establecimiento de los requerimientos del
sistema.
Proceso de análisis y diseño del desarrollo del
Elaboración I1 sistema. Finaliza con la reunión de presentación de
los prototipos de interface.
Proceso de implementación de la base de datos. Se
realiza el desarrollo del módulo de gestión de
Construcción I2
solicitudes. Finaliza con la reunión de
presentación del módulo de gestión de solicitudes.
Proceso donde se corrigen las observaciones y se
Construcción I3 realiza el aumento de funcionalidades derivadas
de la presentación el módulo de gestión de

38
 solicitudes. Se desarrolla el módulo de control de
entregas de raciones alimentarias. Finaliza con la
reunión de presentación del módulo de entrega de
raciones alimentarias.
Proceso donde se corrigen las observaciones y se
realiza el aumento de funcionalidades derivadas
de la presentación el módulo de gestión de
solicitudes y control de entregas. Se desarrolla el
Construcción I4
módulo de control de almacén, reportes y
mantenimiento. Finaliza con la reunión de
presentación de los módulos de control de
almacén, reportes y mantenimiento.
Proceso donde se realizan las pruebas de
validación por parte de los usuarios finales.
Construcción I5
Finaliza con la corrección final de observaciones
y la preparación para la puesta en producción
Proceso de puesta en producción del sistema.
Transición I6 Finaliza con la realización del informe de
metodología de desarrollo del sistema.
Tabla 4.7. – Detalle de las iteraciones. Fuente: Elaboración propia.
Al final cada fase existe un hito donde se evalúa las iteraciones realizadas. En la tabla 4.8 se
muestran los hitos posteriores a cada iteración y la actividad que lo representa.

Hitos
Iteración Preliminar (I0)
Reunión de establecimiento del proyecto. Presentación del documento de visión y
requerimientos para el desarrollo del sistema. Preparación de las herramientas para el diseño
del sistema.
I1 – Inicio y Fin.
Reunión de presentación de los prototipos de interface y preparación de las herramientas para
el desarrollo del sistema y levantamiento de la base de datos.
I2 – Inicio y Fin.
I3 – Inicio y Fin.
I4 – Inicio y Fin.
I5 – Inicio y Fin.
Finalización de las pruebas de validación por parte del usuario y reunión para dar pase a
producción al sistema.
I6 – Inicio y Fin
Presentación del informe de metodología de desarrollo del sistema.
Tabla 4.8. – Hitos. Fuente: Elaboración propia.
La tablas 4.9, 4.10, 4.11, 4.12, 4.13, 4.14 y 4.15 muestran las tareas y/u objetivos más importantes
realizadas por cada iteración.

Iteración Preliminar (I0) – Objetivos/Tareas

Reunión de inicio del proyecto.
Establecer la visión del proyecto.
Establecer los casos de uso de negocio.
Análisis del flujo de trabajo del Programa de Comedor del Pueblo (Diagrama de actividades)
Realizar la matriz de requerimientos funcionales y no funcionales.

39
Preparar las herramientas para continuar con el análisis y el diseño del sistema.
Tabla 4.9. – Actividades y objetivo (I0). Fuente: Elaboración propia.

I1 – Objetivos/Tareas
Establecer los casos de uso del sistema.
Desarrollar los prototipos de interfaces del sistema.
Establecer los estados de los objetos.
Definir la arquitectura para el desarrollo del sistema.
Reunión de presentación de prototipos de interfaces del sistema.
Preparación de las herramientas para el desarrollo del sistema (levantamiento del servidor de
desarrollo y el servidor de base de datos, y preparación del entorno de desarrollo).
Tabla 4.10. – Actividades y objetivo (I1). Fuente: Elaboración propia.

I2 – Objetivos/Tareas
Modelar la base de datos.
Realizar el levantamiento de la base de datos.
Levantamiento de la arquitectura del sistema y configuración inicial.
Generar los modelos del sistema.
Generación del módulo de gestión de solicitudes.
Codificación de las vistas y controladores del módulo de gestión de solicitudes.
Realizar el levantamiento de la configuración, avance y versionado en el repositorio del
proyecto.
Realizar los diagramas de componentes correspondientes al módulo.
Pruebas unitarias del módulo de gestión de solicitudes.
Reunión de presentación del sistema integrando el módulo de gestión de solicitudes.
Realizar la matriz de observaciones y nuevos requerimientos.
Tabla 4.11. – Actividades y objetivo (I2). Fuente: Elaboración propia.

I3 – Objetivos/Tareas
Levantamiento de observaciones y nuevos requerimientos.
Generación del módulo de control de entregas.
Codificación de las vistas y controladores para el control de entregas del padrón de
beneficiarios.
Codificación de las vistas y controladores para el control de entregas del padrón a transeúntes.
Realizar el levantamiento de la configuración, avance y versionado en el repositorio del
proyecto.
Realizar los diagramas de componentes correspondientes al módulo.
Pruebas unitarias del módulo de control de entregas.
Reunión de presentación del sistema integrando el módulo de control de entregas.
Realizar la matriz de observaciones y nuevos requerimientos.
Tabla 4.12. – Actividades y objetivo (I3). Fuente: Elaboración propia.

I4 – Objetivos/Tareas
Levantamiento de observaciones y nuevos requerimientos.
Generación del módulo de control de almacén, reportes y mantenimiento.
Codificación de las vistas y controladores del control del módulo de almacén.
Codificación de las vistas y controladores del control del módulo de reportes.
Codificación de las vistas y controladores del módulo de mantenimiento.

40
 Codificación de las vistas y controladores para mostrar gráficos estadísticos en el módulo de
inicio. El módulo de inicio es generado automáticamente con el levantamiento de la
arquitectura, junto con el módulo de login.
Realizar el levantamiento de la configuración, avance y versionado en el repositorio del
proyecto.
Realizar los diagramas de componentes correspondientes al módulo.
Pruebas unitarias del módulo de control del almacén, reportes y mantenimiento.
Reunión de presentación del sistema integrando el módulo de control del almacén, reportes y
mantenimiento
Realizar la matriz de observaciones y nuevos requerimientos.
Tabla 4.13. – Actividades y objetivo (I4). Fuente: Elaboración propia.

I5 – Objetivos/Tareas
Levantamiento de observaciones y nuevos requerimientos.
Creación de usuarios y accesos en ambiente pre producción.
Levantamiento del sistema en ambiente pre producción.
Inicio de las pruebas de validación de los usuarios.
Levantamiento final de observaciones
Realizar el diagrama de despliegue
Realizar el levantamiento de la configuración y versionado en el repositorio del proyecto.
Realizar los diagramas de componentes correspondientes al módulo.
Reunión de pase a producción.
Tabla 4.14. – Actividades y objetivo (I5). Fuente: Elaboración propia.

I6 – Objetivos/Tareas
Creación de usuarios y accesos en ambiente producción.
Puesta del sistema en ambiente de producción.
Instalación de accesos al sistema en los ordenadores de los usuarios.
Realización del acta de conformidad del sistema.
Liberación de los módulos del sistema.
Realización del informe de metodología de desarrollo del sistema.
Tabla 4.15. – Actividades y objetivo (I6). Fuente: Elaboración propia.
Las solicitudes de mejoras, arreglos o nuevas funcionalidades al sistema son parte del proceso de
mantenimiento del sistema. Estas actividades son analizadas, diseñadas y desarrolladas en
iteraciones a futuro, de esta manera en siguiendo la fase de transición se realizan iteraciones de
manera indefinida de acuerdo a dichas solicitudes.

41
 CAPÍTULO V: SOLUCIÓN TECNOLÓGICA
5.1. Fase de Inicio
El objetivo principal de la fase de iniciación es definir el enfoque de la aplicación y establecer los
casos de negocio que justifiquen el pase a desarrollo del proyecto. Se presentan los artefactos que
dan respuesta a la fase de Iniciación.
a. Modelo de casos de uso de negocio
El diagrama de casos de uso de negocio describe a grandes rasgos las personas que participan en
el flujo de trabajo del negocio y engloba las actividades que se realizan en los denominados casos
de uso. Así mismo, se planea las metas de negocio que se desea alcanzar con el desarrollo del
proyecto.
Casos de uso de negocio

La tabla 5.1 describe los casos de usos de negocio identificados.

CASO DE USO DE NEGOCIO BREVE DESCRIPCIÓN

CUN01 El proceso inicia cuando un ciudadano realiza presenta

una solicitud en el área de trámite documentario para
pertenecer al padrón de beneficiarios. La solicitud
genera un expediente que es enviado a la Gerencia
General de Programas Sociales.

CUN02 El proceso corresponde a la realización de una

evaluación de las personas que desean ser beneficiarios.
Un evaluador se acerca a la vivienda del titular con un
formato generado a partir del expediente presentado. Si
no se realiza la primera evaluación, se programa una
segunda. Finalmente la solicitud es rechazada o
aprobada.

CUN03 Se realiza la entrega de raciones alimentarias a los

titulares según corresponda. Las raciones alimentarias
sobrantes son entregadas a otras personas que las
necesiten. Se realiza la firma del registro de asistencia
que es entregada a los coordinadores.

CUN04 Proceso de ingreso y salida de productos del almacén y

llenado del formato kárdex presentado para la emisión
de reportes.

Tabla 5.1. – Casos de uso de negocio. Fuente: Elaboración propia.

42
Actores de negocio
La tabla 5.2 describe los actores de negocio identificados.

ACTOR TIPO DESCRIPCIÓN

Persona que presenta una solicitud para formar

Actor de parte del padrón de beneficiarios del comedor
negocio popular.

Actor de Empresa encargada de brindar productos al

negocio almacén general del comedor popular.

Personal que recepciona la solicitud del

Trabajador ciudadano y la deriva a la Gerencia General de
de negocio Programas Sociales

Personal encargado de gestionar el padrón de

beneficiarios y coordinar con verificadores y
Trabajador beneficiarios, también controla la asistencia al
de negocio comedor popular y recibe la información del
almacén.

Personal encargado de evaluar a los beneficiarios

Trabajador en su vivienda actual y entregar la información
de negocio recolectada de estos.

Personal encargado de entregar las raciones

Trabajador alimentarias, envía un listado de la asistencia de
de negocio los titulares y los transeúntes atendidos.

Recepciona los productos y los ingresa al

Trabajador almacén, también realiza los retiros del almacén
de negocio y llena los formatos de kárdex.

Tabla 5.2. – Actores de negocio. Fuente: Elaboración propia.

43
Diagramas de casos de uso de negocio
La siguiente figura presenta el diagrama de casos de uso de negocio con los casos de uso asignados
a cada actor o trabajador correspondiente.

Figura 5.1. – Diagrama de casos de uso de negocio. Fuente: Elaboración propia.

b. Diagrama de actividades de negocio
El diagrama de actividades muestra secuencia de acciones que se realizan en el negocio. Para el
desarrollo de la aplicación en cuestión se identificaron dos procesos, donde la Gerencia General
de Programas Sociales necesita gestionar su información. El primer proceso corresponde a la
gestión del padrón de beneficiarios donde se recopila, verifica y clasifica la información que
proveen las personas que son beneficiarios para mantener actualizado el padrón del comedor
popular. El segundo proceso se refiere a cómo se realizan los movimientos del almacén central
del comedor popular.
CUN01 Gestionar solicitudes
El proceso inicia cuando el ciudadano que desea ser un beneficiario ingresa al área de trámite
documentario, la persona tiene que entregar una solicitud para pertenecer al padrón de
beneficiarios junto información adicional sobre su asistencia previa al comedor del pueblo como
transeúnte. El personal de trámite documentario recepciona la solicitud y generado un expediente,
una vez generado el expediente se envía a la Gerencia General de Programas Sociales. El
expediente es recepcionado por un personal de secretaria o un administrativo en la Gerencia
General de Programas Sociales donde se verifica y es derivado a un coordinador. Las actividades
descritas son previas a las actividades que abarcan la aplicación que se desarrolla, sin embargo
corresponden a información que necesita el coordinador encargado, estas actividades se realizan
en el Sistema de Gestión Documentaria (GESDOC) que cuenta la Municipalidad Provincial del
Callo, en la figura 5.2 se observa la representación en el diagrama de actividades.

44
 Figura 5.2. – Diagrama de actividades de negocio para el proceso de gestión de solicitudes,
primera parte. Fuente: Elaboración propia.
El expediente es enviado a un coordinador que verificará los datos del expediente y preparará una
ficha de datos enumerada para realizar la evaluación.

Figura 5.3. – Diagrama de actividades de negocio para el proceso de gestión de solicitudes,

segunda parte. Fuente: Elaboración propia.

45
CUN02 Evaluación de beneficiarios
El expediente con la información del ciudadano solicitante (titular) es recepcionado por el
coordinador, este verifica la información del solicitante y genera un número correlativo para una
ficha de datos y un acta de supervisión nueva para el solicitante, el coordinador establece una
fecha con el titular para realizar un proceso de supervisión. Un verificador es enviado con los
documentos generados, en la supervisión se entrevistará a las personas que serán beneficiarios
pudiendo ser familiares del titular o, en caso sea una organización como un albergue, orfanato o
instituto educativo, los miembros de la tal organización; asimismo, se toman datos del lugar de
residencia. En caso de que no se realice la supervisión en la fecha establecida se coordina una
segunda supervisión, si no es realizada la segunda supervisión la solicitud es rechazada y el
coordinador emite un informe al titular. Si el proceso de supervisión es realizado correctamente
y las personas reúnen las condiciones para ser beneficiarios la solicitud es aprobada; sin embargo,
si la Gerencia de Comedor Popular no cuenta con la capacidad necesaria de raciones alimentarias
diarias necesarias para todos los beneficiarios que conforman la ficha presentada, la solicitud
quedará un estado de suspensión hasta que se cuente con dicha capacidad. Una vez aprobados el
titular podrá recoger las raciones alimentarias de sus beneficiarios en el comedor del pueblo.

Figura 5.4. – Diagrama de actividades de negocio para el proceso de evaluación de

beneficiarios. Fuente: Elaboración propia.

46
CUN03 Controlar asistencia
Se cuenta con un personal a cargo de llevar el registro de asistencia de los titulares. Si un titular
falta tres o más veces seguidas en un mes podrá ser retirado del padrón por inasistencia, además
el titular puede informar sobre el retiro de uno o todos los beneficiarios. Las raciones alimentarias
sobrantes en el día serán entregadas a personas que las necesiten y no conforme el padrón de
beneficiarios (transeúntes).
Finalmente los coordinadores son los encargados de emitir reportes respecto a la composición del
padrón de beneficiarios y las raciones alimentarias entregadas a los titulares y transeúntes de
manera trimestral.

Figura 5.5. – Diagrama de actividades de negocio para el proceso de evaluación de

beneficiarios. Fuente: Elaboración propia.
CUN04 Controlar el almacén
En el proceso de control del almacén el chef jefe que se encarga de ingresar los productos de los
proveedores en el almacén general, al ingresar los productos se llena un formato de kárdex de
acuerdo a una guía de entrada provista por la Gerencia General de Programas Sociales. Una vez
llenado el formato es entregado a un coordinador, el cual lo archiva. De igual manera si el chef
jefe desea retirar productos del almacén deberá llenar un kardex y enviarlo a un coordinador. Los
kardex son utilizados finalmente para emitir informes de los movimientos en el almacén y
establecer el estado general del almacén. Sin embargo estas actividades pueden ser optimizadas
y el presente trabajo propone una mejora en el proceso. En la figura 5.6 se describe este proceso
en el diagrama de actividades de negocio.

47
 Figura 5.6. – Diagrama de actividades de negocio para el proceso de controlar el almacén.
Fuente: Elaboración propia.

Para la mejora del proceso de control del almacén se contará un nuevo personal de acuerdo al
principio de segregación de funciones. De esta manera el personal responsable (el chef jefe) ya
no se encarga de realizar los movimientos en el almacén, sino se contará con un almacenero
encargado de estas funciones. Así mismo, de igual manera que la Gerencia General de Programas
Sociales realiza documentos como las guías de entradas que establecen el proceso para ingresar
productos en el almacén, se debe establecer documentos de guía para la salida de productos en el
almacén (Ver punto 1 en la figura 5.7). En la figura 5.7 se describe el proceso mejorado en el
diagrama de actividades.

Figura 5.7. – Diagrama de actividades de negocio para el proceso de controlar el almacén

mejorado. Fuente: Elaboración propia.

48
c. Matriz de requerimientos
En base a la reunión inicial se definen los requerimientos de acuerdo a los casos de uso. En la
tabla 5.3 se muestra la matriz de acuerdo con los requerimientos funcionales establecidos.
Actividad
Actor de
Proceso de negocio Requerimiento funcional Caso de uso Actor
negocio
a mejorar
Verificar RF01: La aplicación permitirá el
información registro de la solicitud y generar CUS01: Registrar
CUN01 Coordinador Coordinador
del un número de ficha Solicitud
solicitante correspondiente
Verificar
información
del
solicitante
(CUN01) RF02: La aplicación verificará
CUN01
Llena la la información de las personas CUS03: Buscar
CUN02 Coordinador Coordinador
ficha de mediante el ingreso de su Persona
CUN03
datos número de documento.
(CUN02)
Indica datos
personales
(CUN03)
RF02: La aplicación permitirá
registrar la información de las
evaluaciones a los beneficiarios.
Las evaluaciones contienen
Llenar ficha CUS02: Gestionar
CUN02 Verificador información importante sobre la Coordinador
de datos Solicitudes
composición familiar de los
titulares que formarán parte del
padrón de beneficiarios y sobre
sus condiciones de vivienda.
RF03: La aplicación permitirá
cambiar de estado las fichas y
Emitir carta beneficiarios, así como generar
de rechazo los documentos respectivos
de solicitud. sobre el cambio.
Emitir carta Al cambiar de estado una ficha
CUS02: Gestionar
CUN02 de Coordinador registrada (Pre aprobada, Coordinador
Solicitudes
aprobación. aprobada, desaprobada o retirada)
Emitir carta o un beneficiario (Activo o
de pre retirado), se ingresarán
aprobación información necesaria para
generar documentos que serán
entregados.

49
 Una ficha no podrá ser aprobada si
no se cuenta con raciones que se
necesitan para entregar a todos los
beneficiarios que la conforman.
RF04: La aplicación permitirá
registrar la información del acta
Recibe acta
de supervisión. CUS02: Gestionar
CUN02 de Verificador Coordinador
Se registra información sobre Solicitudes
supervisión
observaciones y la persona que
evaluó la solicitud.
Personal RF06: La aplicación permitirá
Entrega encargado registrar las entregas de
CUS04: Registrar
CUN03 raciones de entregar raciones diarias de las personas Coordinador
entregas padrón
alimentarias raciones que pertenezcan al padrón de
alimentarias beneficiarios.
RF07: La aplicación permitirá
registrar la información de los
transeúntes a los que se les
entregue una ración diaria.
CUS05: Registrar
Indica datos El registro de transeúntes se
CUN03 Ciudadano transeúntes Coordinador
personales realiza de acuerdo a la cantidad de
raciones sobrantes en el día y la
información personal es validada
de igual manera que un
beneficiario.
RF09: La aplicación permitirá
registrar los cambios en el
Ingresa
almacén.
productos. CUS07: Gestionar
CUN04 Chef Jefe Los cambios en el almacén serán Almacenero
Retira Kárdex
validados de acuerdo al stock que
productos.
se cuente del producto que se está
registrando el movimiento.
RF10: La aplicación permitirá
registrar y actualizar la
información de los productos
Llena CUS6: Mantener
CUN04 Chef Jefe que se encuentren en el almacén. Almacenero
kárdex Productos
No se podrán realizar cambios
directos en el stock del producto
registrado.
RF11: La aplicación permitirá
Emite
CUN03 generar reportes de acuerdo a la CUS08: Emitir
reportes/ Coordinador Coordinador
CUN04 información ingresada en los Reportes
informes
diferentes módulos.
REQUERIMIENTOS ADICIONALES

50
 Descripción Caso de uso
RA01: La aplicación permitirá adjuntar copias digitales de los
CUS09: Adjuntar documento
documentos físicos generados por el personal.
RA02: La aplicación permitirá a los usuarios registrar ítems de
información manejada por el persona, por ejemplo: grupos de CUS10: Mantenimiento
beneficiarios, tipos de documento, parentescos, seguros, etc.

Tabla 5.3. – Matriz de requerimientos funcionales. Fuente: Elaboración propia.

Asimismo, se establecieron ciertos requerimientos no funcionales que se establecieron para los

aplicación de información gerenciales, en la tabla 5.4 se muestra cuáles son.

REQUERIMIENTOS NO FUNCIONALES

N° Descripción

Los permisos de acceso la aplicación podrán ser cambiados solamente por el personal del
área de desarrollo de la Gerencia de Informática. La gerencia General de Programas
1
Sociales deberá enviar un memo solicitando la creación o cambio de un usuario junto con
los datos de la persona.

2 La aplicación debe contar con manuales de usuario.

3 La aplicación debe proporcionar mensajes de error que sean informativos.

La aplicación web debe poseer un diseño adaptable a fin de garantizar la adecuada

4
visualización en múltiples computadores personales.

5 La aplicación debe poseer interfaces gráficas bien formadas.

Tabla 5.4. – Matriz de requerimientos no funcionales. Fuente: Elaboración propia.

51
5.2 Fase de Elaboración
El objetivo principal de la fase de Elaboración es realizar el diseño del sistema a realizar así como
definir la arquitectura que se va a utilizar para la construcción de la solución tecnológica. A
continuación se presentan los artefactos que dan respuesta a esta fase.
a. Diagrama de casos de uso de sistema
Casos de uso del sistema
La tabla 5.5 describe los casos de uso de sistema identificados.

CASO DE USO DE SISTEMA BREVE DESCRIPCIÓN

CUS01
Permite al usuario realizar el registro de la solicitud
presentada, además se asigna automáticamente un
número de ficha.

CUS02
Permite al usuario gestionar las solicitudes
registradas, cambiar de estado la solicitud, registrar
los datos de la ficha de datos y el acta de supervisión.

CUS03
Permite buscar la información de una persona
ingresando su número de documento.

CUS04
Permite al usuario registrar la asistencia de los
beneficiarios, además se podrá adjuntar copias
digitales de los registros de asistencia.

CUS05

Permite registrar la información de los transeúntes

atendidos.

CUS06

Permite listar, registrar o editar la información de los

productos del almacén. No se podrá editar el stock de
los productos registrados.
Gestionar Productos

CUS07 Permite registrar y visualizar los movimientos del

almacén. Se realiza la actualización automática del

52
 stock de los productos de acuerdo a la información
ingresada.

CUS08
Permite generar reportes de manera rápida utilizando
la información registrada en el sistema.

CUS09

Permite adjuntar copias digitales de los documentos

físicos manejados y se accedidos posteriormente.

CUS10

Permite al registrar o editar ítems de información

manejadas por el personal y la aplicación.

Tabla 5.5. – Casos de uso de sistema. Fuente: Elaboración propia.

Actores del sistema

La tabla 5.6 describe los actores de sistema identificados.

ACTOR DESCRIPCIÓN

Representa de forma general una persona que interactúa con el

sistema.

Personal de la Gerencia de Informática encargado de darle soporte

y mantenimiento al sistema.

Personal encargado de gestionar el padrón de los beneficiarios y el

control de la entrega de raciones alimentarias a estos.

53
 Adquiere las funciones del chef jefe respecto al control del
almacén, se encarga de registrar los movimientos de entrada y
salida en el almacén.

Tabla 5.6. – Actores de sistema. Fuente: Elaboración propia.

Diagrama de casos de uso de sistema

El diagrama de casos de uso de sistema representa las funcionalidades que debe realizar el sistema
englobadas en casos de uso. En la siguiente imagen se muestra los casos de uso de sistema
descritos en la tabla 5.5 y los casos de uso de sistema adicionales no descritos junto con la relación
con los actores de sistema identificados.

Figura 5.8. – Diagrama de casos de uso de sistema. Fuente: Elaboración propia.

54
b. Especificaciones de casos de uso de sistema
Las siguientes tablas corresponden a las especificaciones de casos de uso de sistema para los casos
de uso de sistema establecidos en la tabla 5.5.

Especificación de Caso de Uso de Sistema ECUS01

Caso de Uso
CUS01 Registrar Solicitud
de Sistema
Permite al usuario realizar el registro de la solicitud presentada, además se asigna
Descripción
automáticamente un número de ficha.
1. Flujo de eventos
Paso Acción

1 El caso de uso inicia cuando el coordinador selecciona la opción “Nuevo Registro” en el

menú principal.
La aplicación muestra un formulario para el registro de la solicitud. El formulario contiene
los campos: número de expediente, número de documento, nombres, apellido paterno,
2 apellido materno, género, fecha de nacimiento, departamento, provincia, distrito, tipo de
zona, zona, tipo de vía, vía, número, manzana, lote, tipo de interior, número de interior,
tipo de edificación y referencia.
3 El coordinador ingresa el número de expediente y número de documento.

4 Al ingresar el número de documento, la aplicación mostrará los nombres, apellido paterno,

apellido materno, género y fecha de nacimiento.
5 El coordinador ingresa los datos de la dirección y seleccionará guardar.

6 La aplicación guarda los datos y mostrará la interfaz que contiene la bandeja de solicitudes
registradas.
7 Fin del caso de uso.
2. Flujos alternativos
Ninguno.
3. Excepciones
Ninguna.
4. Pre-condiciones
Tener una sesión iniciada.
5. Post-condiciones
La aplicación guardó los datos de la solicitud y se generó un número de ficha.
6. Prototipos
Tabla 5.7. – ECUS01. Fuente: Elaboración propia.

55
La figura 5.9 corresponde al registro de solicitudes, contiene los campos para ingresar los datos
del titular que presenta la solicitud, los datos del titular son buscados en la base de datos una vez
se ingrese el número de documento de este. Así mismo se ingresan los datos de la dirección de
DNI del titular, estos campos son manejados de manera similar para las aplicaciones gerenciales
desarrollados y son provistos por la Gerencia General de Asentamientos Humanos. La función de
esta interfaz es mantener válida los datos del titular y generar un número correlativo a su solicitud
o número de ficha.

Figura 5.9. – Prototipo de Formulario de Registro de Solicitud. Fuente: Elaboración propia.

Especificación de Caso de Uso de Sistema ECUS02

Caso de Uso
CUS02 Gestionar Solicitudes
de Sistema
Permite al usuario gestionar las solicitudes registradas, cambiar el estado de la
Descripción
solicitud, registrar datos de la ficha de datos y el acta de supervisión
1. Flujo de eventos
Paso Acción
El caso de uso inicia cuando el coordinador selecciona la opción “Bandeja de Solicitudes”
1
en el menú principal.
2 La aplicación muestra una bandeja con las solicitudes registradas en la fecha actual.

3 El coordinador selecciona la opción “Ficha de Datos” en una de las solicitudes.

4 El sistema muestra una interfaz divida en las secciones: Información general, Titular,
Dirección Actual, Vivienda y Composición Familiar.

5 El coordinador ingresa los datos necesarios en la sección de Titular: grado académico,

nacionalidad y estado de salud.
El coordinador ingresa los datos necesarios en la sección Dirección Actual: departamento,
6 provincia, distrito, tipo de zona, zona, tipo de vía, vía, número, manzana, lote, tipo de
interior, número de interior, tipo de edificación y referencia, tipo de vivienda, nombre del
albergue, recibo de agua, luz, teléfono o cable.

56
 7 El coordinador ingresa los datos necesarios en la sección Vivienda: pisos, techos y paredes.
El coordinador ingresa los datos necesarios de los beneficiarios en la sección Composición
8
Familiar e indicará el tipo de pensión y seguro. Posteriormente se seleccionará Guardar.
La aplicación guarda la información ingresada de la ficha de datos y vuelve a la bandeja de
9
solicitudes.
10 Fin del caso de uso
2. Flujos alternativos
2.1 Imprimir
En el paso 3, si el coordinador selecciona la opción “Imprimir”, la aplicación muestra un
documento pdf con la información de la ficha de datos registrada hasta el momento.
2.2. Acta de supervisión
En el paso 3, si el coordinador selecciona la opción “Acta de Supervisión”, la aplicación muestra
un formulario para el registro de los datos del acta de supervisión: fecha, hora, observaciones,
verificador. El coordinador realiza la búsqueda del verificador con su número de DNI, además
puede adjuntar una copia digital del acta de supervisión, una vez llenado los datos selecciona la
opción Guardar y vuelve a la bandeja de solicitudes.
2.3. Estados
En el paso 4, si el coordinador selecciona la opción “Estado”, la aplicación muestra un formulario
con los estados por los cuales ha pasado la solicitud. El coordinador puede ingresar los campos:
estado, número de carta, número de informe y fecha de informe, para cambiar el estado de la
solicitud a aprobado, preaprobado, rechazado o retirado según sea el caso.
2.4. Agregar beneficiario
En el paso 8, si el coordinador selecciona la opción “Agregar Familiar”, la aplicación mostrará un
formulario para ingresar los datos del beneficiario, el coordinador ingresará los datos personales
(Ir a ECUS03), la cantidad de raciones, parentesco y grupo beneficiario. El coordinador
seleccionará la opción “Guardar”, y la aplicación guardará los datos y mostrará el beneficiario
registrado en un listado.
3. Excepciones
3.1. No hay datos encontrados
En el paso 3, si no se ha realizado previamente el registro de la ficha de datos, la aplicación muestra
un formulario para ingresar el grupo beneficiario y raciones correspondientes del titular. Una vez
ingresado estos datos, la aplicación muestra el formulario de Ficha de Datos.
3.2 Cambio de datos
En el flujo 2.3, si se desea cambiar el estado a aprobado y no se cuenta la cantidad de raciones
suficientes, la aplicación muestra un mensaje de error y detiene el cambio de estados
4. Pre-condiciones
Tener una sesión iniciada.
El coordinador debe haber registrado la ficha de datos del solicitante, ver ECUS01.
5. Post-condiciones
La aplicación realizó una transacción y volvió a la bandeja de solicitudes.
6. Prototipos
Tabla 5.8. – ECUS02. Fuente: Elaboración propia.

La figura 5.10 muestra el formulario de ficha de datos, está dividido en pestañas de acuerdo a la
categoría de datos que conforman el formato de ficha entregado por la Gerencia General de
Programas Sociales. La primera pestaña muestra los datos de cabecera de la ficha y un conteo de
los beneficiarios que la conforman de acuerdo al grupo beneficiario al que pertenecen.

57
 Figura 5.10. – Prototipo de formulario de ficha de datos (Información General). Fuente:
Elaboración propia.

La figura 5.11 muestra la pestaña que corresponde a los datos del titular, contiene los datos
ingresados en la solicitud, además se tendrán que ingresar información adicional para continuar
con el registro.

Figura 5.11. – Prototipo de formulario de ficha de datos (Titular). Fuente: Elaboración propia.

La figura 5.12 muestra la pestaña en la que se ingresa la dirección actual, además se determina si
los beneficiarios residen en una vivienda propia, alquilada u otro tipo de vivienda como un
albergue, asimismo se determina si cuentan con luz, agua potable y otros servicios presentando
los recibos de pago respectivos.

58
Figura 5.12. – Prototipo de formulario de ficha de datos (Dirección actual). Fuente: Elaboración
propia.
La figura 5.13 muestra la pestaña en la que se determina las condiciones de la vivienda de acuerdo
a los materiales de construcción de las paredes, pisos y techo.

Figura 5.13. – Prototipo de formulario de ficha de datos (Condiciones de vivienda). Fuente:

Elaboración propia.

La figura 5.14 muestra la última pestaña que contiene los beneficiarios que conforman la ficha,
en una pequeña bandeja se listará los beneficiarios registrados. Se contará con un botón que
mostrará un formulario para buscar a la persona de acuerdo al documento ingresado y se
especificará el grupo beneficiario al que pertenece y su relación con el titular. Además se
especificará si el titular cuenta con seguro y pensión, y cuáles son estos. Una vez llenados los
datos en todas las pestañas el usuario seleccionará el botón guardar y volverá a la bandeja de
datos. Esta información registrada es importante para que la solicitud pueda ser pre aprobada o
aprobada.

59
 Figura 5.14. – Prototipo de formulario de ficha de datos (Composición Familiar). Fuente:
Elaboración propia.

La figura 5.15 muestra el prototipo que corresponde al formulario para el registro del acta de
supervisión, se deberá identificar al verificador encargado de la supervisión de los beneficiarios,
además se podrá adjuntar una copia digital de dicho acta, la copia podrá ser accedida en cualquier
momento.

Figura 5.15. – Prototipo de formulario de acta de supervisión. Fuente: Elaboración propia.

La figura 5.16 corresponde al prototipo del formulario para cambiar el estado de la solicitud,
este formulario será visto desde la bandeja de solicitudes. En el formulario se seleccionará los

60
estados posibles para ser cambiado y se ingresarán los datos del informe y la carta para ser
impresa. Una vez cambiado el estado podrá visualizarse el botón para imprimir la carta.

Figura 5.16. – Prototipo de formulario de cambio de estado. Fuente: Elaboración propia.

Especificación de Caso de Uso de Sistema ECUS03

Caso de Uso
CUS03 Buscar persona
de Sistema

Descripción Permite buscar la información de una persona ingresando su número de documento

1. Flujo de eventos
Paso Acción

1 La aplicación muestra un formulario con campos de datos personales de una persona.

2 El coordinador ingresa un número de documento.

La aplicación muestra los datos personales de la persona a la cual le corresponde ese
3
número de documento.
4 Fin del caso de uso.
2. Flujos alternativos
Ninguno.
3. Excepciones
3.1 Datos no encontrados
En el paso 3, si no se cuenta con los datos personales al ingresar el número de documento, la
aplicación muestra un mensaje de error y el usuario tiene que ingresar los datos manualmente.
3.2 Ya registrado

61
En el paso 3, si la persona a la que le pertenece el número de documento ya está empadronado o
tiene una solicitud pendiente, la aplicación muestra un mensaje de error y borra los datos
ingresados.
4. Pre-condiciones
El usuario debe estar en la interfaz que contiene un formulario con datos personales.
Tener una sesión iniciada.
5. Post-condiciones
La aplicación realizó una búsqueda de datos y mostró un mensaje
6. Prototipos
Ninguno.
Tabla 5.9. – ECUS03. Fuente: Elaboración propia.

Especificación de Caso de Uso de Sistema ECUS04

Caso de Uso
CUS04 Registrar entregas padrón.
de Sistema
Permite al usuario registrar la asistencia de los beneficiarios, además se podrá
Descripción
adjuntar copias digitales de los registros de asistencia.
1. Flujo de eventos
Paso Acción

1 El flujo inicia cuando el coordinador selecciona la opción Padrón en el menú principal.

La aplicación muestra una interfaz con un listado de titulares para el padrón de beneficiarios
2
activo en la fecha actual.
3 El coordinador selecciona la fecha a la cual desea registrar.

4 La aplicación muestra los titulares en el padrón de beneficiario de la fecha seleccionada.

El coordinador cambia el estado del titular a ASISTIÓ o NO ASISTIÓ de acuerdo sea el
5
caso.
6 La aplicación guarda los datos de cada titular cuando se haga el cambio de estado.

7 Fin del caso de uso

2. Flujos alternativos
2.1. Imprimir asistencia
En el paso 5, si el usuario selecciona la opción IMPRIMIR ASISTENCIA, la aplicación muestra
un documento pdf para imprimir el listado de titulares para la fecha seleccionada.
2.2. Adjuntar asistencia
En el paso 5, si el usuario selecciona la opción ADJUNTAR ASISTENCIA, la aplicación muestra
una ventana para adjuntar una copia digital de la asistencia firmada por los titulares en la semana
de la fecha seleccionada.
3. Excepciones
3.1. No hay raciones disponibles
Si la cantidad de raciones disponibles es menor a la cantidad de raciones de la composición familiar
del titular que se desea cambiar la asistencia, la aplicación muestra un mensaje de error y detiene
el proceso.
4. Pre-condiciones
Tener una sesión iniciada.
5. Post-condiciones
La aplicación realizó una transacción.
6. Prototipos
Tabla 5.10. – ECUS04. Fuente: Elaboración propia.

62
En la figura 5.17 se muestra el prototipo de interfaz para el control de asistencia de los
beneficiarios, esta interfaz pertenece al módulo de control de entregas de la aplicación. Al ingresar
se mostrarán una lista de beneficiarios que están activos de acuerdo a la fecha ingresada, el usuario
tendrá que cambiar el estado de la asistencia para cada uno de los beneficiarios. El control de la
asistencia es importante para la emisión de los reportes, asimismo ya que se cuenta con cada uno
de los beneficiarios categorizados en un grupo beneficiario se podrá emitir los reportes de manera
categorizada de forma más eficiente. En el prototipo se observa que la bandeja contiene un botón
para adjuntar una copia digital de la ficha de asistencia.

Figura 5.17. – Prototipo de ventana de asistencia de beneficiarios. Fuente: Elaboración propia.

Especificación de Caso de Uso de Sistema ECUS05

Caso de Uso
CUS05 Gestionar transeúntes
de Sistema
Descripción Permite registrar la información de los transeúntes atendidos.
1. Flujo de eventos
Paso Acción

1 El flujo inicia cuando el usuario selecciona la opción Transeúntes en el menú principal.

La aplicación muestra una interfaz con un listado de transeúntes registrados en la fecha
2
actual.
3 El coordinador selecciona la fecha a la cual desea registrar.

4 La aplicación muestra los transeúntes en el padrón de beneficiario de la fecha seleccionada.

5 El coordinador selecciona la opción NUEVO REGISTRO.

6 La aplicación muestra un formulario para el registro del transeúnte.

El coordinador ingresa los datos personales (Ir a ECUS03), nacionalidad, grupo
7
beneficiario y grado de instrucción. El usuario selecciona la opción GUARDAR.

63
 8 La aplicación guarda los datos del transeúnte y vuelve al listado de transeúntes.

9 Fin del caso de uso.

2. Flujos alternativos
Ninguno.
3. Excepciones
3.1. No hay raciones disponibles
En el paso 5, si no hay raciones disponibles en la fecha seleccionada, la aplicación mostrará un
mensaje de error y no mostrará el formulario de registro.
4. Pre-condiciones
Tener una sesión iniciada.
5. Post-condiciones
La aplicación realizó una transacción.
6. Prototipos
Tabla 5.11. – ECUS05. Fuente: Elaboración propia.

El módulo de control de entregas contará con una bandeja donde se podrán registrar los
traunseúntes que reciben raciones alimentarias, un transeúnte es una persona que no pertenece al
padrón de beneficiarios y recibe raciones alimentarias que no han recogido las personas que
pertenecen al padrón de beneficiarios. Igual que los beneficiarios, los transeúntes deben ser
categorizados en un grupo beneficiario. En la figura 5.18 se muestra el prototipo de esta interfaz.

Figura 5.18. – Prototipo de ventana de asistencia de transeúntes. Fuente: Elaboración propia.

La figura 5.19 muestra el prototipo de formulario para registrar un transeúnte, el formulario es
similar al de registro de un beneficiario, pero no cuenta con los campos de relación con un
titular y no se puede cambiar la cantidad de raciones alimentarias que recibe.

64
 Figura 5.19. – Prototipo de formulario de registro de transeúnte. Fuente: Elaboración propia.

Especificación de Caso de Uso de Sistema ECUS06

Caso de Uso
CUS08 Gestionar productos.
de Sistema
Descripción Permite listar, registrar o editar la información de los productos del almacén.
1. Flujo de eventos
Paso Acción

1 El flujo inicia cuando el almacenero selecciona la opción Productos en el menú principal.

2 La aplicación muestra una interfaz con un listado de productos registrados.

3 El almacenero selecciona la opción NUEVO REGISTRO

La aplicación muestra un formulario con los campos: nombre, familia, unidad de medida,
4
stock actual.
5 El almacenero ingresa los datos y selecciona la opción GUARDAR.

6 La aplicación guarda los datos y vuelve al listado de productos.

7 Fin del caso de uso.

2. Flujos alternativos
2.1. Editar

65
En el paso 3, si el almacenero selecciona la opción EDITAR en uno de los productos, la aplicación
muestra el formulario de registro del producto con los datos respectivos. El almacenero puede
modificar estos datos a excepción del stock. Posteriormente selecciona la opción GUARDAR, la
aplicación guarda las modificaciones y vuelve al listado del producto.
3. Excepciones
Ninguna.
4. Pre-condiciones
Tener una sesión iniciada.
5. Post-condiciones
La aplicación realizó una transacción y volvió al listado de productos.
6. Prototipos
Tabla 5.12. – ECUS06. Fuente: Elaboración propia.

El prototipo en la figura 5.20 corresponde a los productos registrados del almacén, se listarán los
productos registrados junto con su stock actual actualizado de acuerdo a los movimientos
realizados.

Figura 5.20. – Prototipo de bandeja de productos en el almacén. Fuente: Elaboración propia.

66
La figura 5.21 muestra el prototipo de formulario para el registro inicial del producto.

Figura 5.21. – Prototipo de formulario de registro de productos. Fuente: Elaboración propia.

Especificación de Caso de Uso de Sistema ECUS07

Caso de Uso
CUS07 Gestionar Kárdex
de Sistema
Permite registrar y visualizar los movimientos del almacén. Se realiza la
Descripción actualización automática del stock de los productos de acuerdo a la información
ingresada.
1. Flujo de eventos
Paso Acción

1 El flujo inicia cuando el almacenero selecciona la opción Kárdex en el menú principal.

La aplicación muestra una interfaz con un listado de movimientos del almacén registrados
2
en la fecha actual.
3 El almacenero selecciona la opción NUEVO REGISTRO
La aplicación muestra un formulario con los campos: tipo de documento, número de
4 documento, tipo de movimiento, fecha del movimiento, producto, cantidad sueltos, tipo de
bulto, cantidad bultos y equivalencia.
El almacenero ingresa los datos: tipo de documento, número de documento, tipo de
5
movimiento y fecha del movimiento.
6 El almacenero selecciona el producto del movimiento.

7 La aplicación muestra el stock actual del producto seleccionado.

El almacenero ingresa los datos: cantidad sueltos, tipo de bulto, cantidad bultos y
8
equivalencia.
9 El almacenero selecciona la opción GUARDAR.

67
 La aplicación guarda los datos y actualiza el stock del producto. Una vez hecho esto vuelve
10
al listado de movimientos.
11 Fin del caso de uso.
2. Flujos alternativos
2.1. Editar
En el paso 3, si el almacenero selecciona la opción ELIMINAR en uno de los movimiento, éste es
eliminado y se recalcula el stock del producto.
3. Excepciones
3.1. No hay stock suficiente
En el paso 8, si el almacenero seleccionó un movimiento de salida y la cantidad ingresada es mayor
al stock actual del producto, la aplicación mostrará un mensaje de error y no permitirá guardar los
datos.
4. Pre-condiciones
Tener una sesión iniciada.
5. Post-condiciones
La aplicación realizó una transacción y volvió al listado de movimientos.
6. Prototipos
Tabla 5.13. – ECUS07. Fuente: Elaboración propia.

La figura 5.22 muestra la bandeja de kárdex que corresponde al módulo de control del almacén,
en esta bandeja se listará los movimientos del almacén registrados.

Figura 5.22. – Prototipo de bandeja de kárdex. Fuente: Elaboración propia.

La figura 5.253 corresponde al formulario de registro de movimientos del almacén, el usuario

deberá seleccionar la guía con el cuál se realiza el movimiento, luego deberá ingresar los datos de
las cantidades retiradas o ingresadas. La aplicación validará que se cuenten con el stock suficiente
si se está retirando productos del almacén. Una vez registrado un movimiento, el stock del
producto en el almacén será actualizado automáticamente.

68
 Figura 5.23. – Prototipo de registro de kárdex. Fuente: Elaboración propia.

Especificación de Caso de Uso de Sistema ECUS08

Caso de Uso
CUS08 Emitir Reportes
de Sistema
Descripción Permite buscar y generar un reporte en formato pdf o excel.
1. Flujo de eventos
Paso Acción
El flujo inicia cuando el coordinador o almacenero selecciona la opción Reportes en el
1
menú principal.
2 La aplicación muestra una lista de opciones de reportes.

3 El coordinador o almacenero selecciona la opción deseada.

La aplicación muestra una pantalla con opciones de búsqueda de acuerdo a la opción
4
seleccionada.
El coordinador o almacenero modifica los filtros de búsqueda para obtener la información
5
deseada.
6 El coordinador o almacenero selecciona la opción con el formato de reporte deseado.

7 La aplicación desarga o visualiza el reporte.

8 Fin del caso de uso.

2. Flujos alternativos
No hay flujos alternativos.
3. Excepciones
No hay excepciones.
4. Pre-condiciones
Tener una sesión iniciada.
5. Post-condiciones

69
La aplicación descargó o visualizó un reporte
6. Prototipos
Tabla 5.13. – ECUS08. Fuente: Elaboración propia.

El prototipo 5.24 muestra una pantalla con opciones para generar el reporte.

Figura 5.24. – Prototipo de pantalla para generar reporte. Fuente: Elaboración propia.

Especificación de Caso de Uso de Sistema ECUS09

Caso de Uso
CUS09 Adjuntar documento
de Sistema
Descripción Permite guardar una copia digítal de algún documento.
1. Flujo de eventos
Paso Acción

1 El flujo inicia cuando el coordinador selecciona una opción para adjuntar documento.

2 El coordinador o almacenero busca el documento que desea adjuntar.

3 El coordinador o almacenero guarda los datos del formulario en el que se encuentra.

4 La aplicación guarda el documento en un servidor de archivos.

5 Fin del caso de uso.

2. Flujos alternativos
2.1. Documento encontrado.
Si se encuentra un documento adjunto, la aplicación adicionalmente mostrará un botón para
descargar dicho documento.
3. Excepciones
No hay excepciones.

70
4. Pre-condiciones
Tener una sesión iniciada.
Estar ubicado en una intefaz con opción para adjuntar un documento.
5. Post-condiciones
La aplicación descargó o visualizó un reporte
Tabla 5.14. – ECUS09. Fuente: Elaboración propia.

Especificación de Caso de Uso de Sistema ECUS10

Caso de Uso
CUS10 Mantener ítems
de Sistema
Permite registrar y editar información para los ítems necesarios para el manejo de
Descripción
la aplicación.
1. Flujo de eventos
Paso Acción

1 El flujo inicia cuando el usuario selecciona la opción Mantenimiento en el menú principal.

2 La aplicación muestra una serie de opciones en el menú principal.

3 El usuario selecciona la opción deseada.

La aplicación muestra una interfaz con una bandeja con el listado de ítems registrados de
4
la opción seleccionada.
5 El usuario selecciona la opción NUEVO REGISTRO.

6 La aplicación muestra un formulario para ingresar el nombre del ítem.

7 El usuario ingresa el nombre y selecciona GUARDAR.

8 La aplicación guarda los datos y vuelve al listado.

9 Fin del caso de uso.

2. Flujos alternativos
2.1. Editar
En el paso 5, si el usuario selecciona EDITAR en un ítem, la aplicación muestra el formulario de
registro con el nombre del ítem. El usuario puede modificar el dato y luego seleccionar
GUARDAR, la aplicación guardará los cambios y volverá al listado.
3. Excepciones
3.1. Ya registrado
En el paso 7, si el usuario ingresa un nombre de ítem que ya está registrado, la aplicación mostrará
un mensaje de error y detendrá el proceso de guardado.
4. Pre-condiciones
Tener una sesión iniciada.
5. Post-condiciones
La aplicación realizó una transacción y volvió al listado de ítems.
6. Prototipos
Tabla 5.15. – ECUS10. Fuente: Elaboración propia.

Se contará con un módulo de mantenimiento donde se contará con una bandeja para cada uno de
los ítems necesarios derivados del diseño de la base de datos, cada bandeja tendrá un botón para
registrar un nuevo ítem y una opción para editar los datos de los ítems. El formulario de registro
de ítems es similar para todos los casos exceptuando para los verificadores. En la figura 5.25 se

71
muestra el prototipo de la interfaz junto con el prototipo del formulario de registro y edición de
datos.

Figura 5.25. – Prototipo de bandeja de productos en el almacén. Fuente: Elaboración propia.

72
c. Arquitectura de la aplicación
La aplicación trabaja con el framework Yii que utiliza una arquitectura basada en componentes y
que sigue el patrón modelo-vista-controlador (MVC). En la figura 5.25 se describe la arquitectura
en un diagrama, donde el usuario envía una solicitud a la aplicación, la solicitud es recibida por
un controlador que contiene la lógica de negocio y utiliza al modelo para interactuar con la base
de datos. Una vez realizada la función del controlador, éste envía una respuesta de vista mediante
páginas html. La arquitectura Yii contiene una función para controlar la sesión de los usuarios,
sin embargo ésta ha sido desactivada para ingresar una extensión propia de la Gerencia de
Informática para controlar la sesión.

Figura 5.26. – Arquitectura de la aplicación. Fuente: Elaboración propia.

73
El framework Yii cuenta con una función de división del contenido mediante módulos, cada
módulo generado contiene a su vez un patrón MVC que maneja las solicitudes de igual manera
que la aplicación a nivel general, esto permite mantener un desarrollo más ordenado y al tener
aislados los componentes en sus módulos respectivos permite que la funcionabilidad no falle en
más de un módulo a causa de un error. En la figura 5.27 se muestra como el framework trabaja
de forma individual con cada módulo.

Figura 5.27. – Comportamiento modular de la arquitectura. Fuente: Elaboración propia.

En la figura 5.28 se muestra la estructura de carpetas de la aplicación, donde system contiene los
archivos del framework yii y protected contiene la estructura del patrón MVC, así como
componentes a nivel general que pueden crear los programadores, extensiones y la configuración
del proyecto.

Figura 5.28. – Estructura general de la aplicación. Fuente: Elaboración propia.

74
Como se explica, dentro de la carpeta protected se contiene la estructura MVC. La carpeta config
contiene archivos de configuración de conexión a base de datos y configuración de la aplicación.
Existe una carpeta modules que contiene dentro una carpeta por cada módulo, cada módulo
obedece también a un patrón MVC conteniendo así carpetas como views, models, controlles y,
otras como assets y components. En la figura 5.29 se muestra la carpeta protected.

Figura 5.29. – Estructura dentro del directorio protected. Fuente: Elaboración propia.

75
5.3. Fase de Construcción
En esta fase se realiza la construcción del software de acuerdo a los requerimientos y el modelado
establecido, mientras se realiza la codificación también se realizan las pruebas de software. Una
vez terminada la codificación se debe entrar en un estado de pre-producción para realizar las
pruebas de aceptación. En esta fase también se puede establecer un ambiente de capacitación a
los usuarios.
a. Modelo de base de datos
El modelo de base datos representa como se estructura la base de datos a implementar, la
herramienta Erwin Data Modeler permite realizar el modelado de manera simple y generar el
script de base de datos rápidamente. Las siguientes figuras corresponden a diferentes esquemas y
bases de datos utilizadas por la aplicación desarrollado, hay que tener en cuenta que se aplican
técnicas de normalización de base de datos, ya que se trabaja con una metodología ágil, el enfoque
de esta es trabajar con cambios o nuevos requerimientos que piden los clientes, por lo tanto los
modelos de base de datos propios de la aplicación son susceptibles a cambiar a lo largo del
proyecto.
La figura 5.30 muestra el primer esquema que corresponde a la base de datos propia de la
aplicación, contiene las tablas que se utilizan para realizar la gestión de la información del padrón
de beneficiarios. Se cuenta principalmente con la tabla FICHAS donde se guarda la información
inicial de la solicitud, esta tabla está relacionada con la tabla BENEFICIARIOS donde se guarda
la información de los beneficiarios pertenecientes a la ficha, estas dos tablas son necesarias para
establecer el padrón de beneficiarios. Como se puede observar los beneficiarios están catalogados
por grupos, asimismo se tiene también la tabla que contiene la información de los transeúntes,
estos también están categorizados en un grupo. Se cuenta con una tabla de entrega de raciones,
aquí se guarda la información de las raciones alimentarias entregadas, ésta se debe relacionar con
los transeúntes o las fichas de acuerdo sea el caso.

Figura 5.30. – Modelo de base de datos para la gestión del padrón de beneficiarios. Fuente:
Elaboración propia.

76
La figura 5.31 muestra el esquema que corresponde a la base de datos propia de la aplicación,
contiene las tablas para el control del almacén. La tabla principal corresponde a KARDEX, que
guarda información de los movimientos de ingreso o salida de un producto del almacén, al realizar
registros o cambios en esta tabla la aplicación actualizará la tabla ALMACEN que contiene el
detalle del stock de producto.

KARDEX
FAMILIA_PRODUCTOS
ID_KARDEX
ID_FAMILIA
NUMERO_DOCUMENTO
DESCRIPCION_FAMILIA_PRODUCTO FECHA_MOVIMIENTO DOCUMENTOS_MOVIMIENTO
TIPO_MOVIMIENTO
OBSERVACION ID_DOCUMENTO
CANTIDAD_SUELTOS DESCRIPCION_DOCUMENTO
CANTIDAD_BULTOS
PRODUCTOS EQUIVALENCIA_BULTO
UNIDADES_MEDIDA ALMACEN FECHA_REGISTRO
ID_PRODUCTO
ID_UM ID_ALMACEN ID_USUARIO BULTOS
DESCRIPCION_PRODUCTO ID_ALMACEN (FK)
STOCK_ALMACEN ID_BULTO
DESCRIPCION_UM ID_UM (FK) ID_DOCUMENTO (FK)
ID_FAMILIA (FK) ID_PRODUCTO (FK) ID_BULTO (FK) DESCRIPCION_BULTO

Figura 5.31. – Modelo de base de datos para el control del almacén. Fuente: Elaboración propia.

La figura 5.32 refiere corresponde al esquema para la gestión de usuarios. Esta base de datos
pertenece al sistema PadLock de la Gerencia de Informática y sirve para controlar los accesos de
los usuarios. El sistema PadLock trabaja con diferentes aplicaciones desarrolladas por la Gerencia
de Informática y agiliza el proceso de desarrollo ya que se cuenta con un módulo de seguridad
externo al proyecto desarrollado.

Figura 5.32. – Modelo de base de datos para la gestión de usuarios. Fuente: Elaboración propia.

La figura 5.33 corresponde a una base de datos maestra (MASTER), esta base de datos contiene
tablas con información que puede ser manejada por cualquier aplicación, por ejemplo esta base
tiene la tabla PERSONAS que tiene los datos personales de las personas que hayan sido atendidas
en la Municipalidad Provincial del Callao esta información es registrada y actualizada por todos
las aplicaciones que accedan a ella. En los modelos de datos anteriores se cuenta con tablas que
tienen campos “ID” no relacionados a ninguna otra tabla, esos campos corresponde a la relación
con las tablas contenidas en MASTER.

77
 Figura 5.33. – Modelo de base de datos MASTER. Fuente: Elaboración propia.
b. Diagramas de componentes
Los diagramas de componentes muestran los distintos componentes de software del código fuente
de la aplicación desarrollada y cómo se relacionan para mantener la funcionabilidad. Los
diagramas de componentes son especialmente útiles para los desarrolladores ya que permiten
entender fácilmente cómo se comporta la aplicación y pueden ser utilizados por las instituciones
donde se tienen cambios de personal de forma constante.
La figura 5.34 muestra el diagrama de componentes para la configuración principal del proyecto,
el componente main.php corresponde a una clase propia del framework que define las variables
del proyecto desarrollado. Se puede observar que contiene la definición de los módulos
planteados, asimismo se declarara de manera global las extensiones a utilizar del paquete
extensions y los componentes correspondientes a clases utilizadas en todo el proyecto en el
paquete components, estos paquetes son contenidos en la estructura protected del proyecto como
se observa en la imagen Figura 5.29.

Figura 5.34. – Diagrama de componentes (main). Fuente: Elaboración propia.

78
La figura 5.35 muestra el diagrama de componentes correspondiente al paquete extensions, este
paquete contiene las extensiones utilizadas en todo el proyecto.

Figura 5.35. – Diagrama de componentes (paquete extensions). Fuente: Elaboración propia.

La figura 5.36 muestra el diagrama de componentes para el despliegue de la aplicación. El
desarrollo de la aplicación cuenta con tres entornos, el primero es el entorno local que corresponde
los equipos utilizados para el desarrollo, este entorno también es utilizado para realizar pruebas
unitarias; el segundo es el entorno desarrollo (development) corresponde a un servidor Ubuntu
para realizar la demostración de prototipos y pruebas con los usuarios, además está configurado
para comportarse igual que el entorno de producción; el último entorno es el de producción
(production) donde los usuarios utilizan el producto final. La aplicación utiliza estos componentes
de entorno para ser desplegado y conectar con el servidor de base de datos.

Figura 5.36. – Diagrama de componentes (entornos). Fuente: Elaboración propia.

La figura 5.37 muestra el diagrama de componentes con componentes utilizados por el framework
a manera general, los componentes CMODEL.php, CCOTROLLER.php,
CBASECONTROLLER.php, CMODULE.php y CCOMPONENT.php corresponde a componentes
del framework Yii para la creación de otros componentes utilizando la técnica de scaffolding. Se
puede observar el componente MODULE.php, éste representa de manera general cualquier clase
de declaración de módulo y se relaciona con el componente personalizado Assets.php que

79
configura el módulo para cargar diferentes librerías exclusivamente en el módulo que las va a
utilizar, de esta manera se reducen los tiempos de carga y la memoria utilizada.

Figura 5.37. – Diagrama de componentes (componentes generales). Fuente: Elaboración propia.

80
La figura 5.38 muestra el diagrama de componentes que contiene los modelos utilizados por la
aplicación, se puede observar que se extienden al componente CACTIVERECORD que es el
encargado de realizar las transacciones con la base de datos.

Figura 5.38. – Diagrama de componentes (modelos). Fuente: Elaboración propia.

La figura 5.39 describe los componentes utilizados por los controladores, el componente
CONTROLADOR representa de manera general cualquier controlador generado, este es
extendido al componente auth.php que contiene funciones de autorización de acceso los módulos
y controladores, el componente auth.php es extendido al componente builder.php que sirve como
personalización del componente general de controlador del framework y contiene funciones para
el control de la sesión del usuario utilizando la extensión padlock.

81
 Figura 5.39. – Diagrama de componentes (controladores). Fuente: Elaboración propia.
La figura 5.40 muestra los componentes usados por el módulo de fichas/solicitudes en la bandeja
de solicitudes, se cuenta con la vista index.php que contiene la bandeja en cuestión y un
controlador principal para manejar las solicitudes del usuario, además se describe los
componentes para realizar el cambio de estado de la solicitud utilizando la vista _estado.php. El
módulo cuenta con un controlador de respuesta (ResponseController.php) utilizado para validar
la capacidad de raciones alimentarias que se tiene. El controlador principal y de respuesta y
utilizan el componente QFichas.php para realizar consultas a la base de datos sin necesidad de
utilizar los componentes de modelo.

Figura 5.40. – Diagrama de componentes (bandeja de solicitudes). Fuente: Elaboración propia.

82
La figura 5.41 corresponde al diagrama de componentes utilizados para realizar el registro de una
solicitud, este proceso es realizado en el módulo de fichas/solicitudes. Se cuenta con la vista
_nuevo.php que contiene el formulario de registro y los controladores principal y de respuesta, el
controlador de respuesta se encarga de buscar y validar los datos de la persona mediante un
número de documento ingresado utilizando la extensión master, esta extensión utiliza el modelo
de personas para conectar con la base de datos BDMASTER; el controlador principal se encarga
de realizar el guardado de los datos del formulario y utiliza modelos y el paquete Yii para hacer
transacciones en la base de datos propia de la aplicación.

Figura 5.41. – Diagrama de componentes (nueva solicitud). Fuente: Elaboración propia.

La figura 5.42 corresponde al diagrama de componentes para el registro de la ficha de datos, se
utiliza el controlador principal para realizar la carga de datos de la ficha, en la vista Ficha.php se
cuenta con la lista de beneficiarios que conforma la ficha y se utiliza la vista _beneficiarios.php
que contiene el formulario para el registro de formulario para formar el padrón de beneficiarios,
este es uno de los pasos más importantes para gestionar la información ya que se cuenta con la
categorización de los beneficiarios y las raciones alimentarias que le corresponden a cada uno,
además se cuentan con datos reales edades, género, número de documentos que serán mostrados
en los reporte. Al igual que con el registro de la solicitud, se utiliza la extensión master para
buscar los datos de los beneficiarios con el número de documento y se cuenta con diferentes
módulos generados para realizar transacciones a la base de datos.

83
 Figura 5.42. – Diagrama de componentes (ficha de datos). Fuente: Elaboración propia.
La figura 5.43 muestra el diagrama de componentes para el registro del acta de supervisión, en
este paso se cuenta con la primera interacción con los componentes utilizados para interactuar
con el servidor de archivos mediante conexión sftp.

Figura 5.43. – Diagrama de componentes (acta de supervisión). Fuente: Elaboración propia.

84
La figura 5.44 muestra el diagrama de colaboración para el registro de asistencia de beneficiarios
en el módulo de control de entregas, se cuenta con la vista index.php donde se muestra una lista
de beneficiarios solicitada al controlador principal del módulo utilizando el componente
QEntregas que ejecuta procedimientos almacenados en la base de datos
BDPROGRAMASSOCIALES, la vista es utilizada para marcar la asistencia de cada beneficiario.
Además se cuenta con una ventana _adjuntar.php donde el usuario podrá adjuntar una copia del
registro de asistencia, el controlador utilizará la extensión sftp para guardar la copia en el servidor
de archivos.

Figura 5.44. – Diagrama de componentes (entregas a beneficiarios). Fuente: Elaboración propia.

La figura 5.45 muestra el diagrama de componentes para el registro de entregas a transeúntes en
el módulo de control de entregas. Se cuenta con la vista index.php manejada por el controlador
TranseuntesController.php presente en el mismo módulo, la vista muestra un formulario para el
registro de transeúntes, este formulario contiene campos similares que el formulario de
beneficiarios, sin embargo los transeúntes sólo reciben una ración alimentaria. Al momento de
realizar el registro de transeúntes la vista manda una solicitud de validación de que se cuenta con
raciones alimentarias suficientes para atender al transeúnte.

85
Figura 5.45. – Diagrama de componentes (entregas a transeúntes). Fuente: Elaboración propia.
El diagrama 5.46 muestra los componentes de la bandeja de movimientos del almacén registrados,
se cuenta con el controlador kardexController.php encargado de listar los movimientos, demás se
tiene la vista _movimiento.php que muestra los detalles del movimiento registrado.

Figura 5.46. – Diagrama de componentes (bandeja de movimientos del almacén). Fuente:

Elaboración propia.
La figura 5.47 muestra los componentes para el registro de kárdex, se realiza la validación de
stock del almacén utilizando un controlador de respuesta dentro del módulo, asimismo se utilizan
el modelo MODELKARDEX para guardar la información del movimiento y el modelo
MODELALMACEN para actualizar el stock del producto.

86
 Figura 5.47. – Diagrama de componentes (kárdex). Fuente: Elaboración propia.
La figura 5.48 muestra los componentes para el registro de los productos contenidos en el
almacén, se utiliza una vista bandeja index.php y un formulario _producto.php, los productos
registrados son mostrados en otras funciones de la aplicación, la bandeja además muestra las
existencias de stock del producto en el almacén, los stocks no pueden ser modificados
manualmente.

Figura 5.48. – Diagrama de componentes (productos). Fuente: Elaboración propia.

La figura 5.49 muestra el diagrama de componentes para la emisión de reportes. Se cuenta con
una vista index.php dentro de un paquete por cada tipo de reporte dentro del módulo, la vista
cuenta con los filtros necesarios para generar el reporte y envía solicitudes al su controlador
correspondiente. Los controladores utilizan el componente QReportes.php para ejecutar
procedimientos almacenados que envían la información del reporte desde el servidor de base de
datos, además estos controladores utilizan el paquete de extensión tcpdf que cuenta con un

87
software de código libre para generar documentos en formato PDF. Además se cuenta con un
controlador excelController.php que recibe solicitudes si el usuario desea generar reporte en
formato excel, el controlador devuelve una vista que contiene la data deseada y es descargada por
el navegador automáticamente.

Figura 5.49. – Diagrama de componentes (reportes). Fuente: Elaboración propia.

88
La figura 5.50 muestra el diagrama de componentes para mostrar estadísticas de gestión, las
estadísticas son mostradas en la pantalla inicial de la aplicación. Se utiliza la librería CanvasJS
para la visualización de los gráficos, esta librería además cuenta con opciones de exportación en
diferentes formatos como jpg, png, entre otros. El controlador encargado se vale de
procedimientos almacenados para mostrar la obtener la información.

Figura 5.50 – Diagrama de componentes (dashboard). Fuente: Elaboración propia.

89
La figura 5.51 corresponde a los componentes que usa la aplicación para armar la interfaz que
contiene elementos como el menú principal, la cabecera y el pie de página. La carga del menú
principal se realiza utilizando la extensión padlock para mostrar las opciones a las cuales el
usuario tiene acceso. El contenido de cada página es proveído por el framework Yii.

Figura 5.51. – Diagrama de componentes (interfaz). Fuente: Elaboración propia.

c. Nuevos requerimientos
La tabla 5.17 muestran los nuevos requerimientos surgidos a partir de la iteración I2 donde se
realizó la presentación del prototipo del módulo de gestión de solicitudes. Los requerimientos
fueron categorizados y priorizados según muestra la tabla.

ITERACIÓN MÓDULO PANTALLA OBSERVACIÓN TIPO PRIORIDAD

Nueva Agregar la opción de

solicitud registrar datos
GESTIÓN DE manualmente ya que no Nuevo
I2 Crear/editar 3
SOLICITUDES siempre se cuenta con el requerimiento
beneficiario
documento de identidad
de la persona

90
 Bandeja de Separar los retirados y
GESTIÓN DE Nuevo
I2 solicitudes desaprobados en una 2
SOLICITUDES requerimiento
bandeja diferente

Bandeja de Agregar una opción para

GESTIÓN DE solicitudes gestionar los Nuevo
I2 1
SOLICITUDES beneficiarios desde la requerimiento
bandeja

Ficha de Agregar una opción para

datos agregar el grupo
GESTIÓN DE
I2 beneficiario y las Mejora 1
SOLICITUDES
raciones del titular antes
de ingresar a la pantalla

Bandeja de Por defecto mostrar las

GESTIÓN DE
I2 solicitudes solicitudes pendientes Mejora 1
SOLICITUDES
del año

Tabla 5.17. – Nuevos requerimientos (I2). Fuente: Elaboración propia.

La figura 5.52 muestra el cambio en el modelo de base de datos de acuerdo a los nuevos
requerimientos que establecen que se requiere registrar datos personales de forma manual porque
existen casos que los beneficiarios no cuentan con su documento de identificación. Se agrega la
tabla exclusiva PERSONAS_SIN_DOCUMENTO para el esquema de padrón de beneficiarios,
además se agrega un campo condicional en las tablas BENEFICIARIOS y FICHAS para indicar
en qué tabla se debe realizar la consulta. Este cambio se realizó posteriormente para la tabla de
TRANSEUNTES.

91
Figura 5.52. – Nueva tabla en el modelo de base datos. Fuente: Elaboración propia.

92
La figura 5.53 muestra el diagrama de componentes para la creación de la bandeja de fichas
retiradas, como se puede observar se utiliza en el mismo módulo se utiliza un controlador y vista
diferente.

Figura 5.53. – Diagrama de componentes para la bandeja de fichas retiradas. Fuente:

Elaboración propia.
La tabla 5.18 muestran los nuevos requerimientos surgidos a partir de la iteración I3 donde se
realizó la presentación del prototipo del módulo de control de entregas. Los requerimientos fueron
categorizados y priorizados según muestra la tabla.

ITERACIÓN MÓDULO PANTALLA OBSERVACIÓN TIPO PRIORIDAD

Asistencia Mostrar información de las

de entregas del día que se
CONTROL
beneficiarios hayan registrado
I3 DE Mejora 1
Asistencia
ENTREGAS
de
transeúntes

Asistencia Agregar la opción de

CONTROL
de registrar datos
I3 DE Mejora 3
transeúntes manualmente ya que no
ENTREGAS
siempre se cuenta con el

93
 documento de identidad de
la persona

Asistencia Agregar una opción para

CONTROL
de buscar todas las atenciones Nuevo
I3 DE 2
transeúntes que haya tenido un requerimiento
ENTREGAS
transeúnte

CONTROL Asistencia Agregar la opción de

I3 DE de eliminar un transeúnte en Mejora 1
ENTREGAS transeúntes caso de error

Tabla 5.18. – Nuevos requerimientos (I3). Fuente: Elaboración propia.

La figura 5.54 muestra el cambio para el nuevo requerimiento para realizar una búsqueda de
atenciones del transeúnte. Se agrega un nuevo botón en pantalla de asistencia de transeúntes.

Figura 5.54. – Prototipo cambio a la pantalla de asistencia de transeúntes. Fuente: Elaboración

propia.
La figura 5.55 muestra el prototipo de pantalla para la búsqueda de atenciones a transeúntes. La
ventana sólo es de consulta.

Figura 5.55. – Prototipo pantalla de búsqueda de atención de transeúntes. Fuente: Elaboración

propia.

94
La figura 5.56 muestra los componentes agregados sólo para la nueva funcionalidad.

Figura 5.56. – Diagrama de componentes para la búsqueda de atenciones a un transeúnte.

Fuente: Elaboración propia.
La tabla 5.19 muestran los nuevos requerimientos surgidos a partir de la iteración I4 donde se
realizó la presentación de los prototipos de los módulos de control del almacén, reportes y
mantenimiento. Los requerimientos fueron categorizados y priorizados según muestra la tabla.

ITERACIÓN MÓDULO PANTALLA OBSERVACIÓN TIPO PRIORIDAD

Bandeja de Tener la opción de editar o

CONTROL
kárdex eliminar un registro de
I4 DEL Mejora 1
movimiento en caso de
ALMACEN
error

CONTROL Nuevo Poder continuar registrando

I4 DEL registro de de forma continua. Mejora 1
ALMACÉN movimiento

Asistencia Agregar una opción para

CONTROL
de buscar todas las atenciones Nuevo
I4 DE 2
transeúntes que haya tenido un requerimiento
ENTREGAS
transeúnte

Sin pantalla Agregar un reporte de

Nuevo
I4 REPORTES entradas y salidas totales 2
requerimiento
(no se cuenta con formato)

95
 Reporte de Agregar la opción de emitir
Nuevo
I4 REPORTES entrega de un reporte mensual y anual 2
requerimiento
raciones (no se cuenta con formato)

Sin pantalla Agregar un reporte de

beneficiarios por edad y Nuevo
I4 REPORTES 2
grupo beneficiario (no se requerimiento
cuenta con formato)

Tabla 5.19. – Nuevos requerimientos (I4). Fuente: Elaboración propia.

La figura 5.57 muestra los cambios en la tabla KARDEX del modelo de base de datos, se agregó
los campos de auditoría para la modificación y edición de datos, así como un campo de estado.

Figura 5.57. – Cambio en la tabla KARDEX en el modelo de base de datos. Fuente: Elaboración
propia.
La figura 5.58 muestra el prototipo del menú principal incorporando las nuevas opciones de
reportes solicitadas.

96
Figura 5.58. – Prototipo de menú principal con nuevos reportes. Fuente: Elaboración propia.

97
d. Diagramas de despliegue
Los diagramas de despliegue describen los equipos necesarios para el despliegue de la aplicación
en sus diferentes entornos.
La figura 5.59 muestra el diagrama de despliegue en entorno de desarrollo, la aplicación es
desplegada en un servidor en el dispositivo del desarrollador, se utiliza un servidor de base de
datos de prueba. Además la aplicación para gestionar los usuarios que se utilizarán en el entorno
de desarrollo y pre-producción se encuentra en un servidor en Ubuntu que se encuentra en entorno
pre-producción y utiliza el mismo servidor de base de datos. Los servidores en Ubuntu y Windows
no se comunican, pero las aplicaciones que contienen utilizan el mismo servidor de baso de datos.

Figura 5.59. – Diagrama de despliegue (entorno desarrollo). Fuente: Elaboración propia.

La figura 5.60 muestra el diagrama de despliegue en entorno pre-producción, la aplicación es
desplegada en el servidor de aplicaciones pre-producción para la realización de pruebas.

Figura 5.60. – Diagrama de despliegue (entorno pre-producción). Fuente: Elaboración propia.

98
La figura 5.61 muestra el diagrama de despliegue en entorno producción. La aplicación es
configurada y desplegada para el uso del usuario final en un servidor de producción. El servidor
de producción cuenta también con la aplicación de gestión de usuarios en entorno producción.
Además se cuenta con un servidor de base de datos de producción.

Figura 5.61. – Diagrama de despliegue (entorno producción). Fuente: Elaboración propia.

99
5.4 Aplicación web
La tabla 5.20 muestra las versiones más resaltantes en el desarrollo y despliegue del proyecto.

VERSIÓN DESCRIPCIÓN
0.0.0.0 Creación del repositorio.
Despliegue de la arquitectura, incluye los módulos de inicio de sesión y el
módulo de inicio que posteriormente incluirá los gráficos estadísticos.
0.1.0.0
Además ya contiene la configuración del proyecto y conexión con el
servidor de base de datos.
Finalización del desarrollo y pruebas del módulo de gestión de solicitudes.
Contiene la conexión con el servidor de archivos y funcionalidades de
0.4.5.0
registro de solicitudes, fichas de datos, beneficiarios, actas de supervisión y
cambio de estados e impresión de cartas de informe.
Finalización del desarrollo y pruebas del módulo de control de entregas.
0.6.5.0 Contiene funcionalidades de control de asistencia de beneficiarios y
transeúntes.
Finalización del desarrollo y pruebas del módulo de control del almacén.
0.8.5.0 Contiene funcionalidades de registro de productos y movimientos del
almacén.
Finalización del desarrollo y pruebas del módulo de reportes. Contiene
reportes de raciones alimentarias entregadas diariamente, padrón de
0.9.5.0
beneficiarios, beneficiarios, estado de almacén y movimientos del almacén
realizados en listado general y formato kárdex,
Finalización del desarrollo y pruebas del módulo de mantenimiento. Se
0.9.9.9
agregan las estadísticas de gestión en el módulo de inicio.
Pase a producción, se despliega la aplicación con los módulos de inicio de
1.0.0.0
sesión, inicio, gestión de solicitudes, reportes y mantenimiento.
Despliegue del módulo de control de entregas. Se liberó el módulo cuando
1.1.0.0
se terminó el registro del padrón de beneficiarios.
Despliegue del módulo de control del almacén. Se liberó el módulo en
1.2.0.0
cuanto se tuvo persona a cargo de la aplicación con perfil de almacenero.
Tabla 5.20. – Versiones de la aplicación. Fuente: Elaboración propia.
Los requerimientos posteriores presentados por la Gerencia General de Programas Sociales son
tratados como requerimientos menores mediante versiones como 1.2.1.0, 1.2.2.0, 1.2.3.0, etc.
A continuación se presentan las interfaces de la aplicación ya desplegada en producción y
utilizado por los usuarios de la Gerencia General de Programas Sociales.
La aplicación puede ser ejecutada en los siguientes navegadores web según la tabla 5.21.

APLICACIÓN VERSIÓN
Internet Explorer 10+
Mozilla Firefox 4+
Google Chrome 7+
Safari 5+
Opera 12+
Tabla 5.21. – Navegadores web para ejecutar la aplicación. Fuente: Elaboración propia.

100
La figura 5.62 muestra la interfaz de inicio de sesión, cabe mencionar que se crearon usuarios
para el personal que haya participado en las pruebas y capacitaciones. Los nuevos usuarios tienen
que ser solicitados mediante memorándum a la Gerencia de Informática.

Figura 5.62. – Interfaz de inicio de sesión. Fuente: Elaboración propia.

La figura 5.63 muestra la interfaz inicial de la aplicación habiendo ingresado con el usuario
administrador del sistema. Como se puede observar la interfaz de inicio contiene un resumen de
la capacidad de raciones que se tiene y las fichas y solicitudes registradas. Además se lista las
fichas que contienen inasistencia y los productos del almacén que se cuentan sin stock. La interfaz
contiene también una opción para mostrar más gráficos estadísticos. En el menú principal
contiene los accesos a los módulos desarrollados, las opciones en el menú principal varían de
acuerdo al perfil del usuario ingresado.

101
Figura 5.63. – Interfaz inicial. Fuente: Elaboración propia.

102
La figura 5.64 muestra el menú de opciones para mostrar gráficos estadísticos.

Figura 5.64. – Menú de opciones de gráficos estadísticos. Fuente: Elaboración propia.

La figura 5.65 muestra un gráfico que es presentado al usuario cuando selecciona una opción.

Figura 5.65. – Gráfico estadístico mostrado en la aplicación. Fuente: Elaboración propia.

103
La figura 5.66 muestra la interfaz con el formulario para el registro de una solicitud.

Figura 5.66. – Interfaz de registro de solicitud. Fuente: Elaboración propia.

104
Al ingresar el número de documento de la persona se buscarán sus datos personales pudiendo
mostrar tres mensajes de acuerdo a lo encontrado.

Figura 5.67. – Mensajes de búsqueda de persona. Fuente: Elaboración propia.

La figura 5.68 muestra la bandeja de fichas vigentes, se listarán las solicitudes asignándoles un
número de ficha automáticamente. En esta bandeja se listan las fichas que están en estado
pendiente, preaprobado o aprobado. Las opciones que se tienen para cada ficha varían de acuerdo
a su estado.

Figura 5.68. – Interfaz de bandeja de fichas aprobadas. Fuente: Elaboración propia.

105
Asimismo la figura 5.69 muestra la interfaz de bandeja de fichas reprobadas, en esta interfaz se
listarán las fichas que estén en estado rechazado, retirado por inasistencia u otros motivos.

Figura 5.69. – Interfaz de bandeja de fichas reprobadas. Fuente: Elaboración propia.

La figura 5.70 muestra la interfaz de ficha de datos en la pestaña que contiene el resumen de las
raciones alimentarias correspondientes.

Figura 5.70. – Interfaz de ficha de datos (resumen). Fuente: Elaboración propia.

106
La figura 5.71 muestra la pestaña que contiene los datos registrados del titular en la solicitud.

Figura 5.71. – Interfaz de ficha de datos (titular). Fuente: Elaboración propia.

La figura 5.72 muestra la pestaña donde se indican las condiciones de materiales de la vivienda.

Figura 5.72. – Interfaz de ficha de datos (condiciones de la vivienda). Fuente: Elaboración

propia.

107
La figura 5.73 muestra la pestaña para ingresar los datos de dirección de la vivienda actual.

Figura 5.73. – Interfaz de ficha de datos (dirección actual). Fuente: Elaboración propia.

108
La figura 5.74 muestra la pestaña donde se listarán los beneficiarios registrados que componen la
ficha, además se especificarán si el titular cuenta con pensión y seguro.

Figura 5.74. – Interfaz de ficha de datos (composición familiar). Fuente: Elaboración propia.
La figura 5.75 muestra el formulario para el registro de un beneficiario, los datos personales son
buscados cuando se ingresa el número de documento.

Figura 5.75. – Formulario de registro de beneficiario. Fuente: Elaboración propia.

109
La figura 5.76 muestra la interfaz para realizar el cambio de estado de la ficha, además se muestra
un resumen de datos del titular y un historial de estados donde se podrá reimprimir la carta para
el titular. Al realizar un cambio de estado el historial será actualizado automáticamente. Los
estados disponibles para el cambio varían de acuerdo al estado actual y una vez guardado el
cambio no se podrá regresar a un estado anterior.

Figura 5.76. – Interfaz de cambio de estado de ficha. Fuente: Elaboración propia.

110
La figura 5.77 muestra la interfaz de registro del acta de supervisión.

Figura 5.77. – Interfaz de cambio de estado de ficha. Fuente: Elaboración propia.

Desde la bandeja de solicitudes se puede ver la composición de la ficha, además se puede eliminar
los beneficiarios registrados. En la figura 5.78 se muestra esta opción.

111
 Figura 5.78. – Interfaz de composición familiar. Fuente: Elaboración propia.
La figura 5.79 muestra los filtros de búsqueda y las opciones que se tienen en la interfaz de
asistencia de beneficiarios en el módulo de control de entregas.

Figura 5.79. – Interfaz de asistencia de beneficiarios. Fuente: Elaboración propia.

112
Se listará los titulares activos en la fecha seleccionada como se observa en la figura 5.80, el
usuario deberá marcar los que asistieron o utilizar el botón “MARCAR TODO”.

Figura 5.80. – Lista de beneficiarios activos. Fuente: Elaboración propia.

La figura 5.81 muestra la interfaz para el control de asistencia de transeúntes.

Figura 5.81. – Interfaz de asistencia de transeúntes. Fuente: Elaboración propia.

De igual manera se mostrarán los transeúntes registrados en la fecha seleccionada como se
observa en la figura 5.82.

113
 Figura 5.82. – Lista de transeúntes registrados. Fuente: Elaboración propia.
En la figura 5.83 se muestra el formulario para el registro de transeúntes, la aplicación valida que
se cuenten con raciones alimentarias antes de realizar el registro. Asimismo para cambiar la
asistencia de los beneficiarios también se realiza dicha validación.

Figura 5.83. – Lista de transeúntes registrados. Fuente: Elaboración propia.

114
En la figura 5.84 se muestra la interfaz que contiene el listado de movimientos registrados en el
almacén. Cada registro contiene las opciones para ser eliminado o editado según lo desee el
usuario.

Figura 5.84. – Interfaz de lista de movimientos del almacén. Fuente: Elaboración propia.

115
En la figura 5.85 muestra el formulario para el registro de un movimiento del almacén, el
formulario valida que se tenga stock del producto del movimiento en caso de ser una salida,
además ya que la Gerencia General de Programas Sociales está en proceso de formalizar las guías
de salida, la opción de número de documento y tipo de documento son opcionales sólo en caso de
ser un movimiento de salida.

Figura 5.85. – Formulario de registro de movimientos del almacén. Fuente: Elaboración propia.

116
La figura 5.86 muestra el formulario donde se pueden ver los datos del movimiento registrado,
en el formulario se puede cambiar los datos de acuerdo al requerimiento del usuario.

Figura 5.86. – Formulario de datos de movimientos del almacén. Fuente: Elaboración propia.

117
La figura 5.87 muestra la interfaz para generar un reporte, las interfaces de los reportes contiene
filtros específicos para cada uno de acuerdo a lo que requiere el usuario. Como primer paso se
buscará la información del reporte y luego se procederá a la impresión.

Figura 5.87. – Interfaz de generación de reportes. Fuente: Elaboración propia.

La figura 5.88 muestra el reporte generado corresponde a la entrega de raciones alimentarias, el
uso de la aplicación asegura que la información de los grupos de beneficiarios sea la
correspondiente.

Figura 5.88. – Reporte de entrega de raciones alimentarias por grupo beneficiario. Fuente:
Elaboración propia.

118
La figura 5.89 muestra el reporte de control del almacén de diferentes productos.

Figura 5.89. – Reporte de control del almacén. Fuente: Elaboración propia.

La figura 5.90 muestra el reporte de control del almacén con el formato del kárdex que
corresponde a un solo producto.

Figura 5.90. – Reporte de control del almacén en formato kárdex. Fuente: Elaboración propia.

119
La figura 5.91 muestra un reporte de estado de almacén.

Figura 5.91. – Reporte de estado de almacén. Fuente: Elaboración propia.

120
La figura 5.92 muestra el reporte del padrón de beneficiarios conteniendo los titulares y debajo
los beneficiarios, además se muestran la edad, grupo, raciones correspondientes y dirección.

Figura 5.92. – Reporte de padrón de beneficiarios. Fuente: Elaboración propia.

La figura 5.93 muestra la interfaz de listado de verificadores registrados, se accede desde el
módulo de gestión de solicitudes.

Figura 5.93. – Interfaz de lista de verificadores. Fuente: Elaboración propia.

121
La figura 5.94 muestra el formulario para el registro de verificadores, el formulario también es
abierto para actualizar datos incluyendo una opción para cambiar el estado del verificador.

Figura 5.94. – Formulario de registro de verificadores. Fuente: Elaboración propia.

La figura 5.95 muestra la interfaz de listado de productos, es accedido desde el módulo de control
del almacén.

Figura 5.95. – Interfaz de lista de productos del almacén. Fuente: Elaboración propia.

122
La figura 5.96 muestra el formulario para el registro de un producto. El formulario no permite
actualizar el stock ya que se actualiza de acuerdo a los movimientos del almacén registrados para
el producto.

Figura 5.96. – Formulario de registro de productos. Fuente: Elaboración propia.

La figura 5.97 muestra uno de los listados de mantenimiento de ítems, se accede desde el módulo
de mantenimiento seleccionando la opción deseada, en este caso corresponde a los tipos de
seguro.

Figura 5.97. – Interfaz de listado de un ítem de mantenimiento. Fuente: Elaboración propia.

123
Los formularios corresponden a un campo único donde se registra el nombre del ítem como se ve
en la figura 5.98.

Figura 5.98. – Formulario de registro de ítem. Fuente: Elaboración propia.

La figura 5.99 muestra la interfaz donde se actualiza la capacidad de raciones alimentarias que
maneja la gerencia.

Figura 5.99. – Interfaz de actualización de capacidad de raciones alimentarias. Fuente:

Elaboración propia.

124
La figura 5.100 muestra el gráfico de evolución del padrón de beneficiarios en cantidades por
grupo beneficiario, la aplicación permite exportar el gráfico a diferentes formatos de imagen.

Figura 5.100. – Gráfico de evolución del padrón de beneficiarios por grupo. Fuente:
Elaboración propia.
La figura 5.101 muestra el gráfico de distritos de donde se alojan los beneficiarios atendidos, este
gráfico se utiliza para conocer los sectores donde se puede brindar más apoyo a las personas de
bajos recursos.

Figura 5.101. – Gráfico de beneficiarios por distrito. Fuente: Elaboración propia.

125
La figura 5.102 muestra el gráfico de beneficiarios por ficha, sirve para conocer el tamaño de
hogar, asilo o refugio de las personas atendidas.

Figura 5.102. – Gráfico de beneficiarios por ficha. Fuente: Elaboración propia.

La figura 5.103 muestra el gráfico de titulares por grupo, sirve para conocer la condición de los
titulares además se visualiza que existen titulares que son encargados de iglesias, institutos
educativos, albergues, etc.

Figura 5.103. – Gráfico de titulares por grupo. Fuente: Elaboración propia.

La figura 5.104 muestra el gráfico estadístico de relación entre beneficiarios y titulares.

Figura 5.104. – Gráfico estadístico de parentescos con el titular. Fuente: Elaboración propia.

126
La figura 5.105 muestra el gráfico de cobertura de seguros, como se puede observar la mayoría
de beneficiarios no cuentan con ninguna clase de seguro de salud.

Figura 5.105. – Gráfico de cobertura de seguros de salud. Fuente: Elaboración propia.

127
 CAPÍTULO VI: RESULTADOS

a. Resultados respecto a la efectividad

Para realizar el cálculo del indicador de efectividad se realiza el cálculo de indicadores eficacia y
eficiencia de la aplicación.

 El indicador de eficacia corresponde a la relación entre funcionalidades terminadas junto con

lo propuesto, en la tabla 6.1 se muestra dicha relación. Como se puede observar se
desarrollaron todas las funcionalidades propuestas para la aplicación teniendo un porcentaje
de eficacia de 100%.

INDICADOR DE EFICACIA DE LA APLICACIÓN

MÓDULO % DE EFICACIA
Inicio 100.00
Gestión de solicitudes 100.00
Control de entregas 100.00
Control del almacén 100.00
Reportes 100.00
Mantenimiento 100.00
PROMEDIO 100.00
Tabla 6.1. – Indicador de eficacia de la aplicación. Fuente: Elaboración propia.

 La tabla 6.2 muestra el porcentaje de código duplicado en los módulos referenciando la

eficacia de código, los módulos por lo general contienen código duplicado que no fue posible
de transcribir de manera general.

INDICADOR DE EFICACIA DE CÓDIGO

MÓDULO % DE CÓDIGO DUPLICADO
Inicio 0.00
Gestión de solicitudes 4.00
Control de entregas 0.25
Control del almacén 3.00
Reportes 0.00
Mantenimiento 0.00
PROMEDIO DE CÓDIGO
1.20
DUPLICADO
PROMEDIO DE CÓDIGO
98.80
LIMPIO
Tabla 6.2. – Indicador de eficacia de código. Fuente: Elaboración propia.

128
 El indicador de eficiencia se realizó haciendo comparaciones a diferentes tiempos
relacionados al funcionamiento de la aplicación. La tabla 6.3 muestra tiempos promedios de
respuesta de la aplicación para la carga de datos, los tiempos son promediados teniendo como
el primer porcentaje de eficiencia en relación a tiempos de respuesta, los tiempos están en
segundos.

INDICADOR DE EFICIENCIA DE LA APLICACIÓNEN RELACIÓN AL

TIEMPOS DE RESPUESTA
ÍTEM TIEMPO TIEMPO % DE
ESPERADO REAL EFICIENCIA
Carga de datos de solicitudes 0.38 0.49 77.55
Carga de datos de fichas de datos 2.5 2.79 89.60
Carga de datos de beneficiarios 0.25 0.48 52.08
Carga de asistencia d beneficiarios 1.27 1.59 79.87
Carga de asistencia de transeúntes 0.53 0.63 84.12
Carga de movimientos del almacén 0.32 0.56 57.14
Carga de productos del almacén 0.10 0.24 41.66
Carga de datos para reporte de almacén 0.33 0.42 78.57
Carga de datos para reporte de entrega de 4.53 5.31 85.31
raciones alimentarias
Carga de datos para reporte de padrón de 4.20 4.43 94.80
beneficiarios
Carga de datos de lista de ítems en 0.10 0.41 24.39
mantenimiento
PROMEDIO 69.55
Tabla 6.3. – Indicador de eficiencia de la aplicación en relación a tiempos de respuesta. Fuente:
Elaboración propia.

 Para el cálculo del índice de efectividad se tiene realiza el promedio de eficacia en base a la
funcionalidad completada de la aplicación y los tiempos de respuesta resultados. Teniendo
como resultado una efectividad de 84.77%
 Además se menciona que para el desarrollo de la aplicación se han reutilizado hardware como
servidores de aplicaciones y base de datos, y software como la arquitectura que ha sido
modificada, componentes de código y librerías.

129
b. Resultados respecto a la mantenibilidad
Para el indicador de mantenibilidad, se evaluó las características del producto final que de alguna
forma determinan la mantenibilidad según Silicia Miguel-Angel (2009).

 La primera característica a evaluar es la madurez de software, esta característica evalúa la

estabilidad de un producto software. El índice de madurez es calculado utilizando la
siguiente fórmula.

(𝑀𝑡 − (𝐹𝑎 + 𝐹𝑚 + 𝐹𝑒)) ∗ 100

= Í𝑛𝑑𝑖𝑐𝑒 𝑑𝑒 𝑚𝑎𝑑𝑢𝑟𝑒𝑧 𝑑𝑒 𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒
𝑀𝑡

 Para el cálculo de proyecto desarrollado se realizaron modificaciones a los parámetros,

teniendo:
Mt = número de módulos en la versión actual = 6.
Fm = número de módulos que han sido modificados desde la puesta en producción. = 1
Fa = número de módulos que han sido añadidos desde la puesta en producción = 0.
Fe = número de módulos que han sido eliminados desde la puesta en producción = 0.

 Teniendo el siguiente resultado.

(6 − (0 + 1 + 0)) ∗ 100
= 83.33
6

 El cálculo del indicador de mantenibilidad se realizó aplicando la fórmula de Halstead.

171 − 5.2 ∗ ln (aveV) − 0.23 ∗ aveV (g ′ ) − 16.2 ∗ ln (aveLOC) + 50 ∗ sin (sqrt (2.4 ∗
perCM)) = Í𝑛𝑑𝑖𝑐𝑒 𝑑𝑒 𝑚𝑎𝑛𝑡𝑒𝑛𝑖𝑏𝑖𝑙𝑖𝑑𝑎𝑑

 Para el caso desarrollado se realiza el cálculo de las variables para los módulos, teniendo.
aveV = media del volumen por módulo.
aveV(g’) = media de la complejidad ciclomática. Corresponde a la media de cantidad de
flujos condicionales por fichero.
aveLOC = media de número de líneas de código por módulo.
perCM = media porcentual de líneas de código comentadas.

 La primera variable corresponde a la media de volumen, el volumen es calculado utilizando

la cantidad de operandos y operadores contenidos en los ficheros utilizando la siguiente
fórmula.

(𝑁1 + 𝑁2) ∗ 𝑙𝑜𝑔2((𝑛1 + 𝑛2)) = 𝑉𝑜𝑙𝑢𝑚𝑒𝑛

 Dónde:
n1 = número de operadores únicos que aparecen en un programa.
N1 = número total de ocurrencias de operadores.
N2 = número de operandos únicos que aparecen en un programa.
n2 = número total de ocurrencias de operandos.

130
 Se realizó el cálculo de volumen por módulo y se procedió a calcular la media de acuerdo a
la tabla 6.4.
MÓDULO VOLÚMEN
Inicio 237.57
Gestión de solicitudes 783.65
Control de entregas 269.50
Control del almacén 599.77
Reportes 368.59
Mantenimiento 203.44
MEDIA 410.42
Tabla 6.4. – Valores para el cálculo de la media de volumen por módulo. Fuente: Elaboración
propia.

 La siguiente variable corresponde a la media de complejidad ciclomática por módulo, la

variable es calculada realizando un conteo de rutas de acuerdo a la cantidad de
condicionales encontradas en un fichero, el valor de esta variable para el caso desarrollado
es de 4.86.
 La siguiente variable corresponde a la media de número de líneas por módulo, corresponde
a un conteo de líneas de código por fichero, para el caso desarrollado halló el valor de la
media de acuerdo a la tabla 6.5.

MEDIA DE NÚMERO DE LÍNEAS POR

MÓDULO
FICHERO EN EL MÓDULO
Inicio 158.355
Gestión de solicitudes 203.53
Control de entregas 100.49
Control del almacén 91.08
Reportes 159.50
Mantenimiento 73.5
MEDIA 131.07
Tabla 6.5. – Valores para el cálculo de la media de número de líneas por módulo. Fuente:
Elaboración propia.

 La siguiente variable a evaluar es la densidad de comentarios, mientras más documentado se

encuentre el código fuente, mayor será la mantenibilidad. La evaluación realizada
corresponde a código escrito, no incluye los modelos ya que éstos son autogenerados junto
con los ficheros de definición de módulos, la arquitectura del sistema, componentes realizados
para modificar la arquitectura, librerías y extensiones de terceros, y plantillas o páginas de
estilo. De esta manera se realiza el siguiente cálculo.

𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑙í𝑛𝑒𝑎𝑠 𝑑𝑒 𝑐𝑜𝑚𝑒𝑛𝑡𝑎𝑟𝑖𝑜 ∗ 100

= 𝐷𝑒𝑛𝑠𝑖𝑑𝑎𝑑 𝑑𝑒 𝑐𝑜𝑚𝑒𝑛𝑡𝑎𝑟𝑖𝑜𝑠
𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑙í𝑛𝑒𝑎𝑠 𝑑𝑒 𝑐ó𝑑𝑖𝑔𝑜

 Teniendo el siguiente resultado.

3,313 ∗ 100
= 18.69
17,723

131
 Finalmente se realiza el reemplazo de variables por sus respectivos valores, teniendo el
siguiente resultado.

171 − 5.2 ∗ ln (410.40) − 0.23 ∗ 12.86 − 16.2 ∗ ln (131.07) + 50 ∗ sin (sqrt (2.4 ∗
18.69)) = 93.04
 Se concluye que el índice de mantenibilidad de la aplicación tiene un valor de 93.04,
comparando este valor con la tabla 6.6 se puede observar que la aplicación tiene una
mantenibilidad alta.

MANTENIBILIDAD VALOR DEL ÍNDICE

Alto IM > 85
Moderado 65 <= IM <= 85
Bajo IM < 65
Tabla 6.6. – Límites del indicador de mantenibilidad (Omán et al, 1994; Welker et al, 1997)

 Además, gracias a la facilidad de uso de la arquitectura y la generación automática de código,

la aplicación es flexible para la implementación de cambios y nuevas funcionalidades.

c. Resultados respecto a la usabilidad

Para el cálculo de la usabilidad se realizó una encuesta a los usuarios sobre los principales
atributos explicados por Muñoz y Vianello (2017), los atributos son calificados por los usuarios
de acuerdo a la siguiente 6.7.
VALOR DE LA CORRESPONDENCIA
DEFINICIÓN
EVALUACIÓN NUMÉRICA
0: No se cumple en absoluto
0 … 10 0 1 2 3 4 5 6 7 8 9 10
10: se cumple totalmente
Tabla 6.7. – Tipologías de valores de evaluación (Muñoz, Vianello, 1997)
A continuación se muestran los resultados de los atributos.
 Facilidad de aprendizaje: se evalúa la facilidad que tuvo el usuario para utilizar la aplicación.
Los resultados se presentan en la figura 6.1.

Figura 6.1. – Resultado de facilidad de aprendizaje de la aplicación según encuesta. Fuente:

Elaboración propia.

132
 Sintetizabilidad: Capacidad del usuario para poder evaluar el efecto de las operaciones
respecto al tiempo anterior al uso de la aplicación. Los resultados se presentan en la figura
6.2.

Figura 6.2. – Resultado de sintetizabilidad de la aplicación según encuesta. Fuente: Elaboración

propia.

 Consistencia: Los mecanismos de la aplicación son usados siempre de la misma manera y

tienen los mismos efectos. Los resultados se presentan en la figura 6.3.

Figura 6.3. – Resultado de consistencia de la aplicación según encuesta. Fuente: Elaboración

propia.

133
 Flexibilidad: La aplicación permite múltiples maneras de interacción con el usuario, le
proporciona control. Los resultados se presentan en la figura 6.4.

Figura 6.4. – Resultado de flexibilidad de la aplicación según encuesta. Fuente: Elaboración

propia.

 Robustez: La aplicación ayuda a cumplir al usuario con sus objetivos. Los resultados se
presentan en la figura 6.5.

Figura 6.5. – Resultado de robustez de la aplicación según encuesta. Fuente: Elaboración propia.

134
 Recuperabilidad: Capacidad de la aplicación para corregir una acción. Los resultados se
presentan en la figura 6.6.

Figura 6.6. – Resultado de recuperabilidad de la aplicación según encuesta. Fuente: Elaboración

propia.

 Tiempos de respuesta: Los tiempos de respuesta del producto deben ser soportados por el
usuario. Los resultados se presentan en la figura 6.7.

Figura 6.7. – Resultado de tiempos de respuesta de la aplicación según encuesta. Fuente:

Elaboración propia.

135
 Adecuación de las tareas: La aplicación se ajusta a las tareas y capacidades del usuario. Los
resultados se presentan en la figura 6.8.

Figura 6.8. – Resultado de adecuación a las tareas de la aplicación según encuesta. Fuente:
Elaboración propia.

 Disminución de la carga cognitiva: La aplicación favorece un uso basado en reconocimiento

más que en los recuerdos. Los resultados se presentan en la figura 6.9.

Figura 6.9. – Resultado de disminución de la carga cognitiva de la aplicación según encuesta.

Fuente: Elaboración propia.

136
 Se concluye, promediando los atributos de usabilidad, que la aplicación tiene un índice de
usabilidad de 84.91%.
 Además se realiza la entrega de manual de la aplicación de los usuarios como apoyo a la
facilidad de aprendizaje de la aplicación.
 Los usuarios además cuentan con el apoyo del personal de la Gerencia de Informática para
resolver las dudas presentadas.

d. Resultados respecto a la disponibilidad

Para el cálculo de la disponibilidad se tomó como muestra los tiempos de funcionamiento de
diferentes componentes necesarios para brindar el servicio a los usuarios entre los meses de
octubre y noviembre del año 2018 en un horario de lunes a viernes de 8:00 a.m. a 17 p.m., teniendo
los resultados en la tabla 6.8.

COMPONENTE DESCRIPCIÓN DISPONIBILIDAD

Contiene las aplicaciones a las
Servidor de aplicaciones 99.59%
cuales acceden los usuarios.
Aplicación desarrollada para la
Aplicación de Gestión de
Gerencia General de Programas 99.54%
Programas Sociales
Sociales.
Contiene el motor de base de
Servidor de base de datos 99.66%
datos.
Contiene las bases de datos
Motor de base de datos necesarias para el funcionamiento 99.55%
de la aplicación.
Contiene ficheros con los
Servidor de archivos documentos adjuntados por los 99.03%
usuarios.
DISPONIBILIDAD PROMEDIO 99.47%
Tabla 6.8. – Disponibilidad de los componentes de la aplicación. Fuente: Elaboración propia.

 Se concluye que se tiene una alta disponibilidad para que la aplicación pueda ser utilizada por
los usuarios en cualquier momento de su actividad laboral.
 Además la Gerencia de Informática dispone de personal encargado de mantener los equipos
y aplicaciones.
 El efecto del mantenimiento de la aplicación mínimo, esto debido al uso de un repositorio que
permite que los cambios realizados se manifiesten de forma rápida en el servidor de
producción que contienen la aplicación.
 Además la aplicación puede ser accedida mediante navegadores móviles con previa
coordinación con la Gerencia de Informática.

137
e. Resultados respecto a las metas de negocio

 Sobre la corrección de datos erróneos e incompletos, la aplicación apoyó en la corrección de

datos de los beneficiarios, ya que se cuenta con los registros de datos personales de la mayor
parte de beneficiarios. Se tomó como muestra los padrones del mes de abril del año 2018
donde se tiene el padrón de beneficiarios inicial para el funcionamiento de la aplicación,
teniendo los resultados que se muestran en la tabla 6.9.

CANTIDAD DE
CANTIDAD DE % DE
MES BENEFICIARIOS CON DATOS
BENEFICIARIOS CORRECIÓN
ERRÓNEOS
Abril 596 171 92%
Tabla 6.9. – Resultados de corrección de datos erróneos en el padrón de beneficiarios. Fuente:
Elaboración propia.

 La cantidad de beneficiarios cuyos datos no han sido corregidos corresponde en su mayoría

a personas de tercera edad que no tienen ninguna clase de identificación, o niños menores que
no cuentan con documentos de identidad.
 Además se encontró que los padrones de beneficiarios realizados de forma manual en el año
2018 que no reflejan la cantidad real de beneficiarios, estos beneficiarios están identificados
en la aplicación, la cantidad de beneficiarios se muestran en el siguiente gráfico.

Figura 6.10. – Cantidad de beneficiarios faltantes por mes. Fuente: Elaboración propia.

 Sobre la información de control del almacén, se encontraron errores de cálculos en los

formatos manuales, los errores se manifiestan en los siguientes registros y por consiguiente
en el stock de los productos. Se recaudó información de los registros del mes de enero y
febrero para ser corregidos teniendo los resultados en la siguiente tabla.

CANTIDAD DE
CANTIDAD DE
ITEM REGISTROS % DE CORRECIÓN
REGISTROS
ERRÓNEOS
Kárdex 566 71 100%
Stock de 85 6 100%
productos

138
 Tabla 6.10. – Resultados de corrección de datos erróneos en el control del almacén. Fuente:
Elaboración propia.

 Sobre los tiempos de generación de reportes, la aplicación tiene disponibilidad de toda la

información y el conteo de data se realiza de forma automática, en consecuencia los tiempos
de generación de reportes disminuyeron de acuerdo a la siguiente tabla.

TIEMPO TIEMPO
PROMEDIO DE PROMEDIO DE
GENERACIÓN DE GENERACIÓN
% DE
TIPO DE REPORTE REPORTES ANTES DE REPORTES
REDUCCIÓN
DE LA CON EL
IMPLEMENTACIÓN SISTEMA
DEL SISTEMA IMPLEMENTADO
Padrón de beneficiarios 1h 25m 6s 99.99%
Entrega de raciones
2h 35m 11.3s 99.99%
alimentarias
Movimientos del
43m 11.9s 99.99%
almacén
Estado del almacén 1h 30m 2s 99.99%
Tabla 6.11. – Resultados de reducción de tiempo de generación de reportes. Fuente: Elaboración
propia.

 Los tiempos de generación de reporte fueron disminuidos a segundos, además se pudieron

generar nuevos tipos de reportes que la Gerencia General de Programas Sociales no contaba.

f. Resultados respecto a los indicadores de variables dependientes

 Sobre el volumen de datos manejado, previamente a la implementación de sistema, la
información era manejada en un documento Excel, el documento contenía información
principal de los beneficiarios, como sus datos personales, grupo beneficiario, dirección, etc.
Teniendo así 28 campos especificados, además los documentos como el acta de supervisión
y las cartas de notificación a las beneficiarias no eran tomadas en cuenta. Comparando los
campos de datos más importantes de los formularios en la aplicación para los módulos de
gestión de solicitudes y control de entregas con los campos del documento de padrón de
beneficiarios se puede apreciar que hay un incremento en los datos manejados de acuerdo a
la siguiente figura.

139
 Figura 6.11. – Volumen de datos manejados. Fuente: Elaboración propia.

 El volumen de datos en el control del almacén no sufrió cambios, sin embargo se solicitó la
creación de una guía de salida para formalizar los movimientos realizados en el almacén.
 Además se cuenta la implementación del sistema permitió el manejo de nuevos reportes
solicitados por la gerencia como son: reporte de raciones alimentarias entregadas por semana,
mes, trimestre y año, relación de beneficiarios y transeúntes atendidos, reporte de asistencia
de beneficiarios y transeúntes específicos.
 La figura 6.12 muestra la cantidad de registros realizados en la aplicación sobre la gestión de
solicitudes desde inicios de abril del 2018.

Figura 6.12. – Cantidad de registros en el módulo de gestión de solicitudes. Fuente: Elaboración

propia.

 La figura 6.13 muestra la cantidad de registros realizados en la aplicación sobre la entrega de

raciones alimentarias desde inicios de abril del 2018.

140
 Figura 6.13. – Cantidad de registros en el módulo de control de entregas. Fuente: Elaboración
propia.

 La figura 6.14 muestra la cantidad de registros realizados en la aplicación sobre el control del
almacén desde inicios de enero del 2018.

Figura 6.14. – Cantidad de registros en el módulo de control del almacén. Fuente: Elaboración
propia.

 Sobre la cantidad de errores en la información manejada, revisar las tablas 6.9 y 6.10, y la
figura 6.11.
 Sobre la cantidad de registros manipulados o modificados. Se realizó un conteo de registros
teniendo como muestra los meses de 24 de septiembre y 7 de diciembre del 2018 teniendo los
siguientes resultados.
CANTIDAD DE CANTIDAD CANTIDAD
ÍTEM
REGISTROS MODIFICADOS ELIMINADOS
Fichas/solicitudes 2 2 30

141
 Actas de supervisión 2 0 0
Beneficiarios 22 22 46
Entrega de raciones
13767 1654 0
a beneficiarios
Entrega de raciones
2850 0 35
a transeúntes
Movimientos en el
1187 7 1
almacén
Tabla 6.12. – Resultados sobre la cantidad de registros manipulados o modificados. Fuente:
Elaboración propia.

 Como se puede observar existe una cantidad considerable de registros realizados por los
usuarios, las modificaciones realizadas corresponden en su mayoría a actualizaciones de
datos, como por ejemplo estados de las fichas y beneficiarios, así como los registros
eliminados para fichas y beneficiarios. Además se mantienen registrados los datos de los
usuarios y la fecha y hora de modificación y eliminación de registros.
 Sobre la categorización de datos, se tiene la categoría de grupo beneficiario para todos los
beneficiarios y transeúntes registrados, además la aplicación muestra una sugerencia de
categoría en el instante que se está realizando el registro de beneficiarios y transeúntes.
Además las categorías de los beneficiarios son actualizados automáticamente de acuerdo a su
edad para ciertos casos, de esta manera se garantiza que la información se mantenga
actualizada.

142
 CONCLUSIONES
La aplicación de Gestión de Programas Sociales para la Gerencia General de Programas Sociales
influyó positivamente en la gestión de la información del Programa Comedor del Pueblo.
La efectividad de la aplicación web influyó positivamente en la gestión de la información, ya que
se concluyó con la funcionabilidad esperada y se obtuvieron tiempos de respuesta consistentes.
Además, se mitigaron en su totalidad los problemas de información errónea y casi en su totalidad
la información incompleta, igualmente se redujeron los tiempos de trabajo para la generación de
reportes, teniendo nivel de efectividad del 84.77%.
La mantenibilidad de la aplicación web influyó positivamente en la gestión de la información,
teniendo el código documentado y bien organizado permite que se puedan analizar y solucionar
los problemas encontrados de manera eficiente. La organización de la arquitectura y generación
automática de código permite que la aplicación sea flexible para la implementación de cambios y
nuevas funcionalidades, teniendo un nivel de mantenibilidad alto.
La usabilidad de la aplicación web influyó positivamente en la gestión de la información, la
capacitación de usuarios y la creación de interfaces en base a prototipos permitieron que la
aplicación sea entendible por los usuarios; sin embargo la cantidad de datos manejados por la
aplicación puede ser reducir la facilidad de aprendizaje para lo cual se realizó al entrega de
manuales para los usuarios. Igualmente la aplicación pueda cumplir con los objetivos
adecuándose a las tareas del usuario, por ejemplo para la atención de albergues, institutos
educativos, etc., teniendo finalmente un nivel de usabilidad de 84.91%.
La disponibilidad de la aplicación web influyó positivamente en la gestión de la información, ya
que el sistema cuenta con una disponibilidad alta y personal que le brinde soporte. Además ya
que se ofrece una aplicación web las funcionalidades nuevas, cambios o correcciones realizadas
pueden ser visualizados instantáneamente por los usuarios sin necesidad de que tengan que ser
expulsados de la aplicación, teniendo así una disponibilidad de 99.47%.

143
 RECOMENDACIONES

 Se recomienda la realización de un convenio con el Registro Nacional de Identificación y

Estado Civil (RENIEC), para la autenticación exacta de personas mediante su número de
documento de identificación.
 Se recomienda agregar funcionalidades para generar documentos como cartas y reportes
según lo que necesite la Gerencia General de Programas Sociales.
 Se recomienda establecer el uso de datos obligatorios para la formalización de los procesos
pertenecientes a la gerencia para la cual se desarrollan las aplicaciones.
 Se recomienda agregar la funcionalidad de generación de carnets de identificación únicos
para el Programa Comedor del Pueblo, sólo si la Gerencia General de Programas Sociales
establece el uso obligatorio de éstos.
 Se recomienda agregar funcionalidades para la gestión de información de otros programas
sociales por ejemplo el Programa Vaso de Leche.
 Si se considera óptimo se recomienda agregar opciones para la presentación de solicitudes de
pertenencia al padrón mediante el portal municipal, esto favorece principalmente a las
personas encargadas de asilos, albergues, institutos, etc.
 Se recomienda la adaptación de metodologías de desarrollo de software de acuerdo a las
necesidades de la gerencia que desarrolla la aplicación, así como la reutilización de recursos
que dispongan.

144
REFERENCIAS BIBLIOGRÁFICAS

Alfonzo, P. L., & Mariño, S. I. (2013). Los estándares internacionales y su importancia para la
industria del software.
Alva, R. (2014), Análisis, diseño e implementación de un sistema de información para el apoyo
al proceso de toma de decisiones en la ejecución de proyectos sociales de una municipalidad
provincial, Tesis para optar el título de Ingeniero Informático en la Pontificia Universidad
Católica del Perú, Lima, Perú.
Alvear, A., Quintero, G. (2014). Integrating software development techniques, Usability, and
Agile Methodologies Desarrollo de Software Integrando Técnicas de Usabilidad y
Metodologías Agiles.
Ambler, S. (2010). The Object Primer. Third Edition. Agile Model-Driven Development with
UML 2.0. Cambridge University Press, Cambridge, Reino Unido.
Ayala, E. (2010). Calidad de Sofware. Tesis para obtener el título de Licenciado en Ciencias de
la Informática en la Universidad Profesional Interdisciplinaria de Ingeniería y Ciencias
Sociales y Administrativas, México D.F., México.
Bonilla, C. y Guerrero E. (2014). Evaluación del programa municipal “Comedores Populares”
de la Municipalidad Provincial de Lambayeque. Caso: Distrito Lambayeque. Año 2007 –
2012. Tesis para optar el título de Economista en la Universidad Católica Santo Toribio de
Mogrovejo, Chiclayo, Perú.
Díaz, J. R. (2009). Las metodologías ágiles como garantía de calidad del software. REICIS.
Revista Española de Innovación, Calidad e Ingeniería del Software, 5(3), 40-43.
Doria, H. G. (2001). Las Metricas de Software y su Uso en la Region. Tesis para obtener el título
de Licenciado en Ingeniería en Sistemas Computacionales en la Universidad de las Américas
de Puebla, Puebla, México.
Edeki, C. (2013). Agile unified process. International Journal of Computer Science, 1(3).
Fernández, Juan M.; Cadelli, S. (2014), Convivencia de metodologías: Scrum y Rup en un
proyecto de gran escala. Telem@ tica (La Habana), 11(1), 47-57.
Fernández Romero, Y., & Díaz González, Y. (2012). Patrón Modelo-Vista-Controlador. Telem@
tica (La Habana), 11(1), 47-57.
Guzmán M. (2018). Construcción de un Sistema de Alta Disponibilidad para manejo de
documentos. Tesis para obtener el título de Ingeniero en Telemática en la Universidad Distrital
Francisco José de Caldas, Bogotá, Colombia.
Hansmann, U., Stober T. (2009). Agile Software Development, Best Practices for Large Software
Development Projects. Springer-Verlag, Berlin, Alemania.
Hernández, J. & de la Cruz, A. (2011). Sistema de apoyo a la gestión del departamento de
dirección de desarrollo comunitario de la Ilustre Municipalidad de San Nicolás. Tesis para

145
 obtener el título de ingeniero de ejecución en computación e informática en la Universidad del
Bío-Bío, Región del Bío Bío, Chile.
Herrera Uribe, E., & Valencia Ayala, L. (2007). Del manifiesto ágil sus valores y principios.
Scientia Et Technica, XIII (34), 381-386.
Huanca, C. (2015), Sistemas de información para la administración de programas sociales
(SIAPS) en la Municipalidad Provincial de Azángaro, Tesis para optar el título de Ingeniero
Estadístico e Informático en la Universidad Nacional del Altiplano, Puno, Perú.
Huayamares, L. (2012), Implementación de un sistema de información para el área de registro
civil, en la Municipalidad Distrital de Pueblo Nuevo, Tesis para optar el título de Ingeniero de
Sistemas en la Universidad Privada Ada A. Byron S.A.C, Ica, Perú.
Laudon, K, Laudon J.P. (2004), Sistema de Información Gerencial, decimosegunda edición. New
York, Estados Unidos de América: Editorial Pearson.
Lisana S. (2014), Review on the effectivness of Agile Unified Process in software development
with vague system requiremen. ARPN Journal of Engineering and Applied Sciences 9(10).
Lozano, H. (2017), Análisis y desarrollo de un sistema web para la gestión kárdex de un almacén.
Tesis para optar el grado de máster en ingeniería web en la Universidad Politécnica de Madrid,
Madrid, España.
Makarov, A. (2011). Yii 1.1 Application Development Cookbook. Packt Publishing Ltd 392(31).
Martín, A. R., & Martín, M. J. R. (2014). Aplicaciones web. Ediciones Paraninfo, SA.
Mascheroni, M. A., Greiner, C. L., Dapozo, G. N., & Estayno, M. G. (2013). Ingeniería de
Usabilidad. Una Propuesta Tecnológica para Contribuir a la Evaluación de la Usabilidad del
Software. Revista Latinoamericana de Ingeniería de Software, 1(4), 125-134.
Mateu, C. (2004). Desarrollo de aplicaciones web. (1ra ed). Catalunya: Fundación para la
Universitar Oberta de Catalunya.
Moreno, A. M., & Sánchez-Segura, M. (2003). Patrones de Usabilidad: Mejora de la Usabilidad
del Software desde el Momento Arquitectónico. In JISBD (pp. 117-126).
Municipalidad Provincial del Callao (2017), Ordenanza Municipal Nº 032-2017.
Municipalidad Provincial del Callao (2017), Presupuesto Participativo Basado en Resultados
2017Municipalidad Provincial del Callao Rendición de cuentas 2015 I Trimestre 2016,
recuperado el 29 de enero del 2018 de: http://www.municallao.gob.pe/index.php/presupuesto-
participativo-2016.
Object Management Group, UML (2017), Unified Modeling Language 2.5.1. Massachusetts,
Estados Unidos de América: Object Management Group.
Pérez-González, Héctor y Martínez, Francisco y Nava, Sandra y Varela, Alberto y Vázquez
Escalante, Miriam y Antonio Flores Saucedo, J. (2015). Analizando la Mantenibilidad de
Software Desarrollado Durante la Formación Universitaria. Revista Latinoamericana de
Ingeniería de Software, 3(6).

146
Riascos Erazo, S. C. (2008). Modelo para la evaluación de la efectividad de la tecnología
informática en el entorno empresarial. Ingeniería e investigación, 28(2).
Rodríguez, M., Pedreira, Ó., y Fernández, C. M. (2015). Certificación de la mantenibilidad del
producto software: Un caso práctico. Revista Latinoamericana de Ingeniería de Software,
3(3), 127-134.
Rodríguez Salas, K. (2012). Gestión de la información en las organizaciones, recuperado el 05
de agosto del 2018 de:
http://repositorio.una.ac.cr/bitstream/handle/11056/2712/recurso_809.pdf
Sicilia, M. (2009). Métricas de mantenimiento de software, recuperado el 03 de diciembre del
2018 de: https://cnx.org/exports/a0484c7c-5b86-4ef2-9f7e-
[email protected]/m%C3%A9tricas-del-mantenimiento-de-software-9.1.pdf
Sommerville, I. (2005). Ingeniería del software 7ma. Ed. Pearson Educación, Madrid, España.
Quispe, M. (2017), Impacto de los programas sociales en la disminución de la pobreza,
Pensamiento Crítico, 22(1).
Távara, I. (2014), Mejora en el sistema para optimizar la gestión logística de la empresa
comercial Piura, Tesis para optar el título de Ingeniero Industrial en la Universidad Nacional
de Piura, Piura, Perú.
Vazques E. (2006), Programas sociales ¿de lucha contra la pobreza?: casos emblemáticos,
recuperado el 06 de febrero del 2018 de:
https://www.mef.gob.pe/contenidos/pol_econ/documentos/Programas_Sociales_EVasquez.p
df.
Welker, K.D., Oman, P.W., & Atkinson, G.G (1997), Development and application of an
automated source code maintainability Index. In Journal of Software Maintenance, vol. 9(3),
127-159 pp.

147
 ANEXO I: MATRIZ DE CONSISTENCIA INTERNA

PROBLEMAS OBJETIVOS HIPÓTESIS VARIABLES INDICADORES

¿En qué medida la aplicación web Determinar la influencia de la La aplicación web influye INDEPENDIENTE:  Nivel de efectividad.
GENERAL

influye en la mejora en la gestión aplicación web para la mejora en significativamente en la mejora en la  Nivel de
de la información de los la gestión de la información de los gestión de la información de los Aplicación web. mantenibilidad.
Programas Sociales en la Programas Sociales en la Programas Sociales en la  Nivel de usabilidad.
Municipalidad Provincial del Municipalidad Provincial del Municipalidad Provincial del Callao.  Nivel de disponibilidad.
Callao? Callao.
¿En qué medida el nivel de Determinar la influencia del nivel El nivel de efectividad de la DEPENDIENTE:  Volumen de la
efectividad de la aplicación web de efectividad de la aplicación web aplicación web influye información manejada.
influye en la mejora en la gestión para la mejora en la gestión de la significativamente en la mejora en la Mejora en la gestión de  Cantidad de errores en
de la información de los información de los Programas gestión de la información de los la información de los la información
Programas Sociales en la Sociales en la Municipalidad Programas Sociales en la Programas Sociales en manejada.
Municipalidad Provincial del Provincial del Callao. Municipalidad Provincial del Callao la Municipalidad  Cantidad de registros
Callao? Provincial del Callao. manipulados o
¿En qué medida el nivel de Determinar la influencia del nivel El nivel de mantenibilidad de la modificados.
mantenibilidad de la aplicación de mantenibilidad de la aplicación aplicación web influye  Porcentaje de
web influye en la mejora en la web para la mejora en la gestión de significativamente en la mejora en la información
gestión de la información de los la información de los Programas gestión de la información de los categorizada en
Programas Sociales en la Sociales en la Municipalidad Programas Sociales en la relación al tiempo
ESPECÍFICO

Municipalidad Provincial del Provincial del Callao. Municipalidad Provincial del Callao. previo a la
Callao? implementación del
¿En qué medida el nivel de Determinar la influencia del nivel El nivel de usabilidad de la aplicación sistema.
usabilidad de la aplicación web de usabilidad de la aplicación web web influye significativamente en la
influye en la mejora en la gestión para la mejora en la gestión de la mejora en la gestión de la
de la información de los información de los Programas información de los Programas
Programas Sociales en la Sociales en la Municipalidad Sociales en la Municipalidad
Municipalidad Provincial del Provincial del Callao. Provincial del Callao.
Callao?
¿En qué medida el nivel de Determinar la influencia del nivel El nivel de disponibilidad de la
disponibilidad de la aplicación de disponibilidad de la aplicación aplicación web influye
web influye en la mejora en la web para la mejora en la gestión de significativamente en la mejora en la
gestión de la información de los la información de los Programas gestión de la información de los
Programas Sociales en la Sociales en la Municipalidad Programas Sociales en la
Municipalidad Provincial del Provincial del Callao. Municipalidad Provincial del Callao.
Callao?

148
 ANEXO II: ENCUESTA DE EVALUACIÓN DE USABILIDAD DE LA
APLICACIÓN

VALOR DE LA CORRESPONDENCIA
DEFINICIÓN
EVALUACIÓN NUMÉRICA
0: No se cumple en absoluto
0 … 10 0 1 2 3 4 5 6 7 8 9 10
10: se cumple totalmente
Por favor responda de acuerdo a los valores presentados.

 ¿La aplicación es accesible y fácil de usar para realizar sus operaciones?

1 – 2 – 3 – 4 – 5 – 6 -7 – 8 – 9 – 10

 ¿Notó el efecto en las operaciones después de la puesta en producción de la aplicación?

1 – 2 – 3 – 4 – 5 – 6 -7 – 8 – 9 – 10

 ¿Al utilizar la aplicación en sus operaciones se utiliza siempre de la misma manera y se

obtienen los resultados esperados?

1 – 2 – 3 – 4 – 5 – 6 -7 – 8 – 9 – 10

 ¿La aplicación le proporciona control en sus operaciones?

1 – 2 – 3 – 4 – 5 – 6 -7 – 8 – 9 – 10

 ¿Piensa que la aplicación le ayuda a cumplir con sus objetivos?

1 – 2 – 3 – 4 – 5 – 6 -7 – 8 – 9 – 10

 ¿La aplicación le facilita corregir acciones y errores que pueda cometer?

1 – 2 – 3 – 4 – 5 – 6 -7 – 8 – 9 – 10

 Indique su satisfacción respecto a los tiempos de respuesta de la aplicación.

1 – 2 – 3 – 4 – 5 – 6 -7 – 8 – 9 – 10

 ¿La aplicación se ajusta a sus tareas y a la información que maneja?

1 – 2 – 3 – 4 – 5 – 6 -7 – 8 – 9 – 10

 ¿La aplicación muestra información de manera sustancial, de forma que usted no tiene que

recordar tal información?

1 – 2 – 3 – 4 – 5 – 6 -7 – 8 – 9 – 10

149