Rolando Soriano - Jack Osorio - Trabajo de Suficiencia Profesional - Titulo Profesional - 2017

Facultad de Ingeniería
Ingeniería de Sistemas e Informática
Trabajo de Suficiencia Profesional:
“DESARROLLO DE UNA APLICACIÓN

WEB PARA EL REGISTRO DE LOS
PROGRAMAS NO ESCOLARIZADOS DE
EDUCACIÓN INICIAL”
Bachilleres:
Rolando Soriano Salazar
Jack Jimmy Osorio Julca
Para optar el Título Profesional de Ingeniero de

Sistemas e Informática
Lima – Perú
2017

DEDICATORIA

A mis hermanos que siempre están presente en los malos y buenos momentos
siempre apoyándome incondicionalmente y así lograr mis objetivos
profesionales.
A mi madre Gloria aunque ahora guiándome desde el cielo, por ser una mujer
luchadora apoyándome incondicionalmente y guiarme por el camino del bien y
a tomar buenas decisiones. Gracias a sus enseñanzas, comprensión y los
valores que me brindaste me forjaron a ser un profesional.
Y a mi padre Claudio que aunque no estés presente, me dejaste tus

enseñanzas, valores y sobre todo aprender a amar las cosas que uno hace y
así lograr a ser un profesional.
JACK

A mis amigos, por su compañía, por todos los buenos momentos vividos, por la
confraternidad, confianza, respeto y solidaridad que existe en el grupo y por el
impulso a lograr mis objetivos de vida.
A mi madre Rosa por el apoyo constante para lograr mis objetivos personales y
profesionales, por tu dedicación a tu esposo e hijos, gracias por todo tu tiempo
madre.
Y a ti padre Manuel, que aunque estemos en mundos diferentes siempre te voy

a llevar en mi corazón, guardaré para siempre los momentos alegres vividos a
tu lado. Gracias por todas tus enseñanzas, por la confianza y el apoyo
incondicional para lograr mis objetivos personales y profesionales y haberme
forjado una persona con valores, disciplina y responsabilidad.
ROLANDO

1

RESUMEN
El presente Trabajo de Suficiencia Profesional, fue creado con la finalidad de

optimizar el proceso de creación y/o actualización de los Programas No Escolarizados
de Educación Inicial.
En la actualidad el proceso de creación y/o actualización de los programas no
escolarizados de educación inicial es monitoreado por la Unidad de Estadística (UE)
del Ministerio de Educación (MINEDU), a través de sus Instancias de Gestión
Educativa Descentralizada (IGED), 220 Unidades de Gestión Educativa Local (UGEL),
22 Direcciones Regionales de Educación (DRE) y 4 Gerencias Regionales de
Educación (GRE).
El problema principal es un deficiente proceso de registro y/o modificación de
datos, ya que este proceso se realiza en una aplicación local y de forma aislada, las
solicitudes de creación y/o modificación se envían mediante correo electrónico,
causando las siguientes problemáticas, duplicidad en el envío de solicitudes de
requerimiento y demora en el retorno de respuesta de las solicitudes requeridas.
El objetivo principal es desarrollar e implementar una aplicación WEB que
permita realizar el proceso de registro y/o modificación de datos de los Programas No
Escolarizados de Educación Inicial, a través del uso de un lenguaje de programación
web.
El presente Trabajo de Suficiencia profesional, está dividido en el
planteamiento del problema, las herramientas tecnológicas utilizadas, ejemplos de
soluciones a similares problemáticas, análisis y diseño de la solución y conclusiones
finales.
Finalmente se presenta el “Desarrollo de una aplicación WEB para el registro,
creación y/o modificación delos Programas No Escolarizados de Educación Inicial” el
cual nos permitirá optimizar recursos de la Unidad de Estadística tanto humanos como
económicos, el padrón de los Programas No Escolarizados de Educación Inicial se
mantendrá actualizado y será de vital importancia para el Sector Educación ya que
permitirá conocer la realidad educativa de estos programas, para una mejor toma de
decisiones, esto generará una rápida y versátil distribución de los recursos materiales
y económicos.

2

3

ÍNDICE
Contenido
CAPÍTULO 1 .................................................................................................................. 9.
ASPECTOS GENERALES ............................................................................................ 9.
1.1 Definición del Problema .................................................................................. 9.
1.1.1 Descripción del Problema ............................................................................ 9.
1.1.2 Formulación del Problema ......................................................................... 10.
1.2 Definición de Objetivos.................................................................................. 10.
1.2.1 Objetivo General ........................................................................................ 10.
1.2.2 Objetivos Específicos ................................................................................ 11.
1.2.3 Alcances y Limitaciones ............................................................................ 11.
1.2.4 Justificación ............................................................................................... 11.
1.2.5 Estado del Arte .......................................................................................... 12.
1.2.5.1 Registro de Historias Clínicas Electrónicas para un Hospital ................... 12.
1.2.5.2 Aplicación de Control de Inventario y Rastreo de Puntos de Venta ......... 12.
CAPÍTULO 2 ................................................................................................................ 14.

MARCO TEÓRICO ...................................................................................................... 14.
2.1 Aspectos generales ....................................................................................... 14.
2.1.1 Rol de la Unidad de Estadística del Ministerio de Educación ..................... 14.
2.2 Definiciones Teóricas .................................................................................... 14.
2.2.1 Aplicaciones web ......................................................................................... 14.
2.2.2 Metodología RUP ........................................................................................ 16.
2.2.2.1 Evaluación de la mejor solución................................................................. 18.
2.2.2.2 Principios del RUP ..................................................................................... 18.
2.2.2.3 Ciclo de vida del RUP ................................................................................ 20.
2.2.3 Base de Datos ............................................................................................. 21.
2.2.3.1 Introducción.............................................................................................. 21.
2.2.3.2 Historia de los sistemas de base de datos ............................................... 22.
2.2.3.3 Personas en el entorno de las bases de datos ........................................ 23.
2.2.4 MySQL ........................................................................................................ 24.
2.2.4.1 Sistema de gestión de bases de datos ..................................................... 24.
2.2.4.2 Ventajas e inconvenientes de los sistemas de bases de datos ................ 25.
2.2.5 HTML........................................................................................................... 30.
2.2.5.1 Descripciones previas .............................................................................. 30.
2.2.5.2 Introducción al lenguaje HTML ................................................................ 30.
2.2.6 JAVA ............................................................................................................. 33.
4

2.2.6.1 Una primera reflexión acerca de Java ...................................................... 33.
2.2.6.2 Java como lenguaje y plataforma de programación .................................. 33.
2.2.6.3 Historia de java .......................................................................................... 33.
CAPÍTULO 3 ................................................................................................................ 37.

DESARROLLO DE LA SOLUCIÓN ............................................................................. 37.
3.1 Breve descripción de la solución........................................................................ 37.
3.2 Situación actual ............................................................................................. 38.
3.2.1 Problemática ............................................................................................... 38.
3.2.2 Definición de requerimientos....................................................................... 39.
3.2.3 Requerimientos de validación ..................................................................... 40.
3.2.4 Requerimientos de entrenamiento al usuario ............................................. 40.
3.3 Diagramas de caso de uso del negocio ........................................................ 41.
3.4 Diagrama del sistema.................................................................................... 43.
3.4.1 Diagrama de paquetes ............................................................................... 43.
3.4.2 Diagrama de actores .................................................................................. 43.
3.4.3 Diagrama de actores del sistema ............................................................... 44.
3.5 Diagrama de caso de uso por paquetes ....................................................... 44.
3.5.1 Paquete de registro de programas ............................................................. 44.
3.5.2 Paquete de gestión de requerimientos....................................................... 46.
3.6 Especificación de casos de uso del sistema ................................................. 47.
3.6.1 Especificación de paquetes........................................................................ 47.
3.6.2 Especificación de actores........................................................................... 47.
3.6.3 Especificación de casos de uso ................................................................. 47.
3.7 Diagrama de actividades ............................................................................... 58.
3.8 Diagrama de secuencia................................................................................. 70.
3.8.1 Diagrama de secuencia: solicitud de creación y renovación ..................... 70.
3.8.2 Diagrama de secuencia: revisión de solicitud de creación y renovación .. 71.
3.9 Diagrama de colaboración ............................................................................ 72.
3.9.1 Diagrama de colaboración: solicitud de creación y renovación ................. 72.
3.9.2 Diagrama de colaboración: revisión de solicitud de creación y renovación 73.
3.10 Diagrama de estado ................................................................................... 74.
3.10.1 Diagrama de estado: solicitud de creación y renovación ......................... 74.
3.10.2 Diagrama de estado: revisión de solicitud de creación y renovación ......... 75.
3.11 Diagrama de componentes ........................................................................... 76.
3.12 Diagrama de despliegue ............................................................................... 77.
3.13 Modelo Entidad Relación .............................................................................. 78.
5

3.13.1 Modelo conceptual de la BD ....................................................................... 78.
3.13.2 Modelo lógico de la BD ............................................................................... 79.
3.13.3 Modelo físico de la BD ................................................................................ 80.
3.13 Prototipo ........................................................................................................ 81.
3.13.1 Introducción................................................................................................. 81.
3.13.2 Objetivos ..................................................................................................... 81.
3.13.3 Alcances...................................................................................................... 81.
3.13.4 Diseño de Interfaces ................................................................................... 81.
3.13.4.1 Mapa de navegación del Sistema ........................................................... 81.
3.13.4.2 Caso de Uso: Ingreso al sistema ............................................................ 82.
3.13.4.3 Caso de Uso: Solicitud de creación de programa ................................... 82.
3.13.4.4 Caso de Uso: Renovación de un programa ............................................ 83.
3.13.4.5 Caso de Uso: Modificación de un programa ........................................... 85.
3.13.4.6 Caso de Uso: Cierre de un programa ..................................................... 87.
3.13.4.7 Caso de Uso: Solicitudes en proceso ..................................................... 87.
3.13.4.8 Caso de Uso: Historial de solicitudes...................................................... 88.
3.13.4.9 Caso de Uso: Reportes del padrón ......................................................... 89.
3.13.4.10 Caso de Uso: Control de avance ............................................................ 90.
3.13.4.11 Caso de Uso: Crear usuarios .................................................................. 91.
3.13.4.12 Caso de Uso: Modificar usuarios ............................................................ 91.
3.13.4.13 Caso de Uso: Inhabilitar usuarios ........................................................... 92.
3.13.4.14 Caso de Uso: Eliminar solicitud .............................................................. 93.
3.13.4.15 Caso de Uso: Eliminar programa ............................................................ 93.
3.13.4.16 Caso de Uso: Gestionar coordinadores .................................................. 94.
3.14. Pruebas de software .................................................................................... 95.
3.14.1 Pruebas funcionales................................................................................... 96.
3.14.2 Pruebas unitarias ....................................................................................... 96.
3.14.3 Reporte de observaciones .......................................................................... 96.
3.14.3.1 Gestión de solicitudes - solicitudes en proceso ..................................... 97.
3.14.3.2 Registrar solicitud de creación ............................................................... 97.
3.14.3.3 Acceso al sistema .................................................................................. 98.
3.14.3.4 Modificación de datos ............................................................................... 99.
3.14.3.5 Gestión de solicitudes - solicitudes en proceso ...................................... 100.
CAPÍTULO 4 .............................................................................................................. 103.

RESULTADOS .......................................................................................................... 103.
4.1 Resultados .................................................................................................. 103.
6

4.2 Planificación del tiempo............................................................................... 104.
4.2.1 Cronograma del proyecto ......................................................................... 104.
4.3 Hitos del proyecto ........................................................................................ 106.
4.4 Conclusiones ............................................................................................... 106.
4.5 Planificación de los costos ........................................................................... 106.
4.5.1 Recurso humano ..................................................................................... 106.
4.5.2 Recurso tecnológico ................................................................................ 107.
4.5.3 Otros gastos ............................................................................................ 107.
4.5.4 Cuadro de asignación de recursos .......................................................... 108.
4.5.5 Flujo del proyecto .................................................................................... 108.
4.5.6 Flujo de caja ............................................................................................ 109.
4.5.7 tasa de descuento VAN y TIR del proyecto ............................................. 109.
CONCLUSIONES ...................................................................................................... 111.

RECOMENDACIONES.............................................................................................. 112.
GLOSARIO ................................................................................................................ 113.
BIBLIOGRAFÍA .......................................................................................................... 114.
7

INTRODUCCIÓN
La Unidad de Estadística (UE), es una Unidad Operativa del Ministerio de

Educación (MINEDU). Una de sus funciones es el registro de todas las Instituciones
Educativas, públicas y privadas a nivel nacional, amparado en un marco normativo y
legal. La Unidad de Estadística tiene Unidades Operativas a nivel nacional que se
encargan de este registro, estas son 246 Instancias de Gestión Educativa
Descentralizada (IGED), estas se dividen en 22 Direcciones Regionales de Educación
(DRE), 4 Gerencias Regionales de Educación (GRE) y 220 Unidades de Gestión
Educativa Local (UGEL).
El registro de los programas no escolarizados de educación inicial, tanto de
creación y modificación de datos de los Programas No Escolarizados de Educación
Inicial (PRONOEI), se viene realizando de una manera deficiente, causando malestar
a los usuarios finales.
Razón por la cual se plantea el desarrollo e implementación de una aplicación
WEB que permita realizar el proceso de registro y modificación de datos de los
Programas No Escolarizados de Educación Inicial, a través del uso de un lenguaje de
programación web, de una forma eficiente y optimizar recursos humanos y
económicos.
En la aplicación WEB se podrán registrar la creación y actualización de datos

de los Programas No Escolarizados de Educación Inicial, de las gestiones públicas y
privadas, de todo el territorio Peruano.
No se registrará el resto de niveles y/o modalidades que comprende el Sistema

Educativo Peruano, inicial escolarizado, primaria, secundaria, educación básica
alternativa, educación especial, educación técnico productiva y educación superior no
universitaria. Sería conveniente a futuro implementar la aplicación a estos niveles y/o
modalidades.

8

CAPÍTULO 1
ASPECTOS GENERALES
En este capítulo se va a detallar la definición del problema, descripción y formulación

del problema, definición de los objetivos, tanto general y los específicos, alcances y
limitaciones, justificación y estado del arte.
1.1 Definición del Problema

En este punto se va a detallar la descripción y formulación del problema.
1.1.1 Descripción del Problema

