ESCUELA POLITÉCNICA DEL EJÉRCITO

DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN

CARRERA DE INGENIERÍA EN SISTEMAS E

INFORMÁTICA

“APLICACIÓN DE SEAM FRAMEWORK PARA LA INTEGRACION DE EJB3+ RICH FACES MEDIANTE LA UTILIZACIÓN DE LA PLATAFORMA JAVA ENTERPRISE EDITION JEE WEB.”

CASO PRÁCTICO: SISTEMA ESCOLASTICO PARA SION

INTERNATIONAL CRISTHIAN SCHOOL. ”

Previa a la obtención del Título de:

INGENIERO EN SISTEMAS E INFORMÁTICA

POR: CHUCHO

KALO

Sangolquí, enero de 2011

1

Capítulo 1............................................................................................................................. 1-4

1 GENERALIDADES........................................................................................................ 1-4

1.1 INTRODUCCION.......................................................................................................... 1-4

1.2 PLANTEAMIENTO DEL PROBLEMA......................................................................1-5

1.3 OBJETIVOS.................................................................................................................... 1-7

1.4 General.......................................................................................................................... 1-7

1.5 Específicos.................................................................................................................... 1-7

1.6 JUSTIFICACION............................................................................................................ 1-7

1.7 ALCANCE....................................................................................................................... 1-8

Capítulo 2.......................................................................................................................... 2-11

2 MARCO TEORICO...................................................................................................... 2-11

2.1 TECNOLOGIA............................................................................................................. 2-11

2.2 METODOLOGIA......................................................................................................... 2-11

2.2.1 SCRUM+XP.............................................................................................................. 2-11

2.2.2 Caracteristicas...................................................................................................... 2-12

2.2.3 ROLES....................................................................................................................... 2-13

2.2.4 PROCESO................................................................................................................. 2-14

2.2.5 Backlog.................................................................................................................... 2-15

2.2.6 Fase Sprint.............................................................................................................. 2-15

2

2.2.7 Scrum Diario.......................................................................................................... 2-15

2.2.8 Demostración........................................................................................................ 2-16

2.2.9 Retrospectiva........................................................................................................ 2-16

2.2.10 PRODUCTOS........................................................................................................ 2-17

3

Capítulo 1

1 GENERALIDADES

1.1 INTRODUCCION

La educación en general siempre ha estado ligada al desarrollo de la

sociedad y los individuos. Siendo la educación la etapa de formación de los

individuos en la que se desarrollan las habilidades del pensamiento y las

competencias básicas para favorecer el aprendizaje sistemático y continuo, así

como las disposiciones y actitudes que regirán su vida.

En una educación básica de buena calidad el desarrollo de las

competencias básicas y el logro de los aprendizajes de los alumnos son los

propósitos centrales, son las metas a las cuales los profesores, la escuela y el

sistema dirigen sus esfuerzos.

Para lograr esta educación de calidad nace dentro de las instituciones

educativas la necesidad de apoyarse en los sistemas informáticos para

automatizar sus procesos y atender eficientemente la necesidad institucional de

información oportuna consistente y rápida en todos sus procesos.

Por dicho motivo se ha planteado el desarrollo de un SISTEMA

ESCOLASTICO PARA “SION INTERNATIONAL CHRISTIAN SCHOOL”. que

brinde las facilidades necesarias para atender los principales procesos de la

institución.

4

“ Sión International Christian School” y sus autoridades emprendieron este

proyecto que nació debido a la necesidad de establecer un modelo de escuela

con características que afiancen la educación para futuras generaciones.

Por tal motivo la Escuela siempre ha estado en constante innovación en su

modelo de educación.

1.2 PLANTEAMIENTO DEL PROBLEMA

Actualmente Sión International Christian School” dispone de un sistema

hecho en visual Basic 6.0 y una base de datos en Access los cuales no cubren

las necesidades básicas de un sistema.

La escuela “Sión International Christian School” actualmente no dispone de

la automatización de sus procesos académicos y administrativos siendo los

principales afectados la escuela como institución, los profesores, padres de

familia y alumnos.

En la época escolar la escuela afronta dificultades en su sistema por

problemas de manejo de información, como por ejemplo el generar un reporte

de matriculación de alumnos, información acerca de profesores o alumnos, en

fin el sistema antiguo no puede brindar ciertas características como el trabajo

en red para contar con una aplicación distribuida; el sistema actual no cubre las

necesidades de información para una escuela.

El problema se manifiesta en los siguientes procesos:

Proceso de Matriculación: actualmente la escuela tiene una base de datos

obsoleta (sin claves primarias ni relaciones) sin un front end completo ni

5

amigable para manejar las matriculas de los estudiantes cada año lectivo.

Como consecuencia de esta carencia la escuela no puede generar las fichas

