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

1  

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 

   

2  

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.

 

 

 

 

 

 

 

 

 

 

 

 

3  

 

 

   

4  

Í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.

5  

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.

6  

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.

7  

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.

8  

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.

 

 

 

 

 

 

 

 

9  

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

10  

 

 

 

 

 

 

 

 

 

 

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.

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

Fuente: Elaboración propia.

11  

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

12  

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.

13  

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.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

14  

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.

 

 

 

 

 

15  

Figura 2: Arquitectura de las aplicaciones web Fuente: Elaboración propia

16  

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.

17  

   

 

 

 

 

 

 

 

 

 

 

 

 

 

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

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 

18  

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.

19  

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. 

20  

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

21  

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

22  

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.

23  

 

 

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.

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

24  

Conocer lenguajes de tercera o cuarta generación para implementar los procesos mencionados.

Usuarios:

Ingreso masivo de información.

 

 

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.

Figura 8: Entorno de las bases de datos Fuente: Elaboración propia

25  

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.

26  

El hecho de que todo esté centralizado en el SGBD hace que el sistema sea más vulnerable ante los fallos que puedan producirse.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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.

Figura 9: Resumen de versiones de MySQL y estados actuales de desarrollo. Recuperado de http://prograwebn4.blogspot.pe/

27  

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.

 

 

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:  

Figura 10: Estudio sobre gestores de base de datos Fuente: Estudio Forrester 2009 sobre gestores de Base de Datos

28  

MANEJADOR DE BASE DE DATOS 

PRECIO  VENTAJAS   DESVENTAJAS  CAPACIDAD REQUERIMIENTOS DE HARDWARE 

 

Sin costo Buen rendimiento, buena

velocidad a la hora de conectar con el servidor y de respuesta a consultas. Registros sin límite de

tamaño. Control de acceso: qué

usuarios tienen acceso a qué tablas y con qué permisos. 

No Soporta vistas Win32 w/ FAT/FAT32 2GB/4GB Win32 w/ NTFS 2TB Linux 2.2-Intel 32-bit 2GB (LFS: 4GB) Linux 2.4+ (usando ext3 filesystem) 4TB Solaris 9/10 16TB MacOS X w/ HFS+ 2TB NetWare w/NSS filesystem 8TB 

RAM :512 MB Memoria

virtual1: 1024 MB Protocolo de red

TCP/IP Protocolo de red

TCP/IP con SSL 

 

300 a 40,000 US$

dependiendo del tipo de licencia y

usuario

Suite de productos que ofrece una gran variedad de herramientas. Oracle corre en

computadoras personales, microcomputadoras, mainframes y computadoras con procesamientos paralelo masivo. Soporta unos 17 idiomas. Corre automáticamente en

mas de 80 arquitecturas de hardware y software distinto sin tener la necesidad de cambiar una sola línea de código. Oracle es la base de datos

con más orientación hacia internet. 

Sucedieron varias versiones con correcciones, hasta alcanzar la estabilidad en la 8.0.3. Oracle mal

configurado puede ser desesperantemente lento. 

La capacidad de BDD es alta ya que soporta hasta 4 peta bytes de información.

RAM :256MB mínimo MEMORIA

VIRTUAL : doble de la cantidad de RAM Espacio de disco

duro: se especificara a continuación Espacio para

archivos temporales :100 Mb Adaptadores de

video :256 colores Procesador: 200

MHz mínimo Protocolo de red

TCP/IP

Tabla 2 Cuadro comparativo de gestores de bases de datos

29  

 

40 a 2,000 US$ dependiendo del tipo de licencia y usuario.

Administración multi-servidor y con una sola consola. Ejecución y alerta de

trabajos basadas en eventos. Seguridad integrada. Se ajusta muy bien a las

necesidades cada vez mayores. Para las bases de datos

muy grandes. Ideal para sistemas de lata

tecnología. 

Gran cantidad de memoria RAM ara la instalación y utilización del software. Costo de

actualizaciones. La relación

calidad-precio esta muy debajo comparado con Oracle. 

SQL Server admite 25 instancias en un clúster de conmutación por error cuando se usa un disco de clúster compartido como opción de almacenamiento para la instalación del clúster; SQL Server admite 50 instancias en un clúster de conmutación por error si elige recursos compartidos de archivos SMB como opción de almacenamiento para la instalación del clúster.

