PONTIFICIA UNIVERSIDAD CATLICA DEL PER

FACULTAD DE CIENCIAS E INGENIERA

ANLISIS, DISEO E IMPLEMENTACIN DE UN SISTEMA DE INFORMACIN APLICADO A LA GESTIN EDUCATIVA EN CENTROS DE EDUCACIN ESPECIAL

Tesis para optar por el Ttulo de Ingeniero Informtico que presenta el bachiller:

Ral Miguel Romero Galindo

ASESOR: Ing. Jose Antonio Pow Sang Portillo

Lima, Setiembre de 2012

RESUMEN
Este proyecto consiste en el anlisis, diseo e implementacin de un sistema de informacin de apoyo a la gestin educativa en centros de educacin especial. El propsito de esta plataforma es posibilitar la administracin y atencin de los planes curriculares funcionales (en adelante programas educativos) y teraputicos para personas con necesidades especiales, as como consolidar el conocimiento de trastornos y promover la participacin y evaluacin continua entre padres y especialistas.

La administracin del proyecto adopt las prcticas establecidas por el Project Management Institute. No obstante fueron recogidos un nmero especfico de procesos de gestin segn el alcance de la solucin. Como metodologa de desarrollo de software fue seleccionada la metodologa Agile Unified Process (AUP) por su mayor afinidad y claridad de actividades en las etapas de diseo y construccin de este producto.

Durante la concepcin de la arquitectura se evaluaron mltiples patrones de arquitectura Web como MVC, MVP y Ncapas resultando finalmente una estructura de cuatro capas con funciones especficas e independientes entre s: manteniendo las capas de Presentacin y Acceso a Datos separadas. As como la capa de Lgica de negocio fue subdividida para la seguridad y navegabilidad entre las pginas (capa de Aplicacin) como para conservacin de las reglas de negocio (capa Lgica).

La implementacin fue llevada a cabo mediante el IDE Microsoft Visual Web Developer 2010 Express y el lenguaje de programacin C# soportado bajo .NET Framework 4.0. Para la construccin de las pginas (capa de Presentacin) se trabaj con ASP.NET Webforms y controles dinmicos de la librera Ajax Control Toolkit. La capa de Acceso a Datos fue construida bajo la tecnologa Microsoft ADO.NET Entity Framework y en conexin con una base de datos PostgreSQL.

Para la etapa de pruebas el servidor Web seleccionado fue Internet Information Services (IIS) Express 7.5 una rplica del servidor IIS 7.5 estndar diseada para ambientes de desarrollo y sin restricciones de uso.

II

TEMA DE TESIS PARA OPTAR EL TTULO DE INGENIERO INFORMTICO

TTULO:

ANLISIS, DISEO E IMPLEMENTACIN DE UN SISTEMA DE INFORMACIN APLICADO A LA GESTIN EDUCATIVA EN CENTROS DE EDUCACIN ESPECIAL

REA:

Sistemas de Informacin

PROPONENTE: Ing. Jose Antonio Pow - Sang Portillo ASESOR: ALUMNO: CDIGO: TEMA N: FECHA: Ing. Jose Antonio Pow - Sang Portillo Ral Miguel Romero Galindo 20030448 _______________ San Miguel, 24 de marzo de 2008

DESCRIPCIN En la actualidad las herramientas en tecnologas de informacin constituyen un factor de cambio determinante para el mejoramiento y desarrollo de las actividades del sector educacin. En ese sentido, con el propsito de fortalecer la descentralizacin de la enseanza y el intercambio de conocimiento hacia una mayor participacin e interaccin entre los actores alumno, padres y docentes, las instituciones educativas regulares (desde los centros de educacin inicial, primaria y secundaria) han incorporado herramientas gua como apoyo a los alumnos en las tareas establecidas por los profesores durante el proceso de aprendizaje en lnea desde los hogares, junto con la orientacin a padres y/o tutores del alumno; es as como se refuerzan aspectos como la integracin y participacin de la familia en la educacin del estudiante.

Bajo la ptica anterior, este paradigma contemporneo dentro de los sistemas de informacin encuentra un campo de accin en el marco de los procesos, actividades y tareas localizadas en centros de educacin especial, caracterizada por cuanto involucra a personas con necesidades y habilidades especiales, producto de una discapacidad fsica, psquica o sensorial. La complejidad del sistema educativo en mencin parte del hecho en el cual la enseanza es impartida por un staff multidisciplinario como mdicos, psiclogos, fisioterapeutas,

especialistas, asistentes sociales, especialistas en educacin especial, entre otros; quienes establecen un plan de trabajo (segn la especialidad y caractersticas del alumno) tanto para el alumno como para los familiares.

III

Para afrontar esta problemtica los centros de educacin especial requieren de una herramienta en gestin de la educacin descentralizada, con capacidad de proveer a los usuarios y especialistas informacin clasificada por reas de acuerdo al perfil profesional de los especialistas. A su vez efectuar una evaluacin y anlisis de avances y problemas encontrados durante el proceso de enseanza y la capacidad de generar automticamente un plan de accin/entrenamiento como sustento metodolgico de la labor educativa. Por tanto se plantea la implementacin de un sistema Web para la gestin pedaggica en centros de educacin especial dirigido a especialistas, padres y/o tutores de familia.

OBJETIVO GENERAL El objetivo del proyecto es analizar, disear e implementar un sistema de informacin Web orientado a la gestin educativa de un centro de educacin especial, que brinde soporte a las labores y actividades pedaggicas efectuadas por los especialistas de esta institucin. OBJETIVOS ESPECFICOS Los objetivos especficos del proyecto son: Elaborar el anlisis y diseo del sistema de informacin a implementar, basndose en los requerimientos de la organizacin educativa. Seleccionar y definir la arquitectura bajo la cual se implementar el sistema Web que le permita a esta ser porttil y escalable en el tiempo. Elaborar un modelo de base de datos relacional que se acomode a los requerimientos de almacenamiento y manipulacin de datos de la institucin educativa en cuestin. Disear una Interfaz grfica amigable e intuitiva, que le permita al usuario interactuar con el sistema con facilidad minimizando el uso de manuales o capacitaciones. Definir el esquema de seguridad bajo el cual se har uso del sistema de informacin a implementar, as como tambin garantizar un canal de flujo de informacin a travs de Internet que sea seguro.

ALCANCE El sistema permitir realizar la autenticacin y autorizacin de los usuarios a las diversas funcionalidades proporcionadas por el sistema.

IV

El sistema permitir generar automticamente el documento con el plan de capacitacin (plan curricular funcional) del joven especial, especificando las terapias, tipos de terapias y especialistas as como el cronograma de capacitacin o plan de actividades especficas por cada alumno especial. Asimismo posibilitar el mantenimiento y actualizacin continua del plan de aprendizaje y tareas para el alumno especial

El sistema permitir el registro y mantenimiento de informacin pertinente de los estudiantes con habilidades especiales, as como la actualizacin de la informacin clnica pertinente y que determinan su condicin de salud en la actualidad.

El sistema permitir el acceso y consulta de informacin acadmica del alumno del centro especial, tanto para el (los) especialista(s) como por lo mismo padres del joven, en base al perfil del usuario que para ambas partes se tiene configurada, as como establecer a qu contenidos se encuentran autorizados en su acceso.

El sistema brindar soporte a las funciones realizadas por el profesorado como elaboracin del registro de notas a padres, control de asistencia, planificacin de clases, reportes de aprendizaje del alumno, entre otros.

El sistema permitir el registro de un informe o bitcora semanal al cual podrn acceder y actualizar libremente los especialistas y padres de familia del alumno. A su vez se brindar la posibilidad del registro de solicitudes de entrevista y planificacin de horarios.

A Dios, por la fuerza y la fe para culminar este proyecto importante de mi vida.

A Ral, mi padre, mi nico y mejor amigo: por tu paciencia, apoyo y confianza depositada. Con este proyecto logro demostrarte el cumplimiento y compromiso absoluto con todos mis proyectos.

A Luis y Geraldine, mis hermanos, por su compaa y afecto: ver transcurrir los das y noches a su lado colman mi vida de equilibrio, paz y alegra sin fin.

A todos aquellos quienes encuentran en la ciencia, tecnologa e investigacin los instrumentos para engendrar conocimiento e innovar todos los mbitos del pensamiento humano.

Y a ti madre: aunque infinita sea la distancia entre nuestros mundos guardar en mi corazn, y para la eternidad, todos los momentos vividos contigo desde aquella tarde primaveral de setiembre. Ni el muro entre la vida y la muerte har sucumbir mi inclume esperanza por volver.

VI

Agradecimiento
A travs de estas lneas expreso mi profundo agradecimiento al Ing. Jose Antonio Pow Sang por su contribucin como asesor y mentor durante el desarrollo de esta tesis, fundamental para el xito de este proyecto.

A todos los profesores de la especialidad de Ingeniera Informtica y a mi alma mter PUCP, porque durante los cinco aos y medio de estudios forjaron en m los saberes supremos de carcter cientfico y humanstico, transformndome en un mejor y autntico ser humano para la vida.

VII

NDICE GENERAL
Introduccin .............................................................................................................................. 1 1. CAPTULO 1: Generalidades ........................................................................................ 3 1.1. Definicin de Problema ..................................................................................... 3 1.2. Marco Conceptual ............................................................................................. 6 1.2.1. Educacin Especial ........................................................................... 6 1.2.2. Discapacidad ..................................................................................... 7 1.2.3. Diseo curricular ................................................................................ 7 1.2.4. Necesidades Educativas Especiales ................................................. 8 1.2.5. Adaptacin curricular ......................................................................... 8 1.2.6. DSM-IV .............................................................................................. 8 1.2.7. La Educacin Especial en el Per ..................................................... 8 1.3. Plan del Proyecto .............................................................................................. 9 1.3.1. Metodologa y procedimiento ............................................................ 9 1.3.2. Planificacin..................................................................................... 15 1.3.3. Riesgos del Proyecto ....................................................................... 19 1.3.4. Plan de Respuesta ante riesgos ...................................................... 22 1.4. Estado del Arte................................................................................................ 23 1.4.1. Sistemas de Gestin Educativa ....................................................... 23 1.4.2. Sistemas de Gestin Educativa en Educacin Especial ................. 25 1.4.3. Resumen comparativo de las soluciones ........................................ 30 1.5. Descripcin y sustentacin de la solucin ...................................................... 34 2. CAPTULO 2: Anlisis.................................................................................................. 38 2.1. Definicin de la metodologa de solucin ....................................................... 38 2.1.1. Rational Unified Process (RUP) ...................................................... 38 2.1.2. Agile Unified Process (AUP) ............................................................ 39 2.1.3. Eleccin de la metodologa ............................................................. 40 2.2. Identificacin de requerimientos ..................................................................... 43 2.2.1. Requerimientos funcionales ............................................................ 43 2.2.2. Requerimientos no funcionales ....................................................... 47 2.2.3. Consideraciones sobre el sistema................................................... 48 2.3. Anlisis de la solucin ..................................................................................... 49 2.3.1. Identificacin de las necesidades del cliente .................................. 50 2.3.2. Viabilidad tcnica y econmica ....................................................... 51 2.3.3. Anlisis Costo Beneficio ............................................................... 54 2.3.4. Asignacin de funciones a hardware y software ............................. 55 2.3.5. Restricciones de costo y tiempo ...................................................... 56 2.3.6. Definicin del sistema ...................................................................... 57 3. CAPTULO 3: Diseo ................................................................................................... 62 3.1. Arquitectura de la solucin .............................................................................. 62 3.1.1. Representacin de la arquitectura................................................... 62 3.1.2. Evaluacin ....................................................................................... 63 3.1.3. Diseo de la arquitectura de la solucin ......................................... 66 3.1.4. Vista Lgica ..................................................................................... 69 3.1.5. Vista de Despliegue ......................................................................... 69 3.1.6. Diagrama de clases de diseo ........................................................ 70 3.1.7. Diagrama de base de datos ............................................................ 73 3.1.8. Diagramas de secuencia ................................................................. 75 3.2. Diseo de Interfaz Grfica .............................................................................. 77 3.2.1. Estndar de Interfaz Grfica ............................................................ 77 3.2.2. Consideraciones finales .................................................................. 79 4. CAPTULO 4: Construccin ......................................................................................... 81 4.1. Construccin ................................................................................................... 81 4.1.1. Framework de desarrollo ................................................................. 81 4.1.2. Lenguaje de programacin .............................................................. 83 4.1.3. Framework ORM ............................................................................. 84 4.1.4. IDE ................................................................................................... 85 4.1.5. Base de Datos ................................................................................. 86 4.1.6. Servidor Web ................................................................................... 87

VIII

4.1.7. Otras herramientas y libreras ......................................................... 87 Pruebas ........................................................................................................... 88 4.2.1. Estrategia de Pruebas ..................................................................... 88 4.2.2. Tipos de Pruebas............................................................................. 90 4.2.3. Catlogo de pruebas ....................................................................... 91 4.2.4. Reporte de ejecucin de pruebas.................................................... 93 5. CAPTULO 5: Observaciones, conclusiones y recomendaciones .............................. 95 5.1. Observaciones ................................................................................................ 95 5.2. Conclusiones................................................................................................... 96 5.3. Recomendaciones y trabajos futuros ............................................................. 98 Bibliografa ............................................................................................................................. 99 4.2.

IX

ndice de Ilustraciones
Figura 1.1 Esquema de Diseo Curricular (Molina 1990)........................................................ 7 Figura 1.2 Grupos de Procesos de Proyecto (PMI 2008) ........................................................ 9 Figura 1.3 Grupo del Proceso de Iniciacin ........................................................................... 10 Figura 1.4 Grupo del Proceso de Planificacin...................................................................... 11 Figura 1.5 Grupo del Proceso de Ejecucin .......................................................................... 12 Figura 1.6 Ciclo de vida de desarrollo de software segn AUP (Leffingwell 2011) ............... 13 Figura 1.7 Grupo del Proceso de Seguimiento y Control ...................................................... 14 Figura 1.8 Grupo del Proceso de Cierre ................................................................................ 15 Figura 1.9 Estructura de descomposicin del trabajo del proyecto ....................................... 16 Figura 1.10 Diagrama de Gantt Cronograma de proyecto Fase I ...................................... 17 Figura 1.11 Diagrama de Gantt Cronograma de proyecto Fase II ..................................... 18 Figura 2.1 Actores del sistema .............................................................................................. 49 Figura 2.2 Diagramas de casos de uso del sistema .............................................................. 51 Figura 2.3 Diagrama de paquetes del sistema ...................................................................... 57 Figura 2.4 Diagrama de clases de anlisis Mdulo Seguridad........................................... 58 Figura 2.5 Diagrama de clases de anlisis Mdulo Alumnos ............................................. 58 Figura 2.6 Diagrama de clases de anlisis Mdulo Comunicaciones ................................ 59 Figura 2.7 Diagrama de clases de anlisis Mdulo Organizacin ...................................... 59 Figura 2.8 Diagrama de clases de anlisis Mdulo Planeamiento ..................................... 60 Figura 2.9 Diagrama de clases de anlisis Mdulo Evaluaciones...................................... 60 Figura 3.1 Patrn de arquitectura MVC (Mancini 2003) ........................................................ 65 Figura 3.2 Patrn de arquitectura en N-Capas (Mancini 2003) ............................................. 65 Figura 3.3 Diagrama de componentes de la arquitectura ...................................................... 67 Figura 3.4 Vista lgica del sistema ........................................................................................ 69 Figura 3.5 Diagrama de despliegue ....................................................................................... 70 Figura 3.6 Diagrama de clases de diseo - Mdulo Organizacin ........................................ 71 Figura 3.7 Diagrama de clases de diseo - Mdulo Planeamiento ....................................... 72 Figura 3.8 Diagrama de clases de diseo - Mdulo Evaluaciones ........................................ 73 Figura 3.9 Diagrama de base de datos del sistema .............................................................. 74 Figura 3.10 Diagrama de secuencia del proceso de registro de usuario .............................. 75 Figura 3.11 Diagrama de secuencia del proceso de asignacin de objetivos a actividad .... 76 Figura 3.12 Diagrama de secuencia del proceso de toma de asistencia .............................. 76 Figura 3.13 Patrn de diseo grfico del sistema ................................................................. 77 Figura 3.14 Pantalla de Ingreso al Sistema ........................................................................... 78 Figura 3.15 Pantalla de Bsqueda de Documentos .............................................................. 79 Figura 3.16 Pantalla de Mantenimiento de Programas ......................................................... 79 Figura 4.1 Componentes de .NET Framework 4.0 (Freeman 2011) ..................................... 82

ndice de Tablas
Tabla 1.1 Escalas de Medida de Probabilidad....................................................................... 20 Tabla 1.2 Escala de Medida de Impacto................................................................................ 20 Tabla 1.3 Escala de Severidad .............................................................................................. 20 Tabla 1.4 Riesgos del Proyecto ............................................................................................. 20 Tabla 1.5 Cuadro comparativo de las soluciones presentadas ............................................. 31 Tabla 2.1 Plan de Iteraciones del Proyecto ........................................................................... 42 Tabla 2.2 Requerimientos funcionales del sistema ............................................................... 43 Tabla 2.3 Criterio de Dificultad ............................................................................................... 47 Tabla 2.4 Criterio de Prioridad ............................................................................................... 47 Tabla 2.5 Requerimientos no funcionales del sistema .......................................................... 47 Tabla 2.6 Costo de RR.HH. del proyecto ............................................................................... 53 Tabla 2.7 Costo referencial del proyecto ............................................................................... 53 Tabla 3.1 Requerimientos de diseo vs. Solucin arquitectnica ......................................... 68 Tabla 4.1 Modelo de Caso de Prueba Unitaria ...................................................................... 90 Tabla 4.2 Catlogo de pruebas del sistema .......................................................................... 91

XI

Introduccin
Este proyecto de tesis tiene por finalidad presentar una solucin informtica dirigida a la problemtica presente actualmente en la gestin educativa de centros de educacin especial del pas. Dicha solucin posibilitar la administracin de informacin vinculada a los alumnos, familias y especialistas de la institucin desde las terapias, programas, actividades y tareas asignadas en funcin a los trastornos padecidos.

A largo plazo el objetivo esperado con este proyecto es implantarlo en una red de centros de educacin especial, dispuestos a integrar sus procesos con una herramienta apta para gestionar el conocimiento adquirido de los alumnos, familias, trastornos, terapias, programas educativos y planes de tareas diseados por estas instituciones. A su vez apoyara la descentralizacin de la gestin educativa a organismos y asociaciones no gubernamentales con obstculos en la cobertura de servicios educativos hacia otras localidades (por restricciones geogrficas, econmicas, logsticas o de carencia de profesionales en educacin especial en las regiones). Ambos contextos en la ltima dcada no han sido ajenos a la realidad educativa peruana: si bien aparecen novedosos sistemas de informacin de gestin pedaggica en lnea, su mercado objetivo comprende instituciones de educacin regular (inicial, primaria, secundaria y universitaria) privando en cambio a los centros de educacin especial de los beneficios y oportunidades de automatizacin de sus procesos mediante las tecnologas de informacin, prolongando an ms la espera de una autntica y ambiciosa reforma en el sistema educativo tecnolgico peruano. Este trabajo se divide en cinco captulos descritos a continuacin:

El primer captulo explica los alcances conceptuales y tericos con respecto a la problemtica a tratar. Seguidamente se presentan las soluciones alternativas y los alcances de la nueva solucin junto con el plan de proyecto.

El segundo captulo explica la metodologa de desarrollo de sistemas elegida y presenta el anlisis de la solucin considerando el anlisis de requerimientos y fundamentos de viabilidad.

El tercer captulo presenta el diseo arquitectnico de la solucin, describiendo las funciones de sus principales componentes as como los criterios para la construccin de la interfaz grfica.

El cuarto captulo sustenta las decisiones a nivel tcnico en la eleccin de las tecnologas utilizadas para la implementacin de la solucin as como la estrategia y mtodos de pruebas ejecutados.

Por

ltimo, el quinto captulo rene las observaciones,

conclusiones y

recomendaciones sobre trabajos futuros derivados a partir de este trabajo.

1. CAPTULO 1:

Generalidades

En este captulo se presentan el contexto y marco conceptual de la problemtica a la cual se dar solucin para su entendimiento. De esta manera, el lector comprender el escenario real y deseado con la solucin propuesta y sus alcances contrastando adems con otras soluciones existentes. Asimismo se presentan la planificacin de tareas y actividades a ser realizadas, culminando con la descripcin de la solucin por implementar.

1.1.

Definicin de Problema

Con la aparicin de nuevas y mejores herramientas en tecnologas de informacin orientadas a la automatizacin de sus procesos y el cumplimiento de los objetivos en las organizaciones, actualmente stas se consideran en todo mbito un factor de cambio determinante para el mejoramiento y desarrollo de las actividades del sector educacin. Las instituciones educativas regulares (en los niveles de educacin inicial, primaria y secundaria) vienen incorporando herramientas de apoyo a los alumnos con las tareas establecidas por los profesores en un proceso de aprendizaje en lnea desde los hogares junto con la orientacin a padres y/o tutores. Por otra parte, las universidades vienen asignando anualmente mayores

recursos para implantar plataformas educativas en paralelo a sus procesos habituales de enseanza como el Sistema de Gestin de Aprendizaje Moodle implantado en las universidades ESAN (como EsanVirtual) y la PUCP (como Paideia PUCP). Otras instituciones amplan sus servicios hacia los usuarios sobre su plataforma tecnolgica base (mediante la implementacin de aplicaciones de propsito especfico destinadas para dispositivos mviles); lo anterior aplica actualmente en las principales escuelas de negocios del pas. Desde hace algunos aos viene ocurriendo un incremento en la demanda de equipos de cmputo porttiles a diferencia de los equipos de escritorio (El Comercio 2012). Este escenario demuestra la alta demanda de los usuarios a servicios y aplicaciones en lnea, siendo el rubro educativo uno de los ms competitivos en el mercado del software.

