Capítulo Iv Resultados de La Investigación

CAPÍTULO IV
RESULTADOS DE LA INVESTIGACIÓN
CAPÍTULO IV
RESULTADOS DE LA INVESTIGACIÓN
En este capítulo se presentan los hallazgos de la investigación
producto del trabajo de campo y la aplicación de diferentes instrumentos
diseñados para cumplir exitosamente con los objetivos de la investigación,
así como también el estudio de la factibilidad, aprobación de la solicitud y el
análisis de la información recopilada. Confirmándose o no los objetivos
propuestos y; se evidencia el alcance de la propuesta investigativa. En él se
procede a presentar una visión de conjunto del proceso investigativo hasta
presentar sus resultados o el producto mismo.
1. ANÁLISIS DE LOS DATOS
Una vez aplicados los instrumentos se procede al análisis de la
información de manera cualitativa.
1.1. DESARROLLO DE LAS FASES DE LA METODOLOGÍA
Para darle cumplimiento al primer objetivo especifico, Analizar los
procesos administrativos llevados a cabo actualmente en la Escula
Básica Nacional “Dr. Leonardo Ruiz Pineda”, en correspondencia con
125
126
la primera fase de la metodología referente a la Planeación y Elaboración,
se logro la aclaración a través de una visita a la institución, donde se pudo
constatar que la labor que desarrolla es que imparte Educación Inicial, Básica
y Media cuenta con al menos unos 581 alumnos y más 58 personas que
laboran como docentes.
Esta fase está basada en los resultados que se obtuvieron por la
aplicación de los instrumentos de recolección de datos, los cuales se
encuentran constituidos por el Cuestionario, la Entrevista y la Guía de
Observación Directa. Ver Anexos, B, C y D.
Del mismo modo, se mostrará lo comprobado durante la visita donde
se consiguió conocer a través de una guía de observación, entregada a la
Lic. Adalis Mujica, Sub-Directora del plantel, compuesta por 15 acciones a
evaluar, 10 a nivel de Hardware y 5 a nivel Software, donde, se tildaban
preguntas simples de registro de cumplimiento (SI, NO, N/A) pudo
constatarse que en cuanto a hardware la institución cuenta con: 2 CPU’s
Genéricos, 2 monitores Dell LCD 20”, impresoras HP 2035 y, teclados y
mouse; mientras que al referirse a Software se puede afirmar que la empresa
cuenta con: Windows XP; de la misma forma que posee personal calificado
para la implantación y mantenimiento de todos los procesos relacionados al
portal de servicios de los proveedores.
En este mismo orden de ideas, se realizo una entrevista no
estructurada a la Docente de Aula II Lic. Lorna Oberto, documento
estructurado por ocho (8) preguntas abiertas acerca de los procesos actuales
127
llevados por la institución, evidenciando la problemática actual, sintetizando
sus respuestas:
Considera que el sistema actual es eficiente porque cumple con los
requerimientos básicos pero pueden mejoraren su opinión. Por otra parte,
menciona los procesos que actualmente se llevan a cabo, entre los que
menciona: Boletines Escolares, Resumen de Notas, Certificados de Notas,
Constancias de trabajo y de estudios, Matrículas Nóminas de Estudiantes,
Resumen de Actas para consejos, una serie de formatos como Actas,
citaciones, libros de vida fichas escolares, entre otras
Informa que las fallas comunes en los procesos mencionados se
deben llenar desde cero y con expediente en mano restando rapidez al
mismo. Aceptado el hecho de que, a través de un sistema de información se
permita automatizar dichos procesos permitiendo lograr mayor productividad
y mejores tiempo de respuesta, porque con un programa con una base de
datos con los nombres de los alumnos y los profesores estos procesos se
podrían entregar con mayor rapidez a las partes interesadas y acortaría el
tiempo de trabajo frente al computador
Más adelante, en la entrevista asevera que un punto crítico en sus
procesos administrativos actuales es el manejo de notas por lapso de cada
estudiante este proceso se realiza manualmente, ya que es necesario la
discusión y modificación de notas por estudiante y no tenemos un sistema
digital que permita hacer el mismo de forma rápida y segura, es decir, resulta
128
más eficiente el realizarlo manualmente debido el tiempo y efectividad del
mismo.
En sus respuestas siguientes comenta que la institución cuenta con
equipos e infraestructura para implantación del nuevo sistema propuesto
aunque considera los equipos limitados en su configuración. En la institución
están dispuestos a recibir entrenamiento para el uso de un nuevo sistema
Por su parte, a la Subdirectora Lic. Adalys Mujica, se le realizó la una
encuesta encontrando los siguientes resultados:
En relación a la primera pregunta, no considera que su sistema actual
sea eficiente, ya que, en toda institución se lleva a cabo el proceso
administrativo de manera manual, pero al tecnificarlo, se hará más productivo
pues habrá ahorro en tiempo y así un logro más efectivo. Comenta que el
proceso actual de gestión académica en cualquier institución educativa
conlleva a un grupo de acciones de atención al estudiante desde su ingreso
hasta el término (logrando la inserción del joven a la sociedad) para ser
productivo.
Así mismo, encuentra fallos en los procesos actuales acerca de la
continuidad de la gestión administrativa (planificación, organización, dirección
y evaluación) cuando se logra la sistematización existirá mayor operatividad y
se hará más dinámica la conducción de cada uno de los procesos.
También considera necesaria la automatización de los procesos
actuales, ya que la escuela debe ofrecer una perspectiva de eficiencia,
tomando en cuenta sus servicios de enseñanza como una empresa definida,

129
destinada a dar rendimiento seguro. Por otra parte, está dispuesta a la
migración de un sistema automatizado y recibir entrenamiento para su uso.
Con esta serie de preguntas claves acerca de los procesos actuales,
se logró identificar puntos críticos así como el planteamiento de la
automatización de los mismo, aceptando la necesidad de entrenamiento y
adiestramiento para el manejo eficiente del nuevo sistema.
De igual manera, a la Secretaría Administrativa, Yolimar Montilla, se le
entrego un cuestionario comprendido con 11 preguntas cerradas, a
continuación se presentan las preguntas y respuestas:
Con respecto a la primera pregunta, asevera que la institución cuenta
con un sistema confiable, aunque, considera que una automatización de los
procesos actuales aumentaría la eficiencia de los mismos. Igualmente
manifiesta su interés en la migración a un nuevo sistema informático, ya que,
la institución cuenta con la infraestructura básica para su implementación.
Considera que un nuevo sistema aumentaría la confiabilidad de los
resultados obtenidos en los procesos actuales y su posterior
almacenamiento, alega que, a pesar de una automatización, todos los
procesos de a nivel administrativos son mediante formatos preestablecidos
por la zona Educativa, que deben ser llenados en digital y luego impresos en
físico para entregar o ser archivados
Estas repuestas permitieron saber concretamente sobre: existencia del
sistema actual, considerar las mejoras a partir de un sistema nuevo
automatizado, los tiempos de respuesta, conocimiento de infraestructura,

130
existencia de red de computadores. Además, permitió conocer que no
poseen un sistema confiable, existen pérdidas de información
paulatinamente, que tienen retrasos considerables en los tiempos de
respuesta para los padres, representantes y alumno. La escuela tiene
equipos para la migración a un nuevo sistema pero no cuenta con una
infraestructura de red.
A continuación se presentan los resultados a las entrevistas realizadas
en la institución. La entrevista se inicio con la descripción de la situación
actual de la institución en cuanto al manejo de la información lo que afirma
que se lleva a cabo de forma manual. Se recopiló toda la información acerca
de los procesos para realizar la evaluación al sistema actual a través de la
observación directa, se determinaron las fallas que presenta entre las
cuales se pueden mencionar:
Alto retraso con respecto a la actividades que se realizan en la
institución, estas actividades pueden identificarse como: Matrícula de los
alumnos, evaluaciones académicas y el procesado posterior de las
calificaciones de dichas evaluaciones, control de recaudos de alumnos,
captación de toda la información de los alumnos, es decir, matrícula, datos
académicos, familiares, libro de vida y observaciones que se realicen;
procesando dicha información y su almacenamiento.
En lo que se refiere a las estadísticas que realiza la Unidad Educativa
Nacional, las manejan de manera muy rudimentaria en formatos en papel,
informes estadísticos tales como: cálculo de promedios, cantidad de alumnos