La Unidad de Estadística, es una Unidad Operativa del Ministerio de
Educación. Una de sus funciones es el registro de todas las Instituciones
Educativas a nivel nacional, amparado en un marco normativo y legal.
La Unidad de Estadística tiene Unidades Operativas a nivel nacional que se
encargan de este registro, estas son 24 DRE, 4 GRE y 220 UGEL.
La creación y/o actualización de datos de los Programas No Escolarizados de
Educación Inicial, se realizaban en una aplicación local, se generaban los
requerimientos de información en un archivo local (*.DB), este archivo contenía
la información de creación o modificación de datos. Se remitía este archivo
generado, vía correo electrónico, anexando la documentación sustentatoria,
resoluciones de creación o modificación de datos.
Con la finalidad de identificar el problema central, se ha utilizado la metodología
del árbol de problemas. A continuación se muestra el gráfico.

Figura 1: Árbol
de problemas para la Unidad de Estadística del Ministerio de Educación
Fuente: Elaboración propia
9

Tabla 1.
Árbol de problemas para la Unidad de Estadística del Ministerio de Educación.

Fuente: Elaboración propia.

Como se observa en la figura 1 Árbol de problemas para la Unidad de

Estadística del Ministerio de Educación, las causas encontradas para este
problema son: inadecuado uso del procedimiento para el envío de archivos de
solicitudes requeridas, duplicidad en el envío de solicitudes de requerimientos,
limitado monitoreo y control de las solicitudes de requerimientos en tiempo real
y demora en el retorno de respuesta de la solicitud requerida. Los efectos
originados por el problema central son:
 Retorno de solicitudes requeridas en 6 días calendario.
 Registro de los Programas No Escolarizados de Educación Inicial

deficiente.
 Programas No Escolarizados no beneficiados con programas de apoyo

social y
 Recarga laboral al momento de procesar solicitudes de requerimientos

duplicados.
1.1.2 Formulación del Problema

Después de haber utilizado la metodología del árbol de problemas, el problema
planteado es: deficiencia en el proceso de registro y/o modificación de datos de
los Programas No Escolarizados de Educación Inicial, en la Unidad de
Estadística del Ministerio de Educación.
1.2 Definición de Objetivos
1.2.1 Objetivo General

Desarrollar e implementar una aplicación WEB que permita realizar el proceso
de registro y/o modificación de datos de los Programas No Escolarizados de
Educación Inicial, a través del uso de un lenguaje de programación web.
10

1.2.2 Objetivos Específicos
 Analizar y diseñar los procesos y flujos de información del desarrollo de
software, usando la metodología de desarrollo de software RUP.
 Estructurar y elaborar la base de datos, usando el sistema de gestión de

bases de datos MySQL 5.1.
 Generar el contenido gráfico y dinámico para web, usando el lenguaje de

programación HTML 5.1.
 Elaborar e implementar los programas de interconexión entre la interfaz

gráfica y las bases de datos usando JAVA JDK 1.6.
1.2.3 Alcances y Limitaciones
Alcances
En la aplicación WEB se podrán registrar la creación y/o actualización de datos
de los Programas No Escolarizados de Educación Inicial, de las gestiones
públicas y privadas, de todo el territorio Peruano, abarcando a las 246
Instancias de Gestión Educativa Descentralizada. El uso de la aplicación
comprende a todo el personal que realiza las funciones de Estadístico en
dichas sedes administrativas.
Limitaciones
No se va a registrar al resto de niveles que comprende el Sistema Educativo
Peruano, inicial escolarizado, primaria, secundaria, educación básica
alternativa, educación especial, educación técnico productiva y educación
superior no universitaria. Sería conveniente a futuro implementar la aplicación a
estos niveles del Sistema Educativo Peruano.
1.2.4 Justificación
El proceso de registro actual de los Programas No Escolarizados de Educación
Inicial, no se da abasto para seguir atendiendo las solicitudes de cambio de
estos programas, ya que se realiza en una aplicación local. Mediante la
aplicación WEB se realizará el registro oportuno y la actualización inmediata de
los datos de los Programas No Escolarizados de Educación Inicial.
Se optimizaran recursos de la Unidad de Estadística tanto humanos como

económicos. El padrón de los Programas No Escolarizados de Educación
Inicial se mantendrá actualizado y será de vital importancia para el Sector
Educación ya que permitirá conocer la realidad educativa de estos programas,
para una mejor toma de decisiones por parte del Ministerio de Educación y las
diferentes DRE, GRE y UGEL a nivel nacional.
Esto generará una rápida y versátil distribución de los recursos materiales y

económicos, beneficiándose con los diferentes programas de apoyo social por
parte del Estado Peruano.
1.2.5 Estado del Arte
11

En este punto se va a tratar cómo dos empresas han enfrentado similar
problemática a la nuestra, y se mostrará la manera como lo han solucionado.
1.2.5.1 Registro de Historias Clínicas Electrónicas para un Hospital

En el proyecto de tesis Desarrollo de una Aplicación Web para el Registro de
Historias Clínicas Electrónicas (HCE) para el Hospital Nacional Guillermo
Almenara elaborado por Rojas y Sullca (2012), manifiestan que el objetivo de
este estudio fue mantener actualizada la base de datos de historias clínicas de
los pacientes, estas se realizaban de forma manual, dada que la información
que se maneja es de carácter confidencial había restricciones y dificultades al
momento de tener acceso a la carpeta de historia clínica del paciente. Otra
dificultad se generaba cuando se trasladaba al paciente a otro nosocomio, esto
generalmente por la demora en obtener la carpeta de historia clínica del
paciente. Sabemos que en este tipo de escenarios el tiempo es muy valioso
para la salud del paciente. Manifiestan que en muchas oportunidades no se
tenía acceso a la carpeta de historia clínica o en su defecto se extraviaba,
debido a esta pérdida de documentación se generaba una nueva carpeta con
la historia clínica del paciente, perdiéndose datos muy sensibles de diagnóstico
de los pacientes que serían valiosos para acelerar el proceso de
restablecimiento del paciente.
Así mismo los autores plantean esta problemática y deciden desarrollar una
Aplicación Web para el Almacenamiento y Acceso a Historias Clínicas de los
Pacientes para el Hospital Nacional Guillermo Almenara de Perú. En las
diferentes etapas de análisis, desarrollo e implementación utilizaron las
herramientas y software siguiente: Lenguaje Unificado de Modelo (UML);
Proceso Racional Unificado (RUP); LOLCLI 9000, modelo de gestión
asistencial para hospitales; MEDFILE 5.x, software diseñado para satisfacer
las necesidades de historias clínicas; CITMED 6, software médico para la
gestión de consultas médicas; Lenguaje de Marcas Extensible (XML) y DICOM,
estándar para el intercambio de pruebas médicas.

1.2.5.2 Aplicación de Control de Inventario y Rastreo de Puntos de Venta

En el proyecto de tesis Diseño e Implementación de una Aplicación Web de
Control de Inventario y Rastreo de Puntos de Venta elaborado por Vargas
(2012), manifiesta que este proyecto fue elaborado para la empresa POS
MANAGED SERVICES C.A. (PMS C.A.), esta empresa se encarga de
administrar y distribuir los equipos POS (Point Of Sale), a todos los negocios
que lo soliciten a nivel nacional, para poder realizar pagos electrónicos con
tarjetas de crédito o débito. En ese entonces la empresa no contaba con un
control adecuado de la distribución y ubicación de sus POS.
12

Así mismo el autor ante esta problemática, plantea el desarrollo de un Módulo
de Inventario y Rastreo de Puntos, el cual permitirá conocer al momento la
ubicación de un POS, y el historial de este POS donde se conocerá a que
establecimientos fue asignado y cuál fue su historial, es decir conocer por cual
negocios transitó este equipo. Las herramientas utilizadas por el autor para el
desarrollo de este módulo fueron las siguientes: JAVA, APACHE STRUTS 3,
JBOSS HIBERNATE 4, APACHE TOMCAT 5, POSTGRESQL 6,
JAVASCRIPT, AJAX 7.0 y JQUERY 8.
En ambos proyectos los autores plantean la misma problemática, deficiente

registro de datos, datos desactualizados y reportes con errores o sesgos.
Usando herramientas y software diferentes damos solución a una misma
problemática, utilizando internet como medio para enviar y recepcionar
información actualizada.

13

CAPÍTULO 2
MARCO TEÓRICO
En este capítulo se van a detallar los aspectos generales y definiciones teóricas.
2.1 Aspectos Generales
2.1.1 Rol de la Unidad de Estadística del Ministerio de Educación

La Unidad de Estadística del Ministerio de Educación dependiente de la Oficina
de Planificación Estratégica, dentro de una de sus funciones es la que se
encarga del registro de las Instituciones Educativas a nivel nacional. Y por
ende debe de facilitar este proceso a las DRE, GRE y UGEL, de todo el
territorio nacional.
2.1.2 Definiciones Teóricas

Se pasará a definir las herramientas tecnológicas y la arquitectura de software
que usaremos para solucionar la problemática encontrada.
2.2.1 Aplicaciones WEB

En los últimos tiempos el avance tecnológico ha ido de menos a más, es así
que el desarrollo de aplicaciones web ha ido de forma incremental, optimizando
recurso humano y tecnológico, dada las características de estas aplicaciones,
se pueden acceder desde cualquier lugar del mundo, basta con tener a
disposición una computadora, laptop, Tablet, etc. Las actualizaciones de
software se realizan en una sola computadora llamada servidor de
aplicaciones. El personal ya no se traslada para recibir las actualizaciones del
software ahorrando tiempo y dinero. En la figura 02. Arquitectura de las
aplicaciones WEB, se visualiza el funcionamiento de estas.

14

Figura 2: Arquitectura
de las aplicaciones web
15

2.2.2 Metodología RUP
Jacobson, Booch y Rumbaught (2000) afirman que la Metodología RUP es un
procedimiento de desarrollo de software apoyándose conjuntamente con el
Lenguaje Unificado de Modelado UML que forman la metodología con mayor
demanda para el análisis, diseño, implementación y documentación de
sistemas de información.
La metodología RUP descarta ser una metodología con procedimientos

establecidos, AL contrario viene hacer una unificación de metodologías
adaptables al contexto y necesidades de una empresa.
A la Metodología RUP se le reconoce como un software, construido y creado

por la organización Rational, la cual contiene información relacionada de
diversos artefactos y descripciones de las diversas actividades involucradas en
el proceso. La metodología Rational Method Composer (RMC), Dentro de sus
principales características permite la personalización de acuerdo al
requerimiento de las organizaciones.
A continuación describiremos las principales características según Jacobson,

Booch y Rumbaught (2000):
 Describir la organización, documentación, funcionalidad y restricciones

de un software.
 Documentar y registrar las decisiones que se tomen para el desarrollo

de un software.
 Implementar los diferentes diagramas de UML, dando paso a la

reducción de tiempo a la hora de desarrollar un software.
16

Figura 3: Porcentaje de crecimiento de puestos de trabajo, que solicitan conocimiento de
habilidades en RUP. Recuperado de http://www.itjobswatch.co.uk/jobs/uk/rup.do
Figura 4: Promedio
móvil de tres meses para los salarios cotizados en Tecnologías de
Información. Recuperado de http://www.itjobswatch.co.uk/jobs/uk/rup.do
17

2.2.2.1 Evaluación de la mejor solución
Jacobson, Booch y Rumbaught (2000) afirman que el estudio realizado en la
búsqueda de diferentes soluciones que satisfagan las principales
características igualitarias a los requerimientos funcionales de la empresa, han
permitido encontrar diferentes soluciones alternas a fuera del mercado local
que satisfacen en una parte las principales funcionalidades solicitadas por los
usuarios y clientes de la organización.
Los autores manifiestan que las todas las organizaciones que desarrollan sus
proyectos utilizando la metodología RUP logran un gran posicionamiento en el
mundo de la gestión de las TIC dentro del parque informático y servicios de TIC
aplicando las mejores prácticas de ITIL. Las diversas soluciones planteadas y
utilizadas por el mercado son grandes sistemas integrados que no satisfacen
de manera óptima su ámbito sino simplemente el seguimiento de las
incidencias. Más bien controlan toda la información de la cadena de valor de la
organización.
Empero, la valoración de las características del software que actualmente

necesita la empresa es más reducido. Por lo que no necesita un control integral
de toda la cadena de producción. Es decir solo necesita un buen saco a la
medida y a la medida de sus necesidades descritas en sus requerimientos.
El diagnostico de un sistema de información se ha construido aplicando las

características funcionales y no funcionales basadas en las tecnologías
estudiadas. En consecuencia el resultado del estudio nos muestra que la
Proactiva NET con la valoración de 78.13 %, seguida de CESTRACK con una
valoración de 76.04%.
Una propuesta muy importante es el producción y producción in house la cual

satisface todos los requerimientos exigidos por la organización, en gran medida
esto en producto de la funcionalidades solicitadas, la flexibilidad del
mejoramiento de la herramienta en base a la retroalimentación del sistema,
acceso a la documentación y código fuente, entre otras. Las soluciones
descartadas no son dejadas de lado por ser consideradas como productos
inadecuados. Es más estas soluciones cuentan con gran respaldo de los
clientes que la implantan. Son las características de la organización que las
dejan sin interés atractivo.
2.2.2.2 Principios del RUP

Jacobson, Booch y Rumbaught (2000) afirman que el RUP está basado en seis
principios claves que son los siguientes:
 Adaptar el proceso:
El proceso deberá adaptarse a las necesidades del cliente ya que es

muy importante interactuar con él. Las características propias del
proyecto u organización, el tamaño del mismo, así como su tipo o las
regulaciones que lo condicionen, influirán en su diseño específico.
18

 Equilibrar prioridades:
Las Características de los diversos participantes pueden ser diferentes,

contradictorios o disputarse recursos limitados. Como resultado es muy
importante encontrar una armonía que satisfaga los deseos de todos.
Gracias a este equilibrio se podrán subsanar desacuerdos que surjan en
el futuro.
 Demostrar valor iterativamente:
Los proyectos se entregan, aunque sea de un modo interno, en cada

parte de las partes. En cada iteración se analiza la opinión de los
inversores, la estabilidad y calidad del producto, y se refina la dirección
del proyecto así como también los riesgos involucrados.
 Colaboración entre equipos:
El desarrollo de software no lo hace una única persona sino múltiples

equipos. Debe haber una comunicación fluida para coordinar requisitos,
desarrollo, evaluaciones, planes, resultados, etc.
 Elevar el nivel de abstracción:
Inicialmente el dominio motiva el uso de terminos reutilizables tales

como patrón del software, lenguajes de programación 4GL asimismo los
marcos de referencia (frameworks) por citar algunos. Esto permite que
los ingenieros de software vayan directamente de los requisitos a la
codificación de software a la medida del cliente, sin saber con certeza
qué codificar para satisfacer de la mejor manera los requisitos y sin
comenzar desde un principio pensando en la reutilización del código.
 Enfocarse en la calidad:
La administración de calidad se desde de aplicar en cada iteración, de

los aspectos de la producción. El proceso de la calidad forma parte del
proceso de desarrollo y no de un grupo independiente.
19

2.2.2.3 Ciclo de vida del RUP
Jacobson, Booch y Rumbaught (2000) definen al ciclo de vida la metodología
RUP es una implementación del Desarrollo en espiral. Desarrollado con los
elementos en secuencias semi ordenadas. El ciclo de vida se desarrolla en
base a las tareas de las fases e iteraciones.
La metodología RUP está compuesta en cuatro fases, en cada fase de

desarrollan un conjunto de iteraciones en número variable según el proyecto y
en las que se hace un mayor o menor hincapié en las distintas actividades del
proyecto. En la Figura muestra cómo varía el esfuerzo asociado a las
disciplinas según la fase en la que se encuentre el proyecto RUP. Las primeras
iteraciones (en las fases de Inicio y Elaboración) se basan hacia la
comprensión del problema y la tecnología, la delimitación del ámbito del
proyecto, la eliminación de los riesgos críticos, y al establecimiento de la
arquitectura del sistema de información.
Figura 5: Ciclo de vida del RUP. Recuperado de

http://josemiguelrincon.blogspot.pe/2012/04/ciclo-de-vida-rup.html
20

2.2.3 Base de Datos
2.2.3.1 Introducción
Marqués (2011) manifiesta que una base de datos es la mejor alternativa de
solución para la gestión y ordenamiento de grandes volúmenes de información,
los datos pueden ser guardados y administrada en forma ordenada, estos se
diseñan para el mejor control de la información de las organizaciones.
Cuando las organizaciones no utilizaban las bases de datos, se trabajaba con

sistemas de ficheros, el cual se elaboraba y almacenaba de forma manual,
antes que aparecieran los software de base de datos, el punto débil era que la
organización no podía compartir ni transmitir información, ya que se generaban
aisladamente y generaban muchas inconsistencias como duplicidad de datos y
datos erróneos.
Definimos a la base de datos como una gran colección de datos, esta puede
ser accesada por distintos usuarios a la vez, esta no contiene duplicidad de
información, es compartida por toda la organización, los datos en si tienden a
presentar errores mínimos de entrada debido a que se pueden controlar y
verificar mediante formularios de entrada y ciertos procedimientos de validación
de datos. El acceso a estos datos por parte de la organización es de forma
rápida.
Figura 6: Acceso a las base de datos. Recuperado de http://idevnote.com/wp-

content/uploads/base-de-datos-4.jpg638.jpg?cb=1372277303

21

2.2.3.2 Historia de los sistemas de base de datos
Según Marqués (2011) Afirma que al comienzo los sistemas de bases de datos
fueron los sistemas de ficheros, no existe evidencia que si estos sistemas de
ficheros dejaron de usarse, es más cabe la posibilidad que en la actualidad
existan sistemas de ficheros en uso.
La autora menciona que los sistemas de bases de datos tiene sus inicios en el
proyecto estadounidense APOLO, que fue a mediados de los años sesenta, en
el cual se dio inicio al uso de las bases de datos dada la complejidad del
proyecto y se basa en el concepto de que varias piezas pequeñas se unen para
formar una pieza más grande. Este fue un punto de inicio para el uso de los
sistemas de bases de datos.
Manifiesta que a mitad de los años setenta, General Electric desarrolló IDS
(Integrated Data Store), este proyecto fue dirigido por Charles Bachmann, este
sistema de bases de datos produjo un gran efecto y despegue sobre los
sistemas de información de ese entonces. En ese entonces se fundó el grupo
DBTG (Data base Task Group), el objetivo principal de este grupo era la de
definir estándares para la creación de bases de datos y el manejo y acceso de
los mismos.
En el año de 1970, Edgar Frank Codd, de IBM dio inicio al modelo relacional de
base de datos que después de unos años dio inicio al desarrollo de los
primeros sistemas relacionales. Dos grandes logros fueron el desarrollo de un
lenguaje de consulta estructurado llamado SQL y en los años 80 la producción
de varios Sistemas de Gestión de Base de Datos (SGBD).
Los SGBD relacionales están considerados como la segunda generación de los

SGBD, presentando ciertos inconvenientes que fueron subsanados con el
transcurrir del tiempo. En 1976, Peter Chen presentó el modelo entidad-
relación, que es la técnica más utilizada en el diseño de bases de datos.
La creciente evolución de la tecnología de bases de datos, está marcada por

una mayor solidez de las bases de datos orientada a objetos. Esta representa
la tercera generación de SGBD.
La autora concluye que en la actualidad el uso de la Web se ha visto como una

interfaz de acceso a las bases de datos, con la creación de programas con
sentencias que accesan a estas mismas y la estandarización y mejora del
lenguaje SQL hicieron que esto sea posible.
22

Figura 7: Evolución de las bases de datos. Recuperado de
http://es.slideshare.net/mickienet/base-de-datos-sistema-modelo-de-gestion-de-datos
2.2.3.3 Personas en el entorno de las bases de datos

Según Marqués (2011) existen cuatro grupos de personas que intervienen en el
entorno de una base de datos:
 Administrador de la base de datos:
 Implementación física de la base de datos, crear índices ubicación

de las tablas, etc.
 Establecer la política de seguridad y del acceso a los usuarios.
 Verificar que el sistema se encuentre siempre operativo
 Conocer la base de datos.
 Diseñador de la base de datos:
 Realizar el diseño de la base de datos.
 Identificar los datos, las relaciones entre ellos y las restricciones

sobre los datos y sobre sus relaciones.
 Conocer sus reglas de negocio.
 Los programadores de aplicaciones:
 Implementar los programas de aplicación que permiten consultar

datos, insertarlos, actualizarlos y eliminarlos.
23

 Conocer lenguajes de tercera o cuarta generación para implementar
los procesos mencionados.
 Usuarios:
 Ingreso masivo de información.

Figura 8: Entorno
de las bases de datos
2.2.4 MySQL
2.2.4.1 Sistema de gestión de bases de datos

Marqués (2011) Define que un sistema de gestión de la base de datos (SGBD)
es una aplicación que permite a los usuarios definir, crear y mantener la base
de datos, además de tener un acceso controlado a la misma.
Un SGBD proporciona los siguientes servicios:
 Permite la definición de la base de datos mediante un lenguaje de definición

de datos. El cual permitirá especificar la estructura y el tipo de los datos, así
como las restricciones sobre los datos.
 Permite la inserción, actualización, eliminación y consulta de datos

mediante un lenguaje de manejo de datos. El lenguaje más utilizado es el
SQL que, de hecho, es un estándar y es el lenguaje de los SGBD.
 Proporciona un acceso controlado a la base de datos mediante:
 Un sistema de seguridad, de modo que los usuarios no autorizados

no puedan acceder a la base de datos.
 Un sistema de integridad que mantiene la integridad y la

consistencia de los datos.
 Un sistema de control de concurrencia que permite el acceso

compartido a la base de datos.
24

 Un sistema de control de recuperación que restablece la base de
datos después de que se produzca un fallo del hardware o del
software.
 Un diccionario de datos o catálogo, accesible por el usuario, que

contiene la descripción de los datos de la base de datos.
2.2.4.2 Ventajas e inconvenientes de los sistemas de bases de datos

Marqués (2011) afirma que la bases de datos representan una ventaja
competitiva a las organizaciones, por la integración de datos y a la interfaz
común que proporciona el SGBD. Estas ventajas se describen a continuación:
 Control sobre la redundancia de datos al no hacer varias copias de la BD

solo las necesarias.
 Control sobre la consistencia de datos.
 Compartición de datos, por las nuevas aplicaciones y a todas las áreas de

la organización.
 Mantenimiento de estándares necesarios, tanto los establecidos a nivel de

la empresa como los nacionales e internacionales.
 Mejora en la integridad de datos y validez de los datos almacenados.
 Mejora en la seguridad que consiste a la protección de la base de datos

frente a usuarios no autorizados.
 Mejora en la accesibilidad a los datos, dado que los lenguajes de consulta o

generadores de informes permiten al usuario hacer cualquier tipo de
consulta sobre los datos.
 Mejora en el mantenimiento gracias a la independencia de datos.
 Aumento de la concurrencia, ya que varios usuarios pueden acceder

simultáneamente a un mismo fichero.
 Mejora en los servicios de copias de seguridad y de recuperación de

ficheros ante fallos.
 La integración de los datos y la existencia del SGBD también plantean

ciertos inconvenientes, como los que se citan a continuación.
 Alta complejidad, debido a la complejidad de sus programas.
 Poseen gran tamaño, por lo que requieren una gran cantidad de espacio en
disco y de memoria para trabajar de forma eficiente.
 Coste económico del SGBD, puede costar entre 10,000 y 100,000 €.

Además, hay que pagar una cuota anual de mantenimiento que suele ser
un porcentaje del precio del SGBD.
 Coste del equipamiento adicional.
 Coste de la conversión, para migrar la información al nuevo SGBD.

25

 El hecho de que todo esté centralizado en el SGBD hace que el sistema
sea más vulnerable ante los fallos que puedan producirse.
Figura 9: Resumen de versiones de MySQL y estados actuales de desarrollo. Recuperado

de http://prograwebn4.blogspot.pe/

Para el desarrollo de nuestra aplicación Web Hemos elegido MySQL porque se

adapta a las dimensiones de nuestro proyecto y porque posee ciertas
características que hacen atractivo este gestor de base de datos. Estas son las
principales:
 El factor económico, ya que al ser un software libre no posee costo

alguno.
 Las dimensiones de nuestra base datos, no son de mucha exigencia ya

que al no almacenar grandes volúmenes de información hacen a
MySQL muy atractivo para nuestro proyecto. De seguro si estuviésemos
en un proyecto de grandes dimensiones optaríamos por ejemplo
ORACLE.
26

 Dada las características de MySQL, posee un prestigio reconocido,
fiabilidad, velocidad, rendimiento y de fácil administración y conexión
con otros productos.
 Maneja un amplio subconjunto de sentencias SQL Standard, que lo

hacen de fácil manejo para explotar la información.
 Facilidad de configuración e instalación y soporta gran variedad de

sistemas operativos.
 Baja probabilidad de corromper datos grabados.

Figura 10: Estudio
sobre gestores de base de datos

Fuente: Estudio Forrester 2009 sobre gestores de Base de Datos
A continuación mostramos un cuadro comparativo, tabla 2 Cuadro comparativo

de gestores de base de datos, de nuestro Gestor de Base de Datos elegido
MySQL y de los tres Gestores de Base de Datos más comerciales del mercado,
Oracle, SQL Server y Access, y MySQL, donde mostramos que MySQL se
adapta a las exigencias técnicas y presupuestales de nuestro proyecto:
27

Tabla 2
Cuadro comparativo de gestores de bases de datos
MANEJADOR DE BASE REQUERIMIENTOS
PRECIO VENTAJAS DESVENTAJAS CAPACIDAD
DE DATOS DE HARDWARE
 Buen rendimiento, buena Win32 w/ FAT/FAT32  RAM :512 MB
Sin costo velocidad a la hora de  No Soporta vistas 2GB/4GB  Memoria
conectar con el servidor Win32 w/ NTFS 2TB virtual1: 1024
y de respuesta a Linux 2.2-Intel 32-bit 2GB MB
consultas. (LFS: 4GB)  Protocolo de red
 Registros sin límite de Linux 2.4+ (usando ext3 TCP/IP
tamaño. filesystem) 4TB  Protocolo de red
 Control de acceso: qué Solaris 9/10 16TB TCP/IP con SSL
usuarios tienen acceso a MacOS X w/ HFS+ 2TB
qué tablas y con qué NetWare w/NSS
permisos. filesystem 8TB
300 a 40,000  Suite de productos que  Sucedieron La capacidad de BDD es  RAM :256MB
US$ ofrece una gran variedad varias versiones alta ya que soporta hasta mínimo
dependiendo del de herramientas. con correcciones, 4 peta bytes de  MEMORIA
tipo de licencia y  Oracle corre en hasta alcanzar la información. VIRTUAL : doble
usuario computadoras personales, estabilidad en la de la cantidad de
microcomputadoras, 8.0.3. RAM
mainframes y  Oracle mal  Espacio de disco
computadoras con configurado duro: se
procesamientos paralelo puede ser especificara a
masivo. desesperanteme continuación
 Soporta unos 17 idiomas. nte lento.  Espacio para
 Corre automáticamente en archivos
mas de 80 arquitecturas de temporales :100
hardware y software Mb
distinto sin tener la  Adaptadores de
necesidad de cambiar una video :256
sola línea de código. colores
 Oracle es la base de datos  Procesador: 200
con más orientación hacia MHz mínimo
internet.  Protocolo de red
TCP/IP
28

40 a 2,000 US$  Administración multi-  Gran cantidad de SQL Server admite 25  RAM: Mínimo:
dependiendo del servidor y con una sola memoria RAM instancias en un clúster 512 MB
tipo de licencia y consola. ara la instalación de conmutación por error  Recomendado:
usuario.  Ejecución y alerta de y utilización del cuando se usa un disco 2,048 GB o más
trabajos basadas en software. de clúster compartido  Tipo de
eventos.  Costo de como opción de procesador:
 Seguridad integrada. actualizaciones. almacenamiento para la Procesador
 Se ajusta muy bien a las  La relación instalación del clúster; Itanium o más
necesidades cada vez calidad-precio SQL Server admite 50 rápido
mayores. esta muy debajo instancias en un clúster  Velocidad de
 Para las bases de datos comparado con de conmutación por error procesador:
