PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ 
FACULTAD DE CIENCIAS E INGENIERÍA 
 
 
  
 
 
 
 
ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE 
INFORMACIÓN APLICADO A LA GESTIÓN EDUCATIVA EN 
CENTROS DE EDUCACIÓN ESPECIAL 
 
 
 
Tesis para optar por el Título de Ingeniero Informático que presenta el bachiller: 
 
 
 
Raúl Miguel Romero Galindo 
 
 
 
ASESOR: Ing. Jose Antonio Pow Sang Portillo 
 
 
 
 
 
 
Lima, Setiembre de 2012
II 
RESUMEN 
 
Este proyecto consiste en el análisis, diseño e implementación de un sistema de 
información de apoyo a la gestión educativa en centros de educación especial. El 
propósito de esta plataforma es posibilitar la administración y atención de los planes 
curriculares funcionales (en adelante programas educativos) y terapéuticos para 
personas con necesidades especiales, así como consolidar el conocimiento de 
trastornos y promover la participación y evaluación continua entre padres y 
especialistas. 
 
La administración del proyecto adoptó las prácticas establecidas por el Project 
Management Institute. No obstante fueron recogidos un número específico de 
procesos de gestión según el alcance de la solución. Como metodología de 
desarrollo de software fue seleccionada la metodología Agile Unified Process (AUP) 
por su mayor afinidad y claridad de actividades en las etapas de diseño y 
construcción de este producto. 
 
Durante la concepción de la arquitectura se evaluaron múltiples patrones de 
arquitectura Web como MVC, MVP y N–capas resultando finalmente una estructura 
de cuatro capas con funciones específicas e independientes entre sí: manteniendo 
las capas de Presentación y Acceso a Datos separadas. Así como la capa de 
Lógica de negocio fue subdividida para la seguridad y navegabilidad entre las 
páginas (capa de Aplicación) como para conservación de las reglas de negocio 
(capa Lógica). 
 
La implementación fue llevada a cabo mediante el IDE Microsoft Visual Web 
Developer 2010 Express y el lenguaje de programación C# soportado bajo .NET 
Framework 4.0. Para la construcción de las páginas (capa de Presentación) se 
trabajó con ASP.NET Webforms y controles dinámicos de la librería Ajax Control 
Toolkit. La capa de Acceso a Datos fue construida bajo la tecnología Microsoft 
ADO.NET Entity Framework y en conexión con una base de datos PostgreSQL. 
 
Para la etapa de pruebas el servidor Web seleccionado fue Internet Information 
Services (IIS) Express 7.5 una réplica del servidor IIS 7.5  estándar diseñada para 
ambientes de desarrollo y sin restricciones de uso.  
  
III 
TEMA DE TESIS PARA OPTAR EL TÍTULO DE INGENIERO INFORMÁTICO 
 
TÍTULO:  ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA 
DE INFORMACIÓN APLICADO A LA GESTIÓN EDUCATIVA 
EN CENTROS DE EDUCACIÓN ESPECIAL 
ÁREA: Sistemas de Información 
PROPONENTE: Ing. Jose Antonio Pow - Sang Portillo 
ASESOR: Ing. Jose Antonio Pow - Sang Portillo 
ALUMNO: Raúl Miguel Romero Galindo 
CÓDIGO: 20030448 
TEMA  Nº: _______________ 
FECHA: San Miguel, 24 de marzo de 2008 
 
DESCRIPCIÓN 
En la actualidad las herramientas en tecnologías de información constituyen un 
factor de cambio determinante para el mejoramiento y desarrollo de las actividades 
del sector educación. En ese sentido, con el propósito de fortalecer la 
descentralización de la enseñanza y el intercambio de conocimiento hacia una 
mayor participación e interacción entre los actores alumno, padres y docentes, las 
instituciones educativas regulares (desde los centros de educación inicial, primaria 
y secundaria) han incorporado herramientas guía como apoyo a los alumnos en las 
tareas establecidas por los profesores durante el proceso de aprendizaje en línea 
desde los hogares, junto con la orientación a padres y/o tutores del alumno; es así 
como se refuerzan aspectos como la integración y participación de la familia en la 
educación del estudiante. 
 
Bajo la óptica anterior, este paradigma contemporáneo dentro de los sistemas de 
información encuentra un campo de acción en el marco de los procesos, 
actividades y tareas localizadas en centros de educación especial, caracterizada 
por cuanto involucra a personas con necesidades y habilidades especiales, 
producto de una discapacidad física, psíquica o sensorial. La complejidad del 
sistema educativo en mención parte del hecho en el cual la enseñanza es impartida 
por un staff multidisciplinario como médicos, psicólogos, fisioterapeutas, 
especialistas, asistentes sociales, especialistas en educación especial, entre otros; 
quienes establecen un plan de trabajo (según la especialidad y características del 
alumno) tanto para el alumno como para los familiares. 
IV 
 
Para afrontar esta problemática los centros de educación especial requieren de una 
herramienta en gestión de la educación descentralizada, con capacidad de proveer 
a los usuarios y especialistas información clasificada por áreas de acuerdo al perfil 
profesional de los especialistas. A su vez efectuar una evaluación y análisis de 
avances y problemas encontrados durante el proceso de enseñanza y la capacidad 
de generar automáticamente un plan de acción/entrenamiento como sustento 
metodológico de la labor educativa. Por tanto se plantea la implementación de un 
sistema Web para la gestión pedagógica en centros de educación especial dirigido 
a especialistas, padres y/o tutores de familia. 
 
OBJETIVO GENERAL 
El objetivo del proyecto es analizar, diseñar e implementar un sistema de 
información Web orientado a la gestión educativa de un centro de educación 
especial, que brinde soporte a las labores y actividades pedagógicas efectuadas 
por los especialistas de esta institución.  
 
OBJETIVOS ESPECÍFICOS 
Los objetivos específicos del proyecto son: 
 Elaborar el análisis y diseño del sistema de información a implementar, 
basándose en los requerimientos de la organización educativa. 
 Seleccionar y definir la arquitectura bajo la cual se implementará el sistema 
Web que le permita a esta ser portátil y escalable en el tiempo. 
 Elaborar un modelo de base de datos relacional que se acomode a los 
requerimientos de almacenamiento y manipulación de datos de la institución 
educativa en cuestión. 
 Diseñar una Interfaz gráfica 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 
información a implementar, así como también garantizar un canal de flujo de 
información a través de Internet que sea seguro. 
 
ALCANCE 
 El sistema permitirá realizar la autenticación y autorización de los usuarios a las 
diversas funcionalidades proporcionadas por el sistema. 
V 
 El sistema permitirá generar automáticamente el documento con el plan de 
capacitación (plan curricular funcional) del joven especial, especificando las 
terapias, tipos de terapias y especialistas así como el cronograma de 
capacitación o plan de actividades específicas por cada alumno especial. 
Asimismo posibilitará el mantenimiento y actualización continua del plan de 
aprendizaje y tareas para el alumno especial 
 El sistema permitirá el registro y mantenimiento de información pertinente de los 
estudiantes con habilidades especiales, así como la actualización de la 
información clínica pertinente y que determinan su condición de salud en la 
actualidad. 
 El sistema permitirá el acceso y consulta de información académica 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 
elaboración del registro de notas a padres, control de asistencia, planificación 
de clases, reportes de aprendizaje del alumno, entre otros. 
 El sistema permitirá el registro de un informe o bitácora semanal al cual podrán 
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 
planificación de horarios. 
  
VI 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
A Dios, por la fuerza y la fe para culminar este proyecto importante de mi vida. 
 
A Raúl, 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 compañía y afecto: ver transcurrir los días 
y noches a su lado colman mi vida de equilibrio, paz y alegría sin fin. 
 
A todos aquellos quienes encuentran en la ciencia, tecnología e investigación 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 
corazón, 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 
incólume esperanza por volver. 
  
VII 
Agradecimiento 
 
A través de estas líneas expreso mi profundo agradecimiento al Ing. Jose Antonio 
Pow Sang por su contribución 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 Ingeniería Informática y a mi alma 
máter PUCP, porque durante los cinco años y medio de estudios forjaron en mí los 
saberes supremos de carácter científico y humanístico, transformándome en un 
mejor y auténtico ser humano para la vida. 
 
  
VIII 
ÍNDICE GENERAL 
 
Introducción .............................................................................................................................. 1 
1. CAPÍTULO 1: Generalidades ........................................................................................ 3 
1.1. Definición de Problema ..................................................................................... 3 
1.2. Marco Conceptual ............................................................................................. 6 
1.2.1. Educación Especial ........................................................................... 6 
1.2.2. Discapacidad ..................................................................................... 7 
1.2.3. Diseño curricular ................................................................................ 7 
1.2.4. Necesidades Educativas Especiales ................................................. 8 
1.2.5. Adaptación curricular ......................................................................... 8 
1.2.6. DSM-IV .............................................................................................. 8 
1.2.7. La Educación Especial en el Perú ..................................................... 8 
1.3. Plan del Proyecto .............................................................................................. 9 
1.3.1. Metodología y procedimiento ............................................................ 9 
1.3.2. Planificación ..................................................................................... 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 Gestión Educativa ....................................................... 23 
1.4.2. Sistemas de Gestión Educativa en Educación Especial ................. 25 
1.4.3. Resumen comparativo de las soluciones ........................................ 30 
1.5. Descripción y sustentación de la solución ...................................................... 34 
2. CAPÍTULO 2: Análisis.................................................................................................. 38 
2.1. Definición de la metodología de solución ....................................................... 38 
2.1.1. Rational Unified Process (RUP) ...................................................... 38 
2.1.2. Agile Unified Process (AUP) ............................................................ 39 
2.1.3. Elección de la metodología ............................................................. 40 
2.2. Identificación 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. Análisis de la solución ..................................................................................... 49 
2.3.1. Identificación de las necesidades del cliente .................................. 50 
2.3.2. Viabilidad técnica y económica ....................................................... 51 
2.3.3. Análisis Costo – Beneficio ............................................................... 54 
2.3.4. Asignación de funciones a hardware y software ............................. 55 
2.3.5. Restricciones de costo y tiempo ...................................................... 56 
2.3.6. Definición del sistema ...................................................................... 57 
3. CAPÍTULO 3: Diseño ................................................................................................... 62 
3.1. Arquitectura de la solución .............................................................................. 62 
3.1.1. Representación de la arquitectura................................................... 62 
3.1.2. Evaluación ....................................................................................... 63 
3.1.3. Diseño de la arquitectura de la solución ......................................... 66 
3.1.4. Vista Lógica ..................................................................................... 69 
3.1.5. Vista de Despliegue ......................................................................... 69 
3.1.6. Diagrama de clases de diseño ........................................................ 70 
3.1.7. Diagrama de base de datos ............................................................ 73 
3.1.8. Diagramas de secuencia ................................................................. 75 
3.2. Diseño de Interfaz Gráfica .............................................................................. 77 
3.2.1. Estándar de Interfaz Gráfica ............................................................ 77 
3.2.2. Consideraciones finales .................................................................. 79 
4. CAPÍTULO 4: Construcción ......................................................................................... 81 
4.1. Construcción ................................................................................................... 81 
4.1.1. Framework de desarrollo ................................................................. 81 
4.1.2. Lenguaje de programación .............................................................. 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 
IX 
4.1.7. Otras herramientas y librerías ......................................................... 87 
4.2. Pruebas ........................................................................................................... 88 
4.2.1. Estrategia de Pruebas ..................................................................... 88 
4.2.2. Tipos de Pruebas............................................................................. 90 
4.2.3. Catálogo de pruebas ....................................................................... 91 
4.2.4. Reporte de ejecución de pruebas.................................................... 93 
5. CAPÍTULO 5: Observaciones, conclusiones y recomendaciones .............................. 95 
5.1. Observaciones ................................................................................................ 95 
5.2. Conclusiones ................................................................................................... 96 
5.3. Recomendaciones y trabajos futuros ............................................................. 98 
Bibliografía ............................................................................................................................. 99 
  
X 
Índice de Ilustraciones 
 
Figura 1.1 Esquema de Diseño Curricular (Molina 1990) ........................................................ 7 
Figura 1.2 Grupos de Procesos de Proyecto (PMI 2008) ........................................................ 9 
Figura 1.3 Grupo del Proceso de Iniciación ........................................................................... 10 
Figura 1.4 Grupo del Proceso de Planificación...................................................................... 11 
Figura 1.5 Grupo del Proceso de Ejecución .......................................................................... 12 
Figura 1.6 Ciclo de vida de desarrollo de software según 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 descomposición 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 análisis – Módulo Seguridad ........................................... 58 
Figura 2.5 Diagrama de clases de análisis – Módulo Alumnos ............................................. 58 
Figura 2.6 Diagrama de clases de análisis – Módulo Comunicaciones ................................ 59 
Figura 2.7 Diagrama de clases de análisis – Módulo Organización ...................................... 59 
Figura 2.8 Diagrama de clases de análisis – Módulo Planeamiento ..................................... 60 
Figura 2.9 Diagrama de clases de análisis – Módulo Evaluaciones...................................... 60 
Figura 3.1 Patrón de arquitectura MVC (Mancini 2003) ........................................................ 65 
Figura 3.2 Patrón de arquitectura en N-Capas (Mancini 2003) ............................................. 65 
Figura 3.3 Diagrama de componentes de la arquitectura ...................................................... 67 
Figura 3.4 Vista lógica del sistema ........................................................................................ 69 
Figura 3.5 Diagrama de despliegue ....................................................................................... 70 
Figura 3.6 Diagrama de clases de diseño - Módulo Organización ........................................ 71 
Figura 3.7 Diagrama de clases de diseño - Módulo Planeamiento ....................................... 72 
Figura 3.8 Diagrama de clases de diseño - Módulo 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 asignación de objetivos a actividad .... 76 
Figura 3.12 Diagrama de secuencia del proceso de toma de asistencia .............................. 76 
Figura 3.13 Patrón de diseño gráfico del sistema ................................................................. 77 
Figura 3.14 Pantalla de Ingreso al Sistema ........................................................................... 78 
Figura 3.15 Pantalla de Búsqueda de Documentos .............................................................. 79 
Figura 3.16 Pantalla de Mantenimiento de Programas ......................................................... 79 
Figura 4.1 Componentes de .NET Framework 4.0 (Freeman 2011) ..................................... 82 
 
  
XI 
Í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 diseño vs. Solución arquitectónica ......................................... 68 
Tabla 4.1 Modelo de Caso de Prueba Unitaria ...................................................................... 90 
Tabla 4.2 Catálogo de pruebas del sistema .......................................................................... 91 
  
1 
Introducción 
 
Este proyecto de tesis tiene por finalidad presentar una solución informática dirigida 
a la problemática presente actualmente en la gestión educativa de centros de 
educación especial del país. Dicha solución posibilitará la administración de 
información vinculada a los alumnos, familias y especialistas de la institución desde 
las terapias, programas, actividades y tareas asignadas en función a los trastornos 
padecidos. 
 
A largo plazo el objetivo esperado con este proyecto es implantarlo en una red de 
centros de educación 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 diseñados por estas 
instituciones. A su vez apoyaría la descentralización de la gestión educativa a 
organismos y asociaciones no gubernamentales con obstáculos en la cobertura de 
servicios educativos hacia otras localidades (por restricciones geográficas, 
económicas, logísticas o de carencia de profesionales en educación especial en las 
regiones). Ambos contextos en la última década no han sido ajenos a la realidad 
educativa peruana: si bien aparecen novedosos sistemas de información de gestión 
pedagógica en línea, su mercado objetivo comprende instituciones de educación 
regular (inicial, primaria, secundaria y universitaria) privando en cambio a los 
centros de educación especial de los beneficios y oportunidades de automatización 
de sus procesos mediante las tecnologías de información, prolongando aún más la 
espera de una auténtica y ambiciosa reforma en el sistema educativo tecnológico 
peruano. Este trabajo se divide en cinco capítulos descritos a continuación: 
  
El primer capítulo explica los alcances conceptuales y teóricos con respecto a la 
problemática a tratar. Seguidamente se presentan las soluciones alternativas y los 
alcances de la nueva solución junto con el plan de proyecto. 
 
El segundo capítulo explica la metodología de desarrollo de sistemas elegida y 
presenta el análisis de la solución considerando el análisis de requerimientos y 
fundamentos de viabilidad. 
 
El tercer capítulo presenta el diseño arquitectónico de la solución, describiendo las 
funciones de sus principales componentes así como los criterios para la 
construcción de la interfaz gráfica. 
  
2 
 
El cuarto capítulo sustenta las decisiones a nivel técnico en la elección de las 
tecnologías utilizadas para la implementación de la solución así como la estrategia 
y métodos de pruebas ejecutados. 
 
Por último, el quinto capítulo reúne las observaciones, conclusiones y 
recomendaciones sobre trabajos futuros derivados a partir de este trabajo. 
  
  
3 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1. CAPÍTULO 1: Generalidades 
 
En este capítulo se presentan el contexto y marco conceptual de la problemática a 
la cual se dará solución para su entendimiento. De esta manera, el lector 
comprenderá el escenario real y deseado con la solución propuesta y sus alcances 
contrastando además con otras soluciones existentes. Asimismo se presentan la 
planificación de tareas y actividades a ser realizadas, culminando con la descripción 
de la solución por implementar. 
 
1.1. Definición de Problema 
 