131
por nivel de educación, alumnos por curso, alumnos, aprobados, aplazados,
edades de alumnos regulares, entre otros. Lo que genera tiempo de retraso
en la presentación de informes.
Uso de formatos llenados de forma manual, colocados en carpetas y
guardados en un archivo común donde, con el tiempo, esta base de datos
física puede traspapelarse, deteriorarse o sencillamente perderse.
En cuanto a las actividades realizadas se obtuvieron los escenarios
básicos en los que se llego a la conclusión de que en el mejor escenario con
el sistema los resultados estarán disponibles cuando se les necesite,
proporcionando claridad y precisión. Lo cual aumentará las capacidades de
respuesta, y se logrará la satisfacción del alumno y representante
permitiéndole llevar un mejor seguimiento. Asimismo, se analizo el peor de
los escenarios, que sería que el sistema falle y se tenga que recurrir
temporalmente a realizar el procedimiento de forma manual, mientras se
solucione el problema.
La Entrevista, arrojó que la planificación, organización, dirección y
evaluación de los alumnos, toma un tiempo excesivo y la institución no
cuenta con la tecnología adecuada actualmente para poder satisfacer
adecuadamente estos procesos de manera que se ejecuten los tiempos de
gestión dando eficiencia y seguridad a toda su información procesada.
Los requerimientos son una descripción de las necesidades o deseos
de un producto, pudieron ser identificados claramente gracias a la aplicación
de las técnicas de recolección de datos mencionadas anteriormente, la

132
utilización de ellas, permitió alcanzar la meta primaria que es identificar y
documentar lo que en realidad se necesita; para definirlos se crearon los
siguientes artefactos, siguiendo con lo expuesto en la metodología de
Larman (1999).
Así que luego de la aplicación de estos instrumentos surgen los
siguientes requerimientos de información:
Diseño de un sistema que permita mejorar la gestión de los procesos
administrativos.
Generación de reportes, boletines y certificados.
Diseño de claves de acceso al sistema de información.
Un entorno amigable al usuario.
Requerimientos Funcionales:
Estadísticas en tiempo real del desempeño del alumnado.
Reportes efectivos de boletines y certificaciones de notas y
resúmenes.
Control total de todas las gestiones administrativas llevadas a cabo por
la institución.
En un Panorama General este proyecto tiene como objetivo
desarrollar Sistema Informático para la gestión de los procesos
administrativos de la Escula Básica Nacional “Dr. Leonardo Ruiz Pineda”,
facilitando de este modo sus procesos actuales tales como: control de las
calificaciones de alumnos (matricula, datos académicos, familiares, libro de
vida y observaciones), control de las horas y materias impartidas por los

133
docentes y todos aquellos procesos administrativos que estén de cierta forma
ligados a estos dos principales objetos dentro del sistema de la institución.
Luego del estudio y asimilación de los datos obtenidos, producto de la
recolección de información resultó que los alumnos son los principales
personajes de información que debe procesar el software, utilizando sistemas
elaborados con tecnologías de vanguardia, como son las técnicas orientadas
a objetos, que permiten un fácil mantenimiento y actualización de los
sistemas.
Como producto de la interpretación de los datos obtenidos se definió
que la meta, es una automatización de la gestión de los procesos
administrativos de la Escula Básica Nacional “Dr. Leonardo Ruiz Pineda”,
para que las tareas ejecutadas en dicha institución, en material académico,
sean más rápidas, eficaces y den óptimos resultados.
FUNCIONES DEL SISTEMA
Como resultado del estudio de los flujos de información presentes en
los Procesos administrativos de la Escula Básica Nacional “Dr. Leonardo
Ruiz Pineda”, se pudo determinar que las funciones del sistema son lo que
éste habrá de hacer, estas funciones se clasifican para establecer
prioridades entre ellas e identificar las que pasarán desapercibidas (pero que
consumen tiempo y recursos), y las que no, todo esto en correspondencia
con los criterios de Larman (1999), expuestos en el capítulo anterior. Las
categorías son:
134
 Evidente: Debe realizarse, y el usuario debería saber que se ha
realizado.
 Oculta: debe realizarse aunque no es visible para los usuarios.
 Superflua: Opcionales.
Como resultado se determinó que las funciones básicas que debe
cumplir el sistema son las siguientes (con su respectiva categoría):
a) Registro de alumnos, información básica, escolaridad, tipo de
matriculación y secciones, transferencia o procedencia de alguna otra
institución, información académica (notas), observaciones y libro de vida,
entre otros datos con la finalidad de identificar los listados y estadísticas que
luego se requieran. (Evidente)
b) Control de modificación de datos de los alumnos, profesores con
claves de acceso. (Evidente)
c) Generar reportes de diferentes ámbitos, con criterios de selección
según la consulta. (Evidente)
d) Consultas de secciones, alumnos, profesores. (Evidente)
e) Cargas de Notas o calificaciones, Ausencias y observaciones.
(Evidente)
f) Creación de estadísticas de diferentes ámbitos, con criterios de
selección según la consulta. (Evidente)
g) Modificación de Matricula Inicial. (Evidente)
h) Modificar y Guardar Hoja de Registros de Alumnos. (Evidente)

135
i) Modificar y Guardar Hoja de Registros de Profesores (Evidente)
j) Validar carga de evaluaciones. (Evidente)
k) Controlar la disponibilidad de las secciones. (Oculto)
l) Calcular de promedios académicos por alumno. (Oculto)
m) Calculo de las estadísticas diversas disponibles para consulta.
(Oculto)
n) Validar tipos de datos de entrada para los reportes.
o) Formularios para clave.
DESCRIPCIÓN DE LOS PROCESOS
Para formar la descripción de los procesos es necesario crear una
serie de diagramas los cuales siguen a continuación, en concordancia con
los pasos de la metodología de Larman (1999) descrita anteriormente, para
elaborar estos diagramas fue preciso el análisis de los datos recopilados
anteriormente producto de la aplicación de las técnicas de recolección de
datos, esto sirvió para definir claramente los procesos, y obtener como
producto los diagramas concernientes.
IDENTIFICAR Y ESCRIBIR CASOS DE USO
Para identificar y escribir los casos de uso, fue necesario analizar los
datos, gracias al seguimiento de la metodología de Larman (1999), luego de
identificarlos se comprobó que hay concordancia con lo expuesto en el

136
Capítulo II, donde se manifiesta que los casos de uso ayudan a identificar los
requerimientos del sistema y a describir los procesos, los casos de uso
obtenidos para el sistema son los siguientes:
CASOS DE USO DE ALTO NIVEL
Caso de uso: Gestión Alumno.
Actores: Coordinador, Representante.
Tipo: Primario.
Descripción: El representante llega a la institución, el coordinador toma los
datos del alumno y los ingresa en el sistema, verificando que estos
pertenezcan a la base de datos, en caso contrario los mismos serán
registrados; de igual forma, el administrador puede modificar los datos de un
alumno ya registrado.
Caso de uso: Matricula Inicial.
Actores: Coordinador, Ministerio De Educación.
Tipo: Primario.
Descripción: El Ministerio de Educación solicita Un formato de todo el
alumnado inscrito en el plantel.
Caso de uso: Gestión Docente.
Actores: Coordinador, Docente.
Tipo: Primario.
Descripción: El coordinador Ingresa los datos siniestrados por el Docente,