muy grandes. Oracle. si elige recursos Recomendado:
 Ideal para sistemas de lata compartidos de archivos 1,0 GHz o más
tecnología. SMB como opción de
almacenamiento para la
instalación del clúster.
 Tablas para almacenar los  Tiene  RAM: 1 GB (32
100 a 250 datos. limitaciones en el Capacidad hasta 1GB bits) o 2 GB (64
US$, software  Consultas para buscar y procesamiento de de información, es bits)
comprende recuperar únicamente los las búsquedas. limitada.  Procesador de
todo el datos que necesita.  Poca estabilidad x32 o x64 bits a 1
OFFICE.  Informes para analizar o cuando maneja GHz o más
imprimir los datos con un grandes rápido con
diseño específico. volumenes de instrucciones
 Páginas de acceso a datos información. SSE2.
para ver, actualizar o  Específica para
analizar los datos de la proyectos
base de datos desde pequeños dada
internet o desde una sus limitaciones.
intanet.

Fuente: Elaboración Propia
29

2.2.5 HTML
2.2.5.1 Descripciones previas

Antes de poner manos a la obra en el diseño de nuestra página web debemos
tener claro algunos conceptos básicos y conocer previamente el objetivo del
proyecto para no tener retrasos, debemos de tener todo claro para lograr el
éxito de nuestro proyecto. Para asegurar el éxito de nuestra página web
debemos de medir su definición de propósito.
La fase de definición cubre tres áreas:
 Identificar la audiencia:
Comprende al grupo de personas del cual se espera que visite la página

web. Se trata de gente que estará viendo la página por alguna razón
específica. Tenerlas en cuenta nos permitirá crear una página que ofrezca
el contenido deseado a la audiencia.
 Evaluar el contenido:
La evaluación del contenido y su organización implica que el propósito de la

página será claramente definido. Realizar una lista de los contenidos
necesarios facilitará
 Diseñar la estructura:
El último paso en el proceso de definición consiste en diseñar la estructura

o la arquitectura en la cual los contenidos serán categorizados y la
información formulada.
2.2.5.2 Introducción al lenguaje HTML

Vértice (2009) manifiesta que HTML es un software artificial que las
computadoras interpretan y diseñan para que los desarrolladores programen
instrucciones que los navegadores ejecutan para originar la página web.
HTML significa HyperText Markup Language (lenguaje de marcas de

hipertexto). El hipertexto en una computadora es texto que posee referencias
(hipervínculos, links o enlaces) a otro texto. Para simplificar podemos decir que
el hipertexto es aquel texto que pulsamos con el ratón del ordenador y nos
conduce a otro texto cuando utilizamos Internet.
En enero de 2008, W3C (World Wide Web Consortium, consorcio internacional

que produce recomendaciones para la World Wide Web) publicó un borrador
de la versión 5.o de HTML, lo que ellos mismos llaman el futuro del contenido
web.
30

Vértice (2009) define que HTML sirve para esquematizar y estructurar
documentos (títulos, párrafos, listas, etc.), pero no muestra la apariencia o el
producto de un documento sino que ofrece las herramientas necesarias para
dar formato, según la capacidad del servidor web en el que se almacenan las
páginas web y la capacidad del navegador. HTML tiene dos ventajas que lo
hacen prácticamente imprescindible a la hora de diseñar una presentación web:
su compatibilidad y la facilidad que plantea su aprendizaje debido al reducido
número de etiquetas en las que se apoya.
Se decidió usar el lenguaje HTML por dos potentes razones que son, lo
económico, sin costo de licencia y la sencillez del lenguaje ya que se pueden
desarrollar páginas web de manera rápida y sencilla. Otras características por
que se decidió usar este lenguaje son las que se mencionan a continuación:
 Su sencillez hace que pueda diseñarse y desplegarse una página WEB

en muy poco tiempo.
 Dada su sencillez es muy rápido de aprender.
 Es un lenguaje que es admitido por todos los navegadores WEB,

Internet Explorer, Mozilla Firefox, Google Chrome, Safari, Opera, etc.
 Incluye una gran cantidad de funciones.
 Dada la característica de nuestra aplicación WEB, se va a desarrollar

páginas WEB estáticas y este lenguaje se adapta fácilmente a esta
necesidad.
En este cuadro comparativo, tabla 3 cuadro comparativo de lenguajes de

programación para páginas web, mencionamos las ventajas y desventajas del
porque el uso del lenguaje HTML y los otros lenguajes, JavaScript, PHP y
ASP.NET.
Tabla 3
Cuadro comparativo de lenguajes de programación para páginas WEB
LENGUAJE PRECIO VENTAJAS DESVENTAJAS
 La sencillez de su  No permite manejar
Sin costo programación. Base de Datos.
 Muy rápido de  Funcionalidad limitada.
aprender.
 Lenguaje admitido
por todos los
navegadores WEB.
 Incluye una gran
cantidad de
funciones.
 Se adapta con
facilidad al
desarrollo para
páginas WEB
estáticas.
 Ha mejorado
bastante con
HTML5.

31

 Lenguaje de scripting  Código visible por
Sin Costo seguro y fiable. cualquier usuario.
 Los script tienen  El código debe
capacidades descargarse
limitadas, por completamente.
razones de  Puede poner en riesgo
seguridad. la seguridad del sitio,
 El código JavaScript con el actual problema
se ejecuta en el llamado XSS.
cliente.
 Muy fácil de  Se necesita instalar un
Sin Costo aprender. servidor web.
 Se caracteriza por  La legibilidad del
ser un lenguaje muy código puede verse

rápido. afectada al mezclar
 Soporta en cierta sentencias HTML y
medida la orientación PHP.
a objeto. Clases y  La programación
herencia. orientada a objetos es
 Incluye gran cantidad aún muy deficiente
de funciones. para aplicaciones
 No requiere grandes.
definición de tipos de  Dificulta la
variables ni manejo organización por capas
detallado del bajo de la aplicación.
nivel.
 Versiones  Completamente  Mayor consumo de
Con orientado a objetos. recursos.
Costo.  Controles de usuario
 Versiones y personalizados.
Sin Costo.  División entre la capa
de aplicación o
diseño y el código.
 Facilita el
mantenimiento de
grandes
aplicaciones.
 Incremento de
velocidad de
respuesta del
servidor.
 Mayor velocidad.
 Mayor seguridad.

32

2.2.6 JAVA
2.2.6.1 Una primera reflexión acerca de Java

Joyanes y Zahonero (2011) manifiestan que el explosión en los años 90 del
internet por, propicio que Sun Microsystems, anunciará formalmente el
nacimiento de java, mostrando al mercado de la computación y de a informática
que conectaría usuarios con los usuarios de servidores web y bases de datos.
Los autores manifiestan que actualmente Java es utilizado por todo tipo de
empresas y es pieza clave en el desarrollo y aplicación de productos web; sus
fortalezas en las características de seguridad tanto para desarrolladores como
para usuarios fortalecieron su uso. Java se utiliza actualmente en el desarrollo
de grandes proyectos tecnológicos empresariales. Desde su presentación en
1996, Sun ha lanzado siete versiones importantes de Java: 1.0, 1.1, 1.2, 1.3,
1.4, 5.0, 62, 7.0 y ya anunció Java 8. El 17 de enero de 2017.
2.2.6.2 Java como lenguaje y plataforma de programación

Joyanes y Zahonero (2011) manifiestan que el lenguaje de programación Java
es un lenguaje de propósito general, teniendo su fortaleza en el desarrollo de
programas en internet y web; actualmente se encuentra en numerosas
aplicaciones, dispositivos, redes de comunicaciones, etcétera, como:
 Servidores web.
 Bases de datos relacionales.
 Sistemas de información geográfica (SIG/GIS, Geographical Information

System).
 Teléfonos celulares (móviles).
 Sistemas de teledetección.
 Asistentes digitales personales (PDA).
 Sistemas medioambientales.
Java tiene todo lo que un programador eficiente necesita: un buen lenguaje, un

entorno de ejecución de alta calidad y una biblioteca extensa; esta combinación
caracteriza a Java como el lenguaje de programación por excelencia y permite
utilizarlo tanto en la enseñanza, prácticamente en todas las carreras
universitarias y profesionales de ciencias e ingeniería y en los diferentes
niveles de aprendizaje. En las empresas, en la industria y en internet es el rey
de los lenguajes de programación utilizados para el desarrollo web.
2.2.6.3 Historia de Java
33

Joyanes y Zahonero (2011) manifiestan que en un inicio el proyecto que
desarrollo Green, comenzó apoyándose en el lenguaje C++ pero a medida que
avanzaba su desarrollo, el equipo creador se encontró con dificultades en el
camino, especialmente de portabilidad; para evitar esto decidieron desarrollar
su propio lenguaje, y en agosto de 1991 nació uno nuevo orientado a objetos y
al cual llamaron Oak. En 1993, Green se renombró First Person Juc.; Sun
invirtió, sin mucho éxito, un gran presupuesto y esfuerzo humano para intentar
vender esta tecnología, hardware y software a las organizaciones que más
adelante fueran sus principales clientes en el ámbito de la informática.
En los meses de julio y agosto del año de 1993 se lanzó Mosaic, el primer
navegador web, y comenzó a crecer el interés por internet; después se
rediseñó el lenguaje para desarrollar internet y, en enero de 1995, Oak se
convirtió en Java. Sun lanzó el entorno JDK 1.0 (java development kit) en 1996
como primera versión del kit de desarrollo de dominio público y se convirtió en
la primera especificación oficial de la plataforma Java; desde entonces se han
lanzado varias versiones, aunque JDK 1.1, la primera versión comercial, se
lanzó a principios de 1997. En diciembre de 1998, Sun lanzó JDK 1.2 pero la
renombró como Java 2 y comenzó a utilizarse el nombre de J2SE (Java 2
Platform, Standard Edition) para diferenciar las plataformas base de J2EE
(Java 2 Platform, Enterprise Edition) y J2ME (Java 2 Plataform, Micro Edition);
además de la versión estándar SE, Sun lanzó otras dos ediciones populares:
Micro Edition (ME) para dispositivos empotrados tales como teléfonos celulares
y la edición empresarial (Enterprise Edition, EE) para procesamiento desde el
servidor.
Siguieron muchas versiones que se detallan en la figura 11. Versiones de Java.

Figura 11: Versiones
de JAVA. Recuperado de
http://www.slideshare.net/wolfgangweigend/jdk-8-and-updates-in-open-jdk
34

Las características más importantes por lo que se decidió usar JAVA, fue
porque es un lenguaje gratuito y por su fácil acceso y conexión a la base de
datos. Para nuestro proyecto vamos a enlazar JAVA con MySQL. Analizando
las características técnicas de nuestro proyecto y viendo otras
características adicionales de JAVA y nos animaron a usar este lenguaje de
programación fueron estas:
 Es un lenguaje simple y ya que la base de JAVA es C y C++, esto nos

favoreció ya que los programadores de nuestro proyecto están
familiarizados con estos lenguajes y fácilmente podemos optimizar el
tiempo.
 Este lenguaje es altamente fiable, proporciona numerosas

comprobaciones en compilaciones y en tiempo de ejecución.
 Está diseñado para soportar aplicaciones que serán ejecutadas en los

más variados entornos de red desde Unix a Windows NT, MAC y
estaciones de trabajo, arquitecturas distintas y sistemas operativos
diversos.
En el mercado informático actual JAVA tiene buen posicionamiento y la gran

mayoría de código fuente de las aplicaciones están hechas en este lenguaje.
En el cuadro comparativo, tabla 4 cuadro comparativo de lenguajes de
programación para conexión de base de datos vía web, se hace un
comparativo con CSharp.

Tabla 4
Cuadro comparativo de lenguajes de programación para conexión de base de datos vía web
LENGUAJE PRECIO VENTAJAS DESVENTAJAS
 Fuente abierta, no  Menos eficiente,
Sin costo tiene pago de comparado con C/C++.
patentes anuales.  Requiere de un
 Plataforma intérprete.
independiente.  Una mala
 Manejo automático de implementación de un
la memoria. programa, puede
 Lenguaje resultar algo muy lento
multiplataforma, es de ejecutarse.
decir el programa se

ejecutará en cualquier
plataforma.
 Sintaxis similar a
C/C++, pero más
simple.
35

 Posee una facilidad de  Se tiene que tener una
Pagado uso, ambiente versión reciente de
amigable, clásico de Visual Studio .NET.
Windows.  Los requerimientos
 Ahorro de código, ya mínimos del sistema
que la programación para que pueda
está orientada a funcionar
objetos. adecuadamente son 4
 Seguridad en el manejo GB de espacio libre para
de datos. la pura instalación con
Windows NT 4 o
superior.
Fuente: Elaboración Propia.
36

CAPÍTULO 3
DESARROLLO DE LA SOLUCIÓN
En éste tercer capítulo describiremos la metodología que nos permitirá desarrollar la
aplicación WEB para el registro de los programas no escolarizados de educación
inicial del Ministerio de Educación, detallando así la recopilación de la información a
través de las historias de usuarios y el resultado de los prototipos de interfaces en
base a la participación de los usuarios en diversas iteraciones.
La aplicación de registro de Programas No Escolarizados de Educación Inicial,

corresponde básicamente a la mejora en la captura de datos en los registros de
solicitudes de creación, renovación y cierre de PRONOEI realizadas por los
estadísticos de las UGEL a nivel Nacional. Se presenta al usuario las mejoras para el
registro de los programas no escolarizados, también se incluye interfaces de búsqueda
de programas no escolarizados del ámbito de la UGEL y las pantallas para la
visualización del control de avance como parte del cumplimiento del compromiso.
El módulo del Validador, vienen a ser el Personal de la Unidad de Estadística del

Ministerio de Educación, quienes se encargarán de atender las solicitudes de creación,
renovación y cierre de programas no escolarizados de Educación Inicial. Las interfaces
que se presenta para este módulo incluyen la bandeja de atención de solicitudes,
búsqueda de Solicitudes, búsquedas de programas no escolarizados de educación
Inicial y la verificación del control de avance por UGEL.
3.1 Breve descripción de la solución

En la aplicación WEB se podrán registrar la creación y/o actualización de datos
de los Programas No Escolarizados de Educación Inicial, de las gestiones
públicas y privadas, de todo el territorio Peruano, abarcando a las 24 DRE, 4
GRE y 220 UGEL. El uso de la aplicación comprende a todo el personal que
realiza las funciones de Estadístico en dichas sedes administrativas se
encuentran a cargo del Ministerio de Educación.
Entre las funcionalidades principales para el cual fue desarrollada la aplicación