En el caso de los centros de educacin especial (y por ende la educacin especial en el Per como tal) encuentra un desfase en las polticas de aprovechamiento de las Tecnologas de Informacin y Comunicacin (TIC). Estas instituciones trabajan con los alumnos en base a una metodologa flexible, interactiva, personalizada y no estrictamente sujeta a un currculo fijo y nico para todos sus participantes. El mbito de la educacin especial se vale de perfiles y antecedentes clnicos, psicolgicos y psiquitricos para el establecimiento de programas de enseanza y terapias del alumno, previa evaluacin al postulante. La complejidad de este sistema educativo se incrementa durante la fase de entrenamiento por cuanto comprende un staff de especialistas (mdicos, psiclogos, fisioterapeutas, psiquiatras, educadores y otros) para un nico alumno.

Para esta labor es importante la cooperacin familiar, por ello regularmente en los centros educativos se organizan dinmicas con los padres reforzando aspectos a practicar en casa con sus hijos. Otros recursos lo constituyen las entrevistas, entrenamientos en casa o en el aula, reuniones y entrevistas a hermanos u otros conocidos, entre otros. Estos avances son medidos progresivamente para cada miembro de familia por parte del especialista, quien a su vez recibe una calificacin acorde a su desempeo y pautas a considerar para futuras capacitaciones y entrenamientos.

Con una frecuencia semanal o quincenal los especialistas envan a las familias de los alumnos un informe manuscrito con el detalle del trabajo efectuado, los avances, metas alcanzadas y aspectos por cumplir durante la semana, as como

recomendaciones como parte de su evaluacin. Este documento constituye un importante y nico medio de comunicacin fsico entre la familia y el centro educativo especial para el registro de los avances y problemas presentados.

Actualmente un nmero importante de centros educativos especiales no disponen de un sistema capaz de brindar informacin pertinente de las labores pedaggicas apropiadamente. Existen casos donde la generacin de los programas de capacitacin y entrenamiento, junto con la actualizacin y evaluacin se realizan manualmente reflejando as la carencia de un medio automatizado para el control de cambios. Es prioritario en las evaluaciones el mantenimiento de un record de notas semanal, mensual, bimestral o anual. Del mismo modo, la informacin de los alumnos es recopilada peridica y manualmente en formatos fsicos junto con los avances progresivos, a falta de un medio automtico para el control de cambios de los programas educativos desde los primeros aos de estudios en el centro. Las observaciones y sugerencias de los especialistas son redactadas a mano y, debido a la alta rotacin de especialistas, la informacin preliminar es susceptible de prdida u olvido en los almacenes y oficinas. Este escenario se agrava cuando los centros carecen de informacin cientfica especializada y actualizada de los trastornos psicolgicos tratados, impactando negativamente en el diagnstico y tratamiento posterior de los estudiantes. Otra problemtica existente ocurre en la planificacin de las tareas y actividades pedaggicas, debido a la ausencia de un eficiente procedimiento de calendarizacin de tareas y horarios de atencin entre los mismos especialistas.

Estos centros requieren contar con una herramienta de gestin educativa de carcter descentralizada como apoyo al staff de profesionales de los centros educativos, cuyas herramientas faciliten la actualizacin de informacin de los avances y problemas encontrados durante el proceso de enseanza en los jvenes especiales, as como generar automticamente un programa de entrenamiento supervisado por los padres en lnea aplicables durante el entrenamiento en el hogar. Adicionalmente esta herramienta hara posible el mantenimiento de distintos trastornos psiquitricos y escalas de severidad correlacionndolas a un conjunto de terapias aplicables en base a la escala de los trastornos. Se constituira adems como un medio de comunicacin entre la familia y los especialistas.

En una serie de visitas y entrevistas realizadas a coordinadores de centros educativos especiales ubicados en la ciudad de Lima, un sector importante carece

de un sistema de gestin educativa. Mientras otras instituciones trabajan sobre una base tecnolgica limitada a tareas ofimticas.

Los pobres niveles de desempeo operativo existentes en muchos centros educativos especiales guardan relacin directa con la carencia de un medio automatizado de administracin de programas educativos y de la informacin de alumnos, trastornos y terapias. Por tanto, en este proyecto de tesis se implementar un sistema Web orientado a la gestin educativa en los centros de educacin especial.

1.2.

Marco Conceptual

En esta seccin se ampla el marco terico base para el desarrollo y comprensin de la temtica de este proyecto de fin de carrera. 1.2.1. Educacin Especial Se define como un proceso integral, flexible y dinmico de las orientaciones, actividades y atenciones cuya aplicacin comprende los diferentes niveles y grados en sus respectivas modalidades para la superacin de las deficiencias y encaminadas a conseguir la integracin social (Equipo Taure 1980). Otra acepcin la presenta como una educacin ordinaria con caractersticas propias y dirigida a sujetos excepcionales, es decir, sujetos quienes por defecto o exceso han de participar en programas especiales para su integracin en la escuela ordinaria (Snchez 2001). Heward amplia el concepto hacia una instruccin individualmente planeada, sistemticamente implementada y cuidadosamente evaluada, con miras a contribuir al logro de las mejores posibilidades de autosuficiencia y xito en los ambientes presentes y futuros (Heward 2005).

Siguiendo esta lnea los programas educativos, sesiones y servicios diseados para desarrollar el potencial educativo de los nios con discapacidades involucran la participacin conjunta de un amplio staff de profesionales desde trabajadores sociales, psiclogos, enfermeros, educadores, entre otros.

1.2.2. Discapacidad Las Naciones Unidas (Zevallos 2005) reconocen este trmino como la forma de una deficiencia fsica, intelectual o sensorial, una dolencia atendida clnicamente o una enfermedad mental de carcter permanente o transitoria.

La ley peruana en su artculo 2 define a la persona con discapacidad como aquella con una o ms deficiencias evidenciadas con la prdida significativa de alguno o algunas de sus funciones fsicas, mentales o sensoriales () la disminucin o ausencia de la capacidad de realizar una actividad dentro de las formas o mrgenes considerados normales (Congreso de la Repblica del Per 2011).

Los alumnos integrantes de un centro educativo especial presentan considerables dficits a nivel biolgico como estado de salud debilitado, nivel de conciencia inferior, ausencia de habla y movilidad voluntaria deficiente. 1.2.3. Diseo curricular

Segn Brennan (Molina 1990) el diseo curricular debe compatibilizar entre una serie de reas curriculares comunes a los alumnos con distintos niveles de aprendizaje en funcin a la experiencia, actitudes e incluso por las competencias cognitivas del alumno, conforme muestra la figura 1.1.
EXPERIENCIA Podra Funcional Directa Debera Ha de Contextual Presente ACTITUDES

Transmitida

Apreciada

Figura 1.1 Esquema de Diseo Curricular (Molina 1990)

Para Brennan el diseo y construccin de un marco de trabajo conformado por las caractersticas anteriores no puede ser determinado por el Ministerio de Educacin sino debe involucrar a los especialistas y las familias considerando la infraestructura del centro educativo y las necesidades educativas variables de los estudiantes.

1.2.4. Necesidades Educativas Especiales

Se entiende por persona con necesidades educativas especiales a aquella con dificultades o discapacidades las cuales dificultan su proceso de aprendizaje o su acceso a la educacin a diferencia de otros de su misma edad (Snchez 2001).

1.2.5. Adaptacin curricular Una adaptacin curricular rene estrategias de apoyo al proceso de enseanza aprendizaje en un grupo de alumnos con necesidades educativas especiales, como respuesta a la diversidad individual independientemente del origen de esas diferencias, historia personal, historial educativo, motivacin, ritmo de aprendizaje, entre otros (Augustbriga 2007). Se trata de todo ajuste efectuado sobre el currculo educativo propio de los alumnos con necesidades educativas especiales.

1.2.6. DSM-IV El DSM-IV (APA 2000) es una clasificacin categorial de los trastornos mentales en diversos tipos basndose en series de criterios con rasgos definitorios. La formulacin de categoras es el mtodo habitual de organizar y transmitir informacin en la vida diaria y ha sido el enfoque fundamental empleado en todos los sistemas de diagnstico mdico. El DSM-IV contempla como trastornos del aprendizaje una serie de dificultades en el aprendizaje de las habilidades acadmicas, particularmente lectura, clculo y expresin escrita. 1.2.7. La Educacin Especial en el Per

Desde la Ley de Reforma Educativa del Per del ao 1971 hasta la fecha, es el Estado responsable de estimular y apoyar la educacin especial velando por su inclusin social y laboral haciendo valer sus derechos y deberes (OEI 1997).

Desde el ao 1971 a la fecha se ha incrementado el nmero de centros de educacin especial hasta superar los trescientos setenta (370) distribuidos entre programas de Intervencin Temprana (PRITE), centros de educacin bsica especial (CEBE), centros de recursos de EBE (CREBE), servicios de apoyo y

asesoramiento a las necesidades educativas especiales (SAANEE). Sin embargo

an la cobertura de la poblacin excepcional estimada alcanzaba solamente el 1.2% hacia 1997 (OEI 1997).

1.3.

Plan del Proyecto

En esta seccin se describe la metodologa y procedimiento adoptados para llevar a cabo la administracin del proyecto de fin de carrera, as como del ciclo de desarrollo del producto software. Seguidamente se presenta la estructura de descomposicin del trabajo (EDT) y el cronograma de actividades. 1.3.1. Metodologa y procedimiento

Para la gestin de este proyecto se tomarn como lineamientos base los fundamentados descritos en la cuarta edicin del libro A Guide to the Project Management Body of Knowledge (PMBOK) elaborado por el Project Management Institute (PMI), para la gestin del proyecto en su conjunto. Se decide esto porque los procesos y reas de conocimiento descritos en el PMBOK cubren adecuadamente las cinco fases desde el inicio hacia el final del proyecto. La figura 1.2 presenta los cinco grupos de procesos de la gestin de proyectos.

Figura 1.2 Grupos de Procesos de Proyecto (PMI 2008)

Como parte del proceso de ejecucin se tiene previsto seguir las pautas de la metodologa Agile Unified Process (AUP) vinculada a las fases de Elaboracin y Construccin del producto software, por cuanto los entregables requeridos por esta metodologa son adaptables a la realidad y tiempo de vida del proyecto y correspondientes con la naturaleza de la solucin informtica objetivo; junto con la existencia de un mayor nmero de herramientas de cdigo abierto, destinadas al

modelamiento de sistemas en notacin UML generando los artifacts RUP necesarios para las fases de anlisis y diseo.

Sin embargo conviene limitar el mbito de procesos de gestin para el presente trabajo, adoptando una parte de estos entregables segn la necesidad del proyecto. En ese sentido se presentar la relacin de procesos seleccionados, clasificados por grupos de procesos, junto con las justificaciones del caso. Se trabajar con los fundamentos de la cuarta edicin del PMBOK vigente desde el ao 2008 (PMI 2008).

1.3.1.1.

Grupo del Proceso de Iniciacin

Este grupo tiene como propsito definir el proyecto a realizar anexando el alcance global (funcional y tcnico), especificando los recursos econmicos y/o tecnolgicos e identificando a los interesados en el proyecto. De acuerdo con la figura 1.3 los procesos involucrados en este grupo son:

1.1. Desarrollar Acta de Constitucin del Proyecto 1.2. Identificar interesados

Figura 1.3 Grupo del Proceso de Iniciacin

Para propsitos de esta tesis en este grupo se adoptar el proceso 1.1 por cuanto este proceso incorpora la documentacin de los requisitos iniciales para satisfacer los objetivos y expectativas, as como para formalmente autorizar el inicio de todo nuevo proyecto. 1.3.1.2. Grupo del Proceso de Planificacin

El propsito de este grupo es establecer el alcance total en trminos de esfuerzo y objetivos, as como la modalidad del trabajo en la gestin y finalmente desarrolla la lnea de accin para completar tales objetivos. Se establece un plan de direccin y los documentos a ser utilizados para llevarla a cabo.

En esta etapa se profundiza el anlisis en trminos de calidad, riesgo, costo y alcance. Los procesos involucrados en este grupo se presentan a continuacin en la figura 1.4:

10

2.12. Planificar la Calidad

2.6. Secuenciar las Actividades

2.7. Estimar los Recursos de las Actividades

2.13. Desarrollar el Plan de Recursos Humano 2.1. Desarrollar el Plan para la Direccin del Proyecto

2.5. Definir las Actividades

2.8. Estimar la Duracin de las Actividades

2.2. Recolectar requerimientos

2.3. Definir el Alcance

2.9. Desarrollar el 2.4. Crear la EDT Cronograma

2.14. Planificar las Comunicaciones

2.15. Planificar la Gestin de Riesgos

2.20. Planificar las Adquisiciones

2.16. Identificar Riesgos

2.19. Planificar la Respuesta a los Riesgos

2.11. Determinar el Presupuesto

2.10. Estimar Costos

2.17. Realizar Anlisis Cualitativo de Riesgos

2.18. Realizar Anlisis Cuantitativo de Riesgos

Figura 1.4 Grupo del Proceso de Planificacin

Para propsitos de esta tesis los procesos vinculados con la Gestin de Calidad (2.12), Gestin de Recursos Humanos (2.13), Gestin de Comunicaciones (2.14), Gestin de Adquisiciones (2.20) y Gestin de Costos (2.10 y 2.11) no sern tomados en cuenta para la documentacin final debido a la oportuna identificacin de los recursos humanos, logsticos e informticos especficos para el trabajo y su administracin y seguimiento no demandarn para el autor de una mayor complejidad.

En cambio si es importante para fines de planificacin definir las acciones y la modalidad sobre cmo planificar, ejecutar, supervisar, controlar y cerrar el proyecto (2.1), documentar los requerimientos y necesidades obtenidos una vez identificados (2.2), elaborar la descripcin detallada del producto y del proyecto (2.3), subdividir el trabajo en actividades y tareas as como precisar los entregables a manejar (2.4). Con la definicin del EDT (o Estructura de Descomposicin del Trabajo) se procede a identificar las actividades a ser realizadas para elaborar los entregables y construir las relaciones existentes entre todas stas para su posterior

calendarizacin (2.5, 2.6 y 2.8 respectivamente). El proceso 2.7 ser considerado, pues es indispensable especificar, de acuerdo a cada actividad y su complejidad, cunta demanda y esfuerzo requiere por parte del autor y de los recursos utilizados.

Es importante llevar un tratamiento de los riesgos posibles a incurrir en este proyecto. En ese sentido, la especificacin de las actividades a efectuar en la gestin de riesgos (2.15), identificar y documentar los riesgos y caractersticas (2.16), establecer la priorizacin de riesgos en trminos probabilsticos y medir sus

11

impactos al proyecto, (2.17) cuantificando sus consecuencias y magnitudes (2.18) para finalmente establecer las respuestas inmediatas y as mitigar posibles amenazas y retrasos (2.19) blindarn al proyecto ante posibles incidentes. 1.3.1.3. Grupo del Proceso de Ejecucin

Est conformado por los procesos requeridos para completar todo el trabajo pautado en el plan, para as cumplir con las especificaciones tanto a nivel de producto como de proyecto. Los procesos involucrados en este grupo se muestran en la figura 1.5:
3.3. Adquirir el Equipo del Proyecto 3.4. Desarrollar el Equipo del Proyecto 3.5. Dirigir el Equipo del Proyecto

3.2. Realizar Aseguramiento de Calidad

3.1. Dirigir y Gestionar la Ejecucin del Proyecto

3.6. Distribuir la Informacin

3.8. Efectuar Adquisiciones

3.7. Gestionar las Expectativas de los Interesados

Figura 1.5 Grupo del Proceso de Ejecucin

El control de la calidad no amerita de un tratamiento amplio a nivel documentario (con excepcin de las pruebas de verificacin y validacin del producto), as como la conformacin del equipo de proyecto (por cuanto nicamente el ejecutor de todo este proyecto es el tesista) no formar parte de los entregables finales de este trabajo. De igual modo las adquisiciones o compras para el proyecto no demandarn grandes esfuerzos dadas las especificaciones limitadas del producto final, as como un control fino de los medios de informacin y distribucin de informacin. Por tanto solamente se abarcar la ejecucin del proceso 3.1, en definitiva representa la ejecucin del trabajo tcnico y funcional.

PMBOK rene las buenas prcticas en gestin de proyectos pertenecientes a mltiples reas y disciplinas, pero para propsitos de un proyecto de software es determinante adoptar una metodologa de apoyo y orientada a proyectos de corte informtico, tomando en cuenta el ciclo habitual de desarrollo de sistemas y reflejando los avances en las fases de anlisis y diseo para todos los entregables, diagramas y productos finales. Frente a estos propsitos, la metodologa AUP abarca, adems de un conjunto de procedimientos y herramientas dirigidos a un correcto modelamiento del negocio durante el ciclo de vida de desarrollo del

12

software, un marco de trabajo de buenas prcticas para la etapa de construccin del software (Leffingwell 2011). Su eleccin y justificacin como metodologa de desarrollo de software se profundizan en el siguiente captulo.

Como se observa en la figura 1.6 la metodologa presenta cuatro fases denominadas Iniciacin, Elaboracin, Construccin y Transicin. El modelamiento de sistemas en base a los requerimientos se procesa en la primera fase. La Elaboracin es un hito de importancia porque aqu se define formalmente la arquitectura de producto. Ms adelante se detallan los riesgos tcnicos resueltos y genera un primer prototipo para revisin del usuario. De igual forma, en la fase de Construccin se trabaja en la realizacin de un producto totalmente operativo y eficiente, acorde con los lineamientos y patrones definidos por el equipo de desarrolladores. La etapa de Construccin constar de siete iteraciones (una por cada mdulo del sistema) donde cada iteracin tendr como hito una versin preliminar del producto incorporando, por cada entrega, nuevas funcionalidades de la herramienta hasta la versin definitiva. Como conclusin, esta metodologa presenta un comportamiento iterativo-incremental. Para mayores alcances, revisar el Captulo 2.

Figura 1.6 Ciclo de vida de desarrollo de software segn AUP (Leffingwell 2011)

1.3.1.4.

Grupo del Proceso de Seguimiento y Control

Este grupo de procesos tiene como propsito supervisar, analizar y controlar el avance y performance del proyecto, identificando actividades y posibles cambios (control de cambios) a ser completados evitando retrasos durante el avance. En lneas generales se busca controlar lo planificado como costos, tiempos y avance, as como la calidad de la solucin y el seguimiento de riesgos. De la misma manera, se controlar la evolucin del producto software. Los procesos involucrados en este grupo se muestran en la figura 1.7:

13

4.6. Controlar Costos

4.4. Controlar el Alcance

4.3. Verificar el Alcance 4.7. Realizar Control de Calidad

4.1. Dar Seguimiento y Controlar el Trabajo del Proyecto

4.2. Realizar Control Integrado de Cambios

4.8. Informar el Desempeo

4.9. Dar Seguimiento y 4.5. Controlar el Cronograma Controlar los Riesgos

4.10. Administrar las Adquisiciones

Figura 1.7 Grupo del Proceso de Seguimiento y Control

En este grupo el proceso 4.1 se adoptar para medir y monitorear el desempeo contrastando con lo estipulado a nivel de alcance, el cronograma de actividades y riesgos. Actualmente se cuenta con mtodos e indicadores (como el EV o Valor Ganado) o a nivel de costos y presupuestos (como la tasa interna de retorno y valor presente neto) para contrastar el avance real en el proyecto con el avance esperado en una etapa inicial. Asimismo toda propuesta de cambios, su debida revisin y evaluacin del impacto afectan directamente a los activos del proyecto, documentacin y al plan de la direccin del proyecto, por lo cual el proceso 4.2 cumplir para tales fines. Como lo anterior implica la verificacin y control del alcance del proyecto y producto antes de aprobar o rechazar los cambios, aceptando o denegando los entregables completados del proyecto, los procesos 4.3 y 4.4 vinculados al seguimiento del alcance formarn parte de la gestin.

Los procesos 4.5 y 4.9 trabajarn conjuntamente en el seguimiento del cronograma, detectando posibles retrasos y desfases entre actividades y tiempos, proponiendo medidas para el aprovechamiento de oportunidades y mitigacin de amenazas frente a futuros riesgos en caso se presenten. 1.3.1.5. Grupo del Proceso de Cierre

Este grupo est compuesto por aquellos procesos necesarios para concluir todas las acciones y completar formalmente el proyecto o determinada etapa. Existe una verificacin global de las actividades completadas como prembulo a la culminacin

14

formal de una etapa o proyecto. En el marco de este proyecto un cierre representar tanto la culminacin de cada fase del ciclo de vida de desarrollo de software como la entrega definitiva del documento de tesis y anexos ante la Facultad de Ciencias e Ingeniera. La figura 1.8 muestra los procesos involucrados en este grupo:

5.1. Cerrar el Proyecto o Fase

5.2. Cerrar las Adquisiciones

Figura 1.8 Grupo del Proceso de Cierre

Para este proyecto se contar con el proceso 5.1 entendido como la conclusin de cada una de las fases de desarrollo del producto final as como la entrega del documento de tesis y sus anexos respectivos a la Facultad de Ciencias e Ingeniera y posterior sustentacin ante el jurado calificador. 1.3.2. Planificacin

Se presentan a continuacin los siguientes diagramas con la planificacin del proyecto para los prximos meses: Diagrama EDT ubicado en la figura 1.9. Diagrama de Gantt ubicado en las figuras 1.10 (correspondiente a la fase I, durante el desarrollo del curso Proyecto de Tesis I) y 1.11 (correspondiente a la fase II del proyecto).

Como fecha de entrega inicialmente fue considerada como la fecha de entrega ante el asesor de tesis del documento de tesis y anexos elaborados durante el curso Proyecto de Tesis 2 dentro del ciclo acadmico 2008-1.

En cambio la entrega de la solucin informtica completa y operativa junto con el documento de tesis y anexos actualizados y los resultados de las pruebas est pactada para fines del ao 2011. La prolongacin del tiempo de entrega del proyecto obedece a razones de ndole laboral y acadmica de responsabilidad del tesista.