137
verificando la disponibilidad para las horas de curso y materias impartidas,
puede modificar o consultar materias y horas ya registradas en el sistema,
así como los datos básicos del docente.
Caso de uso: Carga de Notas.
Actores: Coordinador
Tipo: Primario.
Descripción: Luego de la realización de consejo de curso y el coordinador
posee las notas finales para el registro de cada alumno, procede a la carga
en el sistema de estas notas; puede consultar notas ya cargadas o modificar
las mismas.
Caso de uso: Consulta.
Actores: Coordinador.
Tipo: Primario.
Descripción: El Coordinador realiza una consulta de los datos un alumno
para verificar el estado del mismo, notas, observaciones, registro académico,
datos familiares, entre otros.
Caso de uso: Modificación.
Actores: Coordinador.
Tipo: Primario.
Descripción: El Coordinador realiza una modificación de los datos un
alumno a petición del representante, docente o director, modifica ya sea

138
notas, observaciones, registro académico, datos familiares, entre otros.
Caso de uso: Eliminación.
Actores: Coordinador, director.
Tipo: Primario.
Descripción: El Coordinador realiza una eliminación de los datos un alumno
a petición del representante, docente o director, elimina ya sea notas,
observaciones, registro académico, datos familiares, entre otros.
DIAGRAMAS DE CASOS DE USO
Teniendo como base, los datos obtenidos del paso anterior, se obtuvo
los diagramas de casos de uso, todo esto siguiendo la metodología de
Larman (1999), se comprueba que estos diagramas se utilizan para
representar la funcionalidad del sistema tal y como se expone en el CapÍtulo
II.
139
Gráfico 9. Diagrama parcial de casos de uso. (Gestión Alumno).

Fuente: Barrero y Rodríguez (2012).
En el gráfico anterior, se puede observar que el caso Gestión de
alumno se realizan, opcionalmente, los procedimientos de Registrar,
Consultar, Modificar, o Eliminar hecho que se representa con la utilización
de la relación “Extend”, ajustándose a la metodología seleccionada y en
concordancia con lo expuesto en Capítulo II.

140
Gráfico 10. Diagrama parcial de casos de uso. (Gestión de Docente).

En el gráfico 2 igualmente se puede apreciar que el caso de uso
Gestión Docente realiza, opcionalmente, las operaciones de Registrar,
Consultar, Modificar, o Eliminar, hecho que se representa con la utilización
de la relación “Extend”, ajustándose a la metodología seleccionada y en
concordancia con lo expuesto en el Capítulo II.
Estos gráficos son producto del análisis de los datos obtenidos en la
aplicación de las técnicas de recolección de datos, en conjunto con los pasos
de la metodología seleccionada.
141
Gráfico 11. Diagrama parcial de casos de uso.

El gráfico 3 es producto de la unión de los dos anteriores y describe
los casos de uso Gestión de Alumnos y Gestión de Docentes, utilizando la
relación “Extend”. Con la elaboración de estos gráficos se demostró lo
expuesto en el Marco Teórico (Capitulo II), donde se define que los casos de
uso se enfocan en el comportamiento del sistema desde una perspectiva
externa.
CASOS DE USO EXPANDIDOS
Los casos de uso expandidos, son resultado de la aplicación de los
pasos de la metodología, y se realizaron siguiendo los lineamientos de la
misma, luego de su elaboración se demostró que coinciden con lo expuesto

142
en Capitulo II donde se afirma que los casos de uso expandidos son aquellos
más descriptivos donde se explica el curso de los eventos.
Propósito: Ingresar un Alumno.
pertenezcan a la base de datos, en caso contrario serán registrados.
Tipo: Primario y esencial.
Cuadro 3
Curso normal de los eventos
ACCIÓN DEL ACTOR 1.1.1 RESPUESTA DEL SISTEMA
1. El Representante llega a la Institución
y solicita el ingreso del alumno.
2. El Coordinador ingresa los datos del
alumno.
3. El sistema verifica si el alumno
solicitante ya está inscrito y carga los
datos del alumno.
4. el Coordinador solicita al
representante las notas certificadas,
registro académico y demás datos básico
que se requieran. 5. El sistema actualiza la base de datos y
devuelve mensajes de error en caso de
que alguna de las peticiones no pueda
ser realizada.
6. el sistema devuelve un mensaje de
registro exitoso.
7.- el Coordinador Entrega al
representante una constancia de
inscripción y espera hasta que éste esté
conforme.
143
Caso de uso: Gestionar Alumno.
Tipo: Primario.
Propósito: Modificar los datos un Alumno.
Descripción: El representante llega a la Institución, el coordinador toma los
datos del alumno requeridos al representante y los ingresa en el sistema,
verificando que estos se encuentran registrados en la base de datos. Si el
coordinador observa algún cambio en los datos suministrados, o el
representante solicita cambiar alguno de ellos, el coordinador pasa a
modificar los datos del mismo.
Cuadro 4
1. El representante llega a la
institución y solicita un cambio en los
datos

Alumno.

solicitado ya está inscrito y carga los
datos del alumno.
4. El coordinador le solicita al
representante los datos a modificar.
5. El sistema actualiza la base de datos y
que alguna de las peticiones no pueda ser
realizada.
6. Modificación exitosa.
7.- El coordinador entrega al

representante confirma la modificación y
espera hasta que éste esté conforme.
144
Tipo: Primario.
Propósito: Consulta los datos un Alumno.
Descripción: El coordinador realiza una consulta de los datos de un alumno
para verificar el estado del mismo.
Cuadro 5
1. El coordinador ingresa los datos del

alumno.
datos del alumno.
3.- El coordinador le solicita al

representante que datos va a consultar.

realizada.
5. Muestra el pantalla la consulta exitosa

hallada.
6.- El coordinador da respuesta al
requerimiento del representante
informándolo sobre el resultado de la
consulta y espera hasta que éste esté
conforme.

145
Tipo: Primario.
Propósito: Eliminación los datos un Alumno.
Descripción: El coordinador realiza la eliminación de los datos de un alumno
y entrega un registro académico con toda la información del alumno.
Cuadro 6
1. luego del que el coordinador recibe la

autorización por parte de dirección
ingresa los datos del alumno. 2. El sistema verifica si el alumno
datos del alumno.
3.- El coordinador procede a realizar la

eliminación del alumno del sistema.

realizada.
5. el sistema genera e imprime el registro

académico del alumno.
6.- El coordinador entrega el registro
académico y espera hasta que éste esté
conforme.

146
Propósito: Ingresar un docente.
Descripción: El docente entre informa sobre su carga de horas e
información básica requerida: materia impartida, entre otros; el coordinador
toma los datos del docente y los ingresa en el sistema, verificando que estos
registrados.
Tipo: Primario y esencial.
Cuadro 7

docente.
2. El sistema verifica si el docente

solicitante ya está registrado y carga los
datos del docente.
3. el Coordinador solicita al docente
carga de horas, materia impartida, etc y
demás datos básico que se requieran.
ser realizada.
registro exitoso.
6.- el Coordinador Entrega al docente
carga de horas y espera hasta que éste
esté conforme.
147
Propósito: Modifica información de un docente.
Descripción: El docente llega a Coordinación, el coordinador toma los datos
del docente requerido y los ingresa en el sistema, verificando que estos estén
registrados en la base de datos. Si el coordinador observa algún cambio en
los datos suministrados, o el docente solicita cambiar alguno de ellos, el
coordinador pasa a modificar los datos del mismo.
Cuadro 8
1. El docente llega a la institución y

solicita un cambio en los datos

docente.

datos del alumno.
4. El coordinador le solicita al docente
los datos a modificar.
realizada.
7.- El coordinador entrega al docente

confirma la modificación y espera hasta
que éste esté conforme.
148
Caso de uso: Gestionar Docente.
Tipo: Primario.
Propósito: Consulta los datos un Docente.
Descripción: El coordinador realiza una consulta de los datos de un docente
Cuadro 9

docente
datos del docente.
3.- El coordinador le solicita al docente

que datos va a consultar.

realizada.
5. Muestra en pantalla la consulta exitosa

hallada.
requerimiento del docente informándolo
sobre el resultado de la consulta y