RAM: Mínimo: 512 MB Recomendado:

2,048 GB o más Tipo de

procesador: Procesador Itanium o más rápido Velocidad de

procesador: Recomendado: 1,0 GHz o más 

 

 

100 a 250 US$, software comprende todo el OFFICE.

Tablas para almacenar los datos. Consultas para buscar y

recuperar únicamente los datos que necesita. Informes para analizar o

imprimir los datos con un diseño específico. Páginas de acceso a datos

para ver, actualizar o analizar los datos de la base de datos desde internet o desde una intanet. 

Tiene limitaciones en el procesamiento de las búsquedas. Poca estabilidad

cuando maneja grandes volumenes de información. Específica para

proyectos pequeños dada sus limitaciones.

 

Capacidad hasta 1GB de información, es limitada.

RAM: 1 GB (32 bits) o 2 GB (64 bits) Procesador de

x32 o x64 bits a 1 GHz o más rápido con instrucciones SSE2.

 

Fuente: Elaboración Propia

30  

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.

31  

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.

LENGUAJE  PRECIO  VENTAJAS  DESVENTAJAS 

 

 

 

Sin costo La sencillez de su

programación. Muy rápido de

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.  

No permite manejar Base de Datos. Funcionalidad limitada.  

 

Tabla 3 Cuadro comparativo de lenguajes de programación para páginas WEB

32  

 

Sin Costo Lenguaje de scripting

seguro y fiable. Los script tienen

capacidades limitadas, por razones de seguridad. El código JavaScript

se ejecuta en el cliente.

Código visible por cualquier usuario. El código debe

descargarse completamente. Puede poner en riesgo

la seguridad del sitio, con el actual problema llamado XSS.

 

Sin Costo Muy fácil de

aprender. Se caracteriza por

ser un lenguaje muy rápido. Soporta en cierta

medida la orientación a objeto. Clases y herencia. Incluye gran cantidad

de funciones. No requiere

definición de tipos de variables ni manejo detallado del bajo nivel.

Se necesita instalar un servidor web. La legibilidad del

código puede verse afectada al mezclar sentencias HTML y PHP. La programación

orientada a objetos es aún muy deficiente para aplicaciones grandes. Dificulta la

organización por capas de la aplicación.

 

Versiones Con Costo. Versiones

Sin Costo.

Completamente orientado a objetos. Controles de usuario

y personalizados. 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.

Mayor consumo de recursos.

 

 

 

 

 

 

Fuente: Elaboración propia

33  

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

34  

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

35  

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.

 

 

LENGUAJE  PRECIO  VENTAJAS  DESVENTAJAS 

 

 

 

Sin costo  Fuente  abierta,  no tiene  pago  de  patentes anuales.  Plataforma independiente.  Manejo automático de la memoria.  Lenguaje multiplataforma,  es decir  el  programa  se ejecutará  en  cualquier  plataforma.  Sintaxis  similar  a C/C++,  pero  más simple. 

 

Menos  eficiente, comparado con C/C++.  Requiere  de  un intérprete.  Una  mala implementación  de  un programa,  puede resultar  algo  muy  lento de ejecutarse.  

 

Tabla 4 Cuadro comparativo de lenguajes de programación para conexión de base de datos vía web

36  

 

Pagado  Posee  una  facilidad  de uso,  ambiente amigable,  clásico  de Windows. 

Ahorro  de  código,  ya que  la  programación está  orientada  a objetos.  Seguridad en el manejo de datos. 

Se  tiene  que  tener  una versión  reciente  de Visual Studio .NET.  Los  requerimientos mínimos  del  sistema para  que  pueda funcionar adecuadamente  son  4 GB de espacio  libre para la  pura  instalación  con Windows  NT  4  o superior. 

 

 

Fuente: Elaboración Propia.

37  

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.

38  

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.

39  

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.

Figura 12: Proceso actual del registro de los PRONOEI Fuente: Elaboración propia

40  

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.

 

 

 

 

 

 

 

 

 

 

 

 

 

41  

3.3 Diagramas de caso de uso del negocio

 

Figura 12: Diagrama de caso de uso – Usuario Registrador Fuente: Elaboración propia

42  

