FACULTAD DE INGENIERIA EN SISTEMAS...A mi esposo Alexis por haber aceptado ser mi compañero de...

ESCUELA POLITÉCNICA NACIONAL

FACULTAD DE INGENIERIA EN SISTEMAS

DESARROLLO DEL SISTEMA DE GESTIÓN ACADÉMICA Y

ADMINISTRATIVA VÍA WEB PARA EL COLEGIO LA PROVIDENCIA

PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN

SISTEMAS INFORMÁTICOS Y DE COMPUTACIÓN

GABRIELA FERNANDA CRIOLLO BILBAO

[email protected]

DIEGO PAUL QUINTUÑA CHURO

[email protected]

DIRECTOR: ING. RAÚL CÓRDOVA

[email protected]

Quito, Octubre 2012

DECLARACIÓN

Nosotros, Gabriela Fernanda Criollo Bilbao y Diego Paúl Quintuña Churo declaramos

bajo juramento que el trabajo aquí descrito es de nuestra autoría; que no ha sido

previamente presentado para ningún grado o calificación profesional; y, que hemos

consultado las referencias bibliográficas que se incluyen en este documento.

A través de la presente declaración cedemos nuestros derechos de propiedad

intelectual correspondiente a este trabajo, a la Escuela Politécnica Nacional, según

lo establecido por la Ley de Propiedad Intelectual, por su Reglamento y por la

normatividad institucional vigente.

Gabriela Fernanda Criollo

Bilbao

Diego Paúl Quintuña

Churo

CERTIFICACIÓN

Certifico que el presente trabajo fue desarrollado por Gabriela Fernanda Criollo y

Diego Paúl Quintuña Churo, bajo mi supervisión.

Ing. Raúl Córdova

DIRECTOR DE PROYECTO

AGRADECIMIENTO

A Dios por tantos milagros que hizo en mi vida, por ser el más generoso y darme la

fortaleza para seguir mi camino y nunca rendirme.

A un ángel que desde el cielo me dio las fuerzas necesarias para seguir y que

siempre confió en que llegaría a cumplir esta meta, mi abuelita querida, Beatriz

Argoti, aunque no estés aquí, siempre te llevaré en mi corazón.

A mis padres Guillermo y Betty quienes con mucho esfuerzo y amor me han

apoyado en el camino de mi vida, por ser los mejores padres y darme la oportunidad

de superarme, porque lo que soy ahora es gracias a ustedes.

A mi esposo Alexis por haber aceptado ser mi compañero de vida, en la que hemos

aprendido a ser una familia y caminar juntos de la mano, por el amor y esfuerzo que

ha puesto para conservar nuestro hogar.

A tesoro más preciado que Dios me regaló, mi hijita Brithany por ser la alegría de mi

vida y la razón por la cual quiero ser mejor cada día.

A mis hermanas Karina y Mishel, y a toda mi familia por darme siempre ánimos y

confiar en mí.

A mi compañero de tesis Diego por todo el apoyo que me ha brindado ya que más

que un compañero llegó a ser un gran amigo, de esos que nunca se olvidan, gracias

por ser parte de este sueño.

A mi director de tesis Ingeniero Raúl Córdova por los conocimientos y apoyo

brindado en nuestra vida estudiantil y en el desarrollo de nuestro Proyecto de

Titulación.

A Sofy R., Anita G. y Cris C. por cumplir maravillosamente el gran papel de mejores

amigos y estar conmigo en los buenos y malos momentos.

A todos los que pusieron un granito de arena e hicieron que este sueño pueda

lograrse.

Gaby

AGRADECIMIENTO

A Dios, por el segundo de vida que me da y con ello la oportunidad de soñar.

A mis Padres José y Pilar, por enseñarme tantos valores que hoy me permiten ser

mejor, ustedes han sido un ejemplo de lucha y perseverancia.

A mis hermanos Byron, Diana y Henry, por compartir con migo la alegría de crecer y

bridarme su apoyo incondicional.

Fernanda, gracias por ser más que mi compañera de tesis mi gran amiga, por

brindarme tu amistad y por haber compartido este camino juntos.

A nuestro director de tesis Raúl Córdova, por compartir con nosotros sus

enseñanzas y por su apoyo y esfuerzo dedicado para nuestra tutoría.

Finalmente, mientras he viajado por este camino donde la mente es quien dirige el

batallón de guerra contra la ignorancia, es el corazón quien conoció las alegrías y

tristezas, los éxitos y fracasos y con amor supo entender a todos los seres que

formaron parte de esta experiencia de vida; a todos ellos quiero regalar un suspiro

que viaje por la brisa cálida que siempre me supieron brindar cuando lo necesité.

Gracias amigos y amigas por su amistad y vivir juntos estas experiencias

universitarias que nos han hecho grandes; y en especial a ti Dianita porque sobre

todas las cosas estas ahí para mí y eres una luz en mi vida.

Diego

DEDICATORIA

Dedico este trabajo mis padres, hermanas y mi familia por confiar siempre en mí y

enseñarme que los sueños son posibles de alcanzar.

A mi esposo e hija por el apoyo incondicional y por permitirme robarles momentos

para cumplir una meta más para nuestra familia.

Y para quienes nunca dejaron de creer en mí, lo dedico a ustedes.

Gaby

DEDICATORIA

Quiero dedicar este trabajo a mi familia: mis padres y mis hermanos, porque ustedes

me vieron nacer y crecer y ahora puedo triunfar gracias a todo el apoyo que me dan

con mucho amor, esto va por ustedes mi gran familia.

Diego

INTRODUCCIÓN

En la actualidad gracias al avance de la tecnología los Colegios han podido

automatizar sus procesos académicos permitiendo: optimizar recursos y tener un

control efectivo de la información de sus estudiantes.

El presente trabajo plantea el desarrollo del sistema de gestión académica y

administrativa vía web para el Colegio la Providencia, descrito en los siguientes

capítulos.

En el Capítulo 1 se describe la situación actual del Colegio, se realiza la justificación

de la metodología XP (eXtreme Programming) comparando sus características con

los requerimientos del proyecto, se plantea el uso de herramientas Open Source

describiendo sus características y beneficios que aportan al desarrollo del proyecto.

En el Capítulo 2 se describen las fases de la metodología XP que se realizan en el

desarrollo del sistema web.

El desarrollo comienza con la planificación, donde se realiza la especificación de

requerimientos y la definición del plan de entregas, por medio de las historias de

usuario establecidas por el cliente.

Luego se realizan las actividades de diseño necesarias para entender y plantear la

solución, por medio del sistema web, para los requerimientos del cliente.

Para la implementación de las iteraciones, el equipo de desarrollo y el cliente definen

el cronograma de actividades a realizarse, a continuación se implementa cada

iteración y se realiza el seguimiento respectivo.

El diseño de las pruebas de aceptación, en base a la metodología XP, es realizado

por el cliente en las reuniones donde se definen las historias de usuario. Las

pruebas de aceptación se ejecutan después de la implementación de cada historia

de usuario, hasta que el cliente valide con éxito cada una.

En el Capítulo 3 se presenta las conclusiones y recomendaciones que se obtuvo de

la realización del presente proyecto.

RESUMEN

En el presente proyecto se desarrolla un sistema de gestión académica y

administrativa vía web para el colegio la providencia siguiendo la metodología XP.

La presentación escrita del proyecto consta de tres capítulos.

En el primer capítulo se describe la situación actual del colegio, se justifica la

metodología de desarrollo y se plantea el uso de herramientas Open Source para su

ejecución, entre ellas: PostgreSQL, JBOSS, JAVA EE, UML y JSF.

En el segundo capítulo se realiza el desarrollo del sistema en base al ciclo de vida

de XP, en la planificación se especifican los requerimientos y el plan de entregas, en

el diseño se definen la metáfora, diseño arquitectónico y tarjetas CRC, en la

implementación se realiza un cronograma de actividades, se implementa cada

historia de usuario y se realiza el respectivo seguimiento, a continuación se ejecutan

las pruebas de aceptación analizando los resultados con el cliente, finalmente se

especifican los requisitos necesarios para la implantación del sistema.

En el tercer capítulo se presentan las conclusiones y recomendaciones alcanzadas

en el desarrollo del proyecto realizado.

Siguiendo los valores y las buenas prácticas de XP se obtuvo un producto de

software que satisface los requerimientos del cliente; esto es, permite a los

administradores, profesores y estudiantes gestionar: cursos, materias, aulas,

especialidades, materiales académicos, horarios, periodos escolares, configuración

de calificaciones, registro de calificaciones, registro de asistencia, matriculación del

estudiante y generación de reportes académicos y estudiantiles.

CONTENIDO

ÍNDICE GENERAL

CAPITULO 1. PLANTEAMIENTO DEL PROBLEMA ........................................... 1

1.1 SITUACIÓN ACTUAL DEL COLEGIO LA PROVIDENCIA ................................ 1

1.1.1 ANTECEDENTES DE LA INSTITUCIÓN .................................................. 1

1.1.2 MISIÓN INSTITUCIONAL ......................................................................... 1

1.1.3 VISIÓN INSTITUCIONAL .......................................................................... 2

1.1.4 PROCESOS ACADÉMICOS ..................................................................... 2

1.2 JUSTIFICACIÓN DE LA METODOLOGÍA DE DESARROLLO ......................... 3

1.2.1 CICLO DE VIDA DE XP ............................................................................ 3

1.2.2 CARACTERÍSTICAS DE EXTREME PROGRAMMING (XP) .................... 5

1.2.3 CARACTERÍSTICAS DEL PROYECTO .................................................... 8

1.2.4 JUSTIFICACIÓN DE XP EN EL PROYECTO ........................................... 8

1.3 JUSTIFICACIÓN DE LAS HERRAMIENTAS DE DESARROLLO ..................... 9

1.3.1 SERVIDOR DE APLICACIONES JBOSS .................................................. 9

1.3.2 PLATAFORMA DE DESARROLLO JAVA EE ......................................... 10

1.3.3 GESTOR DE BASE DE DATOS POSTGRESQL .................................... 10

1.3.4 LENGUAJE DE MODELAMIENTO UML ................................................. 11

1.3.5 PLATAFORMA DE CONSTRUCCIÓN DE PÁGINAS WEB JSF ............. 12

CAPITULO 2. DESARROLLO DEL SISTEMA .................................................... 13

2.1 PLANIFICACIÓN ............................................................................................ 13

2.1.1 ESPECIFICACIÓN DE REQUERIMIENTOS ........................................... 13

2.1.2 PLAN DE ENTREGAS ............................................................................ 37

2.2 DISEÑO .......................................................................................................... 41

2.2.1 METÁFORA DEL SISTEMA .................................................................... 41

2.2.2 DIAGRAMA DE CLASES ........................................................................ 47

2.2.3 DISEÑO CONCEPTUAL ......................................................................... 49

2.2.4 DISEÑO DE LAS TARJETAS CRC ......................................................... 51

2.2.5 DISEÑO ARQUITECTÓNICO ................................................................. 54

2.2.6 DISEÑO DE INTERFACES ..................................................................... 56

2.2.7 ESTRUCTURA JERÁRQUICA DEL SITIO WEB ..................................... 57

2.3 IMPLEMENTACIÓN ....................................................................................... 59

2.3.1 CRONOGRAMA DE IMPLEMENTACIÓN DE ITERACIONES ................ 59

2.3.2 IMPLEMENTACIÓN DE LAS ITERACIONES ......................................... 60

2.3.3 SEGUIMIENTO DE LAS ITERACIONES ................................................ 73

2.4 PRUEBAS ...................................................................................................... 76

2.4.1 PRUEBAS UNITARIAS ........................................................................... 76

2.4.2 DISEÑO DE LAS PRUEBAS DE ACEPTACIÓN ..................................... 79

2.4.3 PRUEBAS DE ACEPTACIÓN ................................................................. 81

2.5 PLANIFICACIÓN DE LA IMPLANTACIÓN .................................................... 115

CAPITULO 3. CONCLUSIONES Y RECOMENDACIONES ............................. 118

3.1 CONCLUSIONES ......................................................................................... 118

3.2 RECOMENDACIONES ................................................................................. 119

BIBLIOGRAFÍA ...................................................................................................... 120

GLOSARIO ............................................................................................................. 122

ANEXOS ................................................................................................................. 125

ÍNDICE DE FIGURAS

Figura 1.1 Ciclo de vida de eXtreme Programming ..................................................... 3

Figura 2.1 Formato de una Historia de Usuario ......................................................... 13

Figura 2.2 Diagrama de Clases ................................................................................. 48

Figura 2.3 Modelo Conceptual de la Base de Datos ................................................. 50

Figura 2.4 Tarjeta CRC ............................................................................................. 51

Figura 2.5 Arquitectura del Sistema. ......................................................................... 55

Figura 2.6 Plantilla para el diseño de las interfaces de usuario. ............................... 56

Figura 2.7 Mapa del Sitio Web .................................................................................. 58

Figura 2.8 Planificación de la Primera Iteración. Ejemplo ......................................... 59

Figura 2.9 Estructura del proyecto empresarial PROVSIS. ....................................... 61

Figura 2.10 Interfaz de Usuario. Registro de Integrante institucional ........................ 72

Figura 2.11 Diagrama BurnDown. Primera Iteración. ................................................ 73

Figura 2.12 Diagrama BurnDown. Segunda Iteración. .............................................. 74

Figura 2.13 Diagrama BurnDown. Tercera Iteración. ................................................ 75

Figura 2.14 Resultado de la ejecución de la prueba unitaria UsuarioTest ................ 78

ÍNDICE DE TABLAS

Tabla 1 Comparación entre características del proyecto y de la metodología XP....... 8

Tabla 2 Historia de Usuario. Registro de Integrante Institucional. ............................. 15

Tabla 3 Historia de Usuario. Modificación de Integrante Institucional. ...................... 16

Tabla 4 Historia de Usuario. Registro de Usuario. .................................................... 16

Tabla 5 Historia de Usuario. Modificación de Usuario. .............................................. 16

Tabla 6 Historia de Usuario. Acceso al Sistema ........................................................ 17

Tabla 7 Historia de Usuario. Registro de Niveles Educativos.................................... 17

Tabla 8 Historia de Usuario. Modificación de Niveles Educativos. ............................ 18

Tabla 9 Historia de Usuario. Eliminación de Nivel Educativo. ................................... 18

Tabla 10 Historia de Usuario. Registro de Materias. ................................................. 18

Tabla 11 Historia de Usuario. Modificación de Materias por Nivel. ........................... 19

Tabla 12 Historia de Usuario. Eliminación de Materia por Nivel. ............................... 19

Tabla 13 Historia de Usuario. Registro de Aulas. ...................................................... 20

Tabla 14 Historia de Usuario. Modificación de Aulas. ............................................... 20

Tabla 15 Historia de Usuario. Eliminación de Aula .................................................... 20

Tabla 16 Historia de usuario. Registro de Especialidades. ....................................... 21

Tabla 17 Historia de Usuario. Modificación de Especialidades. ................................ 21

Tabla 18 Historia de Usuario. Eliminación de Especialidad ...................................... 22

Tabla 19 Historia de usuario. Registro de Requisitos de Matrícula. .......................... 22

Tabla 20 Historia de Usuario. Modificación de Requisitos de Matrícula. ................... 23

Tabla 21 Historia de Usuario. Eliminación de Requisito de Matrícula. ...................... 23

Tabla 22 Historia de Usuario. Registro de Materiales Académicos. .......................... 23

Tabla 23 Historia de Usuario. Modificación de Materiales Académicos. ................... 24

Tabla 24 Historia de Usuario. Eliminación de Material Académico. .......................... 24

Tabla 25 Historia de usuario. Registro de Datos de la Institución. ............................ 25

Tabla 26 Historia de Usuario. Modificación de Datos de la Institución ...................... 25

Tabla 27 Historia de Usuario. Registro de Período ................................................... 26

Tabla 28 Historia de Usuario. Modificación de Período Actual. ................................. 26

Tabla 29 Historia de Usuario. Eliminación de Período. ............................................. 27

Tabla 30 Historia de Usuario. Registro de Configuración de Calificaciones. ............. 27

Tabla 31 Historia de Usuario. Modificación de Configuración de Calificaciones. ...... 27

Tabla 32 Historia de Usuario. Eliminación de Configuración de Calificaciones. ........ 28

Tabla 33 Historia de Usuario. Registro de Curso. ..................................................... 28

Tabla 34 Historia de Usuario. Modificación de Curso. ............................................... 29

Tabla 35 Historia de Usuario. Generación de Reportes Académicos. ....................... 29

Tabla 36 Historia de Usuario. Información del Estudiante. ........................................ 30

Tabla 37 Historia de Usuario. Registro de Matrícula. ................................................ 30

Tabla 38 Historia de Usuario. Anulación de Matrícula. .............................................. 31

Tabla 39 Historia de Usuario. Registro de Asistencia. .............................................. 31

Tabla 40 Historia de Usuario. Modificación de Asistencia. ........................................ 32

Tabla 41 Historia de Usuario. Registro de Calificaciones. ......................................... 32

Tabla 42 Historia de Usuario. Modificación de Calificaciones ................................... 32

Tabla 43 Historia de Usuario. Generación de Reportes Estudiantiles. ...................... 33

Tabla 44 Estimación de Historias de Usuario. ........................................................... 36

Tabla 45 Tiempo Calendario. .................................................................................... 37

Tabla 46 Esfuerzo de Desarrollo en base a una persona ......................................... 37

Tabla 47 Plan de Entrega. ......................................................................................... 40

Tabla 48 Tarjetas CRC del Sistema. ......................................................................... 52

Tabla 49 Tarjeta CRC. Controlador Matrícula ........................................................... 53

Tabla 50 Tarjeta CRC. Matrícula ............................................................................... 53

Tabla 51 Tarjeta CRC. Servicio Matrícula ................................................................. 53

Tabla 52 Pruebas de Unidad del Sistema PROVSIS. ............................................... 77

Tabla 53 Formato de Pruebas de Aceptación ........................................................... 79

Tabla 54 Prueba de Aceptación. Registro de Integrante Institucional ....................... 81