149
Tipo: Primario.
Propósito: Eliminación los datos un docente.
Descripción: El coordinador realiza la eliminación de los datos de un
docente.
Cuadro 10

ingresa los datos del docente. 2. El sistema verifica si el docente
datos del docente.

eliminación del docente del sistema.

realizada.
5. Muestra en pantalla la eliminación

exitosa.
6.- El coordinador informa al docente
que se encuentra retirado del sistema y

150
CLASIFICACIÓN DE LOS CASOS DE USO
Luego de haber definido los casos de uso expandidos, se continua con
la clasificación de los casos de uso, la clasificación de los casos de uso surge
como resultado del análisis de los flujos de información en la Coordinación
del Plantel, lo que permite conocer cuales son los casos de uso mas
importantes los cuales deben ser desarrollados en primer lugar, también es
producto del análisis de los resultados obtenidos de las fases anteriores.
Cuadro 11
Clasificación Casos de Uso
CLASIFICACIÓN CASO DE USO JUSTIFICACIÓN
Alto Gestión de Alumno.
Gestión de Docentes. Corresponde a los criterios

de clasificación más altos.
Registro.
Modificación.
Consulta.
Eliminación
Bajo Inicia. Efecto mínimo en la

arquitectura.

151
PROGRAMACIÓN DE LOS CASOS DE USO
La programación de los casos de uso se obtiene como resultado del
paso anterior luego de haber definido o clasificado los casos de uso se
procede a determinar cual caso de uso va a ser desarrollado y su versión
correspondiente todo esto de acuerdo a los pasos de la metodología de
Larman (1999) descrita en el capitulo II.
Después de todo lo anterior se pudo determinar que los casos de uso,
serán desarrollados en el Ciclo de Desarrollo 1, en su versión 1.
 Gestión de Alumnos: versión 1 (ingresar alumnos, modificar alumnos,
consultar alumnos y eliminar alumnos).
 Gestión de Docentes: versión 1 (ingresar docentes, modificar docentes,
consultar Docentes y eliminar docentes).
 Ingresar: versión 1: (ingreso de alumnos y/o docentes).
 Modificar: versión 1: (modificar de alumnos y/o docentes).
 Consultar: versión 1: (consultar datos de: alumnos y/o docentes).
 Eliminar: versión 1: (Eliminar datos de: alumnos y/o docentes).
ASIGNACIÓN DE LOS CASOS DE USO.
Después de programar los casos de uso, y usando como base los
resultados anteriormente obtenidos, se asignarán los casos de uso al ciclo
de desarrollo, siguiendo los parámetros de Larman(1999).
En virtud de esto se creó la asignación de los casos de uso:

152
Gráfico 12. Asignación de Casos de Uso

Para darle consecución y cumplimiento al segundo objetivo Determinar
los requerimientos funcionales del software informático para la gestión
de los procesos administrativos en la Escula Básica Nacional “Dr.
Leonardo Ruiz Pineda”. En correspondencia con la primera fase II de la
metodología referente al Análisis.
En esta fase es donde se definen los requerimientos del usuario y
establecen las funciones, restricciones y atributos que el sistema de
información debe satisfacer.
Esta fase está basada en los resultados que se obtuvieron por la
aplicación de los instrumentos de recolección de datos, los cuales se
encuentran constituidos por la Guía de Observación Directa, La Encuesta y la
Entrevista. Ver Anexos B, C y D.

153
La observación se realizó durante la primera visita a la institución,
donde se pudo observar como llevan a cabo los procesos administrativos
manuales, estadísticas, boletines, Resumen de notas, certificados de notas,
matriculas nóminas de los estudiantes, entre otros. Observando el tiempo
que toma realizar esos procesos ocasionando lentitud al proceso diario de
trabajo.
Por otra parte, el cuestionario permitió conocer que no poseen un
sistema confiable, tienen perdidas de información paulatinamente, que tienen
retrasos considerables en los tiempos de respuesta para los padres,
representantes y alumno. La escuela tiene equipos para la migración a un
nuevo sistema pero no cuenta con una infraestructura de red actual.
En el mismo orden, la Entrevista, arrojó que la planificación,
organización, dirección y evaluación de los alumnos, toma un tiempo
excesivo y la institución no cuenta con la tecnología adecuada actualmente
para poder satisfacer adecuadamente estos procesos de manera que se
ejecuten los tiempos de gestión dando eficiencia y seguridad a toda su
información procesada.
Así que luego de la aplicación de estos instrumentos surgen los
siguientes requerimientos de información:
CONSTRUCCIÓN DE UN MODELO CONCEPTUAL
En este paso se produjo un estudio y comprensión de los objetos
existentes, así como también el análisis de los resultados de los pasos

154
anteriores, esto originó como producto el modelo conceptual
CREAR UN MODELO CONCEPTUAL PRELIMINAR
Luego de analizar e interpretar los datos obtenidos usando las técnicas
de recolección y con la aplicación de las fases anteriores dio como resultado,
el modelo conceptual preliminar, con él se demostró lo expuesto en el fase II
donde se sostiene que el mismo identifica las entidades presentes en el
contexto del sistema, es decir, conceptos reales y no conceptos de software.
Ver gráfico 5.
Gráfico 13. Modelo Conceptual Preliminar.

AGREGACIÓN DE LAS ASOCIACIONES
Basado en los resultados obtenidos de los pasos, fases anteriores y
además de la información investigada, se continuó con lo presentado por la

155
metodología, agregando asociaciones.
IDENTIFICAR LAS ASOCIACIONES DE UN MODELO CONCEPTUAL
Como resultado del estudio de los datos obtenidos, durante la
recaudación de información y de la aplicación de los pasos y fases se
obtuvieron las asociaciones del modelo conceptual, comprobándose lo
mostrado en el marco teórico donde se confirma que las asociaciones
revelan como se relacionan las diferentes entidades, empleando conceptos
como la cardinalidad. Ver gráfico 6.
Gráfico 14. Asociaciones del Modelo Conceptual.

ASOCIACIONES QUE NECESITAN CONOCERSE
Una vez ya conocidas, entre las entidades y como producto del estudio de
las mismas, siguiendo además las leyes de Larman (1999), se establecieron

156
las asociaciones que requieren conocerse, es decir las mas significativas,
mostrándose a continuación.
Asociación A
Asociación Desde
Elemento : Alumno
Multiplicidad : 1
Asociación Hasta
Elemento : Alumno_Secciones
Multiplicidad : ∞
Asociación B
Asociación Desde
Elemento : Alumno
Multiplicidad : 1
Asociación Hasta
Elemento : Notas
Multiplicidad : ∞
Asociación C
Asociación Desde
Elemento : Alumno_Secciones
Multiplicidad : ∞
Asociación Hasta
Elemento : Secciones
Multiplicidad : 1
Asociación D
Asociación Desde
Multiplicidad : ∞
Asociación Hasta
Elemento : Periodos
Multiplicidad : 1
Asociación E
Asociación Desde
Elemento : Evaluaciones
Multiplicidad : 1
Asociación Hasta
Elemento : Notas
Multiplicidad : ∞
157
Asociación F
Asociación Desde
Elemento : Materias_Secciones
Multiplicidad : ∞
Asociación Hasta
Multiplicidad : 1
Asociación G
Asociación Desde
Elemento : Evaluaciones
Multiplicidad : ∞
Asociación Hasta
Multiplicidad : 1
Asociación H
Asociación Desde
Elemento : Materias
Multiplicidad : ∞
Asociación Hasta
Multiplicidad : 1
Asociación I
Asociación Desde
Multiplicidad : 1
Asociación Hasta
Elemento : Profesores
Multiplicidad : 1
ATRIBUTOS DEL MODELO DEL SISTEMA
Los atributos del modelo del sistema se obtienen para el estudio como
producto del análisis de la información obtenida en los pasos anteriores,
siguiendo la metodología de Larman (1999). Luego de haber fijado los