15

Figura 1.9 Estructura de descomposicin del trabajo del proyecto

16

Figura 1.10 Diagrama de Gantt Cronograma de proyecto Fase I

17

Figura 1.11 Diagrama de Gantt Cronograma de proyecto Fase II

18

1.3.3. Riesgos del Proyecto

En secciones previas se justificaron las razones por las cuales era imprescindible mantener una correcta gestin de riesgos y planes de acciones para encarar cualquier incidente imprevisto durante el desarrollo del trabajo. A continuacin, en base a la experiencia profesional del tesista, se presenta una relacin de posibles eventos los cuales de presentarse provocaran retrasos o desfases en el normal avance del trabajo.

En el PMBOK se define el trmino riesgo como un evento incierto cuya ocurrencia provoca efectos en los objetivos del proyecto repercutiendo en el alcance, cronograma, costo y calidad (PMI 2008). El riesgo puede ser clasificado como: Riesgos tcnicos, de calidad y/o rendimiento: Este grupo se encuentra presente durante las actividades de diseo y desarrollo del producto deseado y en donde intervienen aspectos de carcter tcnico en su elaboracin y control de calidad. Riesgos en la gerencia de proyectos: Son riesgos presentes en parte de los procesos de gestin y direccin llevados a cabo. Su manejo queda bajo la responsabilidad del equipo del proyecto. Riesgos organizacionales: Son riesgos provenientes de la misma

organizacin laboral o profesional a quienes el proyecto y/o producto impacta directa o indirectamente en sus funciones. Para fines de este proyecto este grupo no aplicar para la gestin de riesgos. Riesgos externos: Son riesgos presentes en el mbito exterior (entorno) de la organizacin. Para fines de este proyecto este grupo no aplicar para la gestin de riesgos.

En la tabla 1.4 se muestran los riesgos identificados y clasificados en la Matriz de Probabilidad e Impacto (MPI), permitiendo relacionar los eventos considerados como riesgos con el grado de probabilidad de ocurrencia e impacto respecto al proyecto en su conjunto. Finalmente, la ltima columna refleja el coeficiente de severidad.

Para la clasificacin de cada dimensin se asumieron las escalas mostradas en las tablas 1.1, 1.2 y 1.3.

19

Tabla 1.1 Escalas de Medida de Probabilidad

Probabilidad Rango 0.00 a 0.25 0.26 a 0.50 0.51 a 0.75 0.76 a 1.00 Descripcin Muy Baja Baja Media Alta

Tabla 1.2 Escala de Medida de Impacto

Impacto Rango 0.00 a 0.25 0.26 a 0.50 0.51 a 0.75 0.76 a 1.00 Descripcin Muy Leve Leve Moderado Severo

Tabla 1.3 Escala de Severidad

Severidad Rango 0.00 a 0.25 0.26 a 0.50 0.51 a 0.75 0.76 a 1.00 Descripcin Muy baja Baja Media Alta

Tabla 1.4 Riesgos del Proyecto Grupo de Riesgos

Riesgos tcnicos, calidad de y/o

Riesgo (R)
Curva de aprendizaje en herramientas de desarrollo de sistemas prolongada. Demora en la presentacin de los entregables. Desconocimiento en herramientas de desarrollo genera retrasos en la implementacin. Diseo muy complejo e ininteligible para las actividades de implementacin. Exclusin de artifacts de software considerados importantes para una mejor documentacin del anlisis y diseo. La arquitectura propuesta no va acorde a las especificaciones del diseo. Las libreras nativas de la plataforma de programacin son incompatibles con algunas bases de datos. Metodologa mal aplicada en el anlisis y diseo del sistema y la base de datos. Ausencia de buenas prcticas en programacin. No se cuenta con un estndar de programacin ni diseo apropiado. Plan de pruebas no cubre adecuadamente todas las funcionalidades de la aplicacin. Pobre anlisis y/o diseo no satisface correctamente los requerimientos. Infraestructura informtica de bajo rendimiento para la construccin. Alta volatilidad y cambios en los requerimientos durante el proyecto. Estimacin errtica en la duracin de algunas

Probabilidad (P)
0.25

Impacto (I)
0.50

Severidad (PXI) 0.13 0.49 0.33

0.65 0.55

0.75 0.60

rendimiento

0.55

0.65

0.36 0.19

0.35

0.55

0.35

0.70

0.25 0.34

0.40

0.85

0.45

0.70

0.32 0.16 0.13 0.32 0.25 0.25 0.44 0.77

0.25 0.25

0.65 0.50

0.45

0.70

0.35

0.70

0.35

0.70

Riesgos en la Gerencia Proyectos de

0.55

0.80

0.85

0.90

20

actividades. Incumplimiento en los plazos de entrega de iteraciones y versin final del producto. El estudio de viabilidad tcnicaeconmica presenta inconsistencias. No se realiza el monitoreo de tareas y actividades. No se monitorean los riesgos del proyecto. Pobre delimitacin del alcance del producto y proyecto. Pobre determinacin de actividades y tareas en el calendario. Mecanismo de control de cambios de producto y proyecto ineficiente. Retiro del responsable del proyecto de fin carrera. Tiempo insuficiente para muchos requerimientos. Tiempos de desarrollo en el proyecto no concuerdan con el programa.

0.65

0.75

0.49 0.29 0.76 0.55 0.68 0.72 0.39 0.93 0.44 0.42

0.45

0.65

0.95 0.65 0.80 0.85

0.80 0.85 0.85 0.85

0.55

0.70

0.95 0.55 0.55

0.98 0.80 0.77

De acuerdo con la tabla 1.4 y las escalas presentadas, existe un 24% de riesgos identificados como de mediana o alta severidad (12% en sendas categoras) para el proyecto. Estos riesgos severos corresponden a los procesos de gestin y la mitad de stos con la planificacin y seguimiento de actividades y tareas. Su severidad se justifica por el alto impacto negativo al avance efectuado en trminos de tiempo en caso no se concreten todas las actividades forzando el equipo de proyecto a realizar cortes o descarte de tareas comprometiendo al alcance del producto y/o proyecto. No obstante, la delimitacin del alcance de proyecto y del producto tambin influye de manera severa por lo cual se recomienda la dedicacin de mayores esfuerzos en tiempo y recursos ad hoc para plasmar satisfactoriamente las necesidades del usuario final.

Por comparacin de promedios entre los factores de severidad de riesgos tcnicos (0.27) y riesgos del proyecto (0.57), los riesgos por implementacin o de carcter tcnico representan una baja severidad porque las actividades de diseo y construccin se ejecutaron prevaleciendo la aplicacin de buenas prcticas segn la metodologa de desarrollo as como el uso de las herramientas de programacin. Diversos frameworks de desarrollo proporcionan amplia documentacin de apoyo a estas labores, junto a un considerable paquete de libreras y herramientas de compatibilidad, actualizadas constantemente por los proveedores de software. Por otro lado, la plataforma informtica utilizada rene las caractersticas recomendadas por el fabricante para el ptimo rendimiento y trabajo exigidos en un proyecto de

21

esta envergadura. Finalmente, el proyecto a nivel global ostenta una severidad baja (0.416) lo cual se espera prosiga aplicando las acciones preventivas y correctivas correspondientes. 1.3.4. Plan de Respuesta ante riesgos

Se presentar a continuacin una seleccin de medidas comprendidas en el Anexo M: Plan de gestin de riesgos. Estas acciones estn orientadas a velar por una correcta direccin de proyecto respecto al manejo y control de riesgos para minimizar o atenuar los efectos negativos al proyecto en caso se presenten. En la etapa de Planificacin se invertir el tiempo razonable en capturar y formalizar correctamente los requerimientos del producto y contrastando las soluciones con opinin de expertos y profesionales quienes conjuntamente con los usuarios finales avalen el proceso automatizado. Bajo este juicio de expertos los requerimientos no presentarn mayores variantes durante el proceso. Consolidada esta etapa es importante especificar las actividades y tareas a efectuar en el proyecto asegurando la adjudicacin de tiempos razonables en funcin a la naturaleza del riesgo, junto con las acciones a seguir. En la etapa de Ejecucin se contarn con las IDE y libreras de la plataforma de programacin procurando su mantenimiento y constante actualizacin va conexin a Internet. El acceso a Internet 24x7 favorecer al equipo de desarrollo durante la recopilacin de documentacin electrnica y manuales de programacin acelerando la fase de aprendizaje y capacitacin en dichas herramientas. La arquitectura ser sometida a pruebas durante la

implementacin a travs de casos de uso breves validando la entrada de datos segn el mecanismo propuesto por la arquitectura y diseo original. Las labores de codificacin irn de la mano con la realizacin de pruebas para validacin de las casusticas una vez concluida la implementacin de cada mdulo junto con sus funcionalidades antes de la presentacin de las respectivas iteraciones. En la etapa de Seguimiento y Control, especficamente para la administracin del cambio se llevar un procedimiento de evaluacin y ejecucin de cambios en la implementacin. Toda solicitud de cambio implicar su contraposicin ante el modelo de negocio originalmente conceptualizado y en caso de proceder se ejecutarn las medidas correctivas a nivel de anlisis, diseo e implementacin.

22

1.4.

Estado del Arte

En esta seccin se presentarn los sistemas de gestin educativa identificados durante la investigacin acompaados por sus principales caractersticas. 1.4.1. Sistemas de Gestin Educativa

Los sistemas mostrados a continuacin fueron clasificados como sistemas de gestin educativa para propsitos generales.

1.4.1.1.

SIAGIE

El Sistema de Informacin de Apoyo a la Gestin en la Institucin Educativa o SIAGIE es un sistema Web creado en el ao 2003 por la Oficina de Ofimtica del Ministerio de Educacin del Per con la finalidad de consolidar en una base de datos los registros histricos de alumnos de las instituciones educativas a nivel nacional (Minedu 2011). El propsito es lograr la estandarizacin electrnica de documentos de valor oficial como nminas de matrcula, registros de evaluacin, boletas de notas, actas de evaluacin y otros documentos recabados por el Estado.

Este sistema Web fue construido bajo la plataforma ASP.NET y presenta las siguientes funcionalidades: Soporta los procesos de matrcula, asistencia y evaluacin de estudiantes. Permite la configuracin de diferentes parmetros y conceptos aplicables a gran parte de todas las instituciones educativas clientes. Este mdulo slo es controlado por parte del equipo de administracin central del ministerio. Incorpora la gestin de informacin del personal docente y administrativo. Permite el registro y mantenimiento de la informacin de los estudiantes y sus procesos de aprendizaje, basado en el Diseo Curricular Nacional.

Adicionalmente brinda la posibilidad de registrar inasistencias, tardanzas y justificaciones de faltas de los estudiantes. Permite la consulta de notas, faltas e inasistencias de los alumnos en la institucin educativa. Cuenta con un mdulo diseado para la administracin de redes educativas, importante para el control de sus recursos en infraestructura y soporte.

23

 Permite el mantenimiento y control de los usuarios, la asignacin de roles y la administracin de privilegios. Brinda un tutorial de ayuda de los principales comandos. 1.4.1.2. EDUSYSNET

EDUSYSNET es un sistema Web construido en lenguaje PHP destinado a la administracin de centros educativos como colegios, institutos y centros de educacin tcnica-productiva (Digitechdata 2011).

Este producto es desarrollado por la empresa peruana Digitechdata y sus funcionalidades ms destacadas son: Mdulo Matrcula: Permite el mantenimiento de datos del alumno y sus tutores. Ofrece reportes de consolidado de matrcula, relacin de alumnos matriculados por fechas, distribucin de alumnos por aulas y por fechas de matrcula, entre otras. Mdulo Notas y Cursos: Se establece la calificacin alfanumrica de acuerdo a las polticas y necesidades de los centros educativos. Asimismo realiza la creacin de cursos y docentes responsables por curso con sus respectivas actas de notas. Mdulo Conductas y Tutora: Posibilita el seguimiento conductual del alumno junto con un registro de incidencias con el detalle de amonestaciones, inasistencias y tardanzas segn corresponda. Mdulo Control de Pagos: Para realizar el seguimiento de los pagos por derechos acadmicos con posibilidad de crear cuentas corrientes por cada alumno y programando las fechas de cancelacin. Mdulo Documentos Oficiales: Permite emitir nminas y actas oficiales, actas de recuperacin y fichas integrales del educando. Estos documentos posteriormente son exigidos por el Ministerio de Educacin. Mdulo Encuestas: Ejecuta la evaluacin a profesores, tutores u otro personal de la institucin educativa; incluye la presentacin de los resultados de las encuestas y cuadros comparativos. Mdulo Padres de Familia, de uso exclusivo de los padres o tutores de los alumnos, se podrn consultar directamente los rcords de nota de los alumnos, el cronograma de pagos, comunicados oficiales de la institucin as como de los docentes del alumno.

24

1.4.2. Sistemas de Gestin Educativa en Educacin Especial

Los sistemas mostrados a continuacin fueron clasificados como sistemas de gestin educativa exclusivos para centros de educacin especial.

1.4.2.1.

SICE

El Sistema de Informacin de los Centros Educativos de la Comunidad de Madrid es un proyecto informtico liderado por la Consejera de Educacin de la Comunidad de Madrid, Espaa. Este sistema permite la gestin integral de los procedimientos en todos los centros educativos de los niveles infantil, primaria, secundaria y educacin especial presentando un entorno de trabajo compartido por los centros con fines de integracin de todos los procesos (Comunidad de Madrid 2008). Este apartado resaltar las caractersticas de la versin dirigida a la gestin de centros de educacin especial. Su acceso es por va Web y cliente/servidor.

Entre las principales funcionalidades de este sistema se tienen las siguientes: Mdulo Catlogos: Realiza los procesos de mantenimiento de datos de los diferentes tipos de discapacidad as como de las enfermedades involucradas. Para la gestin del personal no docente, se encarga del mantenimiento de las actividades asignadas. Mdulo Secretara: Realiza el mantenimiento de informacin de cada centro educativo como datos generales, datos sobre la poblacin con determinadas discapacidades, datos sobre la poblacin de alumnos con dos o ms necesidades educativas, entre otras. Posibilita la gestin de cursos por grupos de centros, as como la ejecucin masiva de los inicios de cursos por centro y distribucin de los alumnos. Asimismo permite el mantenimiento de

promociones de alumnos inscritos por curso y por centro educativo para verificar la relacin de alumnos asignados a varios cursos y determinando si procede o no su inscripcin como tal. Desde este mdulo es posible enviar informacin a otros sistemas para la consolidacin de estadsticas como por ejemplo nmero de alumnos en transporte escolar, total de alumnos atendidos en el servicio mdico, bibliotecas, comedor, entre otros. Adicionalmente la administracin del personal docente y no docente clasificado de acuerdo a especialidades y/o situacin laboral forma parte de este mdulo junto con la

25

emisin de informes con carcter oficial establecidos por la Consejera de Educacin de la Comunidad de Madrid. Mdulo Gestin de Personal: Desde este mdulo es posible realizar el mantenimiento de horarios de actividades del personal no docente asignando por cada colaborador del centro educativo una o ms actividades especificando adems los das y horas de trabajo en esta actividad. Mdulo Gestin de Alumnos: Este mdulo se encarga del proceso de matrcula de alumnos en el centro educativo, permitiendo el registro de informacin como porcentaje de discapacidad, tipo de discapacidad, religin, tipo de transporte asistido o no asistido, seguro escolar (en caso cuente con alguno), nombre de fisioterapeuta o tutor y otros alcances. Asimismo permite la actualizacin masiva de los alumnos del centro educativo. Finalmente, genera listados con la relacin de alumnos segn criterios como alumnado nuevo por centro, por rango de edades, por sexo, por etapa educativa, por aula, por discapacidad, entre otros criterios de seleccin.

1.4.2.2.

SEAS WEB

La compaa norteamericana Computer Automation Systems ha desarrollado este producto desde el ao 1996. Este sistema Web ha sido construido con la plataforma ASP.NET utilizando una base de datos SQL Server y con una arquitectura basada en servicios para una mejor performance (Computer Automation 2008). Actualmente soporta las actividades de ms de dos mil distritos en los Estados Unidos de Amrica y sus funcionalidades bsicas se adaptan a la realidad de cada centro educativo sin importar su tamao o complejidad. Este sistema cuenta con las siguientes caractersticas: Permite el mantenimiento de los programas educacionales individualizados especificando las caractersticas del trastorno del alumno, el mtodo de aprendizaje puesto en marcha, seguido del plan de trabajo escolar a realizar durante el ao acadmico consolidado a modo de calendario. Esta funcionalidad aplica tambin para centros de salud afiliados a las escuelas brindando atencin mdica a determinados alumnos, con el propsito de controlar los costos demandados por esta actividad y sus efectos en el presupuesto educativo. Realiza la asignacin de objetivos o cuadro de objetivos por actividad declarada a fin de medir la eficiencia y tiempo involucrado en su ejecucin.

26

 Provee de los servicios de mensajera y conferencia entre los docentes y padres de familia. SEAS introduce el concepto de administracin del proceso educativo por alumno o por grupo de alumnos mediante un workflow complementado con indicadores de desempeo, notificaciones en lnea de tiempo y mensajera entre los responsables del proceso. Permite la configuracin de formularios y reportes de monitoreo (exclusivo para docentes). Asimismo incorpora un administrador de reportes evaluaciones para efectos del mantenimiento y estandarizacin de todos los informes emitidos por la institucin educativa. SEAS incluye un set de formularios y reportes con valor oficial pre-configurados y requeridos por la jurisdiccin educativa. Todos los reportes generados a travs de este sistema se emiten en formato PDF.

1.4.2.3.

IEPWRITER

IEPWriter es un sistema Web dedicado exclusivamente al mantenimiento de programas educacionales individualizados desde un navegador con tecnologa SSL (Leader 2001) para la encriptacin de datos. Otras funcionalidades de este sistema son: Realiza los procesos de mantenimiento de datos de alumnos y docentes, as como la asignacin de alumnos a uno o ms docentes. Permite la administracin de bibliotecas de objetivos y metas accesibles para todos los docentes de la institucin. Se cuenta adems con un mecanismo de carga y descarga de objetivos y metas entre las instituciones educativas. Incorpora por defecto una serie de reportes como planes de soporte al comportamiento positivo, planes de tratamiento y planes de seguimiento clnico y teraputico. 1.4.2.4. SEIS

El Sistema de Informacin en Educacin Especial (SEIS por sus siglas en ingls) es un sistema de gestin educativa creado en el ao 2003 inicialmente para centros de educacin especial establecido en San Jos, California, Estados Unidos de Amrica

27

(San Joaqun 2004). Actualmente es soportado por la firma CEDR Systems. Las funcionalidades provistas por este sistema son: Permite la creacin de programas educacionales individualizados de los alumnos. Como parte de la legislatura norteamericana, viene incorporado con un administrador de objetivos educativos por actividades o por trastorno educativo basados en estndares como SEACO, BASICS, CSHA, ROPES, AUSPLAN, entre otros. Gestiona los programas educacionales individualizados facilitando su revisin y lectura. Cuenta con mecanismos para la lectura de informacin redundante por nica vez autocompletando los campos dependientes de este ingreso de datos. Adems de contar con un banco de objetivos estandarizados, los especialistas pueden administrar sus indicadores propios o crearlos a partir de otros objetivos ya existentes y de propiedad de otro docente.

1.4.2.5.

PFEEIE

El Sistema Integral de Informacin del Programa de Fortalecimiento de la Educacin Especial e Integracin Educativa (PFEEIE) es un sistema estadstico en lnea diseado para realizar el seguimiento sistemtico de los servicios de educacin especial as como de los alumnos con necesidades educativas especiales integrados a las escuelas y aulas regulares de la ciudad de Mxico. La forma de trabajo de este sistema es como sigue: Est conformado por un sistema estadstico en lnea y un manual de procedimientos de las operaciones. Captura y sistematizacin de los datos de la poblacin objetivo del Programa en pro del acopio de datos por parte de las entidades. Lleva a cabo la administracin de las escuelas de educacin inicial y bsica regular, afiliadas a mltiples servicios de educacin especial e integran alumnos con discapacidad.

1.4.2.6.

ASPEN

Aspen es un sistema Web basado en Java y desarrollado por la compaa X2Development Corporation en los Estados Unidos de Amrica. Se presenta como

28

una plataforma educativa integrada y distribuida en la modalidad software como servicio (SaaS) tanto en instituciones pblicas como privadas e inicialmente comprenda la gestin de procesos acadmicos en centros educativos regulares (X2DEV 2010). Desde el ao 2007, dentro del marco de procesos en educacin especial, cuenta con un mdulo encargado de la administracin de programas educativos para los alumnos integrado con el resto de componentes de la plataforma base. Aspen cuenta con las siguientes funcionalidades: La interfaz grfica de usuario guarda similitud con los formularios completados por los profesores manualmente facilitando as la interaccin. Permite el mantenimiento de alumnos y del staff de profesionales, en el primer caso incluyendo antecedentes clnicos y demogrficos. Como apoyo a las funciones docentes, permite la calendarizacin de actividades y tareas educativas por alumno o por grupo. Cuenta con un checklist interactivo de verificacin de los requisitos estatales y federales exigidos por las autoridades educativas a cada institucin. Ejecuta el seguimiento a escala global, basado en workflows, de los servicios educativos y mdicos brindados a los alumnos, logrando la automatizacin de actividades repetitivas a partir de la simplificacin de procedimientos administrativos (evaluaciones, enmiendas) y, a su vez, medir el progreso en las sesiones. Incorpora los servicios de correo electrnico a docentes y tutores del alumno. Aspen brinda las facilidades para confeccionar reportes a la medida de las necesidades de los usuarios finales. Asimismo contiene un set de reportes de carcter obligatorio y requeridos por las autoridades educativas competentes. 1.4.2.7. IEPPLUS

