sistema de gestiÓn de procesos acadÉmicos de … · 2.3. arquitectura orientada a componentes ......

UNIVERSIDAD CENTRAL DEL ECUADOR

FACULTAD DE INGENIERÍA CIENCIAS FISICAS Y MATEMATICA

CARRERA DE INGENIERIA INFORMÁTICA

SISTEMA DE GESTIÓN DE PROCESOS ACADÉMICOS DE LA UNIDAD EDUCATIVA

“LA COLINA”

TRABAJO DE GRADUACION PREVIO A LA OBTENCIÓN DEL TITULO DE INGENIERO

INFORMÁTICO

AUTORES: RUBÉN ANDRÉS TUBÓN COICHÁN

ELIZABETH MARIA SAMPEDRO CHÁVEZ

TUTOR: ING. FRANZ EDUARDO DEL POZO SÁNCHEZ

QUITO, 8 JUNIO

2016

ii

DEDICATORIA

A mi hija Samantha Abigail y mi esposa Elizabeth María a las cuales no he podido

dedicar el tiempo merecido durante la elaboración del presente documento.

A mi padre Jorge Remigio y en especial a mi madre María Fabiola que con un

esfuerzo de trabajo, dedicación de tiempo no merecido y enfermedades dio una entrega que

solo una madre puede proporcionar tuvo la esperanza y amplia confianza en mis capacidades

para seguir con mi preparación académica.

A mis hermanos José Luis, Jorge Fernando y María Elena, Manuela Gardenia y Daniel

Geovanny, Ruth Esperanza, Marco Antonio, Claudia Azucena y Luis Patricio quienes me

apoyan todas mis decisiones y siempre con su aprecio, son el pilar para seguir en el diario

vivir.

A mis sobrinos Jorge Esteban†, Michelle Fernanda, Dulce María, Jorge Jefferson,

Kevin Daniel, Heidy Daniela, Jhonnathan Israel, Franco Leonardo, María José, Dayana

Janeth, Sebastián Alejandro, Leslie Karina y Wendy quienes han sido inspiración para seguir

estudiando y quienes son luz y futuras promesas para la sociedad.

Al ingeniero Franz del Pozo que ha sido un apoyo fundamental para este trabajo,

creando oportunidades para escalar peldaños en el conocimiento, quien es autor de una mente

abierta para compartir la información, que actualmente son las tendencias de corporaciones

vanguardistas.

Finalmente, a todos mis apreciados amigos de la infancia, juventud y amigos

profesionales, de la escuela, colegio, universidad, instituto de orientación juvenil y amigos del

trabajo que con frases de ánimo en momentos difíciles y momentos de alegría aportaron con

su granito para que este camino sea ameno.

Rubén A. Tubón

iii

DEDICATORIA

Con todo mi cariño y amor para mi esposo e hija, padres y hermanos que hicieron todo en la

vida para que yo pudiera lograr mis sueños, siempre supieron apoyarme y darme ánimos para

seguir adelante.

Esposo Andrés

Mi hija Samantha

Mi madre María Chávez

Mi Padre Jaime Sampedro

Mis Hermanos Paul y Daniel.

Elizabeth M. Sampedro

iv

AGRADECIMIENTOS

Permanentes agradecimientos a DIOS el autor de la vida y la verdad, quien permite en

toda su santa voluntad culminar esta meta, a mis padres Jorge Remigio y María Fabiola

quienes me han soportado y definitivamente han hecho un esfuerzos sobrehumanos con varias

anécdotas para cumplir un sueño de infancia; a varias instituciones educativas e institutos de

orientación juvenil que con ayuda de los valiosos recursos humanos que con su

profesionalismo fueron forjando con valores y ciencia mi personalidad y ética.

A mis hermanos y compañeros de las instituciones anteriores enunciadas en el párrafo

anterior quienes fueron en gran parte testigos de la armonía y compañerismo del crecimiento

personal e intelectual.

Rubén A. Tubón

v

AGRADECIMIENTOS

En primer lugar a Dios por haberme guiado en la culminación de una etapa más de mi vida, en

segundo lugar a cada uno de los que son parte de mi familia mi esposo Andrés, mi hija

Samantha que me han dado la fuerza para siempre querer superarme día con día sin decaer en

el camino, a mi PADRE Jaime Sampedro un ejemplo de constancia y responsabilidad, mi

MADRE María Chávez quien siempre ha estado presente en mi vida como apoyo

fundamental más que una madre una amiga y guía, a mis hermanos Paul y Daniel que son

ejemplo de superación y conocimiento a quienes siempre puedo recurrir cuando los necesito.

Por último, al Ing. Franz Del Pozo quien me dio el apoyo y guía para la culminación de este

proyecto.

Elizabeth M. Sampedro

vi

AUTORIZACIÒN DE LA AUTORÌA INTELECTUAL

Nosotros, Rubén Andrés Tubón Coichán y Elizabeth María Sampedro Chávez en

calidad de autor(es) del proyecto Integrador: SISTEMA DE GESTIÓN DE

PROCESOS ACADÉMICOS DE LA INSTITUCIÓN EDUCATIVA LA

COLINA, autorizamos a la Universidad Central del Ecuador hacer uso de todos los

contenidos que nos pertenecen o parte de los que contiene esta obra, con fines

estrictamente académicos o de investigación.

Los derechos que como autores nos corresponden, con excepción de la presente

autorización, seguirán vigentes a mi/nuestro favor, de conformidad con lo establecido

en los artículos 5, 6, 8; 19 y demás pertinentes de la Ley de Propiedad Intelectual y su

Reglamento.

Asimismo, autorizamos a la Universidad Central del Ecuador para que realice la

digitalización y publicación de este trabajo de investigación en el repositorio virtual,

de conformidad a lo dispuesto en el Art. 144 de la Ley Orgánica de Educación

Superior.

En la ciudad de Quito, a los 31 días del mes marzo de 2016.

Rubén Andrés Tubón Coichán

CC. 1720193711

[email protected]

Elizabeth María Sampedro Chávez

CC: 1721116729

[email protected]

Telf 0998436336 telf 0969010699

mailto:[email protected]

mailto:[email protected]

vii

CERTIFICACION DEL TUTOR

Yo FRANZ E. DEL POZO en calidad de Tutor del trabajo de titulación: SISTEMA

DE GESTIÓN DE PROCESOS ACADÉMICOS DE LA INSTITUCIÓN

EDUCATIVA LA COLINA, elaborado por los estudiantes: RUBEN A. TUBON y

la señora: ELIZABETH M. SAMPEDRO de la carrera de INGENIERIA

INFORMÁTICA, facultad de Ingeniería Ciencias Físicas y Matemática de la

Universidad Central del Ecuador, considero que el mismo reúne los requisitos y

méritos necesarios en el campo metodológico y en el campo epistemológico, para

ser sometido a la evaluación por parte del jurado examinador que se designe, por lo

que lo APRUEBO, a fin de que trabajo investigativo sea habilitado para continuar

con el proceso de titulación determinado por la Universidad Central del Ecuador.

En la ciudad de Quito, a los 31 días del mes de marzo del 2016

ING. FRANZ EDUARDO DEL POZO SÁNCHEZ

CC: 1712210630

viii

DESIGNACIÓN TRIBUNAL

ix

CALIFICACIÓN TRIBUNAL

x

CONTENIDO

DEDICATORIA .................................................................................................................................. II

DEDICATORIA ................................................................................................................................. III

AGRADECIMIENTOS.......................................................................................................................IV

AGRADECIMIENTOS........................................................................................................................V

AUTORIZACIÒN DE LA AUTORÌA INTELECTUAL .......................................................................VI

APROBACIÓN DEL TUTOR DEL TRABAJO DE TITULACIÓN...................................................... VII

INFORME DE LA CONCLUSIÓN DEL TRABAJO DE GRADUACIÓN ............................................ VII

CONTENIDO .................................................................................................................................. VIII

LISTA DE FIGURAS ....................................................................................................................... XIII

LISTA DE TABLAS ......................................................................................................................... XIV

RESUMEN........................................................................................................................................XV

ABSTRACT ..................................................................................................................................... XVI

CERTIFICADO DE TRADUCCIÓN RESUMEN AL INGLES .......................................................... XVII

INTRODUCCIÓN ............................................................................................................................... 1

Objetivos de la Investigación. ............................................................................................................................... 2

Objetivo General. ................................................................................................................................................... 2

Objetivos Específicos. ............................................................................................................................................ 2

Justificación. .......................................................................................................................................................... 2

Alcance. .................................................................................................................................................................. 3

CAPÍTULO 1 ...................................................................................................................................... 4

MÉTODO ........................................................................................................................................... 4

1. LENGUAJES DE PROGRAMACIÓN OPEN SOURCE .......................................................................................... 4

2. ARQUITECTURAS DE DISEÑO DE SOFTWARE ................................................................................................. 5

2.1. Arquitectura de Diseño en Capas .......................................................................................................... 5

2.2. Arquitectura Modelo Vista Controlador MVC ..................................................................................... 6

2.3. Arquitectura Orientada a Componentes ............................................................................................... 7

3. FRAMEWORK DE DESARROLLO .................................................................................................................... 10

4. TECNOLOGÍAS DE INFRAESTRUCTURA DE SOFTWARE DE DESPLIEGUE .................................................. 12

4.1. Sistemas Operativos .............................................................................................................................. 12

4.2. Servidor Web.......................................................................................................................................... 14

5. METODOLOGÍA RUP PARA LA IMPLEMENTACIÓN DEL SISTEMA .............................................................. 14

5.1. Fase de Inicio ........................................................................................................................................ 17 5.1.1. Análisis de Prerrequisitos. .................................................................................................................. 17 5.1.2. Descripción de la Fase de Inicio. ......................................................................................................... 18 5.1.3. Marco Administrativo......................................................................................................................... 19

5.1.3.1. Recursos Tecnológicos. ............................................................................................................... 19 5.1.3.2. Recursos Humanos. .................................................................................................................... 20 5.1.3.3. Presupuesto. ............................................................................................................................... 21 5.1.3.4. Cronograma................................................................................................................................ 22

5.2. Fase de Análisis ..................................................................................................................................... 22

5.2.1. Plan de Recolección de Datos. ............................................................................................................. 23

xi

5.2.1.1. Plan de Procesamiento de Datos. ................................................................................................ 23 5.2.1.1.1. Fines Específicos y Generales del istema. ................................................................................ 24

5.2.2. Funcionamiento y Rendimiento Requeridos Para el Sistema. ............................................................ 24 5.2.3. Diagramas de la Arquitectura Lógica del Sistema. ............................................................................ 28 5.2.4. Descripción de la Arquitectura Lógica del Sistema. ........................................................................... 29

5.2.4.1. Componentes del Framework Zope. ............................................................................................ 29 5.2.4.2. Servidor de Aplicaciones ZServer. ............................................................................................... 29 5.2.4.3. Nucleo del Framework Zope Core. .............................................................................................. 30 5.2.4.4. Base de Datos Orientada a Objetos ZODB (Zope Object Data Base). .......................................... 30

5.2.4.4.1. Atomicidad en las Transacciones............................................................................................. 32 5.2.4.4.2. Transacciones que Proporcionan Aislamiento. ........................................................................ 32 5.2.4.4.3. Almacenamiento en Capas Modulares. .................................................................................... 33 5.2.4.4.4. Facilidades Para Pruebas Unitarias........................................................................................ 33 5.2.4.4.5. Auditoría Forense. .................................................................................................................. 33 5.2.4.4.6. Manejo de Objetos Binarios. ................................................................................................... 33 5.2.4.4.7. ¿Cuándo se debe utilizar ZODB? ............................................................................................ 33

5.2.4.5. Integración con RDBMS............................................................................................................. 34 5.2.4.6. Extensiones del Núcleo Zope Products. ....................................................................................... 35

5.2.4.6.1. Componentes Personalizados Interfaces. ................................................................................. 35 5.2.4.6.2. Componentes Personalizados Adapters. .................................................................................. 35 5.2.4.6.3. Componentes Personalizados Utility. ...................................................................................... 35

5.2.4.7. Componentes Nativos ZClasses. .................................................................................................. 36 5.2.5. Modelo de Clases del Sistema. ............................................................................................................ 36

5.2.5.1. Diagramas de Clases del Sistema. ............................................................................................... 36 5.2.5.2. Descripción de las Clases y Componentes del Sistema. ................................................................ 36

5.2.5.2.1. Acceso Inicio del Sistema. ....................................................................................................... 36 5.2.5.2.2. Componentes Generales de Diálogos....................................................................................... 36 5.2.5.2.3. Componentes Genéricos Para Funcionalidades Básicas. ......................................................... 36 5.2.5.2.4. Componentes de Presentación View Web. ................................................................................ 37

5.2.6. Modelo de Casos de Uso del Sistema................................................................................................... 37 5.2.6.1. Diagramas de Secuencia y Flujos de Trabajo del Sistema. .......................................................... 37 5.2.6.2. Descripción de los Diagramas de Secuencia y Flujos de Trabajo del Sistema. ............................. 37

5.2.6.2.1. Estructura del Documento de Casos de Uso del Sistema. ......................................................... 37 5.2.6.3. Interfaz de Usuario del Sistema................................................................................................... 38 5.2.6.4. Diagramas de Navegación del Sistema. ....................................................................................... 38

5.2.7. Catálogo de Controles y Elementos de Diseño. ................................................................................... 39 5.2.7.1. Componentes de Presentación Vistas .......................................................................................... 39 5.2.7.2. Componentes de Presentación Zope Page Templates................................................................... 40 5.2.7.3. Componentes de Presentación Template Attribute Language (TAL)............................................ 40 5.2.7.4. Comandos TAL ........................................................................................................................... 40 5.2.7.4.1. Define. ........................................................................................................................................ 40 5.2.7.4.2. Condition. ................................................................................................................................... 41 5.2.7.4.3. Repeat......................................................................................................................................... 41 5.2.7.4.4. Content. ...................................................................................................................................... 42 5.2.7.4.5. Replace. ...................................................................................................................................... 42 5.2.7.4.6. Attributes. ................................................................................................................................... 42 5.2.7.4.7. Omit-tag ..................................................................................................................................... 43 5.2.7.5. Orden semántico de operaciones y etiquetas TAL ........................................................................ 43 5.2.7.6. Macro Extensión Tal Attribute Language (METAL) ................................................................... 44 5.2.7.7. Recursos estáticos para las vistas. ............................................................................................... 44 5.2.7.8. Definición de excepciones. .......................................................................................................... 44

5.2.8. Información Sobre Trazabilidad. ....................................................................................................... 45 5.3. Fase de Diseño....................................................................................................................................... 46

5.3.1. Diagrama de Base de Datos ZODB. .................................................................................................... 47 5.4. Fase de Construcción ........................................................................................................................... 48

xii

5.4.1. Descripción del Entorno Tecnológico. ................................................................................................ 48 5.4.1.1. Hardware Adecuado en Despliegues a Producción...................................................................... 49 5.4.1.2. Tecnologías de Infraestructura Para Despliegues en Producción. ............................................... 49 5.4.1.3. Sistema Operativo Adecuado en Despliegues a Producción. ........................................................ 49 5.4.1.4. Software Base de Aplicaciones Zope Web Application Server. ..................................................... 50 5.4.1.5. Software Base de Persistencia ZODB y Redis. ............................................................................. 51 5.4.1.6. Software Base de Soporte a Reportes Celery................................................................................ 52 5.4.1.7. Software Base de Procesamiento de Imágenes Pillow .................................................................. 52 5.4.1.8. Software Base de Cumplimiento Pytz .......................................................................................... 52 5.4.1.9. Software Base de Reportes ReportLab ......................................................................................... 53 5.4.1.10. Software Base de Soporte a MS Excel Xlrd y Xlwt....................................................................... 53 5.4.1.11. Estructura Básica de Comunicaciones. ....................................................................................... 53 5.4.1.12. Restricciones Técnicas en Despliegues a Producción. ................................................................. 54

5.4.2. Definición Interfaz de Usuario del Sistema......................................................................................... 55 5.5. Fase de Pruebas..................................................................................................................................... 56

5.6. Fase de Cierre ........................................................................................................................................ 57

CAPÍTULO 2 .................................................................................................................................... 58

RESULTADOS ................................................................................................................................. 58

CAPÍTULO 3 .................................................................................................................................... 62

DISCUSIÓN...................................................................................................................................... 62

BIBLIOGRAFIA ...................................................................................................................................................... 64

ANEXOS .......................................................................................................................................... 67

xiii

LISTA DE FIGURAS

FIGURA 1. ARQUITECTURA EN CAPAS ............................................................................................................................ 6

FIGURA 2. ARQUITECTURA MVC ................................................................................................................................... 7

FIGURA 3. ARQUITECTURA ORIENTADA A COMPONENTES............................................................................................ 8

FIGURA 4. FRAMEWORK ZOPE 3.................................................................................................................................... 10

FIGURA 5. ESFUERZO – FASES DEL PROYECTO............................................................................................................. 20

FIGURA 6. ARQUITECTURA LÓGICA DEL SISTEMA ....................................................................................................... 29

FIGURA 7. DISEÑO DE NAVEGACIÓN DEL SISTEMA...................................................................................................... 38

FIGURA 8. DIAGRAMA DE COMPONENTES DEL SISTEMA ............................................................................................. 46

FIGURA 9. UBUNTU SERVER 14.04................................................................................................................................ 50

FIGURA 11. DIAGRAMA DE RED DEL SISTEMA. ............................................................................................................ 53

FIGURA 10. DIAGRAMA DE DESPLIEGUE DEL SISTEMA................................................................................................ 54