Tabla 55 Prueba de Aceptación. Modificación de Integrante Institucional ................ 82

Tabla 56 Prueba de Aceptación. Registro de Usuario ............................................... 83

Tabla 57 Prueba de Aceptación. Modificación de Usuario ........................................ 84

Tabla 58 Prueba de Aceptación. Acceso al Sistema ................................................. 85

Tabla 59 Prueba de Aceptación. Registro de Niveles Educativos ............................. 85

Tabla 60 Prueba de Aceptación. Modificación de Niveles Educativos ...................... 86

Tabla 61 Prueba de Aceptación. Eliminación de Nivel Educativo ............................. 87

Tabla 62 Prueba de Aceptación. Registro de Materias ............................................. 88

Tabla 63 Prueba de Aceptación. Modificación de Materias ....................................... 89

Tabla 64 Prueba de Aceptación. Eliminación de Materia .......................................... 90

Tabla 65 Prueba de Aceptación. Registro de Aulas .................................................. 90

Tabla 66 Prueba de Aceptación. Modificación de Aulas ........................................... 91

Tabla 67 Prueba de Aceptación. Eliminación de Aula ............................................... 92

Tabla 68 Prueba de Aceptación. Registro de Especialidades ................................... 93

Tabla 69 Prueba de Aceptación. Modificación de Especialidades ............................ 94

Tabla 70 Prueba de Aceptación. Eliminación de Especialidad .................................. 95

Tabla 71 Prueba de Aceptación. Registro de Requisitos de Matrícula ...................... 96

Tabla 72 Prueba de Aceptación. Modificación de Requisitos de Matrícula ............... 97

Tabla 73 Prueba de Aceptación. Eliminación de Requisito de Matrícula .................. 98

Tabla 74 Prueba de Aceptación. Registro de Materiales Académicos ...................... 99

Tabla 75 Prueba de Aceptación. Modificación de Materiales Académicos ............. 100

Tabla 76 Prueba de Aceptación. Eliminación de Materiales Académicos ............... 100

Tabla 77 Prueba de Aceptación. Registro de Datos de la Institución ...................... 101

Tabla 78 Prueba de Aceptación. Modificación de Datos de la Institución ............... 102

Tabla 79 Prueba de Aceptación. Registro de Período ............................................ 102

Tabla 80 Prueba de Aceptación. Modificación de Período Actual ........................... 103

Tabla 81 Prueba de Aceptación. Eliminación de Período ....................................... 104

Tabla 82 Prueba de Aceptación. Registro de Configuración de Calificaciones ....... 105

Tabla 83 Prueba de Aceptación. Modificación de Configuración Calificaciones ..... 105

Tabla 84 Prueba de Aceptación. Eliminación de Configuración Calificaciones ....... 106

Tabla 85 Prueba de Aceptación. Registro de Curso ............................................... 107

Tabla 86 Prueba de Aceptación. Modificación de Curso ......................................... 108

Tabla 87 Prueba de Aceptación. Generación de Reportes Académicos ................. 108

Tabla 88 Prueba de Aceptación. Información del Estudiante .................................. 109

Tabla 89 Prueba de Aceptación. Registro de Matrícula .......................................... 110

Tabla 90 Prueba de Aceptación. Eliminación de Matrícula ..................................... 110

Tabla 91 Prueba de Aceptación. Registro de Asistencia ......................................... 111

Tabla 92 Prueba de Aceptación. Modificación de Asistencia .................................. 112

Tabla 93 Prueba de Aceptación. Registro de Calificaciones ................................... 113

Tabla 94 Prueba de Aceptación. Modificación de Calificaciones ............................ 113

Tabla 95 Prueba de Aceptación. Generación de Reportes Estudiantiles ................ 114

1

CAPITULO 1. PLANTEAMIENTO DEL PROBLEMA

1.1 SITUACIÓN ACTUAL DEL COLEGIO LA PROVIDENCIA

Actualmente el Colegio La Providencia no posee un software que apoye los

procesos académicos de la Institución, por tal razón se consume gran cantidad de

tiempo y recursos innecesarios para realizarlos.

Por medio del Sistema Web que se plantea en este proyecto se pretende apoyar el

proceso de matriculación; ayudar en la planificación académica de los docentes y

alumnos, manteniendo un registro de sus datos personales y académicos; mejorar la

organización de cursos para cada año escolar gestionando materias a ser

impartidas, horarios y docentes; facilitar el registro de calificaciones de los alumnos y

generar reportes útiles en las actividades académicas del Colegio.

1.1.1 ANTECEDENTES DE LA INSTITUCIÓN

La Unidad Educativa “La Providencia” UELP ubicada en el Centro Histórico del

Distrito Metropolitano de Quito, es una Institución regentada por las Hermanas de la

Providencia y de la Inmaculada Concepción. Inició su servicio el 4 de Enero de 1872,

en que llegaron al Ecuador un grupo de hermanas (excelentes educadoras), desde

su país natal Bélgica.

1.1.2 MISIÓN INSTITUCIONAL

La Unidad Educativa “La Providencia” UELP es una Institución Católica que tiene

como objetivo fundamental Evangelizar educando, en base a los principios del

Evangelio, del carisma Providencia y de las innovaciones educativas del país.

2

1.1.3 VISIÓN INSTITUCIONAL

La Unidad Educativa “La Providencia” UELP, anhela ser una Institución responsable

y dinámica en el proceso educativo, para obtener una formación cristiana y

académica de calidad y calidez.

1.1.4 PROCESOS ACADÉMICOS

Actualmente algunos procesos académicos del Colegio La Providencia se manejan

de forma manual, lo que ocasiona un consumo de tiempo y recursos innecesarios,

los que pueden ser aprovechados en mejorar otras actividades involucradas en la

calidad de la educación.

Los documentos de estos procesos son archivados cada año, ocupando material y

espacio innecesario para estas actividades, esto hace que se dificulte la tarea de

búsqueda, generación de reportes históricos y que el manejo de esta información

sea susceptible a errores humanos.

Cada año escolar, durante la matriculación de las estudiantes, se realiza actividades

repetitivas como la recepción, verificación y registro manual de los documentos;

estas actividades causan un consumo de tiempo innecesario para los docentes y los

padres de familia.

El registro de calificaciones y el control de asistencia que se realizan de forma

manual, son actividades que consumen tiempo, que puede ser utilizado en la

preparación de las clases que se imparten diariamente a las estudiantes, o en

actividades relacionadas con el mejoramiento de la educación.

La administración de los horarios, las aulas y el personal docente de cada curso, es

una actividad que puede ser automatizada, de tal forma que se pueda optimizar este

proceso y evitar posibles errores, como el cruce de horarios y aulas.

3

1.2 JUSTIFICACIÓN DE LA METODOLOGÍA DE DESARROLLO

En la actualidad los proyectos de desarrollo de software deben enfocarse

principalmente en los requerimientos del usuario, debido a que estos son

cambiantes se requiere una metodología que se adapte a cambios. A diferencia de

las metodologías tradicionales donde existe una gran resistencia a los cambios, una

metodología ágil permite entregar un producto software de calidad, que cumpla con

las expectativas de los usuarios.

La finalidad de las metodologías ágiles es evitar el tener que seguir los caminos

tediosos que proponen las metodologías tradicionales, para enfocarse directamente

en las personas involucradas y en los resultados, evitando la extensa

documentación y promoviendo la comunicación personalizada con la gente.

Con el fin de justificar el uso de la metodología XP para el presente proyecto, se

presenta en primer lugar, las características de la metodología XP.

1.2.1 CICLO DE VIDA DE XP

“El ciclo de vida de XP se enfatiza en el carácter interactivo e incremental del

desarrollo. Existe una fase de análisis inicial orientada a programar las iteraciones de

desarrollo y cada iteración incluye diseño, codificación y pruebas.

La Figura 1.1 muestra las fases en las que se subdivide el ciclo de vida XP:

Figura 1.1 Ciclo de vida de eXtreme Programming

4

Fase de la exploración: En esta fase, los clientes plantean las historias de usuario

que son de interés para la primera entrega del producto. Al mismo tiempo el equipo

de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se

utilizarán en el proyecto.

Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema

construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos

meses, dependiendo del tamaño y familiaridad que tengan los programadores con la

tecnología.

Fase del planeamiento: se priorizan las historias de usuario y se establece el

alcance de la entrega en las reuniones con el cliente. Los programadores estiman

cuánto esfuerzo requiere cada historia y a partir de allí se define el cronograma. La

fase de planeamiento toma un par de días. Se deben incluir varias iteraciones para

lograr una entrega. El cronograma fijado en la etapa de planeamiento se realiza a un

número de iteraciones, cada una toma de una a cuatro semanas en ejecución. La

primera iteración crea un sistema con la arquitectura del sistema completo, esto es

alcanzado seleccionando las historias que harán cumplir la construcción de la

estructura para el sistema completo. El cliente decide las historias que se

seleccionarán para cada iteración. Las pruebas funcionales creadas por el cliente se

ejecutan al final de cada iteración. Al final de la última iteración el sistema está listo

para producción.

Fase de producción: requiere prueba y comprobación extra del funcionamiento del

sistema antes de que éste se pueda liberar al cliente. En esta fase, los nuevos

cambios pueden todavía ser encontrados y debe tomarse la decisión de si se

incluyen o no en la entrega actual. Durante esta fase, las iteraciones pueden ser

aceleradas de una a tres semanas. Las ideas y las sugerencias pospuestas se

documentan para una puesta en práctica posterior por ejemplo en la fase de

mantenimiento. Después de que se realice el primer entregable productivo para uso

del cliente, el proyecto de XP debe mantener el funcionamiento del sistema mientras

que realiza nuevas iteraciones.

5

Fase de mantenimiento: requiere de un mayor esfuerzo para satisfacer también las

tareas del cliente. Así, la velocidad del desarrollo se puede desacelerar después de

que el sistema esté en producción. La fase de mantenimiento puede requerir la

incorporación de nueva gente y cambiar la estructura del equipo.

Fase de muerte: Es cuando el cliente no tiene más historias para ser incluidas en el

sistema. Esto requiere que se satisfagan las necesidades del cliente en otros

aspectos como rendimiento y confiabilidad del sistema. Se genera la documentación

final del sistema y no se realizan más cambios en la arquitectura. La muerte del

proyecto también ocurre cuando el sistema no genera los beneficios esperados por

el cliente o cuando no hay presupuesto para mantenerlo.”1

1.2.2 CARACTERÍSTICAS DE EXTREME PROGRAMMING (XP)

“Es una metodología ágil que se enfoca en potenciar las relaciones interpersonales

como clave para el éxito en desarrollo de software, promoviendo el trabajo en

equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un

buen clima de trabajo. XP se basa en realimentación continua entre el usuario y el

equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad

en las soluciones implementadas y coraje para enfrentar los cambios. XP se define

como especialmente adecuada para proyectos con requisitos imprecisos y muy

cambiantes, y donde existe un alto riesgo técnico.”2

Valores de XP

Comunicación.- XP pone en comunicación directa y continua a clientes y

desarrolladores. El cliente se integra en el equipo para establecer prioridades y

1 VILLAFUERTE, Víctor. Ciclo de Vida de Extreme Programming. http://extremeprogramming.host56.com/ARTICULO5.php 13/10/2012. 2 LETELIER, Patricio. Metodologías Ágiles en el Desarrollo de Software.http://issi.dsic.upv.es/archives/f-1069167248521/actas.pdf 20/12/2011.

6

resolver dudas. De esta forma ve el avance día a día, y es posible ajustar la agenda

y las funcionalidades de forma consecuente.

Simplicidad.- Consiste en desarrollar sólo el sistema que realmente se necesita,

implica resolver en cada momento sólo las necesidades actuales.

Retroalimentación.- XP se basa en el desarrollo incremental de pequeñas partes,

con entregas y pruebas frecuentes y continuas, proporciona un flujo de retro-

información valioso para detectar los problemas o desviaciones.

Coraje.- involucra los siguientes aspectos:

Ø Disciplina en la aplicación de XP.

Ø Parar cuando se está cansado.

Ø Permitir que el usuario tome las decisiones de negocio.

Ø Permitir que el desarrollador tome las decisiones técnicas.

Ø Descartar código si es necesario.

Ø Introducir cambios cuando las cosas no funcionan.

Ø Respetar el trabajo de los miembros del equipo.

Buenas prácticas de XP.

La planificación.-Se utilizan las “historias del usuario” para realizar el análisis, estas