158
atributos se demostró que va acorde con lo mostrado en el marco teórico
donde se confirma que las entidades tienen atributos que permiten
describirlas mucho mejor dentro del argumento del sistema. Ver gráfico 7.
Gráfico 15. Atributos del Modelo del Sistema.

MODELO CONCEPTUAL DEL SISTEMA
Como consecuencia del estudio de lo obtenido anteriormente, se
procedió a construir el modelo conceptual del sistema siguiendo con los
métodos de Larman (1999), y comprobando lo mostrado en el marco teórico

159
el cual se señala que el modelo conceptual muestra las asociaciones y los
atributos de las entidades del sistema. Ver gráfico 8.
Gráfico 16. Modelo Conceptual del Sistema.

COMPORTAMIENTO DE LOS SISTEMAS
Como resultado del estudio de los flujos de información de la
coordinación del plantel que se obtuvieron en la recolección de datos, y de

160
los artefactos elaborados en pasos anteriores se procedió a establecer la
conducta del sistema.
IDENTIFICAR LOS EVENTOS Y OPERACIONES DEL SISTEMA
Producto de la interpretación de las necesidades se procedió a la
personalización de los eventos y operaciones del sistema, siguiendo con la
metodología elegida. Luego se determinó que estos son:
 Registrar_ Alumno()
 Modificar_ Alumno ()
 Consultar_ Alumno ()
 Eliminar_ Alumno ()
 Registrar_ Profesor()
 Modificar_ Profesor ()
 Consultar_ Profesor ()
 Eliminar_ Profesor ()
 Registrar_ Notas()
 Modificar_ Notas ()
 Consultar_ Notas ()
 Actualizar_base_datos()
 Actualizar_Datos_Plantel()
 Reportes()
161
CREAR EL DIAGRAMA DE SECUENCIA DEL SISTEMA, PARA LOS
CASOS DE USO
Un diagrama de secuencia muestra la interacción de un conjunto de
objetos en una aplicación a través del tiempo y se modela para cada caso de
uso; mientras que el diagrama de casos de uso permite el modelado de una
vista business del escenario, el diagrama de secuencia contiene sus detalles
de implementación, incluyendo los objetos y clases que se usan para
implementarlo, y mensajes intercambiados entre los objetos.
Típicamente se examina la descripción de un caso de uso para
determinar qué objetos son necesarios para la implementación del escenario.
Si se dispone de la descripción de cada caso de uso como una secuencia de
varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir
qué objetos son necesarios para poder seguirlos. Un diagrama de secuencia
muestra los objetos que intervienen en el escenario con líneas discontinuas
verticales, y los mensajes pasados entre los objetos como flechas
horizontales.
Como producto del estudio, y asimilación de los resultados obtenidos
anteriormente se elaboró los diagramas de secuencia del sistema, siguiendo
con la metodología de Larman (1999), evidenciándose lo mostrado en el
marco teórico en el que se señala que los diagramas de secuencia, estos
precisan la conducta del sistema, y se usan para visualizar la comunicación
entre los objetos. Ver gráficos 9, 10, 11, 12, 13, 14, 15 y 16.
162
DIAGRAMAS DE SECUENCIA CASO DE USO GESTIÓN ALUMNOS
Gráfico 17. Diagrama de Secuencia Gestión Alumnos (Registrar)

163
Gráfico 18. Diagrama de Secuencia Gestión Alumnos (Modificar)

Gráfico 19. Diagrama de Secuencia Gestión Alumnos (Consulta)

164
Gráfico 20. Diagrama de Secuencia Gestión Alumnos (Eliminación)

DIAGRAMAS DE SECUENCIA CASO DE USO GESTIÓN DOCENTES
Gráfico 21. Diagrama de Secuencia Gestión Docentes (Registrar)

165
Gráfico 22. Diagrama de Secuencia Gestión Docentes (Modificar)

Gráfico 23. Diagrama de Secuencia Gestión Docentes (Consulta)

166
Gráfico 24. Diagrama de Secuencia Gestión Docentes (Eliminación)

CONTRATOS
Una vez definidas las operaciones del sistema y los diagramas de
secuencia del sistema, obtenidos producto de las fases anteriores y
siguiendo la metodología de Larman (1999), se empieza a elaborar los
contratos para las operaciones del sistema, basándose en los resultados de
los pasos anteriormente mencionados.
CREAR CONTRATOS PARA LAS OPERACIONES DEL SISTEMA
Ya determinadas las operaciones del sistema resultado del paso
1.2.4.1, se pasa a realizar los contratos que son descripciones de las

167
operaciones del sistema, demostrándose con su realización lo mostrado en el
marco teórico, en el que se puede notar que son necesarios para
comprender el comportamiento del sistema. Como resultado se obtiene
entonces los mismos que se muestran a continuación.
CONTRATO
Nombre: Registrar().
Responsabilidades: Capturar datos de alumnos y docentes
Tipo: Sistema.
Notas: Utilizar el acceso a base de datos.
Excepciones: Si los datos introducidos no son válidos, indicar que se
cometió un error.
Precondiciones: El sistema tiene fases de introducción de datos, y
mecanismos de validación.
Poscondiciones:
- Si se trata de los datos de un alumno, el sistema creará un nuevo registro
de alumno y guardará sus datos en la base de datos.
- Si se trata de los datos de un docente, creará un nuevo registro de
docente y guardará los datos en la base de datos.

168
CONTRATO
Nombre: Consultar().
Responsabilidades: Capturar datos de alumnos y docentes ya existentes en
la base de datos.
Tipo: Sistema.
cometió un error.
Precondiciones: El sistema posee interfaces para introducir las consultas, y
Poscondiciones:
- Si se trata de los datos de un alumno, el sistema procesará la consulta, y
mostrará datos del mismo a través de la interfaz, concurrentes con la
consulta.
- Si se trata de los datos de un docente, el sistema procesará la consulta, y
mostrará datos del mismo a través de la interfaz, concurrentes con la
consulta.
169
CONTRATO
Nombre: Modificar().
Responsabilidades: Modifica datos de alumnos y docentes ya existentes en
la base de datos.
Tipo: Sistema.
cometió un error.
Precondiciones: El sistema posee interfaces para introducir los datos, y
Poscondiciones:
- Si se trata de los datos de un alumno, El sistema posee interfaces para
introducir los datos, y mecanismos de validación.
- Si se trata de los datos de un docente, El sistema posee interfaces para
introducir los datos, y mecanismos de validación.

170
CONTRATO
Nombre: Verificar_alumno().
Responsabilidades: Validar datos referentes a los alumnos a nivel de
interfaz para luego almacenarlas en la base datos.
Tipo: Sistema.
Notas: Utilizar la interfaz de usuario (ventana).
cometió un error.
mecanismos de validación, incrustados en las interfaces.
Poscondiciones:
- Una vez validados los datos a nivel de interfaz estarán listos para
ingresarse en la base de datos disminuyendo los riesgos, de
transacciones inválidas que consumen recursos y que pueden restarle
integridad a los datos.

171
CONTRATO
Nombre: Verificar_docente().
Responsabilidades: Validar datos referentes a los docente a nivel de
interfaz para luego almacenarlas en la base datos.
Tipo: Sistema.
cometió un error.
mecanismos de validación, incrustados en las interfaces.
Poscondiciones:
- Una vez validados los datos a nivel de interfaz estarán listos para
ingresarse en la base de datos disminuyendo los riesgos, de
transacciones inválidas que consumen recursos y que pueden restarle
integridad a los datos.

172
CONTRATO
Nombre: Ingresar_Alumno().
Responsabilidades: Asegurar de que solo los alumnos mostrados luego de
la ejecución de Verificar_alumno(), sean ingresadas para su modificación,
consulta o eliminación.
Tipo: Sistema.
Excepciones: Si se introduce un código de alumno (cedula) no válido,
indicar que se cometió un error.
Precondiciones: El sistema posee interfaces donde se muestran los estados
de los alumnos y mecanismos de validación, incrustados en las interfaces.
Poscondiciones:
- Una vez ejecutada la operación los datos del alumno podrán ser
modificado, consultados o eliminados.

