PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA ANALISIS, DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE INFORMACIÓN PARA LA GESTIÓN ACADÉMICA DE UN INSTITUTO SUPERIOR TECNOLÓGICO Tesis para optar por el Título de Ingeniero Informático, que presenta el bachiller: Alexander Daniel Norabuena Guevara ASESOR: Johan Paul Baldeón Medrano Lima, Agosto del 2011 II Resumen La gestión de la información académica en los Institutos Superiores Tecnológicos, sean privados o estatales, requieren el uso de mecanismos que aseguren un manejo eficiente y contribuyan a incrementar la calidad de los servicios que se brindan a los alumnos. El presente proyecto plantea la construcción de un software que implemente estas características tan importantes para el desempeño del personal del área de Dirección Académica. El proyecto se desarrolla y divide en cuatro secciones. La primera sección realiza una presentación de los conceptos necesarios para la comprensión del problema, define el plan del proyecto, y muestra algunas soluciones actuales que ofrecen las tecnologías de información. La segunda sección del proyecto presenta el análisis realizado para la elaboración del software. Este análisis presenta los requerimientos identificados del cliente, los costos y beneficios del uso del software, y las herramientas y tecnologías necesarias para la implementación proyecto. La tercera sección expone el diseño del software, explicando las tecnologías utilizadas para la construcción del producto, así como las pruebas realizadas para verificar su correcto funcionamiento. La cuarta sección expone las observaciones, conclusiones y recomendaciones obtenidas durante el desarrollo del proyecto. Finalmente, el proyecto adjunta los anexos referidos a los documentos elaborados en las etapas de análisis y diseño del software. VI A mis padres, Debbies y Daniel, que con su amor, consejos y apoyo incondicional me impulsaron a superar dificultades y así realizarme profesionalmente. A mi esposa, Mary, por su paciencia. A mi hija, Sofía. VII Un agradecimiento especial al Mag. Johan Baldeón Medrano por haberme apoyado directa e indirectamente en la realización de este proyecto. VIII Índice de Contenidos Introducción.......................................................................................................1 1. Generalidades...................................................................................2 1.1. Definición de Problema .....................................................................2 1.2. Marco Conceptual .............................................................................4 1.2.1 Formación de Institutos Superiores Tecnológicos.........................4 1.2.2. Diferencias entre Institutos Superiores Tecnológicos Privados y Públicos ......................................................................................................4 1.2.3. Áreas principales en la organización de un Instituto Superior Tecnológico ................................................................................................5 1.2.4. Relación entre el Ministerio de Educación y los Institutos Superiores Tecnológicos a través del departamento Dirección Académica.6 1.2.5. Problemas que se presentan en el área de Dirección Académica.9 1.3. Plan del Proyecto ............................................................................10 1.4. Estado del Arte ................................................................................14 1.4.1. Sistema de Matrícula, Notas, Actas y Pagos - ISTP Peruano Alemán (IPAL) ..........................................................................................14 1.4.2. Sistema de Matrícula y Control de Pagos - ISTP Federico Villarreal....................................................................................................15 1.4.3. SIGA - Software Integrado de Gestión Académica Web.............16 1.4.4. SOFTAULA..................................................................................17 1.4.5. Cuadro comparativo de programas .............................................18 1.5. Descripción y Sustentación de la solución ......................................20 2. Análisis............................................................................................22 2.1. Metodología aplicada para el desarrollo de la solución...................22 2.1.1. PMBOK........................................................................................23 2.1.2 Rational Unified Process (RUP) .....................................................25 2.2. Identificación de requerimientos......................................................27 2.2.1. Requerimientos Funcionales .......................................................27 2.2.2. Requerimientos No Funcionales .................................................33 2.3 Análisis de la solución. ....................................................................33 2.3.1. Definición del Sistema .................................................................34 2.3.2 Estudio Costo Beneficio ..............................................................38 2.3.3 Definición del Entorno Tecnológico .............................................42 2.3.4. Viabilidad del Proyecto ................................................................43 3. Diseño de la Solución .....................................................................45 3.1. Arquitectura de la Solución..............................................................45 3.1.1. Arquitectura basada en el Framework Struts ..............................46 3.1.2. Arquitectura basada en el Framework Spring .............................48 3.1.3. Arquitectura elegida.....................................................................50 3.2. Diseño de la Solución......................................................................51 Figura 3.4. Ingreso al sistema INSTISOFT. ....................................................52 3.3. Arquitectura de la Información.........................................................57 4. Construcción y Pruebas..................................................................59 4.1. Construcción....................................................................................59 4.1.1. Acceso a Datos utilizando el Framework Hibernate....................60 4.1.2. Aplicación del Framework Spring ................................................61 4.1.3. Diseño de reportes con las herramienta iReport y JasperReports62 4.2. Pruebas ...........................................................................................63 4.2.1. Pruebas unitarias.........................................................................63 5. Observaciones, conclusiones y recomendaciones .........................66 5.1 Observaciones.................................................................................66 5.2 Conclusiones...................................................................................67 IX 5.3 Recomendaciones...........................................................................67 6. Referencias.....................................................................................69 Anexos Anexo A: Documento De Visión Anexo B: Catálogo de Requisitos Anexo C: Especificación de Requisitos de Software Anexo D: Documento de Análisis Anexo E: Documento de Arquitectura Anexo F: Modelo Físico de Base de Datos Anexo G: Plan de Pruebas Unitarias del Sistema X Índice de ilustraciones Figura 1.1 Diagrama WBS del Sistema de Gestión Académica. 12 Figura 2.1. Grupos de Procesos de la Gestión de Proyectos. 23 Figura 2.2 Fases y Disciplinas del RUP. 26 Figura 2.3. Arquitectura general del sistema INSTISOFT. 34 Figura 2.4. Paquetes de los casos de uso del sistema. 36 Figura 2.5. Diagrama de clases de análisis. 38 Figura 3.1 Patrón MVC. 46 Figura 3.2. Una aplicación con Struts. 48 Figura 3.3. Estructura del Framework Spring. 49 Figura 3.4. Spring + Struts + Hibernate. 51 Figura 3.5. Ingreso al sistema INSTISOFT. 52 Figura 3.6. Diseño de Interfaz de INSTISOFT. 53 Figura 3.7. Barra de Menús de un usuario con perfil Docente. 53 Figura 3.8. Barra de Menús de INSTISOFT. 54 Figura 3.9. Formulario de enlaces de operaciones. 54 Figura 3.10. Formulario de registro de datos. 55 Figura 3.11. Formulario de búsqueda de datos. 56 Figura 3.12. Mensaje de éxito de operación. 56 Figura 3.13. Mensaje de error de operación. 57 Figura 3.14. Diagrama físico de base de datos. 58 XI Índice de tablas Tabla 1.1. Diferencias entre un IST Privado y un IST Público 5 Tabla 1.2. Problemas identificados en la Dirección Académica de un IST Privado 9 Tabla 1.3. Distribución de horas por procesos. 13 Tabla 1.4. Cuadro comparativo de las características de diversos sistemas de gestión académica. 18 Tabla 2.1. Procesos del PMBOK que se realizarán en el presente proyecto. 24 Tabla 2.2. Fases del RUP 26 Tabla 2.3. Disciplinas y artefactos del RUP que se desarrollarán en el presente proyecto. 27 Tabla 2.4. Requerimientos Funcionales del Módulo de Configuración. 29 Tabla 2.5. Requerimientos Funcionales del Módulo de Programación Académica. 29 Tabla 2.6. Requerimientos Funcionales del Módulo de Alumnos. 30 Tabla 2.7. Requerimientos Funcionales del Módulo de Consultas y Reportes. 31 Tabla 2.8. Requerimientos Funcionales del Módulo de Seguridad. 31 Tabla 2.9. Nivel de Prioridad. 32 Tabla 2.10. Requerimientos No Funcionales del Sistema INSTISOFT. 33 Tabla 2.11. Costo de capacitación de personal. 40 Tabla 2.12. Cuadro de resumen de Costo-Beneficio para la implementación del proyecto. 41 Tabla 2.13. Herramientas para la construcción del Sistema de Gestión Académica. 42 1 Introducción Los usuarios de los servicios educativos que brindan entidades de nivel superior, como es el caso de los Institutos Tecnológicos, buscan no sólo una buena formación académica sino también una atención de calidad que se refleje en el ahorro de tiempo y la eficiencia de los resultados al realizar trámites académicos. Lo contrario generaría malestar y deserción de estudiantes en busca de mejores alternativas que se ofrecen en un entorno tan competitivo como es el de la educación superior técnica en Lima. Cabe resaltar que los servicios educativos se ofrecen antes, durante y después de los estudios regulares de los alumnos, ya que involucran actividades previas a la matrícula de los estudiantes y posteriores a su finalización de estudios, como es el caso de las certificaciones. El riesgo de brindar una mala atención se incrementa si se realizan estas actividades de forma manual o utilizando herramientas que no garanticen la eficiencia del servicio. Una alternativa de solución para incrementar la calidad del servicio que brindan los Institutos Tecnológicos Superiores a los alumnos es el uso de tecnologías de la información que sirvan de soporte a las actividades realizadas en estas instituciones, asegurando el manejo eficiente de la información y su disponibilidad en el momento oportuno. 2 1. Generalidades A continuación se explican los conceptos básicos que se requieren para entender el problema que se desea resolver a través del desarrollo del presente proyecto de tesis, luego se mostrará el esquema de actividades que se seguirá para el desarrollo del proyecto y finalmente se presentarán alternativas de solución existentes en la actualidad. 1.1. Definición de Problema La creciente demanda, de parte de los egresados de colegios de educación secundaria, por un carrera profesional corta, es decir, de 3 años de duración, ha impulsado la formación de Institutos Tecnológicos Superiores en todo el Perú. Como se indica en [MEE09] tan sólo en Lima existen más 140 Institutos Tecnológicos entre privados y públicos que han sido revalidados por el Ministerio de Educación. Los Institutos Tecnológicos Privados son instituciones que tienen como misión formar profesionales técnicos altamente competitivos que contribuyan al desarrollo nacional. Para ser consecuentes con esta misión, los servicios, tanto académicos como administrativos, que ofrecen a los alumnos, deben ser eficientes y de calidad, pues en caso contrario se corre el riesgo de 3 fracasar como empresa, ya que los alumnos optarán por buscar otra institución que les ofrezcan mejores servicios. Sin embargo, como resultado de las actividades asociadas a los servicios que se ofrecen a los alumnos, que realiza el personal administrativo, y en particular el personal del área de Dirección Académica, se generan problemas como gastos administrativos y de personal no planificados, sanciones administrativas impuestas por La Dirección Regional de Educación de Lima Metropolitana (DRELM), desprestigio del área ante los padres de familia al no contar con el registro actualizado de la asistencia de los alumnos a clase, entre otras. Estos problemas se acentúan cuando los procesos se desarrollan de forma manual o utilizando herramientas de uso genérico como una Hoja de Cálculo y un Procesador de Textos. En su mayoría, estos problemas tienen su origen en el uso de procedimientos manuales para realizar la gestión académica. Esto se puede traducir como la necesidad de implementar procedimientos eficientes que agilicen el proceso de atención a los alumnos e incremente la productividad de los empleados. Este Proyecto de fin de Carrera está orientado a apoyar las actividades del personal del área de Dirección Académica de un Instituto Superior Tecnológico Privado, a través del desarrollo de un software de tipo Sistema de Información, que mediante su uso elimine los problemas mencionados en los párrafos anteriores de esta sección y contribuya de esta manera en agilizar el servicio y atención al alumno, logrando una mejora continua en los actividades realizadas por los empleados del área en mención. 4 1.2. Marco Conceptual En esta sección se explican los conceptos que nos permiten definir el contexto en el que se forman y desarrollan sus actividades los Institutos Tecnológicos Superiores, describiendo el marco de creación y funcionamiento, las diferencias fundamentales que existen entre Institutos Tecnológicos Privados y Públicos, la estructura general de la institución, la forma en que se relaciona con el Ministerio de Educación y los problemas que se originan en las actividades administrativas del área de Dirección Académica. 1.2.1 Formación de Institutos Superiores Tecnológicos Los Institutos Superiores Tecnológicos (IST) se forman bajo el amparo del reglamento descrito en el Decreto Supremo Nº 014-2002 ED, como se muestra en [MDS02], el cual norma la creación, autorización y revalidación de estas instituciones. Los Institutos Superiores Tecnológicos Públicos y Privados, dependen administrativamente de las Direcciones Regionales de Educación y de las Sub Regiones de Educación, tal como se describe en [MED02]. Las Direcciones Regionales de Educación, Sub Regionales de Educación y la Dirección de Educación de Lima y del Callao, son las responsables de aprobar las metas de atención de alumnos que presentan los IST Públicos y Privados, previa evaluación de la capacidad instalada, así como de su equipamiento 1.2.2. Diferencias entre Institutos Superiores Tecnológicos Privados y Públicos Si bien es cierto que el Ministerio de Educación del Perú decreta normas que rigen para todos los institutos superiores tecnológicos, es necesario mencionar que existen algunas diferencias entre los procesos que se realizan 5 en un Instituto Superior Tecnológico Privado y uno Público, tal como se aprecian en la tabla 1.1. IST Privado IST Público Durante el año se programan varios inicios de ciclos, según la demanda de los alumnos. Esto implica que al momento de elaborar los documentos que se presentan a La Dirección Regional de Educación de Lima Metropolitana (DRELM), se tengan que juntar grupos de alumnos del mismo ciclo que no necesariamente iniciaron sus clases en la misma fecha. Sólo se programan dos inicios al año, según lo establecido por el Ministerio de Educación y regulado por su organismo Dirección Regional de Educación de Lima Metropolitana (DRELM). Se ofrecen las especialidades en tres turnos: mañana, tarde y noche. El estado sólo reconoce dos turnos: diurna y nocturna. Tienen una currícula interna distinta a la establecida por el Ministerio de Educación. Por tanto, deben de realizar un cuadro de equivalencias entre su currícula interna y la publicada por el Ministerio de Educación. Los cursos ofrecidos se ajustan a la currícula establecida por el Ministerio de Educación Tabla 1.1. Diferencias entre un IST Privado y un IST Público, en base a [MED02]. 1.2.3. Áreas principales en la organización de un Instituto Superior Tecnológico Las principales áreas que podemos identificar en la organización de un Instituto Tecnológico son: a. Dirección General.- Se encarga de definir los objetivos institucionales y coordinar las diferentes actividades que involucran a las demás áreas de la organización. 6 b. Dirección Administrativa.- Administra los recursos humanos y materiales de la institución, así como su contabilidad. c. Dirección Académica.- Centraliza y maneja la información relacionada a los alumnos, atiende sus requerimientos y procesa los diferentes trámites que estos realizan. Entre los principales servicios que ofrece esta área tenemos:  Registro de Currícula.  Programación de horarios.  Matrículas.  Ratificaciones de matrículas.  Registro de evaluaciones.  Traslados internos y externos.  Certificaciones.  Titulaciones. Para brindar estos servicios, los Institutos Superiores Tecnológicos que recién empiezan a desarrollar sus actividades y aquellos que poseen escasos recursos económicos hacen uso de herramientas comerciales y genéricas que apoyen sus funciones administrativas, como un Procesador de Textos, una Hoja de Cálculo o hasta máquinas de escribir. Sin embargo, estas herramientas resultan insuficientes para poder gestionar con eficiencia toda la información que es requerida y utilizada por el área de Dirección Académica. 1.2.4. Relación entre el Ministerio de Educación y los Institutos Superiores Tecnológicos a través del departamento Dirección Académica. Para definir el alcance de este documento comenzaremos explicando la relación que existe entre el área de Dirección Académica de un Instituto Superior Tecnológico y el Ministerio de Educación a través de la Dirección Regional de Educación de Lima Metropolitana (DRELM). Dos veces al año (cada semestre) el área de Dirección Académica debe presentar a la Dirección Regional de Educación de Lima Metropolitana (DRELM) las Nóminas de Matrículas, que son las listas oficiales que 7 contienen los datos de los alumnos ingresantes y promovidos en los diferentes ciclos de las especialidades o carreras profesionales impartidas en un periodo lectivo. La información que contienen estas nóminas se obtienen a partir de los procesos de matrícula que se llevan a cabo en la institución. Cabe resaltar que para el caso de Institutos Superiores Tecnológicos Privados, el Ministerio de Educación se muestra flexible en cuanto a las fechas de presentación, pues, se pueden establecer de común acuerdo con la institución las fechas en las que se elevarán los documentos requeridos. Además, debemos tener en cuenta que estas presentaciones se realizan dos veces al año, pues es así como lo establece formalmente el Ministerio de Educación en [MED02]. Sin embargo, en los Institutos Superiores Tecnológicos Privados ocurren varios inicios de semestres académicos durante el año, por lo que la información de estas Nóminas de Matrícula es en realidad una recopilación de los datos de todos los alumnos matriculados en todos estos inicios durante un semestre. Aproximadamente unos cuatro meses después de haber presentado las Nóminas de matrículas, tal como se indica en [MED02], el área de Dirección Académica debe presentar a la Dirección Regional de Educación de Lima Metropolitana (DRELM) las Actas de Evaluación Semestral, que son los documentos que consignan las notas finales obtenidas por los alumnos (del primero al sexto ciclo) luego de las evaluaciones respectivas en las diferentes carreras impartidas en un semestre académico. La información de estas notas finales se obtiene de un documento interno que se conoce como Consolidado de Notas, el cual es un registro de todas las notas obtenidas por los alumnos en las diferentes asignaturas cursadas en el semestre académico. Este Consolidado de Notas, a su vez, se elabora en base a la información que figura en los Registros de Notas que los profesores entregan a la Dirección Académica. Se debe mencionar que junto a las Actas de Evaluación Semestral, también se presentan las Actas de Convalidación, que son documentos que oficializan el traslado interno de un alumno de una especialidad a otra, en caso se hayan producido en el semestre académico. Ambos documentos presentados, Nóminas de Matrícula y Actas de Evaluación Semestral, que corresponden a un semestre académico, deben 8 coincidir en cuanto a la cantidad y datos de alumnos matriculados y evaluados en los diferentes ciclos, turnos y especialidades, de lo contrario la institución deberá rehacer estos documentos para volver a presentarlos, generándose un gasto administrativo. Si algunos de estos documentos se entregan en forma extemporánea, la Dirección Regional de Educación de Lima Metropolitana (DRELM) sancionará administrativamente a la institución, tal como se indica en [MED09]. Los problemas expuestos en los dos párrafos anteriores generan el atraso en el cumplimiento de las actividades diarias del personal de la Dirección Académica y de los objetivos propuestos en esta área. Al finalizar un año o al comenzar uno nuevo, la Dirección Regional de Educación de Lima Metropolitana (DRELM) exige presentar tal como se indica en [MED08], la Propuesta de Metas, que es un documento que solicita la autorización de un número determinado de alumnos que la institución justifica que puede albergar para brindar servicios educativos en el nuevo año académico. Sin embargo, este documento no podrá ser presentado si es que la institución no ha cumplido en presentar las Nóminas de Matrícula y las Actas de Evaluación Semestral, como se puede ver en [MED08]. Durante todo el año la Dirección Académica podrá presentar a la Dirección Regional de Educación de Lima Metropolitana (DRELM) los Expedientes de Títulos, que son un conjunto de documentos que incluyen el formato de título para que sea inscrito en el Ministerio de Educación y devuelto a la institución con Resolución Directoral. Así, de esta manera, los alumnos podrán optar por su título profesional, tal como se indica en [MED09]. Entre los documentos adjuntos al expediente se encuentra el Certificado de Notas del alumno, de primero a sexto ciclo. Las notas del alumno descritas en este Certificado son comparadas con las notas registradas en las Actas de evaluación, de encontrarse alguna diferencia, la institución deberá rehacer el expediente. Este último problema no sólo genera gastos administrativos y de personal, sino que expondría a la institución a una demanda judicial, por parte del alumno, por negligencia del personal en el cumplimiento de sus funciones. 9 Cuando las actividades de un área administrativa en una institución son llevadas a cabo de forma manual, existe una mayor probabilidad de cometer errores en el tratamiento de los datos, como omisiones o alteraciones en el contenido. Este problema se acrecienta en el caso de la gestión que realiza la Dirección Académica de un Instituto Superior Tecnológico Privado, debido al manejo de múltiples documentos que utilizan la misma información, pero, presentada en diferentes formatos. Además, por los volúmenes de información que maneja la institución, respecto a los alumnos de las distintas carreras profesionales en diferentes turnos a través de todos los años de operación, se hace más difícil llevar a cabo la búsqueda en el archivo físico de algún dato en particular, generando la perdida de tiempo del personal del área en estudio y el consecuente malestar de los alumnos. 1.2.5. Problemas que se presentan en el área de Dirección Académica. De lo expuesto en los párrafos de la sección anterior, podemos resumir los problemas que se presentan en el área de Dirección Académica, e identificar las causas que los generan, en la tabla 1.2. Problema Causa  Pérdida de horas-hombre, por la ejecución repetida de tareas, como por ejemplo el llenado de datos de los alumnos por cada trámite que estos realizan o la corrección de documentos indebidamente llenados.  Redundancia innecesaria de la información registrada, como sucede al llenar repetidas veces desde diversas fuentes los datos del alumno.  Sanciones administrativas impuestas por la Dirección Regional de Educación de Lima Metropolitana (DRELM) por la entrega extemporánea de  Inconsistencia en los datos transcritos en los diferentes documentos utilizados. 10 Problema Causa documentos, como Nóminas de Matrículas, etc.  Gastos administrativos no planificados o innecesarios, que se incurren en el área al tener que rectificar los errores de digitación en los diferentes documentos emitidos.  Demandas judiciales interpuestas por los alumnos por negligencia del personal administrativo al omitir su registro en una nómina de matriculados.  Inconsistencia en los datos transcritos en los diferentes documentos utilizados.  Pérdida de horas-hombre en la búsqueda manual de datos en el archivo.  Falta de un procedimiento que agilice el proceso de búsqueda de la información registrada.  Disminución en los ingresos por cobro de pensión, al mostrarse reacios los alumnos a efectuar el pago por la demora en la entrega de los carnets de medio pasaje, debido a la entrega extemporánea de nominas oficiales, por parte de la Dirección Académica, a la Dirección Regional de Educación de Lima Metropolitana (DRELM).  Falta de un procedimiento que facilite la actualización de datos documentados.  Perdida de credibilidad de la institución ante los alumnos por el no cumplimiento de la programación de horarios de clase.  Falta de un medio de fácil acceso para que los docentes actualicen su disponibilidad horaria.  Deterioro de la imagen de la  Falta de un adecuado control de 11 Problema Causa institución ante la opinión pública y la Dirección Regional de Educación de Lima Metropolitana (DRELM), al generalizarse y difundirse el mal servicio a los alumnos, cuando estos van a realizar un trámite y no reciben la atención oportuna. las actividades del personal.  Desprestigio del área ante los padres de familia al no contar con el registro actualizado de la asistencia de los alumnos a clase.  Falta de un adecuado procedimiento para tomar la asistencia de los alumnos. Tabla 1.2. Problemas identificados en la Dirección Académica de un IST Privado, en base a [MED02],[MED08],[MED09]. 1.3. Plan del Proyecto El plan del proyecto de implementación del sistema de gestión académica de un Instituto Superior Tecnológico Privado, se distribuye en cuatro procesos principales: la gestión del proyecto, la concepción, la elaboración y la construcción. La gestión del proyecto se realizará durante toda la vida del proyecto, con la finalidad de garantizar el cumplimiento de los objetivos planificados en las fechas establecidas. En el proceso de concepción se determinan las necesidades de los usuarios de la Dirección Académica, que servirán para establecer los requerimientos que implementará el sistema. Luego, se define el plan de proyecto inicial que guiará el trabajo hasta la construcción del sistema. En el proceso de elaboración se realiza el análisis y diseño de la solución generando los documentos ERS (Especificación de Requisitos de Software) y de Arquitectura. Así mismo, se desarrollan los prototipos del software que guiarán la posterior implementación. 12 Durante el proceso de construcción, se utilizarán las herramientas elegidas en el proceso de análisis para la implementación del sistema. Se definirán el plan de pruebas y plan de ejecución, para luego registrar los resultados de los mismos. A continuación, la figura 1.1 muestra la estructura de trabajo del proyecto, expresado a través de un diagrama WBS (Work Breakdown Structure) o Estructura Desglosada del Trabajo. Herramienta para la Gestión Académica de un Instituto Superior Tecnológico Privado Gestión del Proyecto Concepción Elaboración Construcción Formular la definición y el alcance del proyecto. Entregables 1,2 y 3. Elaboración de los requisitos de software - ERS Elaboración de estándares de interfaz gráfica Elaboración de prototipos Elaboración de Documento de Arquitectura Análisis - Elaboración del Diagrama de Clases de Análisis Glosario de terminos Levantamiento de información Elaboración del Documento de Visión Catálogo de Requisitos Planificar y elaborar los casos de uso del negocio. Diagramas de casos de uso. Plan de proyecto inicial Administración de horas y recursos Plan de iteración para cada fase Evaluar la iteración Iniciar el desarrollo – Prototipo de la arquitectura de software Administrar los procesos y recursos de control Diseño – Diagrama de Clases de Diseño Desarrollo del software que se ajuste a la arquitectura Plan de Ejecución. Plan de Pruebas. Figura 1.1: Diagrama WBS del Sistema de Gestión Académica. La descomposición del trabajo se ha realizado tomando en cuenta las fases de desarrollo de la metodología RUP (Rational Unified Process) y la Gestión de Proyectos del PMBOK, de forma que se pueda aplicar una dirección y control integrados a lo largo del desarrollo del software. 13 Se han establecido las actividades del trabajo de manera que generen algún producto, que permita facilitar su control y evaluación. El proyecto tendrá una duración estimada de 816 horas que abarcarán un periodo aproximado de 6 meses. Estas horas estarán divididas de la siguiente manera: 223 horas para la gestión del proyecto, algunas de sus actividades se realizarán de principio a fin, 68 horas para la concepción, 290 horas para la elaboración y 371 horas para la construcción. La distribución de horas por procesos se realizará según se muestra en la tabla 1.3. Procesos Horas Gestión del Proyecto Entrevistas con el asesor de tesis para definir el proyecto a desarrollar. 4 Elaborar Entregable 1. Desarrollar el enunciado del alcance preliminar del proyecto 12 Elaborar Entregable 2. Elaboración del Diagrama de Gantt y WBS. 17 Elaborar Entregable 3. Definición del alcance. 20 Verificación del alcance. Control del alcance 25 Control del cronograma 25 Control de calidad 40 Total de horas por proceso 143 Concepción Levantamiento de Información, entrevistas con personal del área de Dirección Académica. 15 Definición de requerimientos para los módulos del sistema 15 Generación del Catalogo de requisitos 15 Generación del Documento visión y Casos de uso del negocio. Diagramas de casos de uso. 15 Generación del Plan de proyecto inicial. 8 Total de horas por proceso 68 Elaboración Elaboración del glosario de términos de los departamentos de la Dirección Académica. 10 Especificación de requisitos de software para los módulos del sistema 50 Diagrama de Actividades, Diagrama de casos de Uso. Diagrama de clases de Análisis. 25 14 Procesos Horas Elaboración del estándar de interfaz grafica. 10 Elaboración de prototipos de Interfaz de Usuario para los módulos. 35 Elaboración del estándares de programación 10 Elaboración del documento de Arquitectura 20 Elaboración de prototipos de Arquitectura para los mantenimientos( uno por modulo) 25 Refinar la visión del proyecto y casos de uso 20 Documento de estimación del proyecto 30 Total de horas por proceso 235 Construcción Registro de Asignación de actividades de desarrollo del software (horas) 25 Elaboración del Diagrama de Clases de Diseño. 25 Programación de los módulos del sistema 300 Pruebas del software 20 Total de horas por proceso 370 Tabla 1.3. Distribución de horas por procesos. 1.4. Estado del Arte Debido que no existe una herramienta de software comercial destinada a atender todas las necesidades de gestión académica de los Institutos Superiores Tecnológicos Privados del Perú, vale decir, un software que implemente las reglas definidas por el Ministerio de Educación y se adapte a la forma de trabajo propia de estas instituciones en nuestro país, a continuación se describirán dos herramientas hechas a medida para instituciones educativas de nivel tecnológico superior de nuestra capital y dos herramientas ofrecidas en el Internet, que se utilizan para la gestión académica. 1.4.1. Sistema de Matrícula, Notas, Actas y Pagos - ISTP Peruano Alemán (IPAL) Desarrollado entre el 2007 y 2008 para atender las principales necesidades del ISTP Peruano Alemán en las áreas de Dirección Académica y Caja. Este programa permite generar documentos oficiales, cómo Nominas de Alumnos, 15 Actas de Evaluación Semestral y de Recuperación, con el formato adecuado, y que son requeridos por el Ministerio de Educación. A continuación se describen sus principales características según se indica en [MAN07]. Características:  Facilita la navegación entre ventanas a los usuarios.  Registra alumnos, generando un código por cada especialidad en la que se matricule.  Permite agrupar lógicamente diferentes aulas.  Registra Consolidado de Notas.  Ingresar las subsanaciones por exámenes de recuperación.  Genera reportes de Nóminas de Alumnos, Actas de Evaluación Semestral y de Recuperación, Boleta de Notas y Record de Pagos.  Consultas económicas, académicas y de datos personales.  Genera record de asistencia.  Registra pagos por matrícula, ratificación de matrícula, pensión y otros pagos relacionados con actividades académicas.  Genera reporte de alumnos morosos.  Genera Balance Económico.  Migra reportes hacia Excel.  Arquitectura Cliente/Servidor. Trabaja en red local LAN. 1.4.2. Sistema de Matrícula y Control de Pagos - ISTP Federico Villarreal Orientado principalmente a atender el proceso de matrícula y pagos que realizan los alumnos. Permite atender las necesidades de matrícula de alumnos y control de pagos básicas de esta institución a través de dos subsistemas diseñados para estos fines. Genera Nóminas de Alumnos Matriculados, con el formato solicitados por el Ministerio de Educación. Sus principales características tal como se indican en [MAN05] son: Características:  Fácil de utilizar, orientado a ventanas. 16  Registra alumnos.  Registra información de matrículas.  Registra especialidades y asignaturas.  Registra docentes.  Genera Nóminas de Alumnos matriculados.  Genera reporte de pagos de alumnos.  Registra pagos por matrícula, pensión y venta de artículos.  Arquitectura Cliente/Servidor. Trabaja en red LAN. 1.4.3. SIGA - Software Integrado de Gestión Académica Web Es un sistema modular para la administración académica y curricular, diseñado especialmente para instituciones de educación superior funciona completamente en Internet, que integra tanto datos como procesos en una solución completa eliminando barreras de espacio y tiempo. SIGA cumple a cabalidad con las características necesarias que garantizan la calidad del mismo, ellas son: funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad; todo esto permite la integración con futuros desarrollos de manera económica y de alta calidad, tal como se indica en [SIGA07]. Como SIGA es un producto diseñado para interactuar a través del Internet, permite compartir información de manera eficiente y segura entre dependencias, evitando los problemas de inconsistencia originados por la redundancia de información. Las interfaces para los usuarios son amigables y tienen uniformidad en su presentación induciéndole a navegar por el sistema, al autoaprendizaje, facilitando a los mismos enfrentarse a las nuevas tecnologías de la informática con ánimo y confianza. El sistema SIGA esta compuesto de subsistemas que permite la operación de los diferentes procesos académicos, como son matrículas, evaluaciones, trámites y mantenimientos. Estos subsistemas a su vez se dividen en módulos específicos para cada actividad. La organización tiene la opción, de acuerdo a sus necesidades, de elegir los subsistemas, facilitando adquirir la aplicación completa o los módulos o subsistemas de acuerdo a sus necesidades particulares. 17 1.4.4. SOFTAULA SoftAula es una suite de productos para gestión de centros de educación superior que se presenta en 4 modalidades: Lite, Basic, Profesional y Enterprise. Las características más importantes, relacionadas a la gestión académica, que ofrecen las presentaciones Profesional y Enterprise son las que se indican en [SFA11] y se describen a continuación:  Gestión de alumnos, direcciones y relaciones familiares.  Creación de grupos de alumnos.  Gestión de aulas y espacios.  Definición de cursos y agrupación de materias.  Gestión de profesores (datos personales y profesionales, condiciones económicas, disponibilidad horaria, etc.  Adición de reservas no previstas.  Gestión de estados de reservas (asistente, no presentado, anulado).  Búsqueda y asignación de espacios disponibles (aulas).  Búsqueda y asignación de recursos disponibles.  Gestión y resolución de conflictos entre espacios y profesores para determinados días y horas.  Gestión de estados de reservas (asistente, no presentado, anulado).  Adición de reservas no previstas.  Control de asistencias por profesor.  Gestión de exámenes y pruebas de control, medias y estadísticas por grupo.  Gestión de Incidencias por alumno.  Envío de notificaciones individuales o por grupo (impresión, correo electrónico, SMS, etc.).  Asistentes para la localización de grupos disponibles, creación de reservas, cambio de grupo, nivel, etc.  Prórrogas de estudios.  Creación automática de grupos con asignación automática de profesores y aulas en función de disponibilidades y otros criterios de filtrado. 18  Edición de Plantillas Estándar (matrículas, certificados, actas, carnet, diploma, asistencias, calificaciones, etc.).  Creación de plantillas personalizadas para listados. 1.4.5. Cuadro comparativo de programas A continuación se muestra en la tabla 1.4, un cuadro comparativo de las funciones y características ofrecidas por los programas descritos en las subsecciones anteriores de esta sección, así como también se muestran las funciones que realizará la propuesta de software del presente proyecto. Función SGAPA SGAFV SIGA SOFTA Propuesta Del Proyecto Gestión de grupos de alumnos o inicios académicos. Si Si Si Si Si Gestión de alumnos. Si Si Si Si Si Gestión de docentes. Si Si Si Si Si Gestión de aulas, laboratorios y talleres. Si No Si Si Si Permite agrupar lógicamente diferentes aulas. Si No No No Si Gestión de notas y evaluaciones. Sólo registro Si Si Si Si Genera reportes de Nóminas de Alumnos y Actas de Evaluación Semestral con los formatos del Ministerio de Educación del Perú. Si Sólo Nóminas No No Si Genera reportes de Record académico y de pagos. Si Si Si Si Si Genera record de asistencia de alumnos. Si No Si Si No 19 Función SGAPA SGAFV SIGA SOFTA Propuesta Del Proyecto Gestión de asignaturas y especialidades. Si No Si Si Si Gestión de contenidos temáticos por asignatura. No No Si Si No Gestión de asignaturas equivalentes del Ministerio de Educación del Perú. No No No No Si Gestión de carga horaria de docentes. No No No Si Si Gestión de horarios de clases. No No Si Si Si Consultas económicas, académicas y de datos personales. Si Si Si Si Si Gestión de pagos por matrícula, ratificación de matrícula, pensión y otros pagos relacionados con actividades académicas. Si Si Si Si No Genera reporte de alumnos morosos. Si Si Si Si No Permite enviar correos electrónicos a docentes y alumnos. No No Si Si Si Permite migrar reportes hacia Excel o Word. Sólo Excel No Si Si Si Trabaja sobre la plataforma de Internet. No No Si Si Si Tabla 1.4. Cuadro comparativo de las características de diversos sistemas de gestión académica, en base a [MAN07], [MAN05], [SIGA07] y [SFA11]. Donde:  SGAPA, es el Sistema de Matrícula, Notas, Actas y Pagos - ISTP Peruano Alemán (IPAL). 20  SGAFV, es el Sistema de Matrícula y Control de Pagos - ISTP Federico Villarreal.  SIGA, es el Software Integrado de Gestión Académica Web  SOFTA, es la presentación profesional de SoftAula. 1.5. Descripción y Sustentación de la solución El presente proyecto busca implementar un sistema de información que apoye la gestión académica de un Instituto Superior Tecnológico Privado. Este sistema de gestión académica estará conformado por 5 módulos. El primer módulo se encargará de la configuración de la información básica del sistema como son especialidades, asignaturas, docentes, aulas y laboratorios. El segundo módulo se encargará de la programación académica, el cual permitirá administrar la información relacionada a un inicio académico como son la creación de grupos de inicio, la programación de horarios y asignación de aulas y laboratorios, así como la equivalencia entre las asignaturas impartidas por el Instituto y las establecidas por el Ministerio de Educación como oficiales, por nivel y especialidad. El tercer módulo se encargará de administrar la información relacionada a los alumnos como las matrículas, considerando traslados internos (entre especialidades) y externos (desde otros Institutos), las evaluaciones, permitiendo que los docentes puedan registrar directamente las notas finales. Así mismo, este módulo permitirá el registro y monitoreo de los diferentes trámites que los alumnos realizan en el área de Dirección Académica como solicitudes de certificaciones y titulaciones, permitiendo enviar comunicados por email al alumno. El cuarto módulo permitirá realizar consultas al sistema como alumnos por grupos, carga horaria de docente, horario académico por grupo y asignaturas por especialidad. También se podrán generar reportes como Nóminas semestrales de alumnos matriculados y Actas de Evaluación Semestral. 21 Finalmente el quinto módulo se encargará de la seguridad del sistema permitiendo administrar la información de los usuarios y de sus actividades realizadas en el sistema. La implementación de los módulos mencionados ayudará en mejorar la eficiencia de los procesos realizados en el área de Dirección Académica de los Institutos Superiores Tecnológicos, evitando ingresar repetidas veces la misma información e incurrir en errores de falta de coherencia de los datos que se ingresan en diferentes documentos, como las nóminas de matrícula y Actas de Evaluación Semestral. Así mismo se verificará la validez de la información registrada como en el caso de programación de horarios. Además, el personal de esta área ahorrará tiempo al no realizar algunas tareas, como el ingreso de notas finales por asignatura, necesarias para elaborar las Actas de Evaluación Semestral, reingreso de datos almacenados o búsqueda de información en archivos físicos. 22 2. Análisis En este capítulo se presenta el estudio de la solución propuesta en el proyecto, para lo cual se explicará la metodología de desarrollo y gestión a utilizar en la elaboración del sistema, luego se identificarán los requerimientos de usuarios para crear la solución del problema y finalmente, se realizará el análisis de la solución, el que comprende un estudio costo – beneficio, la determinación del alcance del sistema, la identificación del entorno tecnológico, el establecimiento de las funciones principales del software, la definición de las interfaces de usuario y la especificación del plan de pruebas. 2.1. Metodología aplicada para el desarrollo de la solución La metodología de desarrollo de software que se utilizará en este proyecto será RUP (Rational Unified Process), pues asegura el desarrollo de un software de calidad dentro de los plazos y presupuestos predecibles, tal como se describe en [IBM98]. Así mismo, para la gestión del Proyecto se empleará la GUIA PMBOK de PMI (Project Management Institute), debido a que es un estándar que contiene prácticas aplicables a la gestión de proyectos que son ampliamente reconocidas por su valor y utilidad, tal como se indica en [IEEE04]. 23 2.1.1. PMBOK El PMBOK (Project Management Body of Knowledge) es una colección de procesos y áreas de conocimiento generalmente aceptadas como las mejores prácticas dentro de la gestión de proyectos. Según [IEEE04] el PMBOK es un estándar reconocido internacionalmente que provee los fundamentos de la gestión de proyectos que son aplicables a un amplio rango de proyectos, incluyendo software, ingeniería, etc. PMBOK reconoce 5 procesos básicos y 9 áreas de conocimiento comunes a casi todos los proyectos. Los cinco grupos de procesos básicos son:  Inicio.  Planificación.  Ejecución.  Control y Monitoreo.  Cierre. Figura 2.1. Grupos de Procesos de la Gestión de Proyectos, tomada de Project Experts en [PEX09]. 24 Los procesos se superponen e interactúan a través de un proyecto o fase. Los procesos son descritos en términos de: Entradas (documentos, planes, diseños, etc.), Herramientas y Técnicas (mecanismos aplicados a las entradas) y Salidas (documentos, productos, etc.). Las nueve áreas del conocimiento mencionadas en el PMBOK son:  Gestión de la Integración de Proyectos,  Gestión del Alcance en Proyectos,  Gestión del Tiempo en Proyectos,  Gestión de la Calidad en Proyectos,  Gestión de Costos en Proyectos,  Gestión del Riesgo en Proyectos,  Gestión de Recursos Humanos en Proyectos,  Gestión de la Comunicación en Proyectos, y  Gestión de la Logística en Proyectos. En el desarrollo del presente proyecto se aplicarán las prácticas del PMBOK, expuestas en su tercera versión, en los procesos y áreas del conocimiento descritos en la tabla 2.1. Proceso PMBOK Subprocesos Área de conocimiento Iniciación Desarrollar el enunciado del alcance preliminar del proyecto. Integración Definición del alcance. Alcance Crear WBS. Alcance Definición de actividades. Tiempo Desarrollo del cronograma. Diagrama de Gantt. Tiempo Estimación de costos. Costo Planificación Planificación de la calidad. Calidad Ejecución Realizar el aseguramiento de la calidad. Calidad Control Verificación del alcance. Alcance 25 Proceso PMBOK Subprocesos Área de conocimiento Control del alcance. Alcance Control del cronograma. Tiempo Control de costos. Costo Realizar el control de calidad. Calidad Cierre Cerrar el proyecto. Integración Tabla 2.1. Procesos del PMBOK que se realizarán en el presente proyecto. 2.1.2 Rational Unified Process (RUP) RUP es una metodología que define claramente quien, cómo, cuándo y qué debe hacerse, tal como se indica en [IBM98]; su enfoque esta basado en modelos que utilizan un lenguaje simbólico bien definido para tal fin, el UML (Unified Modeling Language o Lenguaje de Modelamiento Unificado). Esta metodología aporta herramientas como los casos de uso, que definen los requerimientos de los usuarios del sistema. Permite la ejecución iterativa del proyecto y del control de riesgos. Las características principales de esta metodología son:  Guiado por los Casos de Uso  Centrado en la Arquitectura  Guiado por los Riesgos  Iterativo A través de un proyecto guiado por RUP, los requerimientos funcionales son expresados en la forma de Casos de Uso, que guían la realización de una arquitectura ejecutable de la aplicación. Además, el proceso focaliza el esfuerzo del equipo en construir los elementos críticos estructuralmente y del comportamiento antes de construir elementos menos importantes. La mitigación de los riesgos más importantes guía la definición y confirmación del alcance en las primeras etapas del ciclo de vida. Debido a que RUP divide el ciclo de vida en iteraciones, nos permitirá evaluar el avance del desarrollo del software del presente proyecto, en base a las versiones refinadas de los ejecutables de la aplicación que se producirán. 26 La metodología RUP, llamada así por sus siglas en inglés Rational Unified Process, divide en 4 fases el desarrollo del software. Cada Fase tiene definido un conjunto de objetivos y un punto de control especifico, tal como se describe en la tabla 2.2. Tabla 2.2. Fases del RUP, tomada de Metodología de Desarrollo de Software (MDS), en [IBM98] Como se muestra en la figura 2.2, RUP considera un conjunto de disciplinas que guían el desarrollo del software en sus diferentes fases. Estas disciplinas de desarrollo son las siguientes:  Modelado de Negocios: Entendiendo las necesidades del negocio.  Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado.  Análisis y Diseño: Trasladando los requerimientos dentro de la arquitectura de software.  Implementación: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado.  Pruebas: Asegurándose que el comportamiento requerido es el correcto y que todo los solicitado esta presente. Fase Objetivos Puntos de Control Concepción  Definir el alcance del proyecto  Entender que se va a construir Objetivo del proyecto. Elaboración  Construir una versión ejecutable de la arquitectura de la aplicación  Entender cómo se va a construir Arquitectura de la aplicación. Construcción  Completar el esqueleto de la Aplicación con la funcionalidad  Construir una versión Beta Versión Operativa Inicial de la Aplicación Transición  Construir la versión Final Aplicación final. 27  Configuración y administración del cambio: Guardando todas las versiones del proyecto.  Administrando el proyecto: Administrando horarios y recursos.  Ambiente: Administrando el ambiente de desarrollo.  Distribución: Distribuir físicamente el producto del proyecto. Figura 2.2 Fases y Disciplinas del RUP, tomada de Metodología de Desarrollo de Software (MDS) en [RNX08]. La gestión del proyecto descrito en este documento se realizará con algunos procesos de PMBOK como ya se explico en la sección 2.2.1. Se debe tener en cuenta que como este proyecto busca generar una herramienta de uso genérico para la gestión académica de un Instituto Superior Tecnológico Privado, no se realizará la instalación ni el monitoreo en el usuario final, por tanto no se utilizará la fase de Transición, sin embargo, para el desarrollo de las otras fases se utilizarán las disciplinas y artefactos de RUP descritas en la tabla 2.3. Disciplina Artefacto Modelado de negocios Definición del alcance del proyecto. Requerimientos Catálogo de Requisitos Análisis y diseño ERS (Especificación de Casos de Uso). Documento de Visión. 28 Disciplina Artefacto Documento de Análisis (Diagrama de Clases de análisis). Documento de Arquitectura (Tecnologías y estructuras de componentes). Prototipos (Diseño de interfaces). Análisis y diseño Documento de Diseño (Diagrama de clases de diseño, modelo de bases de datos). Plan de Pruebas (Pruebas unitarias). Implementación Plan de Ejecución. Versión Beta. Pruebas Ejecución de pruebas. Tabla 2.3. Disciplinas y artefactos del RUP que se desarrollarán en el presente proyecto. 2.2. Identificación de requerimientos En base a la información oficial del Ministerio de Educación presentada en [MED02], [MED08] y [MED09], así como a entrevistas realizadas con personal del área de la Dirección Académica de 3 Institutos Superiores Tecnológicos Privados (ISTP) de nuestra capital: ISTP Peruano Alemán, ISTP Federico Villarreal e ISTP Paul Müller se han logrado determinar los requerimientos para la implementación del software de Gestión Académica del presente proyecto. Los requerimientos en detalle se encuentran en el Catálogo de Requisitos del anexo B de este documento. En adelante nombraremos al Sistema para la Gestión Académica de un Instituto Superior Tecnológico Privado como INSTISOFT. 2.2.1. Requerimientos Funcionales El sistema INSTISOFT permitirá realizar lo que se describe en las tablas 2.4, 2.5, 2.6, 2.7 y 2.8. Los valores de la columna de prioridad se han tomado de la tabla 2.9. El detalle de esta información se encuentra en el Anexo B – Catálogo de Requisitos. 29 Módulo de Configuración No. Descripción Prioridad 1 El sistema permitirá mantener la información de las especialidades o carreras profesionales. 3 2 El sistema permitirá mantener la información de asignaturas impartidas por el Instituto en una especialidad y nivel determinado. 3 3 El sistema permitirá mantener la información de asignaturas consideradas oficiales por el Ministerio de Educación en una especialidad y ciclo determinado. 3 4 El sistema permitirá mantener la información de aulas tales como el piso o ubicación y la capacidad. 3 5 El sistema permitirá mantener la información de laboratorios tales como el piso o ubicación y la capacidad. 3 6 El sistema permitirá mantener la información de docentes. 3 Tabla 2.4. Requerimientos Funcionales del Módulo de Configuración. Módulo de Programación Académica No. Descripción Prioridad 1 El sistema permitirá mantener grupos de alumnos relacionados a inicios académicos. 1 2 El sistema permitirá mantener un horario de clases asociado a un grupo o inicio académico. 1 3 El sistema permitirá mantener la disponibilidad horaria de un docente. 2 4 El sistema permitirá registrar y eliminar las equivalencias entre las asignaturas impartidas 2 30 Módulo de Programación Académica No. Descripción Prioridad por el Instituto y las consideradas oficiales por el Ministerio de Educación. Tabla 2.5. Requerimientos Funcionales del Módulo de Programación Académica. Tabla 2.6. Requerimientos Funcionales del Módulo de Alumnos. Módulo de Alumnos No. Descripción Prioridad 1 El Sistema permitirá mantener la información de los alumnos. 1 2 El Sistema permitirá buscar un alumno por su código o apellidos 1 3 El sistema permitirá registrar y modificar la matricula de alumnos nuevos. 1 4 El sistema permitirá revalidar la matrícula de alumnos antiguos. 1 5 El sistema permitirá registrar traslados de alumnos de una especialidad a otra. 1 6 El sistema permitirá registrar traslados de alumnos de otros institutos. 1 7 El sistema permitirá registrar y modificar los resultados obtenidos por los alumnos en las evaluaciones de sus asignaturas. 1 8 El sistema permitirá registrar y modificar el estado de los trámites realizados por alumnos ante el área de Dirección Académica. 2 9 El sistema permitirá enviar comunicados a través de correos electrónicos a los alumnos. 1 31 Módulo de Consultas y Reportes No. Descripción Prioridad 1 El sistema permitirá al alumno consultar sus notas. 2 2 El sistema permitirá al alumno consultar el estado de los trámites que haya realizado. 2 3 El sistema permitirá consultar el horario académico asignado a un grupo. 2 4 El sistema permitirá consultar la carga horaria de un docente. 2 5 El sistema permitirá consultar las asignaturas asignadas a una especialidad por ciclos. 2 6 El sistema permitirá generar un reporte de alumnos matriculados en un grupo o inicio académico. 2 7 El sistema permitirá generar un reporte de Nómina de alumnos matriculados en un semestre. 1 8 El sistema permitirá generar un reporte de Acta de Evaluación Semestral 1 Tabla 2.7. Requerimientos Funcionales del Módulo de Consultas y Reportes. Módulo de Seguridad No. Descripción Prioridad 1 El sistema permitirá ingresar a los usuarios previa identificación de su nombre y contraseñas asignadas. 1 2 El sistema permitirá mantener a los usuarios del área de Dirección Académica 1 3 El sistema permitirá consultar las actividades de los usuarios en el sistema en un periodo de tiempo determinado. 2 4 El sistema permitirá modificar la contraseña a los 2 32 Módulo de Seguridad No. Descripción Prioridad usuarios. Tabla 2.8. Requerimientos Funcionales del Módulo de Seguridad. Prioridad Valor Descripción 1 Alta 2 Media 3 Baja Tabla 2.9. Nivel de Prioridad. La implementación de estos requerimientos funcionales en el sistema INSTISOFT ofrece la oportunidad a los usuarios, en la medida que los utilicen, de disminuir el desperdicio de horas-hombre al tener que realizar la búsqueda manual de datos y la comparación o cruce de información contenida en diferentes documentos con la finalidad de detectar inconsistencia de datos al cometer errores de transcripción. Así mismo, al disponer de la información registrada y accesible bajo los formatos establecidos por el Ministerio de Educación permitirá generar en forma oportuna estos documentos evitando recibir sanciones administrativas por la Dirección Regional de Educación de Lima Metropolitana (DRELM) por realizar una entrega extemporánea. Además, al disponer los docentes de un medio para registrar directamente las notas finales de los alumnos bajo su cargo, así como actualizar su disponibilidad horaria se disminuirá la carga de trabajo de los empleados de Dirección Académica. Así mismo, permitirá controlar las actividades realizadas por el personal generando un reporte de auditoría. 33 2.2.2. Requerimientos No Funcionales El sistema INSTISOFT implementará los requerimientos no funcionales mostrados en la tabla 2.10. Nº Descripción Prioridad 1 Será independiente del sistema operativo. 1 2 Será desarrollado con el lenguaje de programación java. 1 3 Utilizará como base de datos a PostgreSQL. 1 4 Trabajará sobre la plataforma Web. 1 5 Permitirá realizar backups periódicos de la base de datos. 2 6 El software se entregará con el código fuente adjunto. 2 Tabla 2.10. Requerimientos No Funcionales del Sistema INSTISOFT. La implementación de estos requerimientos no funcionales en el sistema INSTISOFT le permitirá trabajar en un red interna a una organización (Intranet) o en un servidor web público de Internet facilitando su acceso y uso a través de un navegador web, como Internet Explorer 7.0 en adelante o Mozilla Firefox desde la versión 3.0 a más. Sin embargo, se recomiendan algunas medidas de seguridad para su implementación en un servidor web, tales como el uso de un servidor Firewall, que permita implementar a la institución políticas de acceso a la red interna. Así mismo, es recomendable utilizar un protocolo de comunicación segura como HTTPS (protocolo de transferencia segura de hipertexto) que mediante un certificado digital autorice a un usuario iniciar una sesión en la aplicación del servidor. 2.3 Análisis de la solución. A continuación se realiza el análisis de la solución planteada para el sistema, para lo cual se presentará un estudio técnico de las herramientas y equipos que se utilizarán en la implementación del software y estudio de costo- beneficio que permitirá establecer la viabilidad del proyecto expuesto en este documento. 34 2.3.1. Definición del Sistema El Sistema de Gestión Académica para Institutos Superiores Tecnológicos Privados será desarrollado en la plataforma Web, tal como se muestra en la figura 2.3, lo que permitirá mantener la información y funciones accesibles a los usuarios, según sus privilegios, a través de un programa navegador web. Esta característica agilizará las actividades de los empleados del área y disminuirá su carga de trabajo al derivar algunas de las actividades que realizan actualmente hacia otras personas, por ejemplo, el llenado de notas finales de los alumnos por asignaturas lo realizarán los docentes. Figura 2.3. Arquitectura general del sistema INSTISOFT. Según las necesidades de los usuarios identificadas en el Documento de Visión del anexo A, la implementación de este sistema se realizará en los siguientes módulos:  Módulo de Configuración, permitirá administrar la información de especialidades, asignaturas, aulas y laboratorios, así como de docentes. Este módulo será utilizado por el Administrador Académico.  Módulo de Programación Académica, el cual permitirá administrar la información relacionada a un inicio académico tales como la creación de grupos de inicio, la programación de horarios y asignación de aulas y laboratorios, así como la equivalencia entre las asignaturas impartidas por el Instituto y las establecidas como oficiales por el Ministerio de Educación, por nivel y carrera profesional. Se debe considerar que el PC Cliente Servidor del Instituto. Base de datos INSTISOFT Servidor de aplicación INSTISOFT Red 35 sistema validará los datos ingresados evitando la inconsistencia de la información, como por ejemplo al registrar horarios de clases. Este módulo será utilizado por el Administrador Académico en todas sus funciones, por el docente para la actualización de su disponibilidad horaria y por el empleado del área de Dirección Académica para realizar todo tipo de consultas definidas en el módulo.  Módulo de Alumnos, se encargará de gestionar la matrícula de alumnos nuevos y las revalidaciones de matrícula, considerando traslados internos o cambios de especialidad y traslados externos desde otros institutos. También se podrán administrar las evaluaciones de los alumnos, permitiendo que los docentes puedan registrar directamente las notas finales. Se debe notar que a partir de estas notas registradas se generarán las Actas de Evaluación Semestral que son remitidas al Ministerio de Educación para su visación. Así mismo, este módulo permitirá administrar la información de solicitudes y entrega de certificados y títulos, registrando las solicitudes de los alumnos, controlando el estado de tramitación de estos documentos y permitiendo comunicar a los alumnos por mail en el momento que su titulo o certificado gestionado se encuentre disponible, adicionalmente se facilitarán las consultas en línea del personal y de los alumnos. Este módulo será utilizado por el empleado del área de Dirección Académica para registrar las matrículas de alumnos, trámites y realizar todo tipo de consultas definidas en el módulo, por el Administrador Académico para realizar todo tipo de consultas y por el docente para el registro y modificación de notas.  Módulo de Consultas y Reportes, permitirá realizar consultas como alumnos por grupos, carga horaria de docente, horario académico por grupo y asignaturas por especialidad. También se podrán generar reportes como Nóminas semestrales de alumnos matriculados y Actas de Evaluación Semestral. Este módulo será utilizado por el Administrador Académico y el empleado del área de Dirección Académica para realizar todo tipo de consultas y generación de reportes, así como también por los alumnos para consultar sus notas o algún trámite de certificado o título que hayan realizado. 36  Módulo de Seguridad, permitirá administrar la seguridad del sistema a través del mantenimiento y control de usuarios según los privilegios del perfil que se les haya asignado. Así mismo se podrá realizar un seguimiento de las actividades que hayan realizado los usuarios en el sistema durante un periodo determinado. Este módulo será utilizado por el Administrador de Seguridad. La figura 2.4 muestra los módulos del sistema organizados en paquetes que se detallan en el anexo C, Especificación de Requisitos de Software, los que se utilizarán para organizar los casos de uso. Un caso de uso representa una función del sistema. Figura 2.4. Paquetes de los casos de uso del sistema. Los casos de uso por paquete son los siguientes: a) Configuración:  Mantener especialidad.  Mantener asignaturas por especialidad. 37  Mantener área de estudio.  Mantener docente. b) Programación Académica  Buscar Grupo.  Mantener grupo.  Registrar horario por grupo.  Mantener equivalencias entre asignaturas. c) Alumnos  Mantener evaluaciones.  Buscar alumno.  Mantener alumno.  Mantener matrícula.  Registrar traslado.  Mantener trámites.  Enviar email. d) Consultas y Reportes:  Consultar notas.  Consultar trámites.  Consultar carga horaria de docente.  Consultar horario académico por grupo.  Consultar asignaturas por especialidad.  Generar nómina de matrícula.  Generar acta de evaluación semestral. e) Seguridad:  Iniciar sesión.  Modificar contraseña.  Mantener usuario de Gestión Académica.  Consultar Log de usuario. La especificación de cada caso de uso se encuentra en el apéndice C. 38 Así mismo, como parte del análisis de la solución, se ha elaborado un diagrama de las clases que representan a los diferentes objetos que se han considerado relevantes para este sistema, debido a la información que contienen. Este diagrama se muestra en la figura 2.5. Docente -codDocente -nombres -paterno -materno -domicilio -email -web -telefono -celular -estado Grupo -codGrupo -codigo -fechaFin -fechaInicio -turno -nivel -periodoMinisterio -estado HorarioXGrupo -codHorarioXGrupo -horainicio -horafin -dia * 1 * 1 AsignaturaInstituto -codAsignaturaInstituto -nombre -abreviacion -estado Alumno -codAlumno -codigo -nombres -paterno -materno -telefonofijo -dni -fechanacimiento -celular -email -web -domicilio -estado Matricula -codMatricula -fechaRegistro -fechamodificacion -codigo -reciboPago -condicion -edad -ennomina -situacion -estado Nomina -codNomina -codigo -cara -codPeriodoMinisterio -codNivel -codTurnoMinisterio -codEspecialidad MatriculadosXNomina -codMatriculadosXNomina * 1 * 1 Especialidad -codEspecialidad -nombre -clave -estado *1 * 1 NotaXAsignatura -codNotaXAsignatura -promunidad1 -promunidad2 -promunidad3 -promunidad4 -promfinal -observacion * 1 * 1 HorarioDocente -codHorarioDocente -hora -dia -estado * 1 AsignaturaMinisterio -codAsignaturaMinisterio -nombre -abreviacion -estado Equivalencia -codEquivalencia -anio -estado * 1 * 1 AreaEstudio -codAreaEstudio -nombre -piso -capacidad -tipo -estado * 1 * 1 Empleado -codEmpleado -nombres -paterno -materno -email -estado -telefono -celular Usuario -codUsuario -nombre -clave -fechacreacion -perfil -estado 1 1 Log -codLog -horaFecha -accion -descripcion * 1 1 1 1 1 Tramite -codTramite -fechaRegistro -fechaAtencion -tipoDocumento -codigo -estado * 1 * 1 instituto -codInstituto -nombre -subregion -direccion -numero -provincia -distrito -director -resolucion -telefono Turnoministerio -idturnoministerio -nombre * 1 Figura 2.5. Diagrama de clases de análisis. Cada una de estas de clases describe los datos o atributos más importantes de los objetos del sistema que representa. Algunas de las clases más importantes de este modelo son las siguientes: Alumno.- Representa a todos los alumnos del Instituto. Cada alumno será identificado por un código único. Grupo.- Representa a un grupo de alumnos que estudian una carrera profesional en un mismo turno y nivel en el Instituto. Cada grupo tienen unas fechas de inicio y de fin fijadas previamente a su inicio. Así mismo, los grupos se distinguen por un código único. 39 Matricula.- Representa a las matrículas de todos alumnos que se realizan antes de iniciar un nuevo nivel en el Instituto. AsignaturaInstituto.- Representa a las asignaturas que imparte el Instituto y que están agrupadas por especialidad o carrera profesional. Cada una de estas asignaturas tiene equivalencia con una asignatura del Ministerio de Educación. HorarioXGrupo.- Representa el horario académico que se ha establecido para un grupo. Cada horario relaciona un docente con una asignatura del Instituto que será impartida en un día y horas establecidas. En el apéndice D se puede encontrar más detalle acerca de cada una de estas clases y de los atributos que contiene. 2.3.2 Estudio Costo Beneficio El desarrollo e implementación de un Sistema de Información para el apoyo a la gestión académica de un Instituto Superior Tecnológico Privado conlleva gastos para la institución que adopta esta política de mejora, sin embargo, los beneficios que obtendrá superan ampliamente estos costos iniciales. Como gastos iniciales se debe considerar la adquisición de un equipo que cumpla la función de servidor de aplicaciones y de servidor de base de datos, esto permitirá a la institución tener control total sobre su información y no depender de un tercero. Se deberá implementar también un módulo que facilite el registro de notas obtenidas por los alumnos en las asignaturas a cargo de los docentes. Asumimos que ya existe instalada la conexión a Internet en la institución, esto permitirá el acceso de la información desde cualquier lugar y en todo momento. Así mismo, se asume que los empleados del área cuentan con un equipo con conexión a la red del área y acceso a Internet. Para realizar la capacitación del personal, se formarán tres grupos: empleados de Dirección Académica, coordinadores y docentes invirtiendo un total de S/.3760, según se detalla en la tabla 2.11. 40 Costo de capacitación de personal Tipo de empleado Costo hora- hombre (S/.) Total empleados Total horas- hombre Costo Total por tipo de empleado(S/.) Dirección Académica 10 8 16 1,280 Coordinador 15 4 8 480 Docente 10 100 2 2,000 Costo Total (S/.) 3,760 Tabla 2.11. Costo de capacitación de personal. La implementación del Sistema de Gestión Académica aportará beneficios económicos a la Institución que se explicarán en los siguientes párrafos. Por lo expuesto en la sección 1.2.5., uno de los problemas que afronta el área de Dirección Académica es la pérdida de horas-hombre. Podemos estimar el tiempo que actualmente se desperdicia en el área de Dirección Académica al no utilizar INSTISOFT:  Búsqueda de notas de alumnos.- Diariamente se realizan un promedio de 20 consultas de notas de alumnos en los archivos de la Institución, esto hace un aproximado de 400 consultas al mes. Por cada consulta se invierte un promedio de 30 minutos. Por tanto, al mes se desperdicia 200 horas en búsquedas de notas de forma manual.  Registro de notas finales de alumnos.- En un mes, 15 aulas en promedio finalizan un periodo lectivo, por lo que se deben registrar las notas finales obtenidas por los alumnos. Si consideramos que cada aula cursa 7 asignaturas en promedio y que por el registro de notas de un curso se utilizan 20 minutos, obtendríamos un total de 35 horas al mes desperdiciadas por el personal del área de Dirección Académica. Esto se evitaría al permitir que los docentes registren, ellos mismos, estas evaluaciones.  Elaboración de Certificados de Notas Oficiales.- Diariamente se solicitan un promedio de 10 Certificados de Notas Oficiales, lo que en un mes 41 haría un total de 200 solicitudes. Tomando en cuenta que se invierte 20 minutos por elaborar el documento en mención en un cuadro, harían un total de 67 horas al mes. Es decir, que en total se desperdician aproximadamente 302 horas-hombre por no utilizar el software INSTISOFT. Si consideramos que el costo de hora- hombre promedio es de S/. 10.00, el valor total de horas-hombre perdidas seria de S/. 3,020 por mes. Otro problema expuesto en la sección 1.2.5. es la sanción a la que puede estar afecta la Institución por el incumplimiento en la entrega oportuna semestral de documentos a la Dirección Regional de Educación de Lima, tales como Nóminas de Matrículas y Actas de Evaluación Semestral. El monto de esta sanción es variable, pero por lo general, asciende a una UIT (Unidad Impositiva Tributaria), es decir, a S/. 3,600, según [SNT11]. La implementación de INSTISOFT permitirá disminuir los gastos incurridos en el área de Dirección Académica que han sido expuestos en los párrafos anteriores. A continuación se muestra en la tabla 2.12 un resumen de los conceptos y valores de costos y beneficios tratados de esta sección. Costos Beneficios Ítem Valor mensual (S/.) Valor por 5 meses (S/.) Ítem Valor mensual (S/.) Valor por 5 meses (S/.) Servidor de Base de Datos y Aplicaciones 1,000 5,000 Sanción de la DRELM (1 UIT). En promedio una sanción por semestre. 710 3,550 Módulo de registro de notas. 720 3,600 Ahorro de horas-hombre en actividades manuales. 3,020 15,100 Capacitación de personal 627 3,760 42 Costos Beneficios Ítem Valor mensual (S/.) Valor por 5 meses (S/.) Ítem Valor mensual (S/.) Valor por 5 meses (S/.) Total 2,347 12,360 Total 3,730 18,650 Tabla 2.12. Cuadro de resumen de Costo-Beneficio para la implementación del proyecto en 6 meses. 2.3.3 Definición del Entorno Tecnológico Las herramientas que se utilizarán para la implementación de este proyecto de apoyo a la gestión académica de un Instituto Superior Tecnológico Privado tienen como principal característica el ser software libre, lo que permite ahorrar en costos de implementación y libera a la institución del pago de licencias. Para la implementación del Sistema de Gestión Académica se utilizará el lenguaje de programación Java, cuyo compilador en su versión 1.6 se puede descargar de la página de SUN Microsystems [SUN09]. El IDE de programación será NetBeans versión 6.9.1, el cual se puede descargar de la página de Netbeans Community [NBE10]. El servidor de la aplicación utilizará el contenedor de servlets Tomcat versión 6.0, el cual se puede descargar de la página de Apache Tomcat [TOM09]. Este servidor permite ejecutar aplicaciones desarrolladas en lenguaje java. El motor de la base de datos que se utilizará para el almacenamiento y manejo de la información será PostgreSQL versión 8.4 Herramientas para la construcción del Sistema de Gestión Académica Tipo Nombre Versión Lenguaje de programación Java Edición estándar 1.6.0 Entorno de desarrollo NetBeans IDE 6.9.1 Base de Datos PostgreSQL 8.4.0 Servidor de aplicaciones Web Tomcat 7.0 43 Herramientas para la construcción del Sistema de Gestión Académica Tipo Nombre Versión Servidor Web Apache 2.0 Tabla 2.13. Herramientas para la construcción del Sistema de Gestión Académica. 2.3.4. Viabilidad del Proyecto Por lo expuesto en las secciones 2.3.1, 2.3.2 y 2.3.3 se pueden apreciar los beneficios que aportará la implementación de este Sistema de Gestión Académica a un Instituto Superior Tecnológico y en particular al área de Dirección Académica, no sólo en sentido económico, por el ahorro de horas de trabajo del personal y recursos materiales, sino también por el uso de la tecnología que incrementará la eficiencia de los empleados, al controlar y reducir los errores que se producen en el tratamiento manual de datos, y aliviara la carga de trabajo. La inversión que realice la institución en la implementación de este Sistema de Gestión Académica será recuperada en menos de un semestre, obteniendo luego como beneficio un ahorro de S/.4762 mensuales, lo que representa un aproximado de S/. 57144 anuales, esto último sin considerar el ahorro por pagos de demandas judiciales por negligencia de personal, o la revalorización de la imagen de la institución, tanto interna como externamente, lo que incrementaría su ventaja competitiva y consecuente incremento de ganancias. Por ser un sistema complejo en funciones y extenso en características, conviene dividirlo en módulos que agrupen funciones relacionadas, de modo que la solución al problema del área de Dirección Académica sea mucho más fácil de implementar y mantener durante el periodo de 5 meses propuesto para este proyecto. Por lo expuesto, podemos afirmar que estamos presentando una herramienta que es útil, por las funciones que implementa para atender las necesidades del área de Dirección Académica, y económica, por los ahorros relacionados a horas-hombre, pagos de sanciones y trámites administrativos que generará, lo que la convierte en una excelente alternativa de solución para los 44 problemas del área de Dirección Académica de un instituto Superior Tecnológico. 45 3. Diseño de la Solución El diseño de la solución del problema identificado en el capítulo 1 del presente documento tiene como objetivo principal definir la arquitectura del software del sistema, detallando los componentes que se utilizarán para el Sistema de Información de Gestión Académica de un Instituto Superior Tecnológico. Este capítulo explica los dos aspectos principales que guiarán el diseño del software, la definición de la arquitectura y el diseño que se utilizará para crear la interfaz gráfica del sistema. 3.1. Arquitectura de la Solución El Sistema de Información tratado en el presente documento de tesis se implementará sobre una plataforma Web, esto permitirá la flexibilidad del sistema logrando estar al alcance de todos los usuarios a través de un navegador web, y disponible en todo momento y desde cualquier lugar siempre que se utilice un servidor web público. 46 Para definir la arquitectura de este Sistema de Información Web, se disponen de varias herramientas tecnológicas de código abierto disponibles en Internet para el lenguaje Java, de las cuales se expondrán en las siguientes subsecciones dos alternativas. Estas utilizan el patrón MVC o Modelo Vista Controlador, así como también se basan en una estructura de niveles o capas: presentación, dominio y persistencia. Según [ART04] MVC es un patrón de diseño que se utiliza para separar los datos de su representación, lo que permite a los desarrolladores crear las funciones del sistema que permitirán el acceso a datos sin tener que preocuparse por la forma como se presentarán al usuario. Figura 3.1. Patrón MVC El modelo de MVC es responsable por los datos y reglas del sistema. Coordina la lógica del negocio, el acceso a la base de datos, y todas las otras acciones críticas del sistema que no se relacionan con la parte visual. La vista en MVC se encarga de mostrar los datos sin alterarlos. Finalmente, el controlador es el mecanismo por el cual la vista y el modelo se comunican. 3.1.1. Arquitectura basada en el Framework Struts Según [ART04] un framework es un conjunto de clases relacionadas y otros elementos de soporte que facilitan el desarrollo de aplicaciones por el suministro de parte preconstruidas. 47 Struts fue uno de los primeros frameworks basados en el patrón de diseño MVC (Modelo Vista Controlador) que aparecieron en Internet. Es de distribución gratuita, basado en código Java, y se puede descargar de la página de Apache en [APA09]. En una aplicación web típica un cliente envía datos a través de un formulario HTML, esta información es manejada por un Servlet de Java que se encarga de procesarla, por lo general interactuando con una base datos, para luego preparar la respuesta en un formato HTML, o bien, enviarla a una página JSP (Java Server Page) la que puede combinar código Java con HTML para presentar información obtenida de forma dinámica. Tal como se menciona en [ART04] el objetivo de Struts es separar claramente las funciones del modelo (lógica de la aplicación que interactúa con la base de datos) de la vista (páginas HTML presentadas al cliente) y del controlador (instancia que pasa información entre la vista y el modelo). Struts provee el controlador (un Servlet conocido como ActionServlet) y facilita la escritura de plantillas para la capa de presentación o vista (típicamente páginas JSP, aunque también podría ser un archivo XML). En este modelo de arquitectura, las interfaces utilizan librerías de etiquetas HTML propias de Struts y lenguaje JavaScript. Las librerías de etiquetas HTML de Struts constituyen el término Vista dentro del modelo MVC. Las clases que conforman la lógica del negocio obtienen la información de la base de datos a partir de la capa de persistencia utilizando la lógica implementada por el sistema, para luego enviarla a la capa de presentación. Estas clases constituyen la capa de negocio del sistema. La última capa de este modelo es la de persistencia con clases dedicadas a la comunicación del sistema con la base de datos, utilizando, para ello, el Framework Hibernate, el que tiene como principal función vincular las tablas de un modelo de bases de datos relacional con entidades del dominio que pertenecen a un modelo orientado a objetos, conocidos como POJO’s. Esto lo realiza a través de archivos XML. Hibernate se encarga de concretar las transacciones con las bases de datos. 48 Las clases de la capa de persistencia junto con las clases de negocio constituyen para Struts el término Modelo del diseño MVC. La figura 3.2 muestra la estructura de componentes del framework Struts descrita en los párrafos anteriores de esta misma sección. Se debe resaltar la función del archivo xml Struts-config.xml, el que permite configurar las acciones que se realizarán como respuesta a los requerimientos de los clientes web. Figura 3.2 Una aplicación con Struts, en [STR02]. 3.1.2. Arquitectura basada en el Framework Spring En [SPR06] se menciona que el framework Spring es software de código abierto que implementa patrones de diseño conocidos como Factory, Abstract Factory, Builder, Decorator, Service Locator, entre otros. Es un framework de código abierto que se comunica fácilmente con otros frameworks como lo son: Struts, Hibernate, iBatis, Tapestry, entre otros. Entre las características más resaltantes de Spring encontramos los módulos por los que esta compuesto, tal como se muestra en la figura 3.3. Algunos de estos módulos son: 49  El Core Container o Contenedor de Inversión de Control (Inversion of Control, IoC) es el núcleo del sistema. Responsable de la creación y configuración de los objetos.  Aspect-Oriented Programming Framework, que trabaja con soluciones que son utilizadas en numerosos lugares de una aplicación, lo que se conoce como asuntos transversales (cross-cutting concerns).  Data Access Framework, que facilita el trabajo de usar un API (Librería o archivo que contiene funciones para el desarrollo de aplicaciones) con JDBC (Conjunto de clases que pertenecen al lenguaje java para realizar operaciones con bases de datos), Hibernate, etc.  Remote Access framework. Facilita la existencia de objetos en el servidor que son exportados para ser usados como servicios remotos.  Spring Web MVC. Maneja la asignación de peticiones a controladores y desde estos a las vistas. Implica el manejo y validación de formularios.  Spring Web Services Figura 3.3. Estructura del Framework Spring, ver en [SPR08]. En este modelo de arquitectura las interfaces JSP (Java Server Pages o Páginas de Servidor Java) forman la capa de presentación, estas páginas utilizan el lenguaje JavaScript, tanto para comunicarse con las clases dedicadas a la lógica de presentación como para mostrar las respuestas a los usuarios en un formato sencillo. 50 El control del flujo de datos en la presentación lo realizan las clases Action de Struts integradas a Spring, estas clases se encargan de controlar la comunicación entre el cliente y el servidor. Las clases de negocio que constituyen la capa de negocio se encargan de administrar los datos obtenidos de la base de datos y presentarlos en el formato reconocido por las clases dedicadas a la lógica de presentación. Debido que Spring permite que cualquier clase ejecute sus métodos de manera transaccional, el control de las transacciones se realiza en la capa de negocio. Finalmente, de forma similar a Struts, este modelo de arquitectura posee una capa de persistencia que contiene un conjunto de clases encargadas de comunicarse con la base de datos, utilizando el Framework Hibernate, que se integra con Spring. Los datos obtenidos de la base de datos relacional se almacenan en las clases de dominio o entidades de negocio, las que tienen la misma estructura que sus correspondientes tablas. Estas clases de dominio pertenecen a la capa de persistencia. 3.1.3. Arquitectura elegida La arquitectura que se utilizará en la etapa de Diseño e Implementación de INSTISOFT estará conformada por las tecnologías Struts en su versión 2 y Spring descritas en los puntos 3.1.1 y 3.1.2 de este documento. Debido a que el Framework Spring se acopla perfectamente con otros Frameworks como Struts y Hibernate, se logrará aprovechar las mejores características de cada una de estas herramientas, como son el adecuado control del flujo de información desde la capa de presentación o vista hacia el modelo o lógica del negocio, en el caso de Struts, y el manejo eficiente de las transacciones con base de datos relacionales desde una aplicación orientada a objetos, como es el caso de Hibernate. Además, tal como se muestra en la figura 3.4, las herramientas seleccionadas, Spring, Struts y Hibernate pueden trabajar en conjunto bajo el 51 patrón de diseño MVC (Modelo Vista Controlador), el cual se ha seleccionado para desarrollar el software de este trabajo de tesis por representar mejor a la estructura de una aplicación web, así como implementar sus funciones. Figura 3.4. Spring + Struts + Hibernate, ver en [SHI11]. 3.2. Diseño de la Solución Esta sección tiene como propósito presentar el diseño de las interfaces que se utilizarán para acceder y utilizar las funciones implementadas en el software INSTISOFT. Para permitir el ingreso de los usuarios registrados al sistema INSTISOFT se utilizará un formulario inicial, tal como se muestra en la figura 3.5, en el que 52 se solicitará el nombre y clave de usuario, para poder verificar la existencia de los datos en el sistema. Figura 3.5. Ingreso al sistema INSTISOFT. Una vez que se haya validado a un usuario, el Sistema de Información para la Gestión Académica de Instituto Superior Tecnológico (INSTISOFT) utilizará un diseño de interfaz dividida en 2 secciones, tal como se muestra en la Figura 3.6. En la sección superior se describe el nombre del producto, así como los datos del usuario conectado al sistema (nombres, apellidos y tipo de usuario). Además, en esta sección podemos observar una barra de menús que permitirá a los usuarios acceder a diferentes funciones de la aplicación según el rol que se le haya asignado. En la siguiente sección se muestra el contenido del formulario, si este es demasiado grande para ser mostrado en el área de la ventana aparecerá una barra de desplazamiento vertical. 53 Figura 3.6. Diseño de Interfaz de INSTISOFT. La barra de menús que se utilizará será horizontal y estará ubicada en la parte superior de la ventana del navegador. Esta barra contiene las opciones principales del menú, que no serán las mismas para todos los usuarios, pues variarán según el tipo de usuario que se haya conectado. Por ejemplo, las opciones del menú que se muestran en la figura 3.6 corresponden a un usuario con perfil de Administrador Académico, y son distintas a las opciones de menú que se muestran en la figura 3.7, que corresponden a un usuario con perfil Docente. Figura 3.7. Barra de Menús de un usuario con perfil Docente. Al seleccionar con un clic uno de estos menús, entonces se desplegarán las alternativas correspondientes tal como se muestra en la figura 3.8. 54 Figura 3.8. Barra de Menús de INSTISOFT. Por lo general, una vez que se seleccione alguna de las alternativas de los menús se mostrará un formulario con enlaces relacionados a operaciones que se pueden realizar, tal como búsqueda o registro, con la entidad respectiva, tal como se muestra en la figura 3.9. Figura 3.9. Formulario de enlaces de operaciones. Los formularios que se utilicen para registrar o modificar datos de entidades del sistema presentarán un formulario con el titulo apropiado, según se vaya a registrar una nueva entidad o modificar los datos de una existente, así como el nombre de la entidad correspondiente tal como se muestra en la figura 3.10. Este formulario presentará dos botones, uno para Grabar los datos y el otro para Limpiar los valores escritos o seleccionados en los campos. Así mismo, se mostrará un enlace que permitirá realizar una búsqueda de la entidad correspondiente. El sistema generará los identificadores únicos para cada entidad registrada, estos identificadores serán números correlativos que empezaran en uno. En el caso de los alumnos y los grupos se generarán códigos con un formato específico. Para el caso de los alumnos su código estará formado por el año en que se registra y un número correlativo de 4 dígitos, por ejemplo: 20110001, corresponderá al primer alumno registrado en el año 2011. Para el caso de los grupos su código estará formado por el número del mes y año de inicio, la letra inicial del turno, la abreviación de la especialidad y el nivel del grupo (que toma los valores del uno al seis), por 55 ejemplo: 05/2011/M/CEI/1, corresponde al grupo que inició en Mayo del 2011, en el turno mañana, en la especialidad de Computación e Informática y en el primer nivel. Para el caso de las especialidades o carreras profesionales, será el mismo usuario quien cree una abreviación del nombre, la cual deberá será validada por el sistema para evitar duplicidades, esta abreviación servirá como código de la especialidad. Figura 3.10. Formulario de registro de datos. Los formularios que se utilicen para realizar la búsqueda de datos presentarán un área de filtro donde se ingresarán las condiciones de búsqueda a realizar y un área de resultados, que mostrará el conjunto de registros coincidentes con los datos de búsqueda proporcionados que han sido encontrados. Tal como se puede apreciar en la figura 3.11, luego de seleccionar el botón Buscar, estos datos se presentarán en forma de tabla con opciones de exportación a diferentes formatos como Excel (versión 2003), PDF (versión 8.0), XML o CSV. Así mismo, en la parte inferior se presenta un enlace que permitirá retornar al formulario con los enlaces principales a las operaciones que se pueden realizar con la entidad tratada. 56 Figura 3.11. Formulario de búsqueda de datos. En el caso de que una operación de registro haya tenido éxito se mostrará un mensaje en forma de etiqueta en color verde en la ventana de enlaces de operaciones tal como se muestra en la figura 3.12, pero si la operación de registro, búsqueda o generación de reporte fracaso se mostrará un mensaje de error en color rojo en el mismo formulario donde se ejecuto la operación, tal como se puede apreciar en la figura 3.13. Figura 3.12. Mensaje de éxito de operación. 57 Figura 3.13. Mensaje de error de operación. Como se puede apreciar todos los formularios presentan una interfaz intuitiva, y homogénea que permitirá al usuario familiarizarse fácilmente con su uso. 3.3. Arquitectura de la Información En esta sección se describe la estructura de la base de datos teniendo en cuenta que el Sistema Gestor de Base de Datos relacional que se utilizará será PostgreSql, en su versión 8.4, lo que fija un rango de tipos de datos a utilizar en el sistema. Esta base de datos se ha diseñado para satisfacer las necesidades del Sistema de Información para la Gestión Académica de un Instituto Superior Tecnológico. El modelo de base de datos del sistema se muestra en la figura 3.14. 58 alumno idalumno: serial idusuario: integer (FK) codigo: character(10) nombres: character varying(30) paterno: character varying(30) materno: character varying(30) telefonofijo: character varying(10) celular: character varying(10) email: character varying(50) web: character varying(50) domicilio: character varying(120) estado: character varying(10) dni: character(8) fechanacimiento: date docente iddocente: serial nombres: character varying(30) paterno: character varying(30) materno: character varying(30) domicilio: character varying(120) email: character varying(50) web: character varying(50) telefono: character(7) idusuario: integer (FK) estado: character varying(10) celular: character(9) especialidad idespecialidad: serial nombre: character varying(50) estado: character varying(10) clave: character(3) asignaturainstituto idasignaturainstituto: serial nombre: character varying(50) idespecialidad: integer (FK) idnivel: integer (FK) abreviacion: character varying(5) estado: character varying(10) grupo idgrupo: serial idnivel: serial (FK) idturno: serial (FK) codigo: character varying(20) idespecialidad: integer (FK) idperiodoministerio: integer (FK) idareaestudio: integer (FK) fechainicio: date fechafin: date estado: character varying(10) areaestudio idareaestudio: serial nombre: character varying(50) piso: integer tipo: character varying(30) estado: character varying(10) capacidad: integer turno idturno: serial nombre: character varying(10) empleado idempleado: serial nombres: character varying(30) paterno: character varying(30) materno: character varying(30) idusuario: integer (FK) email: character varying(50) estado: character varying(10) telefono: character(7) celular: character(9) usuario idusuario: serial idperfil: integer (FK) nombre: character varying(50) clave: character varying(30) fechacreacion: date estado: character varying(10) perfil idperfil: serial nombre: character varying(50) descripcion: character varying(200) matricula idmatricula: serial idgrupo: integer (FK) fecharegistro: date idalumno: integer (FK) idsituacion: integer (FK) idcondicion: integer (FK) codigo: character(11) reciboPago: character varying(6) estado: character varying(10) fechamodificacion: date ennomina: character(2) edad: integer dia iddia: serial nombre: character varying(10) nivel idnivel: serial numero: integer horarioxgrupo idhorarioxgrupo: serial iddocente: integer (FK) iddia: integer (FK) idgrupo: integer (FK) idareaestudio: integer (FK) idhorainicio: integer (FK) idasignaturainstituto: integer (FK) idhorafin: integer notaxasignatura idnotaxasignatura: serial idmatricula: serial (FK) promunidad1: integer promunidad2: integer promunidad3: integer promunidad4: integer promfinal: integer idasignaturainstituto: integer (FK) observacion: character varying(200) horariodocente idhorariodocente: serial iddocente: integer (FK) iddia: integer (FK) idhora: integer (FK) estado: character varying(50) tramite idtramite: char(18) idtipodocumento: integer (FK) fecharegistro: date fechaatencion: date descripcion: character varying(200) idalumno: integer (FK) idempleado: integer (FK) codigo: character(6) estado: character varying(10) tipodocumento idtipodocumento: serial nombre: character varying(50) log idlog: serial horafecha: character varying(25) descripcion: character varying(200) idaccion: integer (FK) idusuario: integer (FK) accion idaccion: serial nombre: character varying(25) hora idhora: serial inicio: character varying(2) fin: character varying(2) asignaturaministerio idasignaturaministerio: serial nombre: character varying(50) idespecialidad: integer (FK) abreviacion: character varying(5) idnivel: integer (FK) estado: character varying(10) equivalencia idequivalencia: serial idasignaturainstituto: integer (FK) idasignaturaministerio: integer (FK) anio: integer estado: character varying(10) situacion idsituacion: serial nombre: character varying(30) condicion idcondicion: serial nombre: character varying(15) periodoministerio idperiodoministerio: serial nombre: character varying(10) nomina idnomina: serial codigo: character(10) cara: integer idperiodoministerio: serial (FK) idturnoministerio: serial (FK) idnivel: serial (FK) idespecialidad: serial (FK) matriculadosxnomina idmatriculadosxnomina: char(18) idmatricula: integer (FK) idnomina: integer (FK) asignaturainstitutoxdocente idasignaturainstitutoxdocente: serial idasignaturainstituto: integer (FK) iddocente: integer (FK) instituto idinstituto: serial nombre: character varying(100) subregion: character varying(15) direccion: character varying(50) numero: character varying(5) distrito: character varying(50) provincia: character varying(50) telefono: character(7) director: character varying(50) resolucion: character varying(100) turnoministerio idturnoministerio: serial nombre: character varying(10) Figura 3.14. Diagrama físico de base de datos. En el anexo F se presenta con mayor detalle el modelo físico de esta base de datos. 59 4. Construcción y Pruebas En esta sección se desarrolla el código de los componentes del Sistema de Información para la Gestión Académica de un Instituto Superior Tecnológico, así mismo se desarrollan todos los procedimientos de operación y seguridad con el objetivo de asegurar el correcto funcionamiento del Sistema para su posterior implantación. En las siguientes subsecciones se explica el proceso de construcción del sistema, así como también se incluye la realización de pruebas unitarias, pruebas de integración de los subsistemas y componentes y pruebas del sistema, de acuerdo al plan de pruebas establecido. 4.1. Construcción En este proceso se codifican los componentes del sistema en base a las especificaciones de construcción establecidas en la sección 3 correspondiente a la etapa de diseño. De acuerdo a lo que se estableció en la etapa de análisis, para la construcción del Sistema de Información para la Gestión Académica de un Instituto Superior Tecnológico, se deben cumplir los siguientes requisitos: 60  Registro de una nueva programación académica o inicio de ciclo en algún nivel de una especialidad considerando asignaciones de aulas, laboratorios y de docentes encargados de la enseñanza. Se verificarán los cruces en la asignación de recursos y docentes.  Matrícula de alumnos en un grupo asignado a un inicio de ciclo. Se verificará la disponibilidad de vacantes del grupo para evitar matrículas indebidas.  Generar Nóminas de Matrículas y Actas de Evaluación Semestral en base a los formatos utilizados por el Ministerio de Educación del Perú.  Registrar usuarios del sistema. Así mismo, en la etapa de diseño se decide utilizar el framework Spring como modelo para la construcción del sistema y el Framework Hibernate para la conexión y transacciones con la base de datos. A continuación, se explica de qué forma se implementaron estas características en el sistema. 4.1.1. Acceso a Datos utilizando el Framework Hibernate El Framework Hibernate se ubica en el dominio del “modelo” del patrón MVC y se encarga de realizar la conexión con la base de datos PostgreSQL, así como de ejecutar las consultas y transacciones sobre la información almacenada en las tablas de dicha base de datos. Como paso inicial para realizar estas actividades se utiliza un archivo que pertenece al Framework Hibernate, llamado hibernate.cfg.xml, y que se utiliza para realizar la configuración de conexión con base de datos. Este archivo contiene información de la conexión como el nombre y tipo de base de datos, el puerto de conexión a utilizar así como el nombre y clave de cuenta de usuario que se utilizará. Una vez creado el archivo de configuración se procede a crear la estructura de clases conocidas como POJO’s (Plain Old Java Object), las que se relacionan con cada una de las tablas de la base de datos en un procedimiento conocido como “mapeo”. Estas clases se utilizan para comunicar el modelo relacional de la base de datos PostgreSQL y el modelo 61 orientado a objetos de Java, de forma que para realizar las operaciones de consulta y transacciones se utilice la estructura de estas clases para almacenar y compartir información. A bajo nivel se utilizan objetos Session y Transaction para la comunicación con la base de datos. El uso del objeto Transaction permite realizar operaciones como agregar, modificar y eliminar datos sin tener que crear instrucciones sql. Se debe mencionar que el entorno de NetBeans facilita a través de sus asistentes la creación del archivo de configuración de Hibernate y del los POJO’s. 4.1.2. Administrando la lógica del negocio con el Framework Spring Una vez completadas las operaciones de “mapeo” de la base de datos utilizando el Framework Hibernate, se desarrolla la lógica del negocio que se encuentra en el “modelo” del patrón MVC. Para ello se definen en primer lugar las clases que se encargarán de implementar el patrón DAO (Data Access Object) y que permitirán persistir los objetos del dominio del modelo en la base de datos. Luego, se crean las clases que contendrán en sí toda la lógica del negocio, y que serán los llamados en el momento que se tenga que proporcionar alguna función del sistema. Para atender los requerimientos capturados por Struts desde la “vista” se debe configurar el archivo XML de contexto de Spring, para que se encargue de proporcionar los objetos necesarios (inyección de dependencia) a las clases Action del Framework Struts. Debido a que Spring implementa la programación orientada a aspectos, se utiliza esta característica en el sistema para interceptar los errores que se puedan generar en la ejecución de los métodos de alguno de los objetos del modelo, y así simplificar este proceso. En este caso se utiliza una clase 62 conocida como “Proxy” que se encargará de capturar los errores, tratarlos y enviar un mensaje predefinido a la capa de presentación. 4.1.3. Atendiendo los requerimientos de los usuarios con Struts. Para capturar los requerimientos enviados por los usuarios a través de la “vista” se utilizan las clases Action del Framework Struts. En estas clases es donde se implementa la inyección de dependencia del Framework Spring. La integración entre ambos frameworks se logra cediéndole todo el control del manejo de la clase Action de Struts al Framework Spring. Por tanto existirá una relación o “mapeo” entre la clase Action de Struts, que captura o intercepta una solicitud y la clase de Spring encargada de atender dicho requerimiento. Como se explico en la subsección anterior, esta relación también se debe declarar en el archivo de contexto de Spring. 4.1.4. Diseño de reportes con las herramienta iReport y JasperReports iReport es una herramienta visual que sirve para generar ficheros XML (plantillas de informe) que se puedan utilizar con la herramienta de generación de informes JasperReports. Ambas herramientas se pueden descargar de [RPT10]. El Jasper Report es una librería para la generación de informes. Está escrita en Java y es libre. El funcionamiento consiste en escribir un archivo XML donde se recogen las particularidades del informe. Este archivo XML lo tratan las clases del Jasper para obtener una salida. Esta salida puede ser un PDF, XML, HTML, CSV, XLS, RTF, TXT. El paso inicial que se sigue para trabajar con estas herramientas fue configurar las variables de entorno de la herramienta iReport, para establecer 63 el origen de base de datos y las librerías que se utilizarían. Luego se establece el tamaño del reporte, por defecto A4, sin embargo, para el Acta de Evaluación Semestral se utilizo el tamaño A3. El asistente muestra un diseño de reporte dividido en secciones horizontales. A continuación se definen los distintos elementos que mostrarán alguna información sobre el reporte, tales como parámetros, campos, imágenes, elementos de texto, etc. Finalmente se compila el reporte y se genera un archivo XML. Este archivo XML será el que utilizará la herramienta JasperReports, que está incorporada en NetBeans, para mostrar la información de la base de datos en el reporte. 4.2. Pruebas En esta sección se describen los casos de prueba que se utilizarán para medir el rendimiento del sistema desarrollado en el presente trabajo. Estas pruebas se realizarán en una primera etapa por cada uno de los módulos del sistema (pruebas unitarias), luego integrando cada módulo (pruebas de integración) y finalmente una prueba a todo el sistema. 4.2.1. Pruebas unitarias El objetivo principal de realizar las pruebas unitarias es comprobar el correcto funcionamiento de cada uno de los componentes individuales ubicados en los diferentes módulos del presente sistema de información. Estas pruebas se han diseñado en base al documento Plan de Pruebas Unitarias del Sistema que se encuentra en el anexo G. La ejecución de estas pruebas unitarias empieza con el registro o creación de datos, luego continúan las actualizaciones, búsquedas o consultas y se concluye con la eliminación. 64 A continuación se presentan las pruebas unitarias más importantes del presente sistema. a. Pruebas Unitarias del Módulo de Programación Académica Para el módulo de Programación académica se realizaron los siguientes casos de prueba:  Creación de grupo.- Verifica que los datos del grupo creado son los mismos que los datos iniciales de la prueba.  Actualización de grupo.- Verifica que los datos del grupo creado son modificados por los datos iniciales de la prueba.  Eliminación de grupo.- Verifica que el grupo establecido como dato inicial de prueba es eliminado.  Creación de un horario académico de un grupo.- Verifica que los datos del horario creado son los mismos que los datos iniciales de prueba. b. Pruebas Unitarias del Módulo de Alumnos Para el módulo de Alumnos se realizaron los siguientes casos de prueba:  Búsqueda de alumno por código.- Verifica que los datos del alumno devuelto corresponden al código ingresado.  Búsqueda de alumno por apellidos.- Verifica que los datos del alumno devuelto corresponden a los apellidos ingresados.  Creación de matrícula de alumno.- Verifica que los datos de la matrícula creada son los mismos que los datos iniciales de la prueba.  Actualización de matrícula.- Verifica que los datos de la matrícula creada son modificados por los datos iniciales de la prueba.  Eliminación de matrícula.- Verifica que la matrícula establecida como dato inicial de prueba es eliminada. c. Pruebas Unitarias del Módulo de Consultas y Reportes. 65 Para el módulo de Consultas y Reportes se realizaron los siguientes casos de prueba:  Búsqueda de notas de alumno por matrícula.- Verifica que las notas del alumno devueltas corresponden a la matrícula ingresada.  Creación de nómina de matrícula.- Verifica que los datos de nómina creada corresponda a los datos iniciales ingresados.  Búsqueda de nómina de matrícula.- Verifica que los datos devueltos correspondan a la nómina que acaba de ser creada.  Elaboración de acta de evaluación semestral.- Verifica que los datos del acta correspondan a la nómina seleccionada. 66 5. Observaciones, conclusiones y recomendaciones En esta sección se describen las observaciones, conclusiones y recomendaciones finales en base a lo expuesto en el presente proyecto. 5.1 Observaciones Como se explica en la sección 1.4 de este documento existen varias herramientas comerciales que se ofrecen en el mercado informático como apoyo a la gestión académica de una entidad educativa. Sin embargo, la mayoría de estas herramientas son software de tipo genérico que proceden de otros países, lo que implica que no atienden los principales requerimientos que presenta un Instituto Tecnológico y que no se adapta a la forma de trabajo de las instituciones de nuestro medio. El software propuesto en este proyecto pretende satisfacer los requerimientos primarios de los Institutos Tecnológicos de nuestro país incorporando características ofrecidas por software genérico ofrecido en Internet y en tiendas comerciales de software. De esta manera se logra un producto 67 apropiado a las exigencias de los Institutos tecnológicos de nuestro medio y que además es competente con otros productos ofrecidos por al competencia. 5.2 Conclusiones La metodología RUP en las fases elegidas para el desarrollo de este proyecto, tal como se indican en la sección 2.1.2, guiaron de forma efectiva el desarrollo del software en todas sus etapas, desde el análisis hasta la implementación, brindando un mecanismo fiable y eficiente que describía cada componente considerado para la implementación final. Los conocimientos adquiridos durante los ciclos de estudio en la Facultad de Ciencias e Ingeniería de la Universidad se integraron y coadyuvaron a la conclusión satisfactoria de este trabajo. Pero, se debe considerar que gran parte de este conocimiento es de orientación general, y por tanto para una aplicación particular tal conocimiento debe ser complementado con herramientas y tecnologías de soporte que competen al alumno investigar su aplicación. 5.3 Recomendaciones Una dificultad encontrada en el presente proyecto ha sido la falta de tiempo suficiente para la realización de las actividades asociadas a su desarrollo. Es por este motivo que no se agregaron algunas funcionalidades que resultarían importantes para la institución. Por ejemplo, el proceso de cobros por matrícula y pensión que se realiza a los alumnos, si bien es cierto que se relaciona con otra área que pertenece a la Dirección Administrativa, este proceso se complementa con la matrícula de alumnos. Por ello, se sugiere incorporar esta funcionalidad como una extensión del presente proyecto, de manera que se logre construir un producto útil en todas las áreas del instituto. Así mismo, se recomienda incorporar herramientas de comunicación que fomenten la participación de los alumnos y docentes, tales como wikis, foros y 68 blogs. El concepto de Web 2.0 se adapta muy bien al ámbito educativo teniendo como objetivo la difusión de contenidos temáticos por parte de docentes y la edificación de una comunicación dinámica y eficaz entre los diferentes miembros del Instituto. 69 6. Referencias 5.4 Libros [ART04] N. Ford, “Art of Java web Development”, Manning, Greenwich, 2004. Pags. 6-14, 131-155, [SPR06] S. Ladd, D. Davison, S. Devijver y C. Yates, “Expert Spring MVC and Web Flow”, Apress, USA, 2006. Pags. 7-75. 5.5 Referencias de Fuentes Electrónicas [MEE09] Ministerio de Educación – Dirección de Educación Superior Tecnológica y Técnico-Productiva. Consulta de Centros de Formación Profesional Técnica y Asociaciones Civiles. PERÚ. 2009. http://destp.minedu.gob.pe/centros.asp?xyz=1&xdpto=LIMA&sdpto= LIMA&xprov=LIMA&sprov=LIMA&xdist=TODOS&sdist=TODOS&xti pcen=01&Ytipcen=01&busca=. [MDS02] Ministerio de Educación – Dirección de Educación Superior Tecnológica y Técnico-Productiva. Decreto Supremo Nº 014-2002 ED. PERÚ. 2002. http://destp.minedu.gob.pe/docum/DS002-2008- ED.PDF [MED02] Ministerio de Educación - Normas De Inicio, Organización Y Desarrollo De Las Actividades Académicas De Los Centros Y Programas De Educación Ocupacional E Institutos Superiores Tecnológicos. PERÚ. 2002. http://destp.minedu.gob.pe/docum/D021-02-UFP-DINESST.doc. [MED09] Ministerio de Educación. Dirección de Educación Superior Tecnológica y Técnico-Productiva. RD Nº 0417-2009-ED. PERÚ. 2009. http://destp.minedu.gob.pe/docum/rd-0417-2009-ed.pdf 70 [MED08] Ministerio de Educación - Dirección de Educación Superior Tecnológica y Técnico-Productiva. R.D. Nº 0818-2008-ED. DIRECTIVA Nº 104-2008-DIGESUTP. PERÚ. 2009. http://ciberdocencia.gob.pe/index.php?id=2943&a=articulo_complet o. [SIGA07] Siga – Software Integrado de Gestión Académica. COLOMBIA. 2007. http://www.datasae.com/siga/index.php?option=com_content&task= view&id=12&Itemid=42. [SFA11] SoftAula – Software para Gestionar Instituciones Educativas. ESPAÑA. 2009. http://softaula.net/?page_id=1031. [IBM98] IBM – Rational unified Process – Best Practices for Software Development Team. 1998. http://www.ibm.com/developerworks/rational/library/content/03July/1 000/1251/1251_bestpractices_TP026B.pdf [IEEE04] IEEE Standard Association - IEEE Std 1490™-2003 Adoption of PMI StandardA Guide to the Project Management Body of Knowledge – Description. USA. 2004. http://standards.ieee.org/reading/ieee/std_public/description/se/149 0-2003_desc.html. [PEX09] Project Experts – Project ExpertEase Using Project Vital Signs to Prioritize Expectations. 2009. http://www.projectexperts.com/articles/1vitalsigns.html. [SNT11] Sunat. Valores de la UIT. PERÚ. 2009. http://www.sunat.gob.pe/indicestasas/uit.html [SUN09] Home Page de Sun Microsystems. USA. 2009. http://www.sun.com. [NBE10] Home Page de Netbeans Community. USA. 2010. http://www.netbeans.org. [TOM09] Home Page de Apache Tomcat. USA. 2009. http://tomcat.apache.org/. 71 [APA09] Home Page de Apache Software Foundation. USA. 2009. http://www.apache.org/. [STR02] Oracle - ¿How I Do Jakarta Struts with JDeveloper?. USA. 2002. http://www.oracle.com/technology/products/jdev/howtos/jsp/StrutsH owTo.html. [SPR08] DevelopersBook – Spring Framework Tutorials. USA. 2008. http://www.developersbook.com/spring/spring-tutorials/spring- tutorials.php. [SHI11] Schinetec .NET Case Study. CHINA. 2011. http://www.shinetechchina.com/softwave/case_study/loansystem.ht m. [RPT10] The Jaspersoft open source development site for community projects and the Jaspersoft Business Intelligence Suite. USA. 2010. http://jasperforge.org/. 5.6 Manuales [MAN07] Instituto Superior Tecnológico Privado Peruano Alemán. Manual de Usuario del Sistema del ISTP IPAL. PERÚ. 2007. Av. Uruguay Nº 514 - Lima. [MAN05] Instituto Superior Tecnológico Privado Federico Villarreal. Manual de Usuario del Sistema de Matrícula y Control de Pagos del ISTP Federico Villarreal. PERÚ. 2005. Av. 28 de Julio 687 - Lima. 72 Anexos Anexo A: Documento De Visión Anexo B: Catálogo de Requisitos Anexo C: Especificación de Requisitos de Software Anexo D: Documento de Análisis Anexo E: Documento de Arquitectura Anexo F: Modelo Físico de Base de Datos Anexo G: Plan de Pruebas Unitarias del Sistema