se encuentran:
 Registro y envío de solicitudes de creación, renovación, modificación y

cierre de programas no escolarizados de educación inicial por los
estadísticos de las UGEL a nivel Nacional.
 Gestión de las solicitudes, el cual permite administrar sus solicitudes

dependiendo del estado en el que se encuentra su solicitud y un historial
de las mismas.
 Reporte de los Programas registrados, actualizados.
 Reporte del padrón de los PRONOEI y control de avance de la

actualización de programas.
 Gestión de usuarios, el cual incluye las funcionalidades de creación,

actualización e inhabilitación de usuarios que acceden al sistema de
Registro de Programas.
37

 Administración de solicitudes, donde se podrá eliminar solicitudes, eliminar
programas y gestionar a los coordinadores de la aplicación.

3.2 Situación actual

El Padrón de los programas no escolarizados de educación inicial, debe reflejar
las recientes ocurrencias administrativas, así como las ocurrencias o
rectificaciones en los registros administrativos o estadísticos. Es así que el
Padrón debe ser actualizado permanentemente y esto se hace mediante
requerimientos efectuados por los Estadísticos de DRE/GRE/UGEL a través del
software SIEMED, el cual funciona de manera local en cada Instancia de
Gestión Educativa Descentralizada (DRE/GRE/UGEL).
3.2.1 Problemática
 Se pierde mucho tiempo en coordinación.
 Actualmente los Usuarios realizan 2 o 3 solicitudes sobre la misma

institución ya que no visualizan su requerimiento.
 Generación de duplicidad de trabajo con varias solicitudes sobre el mismo

requerimiento
 Documento de justificación del requerimiento no es registrado por el

sistema, muchas veces ocurre errores.
 En envío y recepción de solicitudes de creación y/o modificación de datos

de los PRONOEI se realiza mediante correo electrónico, no se realiza en
tiempo real.
 La documentación sustentatoria, tanto las resoluciones de creación y/o

modificación se anexan al correo electrónico, muchas veces ocasionando
pérdida de información y rebote del correo electrónico por la cantidad de
megas que posee dicho archivo digital.
 Se necesita mayor transparencia en cuanto al registro de información,

también se ve la necesidad de contar con información confiable en línea
para una correcta toma de decisiones.
 Se calcula en un aproximado de 240 usuarios del sistema nivel nacional.
En la figura 12 proceso actual del registro de los PRONOEI se describe el

proceso actual del registro de los PRONOEI.
38

Figura 12: Proceso
actual del registro de los PRONOEI
3.2.2 Definición de requerimientos
Requerimientos funcionales:
Módulos del software:
 Módulo de acceso
 Módulo de nueva solicitud
 Creación
 Renovación
 Modificación
 Gestión de solicitudes
 Solicitudes en proceso
 Historial de solicitudes
 Módulo de reportes
 Padrón de Programas
 Control de avance
 Gestión de usuarios
 Crear usuarios.
 Modificar usuarios.
 Inhabilitar usuarios.
 Administración
 Eliminar solicitud.
 Eliminar programa.
39

 Gestión de coordinadores.
3.2.3 Requerimientos de validación

 Cumpla los estándares del desarrollo web.
 La implementación del diseño cumpla con los requerimientos de cada tipo

de usuario.
 Cumpla con la aprobación del plan de pruebas de cada uno de los módulos
(piloto).
 Cumpla con los respectivos controles de acceso y seguridad de los datos.
3.2.4 Requerimientos de entrenamiento al usuario

 Documentación del sistema en formato digital (Word) e impreso.
 Capacitación del personal técnico impactado por la implementación de la

solución.
 Capacitación del personal funcional impactado por la implementación de la

solución.
 Manual interactivo de operación del sistema.

40

3.3 Diagramas de caso de uso del negocio
Diagrama de caso de uso – Usuario Registrador

Figura 12:
41

Figura 13: Diagramade caso de uso – Usuario Validador
Figura 14: Diagramade caso de uso – Administrador de Requerimientos

42

3.4 Diagrama del Sistema
3.4.1 Diagrama de Paquetes
Figura 15: Diagrama de paquetes

El sistema cuenta con dos paquetes que constituyen su arquitectura básica:
Mantenimiento de Instituciones Educativas y Gestión de Solicitudes. Cada uno
encierra funcionalidades separadas por la etapa en la cual intervienen en el
proyecto. Las relaciones entre paquetes implica la dependencia entre estas
agrupaciones, lo cual nos da un indicativo del orden de desarrollo requerido.
3.4.2 Diagrama de Actores
Estadistico Adm inistrador de Requerim iento
Usuario Registrador
Usuario Evaluador
Figura 16: Diagramade actores

43

3.4.3 Diagrama de Actores del Sistema
Adm inistrador de Requerim iento
Usuario Registrador Usuario Evaluador Estadistico
Figura 17: Diagramade actores del sistema

3.5 Diagrama de caso de uso por paquetes
3.5.1 Paquete de Registro de Programas
44

Figura 18: Paquete
de registro de PRONOEI
45

3.3.2 Paquete de Gestión de Requerimietos
Figura 19: Paquete de gestión de requerimientos – Administrador de

requerimientos
Figura 20: Paquete
de gestión de requerimientos – Usuario validador
46

3.6 Especificación de casos de uso del sistema
3.6.1 Especificación de paquetes

PAQUETE DE REGISTRO DE PROGRAMAS
Permitir el registro de solicitudes de creación, renovación y cierre de programas no

escolarizados de educación inicial. Así como también se permite el registro de solicitudes
de creación, modificación e inhabilitación de usuarios.
PAQUETE DE PROCESO DE SOLICITUDES Y ADMINISTRACION
Permitir el procesamiento de las solicitudes de creación, renovación y cierre de

programas. Así mismo se permite procesar las solicitudes de creación, modificación e
inhabilitación de usuarios.
3.6.2 Especificación de actores

ACTOR DESCRIPCIÓN
Usuario Estadístico UGEL - Responsable del Ingreso de las solicitudes de

Registrador creación, modificación, cambios de estado. Responsable del registro de
solicitud de creación de Usuarios de UGEL.
Usuario Responsable del procesamiento de solicitudes. Responsable de la
Validador atención a solicitudes de creación de usuarios.
Administrador Visualización del control de Avance por DRE, GRE y UGEL
3.6.3 Especificación de casos de uso

PAQUETE REGISTRO DE PROGRAMAS
 CUS103: Registrar solicitud de creación de un programa no escolarizado.

 CUS104: Registrar solicitud de renovación de un programa no escolarizado.
 CUS105: Modificación de datos de un programa no escolarizado.
 CUS106: Visualizar solicitudes en proceso.
 CUS107: Visualizar historial de solicitudes.
 CUS108: Reporte del padrón de PRONOEI.
 CUS109: Visualizar control de avance.
 CUS110: Crear Solicitud de Nuevo Usuario.
 CUS111: Crear Solicitud de Modificación de Usuario.
 CUS112: Crear Solicitud de Inhabilitación de Usuario.
 CUS113: Ingresar al Sistema.
 CUS114: Eliminar Solicitud.
 CUS115: Registrar eliminación de un PRONOEI.
 CUS116: Gestionar coordinadores.

CUS103: Registrar solicitud de creación de un programa no escolarizado.
1.- Código CUS103
2.- Nombre Registrar solicitud de creación de un programa no escolarizado
3.- Objetivo Registrar la solicitud de creación de un programa no escolarizado

de educación inicial, basado en un documento que le dé sustento.
4.- Actores Actores que intervienen:
+ Usuario UGEL
5.- Precondiciones
 Logueo en el sistema
 Existencia de la resolución que autoriza la creación del programa.
47

 El usuario debe ser de tipo UGEL
6.- Flujo Básico
1. El usuario en el menú “Nueva Solicitud” accede a la opción “Creación”.

2. El sistema muestra la pantalla de registro de datos.
3. El usuario registra los datos de identificación del programa (nombre, tipo, si
pertenece al programa presupuestal 0091, gestión, gestión-dependencia, entidad-
gestora, tipo de financiamiento).
4. El usuario registrará los datos de ubicación (dirección, referencia, ubicación
geográfica, centro poblado y la primaria más cercana). Si el usuario no encuentra el
centro poblado en la búsqueda, el usuario ingresa manualmente los datos del centro
poblado y adjuntado los datos las coordenadas y el documento de croquis del centro
poblado.
5. El usuario registrará los datos de la documentación sustentatoria y el documento de
la resolución que autoriza la creación del programa (Tipo de motivo, tipo de
documento, número de documento y fecha).
6. El usuario debe adjuntar el archivo (en formato PDF) que contiene la resolución, este
no debe pesar más de 3 MB.
7. Entre los datos complementarios, se encuentran los datos opcionales que ingresa el
usuario dentro de los datos que ingresa en esta sección está el turno, el servicio de
agua y energía eléctrica.
8. El sistema validará la información enviada y luego procederá con el envío de datos,
en caso de error en el envío del archivo, tampoco se enviarán los datos.
9. El sistema informará al usuario que el requerimiento se ha enviado correctamente.
7.- Flujos Alternativos
 El usuario, en caso de haber adjuntado el archivo en un requerimiento anterior, puede

omitir el adjuntar de nuevo el archivo.
8.- Post condiciones
Ninguna

CUS104: Registrar solicitud de renovación de un programa no escolarizado.
1.- Código CUS104
2.- Nombre Registrar solicitud de renovación de un programa no escolarizado
3.- Objetivo Registrar la solicitud de renovación de un programa no

escolarizado, basado en un documento que le dé sustento.
+ Usuario UGEL
5.- Precondiciones
 Existencia de la resolución que autoriza la modificación del programa.

 Existencia en el registro del padrón del programa no escolarizado a modificar.
 El usuario debe de tipo UGEL
6.- Flujo Básico
1. El usuario en el menú “Nueva Solicitud” accede a la opción “Renovación”.

3. El usuario hace una búsqueda del código modular a modificar.
4. El sistema llena los datos del programa a modificar en el formulario de datos.
5. El usuario modifica y/o llena datos de identificación del programa (nombre, tipo, si
48

pertenece al programa presupuestal 0091, gestión, gestión-dependencia, entidad-
gestora, tipo de financiamiento).
6. El usuario modifica los datos de ubicación (dirección, referencia, ubicación geográfica,
centro poblado y la primaria más cercana). Si el usuario no encuentra el centro
poblado en la búsqueda, el usuario ingresa manualmente los datos del centro poblado
y adjuntado los datos las coordenadas y el documento de croquis del centro poblado.
7. El usuario registrará los datos de la resolución que autoriza la modificación del
programa (Tipo de motivo, tipo de documento, número de documento y fecha).
8. El usuario debe adjuntar el archivo (en formato PDF) que contiene la resolución de
renovación del programa, el archivo no debe pesar más de 3 MB.
9. Entre los datos complementarios, se encuentran los datos opcionales a ingresar por
usuario entre ellos el ciclo, el turno, el servicio de agua y energía eléctrica.
10. El sistema validará la información enviada y luego procederá con el envío de datos, en
caso de error en el envío del archivo no se enviarán los datos.
11. El sistema informará al usuario que el requerimiento se ha enviado correctamente.

omitir el adjuntar de nuevo el archivo solamente escribiendo el nombre del archivo
adjuntado anteriormente.
Ninguna
CUS105: Modificación de datos de un programa no escolarizado.
1.- Código CUS105
2.- Nombre Modificación de datos de un programa no escolarizado
3.- Objetivo Registrar una solicitud de modificación de un programa no

+ Usuario UGEL
5.- Precondiciones
 Existencia de la resolución que autoriza el cierre del programa.

 Existencia en padrón del programa no escolarizado a cerrar.
6.- Flujo Básico
1. El usuario en el menú “Nueva Solicitud” accede a la opción “Modificación”.

3. El usuario hace una búsqueda del código modular a modificar.
4. El sistema muestra los datos del programa a modificar.
5. El usuario debe verificar que los datos mostrados, corresponden al programa que
desea modificarse.
6. El usuario registrará los datos de la resolución que autoriza la modificación (Tipo de
motivo, tipo de documento, número de documento y fecha).
caso de error en el envío del archivo, no se guardarán los datos.
9. El sistema informará al usuario que la solicitud se ha enviado correctamente.
49


Ninguna
CUS106: Visualizar solicitudes en proceso.
1.- Código CUS106
2.- Nombre Visualizar solicitudes en proceso
3.- Objetivo Listar las solicitudes registrados por el usuario en sesión y sustentar
las observaciones de las solicitudes que fueron observadas por el
usuario validador.
+ Usuario UGEL
5.- Precondiciones
 Existencia de Registro de Requerimientos.

 Logueo en el sistema.
6.- Flujo Básico
1. El Usuario en el menú accede a la opción “gestión de Solicitudes”.

2. En la primera sección el sistema muestra el listado de las solicitudes registradas en el
sistema para el usuario en sesión, donde se muestra principalmente su estado y su
situación (PENDIENTE, SUSTENTADO, OBSERVADO). En la segunda sección se
muestra las secciones donde se encuentras los botones de la acción a realizar
(Sustentar, Anular).
3. El usuario puede visualizar el listado de todas las solicitudes. Al seleccionar cada
solicitud puede visualizar la descripción de la observación realizado a cada
requerimiento.
4. El sistema muestra en la parte inferior del formulario el comentario del requerimiento
seleccionado por el usuario. El sistema activa el botón de “Sustentar” y el botón
“Anular” si la solicitud está en situación “OBSERVADO”.
5. El usuario hace clic en la opción sustentar. El sistema muestra la pantalla emergente
con los datos de la solicitud seleccionada para la corrección de los datos, los campos
a corregir que fueron observados se muestran en color rojo. El usuario ingresa los
datos a corregir de la solicitud a sustentar, adjunta los documentos de justificación y
hace clic en el botón “Enviar”. El sistema guarda los datos de la solicitud y actualiza el
estado de la solicitud a “SUSTENTADO”.
1. El usuario selecciona un registro con situación “OBSERVADO” del listado de

solicitudes.
2. El sistema habilita el botón “Anular” que se encuentra en la tercera sección del
formulario, dicho botón se habilita si el estado del requerimiento es “OBSERVADO”.
50