IEPPLUS es un software de gestin educativa desarrollado por la compaa Sungard y forma parte de la plataforma de gestin educativa integral Plus360 (Sungard 2002). IEPPLUS permite a los centros educativos administrar los programas educacionales individualizados as como en el establecimiento de objetivos para con los estudiantes. Es un sistema basado en formularios configurables cuyas funcionalidades comprendidas son: Permite el mantenimiento de datos de estudiantes y del staff de profesionales.

29

 Realiza la gestin de programas educacionales individualizados as como sus respectivas evaluaciones. Incorpora los procesos de planificacin de reuniones y eventos automatizados as como procedimientos en gestin y asignacin de objetivos. Incluye procesos automatizados de facturacin por servicios mdicos brindados por la unidad educativa. Genera informes personalizados de progreso del estudiante as como formularios estndares exigidos (con base a la regulacin americana IDEA) por las autoridades educativas compatibles con Microsoft Word.

1.4.2.8.

SIRNEE

El Sistema de Informacin Regional sobre Necesidades Educativas Especiales es un proyecto de sistemas an en fase de diseo patrocinado por la UNESCO en coordinacin con los Ministerios de Educacin de Amrica Latina y el Ministerio de Educacin y Cultura de Espaa desde el ao 2007. El propsito a alcanzar con este sistema es contar con datos y estadsticas para la construccin de indicadores de la situacin educativa de la poblacin con necesidades educativas especiales en la regin. 1.4.3. Resumen comparativo de las soluciones

La tabla 1.5 rene las caractersticas comparadas entre las soluciones investigadas y el sistema de informacin desarrollado en este proyecto de tesis (denominado Pegasus) a partir de los criterios y procesos funcionales y tecnolgicos.

Este cuadro comparativo muestra las ventajas ofrecidas por la solucin Pegasus, a diferencia de otros sistemas, en la incorporacin de la gestin de terapias (para la generacin de programas educativos) y control de asistencia (como apoyo al seguimiento de las participaciones de los alumnos y tutores en las sesiones educativas). Con la funcionalidad de evaluacin a especialistas el centro educativo obtendra el grado de satisfaccin de los usuarios sobre el servicio, factor a considerar durante la toma de decisiones sobre el staff de especialistas. La implementacin de un repositorio de documentos junto con el mdulo de mensajes y comunicaciones son funcionalidades claramente inexistentes en el resto de sistemas, y busca la participacin de la comunidad educativa en la capacitacin.

30

Tabla 1.5 Cuadro comparativo de las soluciones presentadas

Producto EDU SYSNET Criterios Tecnologa Ambiente SABD integrado Administrac in de usuarios, roles y perfiles. Administrac in del Proceso de Matrcula Administrac in de datos de estudiantes Administrac in de datos de especialista s Gestin de objetivos e Indicadores Administrac in de datos de trastornos Mantenimie nto de terapias PHP Web Slo PostgreSQL y MySQL ASP.NET Web y Cliente Servidor Slo SQL Server JAVA Web y Cliente Servidor Multiplatafor ma ASP.NET Web Slo SQL Server JAVA Web Multiplatafor ma ASP.NET Web Slo SQL Server ASP.NET Web Slo SQL Server JAVA Web Multiplatafor ma ASP.NET Web Slo SQL Server Por definir Web ASP.NET Web PostgreSQL , SQL Server y MySQL*** SIAGIE SICE Madrid SEAS Web IEPWriter SEIS PFEEIE Aspen IEPPLUS SIRNEE PEGASUS

Por definir

Por definir

NO

NO

NO

NO

NO

S*

NO

S*

NO

NO

NO

S*

NO

NO

NO

NO

NO

NO

S*

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

31

Producto EDU SYSNET Criterios Administrac in de actividades y tareas Administrac in de programas educativos Monitoreo de procesos por workflow Administrac in de Evaluacione s (alumnos) Administrac in de Evaluacione sa especialista s Repositorio documentari o en lnea Facturacin de procedimien tos mdicos Administrac in de pagos por derechos acadmicos Calendariza cin de S NO S S NO NO NO S S NO S SIAGIE SICE Madrid SEAS Web IEPWriter SEIS PFEEIE Aspen IEPPLUS SIRNEE PEGASUS

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

S*

NO

NO

NO

NO

NO

NO

S*

NO

32

Producto EDU SYSNET Criterios actividades y eventos Mensajera y comunicaci ones entre usuarios Control de asistencia Reportes (con o sin valor oficial) Sector objetivo SIAGIE SICE Madrid SEAS Web IEPWriter SEIS PFEEIE Aspen IEPPLUS SIRNEE PEGASUS

NO

NO

NO

NO

NO

NO

NO

NO

S S Educacin regular

S NO Educacin regular

NO S Educacin Especial y Regular

NO S Educacin Especial

NO S Educacin Especial

NO S Educacin Especial

NO S Educacin Especial

NO S Educacin Especial y Regular

S* S Educacin Especial y Regular

NO S Educacin Especial y Regular

S S** Educacin Especial

* Requiere la instalacin de otro(s) componente(s) software para esta funcionalidad. ** No se incluyen reportes con valor oficial en el sistema en la versin 1.0. *** Requiere regeneracin de la cadena de conexin de base de datos para el nuevo modelo de dominio.

33

1.5.

Descripcin y sustentacin de la solucin

Frente a la problemtica en torno a la necesidad de una solucin informtica para la gestin educativa en los centros de educacin especial y adaptada a la realidad local, se propone la implementacin de un sistema de informacin Web para el cumplimiento de estos propsitos. Este proyecto se constituye como uno de los primeros esfuerzos por democratizar el uso y aprovechamiento de las TI en centros de educacin especial pblicos y privados a nivel nacional (dada la carencia absoluta de tales plataformas en el sector informtico de este pas) ofreciendo las funcionalidades claves para flexibilizar la gestin e innovando los procesos en bsqueda de una mayor calidad educativa.

La solucin estar facultada para administrar informacin concerniente a los programas y actividades educativas de las instituciones hacia sus alumnos habilitando el acceso simultneo a usuarios internos (especialistas) y externos (miembros de familia).

Con este sistema se permitir el mantenimiento de informacin de los alumnos (datos personales, comunicaciones, entre otros) cumpliendo de este modo con la automatizacin de las labores de matrcula en paralelo con el mantenimiento del perfil clnico. Incorpora un procedimiento automatizado de control de asistencia de alumnos y padres de familia a clases, escuelas de familia, entre otros eventos pblicos, a diferencia de gran parte de los sistemas de gestin educativa especial expuestos en el Estado de Arte quienes prescinden de esta funcionalidad.

Si bien todos los sistemas revisados en el Estado de Arte se limitan al mantenimiento de los planes educativos individuales (IEP) y su cuantificacin, es ms coherente concebir la solucin como un medio nico centralizador del conocimiento especializado de los trastornos para los cuales el centro educativo ofrece terapias. Pensando en ello, la solucin incorpora el mantenimiento de informacin de trastornos y terapias bajo la categorizacin establecida en el DSMIV (estndar americano referente en centros de educacin especial de Latinoamrica) para la homologacin de conocimientos entre los centros y especialistas multidisciplinarios. En el primer caso presenta como caracterstica adicional la clasificacin de la severidad del trastorno en base a escalas as como el registro de institutos y clnicas especializadas en su tratamiento respectivo. La

34

presentacin del concepto de escalas asociadas a los trastornos es importante para la posterior determinacin y especificacin de las terapias.

Toda medicin del avance y progreso en el proceso educativo requiere de indicadores evaluadores de los objetivos a alcanzar por cada estudiante. La solucin tendr como funcionalidad la administracin de indicadores y objetivos educativos (evaluados escalarmente) para posteriormente ser asignados a actividades y tareas competentes a las terapias. Los objetivos son configurables por los especialistas a lo largo del tiempo.

Por su parte, la estructura de trabajo se basa en la definicin de actividades y tareas educativas. Toda actividad se compone de una o muchas tareas complementarias y vinculadas a una determinada habilidad a evaluar en el alumno. La solucin permitir la inclusin y administracin de estos conceptos sujetos a la adjudicacin de una terapia previamente creada. Las terapias, actividades y tareas cuentan con una duracin expresada en das para la posterior calendarizacin de actividades.

Se permitir el mantenimiento de programas educativos de los alumnos en el centro educativo. A diferencia de otras aplicaciones de monitoreo del desempeo de alumnos basadas en un nico conjunto de reglas, este sistema propone la individualizacin del seguimiento en funcin a programas educativos nicos por alumno y divididos en actividades y tareas. El programa vincula la informacin entre la terapia y alumno segn el trastorno y escala. Asimismo la administracin de dicho programa queda a cargo del especialista responsable del alumno indicado en la matrcula.

En algunos centros de educacin especial, a diferencia de los colegios e institutos, las familias reciben capacitaciones presenciales o virtuales (si la familia est ubicada geogrficamente lejos de la institucin) reforzando as lo aprendido por los alumnos en sus domicilios. Cada especialista podra decidir si tales merecen ser evaluadas o no. Para el cumplimiento de este alcance, ausente en todas las plataformas de gestin investigadas, se implementar la administracin en lnea de planes de tareas para tutores y padres de familia, constituyndose en un medio ms efectivo para la gestin.

35

Adems de los programas y planes de tareas, se brindarn dos nuevas funcionalidades afines a las labores pedaggicas del escenario educativo local an no cubiertas en el resto de plataformas. En el caso de los programas se facilitar el registro de eventos presentados durante su puesta en marcha, especificando adems del alumno y programa el cdigo de la actividad donde se present el suceso. Con este mecanismo es posible hacer el seguimiento y revisin en base al historial de eventos suscitados durante el proceso educativo. Y como apoyo a los especialistas y pensando en la digitalizacin de documentos en el centro educativo, los especialistas contarn con un repositorio de documentos para todo alumno y programa, con opciones de carga y descarga de archivos.

Todos los programas y planes de tareas son susceptibles de pasar por una evaluacin. Para este propsito la solucin permitir la calificacin de los programas y planes segn los objetivos e indicadores asignados a las actividades y tareas. Sin embargo, ofrece adems la evaluacin del desempeo de los especialistas por parte de los padres y tutores del alumno (alcance no cubierto explcitamente por los sistemas de informacin investigados). Este mecanismo permitir a la institucin identificar los aspectos pedaggicos a mejorar en el corto plazo.

Para la comunicacin entre los usuarios y la familia del alumno se incorporarn las funcionalidades de mensajera y solicitudes de entrevistas. En el primer caso, el usuario podr enviar o recibir mensajes de especialistas o de otras cuentas convirtindose de ese modo en una agenda semanal donde ambos entornos canalizarn sus observaciones y consultas. Los padres o tutores del alumno podrn efectuar solicitudes de entrevistas a los especialistas en una hora y fecha por tratar. Durante la creacin de una solicitud se validar si los tiempos propuestos para la entrevista estn sujetos al horario de atencin configurado por el especialista directamente y sin contar con una cuenta de administrador. Por otra parte, el especialista tendr libertad para aceptar o rechazar la solicitud. La planificacin y gestin de solicitudes de entrevistas entre padres, tutores y especialistas se adopta como un alcance nuevo en el proyecto a diferencia de otros sistemas.

En cuanto a la seguridad del sistema, se permitir el registro y actualizacin de datos de los usuarios especialistas as como de los usuarios externos, lase padres o tutores del alumno. Para ambos tipos de usuario se contar con la posibilidad de efectuar el cambio de contrasea en sus cuentas de usuario. Para las labores de

36

administracin de usuarios todas las cuentas estn asociadas a un perfil de usuario configurado con anterioridad sujeto a modificaciones en la configuracin de sus permisos a ciertos contenidos y pginas. Los niveles de acceso a las pginas sern descritos como de alcance global (acceso total), parcial (slo lectura) o restringido (sin autorizacin). La asignacin de perfiles a usuarios podr procesarse de forma individual o masiva. Del mismo modo se permitir la modificacin de un perfil de usuario previamente registrado, replicando posteriormente dichos cambios a todos los usuarios asociados a este perfil.

Adems de lo mencionado en prrafos previos, la solucin contar con las funciones de generacin de reportes. Los informes a ser tomados en cuenta comprenden tanto el reporte de alumnado, control de asistencias como los resultados de evaluaciones aplicadas a los especialistas junto con el informe de progresos y avances del alumno.

Para cumplir con todos los requerimientos y como prerrequisito al inicio de las fases de anlisis y diseo, es importante la evaluacin de la infraestructura tecnolgica para el proceso de construccin. Se examinar si la plataforma existente en los centros educativos soporta las actividades de desarrollo y pruebas de software, en funcin a los requerimientos recomendados de las herramientas de desarrollo.

Finalmente se proceder con las pruebas de conectividad de base de datos y de las funcionalidades del producto. Cumplidos estos procesos proseguir la implantacin del producto en las instalaciones del centro educativo. Este proyecto beneficiar a todo centro educativo especial pblico y privado y residir en un servidor con sistema operativo Windows (para propsitos de implantacin, este sistema operativo es requerido como servidor de aplicaciones Web) sin embargo el margen de beneficiados es ilimitado por tratarse de un producto Web accesible desde cualquier navegador y en cualquier equipo de cmputo dentro o fuera de la institucin educativa.

37

2. CAPTULO 2:

Anlisis

El desarrollo del captulo abarca la presentacin de conceptos vinculados a la metodologa de desarrollo de software aplicada junto con los requerimientos y restricciones identificados del producto. Continuando con el acpite de anlisis de la solucin se presentan las evaluaciones de viabilidad tcnica y econmica, la asignacin de funciones a los elementos del producto y la definicin del sistema.

2.1.

Definicin de la metodologa de solucin

A continuacin se presentan las dos metodologas candidatas para el desarrollo de la solucin. Posteriormente se exponen las justificaciones respecto a la eleccin de una de estas propuestas.

2.1.1. Rational Unified Process (RUP) RUP es una metodologa de desarrollo de software basada en un enfoque iterativo con una adecuada adaptacin de los cambios durante el proceso de desarrollo, sumada a la correcta gestin de requerimientos incorporando al diseo de software el lenguaje UML, definido como un sistema de modelamiento visual para la

38

representacin grfica de casos de uso, clases de anlisis, componentes de software entre otros. Un elemento clave en la concepcin de RUP es el aseguramiento de la calidad del software.

Los proyectos se organizan en fases y cada una demanda un conjunto de iteraciones, en ambas se van emitiendo entregables y prototipos de software con miras a la culminacin del producto. Este enfoque trae como beneficios la atenuacin de riesgos desde ciclos tempranos del proceso alineando las necesidades de los usuarios a las funcionalidades del producto. A su vez promueve una correcta administracin del cambio y la configuracin.

Esta metodologa engloba una serie de entregables o artifacts del ciclo de desarrollo del producto, constituyndose as como el activo ms importante despus del producto final, pues en stos se documentan los alcances tcnicos y funcionales definitivos del producto desarrollado en el presente proyecto de fin de carrera.

Pese a sus prestaciones, RUP enfrenta crticas por cuando prioriza el avance documentario y la elaboracin de entregables como prioritarios para el software (en ciertos casos extensos y complejos en su administracin) relegando otros factores tales como la modalidad de trabajo durante la codificacin del producto. Sumado a lo anterior, la adopcin de RUP como metodologa conlleva al establecimiento de flujos de trabajo y roles en el equipo de proyecto la cual, de no contar con una eficiente gestin del equipo de proyecto, recaera en una alta jerarquizacin de funciones aumentando la burocracia en el trabajo. 2.1.2. Agile Unified Process (AUP)

AUP es una metodologa de desarrollo gil heredera de otros paradigmas como la programacin extrema (XP) y RUP. Esta metodologa consta de principios y prcticas influyentes en la construccin del software en armona con la documentacin esencial de entregables especficos para el entendimiento de la solucin. Entre sus objetivos destaca la reduccin del costo del cambio en el proyecto en base a procedimientos iterativos (caracterstica propia de RUP) donde la codificacin y pruebas del software se llevan a cabo paralelamente (segn XP). Por experiencia de proyectos anteriores se recomienda la aplicacin de esta

39

metodologa en equipos con menos de diez integrantes aunque cuenta con casos de xito en proyectos de mayor envergadura (Ambysoft 2005).

Adems de la estructura metodolgica fijada por RUP (como el desarrollo de producto por iteraciones y presentacin de prototipos en modo incremental), AUP introduce propuestas como la programacin por pares (todos los desarrolladores conocen el cdigo implementado por todos), la gestin de requerimientos por niveles de prioridad (toda solicitud de cambio es analizada y/o ejecutada durante la construccin del software), independencia entre herramientas para la concepcin del producto y el refactoring o la modificacin del cdigo del programa sin alterar su comportamiento original mejorando en su estructura, performance y diseo. Asimismo propone el desarrollo dirigido por pruebas (TDD) a partir de un concepto denominado unidad de prueba (sincronizando tanto la construccin como las pruebas en el prototipo) de carcter reutilizable.

Pese a su evolucin y demanda como metodologa de desarrollo en la ltima dcada, por sus semejanzas con el paradigma XP enfrenta crticas dado el enfoque orientado a la optimizacin en la programacin en lugar de la documentacin del producto as como por la no profundizacin en mbitos como la gestin de costo. A su vez, XP no provee plantillas de proyecto para facilitar la adaptacin de esta metodologa: particularmente en proyectos con mayor nmero de programadores, propuestas como la programacin por pares terminan siendo una labor crtica. 2.1.3. Eleccin de la metodologa

La metodologa de desarrollo seleccionada para el presente proyecto es Agile Unified Process por las razones expuestas a continuacin: El enfoque AUP ofrece un amplio marco de buenas prcticas en la fase de construccin de software en bsqueda de la optimizacin promoviendo medidas como la ejecucin de pruebas en paralelo con la programacin as como el manejo de unidades de prueba. Del mismo modo por sus principios derivados de RUP, se constituye como una de las metodologas ms aplicadas para el anlisis, implementacin y documentacin de sistemas orientados a objetos. AUP cuenta con actividades de carcter iterativo e incremental y tomando en cuenta las propuestas del paradigma XP (como el tratamiento de solicitudes de

40

cambios del producto en paralelo con la codificacin) favorecen al logro de un producto software en menor tiempo y bajo una comunicacin horizontal en el tratamiento de cambios (el equipo de desarrolladores reunido directamente con el cliente para conocer sus necesidades) en lugar de una comunicacin vertical (la solicitud de cambio transmitida a travs de una serie de revisiones, usuarios y analistas). Como RUP prioriza a un grado mayor la documentacin se opta por un paradigma de trabajo con entregables esenciales y especficos para el entendimiento de la solucin final. Finalmente por tratarse de un equipo de proyecto conformado nicamente por el tesista como responsable de las labores de anlisis, diseo e implementacin, el escenario resulta propicio para esta metodologa considerando su aplicacin en entornos organizacionales no masivos o en equipos con una estructura jerrquica reducida. Con referencia a la gestin de costos, este alcance ser delegado a la gestin del proyecto dentro del marco de buenas prcticas del PMBOK. 2.1.3.1. Fase de Iniciacin

El objetivo en esta fase es asimilar los requerimientos esperados de la solucin y plasmarlos en la definicin y especificacin de los casos de uso. Asimismo, como apoyo a los procesos de gestin, se presenta la programacin definitiva de las actividades y tareas conforme a la planificacin del proyecto (diagrama de Gantt y WBS) junto con la relacin de riesgos identificados. Los documentos como el catlogo de requerimientos, las especificaciones de requisitos de software, el cronograma del proyecto, la lista de riesgos, el plan de proyecto y enunciado de alcance se encuentran en observacin durante esta fase. 2.1.3.2. Fase de Elaboracin

En esta fase el objetivo es construir y probar la arquitectura descrita en el documento de arquitectura del sistema.

41

Entre los entregables requeridos durante esta fase conviene citar el documento de anlisis (junto con el diagrama de clases de anlisis) y el documento de diseo (acompaado del diagrama de clases de diseo). Otras actividades involucradas en esta fase son: Identificacin de las necesidades de hardware y software para el proyecto. Elaboracin del documento de arquitectura del sistema. Elaboracin del documento de diseo de base de datos. Elaboracin de estndares de programacin e interfaz grfica. Establecimiento de las iteraciones as como de las especificaciones del plan de pruebas de software. 2.1.3.3. Fase de Construccin

Esta fase comprende las labores de codificacin y pruebas del producto a partir de las pautas definidas en los documentos de anlisis y diseo (para mayor informacin sobre el desarrollo de pruebas del producto revisar el captulo 4).

Se establecieron siete iteraciones identificadas en la tabla 2.1:

Tabla 2.1 Plan de Iteraciones del Proyecto

N de iteracin I

Descripcin Programacin y pruebas de las funcionalidades del mdulo Seguridad.

II

Programacin y pruebas de las funcionalidades del mdulo Comunicaciones.

III

Programacin y pruebas de las funcionalidades del mdulo Alumnos.

IV

Programacin y pruebas de las funcionalidades del mdulo Organizacin.

Programacin y pruebas de las funcionalidades del mdulo Planeamiento.

VI

Programacin y pruebas de las funcionalidades del mdulo Evaluaciones.

VII

Programacin y pruebas de las funcionalidades del mdulo Reportes.

42

2.1.3.4.

Fase de Transicin

Esta fase tiene como propsito la puesta del sistema en produccin (afinando las pruebas integrales) junto a la capacitacin de los usuarios y conversiones de sistemas en caso existieran. A su vez se completar la documentacin final del sistema. Las actividades involucradas son: Desarrollo de pruebas unitarias y pruebas de integracin Cierre de documentacin tcnica

2.2.

Identificacin de requerimientos

Los requerimientos funcionales y no funcionales de las tablas 2.2 y 2.5 respectivamente fueron recopilados durante las entrevistas con consultores, especialistas y docentes en educacin especial. Adicionalmente se incluyeron una serie de funcionalidades existentes en los sistemas mencionados en el Estado de Arte (ver Captulo 1). En las tablas 2.3 y 2.4 figuran las escalas de valoracin de dificultad y prioridad respectivamente.