Figura 13: Diagrama de caso de uso – Usuario Validador Fuente: Elaboración propia

Figura 14: Diagrama de caso de uso – Administrador de Requerimientos Fuente: Elaboración propia

43  

3.4 Diagrama del Sistema

3.4.1 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

Administrador de Requerim iento

Usuario Registrador Usuario Evaluador

Estadistico

Figura 15: Diagrama de paquetes Fuente: Elaboración propia

Figura 16: Diagrama de actores Fuente: Elaboración propia

44  

3.4.3 Diagrama de Actores del Sistema

3.5 Diagrama de caso de uso por paquetes

3.5.1 Paquete de Registro de Programas

Administrador de Requerimiento

Usuario Registrador Usuario Evaluador Estadistico

Figura 17: Diagrama de actores del sistema Fuente: Elaboración propia

45  

 

 

 

Figura 18: Paquete de registro de PRONOEI Fuente: Elaboración propia

46  

3.3.2 Paquete de Gestión de Requerimietos

Figura 19:  Paquete de gestión de requerimientos – Administrador de requerimientos Fuente: Elaboración propia

Figura 20: Paquete de gestión de requerimientos – Usuario validador Fuente: Elaboración propia

47  

3.6 Especificación de casos de uso del sistema

3.6.1 Especificación de paquetes

3.6.2 Especificación de actores ACTOR DESCRIPCIÓN

Usuario Registrador

Estadístico UGEL - Responsable del Ingreso de las solicitudes de creación, modificación, cambios de estado. Responsable del registro de solicitud de creación de Usuarios de UGEL.

Usuario Validador

Responsable del procesamiento de solicitudes. Responsable de la 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

 

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.

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.

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.

48  

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.

4.- Actores Actores que intervienen: + 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. Logueo en el sistema 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”. 2. El sistema muestra la pantalla de registro de datos. 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

49  

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.

7.- Flujos Alternativos

El usuario, en caso de haber adjuntado el archivo en un requerimiento anterior, puede omitir el adjuntar de nuevo el archivo solamente escribiendo el nombre del archivo adjuntado anteriormente.

8.- Post condiciones

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 escolarizado, basado en un documento que le dé sustento.

4.- Actores Actores que intervienen: + 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. Logueo en el sistema El usuario debe ser de tipo UGEL

6.- Flujo Básico

1. El usuario en el menú “Nueva Solicitud” accede a la opción “Modificación”. 2. El sistema muestra la pantalla de registro de datos. 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). 7. El usuario debe adjuntar el archivo (en formato PDF) que contiene la resolución, este

no debe pesar más de 3 MB. 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, no se guardarán los datos. 9. El sistema informará al usuario que la solicitud se ha enviado correctamente.

50  

7.- Flujos Alternativos

El usuario, en caso de haber adjuntado el archivo en un requerimiento anterior, puede omitir el adjuntar de nuevo el archivo solamente escribiendo el nombre del archivo adjuntado anteriormente.

8.- Post condiciones

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.

4.- Actores Actores que intervienen: + Usuario UGEL

5.- Precondiciones

Existencia de Registro de Requerimientos. Logueo en el sistema. El usuario debe ser de tipo UGEL

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”.

7.- Flujos Alternativos

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”.

51  

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.

8.- Post condiciones

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.

4.- Actores Actores que intervienen: + Usuario UGEL

5.- Precondiciones

Existencia de Registro de Requerimientos. Logueo en el sistema. El usuario debe ser de tipo UGEL

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.

7.- Flujos Alternativos

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.

8.- Post condiciones

Ninguna

 

CUS108: Reporte del Padrón de PRONOEI

52  

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.

4.- Actores Actores que intervienen: + Usuario UGEL

5.- Precondiciones

Existencia de Registro de Programas. Logueo en el sistema. El usuario debe ser de tipo UGEL

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.

7.- Flujos Alternativos

No hay flujos alternativos.

8.- Post condiciones

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.

4.- Actores Actores que intervienen: Usuario UGEL

5.- Precondiciones

Existencia de Programas. Logueo en el sistema. El usuario debe ser de tipo UGEL

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.

53  

7.- Flujos Alternativos

Ninguno

8.- Post condiciones

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.

4.- Actores Actores que intervienen: + Usuario UGEL

5.- Precondiciones