173
CONTRATO
Nombre: Ingresar_docente().
Responsabilidades: Asegurar de que solo los docentes mostrados luego de
la ejecución de Verificar_docente(), sean ingresadas para su modificación,
consulta o eliminación.
Tipo: Sistema.
Excepciones: Si se introduce un código de docente (cedula) no válido,
indicar que se cometió un error.
Precondiciones: El sistema posee interfaces donde se muestran los estados
de los alumnos y mecanismos de validación, incrustados en las interfaces.
Poscondiciones:
- Una vez ejecutada la operación los datos del alumno podrán ser
modificado, consultados o eliminados.

174
CONTRATO
Nombre: Actualizar_base_datos().
Responsabilidades: Validar datos de alumnos y docentes para ingresarlos
en la base de datos.
Tipo: Sistema.
cometió un error.
Precondiciones: La base de datos está correctamente diseñada, al igual
que los mecanismos de validación.
Poscondiciones:
- Si se trata de datos de un alumno, se validarán los datos de mismo, luego
se procederá a actualizar la base de datos
- Si se trata de datos de un docente, se validarán los datos de la misma, y
luego se procederá a actualizar la base de datos.

175
CONTRATO
Nombre: Reporte().
Responsabilidades: Generar reportes con información, de alumnos, y
docentes en la isntitución.
Tipo: Sistema.
Excepciones: Si no hay datos disponibles no se podrá generar el reporte.
Precondiciones: El sistema posee interfaces para crear el reporte.
Poscondiciones:
- Se generarán reportes de acuerdo a la necesidad del usuario, conteniendo
datos de alumnos, y docentes, en formato digital y/o papel.
CREAR DIAGRAMAS DE ESTADO PARA LOS CASOS DE USO
Los diagramas de estado muestran el conjunto de estados por los
cuales pasa un objeto durante su vida en una aplicación en respuesta a
eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto
con sus respuestas y acciones. También ilustran qué eventos pueden
cambiar el estado de los objetos de la clase. Normalmente contienen:
estados y transiciones. Como los estados y las transiciones incluyen, a su
vez, eventos, acciones y actividades, vamos a ver primero sus definiciones.
Al igual que otros diagramas, en los diagramas de estado pueden
aparecer notas explicativas y restricciones.

176
Hay quienes consideran que los diagramas de estado son naturales,
pero muchos no los consideran así. Preste atención al modo en que los
emplean quienes trabajan con ellos; podría ocurrir que su equipo no
considere útiles los diagramas de estados, debido a su modo de trabajar.
Esto no sería un gran problema; como siempre, deben combinarse las
técnicas que sean de utilidad.
Como resultado del estudio y asimilación de la información obtenida
en el paso anterior se realizaron los diagramas de estado para el sistema,
luego de esto se comprueba que describen el comportamiento de un objeto
individual con varios estados y transiciones entre esos estados tal y como se
refiere en el marco teórico. Los resultados de este paso son los diagramas de
estado que se muestran en los gráficos 17, 18, 19, 20, 21, 22, 23 y 24.
DIAGRAMAS DE ESTADO PARA CASO DE USO GESTIÓN ALUMNOS
Gráfico 1. Diagrama de Estado Gestión Alumnos (Registrar)

177
Gráfico 26. Diagrama de Estado Gestión Alumnos (Modificar)

Gráfico 27. Diagrama de Estado Gestión Alumnos (Consulta)

178
Gráfico 28. Diagrama de Estado Gestión Alumnos (Eliminación)

DIAGRAMAS DE ESTADO PARA CASO DE USO GESTIÓN DOCENTES
Gráfico 29. Diagrama de Estado Gestión Docentes (Registrar)

179
Gráfico 30. Diagrama de Estado Gestión Docentes (Modificar)

Gráfico 31. Diagrama de Estado Gestión Docentes (Consulta)

180
Gráfico 32. Diagrama de Estado Gestión Docentes (Eliminación)

Para darle consecución y cumplimiento al tercer objetivo Diseñar
lógica y físicamente el software informático para la gestión de los
procesos administrativos en la Escula Básica Nacional “Dr. Leonardo
Ruiz Pineda”. en correspondencia con la primera fase III y IV de la
metodología referente al Diseño y Construcción respectivamente.
Después de finalizada la fase de análisis los resultados se utilizan para
la fase de diseño y construcción, siguiendo la metodología de Larman (1999),
esto facilitó la obtención de las herramientas de la fase de diseño y
construcción que se muestran a continuación.

181
DESCRIPCIÓN DE LOS CASOS REALES DE USO
Basándose en los resultados obtenidos de las fases anteriores se
procede a describir los casos de usos en concordancia con la metodología
seleccionada.
CREAR CASOS REALES DE USO
Apoyándose en la metodología, Larman (1999), y estudiando los
resultados de las otras fases y pasos, se elaboro los casos reales de uso,
obteniendo como resultado la siguiente información que se detalla a
continuación:
Propósito: Ingresar un Alumno.
registrados.
Tipo: Primario, esencial y Real.

182
Cuadro 12
1. El Representante llega a la Institución

y solicita el ingreso del alumno.
alumno.
solicitante ya está inscrito y carga los
datos del alumno.
4. el Coordinador solicita al
representante las notas certificadas,
registro académico y demás datos básico
que se requieran. 5. El sistema actualiza la base de datos y
ser realizada.
registro exitoso.
7.- el Coordinador Entrega al

representante una constancia de
inscripción y espera hasta que éste esté
conforme.
Tipo: Primario y real.
Propósito: Modificar los datos un Alumno.
Descripción: El representante llega a la Institución, el coordinador toma los
datos del alumno requeridos al representante y los ingresa en el sistema,
verificando que estos estén registrados en la base de datos. Si el coordinador
observa algún cambio en los datos suministrados, o el representante solicita
cambiar alguno de ellos, el coordinador pasa a modificar los datos del mismo.
183
Cuadro 13
2. El representante llega a la
institución y solicita un cambio en los
datos

Alumno.
datos del alumno.
4. El coordinador le solicita al
representante los datos a modificar.
realizada.
7.- El coordinador entrega al

representante confirma la modificación y
Propósito: Consulta los datos un Alumno.
Descripción: El coordinador realiza una consulta de los datos de un alumno

184
Cuadro 14

alumno.
datos del alumno.
3.- El coordinador le solicita al

representante que datos va a consultar.

realizada.
5. Muestra el pantalla la consulta exitosa

hallada.
requerimiento del representante
informándolo sobre el resultado de la
consulta y espera hasta que éste esté
conforme.
Propósito: Eliminación los datos un Alumno.
Descripción: El coordinador realiza la eliminación de los datos de un alumno
y entrega un registro académico con toda la información del alumno.

185
Cuadro 15

ingresa los datos del alumno. 2. El sistema verifica si el alumno
datos del alumno.

eliminación del alumno del sistema.

realizada.
5. el sistema genera e imprime el registro

académico del alumno.
6.- El coordinador entrega el registro
académico y espera hasta que éste esté
conforme.
Propósito: Ingresar un docente.
Descripción: El docente entre informa sobre su carga de horas e
información básica requerida: materia impartida, etc., el coordinador toma los
datos del docente y los ingresa en el sistema, verificando que estos
registrados.
Tipo: Primario, esencial y real.

186
Cuadro 16

docente.

solicitante ya está registrado y carga los
datos del docente.
3. el Coordinador solicita al docente
carga de horas, materia impartida, etc y
demás datos básico que se requieran.
ser realizada.
registro exitoso.
6.- el Coordinador Entrega al docente
carga de horas y espera hasta que éste
esté conforme.
Propósito: Modifica información de un docente.
Descripción: El docente llega a Coordinación, el coordinador toma los datos
del docente requerido y los ingresa en el sistema, verificando que estos estén
registrados en la base de datos. Si el coordinador observa algún cambio en
los datos suministrados, o el docente solicita cambiar alguno de ellos, el
coordinador pasa a modificar los datos del mismo.