3. El usuario hace clic en el botón “Anular”.
4. El sistema elimina el requerimiento seleccionado, y muestra el mensaje de Anulación
satisfactoria.
Ninguna
CUS107: Visualizar historial de solicitudes.
1.- Código CUS107
2.- Nombre Visualizar solicitudes en proceso
3.- Objetivo Listar las solicitudes históricas registrados por el usuario en sesión.

+ Usuario UGEL
5.- Precondiciones
 Existencia de Registro de Requerimientos.

6.- Flujo Básico
6. El Usuario en el menú accede a la opción “Historial de solicitudes”.

7. En la primera sección el sistema muestra el listado de las solicitudes registradas en el
sistema para el usuario en sesión, donde se muestra principalmente su estado y su
situación (PENDIENTE, SUSTENTADO, OBSERVADO). En la segunda sección se
muestra las secciones donde se encuentras los botones de la acción a realizar
(Sustentar, Anular).
8. El usuario puede visualizar el listado de todas las solicitudes. Al seleccionar cada
solicitud puede visualizar la descripción de la observación realizado a cada
requerimiento.
5. El usuario selecciona un registro con situación “OBSERVADO” del listado de

solicitudes.
6. El sistema habilita el botón “Anular” que se encuentra en la tercera sección del
formulario, dicho botón se habilita si el estado del requerimiento es “OBSERVADO”.
7. El usuario hace clic en el botón “Anular”.
8. El sistema elimina el requerimiento seleccionado, y muestra el mensaje de Anulación
satisfactoria.
Ninguna
CUS108: Reporte del Padrón de PRONOEI

51

1.- Código CUS108
2.- Nombre Mostrar Reporte de Programas
3.- Objetivo Mostrar el reporte de los programas registrados en el sistema para

el usuario en sesión.
+ Usuario UGEL
5.- Precondiciones
 Existencia de Registro de Programas.

6.- Flujo Básico
1. El Usuario selecciona el menú “Programas” y luego el sub menú “Padrón”.

2. En la interfaz se muestra el filtro por situación y el listado de programas. El usuario
realiza la búsqueda, el sistema muestra el listado de los programas para la situación
seleccionada.
3. En la primera sección el sistema muestra el filtro por situación para el listado de
programas. En la segunda sección el sistema muestra el listado de todos los
programas registrados para el usuario en sesión, donde se muestran principalmente
situación y el estado de los programas.
4. El usuario hace clic en el enlace “Exportar” el sistema genera el reporte del listado de
los programas en formato Excel.
No hay flujos alternativos.
Ninguna
CUS109: Visualizar Control de Avance
1.- Código CUS109
2.- Nombre Visualizar Control de Avance
3.- Objetivo Permite visualizar el total de programas registrados y el reporte de

programas Actualizados y pendientes.
Usuario UGEL
5.- Precondiciones
 Existencia de Programas.
6.- Flujo Básico
1. El Usuario selecciona el menú “Reportes” y luego el sub menú “Control de Avance”.

2. El sistema muestra el reporte de la cantidad de programas registrados para el usuario
en sesión (Total de Programas por UGEL), el total de programas actualizados, el total
de programas no iniciados y el total de programas en proceso.
52

Ninguno
Ninguna
CUS110: Crear Solicitud de Nuevo Usuario
1.- Código CUS110
2.- Nombre Crear Solicitud de Nuevo Usuario
3.- Objetivo Permite registrar la solicitud para la creación de los datos de un

nuevo usuario UGEL.
+ Usuario UGEL
5.- Precondiciones
 El usuario debe ser de tipo Validador
6.- Flujo Básico
1. El Usuario selecciona el menú “Usuarios” y luego el sub menú “Crear”.

2. El usuario ingresa los datos personales del usuario que desea crear (tipo de
documento, nro de documento, nombres, apellido paterno, apellido materno, email,
anexo y documento sustentatorio) para generar la solicitud de creación de un nuevo
usuario UGEL.
3. El usuario hace clic en el botón “Enviar Solicitud”.
4. El sistema guarda los datos de la solicitud de creación de usuarios.
Ninguno
Ninguna

CUS111: Crear Solicitud de Modificación de Usuario
1.- Código CUS111
2.- Nombre Crear Solicitud de Modificación de Usuario
3.- Objetivo Permite registrar la solicitud para la modificación de los datos del
usuario UGEL.
+ Usuario UGEL
5.- Precondiciones
53

6.- Flujo Básico
1. El Usuario selecciona el menú “Usuarios” y luego el sub menú “Modificar”.

2. El usuario hace la búsqueda por numero documento de los datos a modificar. El
usuario hace clic en el botón en el botón buscar. El sistema devuelve los datos de un
usuario a modificar.
3. El usuario ingresa los datos personales del usuario que desea crear (nombres, apellido
paterno, apellido materno, email, anexo y documento sustentatorio) para generar la
solicitud de creación de un nuevo usuario UGEL.
5. El sistema guarda los datos de la solicitud de modificación de usuarios.
Ninguno
Ninguna

CUS112: Crear Solicitud de Inhabilitación de Usuario
1.- Código CUS112
2.- Nombre Crear Solicitud de Inhabilitación de Usuario
3.- Objetivo Permite registrar la solicitud para la Inhabilitación de los datos del
usuario UGEL.
+ Usuario UGEL
5.- Precondiciones
6.- Flujo Básico
1. El Usuario selecciona el menú “Usuarios” y luego el sub menú “Modificar”.

2. El usuario hace la búsqueda por numero documento de los datos a inhabilitar. El
usuario hace clic en el botón en el botón buscar. El sistema devuelve los datos de un a
inhabilitar.
3. El usuario ingresa los datos personales del usuario que desea crear (nombres, apellido
paterno, apellido materno, email, anexo y documento sustentatorio) para generar la
solicitud de creación de un nuevo usuario UGEL.
5. El sistema guarda los datos de la solicitud de inhabilitación de usuarios.
Ninguno
Ninguna
54

CUS113 Ingresar al Sistema
1.- Código CUS113

2.- Nombre Ingresar al Sistema
3.- Objetivo Ingresar o accesar al sistema de usuarios autorizados

+ Administrador del Sistema (Usuario)
5.- Precondiciones
Cuenta de Usuario creado.
6.- Flujo Básico
1. El Sistema muestra la opción Ingresar al Sistema.
2. El Usuario Ingresar su Cuenta de Usuario.
3. El Usuario Ingresar su Password (contraseña) de Usuario.
4. EL Usuario Acepta y envía sus datos para acceder al sistema.
5. El Sistema Verifica los datos ingresados.
5.1 Si los datos son correctos se permite el ingreso al Sistema.
5.2 Si Uno de los Datos es Incorrectos el Sistema no permite el acceso.
6. En cualquiera de los dos casos anteriores El Sistema Emite mensaje de conforme o
inconforme.

Ninguno
Ninguna

CUS114: Registrar solicitud de eliminación de una solicitud.
1.- Código CUS1114
2.- Nombre Registrar solicitud de eliminación de una solicitud.
3.- Objetivo Registrar una solicitud de eliminación de una solicitud previamente

realizada.
+ Usuario ADMINISTRADOR
5.- Precondiciones
 Existencia de una solicitud de requerimiento previamente solicitada

 El usuario debe ser de tipo ADMINISTRADOR
6.- Flujo Básico
10. El usuario en el menú “Nueva Solicitud” accede a la opción “Eliminar Solicitud”.

11. El sistema muestra la pantalla de solicitud a eliminar.
12. El usuario hace una búsqueda por DRE/GRE/Ugel y/o código modular.
13. El sistema muestra los datos de la solicitud a eliminar.
14. El usuario debe verificar que los datos mostrados, corresponden a la solicitud a
eliminar.
15. Seleccionará la solicitud a eliminar y confirmará dicha solicitud.
16. El sistema informará al usuario que la solicitud se ha eliminado correctamente.
Ninguno
55

Ninguna

CUS115: Registrar solicitud de eliminación de un programa no escolarizado.
1.- Código CUS1115
2.- Nombre Registrar solicitud de cierre de un programa no escolarizado
3.- Objetivo Registrar una solicitud de eliminación de un programa no

+ Usuario UGEL
5.- Precondiciones
 Existencia de la resolución que autoriza el cierre del programa.

 Existencia en padrón del programa no escolarizado a cerrar.
6.- Flujo Básico
17. El usuario en el menú “Nueva Solicitud” accede a la opción “Cierre”.

19. El usuario hace una búsqueda del código modular a cerrar.
20. El sistema muestra los datos del programa a cerrar.
21. El usuario debe verificar que los datos mostrados, corresponden al programa que
desea cerrarse.
22. El usuario registrará los datos de la resolución que autoriza el cierre del programa
(Tipo de motivo, tipo de documento, número de documento y fecha).
caso de error en el envío del archivo, no se guardarán los datos.
25. El sistema informará al usuario que la solicitud se ha enviado correctamente.

Ninguna

CUS116: Gestionar Coordinadores
1.- Código CUS116
2.- Nombre Asociar Coordinadores UE a DRE/GRE
3.- Objetivo Permite registrar la solicitud para la Inhabilitación de los datos del
usuario UGEL.
+ Usuario Administrador
56

5.- Precondiciones
 El usuario debe ser de tipo Administrador
6.- Flujo Básico
1. El Usuario administrador selecciona el menú “Administración” y luego el sub menú

“Coordinadores”.
2. El sistema muestra la lista de los coordinadores de la unidad de Estadística en la
columna Usuarios y lista a todas las DRE/GRE que aún no han sido asociadas a un
coordinador. Así mismo en la sección inferior “RELACIONES” muestra las relaciones
existentes entre usuarios Coordinador UE y DRE/GRE.
3. El usuario administrador selecciona a un usuario coordinador UE y puede asociar con
varios Ítems DRE/GRE. El usuario administrador hace clic en el botón “Agregar”. En la
sección “RELACIONES”, el sistema muestra la lista de las DRE/GRE previamente
seleccionadas que se asociaron con el coordinador UE.
4. El usuario hace clic en el botón “Guardar Configuración”, el sistema guarda la lista de
relaciones existentes entre coordinadores UE y las DRE/GRE mostrando el mensaje
“Datos guardados satisfactoriamente”.
Ninguno
Ninguna

57

3.7 Diagrama de actividades
 CUS103: Registrar solicitud de creación de un programa no escolarizado.
Caso de Uso
CUS103 Gestionar Creación
de Sistema
Diagrama de Actividad
 CUS104: Registrar solicitud de renovación de un programa no escolarizado.

Caso de Uso
CUS104 Solicitar Renovación
de Sistema
58

 CUS105: Modificación de datos de un programa no escolarizado.
Caso de Uso
CUS105 Modificación
de Sistema
59

 CUS106: Visualizar solicitudes en proceso.
Caso de Uso
CUS106 Visualizar solicitudes en proceso
de Sistema
60

 CUS107: Visualizar historial de solicitudes
Caso de Uso
CUS107 Visualizar historial en proceso
de Sistema
61

 CUS108: Reporte del padrón de PRONOEI.
Caso de Uso
CUS108 Reporte del Padrón de PRONOEI
de Sistema

 CUS109: Visualizar control de avance.
Caso de Uso
CUS109 Visualizar control de avance
de Sistema
 CUS110: Crear Solicitud de Nuevo Usuario

Caso de Uso
CUS110 Crear usuarios
de Sistema
62

 CUS111: Crear Solicitud de Modificación de Usuario

Caso de Uso
CUS111 Modificar usuarios
de Sistema
63

 CUS112: Crear Solicitud de Inhabilitación de Usuario
Caso de Uso
CUS112 Inhabilitar usuarios
de Sistema
64

 CUS113: Ingresar al Sistema
Caso de Uso
CUS113 Ingresar al Sistema
de Sistema
65

 CUS114: Eliminar Solicitud
Caso de Uso
CUS114 Eliminar Solicitud
de Sistema
66

 CUS115: Registrar eliminación de un PRONOEI
CUS116:
Gestionar
coordinadores CUS115 Eliminar Programa
Caso de Uso
de Sistema
67

 CUS116: Gestionar coordinadores
Caso de Uso
CUS116 Gestionar Coordinadores
de Sistema
68

69

3.8 Diagrama de secuencia
3.8.1 Diagrama de secuencia: solicitud de creación y renovación

Figura 21: Diagramade secuencia: solicitud de creación y renovación
70

3.8.2 Diagrama de secuencia: revisión de solicitud de creación y renovación
Figura 22: Diagrama de secuencia: revisión de solicitud de creación y renovación

71

3.9 Diagrama de colaboración
3.9.1 Diagrama de colaboración: solicitud de creación y renovación

Figura 23: Diagramade colaboración: solicitud de creación y renovación
72

3.9.2 Diagrama de colaboración: revisión de solicitud de creación y renovación

Figura 24: Diagramade colaboración: revisión de solicitud de creación y renovación.
73

3.10 Diagrama de estado
3.10.1 Diagrama de estado: solicitud de creación y renovación
Figura 25: Diagramade estado: solicitud de creación y renovación

74

3.10.2 Diagrama de estado: revisión de solicitud de creación y renovación
Figura 26: Diagramade estado: revisión de solicitud de creación y renovación

75

3.11 Diagrama de componentes

Figura 27: Diagramade componentes
76

3.12 Diagrama de despliegue

Figura 28: Diagramade despliegue
77

3.13 Modelo Entidad Relación
3.13.1 Modelo Conceptual de la BD
Figura 29: Modeloconceptual de la BD
78

3.13.2 Modelo Lógico de la BD

Figura 30: Modelológico de la BD
79

3.13.3 Modelo Físico de la BD

Figura 31: Modelofísico de la BD
80

3.13 Prototipo
3.13.1 Introducción
El presente documento contiene el prototipo del Sistema de registro de los
programas no escolarizados de educación inicial, para lo cual se considerarán
las pantallas principales del mismo.
3.13.2 Objetivos
El objetivo del documento es presentar el prototipo del sistema, solución que
plantea actualizar el registro de los programas no escolarizados de educación
inicial, vía internet y realizar la gestión de requerimientos solicitados.
3.13.3 Alcances
El sistema operará en todas las 26 Direcciones Regionales de Educación, en las
238 Unidades de Gestión Educativa Local y la Unidad de Estadística del
Ministerio de Educación.