Logueo en el sistema. El usuario debe ser de tipo Validador El usuario debe ser de tipo UGEL

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.

7.- Flujos Alternativos

Ninguno

8.- Post condiciones

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.

4.- Actores Actores que intervienen: + Usuario UGEL

5.- Precondiciones

Logueo en el sistema. El usuario debe ser de tipo Validador

54  

El usuario debe ser de tipo UGEL 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.

4. El usuario hace clic en el botón “Enviar Solicitud”. 5. El sistema guarda los datos de la solicitud de modificación de usuarios.

7.- Flujos Alternativos

Ninguno

8.- Post condiciones

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.

4.- Actores Actores que intervienen: + Usuario UGEL

5.- Precondiciones

Logueo en el sistema. El usuario debe ser de tipo Validador El usuario debe ser de tipo UGEL

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.

4. El usuario hace clic en el botón “Enviar Solicitud”. 5. El sistema guarda los datos de la solicitud de inhabilitación de usuarios.

7.- Flujos Alternativos

Ninguno

8.- Post condiciones

Ninguna

55  

CUS113 Ingresar al Sistema

1.- Código CUS113 2.- Nombre Ingresar al Sistema 3.- Objetivo Ingresar o accesar al sistema de usuarios autorizados

4.- Actores Actores que intervienen: + 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.

7.- Flujos Alternativos Ninguno

8.- Post condiciones

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.

4.- Actores Actores que intervienen: + Usuario ADMINISTRADOR

5.- Precondiciones

Existencia de una solicitud de requerimiento previamente solicitada Logueo en el sistema 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.

7.- Flujos Alternativos

Ninguno

56  

8.- Post condiciones

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 escolarizado, basado en un documento que le dé sustento.

4.- Actores Actores que intervienen: + 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. Logueo en el sistema El usuario debe ser de tipo UGEL

6.- Flujo Básico

17. El usuario en el menú “Nueva Solicitud” accede a la opción “Cierre”. 18. El sistema muestra la pantalla de registro de datos. 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). 23. El usuario debe adjuntar el archivo (en formato PDF) que contiene la resolución, este

no debe pesar más de 3 MB. 24. 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 guardarán los datos. 25. El sistema informará al usuario que la solicitud 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 solamente escribiendo el nombre del archivo adjuntado anteriormente.

8.- Post condiciones

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.

4.- Actores Actores que intervienen: + Usuario Administrador

57  

5.- Precondiciones

Logueo en el sistema. El usuario debe ser de tipo Validador 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”.

7.- Flujos Alternativos

Ninguno

8.- Post condiciones

Ninguna

                        

58  

3.7 Diagrama de actividades CUS103: Registrar solicitud de creación de un programa no escolarizado.

Caso de Uso de Sistema

CUS103 Gestionar Creación

Diagrama de Actividad

CUS104: Registrar solicitud de renovación de un programa no escolarizado.

Caso de Uso de Sistema

CUS104 Solicitar Renovación

Diagrama de Actividad

59  

CUS105: Modificación de datos de un programa no escolarizado.

Caso de Uso de Sistema

CUS105 Modificación

Diagrama de Actividad

60  

CUS106: Visualizar solicitudes en proceso.

Caso de Uso de Sistema

CUS106 Visualizar solicitudes en proceso

Diagrama de Actividad

61  

CUS107: Visualizar historial de solicitudes

Caso de Uso de Sistema

CUS107 Visualizar historial en proceso

Diagrama de Actividad

62  

CUS108: Reporte del padrón de PRONOEI.

Caso de Uso de Sistema

CUS108 Reporte del Padrón de PRONOEI

Diagrama de Actividad

 

CUS109: Visualizar control de avance.

Caso de Uso de Sistema

CUS109 Visualizar control de avance

Diagrama de Actividad

CUS110: Crear Solicitud de Nuevo Usuario

Caso de Uso de Sistema

CUS110 Crear usuarios

63  

Diagrama de Actividad

CUS111: Crear Solicitud de Modificación de Usuario

Caso de Uso de Sistema

CUS111 Modificar usuarios

Diagrama de Actividad

64  

CUS112: Crear Solicitud de Inhabilitación de Usuario

Caso de Uso de Sistema

CUS112 Inhabilitar usuarios

Diagrama de Actividad