FIGURA 12. MONITOREO DE ESFUERZOS DE HITOS DEL PROYECTO ........................................................................... 60

FIGURA 13. MONITOREO EN TIEMPO DEL PROYECTO .................................................................................................. 61

FIGURA 14. EVIDENCIA DE APROBACIÓN DE PLAN DE TESIS. ..................................................................................... 67

FIGURA 15. EVIDENCIA DE TABLA OFICIAL DE PLANES DEL PROYECTO INTEGRADOR APROBADO. ........................ 67

FIGURA 16. DIAGRAMA DE CLASES DEL SISTEMA. ...................................................................................................... 69

FIGURA 17. CASOS DE USO, CONFIGURACIÓN DE SEGURIDAD.................................................................................... 70

FIGURA 18.CASOS DE USO, EMPAQUETAMIENTO DE BASE DE DATOS. ...................................................................... 71

FIGURA 19. CASOS DE USO, PARAMETRIZACIÓN DE AÑOS ESCOLARES. .................................................................... 71

FIGURA 20. CASOS DE USO, PARAMETRIZACIÓN DE AÑOS ESCOLARES. .................................................................... 72

FIGURA 21. CASOS DE USO, CREACIÓN DE USUARIOS................................................................................................. 72

FIGURA 22. CASOS DE USO, MODIFICACIÓN DE USUARIOS. ........................................................................................ 73

FIGURA 23. CASOS DE USO, ELIMINAR USUARIOS. ...................................................................................................... 74

FIGURA 24. CASOS DE USO, CREAR CONTACTOS......................................................................................................... 74

FIGURA 25. CASOS DE USO, MODIFICAR CONTACTOS. ................................................................................................ 75

FIGURA 26. CASOS DE USO, ELIMINAR CONTACTOS. .................................................................................................. 76

FIGURA 27. CASOS DE USO, PARAMETRIZACIÓN DE ASIGNATURAS. .......................................................................... 76

FIGURA 28. CASOS DE USO, MODIFICACIÓN DE ASIGNATURAS. ................................................................................. 76

FIGURA 29. CASOS DE USO, ELIMINAR ASIGNATURAS. ............................................................................................... 77

FIGURA 30. CASOS DE USO, INGRESO DE HORARIOS. .................................................................................................. 77

FIGURA 31. CASOS DE USO, MODIFICAR HORARIOS. ................................................................................................... 78

FIGURA 32. CASOS DE USO, ELIMINAR HORARIOS. ..................................................................................................... 78

FIGURA 33. CASOS DE USO, ASIGNACIÓN HORARIOS Y ASIGNATURAS...................................................................... 79

FIGURA 34. CASOS DE USO, ASIGNACIONES HORARIO Y PROFESOR. ......................................................................... 79

FIGURA 35. CASOS DE USO, ASIGNACIÓN HORIARIOS Y ESTUDIANTES...................................................................... 80

FIGURA 36. CASOS DE USO, REGISTRO DE CALIFICACIONES....................................................................................... 80

FIGURA 37. CASOS DE USO, INGRESO DE ACTIVIDADES CURRICULARES. .................................................................. 81

FIGURA 38. CASOS DE USO, CONTROL DE ASISTENCIA DE ESTUDIANTES. ................................................................. 81

FIGURA 39. DIAGRAMA DE SECUENCIA, CONFIGURACIONES DE SEGURIDAD DEL SISTEMA. .................................... 82

FIGURA 40. DIGRAMA DE SECUENCIA, EMPAQUETAR BASE DE DATOS. .................................................................... 83

FIGURA 41. DIAGRAMA DE SECUENCIA, INGRESO DE ASIGNATURAS. ........................................................................ 83

FIGURA 42. DIAGRAMA DE SECUENCIA, MODIFICAR ASIGNATURAS.......................................................................... 84

FIGURA 43. DIAGRAMA DE SECUENCIA, ELIMINAR ASIGNATURA. ............................................................................. 85

FIGURA 44. DIAGRAMA DE SECUENCIA, INGRESAR ACTIVIDADES CURRICULARES................................................... 86

FIGURA 45. DIAGRAMA DE SECUENCIA, CREAR AÑOS ESCOLARES. .......................................................................... 87

FIGURA 46. DIAGRAMA DE SECUENCIA, CREAR PERIODOS ESCOLARES. ................................................................... 88

FIGURA 47. DIAGRAMA DE SECUENCIA, REGISTRO DE CALIFICACIONES. .................................................................. 89

FIGURA 48. DIAGRAMA DE SECUENCIA, CONTROL DE ASISTENCIA............................................................................ 90

xiv

LISTA DE TABLAS

TABLA 1. FASES DEL PROYECTO SUJETO A RUP .......................................................................................................... 15

TABLA 2. PRESUPUESTO ESTIMACIÓN INICIAL ............................................................................................................. 19

TABLA 3. PRESUPUESTO GLOBAL DEL PROYECTO ....................................................................................................... 21

TABLA 4.FORMATO DE ENTREVISTAS........................................................................................................................... 23

TABLA 5. REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES ................................................................................ 24

TABLA 6. RESUMEN DE MÉTRICAS DEL PROYECTO ..................................................................................................... 58

TABLA 7. HITOS DEL PROYECTO ................................................................................................................................... 59

TABLA 8. MONITOREO DE HITOS DEL PROYECTO ........................................................................................................ 59

TABLA 9. DESVIACIÓN DE HITOS DEL PROYECTO ........................................................................................................ 60

TABLA 10. ENCABEZADO PRINCIPAL DEL CONTROL DE DOCUMENTACIÓN. .............................................................. 68

TABLA 11. TABLA DE DETALLES DEL CONTROL DE DOCUMENTACIÓN...................................................................... 68

TABLA 12. TABLA DE REVISORES DEL CONTROL DE DOCUMENTACIÓN .................................................................... 68

TABLA 14. MATRIZ DE TRAZABILIDAD – GUION DE PRUEBAS. ................................................................................... 92

xv

RESUMEN

SISTEMA DE GESTIÓN DE PROCESOS ACADÉMICOS DE LA UNIDAD

EDUCATIVA “LA COLINA”

Autores: Rubén Andrés Tubón Coichán


Tutor: Franz Eduardo Del Pozo Sánchez

La escuela de la ciudad de Ibarra tiene el objetivo de solucionar sus requerimientos de

procesos de gestión académica, sustentándose en la tecnología con licenciamiento gratuito. El

soporte para automatizar este requerimiento lo ha buscado en la Universidad Central para lo

cual se implementó el Sistema de Gestión de Procesos Académicos que está basado en

tecnologías de código abierto. De esta forma el instituto cubre sus necesidades para

automatizar procesos que por el momento se realizan de forma artesanal y algunos procesos

se encuentran automatizadas, pero con herramientas de pago.

Los componentes que soportan la presentación del aplicativo se sustentará en

tecnologías web elaboradas de acuerdo a esquemas y requerimientos funcionales.

Para el diseño y codificación de la persistencia se utilizarán bases de datos nativas del

lenguaje de programación, conforme a las mejores prácticas dictadas por el marco de

desarrollo para Python.

PALABRAS CLAVE: SISTEMAS ACADÉMICOS/TECNOLOGIAS WEB/SOFTWARE

LICENCIAMIENTO GRATUITO/GESTIÓN PROCESOS ACADEMICOS/ /UNIDAD

EDUCATIVA “LA COLINA”/PHYTON

xvi

ABSTRACT

SYSTEM OF ACADEMIC PROCESS MANAGEMENT FROM THE EDUCATIONAL

INSTITUTE “LA COLINA”

Authors: Rubén Andrés Tubón Coichán


Tutor: Franz Eduardo Del Pozo Sánchez

The Ibarra´s school aims to solve its requeriments of the academic process

management, premised on the free licensing technology. The support to automate this

requeriment has been searched of the Central University for witch it was implemented the

system of academic processes management based on open source technologies. Thus the

institute meets its needs to automate processes that are performed of a traditional way and

some processes are automated but with payment tools.

The components that support the presentation of the application will be based on web

technologies developed according to schemes and functional requirements

For the design and coding of the persistence will be used native data bases from

programming language in accordance with the best practices dictated by the development

framework for Phyton.

KEYWORDS: ACADEMIC SYSTEMS/ WEB TECHNOLOGIES/SOFTWARE

LICENSING FREE /GESTIÓN PROCESS MANAGEMENT ACADEMIC/

/EDUCATIONAL INSTITUTE “LA COLINA”/PHYTON

I CERTIFY that the above and foregoing is a true and correct translation of the original

document in Spanish

xvii

CERTIFICADO DE TRADUCCIÓN RESUMEN AL INGLES

SISTEMA DE GESTIÓN DE PROCESOS ACADÉMICOS 1

Introducción

La necesidad de contar con un sistema de información relativamente con bajo o un

costo nulo, para automatizar los procesos de los actores que intervienen en la educación de la

Unidad Educativa “La Colina”.

La Unidad Educativa “La Colina” considera al sistema indispensable para facilitar un

nuevo conjunto de servicios de mejora para las diferentes variantes del sistema educativo.

Analizar los elementos que integran los diferentes subsistemas del aplicativo, para que, en

base a la elaboración de un modelo adecuado, se implemente el sistema de información en la

institución.

El valor de este proyecto radica en la necesidad del sistema en la institución, ya que por

varios años se ha mantenido el sistema incompleto. Los primeros sistemas informáticos

orientados a la educación comenzaron con el desarrollo de sistemas de educación básicos de

recuperación de información residentes actualmente en la institución, para ayudar a los

profesores en la elaboración de documentos de trabajo, para validar notas, asistencia, etc.

Aunque estos sistemas no se desarrollaron en comprender la complejidad de modalidades de

la educación del futuro, ahora las investigaciones y aplicaciones en el área continúan siendo

cada vez más sofisticadas, para que las implementaciones de las necesidades en diferentes

instituciones lleven a sus estudiantes a vivir sin complicaciones en un mundo globalizado.

Es importante recalcar que la solución que se han propuesto anteriormente requería

software propietario. Esto ocasionaba un coste alto en todas las fases del proyecto, el costo del

proyecto es una limitante para el proyecto ya que la Unidad Educativa no cuenta con fondos

para implementar soluciones de pago.

La investigación presente documento se fundamenta en el desarrollo de aplicaciones en

tecnologías de código abierto y de libre uso, sujeto a metodologías RUP. La metodología

recomienda pasar por diferentes fases que soportarán la construcción del sistema.


Inicialmente los componentes del plan propuestos, se establecen los siguientes ítems

fundamentales para la implementación del sistema de información:

Objetivos de la Investigación.

Objetivo General.

Construir un sistema de información orientado a la gestión de procesos académico,

cuya finalidad es brindar soporte a la unidad educativa en la gestión y automatización de los

procesos que se realizan de forma manual, mediante el uso de una interfaz para aplicar toda la

investigación con herramientas informáticas de código abierto.

Objetivos Específicos.

Diagramar definiciones de arquitectura del sistema de gestión de procesos académicos

conforme las necesidades de la Unidad Educativa.

Implementar las definiciones lógicas y arquitectónicas del sistema de información en

la institución.

Sujetarse a los lineamientos de instituciones educativas conforme la disposición del

gobierno ecuatoriano.

Justificación.

Se han manifestado argumentaciones a favor del desarrollo de sistemas de gestión

educativa para los diferentes entornos vigentes en el Ecuador y sus variantes, para fomentar el

desarrollo de alternativas de éxito para los estudiantes del Ecuador. Sin embargo, en la

institución no existe el soporte suficiente de sistemas que ayudan en la automatización en

diferentes procesos de la unidad educativa que aportan en la gestión de la educación, la

implementación para automatizar procesos está basado en tecnologías para implementar

nuevos paradigmas de sistemas de información educativos actuales. Las definiciones de

implementaciones para la gestión de la educación tanto para profesores, estudiantes y padres


de familia actores de la educación se ven afectados cuando optan acoplarse a sistematizar los

diferentes procesos establecidos en la unidad educativa. Actualmente existen problemas con

estos procesos, pues no existe un sistema que transmita confiabilidad en el flujo del proceso.

No existe la plataforma que soporte de forma óptima el proceso en la institución, los

stakeholders intervinientes en el proceso se ven perjudicados por no poseer un sistema que

brinde soporte requerido para las nuevas implementaciones u ofertas académicas en el

Ecuador.

Alcance.

La solución global contempla la implementación de un sistema gestión de procesos

académicos en la Unidad Educativa “La Colina” de la ciudad de Ibarra.


Capítulo 1

Método

Para realizar el presente proyecto interviene el conocimiento de implementaciones de

un sistema informático sujeto a metodologías y buenas prácticas, con la formulación y

solución consistente sustentada en un diseño adecuado En consecuencia es necesario

desplegar una investigación de las diferentes disciplinas que intervienen en el desarrollo de

este sistema de información:

1. Lenguajes de Programación Open Source

Python es una tecnología open source de libre uso, sus raíces se fundamentan en un

leguaje ABC del cual se dice ser el sucesor, este leguaje en su tiempo fue una alternativa a

BASIC. Python es un lenguaje de programación tiene una gran ventaja de ser multipropósito,

es decir dentro de sus roles sirve para seguir un paradigma de programación orientado a

objetos, de manera resumida es un lenguaje de programación interpretado, lo que implica que

es multiplataforma para desarrollo de aplicaciones en varios campos y lo que nos interesa en

el presente trabajo las aplicaciones Web. Ahora todos los lenguajes de programación

compilados empaquetan su código para que sea ejecutado en máquinas virtuales, producen

lenguaje intermedio que en , es el

lenguaje que entiende su compilador lo traduce en código nativo comprensivo para las

diferentes plataformas, similar a estos tipos de lenguajes de programación, Python es un

lenguaje de programación que puede ser transformado en bytecode que es una especie de

lenguaje parcialmente interpretado, es decir se puede ejecutar estos archivos indefinidamente,

conforme lo requiera el programador o librerías existentes. Finalmente se encarga de gestionar

la ejecución de las aplicaciones en varias plataformas donde exista el intérprete de python.

La integración de lenguajes que ejecutan sus aplicativos en el CLR o JVM puede realizarse

mediante variantes de Python como Jython para Java e Iron Python para .Net. Python maneja


excepciones en la ejecución de los programas, se encarga de la seguridad garantizando los

permisos segregados para la ejecución de código, la recolección de basura en sus últimas

versiones y el soporte de la ejecución de un programa en varios hilos que es una característica

de los lenguajes de programación modernos.

Para comprender el modelo en el que se basa el presente trabajo es necesario conocer y

desarrollar los módulos de código orientado a componentes, son conocidos como código semi

interpretado y librerías de enlace con peso extremadamente liviano en comparación con .Net y

Java, el intérprete y empaquetador suele agregar automáticamente en estos módulos de código

interpretado.

2. Arquitecturas de Diseño de Software

Existen patrones de diseño que facilitan la construcción de software, el modelo en

capas es un esquema que resume el sistema en n capas que requiera un sistema. Modelos de

construcción de software como Modelo Vista Controlador MVC resumen un sistema en tres

roles proporcionando un alto rendimiento, escalabilidad y mejora el mantenimiento. Existe

una arquitectura llamada Basada en Componentes que es la base tanto de MVC y diseño en

Capas. Los esquemas de las arquitecturas para Python utilizan varias tecnologías para cumplir

con estos patrones de diseño.

2.1. Arquitectura de Diseño en Capas

El modelo en capas separa el diseño de la aplicación fundamentalmente en varias

responsabilidades. La capa de presentación que es el conjunto de interfaces que permiten

administrar o gestionar los datos conforme los formularios creados. La capa de negocio en

términos simples es un conjunto de abstracciones de las reglas de negocio y su esquema

generalmente se sujeta a una base de datos. La capa de acceso a datos que se encarga de la

interacción lógica entre las peticiones de la capa de presentación y la interacción con la capa

de negocio, de tal forma que la comunicación es de forma bidireccional entre capas contiguas


esto puede ser fácilmente implementado con Tryton que es una plataforma para desarrollar

este tipo de aplicaciones con este paradigma.

Figura 1. Arquitectura en Capas

Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina”

Nombre: Diagrama de Componentes del Sistema

Versión: 1.0

Autor(es): Rubén A. Tubón y Elizabeth M. Sampedro

2.2. Arquitectura Modelo Vista Controlador MVC

MVC es una arquitectura que discierne roles fundamentalmente en tres

responsabilidades. La capa de modelo que simplemente es el repositorio y sus respectivos

Ajax

Componentes

Componentes Persistentes Python & Redis

Archivo de Configuración

Base de Datos

PostgreSQL

Back End

Capa de Datos

Capa de Negocio

Capa de Presentación

Vistas Tryton

Clases y objetos Python


controles de excepciones, la vista que es referente al front end del aplicativo, finalmente se

tiene el controlador que es el orquestador que permiten administrar o gestionar los datos

conforme los formularios creados. Para las tecnologías Python existen una variedad de

herramientas para implementar este paradigma como modelo para el sistema en construcción.

Figura 2. Arquitectura MVC


Nombre: Patrón de Diseño Modelo-Vista-Controlador

Versión: 1.0


2.3. Arquitectura Orientada a Componentes

El paradigma de la Arquitectura Orientada a componentes fue en su tiempo la base

para diferentes patrones de programación. En la actualidad existe en la red diferentes

componentes con especificaciones variadas, son de libre uso y también componentes

propietarios de pago que estructura la forma de desarrollar, utilizar y distribuir componentes.

Este paradigma de componentes tiene amplia acogida en construcción de sistemas de

información.

Controlador