informativas de cada alumno que tiene que ser entregadas al Ministerio de

Educación y Cultura. Además al generar algún informe de alumnos

matriculados para un determinado ciclo, el reporte da respuesta incoherente

como niños matriculados en años anteriores.

Proceso de Facturación de matriculas: no tiene.

Procesos de Control de asistencia de personal administrativo y

docente: no tiene.

Proceso de manejo de nomina: no tiene.

Proceso Académico: La escuela actualmente no cuenta con ningún

tipo de sistema para la administración de notas, asistencia y

observaciones de los alumnos. Además de no contar con la

información necesaria acerca del profesor asignado a cada curso y

cada materia. Otro problema en este proceso es la generación

manual de la libreta de calificaciones (record académico)

desperdiciando así tiempo y recursos en esta tarea.

En conclusión, la escuela carece de un sistema académico-administrativo

apropiado para las necesidades acordes con la tecnología actual para

satisfacer a requerimientos de administración en una Escuela y sus

correspondientes actividades a fin de brindar una correcta y rápida atención por

eso se necesita dar solución mediante un sistema informático a medida que

abastezca las mencionadas necesidades.

6

1.3 OBJETIVOS

1.4 General

Utilizar Seam Framework integrando EJB3+Rich Faces para el caso

práctico: Desarrollo del Sistema Escolástico para “Sión International

Christian School”.

1.5 Específicos.

Realizar el estudio y análisis de Seam Framework conjuntamente con

Rich faces, la arquitectura JEE y EJB 3.0. para determinar su

aplicabilidad en sistemas web .

Utilizar Scrum+Xp+Uml como metodología para el desarrollo del

aplicativo web.

Realizar la Especificación de requerimientos funcionales del sistema

definidos por “Sión International Christian School” de acuerdo al

Standard IEEE 830-1998.

Diseñar y ejecutar un plan de pruebas para ambiente web acorde al

proyecto realizado.

Capacitar al personal sobre el uso del aplicativo web y brindar

documentación de apoyo a través de los manuales técnicos y de

usuario.

1.6 JUSTIFICACION

La producción de software en nuestro país es una ciencia joven, la cual se

ha impulsado rápidamente gracias al desarrollo de las ciencias informáticas en

7

las universidades y a organizaciones, surgidas con el objetivo de impulsar,

facilitar y ordenar el uso masivo de servicios y productos de las Tecnologías de

la Información, las Comunicaciones y la Automatización de procesos para

satisfacer las expectativas de todas las esferas de la sociedad.

La creciente demanda solicita aplicar procesos que ayuden a gestionar de

mejor manera el tiempo y los recursos, y la solución es un sistema software en

plataforma Web.

En la actualidad existen sistemas orientados a la administración de una

escuela, pero no ofrecen la solución completa a sus necesidades tanto

académicas como institucionales.

La incorporación de nuevas tecnologías en el tratamiento de la información

beneficiara a la “Sión International Christian School” dotando de procesos más

transparentes en su administración.

1.7 ALCANCE

El alcance del proyecto viene dado por la creación de un Sistema

Informático para la escuela “Sión International Christian School” que

automatizara y atenderá los siguientes procesos básicos de la institución:

1. Proceso Académico

Dentro de este proceso el sistema nos permitirá realizar las inscripciones

de alumnos que desean ingresar a un nuevo año lectivo. Posteriormente

nos permitirá gestionar la matriculación de dichos alumnos. Para el

efecto también será una base de apoyo para la administración de

niveles, paralelos y materias tanto como la gestión de Profesores y

tutores. Luego en el transcurso de todo el ciclo educativo el nuevo

8

sistema será un apoyo para la administración de asistencia tanto de

alumnos como profesores. Finalmente dentro de este proceso el sistema

atenderá todas las necesidades de administración de notas para cada

alumno.

Inscripción de Alumnos

Matriculación de Alumnos

Administración de niveles y paralelos

Administración de Profesores y tutores.

Gestión de Asistencia de alumnos

Ingreso y gestión de Notas.

2. Proceso Administrativo - Recursos Humanos

El sistema para el proceso de administración de recursos humanos nos

permitirá el manejo de Empleados de la institución que incluye

Autoridades, Profesores, personal administrativo, personal de apoyo.

Luego gestionara y reportara la asistencia, permisos y novedades de

todos los empleados. Paralelamente a esto el sistema gestionara

mensualmente la nomina y rol de pagos.

Administración de Personal y empleados

Administración de Asistencia

Administración de Nomina.

3. Proceso Administrativo – Financiero

La institución tiene dentro de sus principales procesos el cobro de

pensiones y venta de materiales del almacén. Procesos que serán

automatizados por el sistema permitiendo la facturación de

9

materiales del almacén, así como la facturación por rubros referentes

a cuotas y pensiones mensuales.