3.13.4 Diseño de Interfaces
3.13.4.1 Mapa de Navegación del Sistema

El siguiente esquema representa la estructura del Sistema de registro de los
programas no escolarizados de educación inicial.

Opciones
Nueva Solicitud
Creación
Renovación
Modificación
Cierre
Gestión de solicitudes
Solicitudes en proceso
Historial de solicitudes
Reportes
Padrón
Control de avance
Usuarios
Crear
Modificar
Inhabilitar
Administración
Eliminar Solicitud
Eliminar Programa
Coordinadores
81

3.13.4.2 Caso de Uso: Ingreso al sistema

Nombre Ingreso al Sistema
Descripción
La presente pantalla nos permitirá ingresar al sistema a través del uso de las
credenciales de usuario y clave.
Pantalla
3.13.4.3 Caso de uso: Solicitud de creación de programa

Nombre Creación
Descripción
La presente pantalla permitirá a un usuario poder crear un programa.
Pantalla
82

3.13.4.4 Caso de uso: Renovación de un programa

Nombre Renovación
Descripción
83

La presente pantalla permitirá renovar un programa.
Pantalla

84

3.13.4.5 Caso de uso: Modificación de un programa
Nombre Modificación
Descripción
La presente pantalla permitirá modificar un programa.
Pantalla
85

86

3.13.4.6 Caso de uso: Cierre de un programa
Nombre Cierre
Descripción
La presente pantalla nos permitirá cerrar un programa.
Pantalla
3.13.4.7 Caso de uso: Solicitudes en proceso

Nombre Solicitudes en proceso
Descripción
La presente pantalla nos permitirá visualizar las solicitudes en proceso
Pantalla

87

3.9.4.8 Caso de uso: Historial de solicitudes

Nombre Historial de solicitudes
Descripción
La presente pantalla nos permitirá visualizar un historial de las solicitudes hechas por el
usuario activo.
Pantalla

88

3.13.4.9 Caso de uso: Reportes del padrón

Nombre Reportes del padrón
Descripción
La presente pantalla nos permitirá visualizar y llevar a Excel un padrón de los

Programas no escolarizados de educación inicial.
Pantalla
89

3.13.4.10 Caso de uso: Control de avance

Nombre Control de avance
Descripción
La presente pantalla nos permitirá visualizar el control de avance de los requerimientos

actualizados.
Pantalla
90

3.13.4.11 Caso de uso: Crear usuarios

Nombre Crear usuarios
Descripción
La presente pantalla nos permitirá crear usuarios.
Pantalla

3.13.4.12 Caso de uso: Modificar usuarios

Nombre Modificar usuarios
Descripción
La presente pantalla nos permitirá modificar usuarios.
Pantalla
91

3.13.4.13 Caso de uso: Inhabilitar usuarios

Nombre Inhabilitar usuarios
Descripción
La presente pantalla nos permitirá Inhabilitar usuarios.
Pantalla

92

3.13.4.14 Caso de uso: Eliminar Solicitud
Nombre Eliminar solicitud
Descripción
La presente pantalla nos permitirá eliminar solicitud.
Pantalla
3.13.4.15 Caso de uso: Eliminar Programa

Nombre Eliminar programa
Descripción
La presente pantalla nos permitirá eliminar un programa.
Pantalla

93

3.13.4.16 Caso de uso: Gestionar Coordinadores

Nombre Coordinadores
Descripción
La presente pantalla nos permitirá gestionar coordinadores.
Pantalla
94

3.14 Pruebas de software
Las pruebas de software, son necesarias en todo desarrollo de una aplicación
ya que el resultado final es hacer un diagnóstico de la calidad de la
funcionabilidad y rendimiento del aplicativo, tanto de los flujos de información,
procedimientos, funciones, datos de entrada, datos de salida, resultados
esperados de los mismos, performance, estabilidad, tiempo de respuesta, etc.
Estas pruebas consisten en encontrar inconsistencia o defectos en los datos de
entrada, dado que la información de salida es de vital importancia para el
sector Educación y para la toma de decisiones a nivel gerencial, esta no debe
tener sesgos, y debe ser lo más exacta posible, reflejando la realidad actual de
las características de los PRONOEI.
En el desarrollo de software las pruebas son una parte muy importante, pero a
su vez muy costosa, estas pruebas pueden llegar a costar hasta el 50% del
costo total del proyecto. Sin embargo las fallas de funcionalidad y
95

operacionales del software, de no ser detectadas en este proceso o no incluir
esta etapa pueden llegar a tener consecuencias muy costosas para el proyecto.
Las pruebas realizadas a la aplicación WEB fueron pruebas funcionales y
pruebas unitarias:
3.14.1 Pruebas funcionales

Dentro de las pruebas funcionales podemos destacar:
 Pruebas de acceso al aplicativo y validación de cuentas de usuario por
perfil (usuario Estadístico, usuario Registrador, usuario Evaluador y
Administrador de Requerimientos).
 Operatividad de la funcionalidad de la aplicación, de acuerdo a lo
especificado en los CUS.
 El correcto registro de los datos en la base de datos y su posterior
visualización en los reportes generales.
3.14.2 Pruebas unitarias

Dentro de las pruebas unitarias podemos destacar:
 Se realizó pruebas de performance y pruebas de conectividad.
 Pruebas de consistencia de datos. La base de datos debe reflejar lo que
se ha ingresado al momento del registro de los PRONOEI, datos de
identificación y ubicación geográfica.
3.14.3 Reporte de observaciones

A continuación se muestra unas pantallas con las observaciones encontradas
en la aplicación WEB:
96

3.14.3.1 Gestión de solicitudes – Solicitudes en proceso
CUADRO DE OBSERVACIONES 1
CALIDAD
ÍTEM 1.
NOMBRE CUS Gestión de solicitudes – Solicitudes en
proceso
TIPO OBSERVACIÓN Fondo
OBSERVACIÓN Alerta
LOGIN Usuario: 19000123
Clave: RSS1975MSA
ROL Usuario: UGEL
DESCRIPCIÓN Validar campos de filtro fecha y código
modular. Al campo fecha se recomienda
poner un calendario.
PANTALLAS
SOLUCIÓN
<Capturas de pantallas de la solución>
Se realizó la actualización de acuerdo a lo observado
Analista Programador 1
3.14.3.2 Registrar solicitud de creación

CALIDAD
ÍTEM 2.
NOMBRE CUS Registrar solicitud de creación de un
programa no escolarizado
OBSERVACIÓN Alerta
Clave: RSS1975MSA
ROL Usuario: UGEL
DESCRIPCIÓN
Según lo indicado en los correos, el
97

CUS no ha sido modificado, pero al
revisarlo en el sistema se encontró el
error indicado.
Al registrar una solicitud de creación de
un programa no escolarizado dando
clic en “Enviar”, el sistema indica que
existen errores en el formulario, el cual
no especifica que errores son.
PANTALLAS
SOLUCIÓN
Se corrigió el error de acuerdo a lo observado

3.14.3.3 Acceso al Sistema

98

CALIDAD
ÍTEM 3.
NOMBRE CUS Acceso al sistema.
OBSERVACIÓN Alerta
Clave: RSS1975MSA
ROL Usuario: UGEL
DESCRIPCIÓN
Según lo indicado en los correos, el
CUS no ha sido modificado, pero al
revisarlo en el sistema se encontró el
error indicado.
Al ingresar 3 veces las credenciales de
forma incorrecta, el sistema muestra
error en el captcha.
PANTALLAS

SOLUCIÓN
<Capturas de pantallas de la solución>
En el despliegue realizado en Pre-Producción no se realizó la configuración para
activar el CAPTCHA. Para el siguiente despliegue se considerara la configuración.
3.14.3.4 Modificación de datos

CALIDAD
ÍTEM 4.
99

NOMBRE CUS Modificación de datos.
OBSERVACIÓN Alerta
Clave: RSS1975MSA
ROL Usuario: UGEL
DESCRIPCIÓN En el formulario de modificación se
ingresó en el campo zona y otros 45B y
portón 5 respectivamente (imagen 1). Al
validar la modificación, lo ingresado en
los campos mencionados se muestran
juntas (imagen 2)
PANTALLAS

SOLUCIÓN
Se realizó la corrección de acuerdo a lo observado.

3.14.3.5 Gestión de solicitudes – Solicitudes en proceso

CALIDAD
ÍTEM 5.
NOMBRE CUS Gestión de solicitudes – Solicitudes en
100

proceso.
OBSERVACIÓN Alerta
Clave: RSS1975MSA
ROL Usuario: UGEL
DESCRIPCIÓN No permite registrar observaciones para
la solicitud seleccionada.
PANTALLAS

SOLUCIÓN
101

El espacio solo corresponde a la observación realizada por el validador. Solo es
para la lectura del usuario UGEL.

102

CAPÍTULO 4
RESULTADOS
En este capítulo se va a detallar el análisis de los resultados, planificación del tiempo y

planificación de los costos.
4.1 Resultados
Nuestros resultados logrados se muestran a continuación:
 Se logró analizar y diseñar los procesos y flujos de información del

desarrollo de software, usando la metodología RUP.
 Se logró estructurar y elaborar la base de datos, usando el sistema de

gestión de base de datos MySQL 5.1.
 Se generó el contenido gráfico y dinámico para web, usando el lenguaje de

programación HTML 5.1.
 Se logró aprobar el 90% de solicitudes en comparación con la aplicación

local que fue de 59%, del 29% de solicitudes observadas que se tenían se
redujo al 7% y del 16% de solicitudes duplicadas se redujo al 3%, tal como
se muestra en la figura 32: Comparativo de solicitudes de requerimiento.

Figura 32: Comparativode solicitudes de requerimiento
103

 El proceso de actualización del padrón de los programas no escolarizados
de educación inicial se redujo de 90 a 30 días.

Figura 33: Actualización
del padrón de PRONOEI
4.2 Planificación del tiempo
4.2.1 Cronograma del proyecto

En esta etapa de planificación del tiempo, mostraremos el tiempo que demora
la conclusión de la aplicación WEB, se estima la culminación en 3 meses. En la
figura 34: Cronograma de actividades, se detalla las actividades a desarrollar
en el proyecto.

104

Figura 34: Cronograma de actividades

Fuente: Fuente propia

105

4.3 Hitos del proyecto
En la tabla 5 Hitos del proyecto, mostramos la duración de las actividades, el

cual nos da una idea general del inicio, avance y término del proyecto.
Tabla 5
Hitos del proyecto
Nro NOMBRE FECHA
1 Acta de Constitución del Proyecto 15/08/2015
2 Plan de Gestión de Proyecto 20/08/2015
3 Requerimiento de Usuario terminada 22/08/2015
4 Documento de Análisis de Requerimientos Técnicos 22/08/2015
5 Diseño del Sistema 21/10/2015
6 Fin de Construcción de Software 28/10/2015
7 Manual de usuario 21/10/2015
8 Manual de Instalación y Configuración 21/10/2015

4.4 Conclusiones
 Cumplir todas las fechas programadas en el cronograma del proyecto, para
no tener que ampliar el tiempo del proyecto, ya que esto generaría un gasto
extra.
 Al momento de la selección del personal tanto de gestión como técnico,
asegurar de que este sea el idóneo para la función que va a desarrollar.
 El personal técnico debe tener experiencia en el lenguaje de programación
y metodología a desarrollar, para evitar retrasos en los tiempos
establecidos.
 El personal debe estar comprometido con sacar adelante el proyecto,
demostrando mucha entrega, disponibilidad de tiempo, trabajo en equipo y
responsabilidad en el desarrollo de sus funciones.
 Implementar un plan de contingencia para ponerlo en práctica ante
cualquier eventualidad, tanto en recurso humano como económico.

4.5 Planificación de los costos

Para estimar los costos y presupuestos para el desarrollo y éxito de la aplicación
WEB, definiremos los recursos que vamos a utilizar, estos son:
4.5.1 Recurso humano

Este Recurso está formado por el personal profesional y técnico que usaremos en
nuestro proyecto, el cual en base a su experiencia y conocimiento, forman el pilar
fundamental para el éxito de nuestro proyecto. Se detalla en la tabla 6 Tipo de
personal y montos de remuneraciones, agregando su ingreso mensual expresado
en moneda nacional Soles (S/.). Los descuentos por impuestos de ley, tanto
106

impuesto a la renta (4ta o 5ta categoría) y AFP están incluidos en los montos
establecidos.
Tabla 6

Tipo de personal y montos de remuneraciones

TIPO DE
PERSONAL ROL CÓDIGO CANT. SUB TOTAL TOTAL
Personal de Gestión Jefe de Proyecto JP 1 8,000.00 8,000.00
Personal de Gestión Líder Funcional LF 1 7,500.00 7,500.00
Personal de Gestión Líder Técnico LT 1 6,000.00 6,000.00
Personal Técnico Analista Programador AP 2 4,500.00 9,000.00
Personal Técnico Arquitecto de Datos AD 1 3,200.00 3,200.00
Personal Técnico Gestor de Calidad GC 1 2,800.00 2,800.00
Nota: Lo montos están expresados en soles (S/.)
4.5.2 Recurso Tecnológico

Este Recurso está formado por el equipo de cómputo y licencias utilizadas en el
desarrollo de nuestro proyecto. Están detallados en la tabla 7 Recursos
tecnológicos y costos, los montos están expresados en moneda nacional Soles
(S/.), y no incluyen los impuestos de ley (IGV).
Tabla
7
Recurso tecnológico y costos
SUB VIDA PAGO
TIPO DETALLE ESTADO CANT TOTAL
TOTAL ÚTIL MENSUAL
Equipo Servidor de la Existente 1 120,000.00 120,000.00 36 3,333.33
aplicación
Equipo Servidor de BD Existente 1 120,000.00 120,000.00 36 3,333.33
Licencia Licencias de Adquirir - - - - 500.00
software
4.5.3 Otros gastos

En la tabla 8 Otros gastos, detallamos los gastos extras y gastos imprevistos que
pudiesen suscitarse durante el desarrollo del proyecto. Los montos están
expresados en moneda nacional Soles (S/.), y no incluyen los impuestos de ley
(IGV).
Tabla 8
Otros gastos
SUB PAGO
DETALLE CANT TOTAL VIDA ÚTIL
TOTAL MENSUAL
Equipo móvil 4 1,000.00 4,000.00 36 27.78

Servicio móvil - - - - 400.00
Otros gastos - - - - 500.00
107