Con la aparición de nuevas y mejores herramientas en tecnologías de información 
orientadas a la automatización 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 
educación. Las instituciones educativas regulares (en los niveles de educación 
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 línea desde los hogares junto con la orientación a padres y/o 
tutores. Por otra parte, las universidades vienen asignando anualmente mayores 
  
4 
recursos para implantar plataformas educativas en paralelo a sus procesos 
habituales de enseñanza como el Sistema de Gestión de Aprendizaje Moodle 
implantado en las universidades ESAN (como EsanVirtual) y la PUCP (como 
Paideia PUCP). Otras instituciones amplían sus servicios hacia los usuarios sobre 
su plataforma tecnológica base (mediante la implementación de aplicaciones de 
propósito específico destinadas para dispositivos móviles); lo anterior aplica 
actualmente en las principales escuelas de negocios del país. Desde hace algunos 
años viene ocurriendo un incremento en la demanda de equipos de cómputo 
portátiles a diferencia de los equipos de escritorio (El Comercio 2012). Este 
escenario demuestra la alta demanda de los usuarios a servicios y aplicaciones en 
línea, siendo el rubro educativo uno de los más competitivos en el mercado del 
software. 
 
En el caso de los centros de educación especial (y por ende la educación especial 
en el Perú como tal) encuentra un desfase en las políticas de aprovechamiento de 
las Tecnologías de Información y Comunicación (TIC). Estas instituciones trabajan 
con los alumnos en base a una metodología flexible, interactiva, personalizada y no 
estrictamente sujeta a un currículo fijo y único para todos sus participantes. El 
ámbito de la educación especial se vale de perfiles y antecedentes clínicos, 
psicológicos y psiquiátricos para el establecimiento de programas de enseñanza y 
terapias del alumno, previa evaluación al postulante. La complejidad de este 
sistema educativo se incrementa durante la fase de entrenamiento por cuanto 
comprende un staff de especialistas (médicos, psicólogos, fisioterapeutas, 
psiquiatras, educadores y otros) para un único alumno. 
 
Para esta labor es importante la cooperación familiar, por ello regularmente en los 
centros educativos se organizan dinámicas 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 calificación 
acorde a su desempeño y pautas a considerar para futuras capacitaciones y 
entrenamientos. 
 
Con una frecuencia semanal o quincenal los especialistas envían 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 
  
5 
recomendaciones como parte de su evaluación. Este documento constituye un 
importante y único medio de comunicación físico entre la familia y el centro 
educativo especial para el registro de los avances y problemas presentados. 
 
Actualmente un número importante de centros educativos especiales no disponen 
de un sistema capaz de brindar información pertinente de las labores pedagógicas 
apropiadamente. Existen casos donde la generación de los programas de 
capacitación y entrenamiento, junto con la actualización y evaluación 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 información de los 
alumnos es recopilada periódica y manualmente en formatos físicos junto con los 
avances progresivos, a falta de un medio automático para el control de cambios de 
los programas educativos desde los primeros años de estudios en el centro. Las 
observaciones y sugerencias de los especialistas son redactadas a mano y, debido 
a la alta rotación de especialistas, la información preliminar es susceptible de 
pérdida u olvido en los almacenes y oficinas. Este escenario se agrava cuando los 
centros carecen de información científica especializada y actualizada de los 
trastornos psicológicos tratados, impactando negativamente en el diagnóstico y 
tratamiento posterior de los estudiantes. Otra problemática existente ocurre en la 
planificación de las tareas y actividades pedagógicas, debido a la ausencia de un 
eficiente procedimiento de calendarización de tareas y horarios de atención entre 
los mismos especialistas.  
 
Estos centros requieren contar con una herramienta de gestión educativa de 
carácter descentralizada como apoyo al staff de profesionales de los centros 
educativos, cuyas herramientas faciliten la actualización de información de los 
avances y problemas encontrados durante el proceso de enseñanza en los jóvenes 
especiales, así como generar automáticamente un programa de entrenamiento 
supervisado por los padres en línea aplicables durante el entrenamiento en el 
hogar. Adicionalmente esta herramienta haría posible el mantenimiento de distintos 
trastornos psiquiátricos y escalas de severidad correlacionándolas a un conjunto de 
terapias aplicables en base a la escala de los trastornos. Se constituiría además 
como un medio de comunicación 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 
  
6 
de un sistema de gestión educativa. Mientras otras instituciones trabajan sobre una 
base tecnológica limitada a tareas ofimáticas. 
 
Los pobres niveles de desempeño operativo existentes en muchos centros 
educativos especiales guardan relación directa con la carencia de un medio 
automatizado de administración de programas educativos y de la información de 
alumnos, trastornos y terapias. Por tanto, en este proyecto de tesis se implementará 
un sistema Web orientado a la gestión educativa en los centros de educación 
especial. 
 
1.2. Marco Conceptual 
 
En esta sección se amplía el marco teórico base para el desarrollo y comprensión 
de la temática de este proyecto de fin de carrera. 
 
1.2.1. Educación Especial 
 
Se define como un “proceso integral, flexible y dinámico de las orientaciones, 
actividades y atenciones cuya aplicación comprende los diferentes niveles y grados 
en sus respectivas modalidades” para la superación de las deficiencias y 
encaminadas a conseguir la integración social (Equipo Taure 1980). 
 
Otra acepción la presenta como “una educación ordinaria con características 
propias y dirigida a sujetos excepcionales, es decir, sujetos quienes por defecto o 
exceso han de participar en programas especiales para su integración en la escuela 
ordinaria” (Sánchez 2001).  
 
Heward amplia el concepto hacia “una instrucción individualmente planeada, 
sistemáticamente 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 línea los programas educativos, sesiones y servicios diseñados para 
desarrollar el potencial educativo de los niños con discapacidades involucran la 
participación conjunta de un amplio staff de profesionales desde trabajadores 
sociales, psicólogos, enfermeros, educadores, entre otros. 
 
  
7 
1.2.2. Discapacidad 
 
Las Naciones Unidas (Zevallos 2005) reconocen este término como “la forma de 
una deficiencia física, intelectual o sensorial, una dolencia atendida clínicamente o 
una enfermedad mental de carácter permanente o transitoria”. 
 
La ley peruana en su artículo 2º define a la persona con discapacidad como 
“aquella con una o más deficiencias evidenciadas con la pérdida significativa de 
alguno o algunas de sus funciones físicas, mentales o sensoriales (…) la 
disminución o ausencia de la capacidad de realizar una actividad dentro de las 
formas o márgenes considerados normales” (Congreso de la República del Perú 
2011). 
 
Los alumnos integrantes de un centro educativo especial presentan considerables 
déficits a nivel biológico como estado de salud debilitado, nivel de conciencia 
inferior, ausencia de habla y movilidad voluntaria deficiente. 
 
1.2.3. Diseño curricular 
 
Según Brennan (Molina 1990) el diseño curricular debe compatibilizar entre una 
serie de áreas curriculares comunes a los alumnos con distintos niveles de 
aprendizaje en función a la experiencia, actitudes e incluso por las competencias 
cognitivas del alumno, conforme muestra la figura 1.1. 
 
 
Figura 1.1 Esquema de Diseño Curricular (Molina 1990) 
 
Para Brennan el diseño y construcción de un marco de trabajo conformado por las 
características anteriores no puede ser determinado por el Ministerio de Educación 
sino debe involucrar a los especialistas y las familias considerando la infraestructura 
del centro educativo y las necesidades educativas variables de los estudiantes. 
Funcional
Contextual
EXPERIENCIA ACTITUDES
Podría
Debería
Directa Presente
Ha de
Transmitida Apreciada
  
8 
 
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 educación a diferencia de otros de su misma edad (Sánchez 2001). 
 
1.2.5. Adaptación curricular 
 
Una adaptación curricular reúne estrategias de apoyo al proceso de enseñanza – 
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, motivación, ritmo de aprendizaje, 
entre otros (Augustóbriga 2007). Se trata de todo ajuste efectuado sobre el currículo 
educativo propio de los alumnos con necesidades educativas especiales. 
 
1.2.6. DSM-IV 
 
El DSM-IV (APA 2000) es una clasificación categorial de los trastornos mentales en 
diversos tipos basándose en series de criterios con rasgos definitorios. La 
formulación de categorías es el método habitual de organizar y transmitir 
información en la vida diaria y ha sido el enfoque fundamental empleado en todos 
los sistemas de diagnóstico médico. El DSM-IV contempla como trastornos del 
aprendizaje una serie de dificultades en el aprendizaje de las habilidades 
académicas, particularmente lectura, cálculo y expresión escrita. 
 
1.2.7. La Educación Especial en el Perú 
 
Desde la Ley de Reforma Educativa del Perú del año 1971 hasta la fecha, es el 
Estado responsable de “estimular y apoyar la educación especial” velando por su 
inclusión social y laboral haciendo valer sus derechos y deberes (OEI 1997). 
 
Desde el año 1971 a la fecha se ha incrementado el número de centros de 
educación especial hasta superar los trescientos setenta (370) distribuidos entre 
programas de Intervención Temprana (PRITE), centros de educación básica 
especial (CEBE), centros de recursos de EBE (CREBE), servicios de apoyo  y  
asesoramiento a las necesidades educativas especiales (SAANEE). Sin embargo 
  
9 
aún la cobertura de la población excepcional estimada alcanzaba solamente el 
1.2% hacia 1997 (OEI 1997). 
 
1.3. Plan del Proyecto 
 
En esta sección se describe la metodología y procedimiento adoptados para llevar a 
cabo la administración del proyecto de fin de carrera, así como del ciclo de 
desarrollo del producto software. Seguidamente se presenta la estructura de 
descomposición del trabajo (EDT) y el cronograma de actividades. 
 
1.3.1. Metodología y procedimiento  
 
Para la gestión de este proyecto se tomarán como lineamientos base los 
fundamentados descritos en la cuarta edición del libro “A Guide to the Project 
Management Body of Knowledge” (PMBOK) elaborado por el Project Management 
Institute (PMI), para la gestión 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 gestión de proyectos. 
 
Figura 1.2 Grupos de Procesos de Proyecto (PMI 2008) 
  
Como parte del proceso de ejecución se tiene previsto seguir las pautas de la 
metodología Agile Unified Process (AUP) vinculada a las fases de Elaboración y 
Construcción del producto software, por cuanto los entregables requeridos por esta 
metodología son adaptables a la realidad y tiempo de vida del proyecto y 
correspondientes con la naturaleza de la solución informática objetivo; junto con la 
existencia de un mayor número de herramientas de código abierto, destinadas al 
  
10 
modelamiento de sistemas en notación UML generando los artifacts RUP 
necesarios para las fases de análisis y diseño. 
 
Sin embargo conviene limitar el ámbito de procesos de gestión para el presente 
trabajo, adoptando una parte de estos entregables según la necesidad del proyecto. 
En ese sentido se presentará la relación de procesos seleccionados, clasificados 
por grupos de procesos, junto con las justificaciones del caso. Se trabajará con los 
fundamentos de la cuarta edición del PMBOK vigente desde el año 2008 (PMI 
2008). 
 
1.3.1.1. Grupo del Proceso de Iniciación 
 
Este grupo tiene como propósito definir el proyecto a realizar anexando el alcance 
global (funcional y técnico), especificando los recursos económicos y/o tecnológicos 
e identificando a los interesados en el proyecto. De acuerdo con la figura 1.3 los 
procesos involucrados en este grupo son: 
 
 
Figura 1.3 Grupo del Proceso de Iniciación 
  
Para propósitos de esta tesis en este grupo se adoptará el proceso 1.1 por cuanto 
este proceso incorpora la documentación 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 Planificación 
 
El propósito de este grupo es establecer el alcance total en términos de esfuerzo y 
objetivos, así como la modalidad del trabajo en la gestión y finalmente desarrolla la 
línea de acción para completar tales objetivos. Se establece un plan de dirección y 
los documentos a ser utilizados para llevarla a cabo.  
 
En esta etapa se profundiza el análisis en términos de calidad, riesgo, costo y 
alcance. Los procesos involucrados en este grupo se presentan a continuación en 
la figura 1.4: 
1.1. Desarrollar 
Acta de 
Constitución del 
Proyecto
1.2. Identificar 
interesados
  
11 
 
Figura 1.4 Grupo del Proceso de Planificación 
 
Para propósitos de esta tesis los procesos vinculados con la Gestión de Calidad 
(2.12), Gestión de Recursos Humanos (2.13), Gestión de Comunicaciones (2.14), 
Gestión de Adquisiciones (2.20) y Gestión de Costos (2.10 y 2.11) no serán 
tomados en cuenta para la documentación final debido a la oportuna identificación 
de los recursos humanos, logísticos e informáticos específicos para el trabajo y su 
administración y seguimiento no demandarán para el autor de una mayor 
complejidad. 
 
En cambio si es importante para fines de planificación definir las acciones y la 
modalidad sobre cómo planificar, ejecutar, supervisar, controlar y cerrar el proyecto 
(2.1), documentar los requerimientos y necesidades obtenidos una vez identificados 
(2.2), elaborar la descripción 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 definición del EDT (o Estructura de Descomposición 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 
calendarización (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, 
cuánta 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 especificación de las actividades a efectuar en la 
gestión de riesgos (2.15), identificar y documentar los riesgos y características 
(2.16), establecer la priorización de riesgos en términos probabilísticos y medir sus 
2.1. Desarrollar el 
Plan para la 
Dirección del 
Proyecto
2.2. Recolectar 
requerimientos
2.3. Definir el 
Alcance
2.4. Crear la EDT
2.5. Definir las 
Actividades
2.6. Secuenciar las 
Actividades
2.7. Estimar los 
Recursos de las 
Actividades
2.8. Estimar la 
Duración de las 
Actividades
2.9. Desarrollar el 
Cronograma
2.10. Estimar 
Costos
2.11. Determinar el 
Presupuesto
2.12. Planificar la 
Calidad
2.13. Desarrollar el 
Plan de Recursos 
Humano
2.14. Planificar las 
Comunicaciones
2.15. Planificar la 
Gestión de Riesgos
2.16. Identificar 
Riesgos
2.17. Realizar 
Análisis Cualitativo 
de Riesgos
2.18. Realizar 
Análisis Cuantitativo 
de Riesgos
2.19. Planificar la 
Respuesta a los 
Riesgos
2.20. Planificar las 
Adquisiciones
  
12 
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) blindarán al proyecto ante posibles incidentes. 
 
1.3.1.3. Grupo del Proceso de Ejecución 
 
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: 
 
Figura 1.5 Grupo del Proceso de Ejecución 
 
El control de la calidad no amerita de un tratamiento amplio a nivel documentario 
(con excepción de las pruebas de verificación y validación del producto), así como 
la conformación 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 
demandarán grandes esfuerzos dadas las especificaciones limitadas del producto 
final, así como un control fino de los medios de información y distribución de 
información. Por tanto solamente se abarcará la ejecución del proceso 3.1, en 
definitiva representa la ejecución del trabajo técnico y funcional. 
 
PMBOK reúne las buenas prácticas en gestión de proyectos pertenecientes a 
múltiples áreas y disciplinas, pero para propósitos de un proyecto de software es 
determinante adoptar una metodología de apoyo y orientada a proyectos de corte 
informático, tomando en cuenta el ciclo habitual de desarrollo de sistemas y 
reflejando los avances en las fases de análisis y diseño para todos los entregables, 
diagramas y productos finales. Frente a estos propósitos, la metodología AUP 
abarca, además de un conjunto de procedimientos y herramientas dirigidos a un 
correcto modelamiento del negocio durante el ciclo de vida de desarrollo del 
3.1. Dirigir y 
Gestionar la 
Ejecución del 
Proyecto
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.8. Efectuar 
Adquisiciones
3.6. Distribuir la 
Información
3.7. Gestionar las 
Expectativas de los 
Interesados
  
13 
software, un marco de trabajo de buenas prácticas para la etapa de construcción 
del software (Leffingwell 2011). Su elección y justificación como metodología de 
desarrollo de software se profundizan en el siguiente capítulo. 
 
Como se observa en la figura 1.6 la metodología presenta cuatro fases 
denominadas Iniciación, Elaboración, Construcción y Transición. El modelamiento 
de sistemas en base a los requerimientos se procesa en la primera fase. La 
Elaboración es un hito de importancia porque aquí se define formalmente la 
arquitectura de producto. Más adelante se detallan los riesgos técnicos resueltos y 
genera un primer prototipo para revisión del usuario. De igual forma, en la fase de 
Construcción se trabaja en la realización de un producto totalmente operativo y 
eficiente, acorde con los lineamientos y patrones definidos por el equipo de 
desarrolladores. La etapa de Construcción constará de siete iteraciones (una por 
cada módulo del sistema) donde cada iteración tendrá como hito una versión 
preliminar del producto incorporando, por cada entrega, nuevas funcionalidades de 
la herramienta hasta la versión definitiva. Como conclusión, esta metodología 
presenta un comportamiento iterativo-incremental. Para mayores alcances, revisar 
el Capítulo 2. 
  
Figura 1.6 Ciclo de vida de desarrollo de software según AUP (Leffingwell 2011) 
 
1.3.1.4. Grupo del Proceso de Seguimiento y Control 
 
Este grupo de procesos tiene como propósito 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 
líneas generales se busca controlar lo planificado como costos, tiempos y avance, 
así como la calidad de la solución y el seguimiento de riesgos. De la misma 
manera, se controlará la evolución del producto software. Los procesos 
involucrados en este grupo se muestran en la figura 1.7: 
  
14 
 
Figura 1.7 Grupo del Proceso de Seguimiento y Control 
  
En este grupo el proceso 4.1 se adoptará para medir y monitorear el desempeño 
contrastando con lo estipulado a nivel de alcance, el cronograma de actividades y 
riesgos. Actualmente se cuenta con métodos 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 
revisión y evaluación del impacto afectan directamente a los activos del proyecto, 
documentación y al plan de la dirección del proyecto, por lo cual el proceso 4.2 
cumplirá para tales fines. Como lo anterior implica la verificación 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 formarán parte de la gestión.  
 
Los procesos 4.5 y 4.9 trabajarán conjuntamente en el seguimiento del cronograma, 
detectando posibles retrasos y desfases entre actividades y tiempos, proponiendo 
medidas para el aprovechamiento de oportunidades y mitigación 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 
verificación global de las actividades completadas como preámbulo a la culminación 
4.1. Dar Seguimiento y 
Controlar el Trabajo 
del Proyecto
4.2. Realizar Control 
Integrado de Cambios
4.3. Verificar el 
Alcance
4.4. Controlar el 
Alcance
4.6. Controlar Costos
4.7. Realizar Control 
de Calidad
4.8. Informar el 
Desempeño
4.9. Dar Seguimiento y 
Controlar los Riesgos
4.10. Administrar las 
Adquisiciones
4.5. Controlar el 
Cronograma
  
15 
formal de una etapa o proyecto. En el marco de este proyecto un cierre 
representará tanto la culminación 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 Ingeniería. La figura 1.8 muestra los procesos involucrados 
en este grupo: 
 
 
Figura 1.8 Grupo del Proceso de Cierre 
 
Para este proyecto se contará con el proceso 5.1 entendido como la conclusión 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 Ingeniería 
y posterior sustentación ante el jurado calificador.  
 
1.3.2. Planificación 
 
Se presentan a continuación los siguientes diagramas con la planificación del 
proyecto para los próximos 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 académico 2008-1.  
 
En cambio la entrega de la solución informática completa y operativa junto con el 
documento de tesis y anexos actualizados y los resultados de las pruebas está 
pactada para fines del año 2011. La prolongación del tiempo de entrega del 
proyecto obedece a razones de índole laboral y académica de responsabilidad del 
tesista. 
 
5.1. Cerrar el 
Proyecto o Fase
5.2. Cerrar las 
Adquisiciones
  
16 
 
Figura 1.9 Estructura de descomposición del trabajo del proyecto
  
17 
 
Figura 1.10 Diagrama de Gantt – Cronograma de proyecto Fase I 
  
18 
 
Figura 1.11 Diagrama de Gantt – Cronograma de proyecto Fase II 
  
19 
 
1.3.3. Riesgos del Proyecto 
 
En secciones previas se justificaron las razones por las cuales era imprescindible 
mantener una correcta gestión de riesgos y planes de acciones para encarar 
cualquier incidente imprevisto durante el desarrollo del trabajo. A continuación,  en 
base a la experiencia profesional del tesista, se presenta una relación de posibles 
eventos los cuales de presentarse provocarían retrasos o desfases en el normal 
avance del trabajo. 
 
En el PMBOK se define el término 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 técnicos, de calidad y/o rendimiento: Este grupo se encuentra 
presente durante las actividades de diseño y desarrollo del producto deseado y 
en donde intervienen aspectos de carácter técnico en su elaboración y control 
de calidad.  
 Riesgos en la gerencia de proyectos: Son riesgos presentes en parte de los 
procesos de gestión y dirección llevados a cabo. Su manejo queda bajo la 
responsabilidad del equipo del proyecto. 
 Riesgos organizacionales: Son riesgos provenientes de la misma 
organización 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 gestión de riesgos. 
 Riesgos externos: Son riesgos presentes en el ámbito exterior (entorno) de la 
organización. Para fines de este proyecto este grupo no aplicará para la gestión 
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 clasificación de cada dimensión se asumieron las escalas mostradas en las 
tablas 1.1, 1.2 y 1.3. 
 20 
Tabla 1.1 Escalas de 
Medida de Probabilidad 
 
 
 
Tabla 1.2 Escala de 
Medida de Impacto 
 
Impacto 
Rango Descripción 
0.00 a 0.25 Muy Leve 
0.26 a 0.50 Leve 
0.51 a 0.75 Moderado 
0.76 a 1.00 Severo 
 
Tabla 1.3 Escala de 
Severidad 
 
Severidad 
Rango Descripción 
0.00 a 0.25 Muy baja 
0.26 a 0.50 Baja 
0.51 a 0.75 Media 
0.76 a 1.00 Alta 
Tabla 1.4 Riesgos del Proyecto 
Grupo de 
Riesgos 
Riesgo 
(R) 
Probabilidad 
(P) 
Impacto 
(I) 
Severidad 
(PXI) 
Riesgos 
técnicos, de 
calidad y/o 
rendimiento 
Curva de aprendizaje en 
herramientas de desarrollo de 
sistemas prolongada. 
0.25 0.50 0.13 
Demora en la presentación de 
los entregables. 
0.65 0.75 0.49 
Desconocimiento en 
herramientas de desarrollo 
genera retrasos en la 
implementación. 
0.55 0.60 0.33 
Diseño muy complejo e 
ininteligible para las actividades 
de implementación. 
0.55 0.65 0.36 
Exclusión de artifacts de 
software considerados 
importantes para una mejor 
documentación del análisis y 
diseño. 
0.35 0.55 0.19 
La arquitectura propuesta no va 
acorde a las especificaciones 
del diseño. 
0.35 0.70 0.25 
Las librerías nativas de la 
plataforma de programación son 
incompatibles con algunas 
bases de datos. 
0.40 0.85 0.34 
Metodología mal aplicada en el 
análisis y diseño del sistema y la 
base de datos. 
0.45 0.70 0.32 
Ausencia de buenas prácticas 
en programación. 
0.25 0.65 0.16 
No se cuenta con un estándar 
de programación ni diseño 
apropiado. 
0.25 0.50 0.13 
Plan de pruebas no cubre 
adecuadamente todas las 
funcionalidades de la aplicación. 
0.45 0.70 0.32 
Pobre análisis y/o diseño no 
satisface correctamente los 
requerimientos. 
0.35 0.70 0.25 
Infraestructura informática de 
bajo rendimiento para la 
construcción. 
0.35 0.70 0.25 
Riesgos en la 
Gerencia de 
Proyectos 
Alta volatilidad y cambios en los 
requerimientos durante el 
proyecto. 
0.55 0.80 0.44 
Estimación errática en la 
duración de algunas 
0.85 0.90 0.77 
Probabilidad 
Rango Descripción 
0.00 a 0.25 Muy Baja 
0.26 a 0.50 Baja 
0.51 a 0.75 Media 
0.76 a 1.00 Alta 
  
21 
actividades. 
Incumplimiento en los plazos de 
entrega de iteraciones y versión 
final del producto. 
0.65 0.75 0.49 
El estudio de viabilidad técnica-
económica presenta 
inconsistencias. 
0.45 0.65 0.29 
No se realiza el monitoreo de 
tareas y actividades. 
0.95 0.80 0.76 
No se monitorean los riesgos 
del proyecto. 
0.65 0.85 0.55 
Pobre delimitación del alcance 
del producto y proyecto. 
0.80 0.85 0.68 
Pobre determinación de 
actividades y tareas en el 
calendario. 
0.85 0.85 0.72 
Mecanismo de control de 
cambios de producto y proyecto 
ineficiente. 
0.55 0.70 0.39 
Retiro del responsable del 
proyecto de fin carrera. 
0.95 0.98 0.93 
Tiempo insuficiente para 
muchos requerimientos. 
0.55 0.80 0.44 
Tiempos de desarrollo en el 
proyecto no concuerdan con el 
programa. 
0.55 0.77 0.42 
 
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 categorías) para el 
proyecto. Estos riesgos severos corresponden a los procesos de gestión y la mitad 
de éstos con la planificación y seguimiento de actividades y tareas. Su severidad se 
justifica por el alto impacto negativo al avance efectuado en términos 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 delimitación del alcance de proyecto y del producto 
también influye de manera severa por lo cual se recomienda la dedicación de 
mayores esfuerzos en tiempo y recursos ad hoc para plasmar satisfactoriamente las 
necesidades del usuario final.  
 
Por comparación de promedios entre los factores de severidad de riesgos técnicos 
(0.27) y riesgos del proyecto (0.57), los riesgos por implementación o de carácter 
técnico representan una baja severidad porque las actividades de diseño y 
construcción se ejecutaron prevaleciendo la aplicación de buenas prácticas según 
la metodología de desarrollo así como el uso de las herramientas de programación. 
Diversos frameworks de desarrollo proporcionan amplia documentación de apoyo a 
estas labores, junto a un considerable paquete de librerías y herramientas de 
compatibilidad, actualizadas constantemente por los proveedores de software. Por 
otro lado, la plataforma informática utilizada reúne las características recomendadas 
por el fabricante para el óptimo rendimiento y trabajo exigidos en un proyecto de 
  
22 
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 continuación una selección de medidas comprendidas en el Anexo 
M: Plan de gestión de riesgos. Estas acciones están orientadas a velar por una 
correcta dirección 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 Planificación se invertirá el tiempo razonable en capturar y 
formalizar correctamente los requerimientos del producto y contrastando las 
soluciones con opinión de expertos y profesionales quienes conjuntamente con 
los usuarios finales avalen el proceso automatizado. Bajo este juicio de expertos 
los requerimientos no presentarán mayores variantes durante el proceso. 
Consolidada esta etapa es importante especificar las actividades y tareas a 
efectuar en el proyecto asegurando la adjudicación de tiempos razonables en 
función a la naturaleza del riesgo, junto con las acciones a seguir. 
 
 En la etapa de Ejecución se contarán con las IDE y librerías de la plataforma de 
programación procurando su mantenimiento y constante actualización vía 
conexión a Internet. El acceso a Internet 24x7 favorecerá al equipo de 
desarrollo durante la recopilación de documentación electrónica y manuales de 
programación acelerando la fase de aprendizaje y capacitación en dichas 
herramientas. La arquitectura será sometida a pruebas durante la 
implementación a través de casos de uso breves validando la entrada de datos 
según el mecanismo propuesto por la arquitectura y diseño original. Las labores 
de codificación irán de la mano con la realización de pruebas para validación de 
las casuísticas una vez concluida la implementación de cada módulo junto con 
sus funcionalidades antes de la presentación de las respectivas iteraciones. 
 
 En la etapa de Seguimiento y Control, específicamente para la administración 
del cambio se llevará un procedimiento de evaluación y ejecución de cambios 
en la implementación. Toda solicitud de cambio implicará su contraposición ante 
el modelo de negocio originalmente conceptualizado y en caso de proceder se 
ejecutarán las medidas correctivas a nivel de análisis, diseño e implementación. 
  
23 
 
1.4. Estado del Arte 
 
En esta sección se presentarán los sistemas de gestión educativa identificados 
durante la investigación acompañados por sus principales características.  
 
1.4.1. Sistemas de Gestión Educativa 
 
Los sistemas mostrados a continuación fueron clasificados como sistemas de 
gestión educativa para propósitos generales. 
 
1.4.1.1. SIAGIE 
 
El Sistema de Información de Apoyo a la Gestión en la Institución Educativa o 
SIAGIE es un sistema Web creado en el año 2003 por la Oficina de Ofimática del 
Ministerio de Educación del Perú con la finalidad de consolidar en una base de 
datos los registros históricos de alumnos de las instituciones educativas a nivel 
nacional (Minedu 2011). El propósito es lograr la estandarización electrónica de 
documentos de valor oficial como nóminas de matrícula, registros de evaluación, 
boletas de notas, actas de evaluación 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 matrícula, asistencia y evaluación de estudiantes. 
 Permite la configuración de diferentes parámetros y conceptos aplicables a gran 
parte de todas las instituciones educativas clientes. Este módulo sólo es 
controlado por parte del equipo de administración central del ministerio. 
 Incorpora la gestión de información del personal docente y administrativo. 
 Permite el registro y mantenimiento de la información de los estudiantes y sus 
procesos de aprendizaje, basado en el Diseño 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 
institución educativa. 
 Cuenta con un módulo diseñado para la administración de redes educativas, 
importante para el control de sus recursos en infraestructura y soporte. 
  
24 
 Permite el mantenimiento y control de los usuarios, la asignación de roles y la 
administración 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 
administración de centros educativos como colegios, institutos y centros de 
educación técnica-productiva (Digitechdata 2011).  
 
Este producto es desarrollado por la empresa peruana Digitechdata y sus 
funcionalidades más destacadas son: 
 
 Módulo Matrícula: Permite el mantenimiento de datos del alumno y sus tutores. 
Ofrece reportes de consolidado de matrícula, relación de alumnos matriculados 
por fechas, distribución de alumnos por aulas y por fechas de matrícula, entre 
otras. 
 Módulo Notas y Cursos: Se establece la calificación alfanumérica de acuerdo a 
las políticas y necesidades de los centros educativos. Asimismo realiza la 
creación de cursos y docentes responsables por curso con sus respectivas 
actas de notas. 
 Módulo Conductas y Tutoría: Posibilita el seguimiento conductual del alumno 
junto con un registro de incidencias con el detalle de amonestaciones, 
inasistencias y tardanzas según corresponda. 
 Módulo Control de Pagos: Para realizar el seguimiento de los pagos por 
derechos académicos con posibilidad de crear cuentas corrientes por cada 
alumno y programando las fechas de cancelación. 
 Módulo Documentos Oficiales: Permite emitir nóminas y actas oficiales, actas 
de recuperación y fichas integrales del educando. Estos documentos 
posteriormente son exigidos por el Ministerio de Educación. 
 Módulo Encuestas: Ejecuta la evaluación a profesores, tutores u otro personal 
de la institución educativa; incluye la presentación de los resultados de las 
encuestas y cuadros comparativos. 
 Módulo Padres de Familia, de uso exclusivo de los padres o tutores de los 
alumnos, se podrán consultar directamente los récords de nota de los alumnos, 
el cronograma de pagos, comunicados oficiales de la institución así como de los 
docentes del alumno. 
  
25 
 
1.4.2. Sistemas de Gestión Educativa en Educación Especial 
 
Los sistemas mostrados a continuación fueron clasificados como sistemas de 
gestión educativa exclusivos para centros de educación especial. 
 
1.4.2.1. SICE 
 
El Sistema de Información de los Centros Educativos de la Comunidad de Madrid 
es un proyecto informático liderado por la Consejería de Educación de la 
Comunidad de Madrid, España. Este sistema permite la gestión integral de los 
procedimientos en todos los centros educativos de los niveles infantil, primaria, 
secundaria y educación especial presentando un entorno de trabajo compartido por 
los centros con fines de integración de todos los procesos (Comunidad de Madrid 
2008). Este apartado resaltará las características de la versión dirigida a la gestión 
de centros de educación especial. Su acceso es por vía Web y cliente/servidor. 
 
Entre las principales funcionalidades de este sistema se tienen las siguientes: 
 
 Módulo Catálogos: Realiza los procesos de mantenimiento de datos de los 
diferentes tipos de discapacidad así como de las enfermedades involucradas. 
Para la gestión del personal no docente, se encarga del mantenimiento de las 
actividades asignadas. 
 Módulo Secretaría: Realiza el mantenimiento de información de cada centro 
educativo como datos generales, datos sobre la población con determinadas 
discapacidades, datos sobre la población de alumnos con dos o más 
necesidades educativas, entre otras. Posibilita la gestión de cursos por grupos 
de centros, así como la ejecución masiva de los inicios de cursos por centro y 
distribución de los alumnos. Asimismo permite el mantenimiento de 
promociones de alumnos inscritos por curso y por centro educativo para 
verificar la relación de alumnos asignados a varios cursos y determinando si 
procede o no su inscripción como tal. Desde este módulo es posible enviar 
información a otros sistemas para la consolidación de estadísticas como por 
ejemplo número de alumnos en transporte escolar, total de alumnos atendidos 
en el servicio médico, bibliotecas, comedor, entre otros. Adicionalmente la 
administración del personal docente y no docente clasificado de acuerdo a 
especialidades y/o situación laboral forma parte de este módulo junto con la 
  
26 
emisión de informes con carácter oficial establecidos por la Consejería de 
Educación de la Comunidad de Madrid. 
 Módulo Gestión de Personal: Desde este módulo es posible realizar el 
mantenimiento de horarios de actividades del personal no docente asignando 
por cada colaborador del centro educativo una o más actividades especificando 
además los días y horas de trabajo en esta actividad. 
 Módulo Gestión de Alumnos: Este módulo se encarga del proceso de matrícula 
de alumnos en el centro educativo, permitiendo el registro de información como 
porcentaje de discapacidad, tipo de discapacidad, religión, 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 actualización masiva 
de los alumnos del centro educativo. Finalmente, genera listados con la relación 
de alumnos según criterios como alumnado nuevo por centro, por rango de 
edades, por sexo, por etapa educativa, por aula, por discapacidad, entre otros 
criterios de selección. 
 
1.4.2.2. SEAS WEB 
 
La compañía norteamericana Computer Automation Systems ha desarrollado este 
producto desde el año 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 más de dos mil distritos en los Estados 
Unidos de América y sus funcionalidades básicas se adaptan a la realidad de cada 
centro educativo sin importar su tamaño o complejidad. Este sistema cuenta con las 
siguientes características: 
 
 Permite el mantenimiento de los programas educacionales individualizados 
especificando las características del trastorno del alumno, el método de 
aprendizaje puesto en marcha, seguido del plan de trabajo escolar a realizar 
durante el año académico consolidado a modo de calendario. Esta 
funcionalidad aplica también para centros de salud afiliados a las escuelas 
brindando atención médica a determinados alumnos, con el propósito de 
controlar los costos demandados por esta actividad y sus efectos en el 
presupuesto educativo. 
 Realiza la asignación de objetivos o cuadro de objetivos por actividad declarada 
a fin de medir la eficiencia y tiempo involucrado en su ejecución. 
  
27 
 Provee de los servicios de mensajería y conferencia entre los docentes y padres 
de familia. 
 SEAS introduce el concepto de administración del proceso educativo por 
alumno o por grupo de alumnos mediante un workflow complementado con 
indicadores de desempeño, notificaciones en línea de tiempo y mensajería entre 
los responsables del proceso. 
 Permite la configuración de formularios y reportes de monitoreo (exclusivo para 
docentes). Asimismo incorpora un administrador de reportes evaluaciones para 
efectos del mantenimiento y estandarización de todos los informes emitidos por 
la institución educativa. 
 SEAS incluye un set de formularios y reportes con valor oficial pre-configurados 
y requeridos por la jurisdicción educativa. 
 Todos los reportes generados a través 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 tecnología SSL 
(Leader 2001) para la encriptación de datos. Otras funcionalidades de este sistema 
son: 
 
 Realiza los procesos de mantenimiento de datos de alumnos y docentes, así 
como la asignación de alumnos a uno o más docentes. 
 Permite la administración de bibliotecas de objetivos y metas accesibles para 
todos los docentes de la institución. Se cuenta además 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 clínico 
y terapéutico. 
 
1.4.2.4. SEIS 
 
El Sistema de Información en Educación Especial (SEIS por sus siglas en inglés) es 
un sistema de gestión educativa creado en el año 2003 inicialmente para centros de 
educación especial establecido en San José, California, Estados Unidos de América 
  
28 
(San Joaquín 2004). Actualmente es soportado por la firma CEDR Systems. Las 
funcionalidades provistas por este sistema son: 
 
 Permite la creación 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 estándares como SEACO, BASICS, CSHA, ROPES, AUSPLAN, 
entre otros. 
 Gestiona los programas educacionales individualizados facilitando su revisión y 
lectura. Cuenta con mecanismos para la lectura de información redundante por 
única vez autocompletando los campos dependientes de este ingreso de datos. 
 Además 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 Información del Programa de Fortalecimiento de la 
Educación Especial e Integración Educativa (PFEEIE) es un sistema estadístico en 
línea diseñado para realizar el seguimiento sistemático de los servicios de 
educación especial así como de los alumnos con necesidades educativas 
especiales integrados a las escuelas y aulas regulares de la ciudad de México. La 
forma de trabajo de este sistema es como sigue: 
 
 Está conformado por un sistema estadístico en línea y un manual de 
procedimientos de las operaciones. 
 Captura y sistematización de los datos de la población objetivo del Programa en 
pro del acopio de datos por parte de las entidades. 
 Lleva a cabo la administración de las escuelas de educación inicial y básica 
regular, afiliadas a múltiples servicios de educación especial e integran alumnos 
con discapacidad. 
 
1.4.2.6. ASPEN 
 
Aspen es un sistema Web basado en Java y desarrollado por la compañía 
X2Development Corporation en los Estados Unidos de América. Se presenta como 
  
29 
una plataforma educativa integrada y distribuida en la modalidad software como 
servicio (SaaS) tanto en instituciones públicas como privadas e inicialmente 
comprendía la gestión de procesos académicos en centros educativos regulares 
(X2DEV 2010). Desde el año 2007, dentro del marco de procesos en educación 
especial, cuenta con un módulo encargado de la administración de programas 
educativos para los alumnos integrado con el resto de componentes de la 
plataforma base. Aspen cuenta con las siguientes funcionalidades: 
 
 La interfaz gráfica de usuario guarda similitud con los formularios completados 
por los profesores manualmente facilitando así la interacción. 
 Permite el mantenimiento de alumnos y del staff de profesionales, en el primer 
caso incluyendo antecedentes clínicos y demográficos. 
 Como apoyo a las funciones docentes, permite la calendarización de 
actividades y tareas educativas por alumno o por grupo. 
 Cuenta con un checklist interactivo de verificación de los requisitos estatales y 
federales exigidos por las autoridades educativas a cada institución. 
 Ejecuta el seguimiento a escala global, basado en workflows, de los servicios 
educativos y médicos brindados a los alumnos, logrando la automatización de 
actividades repetitivas a partir de la simplificación de procedimientos 
administrativos (evaluaciones, enmiendas) y, a su vez, medir el progreso en las 
sesiones. 
 Incorpora los servicios de correo electrónico 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 
carácter obligatorio y requeridos por las autoridades educativas competentes.  
 
1.4.2.7. IEPPLUS 
 
IEPPLUS es un software de gestión educativa desarrollado por la compañía 
Sungard y forma parte de la plataforma de gestión 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. 
  
30 
 Realiza la gestión de programas educacionales individualizados así como sus 
respectivas evaluaciones. 
 Incorpora los procesos de planificación de reuniones y eventos automatizados 
así como procedimientos en gestión y asignación de objetivos. 
 Incluye procesos automatizados de facturación por servicios médicos brindados 
por la unidad educativa. 
 Genera informes personalizados de progreso del estudiante así como 
formularios estándares exigidos (con base a la regulación americana IDEA) por 
las autoridades educativas compatibles con Microsoft Word. 
 
1.4.2.8. SIRNEE 
 
El Sistema de Información Regional sobre Necesidades Educativas Especiales es 
un proyecto de sistemas aún en fase de diseño patrocinado por la UNESCO en 
coordinación con los Ministerios de Educación de América Latina y el Ministerio de 
Educación y Cultura de España desde el año 2007. El propósito a alcanzar con este 
sistema es contar con datos y estadísticas para la construcción de indicadores de la 
situación educativa de la población con necesidades educativas especiales en la 
región. 
 
1.4.3. Resumen comparativo de las soluciones 
 
La tabla 1.5 reúne las características comparadas entre las soluciones investigadas 
y el sistema de información desarrollado en este proyecto de tesis (denominado 
Pegasus) a partir de los criterios y procesos funcionales y tecnológicos. 
 
Este cuadro comparativo muestra las ventajas ofrecidas por la solución Pegasus, a 
diferencia de otros sistemas, en la incorporación de la gestión de terapias (para la 
generación 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 evaluación a especialistas el centro educativo 
obtendría el grado de satisfacción de los usuarios sobre el servicio, factor a 
considerar durante la toma de decisiones sobre el staff de especialistas. La 
implementación de un repositorio de documentos junto con el módulo de mensajes 
y comunicaciones son funcionalidades claramente inexistentes en el resto de 
sistemas, y busca la participación de la comunidad educativa en la capacitación. 
  
31 
Tabla 1.5 Cuadro comparativo de las soluciones presentadas 
 
Producto 
 
 
 
 
Criterios 
EDU 
SYSNET 
SIAGIE SICE Madrid 
SEAS 
Web 
IEPWriter SEIS PFEEIE Aspen IEPPLUS SIRNEE PEGASUS 
Tecnología PHP ASP.NET JAVA ASP.NET JAVA ASP.NET ASP.NET JAVA ASP.NET Por definir ASP.NET 
Ambiente Web 
Web y 
Cliente 
Servidor 
Web y 
Cliente 
Servidor 
Web Web Web Web Web Web Web Web 
SABD 
integrado 
Sólo 
PostgreSQL 
y MySQL 
Sólo SQL 
Server 
Multiplatafor
ma 
Sólo SQL 
Server 
Multiplatafor
ma 
Sólo SQL 
Server 
Sólo SQL 
Server 
Multiplatafor
ma 
Sólo SQL 
Server 
Por definir 
PostgreSQL
, SQL Server  
y MySQL*** 
Administrac
ión de 
usuarios, 
roles y 
perfiles. 
SÍ SÍ SÍ SÍ SÍ SÍ SÍ SÍ SÍ Por definir SÍ 
Administrac
ión del 
Proceso de 
Matrícula 
SÍ SÍ SÍ NO NO NO NO NO SÍ* NO SÍ 
Administrac
ión de datos 
de 
estudiantes 
SÍ SÍ SÍ SÍ SÍ SÍ SÍ SÍ SÍ* NO SÍ 
Administrac
ión de datos 
de 
especialista
s 
SÍ SÍ SÍ SÍ SÍ NO NO SÍ SÍ* NO SÍ 
Gestión de 
objetivos e 
Indicadores 
NO NO NO SÍ SÍ SÍ NO NO SÍ* SÍ SÍ 
Administrac
ión de datos  
de 
trastornos 
NO NO SÍ SÍ NO SÍ NO NO SÍ SÍ SÍ 
Mantenimie
nto de 
terapias 
NO NO NO NO NO NO NO NO NO NO SÍ 
  
32 
 
Producto 
 
 
 
 
Criterios 
EDU 
SYSNET 
SIAGIE SICE Madrid 
SEAS 
Web 
IEPWriter SEIS PFEEIE Aspen IEPPLUS SIRNEE PEGASUS 
Administrac
ión de 
actividades 
y tareas 
SÍ NO SÍ SÍ NO NO NO SÍ SÍ NO SÍ 
Administrac
ión de 
programas 
educativos 
NO NO NO SÍ SÍ SÍ SÍ SÍ SÍ NO SÍ 
Monitoreo 
de procesos 
por 
workflow 
NO NO NO SÍ NO NO NO SÍ NO NO NO 
Administrac
ión de 
Evaluacione
s (alumnos) 
SÍ SÍ SÍ SÍ SÍ NO NO SÍ SÍ NO SÍ 
Administrac
ión de 
Evaluacione
s a 
especialista
s 
NO NO NO NO NO NO NO NO NO NO SÍ 
Repositorio 
documentari
o en línea 
NO NO NO NO NO NO NO NO NO NO SÍ 
Facturación 
de 
procedimien
tos médicos 
NO NO NO SÍ NO NO NO NO SÍ NO NO 
Administrac
ión de  
pagos por  
derechos 
académicos 
SÍ NO NO NO NO NO NO NO SÍ* NO NO 
Calendariza
ción de 
NO NO SÍ SÍ SÍ NO NO SÍ SÍ* NO SÍ 
  
33 
 
Producto 
 
 
 
 
Criterios 
EDU 
SYSNET 
SIAGIE SICE Madrid 
SEAS 
Web 
IEPWriter SEIS PFEEIE Aspen IEPPLUS SIRNEE PEGASUS 
actividades 
y eventos 
Mensajería y 
comunicaci
ones entre 
usuarios 
NO NO NO SÍ NO NO NO SÍ NO NO SÍ 
Control de 
asistencia 
SÍ SÍ NO NO NO NO NO NO SÍ* NO SÍ 
Reportes 
(con o sin 
valor oficial) 
SÍ NO SÍ SÍ SÍ SÍ SÍ SÍ SÍ SÍ SÍ** 
Sector 
objetivo 
Educación 
regular 
Educación 
regular 
Educación 
Especial y 
Regular 
Educación 
Especial 
Educación 
Especial 
Educación 
Especial 
Educación 
Especial 
Educación 
Especial y 
Regular 
Educación 
Especial y 
Regular 
Educación 
Especial y 
Regular 
Educación 
Especial 
* Requiere la instalación de otro(s) componente(s) software para esta funcionalidad. 
** No se incluyen reportes con valor oficial en el sistema en la versión 1.0. 
*** Requiere regeneración de la cadena de conexión de base de datos para el nuevo modelo de dominio. 
 
  
34 
1.5. Descripción y sustentación de la solución 
 
Frente a la problemática en torno a la necesidad de una solución informática para la 
gestión educativa en los centros de educación especial y adaptada a la realidad 
local, se propone la implementación de un sistema de información Web para el 
cumplimiento de estos propósitos. Este proyecto se constituye como uno de los 
primeros esfuerzos por democratizar el uso y aprovechamiento de las TI en centros 
de educación especial públicos y privados a nivel nacional (dada la carencia 
absoluta de tales plataformas en el sector informático de este país) ofreciendo las 
funcionalidades claves para flexibilizar la gestión e innovando los procesos en 
búsqueda de una mayor calidad educativa. 
   
La solución estará facultada para administrar información concerniente a los 
programas y actividades educativas de las instituciones hacia sus alumnos 
habilitando el acceso simultáneo a usuarios internos (especialistas) y externos 
(miembros de familia). 
 
Con este sistema se permitirá el mantenimiento de información de los alumnos 
(datos personales, comunicaciones, entre otros) cumpliendo de este modo con la 
automatización de las labores de matrícula en paralelo con el mantenimiento del 
perfil clínico. Incorpora un procedimiento automatizado de control de asistencia de 
alumnos y padres de familia a clases, escuelas de familia, entre otros eventos 
públicos, a diferencia de gran parte de los sistemas de gestión 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 cuantificación, es 
más coherente concebir la solución como un medio único centralizador del 
conocimiento especializado de los trastornos para los cuales el centro educativo 
ofrece terapias. Pensando en ello, la solución incorpora el mantenimiento de 
información de trastornos y terapias bajo la categorización establecida en el DSM-
IV (estándar americano referente en centros de educación especial de 
Latinoamérica) para la homologación de conocimientos entre los centros y 
especialistas multidisciplinarios. En el primer caso presenta como característica 
adicional la clasificación de la severidad del trastorno en base a escalas así como el 
registro de institutos y clínicas especializadas en su tratamiento respectivo. La 
  
35 
presentación del concepto de escalas asociadas a los trastornos es importante para 
la posterior determinación y especificación de las terapias. 
 
Toda medición del avance y progreso en el proceso educativo requiere de 
indicadores evaluadores de los objetivos a alcanzar por cada estudiante. La 
solución tendrá como funcionalidad la administración 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 definición 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 solución permitirá la inclusión y administración de estos conceptos sujetos a la 
adjudicación de una terapia previamente creada. Las terapias, actividades y tareas 
cuentan con una duración expresada en días para la posterior calendarización de 
actividades. 
 
Se permitirá el mantenimiento de programas educativos de los alumnos en el centro 
educativo. A diferencia de otras aplicaciones de monitoreo del desempeño de 
alumnos basadas en un único conjunto de reglas, este sistema propone la 
individualización del seguimiento en función a programas educativos únicos por 
alumno y divididos en actividades y tareas. El programa vincula la información entre 
la terapia y alumno según el trastorno y escala. Asimismo la administración de 
dicho programa queda a cargo del especialista responsable del alumno indicado en 
la matrícula.  
 
En algunos centros de educación especial, a diferencia de los colegios e institutos, 
las familias reciben capacitaciones presenciales o virtuales (si la familia está 
ubicada geográficamente lejos de la institución) reforzando así lo aprendido por los 
alumnos en sus domicilios. Cada especialista podría decidir si tales merecen ser 
evaluadas o no. Para el cumplimiento de este alcance, ausente en todas las 
plataformas de gestión investigadas, se implementará la administración en línea de 
planes de tareas para tutores y padres de familia, constituyéndose en un medio 
más efectivo para la gestión. 
 
  
36 
Además de los programas y planes de tareas, se brindarán dos nuevas 
funcionalidades afines a las labores pedagógicas del escenario educativo local aún 
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 
además del alumno y programa el código de la actividad donde se presentó el 
suceso. Con este mecanismo es posible hacer el seguimiento y revisión en base al 
historial de eventos suscitados durante el proceso educativo. Y como apoyo a los 
especialistas y pensando en la digitalización de documentos en el centro educativo, 
los especialistas contarán 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 
evaluación. Para este propósito la solución permitirá la calificación de los 
programas y planes según los objetivos e indicadores asignados a las actividades y 
tareas. Sin embargo, ofrece además la evaluación del desempeño de los 
especialistas por parte de los padres y tutores del alumno (alcance no cubierto 
explícitamente por los sistemas de información investigados). Este mecanismo 
permitirá a la institución identificar los aspectos pedagógicos a mejorar en el corto 
plazo. 
 
Para la comunicación entre los usuarios y la familia del alumno se incorporarán las 
funcionalidades de mensajería y solicitudes de entrevistas. En el primer caso, el 
usuario podrá enviar o recibir mensajes de especialistas o de otras cuentas 
convirtiéndose de ese modo en una agenda semanal donde ambos entornos 
canalizarán sus observaciones y consultas. Los padres o tutores del alumno podrán 
efectuar solicitudes de entrevistas a los especialistas en una hora y fecha por tratar. 
Durante la creación de una solicitud se validará si los tiempos propuestos para la 
entrevista están sujetos al horario de atención 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 planificación y 
gestión 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 actualización de 
datos de los usuarios especialistas así como de los usuarios externos, léase padres 
o tutores del alumno. Para ambos tipos de usuario se contará con la posibilidad de 
efectuar el cambio de contraseña en sus cuentas de usuario. Para las labores de 
  
37 
administración de usuarios todas las cuentas están asociadas a un perfil de usuario 
configurado con anterioridad sujeto a modificaciones en la configuración de sus 
permisos a ciertos contenidos y páginas. Los niveles de acceso a las páginas serán 
descritos como de alcance global (acceso total), parcial (sólo lectura) o restringido 
(sin autorización). La asignación de perfiles a usuarios podrá procesarse de forma 
individual o masiva. Del mismo modo se permitirá la modificación de un perfil de 
usuario previamente registrado, replicando posteriormente dichos cambios a todos 
los usuarios asociados a este perfil. 
 
Además de lo mencionado en párrafos previos, la solución contará con las 
funciones de generación 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 análisis y diseño, es importante la evaluación de la infraestructura tecnológica 
para el proceso de construcción. Se examinará si la plataforma existente en los 
centros educativos soporta las actividades de desarrollo y pruebas de software, en 
función 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 implantación 
del producto en las instalaciones del centro educativo. Este proyecto beneficiará a 
todo centro educativo especial público y privado y residirá en un servidor con 
sistema operativo Windows (para propósitos de implantación, 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 cómputo dentro o fuera de la 
institución educativa. 
  
  
38 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2. CAPÍTULO 2: Análisis 
 
El desarrollo del capítulo abarca la presentación de conceptos vinculados a la 
metodología de desarrollo de software aplicada junto con los requerimientos y 
restricciones identificados del producto. Continuando con el acápite de análisis de la 
solución se presentan las evaluaciones de viabilidad técnica y económica, la 
asignación de funciones a los elementos del producto y la definición del sistema. 
 
2.1. Definición de la metodología de solución 
 
A continuación se presentan las dos metodologías candidatas para el desarrollo de 
la solución. Posteriormente se exponen las justificaciones respecto a la elección de 
una de estas propuestas. 
 
2.1.1. Rational Unified Process (RUP) 
 
RUP es una metodología de desarrollo de software basada en un enfoque iterativo 
con una adecuada adaptación de los cambios durante el proceso de desarrollo, 
sumada a la correcta gestión de requerimientos incorporando al diseño de software 
el lenguaje UML, definido como un sistema de modelamiento visual para la 
  
39 
representación gráfica de casos de uso, clases de análisis, componentes de 
software entre otros. Un elemento clave en la concepción 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 culminación del producto. Este enfoque trae como beneficios la 
atenuación de riesgos desde ciclos tempranos del proceso alineando las 
necesidades de los usuarios a las funcionalidades del producto. A su vez promueve 
una correcta administración del cambio y la configuración.  
 
Esta metodología engloba una serie de entregables o artifacts del ciclo de 
desarrollo del producto, constituyéndose así como el activo más importante 
después del producto final, pues en éstos se documentan los alcances técnicos y 
funcionales definitivos del producto desarrollado en el presente proyecto de fin de 
carrera. 
 
Pese a sus prestaciones, RUP enfrenta críticas por cuando prioriza el avance 
documentario y la elaboración de entregables como prioritarios para el software (en 
ciertos casos extensos y complejos en su administración) relegando otros factores 
tales como la modalidad de trabajo durante la codificación del producto. Sumado a 
lo anterior, la adopción de RUP como metodología conlleva al establecimiento de 
flujos de trabajo y roles en el equipo de proyecto la cual, de no contar con una 
eficiente gestión del equipo de proyecto, recaería en una alta jerarquización de 
funciones aumentando la burocracia en el trabajo. 
 
2.1.2. Agile Unified Process (AUP) 
 
AUP es una metodología de desarrollo ágil heredera de otros paradigmas como la 
programación extrema (XP) y RUP. Esta metodología consta de principios y 
prácticas influyentes en la construcción del software en armonía con la 
documentación esencial de entregables específicos para el entendimiento de la 
solución. Entre sus objetivos destaca la reducción del costo del cambio en el 
proyecto en base a procedimientos iterativos (característica propia de RUP) donde 
la codificación y pruebas del software se llevan a cabo paralelamente (según XP). 
Por experiencia de proyectos anteriores se recomienda la aplicación de esta 
  
40 
metodología en equipos con menos de diez integrantes aunque cuenta con casos 
de éxito en proyectos de mayor envergadura (Ambysoft 2005). 
 
Además de la estructura metodológica fijada por RUP (como el desarrollo de 
producto por iteraciones y presentación de prototipos en modo incremental), AUP 
introduce propuestas como la programación por pares (“todos los desarrolladores 
conocen el código implementado por todos”), la gestión de requerimientos por 
niveles de prioridad (toda solicitud de cambio es analizada y/o ejecutada durante 
la construcción del software), independencia entre herramientas para la 
concepción del producto y el refactoring o la modificación del código del programa 
sin alterar su comportamiento original mejorando en su estructura, performance y 
diseño. Asimismo propone el desarrollo dirigido por pruebas (TDD) a partir de un 
concepto denominado unidad de prueba (sincronizando tanto la construcción como 
las pruebas en el prototipo) de carácter reutilizable. 
 
Pese a su evolución y demanda como metodología de desarrollo en la última 
década, por sus semejanzas con el paradigma XP enfrenta críticas dado el enfoque 
orientado a la optimización en la programación en lugar de la documentación del 
producto así como por la no profundización en ámbitos como la gestión de costo. A 
su vez, XP no provee plantillas de proyecto para facilitar la adaptación de esta 
metodología: particularmente en proyectos con mayor número de programadores, 
propuestas como la programación por pares terminan siendo una labor crítica. 
 
2.1.3. Elección de la metodología 
 
La metodología de desarrollo seleccionada para el presente proyecto es Agile 
Unified Process por las razones expuestas a continuación: 
 
 El enfoque AUP ofrece un amplio marco de buenas prácticas en la fase de 
construcción de software en búsqueda de la optimización promoviendo medidas 
como la ejecución de pruebas en paralelo con la programación así como el 
manejo de unidades de prueba. Del mismo modo por sus principios derivados 
de RUP, se constituye como una de las metodologías más aplicadas para el 
análisis, implementación y documentación de sistemas orientados a objetos. 
 
 AUP cuenta con actividades de carácter iterativo e incremental y tomando en 
cuenta las propuestas del paradigma XP (como el tratamiento de solicitudes de 
  
41 
cambios del producto en paralelo con la codificación) favorecen al logro de un 
producto software en menor tiempo y bajo una comunicación horizontal en el 
tratamiento de cambios (el equipo de desarrolladores reunido directamente con 
el cliente para conocer sus necesidades) en lugar de una comunicación vertical 
(la solicitud de cambio transmitida a través de una serie de revisiones, usuarios 
y analistas). 
 
 Como RUP prioriza a un grado mayor la documentación se opta por un 
paradigma de trabajo con entregables esenciales y específicos para el 
entendimiento de la solución final. 
 
 Finalmente por tratarse de un equipo de proyecto conformado únicamente por el 
tesista como responsable de las labores de análisis, diseño e implementación, 
el escenario resulta propicio para esta metodología considerando su aplicación 
en entornos organizacionales no masivos o en equipos con una estructura 
jerárquica reducida. 
 
 Con referencia a la gestión de costos, este alcance será delegado a la gestión 
del proyecto dentro del marco de buenas prácticas del PMBOK. 
  
2.1.3.1. Fase de Iniciación 
 
El objetivo en esta fase es asimilar los requerimientos esperados de la solución y 
plasmarlos en la definición y especificación de los casos de uso. Asimismo, como 
apoyo a los procesos de gestión, se presenta la programación definitiva de las 
actividades y tareas conforme a la planificación del proyecto (diagrama de Gantt y 
WBS) junto con la relación de riesgos identificados. Los documentos como el 
catálogo 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 observación durante esta fase. 
 
2.1.3.2. Fase de Elaboración 
 
En esta fase el objetivo es construir y probar la arquitectura descrita en el 
documento de arquitectura del sistema.  
 
  
42 
Entre los entregables requeridos durante esta fase conviene citar el documento de 
análisis (junto con el diagrama de clases de análisis) y el documento de diseño 
(acompañado del diagrama de clases de diseño). Otras actividades involucradas en 
esta fase son: 
 
 Identificación de las necesidades de hardware y software para el proyecto. 
 Elaboración del documento de arquitectura del sistema. 
 Elaboración del documento de diseño de base de datos. 
 Elaboración de estándares de programación e interfaz gráfica. 
 Establecimiento de las iteraciones así como de las especificaciones del plan de 
pruebas de software. 
 
2.1.3.3. Fase de Construcción 
 
Esta fase comprende las labores de codificación y pruebas del producto a partir de 
las pautas definidas en los documentos de análisis y diseño (para mayor 
información sobre el desarrollo de pruebas del producto revisar el capítulo 4).  
 
Se establecieron siete iteraciones identificadas en la tabla 2.1: 
 
Tabla 2.1 Plan de Iteraciones del Proyecto 
N° de iteración Descripción 
I Programación y pruebas de las funcionalidades del módulo 
Seguridad. 
II Programación y pruebas de las funcionalidades del módulo 
Comunicaciones. 
III Programación y pruebas de las funcionalidades del módulo 
Alumnos. 
IV Programación y pruebas de las funcionalidades del módulo 
Organización. 
V Programación y pruebas de las funcionalidades del módulo 
Planeamiento. 
VI Programación y pruebas de las funcionalidades del módulo 
Evaluaciones. 
VII Programación y pruebas de las funcionalidades del módulo 
Reportes. 
 
 
  
43 
2.1.3.4. Fase de Transición 
 
Esta fase tiene como propósito la puesta del sistema en producción (afinando las 
pruebas integrales) junto a la capacitación de los usuarios y conversiones de 
sistemas en caso existieran. A su vez se completará la documentación final del 
sistema. Las actividades involucradas son: 
 
 Desarrollo de pruebas unitarias y pruebas de integración 
 Cierre de documentación técnica 
 
2.2. Identificación 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 educación especial. Adicionalmente se incluyeron una 
serie de funcionalidades existentes en los sistemas mencionados en el Estado de 
Arte (ver Capítulo 1). En las tablas 2.3 y 2.4 figuran las escalas de valoración de 
dificultad y prioridad respectivamente. 
 
2.2.1. Requerimientos funcionales 
 
La presentación de estos requerimientos fue separada por cada módulo identificado 
en la tabla 2.2. 
Tabla 2.2 Requerimientos funcionales del sistema 
Módulo Seguridad 
Nº Descripción Tipo Dif. Pri. 
1 
El sistema permitirá el mantenimiento de los 
usuarios internos (especialistas) y externos 
(padres/tutores de familia) al sistema. 
Funcional 3 2 
2 
El sistema permitirá el mantenimiento de los 
perfiles de usuario y accesos al sistema. 
El perfil especifica las acciones permitidas y 
restringidas durante la navegación por las páginas, 
para uno o más usuarios. Los accesos 
considerados por cada página son de sólo lectura, 
acceso completo o ninguno. 
Funcional 2 2 
3 
El sistema permitirá la asignación del perfil de 
usuario a uno o varios usuarios. 
Funcional 1 1 
  
44 
4 
El sistema permitirá la personalización de 
accesos al sistema para una cuenta de usuario. 
El sistema permitirá cambiar la configuración de 
accesos otorgados previamente a un usuario a 
través de un perfil, a manera de personalizar sus 
accesos para eventualidades laborales. 
Funcional 1 2 
5 
El sistema posibilitará al usuario el cambio de 
su contraseña de acceso al sistema. 
Desde el panel de mantenimiento de datos el 
usuario podrá cambiar la contraseña en caso lo 
requiera. 
Funcional 3 3 
Módulo Comunicaciones 
Nº Descripción Tipo Dif. Pri. 
1 
El sistema permitirá el envío y recepción de 
mensajes y comunicados entre los usuarios. 
Bajo este mecanismo, los especialistas y las 
familias tendrán a su disposición una bitácora con 
las observaciones y consultas efectuadas entre 
ambas partes. A su vez permite el envío de 
noticias sobre eventos públicos de interés a toda la 
comunidad educativa. 
Funcional 2 1 
2 
El sistema permitirá a los especialistas el 
mantenimiento de horarios de atención a 
padres y tutores de familia. 
Funcional 1 1 
3 
El sistema permitirá a los usuarios externos el 
mantenimiento de solicitudes de entrevista con 
los especialistas. 
Previo a su creación se validará si el especialista 
buscado cuenta con disponibilidad de atención 
para la fecha y hora consignada. 
Funcional 2 1 
4 
El sistema posibilitará a los especialistas la 
gestión de solicitudes de entrevista por 
estados. 
De este modo, el especialista podrá aceptar o 
rechazar una solicitud entrante. 
Funcional 3 1 
Módulo Alumnos 
Nº Descripción Tipo Dif. Pri. 
1 
El sistema permitirá registrar y actualizar 
información del alumno especial. 
El sistema permitirá registrar información general 
Funcional 3 1 
  
45 
del alumno, tanto datos personales propios como 
los del padre de familia y/o apoderado. 
2 
El sistema permitirá el mantenimiento de hojas 
de asistencia para alumnos y padres. 
Funcional 2 1 
3 
El sistema permitirá registrar y actualizar el 
control de asistencia a clases del alumno 
especial. 
Funcional 2 1 
4 
El sistema permitirá registrar y actualizar el 
control de asistencia a reuniones de padres de 
familia. 
Funcional 2 1 
Módulo Organización 
Nº Descripción Tipo Dif. Pri. 
1 
El sistema permitirá el mantenimiento de la 
información de trastornos. 
Posibilitará el registro y actualización de las 
enfermedades incluyendo los criterios 
clasificatorios del DSM-IV.  Además contará con 
un directorio de instituciones especializadas por 
cada trastorno. 
Funcional 3 2 
2 
El sistema permitirá el mantenimiento de 
terapias por trastorno. 
La terapia reúne las actividades competentes para 
el tratamiento del trastorno del alumno y bajo una 
escala de severidad. 
Funcional 2 1 
3 
El sistema permitirá el mantenimiento de 
actividades clasificadas por terapias. 
Funcional 1 1 
4 
El sistema permitirá el mantenimiento de tareas 
asignadas por actividad. 
Funcional 1 1 
5 
El sistema permitirá el mantenimiento de 
indicadores de evaluación. 
Los indicadores cuantificarán el avance de un 
objetivo. 
Funcional 3 2 
6 
El sistema permitirá el mantenimiento de 
objetivos. 
Los objetivos consisten en logros puntuales 
esperados en los alumnos según la actividad o 
tarea pautada. 
Funcional 3 2 
7 
El sistema permitirá asociar actividades por 
cada terapia. 
Funcional 2 1 
8 El sistema permitirá asociar tareas por Funcional 1 1 
  
46 
actividad de acuerdo con la terapia. 
9 
El sistema posibilitará la asignación de 
objetivos tanto a actividades como tareas. 
De este modo ambos conceptos podrán ser 
evaluados por los especialistas. 
Funcional 2 1 
Módulo Planeamiento 
Nº Descripción Tipo Dif. Pri. 
1 
El sistema permitirá el mantenimiento de 
programas educativos de los alumnos. 
El programa englobará las actividades y tareas 
según la terapia adecuada y escala de severidad 
del trastorno padecido por el alumno. 
Funcional 1 1 
2 
El sistema permitirá incorporar actividades al 
programa educativo procedentes de otras terapias, 
tomando como criterio de filtro la edad del alumno. 
Funcional 2 1 
3 
El sistema permitirá modificar la duración de las 
tareas en el programa educativo. 
Funcional 1 1 
4 
El sistema permitirá el mantenimiento del Plan 
de tareas dirigido a los padres y/o tutores del 
alumno. 
Funcional 3 1 
5 
El sistema permitirá el mantenimiento de 
eventos y observaciones ocurridas durante la 
ejecución del programa educativo, por cada 
actividad tratada. 
Funcional 3 1 
6 
El sistema contará con un repositorio de 
archivos, en diferentes formatos, para uso de 
la comunidad educativa del centro. 
Funcional 2 2 
7 
El sistema posibilitará el mantenimiento de 
documentos clasificados por programa 
educativo y actividad. 
Los documentos no deberán superar los 8MB para 
su carga y descarga. 
Funcional 2 2 
Módulo Evaluaciones 
Nº Descripción Tipo Dif. Pri. 
1 
El sistema posibilitará la evaluación de los 
programas educativos del alumno. 
La calificación será manejada al nivel de las tareas 
y actividades. Cada ámbito tomará como criterios 
los objetivos e indicadores de medición 
respectivos. 
Funcional 2 1 
  
47 
2 
El sistema posibilitará la evaluación de los 
planes de tareas del alumno. 
La calificación será manejada al nivel de las tareas 
y tomará como criterios los objetivos e indicadores 
de medición respectivos. 
Funcional 2 1 
3 
El sistema permitirá el mantenimiento de 
evaluaciones a los especialistas. 
Funcional 2 3 
4 
El sistema permitirá a los usuarios externos 
evaluar la labor educativa de los especialistas 
del centro educativo. 
Funcional 3 1 
Módulo Reportes 
Nº Descripción Tipo Dif. Pri. 
1 
El sistema emitirá reportes de asistencia de 
alumnos. 
Funcional 2 3 
2 
El sistema emitirá reportes de asistencia de los 
tutores y/o padres de familia. 
Funcional 2 3 
3 
El sistema generará el informe de avances y 
progresos de los alumnos con las calificaciones 
obtenidas. 
Funcional 1 1 
4 
El sistema generará el reporte de evaluación 
aplicada a los especialistas. 
Funcional 2 3 
5 
La emisión de reportes tendrá como formato único 
en PDF (Portable Document Format). 
Funcional 2 3 
 
Tabla 2.3 Criterio de Dificultad 
Dif: Dificultad 
Valor Descripción 
1 Alta 
2 Media 
3 Baja 
 
Tabla 2.4 Criterio de Prioridad 
Pri: Prioridad/Importancia 
Valor Descripción 
1 Alta 
2 Media 
3 Baja 
2.2.2. Requerimientos no funcionales 
 
La tabla 2.5 agrupa los requerimientos a nivel de arquitectura y tecnologías. 
 
Tabla 2.5 Requerimientos no funcionales del sistema 
Nº Descripción Tipo Dif. Pri. 
1 
El usuario interactuará con el sistema utilizando el 
teclado y mouse. 
No funcional 3 2 
2 
El sistema será desarrollado con una interfaz 
gráfica de usuario basada en controles Web. 
No funcional 2 2 
3 El sistema estará disponible vía Internet las 24 No funcional 2 2 
  
48 
horas del día. 
4 
El sistema será accesible desde cualquier equipo 
de trabajo con navegadores Web Microsoft 
Internet Explorer (6.0 o superior) Google Chrome 
(17.0 o superior) y Mozilla Firefox (2.0 o superior). 
No funcional 2 2 
5 
El sistema se ejecutará sobre un servidor de 
aplicaciones Web con  sistema operativo Windows 
Server 2008 en adelante. 
No funcional 3 1 
6 
El sistema trabajará con el administrador de base 
de datos PostgreSQL. 
No funcional 2 2 
7 
El sistema guardará en base de datos los registros 
de errores en tiempo de ejecución producidos 
durante todas las sesiones activas. 
No funcional 3 2 
8 
El sistema contará con manuales de usuario para 
su entendimiento y capacitación en la herramienta. 
No funcional 2 2 
9 
El protocolo SMTP será utilizado para el envío de 
correos al administrador. 
No funcional 2 2 
10 
El sistema comunicará al administrador vía correo 
electrónico los errores presentados durante las 
sesiones de los usuarios. 
No funcional 3 3 
 
2.2.3. Consideraciones sobre el sistema 
 
Como alcance de la propuesta quedan excluidas las automatizaciones de los 
procesos en contabilidad, logística, gestión de planillas y recursos humanos de las 
instituciones educativas. En contraparte, se respetarán las siguientes restricciones: 
 
 Validación: La información 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 
contraseña. En función a los perfiles y accesos se controlará el nivel de 
visibilidad de la información. 
 Escalabilidad: La arquitectura posibilitará la incorporación de nuevas 
funcionalidades y módulos flexiblemente sin procedimientos drásticos para el 
desarrollador. 
 Usabilidad: Para la familiarización del usuario con el software se requiere una 
interfaz gráfica ligera e intuitiva sumada a una correcta emisión 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. 
  
49 
 
Como consecuencia de las entrevistas efectuadas y según los requerimientos 
analizados a partir de la lista de exigencias, se presenta a continuación la 
descripción 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 notificación 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. Análisis de la solución 
 
Se presenta a continuación el trabajo llevado a cabo durante el análisis de la 
solución tomando como base las recomendaciones establecidas por Roger 
Pressman (Pressman 2002) desde la relación de funcionalidades deseadas e 
identificadas por los usuarios de dos centros de educación especial, la viabilidad 
técnica y económica, el análisis costo – beneficio del proyecto, la asignación de 
funciones a los elementos del sistema hasta el establecimiento de restricciones en 
costo y tiempo y la definición del producto. 
 
  
50 
2.3.1. Identificación de las necesidades del cliente 
 
Como principales necesidades establecidas por los docentes y especialistas de dos 
centros de educación especial se obtuvieron los siguientes alcances: 
 
 Disponibilidad de información del avance en los programas educativos de los 
alumnos tanto dentro como fuera de la institución y en cualquier momento. 
 
 Acceso a tiempo completo de la información y documentación pedagógica de 
trastornos, terapias, actividades y tareas supervisados por el centro educativo 
durante el periodo anual. 
 
 Establecimiento de un mecanismo de verificación de la asistencia y tardanza de 
los alumnos. 
 
 Planificación de la duración de cada actividad y tarea comprendida en el 
programa. 
 
 Registro de incidencias durante las actividades dadas en el programa educativo 
del alumno. 
 
 Evaluación de los programas educativos del alumno. 
 
 Evaluación del desempeño 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 especificación de los casos de usos mostrados en la figura 2.2 se encuentra en 
el Anexo F: Especificación de requisitos de software. La propuesta de solución 
contará con siete módulos funcionales destinados a solucionar los problemas en 
gestión educativa descritos. Para mayores precisiones revisar el Anexo G: 
Documento de análisis del sistema. 
  
51 
 
Figura 2.2 Diagramas de casos de uso del sistema 
 
2.3.2. Viabilidad técnica y económica 
 
Para la viabilidad técnica se presentan las restricciones en hardware y software 
con miras a la construcción de la solución planteada, así como su disponibilidad. 
Con la salvedad del software de ofimática para labores documentarias, las 
restricciones técnicas identificadas son las siguientes: 
 
(1) Disponibilidad del equipo de cómputo/servidor para albergar a la base de 
datos. 
(2) Disponibilidad del equipo de cómputo/servidor para su utilización como 
servidor de aplicaciones Web. 
(3) Disponibilidad del equipo de cómputo para las labores de análisis, diseño, 
construcción y pruebas. 
  
52 
(4) Herramientas CASE de libre distribución para el modelamiento UML y 
construcción de la base de datos de la solución. 
(5) Herramienta IDE para la construcción de la interfaz gráfica y codificación de 
las funcionalidades bajo la plataforma ASP.NET. 
(6) Sistema administrador de base de datos de libre distribución con capacidad 
para soportar múltiples conexiones. 
(7) Librerías DLL con capacidad de transmisión 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 programación y sus características para la construcción bajo 
el paradigma orientado a objetos. 
(9) Disponibilidad de un servidor Web ASP.NET para labores de 
implementación. 
 
Este proyecto es técnicamente viable porque el tesista cuenta con todos los 
requisitos citados. Bajo una adecuada planificación de recursos y con miras a 
maximizar las capacidades logísticas existentes, se adoptarán las siguientes 
medidas: 
 
 Los requerimientos (1) y (2) quedan cubiertos empleando una computadora con 
procesador Intel de séptima generación 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 portátil Core Duo de 2GHz y 3GB de memoria 
RAM  ofreciendo así un rendimiento superior para las fases de análisis, diseño, 
desarrollo y pruebas por parte del tesista. Esta disposición obedece 
estrictamente a razones de simplificación de recursos, en contraparte con 
entornos de trabajo reales donde sí se exige una clara separación entre 
servidores. 
 
 Para el requisito (4) existen productos como Visual Paradigm CE, ArgoUML y 
StarUML sujetos a las exigencias técnicas propias de la documentación con 
RUP y además son de libre distribución. En el proyecto se hará uso del software 
Visual Paradigm CE. Los requerimientos (5) y (6) se encuentran cubiertos con la 
incorporación de las herramientas IDE Microsoft Visual Web Developer 2010 
Express (una versión gratuita y liviana para el desarrollo Web con ASP.NET) y 
del administrador de base de datos PostgreSQL. 
 
  
53 
 Npgsql es un proveedor de datos gratuito para bases de datos PostgreSQL en 
la plataforma Microsoft .NET Framework. Esta librería DLL a partir de su versión 
2.0 soporta operaciones con ADO.NET Entity Framework (EF4). Se elige este 
manejador para el cumplimiento del requisito (7). 
 
 La elección del lenguaje C# y del servidor Web IIS Express comprenden los 
requerimientos (8) y (9). 
 
En cuanto a la viabilidad económica, tomando como punto de partida los ítems 
técnicos citados para la implementación, 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 construcción 
(5), se encuentra a disposición 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 (según los roles y 
funciones) durante la realización del proyecto. Del mismo modo la tabla 2.7 resume 
la inversión 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 Abrev. Cant. Costo/Hora 
(S/.) 
Jefe de Proyecto  JP 1 20.00 
Analista Funcional  AF 1 12.00 
Analista 
Programador 
AP 1 10.00 
Analista de Pruebas AQ 1 9.00 
 
Tabla 2.7 Costo referencial del proyecto 
Fase Responsable Horas 
estimadas 
Costo 
(S/.) 
Ítems Gasto  
(S/.) 
Iniciación JP 20 400.00 Luz 88.50 
  
54 
  AF 50 600.00 Internet 80.00 
Elaboración 
(Anál./Diseño) 
JP 10 200.00 Telf. móvil 60.00 
  AF 320 3840.00 Materiales de 
oficina 
50.00 
Construcción 
(Impl./Pruebas) 
AP 648 6480.00 Otros gastos 100.00 
  AQ 250 2250.00 TOTAL (MES) 378.50 
Transición AP 60 600.00 TOTAL 4163.50 
  AF 90 1080.00 
  TOTAL 15450.00 MONTO FINAL 19613.50 
 
 
2.3.3. Análisis Costo – Beneficio 
 
En este análisis se presentan las razones y criterios tomados como justificación 
para el desarrollo del proyecto y la inversión económica, así como el grado de 
contribución esperado en los procesos de gestión educativa más importantes en 
centros de educación especial tras su implantación. 
 
Una vez expuestos los detalles del costo y gastos a incurrir en el proyecto, arroja 
como conclusión la no existencia de una fuerte inversión en hardware y software 
gracias al empleo de herramientas informáticas de código abierto como de licencia 
gratuita y bajo la condición de aprovisionamiento del hardware por parte del tesista. 
En cambio, el íntegro de la inversión se reserva para la cobertura en costos de 
logística y personal del proyecto (un único ejecutor, el tesista, en diferentes perfiles 
especializados). Si se introduce en este análisis la curva de experiencia profesional 
en proyectos académicos y laborales (así como en el uso de herramientas CASE e 
IDE) la reducción del margen de horas en cada perfil es altamente probable. El 
costo en función 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 solución. 
El propósito como se recalca en el Capítulo 1 es optimizar los procesos de gestión 
educativa en los centros de educación especial, comprometiendo la 
descentralización de la labor educativa. Para los especialistas de estas instituciones 
la actualización constante de la información del programa educativo así como la 
evaluación y registro del seguimiento a los alumnos favorecerá a la mejora del 
currículo brindando técnicas y terapias eficaces para futuros casos; a su vez 
permite incorporar mecanismos de evaluación a distancia para las familias. 
  
55 
Institucionalmente, contribuirá con la centralización de todo el conocimiento 
albergado en medios físicos o digitales (gracias al repositorio documentario en 
línea) a disposición de la comunidad educativa en general desde un dispositivo fijo 
o móvil con conexión a Internet. Bajo esta óptica, otro grupo de beneficiarios serán 
los padres y tutores de familia por cuanto podrán visualizar las observaciones y 
orientaciones en línea de los especialistas, realizar consultas sobre el proceso 
llegando incluso a evaluar la labor educativa brindada por la institución. Las 
funcionalidades citadas cuentan con las medidas en seguridad informática propias 
de un sistema Web estándar. Por último la masificación de soluciones de gestión 
educativa augura un futuro positivo para la integración tecnológica de las 
instituciones en educación especial con un proyecto informático pionero en el 
ámbito de la gestión de la educación especial nacional. 
 
En ese sentido, tras el análisis efectuado, la solución presenta mayores beneficios a 
futuro para todos los participantes en educación y a un costo razonable por invertir 
en las instituciones. En otras palabras, es viable dadas las ventajas y mejoras 
ofrecidas en la automatización de los procesos de las comunidades educativas. 
 
2.3.4. Asignación de funciones a hardware y software 
 
Las funciones asignadas al hardware durante el proyecto son: 
 
 Como servidor Web, cumplir con el almacenamiento físico de la aplicación Web. 
 Como servidor de base de datos, cumplir con el almacenamiento físico del 
servidor de base de datos. 
 Albergar aplicaciones ofimáticas y herramientas CASE e IDE requeridas para 
labores de análisis, diseño, construcción y pruebas. 
 
Las funciones asignadas al software durante el proyecto son: 
 
 Asistir al tesista en las actividades de diagramación, modelamiento y 
documentación durante las fases de análisis y diseño. 
 Permitir la codificación óptima y eficiente de los módulos, componentes y 
funcionalidades de la solución. 
 Permitir la construcción de la interfaz gráfica de la aplicación vía código HTML o 
por arrastre de elementos gráficos (drag & drop). 
 
  
56 
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 ejecución de los procesos de gestión educativa obtenidos a partir 
de la lista de exigencias de la solución. 
 
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 recuperación de la información necesaria. 
 Permitir la realización de copias de seguridad de la información albergada en la 
base de datos. 
 De ser necesario, admitir las configuraciones de conexión 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 información de los requerimientos. 
 Ingresar los datos apropiados de acuerdo con los propósitos de cada módulo 
incorporado a la solución. 
 Cumplir con las pruebas de software necesarias 
 Participar activamente en las reuniones de coordinación e implantación del 
sistema. 
 
Las funciones asignadas al equipo (tesista) a lo largo del proyecto son: 
 
 Dirigir, coordinar y ejecutar las actividades técnicas y funcionales.  
 Según 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 acápite 2.3.2 y únicamente 
se incurren en gastos logísticos y en el personal del proyecto, este costo final no 
deberá extenderse en más del 15% respecto al costo estimado original, frente a 
  
57 
futuras adendas. Por su parte, el cronograma de entregas de tesis representó para 
el proyecto una restricción 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 
implementación del sistema se postergó por un espacio de dos (02) años, para 
posteriormente retomar estas funciones, invirtiendo adicionalmente un total de 
quince (15) meses para su cumplimiento, con una dedicación de tres (03) días por 
semana y nueve (09) horas de trabajo por cada día. 
 
2.3.6. Definición del sistema 
 
Se presenta la definición del sistema a partir del diagrama de clases de análisis 
involucrando a las entidades principales en el modelamiento del escenario de 
negocio. Este análisis favorecerá al establecimiento y definición de la arquitectura 
final junto con las clases de diseño necesarias para su construcción. La solución 
cubre los requerimientos revisado en la sección 2.2 a través 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 reúne las funcionalidades de administración de usuarios (clases 
Usuario, UsrFamiliar y UsrEspecialista) y perfiles (clase Perfil), asignación de 
perfiles a uno o varios usuarios, así como la modificación de contraseñas a las 
cuentas de usuario y personalización de accesos a las páginas desde las clases 
Módulo y Acción. Las clases asociadas se muestran en la figura 2.4. 
  
58 
 
Figura 2.4 Diagrama de clases de análisis – Módulo Seguridad 
 
2.3.6.2. Paquete Alumnos 
 
Este paquete reúne las funcionalidades de gestión de información 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 integración con el módulo 
Seguridad en las operaciones de asignación 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 análisis – Módulo Alumnos 
 
2.3.6.3. Paquete Comunicaciones 
 
Este paquete permite el envío y recepción de mensajes (clase MensajeUsuario) y 
mantenimiento de solicitudes de entrevista con especialistas (clase 
SolicitudEntrevista). Los especialistas podrán planificar sus horarios de atención 
para un determinado rango de fechas y horas (clase HorarioAtencion) y podrán 
aceptar o denegar las solicitudes de entrevistas. La representación gráfica de este 
paquete se encuentra en la figura 2.6. 
  
59 
 
Figura 2.6 Diagrama de clases de análisis – Módulo Comunicaciones 
 
2.3.6.4. Paquete Organización 
 
Este paquete cubre las funcionalidades de mantenimiento de información de 
trastornos, actividades y tareas así como la asignación de terapias a un trastorno. 
La clase Terapia destaca en este paquete pues su existencia depende de la 
relación entre un trastorno con una severidad específica (clases Trastorno y 
EscalaTrastorno) para la cual se diseña un tratamiento (compuesto por las clases 
Actividad y Tarea). La evaluación de actividades y tareas del programa educativo 
está en función a un determinado conjunto de objetivos (clase Objetivo) junto a sus 
indicadores (clase Indicador). Se muestra a continuación en la figura 2.7. 
 
Figura 2.7 Diagrama de clases de análisis – Módulo Organización 
 
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. 
  
60 
Administra un historial para el registro de eventos (clases EventoProcesoHistorial y 
EventoProceso) y reúne las funciones de gestión 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 análisis – Módulo Planeamiento 
 
2.3.6.6. Paquete Evaluaciones 
 
Este paquete reúne las funcionalidades de evaluación de tareas y actividades de 
los programas y planes de tareas (clase Calificación). 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 análisis – Módulo 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. 
 
  
61 
En el Anexo G: Documento de Análisis se describen con mayor detalle todas estas 
clases obtenidas, una vez revisados los casos de uso y el catálogo de 
requerimientos.  
  
62 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
3. CAPÍTULO 3: Diseño 
 
En este capítulo se describe el diseño de la solución propuesta. La primera parte 
comprende el diseño en alto nivel de la arquitectura justificando la elección de un 
patrón arquitectónico. Respecto a la interfaz gráfica, se mencionan los patrones y 
estándares adoptados para uniformizar el aspecto visual y la interacción con el 
usuario. 
 
3.1. Arquitectura de la solución 
 
En esta sección se explica el diseño a alto nivel y los paradigmas arquitectónicos 
evaluados para posteriormente presentar la arquitectura final. Para mayores 
referencias, revisar el Anexo H: Documento de diseño del sistema y Anexo I: 
Documento de arquitectura del sistema. 
 
3.1.1. Representación de la arquitectura 
 
De acuerdo con capítulos anteriores la arquitectura está orientada a entornos Web. 
Bajo este diseño las tareas se ejecutan por el lado del servidor, evitando delegar 
tales responsabilidades hacia las máquinas clientes desde sus navegadores. 
  
63 
Asimismo asegura la disponibilidad a tiempo completo y desde un equipo fijo o 
móvil con conexión a Internet. Es así como el diseño 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 programación orientado a objetos. 
Esta característica si bien depende del lenguaje de programación utilizado, la 
propuesta de diseño debe asegurar la manipulación de los datos y operaciones 
de manera encapsulada a través de clases y objetos interrelacionados entre sí 
por invocaciones a los métodos respectivos. El manejo de cambios en el 
producto se logra modificando las características de un número determinado de 
componentes sin comprometer el funcionamiento del resto de módulos. 
 
 Para la lógica de negocio la arquitectura trabajará bajo el patrón Modelo de 
Dominio (Microsoft 2009). Este patrón 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 patrón 
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 patrón 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 visión más orientada a objetos en la capa de persistencia 
logrando dos metas: brindar una clara separación 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 lógica de 
negocio de la responsabilidad del funcionamiento del mecanismo de 
persistencia de datos (Microsoft 2007). 
 
3.1.2. Evaluación 
 
En las siguientes secciones se describen dos tendencias arquitectónicas candidatas 
perfectamente aplicables para el diseño a alto nivel de la aplicación. Ambas 
  
64 
propuestas cuentan con el soporte tecnológico para su realización, sin embargo 
difieren en el modo de comunicación entre los componentes lógicos del sistema. 
 
3.1.2.1. Arquitectura orientada hacia la presentación Web 
 
El patrón Modelo – Vista – Controlador (MVC) tiene sus orígenes desde 1979 por 
una comunidad de usuarios del lenguaje Smalltalk proveniente de los laboratorios 
de investigación en Xerox. Bajo este diseño el modelo de dominio (de datos y 
aplicaciones), la presentación y las acciones basadas en la información 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 aplicación 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 visualización de la información en un formato 
adecuado para el usuario y su interacción. 
 
 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 diseño destaca el soporte a múltiples vistas 
de una misma aplicación al mismo tiempo, aprovechando un único modelo de 
datos. La incorporación de nuevas vistas (por ejemplo, para dispositivos de 
plataformas diversas) no altera de sobremanera el comportamiento del modelo. En 
contraparte, adoptando este patrón trae consigo una fuerte dependencia hacia los 
eventos en la interfaz de usuario, incrementando la complejidad en la programación 
y control de tales acciones según las reglas de negocio. Asimismo la codificación 
del modelo debe efectuarse tomando en cuenta la vista, para así evitar escenarios 
en los cuales un modelo al manejar múltiples cambios en el dominio pudiera 
sobrecargar a la vista con solicitudes de actualización, en tanto algunas vistas 
ralentizarían su ejecución quedando inoperativas ante tales sobrecargas. La figura 
3.1 grafica las interacciones en el patrón MVC. 
 
  
65 
 
Figura 3.1 Patrón de arquitectura MVC (Mancini 2003) 
 
3.1.2.2. Arquitectura orientada hacia la implementación Web 
 
El patrón de arquitectura en N-Capas (Mancini 2003) comprende la implementación 
de la presentación, la lógica de negocio y la base de datos en capas por separado 
donde N representa el número 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 podría residir físicamente en ambientes diferentes 
favoreciendo así a la escalabilidad del software (ver figura 3.2).  
 
 
Figura 3.2 Patrón de arquitectura en N-Capas (Mancini 2003) 
 
La interacción con las capas inferiores presenta dos enfoques. El enfoque estricto 
en capas ocurre cuando interactúan una capa (J) y la capa inmediata inferior (J-1). 
El enfoque flexible ocurre con la interacción 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 
podría 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). 
 
  
66 
Debido al acoplamiento y cohesión entre las capas la implementación de cambios 
recae sobre una parte de la solución, minimizando el impacto hacia otras capas 
reduciendo así el esfuerzo a invertir en la depuración y corrección de errores. La 
separación de componentes en capas incrementa la flexibilidad y escalabilidad 
posibilitando la reutilización de componentes y la ejecución de pruebas unitarias de 
software. Para fines de performance, la seguridad y accesibilidad de la aplicación 
Web es altamente valorada. Esto bien se logra distribuyendo la aplicación sobre 
niveles físicos (hardware) aplicando políticas de seguridad como cortafuegos para 
determinados componentes, liberando al resto por Internet. Así, la distribución de 
las capas en niveles físicos favorece al incremento de la tolerancia a fallos y 
rendimiento de la solución. 
 
Por otro lado, como la interacción 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 podría evitarse bajo un enfoque relajado sacrificando propiedades como 
el aislamiento de capas. A su vez, este patrón para una aplicación con 
funcionalidades sencillas no resulta óptimo dado el nivel de complejidad 
incorporado. En similar situación, para aplicaciones dependientes de operaciones 
intensivas con bases de datos su adaptación no es viable. 
 
3.1.3. Diseño de la arquitectura de la solución 
 
Para la implementación de esta solución se aplicará la arquitectura en N-Capas, 
debido a su diseño altamente escalable ante la incorporación de nuevos módulos y 
funcionalidades a futuro. Además posibilita la distribución 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 obstáculos para adaptar tanto el patrón de modelo de dominio en la capa 
de lógica de negocio como el patrón de repositorio en la capa de acceso a datos, 
cumpliendo así con los lineamientos base de diseño indicados a comienzos del 
capítulo. La arquitectura queda dividida en cuatro capas descritas a continuación 
(ver figura 3.3): 
 
 Capa de Presentación: Esta capa integra los elementos de la  interfaz gráfica y 
las clases con la lógica del comportamiento de las páginas para su interacción 
con el usuario. Involucra librerías CSS, JavaScript, Ajax, Flash, páginas 
  
67 
maestras y ficheros ASPX y HTML además de contenido audiovisual. Esta capa 
actúa de forma similar a la Vista en el patrón MVC. 
 
 Capa de Aplicación: Esta capa tiene como función delegar las solicitudes de 
usuario provenientes de la capa previa hacia los módulos y clases 
correspondientes de la Capa de Lógica de Negocio, sin involucrar la 
implementación en líneas de código de dicha solicitud. Asimismo actúa como 
fachada para futuras implementaciones de integración con otros dispositivos, 
plataformas y sistemas a través de aplicaciones como servicios Web. 
 
 Capa de Lógica: Esta capa sigue la línea de trabajo de la entidad Modelo del 
patrón MVC. Conformada por clases cuyas funciones recaen en la 
implementación de la lógica de negocio atendiendo el requerimiento de usuario. 
Interactúa con la capa de base de datos de acuerdo con el tratamiento deseado 
de la información intercambiada. La codificación de la lógica de negocio sigue el 
patrón modelo de dominio. 
 
 Capa de Acceso a Datos: En esta capa se ubicarán las clases DAO y librerías 
de conexión encargadas de administrar las operaciones CRUD (Create – Read 
– Update – Delete) y sentencias SQL a nivel de base de datos. La codificación 
de esta capa sigue el patrón repositorio. 
    
Figura 3.3 Diagrama de componentes de la arquitectura 
 
  
68 
Para el intercambio de información 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 diseño definidos en el capítulo anterior. La tabla 
3.1 refleja cómo esta elección satisface los requerimientos de diseño. 
 
Tabla 3.1 Requerimientos de diseño vs. Solución arquitectónica 
Requerimiento no funcional Solución propuesta 
El sistema será desarrollado con una 
interfaz gráfica de usuario basada en 
controles Web. 
La codificación de la Capa de 
Presentación no será controlada por la 
Capa de Lógica, otorgando mayor 
libertad para incorporar los elementos 
gráficos y HTML adecuados. 
El sistema será accesible desde cualquier 
equipo de trabajo con navegadores Web 
Microsoft Internet Explorer (6.0 o 
superior) y Mozilla Firefox (2.0 o 
superior). 
La lógica de la Capa de presentación 
residirá en el servidor de aplicaciones 
Web y por el lado del cliente sólo 
observará código HTML compatible 
con los navegadores Web. En caso se 
requiera ejecutar lógica por el lado del 
cliente las librerías AJAX de igual 
forma simplifican esta labor 
conservando la compatibilidad. 
El sistema se ejecutará sobre un servidor 
de aplicaciones Web con  sistema 
operativo Windows Server 2008 en 
adelante. 
El sistema será albergado en el 
servidor IIS Express de libre 
distribución. 
El sistema trabajará con el administrador 
de base de datos PostgreSQL 
En la Capa de Acceso a Datos se 
ubicará el componente de conexión a 
la base de datos deseada, 
independiente del resto de la 
aplicación. 
 
Entre los objetivos y restricciones aplicables a esta arquitectura destacan: 
 
 Validación de información: Para la validación de los datos de entrada y salida 
se contará con controles desarrollados bajo las librerías Ajax (ubicadas en la 
Capa de Presentación) y con las reglas impuestas en la Capa de Lógica. 
  
69 
 Performance: Para fines de implantación la arquitectura es afín al 
establecimiento de diferentes niveles físicos (o de hardware) por capa 
mejorando el rendimiento. Respecto a los clientes navegadores Web, la 
arquitectura soporta la ejecución de múltiples transacciones desde otras 
conexiones en simultáneo. 
 Protección: La autenticación y validación de acciones al usuario queda a cargo 
del módulo Seguridad en la Capa de Lógica. 
 Unicidad: La arquitectura en su Capa de acceso a datos permite la interacción 
con una base de datos a la vez, canalizando todas las operaciones de lectura y 
escritura hacia ésta. 
 
3.1.4. Vista Lógica 
 
La figura 3.4 representa la vista lógica del software con las cuatro capas descritas, 
así como los principales componentes encargados de su funcionamiento. 
 
Figura 3.4 Vista lógica del sistema 
 
3.1.5. Vista de Despliegue 
 
A continuación la figura 3.5 grafica la representación de las relaciones entre los 
nodos físicos y su localización junto con los componentes en hardware y software. 
 
  
70 
 
Figura 3.5 Diagrama de despliegue 
 
Los nodos indicados en la figura se describen a continuación 
 Estación cliente: Este nodo representa al navegador Web de la máquina 
cliente, desde el cual se realiza la conexión al sistema. 
 Servidor Web y de Aplicación: En este nodo residen los archivos del código 
fuente con la lógica de negocio estructurada en capas. 
 Servidor de Base de datos: Este nodo contiene el sistema administrador de 
base de datos. Interactúa con el nodo de servidor Web en su capa de acceso a 
datos (DAO). 
 
3.1.6. Diagrama de clases de diseño 
 
Se muestran a continuación los diagramas de clases de diseño de los módulos 
Organización, Planeamiento y Evaluaciones. En primer lugar las clases de diseño 
representan a las entidades de negocio identificadas en la etapa de análisis, con 
sus atributos y tipos de datos utilizados. En segundo lugar representan a las clases 
cuyos métodos más importantes tienen a cargo la implementación de la lógica de 
negocio así como las operaciones de lectura y escritura con la base de datos. Una 
última clase llamada MasterDAO implementará la conexión entre la base de datos 
con el modelo de dominio empleado para la persistencia. 
 
Las clases de diseño del módulo Organización (figura 3.6) muestran la dependencia 
de la relación entre las clases Trastorno y EscalaTrastorno para dar lugar a una 
instancia de la clase Terapia. La interacción entre las clases Tarea, Actividad y 
Terapia es imprescindible para las funcionalidades de mantenimiento de terapias y 
asignación 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 evaluación de un 
  
71 
objetivo por indicadores requiere de la implementación de la navegación desde la 
clase padre hacia la clase Indicador. 
 
Figura 3.6 Diagrama de clases de diseño - Módulo Organización 
 
En el módulo Planeamiento (figura 3.7) las clases Programa y EventoProceso 
reúnen las operaciones de mantenimiento de estas entidades en el sistema. Una 
instancia de la clase EventoProcesoHistorial accede a información del programa 
educativo y puede recuperar la secuencia de eventos transcurridos.  
 
Bajo este diseño se tendrá acceso a la información de una tarea miembro de una 
actividad desde una instancia de la clase Programa. 
  
72 
 
Figura 3.7 Diagrama de clases de diseño - Módulo Planeamiento 
 
 
El módulo Evaluaciones (figura 3.8) tiene como clases de diseño principales a la 
clase EvaluacionEspecialista, la cual reúne métodos para el mantenimiento de 
evaluaciones (a nivel de preguntas y respuestas alternativas).  
 
La clase Calificación fue concebida para las operaciones de actualización de notas 
y observaciones en las posiciones de una entidad de las clases Programa y Plan de 
tarea.  
 
  
73 
Finalmente las clases EvalEspecialistaResult y LineaEvalEspecialistaResult 
incluyen métodos para la actualización de las respuestas emitidas por los familiares 
en las evaluaciones de especialistas. 
 
 
Figura 3.8 Diagrama de clases de diseño - Módulo Evaluaciones 
 
La explicación del diagrama de clases de diseño se profundiza el Anexo H: 
Documento de diseño del sistema. 
 
3.1.7. Diagrama de base de datos 
 
Se presenta a continuación 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 diseño de base de datos. 
  
74 
Figura 3.9 Diagrama de base de datos del sistema 
  
75 
3.1.8. Diagramas de secuencia 
 
Se presentan a continuación tres diagramas de secuencia correspondientes a los 
procesos de creación de usuarios, asignación de objetivos a una actividad y toma 
de asistencia. El propósito es representar gráficamente la interacción entre las 
capas del software conforme con las acciones del usuario. La relación completa de 
diagramas se ubica en el Anexo H: Documento de diseño del sistema. 
 
Como muestra el diagrama de secuencia de la figura 3.10 el inicio de la acción 
ocurre en el formulario de búsqueda de usuarios. El administrador tras seleccionar 
la creación de un nuevo usuario se dirige a otro formulario y completa la 
información 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 Lógica) asignando dichas entidades al 
nuevo usuario. Procede a continuación la asignación de un perfil de seguridad y por 
último la invocación al método de registro de la clase DAOUsuario (miembro de la 
Capa de Acceso a Datos). La conclusión satisfactoria o errónea del proceso es 
transmitida hacia la Capa de Aplicación y Presentación respectivamente, mediante 
un mensaje junto con el código 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 opción de modificación. En este ámbito es invocado el método de 
carga de objetivos previamente ingresados al sistema (como se recuerda la 
clasificación de objetivos difiere según sea las entidades actividad o tarea). Del 
  
76 
mismo modo, en caso de no ubicar un objetivo coherente y amerite su creación, se 
carga el listado de indicadores de evaluación. Finalmente el proceso concluye con 
la grabación de los cambios efectuados. Como este flujo es parte del proceso de 
mantenimiento de una actividad, se optó por prescindir en el gráfico 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 asignación 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 búsqueda donde el usuario selecciona una hoja de asistencia para 
proceder con el registro. El método p_BuscaHojaAsistencia recupera los datos de 
  
77 
cabecera y posición de la respectiva hoja. Concluido el mantenimiento de asistencia 
en la pantalla Pres_MantenerTomaAsistencia el ciclo cierra con la invocación al 
método p_UpdateHojaAsistencia actualizando automáticamente las posiciones de 
la hoja de asistencia tomadas en el registro. 
 
3.2. Diseño de Interfaz Gráfica 
 
En esta sección se exponen los criterios para el diseño de la interfaz gráfica para la 
implementación de la Capa de Presentación. Posteriormente se describen las 
restricciones asumidas en el diseño gráfico Web. 
 
3.2.1. Estándar de Interfaz Gráfica 
 
Todas las páginas del sistema (con excepción de la interfaz de inicio de sesión) 
seguirán el patrón gráfico mostrado en la figura 3.13. 
 
 
Figura 3.13 Patrón de diseño gráfico del sistema 
 
 Título de la ventana: El título de la ventana en todo momento albergará los 
nombres de la institución educativa y del producto. 
 
 Encabezado de página: Incorpora el logotipo característico del centro 
educativo en la parte superior izquierda de la pantalla, sobre la barra lateral de 
menú. 
 
 Nombre de usuario: Durante la sesión activa se mostrará el nombre completo 
del usuario en la parte superior derecha. Se hará uso de la fuente Arial en doce 
(12) puntos. 
  
78 
 
 Título de página: Como título de la página en ejecución se visualizará la ruta 
de acceso seguida por el usuario. Se hará uso de la fuente Arial en catorce (14) 
puntos. 
 
 Fecha de sesión: Ubicada en el extremo izquierdo del título de página se 
mostrará la fecha del día. 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 módulo (por ejemplo, 
durante los mantenimientos de las principales entidades). 
 
 Barra de menú: La barra de menú desplegable tendrá como ubicación el sector 
intermedio izquierdo de la pantalla y usará la fuente Arial en once (11) puntos. 
 
 Iconos de desconexión: En la parte inferior del menú se ubicará el botón de 
cierre de sesión de usuario. 
 
 Barras de desplazamiento: Para el traslado horizontal y vertical se contará con 
barras de desplazamiento a lo largo de la página.  
 
 Hojas de estilos en cascada (CSS): El manejo de las propiedades de fuente 
en cajas de textos y etiquetas (tipo de fuente, tamaño y color) recaerá en estos 
ficheros. 
 
A continuación se muestran los prototipos de las pantallas de inicio de sesión 
(figura 3.14), búsqueda (figura 3.15) y mantenimiento (figura 3.16) sujetas al patrón 
de diseño Web descrito. 
 
 
Figura 3.14 Pantalla de Ingreso al Sistema 
  
79 
 
 
Figura 3.15 Pantalla de Búsqueda de Documentos 
 
 
Figura 3.16 Pantalla de Mantenimiento de Programas 
 
3.2.2. Consideraciones finales 
 
Las observaciones señaladas a continuación favorecerán a la implementación de 
una interfaz sencilla, intuitiva y de fácil interacción para el usuario. 
 
  
80 
 Las páginas no albergarán elementos dinámicos como contenidos en Flash, 
archivos de imágenes GIF animados entre otros dado el alto consumo de 
recursos demandados en la aplicación. Para escenarios con múltiples 
conexiones y transacciones la incorporación de estos componentes afectaría a 
la performance y tiempos de respuesta del servidor. 
 
 Se trabajará en la implementación con tablas HTML y páginas maestras para 
contribuir así con la estandarización del diseño y distribución uniforme de 
elementos gráficos en pantalla. 
 
 Se limitará el tamaño de caracteres por línea de acuerdo a las dimensiones de 
la pantalla evitando el truncamiento automático 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 gráficos Web exclusivos de la tecnología ASP.NET no 
formarán parte de las pantallas presente en la Capa de Presentación.  
  
81 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4. CAPÍTULO 4: Construcción 
 
El presente capítulo tiene como propósito presentar las tecnologías seleccionadas 
para la implementación del producto. Por su parte se define la estrategia de 
pruebas y los tipos de pruebas seleccionados en esta etapa. 
 
4.1. Construcción 
 
En esta sección se hace un resumen de las características de las principales 
tecnologías, motores y frameworks empleados en la implementación como el 
lenguaje de programación, librerías, 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 características de desarrollo e integración de diferentes lenguajes de 
programación con el propósito de construir aplicaciones reutilizables y escalables 
en ambientes cliente/servidor, Web, dispositivos móviles entre otros. En su 
transformación a partir de la API de Windows se presentaron factores de carácter 
  
82 
evolutivo como la compatibilidad hacia atrás con otros lenguajes de programación 
demandando así una mayor complejidad en integración. .NET Framework 4.0 se 
adapta a la reutilización de códigos provenientes de diferentes lenguajes de 
programación, sin perder la característica de independencia del lenguaje (Freeman 
2011). Entre las características más resaltantes destacan: 
 
 Common Language Specification o CLS: Encargado de la compatibilidad de 
código entre lenguajes. Conjunto mínimo de estándares para la 
interoperabilidad de código generado a partir de diferentes lenguajes. Todo 
compilador para .NET debe generar código compatible con este estándar. 
Representa un subconjunto de las características ofrecidas por .NET (Freeman 
2011). 
 
 Compilación Just-in-Time o JIT: La máquina virtual de .NET utiliza un 
compilador para convertir el código IL a código máquina justo antes de ser 
ejecutado. Esto permite eficiencia al ejecutar un programa, pues solo compila el 
fragmento de código en uso. La compilación JIT solo se realiza una vez por 
cada porción de código ejecutado. Si un código es ejecutado por segunda vez 
se utiliza su versión compilada. 
 
 El conjunto unificado de bibliotecas de clase proporciona las funciones estándar 
para entrada y salida de datos, manipulación de cadenas y XML, entre otros 
ofreciendo una interfaz de desarrollo común 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 elección de esta tecnología queda justificada por la alta integración 
  
83 
existente entre este framework con otras herramientas y librerías logrando con ello 
maximizar la velocidad en la programación y pruebas del software. Por otro lado la 
curva de aprendizaje bajo esta tecnología es inferior en comparación con otras 
tecnologías Web y en cuanto al tiempo dedicado a la construcción de la solución. 
Entre otras capacidades logradas con la utilización de este framework destacan: 
 
 Ofrece herramientas y recursos para una mejor experiencia en programación 
orientada a objetos promoviendo la reutilización de código fuente. 
 La configuración de la seguridad  es realizada sea con autenticación nativa de 
Windows o vía configuración individual por aplicación. 
 Durante el desarrollo se tiene acceso a toda la librería de clases de .NET. 
Independiente del lenguaje de programación. 
 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 tecnología ASP.NET por ser considerada 
como la plataforma ad hoc para la creación de aplicaciones Web en .NET 
Framework complejas y limitadas con contenido dinámico integrando las mismas 
prestaciones. Asimismo todos los sitios Web construidos a partir de ASP.NET son 
compatibles con la mayoría de navegadores Web y simplifica los procedimientos en 
configuración reduciendo significativamente la dependencia del servidor IIS por 
medio de un fichero XML de configuración denominado WEB.CONFIG diferente por 
cada ambiente de desarrollo, pruebas o producción. 
 
4.1.2. Lenguaje de programación 
 
.NET Framework permite trabajar con más de veinte lenguajes de programación 
integrados entre ellos C# y Visual Basic. Si bien el tesista reúne la preparación y 
experiencia frente a ambos candidatos, se seleccionó en lenguaje C# por las 
razones expuestas a continuación: 
 
 En búsqueda de construir una solución desde una perspectiva orientada a 
objetos estricta, este lenguaje ofrece capacidades maduras en términos de 
sintaxis y estructura de código; respetando principios como el encapsulamiento, 
abstracción y polimorfismo en un nivel avanzado respecto a Visual Basic. 
 C# reúne un nutrido conjunto de librerías y componentes en una estructura de 
código cercana al lenguaje Java y C++. 
  
84 
 Las librerías y componentes de software integradas al proyecto ofrecen una 
mejor performance con proyectos en el lenguaje C# (como el driver de conexión 
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 programación orientada a objetos con C# alcanza una mayor libertad en la 
implementación de mecanismos de encapsulamiento, herencia, polimorfismo, 
sobrecarga, entre otros. Mientras su contraparte Visual Basic no reúne estos 
conceptos mínimos para plasmar esta óptica. 
 La programación en el lenguaje Visual Basic no exige la declaración de 
variables a diferencia del lenguaje C#. Dicha omisión afecta la estandarización 
de la programación y a las pruebas de producto. Sumado a lo anterior, 
considerando un paradigma ágil donde se pretende optimizar las labores de 
codificación adecuando buenas prácticas en programación, dicha carencia es 
calificada como contraproducente. 
 
4.1.3. Framework ORM 
 
Para las operaciones de lectura y escritura en base de datos, en la evaluación 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 específicos 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 continuación: 
 
 Se reduce drásticamente 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 conexión de una determinada base de datos (propietaria o de libre 
distribución) y genera en la carpeta de proyecto los mapas y clases del modelo 
  
85 
de datos homologando a su vez los tipos de datos entre ambos entornos. Como 
flujo alternativo, también es posible retornar clases POCO (Plain Old Class 
Object) depurando aún más la definición de las clases. A diferencia del otro 
framework donde la labor de mapeo es manual incrementando los tiempos en la 
programación. 
 NHibernate cuenta con el lenguaje HQL para la construcción 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 programación de la plataforma .NET la 
capacidad de construcción de sentencias SQL nativas como parte de su sintaxis 
propia. 
 ADO.NET EF soporta funciones canónicas (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 
solución a implementar. 
 ADO.NET EF es un proyecto integrado a la plataforma .NET Framework 4.0 
desde el año 2008 constituyéndose como una tecnología en constante 
evaluación y evolución a futuro (Lerman 2010). 
 
El factor rendimiento entre ambos frameworks es un criterio de medición 
despreciable por cuanto ambos responden satisfactoriamente a los límites de 
tolerancia fijados en las pruebas preliminares de selección de herramientas. Es 
común, tendencioso y arriesgado señalar un candidato como el más óptimo, sin 
conocer previamente cómo efectuar la configuración de ambos productos bajo las 
buenas prácticas recomendadas por sus fabricantes. 
 
4.1.4. IDE 
 
Entre los candidatos para la elección de la entorno de desarrollo fueron los 
productos SharpDevelop, MonoDevelop y Visual Web Developer 2010 Express 
Edition (VWD2010). Además 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 versión de .NET Framework 4.0.  
 
  
86 
Sin embargo la elección de la herramienta IDE decantó en Visual Web Developer 
2010 Express Edition por las siguientes consideraciones: 
 
 SharpDevelop y MonoDevelop son entornos de programación para propósitos 
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 construcción de aplicaciones Web desde cero. 
 Por tratarse de un entorno de desarrollo Web, VWD2010 posee un editor de 
páginas compatible con estándares Web como CSS 2.1, JavaScript, XML, 
XHTML 1.0/1.1 simplificando la construcción de páginas HTML mediante el 
arrastre de elementos gráficos (drag & drop). 
 Realiza la validación automática de las páginas HTML junto con las notaciones 
de los estándares Web incrustados como código de página. 
 VWD2010 ofrece un mejor control para la visualización del diseño de páginas 
Web tanto en modo código (código HTML) y modo diseño (interface WYSIWYG) 
contrastando su compatibilidad frente a diversos navegadores Web. 
 Para propósitos 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 integración. 
 VWD2010 simplifica el mantenimiento de los ficheros de configuración en 
ASP.NET (WEB.CONFIG), para el establecimiento de la conexión con la base 
de datos del sistema así como para la sincronización con ELMAH y el registro 
de errores y excepciones en línea. Además permite el manejo de hasta dos 
versiones de un mismo fichero de configuración para los ambientes de 
desarrollo y pruebas, evitando posibles pérdidas o errores en configuración 
entre dichos ámbitos. 
 La administración de archivos y librerías en VWD2010 se basa en proyectos 
Web y en proyectos de librería de clases (con propiedades de configuración 
similares ofrecidas por Visual Studio Professional Edition). 
 
4.1.5. Base de Datos 
 
En esta categoría 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 característica es opcional en 
  
87 
MySQL (por defecto, desactivada a fin de no afectar la performance). No 
obstante para los propósitos de la solución a implementar es crucial contar con 
esta capacidad. 
 En MySQL la inclusión de llaves foráneas en las tablas de la base de datos sólo 
se encuentran en tablas InnoDB. Para simular este comportamiento se 
necesitan disparadores (triggers). 
 En líneas generales, PostgreSQL provee herramientas y alternativas de 
configuración 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 específicas 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 distribución (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 elección respecto de otro candidato como el servidor por defecto de 
ASP.NET (Cassini) obedece por tratarse de una versión del IIS estándar y 
optimizada para desarrolladores reuniendo similares funciones y capacidades de 
integración con SSL (Secure Socket Layer) y URL Rewrite (para el cifrado y envío 
seguro de datos) bajo las mismas configuraciones en el fichero WEB.CONFIG. 
Finalmente no requiere del pago de licencia alguna y permite su distribución junto 
con las aplicaciones. 
 
4.1.7. Otras herramientas y librerías 
 
La librería 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 versión 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 integración y además para establecer un 
registro global de errores de la aplicación una vez implantada en los centros 
  
88 
educativos, se incorporó la librería ELMAH (Google 2009) con la finalidad de 
conservar por base de datos la relación de errores y excepciones producidos 
durante las sesiones de los usuarios desde diversos clientes. Por medio de una 
configuración al archivo WEB.CONFIG de la solución desarrollada bajo ASP.NET, 
efectúa el envío automático de correos electrónicos (o por notificaciones vía RSS) 
al administrador sobre las incidencias producidas, con información relativa a la 
ubicación, fecha, hora y detalle de la excepción producida. 
 
Por su parte, el proyecto de código abierto Ajax Control Toolkit contribuyó al 
desarrollo de controles y extensiones interactivas sobre los formularios Web con 
capacidad de ejecución en la máquina cliente manteniendo una comunicación 
asíncrona con el servidor en segundo plano, evitando así la recarga de página. Ajax 
combina tres tecnologías como XHTML y CSS para el diseño de la presentación, 
DOM o modelo de objeto de documento para la captura de datos, el objeto  
XMLHttpRequest para intercambio de información en segundo plano con el servidor 
y XML para la transferencia de datos de retorno. 
 
Finalmente, para el control de versiones de documentos y código fuente se contó 
con el apoyo del software TortoiseSVN. 
 
4.2. Pruebas 
 
En esta sección se detalla el procedimiento de pruebas durante la verificación y 
validación 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 código y funcionalidad. En otras 
palabras, verificar la interacción e integración de los componentes y validar la 
implementación de todos los requerimientos de producto.  
 
Para el cumplimiento de lo descrito anteriormente, la estrategia establecida será 
como sigue (para mayor información revisar el Plan de Pruebas): 
 
  
89 
 Recopilar, diseñar y documentar los casos de prueba de software a nivel de 
módulo y de producto en el catálogo de pruebas. Los casos de prueba deben 
cubrir la revisión de más de un requerimiento funcional. 
 Cuantificar el esfuerzo estimado en horas de cada uno de los recursos por 
emplear bajo estas pruebas. 
 Las pruebas unitarias serán ejecutadas en paralelo con la codificación teniendo 
como propósito el funcionamiento correcto del código fuente implementado bajo 
el lenguaje de programación. 
 Sobre la aplicación del desarrollo guiado por pruebas (TDD), en el marco de la 
metodología AUP, ésta reúne como etapas la elección de requisitos a codificar, 
seguida de la escritura y ejecución de las pruebas de dichos requisitos, la 
implementación del código de solución a las pruebas para culminar aplicando la 
refactorización y actualización de la lista de requisitos. Debido a la extensión en 
el número de requerimientos de software del proyecto se aplicarán, de las 
etapas descritas, la programación del código de solución de las pruebas del 
sistema y la refactorización del software. 
 Como siguiente instancia de pruebas se desarrollarán las pruebas de 
integración en modo incremental. Se pretende con ello el acoplamiento 
satisfactorio y paulatino de cada módulo así como la validación de las 
funcionalidades provistas por todos los módulos integrados anteriormente. Con 
la integración del último módulo, las pruebas de integración pasarían 
formalmente a supervisarse como pruebas del sistema. 
 Como apoyo al proceso anterior, dichas pruebas contarán con la participación 
de los usuarios finales de los centros educativos (previa coordinación 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 librería 
ELMAH a la solución final ASP.NET, manteniéndose hasta una vez concluida la 
implantación o en su defecto para las actividades de mejora continua al 
producto. 
 Para la automatización 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 interacción del usuario. 
 Ante cada flujo aprobado por el usuario, se contará con actas de aceptación 
constatando la revisión de los requerimientos funcionales completados. 
 
  
90 
4.2.2. Tipos de Pruebas 
 
En esta sección 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 módulos 
de un sistema, probando los caminos de control importantes con el fin de descubrir 
errores dentro de esta instancia (Dávila 2005). Es así como el equipo logrará 
identificar los defectos en fases tempranas de codificación sin esperar la realización 
de pruebas integrales. Las técnicas consideradas son: 
 
 Pruebas de Caja Blanca: Examinan la estructura de un código fuente según la 
lógica implementada evaluando la ejecución correcta a nivel de sentencia, 
estructuras selectivas e iterativas (Dávila 2005). No obstante, este ámbito queda 
cubierto dentro del marco de pruebas de código a realizarse durante la 
codificación del producto adoptada como práctica ágil. 
 
 Pruebas de Caja Negra: Estas pruebas se realizan sobre las interfaces 
gráficas buscando comprobar la funcionalidad, comportamiento en la entrada y 
salida de datos así como la integridad de la información enviada y recibida. 
 
Por lo tanto las pruebas de caja negra serán efectuadas considerando la 
documentación de los casos sujetos a los requerimientos del negocio a partir de la 
identificación y evaluación de diversos juegos de datos en las entradas del sistema 
para así observar la coherencia con las salidas del sistema. Como patrón de 
documentación se adopta el modelo presentado en la tabla 4.1. 
 
Tabla 4.1 Modelo de Caso de Prueba Unitaria 
Identificador ALU-TST-002 
Objetivo Verificar en el sistema el retorno de resultados en la 
búsqueda al ingresar un código de alumno incorrecto. 
Clases 
Asociadas 
2,3,4,7,10 
Descripción de 
la prueba 
Se introduce en el campo código de alumno un texto sujeto a 
las dos clases antes indicadas. Se dejan los otros campos en 
  
91 
blanco y se selecciona el botón Buscar. 
Resultados 
Esperados 
Se muestra un aviso reportando error en el formato de código 
de alumno ingresado. 
 
4.2.2.2. Pruebas de Integración 
 
Bajo estas pruebas todos los módulos revisados e integrados en diferentes 
secuencias de procesos y llamadas, son evaluados con el propósito de comprobar 
la ejecución correcta conforme al proceso de negocio esperado. Un factor clave es 
la capacidad de identificación 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 módulo del producto software 
culminados para así concretar en su conjunto estas pruebas. 
 
 Incremental: Cada módulo es acoplado a los componentes existentes, así las 
pruebas futuras no afectarán los avances y correcciones de fases anteriores, en 
la búsqueda de un software robusto desde el inicio de las pruebas. 
 
La prueba de integración incremental fue adoptada para esta etapa, pretendiendo 
demostrar así el funcionamiento del software sin errores desde el inicio de su 
creación. Esto puede afectar en mediano grado los tiempos globales, pero asegura 
calidad en la construcción y está alineado con la metodología iterativa incremental. 
Involucrando a los usuarios en las pruebas, trae como ventaja la simulación de los 
escenarios reales de los procesos de negocio midiendo así el grado de satisfacción 
de los requerimientos funcionales. 
 
4.2.3. Catálogo de pruebas 
 
A continuación en la tabla 4.2 se listan los principales casos del catálogo de 
pruebas concerniente a los módulos de Seguridad, Planeamiento y Evaluación. 
 
Tabla 4.2 Catálogo de pruebas del sistema 
Módulo ID Test Tipo Descripción 
Evaluación EVA-TST-001 Integral Verificar si para la evaluación del programa se 
despliegan las tareas asociadas. 
Evaluación EVA-TST-002 Unitaria Verificar si el sistema no realiza la búsqueda de 
  
92 
evaluaciones en caso no se ingrese un código de 
especialista válido. 
Evaluación EVA-TST-003 Integral Verificar si la búsqueda de evaluaciones a 
especialistas muestra una a más coincidencias o 
un aviso de error en caso contrario. 
Planeamiento PLA-TST-043 Unitaria Registrar un nuevo programa educativo. 
Planeamiento PLA -TST-045 Unitaria 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 confirmación de la operación 
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 búsqueda de programas por rango de 
fechas. 
Planeamiento PLA -TST-031 Unitaria Realizar la búsqueda de programas por criterios 
de alumno y especialista. 
Planeamiento PLA -TST-075 
PLA -TST-076 
PLA -TST-077 
Unitaria Verificar si el usuario puede incorporar tareas de 
otras actividades en otras terapias sobre un 
programa actual. 
Planeamiento PLA -TST-078 Unitaria 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 
ejecución 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 PLA-TST-056 Unitaria Modificar un suceso registrado anteriormente. 
Planeamiento PLA-TST-015 Unitaria Verificar la búsqueda de eventos por código de 
alumno. 
Planeamiento PLA-TST-016 Unitaria Verificar la búsqueda de eventos por texto de 
referencia. 
Planeamiento PLA-TST-037 Integral Verifica, durante el mantenimiento de 
documentos, si el sistema admite la operación sin 
un código de programa. 
Planeamiento PLA-TST-018 Integral Verifica, previa búsqueda de planes de tareas, si 
el sistema valida el código de plan de tarea con 
caracteres válidos. 
Seguridad SEG-TST-001 Unitaria Verificar la emisión de un mensaje de error en 
caso el usuario no haya elegido un perfil de la lista 
  
93 
de valores propuestos. 
Seguridad SEG-TST-002 Unitaria Verificar la emisión de un mensaje de error al no 
indicar un código de usuario correcto en el campo 
“Usuario desde” 
Seguridad SEG-TST-004 Unitaria Verificar la emisión de un mensaje de 
confirmación en la asignación de perfil al indicar 
un código 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 
contraseña. 
Seguridad SEG-TST-008 Unitaria Verificar si el usuario ha ingresado al sistema 
utilizando un código y contraseña erróneos. 
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 creación de un usuario/perfil procede 
dejando campos obligatorios u otros campos en 
blanco. 
Seguridad SEG-TST-031 Unitaria Verificar si los paneles de búsqueda de usuarios y 
perfiles arrojan los resultados esperados. 
Seguridad SEG-TST-012 Unitaria Verificar si el usuario no ingrese al sistema 
utilizando código y contraseña en blanco. 
Seguridad SEG-TST-013 Unitaria Verificar si la contraseña ingresada cumple con 
las restricciones en cuanto a longitud y contenido. 
Seguridad SEG-TST-014 Unitaria Verificar si el usuario ha modificado correctamente 
su contraseña. 
 
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 ejecución de pruebas 
 
Tras la ejecución de pruebas unitarias e integración según el Plan de Pruebas se 
presenta en esta sección los resultados obtenidos. En líneas globales, se 
obtuvieron porcentajes superiores al 90% de efectividad: la estrategia de pruebas 
de carácter incremental sumada a las prácticas de pruebas en desarrollo y la 
documentación de las casuísticas contribuyeron al logro de estos resultados. 
 
  
94 
En el desarrollo de pruebas unitarias se obtuvo un porcentaje de éxito del 96.12% 
como consecuencia de las prácticas de pruebas en paralelo a la programación de 
los módulos. 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 integración se obtuvo un 92.13% de cumplimiento como 
consecuencia de problemas en la integración de procesos entre módulos. Dichos 
inconvenientes se fueron solucionando tras nuevas pruebas de regresión. 
  
  
95 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
5. CAPÍTULO 5: Observaciones, conclusiones y 
recomendaciones 
 
Este capítulo 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 temática 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 gestión educativa y de 
administración de la labor pedagógica en estas instituciones.  
 
En la etapa de análisis se realizó el levantamiento de información entre 
profesionales del área educativa especial así como estudiantes de pregrado para 
obtener una relación potencial de requerimientos y exigencias. Con la finalidad de 
entender el comportamiento e interacción de sus procesos se realizaron 
seguimientos de actividades en dos instituciones dedicadas al tratamiento de 
personas con habilidades especiales. Lo anterior facilitó la identificación de 
  
96 
requerimientos funcionales y del modelo de negocio aplicado y acorde con los 
objetivos establecidos. 
 
La incorporación de prácticas ágiles en las fases de construcción y pruebas 
favoreció significativamente en la reducción de los tiempos de entrega y salida de 
cada módulo construido paulatinamente. Así como la utilización de herramientas 
como ELMAH y Selenium para la captura de errores y ejecución 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 distribución. La inversión 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 podría ser 
distribuida bajo modalidades de computación en nube y software como servicio 
(SaaS) hacia instituciones educativas carentes de la infraestructura física y 
tecnológica adecuada. 
 
Una restricción importante a nivel de arquitectura es la alta dependencia existente 
entre el modelo de dominio implementado en la solución y el diseño de la base de 
datos del sistema. Todo cambio importante a nivel de atributos o tablas implicará la 
regeneración inmediata del modelo de dominio, adecuando las funcionalidades a 
las capas y módulos competentes. Caso contrario se presentarán serios problemas 
con el mapeo de entidades y tablas por la obsolescencia existente entre ambas 
versiones. Por consiguiente es importante asegurar un buen diseño de la base de 
datos antes y durante la fase de construcción, 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 académicos y no es de 
interés del autor obtener un fin lucrativo a futuro. Aquí es preciso destacar las 
características y funcionalidades de este sistema como uno de los pioneros en el 
rubro de sistemas educativos en educación especial, dentro del emergente 
mercado local de desarrollo de software. 
 
5.2. Conclusiones 
 
Las conclusiones obtenidas a raíz de este proyecto son las siguientes: 
  
97 
 
 Con este proyecto se consiguió implementar una solución automatizada capaz 
de administrar los programas educativos, planes de tareas, actividades y tareas 
de los alumnos de centros de educación especial junto con otros procesos en 
gestión educativa en dichas instituciones. 
 
 El monitoreo continuo del cronograma de proyecto y de la estructura de 
descomposición del trabajo posibilitó el cumplimiento de los tiempos 
estipulados. Además se logró culminar satisfactoriamente las fases de 
desarrollo del software junto con los entregables adecuados y establecidos por 
la metodología AUP. 
 
 Los esfuerzos y tiempo invertidos en el análisis y diseño de la solución 
posibilitaron la cobertura de todos los requerimientos funcionales del usuario 
maximizando las funcionalidades deseadas del producto enriqueciéndolas con 
aportes provenientes de otros sistemas descritos en el Estado de Arte del 
capítulo 1. 
 
 La incorporación de buenas prácticas y de la metodología AUP en las etapas de 
construcción de software permitieron cumplir con los tiempos de entrega en 
cada una de las siete iteraciones. 
 
 Este proyecto comprueba la capacidad de integración de aplicaciones 
construidas bajo la plataforma .NET Framework con proyectos de código abierto 
como PostgreSQL, ELMAH, Npgsql y otros logrando una significativa reducción 
de costos en la solución y cumpliendo los requerimientos no funcionales en 
cuanto la arquitectura. 
 
 El producto es viable económicamente a lo largo de sus etapas como 
consecuencia de la utilización de herramientas de diseño y desarrollo de código 
abierto o libre de pago por licencias, figurando como únicos ítems de gasto las 
planillas del equipo de proyecto. 
 
 La adopción de ASP.NET Webforms como framework de desarrollo a diferencia 
de otros proyectos como ASP.NET MVC o ASP.NET Razor permitió una mejor 
implementación de funcionalidades desde una interfaz gráfica intuitiva, 
  
98 
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 reutilización de 
componentes. 
 
 La documentación técnica 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 preámbulo a la puesta en 
marcha del software, realizar capacitaciones periódicas 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 aplicación, como 
medida preventiva ante posibles problemas en compilación 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 gestión de personal y planillas así como la contabilidad 
financiera de la institución. Con lo anterior esta solución prácticamente abarcaría 
todas las operaciones y actividades de dichas instituciones. Respecto al módulo 
Reportes, se sugiere ampliar la capacidad de impresión de documentos en formato 
DOCX para su distribución y visualización en editores como MS Word, OpenOffice 
o StarOffice. Sumado a lo anterior, se propone implementar una solución encargada 
de la configuración y salida automática de todos los reportes con valor oficial 
exigidos por el Ministerio de Educación. 
 
Frente a posibles proyectos de integración donde es indispensable el intercambio 
de información (por ejemplo, mediante servicios Web) se recomienda su 
implementación desde la capa de Aplicación. Dado el alto flujo de información 
circulante entre los especialistas y el sistema, las incorporaciones de proyectos en 
inteligencia de negocios como datawarehouse y minería de datos contribuirían con 
creces en una mejor explotación de datos en conocimiento como apoyo a las 
investigaciones pedagógicas.  
  
99 
Bibliografía 
 
AMBYSOFT 
2005 The Agile Unified Process (AUP). Material de enseñanza. Consulta: 
02 de junio de 2011. 
<http://www.ambysoft.com/unifiedprocess/agileUP.html> 
 
AMERICAN PSYCHIATRIC ASSOCIATION (APA) 
2000 Manual diagnóstico y estadístico de los trastornos mentales. Cuarta 
edición. Barcelona: Masson S.A. 
 
COMPUTER AUTOMATION 
2008 SEAS – Special Education Management System. Documento técnico. 
Consulta: 20 de marzo de 2010. 
<http://www.computerautomation.com/seasfeat.asp> 
 
COMUNIDAD DE MADRID 
2008 S.I.C.E. Sistema de Información 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 REPÚBLICA DEL PERÚ 
2011  Proyecto de Ley N° 4707/2010-IC. Ley General de las Personas con 
discapacidad y de implementación de la convención sobre los 
derechos de las personas con discapacidad. 03 de abril. 
 
DÁVILA, Abraham 
2005 Pruebas, verificación y validación de software. Material de 
enseñanza. Lima: Pontifica Universidad Católica del Perú, Facultad 
de Ciencias e Ingeniería, Ingeniería Informática, Grupo de 
Investigación y Desarrollo en Ingeniería de Software. 
 
  
100 
DIGITECHDATA PERÚ 
2011 EDUSYSNET Colegios. Documento técnico. Consulta: 01 de junio de 
2011.  
<http://www.edusysnet.pe> 
 
EL COMERCIO 
2012  “El Perú comercializará este año más tabletas que PC de escritorio”. 
El Comercio. Lima, 22 de marzo. Consulta: 16 de septiembre. 
  <http://elcomercio.pe/tecnologia/1391059/noticia-peru-
comercializara-este-ano-mas-tabletas-que-pc-escritorio> 
 
2012  “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-ventas-
smartphones-tabletas-se-duplicaron-primer-semestre-2012> 
 
EQUIPO TAURE 
1980  Educación especial. Primera Edición. Madrid: Editorial Cincel. 
 
FREEMAN, Adam, Matthew MACDONALD y Mario SZPUSZTA 
2011  Pro C# 2010 and the .NET 4 Platform. Quinta Edición. Nueva York: 
Apress. 
 
GOOGLE CODE 
2009 Error Logging Modules and Handlers for ASP.NET. Documento 
técnico. Consulta: 12 de julio de 2011. 
<http://code.google.com/p/elmah/> 
 
HEWARD, William 
2005 Exceptional Children: An Introduction to Special Education. Séptima 
Edición. Nueva Jersey: Prentice Hall. 
 
INSTITUCIÓN EDUCATIVA AUGUSTÓBRIGA 
2007 “¿Qué son adaptaciones curriculares?”. Guía para la elaboración de 
Adaptaciones Curriculares. Extremadura. Consulta: 05 de abril de 
2010. 
  
101 
<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 
técnico. 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 edición. 
Massachusetts: Addison-Wesley Professional. 
 
LERMAN, July 
2010 Programming Entity Framework. Segunda Edición. California: 
O’Reilly Media Inc. 
 
MANCINI, Dave y David TROWBRIDGE 
2003 Enterprise Solution Patterns Using Microsoft .Net: Version 2.0: 
Patterns & Practices. Primera Edición. California: Microsoft Press. 
 
MICROSOFT DEVELOPER NETWORK 
2007 The Repository Pattern. Material de enseñanza. 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 Edición. California: 
Microsoft Press. 
 
MINISTERIO DE EDUCACIÓN DEL PERÚ (Minedu) 
2011 Sistema de Información de Apoyo a la Gestión en la Institución 
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 Edición. Lima: 
Ministerio de Educación. 
  
102 
 
MOLINA GARCÍA, Santiago 
1990 Implicaciones del diseño curricular base para la educación especial. 
Primera edición. Zaragoza: Universidad de Zaragoza, Facultad de 
Educación, Departamento de Ciencias de la Educación. 
 
ORGANIZACIÓN DE ESTADOS IBEROAMERICANOS (OEI) 
1997 “Sección Educación 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 técnico. 
Consulta: 12 de Julio de 2011. 
<http://npgsql.projects.postgresql.org/> 
 
PRESSMAN, Roger 
2002 Ingeniería del Software: un enfoque práctico. Quinta Edición. México 
D.F.: McGraw-Hill. 
 
PROJECT MANAGEMENT INSTITUTE (PMI) 
2008 Guía de los Fundamentos de la Dirección de Proyectos. Cuarta 
Edición. Pennsylvania: Project Management Institute Inc. 
 
SAN JOAQUIN COUNTY OFFICE OF EDUCATION 
2004 SEIS – Special Education Information System. Documento técnico. 
Consulta: 22 de marzo de 2011. 
<http://www.seis.org/> 
 
SÁNCHEZ MANZANO, Esteban 
2001 Principios de Educación Especial. Primera Edición. Madrid: Ediciones 
CCS. 
 
SUBSECRETARÍA DE EDUCACIÓN BÁSICA DEL GOBIENO DE MÉXICO (SEP)  
2009 Sistema Integral de Información del Programa de Fortalecimiento de 
la Educación Especial y de la Integración Educativa. Manual de 
usuario. Consulta: 17 de marzo de 2012. 
  
103 
<http://www.educacionespecial.sep.gob.mx/pdf/manual/Manual_Siste
ma_Info_PFEEIE.pdf> 
 
SUNGARD 
2002 IEPPLUS – SunGard K-12 Education. Documento técnico. 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 técnico. Consulta: 23 de marzo de 
2011. 
 <https://www.x2dev.net/pando/publicContent.do;jsessionid=000000?n
avkey=products.aspen.detail> 
 
ZEVALLOS, Ricardo 
2005 Nuevas tecnologías y discapacidad en el Sistema Educativo 
Peruano. Trabajo de Consultoría. Lima: Ministerio de Educación del 
Perú.