Proceso de Facturación

Administración de Clientes

Manejo de pensiones y cuotas.

4. Proceso Administrativo - Seguridad

Como apoyo para los procesos mencionados anteriormente el sistema

incluirá el modulo de seguridad permitiéndonos el manejo de usuario,

perfiles y roles para garantizar el acceso, seguridad y veracidad de toda

la información del sistema.

Administración de usuario

Administración de perfiles

Administración de roles

5. Modulo Reportes

Para todos los procesos el sistema permitirá generar los principales reportes necesitados por el usuario.

El proyecto será instalado y funcionará en la intranet de la institución.

El proyecto no incluye configurar la intranet de la institución, el modulo

de contabilidad y migración de datos excepto los acordados para pruebas.

10

Capítulo 2

2 MARCO TEORICO

2.1 TECNOLOGIA

2.2 METODOLOGIA

La metodología usada será Scrum combinada con Extreme Programming,

Scrum toma su nombre y principios de los estudios sobre practicas de

produccion por Hirotaka Taekuchi e Ikujijo Nonaka en la decada de los 80.

A pesar que las Practicas Scrum son utilizadas para el desarrollo de

productos tecnologicos, resulta valido en entornos que trabajan con requisitos

inestables, y necesitan rapidez y flexibilidad, caracteristicas comunes en el

desarrollo del software.

En 1996, Jeff Sutherland y Ken Shwaber lo presentaron como proceso

formal para gestion del desarrollo de software en OOPSLA 96 y a partir del

2001 formaron parte de la lista de modelos agiles de Agile Alliance.

Scrum es una metodologia que requiere trabajo duro, la gestion del

desarrollo no se basa en el seguimiento de un plan mas bien en la adaptacion

continua a las circunstancias del avance de proyecto.

El Control de la Evolucion del Proyecto se lo realiza mediante practicas de

gestion Agiles como:

Revision de Iteraciones

Desarrollo Incremental

Desarrollo evolutivo

11

Auto-organización.

Colaboracion.

2.2.1 SCRUM+XP

Es una metodología ágil que gestiona proyectos de software, se

definiría como la metodología de gestión de trabajo, cuyo objetivo es

elevar al máximo la productividad de un equipo mediante la auto-

organización. Scrum se basa en lo que llaman un Sprint que es un

esfuerzo concentrado para en un periodo de tiempo lograr metas

fijadas.1

Las practicas Scrum fueron diseñadas por Schwaber y Sutherland

para gestionar el desarrollo de software ,las cuales están incluidas en

la lista de modelos ágiles de Agile Alliance.

2.2.2 Caracteristicas

Las fases de la metodología tradicional ahora pasan a ser tareas,

lo serían las fases de requisitos del sistema, requisitos del software,

análisis, diseño, construcción, pruebas, y se ejecutarían de forma

secuencial. Normalmente a lo largo de pequeñas iteraciones durante

todo el desarrollo denominados Sprint.

1 http://www.scrumalliance.org/pages/what_is_scrum

12

Se empieza a trabajar sin el detalle cerrado de lo que se va a

producir. Se parte de la visión general. El descubrimiento paulatino

durante el desarrollo, y las circunstancias que se irán produciendo en el

entorno, dibujarán el detalle de forma paralela al desarrollo .

Con Scrum conseguiremos la planificación y seguimiento del

proyecto, mientras que con Xp gestionaremos la parte de Desarrollo del

software.

Además, utilizaremos modelos de UWE2 ,ya que presenta unos

modelos de diseño que se ajustan al diseño de sitios web.

Los diagramas de secuencia y componentes de UML en la parte

del diseño serán parte de nuestro marco de trabajo.

Los modelos serán: Modelo de Navegación y Modelo de

Presentación, ya que son muy útiles a la hora de poder visualizar como

se navegará por un sitio web y como será mostrada la información al

usuario respectivamente.

Para de esta forma facilitarnos encontrar errores de diseño, pues

de un simple vistazo podemos observar si una página es difícilmente

alcanzable mediante la navegación o si hay información que no se

representa en el sitio web

El modelo de Navegación se especifica la relación interna del sitio

web, en definitiva es como se navega por el sitio web.

El modelo de Presentación provee una visión abstracta de la

interfaz del usuario.

2 UWE acrónimo de UML-based Web Engineering,es un enfoque de ingeniería de software para el dominio web.

13

Planificación: ocurre durante la planificación del sprint: el product owner propone funcionalidades a desarrollar, y el equipo de desarrollo las estima en horas de trabajo.

Entregas pequeñas y frecuentes: duran 1 a 4 semanas.

Historias de usuario: funcionalidades que apuntamos en el product backlog.

Diseño simple: Programar el mínimo código posible que implementa una funcionalidad, sin adornos.