Modelo

Vista


La definición de los componentes puede resumirse en que es un paquete o modulo

totalmente encapsulado que proporciona funcionalidad robusta y altamente testeados para

garantizar su funcionamiento.

La comunicación entre componentes se implementa mediante interfaces, en estas interfaces se

definen los métodos que una solución puede requerir, la relación establecida por las interfaces

es de manera semántica de tal forma que cada componente forma parte de un sistema

consistente.

La característica de esta arquitectura es obtener un máximo beneficio del nivel de

reutilización, la minimización del desarrollo de nuevos componentes. Para el desarrollo de

este paradigma se puede utilizar herramientas para Python como Zope.

Figura 3. Arquitectura Orientada a Componentes




Nombre: Patrón de Diseño Orientado a Componentes

Versión: 1.0


Componente 0

Interfaz de ensamblaje

Componente con

funcionalidad

Interfaz integración

Componente con

funcionalidad


Componente con

funcionalidadInterfaz integración

Componente con

funcionalidad


Componente con

funcionalidad

Ahora es necesario verificar las métricas el uso de este paradigma, para lo cual se ha

investigado medidas para el uso de componentes en los desarrollos de software. Es necesario

resaltar que el uso de componentes se encuentra orientado a facilitar el acoplamiento y el ágil

desarrollo para ensamblar un producto final con especificaciones funcionales acordes al

requerimiento del cliente y de alta calidad, es decir el trabajo de ensamblar e identificar los

componentes adecuados para satisfacer los requerimientos del cliente. Finalmente, no existen

modelos estandarizados para el apoyo en el asesoramiento de la elección de los componentes


para medir la calidad de su funcionalidad y rendimiento. Sin embargo, puede tomarse en

cuenta un modelo genérico para el cumplimiento de la calidad del software como la ISO/IEC

9126, que simplemente es un estándar genérico para validar, valorar el rendimiento y calidad

del software, en el presente trabajo se utilizarán las pautas de este estándar para evaluar la

selección de componentes o los marcos de desarrollo. Para concluir la idea es necesario

recalcar que para la selección de los componentes o los marcos de desarrollo se necesitará

validar su funcionalidad, fiabilidad, usabilidad, eficiencia, mantenimiento del código,

portabilidad y calidad de uso que son parte del estándar escogido.

3. Framework de Desarrollo

Figura 4. Framework Zope 3

Fuente: Zope. (2013). Zope. 2016, de página de inicio del portal Sitio web: http://zope.org/

El framework de desarrollo es una herramienta que permite la construcción de

software en referencia a mejores prácticas, de tal forma que permite llevar una construcción

sujeta a la correcta segregación de código en componentes específicos, gestiona errores en

tiempo real, integra bibliotecas externas para agregar funcionalidades en desarrollos

particulares, para llevar un correcto control de cambio el framework puede tener integración

con sistemas de control de versiones. Adicionalmente este framework contiene varios

componentes de código abierto y es soportado por una comunidad de desarrolladores de

Europa y Estados Unidos, el framework es una herramienta ideal para la implementación de

construcción de software en forma colaborativa es decir al soportar la Arquitectura Orientada

a Componentes, el grupo puede dividirse en equipos de desarrollo segregados para ejecutar

desarrollos de componentes específicos. Todos los módulos de Zope 3 se encuentran

completamente separados y totalmente aislados para que los métodos de un componente

puedan ser utilizados parcialmente o en su totalidad. Facilita el testeo de los desarrollos para


asegurar la calidad del software funcionalmente y pruebas de carga transaccional. Zope 3 es

multiplataforma y adaptable con diferentes sistemas operativos incluido Windows y MacOS.

El Framework tiene un gestor de persistencia particular ZODB que en síntesis no se

sujeta a los paradigmas de motores de bases de datos relacionales que generalmente son

tradicionales en otros framework, ZODB es un motor que maneja la persistencia con

paradigmas orientados a objetos. Para soportar implementaciones basadas en la web Zope

tiene componentes de gestión y validación para formularios. Otra característica es el ZPT

Zope Page Templates, que son XML bien formados y pueden ser invocados desde un paquete

que especifica métodos para el uso de este tipo de características en diferentes tipos de

desarrollos para Python.

En función a las características enunciadas anteriormente el framework que cumple

con las necesidades del proyecto es Zope 3. Es un framework desarrollado por una comunidad

libre y con amplio soporte, ya que se encuentra en su tercera versión. Se basa en Python y

utiliza este lenguaje de programación con variantes mínimas en librerías adaptadas para el fin

de este framework.

El entorno de desarrollo es ahora más que un simple editor de código. Un entorno de

desarrollo orientado a componentes debe facilitar la instalación de componentes y su

configuración e integración en una aplicación. El código fuente adicional necesario es

mínimo.

Zope 3 ha sido probado intensivamente, de tal forma que es robusto, comprobando en

todos los aspectos y es transparente a nivel de validez de las entradas que requieran consumo

de servicios. Es capaz de pasar mensajes de error apropiados entre componentes. Posee

protocolos que garantizan la interoperabilidad entre componentes internos y externos al

Framework


Los beneficios de utilizar como entorno para el desarrollo del presente trabajo es la

facilidad de construir software de forma sencilla y en un tiempo considerablemente mínimo,

al tener complejidad baja en la construcción y tiempos mínimos en la construcción los

desarrollos de proyectos en Zope 3 son relativamente baratos en comparación con otros

framework.

En resumen, las características del framework se describe que la unidad o paquete o

componente es reutilizable para diferentes desarrollos esto gracias al paradina de la

arquitectura. Es distribuible multiplataforma sin dependencias que aten al uso de plataformas

específicas. Las implementaciones en diferentes leguajes de programación para diferentes

lenguajes. Los componentes se encuentran desarrollados por proveedores con alta capacidad

en el campo de desarrollo. Las implementaciones para la reutilización son proveídas y

consumidas mediante definiciones de interfaces y el efecto de serializar los objetos y tramas

conforme a las buenas prácticas de programación.

Zope 3 usa el paradigma de Arquitectura Basada en Componentes es el indicado para

solucionar los requerimientos establecidos para la Unidad Educativa “La Colina”, de esta

manera se presenta los siguientes esquemas que en cierta manera representan el sistema a

plasmar y sus diferentes tecnologías

4. Tecnologías de Infraestructura de Software de Despliegue

Las tecnologías de despliegue que requiere la aplicación se encuentra basada en

software de código abierto, ligado a su patrón de desarrollo y a su framework Zope 3.

4.1. Sistemas Operativos

El sistema operativo para las aplicaciones generadas y ensambladas en Zope 3 es

independiente de la plataforma, es decir podemos escoger un sistema operativo propietario de

pago como un sistema operativo Open Source. Para fundamentar el uso de un sistema

operativo es necesario evaluar su potencia y funcionalidad para los diferentes fines que tienen


las instituciones sin embargo en el presente existen varios sistemas operativos que son

multipropósito, es decir pueden desempeñar un alto rendimiento en varios campos: bancarios,

agrícolas, industriales, etc. Ahora es imprescindible validar el tiempo que lleva en el mercado

y el soporte del fabricante. Las pautas que deben ser analizadas son: la fiabilidad,

rendimiento, seguridad, controlador de dispositivos, aplicaciones y costo del sistema y

propiedad.

Windows Server es una alternativa interesante en sus versiones 2012 ya que cuenta

con un amplio soporte y tiene mejoras en sus nuevas variantes (Service Pack) que pueden ser

promovidas por upgrades, el inconveniente de este tipo de tecnologías es simplemente el

licenciamiento ya que se encuentra licenciado bajo las políticas de Microsoft. Su arquitectura

está orientada para implementaciones de servicios distribuidos, su arquitectura es robusta para

la implementación como un servidor de aplicaciones, servidor de dominio, servidor de

impresiones, etc.

Ubuntu es una alternativa con beneficios múltiples sobre sus competidores desde el

lanzamiento de sus versiones para sistemas operativos actualmente se encuentra en versiones

16.x sin embargo la recomendación de varios fabricantes de sistemas operativos y las buenas

prácticas es recomendable implementar soluciones de sistemas operativos que al menos lleven

un año en el mercado, es decir con esta premisa se estará garantizando el soporte para los

sistemas operativos. En el presente trabajo se analizará el sistema operativo Ubuntu Server

14.04 que es una distribución de libre uso bajo licenciamiento GPL y cuenta con soporte hasta

el 2019 a nivel de actualizaciones en sus paquetes y kernel.

Al igual que sus competidores Ubuntu Server no tiene ningún argumento para no

asumir roles como un servidor de aplicaciones, servidores de base de datos, servidores de

archivos, u otras diferentes funciones, incluso varios roles en un solo servidor. La

infraestructura no tiene porqué ser complejas y potentes máquinas, ya que los requerimientos


de este tipo de sistemas operativos a nivel de recursos de hardware no son de alto nivel ni

exigen infraestructura con tecnología de punta.

Ubuntu Server es un sistema operativo sin entorno gráfico sin embargo puede ser

instalado con el riesgo de la degradación en su rendimiento, lo que quiere decir, en resumen,

todas las acciones de administración e implementaciones se ejecutan mediante consola, ya que

normalmente la administración de los servidores en general se ejecuta mediante una conexión

remota.

4.2. Servidor Web.

El servidor web sobre el cual se desplegará la aplicación es un nativo de Zope 3 para

que el tiempo de implementación sea considerablemente bajo y no depender de una

instalación a la adicional y ahorrarse los problemas técnicos de mantenimiento con el servidor

web de otros fabricantes. Es importante recalcar que existen servidores para tecnologías web

que soportan e implementan módulos para Python como Apache y Tomcat que sirven para

nuestro propósito, sin embargo, no son nativos de Python, esta premisa de implementar el

producto con diferentes proveedores de servidores web, establece un esfuerzo adicional en las

fases propuestas por la metodología escogida para la implementación del sistema de

información.

Para el software relativamente es nulo sin embargo siempre es necesario contar con

soporte y sus respectivas suscripciones en el apartado Administrativo del proyecto.

5. Metodología RUP para la implementación del sistema

Es una metodología sujeta a buenas prácticas de desarrollo de software, donde

intervienen iteraciones para realizar un afinamiento en cada etapa, de esta manera la

metodología nos indica los lineamientos a seguir, a definir hitos y fases en el desarrollo, estas

fases brevemente se detallan a continuación:


Tabla 1. Fases del Proyecto sujeto a RUP

N° Fase Detalle

1

Inicio

En esta fase se inicia con una estimación inicial del

proyecto, una planificación inicial, donde se plasman un

plan de trabajo, el mismo debe ser aprobado por un ente

controlador, en este caso el ente controlador es la

Universidad Central del Ecuador. Este documento se

encuentra en el Anexo 1.

2

Análisis

En la fase de análisis se determinarán las especificaciones

funcionales y una matriz de trazabilidad, las

especificaciones y la matriz son las ideas de

funcionamiento conforme las necesidades del instituto.

3

Diseño

Para esta fase se aterrizarán las definiciones de las

especificaciones funcionales en diagramas UML en alto y

bajo nivel para definir una arquitectura adecuada. En esta

fase se debe mapear una forma de ejecutar pruebas

funcionales y pruebas técnicas, ya que conforme la

metodología en esta fase deben planificarse afinamientos

en base a iteraciones. Adicionalmente se debe actualizar

las matrices de requerimientos y trazabilidad, esto

impactará seguramente al Gantt del proyecto.

4

Construcción

En este punto se elaboran los guiones que probarán las

especificaciones funcionales, adicionalmente el

desarrollador debe ejecutar pruebas unitarias que verifique

el cumplimiento de los requerimientos levantados. Para

esta fase se requiere levantar un ambiente para probar

todas las especificaciones funcionales, en estos puntos será

fundamental la herramienta de la matriz de trazabilidad

para cubrir los requerimientos del negocio.

Es necesario realizar pruebas de carga y de estrés del


N° Fase Detalle

sistema para certificar el volumen de transacciones en

ambiente productivo.

Es crítico realizar una matriz de defectos ya que la

metodología conlleva a validar con el negocio los riesgos

en cada etapa. Este punto obligatoriamente impactará la

matriz de trazabilidad. Consecuentemente se registran y

documenta los errores de prueba para elevar

requerimientos de solución al desarrollador.

Mediante iteraciones se realizarán las mejoras y cambio de

configuraciones pertinentes.

5

Pruebas

Esta fase demanda la ejecución de pruebas en un ambiente

de test, que garantice un ambiente análogo al ambiente de

producción. Luego de una ejecución del recurso que

ejecuta las pruebas, se realiza los ajustes necesarios.

Subsecuentemente se realizarán las pruebas del sistema por

el usuario experto. En este punto se relevarán el análisis

causal en caso de existir errores en el sistema. Finalmente

en caso que aplicara, es necesario capacitar a los usuarios

técnicos que den soporte a las herramientas del instituto.

6

Publicación

Este hito debe tener insumos como la validación de paso a

producción del desarrollo, por parte de los recursos que

prueban el aplicativo y el personal que representa al

negocio.

Finalmente es necesario coordinar con los administradores

de la plataforma con la que interactúe el sistema, para el

despliegue del desarrollo mediante un documento que

detalle:

Prerrequisitos.

Backup de sistemas y configuraciones de ambientes

productivos.


N° Fase Detalle

Pasos detallados del despliegue.

Plan de rollback.

Todos estos pasos son esenciales para garantizar un

correcto despliegue y una recuperación efectiva de

configuraciones en caso de fallos inesperados. En caso de

evidenciarse fallos leves relacionados con el desarrollo, es

necesario solucionarlos en ambiente no productivo y seguir

el ciclo apegado a la metodología.

Para eventualidades no previstas en caso de errores se debe

ejecutar un análisis causal. Finalmente se debe determinar

los riesgos de esta fase.

7

Cierre

Se debe entregar el sistema en producción a las áreas de

soporte. Programar en agenda las reuniones para obtener

un acta de finalización con la entrega de documentación

del sistema. Finalmente se debe asegurar la destrucción de

la información relacionada al proyecto, en todos los

medios magnéticos de almacenamiento.

5.1. Fase de Inicio

5.1.1. Análisis de Prerrequisitos.

Como un habilitante imprescindible es necesario contar con la aprobación del plan del

Proyecto Integrador que es una especie de contrato aprobado entre los estudiantes que

desarrollan el Proyecto Integrador y el director de la escuela de Ingeniería Informática de la

Facultad de Ingeniería Ciencias Físicas y Matemática de la Universidad Central del Ecuador

para continuar con la ejecución del proyecto. Este habilitante se encuentra en el apartado

“Anexos” del presente documento como Anexo 1.

Continuando con los requisitos para poder construir adecuadamente esta fase es

necesario validar la estimación de forma temprana en el proyecto, revisada y aprobada por el


Director de la tesis y el Director de la carrera de la Facultad, este punto está constituido en el

plan de tesis, en el apartado “Anexos” del presente documento como Anexo 1. Este

documento asegura que las definiciones y el alcance del proyecto se encuentren concisos y

acordados formalmente por los actores que intervienen en la aprobación del documento.

5.1.2. Descripción de la Fase de Inicio.

Esta fase es esencial en el presente trabajo ya que implica actividades de inicio de

proyecto y creación de estructuras para la ejecución en las posteriores fases del proyecto.

Conforme a la metodología RUP se entrega el proyecto por parte de los estudiantes que

desarrollan el Proyecto Integrador en conjunto con el director de la tesis. Se define los

diferentes procesos estratégicos y se establecen los diferentes planes de acción para gestionar

las fases descritas en el proyecto. Se identifican y se documentan los estándares adecuados

para la ejecución del proyecto, mejores prácticas, metodologías aprobadas por entes

internacionales, herramientas de alto nivel, personal y otros recursos necesarios para alinear

estos elementos y proceder a ejecutar el proyecto.

La importancia de esta fase es de nivel crítico, ya que el proyecto y las fases

subsecuentes dependen del alcance del proyecto y del proceso estratégico que se adoptará

para el desarrollo del proyecto.

Las mejores prácticas en la ejecución de proyectos relacionados a la construcción del

software con metodología RUP, establecen que se pueda llevar un control de los diferentes

cambios en la documentación del proyecto y los diferentes componentes a nivel de hardware

y software que integran la solución del proyecto. El concepto de este control radica en

registrar consistentemente los cambios después de una primera entrega. Para ejecutar esta

buena práctica en el proyecto se ha establecido un formato que será parte de cada entregable

que se encuentra en el apartado “Anexos” del presente documento como Anexo 2.


Establecer un control en los cambios del contenido configurable del software, es

importante establecer controles en las especificaciones del producto y otros documentos del

software en el ciclo de vida del proyecto después de la primera entrega.

Es necesario asegurar la eficiencia en la ejecución de las actividades, al tomar ventaja de un

listado de componentes de software previamente desarrollados que pueden ser parte de una

reutilización dentro del proyecto.

Para dar comienzo a esta fase y al proyecto se realizó una reunión, con el director de la

tesis y junto con un representante de la institución con el plan de tesis aprobado para

garantizar un inicio formal del proyecto con los implicados fundamentales del proyecto. El

acta de reunión con los implicados será un documento válido para comprometer a los

involucrados a validar y aceptar ítems levantados como observación durante la reunión. El

documento se encuentra en el Anexo 3.

5.1.3. Marco Administrativo.

5.1.3.1. Recursos Tecnológicos.

Es importante determinar el tipo y la cantidad de recursos utilizados en las fases del

proyecto.

La ponderación de los factores en la materia educativa se obtuvo de la evaluación

realizada por un grupo de especialistas profesores y directores de la Unidad Educativa “La