“historias” se dividirán en tareas (unidades pequeñas, de 1 a 5 días de trabajo en

pareja. Además, se priorizarán las tareas, y cada una de ellas tendrá un desarrollo

incremental.

Versiones pequeñas.-La primera versión contendrá el conjunto mínimo de

requisitos más útiles/necesarios para el sistema global.

Sistema metafórico.-Cada proyecto debe tener una metáfora asociada que nos

ofrezca unos criterios para nombrar lo que vayamos haciendo de forma fácil.

7

Diseño simple.-Cómo los requerimientos cambian, o pueden hacerlo, diariamente,

hay que utilizar los diseños más simples posibles para cumplir los requerimientos

que tenemos en la actualidad.

Pruebas continuas.-Antes de que se implemente cualquier característica de un

sistema, se debe escribir un test para ella.

Refactorización.-Cuando tenemos que introducir una nueva característica del

sistema, si esta tiene mucho en común con otra previa, lo mejor es eliminar el código

duplicado, sin miedo a que falle, debido a que el test probará el correcto

funcionamiento.

Programación en parejas.-Se trabaja en parejas, cada una utilizando un único

ordenador. Así, el código se revisa mientras se desarrolla.

Propiedad colectiva del código.-Cualquiera puede modificar cualquier módulo en

cualquier momento, nadie tiene la propiedad de ningún módulo.

Integración continua.-Todos los cambios se introducen en el sistema, al menos,

una vez al día.

Semanas de 40 horas de trabajo.-Los programadores se deben ir a casa a su hora.

Cliente en su sitio.-Siempre hay un usuario del sistema que es accesible por los

miembros del equipo de trabajo.

Estándares de codificación.-Todos deben usar los mismos criterios a la hora de

programar. De esta forma, no sería posible determinar quién ha realizado una

determinada parte de la implementación.

8

A continuación se especifica las características del presente proyecto relacionadas

con la metodología XP.

1.2.3 CARACTERÍSTICAS DEL PROYECTO

El grupo de trabajo del presente proyecto está conformado por dos personas.

El proyecto está planificado para un plazo de tiempo corto.

No tiene costo ya que es un proyecto con fines académicos y maneja herramientas

de libre difusión.

La información que maneja el sistema web no es compleja.

Existe apoyo de las autoridades del Colegio La Providencia para facilitar al equipo

de desarrollo, la información sobre lo que se requiere en el sistema y cambios que

los usuarios sugieran.

1.2.4 JUSTIFICACIÓN DE XP EN EL PROYECTO

Con el fin de justificar el uso de la metodología XP, en la Taba 1.1 se realiza un

cuadro comparativo en el que se valida que las características del proyecto se

acoplen a la Metodología XP.

eXtreme Programming Proyecto

Comunicación. Comunicación directa y continua entre los usuarios

y los desarrolladores.

Simplicidad. Los desarrolladores resuelven en cada momento

las necesidades actuales.

Retroalimentación. Los usuarios intervienen en la especificación de los

requerimientos nuevos y cambiantes.

Programación en parejas Dos personas que trabajan en un solo ordenador.

Tabla 1 Comparación entre características del proyecto y de la metodología XP.

9

1.3 JUSTIFICACIÓN DE LAS HERRAMIENTAS DE DESARROLLO

Para el desarrollo del Sistema de Gestión Académica y Administrativa Vía Web se

utilizan herramientas de libre difusión, ya que ofrecen la ventaja de manejarlas

libremente, facilitando la adaptación del sistema a las necesidades de la institución.

Además se utilizan estándares de desarrollo que permiten realizar un producto de

calidad y útil para el usuario.

A continuación se describen las herramientas a utilizarse en el desarrollo del

Sistema Web.

1.3.1 SERVIDOR DE APLICACIONES JBOSS

Para el desarrollo del presente proyecto se utiliza JBoss como servidor de

aplicaciones, por su ventaja de ser código abierto y, tener soporte completo con la

plataforma Java EE que también se utiliza en el desarrollo del sistema.

Descripción

JBoss es un servidor de aplicaciones de código abierto basado en JEE, se puede

utilizar en cualquier sistema operativo que soporte Java.

Estas son algunas características de JBoss:

Ø Open Source

Ø Escalable

Ø Orientado a arquitectura de servicios

Ø Arquitectura Modular

Ø Confiable a nivel de empresa

Ø Servicios del middleware para cualquier objeto de Java

10

1.3.2 PLATAFORMA DE DESARROLLO JAVA EE

Se utiliza la plataforma Java EE para el desarrollo del presente proyecto, porque

brinda la ventaja de separar claramente la presentación, los datos y el modelo de

negocios en el sistema web, además de estar basado en componentes.

Descripción.

Java Enterprise Edition es una plataforma para el desarrollo de aplicaciones

empresariales (portables, robustas, escalables y seguras) usando tecnología Java.

Java EE en la versión 5 simplifica el modelo de desarrollo de las antiguas versiones,

además de usar anotaciones e inyecciones de dependencia.

Estas son algunas características de JEE:

Ø Heterogénea.- Permite múltiples plataformas, sistemas operativos y lenguajes

de desarrollo.

Ø Escalable.-Facilita las ampliaciones y modificaciones necesarias.

Ø Alta disponibilidad.- Facilita la adquisición y actualización.

Ø Fácil mantenimiento.-Facilita el mantenimiento del sistema mediante la

actualización de sus componentes.

1.3.3 GESTOR DE BASE DE DATOS POSTGRESQL

Para el desarrollo del presente proyecto se escogió como motor de base datos

PostgreSQL, por su ventaja de ser código abierto, y brindar estabilidad y

confiabilidad.

Descripción.

PostgreSQL es un sistema de gestión de bases de datos objeto-relacional,

distribuido bajo licencia BSD y con su código fuente disponible libremente.

11

Estas son algunas características de PostgreSQL:

Ø Multiplataforma.

Ø Diseñado para ambientes de alto volumen.

Ø Herramientas gráficas de diseño y administración de bases de datos.

Ø Instalación ilimitada.

Ø Mejor soporte que los proveedores comerciales.

Ø Ahorros considerables en costos de operación.

Ø Alta concurrencia.

Ø Extensible.

Ø Diseñado para ambientes de alto volumen.

Ø Gran capacidad de almacenamiento.

Ø Buena escalabilidad.

Ø Su administración se basa en usuarios y privilegios.

Ø Es altamente confiable en cuanto a estabilidad se refiere.

Ø Soporte.

1.3.4 LENGUAJE DE MODELAMIENTO UML

En el presente proyecto se utiliza UML para apoyar las tareas de planificación y

diseño de XP en el desarrollo del sistema web.

Descripción.

La notación UML (no hay que confundir con las metodologías que utilizan dicha

notación), se ha convertido desde finales de los 90 en un estándar para modelar,

con tecnología orientada a objetos, todos aquellos elementos que configuran la

arquitectura de un sistema de información y, por extensión, de los procesos de

negocio de una organización. Los diagramas UML suministran un modelo de

referencia para formalizar los procesos, reglas de negocio, objetos y componentes

de una organización. La interacción de todos estos elementos es una representación

de nuestra realidad.

12

1.3.5 PLATAFORMA DE CONSTRUCCIÓN DE PÁGINAS WEB JSF

En el presente proyecto se utiliza JSF como marco de trabajo para la construcción

de las páginas web del sistema, aprovechando la ventaja de que JSF forma parte de

Java EE.

JSF permite simplificar la construcción de páginas web, debido a que la

programación de la interfaz de usuario se la realiza a través de componentes y

basada en eventos.

Descripción.

JSF es un marco de trabajo para crear aplicaciones Java EE (Java Enterprise

Edition) basadas en el patrón Modelo Vista Controlador (MVC).

Esta tecnología simplifica la construcción de interfaces de usuario de Aplicaciones

Java-Servidor. Los desarrolladores pueden construir rápidamente aplicaciones web,

ensamblando componentes de interfaces de usuario (UI) reusables en una página,

conectando estos componentes a una aplicación de datos, y enlazando los eventos

generados por el cliente con el manejador de eventos del lado del servidor.

13

CAPITULO 2. DESARROLLO DEL SISTEMA

2.1 PLANIFICACIÓN

“La metodología XP plantea la planificación como un diálogo continuo entre las

partes involucradas en el proyecto, incluyendo al cliente, a los programadores y a los

coordinadores o gerentes.”3

La planificación del desarrollo del presente proyecto se realiza en reuniones entre

los integrantes del equipo de desarrollo y el cliente.

2.1.1 ESPECIFICACIÓN DE REQUERIMIENTOS

La especificación de los requerimientos del sistema se realiza en las reuniones del

equipo de desarrollo con la secretaria del Colegio “La Providencia”, quien es la

persona que está relacionada ampliamente con los procesos académicos que se

realizan en la Institución. La descripción de estos requerimientos se detalla en las

historias de usuarios.

HISTORIAS DE USUARIO

Cada historia de usuario tiene el modelo presentado en la Figura 2.1, basado en el

diseño propuesto por Kent Beck en la metodología XP.

Historia de usuario

Número: Usuario:

Nombre de la historia:

Prioridad en el negocio:

(BAJA / MEDIA / ALTA)

Riesgo en desarrollo:

(BAJO / MEDIO / ALTO)

Puntos estimados: Iteración asignada:

Descripción:

Observaciones:

Figura 2.1 Formato de una Historia de Usuario4

3 JOSKOWICZ, José. Reglas y Prácticas en eXtremeProgramming. Febrero 2008. http://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20Joskowicz.pdf 4 KENT BECK Martin. Planning Extreme Programming. Addison Weley. 2000.

14

Donde:

Número: Es el identificador unívoco de la historia de usuario.

Nombre de la historia: Es el nombre de la historia de usuario, asignada de acuerdo

a la tarea que se especifica.

Usuario: Es la persona responsable de realizar la descripción de la historia de

usuario.

Prioridad en el negocio: Definido por el cliente, es el grado de prioridad para el

desarrollo de la historia de usuario.

Riesgo en desarrollo: Se define basado en el riesgo que afronta el equipo de

desarrollo para la obtención de resultados de la historia de usuario para satisfacer

los requerimientos del cliente. Pueden ser alto, medio o bajo.

Puntos estimados: Son puntos de esfuerzo determinados en base a la duración del

desarrollo de la historia de usuario.

Iteración asignada: Es la iteración en la que el cliente desea que se implemente la

historia.

Descripción: Es el detalle de lo que se va a realizar en la historia de usuario.

Observaciones: Son aclaraciones de un requerimiento que deberían tomarse en

cuenta; este campo es opcional.

2.1.1.1 Identificación de las Historias de Usuario

Las Historias de Usuario son priorizadas y agrupadas durante las reuniones entre el

equipo de desarrollo y el cliente. En el presente proyecto se agrupa las Historias de

Usuario en los módulos: Administración, Gestión Académica y Gestión Estudiantil.

15

2.1.1.1.1 Módulo 1: Administración

Historia de Usuario

Número: 01 Usuario: Secretaria

Nombre de la historia: Registro de Integrante Institucional.

Prioridad en el negocio: ALTA Riesgo en desarrollo: ALTO

Puntos estimados: 0,8 Iteración asignada: 1

Descripción:

El sistema permite a la Secretaria registrar la información de un nuevo

Integrante Institucional (estudiante, profesor o administrador).

Observaciones:

Se registra la siguiente información del Integrante Institucional.

Ø Número de cédula de ciudadanía, nombre, apellido paterno, apellido

materno, fecha de nacimiento, dirección domiciliaria, teléfono del

domicilio, número de celular y dirección de correo electrónico.

Si el integrante es estudiante se registra como información adicional el nombre

del representante.

Tabla 2 Historia de Usuario. Registro de Integrante Institucional.

Historia de usuario


Nombre de la historia: Modificación de Integrante Institucional.



Descripción:

El sistema permite a la Secretaria modificar la información del Integrante

Institucional.

16

Observaciones:

Se modifica la siguiente información del Integrante Institucional.

Ø Número de cédula de ciudadanía, nombre, apellido paterno, apellido

materno, fecha de nacimiento, dirección domiciliaria, teléfono del

domicilio, número de celular y dirección de correo electrónico.

Si el integrante es estudiante se puede modificar el nombre del representante.

Tabla 3 Historia de Usuario. Modificación de Integrante Institucional.

Historia de usuario


Nombre de la historia: Registro de Usuario.



Descripción: El sistema permite a la Secretaria registrar nombre de usuario y

contraseña de un Integrante Institucional.

Observaciones:

Tabla 4 Historia de Usuario. Registro de Usuario.

Historia de usuario


Nombre de la historia: Modificación de Usuario.



Descripción: El sistema permite a la Secretaria modificar el nombre de usuario

y contraseña del Usuario.

Observaciones:

Tabla 5 Historia de Usuario. Modificación de Usuario.

17

Historia de usuario

Número: 05 Usuario: Secretaria, Profesor,

Estudiante

Nombre de la historia: Acceso al sistema.



Descripción: El sistema permite al usuario ingresar a las opciones del sistema

con su nombre de usuario y contraseña.

Observaciones:

Las opciones del sistema a las que el usuario puede acceder dependen del

perfil con el que esté registrado.

Tabla 6 Historia de Usuario. Acceso al Sistema

Historia de usuario


Nombre de la historia: Registro de Niveles Educativos.



Descripción: El sistema permite a la Secretaria registrar niveles educativos.

Observaciones:

La información de Nivel Educativo que se registra es:

· Nombre del nivel educativo, nombre de la especialidad.

Tabla 7 Historia de Usuario. Registro de Niveles Educativos.

Historia de usuario


Nombre de la historia: Modificación de Niveles Educativos.



18

Descripción: El sistema permite a la Secretaria modificar la información del

Nivel Educativo.

Observaciones:

La información de Nivel Educativo que se modifica es:

· Nombre del nivel educativo, nombre de la especialidad.

Tabla 8 Historia de Usuario. Modificación de Niveles Educativos.

Historia de usuario


Nombre de la historia: Eliminación de Nivel Educativo.



Descripción: El sistema permite a la Secretaria eliminar la información de un

Nivel Educativo.

Observaciones:

Se puede eliminar el Nivel Educativo solamente si no tiene cursos asociados.

Tabla 9 Historia de Usuario. Eliminación de Nivel Educativo.

Historia de usuario


Nombre de la historia: Registro de Materias.



Descripción:

El sistema permite a la Secretaria registrar las materias correspondientes a

cada nivel.

Observaciones:

La información de Materia que se registra es:

· Nombre de materia

Tabla 10 Historia de Usuario. Registro de Materias.

19

Historia de usuario


Nombre de la historia: Modificación de Materias.



Descripción:

El sistema permite a la Secretaria modificar la información de la materia,

seleccionada de una lista.

Observaciones:

La información de Materia que se modifica es:

· Nombre de materia

Tabla 11 Historia de Usuario. Modificación de Materias por Nivel.

Historia de usuario


Nombre de la historia: Eliminación de Materia.



Descripción:

El sistema permite a la Secretaria eliminar la información de una materia.

Observaciones:

Se puede eliminar la Materia solamente si no tiene horarios asociados.

Tabla 12 Historia de Usuario. Eliminación de Materia por Nivel.

Historia de usuario


Nombre de la historia: Registro de Aulas.



20

Descripción: El sistema permite a la Secretaria registrar la información de las

aulas de la institución.

Observaciones:

La información de Aula que se registra es:

· Nombre de aula.

Tabla 13 Historia de Usuario. Registro de Aulas.

Historia de usuario


Nombre de la historia: Modificación de Aulas.




Aula, seleccionada de una lista.

Observaciones:

La información de Aula que se modifica es:

· Nombre del aula.

Tabla 14 Historia de Usuario. Modificación de Aulas.

Historia de usuario


Nombre de la historia: Eliminación de Aula.



Descripción: El sistema permite a la Secretaria eliminar la información de una

Aula.

Observaciones:

Se puede eliminar el Aula, solamente si no tiene ningún horario asociado.

Tabla 15 Historia de Usuario. Eliminación de Aula

21

Historia de usuario


Nombre de la historia: Registro de Especialidades.



Descripción: El sistema permite a la Secretaria registrar las especialidades

que tiene la Institución.

Observaciones:

La información de Especialidad que se registra es:

· Nombre de especialidad.

Tabla 16 Historia de usuario. Registro de Especialidades.

Historia de usuario


Nombre de la historia: Modificación de Especialidades.



Descripción: El sistema permite a la Secretaria modificar la información de la

Especialidad, seleccionada de una lista.

Observaciones:

La información de Especialidad que se modifica es:

Nombre de especialidad.

Tabla 17 Historia de Usuario. Modificación de Especialidades.

Historia de usuario


Nombre de la historia: Eliminación de Especialidad.



Descripción: El sistema permite a la Secretaria eliminar la información de una

22

Especialidad.

Observaciones:

La especialidad se puede eliminar solamente si no tiene asociado un nivel

educativo.

Tabla 18 Historia de Usuario. Eliminación de Especialidad

Historia de usuario


Nombre de la historia: Registro de Requisitos de Matrícula.



Descripción: El sistema permite a la Secretaria registrar los requisitos de

matrícula.

Observaciones:

Los requisitos son definidos por la Institución.

La información de Requisito de Matrícula que se registra es:

· Nombre del requisito.

· Si es solicitado cada año.

Tabla 19 Historia de usuario. Registro de Requisitos de Matrícula.

Historia de usuario


Nombre de la historia: Modificación de Requisitos de Matrícula.




Requisito de Matrícula, seleccionado de una lista.

23

Observaciones:

La información de Requisito de Matrícula que se modifica es:

· Nombre del requisito.

· Si es solicitado cada año.

Tabla 20 Historia de Usuario. Modificación de Requisitos de Matrícula.

Historia de usuario


Nombre de la historia: Eliminación de Requisito de Matrícula.



Descripción: El sistema permite a la Secretaria eliminar un Requisito de

Matrícula.

Observaciones:

El Requisito de Matrícula se puede eliminar solamente si no tiene asociada una

matrícula.

Tabla 21 Historia de Usuario. Eliminación de Requisito de Matrícula.

Historia de usuario

Número: 21 Usuario: Profesor

Nombre de la historia: Registro de Materiales Académicos.

Prioridad en el negocio: BAJA Riesgo en desarrollo: BAJO


Descripción: El sistema permite a la Secretaria registrar los Materiales

Académicos por cada materia.

Observaciones:

La información de Material Académico que se registra es:

Nombre del material académico, cantidad.

Tabla 22 Historia de Usuario. Registro de Materiales Académicos.

24

Historia de usuario


Nombre de la historia: Modificación de Materiales Académicos.



Descripción: El sistema permite a la Secretaria modificar el Material

Académico seleccionado de una lista.

Observaciones:

La información de Material Académico que se modifica es:

Nombre del material académico, cantidad.

Tabla 23 Historia de Usuario. Modificación de Materiales Académicos.

Historia de usuario


Nombre de la historia: Eliminación de Material Académico.



Descripción: El sistema permite a la Secretaria eliminar un Material

Académico.

Observaciones:

Tabla 24 Historia de Usuario. Eliminación de Material Académico.

Historia de usuario


Nombre de la historia: Registro de datos de la Institución.



Descripción: El sistema permite a la Secretaria registrar los datos de la

Institución.

25

Observaciones:

Los datos de la Institución que se registran son:

Nombre del Colegio, dirección de la institución, RUC, teléfono, logotipo y

nombre de la máxima autoridad del plantel.

Tabla 25 Historia de usuario. Registro de Datos de la Institución.

Historia de usuario


Nombre de la historia: Modificación de datos de la Institución.



Descripción: El sistema permite a la Secretaria modificar los datos de la

Institución.

Observaciones:

Los datos de la Institución que se modifican son:

Nombre del Colegio, dirección de la institución, RUC, teléfono, logotipo y

nombre de la máxima autoridad del plantel.

Tabla 26 Historia de Usuario. Modificación de Datos de la Institución

2.1.1.1.1 Módulo 2: Gestión Académica

Historia de usuario


Nombre de la historia: Registro de Período.



Descripción:

El sistema permite a la Secretaria registrar la información de un nuevo Período.

26

Observaciones:

La información de Período que se registra es:

Fecha de inicio y fin del periodo escolar y de matrículas, y tipo de

subperíodos.

El tipo de subperíodos puede ser personalizado de acuerdo a las necesidades

de la Institución.

Tabla 27 Historia de Usuario. Registro de Período

Historia de usuario


Nombre de la historia: Modificación de Período Actual.



Descripción:

El sistema permite a la Secretaria modificar la información del Período Escolar

Actual.

Observaciones:

La información de Período que se modifica es:

Nombre, fecha de inicio y fin de: período, subperíodos, parciales y de

matrículas.

Tabla 28 Historia de Usuario. Modificación de Período Actual.

Historia de usuario


Nombre de la historia: Eliminación de Período.



Descripción:

El sistema permite a la Secretaria eliminar la información de un Período.

27

Observaciones:

El Período se puede eliminar solamente si está inactivo o cerrado.

Período inactivo es aquel que no tiene matrículas registradas.

Período cerrado es aquel que no corresponde al año escolar vigente.

Tabla 29 Historia de Usuario. Eliminación de Período.

Historia de usuario


Nombre de la historia: Registro de Configuración de Calificaciones



Descripción: El sistema permite a la Secretaria registrar las Configuraciones

de Calificación de cada período, subperíodo o parcial.

Observaciones:

La información de Configuración de Calificación que se registra es:

Nombre de calificación, Nombre corto de la calificación.

Tabla 30 Historia de Usuario. Registro de Configuración de Calificaciones.

Historia de usuario


Nombre de la historia: Modificación de Configuración de Calificaciones



Descripción: El sistema permite a la Secretaria modificar las Configuraciones

de Calificación de cada período, subperíodo o parcial.

Observaciones:

La información de Configuración de Calificación que se puede modificar es:

Nombre de calificación, Nombre corto de la calificación.

Tabla 31 Historia de Usuario. Modificación de Configuración de Calificaciones.

28

Historia de usuario


Nombre de la historia: Eliminación de Configuración de Calificaciones



Descripción: El sistema permite a la Secretaria eliminar una Configuración de

Calificación.

Observaciones:

Tabla 32 Historia de Usuario. Eliminación de Configuración de Calificaciones.

Historia de usuario


Nombre de la historia: Registro de Curso.



Descripción: El sistema permite a la Secretaria registrar la información de los

cursos.

Observaciones:

La información de Curso es:

Nivel educativo, paralelo, nombre del dirigente y horario.

La información de Horario que se registra es:

Materia, profesor, aula, hora de entrada y salida.

Tabla 33 Historia de Usuario. Registro de Curso.

Historia de usuario


Nombre de la historia: Modificación de Curso.



29


Curso, seleccionado de una lista.

Observaciones:

La información de Curso que se modifica es:

Nivel educativo, paralelo, nombre del dirigente y horario.

La información de Horario que se modifica es:

Profesor, aula, hora de entrada y salida.

Tabla 34 Historia de Usuario. Modificación de Curso.

Historia de usuario

Número: 34 Usuario: Secretaria, Profesor

Nombre de la historia: Generación de Reportes Académicos.



Descripción: El sistema permite al Usuario generar reportes de la información

académica de la institución.

Observaciones:

Los reportes son:

Ø Listado de Cursos

Ø Horarios

Ø Listado de Útiles

Ø Listado de Estudiantes

Ø Listado de Profesores

Ø Listado de Materias

Tabla 35 Historia de Usuario. Generación de Reportes Académicos.

30

2.1.1.1.2 Módulo 3: Gestión Estudiantil

Historia de usuario

Número: 35 Usuario: Estudiante

Nombre de la historia: Información del estudiante.

Prioridad en el negocio: MEDIA Riesgo en desarrollo: MEDIO


Descripción: El sistema permite al estudiante visualizar su información

personal y académica.

Observaciones:

La información que se muestra del estudiante es:

Información personal, datos de la matrícula y horario de clases.

Tabla 36 Historia de Usuario. Información del Estudiante.

Historia de usuario


Nombre de la historia: Registro de Matrícula.


Puntos estimados: 1 Iteración asignada: 2

Descripción: El sistema permite a la Secretaria matricular a un estudiante en

un curso.

Observaciones:

El proceso de matriculación comienza con la inscripción del estudiante en un

curso, luego se habilitan automáticamente los requisitos y una vez que se han

revisado todos se matricula al estudiante.

Tabla 37 Historia de Usuario. Registro de Matrícula.

31

Historia de usuario


Nombre de la historia: Anulación de Matrícula.



Descripción: El sistema permite a la Secretaria anular la matricular de un

estudiante del periodo actual.

Observaciones:

Tabla 38 Historia de Usuario. Anulación de Matrícula.

Historia de usuario


Nombre de la historia: Registro de Asistencia.



Descripción: El sistema permite al Profesor registrar la asistencia de los

estudiantes de un curso.

Observaciones:

Los profesores dirigentes se encargan de registrar la asistencia.

El estado de asistencia es: Presente, falta justificada, falta Injustificada, fuga o

atraso.

Tabla 39 Historia de Usuario. Registro de Asistencia.

Historia de usuario


Nombre de la historia: Modificación de Asistencia.



32

Descripción: El sistema permite al Profesor modificar la asistencia de los


Observaciones:

Los profesores dirigentes se encargan de modificar la asistencia.

Tabla 40 Historia de Usuario. Modificación de Asistencia.

Historia de usuario


Nombre de la historia: Registro de Calificaciones.



Descripción: El sistema permite al Profesor registrar la calificación de los


Observaciones:

Tabla 41 Historia de Usuario. Registro de Calificaciones.

Historia de usuario


Nombre de la historia: Modificación de Calificaciones.



Descripción: El sistema permite al Profesor modificar la calificación de los


Observaciones:

Tabla 42 Historia de Usuario. Modificación de Calificaciones

33

Historia de usuario

Número: 42 Usuario: Secretaria, Profesor,

Estudiante

Nombre de la historia: Generación de reportes estudiantiles



Descripción: El sistema permite al usuario generar reportes de la información

de los estudiantes.

Observaciones:

Los reportes son:

Ø Reporte de Calificaciones

Ø Reporte de Asistencia

Ø Listado de Estudiantes

Tabla 43 Historia de Usuario. Generación de Reportes Estudiantiles.

2.1.1.2 Estimación de Historias de Usuario

La valoración de las historias de usuario se realiza en las reuniones de planificación,

donde el equipo de desarrollo estima la duración de cada historia de usuario, y el

cliente decide que historia de usuario tiene mayor importancia o prioridad para el

negocio.

En la Tabla 44 se muestran los resultados de la priorización y estimación realizadas

por el cliente y el equipo de desarrollo. Los elementos que se presentan en la tabla

se basan en un Proyecto de Titulación de referencia5, el cual nos proporcionó

información útil para establecer los parámetros.

5 Pullas Elizabeth, Desarrollo de un Sistema para Voto Electrónico y Emisión de Resultados en Procesos Electorales de la Escuela Politécnica Nacional. Proyecto de Titulación.EPN.2010.

34

Los parámetros a considerar son:

Prioridad: es el orden de importancia considerado para el negocio.

Riesgo: es el riesgo que afronta el equipo de desarrollo para la obtención de

resultados de cada historia de usuario.

Tiempo Estimado: para realizar la estimación del Tiempo Estimado se considera:

Ø Una semana de duración es equivalente a 1 punto de estimación.

Ø Una semana equivale a 5 días laborables.

Ø Cada día laborable se trabaja 5 horas.

Ø El equipo de desarrollo está conformado por dos personas.

35

Mó

du

lo

No

H

isto

ria

s d

e U

sua

rio

P

rio

rid

ad

R

iesg

o

Tie

mp

o E

stim

ad

o

Se

ma

na

Día

Ho

ras

Ad

min

istr

aci

ón

Inte

gra

nte

In

stit

uci

on

al

01

R

egis

tro

de

Inte

gran

te In

stit

uci

on

al

ALT

A

ALT

O

0,8

4

2

0

02

M

od

ific

ació

n d

e In

tegr

ante

Inst

itu

cio

nal

A

LTA

A

LTO

0

,4

2

10

Usu

ari

os

03

R

egis

tro

de

Usu

ario

A

LTA

A

LTO

0

,8

4

20

04

M

od

ific

ació

n d

e U

suar

io

ALT

A

ALT

O

0,4

2

1

0

Acc

eso

0

5

Acc

eso

al s

iste

ma

ALT

A

ALT

O

0,4

2

1

0

Pa

rám

etr

os

Aca

dé

mic

os

06

R

egis

tro

de

Niv

ele

s Ed

uca

tivo

s A

LTA

A

LTO

0

,6

3

15

07

M

od

ific

ació

n d

e N

ivel

es

Edu

cati

vos

ALT

A

ALT

O

0,4

2

1

0

08

El

imin

ació

n d

e N

ive

l Ed

uca

tivo

A

LTA

A

LTO

0

,4

2

10

09

R

egis

tro

de

Mat

eria

s A

LTA

A

LTO

0

,6

3

15

10

M

od

ific

ació

n d

e M

ater

ias

ALT

A

ALT

O

0,4

2

1

0

11

El

imin

ació

n d

e M

ater

ia

ALT

A

ALT

O

0,4

2

1

0

12

R

egis

tro

de

Au

las

ALT

A

ALT

O

0,6

3

1

5

13

M

od

ific

ació

n d

e A

ula

s A

LTA

A

LTO

0

,4

2

10

14

El

imin

ació

n d

e A

ula

A

LTA

A

LTO

0

,4

2

10

15

R

egis

tro

de

Esp

ecia

lidad

es

ALT

A

ALT

O

0,6

3

1

5

16

M

od

ific

ació

n d

e Es

pe

cial

idad

es

ALT

A

ALT

O

0,4

2

1

0

17

El

imin

ació

n d

e Es

pec

ialid

ad

ALT

A

ALT

O

0,4

2

1

0

18

R

egis

tro

de

Req

uis

ito

s d

e M

atrí

cula

A

LTA

A

LTO

0

,6

3

15

19

M

od

ific

ació

n d

e R

equ

isit

os

de

Mat

rícu

la

ALT

A

ALT

O

0,4

2

1

0

20

El

imin

ació

n d

e R

equ

isit

o d

e M

atrí

cula

A

LTA

A

LTO

0

,4

2

10

36

21

R

egis

tro

de

Mat

eria

les

Aca

dé

mic

os

BA

JA

BA

JO

0,4

2

1

0

22

M

od

ific

ació

n d

e M

ater

iale

s A

cad

émic

os

BA

JA

BA

JO

0,4

2

1

0

23

El

imin

ació

n d

e M

ater

iale

s A

cad

émic

os

BA

JA

BA

JO

0,4

2

1

0

Inst

itu

ció

n

24

R

egis

tro

de

Dat

os

de

la In

stit

uci

ón

A

LTA

A

LTO

0

,4

2

10

25

M

od

ific

ació

n d

e D

ato

s d

e la

Inst

itu

ció

n

ALT

A

ALT

O

0,4

2

1

0

Pe

río

do

s

26

R

egis

tro

de

Per

íod

o

MED

IA

MED

IO

0,8

4

2

0

27

M

od

ific

ació

n d

e P

erío

do

Act

ual

M

EDIA

M

EDIO

0

,6

3

15

28

El

imin

ació

n d

e P

erío

do

M

EDIA

M

EDIO

0

,6

3

15

29

R

egis

tro

de

Co

nfi

gura

cio

nes

de

Cal

ific

ació

n

MED

IA

MED

IO

0,8

4

2

0

30

M

od

ific

ació

n d

e C

on

figu

raci

ón

de

Cal

ific

ació

n

MED

IA

MED

IO

0,4

2

1

0

31

El

imin

ació

n d

e C

on

figu

raci

ón

de

Cal

ific

ació

n

MED

IA

MED

IO

0,4

2

1

0

Cu

rso

s 3

2

Reg

istr

o d

e C

urs

o

MED

IA

MED

IO

0,8

4

2

0

33

M

od

ific

ació

n d

e C

urs

o

MED

IA

MED

IO

0,8

4

2

0

Re

po

rte

s A

cad

ém

ico

s 3

4

Gen

erac

ión

de

Rep

ort

es

Aca

dém

ico

s M

EDIA

M

EDIO

0

,8

4

20

Ge

stió

n

Est

ud

ian

til

Info

rma

ció

n

35

In

form

ació

n d

el E

stu

dia

nte

B

AJA

B

AJO

0

,4

2

10

Ma

tríc

ula

3

6

Reg

istr

o d

e M

atrí

cula

B

AJA

B

AJO

1

5

2

5

37

A

nu

laci

ón

de

Mat

rícu

la

BA

JA

BA

JO

0,4

2

1

0

Ev

alu

aci

ón

38

R

egis

tro

de

Asi

sten

cia

BA

JA

BA

JO

0,8

4

2

0

39

M

od

ific

ació

n d

e A

sist

enci

a B

AJA

B

AJO

0

,4

2

10

40

R

egis

tro

de

Cal

ific

acio

ne

s B

AJA

B

AJO

0

,8

4

20

41

M

od

ific

ació

n d

e C

alif

icac

ion

es

BA

JA

BA

JO

0,4

2

1

0

Re

po

rte

s E

stu

dia

nti

les

42

G

ener

ació

n d

e R

epo

rte

s Es

tud

ian

tile

s B

AJA

B

AJO

0

,8

4

20

Tab

la 4

4 E

stim

ació

n d

e H

isto

ria

s d

e U

suar

io.

37

2.1.2 PLAN DE ENTREGAS

Para elaborar el plan de entregas del presente proyecto se agrupan las historias de

usuario en entregables; se determina la iteración, el tiempo calendario y el esfuerzo

de desarrollo de cada historia de usuario.

Tiempo Calendario

Para la estimación del Tiempo Calendario se especifica las horas, días y semanas

por mes, como se muestra en la Tabla 45.

Calendario Estimado

Semanas por mes Días por semana Horas por día

4 5 5

Tabla 45 Tiempo Calendario.

Esta estimación permite calcular el esfuerzo utilizado para el desarrollo del presente

proyecto.

Esfuerzo de Desarrollo

Para la estimación del esfuerzo de Desarrollo se considera al grupo de trabajo como

una persona, por lo tanto:

Esfuerzo por semana de desarrollo: 1 persona = 1 semana

Esfuerzo por días de desarrollo: 1 persona = 5 días

Esfuerzo por horas calendario de desarrollo (día calendario): 1 persona = 5 horas.

De acuerdo al análisis, se tiene:

Personas en el

Equipo

Horas (día calendario) de

Esfuerzo de Desarrollo

Días de Esfuerzo de

Desarrollo

Semana de Esfuerzo de

Desarrollo

1 persona

5 horas

5 días

1 semana

Tabla 46 Esfuerzo de Desarrollo en base a una persona

En la Tabla 47 se muestra el Plan de Entregas del presente proyecto, basado en el

Proyecto de Titulación de Referencia6.

6 Pullas Elizabeth, Desarrollo de un Sistema para Voto Electrónico y Emisión de Resultados en Procesos Electorales de la Escuela Politécnica Nacional. Proyecto de Titulación.EPN.2010.

38

Mó

du

lo

N°

His

tori

as

de

Usu

ari

o

Esf

ue

rzo

de

De

sarr

oll

o

Ca

len

da

rio

est

ima

do

E

ntr

eg

a

asi

gn

ad

a

Se

ma

na

s

Día

s H

ora

s S

em

an

as

Día

s H

ora

s 1

2

3

Ad

min

istr

aci

ón

Inte

gra

nte

Inst

itu

cio

na

l

01

R

egis

tro

de

Inte

gran

te In

stit

uci

on

al

0,8

4

2

0

0,8

4

2

0

X

02

M

od

ific

ació

n d

e In

tegr

ante

Inst

itu

cio

nal

0

,4

2

10

0

,4

2

10

X

Usu

ari

os

03

R

egis

tro

de

Usu

ario

0

,8

4

20

0

,8

4

20

X

04

M

od

ific

ació

n d

e U

suar

io

0,4

2

1

0

0,4

2

1

0

X

A

cce

so

05

A

cce

so a

l sis

tem

a 0

,4

2

10

0

,4

2

10

X

Pa

rám

etr

os

Aca

dé

mic

os

06

R

egis

tro

de

Niv

ele

s Ed

uca

tivo

s 0

,6

3

15

0

,6

3

15

X

07

M

od

ific

ació

n d

e N

ivel

es

Edu

cati

vos

0,4

2

1

0

0,4

2

1

0

X

0

8

Elim

inac

ión

de

Niv

el E

du

cati

vo

0,4

2

1

0

0,4

2

1

0

X

0

9

Reg

istr

o d

e M

ater

ias

0,6

3

1

5

0,6

3

1

5

X

1

0

Mo

dif

icac

ión

de

Mat

eria

s 0

,4

2

10

0

,4

2

10

X

11

El

imin

ació

n d

e M

ater

ia

0,4

2

1

0

0,4

2

1

0

X

1

2

Reg

istr

o d

e A

ula

s 0

,6

3

15

0

,6

3

15

X

13

M

od

ific

ació

n d

e A

ula

s 0

,4

2

10

0

,4

2

10

X

14

El

imin

ació

n d

e A

ula

0

,4

2

10

0

,4

2

10

X

15

R

egis

tro

de

Esp

ecia

lidad

es

0,6

3

1

5

0,6

3

1

5

X

1

6

Mo

dif

icac

ión

de

Esp

eci

alid

ade

s 0

,4

2

10

0

,4

2

10

X

17

El

imin

ació

n d

e Es

pec

ialid

ad

0,4

2

1

0

0,4

2

1

0

X

1

8

Reg

istr

o d

e R

equ

isit

os

de

Mat

rícu

la

0,6

3

1

5

0,6

3

1

5

X

1

9

Mo

dif

icac

ión

de

Req

uis

ito

s d

e

0,4

2

1

0

0,4

2

1

0

X

39

Mat

rícu

la

20

El

imin

ació

n d

e R

equ

isit

o d

e M

atrí

cula

0

,4

2

10

0

,4

2

10

X

21

R

egis

tro

de

Mat

eria

les

Aca

dé

mic

os

0,4

2

1

0

0,4

2

1

0

X

22

M

od

ific

ació

n d

e M

ater

iale

s

Aca

dém

ico

s 0

,4

2

10

0

,4

2

10

X

23

El

imin

ació

n d

e M

ater

iale

s A

cad

émic

os

0,4

2

1

0

0,4

2

1

0

X

Inst

itu

ció

n

24

R

egis

tro

de

Dat

os

de

la In

stit

uci

ón

0

,4

2

10

0

,4

2

10

X

25

M

od

ific

ació

n d

e D

ato

s d

e la

Inst

itu

ció

n

0,4

2

1

0

0,4

2

1

0

X

Pe

río

do

s

26

R

egis

tro

de

Per

íod

o

0,8

4

2

0

0,8

4

2

0

X

2

7

Mo

dif

icac

ión

de

Per

íod

o A

ctu

al

0,6

3

1

5

0,6

3

1

5

X

2

8

Elim

inac

ión

de

Per

íod

o

0,6

3

1

5

0,6

3

1

5

X

29

R

egis

tro

de

Co

nfi

gura

ció

n d

e

Cal

ific

acio

nes

0

,8

4

20

0

,8

4

20

X

30

M

od

ific

ació

n d

e C

on

figu

raci

ón

de

Cal

ific

acio

nes

0

,4

2

10

0

,4

2

10

X

31

El

imin

ació

n d

e C

on

figu

raci

ón

de

Cal

ific

acio

nes

0

,4

2

10

0

,4

2

10

X

Cu

rso

s 3

2

Reg

istr

o d

e C

urs

o

0,8

4

2

0

0,8

4

2

0

X

3

3

Mo

dif

icac

ión

de

Cu

rso

0

,8

4

20

0

,8

4

20

X

Re

po

rte

s

Aca

dé

mic

os

34

G

ener

ació

n d

e R

epo

rte

s A

cad

émic

os

0,8

4

2

0

0,8

4

2

0

X

Info

rma

ció

n

35

In

form

ació

n d

el E

stu

dia

nte

0

,4

2

10

0

,4

2

10

X

Ge

stió

n

Ma

tríc

ula

3

6

Reg

istr

o d

e M

atrí

cula

1

5

2

5

1

5

25

X

40

Est

ud

ian

til

37

A

nu

laci

ón

de

Mat

rícu

la

0,4

2

1

0

0,4

2

1

0

X

Ev

alu

aci

ón

38

R

egis

tro

de

Asi

sten

cia

0,8

4

2

0

0,8

4

2

0

X

3

9

Mo

dif

icac

ión

de

Asi

sten

cia

0,4

2

1

0

0,4

2

1

0

X

4

0

Reg

istr

o d

e C

alif

icac

ion

es

0,8

4

2

0

0,8

4

2

0

X

4

1

Mo

dif

icac

ión

de

Cal

ific

acio

nes

0

,4

2

10

0

,4

2

10

X

Re

po

rte

s

Est

ud

ian

tile

s 4

2

Gen

erac

ión

de

Rep

ort

es

Estu

dia

nti

les

0,8

4

2

0

0,8

4

2

0

X

Tab

la 4

7 P

lan

de

En

treg

a.

41

2.2 DISEÑO

Posterior a la obtención del plan de entregas, el equipo de desarrollo realiza

actividades de diseño que brindan una visión clara de la implementación del sistema.

Las actividades de diseño que se realizan en el presente proyecto son:

Metáfora del sistema.

Diagrama de clases.

Diseño del modelo conceptual.

Diseño de las tarjetas CRC.

Diseño arquitectónico.

Diseño de interfaces gráficas.

2.2.1 METÁFORA DEL SISTEMA

La Metáfora del Sistema permite describir de una manera clara lo que va hacer el

sistema a partir de las historias de usuario; para ello se usa un vocabulario técnico

y entendible para el cliente.

La metáfora del sistema PROVSIS está compuesta por la descripción técnica de los

módulos que lo conforman: Módulo de Administración, Módulo de Gestión

Académica y Módulo de Gestión Estudiantil.

MÓDULO DE ADMINISTRACIÓN

Este módulo permite gestionar la información de los integrantes institucionales,

administrar usuarios, gestionar los parámetros académicos y registrar los datos de la

Institución.

42

Gestión de Integrantes Institucionales

Permite Registrar y Modificar la información de los Integrantes Institucionales (se

consideran Integrantes Institucionales a los profesores y estudiantes).

Registro de Estudiantes

Permite registrar un nuevo estudiante con la siguiente información:

número de cédula de ciudadanía, nombres, apellido paterno, apellido

materno, fecha de nacimiento, dirección, teléfono, número de celular,

dirección de correo electrónico y nombre del representante.

Registro de Profesor

Permite registrar un nuevo profesor con la siguiente información:

número de cédula de ciudadanía, nombres, apellido paterno, apellido

materno, fecha de nacimiento, dirección, teléfono, número de celular y

dirección de correo electrónico.

Registro del Administrador del Sistema

Permite registrar un nuevo administrador del sistema con la siguiente

información: número de cédula de ciudadanía, nombres, apellido

paterno, apellido materno, fecha de nacimiento, dirección, teléfono,

número de celular y dirección de correo electrónico.

Modificación de Integrantes Institucionales

Permite modificar la información de un integrante institucional, el cual

se selecciona de una lista que se obtiene de la búsqueda por nombre,

número de cédula o perfil.

Gestión de Usuarios

Permite registrar, modificar o eliminar los usuarios del sistema.

Registro de Usuario

Permite registrar un nuevo usuario con la siguiente información:

nombre de usuario, contraseña y el tipo de integrante institucional al

que corresponde.

43

Modificación de Usuarios

Permite modificar el nombre de usuario y la contraseña, el usuario se

selecciona de una lista que se obtiene de la búsqueda por perfil.

Parámetros Académicos

Permite gestionar la información de niveles educativos, materias, aulas,

especialidades, requisitos de matrícula y la lista de útiles escolares

Gestión de Niveles Educativos

Permite registrar, modificar o eliminar la información de los niveles

educativos establecidos por la institución de acuerdo a la ley de

educación.

Gestión de Materias

Permite registrar, modificar o eliminar la información de las materias,

por cada nivel educativo, que se imparte en el Colegio La Providencia.

Gestión de Aulas

Permite registrar, modificar o eliminar la información de las aulas

disponibles en la institución para impartir clases.

Gestión de Especialidades

Permite registrar, modificar o eliminar la información de las

especialidades establecidas por la institución de acuerdo a la ley de

educación.

Gestión de Requisitos de Matrícula

Permite registrar, modificar o eliminar la información de los requisitos

necesarios para la Matrícula del estudiante.

Gestión de materiales académicos

Permite registrar, modificar o eliminar los materiales académicos de

cada nivel.

44

Gestión de datos de la Institución

Permite registrar o modificar los datos de la institución: nombre, RUC,

dirección, teléfono, logo de la institución y nombre de la máxima autoridad del

plantel.

MÓDULO DE GESTIÓN ACADÉMICA

Este módulo permite gestionar los periodos escolares, administrar cursos y generar

reportes académicos.

Gestión de Periodos

Permite registrar un periodo escolar, modificar el periodo escolar actual, eliminar un

periodo escolar, configurar las calificaciones del periodo escolar actual o registrar las

fechas del periodo de matriculación.

Registro de Periodo

Permite registrar un nuevo periodo escolar con la siguiente información:

fecha de inicio y fin del periodo escolar y de matriculación, y tipo de

subperíodos (bimestre, trimestre o quimestre).

Permite la personalización del tipo de subperíodos.

Eliminación de Periodos

Permite eliminar un periodo escolar inactivo a partir de la lista de

periodos que muestra el sistema

Gestión de la Configuración de las Calificaciones

Permite registrar, modificar o eliminar las calificaciones de cada parcial,

subperíodo y periodo escolar.

Modificación de Período Actual

Muestra el periodo escolar vigente y permite modificar la fecha de inicio

y fin del período escolar, subperíodos, parciales, de matrículas y de

registro de calificaciones.

45

Cursos

Permite registrar o modificar cursos.

Registro de Curso

Permite registrar la información de los cursos correspondientes al

periodo escolar actual. Incluye la siguiente información: nivel, paralelo,

nombre del profesor dirigente, horario con el listado de materias,

nombre del profesor que imparte cada materia, nombre del aula y los

días con sus respectivas horas de entrada y de salida.

Modificación de Cursos

Permite modificar la información de un curso, el cual se selecciona de

una lista de cursos que presenta el sistema.

Reportes Académicos

Permite generar los siguientes reportes de la información académica de la

institución:

Listado de Cursos

Horarios

Listado de Útiles

Listado de Estudiantes

Listado de Profesores

Listado de Materias

MÓDULO DE GESTION ESTUDIANTIL

Este módulo permite mostrar la información académica del estudiante y matricular a

un estudiante.

Información del estudiante

Permite mostrar la información del estudiante: datos personales, datos académicos y

su horario de clases.

46

Matrícula

Permite inscribir y matricular a un estudiante registrado en el sistema.

Permite asignar un curso al estudiante registrado en el sistema, habilita la revisión

de requisitos de matrícula, una vez cumplida la verificación de requisitos se matricula

al estudiante para el periodo escolar actual.

.

Evaluación

Permite registrar y modificar la asistencia y las calificaciones de los estudiantes de

cada curso.

Registro de Asistencia

Permite al Profesor registrar la asistencia de los estudiantes de un

curso. Los valores de asistencia pueden ser: P: presente, FJ: falta

justificada, FI: falta Injustificada, F: fuga, A: atraso

Modificación de Asistencia

Permite al Profesor modificar la asistencia de los estudiantes de un

curso.

Registro de Calificaciones

Permite al profesor registrar las calificaciones de los estudiantes de

cada curso, correspondientes a la evaluación y materia seleccionadas.

El registro se realiza dentro del plazo establecido para su ingreso.

Cada profesor tiene definido un número de días adicional en los que

puede registrar la calificación.

Modificación de Calificaciones

Permite al profesor modificar la calificación de los estudiantes de cada

curso, correspondiente a la evaluación y la materia seleccionadas.

La modificación se realiza dentro del plazo establecido para su ingreso.

47

Reportes Estudiantiles

El sistema permite al Usuario generar los siguientes reportes de la información del

estudiante:

Registro de Calificaciones

Registro de Asistencia

Listado de Estudiantes

2.2.2 DIAGRAMA DE CLASES

El diseño del diagrama de clases proporciona información completa de la estructura

del sistema, mostrando: clases, atributos y relaciones entre clases.

En la Figura 2.2 se presenta la versión final del diagrama de clases que se diseñó a

través del desarrollo de cada historia de usuario.

48

Fig

ura

2.2

Dia

gra

ma

de

Cla

ses7

7 S

ALIN

AS

, P

atr

icio

. M

ode

lo d

e C

lase

s. h

ttp:

//use

rs.d

cc.u

chile

.cl/~

psa

linas

/um

l/mod

elo.h

tml

49

2.2.3 DISEÑO CONCEPTUAL

A partir del diagrama de clases se genera el diseño conceptual de datos del sistema.

El modelo conceptual permite al equipo de desarrollo describir la estructura de datos

de la base, las restricciones de integridad y las operaciones de manipulación de

datos.

En la Figura 2.3 se presente la versión final del diseño conceptual de datos del

sistema.

50

Fig

ura

2.3

Mo

del

o C

on

cep

tual

de

la B

ase

de

Dat

os

51

2.2.4 DISEÑO DE LAS TARJETAS CRC

Las Tarjetas CRC (Clase, Responsabilidad y Colaborador), contienen la información

del nombre de la clase, sus responsabilidades y sus colaboradores, permitiendo al

equipo de desarrollo conocer cada una de las clases que se implementarán en el

sistema.

En la Figura 2.4 se muestra el modelo de una tarjeta CRC basado en el diseño

propuesto por Kent Beck en la metodología XP.

NOMBRE DE LA CLASE

Responsabilidades Colaboradores

Figura 2.4 Tarjeta CRC8

Donde:

Nombre de la Clase: Es el nombre de la clase que se describe en la tarjeta CRC

Responsabilidades: Describe la funcionalidad de la clase

Colaboradores: Clases que colaboran con la clase descrita

8 KENT BECK Martin. Planning Extreme Programming. Addison Weley. 2000.

52

TARJETAS CRC DEL SISTEMA

En la Tabla 48 se muestra las tarjetas CRC clasificadas en: clases controladoras,

clases entidades y clases de servicio.

Clases controladoras. Clases Entidades. Clases de Servicio

Controlador Integrante

Institucional.

Integrante Institucional. Servicio Integrante

Institucional.

Controlador Usuario. Estudiante. Servicio Usuario.

Controlador Acceso Profesor. Servicio Nivel Educativo.

Controlador Nivel Educativo. Usuario. Servicio Parámetros.

Controlador Parámetros

Académicos.

Nivel Educativo. Servicio Período.

Controlador Institución. Materia. Servicio Curso.

Controlador Período. Aula. Servicio Control Curso.

Controlador Calificación. Especialidad. Servicio Matrícula.

Controlador Curso. Requisito.

Controlador Horario. Institución.

Controlador Material

Académico.

Periodo.

Controlador Información. Calificación.

Controlador Matrícula. Tipo Calificación

Controlador Asistencia. Curso.

Controlador Reportes. Horario.

Material académico.

Matrícula.

Asistencia.

Reporte.

Tabla 48 Tarjetas CRC del Sistema.

53

En la Tabla 49, Tabla 50 y Tabla 51 se presenta un ejemplo por cada clasificación de

las Tarjetas CRC del sistema.

CONTROLADOR MATRÍCULA


Inscribir al Estudiante registrado.

Verificar requisitos de matrícula.

Matricular al Estudiante inscrito.

Estudiante

Requisito Matrícula

Matrícula

Curso

Servicio Matrícula.

Tabla 49 Tarjeta CRC. Controlador Matrícula

MATRICULA


Devolver información de Matricula Estudiante

Requisito de Matrícula

Tabla 50 Tarjeta CRC. Matrícula

SERVICIO MATRÍCULA


Ingresar Matrícula en la BDD.

Actualizar Matrícula en la BDD.

Consultar Matrícula en la BDD.

Matrícula

Tabla 51 Tarjeta CRC. Servicio Matrícula

Las Tarjetas CRC que se utilizan en el desarrollo del sistema se adjuntan en el

Anexo A.

54

2.2.5 DISEÑO ARQUITECTÓNICO

El diseño arquitectónico del sistema PROVSIS se basa en la definición planteada

por la plataforma de desarrollo Java Enterprise Edition (Java EE). Donde se

identifican tres capas: Cliente, Servidor Java EE y Datos.

De esta forma las capas de la arquitectura del sistema se definen de la siguiente

manera:

Ø En la capa Cliente se utiliza un navegador web para acceder a la aplicación

web.

Ø En la capa Servidor Java EE se utiliza el patrón Modelo Vista Controlador

(MVC) para construir la aplicación web.

Ø En la capa de Datos se utiliza un motor de base de datos para almacenar la

información que utiliza el sistema.

En la Figura 2.5 se muestran los componentes de la arquitectura del sistema junto

con las tecnologías que se utilizan y las relaciones entre ellos, basados en la

arquitectura propuesta en Java EE 5.

55

Figura 2.5 Arquitectura del Sistema.9

9 ORACLE. The Java EE 5 Tutorial. 2007.

56

2.2.6 DISEÑO DE INTERFACES

En la Figura 2.6 se muestra la organización de los elementos que se observan en las

páginas web del sistema.

Figura 2.6 Plantilla para el diseño de las interfaces de usuario.

Donde:

El Logo contiene la imagen del logotipo y el nombre de la institución.

El Menú principal contiene los enlaces para acceder a los módulos y submódulos

del sistema.

El Menú lateral contiene los enlaces para acceder a las opciones de los submódulos

del sistema.

El Título contiene un texto representativo de la página web que está siendo

utilizada.

57

La zona de Mensajes se utiliza para mostrar tres tipos de mensajes: información,

advertencia y error.

En el Contenido se encuentran los elementos que permiten implementar las

historias de usuario.

El Pie de página contiene la información sobre: las reglas de uso, presentación de

la institución y presentación de los autores de la aplicación.

2.2.7 ESTRUCTURA JERÁRQUICA DEL SITIO WEB

En la Figura 2.7 se muestra la estructura jerárquica de las páginas web del sistema,

organizadas en módulos y submódulos de acuerdo a la clasificación de las historias

de usuario.

58

F

igu

ra 2

.7 M

apa

del

Sit

io W

eb

Acc

eso

de

Sesi

ón

Ges

tió

n A

cad

émic

a

Per

íod

os

Reg

istr

o d

e P

erío

do

Mo

dif

icac

ión

P

erío

do

Act

ual

Elim

inac

ión

de

Per

íod

o

Cu

rso

s

Reg

istr

o d

e C

urs

o

Mo

dif

icac

ión

d

e C

urs

os

Rep

ort

es

Aca

dém

ico

s

List

ado

de

Cu

rso

s

Ho

rari

os

List

ado

de

Úti

lies

List

ado

de

Estu

dia

nte

List

ado

de

Pro

feso

res

List

ado

de

Mat

eria

s

Ges

tió

n E

stu

dia

nti

l

Info

rmac

ión

Dat

os

del

Es

tud

ian

te

Mat

rícu

la

Reg

istr

o d

e M

atrí

cula

An

ula

ció

n d

e M

atrí

cula

Eval

uac

ión

Reg

isto

de

Asi

sten

cia

Reg

istr

o d

e C

alif

icac

ion

es

Rep

ort

es

Estu

dia

nti

les

Rep

ort

e d

e C

alif

icac

ion

es

Rep

ort

e d

e A

sist

enci

a

List

ado

de

Estu

dia

nte

s

Ad

min

istr

ació

n

Inte

gran

tes

Inst

itu

cio

nal

es

Reg

istr

o d

e Es

tud

ian

te

Reg

istr

o d

e P

rofe

sor

Reg

istr

o d

e A

dm

inis

trad

or

Mo

dif

icac

ión

d

e In

tegr

ante

s

Usu

ario

s

Reg

istr

o d

e U

suar

io

Mo

dif

icac

ión

d

e U

suar

ios

Par

ámet

ros

Aca

dém

ico

s

Niv

eles

Mat

eria

s

Au

las

Esp

ecia

lidad

es

Req

uis

ito

s M

atrí

cula

Mat

eria

les

Aca

dém

ico

s

Inst

itu

ció

n

Dat

os

de

la

Inst

itu

ció

n

59

2.3 IMPLEMENTACIÓN

Una vez definido el plan de entregas, el equipo de desarrollo identifica las historias

de usuario que se comenzaran a implementar.

2.3.1 CRONOGRAMA DE IMPLEMENTACIÓN DE ITERACIONES

En esta fase se planifican las tareas de ejecución y se determinan la fecha de inicio

y fin de implementación de las historia de usuario.

Las tareas de ejecución que XP recomienda para cada historia de usuario son:

1. Análisis de requerimientos

2. Diseño de Base de Datos

3. Diseño con tarjetas CRC

4. Programación

5. Pruebas de Aceptación

Tareas de implementación

En la Figura 2.8 se muestra la planificación de las tareas de la primera historia de

usuario de la Primera Iteración.

Figura 2.8 Planificación de la Primera Iteración. Ejemplo

En el Anexo B se encuentra el cronograma completo de las tareas correspondientes

a cada Iteración.

60

2.3.2 IMPLEMENTACIÓN DE LAS ITERACIONES

Para implementar cada historia de usuario el equipo de desarrollo utiliza los

elementos de diseño definidos en la sección 2.2.

A continuación se presenta un ejemplo de implementación, utilizando la historia de

usuario: “Registro de Integrante Institucional”

Análisis de Requerimientos.

En una reunión con el equipo de desarrollo, el cliente define la prueba de aceptación

para la historia de usuario.

Diseño de Base de Datos.

El equipo de desarrollo identifica y analiza las tablas de la base de datos que se

utilizan en la implementación de la historia de usuario, si es necesario se modifican

las tablas involucradas. Para nuestro ejemplo son: Integrante Institucional,

Estudiante y Profesor.

Diseño CRC

El equipo de desarrollo identifica las Tarjetas CRC que se utilizarán en la

implementación de la historia de usuario. Para nuestro ejemplo son: Controlador

Integrante Institucional, Servicio Integrante Institucional, Integrante Institucional.

Codificación

Para la codificación del proyecto se utiliza el IDE de desarrollo Eclipse, se crea un

proyecto empresarial, cuya estructura se observa en la Figura 2.9, basada en el

empaquetamiento de aplicaciones de Java EE 5.

61

Figura 2.9 Estructura del proyecto empresarial PROVSIS.10

Donde:

El proyecto EJB contiene los paquetes de servicios y entidades.

En el paquete de Entidades se encuentran las clases que mantienen la

persistencia con la base de datos.

En el paquete de Servicios se encuentran las interfaces y las clases java que

implementan los métodos para la interacción con las entidades de la base de

datos.

10 ORACLE. The Java EE 5 Tutorial. 2007.

62

El proyecto Web contiene el directorio WebContent y el paquete Controladores.

En el directorio WebContent se encuentran las páginas XHTML que se utilizan

para implementar las interfaces de usuario.

En el paquete Controladores se encuentran las clases java donde se

implementa la lógica del negocio.

En el proyecto empresarial se unen el proyecto EJB y el proyecto Web, para generar

una aplicación web que puede ser publicada en el servidor de aplicaciones.

Codificación de la historia de usuario

Como ejemplo se utiliza la historia de usuario “Registro de Integrante Institucional”

para ilustrar la codificación.

Construcción de la página web.

Para respetar el formato propuesto para las páginas web del sistema, se codifica

una plantilla utilizando etiquetas JSF; después se crean las páginas web vacías de

acuerdo a la estructura jerárquica del sistema (Figura 2.7).

El código de la plantilla utilizada en todo el proyecto Web es:

plantilla.xhtml

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">



<html xmlns="http://www.w3.org/1999/xhtml"

xmlns:h="http://java.sun.com/jsf/html"

xmlns:a4j="http://richfaces.org/a4j"

xmlns:rich="http://richfaces.org/rich"

xmlns:f="http://java.sun.com/jsf/core"

xmlns:ui="http://java.sun.com/jsf/facelets">

<head>

63

<meta http-equiv="content-type" content="text/html; charset=utf-8" />

<title>La Providencia</title>

<a4j:loadStyle src="/style.css" />

</head>

<body>

<div id="wrapper" >

<ui:include src="/plantillas/encabezado.xhtml" />

<div id="page">

<div id="content">

<div class="post">

<rich:messages styleClass="message" globalOnly="true" showDetail="false">

<f:facet name="errorMarker">

<h:graphicImage value="/images/msgerror.png" />

</f:facet>

<f:facet name="infoMarker">

<h:graphicImage value="/images/msginfo.png" />

</f:facet>

<f:facet name="warnMarker">

<h:graphicImage value="/images/msgwarn.png" />

</f:facet>

</rich:messages>

<h2 class="title">

<a href="#"><ui:insert name="titulo" /></a>

</h2>

<div style="clear: both;"> </div>

<ui:insert name="contenido" />

</div>




</div>



<div id="sidebar">

<div id="left">

<ui:insert name="menu_lateral" />

</div>

</div>




</div>

64

<div id="footer">

<p> <a href="#"> </a>.</p>

</div>



</div>

</body>

</html>

Utilizando la página plantilla.xhtml se diseña la interfaz de usuario de “Registro de

Integrante Institucional” en la página integranteInstitucional.xhtml

integranteInstitucional.xhtml

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">







<ui:composition template="/plantillas/plantilla.xhtml">

<ui:define name="menu_lateral">

<ui:include src="/plantillas/menuIntegrantes.xhtml" />

</ui:define>

<ui:define name="titulo">

<h:outputLabel value="#{integranteControlador.criterioTipoIntegrante}" />

</ui:define>

<ui:define name="contenido">

<ui:include src="/integrantes/integrante-fragmento.xhtml" />

</ui:define>

</ui:composition>

</html>

fragmentoIntegrante.xhtml

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

65







<ui:composition>

<script src="/provsis/jquery/jquery.maskedinput-1.3.js" type="text/javascript"></script>

<script src="/provsis/jquery/livevalidation_standalone.js" type="text/javascript"></script>

<script>

jQuery(document).ready(function(){

jQuery("#fono input").mask("(99) 9999-999");

});

</script>

<div align="center" >

<h:form id="form_ingreso_integrante" >

<h:panelGrid columns="2" styleClass="entry">

<h:outputLabel value="Cédula " />

<h:panelGroup>

<h:inputText id="txt_cedula"

value="#{integranteControlador.integrante.cedula}" maxlength="10"

validator="numberValidator"/>

<script type="text/javascript">

var cedula = new LiveValidation('form_ingreso_integrante:txt_cedula');

cedula.add(Validate.Length, { is: 10, wrongLengthMessage: "Deben ser 10

caracteres!"} );

</script>

<rich:message for="txt_cedula" showSummary="true" />

</h:panelGroup>

<h:outputLabel value="Nombres" />

<h:inputText value="#{integranteControlador.integrante.nombres}" />

<h:outputLabel value="Apellido Paterno" />

<h:inputText

value="#{integranteControlador.integrante.apellidoPaterno}" />

<h:outputLabel value="Apellido Materno" />

<h:inputText

value="#{integranteControlador.integrante.apellidoMaterno}" />

<h:outputLabel value="Fecha de Nacimiento" />

<rich:calendar

66

value="#{integranteControlador.integrante.fechaNacimiento}" />

<h:outputLabel value="Dirección" />

<h:inputText

value="#{integranteControlador.integrante.direccion}" />

<h:outputLabel value="Teléfono: " />

<h:panelGroup>

<span id="fono">

<h:inputText id="txt_telefono"

value="#{integranteControlador.integrante.telefono}"/>

<rich:message for="txt_telefono" showSummary="true" />

</span>

</h:panelGroup>

<h:outputLabel value="Celular: " />

<h:panelGroup>

<span id="fono">

<h:inputText value="#{integranteControlador.integrante.celular}"

id="txt_celular"/>

<rich:message for="txt_celular" showSummary="true" />

</span>

</h:panelGroup>

<h:outputLabel value="Correo Electrónico: " />

<h:inputText id="txt_mail" value="#{integranteControlador.integrante.email}" />

<h:outputLabel value="Perfil: " />

<h:selectOneMenu value="#{integranteControlador.criterioTipoIntegrante}"

rendered="#{integranteControlador.editando}" >

<f:selectItem itemLabel="Estudiante" itemValue="estudiante"/>

<f:selectItem itemLabel="Profesor" itemValue="profesor"/>

<f:selectItem itemLabel="Administrador" itemValue="administrador"/>

</h:selectOneMenu>

<h:outputLabel value="#{integranteControlador.criterioTipoIntegrante}"

rendered="#{!integranteControlador.editando}"/>

</h:panelGrid>

<h3 class="title">

<h:commandLink value="Informacion complementaria"

rendered="#{integranteControlador.criterioTipoIntegrante=='estudiante'}"/>

</h3>

67

<h:panelGrid columns="2" styleClass="entry" id="representante" >

<h:outputLabel value="Nombre Representante: "


<h:inputText value="#{integranteControlador.integrante.nombreRepresentante}"


</h:panelGrid>

<a4j:commandButton value="Guardar" reRender="form_ingreso_integrante"

action="#{integranteControlador.guardarIntegrante}"></a4j:commandButton>

<script type="text/javascript">

var email = new LiveValidation('form_ingreso_integrante:txt_mail');

email.add( Validate.Email, { failureMessage: "Email no valido" });

</script>

</h:form>

</div>

</ui:composition>

</html>

Programación de la lógica del negocio.

Para implementar la lógica del negocio se utilizan las clases controladoras. Éstas a

su vez, utilizan los servicios del proyecto EJB para ingresar o modificar los datos en

la base.

Para el ejemplo, se utiliza la clase IntegranteControlador.java, la clase

IntegranteServicio.java y la interfaz IntegranteServicioLocal.java

IntegranteControlador.java

package com.ec.provsis.controladores;

//librerias importadas

public class IntegranteControlador {

@EJB

private IntegranteServicioLocal integranteServicio;

68

private Integrante integrante;

private List<Integrante> listaIntegrantes;

private String textoBusqueda;

private String criterioBusqueda;

private String criterioTipoIntegrante;

private Boolean editando;

public void guardarIntegrante() {

try {

integrante.setProfesor(false);

integrante.setEstudiante(false);

if(criterioTipoIntegrante.equals("profesor"))

integrante.setProfesor(true);

if(criterioTipoIntegrante.equals("estudiante"))

integrante.setEstudiante(true);

if(criterioTipoIntegrante.equals("administrador"))

{

integrante.setEstudiante(false);

integrante.setProfesor(false);

}

integrante = integranteServicio.guardarIntegrante(integrante);

FacesContext.getCurrentInstance().addMessage(null,new

FacesMessage(FacesMessage.SEVERITY_INFO,"Los datos de "+ integrante.getNombres() + " " +

integrante.getApellidoPaterno() +" han sido registrados. ", ""));

} catch (Exception e) {


FacesMessage(FacesMessage.SEVERITY_ERROR,"Los datos de "+ integrante.getNombres() + " " +

integrante.getApellidoPaterno() +" no se pudieron registrar. " +e.getMessage(), ""));

}

}

public void buscarIntegrante()

{

69

if (textoBusqueda == null || textoBusqueda.trim().isEmpty()) {

if(criterioTipoIntegrante.isEmpty())

listaIntegrantes = integranteServicio.consultarIntegrantes();

else

listaIntegrantes =

integranteServicio.consultarIntegrantes(criterioTipoIntegrante);

}

else {

listaIntegrantes =

integranteServicio.consultarIntegrantePorCriterio(criterioBusqueda, criterioTipoIntegrante,

textoBusqueda);

}

if (listaIntegrantes == null) {

listaIntegrantes = new ArrayList<Integrante>();


FacesMessage(FacesMessage.SEVERITY_INFO,"No se encontró ninguna Integrante

".concat(criterioBusqueda!=null?"con el criterio "+ criterioBusqueda.toUpperCase():""),

""));

}

}

//Métodos Get y Set.

}

IntegranteServicioLocal.java

package com.ec.provsis.servicios;


@Local

public interface IntegranteServicioLocal {

public List<Integrante> consultarIntegrantePorCriterio(String criterio, String

tipoIntegrante, String busqueda);

public List<Integrante> consultarIntegrantes();

70

public List<Integrante> consultarIntegrantes(String tipoIntegrante);

public Integrante consultarIntegrantePorId(int idIntegrante);

public Integrante guardarIntegrante(Integrante integrante) throws Exception;

public List<Usuario> consultarUsuarioPorIntegrante(Integrante integrante);

}

IntegranteServicio.java

package com.ec.provsis.servicios;


/**

* Session Bean implementation class IntegranteServicio

*/

@Stateless

public class IntegranteServicio implements IntegranteServicioLocal {

/**

* Default constructor.

*/

@PersistenceContext

private EntityManager em;

public Integrante guardarIntegrante(Integrante integrante) throws Exception

{

if(integrante==null)

throw new Exception("Ingrese correctamente para crear el Integrante

Institucional. ");

if(integrante.getNombres().isEmpty())

throw new Exception("Ingrese el nombre del Integrante Institucional.

");

if(integrante.getApellidoPaterno().isEmpty())

throw new Exception("Ingrese el apellido paterno del Integrante

Institucional. ");

71

if(integrante.getApellidoMaterno().isEmpty())

throw new Exception("Ingrese el apellido materno del Integrante

Institucional. ");

if(integrante.getFechaNacimiento()==null)

throw new Exception("Seleccione la fecha de nacimiento del Integrante

Institucional. ");

return em.merge(integrante);

}

public List<Integrante> consultarIntegrantePorCriterio(String criterio, String

tipoIntegrante, String busqueda) {

/**

* Implementación del método.

*/

}

@SuppressWarnings("unchecked")

public List<Integrante> consultarIntegrantes() {

/**


*/

}


public List<Integrante> consultarIntegrantes(String tipoIntegrante) {

/**


*/

}


public List<Usuario> consultarUsuarioPorIntegrante(Integrante integrante)

{

/**


*/

}

}

72

El resultado de la implementación de la historia de usuario “Registro de Integrante

Institucional” es una página de web funcional (Figura 2.10).

Figura 2.10 Interfaz de Usuario. Registro de Integrante institucional

Pruebas de aceptación.

Para finalizar la implementación se ejecuta la prueba de aceptación diseñada

previamente por el usuario, si después de evaluar la prueba el usuario indica que se

deben realizar cambios, el equipo de desarrollo debe registrarlos e implementarlos.

La implementación se completa solamente cuando el usuario satisface la prueba de

aceptación.

Para el ejemplo se ejecuta la prueba de aceptación número 2 que se detalla en el

capítulo 2.4 Pruebas.

73

2.3.3 SEGUIMIENTO DE LAS ITERACIONES

Para realizar una correcta implementación de un sistema con XP, se monitorea el

progreso del equipo de trabajo en intervalos de tiempo regulares, con el fin de saber

si se están cumpliendo los tiempos que fueron acordados en la planificación inicial.

Para realizar el monitoreo se utiliza el Reporte BurnDown 11que permite observar el

esfuerzo real del equipo de desarrollo en comparación con el esfuerzo estimado. El

reporte muestra la cantidad de trabajo faltante para completar la iteración.

Seguimiento de Primera Iteración

Diagrama BurnDown.

Figura 2.11 Diagrama BurnDown. Primera Iteración.

Como se observa en la Figura 2.11, la implementación de las primeras historias de

usuario tomó más tiempo del estimado; esto se debe a que el equipo de desarrollo

no tenía experiencia en el uso del Framework JSF y tuvo que aprender esta

11 PERALTA, Iván. Burndown chart. http://useragiledevelopment.blogspot.com/2011/05/burndown-chart.html. 13/10/2012.

-2,00

0,00

2,00

4,00

6,00

8,00

10,00

12,00

14,00

16,00

Tie

mp

o E

stim

ad

o

Inicio 26/03/2012 - Fin 06/07/2012

Esfuerzo Estimado vs Esfuerzo Real

Esfuerzo Estimado

74

tecnología, por esta razón se produjo un incremento en el tiempo estimado de cada

historia de usuario al inicio de la iteración.

Sin embargo, gracias a la programación en parejas, los integrantes del equipo de

desarrollo compartieron conocimientos valiosos a través de la investigación y la

práctica; como consecuencia, mejoraron el tiempo de implementación de las

historias de usuario finales.

Seguimiento Segunda Iteración

Diagrama BurnDown.

Figura 2.12 Diagrama BurnDown. Segunda Iteración.

Como se observa en la Figura 2.12, durante toda la iteración el esfuerzo real de las

historias de usuario fue mayor al estimado; debido a que, en esta iteración se

planificó la realización de las historias de usuario más complejas del sistema; estas

son: inscripción, matrícula, registro de asistencia y registro de calificaciones; se

consideran complejas por su grado de dependencia con las historias de usuario

implementadas en la primera iteración.

0,000,501,001,502,002,503,003,504,004,50

Tie

mp

o E

stim

ad

o

Inicio 09/07/2012 - Fin 06/08/2012


Esfuerzo Estimado

Esfuerzo Real

75

Seguimiento Tercera Iteración

Diagrama BurnDown.

Figura 2.13 Diagrama BurnDown. Tercera Iteración.

En la Figura 2.13 se observa que el esfuerzo real es menor al estimado durante toda

la iteración. Esto se debe a que el equipo de desarrollo adquirió experiencia en el

uso de la tecnología de desarrollo, se mejoró la comunicación con el cliente y se

reutilizó gran parte del código que se desarrolló en las anteriores iteraciones.

-1,00

-0,50

0,00

0,50

1,00

1,50

2,00

2,50

3,00

3,50

4,00

Est

ima

ció

n

Inicio 05/09/2012 - Fin 05/10/2012


Esfuerzo Estimado

76

2.4 PRUEBAS

2.4.1 PRUEBAS UNITARIAS

En la metodología XP se deben escribir las pruebas de unidad antes que el código,

permitiendo una rápida retroalimentación en el diseño y la corrección de errores.

Las pruebas de unidad son escritas por el desarrollador, esto le permite pensar en la

forma correcta de utilizar un módulo del sistema que aún no existe.

En el presente proyecto se utiliza JUnit como plataforma para la automatización de

las pruebas de unidad, disminuyendo el tiempo de construcción de las mismas y

permitiendo al desarrollador enfocarse en los resultados.

En el sistema PROVSIS, las pruebas de unidad son escritas para cada una de las

clases que se encargan de controlar las acciones del usuario, éstas están definidas

en las Tarjetas CRC como ‘Clases Controladoras’.

Cada clase tiene un conjunto de pruebas de unidad que validan el funcionamiento de

los métodos más importantes de la misma.

En la Tabla 52 se presenta las clases del sistema y los métodos sobre los que se

realizan las pruebas unitarias.

Clases de Test Clase del Sistema Métodos

Integrante Test Controlador Integrante

Institucional. Buscar, Guardar

Usuario Test Controlador Usuario. Buscar, Guardar

Acceso Test Controlador Acceso

Cambiar Contraseña,

Obtener Período Actual,

Obtener Usuario, Obtener

Institución.

Nivel Test Controlador Nivel Educativo. Buscar, Guardar, Eliminar

77

Parámetros Test Controlador Parámetros

Académicos. Buscar, Guardar, Eliminar

Institución Test Controlador Institución. Buscar, Guardar

Período Test Controlador Período. Buscar, Guardar, Modificar

Fechas, Eliminar.

Calificaciones

Test Controlador Calificación. Buscar, Guardar

Curso Test Controlador Curso. Buscar, Guardar

Horario Test Controlador Horario. Buscar, Guardar, Validar

Horario

Material Test Controlador Material

Académico. Buscar, Guardar

Matrícula Test Controlador Matrícula. Buscar, Guardar, Verificar

Requisitos

Asistencia Test Controlador Asistencia. Buscar, Guardar

Tabla 52 Pruebas de Unidad del Sistema PROVSIS.

Ejemplo de una prueba unitaria.

public class UsuarioTest { private Persona integrante; @EJB private PersonaServicioLocal personaServicio; @Before public void setUp() throws Exception { integrante = new Persona(); } /** * Caso de prueba que verifica que el objeto que se ingreso sea

* reemplazado por el objeto que se ingresó en la Base de Datos. Es * decir, que sean distintos.

* */ @Test public void testCase0() throws Exception { integrante.setEstado(true); integrante.setApellidoPaterno("Andrade"); integrante.setApellidoMaterno("Benavides"); integrante.setNombres("Daniel Andrés"); integrante.setCedula("1717182537"); integrante.setDireccion("Avenida Naciones Unidas e Iñaquito. ");

78

integrante.setCelular("0998865692"); integrante.setTelefono("022656872"); integrante.setEmail("[email protected]"); Calendar nac = GregorianCalendar.getInstance(); nac.set(1988, 04, 12); integrante.setFechaNacimiento(nac.getTime()); Persona expected = personaServicio.guardarPersona(integrante); Persona actual = integrante; Assert.assertNotSame(expected, actual); } /** * Caso de prueba que verifica que el ID del nuevo Integrante ingresado * sea igual al máximo ID, de la tabla en la Base de Datos, sumado una

* unidad. * */ @Test public void testCase1() throws Exception { integrante.setEstado(true); integrante.setApellidoPaterno("Castro"); integrante.setApellidoMaterno("Correa"); integrante.setNombres("Felipe Javier"); integrante.setCedula("1717527045"); integrante.setDireccion("Amazona y Colon. "); integrante.setCelular("0984894538"); integrante.setTelefono("022646872"); integrante.setEmail("[email protected]"); Calendar nac = GregorianCalendar.getInstance(); nac.set(1984, 03, 11); integrante.setFechaNacimiento(nac.getTime()); int expected = personaServicio.consultarUltimoIdPerson()+1;

int actual = personaServicio.guardarPersona(integrante).getIdPersona();

Assert.assertEquals(expected, actual); } }

Ejecución de la prueba unitaria.

Figura 2.14 Resultado de la ejecución de la prueba unitaria UsuarioTest

79

2.4.2 DISEÑO DE LAS PRUEBAS DE ACEPTACIÓN

Las pruebas de aceptación son escenarios definidos entre el cliente y el equipo de

desarrollo, se utilizan para controlar que una historia de usuario se implemente de

acuerdo a los requerimientos planteados por el cliente.

El objetivo es evitar que el equipo de desarrollo realice un esfuerzo innecesario

desarrollando requerimientos que el cliente no necesita.

Para diseñar las pruebas de aceptación del presente proyecto, el equipo de

desarrollo se reúne con el cliente antes de codificar cada historia de usuario.

En la Tabla 53 se muestra el formato para diseñar una prueba de aceptación para

una historia de usuario, basado en el diseño propuesto por Kent Beck en la

metodología XP.

Número de prueba:

Historia de usuario:

Precondiciones:

Entrada:

Resultado esperado 1:


Tabla 53 Formato de Pruebas de Aceptación12

12 KENT BECK Martin. Planning Extreme Programming. Addison Weley. 2000.

80

Dónde:

Número de prueba.- Es el identificador unívoco de la prueba de aceptación.

Versión.- Es el número de ejecuciones de la prueba de aceptación que se realizan

hasta que el usuario aprueba la historia de usuario.

Historia de usuario.- Nombre de la historia de usuario para la que se define la

prueba.

Precondiciones.- Son las condiciones para poder realizar la funcionalidad que se va

analizar.

Entradas.- Son los pasos que sigue el usuario para realizar la funcionalidad del

sistema que se va analizar.

Resultado esperado.- Respuesta obtenida del sistema posterior a la ejecución de la

funcionalidad.

Evaluación de la prueba.- Nivel de satisfacción del usuario con respecto al

resultado obtenido por el sistema.

81

2.4.3 PRUEBAS DE ACEPTACIÓN

A continuación se muestran las versiones finales de las pruebas de aceptación

diseñadas para la implementación del sistema.

Número de prueba: 1

Historia de usuario: Registro de Integrante Institucional

Precondiciones:

El usuario debe tener perfil de administrador.

Entrada:

El administrador ingresa a la página principal del sistema.

El administrador digita su nombre de usuario y contraseña.

El administrador selecciona el menú Administración.

El administrador selecciona el submenú Integrantes Institucionales.

El administrador selecciona la opción Registro de Integrante Institucional (estudiante,

profesor o administrador).

El administrador ingresa todos los campos requeridos en el formulario.

El administrador presiona “Guardar”.


El sistema registra los datos del nuevo integrante institucional.

El sistema muestra un mensaje de registro exitoso.


El sistema muestra un mensaje de error cuando la autentificación de usuario es inválida.

El sistema muestra un mensaje de error cuando los datos, no son válidos o no se ha

ingresado un dato requerido.

El sistema muestra un mensaje de error cuando se ha ingresado un integrante institucional

ya existente.

Tabla 54 Prueba de Aceptación. Registro de Integrante Institucional

82


Historia de usuario: Modificación de Integrante Institucional

Precondiciones:


El integrante institucional debe estar registrado en el sistema.

Entrada:




El administrador selecciona el submenú Integrantes Institucionales.

El administrador selecciona la opción Modificación de Integrantes.

El administrador realiza la búsqueda del integrante.

El administrador selecciona “Modificar”, en el integrante que requiera.

El administrador modifica en el formulario los campos que requiera.



El sistema despliega una lista de integrantes como resultado de la búsqueda requerida por

el administrador.

El sistema despliega los datos del integrante institucional q se va a modificar.

El sistema modifica los datos del integrante institucional.

El sistema muestra un mensaje de modificación exitosa.





El sistema muestra un mensaje de error cuando se ha ingresado un integrante institucional

ya existente.

Tabla 55 Prueba de Aceptación. Modificación de Integrante Institucional

83


Historia de usuario: Registro de Usuario

Precondiciones:


La persona a la que se va a registrar como usuario, debe estar registrada como integrante

institucional.

Entrada:




El administrador selecciona el submenú Usuarios.

El administrador selecciona la opción Registro de Usuario.




El sistema registra los datos del nuevo usuario.






El sistema muestra un mensaje de error cuando se ha ingresado un usuario ya existente.

Tabla 56 Prueba de Aceptación. Registro de Usuario


Historia de usuario: Modificación de Usuario

Precondiciones:


El usuario debe estar registrado en el sistema.

Entrada:



84


El administrador selecciona el submenú Usuarios.

El administrador selecciona la opción Modificación de Usuarios.

El administrador realiza la búsqueda del usuario.

El administrador selecciona “Modificar”, en el usuario que requiera.

El administrador solo puede modificar en el formulario el nombre de usuario.



El sistema despliega una lista de integrantes como resultado de la búsqueda requerida por

el administrador.

El sistema modifica los datos del integrante institucional.




El sistema muestra un mensaje de error cuando los datos no son válidos o no se ha


El sistema muestra un mensaje de error cuando se ha ingresado un usuario ya existente.

Tabla 57 Prueba de Aceptación. Modificación de Usuario


Historia de usuario: Acceso al Sistema

Precondiciones:

La persona que va a acceder al Sistema debe estar registrada como usuario del Sistema.

Entrada:

El usuario ingresa a la página principal del sistema.

El usuario digita su nombre de usuario y contraseña.

El usuario presiona “Ingresar”

85


El sistema verifica el nombre de usuario y contraseña ingresada.

El sistema muestra una página de bienvenida.


El sistema muestra un mensaje de error cuando los datos ingresados no corresponden a los

datos almacenados o cuando el usuario no existe.

Tabla 58 Prueba de Aceptación. Acceso al Sistema


Historia de usuario: Registro de Niveles Educativos

Precondiciones:


Entrada:




El administrador selecciona el submenú Parámetros Académicos.

El administrador selecciona la opción Niveles Educativos.

El administrador selecciona todos los campos requeridos en el formulario.



El sistema despliega la lista de los niveles educativos registrados.

El sistema registra los datos del nuevo nivel educativo.


El sistema agrega el nuevo nivel educativo a la lista.



El sistema muestra un mensaje de error cuando no se ha ingresado un dato requerido.

El sistema muestra un mensaje de error cuando se ha ingresado un nivel educativo ya

existente.

Tabla 59 Prueba de Aceptación. Registro de Niveles Educativos

86


Historia de usuario: Modificación de Niveles Educativos

Precondiciones:


El Nivel Educativo debe estar registrado en el sistema.

Entrada:



El administrador ingresa al menú Administración.

El administrador ingresa al submenú Parámetros Académicos.


El administrador selecciona “Modificar”, en el nivel educativo que requiera.

El administrador modifica los campos que requiera.




El sistema despliega los datos del nivel educativo seleccionado.

El sistema modifica los datos del nivel educativo.





El sistema muestra un mensaje de error cuando se ha ingresado un nivel educativo ya

existente.

Tabla 60 Prueba de Aceptación. Modificación de Niveles Educativos


Historia de usuario: Eliminación de Nivel Educativo

Precondiciones:


El nivel educativo debe estar registrado en el sistema.

87

Entrada:






El administrador selecciona “Eliminar” en el nivel educativo que requiera.

El administrador confirma la eliminación del nivel educativo.



El sistema muestra un mensaje de confirmación de eliminación.

El sistema elimina los datos del nivel educativo.

El sistema muestra un mensaje de eliminación exitosa.



El sistema muestra un mensaje de error cuando el nivel educativo tiene cursos asociados.

Tabla 61 Prueba de Aceptación. Eliminación de Nivel Educativo


Historia de usuario: Registro de Materias

Precondiciones:


El sistema debe tener registrado al menos un nivel educativo.

Entrada:





El administrador selecciona la opción Materias.



88


El sistema despliega la lista de las materias registradas.

El sistema registra los datos de la nueva Materia.


El sistema agrega la nueva materia a la lista.




El sistema muestra un mensaje de error cuando se ha ingresado una materia ya existente.

Tabla 62 Prueba de Aceptación. Registro de Materias


Historia de usuario: Modificación de Materias

Precondiciones:


La materia debe estar registrada en el sistema.

Entrada:






El administrador selecciona “Modificar” en la materia que requiera.


El administrador presiona “Guardar”

89



El sistema despliega los datos de la materia seleccionada.

El sistema modifica los datos de la materia.





El sistema muestra un mensaje de error cuando se ha ingresado una materia ya existente.

Tabla 63 Prueba de Aceptación. Modificación de Materias


Historia de usuario: Eliminación de Materia

Precondiciones:


La materia debe estar registrada en el sistema.

Entrada:






El administrador selecciona “Eliminar” en la materia que requiera.

El administrador confirma la eliminación de la materia.

90




El sistema elimina los datos de la materia.




El sistema muestra un mensaje de error cuando la materia tiene horarios asociados.

Tabla 64 Prueba de Aceptación. Eliminación de Materia


Historia de usuario: Registro de Aulas

Precondiciones:


Entrada:





El administrador selecciona la opción Aulas.




El sistema despliega la lista de las aulas registradas.

El sistema registra los datos de la nueva Aula.


El sistema agrega la nueva aula a la lista.




El sistema muestra un mensaje de error cuando se ha ingresado un aula ya existente.

Tabla 65 Prueba de Aceptación. Registro de Aulas

91


Historia de usuario: Modificación de Aulas

Precondiciones:


El aula debe estar registrada en el sistema.

Entrada:






El administrador selecciona “Modificar” en el aula que requiera.





El sistema despliega los datos del aula seleccionada.

El sistema modifica los datos del aula.





El sistema muestra un mensaje de error cuando se ha ingresado un aula ya existente.

Tabla 66 Prueba de Aceptación. Modificación de Aulas


Historia de usuario: Eliminación de Aula

Precondiciones:


El aula debe estar registrada en el sistema.

92

Entrada:






El administrador selecciona “Eliminar” en la materia que requiera.

El administrador confirma la eliminación del aula.




El sistema elimina los datos del aula.




El sistema muestra un mensaje de error cuando el aula tiene horarios asociados.

Tabla 67 Prueba de Aceptación. Eliminación de Aula


Historia de usuario: Registro de Especialidades

Precondiciones:


Entrada:





El administrador selecciona la opción Especialidades.



93


El sistema despliega la lista de las especialidades registradas.

El sistema registra los datos de la nueva especialidad.


El sistema agrega la nueva especialidad a la lista.




El sistema muestra un mensaje de error cuando se ha ingresado una especialidad ya

existente.

Tabla 68 Prueba de Aceptación. Registro de Especialidades


Historia de usuario: Modificación de Especialidades

Precondiciones:


La especialidad debe estar registrada en el sistema.

Entrada:






El administrador selecciona “Modificar” en la especialidad que requiera.



94



El sistema despliega los datos de la especialidad seleccionada.

El sistema modifica los datos de la especialidad.





El sistema muestra un mensaje de error cuando se ha ingresado una especialidad ya

existente.

Tabla 69 Prueba de Aceptación. Modificación de Especialidades


Historia de usuario: Eliminación de Especialidad

Precondiciones:


La especialidad debe estar registrada en el sistema.

Entrada:






El administrador selecciona “Eliminar” en la especialidad que requiera.

El administrador confirma la eliminación de la especialidad.

95




El sistema elimina los datos de la especialidad.




El sistema muestra un mensaje de error cuando la especialidad tiene niveles educativos

asociados.

Tabla 70 Prueba de Aceptación. Eliminación de Especialidad


Historia de usuario: Registro de Requisitos de Matrícula

Precondiciones:

El administrador debe tener perfil de administrador.

Entrada:





El administrador selecciona la opción Requisitos de Matrícula.



96


El sistema despliega la lista de los Requisitos de Matrícula registrados.

El sistema registra los datos del nuevo Requisito de Matrícula.


El sistema agrega el nuevo Requisito de Matrícula a la lista.




El sistema muestra un mensaje de error cuando se ha ingresado un requisito de matrícula

ya existente.

Tabla 71 Prueba de Aceptación. Registro de Requisitos de Matrícula


Historia de usuario: Modificación de Requisitos de Matrícula

Precondiciones:


El requisito debe estar registrado en el sistema.

Entrada:






El administrador selecciona “Modificar” en el requisito que requiera.



97


El sistema despliega la lista de los requisitos de matrícula registrados.

El sistema despliega los datos del requisito de matrícula seleccionado.

El sistema modifica los datos del requisito de matrícula.





El sistema muestra un mensaje de error cuando se ha ingresado un requisito de matrícula

ya existente.

Tabla 72 Prueba de Aceptación. Modificación de Requisitos de Matrícula


Historia de usuario: Eliminación de Requisito de Matrícula

Precondiciones:


El requisito debe estar registrado en el sistema.

Entrada:






El administrador selecciona “Eliminar” en el requisito que requiera.

El administrador confirma la eliminación del requisito.

98


El sistema despliega la lista de los requisitos de matrícula registrados.


El sistema elimina los datos del requisito de matrícula.




El sistema muestra un mensaje de error cuando el requisito tiene matriculas asociadas.

Tabla 73 Prueba de Aceptación. Eliminación de Requisito de Matrícula


Historia de usuario: Registro de Materiales Académicos

Precondiciones:


Entrada:





El administrador selecciona la opción Materiales Académicos.



99


El sistema despliega la lista de los Materiales Académicos registrados.

El sistema registra los datos del nuevo Material Académico.


El sistema agrega el nuevo Material Académico a la lista.




El sistema muestra un mensaje de error cuando se ha ingresado un material académico ya

existente.

Tabla 74 Prueba de Aceptación. Registro de Materiales Académicos


Historia de usuario: Modificación de Materiales Académicos

Precondiciones:


El material académico debe estar registrado.

Entrada:






El administrador selecciona “Modificar” en el material académico que requiera.



100


El sistema despliega la lista de los materiales académicos registrados.

El sistema despliega los datos del material académico seleccionado.

El sistema modifica los datos del material académico.





El sistema muestra un mensaje de error cuando se ha ingresado un material académico ya

existente.

Tabla 75 Prueba de Aceptación. Modificación de Materiales Académicos


Historia de usuario: Eliminación de Materiales Académicos

Precondiciones:


El material académico debe estar registrado.

Entrada:






El administrador selecciona “Eliminar” en el material académico que requiera.

El administrador confirma la eliminación del material académico.


El sistema despliega la lista de los materiales académicos registrados.


El sistema elimina los datos del material académico.




Tabla 76 Prueba de Aceptación. Eliminación de Materiales Académicos

101


Historia de usuario: Registro de Datos de la Institución

Precondiciones:


Entrada:




El administrador selecciona el submenú Institución.

El administrador selecciona la opción Datos de la Institución.




El sistema registra los datos de la Institución.




Tabla 77 Prueba de Aceptación. Registro de Datos de la Institución


Historia de usuario: Modificación de Datos de la Institución

Precondiciones:


Los datos de la institución deben estar registrados.

Entrada:




El administrador selecciona el submenú Institución.

El administrador selecciona la opción Datos de la Institución.

102




El sistema modifica los datos de la Institución.




Tabla 78 Prueba de Aceptación. Modificación de Datos de la Institución


Historia de usuario: Registro de Período

Precondiciones:


Entrada:



El administrador selecciona el menú Gestión Académica.

El administrador selecciona el submenú Períodos.

El administrador selecciona la opción Registro de Período.




El sistema registra los datos del nuevo Período.






El sistema muestra un mensaje de error cuando se ha ingresado un período ya existente.

Tabla 79 Prueba de Aceptación. Registro de Período

103


Historia de usuario: Modificación de Período Actual

Precondiciones:


El Período Actual debe estar registrado en el sistema.

Entrada:





El administrador selecciona la opción Modificación de Período Actual.




El sistema modifica los datos del periodo actual.






El sistema muestra un mensaje de error cuando se ha ingresado un período ya existente.

Tabla 80 Prueba de Aceptación. Modificación de Período Actual


Historia de usuario: Eliminación de Período

Precondiciones:


El período debe estar registrado en el sistema.

Entrada:



104



El administrador selecciona la opción Eliminación de Período.

El administrador selecciona “Eliminar”, en el período que requiera.

El administrador confirma la eliminación del período.


El sistema elimina los datos del período.




El sistema muestra un mensaje de error cuando el período está inactivo o cerrado.

Tabla 81 Prueba de Aceptación. Eliminación de Período


Historia de usuario: Registro de Configuración de Calificaciones

Precondiciones:


El sistema debe tener registrado un período actual.

Entrada:





El administrador selecciona la opción Configuración de Calificaciones.



105


El sistema registra la configuración de las calificaciones.

El sistema muestra un mensaje de configuración exitosa.





Tabla 82 Prueba de Aceptación. Registro de Configuración de Calificaciones


Historia de usuario: Modificación de Configuración de Calificaciones

Precondiciones:



Entrada:






El administrador selecciona “Modificar” en la calificación que requiera.




El sistema despliega la lista de configuración de calificaciones registradas.

El sistema despliega los datos de la calificación seleccionada.

El sistema modifica la configuración de la calificación.






Tabla 83 Prueba de Aceptación. Modificación de Configuración Calificaciones

106


Historia de usuario: Eliminación de Configuración de Calificaciones

Precondiciones:



Entrada:






El administrador selecciona “Eliminar” en la configuración de la calificación que requiera.

El administrador confirma la eliminación de la configuración de la calificación.


El sistema despliega la lista de configuración de calificaciones registradas.


El sistema elimina los datos de la configuración de la calificación.




Tabla 84 Prueba de Aceptación. Eliminación de Configuración Calificaciones


Historia de usuario: Registro de Curso

Precondiciones:


El sistema debe tener registrado al menos un nivel.

El sistema debe tener registrado al menos un profesor.

Entrada:




107

El administrador selecciona el submenú Cursos.

El administrador selecciona la opción Registro de Curso.




El sistema despliega la lista de los cursos registrados.

El sistema registra los datos del nuevo curso.


El sistema agrega el nuevo curso a la lista.





El sistema muestra un mensaje de error cuando se ha ingresado un curso ya existente.

Tabla 85 Prueba de Aceptación. Registro de Curso


Historia de usuario: Modificación de Curso

Precondiciones:


El Curso debe estar registrado en el sistema.

Entrada:




El administrador selecciona el submenú Cursos.

El administrador selecciona la opción Modificación de Cursos.



108


El sistema despliega la lista de las cursos registrados.

El sistema despliega los datos del curso seleccionado.

El sistema modifica los datos del curso.






El sistema muestra un mensaje de error cuando se ha ingresado un curso ya existente.

Tabla 86 Prueba de Aceptación. Modificación de Curso


Historia de usuario: Generación de Reportes Académicos

Precondiciones:

El usuario debe tener perfil de estudiante, profesor o administrador.

Entrada:



El usuario selecciona el menú Gestión Académica.

El usuario selecciona el submenú Reportes Académicos.

El usuario selecciona el reporte académico que requiera.

El usuario selecciona la forma de visualizar el reporte académico (PDF o WEB).

El usuario presiona “Generar”.


El sistema despliega los datos del reporte académico requerido.



Tabla 87 Prueba de Aceptación. Generación de Reportes Académicos

109


Historia de usuario: Información del Estudiante

Precondiciones:

El usuario debe tener perfil de estudiante.

El estudiante debe estar registrado.

Entrada:

El estudiante ingresa a la página principal del sistema.

El estudiante digita su nombre de usuario y contraseña.

El estudiante selecciona el menú Gestión Estudiantil.

El estudiante selecciona el submenú Información.

El estudiante selecciona la opción Datos del Estudiante.

El estudiante visualiza su Información Personal.


El sistema despliega los datos personales, académicos y horario de clases del estudiante.



Tabla 88 Prueba de Aceptación. Información del Estudiante


Historia de usuario: Registro de Matrícula

Precondiciones:


El sistema debe tener registrado al estudiante q se le va a matricular.

El sistema debe tener registrado las fechas de matriculación para el período actual.

Entrada:



El administrador selecciona el menú Gestión Estudiantil.

El administrador selecciona el submenú Matrícula.

El administrador selecciona la opción Registro de Matricula.



110


El sistema registra los datos de la matriculación del estudiante.






Tabla 89 Prueba de Aceptación. Registro de Matrícula


Historia de usuario: Anulación de Matrícula

Precondiciones:


El estudiante debe tener registrado la matrícula en el sistema.

Entrada:



El administrador selecciona el menú Gestión Estudiantil.

El administrador selecciona el submenú Matrícula.

El administrador selecciona la opción Anulación Matrícula.

El administrador selecciona Estudiante del cual desea anular la matrícula.

El administrador elimina la matrícula requerida.


El sistema elimina los datos de la matriculación del estudiante.




Tabla 90 Prueba de Aceptación. Eliminación de Matrícula

111


Historia de usuario: Registro de Asistencia

Precondiciones:

El usuario debe tener perfil de profesor.

El sistema debe tener matriculado al menos un estudiante en un curso.

Entrada:

El profesor ingresa a la página principal del sistema.

El profesor digita su nombre de usuario y contraseña.

El profesor selecciona el menú Gestión Estudiantil.

El profesor selecciona el submenú Evaluación.

El profesor selecciona la opción Registro de Asistencia.

El profesor ingresa todos los campos requeridos en el formulario.



El sistema despliega la lista de estudiante matriculados en el curso seleccionado.

El sistema registra los datos de la asistencia del estudiante.






Tabla 91 Prueba de Aceptación. Registro de Asistencia


Historia de usuario: Modificación de Asistencia

Precondiciones:


La asistencia del estudiante debe estar registrada.

Entrada:



112



El profesor selecciona la opción Registro de Asistencia.

El profesor modifica en el formulario los campos que requiera.

El profesor presiona “Guardar”


El sistema modifica los datos de la asistencia del estudiante.






Tabla 92 Prueba de Aceptación. Modificación de Asistencia


Historia de usuario: Registro de Calificaciones

Precondiciones:


El sistema debe tener matriculado al menos un estudiante en un curso.

El sistema debe tener registrado al menos una materia.

El sistema debe tener configurado al menos una calificación.

Entrada:





El profesor selecciona la opción Registro de Calificaciones.

El profesor ingresa todos los campos requeridos en el formulario.


113


El sistema despliega la lista de estudiantes registrados en el curso.

El sistema registra los datos de la calificación del estudiante.






Tabla 93 Prueba de Aceptación. Registro de Calificaciones


Historia de usuario: Modificación de Calificaciones

Precondiciones:


La calificación del estudiante debe estar registrada

Entrada:





El profesor selecciona la opción Registro de Calificaciones.

El profesor modifica en el formulario los campos que requiera.

El profesor presiona “Guardar”


El sistema modifica los datos de la calificación del estudiante.






Tabla 94 Prueba de Aceptación. Modificación de Calificaciones

114


Historia de usuario: Generación de Reportes Estudiantiles

Precondiciones:

El usuario debe tener perfil de estudiante, profesor o administrador.

Entrada:



El usuario selecciona el menú Gestión Estudiantil.

El usuario selecciona el submenú Reportes Estudiantiles.

El usuario selecciona el reporte estudiantil que requiera.

El usuario selecciona la forma de visualizar el reporte estudiantil (PDF o WEB).

El usuario presiona “Generar”.


El sistema despliega los datos del reporte estudiantil requerido.



Tabla 95 Prueba de Aceptación. Generación de Reportes Estudiantiles

115

2.5 PLANIFICACIÓN DE LA IMPLANTACIÓN

Después de finalizar la implementación del sistema en su totalidad, el equipo de

desarrollo y el cliente se reúnen para planificar su implantación.

Para la implantación se planifica las siguientes actividades:

1. Definición de los requisitos de software y hardware para la instalación del

sistema.

2. Configuración de los componentes de software que se requieren para instalar

la aplicación.

3. Publicar la aplicación web.

Definición de Requisitos de instalación

Ø Hardware

o Servidor Web.

§ Procesador de servidor, se recomienda Línea Intel(R) Xeon(R)

§ Memoria RAM mínima de 4 GB

§ Disco Duro mínimo de 100 GB

§ Mínimo un puerto de red Ethernet.

o Computadoras cliente.

§ Capacidad para soportar visualización XHTML.

Ø Software

o Servidor

§ Sistema operativo: Windows Server 2008 o una distribución de

Linux (Centos 6.3)

§ Motor de Base de Datos PostgreSQL 9.0

§ JRE 1.6 o superior

§ Servidor de Aplicaciones JBoss 5.1

116

o Cliente

§ Navegador Web con soporte para javaScript, pueden ser:

· Mozilla Firefox 10.0 o superior

· Google Chrome 10.0 o superior

· Internet Explorer 8 o superior

Configuración del ambiente de instalación.

Ø Motor de Base de Datos.

o Descargar el paquete de instalación de PostgreSQL de la página del

proveedor.

o Instalar PostgreSQL en el Sistema Operativo (Windows o Linux).

o Configurar los parámetros del servidor de Base de Datos.

§ IP del Servidor.

§ Puerto de comunicación.

§ Número máximo de conexiones al servidor.

Ø Servidor de Aplicaciones.

o Descargar el JRE 1.6 de la página del proveedor.

o Instalar el JRE 1.6

o Descargar el paquete de instalación del Servidor JBoss de la página

del proveedor.

o Crear el directorio del Servidor JBoss con el contenido obtenido del

paquete de instalación.

o Configurar los parámetros del Servidor de Aplicaciones.

§ IP del Servidor

§ Puerto de Comunicaciones

§ Las variables de ubicación de la aplicación web.

117

Publicación de la aplicación web del sistema PROVSIS.

Ø Crear las tablas de la Base de Datos del sistema.

Ø Ingresar los valores por defecto en las tablas de la Base de Datos del

sistema.

Ø Configurar en la aplicación web los parámetros de conexión con la Base de

Datos del sistema.

Ø Iniciar el Servidor de Aplicaciones JBoss

Ø Publicar la aplicación web en el servidor JBoss

118

CAPITULO 3. CONCLUSIONES Y RECOMENDACIONES

3.1 CONCLUSIONES

Ø Gracias a la programación en pareja el equipo de desarrollo invirtió menos

tiempo en el aprendizaje de nuevas tecnologías que se utilizaron en el

proyecto, debido a que se compartió conocimientos por medio de la

investigación y la adquisición de experiencia conjunta.

Ø Los cambios que surgieron en los requerimientos durante el desarrollo del

sistema fueron adaptados exitosamente, esto fue posible gracias a que XP

sugiere realizar un desarrollo incremental de pequeñas partes funcionales;

por lo tanto, cuando se implementa una modificación en una parte funcional

no se produce un impacto grande sobre el resto del sistema.

Ø Como indica la metodología XP, el cliente fue parte importante en el

desarrollo este proyecto, durante las reuniones aportó con los requerimientos

del sistema, su conocimiento sobre las reglas del negocio, su decisión en el

diseño de las interfaces de usuario y, el diseño y aceptación de las pruebas

de cada una de las pequeñas partes funcionales entregadas.

Ø El esfuerzo del equipo de desarrollo se enfocó en implementar solamente lo

que el usuario requiere, esto fue posible gracias a que XP sugiere realizar

pruebas continuas, en las cuales el cliente es el que las diseña y ejecuta; por

lo tanto, controla que el equipo de desarrollo realice solamente lo necesario.

119

3.2 RECOMENDACIONES

Ø Se recomienda revisar casos de uso exitosos de la metodología XP, con el

objetivo de recolectar información que sea útil para ordenar las actividades a

realizarse, teniendo en cuenta las características del proyecto y de la

institución.

Ø La metodología XP no cuenta con una documentación formal, por lo que se

recomienda utilizar herramientas y procedimientos de documentación

adicionales en el diseño inicial del sistema, para facilitar el entendimiento y

presentación de los requerimientos del cliente.

Ø La comunicación dentro del equipo de desarrollo es importante, porque evita

conflictos de codificación, por ello se recomienda que exista un rol encargado

de gestionar las relaciones interpersonales dentro del equipo de desarrollo.

Ø Se recomienda el uso de herramientas Open Source, para disminuir costos en

el desarrollo.

120

BIBLIOGRAFÍA

Tesis de referencia.

ü Jarrín María Eugenia, Valarezo Edgar. Desarrollo e implantación del sistema

de gestión académica y administrativa vía web para el colegio Modelo

Politécnico. Proyecto de Titulación.EPN.2011.

ü Barrera Andrea, Sistema Web para la organización local miembro (OLM) de la

Junior Chamber International (JCI) Quito Metropolitano. Proyecto de

Titulación.EPN.2009.

ü Paulina Carrera, Roberto Pullas, Desarrollo e implementación de un portal de

servicios para el Instituto de Fertilidad INFES. Proyecto de

Titulación.EPN.2009.

ü Pullas Elizabeth, Desarrollo de un Sistema para Voto Electrónico y Emisión de

Resultados en Procesos Electorales de la Escuela Politécnica Nacional.

Proyecto de Titulación.EPN.2010.

Libros de referencia

ü PRESSMAN, Roger. Ingeniería del Software. Un enfoque práctico. Sexta

Edición. McGraw-Hill. Madrid. 2002.

ü NIELSEN, Jakob. Usabilidad: diseño de sitios Web. Prentice Hall, 2002.

ü MONTERO Hassan, FERNÁNDEZ Martín, IAZZA Ghzala. Guía de Evaluación

Heurística de sitios web. Segunda edición. SpringerVerlag. Heidelberg.2003.

ü KENT BECK Martin, Planning Extreme Programming. Addison Wesley. 2000. ü ZELDMAN, Jeffrey. Diseño con Estándares Web. Grupo Anaya Comercial.

2005.

ü Oracle and/or its affiliates. The Java EE 5 Tutorial. 2007.

ü Beck, Kent. Smalltalk Best Practice Patterns. Upper Saddle River, N.J.:

Prentice Hall, 1997.

ü Object Oriented Software. Reading, Mass.: Addison-Wesley, 1995.

121

ü ASTELS David, MILLER Granville, NOVAK Miroslav. A Practical Guide to

eXtreme Programming. Prentice Hall, 2002.

Sitios web de referencia

ü Wells Don. Extreme Programming: A gentle introduction.

http://www.extremeprogramming.org/ 15/02/2013

ü JOSKOWICZ, José. Reglas y Prácticas en Extreme

Programming.http://iie.fing.edu.uy/~josej/docs/XP%20-

%20Jose%20Joskowicz.pdf15/02/2013

ü SILVA, Darío. Construyendo aplicaciones web con una metodología de diseño

orientada a objetos

http://lifia.info.unlp.edu.ar/papers/2001/Silva2001.pdf15/02/2013

ü The World Wide Web Consortium (W3C). Arquitectura Web.

http://www.w3.org/15/02/2013

ü W3schools. Web services. http://www.w3schools.com/15/02/2013

ü Extreme Programming.

http://extremeprogramming.host56.com/ARTICULO5.php15/02/2013

ü VILLAFUERTE, Víctor. Ciclo de Vida de Extreme Programming.

http://extremeprogramming.host56.com/ARTICULO5.php15/02/2013

ü PERALTA, Iván. Burndown chart, User Agile Development.

http://useragiledevelopment.blogspot.com/2011/05/burndown-chart.html

15/02/2013

ü LETELIER, Patricio. Metodologías Ágiles en el Desarrollo de

Software.http://issi.dsic.upv.es/archives/f-

1069167248521/actas.pdf15/02/2013

ü JOSKOWICZ, José. Reglas y Prácticas en eXtreme Programming. Febrero

2008. http://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20Joskowicz.pdf15/02/2013

ü SALINAS, Patricio. Modelo de Clases.

http://users.dcc.uchile.cl/~psalinas/uml/modelo.html15/02/2013

122

GLOSARIO

CSS

Hojas de Estilo en Cascada (Cascading Style Sheets), es la tecnología desarrollada

por el World Wide Web Consortium (W3C) con el fin de separar la estructura de la

presentación.

Entity Beans

Los Beans de Entidad representan un objeto concreto que tiene existencia en alguna

base de datos de la organización.

EJB

EJB (enterprise java beans), define un modelo para el desarrollo y distribución de

componentes reutilizables de lado del servidor Java.

HTML

Lenguaje de marcación de Hipertexto (HyperText Markup Language), es el

lenguaje de marcas de texto utilizado normalmente en la World Wide Web.

Java EE

Java Enterprise Edition es una plataforma para el desarrollo de aplicaciones

empresariales (portables, robustas, escalables y seguras) usando tecnología Java.

Java Script

Es un lenguaje de programación que se ejecuta en el navegador web, del lado del

cliente.

JBOSS

JBoss es un servidor de aplicaciones de código abierto basado en JEE, se puede

utilizar en cualquier sistema operativo que soporte Java.

123

JDK

Java Development Kit, es un software que provee herramientas de desarrollo para la

creación de programas en java.

JRE

Entorno de Tiempo de Ejecución (Java Runtime Environment), es un conjunto de

utilidades (Máquina virtual de Java, las clases centrales y bibliotecas de apoyo de la

plataforma Java), que permite la ejecución de programas java sobre todas las

plataformas soportadas.

JSF

JSF es un marco de trabajo para crear aplicaciones Java EE (Java Enterprise

Edition) basadas en el patrón Modelo Vista Controlador (MVC).

JVM

Java Virtual Machine, es un programa nativo, capaz de interpretar y ejecutar

instrucciones expresadas en un código binario especial (Java bytecode), el cual es

generado por el compilador de Java.

PostgreSQL

PostgreSQL es un sistema de gestión de bases de datos objeto-relacional,

distribuido bajo licencia BSD y con su código fuente disponible libremente.

Reporte BurnDown

Permite observar el esfuerzo real del equipo de desarrollo en comparación con el

esfuerzo que al principio se estimó, permitiendo medir el progreso de las iteraciones.

Session Beans

Los Beans de Sesión representan un proceso o una acción de negocio.

124

Tarjetas CRC

Tarjetas CRC (Clase, Responsabilidad, Colaborador), es una técnica de diseño

orientado a objetos, que contiene el nombre de la clase, las responsabilidades y las

clases que colaboran con cada responsabilidad.

UML

Lenguaje Unificado de Modelado (Unified Modeling Language) es un lenguaje

gráfico para visualizar, especificar y documentar cada una de las partes que

comprende el desarrollo de software.

XML

(eXtensible Markup Language), se trata de un metalenguaje extensible de etiquetas

que fue desarrollado por el world wide web consortium (w3c), diseñado

especialmente para los documentos de la web.

XP

Programación extrema (eXtreme Programming), es una metodología ágil que pone

más énfasis en la adaptabilidad que en la previsibilidad.

125

ANEXOS

ANEXO A: Tarjetas CRC (Anexo Digital)

CD-ROOM: \ANEXOS\Anexo A – Tarjetas CRC\A- Tarjetas CRC.

ANEXO B: Planificación de Iteraciones (Anexo Digital)

CD-ROOM: \ANEXOS\Anexo B – Planificación de Iteraciones\B- Planificación de

Iteraciones.

FACULTAD DE INGENIERIA EN SISTEMAS...A mi esposo Alexis por haber aceptado ser mi compañero de...

Documents

Transcript of FACULTAD DE INGENIERIA EN SISTEMAS...A mi esposo Alexis por haber aceptado ser mi compañero de...