2.2.1. Requerimientos funcionales

La presentacin de estos requerimientos fue separada por cada mdulo identificado en la tabla 2.2.
Tabla 2.2 Requerimientos funcionales del sistema Mdulo Seguridad N Descripcin El sistema permitir el mantenimiento de los usuarios internos (especialistas) y externos 1 (padres/tutores de familia) al sistema. El sistema permitir el mantenimiento de los perfiles de usuario y accesos al sistema. El perfil especifica las acciones permitidas y restringidas durante la navegacin por las pginas, para uno o ms usuarios. Los accesos Funcional 2 2 Tipo Funcional Dif. 3 Pri. 2

considerados por cada pgina son de slo lectura, 2 acceso completo o ninguno. El sistema permitir la asignacin del perfil de 3 usuario a uno o varios usuarios. Funcional 1 1

43

El sistema permitir la personalizacin de accesos al sistema para una cuenta de usuario. El sistema permitir cambiar la configuracin de accesos otorgados previamente a un usuario a travs de un perfil, a manera de personalizar sus 4 accesos para eventualidades laborales. El sistema posibilitar al usuario el cambio de su contrasea de acceso al sistema. Desde el panel de mantenimiento de datos el usuario podr cambiar la contrasea en caso lo 5 requiera. Mdulo Comunicaciones N Descripcin El sistema permitir el envo y recepcin de mensajes y comunicados entre los usuarios. Bajo este mecanismo, los especialistas y las familias tendrn a su disposicin una bitcora con las observaciones y consultas efectuadas entre ambas partes. A su vez permite el envo de noticias sobre eventos pblicos de inters a toda la 1 comunidad educativa. El sistema permitir a los especialistas el mantenimiento de horarios de atencin a 2 padres y tutores de familia. El sistema permitir a los usuarios externos el mantenimiento de solicitudes de entrevista con los especialistas. Previo a su creacin se validar si el especialista buscado cuenta con disponibilidad de atencin 3 para la fecha y hora consignada. El sistema posibilitar a los especialistas la gestin estados. De este modo, el especialista podr aceptar o 4 rechazar una solicitud entrante. Mdulo Alumnos N Descripcin El sistema permitir registrar y actualizar informacin del alumno especial. 1 El sistema permitir registrar informacin general de solicitudes de entrevista por

Funcional

Funcional

Tipo Funcional

Dif. 2

Pri. 1

Funcional

Funcional

Funcional

Tipo Funcional

Dif. 3

Pri. 1

44

del alumno, tanto datos personales propios como los del padre de familia y/o apoderado. El sistema permitir el mantenimiento de hojas 2 de asistencia para alumnos y padres. El sistema permitir registrar y actualizar el control de asistencia a clases del alumno 3 especial. El sistema permitir registrar y actualizar el control de asistencia a reuniones de padres de 4 familia. Mdulo Organizacin N Descripcin El sistema permitir el mantenimiento de la informacin de trastornos. Posibilitar el registro y actualizacin de las enfermedades incluyendo los criterios Tipo Funcional Dif. 3 Pri. 2 Funcional 2 1 Funcional 2 1 Funcional 2 1

clasificatorios del DSM-IV. Adems contar con un directorio de instituciones especializadas por 1 cada trastorno. El sistema permitir el mantenimiento de terapias por trastorno. La terapia rene las actividades competentes para el tratamiento del trastorno del alumno y bajo una 2 escala de severidad. El sistema permitir el mantenimiento de 3 actividades clasificadas por terapias. El sistema permitir el mantenimiento de tareas 4 asignadas por actividad. El sistema permitir el mantenimiento de indicadores de evaluacin. Los indicadores cuantificarn el avance de un 5 objetivo. El sistema permitir el mantenimiento de objetivos. Los objetivos consisten en logros puntuales esperados en los alumnos segn la actividad o 6 tarea pautada. El sistema permitir asociar actividades por 7 cada terapia. 8 El sistema permitir asociar tareas por Funcional 1 1 Funcional 2 1 Funcional 3 2 Funcional 3 2 Funcional 1 1 Funcional 1 1 Funcional 2 1

45

actividad de acuerdo con la terapia. El sistema posibilitar la asignacin de Funcional 2 1

objetivos tanto a actividades como tareas. De este modo ambos conceptos podrn ser 9 evaluados por los especialistas. Mdulo Planeamiento N Descripcin El sistema permitir el mantenimiento de programas educativos de los alumnos. El programa englobar las actividades y tareas segn la terapia adecuada y escala de severidad 1 del trastorno padecido por el alumno. El sistema permitir incorporar actividades al programa educativo procedentes de otras terapias, 2 tomando como criterio de filtro la edad del alumno. El sistema permitir modificar la duracin de las 3 tareas en el programa educativo. El sistema permitir el mantenimiento del Plan de tareas dirigido a los padres y/o tutores del 4 alumno. El sistema permitir el mantenimiento de eventos y observaciones ocurridas durante la ejecucin del programa educativo, por cada 5 actividad tratada. El sistema contar con un repositorio de archivos, en diferentes formatos, para uso de 6 la comunidad educativa del centro. El sistema posibilitar el mantenimiento de documentos clasificados por programa Funcional 2 2 Funcional 2 2 Funcional 3 1 Funcional 3 1 Funcional 1 1 Funcional 2 1 Tipo Funcional Dif. 1 Pri. 1

educativo y actividad. Los documentos no debern superar los 8MB para 7 su carga y descarga. Mdulo Evaluaciones N Descripcin El sistema posibilitar la evaluacin de los programas educativos del alumno. La calificacin ser manejada al nivel de las tareas y actividades. Cada mbito tomar como criterios los objetivos e indicadores de medicin Tipo Funcional Dif. 2 Pri. 1

1 respectivos.

46

El sistema posibilitar la evaluacin de los planes de tareas del alumno. La calificacin ser manejada al nivel de las tareas y tomar como criterios los objetivos e indicadores 2 de medicin respectivos. El sistema permitir el mantenimiento de

Funcional

Funcional

3 evaluaciones a los especialistas. El sistema permitir a los usuarios externos evaluar la labor educativa de los especialistas 4 del centro educativo. Mdulo Reportes N 1 alumnos. El sistema emitir reportes de asistencia de los 2 tutores y/o padres de familia. El sistema generar el informe de avances y progresos de los alumnos con las calificaciones 3 obtenidas. El sistema generar el reporte de evaluacin 4 aplicada a los especialistas. La emisin de reportes tendr como formato nico 5 en PDF (Portable Document Format). Tabla 2.3 Criterio de Dificultad
Dif: Dificultad Valor Descripcin Alta Media Baja

Funcional

Descripcin El sistema emitir reportes de asistencia de

Tipo Funcional

Dif. 2

Pri. 3

Funcional

Funcional

Funcional

Funcional

Tabla 2.4 Criterio de Prioridad

Pri: Prioridad/Importancia Valor 1 2 3 Descripcin Alta Media Baja

1 2 3

2.2.2. Requerimientos no funcionales La tabla 2.5 agrupa los requerimientos a nivel de arquitectura y tecnologas.
N Tabla 2.5 Requerimientos no funcionales del sistema Descripcin Tipo Dif. El usuario interactuar con el sistema utilizando el No funcional 1 teclado y mouse. El sistema ser desarrollado con una interfaz No funcional 2 grfica de usuario basada en controles Web. 3 El sistema estar disponible va Internet las 24 No funcional 2 2 2 2 3 Pri. 2

47

horas del da. El sistema ser accesible desde cualquier equipo No funcional de trabajo con navegadores Web Microsoft 2 2

Internet Explorer (6.0 o superior) Google Chrome 4 (17.0 o superior) y Mozilla Firefox (2.0 o superior). El sistema se ejecutar sobre un servidor de No funcional aplicaciones Web con sistema operativo Windows 5 Server 2008 en adelante. El sistema trabajar con el administrador de base No funcional 6 de datos PostgreSQL. El sistema guardar en base de datos los registros No funcional de errores en tiempo de ejecucin producidos 7 durante todas las sesiones activas. El sistema contar con manuales de usuario para No funcional 8 su entendimiento y capacitacin en la herramienta. El protocolo SMTP ser utilizado para el envo de No funcional 9 correos al administrador. El sistema comunicar al administrador va correo No funcional electrnico los errores presentados durante las 10 sesiones de los usuarios. 3 3 2 2 2 2 3 2 2 2 3 1

2.2.3. Consideraciones sobre el sistema Como alcance de la propuesta quedan excluidas las automatizaciones de los procesos en contabilidad, logstica, gestin de planillas y recursos humanos de las instituciones educativas. En contraparte, se respetarn las siguientes restricciones: Validacin: La informacin ingresada por teclado es verificada como medida preventiva ante posibles errores en el proceso. Seguridad: Acceso al sistema a personas mediante cuentas de usuario y contrasea. En funcin a los perfiles y accesos se controlar el nivel de visibilidad de la informacin. Escalabilidad: La arquitectura posibilitar la incorporacin de nuevas funcionalidades y mdulos flexiblemente sin procedimientos drsticos para el desarrollador. Usabilidad: Para la familiarizacin del usuario con el software se requiere una interfaz grfica ligera e intuitiva sumada a una correcta emisin de avisos de error y advertencia. El usuario iniciar todas las operaciones requeridas. Performance: Garantiza un tiempo de acceso no mayor a siete (7) segundos.

48

Como consecuencia de las entrevistas efectuadas y segn los requerimientos analizados a partir de la lista de exigencias, se presenta a continuacin la descripcin de los actores participantes del sistema (ver figura 2.1): Usuario: Toda persona con una cuenta y accesos autorizados al sistema. Administrador: Realiza funciones tales como administrar cuentas, perfiles de usuario y monitorear el funcionamiento del sistema. La notificacin de errores a presentarse con la plataforma es competencia exclusiva de este actor. Usuario Especialista: Cumple el rol de dirigir y llevar a cabo los programas educativos as como ejecutar los procesos de mantenimiento de trastornos, terapias, actividades y tareas. Usuario Externo/Familiar: Representa al padre o tutor del alumno

perteneciente al centro educativo especial.

Figura 2.1 Actores del sistema

2.3.

Anlisis de la solucin

Se presenta a continuacin el trabajo llevado a cabo durante el anlisis de la solucin tomando como base las recomendaciones establecidas por Roger Pressman (Pressman 2002) desde la relacin de funcionalidades deseadas e identificadas por los usuarios de dos centros de educacin especial, la viabilidad tcnica y econmica, el anlisis costo beneficio del proyecto, la asignacin de funciones a los elementos del sistema hasta el establecimiento de restricciones en costo y tiempo y la definicin del producto.

49

2.3.1. Identificacin de las necesidades del cliente Como principales necesidades establecidas por los docentes y especialistas de dos centros de educacin especial se obtuvieron los siguientes alcances: Disponibilidad de informacin del avance en los programas educativos de los alumnos tanto dentro como fuera de la institucin y en cualquier momento. Acceso a tiempo completo de la informacin y documentacin pedaggica de trastornos, terapias, actividades y tareas supervisados por el centro educativo durante el periodo anual. Establecimiento de un mecanismo de verificacin de la asistencia y tardanza de los alumnos. Planificacin de la duracin de cada actividad y tarea comprendida en el programa. Registro de incidencias durante las actividades dadas en el programa educativo del alumno. Evaluacin de los programas educativos del alumno. Evaluacin del desempeo de los docentes y especialistas del centro.

Estas necesidades indicadas quedan cubiertas por los requerimientos del sistema dada la similitud entre las expectativas de usuarios con las funcionalidades del nuevo sistema.

A partir de la lista de exigencias y habiendo identificado las necesidades de los usuarios es factible construir el diagrama de casos de uso y actores.

La especificacin de los casos de usos mostrados en la figura 2.2 se encuentra en el Anexo F: Especificacin de requisitos de software. La propuesta de solucin contar con siete mdulos funcionales destinados a solucionar los problemas en gestin educativa descritos. Para mayores precisiones revisar el Anexo G: Documento de anlisis del sistema.

50

Figura 2.2 Diagramas de casos de uso del sistema

2.3.2. Viabilidad tcnica y econmica

Para la viabilidad tcnica se presentan las restricciones en hardware y software con miras a la construccin de la solucin planteada, as como su disponibilidad. Con la salvedad del software de ofimtica para labores documentarias, las restricciones tcnicas identificadas son las siguientes:

(1) datos. (2)

Disponibilidad del equipo de cmputo/servidor para albergar a la base de

Disponibilidad del equipo de cmputo/servidor para su utilizacin como

servidor de aplicaciones Web. (3) Disponibilidad del equipo de cmputo para las labores de anlisis, diseo,

construccin y pruebas.

51

(4)

Herramientas CASE de libre distribucin para el modelamiento UML y

construccin de la base de datos de la solucin. (5) Herramienta IDE para la construccin de la interfaz grfica y codificacin de

las funcionalidades bajo la plataforma ASP.NET. (6) Sistema administrador de base de datos de libre distribucin con capacidad

para soportar mltiples conexiones. (7) Libreras DLL con capacidad de transmisin de datos entre aplicaciones en

.NET y servidor de base de datos PostgreSQL. A su vez, compatible con las operaciones de persistencia de datos en ADO.NET Entity Framework (EF4). (8) El lenguaje de programacin y sus caractersticas para la construccin bajo

el paradigma orientado a objetos. (9) Disponibilidad de un servidor Web ASP.NET para labores de

implementacin.

Este proyecto es tcnicamente viable porque el tesista cuenta con todos los requisitos citados. Bajo una adecuada planificacin de recursos y con miras a maximizar las capacidades logsticas existentes, se adoptarn las siguientes medidas: Los requerimientos (1) y (2) quedan cubiertos empleando una computadora con procesador Intel de sptima generacin y memoria RAM de 2GB, dadas las exigencias del servidor de base de datos y sistema operativo. El requerimiento (3) est constituido por un equipo porttil Core Duo de 2GHz y 3GB de memoria RAM ofreciendo as un rendimiento superior para las fases de anlisis, diseo, desarrollo y pruebas por parte del tesista. Esta disposicin obedece estrictamente a razones de simplificacin de recursos, en contraparte con entornos de trabajo reales donde s se exige una clara separacin entre servidores. Para el requisito (4) existen productos como Visual Paradigm CE, ArgoUML y StarUML sujetos a las exigencias tcnicas propias de la documentacin con RUP y adems son de libre distribucin. En el proyecto se har uso del software Visual Paradigm CE. Los requerimientos (5) y (6) se encuentran cubiertos con la incorporacin de las herramientas IDE Microsoft Visual Web Developer 2010 Express (una versin gratuita y liviana para el desarrollo Web con ASP.NET) y del administrador de base de datos PostgreSQL.

52

 Npgsql es un proveedor de datos gratuito para bases de datos PostgreSQL en la plataforma Microsoft .NET Framework. Esta librera DLL a partir de su versin 2.0 soporta operaciones con ADO.NET Entity Framework (EF4). Se elige este manejador para el cumplimiento del requisito (7). La eleccin del lenguaje C# y del servidor Web IIS Express comprenden los requerimientos (8) y (9). En cuanto a la viabilidad econmica, tomando como punto de partida los tems tcnicos citados para la implementacin, se establecen los siguientes

considerandos como parte del costo en el proyecto: Los requisitos a nivel de hardware (1), (2) y (3) se encuentran excluidos asumiendo su aprovisionamiento bajo la responsabilidad del tesista. Las herramientas CASE para el modelamiento UML y de la base de datos (4) permanecen libres de costo. El IDE Microsoft Visual Web Developer Express, a emplear para la construccin (5), se encuentra a disposicin desde Internet y libre de costo para el programador. En cuanto al requisito (6) referente al sistema administrador de base de datos, se trabajar con el manejador PostgreSQL, cuyo uso no requiere del pago por una licencia.

La tabla 2.6 muestra el costo asumido por concepto del personal (segn los roles y funciones) durante la realizacin del proyecto. Del mismo modo la tabla 2.7 resume la inversin realizada en cada fase de proyecto con un horizonte de once (11) meses, expresada en nuevos soles.
Tabla 2.6 Costo de RR.HH. del proyecto

Rol Jefe de Proyecto Analista Funcional Analista Programador Analista de Pruebas Fase Iniciacin Responsable JP

Abrev. Cant. JP AF AP AQ 1 1 1 1

Costo/Hora (S/.) 20.00 12.00 10.00 9.00 Gasto (S/.) 88.50

Tabla 2.7 Costo referencial del proyecto

Horas estimadas 20

Costo tems (S/.) 400.00 Luz

53

Elaboracin (Anl./Diseo)

AF JP AF

50 10 320 648 250 60 90

600.00 Internet 200.00 Telf. mvil 3840.00 Materiales de oficina 6480.00 Otros gastos

80.00 60.00 50.00 100.00

Construccin (Impl./Pruebas) Transicin

AP AQ AP AF TOTAL

2250.00 TOTAL (MES) 378.50 TOTAL 600.00 4163.50 1080.00 15450.00 MONTO FINAL 19613.50

2.3.3. Anlisis Costo Beneficio

En este anlisis se presentan las razones y criterios tomados como justificacin para el desarrollo del proyecto y la inversin econmica, as como el grado de contribucin esperado en los procesos de gestin educativa ms importantes en centros de educacin especial tras su implantacin.

Una vez expuestos los detalles del costo y gastos a incurrir en el proyecto, arroja como conclusin la no existencia de una fuerte inversin en hardware y software gracias al empleo de herramientas informticas de cdigo abierto como de licencia gratuita y bajo la condicin de aprovisionamiento del hardware por parte del tesista. En cambio, el ntegro de la inversin se reserva para la cobertura en costos de logstica y personal del proyecto (un nico ejecutor, el tesista, en diferentes perfiles especializados). Si se introduce en este anlisis la curva de experiencia profesional en proyectos acadmicos y laborales (as como en el uso de herramientas CASE e IDE) la reduccin del margen de horas en cada perfil es altamente probable. El costo en funcin al tiempo (llevando este tratamiento a una escala horaria) queda sustentado pues las estimaciones elaboradas se alinean a las actividades fijadas en el cronograma de proyecto.

Por otra parte, conviene precisar las ventajas y beneficios ofrecidos por la solucin. El propsito como se recalca en el Captulo 1 es optimizar los procesos de gestin educativa en los centros de educacin especial, comprometiendo la

descentralizacin de la labor educativa. Para los especialistas de estas instituciones la actualizacin constante de la informacin del programa educativo as como la evaluacin y registro del seguimiento a los alumnos favorecer a la mejora del currculo brindando tcnicas y terapias eficaces para futuros casos; a su vez permite incorporar mecanismos de evaluacin a distancia para las familias.

54

Institucionalmente, contribuir con la centralizacin de todo el conocimiento albergado en medios fsicos o digitales (gracias al repositorio documentario en lnea) a disposicin de la comunidad educativa en general desde un dispositivo fijo o mvil con conexin a Internet. Bajo esta ptica, otro grupo de beneficiarios sern los padres y tutores de familia por cuanto podrn visualizar las observaciones y orientaciones en lnea de los especialistas, realizar consultas sobre el proceso llegando incluso a evaluar la labor educativa brindada por la institucin. Las funcionalidades citadas cuentan con las medidas en seguridad informtica propias de un sistema Web estndar. Por ltimo la masificacin de soluciones de gestin educativa augura un futuro positivo para la integracin tecnolgica de las instituciones en educacin especial con un proyecto informtico pionero en el mbito de la gestin de la educacin especial nacional.

En ese sentido, tras el anlisis efectuado, la solucin presenta mayores beneficios a futuro para todos los participantes en educacin y a un costo razonable por invertir en las instituciones. En otras palabras, es viable dadas las ventajas y mejoras ofrecidas en la automatizacin de los procesos de las comunidades educativas.

2.3.4. Asignacin de funciones a hardware y software

Las funciones asignadas al hardware durante el proyecto son: Como servidor Web, cumplir con el almacenamiento fsico de la aplicacin Web. Como servidor de base de datos, cumplir con el almacenamiento fsico del servidor de base de datos. Albergar aplicaciones ofimticas y herramientas CASE e IDE requeridas para labores de anlisis, diseo, construccin y pruebas. Las funciones asignadas al software durante el proyecto son: Asistir al tesista en las actividades de diagramacin, modelamiento y documentacin durante las fases de anlisis y diseo. Permitir la codificacin ptima y eficiente de los mdulos, componentes y funcionalidades de la solucin. Permitir la construccin de la interfaz grfica de la aplicacin va cdigo HTML o por arrastre de elementos grficos (drag & drop).

55

En cuanto al producto software, como principales funciones comprometidas se tienen: Interactuar con los servidores y el computador cliente desde el cual se conecta el usuario. Cumplir con la ejecucin de los procesos de gestin educativa obtenidos a partir de la lista de exigencias de la solucin. Las funciones asignadas a nivel de base de datos a lo largo del proyecto son: Almacenar una base de datos nica para las operaciones de lectura y escritura. Permitir el almacenamiento y recuperacin de la informacin necesaria. Permitir la realizacin de copias de seguridad de la informacin albergada en la base de datos. De ser necesario, admitir las configuraciones de conexin con la base de datos realizadas dentro o fuera del motor de base de datos. Las funciones asignadas a los usuarios durante el transcurso del proyecto son: Colaborar con el levantamiento de informacin de los requerimientos. Ingresar los datos apropiados de acuerdo con los propsitos de cada mdulo incorporado a la solucin. Cumplir con las pruebas de software necesarias Participar activamente en las reuniones de coordinacin e implantacin del sistema. Las funciones asignadas al equipo (tesista) a lo largo del proyecto son: Dirigir, coordinar y ejecutar las actividades tcnicas y funcionales. Segn el perfil del especialista (analista, programador, entre otros) cumplir con las funciones competentes. 2.3.5. Restricciones de costo y tiempo

Como el tesista cuenta con los equipos descritos en el acpite 2.3.2 y nicamente se incurren en gastos logsticos y en el personal del proyecto, este costo final no deber extenderse en ms del 15% respecto al costo estimado original, frente a