Colina”.

En cuanto a los recursos humanos ya se asume la responsabilidad de: jefe técnico, jefe

del proceso, desarrolladores, analistas, jefe de pruebas.

Tabla 2. Presupuesto Estimación Inicial

Rubro Detalle Valor

Hardware 1 PC’s Core I5, 2GB RAM, 200GB $ 0.00


Rubro Detalle Valor

Disco

Software

ZODB (Base de Datos)

Zope 3

Zope Web Application

Ubuntu Server 14.04

$ 0.00

$ 0.00

$ 0.00

$ 0.00

Recursos

2 Desarrolladores (1 Meses) $ 5,000.00

2 Analistas (3Meses) $ 9,600.00

2 Ingenieros de Pruebas (1 Mes) $ 5,000.00

Valor Renovación

Licencias $ 0.00

*SUBTOTAL RECURSOS HW SW $19,600.00

5.1.3.2. Recursos Humanos.

El siguiente grafo presenta la justificación y aporte de los recursos costeados en el cuadro

anterior, según la figura de la Ilustración 3 siguiendo la metodología del desarrollo del

software tradicional se necesita la participación de cada uno de ellos conforme cada fase en la

que cursa el proyecto.

Figura 5. Esfuerzo – Fases del Proyecto




Nombre: Figura de Esfuerzo - Fases

Versión: 1.0


Vida del proyecto y recursos

PruebasAnálisis CódigoDiseño

Re

cu

rso

s

Analista Analista Desarrollador Ingeniero de Pruebas

Analista Analista Desarrollador Ingeniero de Pruebas

5.1.3.3. Presupuesto.

Los presupuestos que se presentara a continuación están debidamente justificados en

las secciones de recursos y la del cronograma, a continuación, se presenta el presupuesto

invertido en el proyecto:

Tabla 3. Presupuesto Global del Proyecto

Recursos Materiales y Recursos de Hardware, Software y Talento Humano

Nº Descripción Precio Unitario Total

10 Resmas Hojas A4 3.10 $31.00

10 Cartuchos B/N 19.00 $190.00

*SUBTOTAL RECURSOS HW SW

$19,600.0

Subtotal

$19,821.00

Impuesto IVA (12%)


Recursos Materiales y Recursos de Hardware, Software y Talento Humano

Nº Descripción Precio Unitario Total

$2,378.52

TOTAL

$22,199.52

5.1.3.4. Cronograma.

La planificación del proyecto, para la construcción del sistema, ha involucrado

actividades como: establecer las dependencias entre las tareas del proyecto, estimar el

esfuerzo asociado con cada una de ellas, realizar la asignación de personal y de otros recursos,

crear una red de tareas y desarrollar una agenda de fechas. La planificación del proyecto se

detalla en el Anexo 7.

5.2. Fase de Análisis

Esta fase tiene cobertura sobre las actividades focalizadas en la identificación de

requerimientos de software. Se busca comprender y llegar a un entendimiento satisfactorio

sobre los requerimientos del usuario a través del estudio minucioso de los problemas, los

sistemas existentes y discusiones con el usuario. El análisis permite llegar a una solución de

sistema en términos de características vitales, esenciales y deseadas.

Conforme la metodología tradicional de investigación de campo de carácter

exploratorio con lineamientos de la metodología RUP, en este punto se centra la atención en

definir conceptos básicos del proyecto. En esta fase elaboramos los lineamientos del alcance

del proyecto con las funcionalidades que requiere el usuario final y los intervinientes del

proyecto.

Los requerimientos iniciales para la unidad educativa "La Colina" se han especificado

con la necesidad de un sistema para la gestión de procesos académicos de la escuela. Con esto

se han definido los actores, actividades y procesos que intervienen en este tipo de sistemas.


Además, con este insumo se debe determinar, funcionalidades a exigir y requisitos

necesarios para todo ello. Los parámetros fundamentales son:

5.2.1. Plan de Recolección de Datos.

Se elaborará un formato de una entrevista estructurada que permite comprender el

alcance que tendrá el sistema de información para abordar más a fondo el tema del modelo de

créditos para instituciones educativas.

Mediante un documento de toma de requerimientos el cual se efectuará con el

desarrollo del proyecto, se levantará los requerimientos del usuario, los cuales ayudaran a

definir posteriormente los requerimientos del sistema.

Tabla 4.Formato de Entrevistas

ID nombre descriptivo

Versión nº versión (fecha de versión)

Dependencias Proceso actual...

Descripción Descripción detallada del proceso a diseñar.

Importancia Prioridad del proceso en el entorno del negocio

Actores • stakeholder

• ...

Comentarios Observaciones adicionales para el proceso

5.2.1.1. Plan de Procesamiento de Datos.

En base la información obtenida, se ve reflejada la necesidad de reconocer el ámbito

para la implementación del sistema, es decir se debe analizar detalladamente la

parametrización del sistema en el instituto de modo que exista una fase de transición para que

se pueda adaptar el sistema a las necesidades del instituto.


El estudio de la documentación escrita, permite obtener parte de los conocimientos

relevantes en la construcción del sistema.

5.2.1.1.1. Fines Específicos y Generales del istema.

Se requiere un sistema web de información estudiantil libre y de código abierto

diseñado para centros educativos básicos como escuelas. Para administrar la información de

todos los actores en la etapa estudiantil de los alumnos, control en notas de los estudiantes e

intervenciones extra curriculares.

5.2.2. Funcionamiento y Rendimiento Requeridos Para el Sistema.

En este apartado se detallará la forma funcional del proyecto, de acuerdo a las

especificaciones requeridas por el cliente.

Se requieren los siguientes puntos:

Gestión de datos personales a la medida de estudiantes y maestros.

Administración de contactos de maestros, estudiantes y sus responsables;

Cuadros de notas para maestros.

Recolección de datos de evaluación a nivel escolar y generación de libretas de notas.

Control de asistencia y notas de participación diaria

Calendarios para la escuela, grupos, personas y reservas de recursos.

Seguimiento y administración de intervenciones del estudiante.

Los puntos descritos anteriormente serán tabulados formalmente para obtener una mejor

visión y detalle de los requerimientos funcionales de los diferentes stakeholder:

Tabla 5. Requerimientos Funcionales y no Funcionales

NEC MATRIZ DE NECESIDADES DE PROCESOS/SERVICIOS

REQUERIMIENTOS FUNCIONALES



N1

Registro de Alumnos

El usuario Administrador realizará el registro de los alumnos de nuevo ingreso,

considerando los siguientes datos.

CURP

Nombre del alumno

Sexo

Nombre del padre o tutor

Domicilio

Calle

No. exterior

Colonia

Delegación

Teléfono

N 2

Registro de Profesores

El usuario Administrador realizará el registro de los profesores, considerando:

Nombre del profesor

Asignatura que imparte

Grupos asignados

N3

Actualización anual del programa escolar

El usuario Administrador realizará el alta de alumnos mediante un formato de



Excel, después se realizará la relación Profesor que impartirá la Asignatura, así

como asignar Grado, Grupo, Orientador

N4

Registro de Calificaciones

El usuario Profesor asignará las calificaciones:

Primero ingresando al sistema encontrará las asignaturas que imparte, segundo

encontrará los grupos a los que imparte la asignatura y finalmente la lista de los

alumnos.

Los profesores podrán seleccionar la calificación asignada al alumno.

Los datos del formulario son;

Id de la asignatura

Nombre de la asignatura

Grupo

Id del alumno

Nombre del alumno

Periodo de evaluación

Calificación

N5

Registro de asistencia alumno

El usuario Orientador realizará el registro de asistencia diaria de lunes a viernes.

Primero ingresará al sistema, visualizando los grupos asignados, seleccionará el

grupo y encontrará el nombre de los alumnos en existencia; registrará la asistencia

seleccionando el botón correspondiente “Asistió” o “No asistió”.

Los datos necesarios para llenar la asistencia

Nombre del alumno

Grupo

Grado



N6

Informe académico del alumno

El usuario Padre o tutor podrá visualizar el informe del alumno por bimestral quien

podrá visualizarlo después de haber ingresado al sistema. Encontrará las opciones

de calificaciones y asistencia, después de seleccionar una opción podrá visualizarla

cuando lo necesite, pero únicamente se actualizará al final de cada corte de

evaluación bimestral.

Nombre del alumno

Asignatura

Grado

Grupo

Calificación

Asistencia

N7

Avisos

Los avisos serán subidos a la web por el usuario Administrador

Se subirá el documento en el cual se encuentre el aviso dirigido a la población de la

institución, apareciéndole la opción y únicamente presionando el botón subir, se

guardará en la página Web.

Los avisos podrán ser visualizados por todo público no es necesario ingresar a un

usuario.

Únicamente será de consulta para el público.

N8

Consulta de información de la institución

No será necesario contar con un usuario para consultar la información de la

institución será para todo público.



Donde encontrara la siguiente información de la institución

Ubicación

Misión

Visión

Mensaje del director

Teléfonos

Correos

Horarios de atención

NEC REQUERIMIENTOS NO FUNCIONALES

N9 Fiabilidad y calidad

N10 Limitaciones de coste/tiempo

N11 Tecnología disponible (disponibilidad)

N12 Ampliaciones futuras

El cuadro 4.1 conforma un plan de requisitos del producto y la toma formal de

requerimientos, resultado de las diferentes entrevistas con los directivos, especialistas y

usuarios que se encuentran en la institución.

5.2.3. Diagramas de la Arquitectura Lógica del Sistema.

Esta sección contiene una representación gráfica de la arquitectura lógica propuesto

para el sistema en desarrollo.

En este apartado se ha optado por seguir las buenas prácticas y estándares que

recomiendan usar un diagrama de componentes UML, un diagrama de paquetes UML.


Figura 6. Arquitectura Lógica del Sistema


Nombre: Arquitectura Lógica del Sistema

Versión: 1.0


Zope

ZODB

ZServer

Web Server

TCP/HTTP

Datos

Core

Zope Products

ZClases

ODBC

5.2.4. Descripción de la Arquitectura Lógica del Sistema.

Ahora vamos a describir de manera textual la arquitectura lógica del sistema, sus

componentes principales y sus relaciones.

5.2.4.1. Componentes del Framework Zope.

5.2.4.2. Servidor de Aplicaciones ZServer.

ZServer proporciona soporte de conectividad a redes LAN, WAN e Internet de manera

flexible a muchos protocolos de red, incluyendo HTTP, FTP, XML-RPC, FastCGI y PCGI.


ZServer puede funcionar de forma coordinada y controlada con los servidores web existentes.

5.2.4.3. Nucleo del Framework Zope Core.

Zope incluye un módulo ORB que simplemente es un middleware, que proporciona la

capacidad a los objetos realizar llamadas a métodos situados en máquinas remotas, motores de

búsqueda, capa de seguridad, y el intercambio de información dinámica

5.2.4.4. Base de Datos Orientada a Objetos ZODB (Zope Object Data Base).

Base de datos orientada a objetos de Zope, ZODB es una base de datos relacional

nativo para Python, soporta transacciones similares a las DML de las bases de datos

relacionales, adicionalmente tiene la capacidad de procesar escalas a nivel de gigabytes de

datos. Tiene la capacidad de proporcionar escalabilidad y conmutación por error.

Debido ZODB es una base de datos de objetos no se utiliza un lenguaje diferente para

las operaciones de base de datos, lo cual trae un impacto mínimo en su código para hacer

objetos persistentes.

El mapeo objeto-relacional no es como el uso de una base de datos de objetos, es decir

no existe sintaxis que difieran entre el código del aplicativo y la base de datos.

Los Sistemas de Gestión de Bases de Datos para objetos, DBMS de objetos,

implementan la funcionalidad de base de datos a los lenguajes de programación orientado

a objetos. Brindando soporte para el almacenamiento persistente.

Las DBMS de objetos extienden la trayectoria de los lenguajes de programación

orientado a objetos para proporcionar capacidades similares a las bases de datos relacionales y

con la capacidad de no implementar líneas de código que difieran con el lenguaje de

programación con el que se desarrolla el producto.

La unificación del desarrollo del sistema y la base de datos en el mismo modelo de

datos, esto conlleva a tener un desarrollo consolidado en un solo lenguaje de programación


con beneficios en mantenimiento del código de la persistencia orientado a objetos.

El mapeo uno a uno de objetos en el lenguaje de programación orientado a objetos de

base de datos tiene dos ventajas: proporciona una capacidad de procesamiento ágil para la

gestión de objetos, y tiene una capacidad nativa para gestionar relaciones complejas entre el

modelo de datos. Esto valida la aptitud de este paradigma de bases de datos para aplicaciones

de sistemas de análisis de riesgos financieros, sistemas de servicios de telecomunicaciones,

sistemas de registro de pacientes de hospitales.

Las bases de datos orientadas a objetos tienen la limitante de resistencia al cambio,

claro está cuando sea necesario implementar este paradigma, muchas corporaciones

contemplan el gasto sobre la migración a este paradigma. Sin embargo, la potencialidad de

relacionar objetos reusables provee de una increíble capacidad multimedia.

Las bases de datos orientada a objetos, tiene un comportamiento fuertemente ligado al

código del lenguaje de programación orientada a objetos que define una clase.

ZODB no implementa un sistema de dependencias principales en una base de datos

relacional como son las definiciones de llaves foráneas o constrain’s, esta capacidad genera

un diseño transparente en el código. Generalmente en un entorno de programación orientada a

objetos de manera resumida por simplicidad permite manejar la validación de datos dentro de

la lógica del objeto, ya sea utilizando la definición de las propiedades o interfaces.

El uso de miembros heterogéneos en ZODB tiene un potencial muy utilizado en

lenguajes de programación orientados a objetos que soportan el duck-typing. El uso de ZODB

es aún más transparente y natural, sin tener que adaptar su código a la base de datos.

El Glosario de Python define el duck typing como:

Estilo de programación Python que determina el tipo de un objeto a través de la

inspección de sus métodos o su conjunto de atributos en lugar de emplear la relación con


algún tipo de objeto ("Si luce como un pato y suena como un pato, debe ser un pato")

Enfatizando las interfaces sobre los tipos específicos, el código bien diseñado mejora su

flexibilidad al permitir sustitución polimórfica. El duck typing evita las pruebas con type() o

isinstance().

En lugar de eso, prefiere el estilo de programación "Es más fácil pedir perdón que

pedir permiso"

5.2.4.4.1. Atomicidad en las Transacciones.

Tiene definiciones de atomicidad sobre sus transacciones, los cambios realizados en

una transacción se guardan ya sea en su totalidad o en absoluto. Esto hace optimiza el manejo

de excepciones en errores generados por transacciones inconclusas. La definición de

atomicidad en las bases de datos orientadas a objetos garantiza la capacidad de deshacer los

cambios de base de datos que no fueron ejecutados con éxito.

5.2.4.4.2. Transacciones que Proporcionan Aislamiento.

Transacciones que permiten operaciones en varios hilos de proceso de manera lógica

para acceder a bases de datos, adicional tiene la capacidad de impedir que los hilos entren en

conflicto en transacciones concurrentes. Esta capacidad le permite ampliar operar en hilos

múltiples, procesos sin tener que usar bloqueos de bajo nivel. Sin embargo, es importante

recalcar que de alguna manera se tiene que hacer frente a la concurrencia en algún nivel. Para

los sistemas basados ZODB, existe la posibilidad de analizar un reproceso en ciertas

transacciones en conflicto y en ciertos casos es necesario tener un plan de reproceso en los

diferentes casos de uso

ZODB tiene la capacidad de bases de datos relacionales como son las propiedades

ACID en transacciones con aislamiento de forma instantánea. Brinda soporte en operaciones

con transacciones distribuidas utilizando múltiples bases de datos ZODB.


5.2.4.4.3. Almacenamiento en Capas Modulares.

ZODB tiene una arquitectura de almacenamiento modular. Esto permite una la

interacción con una gama de esquemas de almacenamiento, de tal forma que puede soportar

almacenamiento para arquitecturas cliente-servidor basado en memoria y distribuida basada

en archivos. A través de los módulos de almacenamiento, se puede proporcionar compresión,

cifrado, replicación, etc.

5.2.4.4.4. Facilidades Para Pruebas Unitarias.

ZODB suministra implementaciones en memoria cache, por lo tanto, proporciona una

copia de escritura en capas implementaciones de código de “almacenamiento de demostración

virtual” que permite realizar test de código relacionado con la base de datos de manera fácil.

5.2.4.4.5. Auditoría Forense.

Las implementaciones con estructuras ZODB añaden registros en la escritura y

eliminan registros modificados sobre las operaciones ejecutadas en una transacción. Esto

permite revisar transacciones ejecutadas en tiempo pasado de forma limitada, de forma que es

posible validar la nueva afectación en relación a la última vez que el paquete fue afectado.

5.2.4.4.6. Manejo de Objetos Binarios.

En las aplicaciones esto puede ser especialmente útil cuando el aplicativo sirve medios

de comunicación.

5.2.4.4.7. ¿Cuándo se debe utilizar ZODB?

ZODB es adecuado para la implementación de aplicaciones tipo RAD de tal forma que

este tipo de aplicaciones requiere centrarse en la funcionalidad de la aplicación sin tener que

poner esfuerzos en la construcción de código base de datos.

Puede ser práctico para simular la migración de base de datos en un proyecto y sus

cambios futuros, de esta manera se garantizan un aprendizaje mucho más rápido.


En las bases de datos relacionales existen diseños inconsistentes que llevan a la

codificación con malas prácticas de tal forma que se tiene que unir tablas para modelar