187
Cuadro 17
2. El docente llega a la institución y

solicita un cambio en los datos

docente.

datos del alumno.
4. El coordinador le solicita al docente
los datos a modificar.
realizada.
7.- El coordinador entrega al docente

confirma la modificación y espera hasta
que éste esté conforme.
Propósito: Consulta los datos un Docente.
Descripción: El coordinador realiza una consulta de los datos de un docente

188
Cuadro 18

docente
datos del docente.
3.- El coordinador le solicita al docente

que datos va a consultar.

realizada.
5. Muestra en pantalla la consulta exitosa

hallada.
requerimiento del docente informándolo
sobre el resultado de la consulta y
Propósito: Eliminación los datos un docente.
Descripción: El coordinador realiza la eliminación de los datos de un
docente.
189
Cuadro 19

ingresa los datos del docente. 2. El sistema verifica si el docente
datos del docente.

eliminación del docente del sistema.

realizada.
5. Muestra en pantalla la eliminación

exitosa.
6.- El coordinador informa al docente
que se encuentra retirado del sistema y
MAPEO DE LOS DISEÑOS PARA CODIFICACIÓN
Después de realizados los diagramas de clase del diseño y
consignados al ciclo de desarrollo actual, se disponen de suficientes detalles
para generar código que se usará con la finalidad de construir el sistema,
como resultado de esto se escribió código fuente para:
Definiciones de clase.
Definiciones de métodos.
Siguiendo la metodología de Larman (1999).

190
CREACIÓN DE LAS DEFINICIONES DE CLASE A PARTIR DE LOS
DIAGRAMAS DE CLASE DEL DISEÑO
Los datos que generan los diagramas de clase de diseño (nombres de
las clases, etiquetas de los métodos, atributos simples de una clase), es
suficiente para fijar una definición de la clase en un lenguaje orientado a
objetos, se obtuvo como resultado entonces las definiciones de las clases en
un lenguaje orientado a objetos, específicamente Visual Basic 6.0, siguiendo
la metodología Larman (1999).
CREACIÓN DE MÉTODOS A PARTIR DE LOS DIAGRAMAS DE
COLABORACIÓN
Los diagramas de colaboración son los que muestran los mensajes que
se envían como resultado de la llamada a un método, producto de este paso
la sucesión de mensajes se tradujo a una serie expresada en la definición del
método.
En los diagramas de colaboración, los objetos ejemplo se muestran
como iconos. Las flechas indican, como en los diagramas de secuencia, los
mensajes enviados dentro del caso de uso dado. Sin embargo, en esta
ocasión la secuencia se indica numerando los mensajes.
El numerar los mensajes dificulta más ver la secuencia que poner las
líneas verticales en la página. Por otra parte, la disposición espacial del
diagrama permite mostrar otras cosas mejor. Se puede mostrar cómo se

191
vinculan entre ellos los objetos y emplear la disposición para sobre poner
paquetes u otra información.
Se puede usar alguno de los diversos esquemas de numeración para
los diagramas de colaboración. En el pasado, el esquema más utilizado era
el de la numeración simple. El UML utiliza el esquema decimal, pues hace
evidente qué operación llama a otra y cuál es esa otra, aunque pueda ser
más difícil apreciar la secuencia general.
ACTUALIZACIONES DE LAS DEFINICIONES DE CLASES
Producto de este paso, partiendo de decisiones de codificación se
modificaron las definiciones de clases y los diagramas de clase de acuerdo a
los cambios en la codificación.
ORDEN DE IMPLEMENTACIÓN
Como resultado de este paso, se realizaron las clases de la menos
ajustada a la más ajustada; es decir de las más autónomas a las menos
autónomas.
A continuación se presenta el prototipo diseñado, en donde al entrar
al portal se le presentará la siguiente pantalla para el inicio de sesión.

192
Gráfico 332. Acceso al Sistema.

En el gráfico 25, el usuario deberá ingresar sus datos de inicio de
sesión, y enviar la información con el fin de validar la cuenta, y permitirle el
acceso al sistema. En la pantalla de bienvenida se presentarán las opciones
en las cuales el usuario del sistema podrá escoger la función que desea
realizar como gestionar alumnos, docentes, consultas de reportes, entre
otros.
193
Gráfico 34. Menú principal.

En el gráfico 27 haciendo uso de los módulos encontrados el usuario
podrá registrar, modificar, consultar y eliminar, cualquier información
concerniente a las clases alumnos y docentes.
Gráfico 35. Modulo de consulta

194
Para darle cumplimiento al último objetivo especifico relacionado con
Demostrar la Funcionabilidad del Software informático a través de
pruebas especificas, en correspondencia con la última fase de la
metodología Pruebas del Sistema, propuesta por García (2000); se
realizaron una serie de pruebas escogidas para determinar si el sistema
cumple con los requerimientos propuestos inicialmente y con su función
principal, servicio de manera eficiente y sin fallas o retrasos.
Para la prueba del nuevo sistema se usó la estrategia de la caja
negra, debido a que lo esencial es el que se cumpla con las especificaciones
y requerimientos hechos por los usuarios sin prestar atención al código
fuente de los programas. Como producto de esta fase se determino que se
busca cumplan los siguientes aspectos:
a-) Capacidad del sistema para realizar operaciones rápidamente.
b-) Establecer la capacidad de datos que soporta.
c-) Habilidad de realizar operaciones complejas.
d-) Establecer el nivel de adiestramiento necesario para su uso
correcto.
e-) Evaluar la conducta del sistema bajo condiciones diarias del
Departamento Administrativo y los diversos ambientes que se presentan en
el mismo.
f-) Obtener los posibles errores.
Para finalizar los objetivos planteados previamente se establecieron dos
elementos principales:
195
 Subsistemas.
 El Sistema en su totalidad.
Para este proceso se utilizó el software de programación PHP utilizado
para la construcción del sistema, y se uso el método de prueba Bottom-Up o
de abajo hacia arriba el cual consiste en probar individualmente cada
elemento de nivel inferior, luego se agregan los elementos que los solicitan,
hasta incluir el sistema terminado, en primer lugar se evaluaron los
subsistemas por separado, luego las interacciones, entre ellos, y finalmente
todo el sistema bajo diferentes situaciones, para examinar que
funcionamiento sea efectivo en el ambiente real, los problemas que
presentaba y los puntos fuertes y críticos del mismo.
Como siguiente paso se estableció un plan de pruebas conformado de
la siguiente manera:
a-) Prueba Gestión de Alumnos.
b-) Prueba Gestión de Docentes.
Para la elaboración de los casos de prueba se consideraron los datos
obtenidos durante un periodo de observación dentro de la organización, con
lo cual se obtuvo un mayor entendimiento de los procesos.
PRUEBAS DEL SISTEMA
Para las pruebas de estrés se determinó que la aplicación soporta
para determinar la solidez de la aplicación en los momentos de carga

196
extrema, esta prueba se utiliza normalmente para romper la aplicación, es
decir, se va aumentando el número de usuarios que se agregan a la
aplicación y se ejecuta una prueba de carga hasta que colapsa. Este tipo de
prueba se realiza y ayuda a los administradores para determinar si la
aplicación rendirá lo suficiente en caso de que la carga real supere a la carga
esperada.
De igual forma, se realizara una prueba de estabilidad, esta determina
si la aplicación puede aguantar una carga esperada continuamente. Y una
prueba de picos, con la cual se observa el comportamiento del sistema
variando el número de usuarios, tanto cuando bajan, como cuando tiene
cambios drásticos en su carga.
Además se realiza una prueba de integración, para validar que todos
los módulos funcionen bien en conjunto; y una prueba de compatibilidad para
asegurar que el portal funciona correctamente en la plataforma de la
empresa.
Para finalizar se hicieron pruebas de seguridad, para certificar que
sólo puedan ingresar al sistema los usuarios existentes, y que sólo puedan
observar la información de sus productos, y no la de los demás proveedores.
PRUEBA DE ACEPTACIÓN
De los resultados obtenidos de la aplicación de este paso se realizó la
prueba de aceptación general, en esta se efectuaron casos de prueba mas
usuales y algunos de los más inseguros, para evidenciar el hecho de que el