56

futuras adendas. Por su parte, el cronograma de entregas de tesis represent para el proyecto una restriccin en cuanto a tiempos, ocasionando retrasos debido a la obligatoriedad en el cumplimiento de las correcciones solicitadas en los entregables por el asesor. Debido a los compromisos profesionales del tesista, la implementacin del sistema se posterg por un espacio de dos (02) aos, para posteriormente retomar estas funciones, invirtiendo adicionalmente un total de quince (15) meses para su cumplimiento, con una dedicacin de tres (03) das por semana y nueve (09) horas de trabajo por cada da. 2.3.6. Definicin del sistema Se presenta la definicin del sistema a partir del diagrama de clases de anlisis involucrando a las entidades principales en el modelamiento del escenario de negocio. Este anlisis favorecer al establecimiento y definicin de la arquitectura final junto con las clases de diseo necesarias para su construccin. La solucin cubre los requerimientos revisado en la seccin 2.2 a travs de siete paquetes representados en el diagrama de paquetes (ver figura 2.3).

Figura 2.3 Diagrama de paquetes del sistema

2.3.6.1.

Paquete Seguridad

Este paquete rene las funcionalidades de administracin de usuarios (clases Usuario, UsrFamiliar y UsrEspecialista) y perfiles (clase Perfil), asignacin de perfiles a uno o varios usuarios, as como la modificacin de contraseas a las cuentas de usuario y personalizacin de accesos a las pginas desde las clases Mdulo y Accin. Las clases asociadas se muestran en la figura 2.4.

57

Figura 2.4 Diagrama de clases de anlisis Mdulo Seguridad

2.3.6.2.

Paquete Alumnos

Este paquete rene las funcionalidades de gestin de informacin de alumnos (clase Alumno) y la toma de asistencia a las sesiones y eventos (clases HojaAsistencia y TipoHojaAsistencia). La clase Alumno es responsable de la integracin con el mdulo Seguridad en las operaciones de asignacin de especialistas (clases TurnoAlumno, NivelEducativo y UsrEspecialista) y tutores de familia (clases UsrFamiliar) en el sistema. Las clases asociadas se muestran en la figura 2.5.

Figura 2.5 Diagrama de clases de anlisis Mdulo Alumnos

2.3.6.3.

Paquete Comunicaciones

Este paquete permite el envo y recepcin de mensajes (clase MensajeUsuario) y mantenimiento de solicitudes de entrevista con especialistas (clase

SolicitudEntrevista). Los especialistas podrn planificar sus horarios de atencin para un determinado rango de fechas y horas (clase HorarioAtencion) y podrn aceptar o denegar las solicitudes de entrevistas. La representacin grfica de este paquete se encuentra en la figura 2.6.

58

Figura 2.6 Diagrama de clases de anlisis Mdulo Comunicaciones

2.3.6.4.

Paquete Organizacin

Este paquete cubre las funcionalidades de mantenimiento de informacin de trastornos, actividades y tareas as como la asignacin de terapias a un trastorno. La clase Terapia destaca en este paquete pues su existencia depende de la relacin entre un trastorno con una severidad especfica (clases Trastorno y EscalaTrastorno) para la cual se disea un tratamiento (compuesto por las clases Actividad y Tarea). La evaluacin de actividades y tareas del programa educativo est en funcin a un determinado conjunto de objetivos (clase Objetivo) junto a sus indicadores (clase Indicador). Se muestra a continuacin en la figura 2.7.

Figura 2.7 Diagrama de clases de anlisis Mdulo Organizacin

2.3.6.5.

Paquete Planeamiento

Este paquete realiza el mantenimiento de programas educativos de los alumnos (clase Programa) con la posibilidad de incorporar procedimientos de otras terapias.

59

Administra un historial para el registro de eventos (clases EventoProcesoHistorial y EventoProceso) y rene las funciones de gestin de documentos (clase Documento) para especialistas y usuarios. Finalmente realiza el mantenimiento de planes de tareas. Las clases asociadas se muestran en la figura 2.8.

Figura 2.8 Diagrama de clases de anlisis Mdulo Planeamiento

2.3.6.6.

Paquete Evaluaciones

Este paquete rene las funcionalidades de evaluacin de tareas y actividades de los programas y planes de tareas (clase Calificacin). Adicionalmente permite el mantenimiento y toma de evaluaciones a los especialistas por parte de los padres y tutores del alumno (clases EvaluacionEspecialista y LineaEvaluacion) como se aprecia en la figura 2.9.

Figura 2.9 Diagrama de clases de anlisis Mdulo Evaluaciones

2.3.6.7.

Paquete Reportes

Este paquete cumple con emitir informes de asistencia, avances y progresos de los alumnos y los resultados de las evaluaciones a los especialistas.

60

En el Anexo G: Documento de Anlisis se describen con mayor detalle todas estas clases obtenidas, una vez revisados los casos de uso y el catlogo de requerimientos.

61

3. CAPTULO 3:

Diseo

En este captulo se describe el diseo de la solucin propuesta. La primera parte comprende el diseo en alto nivel de la arquitectura justificando la eleccin de un patrn arquitectnico. Respecto a la interfaz grfica, se mencionan los patrones y estndares adoptados para uniformizar el aspecto visual y la interaccin con el usuario.

3.1.

Arquitectura de la solucin

En esta seccin se explica el diseo a alto nivel y los paradigmas arquitectnicos evaluados para posteriormente presentar la arquitectura final. Para mayores referencias, revisar el Anexo H: Documento de diseo del sistema y Anexo I: Documento de arquitectura del sistema.

3.1.1. Representacin de la arquitectura

De acuerdo con captulos anteriores la arquitectura est orientada a entornos Web. Bajo este diseo las tareas se ejecutan por el lado del servidor, evitando delegar tales responsabilidades hacia las mquinas clientes desde sus navegadores.

62

Asimismo asegura la disponibilidad a tiempo completo y desde un equipo fijo o mvil con conexin a Internet. Es as como el diseo debe garantizar un ptimo aprovechamiento de las capacidades propias de los sistemas Web satisfaciendo adecuadamente los requisitos no funcionales del producto. Entre las fortalezas exigidas a la arquitectura se encuentran: La arquitectura respetar el paradigma de programacin orientado a objetos. Esta caracterstica si bien depende del lenguaje de programacin utilizado, la propuesta de diseo debe asegurar la manipulacin de los datos y operaciones de manera encapsulada a travs de clases y objetos interrelacionados entre s por invocaciones a los mtodos respectivos. El manejo de cambios en el producto se logra modificando las caractersticas de un nmero determinado de componentes sin comprometer el funcionamiento del resto de mdulos. Para la lgica de negocio la arquitectura trabajar bajo el patrn Modelo de Dominio (Microsoft 2009). Este patrn consta de un conjunto de objetos de negocio representando las entidades en un dominio y sus relaciones entre ellos. El modelo representa en forma abstracta el negocio real encapsulando las reglas de negocio y recreando as un flujo de trabajo habitual. Bajo este patrn no se tiene conocimiento del mecanismo de persistencia de los datos, delegando esta responsabilidad a otro mbito. La arquitectura, para el manejo de la capa de datos, adoptar el patrn de Repositorio. Un repositorio encapsula un conjunto de objetos persistidos en una base de datos junto con sus operaciones de lectura y escritura. Este esquema provee una visin ms orientada a objetos en la capa de persistencia logrando dos metas: brindar una clara separacin y dependencia en un solo sentido entre el modelo de dominio y el mapeo de datos colocando una fachada sobre el nivel de persistencia, eximiendo as a la capa de lgica de negocio de la responsabilidad del funcionamiento del mecanismo de persistencia de datos (Microsoft 2007). 3.1.2. Evaluacin

En las siguientes secciones se describen dos tendencias arquitectnicas candidatas perfectamente aplicables para el diseo a alto nivel de la aplicacin. Ambas

63

propuestas cuentan con el soporte tecnolgico para su realizacin, sin embargo difieren en el modo de comunicacin entre los componentes lgicos del sistema. 3.1.2.1. Arquitectura orientada hacia la presentacin Web

El patrn Modelo Vista Controlador (MVC) tiene sus orgenes desde 1979 por una comunidad de usuarios del lenguaje Smalltalk proveniente de los laboratorios de investigacin en Xerox. Bajo este diseo el modelo de dominio (de datos y aplicaciones), la presentacin y las acciones basadas en la informacin ingresada por el usuario quedan separados bajo estos tres componentes (Mancini 2003): Modelo: En este mbito se gestionan las comunicaciones entre el dominio de datos y dominio de aplicacin atendiendo las consultas sobre su estado (realizadas con frecuencia desde la Vista) as como a las instrucciones de cambio de estado (usualmente desde el Controlador). Vista: Este mbito maneja la visualizacin de la informacin en un formato adecuado para el usuario y su interaccin. Controlador: Este mbito funciona interpretando las acciones del usuario sea por el teclado o el mouse, informando al modelo y/o a la vista sobre los cambios a realizarse en cada mbito. Como uno de los beneficios bajo este diseo destaca el soporte a mltiples vistas de una misma aplicacin al mismo tiempo, aprovechando un nico modelo de datos. La incorporacin de nuevas vistas (por ejemplo, para dispositivos de plataformas diversas) no altera de sobremanera el comportamiento del modelo. En contraparte, adoptando este patrn trae consigo una fuerte dependencia hacia los eventos en la interfaz de usuario, incrementando la complejidad en la programacin y control de tales acciones segn las reglas de negocio. Asimismo la codificacin del modelo debe efectuarse tomando en cuenta la vista, para as evitar escenarios en los cuales un modelo al manejar mltiples cambios en el dominio pudiera sobrecargar a la vista con solicitudes de actualizacin, en tanto algunas vistas ralentizaran su ejecucin quedando inoperativas ante tales sobrecargas. La figura 3.1 grafica las interacciones en el patrn MVC.

64

Figura 3.1 Patrn de arquitectura MVC (Mancini 2003)

3.1.2.2.

Arquitectura orientada hacia la implementacin Web

El patrn de arquitectura en N-Capas (Mancini 2003) comprende la implementacin de la presentacin, la lgica de negocio y la base de datos en capas por separado donde N representa el nmero de capas conformadas en la arquitectura. Los componentes residentes en una determinada capa pueden interactuar con sus pares ubicados en la misma capa o con componentes residentes en capas inferiores. Cada capa podra residir fsicamente en ambientes diferentes favoreciendo as a la escalabilidad del software (ver figura 3.2).

Figura 3.2 Patrn de arquitectura en N-Capas (Mancini 2003)

La interaccin con las capas inferiores presenta dos enfoques. El enfoque estricto en capas ocurre cuando interactan una capa (J) y la capa inmediata inferior (J-1). El enfoque flexible ocurre con la interaccin entre una capa (capa N) con otras ubicadas en niveles inferiores y en cualquier orden (capas J, J-1, J-3, entre otras). El enfoque flexible ofrece mejoras en eficiencia pues los tiempos de respuesta de las llamadas entre capas son inferiores a diferencia del primer enfoque. No obstante podra presentar conflictos en caso amerite el cambio en el orden de capas, pues no provee el mismo nivel de aislamiento a diferencia del primer enfoque (Mancini 2003).

65

Debido al acoplamiento y cohesin entre las capas la implementacin de cambios recae sobre una parte de la solucin, minimizando el impacto hacia otras capas reduciendo as el esfuerzo a invertir en la depuracin y correccin de errores. La separacin de componentes en capas incrementa la flexibilidad y escalabilidad posibilitando la reutilizacin de componentes y la ejecucin de pruebas unitarias de software. Para fines de performance, la seguridad y accesibilidad de la aplicacin Web es altamente valorada. Esto bien se logra distribuyendo la aplicacin sobre niveles fsicos (hardware) aplicando polticas de seguridad como cortafuegos para determinados componentes, liberando al resto por Internet. As, la distribucin de las capas en niveles fsicos favorece al incremento de la tolerancia a fallos y rendimiento de la solucin.

Por otro lado, como la interaccin de un componente con otro ubicado en niveles inferiores requiere el pase obligatorio por el resto de capas intermedias, se produce una sobrecarga en el tiempo de respuesta en perjuicio de la performance. Este escenario podra evitarse bajo un enfoque relajado sacrificando propiedades como el aislamiento de capas. A su vez, este patrn para una aplicacin con funcionalidades sencillas no resulta ptimo dado el nivel de complejidad incorporado. En similar situacin, para aplicaciones dependientes de operaciones intensivas con bases de datos su adaptacin no es viable. 3.1.3. Diseo de la arquitectura de la solucin Para la implementacin de esta solucin se aplicar la arquitectura en N-Capas, debido a su diseo altamente escalable ante la incorporacin de nuevos mdulos y funcionalidades a futuro. Adems posibilita la distribucin de componentes (capas) entre varios niveles de hardware, obteniendo mayor seguridad y rendimiento ante numerosas peticiones al servidor Web. Esta arquitectura orientada a objetos no presenta obstculos para adaptar tanto el patrn de modelo de dominio en la capa de lgica de negocio como el patrn de repositorio en la capa de acceso a datos, cumpliendo as con los lineamientos base de diseo indicados a comienzos del captulo. La arquitectura queda dividida en cuatro capas descritas a continuacin (ver figura 3.3): Capa de Presentacin: Esta capa integra los elementos de la interfaz grfica y las clases con la lgica del comportamiento de las pginas para su interaccin con el usuario. Involucra libreras CSS, JavaScript, Ajax, Flash, pginas

66

maestras y ficheros ASPX y HTML adems de contenido audiovisual. Esta capa acta de forma similar a la Vista en el patrn MVC. Capa de Aplicacin: Esta capa tiene como funcin delegar las solicitudes de usuario provenientes de la capa previa hacia los mdulos y clases correspondientes de la Capa de Lgica de Negocio, sin involucrar la implementacin en lneas de cdigo de dicha solicitud. Asimismo acta como fachada para futuras implementaciones de integracin con otros dispositivos, plataformas y sistemas a travs de aplicaciones como servicios Web. Capa de Lgica: Esta capa sigue la lnea de trabajo de la entidad Modelo del patrn MVC. Conformada por clases cuyas funciones recaen en la implementacin de la lgica de negocio atendiendo el requerimiento de usuario. Interacta con la capa de base de datos de acuerdo con el tratamiento deseado de la informacin intercambiada. La codificacin de la lgica de negocio sigue el patrn modelo de dominio. Capa de Acceso a Datos: En esta capa se ubicarn las clases DAO y libreras de conexin encargadas de administrar las operaciones CRUD (Create Read Update Delete) y sentencias SQL a nivel de base de datos. La codificacin de esta capa sigue el patrn repositorio.

Figura 3.3 Diagrama de componentes de la arquitectura

67

Para el intercambio de informacin entre las capas tratadas, se hace uso de un conjunto de entidades de negocio (componente PEGA_ENTI), cuyas clases representan el escenario real del negocio. La arquitectura propuesta satisface los requerimientos no funcionales de diseo definidos en el captulo anterior. La tabla 3.1 refleja cmo esta eleccin satisface los requerimientos de diseo.
Tabla 3.1 Requerimientos de diseo vs. Solucin arquitectnica

Requerimiento no funcional El sistema ser desarrollado con una La

Solucin propuesta codificacin de la Capa de