estructuras de datos complejas, estas malas prácticas perjudican al costo del aplicativo en

implementaciones y a largo plazo en el mantenimiento del código. Para mitigar estas malas

práctica en bases de datos relacionales como PostgreSQL es necesario recurrir al uso de tipos

de datos más potentes como matrices y columnas JSON, sin embargo, cuando las relaciones

se encuentran mal diseñadas, es necesario recurrir a malas prácticas como el uso del comando

unión.

En las bases de datos No SQL, es posible modelar estructuras de datos complejas, pero

si es necesario el uso de relaciones, entonces se puede aprovechar la potencialidad de las

capacidades en bases de datos No SQL, que son típicamente mucho menos potentes y

transaccionales. Pese a las limitaciones, puede hacer que los objetos tan complejos como

requiera un aplicativo y relacionarlos con implementaciones con referencias a objetos de

Python. Puede acceder a los datos a través de atributos y métodos del objeto como

implementaciones ORM de otros productos.

ZODB posee un único lenguaje de consulta que es Python. Es el soporte principal de

búsqueda mediante objetos y sus referencias. El proyecto requiere construir API’s de

búsqueda de más alto nivel en componentes superiores de ZODB. Estas implementaciones

tienen resultados efectivos como para apoyar este tipo de búsquedas en alto nivel de los

componentes.

5.2.4.5. Integración con RDBMS.

Zope tiene la facilidad de interactuar con motores de bases de datos conocidas como

proveedores tales como: Oracle, Sybase, MySQL y PostgreSQL. Adicionalmente proporciona

los controladores ODBC.


5.2.4.6. Extensiones del Núcleo Zope Products.

Los productos Zope extienden el núcleo Zope mediante la inclusión de nuevos

componentes con la capacidad de generar nuevos tipos de objetos e instalaciones

personalizados escritos en Python útiles para aplicaciones diseñadas con Zope.

5.2.4.6.1. Componentes Personalizados Interfaces.

El concepto de una interfaz formal es útil en la construcción de un sistema. Las

interfaces permiten implementar todas las ventajas y la potencialidad de la ZCA.

Una interfaz define las características de un objeto, define su comportamiento y las

capacidades en sus implementaciones. La interfaz representa lo que un objeto puede hacer o la

capacidad que tiene para desplegar capacidades de “aprendizaje”.

En algunos lenguajes de programación modernos: Java, .NET C#, VB.NET, etc., las

interfaces son un aspecto explícito del lenguaje.

Como Python no posee definiciones y las características de las interfaces, ZCA

implementa como una meta clase a heredar.

5.2.4.6.2. Componentes Personalizados Adapters.

La arquitectura orientada a componentes de Zope, ayuda a utilizar de manera eficiente

los objetos de Python. Los componentes adaptadores son uno de los componentes primitivos

utilizados por la arquitectura orientada a componentes de Zope donde la definición que

fundamenta los componentes adaptadores son simplemente objetos de Python, pero con una

interfaz más elaborada.

Es importante recalcar que para declarar una clase, es fundamental el uso del

adaptador adapts en la función definida en el paquete zope.component.

5.2.4.6.3. Componentes Personalizados Utility.

Ahora que en definiciones anteriores se conoce el concepto de interfaz y adaptador. Es


importante validar el registrar un objeto que no está adaptando nada. La conexión de la base

de datos, analizadores de objetos XML, retorno de identificaciones único de objetos, etc., son

ejemplos de este tipo de objetos conocidos como utility. Este tipo de componentes

proporcionada por la ZCA se denominan componentes de servicios públicos.

Utility son sólo objetos que proporcionan una interfaz y que son consumidos por una

interfaz. Este enfoque crea un registro global mediante el cual los casos se pueden registrar y

acceder a diferentes partes de la aplicación, sin necesidad de pasar alrededor de los casos

como parámetros.

5.2.4.7. Componentes Nativos ZClasses.

Las clases se extienden del núcleo Zope con nuevos objetos tipos que son

implementados a través de la web o de objetos que instancian estas clases. Las clases no

requieren ningún tipo de programación y pueden ser distribuidos e instalados fácilmente ya

que obedece la definición de Zope que es orientado a componentes.

5.2.5. Modelo de Clases del Sistema.

5.2.5.1. Diagramas de Clases del Sistema.

Este diagrama se encuentra en el apartado de los Anexos en referencia al Anexo 4.

5.2.5.2. Descripción de las Clases y Componentes del Sistema.

El diagrama de clases se encuentra agrupado conforme el siguiente detalle:

5.2.5.2.1. Acceso Inicio del Sistema.

Se detallan los componentes de Python que manejan la parte de inicio de sesión con

variables para nombre de usuarios, consultas y accesos.

5.2.5.2.2. Componentes Generales de Diálogos.

Se describen las clases utilizadas para el manejo mensajes comunes que serán usados

en todo el desarrollo del aplicativo.

5.2.5.2.3. Componentes Genéricos Para Funcionalidades Básicas.


Se detallan los componentes que permiten encapsular características que no son

específicas para las diferentes funcionalidades de la aplicación, generalizando ciertas

características de uso común.

5.2.5.2.4. Componentes de Presentación View Web.

Estas clases representan en el desarrollo la parte web del sistema, para los módulos

que intervienen en las necesidades descritas en los requerimientos del negocio.

En el ANEXO4 se describe el diagrama de clases detallado conforme los apartados de

esta descripción para el presente proyecto.

5.2.6. Modelo de Casos de Uso del Sistema.

5.2.6.1. Diagramas de Secuencia y Flujos de Trabajo del Sistema.

Esta sección es mandatorio y su contenido plasma el modelo dinámico/funcional del

sistema de información, a esta buena práctica de documentación se la denominado modelo de

casos de uso en Métrica versión 3, conforme el desarrollo y los recursos técnicos que

desarrollan el sistema esta documentación se puede modelar los casos de uso descritos en la

Especificación de Requisitos del Sistema, sin embargo para el desarrollo del presente sistema

se ha visto la importancia que este apartado se encuentre en esta sección.

5.2.6.2. Descripción de los Diagramas de Secuencia y Flujos de Trabajo del Sistema.

En síntesis, esta sección plasma y diseña de manera global los casos de uso diseñados

y alineados a los requerimientos funcionales para el sistema del presente trabajo.

5.2.6.2.1. Estructura del Documento de Casos de Uso del Sistema.

Diagrama de Casos de Uso

En esta sección se presentan un diagrama UML del caso de uso en base a la estructura

planteada a los requerimientos del sistema, la información de los requerimientos del sistema

fue recabada en el capítulo anterior.


Para tener un diseño efectivo del en los diferentes diagramas de casos de uso conforme

la notación de UML es necesario tener en cuenta ciertos elementos previos al diseño como:

Lista de Actores Describe todos los actores involucrados en el sistema.

Lista de Casos de Uso

Agrega una descripción detallada de cada caso de uso.

En este documento se detalla cada uno de los casos de uso del Análisis del Sistema.

Estos casos de uso y todas sus características de diseño se encuentran diseñadas en el

ANEXO 5.

5.2.6.3. Interfaz de Usuario del Sistema.

En esta sección se describe el modelo de interfaz de usuario del sistema software,

compuesto por bosquejos simples de las pantallas e informes y el diseño del modelo de

navegación entre los distintos módulos mismos.

5.2.6.4. Diagramas de Navegación del Sistema.

Esta sección contiene el diagrama generalizado de navegación del sistema basado en la

interfaz de usuario del sistema en desarrollo, para este caso se ha optado utilizar la notación

de diagramas UML, ya que no existe ningún diagrama de UML específico para este propósito.

Figura 7. Diseño de Navegación del Sistema




Nombre: Diseño de Navegación del Sistema

Versión: 1.0


5.2.7. Catálogo de Controles y Elementos de Diseño.

En este apartado se describen todos los controles utilizados para la construcción de la

interfaz gráfica (botones, campos de texto, mensajes de aviso...), especificando sus

propiedades y los estilos de diseño utilizados en el desarrollo del aplicativo.

5.2.7.1. Componentes de Presentación Vistas

Son definiciones de páginas mostradas al cliente, este tipo de componentes en su

contenido presentan definiciones de otros componentes mediante peticiones y métodos de

interacción del navegador con el servidor web.


5.2.7.2. Componentes de Presentación Zope Page Templates

Son plantillas XHTML basados en etiquetas TAL (Template Attribute

Language) y METAL (Macro Expansion Template Attribute Language). Como es conocido a

nivel de diseño web, las definiciones de los archivos XHTML modelan formularios web

mediante etiquetas HTML y los dinamizan mediante TAL y METAL.

5.2.7.3. Componentes de Presentación Template Attribute Language (TAL)

Las etiquetas TAL son parte de las representaciones de objetos de interfaz y permite

hacer contenido dinámico, en donde intervienen las definiciones de sus etiquetas html y

etiquetas tal:

<metal:block define-macro="navigation" i18n:domain="schooltool">

<a id="calendar-navigation-context-previous"

tal:attributes="href view/prev;

title view/go_to_prev_title">

<span tal:replace="view/prev_title">Previous</span>

</a>

<a id="calendar-navigation-context-current"

tal:attributes="href view/current;

title view/go_to_current_title">

<span tal:replace="view/current_title">Current</span>

</a>

5.2.7.4. Comandos TAL

5.2.7.4.1. Define.

Sirve para definir variables

<form method="post" action="" tal:attributes="action request/URL"

tal:define="dummy view/update">


5.2.7.4.2. Condition.

Define condiciones de prueba

<table class="person-details">

<tal:if condition="not:context/allday">

<tr tal:condition="view/start">

<td class="dr" i18n:translate="">Starts</td>

<td>: </td>

<td class="dl" tal:content="view/start" />

</tr>

<tr tal:condition="view/end">

<td class="dr" i18n:translate="">Ends</td>

<td>: </td>

<td class="dl" tal:content="view/end" />

</tr>

</tal:if>

<tr tal:condition="context/location|nothing">

<td class="dr" i18n:translate="">Location</td>

<td>: </td>

<td class="dl" tal:content="context/location" />

</tr>

</table>

5.2.7.4.3. Repeat.

Tiene la capacidad de repetir un elemento

<td class="cal_yearly_day" tal:repeat="day week">

<a tal:condition="python:day.date.month == month[1][0].date.month"


tal:content="day/date/day"

tal:attributes="href python:view.calURL('daily', day.date);

class python:(len(day.events) > 0

and 'cal_yearly_day_busy'

or 'cal_yearly_day')

+ (day.today() and ' today' or '')"/>

</td>

5.2.7.4.4. Content.

Este atributo reemplaza el contenido de un elemento

<div class="info" tal:condition="view/message"

tal:content="view/message" />

<div class="error" tal:condition="view/error"

tal:content="view/error" />

5.2.7.4.5. Replace.

Reemplaza el contenido de un elemento y desplaza el elemento del contenido al

abandonar la página

<title metal:fill-slot="title" i18n:translate="">

Calendar for <span tal:replace="context/title"

i18n:name="title" /> - <span i18n:name="calendar_title"

tal:replace="view/title" />

5.2.7.4.6. Attributes.

Cambia de forma dinámica los atributos de los elementos que se encuentran en las

propiedades de las etiquetas

<form method="post" tal:attributes="action view/@@absolute_url">

<tal:block replace="structure view/template" />


<input type="hidden"

tal:condition="view/batch"

tal:attributes="value view/batch/start;

name string:${view/extras_prefix}.batch_start" />



tal:attributes="value view/batch/size;

name string:${view/extras_prefix}.batch_size" />

</form>

5.2.7.4.7. Omit-tag

Elimina el contenido de un elemento dejando su contenido en el formulario

<form method="post" tal:attributes="action view/@@absolute_url">

<tal:block replace="structure view/template" />



tal:attributes="value view/batch/start;

name string:${view/extras_prefix}.batch_start" />



tal:attributes="value view/batch/size;

name string:${view/extras_prefix}.batch_size" />

</form>

5.2.7.5. Orden semántico de operaciones y etiquetas TAL


A excepción del orden de estas etiquetas: el tal:content y tal:replace, pueden existir

una combinación variada en las declaraciones, de manera que cuando un elemento tiene varias

instrucciones, que se ejecutan indistintamente en el siguiente orden:

tal:define

tal:condition

tal:repeat

tal:content o tal:replace

tal:omit-tag

tal:attributes

5.2.7.6. Macro Extensión Tal Attribute Language (METAL)

Estas etiquetas proveen macros para establecer reutilización de código útil para el

diseño de las páginas web, METAL generalmente es empleado para validar el orden

coherente en el diseño de una vista, existe una funcionalidad que permite sobrescribir el

código en el diseño de la vista esta funcionalidad es denominada como slot.

<metal:block define-macro="navigation" i18n:domain="schooltool">

5.2.7.7. Recursos estáticos para las vistas.

Es importante recalcar que para zope es posible usar estándares de diseño conocidos

como las hojas de estilo (css) e imágenes, se puede agregar usabilidad con javascript y sus

diferentes derivados.

5.2.7.8. Definición de excepciones.

A nivel de excepciones es importante validar los mensajes de error que enmascaran

esta información valiosa para el usuario y para el soporte de mantenimiento del aplicativo, los


mensajes de aviso o advertencia sobre transacciones o flujos de alta criticidad que demanda el

aplicativo.

def format_html_exception(etype, exception, traceback):

# Note: this function exposes filenames to the web user; some may

# consider it a security risk.

lines = []

out = lines.append

out('<h2>Exception</h2>\n')

out('<pre>\n')

format_html_ex(out, exception)

out('</pre>\n')

out('<h2>Traceback</h2>\n')

out('<pre>\n')

format_html_traceback(out, traceback)

out('</pre>\n')

return "".join(lines)

5.2.8. Información Sobre Trazabilidad.

La matriz de trazabilidad es una herramienta importante que permitirá visualizar que

partes o módulos del aplicativo en construcción no se encuentran cubiertos en este capítulo

para no omitir el objetivo de este capítulo en contraste a los requerimientos funcionales.

La matriz de trazabilidad permitirá dar el respectivo seguimiento a los requerimientos

más críticos para saber si están suficientemente cubiertos en este capítulo.

La construcción de la matriz de trazabilidad permitirá garantizar que todos los requerimientos

funcionales identificados por sus stakeholders han sido verificados en su totalidad. El detalle

de las matrices se encuentra en el Anexo 6.


5.3. Fase de Diseño

El presente capitulo tiene como objetivo presentar el diseño del sistema,

partiendo de un enfoque global en el que es necesario considerar la naturaleza del

proyecto y las herramientas utilizadas. El proceso de diseño expone claramente el "Qué

hacer" con el "Cómo hacerlo" de las especificaciones del diseño. Se inicia con la definición de

los objetivos de diseño, se mapea y da seguimiento los componentes de software, la

arquitectura del sistema y el diseño de la base de datos definidos en el capítulo anterior.

A continuación, se mostrará los diagramas de componentes y el respectivo diagrama

de ZODB que es un diagrama similar al de clases ya que es una base de datos no relacional.

Figura 8. Diagrama de Componentes del Sistema





Versión: 1.0



ZODB


ReportLab


Zope Page Templates

TALInterfaz integración

Adapter


Utilities


PythonZSERVER


Zope Products


Interfaces


Redis


Celery


ExcelPyton

5.3.1. Diagrama de Base de Datos ZODB.

El diagrama para la Base de Datos por la naturaleza del aplicativo, ya que no es un

sistema de base de datos relacional, se ha comentado la ventaja de obtener un código

simplificado con el uso de ZODB, para lo cual es importante recalcar que nuestro diagrama se

encuentra especificado en el Anexo 4, que corresponde a los diagramas de clases, conforme el

modelo y diccionario de ZODB Python.


5.4. Fase de Construcción

En esta sección se trata la implementación del sistema después de validar una etapa de

diseño relativamente sintetizada, por el efecto de los paradigmas elegidos para la construcción

del aplicativo. Esta fase centra sus esfuerzos en producir el código fuente, bases de datos,

archivos, la documentación técnica y parte de la documentación que servirá como manual de

usuario, estos ítems son parte de la expresión física del diseño. Adicionalmente, es importante

aclarar que en esta fase se integran el código fuente y la base de datos/archivos, que en

nuestro caso se ha consolidado en el código fuente por las definiciones de ZODB y Redis.

En primera instancia se describe la estructura del entorno tecnológico a nivel de

infraestructura y el software base con sus respectivas limitantes. La planificación de las

capacidades a nivel de infraestructura, para luego pasar de la Interfaz del usuario validando

los detalles sobre la forma de autenticación y presentación de los elementos de diseños

presentados en la pantalla principal y la creación de reportes sujetos a las definiciones de las

necesidades funcionales.

5.4.1. Descripción del Entorno Tecnológico.

En esta sección se incluirá la descripción del entorno tecnológico a nivel de

infraestructura que da soporte al sistema de información. Es importante tener en cuenta el

Documento de Especificación de funcionales y no funcionales del sistema, esto en cuanto a

las limitantes a nivel de presupuesto del solicitante.

Elementos de la Infraestructura

En esta sección se describen los elementos de la infraestructura necesarios como

requerimientos mínimos para el sistema, en contraste con la escuela “La Colina” es

importante recalcar que la escuela cuenta con un centro de cómputo que no está orientado a

cubrir necesidades empresariales ya que el core de negocio está orientado a la educación, es

decir atendiendo a la necesidad de la escuela la distribución Hardware, Software y de


Comunicaciones son relativamente básicas pero con potencialidad de los sistemas distribuidos

que requiere la institución.

5.4.1.1. Hardware Adecuado en Despliegues a Producción.