4.5.4 Cuadro de asignación de recursos
El desarrollo de nuestro proyecto, se va a desarrollar en 3 meses, identificando 3
etapas, análisis y diseño, desarrollo y pruebas y ajustes. No se ha tomado en
cuenta la variable costo empresa, ya que la entidad que desarrollará en proyecto
es una entidad pública. Los montos están expresados en moneda nacional Soles
(S/.). En la tabla 9 Cuadro de asignación de recursos, mostramos el cuadro de
asignación de recursos.
Tabla
9
Cuadro de asignación de recursos
ANÁLISIS Y PRUEBAS Y
COD CAN SUEL DESARROLLO TOTAL
ROL DISEÑO AJUSTES
. T DO ES
Mes 1 Mes 2 Mes 3
Jefe de Proyecto JP 1 8,000 100 8,000 100% 8,000 100% 8,000 24,000
%
Líder Funcional LF 1 7,500 100 7,500 100% 7,500 100% 7,500 22,500
%
Líder Técnico LT 1 6,000 0% - 100% 6,000 100% 6,000 12,000
Analista AP 2 4,500 0% - 200% 9,000 200% 9,000 18,000
Programador
Arquitecto de AD 1 3,200 0% - 100% 3,200 100% 3,200 6,400
Datos
Gestor de Calidad GC 1 2,800 0% - 0% 0 100% 2,800 2,800
TOTALES 32,000 15,500 33,700 36,500 85,700
4.5.5 Flujo del proyecto

El flujo del proyecto se presenta en la tabla 10 Flujo del proyecto en meses, por
los tres meses de duración del proyecto. Los montos están expresados en
moneda nacional Soles (S/.). Se incluye el gráfico de costos acumulados (Figura
35 Curva S del proyecto).
Tabla
10
Flujo del proyecto en meses
MESES %
COSTOS 1 2 3 TOTAL
GASTO
Personal 15,500.00 33,700.00 36,500.00 85,700.00 83.35
Equipos (2 servidores) 6,666.67 6,666.67 13,333.33 12.97
Licencias 500.00 500 1,000.00 0.97
Equipos móviles 27.78 27.78 27.78 83.33 0.08
Servicios móvil 400.00 400.00 400.00 1,200.00 1.17
Otros Gastos 500.00 500.00 500.00 1,500.00 1.46
TOTAL 16,427.78 41,794.44 44,594.44 102,816.67 100.00
ACUMULADO 16,427.78 58,222.22 102,816.67

108

Curva S Avance del Proyecto
120,000.00
100,000.00
Expresado en Soles (S/.)
80,000.00
COSTOS
60,000.00
Curva "S"
40,000.00
20,000.00
‐
Mes 1 Mes 2 Mes 3

Figura 35: Curva
S avance del proyecto
4.5.6 Flujo de caja

El flujo de caja se presenta en la tabla 11 Flujo de caja. Los montos están
expresados en moneda nacional Soles (S/.).
Tabla 11
Flujo de caja
FLUJO DE CAJA
DESCRIPCIÓN TOTAL
mes-1 mes-2 mes-3
INGRESOS 50,154.47 75,231.71 125,386.18
EGRESOS 16,427.78 41,794.44 44,594.44 102,816.67
FLUJO NETO 33,726.69 41,794.44 30,637.26 22,569.51
ACUMULADO 33,726.69 8,067.75 22,569.51
4.5.7 Tasas de descuento VAN y TIR del proyecto

En la tabla 12 Cálculo del precio, mostramos el cálculo del precio, incluye el
costo total del proyecto, el margen expresado en porcentaje, el precio y la
utilidad obtenida. Los montos están expresados en moneda nacional Soles
(S/.).
Tabla 12
Cálculo del precio
CÁLCULO DEL PRECIO
Costo 102,816.67
Margen 18%
Precio 125,386.18
Utilidad 22,569.51

109

En la tabla 13 Formas de pago, mostramos las formas de pago, que son el 40%
al inicio del proyecto y el 60% a la entrega del producto final. Los montos están
expresados en moneda nacional Soles S/.).
Tabla 13
Formas de pago
FORMAS DE PAGO
Inicio 40% 50,154.47
Entrega 60% 75,231.71
En la tabla 14 Tasas de descuento, mostramos las tasas de descuento, la

anual y la mensual. Los montos están expresados en moneda nacional Soles
S/.).
Tabla 14
Tasas de descuento
TASAS DE DESCUENTO
Tasa de descuento anual 12%
Tasa de descuento mensual 0.949%
VANI S/. 245,390.67
VAN NETO S/. 43,911.49
Finalmente en la tabla 15 Rentabilidad, mostramos el van neto, en cual nos da

18%, el cual nos demuestra que nuestro proyecto, desarrollo de una aplicación
web es rentable.
Tabla 15
Rentabilidad
RENTABILIDAD
VAN NETO / VANI 17.89%
110

CONCLUSIONES
 Usando la metodología RUP, se logró elaborar los procesos y flujo de
información. Logrando un monitoreo al flujo de información.
 Se logró crear la base de datos, usando el sistema de gestión de bases de

datos MySQL 5.1. Haciendo pruebas con la integridad de los datos y la
estructura de la base de datos.
 Se crearon las páginas web de la aplicación WEB, mediante el lenguaje de

programación HTML 5.1., verificando su interfaz gráfica y su compatibilidad
con los diversos navegadores web. (Mozilla, Internet Explorer, Google
Chrome, etc.)
 Se crearon, compilaron y ejecutaron los programas fuente de interconexión

con la base de datos, usando JAVA JDK 1.6, se analizaron los
procedimientos de lectura, grabado, inserción, eliminación y modificación
de registros de las bases de datos.

111

RECOMENDACIONES
 Normativo:
 Se recomienda incluir el resto de niveles y/o modalidades para el

proceso de actualización de datos de las Instituciones Educativas.
 Mantener una correcta documentación y los códigos fuentes dado que

la normatividad cambia constantemente y está sujeta a las políticas de
estado del gobierno de turno, esta normatividad en lo referente a los
programas no escolarizados puede cambiar y el aplicativo debería de
adaptarse a esta normatividad.
 Técnico:
 Se recomienda el uso de herramientas de software libre, profesionales y

de escasa documentación, ya que el uso de estas no incurre en gastos
de licencia.
 Repotenciar las DRE/GRE y UGEL a nivel nacional con hardware y

software para el correcto funcionamiento de la aplicación web.
 La aplicación actual SIEMED que funciona de manera local, debería

seguir funcionando, como una aplicación de respaldo, ya que en
determinadas zonas geográficas no hay internet de alta velocidad o es
lenta.
 Dado que los cargos de los usuarios registradores que laboran en

Instancias de Gestión Educativa Descentralizada, tanto DRE/GRE como
UGEL, en muchas ocasiones son seleccionados por parte de las
autoridades locales, siendo este cargo muy volátil y dependiente de las
autoridades de turno. Es de suma importancia definir correctamente e
identificar al personal que se va a logear a la aplicación, manteniendo
un correcto registro, dado que la información que se registra es muy
sensible y de mucha importancia para el sector educación.

112

GLOSARIO

MINEDU: Ministerio de Educación del Perú.
Entidad que se encarga del Sector Educación del Estado Peruano. Es la que
determina los lineamientos y políticas de Estado para el Sector Educación.
UE: Unidad de Estadística.

Unidad operativa del Ministerio de Educación, funcionalmente depende de la
Secretaría de Planificación Estratégica del Ministerio de Educación. Sus
principales funciones son registrar a todas las Instituciones y Programas
Educativos a nivel nacional, tanto en la gestión pública y privada y captar
información estadística de las mismas.
IGED: Instancia de Gestión Educativa Descentralizada.

Término para referirse a las Instituciones Educativas Descentralizadas
localizadas en todo el territorio nacional. Estas son las DRE, GRE y UEL.
DRE: Dirección Regional de Educación / GRE: Gerencia Regional de

Educación.
Entidad que depende funcional y jerárquicamente del Ministerio de Educación,
a nivel nacional existen 26 Direcciones Regionales de Educación. Cada región
geográfica es una Región Educativa. Dentro de su jurisdicción es la que se
encarga que se cumplan los lineamientos, normas, directivas, etc. decretadas
por el Ministerio de Educación. Jerárquicamente las DRE y GRE tienen el
mismo nivel de jerarquía funcional.
UGEL: Unidad de Gestión Educativa Local.

Entidad que depende de la Dirección Regional de Educación, nivel nacional
existen 238 Unidades de Gestión Educativa Local. Por lo general esta
dependencia administra toda una provincia de su Región. Dentro de su
jurisdicción es la que se encarga que se cumplan los lineamientos, normas,
directivas, etc. Decretadas por el Ministerio de Educación y las Direcciones
Regionales de Educación.
PRONOEI: Programa No Escolarizado de Educación Inicial.

Son programas cuya función es la de reemplazar a los Centros Educativos de
Educación Inicial. Generalmente se encuentran ubicadas en zonas marginales
y de extrema pobreza. Atienden a niños de 0 a 6 años, estos programas son
atendidos por una profesora llamada animadora, son captadas generalmente
de la misma comunidad, para poder ejercer no es necesario el nivel educativo
alcanzado. Estas profesoras animadoras son monitoreadas por una docente
coordinadora que si debe cumplir ciertos requisitos necesarios para poder
ejercer. Las profesoras animadoras reciben una propina por parte del estado,
las docentes coordinadoras si reciben un salario por parte del Ministerio de
Educación.

113

BIBLIOGRAFÍA
 Publicaciones Vértice S.L. (2009). Diseño Básico de Páginas Web en HTML.

Málaga, España: Vértice
 Jacobson, I., Booch G. y Rumbaugh, J. (2000). El proceso Unificado de

Desarrollo de Software. Málaga, España: Pearson.
 Joyanes, L. y Zahonero, I. (2011). Programación en JAVA 6, D.F. Mexico: Mc

Graw Hill.
 Marqués, M. (2011). Base de datos. Castellon, España: Universidad de Jaume I.
 Rojas, M., y Sullca, G. (2012). Desarrollo de una Aplicación Web Para el Registro
de Historias Clínicas Electrónicas (HCE) para el Hospital Nacional Guillermo
Almenara (tesis de grado). Universidad Tecnológica del Perú, Lima, Perú.
 Vargas, J. (2012). Diseño e Implementación de una Aplicación Web de Control

de Inventario y Rastreo de Puntos de Venta (tesis de grado). Universidad
Simón Bolívar, Caracas, Venezuela.
114

Rolando Soriano - Jack Osorio - Trabajo de Suficiencia Profesional - Titulo Profesional - 2017

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Rolando Soriano - Jack Osorio - Trabajo de Suficiencia Profesional - Titulo Profesional - 2017

Cargado por

Copyright:

Formatos disponibles

Ingeniería de Sistemas e Informática

Trabajo de Suficiencia Profesional:

“DESARROLLO DE UNA APLICACIÓN

Para optar el Título Profesional de Ingeniero de

Y a mi padre Claudio que aunque no estés presente, me dejaste tus

Y a ti padre Manuel, que aunque estemos en mundos diferentes siempre te voy

El presente Trabajo de Suficiencia Profesional, fue creado con la finalidad de

CAPÍTULO 2 ................................................................................................................ 14.

CAPÍTULO 3 ................................................................................................................ 37.

CAPÍTULO 4 .............................................................................................................. 103.

CONCLUSIONES ...................................................................................................... 111.

La Unidad de Estadística (UE), es una Unidad Operativa del Ministerio de

En la aplicación WEB se podrán registrar la creación y actualización de datos

No se registrará el resto de niveles y/o modalidades que comprende el Sistema

En este capítulo se va a detallar la definición del problema, descripción y formulación

1.1 Definición del Problema

1.1.1 Descripción del Problema

Como se observa en la figura 1 Árbol de problemas para la Unidad de

 Retorno de solicitudes requeridas en 6 días calendario.

 Registro de los Programas No Escolarizados de Educación Inicial

 Programas No Escolarizados no beneficiados con programas de apoyo

 Recarga laboral al momento de procesar solicitudes de requerimientos

1.1.2 Formulación del Problema

1.2 Definición de Objetivos

1.2.1 Objetivo General

 Estructurar y elaborar la base de datos, usando el sistema de gestión de

 Generar el contenido gráfico y dinámico para web, usando el lenguaje de

 Elaborar e implementar los programas de interconexión entre la interfaz

1.2.3 Alcances y Limitaciones

Se optimizaran recursos de la Unidad de Estadística tanto humanos como

Esto generará una rápida y versátil distribución de los recursos materiales y

1.2.5 Estado del Arte

1.2.5.1 Registro de Historias Clínicas Electrónicas para un Hospital

1.2.5.2 Aplicación de Control de Inventario y Rastreo de Puntos de Venta

En ambos proyectos los autores plantean la misma problemática, deficiente

En este capítulo se van a detallar los aspectos generales y definiciones teóricas.

2.1 Aspectos Generales

2.1.1 Rol de la Unidad de Estadística del Ministerio de Educación

2.1.2 Definiciones Teóricas

2.2.1 Aplicaciones WEB

La metodología RUP descarta ser una metodología con procedimientos

A la Metodología RUP se le reconoce como un software, construido y creado

A continuación describiremos las principales características según Jacobson,

 Describir la organización, documentación, funcionalidad y restricciones

 Documentar y registrar las decisiones que se tomen para el desarrollo

 Implementar los diferentes diagramas de UML, dando paso a la

Empero, la valoración de las características del software que actualmente

El diagnostico de un sistema de información se ha construido aplicando las

Una propuesta muy importante es el producción y producción in house la cual

2.2.2.2 Principios del RUP

El proceso deberá adaptarse a las necesidades del cliente ya que es

Las Características de los diversos participantes pueden ser diferentes,

 Demostrar valor iterativamente:

Los proyectos se entregan, aunque sea de un modo interno, en cada

 Colaboración entre equipos:

El desarrollo de software no lo hace una única persona sino múltiples

 Elevar el nivel de abstracción:

Inicialmente el dominio motiva el uso de terminos reutilizables tales

La administración de calidad se desde de aplicar en cada iteración, de

La metodología RUP está compuesta en cuatro fases, en cada fase de

Figura 5: Ciclo de vida del RUP. Recuperado de

Cuando las organizaciones no utilizaban las bases de datos, se trabajaba con