65  

CUS113: Ingresar al Sistema

Caso de Uso de Sistema

CUS113 Ingresar al Sistema

Diagrama de Actividad

66  

CUS114: Eliminar Solicitud

Caso de Uso de Sistema

CUS114 Eliminar Solicitud

Diagrama de Actividad

67  

CUS115: Registrar eliminación de un PRONOEI CUS116: 

Gestionar coordinadores Caso de Uso de Sistema

CUS115 Eliminar Programa

Diagrama de Actividad

68  

CUS116: Gestionar coordinadores

Caso de Uso de Sistema

CUS116 Gestionar Coordinadores

Diagrama de Actividad

69  

70  

3.8 Diagrama de secuencia

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

 

Figura 21: Diagrama de secuencia: solicitud de creación y renovación Fuente: Elaboración propia

71  

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 Fuente: Elaboración propia

72  

3.9 Diagrama de colaboración

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

 

Figura 23: Diagrama de colaboración: solicitud de creación y renovación Fuente: Elaboración propia

73  

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

 

Figura 24: Diagrama de colaboración: revisión de solicitud de creación y renovación. Fuente: Elaboración propia

74  

3.10 Diagrama de estado

3.10.1 Diagrama de estado: solicitud de creación y renovación

 

 

 

 

 

 

 

 

 

 

 

 

 

Figura 25: Diagrama de estado: solicitud de creación y renovación Fuente: Elaboración propia

75  

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

 

 

 

 

 

 

 

 

 

 

 

 

Figura 26: Diagrama de estado: revisión de solicitud de creación y renovación Fuente: Elaboración propia

76  

3.11 Diagrama de componentes

 

 

 

 

 

 

Figura 27: Diagrama de componentes Fuente: Elaboración propia

77  

3.12 Diagrama de despliegue

 

 

 

 

 

 

 

 

 

 

 

 

 Figura 28: Diagrama de despliegue Fuente: Elaboración propia

78  

3.13 Modelo Entidad Relación 3.13.1 Modelo Conceptual de la BD

Figura 29: Modelo conceptual de la BD Fuente: Elaboración propia

79  

3.13.2 Modelo Lógico de la BD  

 

 

 

 

Figura 30: Modelo lógico de la BD Fuente: Elaboración propia

80  

3.13.3 Modelo Físico de la BD  

 Figura 31: Modelo físico de la BD Fuente: Elaboración propia

81  

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

 

82  

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

83  

 

3.13.4.4 Caso de uso: Renovación de un programa

Nombre Renovación

Descripción

84  

La presente pantalla permitirá renovar un programa.

Pantalla

 

85  

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

86  

 

87  

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

 

88  

 

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

 

89  

 

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

90  

 

 

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

91  

 

 

 

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

92  

 

 

 

3.13.4.13 Caso de uso: Inhabilitar usuarios

Nombre Inhabilitar usuarios

Descripción

La presente pantalla nos permitirá Inhabilitar usuarios.

Pantalla

 

 

 

93  

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

 

94  

 

3.13.4.16 Caso de uso: Gestionar Coordinadores

Nombre Coordinadores

Descripción

La presente pantalla nos permitirá gestionar coordinadores.

Pantalla

95  

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

96  

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:

97  

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 CUADRO DE OBSERVACIONES 2

CALIDAD ÍTEM 2. NOMBRE CUS Registrar solicitud de creación de un

programa no escolarizado TIPO OBSERVACIÓN Fondo OBSERVACIÓN Alerta LOGIN Usuario: 19000123

Clave: RSS1975MSA ROL Usuario: UGEL DESCRIPCIÓN

Según lo indicado en los correos, el

98  

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 Analista Programador 1

3.14.3.3 Acceso al Sistema CUADRO DE OBSERVACIONES 3

99  

CALIDAD ÍTEM 3. NOMBRE CUS Acceso al sistema.

TIPO OBSERVACIÓN Fondo OBSERVACIÓN Alerta LOGIN Usuario: 19000123

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. Analista Programador 1

3.14.3.4 Modificación de datos  CUADRO DE OBSERVACIONES 4 

CALIDAD ÍTEM 4.

100  

NOMBRE CUS Modificación de datos.