interfaz grfica de usuario basada en Presentacin no ser controlada por la controles Web. Capa de Lgica, otorgando mayor libertad para incorporar los elementos grficos y HTML adecuados. El sistema ser accesible desde cualquier La lgica de la Capa de presentacin equipo de trabajo con navegadores Web residir en el servidor de aplicaciones Microsoft superior) superior). Internet y Mozilla Explorer Firefox (6.0 (2.0 o Web y por el lado del cliente slo o observar cdigo HTML compatible con los navegadores Web. En caso se requiera ejecutar lgica por el lado del cliente las libreras AJAX de igual forma simplifican esta labor

conservando la compatibilidad. El sistema se ejecutar sobre un servidor El sistema ser albergado en el de aplicaciones Web con operativo adelante. El sistema trabajar con el administrador En la Capa de Acceso a Datos se de base de datos PostgreSQL ubicar el componente de conexin a la base de del datos resto deseada, de la Windows Server sistema servidor 2008 IIS Express de libre

en distribucin.

independiente aplicacin.

Entre los objetivos y restricciones aplicables a esta arquitectura destacan: Validacin de informacin: Para la validacin de los datos de entrada y salida se contar con controles desarrollados bajo las libreras Ajax (ubicadas en la Capa de Presentacin) y con las reglas impuestas en la Capa de Lgica.

68

 Performance: Para fines de implantacin la arquitectura es afn al establecimiento de diferentes niveles fsicos (o de hardware) por capa mejorando el rendimiento. Respecto a los clientes navegadores Web, la arquitectura soporta la ejecucin de mltiples transacciones desde otras conexiones en simultneo. Proteccin: La autenticacin y validacin de acciones al usuario queda a cargo del mdulo Seguridad en la Capa de Lgica. Unicidad: La arquitectura en su Capa de acceso a datos permite la interaccin con una base de datos a la vez, canalizando todas las operaciones de lectura y escritura hacia sta.

3.1.4. Vista Lgica

La figura 3.4 representa la vista lgica del software con las cuatro capas descritas, as como los principales componentes encargados de su funcionamiento.

Figura 3.4 Vista lgica del sistema

3.1.5. Vista de Despliegue A continuacin la figura 3.5 grafica la representacin de las relaciones entre los nodos fsicos y su localizacin junto con los componentes en hardware y software.

69

Figura 3.5 Diagrama de despliegue

Los nodos indicados en la figura se describen a continuacin Estacin cliente: Este nodo representa al navegador Web de la mquina cliente, desde el cual se realiza la conexin al sistema. Servidor Web y de Aplicacin: En este nodo residen los archivos del cdigo fuente con la lgica de negocio estructurada en capas. Servidor de Base de datos: Este nodo contiene el sistema administrador de base de datos. Interacta con el nodo de servidor Web en su capa de acceso a datos (DAO).

3.1.6. Diagrama de clases de diseo Se muestran a continuacin los diagramas de clases de diseo de los mdulos Organizacin, Planeamiento y Evaluaciones. En primer lugar las clases de diseo representan a las entidades de negocio identificadas en la etapa de anlisis, con sus atributos y tipos de datos utilizados. En segundo lugar representan a las clases cuyos mtodos ms importantes tienen a cargo la implementacin de la lgica de negocio as como las operaciones de lectura y escritura con la base de datos. Una ltima clase llamada MasterDAO implementar la conexin entre la base de datos con el modelo de dominio empleado para la persistencia.

Las clases de diseo del mdulo Organizacin (figura 3.6) muestran la dependencia de la relacin entre las clases Trastorno y EscalaTrastorno para dar lugar a una instancia de la clase Terapia. La interaccin entre las clases Tarea, Actividad y Terapia es imprescindible para las funcionalidades de mantenimiento de terapias y asignacin de tareas por actividad. De otro lado se observa la navegabilidad bidireccional entre las clases Actividad y Tarea respecto a la clase Objetivo como consecuencia del grado y nivel de dependencia existente. La evaluacin de un

70

objetivo por indicadores requiere de la implementacin de la navegacin desde la clase padre hacia la clase Indicador.

Figura 3.6 Diagrama de clases de diseo - Mdulo Organizacin

En el mdulo Planeamiento (figura 3.7) las clases Programa y EventoProceso renen las operaciones de mantenimiento de estas entidades en el sistema. Una instancia de la clase EventoProcesoHistorial accede a informacin del programa educativo y puede recuperar la secuencia de eventos transcurridos.

Bajo este diseo se tendr acceso a la informacin de una tarea miembro de una actividad desde una instancia de la clase Programa.

71

Figura 3.7 Diagrama de clases de diseo - Mdulo Planeamiento

El mdulo Evaluaciones (figura 3.8) tiene como clases de diseo principales a la clase EvaluacionEspecialista, la cual rene mtodos para el mantenimiento de evaluaciones (a nivel de preguntas y respuestas alternativas).

La clase Calificacin fue concebida para las operaciones de actualizacin de notas y observaciones en las posiciones de una entidad de las clases Programa y Plan de tarea.

72

Finalmente

las

clases

EvalEspecialistaResult

LineaEvalEspecialistaResult

incluyen mtodos para la actualizacin de las respuestas emitidas por los familiares en las evaluaciones de especialistas.

Figura 3.8 Diagrama de clases de diseo - Mdulo Evaluaciones

La explicacin del diagrama de clases de diseo se profundiza el Anexo H: Documento de diseo del sistema. 3.1.7. Diagrama de base de datos Se presenta a continuacin en la figura 3.9 las principales tablas del diagrama de base de datos para las operaciones del sistema. El diccionario de datos se encuentra en el Anexo J: Documento de diseo de base de datos.

73

Figura 3.9 Diagrama de base de datos del sistema 74

3.1.8. Diagramas de secuencia

Se presentan a continuacin tres diagramas de secuencia correspondientes a los procesos de creacin de usuarios, asignacin de objetivos a una actividad y toma de asistencia. El propsito es representar grficamente la interaccin entre las capas del software conforme con las acciones del usuario. La relacin completa de diagramas se ubica en el Anexo H: Documento de diseo del sistema.

Como muestra el diagrama de secuencia de la figura 3.10 el inicio de la accin ocurre en el formulario de bsqueda de usuarios. El administrador tras seleccionar la creacin de un nuevo usuario se dirige a otro formulario y completa la informacin requerida. De acuerdo con el tipo de usuario (usuario externo o especialista) se crean las instancias de dichas entidades desde la clase Seguridad_LogTyp1 (miembro de la Capa de Lgica) asignando dichas entidades al nuevo usuario. Procede a continuacin la asignacin de un perfil de seguridad y por ltimo la invocacin al mtodo de registro de la clase DAOUsuario (miembro de la Capa de Acceso a Datos). La conclusin satisfactoria o errnea del proceso es transmitida hacia la Capa de Aplicacin y Presentacin respectivamente, mediante un mensaje junto con el cdigo de usuario.

Figura 3.10 Diagrama de secuencia del proceso de registro de usuario

En este segundo diagrama (figura 3.11) el especialista tras identificar la actividad selecciona la opcin de modificacin. En este mbito es invocado el mtodo de carga de objetivos previamente ingresados al sistema (como se recuerda la clasificacin de objetivos difiere segn sea las entidades actividad o tarea). Del

75

mismo modo, en caso de no ubicar un objetivo coherente y amerite su creacin, se carga el listado de indicadores de evaluacin. Finalmente el proceso concluye con la grabacin de los cambios efectuados. Como este flujo es parte del proceso de mantenimiento de una actividad, se opt por prescindir en el grfico del resto de mensajes intercambiados entre los componentes destacando nicamente los avisos competentes a este sub-flujo.

Figura 3.11 Diagrama de secuencia del proceso de asignacin de objetivos a actividad

Figura 3.12 Diagrama de secuencia del proceso de toma de asistencia

El proceso de toma de asistencia representado en la figura 3.12 comienza a partir del panel de bsqueda donde el usuario selecciona una hoja de asistencia para proceder con el registro. El mtodo p_BuscaHojaAsistencia recupera los datos de

76

cabecera y posicin de la respectiva hoja. Concluido el mantenimiento de asistencia en la pantalla Pres_MantenerTomaAsistencia el ciclo cierra con la invocacin al mtodo p_UpdateHojaAsistencia actualizando automticamente las posiciones de la hoja de asistencia tomadas en el registro.

3.2.

Diseo de Interfaz Grfica

En esta seccin se exponen los criterios para el diseo de la interfaz grfica para la implementacin de la Capa de Presentacin. Posteriormente se describen las restricciones asumidas en el diseo grfico Web.

3.2.1. Estndar de Interfaz Grfica

Todas las pginas del sistema (con excepcin de la interfaz de inicio de sesin) seguirn el patrn grfico mostrado en la figura 3.13.

Figura 3.13 Patrn de diseo grfico del sistema

Ttulo de la ventana: El ttulo de la ventana en todo momento albergar los nombres de la institucin educativa y del producto. Encabezado de pgina: Incorpora el logotipo caracterstico del centro educativo en la parte superior izquierda de la pantalla, sobre la barra lateral de men. Nombre de usuario: Durante la sesin activa se mostrar el nombre completo del usuario en la parte superior derecha. Se har uso de la fuente Arial en doce (12) puntos.

77

 Ttulo de pgina: Como ttulo de la pgina en ejecucin se visualizar la ruta de acceso seguida por el usuario. Se har uso de la fuente Arial en catorce (14) puntos. Fecha de sesin: Ubicada en el extremo izquierdo del ttulo de pgina se mostrar la fecha del da. La fuente utilizada ser Arial en diez (10) puntos. Barra de botones: Al acceder a cada tem del men desplegable se dispone de esta barra para enlazar con otras funcionalidades del mdulo (por ejemplo, durante los mantenimientos de las principales entidades). Barra de men: La barra de men desplegable tendr como ubicacin el sector intermedio izquierdo de la pantalla y usar la fuente Arial en once (11) puntos. Iconos de desconexin: En la parte inferior del men se ubicar el botn de cierre de sesin de usuario. Barras de desplazamiento: Para el traslado horizontal y vertical se contar con barras de desplazamiento a lo largo de la pgina. Hojas de estilos en cascada (CSS): El manejo de las propiedades de fuente en cajas de textos y etiquetas (tipo de fuente, tamao y color) recaer en estos ficheros. A continuacin se muestran los prototipos de las pantallas de inicio de sesin (figura 3.14), bsqueda (figura 3.15) y mantenimiento (figura 3.16) sujetas al patrn de diseo Web descrito.

Figura 3.14 Pantalla de Ingreso al Sistema

78

Figura 3.15 Pantalla de Bsqueda de Documentos

Figura 3.16 Pantalla de Mantenimiento de Programas

3.2.2. Consideraciones finales

Las observaciones sealadas a continuacin favorecern a la implementacin de una interfaz sencilla, intuitiva y de fcil interaccin para el usuario.

79

 Las pginas no albergarn elementos dinmicos como contenidos en Flash, archivos de imgenes GIF animados entre otros dado el alto consumo de recursos demandados en la aplicacin. Para escenarios con mltiples conexiones y transacciones la incorporacin de estos componentes afectara a la performance y tiempos de respuesta del servidor. Se trabajar en la implementacin con tablas HTML y pginas maestras para contribuir as con la estandarizacin del diseo y distribucin uniforme de elementos grficos en pantalla. Se limitar el tamao de caracteres por lnea de acuerdo a las dimensiones de la pantalla evitando el truncamiento automtico de textos. Ofrecer opciones para minimizar la escritura a partir de controles como dropdownlists, radiobuttons, checkboxes, entre otros. As como el

establecimiento de valores predeterminados en los campos de las pantallas. Con fines de compatibilidad incrustar elementos HTML y JavaScript compatibles con los navegadores IE 6.0, Mozilla Firefox y Google Chrome. En ese sentido, los componentes grficos Web exclusivos de la tecnologa ASP.NET no formarn parte de las pantallas presente en la Capa de Presentacin.

80

4. CAPTULO 4:

Construccin

El presente captulo tiene como propsito presentar las tecnologas seleccionadas para la implementacin del producto. Por su parte se define la estrategia de pruebas y los tipos de pruebas seleccionados en esta etapa.

4.1.

Construccin

En esta seccin se hace un resumen de las caractersticas de las principales tecnologas, motores y frameworks empleados en la implementacin como el lenguaje de programacin, libreras, motor de base de datos entre otros. 4.1.1. Framework de desarrollo

Para este proyecto el framework seleccionado es ASP.NET miembro de la plataforma .NET Framework 4.0. Es un componente del sistema operativo Windows con caractersticas de desarrollo e integracin de diferentes lenguajes de programacin con el propsito de construir aplicaciones reutilizables y escalables en ambientes cliente/servidor, Web, dispositivos mviles entre otros. En su transformacin a partir de la API de Windows se presentaron factores de carcter

81

evolutivo como la compatibilidad hacia atrs con otros lenguajes de programacin demandando as una mayor complejidad en integracin. .NET Framework 4.0 se adapta a la reutilizacin de cdigos provenientes de diferentes lenguajes de programacin, sin perder la caracterstica de independencia del lenguaje (Freeman 2011). Entre las caractersticas ms resaltantes destacan: Common Language Specification o CLS: Encargado de la compatibilidad de cdigo entre lenguajes. Conjunto mnimo de estndares para la

interoperabilidad de cdigo generado a partir de diferentes lenguajes. Todo compilador para .NET debe generar cdigo compatible con este estndar. Representa un subconjunto de las caractersticas ofrecidas por .NET (Freeman 2011). Compilacin Just-in-Time o JIT: La mquina virtual de .NET utiliza un compilador para convertir el cdigo IL a cdigo mquina justo antes de ser ejecutado. Esto permite eficiencia al ejecutar un programa, pues solo compila el fragmento de cdigo en uso. La compilacin JIT solo se realiza una vez por cada porcin de cdigo ejecutado. Si un cdigo es ejecutado por segunda vez se utiliza su versin compilada. El conjunto unificado de bibliotecas de clase proporciona las funciones estndar para entrada y salida de datos, manipulacin de cadenas y XML, entre otros ofreciendo una interfaz de desarrollo comn para todos los lenguajes compatibles con .NET Framework.

Figura 4.1 Componentes de .NET Framework 4.0 (Freeman 2011)

Por lo graficado en la figura 4.1 as como por las observaciones mencionadas anteriormente la eleccin de esta tecnologa queda justificada por la alta integracin

82

existente entre este framework con otras herramientas y libreras logrando con ello maximizar la velocidad en la programacin y pruebas del software. Por otro lado la curva de aprendizaje bajo esta tecnologa es inferior en comparacin con otras tecnologas Web y en cuanto al tiempo dedicado a la construccin de la solucin. Entre otras capacidades logradas con la utilizacin de este framework destacan: Ofrece herramientas y recursos para una mejor experiencia en programacin orientada a objetos promoviendo la reutilizacin de cdigo fuente. La configuracin de la seguridad es realizada sea con autenticacin nativa de Windows o va configuracin individual por aplicacin. Durante el desarrollo se tiene acceso a toda la librera de clases de .NET. Independiente del lenguaje de programacin. Integra el framework ADO.NET Entity Framework para el trabajo con los mecanismos de persistencia de datos en cualquier base de datos.

De este framework se har uso de la tecnologa ASP.NET por ser considerada como la plataforma ad hoc para la creacin de aplicaciones Web en .NET Framework complejas y limitadas con contenido dinmico integrando las mismas prestaciones. Asimismo todos los sitios Web construidos a partir de ASP.NET son compatibles con la mayora de navegadores Web y simplifica los procedimientos en configuracin reduciendo significativamente la dependencia del servidor IIS por medio de un fichero XML de configuracin denominado WEB.CONFIG diferente por cada ambiente de desarrollo, pruebas o produccin.

4.1.2. Lenguaje de programacin

.NET Framework permite trabajar con ms de veinte lenguajes de programacin integrados entre ellos C# y Visual Basic. Si bien el tesista rene la preparacin y experiencia frente a ambos candidatos, se seleccion en lenguaje C# por las razones expuestas a continuacin: En bsqueda de construir una solucin desde una perspectiva orientada a objetos estricta, este lenguaje ofrece capacidades maduras en trminos de sintaxis y estructura de cdigo; respetando principios como el encapsulamiento, abstraccin y polimorfismo en un nivel avanzado respecto a Visual Basic. C# rene un nutrido conjunto de libreras y componentes en una estructura de cdigo cercana al lenguaje Java y C++.

83

 Las libreras y componentes de software integradas al proyecto ofrecen una mejor performance con proyectos en el lenguaje C# (como el driver de conexin Npgsql). C# posee control de excepciones de forma estructurada. Los patrones de desarrollo de software a seguir en el proyecto exigen un lenguaje orientado estrictamente a objetos. La programacin orientada a objetos con C# alcanza una mayor libertad en la implementacin de mecanismos de encapsulamiento, herencia, polimorfismo, sobrecarga, entre otros. Mientras su contraparte Visual Basic no rene estos conceptos mnimos para plasmar esta ptica. La programacin en el lenguaje Visual Basic no exige la declaracin de variables a diferencia del lenguaje C#. Dicha omisin afecta la estandarizacin de la programacin y a las pruebas de producto. Sumado a lo anterior, considerando un paradigma gil donde se pretende optimizar las labores de codificacin adecuando buenas prcticas en programacin, dicha carencia es calificada como contraproducente. 4.1.3. Framework ORM

Para las operaciones de lectura y escritura en base de datos, en la evaluacin de este proyecto los frameworks candidatos fueron NHibernate y ADO.NET Entity Framework (EF). Entre las similitudes de ambos frameworks valen mencionar: Soportan operaciones con bases de datos Oracle, SQL Server, MySQL, PostgreSQL, entre otras. Todas las operaciones CRUD se realizan a partir de objetos. Incluyen lenguajes de consultas especficos como HQL (Hibernate Query Language) o LINQ (Language Integrated Query). Para su funcionamiento requieren del mapeo del modelo de dominio.

Finalmente, se opt por trabajar con ADO.NET Entity Framework por las razones detalladas a continuacin: Se reduce drsticamente el tiempo a invertir en el mapeo entre entidades y tablas de bases de datos. Para este fin el programa EDMGEN.EXE recibe la cadena de conexin de una determinada base de datos (propietaria o de libre distribucin) y genera en la carpeta de proyecto los mapas y clases del modelo

84

de datos homologando a su vez los tipos de datos entre ambos entornos. Como flujo alternativo, tambin es posible retornar clases POCO (Plain Old Class Object) depurando an ms la definicin de las clases. A diferencia del otro framework donde la labor de mapeo es manual incrementando los tiempos en la programacin. NHibernate cuenta con el lenguaje HQL para la construccin de consultas en la base de datos. En cambio ADO.NET EF ofrece hasta tres niveles de consultas, cada uno con diferentes tiempos de respuesta y por ende afectando en diferente grado a la performance global: Entity SQL, LINQ to Entities y LINQ to SQL. LINQ le otorga a todo lenguaje de programacin de la plataforma .NET la capacidad de construccin de sentencias SQL nativas como parte de su sintaxis propia. ADO.NET EF soporta funciones cannicas (como las funciones Count, Max, Min, Avg, entre otras) comunes e implementadas por todas los motores de bases de datos compatibles con este framework. Asimismo, dichos motores aportan al framework nuevos tipos de datos para reforzar la compatibilidad en la solucin a implementar. ADO.NET EF es un proyecto integrado a la plataforma .NET Framework 4.0 desde el ao 2008 constituyndose como una tecnologa en constante evaluacin y evolucin a futuro (Lerman 2010).

El factor rendimiento entre ambos frameworks es un criterio de medicin despreciable por cuanto ambos responden satisfactoriamente a los lmites de tolerancia fijados en las pruebas preliminares de seleccin de herramientas. Es comn, tendencioso y arriesgado sealar un candidato como el ms ptimo, sin conocer previamente cmo efectuar la configuracin de ambos productos bajo las buenas prcticas recomendadas por sus fabricantes.

4.1.4. IDE

Entre los candidatos para la eleccin de la entorno de desarrollo fueron los productos SharpDevelop, MonoDevelop y Visual Web Developer 2010 Express Edition (VWD2010). Adems de presentarse en versiones no comerciales, dichos entornos permiten el desarrollo de aplicaciones orientadas a objetos con ASP.NET en el lenguaje C#, a partir de la versin de .NET Framework 4.0.

85

Sin embargo la eleccin de la herramienta IDE decant en Visual Web Developer 2010 Express Edition por las siguientes consideraciones: SharpDevelop y MonoDevelop son entornos de programacin para propsitos generales. Visual Web Developer 2010 Express Edition en cambio ofrece una gama de comandos, frameworks y plantillas de proyectos para una avanzada experiencia en la construccin de aplicaciones Web desde cero. Por tratarse de un entorno de desarrollo Web, VWD2010 posee un editor de pginas compatible con estndares Web como CSS 2.1, JavaScript, XML, XHTML 1.0/1.1 simplificando la construccin de pginas HTML mediante el arrastre de elementos grficos (drag & drop). Realiza la validacin automtica de las pginas HTML junto con las notaciones de los estndares Web incrustados como cdigo de pgina. VWD2010 ofrece un mejor control para la visualizacin del diseo de pginas Web tanto en modo cdigo (cdigo HTML) y modo diseo (interface WYSIWYG) contrastando su compatibilidad frente a diversos navegadores Web. Para propsitos de pruebas VWD2010 permite trabajar hasta con dos servidores Web (el servidor de desarrollo ASP.NET y IIS Express), a diferencia de los otros editores los cuales carecen de esta integracin. VWD2010 simplifica el mantenimiento de los ficheros de configuracin en ASP.NET (WEB.CONFIG), para el establecimiento de la conexin con la base de datos del sistema as como para la sincronizacin con ELMAH y el registro de errores y excepciones en lnea. Adems permite el manejo de hasta dos versiones de un mismo fichero de configuracin para los ambientes de desarrollo y pruebas, evitando posibles prdidas o errores en configuracin entre dichos mbitos. La administracin de archivos y libreras en VWD2010 se basa en proyectos Web y en proyectos de librera de clases (con propiedades de configuracin similares ofrecidas por Visual Studio Professional Edition). 4.1.5. Base de Datos

En esta categora los precandidatos fueron los motores PostgreSQL y MySQL, siendo elegido el primero por las siguientes razones: PostgreSQL garantiza una mejor integridad de los datos forzando a mantener una integridad referencial entre tablas. Dicha caracterstica es opcional en

86

MySQL (por defecto, desactivada a fin de no afectar la performance). No obstante para los propsitos de la solucin a implementar es crucial contar con esta capacidad. En MySQL la inclusin de llaves forneas en las tablas de la base de datos slo se encuentran en tablas InnoDB. Para simular este comportamiento se necesitan disparadores (triggers). En lneas generales, PostgreSQL provee herramientas y alternativas de configuracin con fines de otorgar mayor seguridad e integridad en los datos. En el caso de MySQL ofrece un mejor rendimiento y tiempo de respuesta frente a operaciones especficas de lectura y escritura. Sin embargo, para escenarios con una importante carga de conexiones ambos motores obtienen tiempos de respuesta promedio similares (por ejemplo, joins en sentencias SQL). Finalmente, en cuanto al tema de licencias de pago y/o libre distribucin (como hasta la fecha ocurre con MySQL, concebido como producto) con PostgreSQL restricciones de este nivel no representa inconveniente alguno.

4.1.6. Servidor Web

IIS Express 7.5 fue elegido como servidor Web para las operaciones de desarrollo y pruebas. Su eleccin respecto de otro candidato como el servidor por defecto de ASP.NET (Cassini) obedece por tratarse de una versin del IIS estndar y optimizada para desarrolladores reuniendo similares funciones y capacidades de integracin con SSL (Secure Socket Layer) y URL Rewrite (para el cifrado y envo seguro de datos) bajo las mismas configuraciones en el fichero WEB.CONFIG. Finalmente no requiere del pago de licencia alguna y permite su distribucin junto con las aplicaciones.

4.1.7. Otras herramientas y libreras

La librera Npgsql (Postgresql 2007) es un proveedor (driver) de datos para aplicaciones .NET conectadas a una base de datos en PostgreSQL desarrollado en el lenguaje C# y compatible con la versin 7.X en adelante de dicho motor de base de datos. Asimismo soporta operaciones de persistencia de datos con ADO.NET Entity Framework.

Como apoyo a las labores de pruebas de integracin y adems para establecer un registro global de errores de la aplicacin una vez implantada en los centros

87

educativos, se incorpor la librera ELMAH (Google 2009) con la finalidad de conservar por base de datos la relacin de errores y excepciones producidos durante las sesiones de los usuarios desde diversos clientes. Por medio de una configuracin al archivo WEB.CONFIG de la solucin desarrollada bajo ASP.NET, efecta el envo automtico de correos electrnicos (o por notificaciones va RSS) al administrador sobre las incidencias producidas, con informacin relativa a la ubicacin, fecha, hora y detalle de la excepcin producida.

Por su parte, el proyecto de cdigo abierto Ajax Control Toolkit contribuy al desarrollo de controles y extensiones interactivas sobre los formularios Web con capacidad de ejecucin en la mquina cliente manteniendo una comunicacin asncrona con el servidor en segundo plano, evitando as la recarga de pgina. Ajax combina tres tecnologas como XHTML y CSS para el diseo de la presentacin, DOM o modelo de objeto de documento para la captura de datos, el objeto XMLHttpRequest para intercambio de informacin en segundo plano con el servidor y XML para la transferencia de datos de retorno.

Finalmente, para el control de versiones de documentos y cdigo fuente se cont con el apoyo del software TortoiseSVN.

4.2.

Pruebas

En esta seccin se detalla el procedimiento de pruebas durante la verificacin y validacin del software, desde los tipos de pruebas seleccionados junto con las justificaciones de sus respectivas elecciones, as como la estrategia desarrollada. 4.2.1. Estrategia de Pruebas

El objetivo global de la estrategia de pruebas es demostrar el funcionamiento completo del software a nivel de eficiencia de cdigo y funcionalidad. En otras palabras, verificar la interaccin e integracin de los componentes y validar la implementacin de todos los requerimientos de producto.

Para el cumplimiento de lo descrito anteriormente, la estrategia establecida ser como sigue (para mayor informacin revisar el Plan de Pruebas):

88

 Recopilar, disear y documentar los casos de prueba de software a nivel de mdulo y de producto en el catlogo de pruebas. Los casos de prueba deben cubrir la revisin de ms de un requerimiento funcional. Cuantificar el esfuerzo estimado en horas de cada uno de los recursos por emplear bajo estas pruebas. Las pruebas unitarias sern ejecutadas en paralelo con la codificacin teniendo como propsito el funcionamiento correcto del cdigo fuente implementado bajo el lenguaje de programacin. Sobre la aplicacin del desarrollo guiado por pruebas (TDD), en el marco de la metodologa AUP, sta rene como etapas la eleccin de requisitos a codificar, seguida de la escritura y ejecucin de las pruebas de dichos requisitos, la implementacin del cdigo de solucin a las pruebas para culminar aplicando la refactorizacin y actualizacin de la lista de requisitos. Debido a la extensin en el nmero de requerimientos de software del proyecto se aplicarn, de las etapas descritas, la programacin del cdigo de solucin de las pruebas del sistema y la refactorizacin del software. Como siguiente instancia de pruebas se desarrollarn las pruebas de integracin en modo incremental. Se pretende con ello el acoplamiento satisfactorio y paulatino de cada mdulo as como la validacin de las funcionalidades provistas por todos los mdulos integrados anteriormente. Con la integracin del ltimo mdulo, las pruebas de integracin pasaran formalmente a supervisarse como pruebas del sistema. Como apoyo al proceso anterior, dichas pruebas contarn con la participacin de los usuarios finales de los centros educativos (previa coordinacin de fechas de pruebas integrales). Para el monitoreo en base de datos as como desde un navegador Web de los errores y excepciones arrojados durante las pruebas, se integrar la librera ELMAH a la solucin final ASP.NET, mantenindose hasta una vez concluida la implantacin o en su defecto para las actividades de mejora continua al producto. Para la automatizacin de las entradas de datos en las ventanas de usuario, se trabajar con un plugin en el navegador Web Firefox denominado Selenium IDE. Dicho plugin permite grabar y ejecutar scripts de forma directa desde este navegador simulando as la interaccin del usuario. Ante cada flujo aprobado por el usuario, se contar con actas de aceptacin constatando la revisin de los requerimientos funcionales completados.

89

4.2.2. Tipos de Pruebas En esta seccin se describen los tipos de prueba empleados en la estrategia de pruebas.

4.2.2.1.

Pruebas Unitarias

Estas pruebas de software se dirigen a componentes menores como los mdulos de un sistema, probando los caminos de control importantes con el fin de descubrir errores dentro de esta instancia (Dvila 2005). Es as como el equipo lograr identificar los defectos en fases tempranas de codificacin sin esperar la realizacin de pruebas integrales. Las tcnicas consideradas son: Pruebas de Caja Blanca: Examinan la estructura de un cdigo fuente segn la lgica implementada evaluando la ejecucin correcta a nivel de sentencia, estructuras selectivas e iterativas (Dvila 2005). No obstante, este mbito queda cubierto dentro del marco de pruebas de cdigo a realizarse durante la codificacin del producto adoptada como prctica gil.

Pruebas de Caja Negra: Estas pruebas se realizan sobre las interfaces grficas buscando comprobar la funcionalidad, comportamiento en la entrada y salida de datos as como la integridad de la informacin enviada y recibida.

Por lo tanto las pruebas de caja negra sern efectuadas considerando la documentacin de los casos sujetos a los requerimientos del negocio a partir de la identificacin y evaluacin de diversos juegos de datos en las entradas del sistema para as observar la coherencia con las salidas del sistema. Como patrn de documentacin se adopta el modelo presentado en la tabla 4.1.
Tabla 4.1 Modelo de Caso de Prueba Unitaria

Identificador Objetivo

ALU-TST-002 Verificar en el sistema el retorno de resultados en la bsqueda al ingresar un cdigo de alumno incorrecto.

Clases Asociadas Descripcin la prueba

2,3,4,7,10

de Se introduce en el campo cdigo de alumno un texto sujeto a las dos clases antes indicadas. Se dejan los otros campos en

90

blanco y se selecciona el botn Buscar. Resultados Esperados Se muestra un aviso reportando error en el formato de cdigo de alumno ingresado.

4.2.2.2.

Pruebas de Integracin

Bajo estas pruebas todos los mdulos revisados e integrados en diferentes secuencias de procesos y llamadas, son evaluados con el propsito de comprobar la ejecucin correcta conforme al proceso de negocio esperado. Un factor clave es la capacidad de identificacin de todos los esquemas de llamadas para una buena cobertura de casos de prueba integral. Las pruebas integrales se clasifican en: No incremental: Requiere tener todos los mdulo del producto software culminados para as concretar en su conjunto estas pruebas. Incremental: Cada mdulo es acoplado a los componentes existentes, as las pruebas futuras no afectarn los avances y correcciones de fases anteriores, en la bsqueda de un software robusto desde el inicio de las pruebas.

La prueba de integracin incremental fue adoptada para esta etapa, pretendiendo demostrar as el funcionamiento del software sin errores desde el inicio de su creacin. Esto puede afectar en mediano grado los tiempos globales, pero asegura calidad en la construccin y est alineado con la metodologa iterativa incremental. Involucrando a los usuarios en las pruebas, trae como ventaja la simulacin de los escenarios reales de los procesos de negocio midiendo as el grado de satisfaccin de los requerimientos funcionales.

4.2.3. Catlogo de pruebas

A continuacin en la tabla 4.2 se listan los principales casos del catlogo de pruebas concerniente a los mdulos de Seguridad, Planeamiento y Evaluacin.
Tabla 4.2 Catlogo de pruebas del sistema
Mdulo Evaluacin ID Test EVA-TST-001 Tipo Integral Descripcin Verificar si para la evaluacin del programa se despliegan las tareas asociadas. Evaluacin EVA-TST-002 Unitaria Verificar si el sistema no realiza la bsqueda de

91

evaluaciones en caso no se ingrese un cdigo de especialista vlido. Evaluacin EVA-TST-003 Integral Verificar si la bsqueda de evaluaciones a especialistas muestra una a ms coincidencias o un aviso de error en caso contrario. Planeamiento Planeamiento PLA-TST-043 PLA -TST-045 Unitaria Unitaria Registrar un nuevo programa educativo. Verifica si el sistema permite el mantenimiento de un evento en caso ingrese todos los campos obligatorios correctamente (programa, actividad, asunto, detalle). Planeamiento PLA -TST-063 Unitaria Verifica si aparece la confirmacin de la operacin de mantenimiento en caso el usuario haya ingresado los valores apropiados y haya insertado dos tareas al plan. Planeamiento PLA -TST-032 Unitaria Realizar la bsqueda de programas por rango de fechas. Planeamiento PLA -TST-031 Unitaria Realizar la bsqueda de programas por criterios de alumno y especialista. Planeamiento PLA -TST-075 PLA -TST-076 PLA -TST-077 Planeamiento PLA -TST-078 Unitaria Unitaria Verificar si el usuario puede incorporar tareas de otras actividades en otras terapias sobre un programa actual. Verificar si es posible restablecer un programa educativo actualizado a partir de una terapia original. Planeamiento PLA-TST-061 Unitaria Verificar si es posible modificar el estado de ejecucin de las tareas en el programa educativo. Planeamiento PLA-TST-062 Unitaria Verificar si es posible incorporar nuevas tareas en el plan de tareas. Planeamiento PLA-TST-011 Unitaria Verificar si es posible eliminar tareas existentes en el plan de tareas. Planeamiento Planeamiento PLA-TST-056 PLA-TST-015 Unitaria Unitaria Modificar un suceso registrado anteriormente. Verificar la bsqueda de eventos por cdigo de alumno. Planeamiento PLA-TST-016 Unitaria Verificar la bsqueda de eventos por texto de referencia. Planeamiento PLA-TST-037 Integral Verifica, durante el mantenimiento de

documentos, si el sistema admite la operacin sin un cdigo de programa. Planeamiento PLA-TST-018 Integral Verifica, previa bsqueda de planes de tareas, si el sistema valida el cdigo de plan de tarea con caracteres vlidos. Seguridad SEG-TST-001 Unitaria Verificar la emisin de un mensaje de error en caso el usuario no haya elegido un perfil de la lista

92

de valores propuestos. Seguridad SEG-TST-002 Unitaria Verificar la emisin de un mensaje de error al no indicar un cdigo de usuario correcto en el campo Usuario desde Seguridad SEG-TST-004 Unitaria Verificar la emisin de un mensaje de

confirmacin en la asignacin de perfil al indicar un cdigo de usuario en el campo Usuario desde dejando en blanco el campo Usuario hasta. Seguridad SEG-TST-005 Unitaria Modificar los accesos de un usuario de acuerdo a su perfil Seguridad SEG-TST-006 Unitaria Verificar si el usuario puede modificar su

contrasea. Seguridad SEG-TST-008 Unitaria Verificar si el usuario ha ingresado al sistema utilizando un cdigo y contrasea errneos. Seguridad SEG-TST-029 Integral Verificar si el usuario de acuerdo al perfil, tiene autorizado o no el acceso a determinadas operaciones. Seguridad SEG-TST-032 Unitaria Verificar si la creacin de un usuario/perfil procede dejando campos obligatorios u otros campos en blanco. Seguridad SEG-TST-031 Unitaria Verificar si los paneles de bsqueda de usuarios y perfiles arrojan los resultados esperados. Seguridad SEG-TST-012 Unitaria Verificar si el usuario no ingrese al sistema utilizando cdigo y contrasea en blanco. Seguridad SEG-TST-013 Unitaria Verificar si la contrasea ingresada cumple con las restricciones en cuanto a longitud y contenido. Seguridad SEG-TST-014 Unitaria Verificar si el usuario ha modificado correctamente su contrasea.

El detalle completo de todos los casos de prueba, procedimiento, resultados y observaciones se encuentran en el Anexo N: Plan de pruebas del sistema.

4.2.4. Reporte de ejecucin de pruebas

Tras la ejecucin de pruebas unitarias e integracin segn el Plan de Pruebas se presenta en esta seccin los resultados obtenidos. En lneas globales, se obtuvieron porcentajes superiores al 90% de efectividad: la estrategia de pruebas de carcter incremental sumada a las prcticas de pruebas en desarrollo y la documentacin de las casusticas contribuyeron al logro de estos resultados.

93

En el desarrollo de pruebas unitarias se obtuvo un porcentaje de xito del 96.12% como consecuencia de las prcticas de pruebas en paralelo a la programacin de los mdulos. Para el cumplimiento total de este paquete de pruebas se recurri a continuas iteraciones para subsanar las falencias ocurridas.

En cuanto a las pruebas de integracin se obtuvo un 92.13% de cumplimiento como consecuencia de problemas en la integracin de procesos entre mdulos. Dichos inconvenientes se fueron solucionando tras nuevas pruebas de regresin.

94

5. CAPTULO 5: recomendaciones

Observaciones, conclusiones y

Este captulo final comprende las observaciones identificadas y asimiladas una vez completadas las fases del proyecto, junto con las conclusiones y recomendaciones finales para futuros proyectos afines a la temtica de este proyecto.

5.1.

Observaciones

Este proyecto fue concebido con el objetivo de integrar en una herramienta Web todas las funcionalidades y tareas afines a un plan de gestin educativa y de administracin de la labor pedaggica en estas instituciones.

En la etapa de anlisis se realiz el levantamiento de informacin entre profesionales del rea educativa especial as como estudiantes de pregrado para obtener una relacin potencial de requerimientos y exigencias. Con la finalidad de entender el comportamiento e interaccin de sus procesos se realizaron seguimientos de actividades en dos instituciones dedicadas al tratamiento de personas con habilidades especiales. Lo anterior facilit la identificacin de

95

requerimientos funcionales y del modelo de negocio aplicado y acorde con los objetivos establecidos.

La incorporacin de prcticas giles en las fases de construccin y pruebas favoreci significativamente en la reduccin de los tiempos de entrega y salida de cada mdulo construido paulatinamente. As como la utilizacin de herramientas como ELMAH y Selenium para la captura de errores y ejecucin de scripts en sistemas Web respectivamente inyectaron mayor dinamismo a las pruebas.

Se ha apostado por una plataforma Web basada en .NET Framework pero integrada con recursos y proyectos gratuitos y de libre distribucin. La inversin en las herramientas IDE y aplicativos de prueba no requiri de pago de licencia. En un escenario real y en caso se opte por comercializar esta propuesta, bien podra ser distribuida bajo modalidades de computacin en nube y software como servicio (SaaS) hacia instituciones educativas carentes de la infraestructura fsica y tecnolgica adecuada.

Una restriccin importante a nivel de arquitectura es la alta dependencia existente entre el modelo de dominio implementado en la solucin y el diseo de la base de datos del sistema. Todo cambio importante a nivel de atributos o tablas implicar la regeneracin inmediata del modelo de dominio, adecuando las funcionalidades a las capas y mdulos competentes. Caso contrario se presentarn serios problemas con el mapeo de entidades y tablas por la obsolescencia existente entre ambas versiones. Por consiguiente es importante asegurar un buen diseo de la base de datos antes y durante la fase de construccin, as como analizar y cuantificar el impacto de cualquier solicitud de cambio en la base de datos a futuro (en proyectos de mejora continua).

El presente trabajo fue concebido con fines estrictamente acadmicos y no es de inters del autor obtener un fin lucrativo a futuro. Aqu es preciso destacar las caractersticas y funcionalidades de este sistema como uno de los pioneros en el rubro de sistemas educativos en educacin especial, dentro del emergente mercado local de desarrollo de software.

5.2.

Conclusiones

Las conclusiones obtenidas a raz de este proyecto son las siguientes:

96

 Con este proyecto se consigui implementar una solucin automatizada capaz de administrar los programas educativos, planes de tareas, actividades y tareas de los alumnos de centros de educacin especial junto con otros procesos en gestin educativa en dichas instituciones. El monitoreo continuo del cronograma de proyecto y de la estructura de descomposicin del trabajo posibilit el cumplimiento de los tiempos estipulados. Adems se logr culminar satisfactoriamente las fases de desarrollo del software junto con los entregables adecuados y establecidos por la metodologa AUP. Los esfuerzos y tiempo invertidos en el anlisis y diseo de la solucin posibilitaron la cobertura de todos los requerimientos funcionales del usuario maximizando las funcionalidades deseadas del producto enriquecindolas con aportes provenientes de otros sistemas descritos en el Estado de Arte del captulo 1. La incorporacin de buenas prcticas y de la metodologa AUP en las etapas de construccin de software permitieron cumplir con los tiempos de entrega en cada una de las siete iteraciones. Este proyecto comprueba la capacidad de integracin de aplicaciones construidas bajo la plataforma .NET Framework con proyectos de cdigo abierto como PostgreSQL, ELMAH, Npgsql y otros logrando una significativa reduccin de costos en la solucin y cumpliendo los requerimientos no funcionales en cuanto la arquitectura. El producto es viable econmicamente a lo largo de sus etapas como consecuencia de la utilizacin de herramientas de diseo y desarrollo de cdigo abierto o libre de pago por licencias, figurando como nicos tems de gasto las planillas del equipo de proyecto. La adopcin de ASP.NET Webforms como framework de desarrollo a diferencia de otros proyectos como ASP.NET MVC o ASP.NET Razor permiti una mejor implementacin de funcionalidades desde una interfaz grfica intuitiva,

97

orientada a eventos y provista de una serie de controles Web a diferencia de sus contrapartes. La arquitectura en capas ofrece una mejor escalabilidad para futuras integraciones con nuevas herramientas y servicios aplicando la reutilizacin de componentes. La documentacin tcnica y funcional del producto brindar a todo nuevo usuario un mejor entendimiento de las funciones implementadas.

5.3.

Recomendaciones y trabajos futuros

Se recomienda a todo centro educativo especial, como prembulo a la puesta en marcha del software, realizar capacitaciones peridicas al staff de profesionales y familias. Ante todo cambio en la estructura de la base de datos se recomienda actualizar inmediatamente en el modelo de dominio utilizado por la aplicacin, como medida preventiva ante posibles problemas en compilacin por incompatibilidad de versiones en el modelo desde ADO.NET EF.

Como trabajos a futuro en este campo, se recomienda incorporar los procesos automatizados de la gestin de personal y planillas as como la contabilidad financiera de la institucin. Con lo anterior esta solucin prcticamente abarcara todas las operaciones y actividades de dichas instituciones. Respecto al mdulo Reportes, se sugiere ampliar la capacidad de impresin de documentos en formato DOCX para su distribucin y visualizacin en editores como MS Word, OpenOffice o StarOffice. Sumado a lo anterior, se propone implementar una solucin encargada de la configuracin y salida automtica de todos los reportes con valor oficial exigidos por el Ministerio de Educacin.

Frente a posibles proyectos de integracin donde es indispensable el intercambio de informacin (por ejemplo, mediante servicios Web) se recomienda su implementacin desde la capa de Aplicacin. Dado el alto flujo de informacin circulante entre los especialistas y el sistema, las incorporaciones de proyectos en inteligencia de negocios como datawarehouse y minera de datos contribuiran con creces en una mejor explotacin de datos en conocimiento como apoyo a las investigaciones pedaggicas.

98

Bibliografa
AMBYSOFT 2005 The Agile Unified Process (AUP). Material de enseanza. Consulta: 02 de junio de 2011. <http://www.ambysoft.com/unifiedprocess/agileUP.html>

AMERICAN PSYCHIATRIC ASSOCIATION (APA) 2000 Manual diagnstico y estadstico de los trastornos mentales. Cuarta edicin. Barcelona: Masson S.A.

COMPUTER AUTOMATION 2008 SEAS Special Education Management System. Documento tcnico. Consulta: 20 de marzo de 2010. <http://www.computerautomation.com/seasfeat.asp>

COMUNIDAD DE MADRID 2008 S.I.C.E. Sistema de Informacin de Centros Educativos de la Comunidad de Madrid. Manual de Usuario. Consulta: 20 de marzo de 2010. <http://www.madrid.org/cs/Satellite?c=CM_Actuaciones_FA&cid=114 2329550510&idConsejeria=1109266187254&idListConsj=110926544 4710&idOrganismo=1109167996735&language=es&pagename=Com unidadMadrid%2FEstructura&sm=1109266100977>

CONGRESO DE LA REPBLICA DEL PER 2011 Proyecto de Ley N 4707/2010-IC. Ley General de las Personas con discapacidad y de implementacin de la convencin sobre los derechos de las personas con discapacidad. 03 de abril.

DVILA, Abraham 2005 Pruebas, verificacin y validacin de software. Material de

enseanza. Lima: Pontifica Universidad Catlica del Per, Facultad de Ciencias e Ingeniera, Ingeniera Informtica, Grupo de

Investigacin y Desarrollo en Ingeniera de Software.

99

DIGITECHDATA PER 2011 EDUSYSNET Colegios. Documento tcnico. Consulta: 01 de junio de 2011. <http://www.edusysnet.pe>

EL COMERCIO 2012 El Per comercializar este ao ms tabletas que PC de escritorio. El Comercio. Lima, 22 de marzo. Consulta: 16 de septiembre. <http://elcomercio.pe/tecnologia/1391059/noticia-perucomercializara-este-ano-mas-tabletas-que-pc-escritorio> Ventas de smartphones y tabletas se duplicaron el primer semestre del 2012. El Comercio. Lima, 13 de septiembre. Consulta: 16 de septiembre. <http://elcomercio.pe/economia/1469010/noticia-ventassmartphones-tabletas-se-duplicaron-primer-semestre-2012>

2012

EQUIPO TAURE 1980 Educacin especial. Primera Edicin. Madrid: Editorial Cincel.

FREEMAN, Adam, Matthew MACDONALD y Mario SZPUSZTA 2011 Pro C# 2010 and the .NET 4 Platform. Quinta Edicin. Nueva York: Apress.

GOOGLE CODE 2009 Error Logging Modules and Handlers for ASP.NET. Documento tcnico. Consulta: 12 de julio de 2011. <http://code.google.com/p/elmah/>

HEWARD, William 2005 Exceptional Children: An Introduction to Special Education. Sptima Edicin. Nueva Jersey: Prentice Hall.

INSTITUCIN EDUCATIVA AUGUSTBRIGA 2007 Qu son adaptaciones curriculares?. Gua para la elaboracin de Adaptaciones Curriculares. Extremadura. Consulta: 05 de abril de 2010.

100

<http://iesaugustobriga.juntaextremadura.net/index.php?option=com_ content&view=article&id=42&Itemid=202>

LEADER SERVICES 2001 IEPWriter Online Special Education Data Management. Documento tcnico. Consulta: 20 de marzo de 2011. <http://www.iepwriter.com/>

LEFFINGWELL, Dean 2011 Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Primera edicin.

Massachusetts: Addison-Wesley Professional.

LERMAN, July 2010 Programming Entity Framework. Segunda Edicin. California: OReilly Media Inc.

MANCINI, Dave y David TROWBRIDGE 2003 Enterprise Solution Patterns Using Microsoft .Net: Version 2.0: Patterns & Practices. Primera Edicin. California: Microsoft Press.

MICROSOFT DEVELOPER NETWORK 2007 The Repository Pattern. Material de enseanza. Consulta: 05 de junio de 2011. <http://msdn.microsoft.com/en-us/library/ff649690.aspx>

MICROSOFT PATTERNS & PRACTICES TEAM 2009 NET Application Architecture Guide. Segunda Edicin. California: Microsoft Press.

MINISTERIO DE EDUCACIN DEL PER (Minedu) 2011 Sistema de Informacin de Apoyo a la Gestin en la Institucin Educativa. Manual de usuario. Consulta: 20 de marzo de 2011. <http://sistemas08.minedu.gob.pe/siagie2_36/>

2011

Manual de Usuario del SIAGIE v.2.0.1. Primera Edicin. Lima: Ministerio de Educacin.

101

MOLINA GARCA, Santiago 1990 Implicaciones del diseo curricular base para la educacin especial. Primera edicin. Zaragoza: Universidad de Zaragoza, Facultad de Educacin, Departamento de Ciencias de la Educacin.

ORGANIZACIN DE ESTADOS IBEROAMERICANOS (OEI) 1997 Seccin Educacin Especial en el Per. Documento de trabajo. Lima. Consulta: 14 de abril de 2012. <http://www.oei.es/quipu/peru/per12.pdf>

POSTGRESQL 2007 Npgsql - .Net Data Provider for PostgreSQL. Documento tcnico. Consulta: 12 de Julio de 2011. <http://npgsql.projects.postgresql.org/>

PRESSMAN, Roger 2002 Ingeniera del Software: un enfoque prctico. Quinta Edicin. Mxico D.F.: McGraw-Hill.

PROJECT MANAGEMENT INSTITUTE (PMI) 2008 Gua de los Fundamentos de la Direccin de Proyectos. Cuarta Edicin. Pennsylvania: Project Management Institute Inc.

SAN JOAQUIN COUNTY OFFICE OF EDUCATION 2004 SEIS Special Education Information System. Documento tcnico. Consulta: 22 de marzo de 2011. <http://www.seis.org/>

SNCHEZ MANZANO, Esteban 2001 Principios de Educacin Especial. Primera Edicin. Madrid: Ediciones CCS.

SUBSECRETARA DE EDUCACIN BSICA DEL GOBIENO DE MXICO (SEP) 2009 Sistema Integral de Informacin del Programa de Fortalecimiento de la Educacin Especial y de la Integracin Educativa. Manual de usuario. Consulta: 17 de marzo de 2012.

102

<http://www.educacionespecial.sep.gob.mx/pdf/manual/Manual_Siste ma_Info_PFEEIE.pdf>

SUNGARD 2002 IEPPLUS SunGard K-12 Education. Documento tcnico. Consulta: 23 de marzo de 2011. <http://www.sungard.com/en/sitecore/content/campaigns/corporate/pl us360/products/iepplus.aspx>

X2DEV CORPORATION 2010 X2 Aspen (X2 DEV). Documento tcnico. Consulta: 23 de marzo de 2011. <https://www.x2dev.net/pando/publicContent.do;jsessionid=000000?n avkey=products.aspen.detail>

ZEVALLOS, Ricardo 2005 Nuevas tecnologas y discapacidad en el Sistema Educativo Peruano. Trabajo de Consultora. Lima: Ministerio de Educacin del Per.

103