El principal inconveniente con el rendimiento óptimo del desempeño de la herramienta

es usualmente la memoria. Generalmente el sistema requiere 1 GB de RAM, sin embargo,

conforme exista más memoria significa un rendimiento óptimo de base de datos.

Se recomienda al menos 1 GHz mono núcleo. La herramienta ejecuta procesos en

varios hilos, pero por la naturaleza y arquitectura del lenguaje de programación Python

procesa solamente en un hilo a nivel de procesador, en resumen, la herramienta no se

beneficia directamente de multiprocesador o un procesador de 2 o más núcleos.

La herramienta demanda espacio significativo en almacenamiento, con un giga-byte es

suficiente, donde se debe contemplar la rapidez del disco en contraste a la capacidad del

disco.

5.4.1.2. Tecnologías de Infraestructura Para Despliegues en Producción.

Actualmente existen varias tecnologías para el despliegue de la solución sin embargo es

necesario recalcar que las tecnologías requeridas por la institución finalmente no requieren

infraestructura compleja y por lo tanto no se requiere servidores con recursos potentes. Sin

embargo, conforme las buenas prácticas es necesario tener infraestructura separada para cada

rol entendiéndose que es necesario segregar la infraestructura para cada rol en el proyecto.

5.4.1.3. Sistema Operativo Adecuado en Despliegues a Producción.

Ubuntu server a escalado posiciones en el uso de sistemas operativos orientados a

servidores, hasta ser de los proveedores de virtualización, cloud, openstack cluster, etc. Donde

la última versión estable es la 14.04 LTS Trusty Tahr de Ubuntu incluyendo su versión

servidor. Con el soporte de la gran mayoría de fabricantes de hardware, Ubuntu server es la

opción adecuada para la implementación del sistema.


Ubuntu 14.04 LTS Server Edition soporta las arquitecturas más populares en procesadores

tales como: Intel x86, AMD64 y ARM. La siguiente tabla muestra las especificaciones de

hardware recomendado por el fabricante.

Figura 9. Ubuntu Server 14.04

Fuente: Ubuntu. (2015). Server Management. 2016, de página de inicio del portal de Ubuntu Sitio web:

http://www.ubuntu.com/

5.4.1.4. Software Base de Aplicaciones Zope Web Application Server.

Es un servidor web de código abierto que está escrito en Python con la tecnología

basado en pila.

Zope tiene un número de componentes, uno de estos es el servidor Zope,

esencialmente un servidor web (y servidor FTP); la diferencia entre Zope y servidores web

como Apache, es que Zope no sirve archivos y su propósito está orientado a objetos. Un

objeto es un fragmento de datos y el código puede tener diversas propiedades y objetos

secundarios adjuntos, emite HTML.

En todas sus páginas web, scripts, imágenes y datos son características sobre la

variedad en la base de datos de objetos de Zope, valida aspectos de seguridad del servidor

HTTP en el puerto TCP 8080, en caso de la herramienta el puerto es parametrizable esto a

nivel de seguridad lleva a enmascarar el puesto para que al menos no exista facilidad de

escaneo de puertos predeterminados que generalmente son debilidades de seguridad habitual

en implementaciones de software.

Puede interactuar con Zope habitualmente desde un navegador en: http:

//localhost:8080/. La interfaz de administración le da una vista de dos paneles de los


contenidos de la base de datos de objetos. El menú de opciones permite validar diferentes

propiedades para la edición o visualización del objeto seleccionado, incluyendo sus permisos

de acceso, atributos asociados, la incorporación en el control de versiones, permite usar la

potencialidad que ofrecen proveedores similares de servicio de control de versiones tales

como el propio software subversión de Apache.

En Zope los métodos son segmentos de comandos que se ejecutan para renderizar el

código HTML que logra comunicarse del servidor hasta el navegador web del usuario final, a

diferencia del contenido estático. En síntesis, un "método DTML" es simplemente un

segmento de código DTML que es ejecutado por Zope, por ninguna circunstancia este

segmento de código es un fichero.

Ahora para propósitos del proyecto se requiere crear un sitio web dentro de Zope: la

primera tarea es crear un sitio en la raíz del servidor web. Esto lleva a una visión de los

contenidos de la carpeta raíz y a validar las diferentes responsabilidades del directorio virtual

creado en el servidor web Zope.

Zope nos da un documento estándar por defecto de esta manera:

<Dtml-var standard_html_header> <h2> <dtml-var title_or_id> </ h2> <p> Este es el

<dtml-var id> Documento. </ P> <dtml-var standard_html_footer>

DTML, es una plantilla de documento de lenguaje de marcado, es el sustituto en Zope

para HTML. En este caso, Zope procesa la plantilla DTML y genera HTML que viaja hasta el

navegador del cliente.

A nivel de seguridades es importante utilizar mejores prácticas son establecidos como

ACL’s en los directorios del sitio en producción.

5.4.1.5. Software Base de Persistencia ZODB y Redis.


Para fortalecer la herramienta para la escuela se ha utilizado Redis que resumidamente

es un motor de base de datos en memoria, que trabaja en conjunto con ZODB para

implementar la persistencia. Es importante recalcar que Python como plataforma de lenguaje

de programación soporta este Software que se lo catalogara como Base, adicionalmente este

motor soporta otros lenguajes de programación tales como: ActionScript, C, C++, C#,

Clojure, Haskell, haXe, Io, Java, Node.js, Lua, Objective-C, Common Lisp, Erlang, Go, Perl,

PHP, Pure Data, Ruby, Scala, Smalltalk y Tcl.

El uso habitual de Redis normalmente es la persistencia de la información en la memoria

RAM, pero para este caso se ha usado un archivo del tipo appendonly, mediante las

definiciones del sistema Journaling el cual escribe en el appendonly cada modificación que se

realice sobre los datos en memoria con la capacidad de mantener un histórico de los datos.

Esto genera un costo en el rendimiento que a su vez puede ser solventado con las capacidades

de los ordenadores actuales, finalmente se ha configurado en modo always, para que la

configuración escriba cualquier cambio en forma instantánea.

5.4.1.6. Software Base de Soporte a Reportes Celery

El core de este utilitario es realizar tareas programadas de forma asíncrona y el paso de

mensajes distribuidos. Para la herramienta se ha utilizado para agilizar y tareas de creación de

reportes y ejecución de tareas programadas en labores de persistencia.

5.4.1.7. Software Base de Procesamiento de Imágenes Pillow

Esta librería agilita el procesamiento de imágenes en el aplicativo para intérpretes de Python,

en nuestro caso se emplea para los componentes de las vistas y el procesamiento de imágenes

en el aplicativo.

5.4.1.8. Software Base de Cumplimiento Pytz

Librería utilizada para estandarizar el aplicativo con normas internacionales a nivel de

procesamiento de zonas horarias para Python.


5.4.1.9. Software Base de Reportes ReportLab

Software utilitario que sirve para construir reportería en el aplicativo, optimizando el tiempo y

soporta parametrización para reportes de todo tipo de requerimientos.

5.4.1.10. Software Base de Soporte a MS Excel Xlrd y Xlwt

Bibliotecas para procesamiento de archivos compatibles con Microsoft Excel, sirve para la

creación de reportería en formato Excel e importación de data.

5.4.1.11. Estructura Básica de Comunicaciones.

El diseño de la topología actual de la red de la escuela es básica tipo estrella en su centro de

cómputo, para las comunicaciones usan protocolos TCP/IP, para el despliegue de la solución

este tipo de topología es adecuado. Para que el sistema se incluya dentro de esta red la hemos

blindado con un dispositivo básico de seguridad a nivel de redes y es el UFW (Uncumplicated

Firewal por sus siglas en inglés) propio del sistema operativo Ubuntu. Es importante recalcar

que un primer punto de interacción con el cliente sería un DDos sin embargo por las

limitantes de infraestructura y por el uso en red interna se ha omitido estos frentes de

seguridad perimetral.

Figura 10. Diagrama de Red del Sistema.



Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Diagrama de Red

Versión: 1.0


5.4.1.12. Restricciones Técnicas en Despliegues a Producción.

En este apartado se describen las restricciones técnicas derivadas de la tecnología

seleccionada o del limitante de infraestructura que afecten al diseño y construcción del

sistema de información que básicamente se resume en la persistencia a nivel de procesamiento

en grandes cantidades el producto se degrada a nivel de rendimiento, la infraestructura

limitada de la institución ha derivado en soluciones que irrumpen en las buenas prácticas de

roles separados para la solución, sin embargo se ha procedido con una solución a medida que

pueda remediar estas carencias.

Figura 11. Diagrama de Despliegue del Sistema





Versión: 1.0


5.4.2. Definición Interfaz de Usuario del Sistema.

Especificación de la Interfaz de Pantalla y de Navegación

En este apartado se incluirá el diseño detallado del comportamiento de la interfaz de

usuario a partir de la especificación de la misma, obtenida en el proceso de análisis y de

acuerdo con el entorno tecnológico definido.

Se incluirá la especificación de cada una de las pantallas del sistema, incluyendo

eventos que la afectan, información que contiene y campos obligatorios. Toda esta

Infraestructura Proyecto

<<Servidor Web>>

Servidor de aplicaciones

Servidor de BDD

Interfaz

Presentación

Componente1

Componente2

Acceso a Datos

{ = <<Dispositivo>>Computadora

Personal: Internet Explorer}


información tiene que ser consistente en tipo y características con lo especificado en el

modelo físico de datos.

5.5. Fase de Pruebas

Esta fase tiene el fin de cubrir pruebas del sistema para la certificar que las

funcionalidades hayan sido implementadas conforme los requerimientos del usuario.

Certificará la seguridad, recuperación implementada en la interfaz del sistema, puntos

importantes como modos de reinicio, desempeño del aplicativo son importantes para medir el

nivel de carga de operatividad que soportará el sistema.

En caso que aplicare es importante validar la interacción con interfaces externas de

proveedores de servicios o consumo de data externa.

Un ítem que no debe ser desconsiderado es la usabilidad de la interfaz que se presenta

al usuario final considerando los factores de seguridad y rendimiento. La integración de

diferentes componentes a nivel de sistema, y validar la integración con el conjunto de

módulos que compone el sistema de información.

Generalmente las pruebas sobre el sistema se las ejecuta de manera recursiva y conforme la

necesidad del cliente, el guion de pruebas definido por el usuario y por las necesidades

funcionales se repite tantas veces como niveles de pruebas existan.

Las combinaciones posibles son:

Pruebas únicamente de sistema

Pruebas de sistema y de módulo

Pruebas de módulo, sistema y subsistema.

En base a los criterios acordados y definidos con anterioridad en reuniones de

socialización en los requerimientos funcionales, el cliente y el equipo de pruebas ejecutan las


pruebas estableciendo un criterio aceptación o una métrica que defina la admisión del sistema

de información durante esta fase. En el Anexo 6 se describe el guion de pruebas, en este caso

se ha optado por realizar una prueba sujeta a la matriz de trazabilidad.

5.6. Fase de Cierre

El propósito que tiene esta fase es validar que los reportes de errores en el instante del

despliegue hayan sido capturados todos los problemas relacionados al aplicativo. Esta

actividad debe ser ejecutada de manera recurrente durante toda la fase de implementación.

Finalmente, esta fase involucra las actividades necesarias para culminar el proyecto.

Esta fase incluye actualización de toda la información relacionada con el proyecto. Se liberan

los recursos tecnológicos y recursos humanos que han intervenido a lo largo de la vida del

proyecto para la construcción del Sistema de Información.


Capítulo 2

Resultados

En lo largo de la vida de un proyecto es necesario elaborar métricas que puedan

evaluar el desempeño del equipo de trabajo en contraste con la necesidad de la Unidad

Educativa “La Colina”. Realizar la ejecución del proyecto con el objetivo de implementar los

controles necesarios para la administración de los procesos académicos requiere de

documentación, obtener una métrica que valide el cumplimiento de las fechas comprometidas

de los hitos importantes en el cronograma. Para esto se ha elaborado una tabla y un diagrama

que refleja la idea de la métrica.

Es importante recalcar que en proyectos con otro tipo de clientes el no cumplir con lo

planificado puede caer en temas de penalizaciones ya que implica un coste adicional. Es decir,

este cuadro es muy importante y crítico para gestionar correctamente un proyecto.

Tabla 6. Resumen de Métricas del Proyecto

Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Fecha 16/feb/2016

Objetivo: Construir un sistema de información orientado a la gestión de procesos académico, cuya finalidad es brindar soporte a la unidad educativa en la gestión y automatización de los procesos que se realizan de forma manual, mediante el uso de una

interfaz para aplicar toda la investigación con herramientas informáticas de código abierto.

Tutor del proyecto: Franz del Pozo Tesista

Rubén A. Tubón y Elizabeth M. Sampedro

Comienzo Previsto: 02/nov/2015 Comienzo Real 02/nov/2015

Fin Previsto: 08/feb/2016 Fin Real 12/feb/2016

Presupuesto Planificado: $22.199,52 % de Desviación Tiempo: 2,04%

Presupuesto Ejecutado: $22.199,52 Esfuerzo Ejec. RRHH ( h/h) $125,00

Presup. TOTAL Planificado: $22.199,52 Presupuesto Ejec. h/h (AC) $22.199,52

Tipo Proyecto Académico Esfuerzo Plan. A la fecha (h/h) $22.324,52

Ciclo de Vida Normal Etapa Actual SDLC: 6. Fase de Cierre

Etapa Actual SDLC: 6. Fase de Cierre


Tabla 7. Hitos del Proyecto

Hitos del Proyecto

No. Hito

% Avance

Fecha Planificada

Fecha Real

Observaciones

1 Fase de Inicio Plan de Tesis Aprobado 100,00% 02/nov/2015 02/nov/201

5

2 Fase de Análisis - Matriz de Trazabilidad 100,00% 23/dic/2015 23/dic/201

5 304

3 Fase de Diseño - Arquitectura Integrada del sistema 100,00% 04/ene/2016 04/ene/201

6 72

4 Fase de Construcción - Sistema implementada en la infraestructura 100,00% 01/feb/2016

01/feb/2016 168

5 Fase de Pruebas - Guión de Pruebas ejecutado 100,00% 08/feb/2016

12/feb/201

6 48

6 Fase de Cierre - Defensa del Proyecto - - -

El cuadro anterior es muy importante para poder elaborar métricas de desempeño en

cada hito en las diferentes fases y medir el tiempo con metodologías de la ingeniería del

software, es por esta razón que el primer paso corresponde a identificar todos los hitos que

intervienen en la vida del proyecto. Se ha registrado una estimación relacionada a los tiempos

de cada actividad.

El cálculo de la desviación la ejecutaremos con una fórmula simple:

𝑑𝑒𝑠𝑣𝑖𝑎𝑐𝑖ó𝑛 =(𝑡𝑖𝑒𝑚𝑝𝑜𝑒𝑗𝑒𝑐𝑢𝑡𝑎𝑑𝑜− 𝑡𝑖𝑒𝑚𝑝𝑜𝑝𝑙𝑎𝑛𝑖𝑓𝑖𝑐𝑎𝑑𝑜)

𝑡𝑖𝑒𝑚𝑝𝑜𝑒𝑗𝑒𝑐𝑢𝑡𝑎𝑑𝑜

Con la información que acabamos de obtener se ha obtenido las siguientes métricas:

Tabla 8. Monitoreo de Hitos del Proyecto

Monitoreo del Proyecto en Tiempo

FECHA HH PLANIF. HH EJEC. % Desv.

02 Nov-02 Nov 8,00 8,00 0,00%

03 Nov-23 Dic 304,00 304,00 0,00%

24 Dic-04 Ene 72,00 72,00 0,00%

02 Dic-06 Dic 168,00 168,00 0,00%

09 Dic-13 Dic 48,00 52,00 7,69%


Figura 12. Monitoreo de Esfuerzos de Hitos del Proyecto

El monitoreo del esfuerzo del proyecto es importante para validar las desviaciones en

el proyecto. Para proyectos con temas contractuales de por medio es importante realizar este

ejercicio semanalmente. Sin embargo, hemos hecho una métrica general para toda la vida del

proyecto, ya que no se puede contar con un Líder de Proyecto dedicado para evaluar

semanalmente con esta actividad y finalmente el perfil del proyecto está orientado al

desarrollo del proyecto y no a la gestión.

Tabla 9. Desviación de Hitos del Proyecto

Monitoreo-Esfuerzo

FECHA Desviación

02 Nov-02 Nov 0,00%

03 Nov-23 Dic 0,00%

24 Dic-04 Ene 0,00%

02 Dic-06 Dic 0,00%

09 Dic-13 Dic 7,69%

8,00

304,00

72,00

168,00

48,00

8,00

304,00

72,00

168,00

52,00

-

50,00

100,00

150,00

200,00

250,00

300,00

350,00

02 Nov-02 Nov 03 Nov-23 Dic 24 Dic-04 Ene 02 Dic-06 Dic 09 Dic-13 Dic

Monitoreo en Esfuerzo

HH PLANIF. HH EJEC.


Figura 13. Monitoreo en Tiempo del Proyecto

La desviación en la fase de Pruebas se fundamenta en la estimación del tiempo que ha

requerido ejecutar el guion de pruebas completo del sistema.

0,00%

0,00% 0,00% 0,00%

7,69%

0,00%

10,00%

20,00%

30,00%

02 Nov-02 Nov 03 Nov-23 Dic 24 Dic-04 Ene 02 Dic-06 Dic 09 Dic-13 Dic

Monitoreo en Tiempo

Desviación


Capítulo 3

Discusión