Pruebas unitarias: Pruebas antes que el propio código, al menos cuando es posible.

Refactorizaciones: Código en continua evolución.

Integración continua: hacemos versiones frecuentes y automáticas.

Estándares de programación: la guía de estilo de Oracle-Sun.

2.2.3 ROLES

El Scrum Team denominado como equipo de trabajo, son los

desarrolladores del proyecto de software, ellos deciden como será

realizado el trabajo y como distribuir las asignaciones o requerimientos

y cuanto van ha tardar en ello.

El Product Owner representa la voz del cliente, trabaja con el

Scrum Team desde una perspectiva del negocio, administra un Product

Back log que es una lista de tareas con especificaciones de un

producto, prioriza las funcionalidades posibles.

El Scrum Máster

Mantiene procesos y trabaja como el director del proyecto en las

reuniones diarias que mantiene, su función es eliminar los

14

impedimentos posibles para el cumplimiento de objetivos de cada

Sprint.

2.2.4 PROCESO

2.2.5 Planificacion

En Scrum un proyecto se ejecuta en bloques temporales cortos y

fijos (iteraciones de un mes natural y hasta de dos semanas, si así se

necesita). Cada iteración tiene que proporcionar un resultado completo,

un incremento de producto final que sea susceptible de ser entregado

con el mínimo esfuerzo al cliente cuando lo solicite.

Análisis

Diseño

Construcción

15

Product Owner recoge todas las peticiones y especificaciones

que son la base de los cambios del producto, pueden ser correcciones

de errores y nuevas funcionalidades

Al mismo tiempo se hace una lista de prioridades, el Product

owner toma las decisiones personalmente acerca de prioridades en los

cambios y entregas.

2.2.6 Fase Sprint

El tiempo de cada Sprint es de 2 a 4 semanas, en esta fase se

crea primeramente un Spring Backlog, y cuando las tareas y el tiempo

requerido es definido el product owner pone en marcha la fase.

En esta fase el Scrum Team trabaja por su propia

responsabilidad, al combinarlo con Extreme programming se adaptara

su practicas de ingeniería para el análisis, diseño, desarrollo y la

entrega del producto ayudándonos con diagramas de UML.

Scrum Diario

Todos los días el Scrum Team y el Scrum Máster deben tener una

breve reunión tratando tres preguntas esenciales

Que has hecho desde la ultima reunión?

Que harás hoy hasta la próxima reunión?

Hay algo que impida lo que haces según lo tenías planeado?

Las dos primeras preguntas dan una visión a los participantes de

cómo están avanzando en el proyecto.

16

La tercera pregunta sirve de base pilas para solucionar el

problema.

Todos los interesados en el proyecto pueden estar en la reunión

pero solo el Scrum Team y el Scrum Máster pueden hablar.

2.2.7 Cierre de Proyecto / Demostración

Cada Sprint termina con una demostración en un grafico burn-

down que marca el día a día y el trabajo programado en horas y

objetivos cumplidos.

Retrospectiva

Se analiza cómo ha sido su manera de trabajar y cuáles son los

problemas que podrían impedirle progresar adecuadamente,

mejorando de manera continua su productividad.

2.2.8 Productos/Artefactos

17

Grafico de Scrum3

Product Backlog:

Listado con los requerimientos del sistema. Contiene: features,

requerimientos de desarrollo (no funcionales), tareas investigativas,

bugs.

Es responsabilidad del Product Owner:

Es una combinación de funcionalidades y tareas

Es un documento dinámico que incorpora constantemente las

necesidades del sistema. Se mantiene durante todo el ciclo de vida

incluso hasta el retiro del aplicativo.

Sprint Backlog

3 http://es.wikipedia.org/wiki/Archivo:Ficha_scrum.png

18

Son tareas determinadas por el equipo para realizar en un sprint y

lograr al final del mismo un incremento de funcionalidad del aplicativo.

Las tareas de mayor duración deben intentar descomponerse en

sub-tareas de ese rango de tiempo

En Scrum se debe ir registrando los tiempos día a día para poder

armar el gráfico de avance del proyecto

El equipo agrega tareas cuando lo crea necesario, pudiendo

eliminar las que considere innecesarias, y ajusta estimaciones a

medida se avanza.

Burndown Chart

El Burndown Chart es una gráfica pública que mide la cantidad de

requisitos en el Backlog del proyecto pendientes al comienzo de cada

Sprint.

Dibujando una línea que conecte los puntos de todos los Sprints

completados, podremos ver el progreso del proyecto.

Lo normal es que esta línea sea descendente (en casos en que

todo va bien en el sentido de que los requisitos están bien definidos

desde el principio y no varían nunca) hasta llegar al eje horizontal,

momento en el cual el proyecto se ha terminado (no hay más requisitos

pendientes de ser completados en el Backlog).

19

20