TIPO OBSERVACIÓN Fondo OBSERVACIÓN Alerta LOGIN Usuario: 19000123

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. Analista Programador 1

3.14.3.5 Gestión de solicitudes – Solicitudes en proceso CUADRO DE OBSERVACIONES 5

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

101  

proceso.

TIPO OBSERVACIÓN Fondo OBSERVACIÓN Alerta LOGIN Usuario: 19000123

Clave: RSS1975MSA ROL Usuario: UGEL DESCRIPCIÓN No permite registrar observaciones para

la solicitud seleccionada. PANTALLAS

 SOLUCIÓN

102  

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

103  

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: Comparativo de solicitudes de requerimiento Fuente: Elaboración propia

104  

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.

 

 

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.

 

 

 

 

Figura 33: Actualización del padrón de PRONOEI Fuente: Elaboración propia

105  

 

 

 

 

 

 

 

 

 

 

Figura 34: Cronograma de actividades Fuente: Fuente propia

106  

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.

 

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

Fuente: Elaboración propia

Tabla 5 Hitos del proyecto

107  

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

   

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

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). 

 

TIPO DETALLE ESTADO CANTSUB

TOTAL TOTAL

VIDA ÚTIL

PAGO MENSUAL

Equipo Servidor de la aplicación

Existente 1 120,000.00 120,000.00 36 3,333.33

Equipo Servidor de BD Existente 1 120,000.00 120,000.00 36 3,333.33

Licencia Licencias de software

Adquirir - - - - 500.00

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). 

 

DETALLE CANT SUB

TOTAL TOTAL VIDA ÚTIL

PAGO MENSUAL

Equipo móvil 4 1,000.00 4,000.00 36 27.78

Servicio móvil - - - - 400.00

Otros gastos - - - - 500.00

Tabla 7 Recurso tecnológico y costos

Tabla 8 Otros gastos

Nota: Lo montos están expresados en soles (S/.) Fuente: Elaboración propia

Nota: Lo montos están expresados en soles (S/.) Fuente: Elaboración propia

Nota: Lo montos están expresados en soles (S/.) Fuente: Elaboración propia

Tabla 6 Tipo de personal y montos de remuneraciones

108  

 

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.  

 

ROL COD

. CAN

T SUEL

DO

ANÁLISIS Y DISEÑO

DESARROLLO PRUEBAS Y

AJUSTES TOTALES 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 Programador

AP 2 4,500 0% - 200% 9,000 200% 9,000 18,000

Arquitecto de Datos

AD 1 3,200 0% - 100% 3,200 100% 3,200 6,400

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). 

 

COSTOS MESES

TOTAL %

GASTO 1 2 3

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

 

 

Nota: Lo montos están expresados en soles (S/.) Fuente: Elaboración propia

Nota: Lo montos están expresados en soles (S/.) Fuente: Elaboración propia

Tabla 10 Flujo del proyecto en meses

Tabla 9 Cuadro de asignación de recursos

109  

 

 

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/.). 

 

DESCRIPCIÓN FLUJO DE CAJA

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/.).

 

CÁLCULO DEL PRECIO Costo 102,816.67

Margen 18%

Precio 125,386.18

Utilidad 22,569.51

 

 

 ‐

 20,000.00

 40,000.00

 60,000.00

 80,000.00

 100,000.00

 120,000.00

Mes 1 Mes 2 Mes 3

COSTOS

Expresado en Soles (S/.)

Curva S Avance del Proyecto

Curva "S"

Tabla 12 Cálculo del precio

Tabla 11 Flujo de caja

Figura 35: Curva S avance del proyecto Fuente: Elaboración propia

Nota: Lo montos están expresados en soles (S/.) Fuente: Elaboración propia

Nota: Lo montos están expresados en soles (S/.) Fuente: Elaboración propia

110  

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/.). 

 

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/.).

 

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.

 

RENTABILIDAD VAN NETO / VANI 17.89%

Tabla 14 Tasas de descuento

Tabla 15 Rentabilidad

Nota: Lo montos están expresados en soles (S/.) Fuente: Elaboración propia

Fuente: Elaboración propia

Nota: Lo montos están expresados en soles (S/.) Fuente: Elaboración propia

Tabla 13 Formas de pago

111  

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.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

112  

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.

 

 

 

 

 

 

 

113  

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.  

 

114  

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.