En el apartado anterior es importante destacar que durante las primeras fases ha

existido un control y planificación adecuada conforme a los resultados obtenidos, y se indica

claramente en la gráfica de desviaciones la figura # y la tabla #, donde se resalta el valor

agregado de tener una desviación menor a diez, el esfuerzo adicional a nivel contractual

representa costo adicional no planificado que debe ser cubierto por el cliente y en otros casos

tiene una acción de penalización sobre los ejecutores del proyecto, la desviación de 7,69 que

es un valor de cierta forma aceptable, teniendo en cuenta que se trata de una fase .

Conclusiones

El diseño y construcción de un sistema con herramientas de código fuente

abierto, permite automatizar procesos de administración académica. Las

herramientas de código fuente abierto son adecuadas para instituciones que

carecen de recursos económicos.

Desarrollar un sistema parametrizable genera la adaptabilidad de diferentes

lineamientos gubernamentales e institucionales al sistema.

Controlar un proyecto mediante métricas y ponderaciones de esfuerzos de

forma periódica en las diferentes fases del proyecto, genera niveles de

aceptación excelentes para nuestros clientes.

Recomendaciones

Analizar los resultados de las desviaciones del proyecto para aprender sobre

hallazgo de errores cometidos e implementar buenas prácticas sobre estos


errores.

Usar componentes alineados a un solo paradigma de desarrollo para obtener un

bajo costo en desarrollo y adaptaciones para obtener nuevas funcionalidades

sobre el producto que se planea construir.

Validar las definiciones de equilibrio entre la seguridad del sistema, la

usabilidad del sistema y el rendimiento del aplicativo.


BIBLIOGRAFIA

1. BAIJU M. (2009). A comprehensive guide to zope component architecture.

Recuperado: diciembre 1, 2015, de GNU Free Documentation License Sitio web:

http://www.muthukadan.net/docs/zca-es.pdf

2. BAIJU M. (2005). Zope3 in 30 minutes. Recuperado: noviembre 15, 2015, de GNU

GPL Sitio web: http://zqpythonic.qiniucdn.com/data/20051008083644/index.html

3. BOIKO, B. (2004). Content Management bible. Recuperado: diciembre 30, 2015, de

ohn Wiley & Sons, Inc. Sitio web: http://www.wiley.com/

4. ISMINI Z. (2012). Z3LAB. Recuperado: noviembre 10, 2015, de Nikos Dimitriadis

and Associates Sitio web: http://z3lab.gr/wordpress_d/?p=1

5. KUCHLING, A. (2006). zodb/zeo Programming Guide. Recuperado: diciembre 24,

2015, de ZODB Sitio web: http://www.zodb.org/

6. MARTY A. (2010). Pro Python. Recuperado: octubre 10, 2015, de Python Sitio web:

http://www.apress.com/corporate-sales/

7. MINISTERIO DE EDUCACIÓN. (2015). Distribución de asignaturas por grado de

EGB. Recuperado: enero 20, 2016, de Ministerio de Educación Sitio web:

http://educacion.gob.ec/educacion-general-basica/


8. RAÚL G. (2010). Python Para Todos. Recuperado: octubre 20, 2015, de Creative

Commons Reconocimiento 2.5 España Sitio web: http://mundogeek.net/tutorial-

python/

9. REAL ACADEMIA ESPAÑOLA. (2016). Real Academia Española. Recuperado:

noviembre 30, 2015, de Real Academia Española Sitio web: http://www.rae.es/

10. SNNA. (S.F.). SNNA.GOB.EC. Recuperado: febrero 10, 2016 de snna.gob.ec:

http://www.snna.gob.ec/dw-pages/Descargas/instructivo%20ENES%20new.pdf

11. SILBERSCHATZ, A., KORTH, H., AND SUDARSHAN, S.. (2006). Database

Systems Concepts. Recuperado: diciembre 6, 2015, de McGraw-Hill Sitio web:

http://www.mcgraw-hill.com/

12. SOMMERVILLE I. (2005). Ingeniería Del Software. Recuperado: noviembre 6, 2015,

de Pearson Educación Sitio web: http://gateway-bayern.de/

13. VON W. (2008). Web component Development with zope 3. Recuperado: diciembre

6, 2015, de Springer Publishing Company Sitio web: http://www.springerpub.com/

14. ZOPE DEVELOPERS COMMUNITY. (2008). The Zope 3 BOOK. Recuperado:

diciembre 2, 2015, de Creative Commons Attribution-ShareAlike Sitio web:

http://muthukadan.net/docs/tzb.html


15. ZOPE FOUNDATION. (2011). ZOPE.ORG. RECUPERADO: diciembre 2, 2015, de

Zope Sitio web: http://www.zope.org/

16. W3C. (S.F.). (2016). Recuperado: enero 19, 2015, de W3C.com:

http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb


Anexos

Anexo 1: UCE_FING_ING_INF_PLAN DE TESIS APROBADO.

Figura 14. Evidencia de Aprobación de Plan de Tesis.

Figura 15. Evidencia de Tabla Oficial de Planes del Proyecto Integrador Aprobado.

Anexo 2: UCE_FING_ING_INF_ FORMATO DE CONTROL DE

DOCUMENTACIÓN.


Tabla 10. Encabezado Principal del Control de Documentación.

Proyecto Sistema de Gestión de Procesos Académicos de la Unidad Educativa

“La Colina”

Entregable <Entregable de cada fase>

Autor Rubén A. Tubón y Elizabeth M. Sampedro

Fecha DD/MM/AAAA

REGISTRO DE CAMBIOS

Tabla 11. Tabla de Detalles del Control de Documentación.

Versión

No.

Fecha del Cambio

Descripción Causa del

Cambio

No.

Pagina

Ejecutor del Cambio

CONTROL DE DISTRIBUCIÓN

Tabla 12. Tabla de Revisores del Control de Documentación

Institución Nombre y Apellidos

<UCE.>, <“LA COLINA”> <Nombre Apellido1 Apellido2>

Anexo 3: UCE_FING_ING_INF_ ACTA FIRMADA DE INICIO DE PROYECTO.


Anexo 4: UCE_FING_ING_INF_DIAGRAMA DE CLASES.

Figura 16. Diagrama de Clases del Sistema.



Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Diagrama de Clases del Sistema

Versión: 1.0

Autor(es): Rubén A. Tubón y

Anexo 5: UCE_FING_ING_INF_CASOS DE USO.

Figura 17. Casos de Uso, Configuración de Seguridad.


0..10..*

0..1

0..*

0..1

0..*

0..1

0..10..*

Aministrador

+

+

+

+

+

+

+

+

+

+

+

+

Crear_Modificar_Eliminar_Asignatura ()

Crear_Modificar_Eliminar_Horarios ()

Crear_Periodos ()

Crear_Año_escolar ()

Configurar_Seguridad_Sistema ()

Empaquetar_Base_Datos ()

Crear_Modificar_Eliminar_Ususarios ()

Crear_Modificar_Eliminar_Contactos ()

Crear_Modificar_Eliminar_Asignaturas ()

Asignar_Horario_asignatura ()

Asignar_Horario_Profesor ()

Asignar_Horario_estudiante ()

: void

: void

: void

: void

: void

: void

: void

: void

: void

: void

: void

: void

Usuario

-

-

-

-

codigo

nombre

apellido

password

: int

: char

: char

: int

Estudiante

-

-

sexo

procedencia

: char

: char

+ Buscar reporte Notas () : void

Profesor

-

-

sexo

procedencia

: char

: char

+

+

+

Registra Calificacion ()

Registra_Asistencia ()

Ingresa_Actividades ()

: void

: void

: void

Asignatura

-

-

codigo

nombre

: int

: char Horario

- codigo : int Año Escolar

-

-

codigo

año_lectivo

: int

: char

Periodo

-

-

codigo

nombre_periodo

: int

: char

Calificacion

-

-

codigo

calificacion

: int

: int

Actividad

-

-

-

codigo

nombre_actividad

porcentaje

: int

: char

: int

Escuela

-

-

-

nombre_escuela

direccion

año_fundacion

: char

: char

: int

Asistencia

-

-

codigo

Asiste

: int

: Boolean

Contacto

-

-

-

-

-

codigo

nombre

direccion

telefono

email

: int

: char

: char

: char

: char


Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Configurar seguridad del sistema

Versión: 1.0

Autor(es): Elizabeth M. Sampedro

Caso de Uso Configurar seguridad del sistema

Actores Administrador

Propósito Realiza la configuración de seguridad del sistema.

Resumen El Administrador ingresa y configura los datos de la escuela

Figura 18.Casos de Uso, Empaquetamiento de Base de Datos.

Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Empaquetar base de datos del sistema

Versión: 1.0


Caso de Uso Empaquetar base de datos del sistema


Propósito Realiza el proceso de empaquetar base datos del sistema.

Resumen El administrador ingresa al sistema y realiza el empaquetado de la base de datos esto con el fin de reducir espacio y rendimiento del sistema.

Figura 19. Casos de Uso, Parametrización de Años Escolares.


Administrador

Configurar seguridad del sistema

Administrador

Empaquetar base de datos del sistema


Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Crear Años escolares

Versión: 1.0


Caso de Uso Crear Años escolares


Propósito Realiza el proceso de creación de años escolares

Resumen El Administrador del sistema ingresa el nuevo año escolar de acuerdo al requerimiento de la escuela, debe ser en un año calendario actual.

Figura 20. Casos de Uso, Parametrización de Años Escolares.

Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Crear periodos escolares

Versión: 1.0


Crear Caso de Uso Crear periodos escolares


Propósito Realiza el proceso de creación de periodos escolares

Resumen El Administrador del sistema ingresa los periodos escolares en el año escolar ingresado, quimestres, bimestres, etc.

Figura 21. Casos de Uso, Creación de Usuarios.


Administrador

Crear Años escolares

Administrador

Crear periodos escolares


Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Crear usuarios

Versión: 1.0


Caso de Uso Crear usuarios


Propósito Realizar el proceso de creación de usuarios

Resumen El administrador realiza el proceso de creación de usuarios administradores, estudiantes y profesores.

Figura 22. Casos de Uso, Modificación de Usuarios.

Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Modificar usuarios

Versión: 1.0


Caso de Uso Modificar usuarios


Propósito Realizar el proceso de modificación de usuarios

Resumen El administrador realiza el proceso de modificación de usuarios administradores, estudiantes y profesores.

Administrador

Crea

Estudiante

Profesor

Administrador

Modificar

Estudiante

Profesor


Figura 23. Casos de Uso, Eliminar Usuarios.

Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Eliminar usuarios

Versión: 1.0


Caso de Uso Eliminar usuarios


Propósito Realizar el proceso de eliminación de usuarios

Resumen El administrador realiza el proceso de eliminación de usuarios administradores, estudiantes y profesores registrados en el sistema en caso de necesitar.

Figura 24. Casos de Uso, Crear Contactos.


Administrador

Eliminar

Estudiante

Profesor


Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Crear Contactos

Versión: 1.0


Caso de Uso Crear Contactos


Propósito Realizar el proceso de creación de contactos

Resumen El administrador realiza el proceso de creación de contactos de los estudiantes y profesores.

Figura 25. Casos de Uso, Modificar Contactos.

Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Modificar Contactos

Versión: 1.0


Caso de Uso Modificar Contactos


Propósito Realizar el proceso de modificación de contactos

Resumen El administrador realiza el proceso de modificación de contactos de los estudiantes y profesores.

Administrador

Crear

Contacto Estudiante

Contacto Profesor

Administrador

Modificar

Contacto Estudiante

Contacto Profesor


Figura 26. Casos de Uso, Eliminar Contactos.

Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Eliminar Contactos

Versión: 1.0


Caso de Uso Eliminar Contactos


Propósito Realizar el proceso de eliminación de contactos

Resumen El administrador realiza el proceso de eliminación de contactos de los estudiantes y profesores.

Figura 27. Casos de Uso, Parametrización de Asignaturas.

Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Ingresar Asignaturas

Versión: 1.0

Autor(es): Rubén A. Tubón

Caso de Uso Ingresar Asignaturas


Propósito Realizar el ingreso de Asignaturas

Resumen El Administrador realiza el proceso de ingreso de asignaturas de la escuela de acuerdo al año escolar.

Figura 28. Casos de Uso, Modificación de Asignaturas.


Administrador

Eliminar

Contacto Estudiante

Contacto Profesor

Administrador

Ingresar Asignaturas


Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Modificar Asignaturas

Versión: 1.0


Caso de Uso Modificar Asignaturas


Propósito Realizar la modificación de Asignaturas creadas

Resumen El Administrador realiza el proceso de modificación de las asignaturas de la escuela que están ya creadas de acuerdo al año escolar.

Figura 29. Casos de Uso, Eliminar Asignaturas.

Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Eliminar Asignaturas

Versión: 1.0


Caso de Uso Eliminar Asignaturas


Propósito Realizar la eliminación de Asignaturas creadas

Resumen El Administrador realiza el proceso de eliminación de las asignaturas de la escuela que están ya creadas en caso de necesitar hacer esto.

Figura 30. Casos de Uso, Ingreso de Horarios.


Administrador

Modificar Asignaturas

Administrador

Eliminar Asignaturas


Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Ingresar horarios

Versión: 1.0


Caso de Uso Ingresar horarios


Propósito Realiza el ingreso de un horario.

Resumen El administrador realiza el ingreso de un horario de una determinada clase.

Figura 31. Casos de Uso, Modificar Horarios.

Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Modificar horarios

Versión: 1.0


Caso de Uso Modificar horarios


Propósito Realiza la modificación de un horario.

Resumen El administrador realiza la modificación de un horario de una determinada clase.

Figura 32. Casos de Uso, Eliminar Horarios.


Administrador

Ingresa Horarios

Administrador

Modica Horarios


Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Eliminar horarios

Versión: 1.0


Caso de Uso Eliminar horarios


Propósito Realiza la eliminación de un horario.

Resumen El administrador realiza la eliminación de un horario de una determinada clase.

Figura 33. Casos de Uso, Asignación Horarios y Asignaturas.

Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Asignar horario a una asignatura

Versión: 1.0


Caso de Uso Asignar horario a una asignatura


Propósito Realizar la asignación de horario a una asignatura.

Resumen El administrador realiza la asignación de los horarios a las asignaturas ya creadas.

Figura 34. Casos de Uso, Asignaciones Horario y Profesor.


Administrador

Elimina Horarios

Administrador

Asignar horario asignatura



Nombre: Asignar horario a profesor

Versión: 1.0


Caso de Uso Asignar horario a profesor


Propósito Realiza la asignación de un horario a un profesor..

Resumen El administrador realiza la asignación de los horarios a los profesores de acuerdo a las asignaturas que imparten.

Figura 35. Casos de Uso, Asignación Horiarios y Estudiantes.


Nombre: Asignar horario a estudiantes

Versión: 1.0


Caso de Uso Asignar horario a estudiantes


Propósito Realiza la asignación de un horario a un estudiante

Resumen El administrador realiza la asignación de los horarios a los estudiantes de acuerdo a los cursos y materias que son tomadas por el estudiante

Figura 36. Casos de Uso, Registro de Calificaciones.


Administrador

Asignar horario profesor

Administrador

Asignar horario estudiante



Nombre: Registro de Calificaciones

Versión: 1.0


Caso de Uso Registro de Calificaciones

Actores Profesor

Propósito Realizar el proceso de registro de calificaciones.

Resumen Realizar el proceso de registro de calificaciones de los estudiantes de una determinada materia y para una actividad

Figura 37. Casos de Uso, Ingreso de Actividades Curriculares.


Nombre: Ingreso de actividades

Versión: 1.0


Caso de Uso Ingreso de actividades

Actores Profesor

Propósito Realiza el proceso de ingreso de Actividades en una determinada materia.

Resumen El profesor ingresa actividades y asigna un puntaje numérico para la calificaron de cada asignatura que le corresponde impartir.

Figura 38. Casos de Uso, Control de Asistencia de Estudiantes.


Profesor

Registra calificaciones

Profesor

Ingreso de actividades



Nombre: Control de asistencia del estudiantes

Versión: 1.0


Caso de Uso Control de asistencia del estudiantes

Actores Profesor

Propósito Realizar el control de asistencia de los estudiantes

Resumen Realizar el proceso de registro de asistencia de los estudiantes de un determinado curso.

Figura 39. Diagrama de Secuencia, Configuraciones de Seguridad del Sistema.

Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Diagrama Secuencia Configurar seguridad del sistema

Versión: 1.0


Profesor

Controll de asistencia del estudiante

Configuracion Seguridad

Otorga Permisos a los usuarios

Configura Permisos

Permite ingreso

Ingresa Usuario y Clave

Solicita Usuario y clave

Sistema

Administrador Usuarios

Otorga Permisos a los usuarios

Configura Permisos

Permite ingreso




Figura 40. Digrama de Secuencia, Empaquetar Base de Datos.

Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Diagrama Secuencia Empaquetar base datos

Versión: 1.0


Figura 41. Diagrama de Secuencia, Ingreso de Asignaturas.


Empaquetar base datos

Informa usuario resultado

Envia Resultado empaquetar

Empaqueta Base Datos

Ingresa Sistema

Envia indicacion para empaquetar BD

Permite ingreso



Sistema

Administrador

Base Datos

Informa usuario resultado

Envia Resultado empaquetar

Empaqueta Base Datos

Ingresa Sistema

Envia indicacion para empaquetar BD

Permite ingreso




Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Diagrama Secuencia Ingresar Asignaturas

Versión: 1.0


Figura 42. Diagrama de Secuencia, Modificar Asignaturas.


Ingresar Asignaturas

Incorrecto envia mensaje falla