197
sistema cumple con todos y cada uno de las exigencias establecidas en el
inicio de una manera decente y que el sistema se encuentra finalizado y listo
para ser implantado con un mínimo de fallas.
Finalizado el proceso de prueba, se contempló que todas las
exigencias fueron satisfechas y todos los objetivos fueron alcanzados de
forma grata, cumpliendo con las metas del sistema y añadiendo nuevas
funciones, las cuales traen grandes beneficios a la organización, tanto en lo
operacional como en lo económico trayendo menor tiempo y costo de
operación.
2. DISCUSIÓN DE LOS RESULTADOS
Para la discusión de los resultados se confrontaron las teorías de la
metodología con los hallazgos obtenidos cumpliendo las actividades del
cuadro en función de los objetivos específicos y de las fases.
Para el análisis de la situación actual de los requerimientos del
suministro de información de la institución educativa, se comprobó mediante
la información general de la empresa, que ésta cuenta con los elementos
organizacionales formalmente establecidos, destacando conocimientos
básicos en el uso de equipos computarizados; y que cuenta con los recursos
técnicos requeridos para el desarrollo del portal.
Y para la determinación de los requerimientos funcionales se
conocieron mediante entrevistas, cuestionarios y observación directa las
fallas existentes, y se establecieron los requerimientos, permitiendo describir

198
los escenarios básicos y los casos de usos básicos del sistema. De esta
forma, se dio cumplimiento a la primera fase de la metodología sugerida por
Larman (1999). Como primer requisito para el desarrollo del software
informático para la gestión de los procesos administrativos.
También, continuando con el objetivo anterior, se constató que los
equipos con la que cuenta la institución se encuentran funcionando de
manera correcta y es compatible con el sistema desarrollado. Además se
recaudó la información necesaria para poder esbozar cuales serian los casos
de uso del sistema.
Y para el diseño del software informático para la Escula Básica
Nacional “Dr. Leonardo Ruiz Pineda”, se hizo una visita con la que se pudo
clarificar las dudas respecto al diseño del software informático; partiendo de
ello se elaboró el diagrama entidad-relación que sirvió de insumo en el
diseño para la base de datos. De esta forma, se dio cumplimiento a la
segunda fase de la metodología sugerida por Larman (1999), como segundo
requisito para el desarrollo del software informático para la gestión de los
procesos administrativos.
Para el diseño y construcción del portal del software informático para
la gestión de los procesos administrativos en la Escula Básica Nacional “Dr.
Leonardo Ruiz Pineda”, se completó el diseño de los diagramas de casos de
uso, permitiendo la programación de los módulos del prototipo y su posterior
integración. Luego de finalizado el portal de servicios se elaboró un manual
que le servirá de guía o ayuda a los usuarios en caso de necesitarla. Así,

199
se dio cumplimiento a la tercera y cuarta fase de la metodología sugerida por
Larman (1999), como tercer requisito para el desarrollo del software
informático para la gestión de los procesos administrativos.
Para la validación del diseño del software informático para la gestión
de los procesos administrativos en la Escula Básica Nacional “Dr. Leonardo
Ruiz Pineda”, se diseñaron las pruebas, se validaron mediante uso directo
por parte del personal de la institución para comprobar su funcionalidad. Se
realizó un registro de los resultados de dichas pruebas, lo que permitió la
realización de un análisis, y la realización de las correcciones necesarias;
obteniendo así el producto final deseado. Se dio cumplimiento a la última
fase de la metodología sugerida por García (2000), como el requisito final
para el desarrollo del portal de servicios.

Capítulo Iv Resultados de La Investigación

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capítulo Iv Resultados de La Investigación

Cargado por

Copyright:

Formatos disponibles

CAPÍTULO IV

En este capítulo se presentan los hallazgos de la investigación

producto del trabajo de campo y la aplicación de diferentes instrumentos

diseñados para cumplir exitosamente con los objetivos de la investigación,

así como también el estudio de la factibilidad, aprobación de la solicitud y el

análisis de la información recopilada. Confirmándose o no los objetivos

propuestos y; se evidencia el alcance de la propuesta investigativa. En él se

procede a presentar una visión de conjunto del proceso investigativo hasta

presentar sus resultados o el producto mismo.

1. ANÁLISIS DE LOS DATOS

Una vez aplicados los instrumentos se procede al análisis de la

información de manera cualitativa.

1.1. DESARROLLO DE LAS FASES DE LA METODOLOGÍA

Para darle cumplimiento al primer objetivo especifico, Analizar los

procesos administrativos llevados a cabo actualmente en la Escula

Básica Nacional “Dr. Leonardo Ruiz Pineda”, en correspondencia con

la primera fase de la metodología referente a la Planeación y Elaboración,

se logro la aclaración a través de una visita a la institución, donde se pudo

laboran como docentes.

Esta fase está basada en los resultados que se obtuvieron por la

aplicación de los instrumentos de recolección de datos, los cuales se

encuentran constituidos por el Cuestionario, la Entrevista y la Guía de

Observación Directa. Ver Anexos, B, C y D.

Del mismo modo, se mostrará lo comprobado durante la visita donde

se consiguió conocer a través de una guía de observación, entregada a la

Lic. Adalis Mujica, Sub-Directora del plantel, compuesta por 15 acciones a

evaluar, 10 a nivel de Hardware y 5 a nivel Software, donde, se tildaban

preguntas simples de registro de cumplimiento (SI, NO, N/A) pudo

constatarse que en cuanto a hardware la institución cuenta con: 2 CPU’s

Genéricos, 2 monitores Dell LCD 20”, impresoras HP 2035 y, teclados y

mouse; mientras que al referirse a Software se puede afirmar que la empresa

para la implantación y mantenimiento de todos los procesos relacionados al

portal de servicios de los proveedores.

En este mismo orden de ideas, se realizo una entrevista no

estructurada a la Docente de Aula II Lic. Lorna Oberto, documento

llevados por la institución, evidenciando la problemática actual, sintetizando

Considera que el sistema actual es eficiente porque cumple con los

requerimientos básicos pero pueden mejoraren su opinión. Por otra parte,

menciona: Boletines Escolares, Resumen de Notas, Certificados de Notas,

Constancias de trabajo y de estudios, Matrículas Nóminas de Estudiantes,

Resumen de Actas para consejos, una serie de formatos como Actas,

citaciones, libros de vida fichas escolares, entre otras

Informa que las fallas comunes en los procesos mencionados se

deben llenar desde cero y con expediente en mano restando rapidez al

mismo. Aceptado el hecho de que, a través de un sistema de información se

permita automatizar dichos procesos permitiendo lograr mayor productividad

y mejores tiempo de respuesta, porque con un programa con una base de

podrían entregar con mayor rapidez a las partes interesadas y acortaría el

tiempo de trabajo frente al computador

Más adelante, en la entrevista asevera que un punto crítico en sus

procesos administrativos actuales es el manejo de notas por lapso de cada

estudiante este proceso se realiza manualmente, ya que es necesario la

discusión y modificación de notas por estudiante y no tenemos un sistema

más eficiente el realizarlo manualmente debido el tiempo y efectividad del

En sus respuestas siguientes comenta que la institución cuenta con

equipos e infraestructura para implantación del nuevo sistema propuesto

aunque considera los equipos limitados en su configuración. En la institución

están dispuestos a recibir entrenamiento para el uso de un nuevo sistema

Por su parte, a la Subdirectora Lic. Adalys Mujica, se le realizó la una

encuesta encontrando los siguientes resultados:

En relación a la primera pregunta, no considera que su sistema actual

sea eficiente, ya que, en toda institución se lleva a cabo el proceso

administrativo de manera manual, pero al tecnificarlo, se hará más productivo