Registra asignatura

Si es correcto

registro exito

Envia Asignatura

Sistema

Administrador

AignaturasVerifica Asignatura


Registra asignatura

Si es correcto

registro exito

Envia Asignatura


Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Diagrama Secuencia Modificar Asignaturas

Versión: 1.0


Figura 43. Diagrama de Secuencia, Eliminar Asignatura.


Modificar Asignaturas

Incorrecto no existe asignatura

Registra cambio

Si es correcto

registro exito

Envia Asignatura

Sistema

Administrador

AignaturasAsignatura Existente


Registra cambio

Si es correcto

registro exito

Envia Asignatura


Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Diagrama Secuencia Eliminar Asignaturas

Versión: 1.0


Figura 44. Diagrama de Secuencia, Ingresar Actividades Curriculares.


Eliminar Asignaturas


Elimina

Si es correcto

registro exito

Envia Asignatura

Sistema

Administrador

AignaturasAsignatura Existente


Elimina

Si es correcto

registro exito

Envia Asignatura


Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Diagrama Secuencia Ingresar Actividades

Versión: 1.0


Figura 45. Diagrama de Secuencia, Crear Años Escolares.


Ingreso de actividades

Guardado exitoso

Guarda Actividad y Puntaje

Ingresa Puntaje Actividad

Ingresa Actividad

Envia nombre asignatura

Nombre Asignatura

Busca Asignatura

Sistema

Profesor

Asignatura Actividad

Guardado exitoso

Guarda Actividad y Puntaje

Ingresa Puntaje Actividad

Ingresa Actividad

Envia nombre asignatura

Nombre Asignatura

Busca Asignatura


Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Diagrama Secuencia Crear Años escolares

Versión: 1.0


Figura 46. Diagrama de Secuencia, Crear Periodos Escolares.


Crear años escolares

registro exito

Incorrecto Envia mensaje falla

Registra

Verifica Año correcto

Envia nuevo año escolar

Sistema

Administrador

Años esolaresAño actual

registro exito

Incorrecto Envia mensaje falla

Registra

Verifica Año correcto

Envia nuevo año escolar


Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Diagrama Secuencia Crear Periodos escolares

Versión: 1.0


Figura 47. Diagrama de Secuencia, Registro de Calificaciones.


Crear periodos escolares


Registra periodo

Si es correcto

registro exito

Envia nuevo periodo escolar

Sistema

Administrador

Periodo esolarVerifica Periodo


Registra periodo

Si es correcto

registro exito

Envia nuevo periodo escolar


Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Diagrama Secuencia Registro de Calificaciones

Versión: 1.0


Figura 48. Diagrama de Secuencia, Control de Asistencia.


Registro de Calificaciones

Guardado exitoso

Guarda

Ingresa Calificaciones

Sistema

Profesor

Calificaciones

Guardado exitoso

Guarda

Ingresa Calificaciones


Sistema de Gestión de Procesos Académicos de la Unidad Educativa “La Colina” Nombre: Diagrama Secuencia Control de Asistencia

Versión: 1.0


Control de asistencia

Actualizacion Correcta

Actualiza asistencia

Registra Asistencia

Envia nombre estudiante

Nombre Estudiante

Busca Estudiante

Sistema

Profesor

BD Estudiantes

Actualizacion Correcta

Actualiza asistencia

Registra Asistencia

Envia nombre estudiante

Nombre Estudiante

Busca Estudiante


Anexo 6: UCE_FING_ING_INF_MATRIZ DE DE TRAZABILIDAD Y GUION DE PRUEBAS.

Tabla 13. Matriz de Trazabilidad – Guion de Pruebas.

Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a

Descripción de la Prueba

Resultados Esperados

Trazabilidad

Sistema Escolar

Caso de

Prueba 1

Ejecutado

Manual

Alta Parametr

izar Escuela

1.- Aplicativo disponible y funcionando en test. 2.- Usuario y Claves de acceso al aplicativo 3.- Se hayan implementado las siguientes soluciones: - Parámetros de datos demográficos

Online

Media Datos

Demográficos

Administrador

08/02/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrización de datos de la Escuela en el módulo Escuela --> Personalizar --> Nombre de la escuela e ingresamos los datos de la escuela y su logo y presionamos "Enviar".

1. Ingreso exitoso. 2. Parametrización exitosa de la escuela.

N8


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

Sistema Escolar

Caso de

Prueba 2

Ejecutado

Manual

Alta Abrir

nuevo año escolar

1.- Aplicativo disponible y funcionando en test 2.- Usuario y Claves de acceso al aplicativo

Online

Media Año

Escolar Administr

ador 08/02

/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrización de datos. Ir al vínculo Escuela --> Agregar --> Año Escolar e ingresar el Nombre del Año Escolar y parametrizar el día de inicio del año escolar y el día del fin del año escolar. Finalmente presionamos "Enviar

1. Ingreso exitoso. 2. Parametrización exitosa del año escolar.

Configuración Previa


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

Sistema Escolar

Caso de

Prueba 3

Ejecutado

Manual

Alta Establece

r período(s) escolar(es)

1.- Aplicativo disponible y funcionando en test 2.- Usuario y Claves de acceso al aplicativo 3.- Año escolar activo

Online

Media Año

Escolar Administr

ador 08/02

/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrización de datos. Ir al vínculo Escuela --> <Año parametrizado> --> Períodos --> Agregar --> Período e ingresar el Nombre del Período y parametrizar el día de inicio del período y el día del fin del período. Finalmente presionamos "Enviar

1. Ingreso exitoso. 2. Parametrización exitosa del período.



Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

Sistema Escolar

Caso de

Prueba 4

Ejecutado

Manual

Alta Establece

r curso(s)


Online

Media Año

Escolar Administr

ador 08/02

/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrización de datos. Ir al vínculo Escuela --> <Año parametrizado> --> Cursos --> Agregar --> Curso e ingresar el Nombre del curso, la descripción, el parámetro que lo identifica de manera única y las horas semanales que deben ser dictados estos cursos. Finalmente

1. Ingreso exitoso. 2. Parametrización exitosa del curso.



Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

presionamos "Enviar"

Sistema Escolar

Caso de

Prueba 5

Ejecutado

Manual

Alta

Parametrizar de Niveles Escolares


Online

Media Año

Escolar Administr

ador 08/02

/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrización de datos. Ir al vínculo Escuela --> Personalizar --> Niveles de Grado --> Agregar --> Nivel e ingresar el Nombre del Nivel y presionamos "Enviar". Finalmente confirmamos

1. Ingreso exitoso. 2. Parametrización exitosa de los niveles de grado.



Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

la acción presionando "Hecho".

Sistema Escolar

Caso de

Prueba 6

Ejecutado

Manual

Alta Parametr

izar Grupos


Online

Media Año

Escolar Administr

ador 08/02

/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrización de datos. Ir al vínculo Escuela --> <Año parametrizado> --> Grupos --> Agregar --> Grupo e ingresar el Nombre del grupo y presionamos "Enviar". Subsecuentemente podemos

1. Ingreso exitoso. 2. Parametrización exitosa de grupos.



Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

asociar a los integrantes y su administrador. Finalmente presionamos "Hecho".

Sistema Escolar

Caso de

Prueba 7

Ejecutado

Manual

Alta

Parametrización de datos demográficos para personas

1.- Aplicativo disponible y funcionando en test 2.- Usuario y Claves de acceso al aplicativo 3.- Año escolar activo (opcional)

Online

Media Año

Escolar Administr

ador 08/02

/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrización de datos. Ir al vínculo Información demográfica y personal --> Información demográfica y personal --> Agregar --> Campo texto, Campo número, Entero, Campo descripción,

1. Ingreso exitoso. 2. Parametrización exitosa de los datos demográficos requeridos para una persona.



Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

Campo Fecha, Capo Booleano, Campo Lista e ingresar los datos solicitados y presionamos "Enviar". Una vez parametrizados los campos necesarios para nuestro datos demográficos seleccionamos "Hecho".

Sistema Escolar

Caso de

Prueba 8

Ejecutado

Manual

Alta Ingreso

de Personas

1.- Aplicativo disponible y funcionando en test 2.- Usuario y Claves de acceso al aplicativo 3.- Datos demográficos parametrizados

Online

Media Año

Escolar Administr

ador 08/02

/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrización de datos. Ir al vínculo Escuela --> Personalizar --

1. Ingreso exitoso. 2. Parametrización exitosa de los datos demográficos requeridos para una persona.

N1, N2


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

4.- Niveles definidos 5.- Grupos de personas definidos 6.- Año escolar activo

> Datos Demográficos --> Agregar --> Campo texto, Campo número, Entero, Campo descripción, Campo Fecha, Capo Booleano, Campo Lista e ingresar los datos solicitados y presionamos "Enviar". Una vez parametrizados los campos necesarios para nuestro datos demográficos seleccionamos "Hecho".


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

Sistema Escolar

Caso de

Prueba 9

Ejecutado

Manual

Alta

Definiciones de Sistema de Puntuación / Sistema de Asistencia


Online

Media Año

Escolar Administr

ador 08/02

/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrización de datos. Ir al vínculo Escuela --> Personalizar --> Sistema de Puntuación --> Agregar --> Sistema de Puntuación / Sistema de Asistencia e ingresar los datos solicitados y presionamos "Enviar". Una vez parametrizados los campos necesarios para nuestro datos

1. Ingreso exitoso. 2. Parametrización exitosa de los sistemas de puntuación y asistencia.

N3, N4, N5


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

demográficos seleccionamos "Hecho".

Sistema Escolar

Caso de

Prueba 10

Ejecutado

Manual

Alta Establece

r Horarios


Online

Media Año

Escolar Administr

ador 08/02

/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrización de datos. Ir al vínculo Escuela --> <Año parametrizado> --> Horarios --> No hay horarios a configurar --> Agregar --> Horario e ingresar el Nombre del horario y

1. Ingreso exitoso. 2. Parametrización exitosa del horario.

N3, N5


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

presionamos "Siguiente", luego presionamos en "Días de la semana", luego damos clic en "A la misma hora de cada día", en el siguiente paso parametrizamos las horas fijas del horario y damos clic en "Siguiente". La siguiente parametrización es importante para validar y enlazar los Horarios con los Períodos y damos clic en "Tienen nombres" en el siguiente cuadro


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

ingresamos el nombre de los períodos y damos clic en "Siguiente". El asistente nos guiará para seguir parametrizando el horario para lo cual presionamos en "Igual". Presionamos "Siguiente". Luego enlazamos con el control de la asistencia y damos clic en "Si". Indicamos los períodos de control para cada día y damos clic en "Siguiente". Finalmente presionamos "Hecho"


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

Sistema Escolar

Caso de

Prueba 11

Ejecutado

Manual

Alta Establece

r Secciones

1.- Aplicativo disponible y funcionando en test 2.- Usuario y Claves de acceso al aplicativo 3.- Año escolar activo 4.- Cursos definidos 5.- Grupos establecidos 6.- Sistema de puntuación definido 7.- Horarios definidos

Online

Media Año

Escolar Administr

ador 08/02

/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrización de datos. Ir al vínculo Escuela --> <Año parametrizado> --> Secciones --> Agregar --> Sección e ingresar el Nombre de la sección si no elegimos el nombre se autogenerará uno en función de los parámetros seleccionados, luego seleccionamos el curso y el

1. Ingreso exitoso. 2. Parametrización exitosa de la sección.

N3


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

período de inicio y el período final y presionamos "Enviar". Subsecuentemente podemos asociar al curso los instructores, estudiantes, ubicaciones y el equipamiento, horario, sistemas de puntuación y asistencia. Finalmente presionamos "Hecho".

Sistema Escolar

Caso de

Prueba 12

Ejecutado

Manual

Alta

Establecer Categorías de Actividades

1.- Aplicativo disponible y funcionando en test 2.- Usuario y Claves de acceso al aplicativo

Online

Media Año

Escolar Administr

ador 09/02

/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrizaci

1. Ingreso exitoso. 2. Parametrización exitosa de las categorías de calificación. N4, N6


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

3.- Año escolar activo

ón de datos. Ir al vínculo Escuela --> Personalizar --> Categoría de actividades --> Agregar --> Categoría nueva e ingresar los datos solicitados y presionamos "Enviar". Una vez parametrizados los campos necesarios para nuestro datos demográficos seleccionamos "Hecho".


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

Sistema Escolar

Caso de

Prueba 13

Ejecutado

Manual

Alta

Establecer Plantillas de calificaciones

1.- Aplicativo disponible y funcionando en test 2.- Usuario y Claves de acceso al aplicativo 3.- Año escolar activo 4.- Categorías de actividades establecidas

Online

Media Año

Escolar Administr

ador 09/02

/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrización de datos. Ir al vínculo Escuela --> <Año parametrizado> --> Plantillas de hojas de informe --> Agregar --> Plantilla de hoja de reporte e ingresar el Nombre de la plantilla y presionamos "Enviar". 3. El siguiente paso es ponderar las categoría para

1. Ingreso exitoso. 2. Parametrización exitosa de las plantillas de calificación.

N4, N6


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

esto nos dirigimos a Configuración --> Ponderación de categoría, en esta pantalla parametrizamos el peso que tiene cada Categoría de actividades del caso de prueba 12. Subsecuentemente podemos asociar Informes de Actividades a la plantilla en Añadir --> Informe de Actividades, luego llenamos los datos mandatorios solicitados y seleccionamo


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

s "Enviar".

Sistema Escolar

Caso de

Prueba 14

Ejecutado

Manual

Alta

Establecer Hojas de Informe Instaladas

1.- Aplicativo disponible y funcionando en test 2.- Usuario y Claves de acceso al aplicativo 3.- Año escolar activo 4.- Periodos parametrizados 5.- Plantillas de calificaciones establecidas

Online

Media Año

Escolar Administr

ador 09/02

/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrización de datos. Ir al vínculo Escuela --> <Año parametrizado> --> Plantillas de hojas de informe -->

1. Ingreso exitoso. 2. Parametrización exitosa del informe de calificaciones para el año establecido.

N4, N6


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

Agregar --> Hojas de informe instaladas e ingresar el Nombre de la plantilla, los datos referentes a los periodos, la plantilla y presionamos "Enviar".

Sistema Escolar

Caso de

Prueba 15

Ejecutado

Manual

Alta

Establecer Esquema de Libreta de Notas

1.- Aplicativo disponible y funcionando en test 2.- Usuario y Claves de acceso al aplicativo 3.- Año escolar activo 4.- Periodos parametrizados 5.- Plantillas de calificaciones establecidas

Online

Media Año

Escolar Administr

ador 09/02

/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrización de datos. Ir al vínculo Escuela --> Personalizar --> Esquema de Libreta de Notas --> Agregar --> Columna de

1. Ingreso exitoso. 2. Parametrización exitosa de los reportes de calificaciones para el año establecido.

N4, N6


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

cuadrícula / Elemento del esquema e ingresar los datos solicitados y presionamos "Enviar". Una vez parametrizados los campos necesarios para nuestros reportes de notas seleccionamos "Hecho".

Sistema Escolar

Caso de

Prueba 16

Ejecutado

Manual

Alta Tomar

Asistencia

1.- Aplicativo disponible y funcionando en test 2.- Usuario y Claves de acceso al aplicativo 3.- Parametrizaciones definidas por el

Online

Media Diario Profesor 10/02

/2016

1. Ingresar con las credenciales del profesor. 2. Ingresar al módulo del diario. Ir al vínculo Diario --> Vista --> Asistencia y seleccionamos los datos con los que se requiere el

1. Ingreso exitoso. 2. Ingreso exitoso de la asistencia de los estudiantes.

N5


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

administrador

ingreso de la asistencia. Se ingresa la asistencia de los estudiantes y presionamos "Guardar".

Sistema Escolar

Caso de

Prueba 17

Ejecutado

Manual

Alta

Ingreso de Calificaciones

1.- Aplicativo disponible y funcionando en test 2.- Usuario y Claves de acceso al aplicativo 3.- Parametrizaciones definidas por el administrador

Online

Media Libro

de Notas Profesor

10/02/2016

1. Ingresar con las credenciales del profesor. 2. Ingresar al módulo del diario. Ir al vínculo Libro de Notas y seleccionamos los datos con los que se requiere el ingreso de las notas. Se ingresan las notas de los estudiantes y presionamos "Guardar".

1. Ingreso exitoso. 2. Ingreso exitoso de notas de los estudiantes.

N4


Sistema

Tipo de

Prueba

Estado de

Prueba

Modo de

Ejecución

Prioridad

Nombre del Test

Precondiciones

Tipo de

Proceso

Complejidad

Modulo Rol

Fecha Ejecució

n Estimad

a



Trazabilidad

Sistema Escolar

Caso de

Prueba 18

Ejecutado

Manual

Alta Promoció

n de Estudiantes

1.- Aplicativo disponible y funcionando en test 2.- Usuario y Claves de acceso al aplicativo 3.- Año escolar activo 4.- Notificación de cierre de año

Online

Media Año

Escolar Administr

ador 10/02

/2016

1. Ingresar con las credenciales del administrador. 2. Ingresar al módulo de la parametrización de datos. Ir al vínculo Escuela --> <Año parametrizado> --> Grupos --> Estudiantes 3. Buscar el estudiante a promover 4. Seleccionamos el vínculo del nombre o apellido. 5. Actualizamos el grado

1. Ingreso exitoso. 2. Actualización exitosa del grado

N3


Anexo 7: UCE_FING_ING_INF_CRONOGRAMA DEL PROYECTO.

sistema de gestiÓn de procesos acadÉmicos de … · 2.3. arquitectura orientada a componentes ......

Documents