UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMATICAS …

UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS

CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES

ELABORACIÓN DE CASOS DE PRUEBAS DEL PROCESO DE HORARIOS

DE CLASES Y RECURSOS DISPONIBLES PARA IMPLEMENTAR

EL PROTOTIPO DE SISTEMA ACADÉMICO

EN LA UNIVERSIDAD

DE GUAYAQUIL

TESIS DE GRADO

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

INGENÍERO EN SISTEMAS COMPUTACIONALES

AUTOR:

FERNANDO VICENTE GORDON YÉPEZ

TUTOR:

ING. MARY CABANILLA

GUAYAQUIL – ECUADOR JULIO 2015

REPOSITORIO NA

FICH

TÍTULO: “ELABORACIÓN DEHORARIOS DE CLASES Y PROTOTIPO DE SISTEMA ACA

INSTITUCIÓN: Universidad de

CARRERA: Ingeniería en Siste

FECHA DE PUBLICACIÓN: J

ÁREA TEMÁTICA: Pruebas

PALABRAS CLAVES: Plan de

RESUMEN: La importancia de cotidianas de trabajo han provoca realizar, la cual debe de ser valmitigado de errores, se determPruebas, lo que garantizará el cviaje libre de embotellamientos ylas personas interesadas. Se esnos llevan a que este sistema es N° DE REGISTRO(en base de

DIRECCIÓN URL (tesis en la w

ADJUNTO PDF

CONTACTO CON AUTOR:

CONTACTO DE LA INSTITU

NACIONAL EN CIENCIAS Y TECNOLOGÍA

CHA DE REGISTRO DE TESIS

E CASOS DE PRUEBAS DEL PROCESO DE RECURSOS DISPONIBLES PARA IMPLEMADÉMICO EN LA UNIVERSIDAD DE GUAYAQU

REVISORES:

de Guayaquil FACULTAD: Cienciasy Físicas

temas Computacionales

Julio del 2015 N° DE PÁGS.: 167

de pruebas horarios de clases y recursos disponi

de poder contar con una herramienta que sopoocado que se diseñe un prototipo que organice la validada y correctamente sistematizada para obmina la necesidad de elaborar un documento l correcto funcionamiento del programa y que la y se cumplan con los estándares y requisitos plstablece mediante este estudio que todos los pl

es adaptable en su totalidad.

e datos): N° DE CLASIFICACIÓNº

a web):

X SI NO

Teléfono: 0986927300

E-mail: [email protected]

UCIÓN Nombre: Teléfono:

ÍA

E CREACIÓN EMENTAR EL QUIL”

as Matemáticas

nibles.

orte las tareas las actividades obtener un flujo o de Casos de la información planteados por planteamientos

ÓN:

O

l.com

APROBACION DEL TUTOR

En mi calidad de Tutor del trabajo de investigación, “ELABORACIÓN DE CASOS DE

PRUEBAS DEL PROCESO DE CREACIÓN HORARIOS DE CLASES Y RECURSOS

DISPONIBLES PARA IMPLEMENTAR EL PROTOTIPO DE SISTEMA ACADÉMICO

EN LA UNIVERSIDAD DE GUAYAQUIL“ elaborado por el Sr. FERNANDO VICENTE

GORDON YÉPEZ, egresado de la Carrera de Ingeniería en Sistemas

Computacionales, Facultad de Ciencias Matemáticas y Físicas de la Universidad de

Guayaquil, previo a la obtención del Título de Ingeniero en Sistemas, me permito

declarar que luego de haber orientado, estudiado y revisado, la Apruebo en todas sus

partes.

Atentamente

Ing. Mary Cabanilla

DEDICATORIA

Dios es mi fortaleza, la Gloria y

la Honra a nuestro Señor

Jesucristo. Dedico sin duda

alguna este triunfo a los pilares

de mi vida, a mi amada esposa

Solange Bueno, a mi hijo

Mathías Gordon Bueno, a mi

madre Isabel Yépez y a mi

hermano Dr. Rafael Gordon

Yépez, por su paciencia, apoyo

inquebrantable, sobre todo por

creer en mí esfuerzo y

capacidad para obtener mi título

profesional.

AGRADECIMIENTO

En general a las autoridades de la

Carrera de Ingeniería en Sistemas

Computacionales por siempre

mostrarnos el camino correcto, a

los Ing. Tutores por su invaluable

tiempo para guiarnos de la

manera correcta a realizar

nuestras actividades, a mi primo,

Anl. Giovanny Yépez Rivera por

sus valiosos aportes y

conocimientos y a mi gran amigo,

Fernando Mendoza Orrala por

apoyarme en todo este trayecto

profesional, el cual juntos hemos

superado.

TRIBUNAL DE GRADO

Ing. Eduardo Santos Baquerizo, M.Sc. DECANO DE LA FACULTAD CIENCIAS MATEMATICAS Y

FISICAS

Ing. Harry Luna Aveiga, M.Sc. DIRECTOR (E)

CISC, CIN

Ing. Mary Cabanilla DIRECTOR DE TESIS

Ing. Katya Faggioni, M.Sc. PROFESOR DEL ÁREA -

TRIBUNAL

Ing. Manuel Reyes W. Ab. Juan Chávez A. PROFESOR DEL ÁREA – SECRETARIO

TRIBUNAL

DECLARACIÓN EXPRESA

“La responsabilidad del contenido de esta Tesis de Grado, me corresponden exclusivamente; y el patrimonio intelectual de la misma a la UNIVERSIDAD DE GUAYAQUIL”

FERNANDO VICENTE GORDON YÉPEZ

UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS

CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES

ELABORACIÓN DE CASOS DE PRUEBAS DEL PROCESO DE HORARIOS



EN LA UNIVERSIDAD

DE GUAYAQUIL

Tesis de Grado que se presenta como requisito para optar por el título de:

INGENIERO EN SISTEMAS COMPUTACIONALES

Autor/a: FERNANDO VICENTE GORDON YÉPEZ

C.I.: 092109768-9

Tutor: ING. MARY CABANILLA

Guayaquil, Julio de 2015

CERTIFICADO DE ACEPTACIÓN DEL TUTOR

En mi calidad de Tutor de Tesis de Grado, nombrado por el Consejo Directivo de la Facultad de Ciencias Matemáticas y Físicas de la Universidad de Guayaquil.

CERTIFICO:

Que he analizado el Proyecto de Grado presentado por el/la

estudiante FERNANDO VICENTE GORDON YÉPEZ, como requisito previo

para optar por el título de Ingeniero en Sistemas Computacionales cuyo

problema es: ELABORACIÓN DE CASOS DE PRUEBAS DEL PROCESO DE

CREACIÓN HORARIOS DE CLASES Y RECURSOS DISPONIBLES PARA

IMPLEMENTAR EL PROTOTIPO DE SISTEMA ACADÉMICO EN LA

UNIVERSIDAD DE GUAYAQUIL.

Considero aprobado el trabajo en su totalidad.

Presentado por:

FERNANDO VICENTE GORDON YÉPEZ C.I. 092109768-9

Tutor: Ing. Mary Cabanilla

Guayaquil, Julio de 2015

UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS


Autorización para Publicación de Tesis en Formato Digital 1. Identificación de la Tesis Nombre Alumno: FERNANDO VICENTE GORDON YÉPEZ Dirección: SAUCES 7 MZ 440 V 15 Teléfono: 042641651 E-mail: [email protected] Facultad: CIENCIAS MATEMÁTICAS Y FÍSICAS Carrera: INGENIERÍA EN SISTEMAS COMPUTACIONALES Título al que opta: INGENIERO EN SISTEMAS COMPUTACIONALES Profesor guía: ING. MARY CABANILLA Título de la Tesis: ELABORACIÓN DE CASOS DE PRUEBAS DEL PROCESO DE CREACIÓN HORARIOS DE CLASES Y RECURSOS DISPONIBLES PARA IMPLEMENTAR EL PROTOTIPO DE SISTEMA ACADÉMICO EN LA UNIVERSIDAD DE GUAYAQUIL Temas Tesis: PROTOTIPO DE SISTEMA ACADÉMICO, PRUEBAS, UNITARIAS, PRUEBAS FUNCIONALES. 2. Autorización de Publicación de Versión Electrónica de la Tesis A través de este medio autorizo a la Biblioteca de la Universidad de Guayaquil y a la Facultad de Ciencias Matemáticas y Físicas a publicar la versión electrónica de esta tesis. Publicación electrónica: Inmediata x Después de 1 año Firma Alumno: 3. Forma de envío: El texto de la Tesis debe ser enviado en formato Word, como archivo .Doc. O .RTF y .Puf para PC. Las imágenes que la acompañen pueden ser: .gif, .jpg o .TIFF. DVDROM x CDROM

ÍNDICE GENERAL

CARTA DE ACEPTACIÓN DEL TUTOR II DEDICATORIA III AGRADECIMIENTO IV ÍNDICE GENERAL IX ÍNDICE DE CUADROS X ÍNDICE DE GRÁFICOS XI RESUMEN VI (ABSTRACT) VII

INTRODUCCIÓN 1

CAP. I - EL PROBLEMA Ubicación del problema 3 Situación nudos críticos 4 Causas y Consecuencias 5 Delimitación el problema 6 Formulación del problema 6 Evaluación del problema 7-8 OBJETIVOS Objetivo General 9 Objetivos Específicos 9 Alcance del problema 10 Justificación e Importancia 11

CAP II – MARCO TERÓRICO Antecedentes del estudio 12 Fundamentación teórica 13 Sistema académico 13 Prototipo de sistema académico 13 Pruebas unitarias 14 Prueba funcionales 14 Hardware 14 Software de sistema 15 FrameworkZK 15 Eclipse Luna 16 Hibernate 17 Apache Jmater 17 Tomcat 18 SQL Server 18 PLAN DE PRUEBAS 19-21 ENTORNO DE PRUEBAS 22

ROLES Y RESPONSABILIDADES 23 IDENTIFICACIÓN DE PRUEBAS 24 Pruebas de Caja Negra 25 Método en V 25 Pruebas de Sistema 28 Pruebas de Contenido 28 Pruebas Funcionales 28 Pruebas Unitarias 28 Entorno Local 29 Pruebas con usuarios 29 CASOS DE PRUEBAS 30 CLASIFICACIÓN SEGÚN FUENTE DE INFORMACIÓN 32 CRITERIO DE SUFICIENCIA 32 CRITERIO ESTRUCTURALES 33 FUNDAMENTACIÓN LEGAL Art. 8 Fines de la educación superior 34 Art. 28 Exoneraciones tributarias 35 Art. 71 Principio de Igualdad 36 Art. 117 Tipología de las Instituciones 36 Art. 12 Ley y reglamento de matriculación 37 Art. 149 Tipos de profesores o profesoras 38 HIPOTESIS 40 VARIABLES 40 DEFINICIONES CONCEPTUALES Horario de clases 41 Recursos disponibles 41 Carga horaria docente 41 Factibilidad 41 Requerimiento 41 Flujo transaccional 42 Operatividad 42 Tiempo de respuesta 42 Capacitación 42 Ley de educación superior 42

CAP III – METODOLOGÍA – DISEÑO DE LA INVESTIGACIÓN INTRODUCCIÓN 43 DEFINICIONES BÁSICAS Espacio muestral 44 Variable aleatorio 44 Población investigada 45 Población Objetivo 45 Marco muestral 45 Muestra 45 Muestra aleatoria 46 Muestreo 46 Variable Cuantitativa 46 Variable Cualitativa 46

POBLACIÓN Y MUESTRA Población 47 Muestra 47 INSTRUMENTO DE RECOLECCIÓN DE DATOS ENCUESTA 50-51 VARIABLES CUANTITATIVAS 52 VARIABLES CUALITATIVAS 52 CODIFICACIÓN DE LAS VARIABLES ENTREVISTA 57 PROPUESTA ENTREVISTA 59 OPERACIONALIZACIÓN DE VARIABLES 60 PREVIO ANÁLISIS PLAN DE PRUEBAS 62 ANÁLISIS ESTADÍSTICO 63-95 PLAN DE PRUEBAS MISIÓN DE LAS PRUEBAS 101 ELEMENTO OBJETIVO DE LAS PRUEBAS 107 PANORAMA DE LAS PRUEBAS 109 ENFOQUE DE LAS PRUEBAS 110 CRITERIOS DE ENTRADA Y SALIDA 112 DATOS DE PRUEBA 114 RESPONSABILIDADES Y EQUIPO DE TRABAJO 115 RIESGOS DE LAS PRUEBAS 116 DIAGRAMA PLAN DE PRUEBAS 118 RESULTADO DE LAS PRUEBAS RESULTADOS DE LA PLANIFICACIÓN 119 SEGUIMIENTO DE LAS PRUEBAS 119 CONCLUSIONES Y RECOMENDACIONES DEL PLAN DE PRUEBAS 124 CRITERIOS PARA LA ELABORACIÓN DE LA PROPUESTA MAPA PROCESO DE ADMINISTRACIÓN 125 MAPA PROCESO PROTOTIPO DEL SISTEMA ACADÉMICO 126 ANÁLISIS DE MAPAS DE PROCESOS 127 DISEÑO PLAN DE PRUEBAS 130 CITERIOS DE VALIDACIÓN DE LA PROPUESTA 132 CAP IV – MARCO ADMINISTRATIVO CRONOGRAMA 135 PRESUPUESTO 138

CAP V – CONCLUSIONES Y RECOMENDACIONES CONCLUSIONES 140 RECOMENDACIONES 142

BIBLIOGRAFÍA 143

ÍNDICE DE CUADROS

Pág. CUADRO 1 Causa y Consecuencia………………………………………………………. 5 CUADRO 2 Roles y responsabilidades…………………..…………………...………….. 23 CUADRO 3 Población……………..……………………………………………………….. 47 CUADRO 4 Muestra…………………………………………………………………..……. 48 CUADRO 5 Variable sexo…………………………………………………………..……… 53 CUADRO 6 Variable facultad…………………………………………………..………….. 54 CUADRO 7 Variable matriculación……………………………………………………..…. 54 CUADRO 8 Variable actual proceso de matriculación.……………………………..……. 54 CUADRO 9 Variable horario de clase.……………………………..………………………. 55 CUADRO 10 Variable sistema académio.……………………………..……………………. 55 CUADRO 11 Variable generación de horarios.……………………………..………………. 55 CUADRO 12 Variable nueva generación de horarios.……………………………..………. 56 CUADRO 13 Variable asignación inmediata de horarios……………………………..……. 56 CUADRO 14 Variable cambio horario de clases……………………………..……………... 56 CUADRO 15 Variable recursos aula.……………………………..………………………….. 57 CUADRO 16 Variable prioridad discapacitados.……………………………..……………… 57 CUADRO 17 Matriz Operacionalización…………...…………………………………………. 61

CUADRO 18 Cuadro estadístico edad..…………...…………………………………………. 63 CUADRO 19 Frecuencia edad.……………………………..……………………………….. 64 CUADRO 20 Cuadro estadístico sexo...…………...…………………………………………. 66 CUADRO 21 Frecuencia sexo.……………………………..……………………………….... 67 CUADRO 22 Cuadro estadístico facultad........................................................................... 68 CUADRO 23 Frecuencia facultad……………………………..…………………………….. 69 CUADRO 24 Cuadro estadístico nueva generación de horarios…..……………………… 70 CUADRO 25 Frecuencia nueva generación de horarios…………………………………… 71 CUADRO 26 Cuadro estadístico de semestre………………………………………………. 72 CUADRO 27 Frecuencia de semestre………..……………………………………………… 73 CUADRO 28 Cuadro estadístico de datos erróneos………………….…………………….. 75 CUADRO 29 Frecuencia de datos erróneos.……………………………..………………... 76 CUADRO 30 Cuadro estadístico de sistema de matriculación…………………………… 78 CUADRO 31 Frecuencia sistema de matriculación………………………………………… 79 CUADRO 32 Cuadro estadístico actual sistema de matriculación..………………………. 80 CUADRO 33 Frecuencia actual sistema de matriculación………………………………… 81 CUADRO 34 Cuadro estadístico informativo horario de clases..…………………………. 82 CUADRO 35 Frecuencia informativo horario de clases…………………………………… 83

CUADRO 36 Cuadro estadístico de nuevo sistema académico…..……………………… 84 CUADRO 37 Frecuencia nuevo sistema académico.……………………………………... 85 CUADRO 38 Cuadro estadístico de actual generación de horarios de clases.…………. 86 CUADRO 39 Frecuencia actual generación de horarios de clases……………………... 87 CUADRO 40 Cuadro estadístico de asignación inmediata de horarios de clases……… 88 CUADRO 41 Frecuencia asignación inmediata de horarios de clases………………….. 89 CUADRO 42 Cuadro estadístico de cambio de horario de clases….……………………. 90 CUADRO 43 Frecuencia cambio horario de clases……………………………………….. 91 CUADRO 44 Cuadro estadístico de asignación recursos aula…………………………… 92 CUADRO 45 Frecuencia asignación recursos aula..……………………………………… 93 CUADRO 46 Cuadro estadístico de prioridad discapacitados…….……………………… 94 CUADRO 47 Frecuencia prioridad discapacitados.………………………………………. 95 CUADRO 48 Tipos de pruebas………………………………………..…………………….. 98 CUADRO 49 Recursos requeridos……………...…………...………………………..……. 99 CUADRO 50 Pruebas finales……..……...…………...……………………...……………… 100 CUADRO 51 Pruebas de aceptación……...…………...…………………...………………. 111 CUADRO 52 Requerimientos hardware….…………...……………………...…………….. 113 CUADRO 53 Personas y roles……..……...…………...……………………...……………. 115

CUADRO 54 Riesgos de las pruebas…...…………...……………………...…………….. 116 CUADRO 55 Involucrados en la validación………...……………………...……………… 123 CUADRO 56 Casos de pruebas ejemplo…………...……………………...……………… 130 CUADRO 57 Casos de pruebas real…...…………...……………………...……………… 131 CUADRO 58 Descripción de las pruebas…………...……………………...……………… 132 CUADRO 59 Informe de las pruebas…...…………...……………………...……………… 133 CUADRO 60 Cronograma……..……...…………...……………………...………………… 136 CUADRO 61 Detalle de egresos del proyecto……...……………………...……………… 138

ÍNDICE DE GRÁFICOS

Pág. GRÁFICO 1 Arquitectura FrameZK………………..….…………………………………… 15 GRÁFICO 2 Interfaz gráfica Eclipse………….….………………………………………… 16 GRÁFICO 3 Arquitectura Hibernate……….…………………..…………………………… 17 GRÁFICO Entorno de trabajo SQL………..……………...……………………………… 18 GRÁFICO 5 Plan de ejecución de pruebas…..…………………………………………. .. 21 GRÁFICO 6 Construcción de pruebas…….……….………………………………………. 22 GRÁFICO 7 Retroalimentación de pruebas.…………….…………………………………. 24 GRÁFICO 8 Método en V…………………...…………….………………………………….. 27 GRÁFICO 9 Diseños casos de pruebas……..……………………………………………… 30 GRÁFICO 10 Método generación casos de prueba.……………………..…………………. 31 GRÁFICO 11 Histograma Edad………………………………………………………….……. 64 GRÁFICO 12 Histograma Sexo………………………………………………………………… 67 GRÁFICO 13 Histograma Facultad…………………………………………………………….. 69 GRÁFICO 14 Histograma Nueva generación Horarios………………………………………. 71 GRÁFICO 15 Histograma Semestre…………………………………………………………… 73 GRÁFICO 16 Caja de bigotes semestre……………….……………………………………… 74

GRÁFICO 17 Histograma datos erróneos……………..……………………………………. 76 GRÁFICO 18 Caja de bigotes datos erróneos………...……………………………………. 77 GRÁFICO 19 Histograma Proceso sistema de matriculación………….………………….. 79 GRÁFICO 20 Histograma actual proceso de matriculación….……………………………. 81 GRÁFICO 21 Histograma informativo horario de clases…..………………………………. 83 GRÁFICO 22 Histograma Nuevo sistema académico..……………………………………. 85 GRÁFICO 23 Histograma Actual generación Horarios de clases……..………………….. 87 GRÁFICO 24 Histograma Asignación inmediata de horarios de clases………………….. 89 GRÁFICO 25 Histograma Cambio horario de clases………………………………………. 91 GRÁFICO 26 Histograma Asignación recursos aula……………………………………….. 93 GRÁFICO 27 Histograma Prioridad discapacitados…….………………………………….. 95 GRÁFICO 28 Diagrama Causa y Efecto………………….…………………………………. 96 GRÁFICO 29 Metodología en V………………………..…………………………………….. 105 GRÁFICO 30 Panorama de pruebas………………...………………………………...……. 109 GRÁFICO 31 Diagrama plan de pruebas.……..……………………………………...……. 118 GRÁFICO 32 Errores encontrados……..……………………………………………………. 120 GRÁFICO 33 Errores encontrados……..………..………………………………………….. 121 GRÁFICO 34 Prototipo de sistema..…..…………………………………………………….. 122

GRÁFICO 35 Prototipo de sistema.………………………………………………………….. 122 GRÁFICO 36 Mapa de procesos Administración……………………..…………………….. 125 GRÁFICO 37 Mapa de procesos prototipo de sistema académico……………………….. 126

UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS

CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES ELABORACIÓN DE CASOS DE PRUEBAS DEL PROCESO DE HORARIOS



EN LA UNIVERSIDAD

DE GUAYAQUIL Resumen

La importancia de poder contar con una herramienta que soporte las tareas cotidianas de trabajo han provocado que se diseñe un prototipo que organice las actividades a realizar, la cual debe de ser validada y correctamente sistematizada para obtener un flujo mitigado de errores, se determina la necesidad de elaborar un documento de Casos de Pruebas, lo que garantizará el correcto funcionamiento del programa y que la información viaje libre de embotellamientos y se cumplan con los estándares y requisitos planteados por las personas interesadas. Se establece mediante este estudio que todos los planteamientos nos llevan a que este sistema es adaptable en su totalidad.

Autor: Fernando Vicente Gordon Yépez Tutor: Ing. Mary Cabanilla



ELABORACIÓN DE CASOS DE PRUEBAS DEL PROCESO DE CREACIÓN

HORARIOS DE CLASES Y RECURSOS DISPONIBLES PARA IMPLEMENTAR EL PROTOTIPO DE SISTEMA ACADÉMICO EN LA UNIVERSIDAD DE GUAYAQUIL

Autor/a: FERNANDO VICENTE GORDON YÉPEZ

Tutor/a: ING. MARY CABANILLA

RESUMEN La importancia de poder contar con una herramienta que soporte las tareas cotidianas de trabajo han provocado que se diseñe un prototipo que organice las actividades a realizar en el ámbito de los HORARIOS Y RECURSOS DISPONIBLES, las cuales deben ser validadas y correctamente sistematizadas para obtener un flujo mitigado de errores, se determina la necesidad de elaborar un anexo para los Casos de Pruebas, lo que garantizará si en el futuro nuestro proyecto de sistema es apto para el funcionamiento, que la información no esté expuesta a cuellos de botellas, se cumplan con los estándares, las normas que las leyes actuales establecen y los requerimientos planteados por las personas interesadas. Se establece mediante este estudio que todos los lineamientos nos llevan a que este sistema es adaptable en su totalidad. Todos los procesos son medibles y pueden ser acoplados a las necesidades inmediatas de la población universitaria, cuyas labores se verán reflejadas en tareas automáticas que reducen los tiempos para obtener un óptimo resultado final. Al mencionar los beneficios de nuestra estructura, no queremos dar a entender que desecharemos todos los procesos actuales, muchos de ellos serán adaptados y reestructurados a nuestro enfoque y otros serán eliminados siempre que se determine que entorpecen el flujo de la data, todo esto con el fin de obtener la certeza que en la creación y asignación de Horarios de clases será un trabajo administrativo automatizado dejando a un lado el tedio y el complejo manejo de varios utilitarios para la administración de los mismos, además se implementa la valiosa tarea de administrar los Recursos Disponibles de las Facultades para la correcta e igualitaria distribución, generando una herramientas de soporte para el aprendizaje de los estudiantes y la importante categorización de los espacios físicos para dar prioridad a las personas discapacitadas que estén matriculadas en las diferentes Carreras Universitarias.



ELABORACIÓN DE CASOS DE PRUEBAS DEL PROCESO DE CREACIÓN HORARIOS DE CLASES Y RECURSOS DISPONIBLES PARA IMPLEMENTAR EL PROTOTIPO DE SISTEMA ACADÉMICO EN LA UNIVERSIDAD DE GUAYAQUIL

ABSTRACT

The importance of counting with a tool that supports the daily tasks during work, have led to designing a prototype that organizes the needed activities taking into account the HOURS AND AVAILABLE RESOURCES. Those activities must be properly validated and systematized, in order to obtain a flow with a decreased number of errors. There is a need to elaborate an annex to the Test Cases, which will ensure that the proposed system is suitable to operate in the future, that the information does not lose fluidity and that it meets the standards and the rules established by the current laws and outlined requirements by interested persons. This study establishes that all guidelines show us that this system is adaptable in its entirety. All processes are measurable and adaptable to the immediate needs of the university population, whose work will reflect in automated tasks that reduces time to obtain an optimum final result. Mentioning the benefits of our structure, we do not want to imply that all current processes will have to be discarded. Many of them will be adjusted and restructured according to our approach meanwhile others will be deleted if it turns out that that they can obstruct the flow of the data. Everything mentioned has the goal to provide the certainty that the creation and allocation of class schedules will be an automated administrative work avoiding the tedium and the complex handling of various utilities for managing those. Besides that, it will implement the valuable task of managing the available resources of the Faculties for proper and equal distribution, generating support tools for student learning and the essential categorization of physical spaces to prioritize disabled people enrolled in the different University Degree Programs.

1

INTRODUCCIÓN

En esta tesis se hace presente la investigación que se ha realizado de todos los

factores pasados y actuales para el levantamiento de un Prototipo de Sistema

Académico para La Universidad de Guayaquil, dicho estudio nos demuestra

mediante su desarrollo que de una manera u otra el no poder contar con un

sistema adecuado se ha convertido en un problema en las actividades cotidianas

del personal administrativo de todas las Facultades presentes.

La Institución posee un flujo transaccional muy alto a diario, y uno de los retos de

esta investigación es poder determinar mediante los Casos de Pruebas

necesarios cual es la opción más válida a implementar y solucionar el manejo

correcto de la misma, ofrecer la comunicación adecuada y un sistema que

soporte todo tipo de transacción o requerimiento que se presente en todas las

oficinas administrativas y centros de cómputos de la Universidad.

Actualmente los Sistemas dan soporte transaccional pero no a la medida que se

espera, los estudiantes, personal docente y personal administrativo deben

realizar solicitudes para poder obtener respuesta en un limitante de tiempo, en

los cuales no siempre se respeta, ocasionando la pérdida de un esquema de

trabajo. Los procesos de mayor demanda no prestan un servicio automatizado y

se depende de la validación humana.

Esta investigación dirige a poder plantear y definir los correctos caminos a tomar

y como debe ser manejado el flujo transaccional mediante la estrategia de

pruebas, en un prototipo de sistema académico, que está apto para cumplir con

la demanda de toda la comunidad universitaria, se trata de acoplar procesos

actuales con los procesos nuevos y desechar todo lo que genere retraso o

estancamiento de las vías de comunicación.

2

Se determina que la comunicación entre cada uno de los sistemas actuales

presentes en todas las Facultades es vital, los lineamientos del prototipo del

sistema académico que se está presentando son escalables y de fácil

adaptabilidad, con esto se determina que sin importar los procesos

independientes o desconocidos que se lleven, pueden ser acogidos por nuestro

prototipo, ya que el análisis que se realizó fue en base a uno ya existente y el

exhaustivo estudio de las necesidades de cada persona involucrada en todas las

tareas de las Carreras universitarias. Las pruebas a realizar, de forma individual

o en conjunto de ninguna forma retrasará o entorpecerá las actividades de las

personas interesadas, se realizará retroalimentación entre los involucrados y se

les mostrará como el prototipo de sistema académico lleva el correcto manejo de

la información y cuán importante es poder disminuir el tiempo de transacción y

de respuesta de las tareas, lo que sin duda alguna garantizará la Calidad del

buen manejo del flujo de datos y una atención eficaz que cambiará

rotundamente la forma de ver a la prestigiosa Universidad de Guayaquil.

3

CAPÍTULO I

EL PROBLEMA

PLANTEAMIENTO DEL PROBLEMA

Ubicación del Problema en un Contexto

La Universidad de Guayaquil, en sus Facultades de Administración y Ciencias

Matemáticas y Físicas, no cuenta con un módulo correctamente estructurado e

integrado para el ingreso, verificación y mantenimiento de los Horarios de clases

y Recursos disponibles. En la actualidad, cada Facultad posee sistemas locales

y dependientes. Sus enfoques se han delimitado en resolver problemas propios,

causando en sí, una ruptura de la información vital entre todas la Carreras

Universitarias.

Los repositorios de pruebas no existen para el registrado de los errores que se

presentan cotidianamente en los sistemas actuales, en casos esporádicos o a

medida que se han suscitado los fallos fueron documentados, sin haberles dado

las correcciones adecuadas y el seguimiento correspondiente, así evitar las

concurrencias de los mismos, todo esto se origina por la falta de un plan de

pruebas que guíe al personal administrativo para la generación de reportes de

soluciones a largo plazo o el correcto manejo de procedimientos con soluciones

a corto plazo.

4

La generación de horarios se realiza manualmente, provocando que la

información sea ubicada en repositorios externos, ajenos a las Carreras

Universitarias, evidenciando que la información quede expuesta a manipulación

de personas no afines a la creación de dicho proceso. Además de no contar con

un herramienta oportuna para la presentación a las autoridades y el tiempo

óptimo para publicarlo a la comunidad estudiantil.

Situación Conflicto Nudos Críticos

El personal humano es el principal nudo crítico, debido que se depende de la

intercesión de las personas encargadas de estos procesos para la elaboración

de los mismos, se depende de tal forma que ellos son los que validan y verifican

que todo lo que se está realizando sea lo correcto, si se llegase a perder un

personal involucrado en los horarios, sea por un lapso de tiempo corto o

prolongado, no se podrá avanzar y generará retrasos y desubicará las

actividades que ya se han enmarcado en el cronograma establecido por las

autoridades universitarias.

El no contar con una base de datos que guarde los datos históricos de las

Carreras Universitarias, conlleva que no se pueda realizar una correcta

proyección de estudiantes y asimilarla a la realidad que se vive en las

Facultades, todo esto induce a que se dispongan de recursos menores o en

ciertos casos mayores a lo que realmente se necesita, sin poder albergar y

ofrecer lo necesario para el desempeño de las actividades académicas

estudiantiles y administrativas.

Implementar el prototipo para dar soluciones a todo lo mencionado anteriormente

y no poder contar con las aprobaciones necesarias para creación del repositorio

local, la no predisposición del personal administrativo, debido a sus actividades

diarias, para las inducciones de los nuevos procesos que se llevan y no contar

con el tiempo acorde para realizar las correctas pruebas, lo cual ayudará a

conocer el punto de vista real de las personas que realizan el trabajo

administrativo y de tal forma realizar un correcto y único análisis para mitigar los

errores encontrados ya sea en el diseño o desarrollo del prototipo.

5

Causas y Consecuencias del Problema

Cuadro N°1

Causas y Consecuencias

Causas Consecuencias

No existen definiciones en las

bases de datos locales para el

ingreso de la información

respectiva de cada Facultad.

No hay registro de la información en

una base centralizada, donde no se

han definido estándares para la misma

y no existe integración de la data.

No contar con un sistema

centralizado y automatizado.

El sistema actual está expuesto a

generación errores humanos en la

creación de horarios de clases y

aquello contempla retrasos para la

entrega de los mismos, provocando en

ciertos casos que haya cruces de

materias y espacios físicos por falta de

un validador.

Personal Administrativo

En ciertos casos las Facultades

poseen personal administrativo que

son renuentes a los cambio y no se

quieren adaptar a los procesos

automatizados, que mejoran el tiempo

de respuesta en sus actividades

cotidianas.

Ley Orgánica de Educación

Superior

Actualmente La LEOS ha sido

reestructurada y los sistemas se ven

sumergidos en cambios para soportar

los procesos actuales y denotan que

no son adaptables a nuevos

requerimientos y entorpece la

automatización de las actividades.

Elaborado por: Fernando Gordon Yépez

Fuente: Fernando Gordon Yépez

6

Delimitación del Problema

Campo: Universidad de Guayaquil, Facultad de Administración y Facultad de

Ciencias Matemáticas y Físicas.

Área: Coordinación académica.

Aspecto: Diseño de Casos de Pruebas.

Tema: Elaboración de Casos de Pruebas para el prototipo del sistema

académico de la Universidad de Guayaquil.

La pruebas van a estar enfocadas en base a los procesos que se han levantado

en La Facultad de Administración y La Facultad de Ciencias Matemáticas y

Físicas, La Universidad de Guayaquil, cuenta con muchas más Facultades pero

solo estas dos son las que han decidido participar dentro del proceso de

adaptación a un nuevo sistema.

Se estudiará el análisis y diseño, los procesos en cuanto al levantamiento de

información y se acoplarán las estructuras administrativas a un solo modelo de

pruebas, considerando que van a estar enmarcadas a las decisiones tomadas

por las autoridades de cada Carrera Universitaria.

Se desea tener un enfoque centralizado, lo cual priorice todos los procesos de

relevante importancia en un solo prototipo de sistema académico, lo que

garantizará el repositorio y la extracción uniforme de la información de las

Carreras involucradas.

Formulación del Problema

¿El plan de pruebas que poseen las Carreras Universitarias contempla el

correcto análisis de todos los procesos y requerimientos para garantizar que se

cubra todas las necesidades presentes en sus sistemas y en el prototipo de

sistema académico que se está estructurando?

7

Evaluación del Problema

Delimitado

El problema radica, no poder realizar pruebas en el actual sistema bajo los

lineamientos de un correcto plan, ya que no existe una integración de todos los

componentes del mismo y no se puede obtener los resultados que son

requeridos para un funcionamiento acorde a las actividades cotidianas de La

Universidad de Guayaquil.

Evidente

En el levantamiento de información se aprecia las inconsistencias que

actualmente tienen los procesos que se realizan de forma manual tales como la

creación de horarios, en comparación con las asignaciones de los mismos a las

actividades de los estudiantes en el sistema académico y de mayor

inconsistencia se ha evidenciado en la asignación de los recursos físicos.

Concreto

El personal administrativo, en sus actividades cotidianas posee cantidades de

documentos que no se pueden almacenar en lugares físicos determinados por la

gran población estudiantil que existe en las Carreras Universitarias, por lo que se

plantea un sistema automatizado que realice el registro general de toda la

información y releve de espacio las oficinas administrativas.

8

Relevante

La importancia de solventar todas las necesidades del actual sistema y poder

suplantar los procesos obsoletos por nuevos y actuales que ayuden al correcto

establecimiento de los procedimientos, certifica la necesidad de un prototipo de

sistema que automatice todas las actividades del personal administrativo,

docente y estudiantil de la Universidad de Guayaquil.

Original

El sistema actual fue diseñado para ser una herramienta de solvencia a los

procesos presentes, algunos son procesados de forma manual y otros

automáticos, generando en ciertos requerimientos inconsistencias en la

asignación de horarios y recursos.

Claro

No se cuenta con una base de pruebas, no se ha registrado todos los

inconvenientes del sistema actual, en el cual están presentes muchos errores

que no se han podido mitigar por falta de una estrategia de pruebas adecuada,

personal capacitados para la elaboración de las mismas y por falta de

documentación, provocando concurrencia de los mismos.

9

OBJETIVOS

OBJETIVO GENERAL

Elaborar un plan de pruebas que garantice el cumplimiento adecuado de la

ejecución de todos los procedimientos presentes en el prototipo de sistema

académico, de acuerdo a los procesos documentados en los Casos de Uso.

OBJETIVOS ESPECÍFICOS

1. Definir la estrategia a usar para determinar el plan de pruebas idóneo,

para validar el correcto funcionamiento del módulo con respecto a

HORARIOS Y RECURSOS DISPONIBLES, del prototipo del sistema

académico.

2. Definir los perfiles de usuarios y cada uno de los roles a cumplir en la

ejecución de las pruebas en el prototipo de sistema académico, velando

el cumplimiento de los procesos requeridos.

3. Diseño de los casos de pruebas, ejecución de las pruebas, considerando

los casos de uso correspondientes al módulo y documentar los resultados

obtenidos.

10

ALCANCES DEL PROBLEMA

Se trabajará enmarcado en el cronograma de actividades establecidas para las

pruebas de HORARIOS Y RECURSOS DISPONIBLES, por los tutores del

proyecto: prototipo del sistema académico.

Se recopilará la información necesaria por medio de la entrevista al personal

administrativo involucrado en el proceso de la generación y mantenimiento de

HORARIOS Y RECURSOS DISPONIBLES, para en base a sus experiencias,

pueda guiar hacia una mejor validación, en cuanto, a los servicios que prestará

el prototipo que se está desarrollando.

Se elaborarán los Casos de Pruebas guiados por el diseño implementando en

los Casos de Uso (Análisis y Diseño), toda la información debe ser recibida

depurada y correctamente validada para la definición de los informes finales.

Cuando se finalicen las pruebas, se podrá determinar que en el prototipo se ha

encontrado y corregido todos los errores presentes, además de contar con una

estructura sólida, con lineamientos aceptables enfocados a realizar las acciones

necesarias por todos los usuarios y establecer la correcta documentación de

todas las pruebas y planificación que fueron establecidas para nuestras pruebas

dentro de este proyecto.

11

JUSTIFICACIÓN E IMPORTANCIA

La autoridad de la Facultad de Ciencias Matemáticas y Físicas desea entregar

un prototipo particular e impulsa a los egresados de la Carrera de Ingeniería en

Sistemas que se realice todas las labores de pruebas del sistema académico, el

cual debe ser apto para el uso de las demás Carreras Universitarias, lo que

conlleva que se realice un trabajo veraz, relevante y satisfaga las necesidades

de las personas que diariamente van a interactuar con nuestro prototipo.

Las pruebas deben ser implementadas para analizar las principales causas de

fallas en el sistema que se va a desarrollar, reflejando resultados de alta

calidad, el contar con personal capacitado no garantiza que el diseño, la

programación y cada una de las estructuras presentes estén implementadas de

la forma correcta, siempre se debe contar con filtros y aprobaciones previas

antes obtener el resultado final.

El planteamiento y la planificación de cada actividad mencionada determina que

este proyecto beneficia a la Universidad de Guayaquil, en sus Facultades de

Administración y Ciencias Matemáticas y Físicas, al contar con un prototipo

escalable, operable, integrado, etc.… da cabida a que las demás Carreras

Universitarias se unan a este nuevo proyecto, listo para ser implementado en su

totalidad y adaptarse a todos los procesos que estén presente en las actividades

de cada personal administrativo.

La meta y el compromiso de realizar este proyecto es dejar en alto el nombre de

nuestra Carrera y demostrar no tan solo a las autoridades de La Universidad de

Guayaquil, sino al país entero que el profesional formado es las aulas

universitarias es capaz de generar productos competitivos, listos para competir

en el mercado nacional y contribuir al desarrollo de nuestra Universidad.

12

CAPÍTULO II

MARCO TEÓRICO

ANTECEDENTES DEL ESTUDIO

La Facultad de Administración y La Facultad de Ciencias Matemáticas y Físicas,

poseen sistemas totalmente separados entre sí y no conllevan relación sus

procesos, provocando que en cada una de sus actividades, haya retrasos en la

entrega de los horarios, la carga horaria de los docentes, no haya una debida

asignación de los recursos y no se pueda brindar el servicio adecuado a la

comunidad estudiantil, en la actualidad el enfoque que se le busca dar es, que

todos los requerimientos presentes deberían de ser canalizados y a su vez poder

reducir los tiempos de respuesta al gran flujo de transacciones presentes.

Una de las grandes problemáticas que poseen los sistemas de las Carreras

involucradas, es no poder aplicar los cambios que son regidos por la ley de

educación superior actual, los procesos automatizados que son llevados no

fueron parametrizados para poder albergar cambios que son exigidos por los

órganos de control y cumplir con los estándares de calidad que garantizan la

correcta operativa de la Universidad de Guayaquil.

Se cuenta con personal administrativo, siendo estos renuentes a los cambios y

entorpeciendo los futuros procesos automatizados a implementar, por seguir

llevando actividades manuales hasta la actualidad, dicho motivo ha llevado que

se retrase o hasta cierto punto se dejen a un lado los sistemas o prototipos de

sistemas académicos enfocados en la generación de Horarios de Clases y

13

Administración de Recursos Disponibles, para el mejoramiento del flujo y

almacenamiento de la información.

Riesgos presentes en este método de manejar la información relevante de la

Universidad y en cada Facultad, porque no hay un filtro de seguridad que

controle la entrada, salida y manipulación de la misma, por tal motivo la acción a

tomar es implementar necesariamente un sistema de control para personal

administrativo, docente y estudiantil.

FUNDAMENTACIÓN TEÓRICA

El objetivo de este fundamente es dejar en claro los conceptos técnicos que son

usados a lo largo de esta tesis, se plantea una explicación y la elaboración de

este documento, lo que nos permitirá administrar los términos a un enfoque más

generalizados a la sociedad que no posee el dominio, la práctica que se

desarrolla en la Ingeniería en Sistemas Computacionales y sobre todo establecer

las ideas que se van a usar para la elaboración de un documento robusto de

pruebas que garantizará la funcionalidad de nuestro prototipo de sistema

académico para la generación de HORARIOS Y RECURSOS DISPONIBLES.

SISTEMA ACADEMICO.- Según (Roger Pressman, 2012): “Es un conjunto de

módulos diseñados a la medida de los usuarios para solventar soluciones

técnicas o administrativas de un conglomerado de personas. El rol de un sistema

académico, ser un intermediario entre la información (históricos – presentes -

futuros) y los requerimientos, prestando soluciones agiles, acortando tiempos de

respuestas”, lo que provoca las tareas administrativas sean acopladas al ámbito

tecnológico y se cumplan normas y estándares solicitados por el Órgano

Interventor.

PROTOTIPO DE SISTEMA ACADÉMICO.- Según (Alain Abran, 2004) “Los

prototipos son una herramienta valiosa para clarificar requerimientos confusos.

14

Pueden actuar de manera similar a los escenarios, proveyendo el contexto de los

usuarios en el cual se puede entender mejor la información.”

Esto hace referencia que todo el enfoque que se está realizando en nuestro

prototipo es una herramienta válida con información depurada lista para ser

usada y a su vez implementada a nivel macro.

PRUEBAS UNITARIAS.- Según (Roger Pressman, 2012): “Estas pruebas son

enfocadas a ser manejados por bloques, se necesita verificar la funcionalidad de

una cantidad mínima de código desarrollado para módulos, se maneja de

aquella forma para poder encontrar errores en pequeños extractos y poder

agilizar las soluciones de errores, el diseño, la documentación y la integración de

cada uno de los módulos”.

PRUEBAS FUNCIONALES.- Según (Roger Pressman, 2012): “Estas pruebas se

basan en la ejecución completa de un módulo. Para generar un esquema

correcto de las pruebas se establece un orden o jerarquía para realizar un

análisis en línea de todas las funciones proporcionadas en las pantallas de

nuestro módulo HORARIOS Y RECURSOS DISPONIBLES. Se realiza una

retroalimentación con la finalidad de generar conocimientos y poder hacer

comparativos con las pruebas unitarias con la finalidad de no saltar procesos o

permitir que los esquemas queden fuera de los requerimientos planteados por

los usuarios”.

HARDWARE.- Según (Roger Pressman, 2012): “Es la parte tangible de la

computadora, consta de varios partes o accesorios los cuales se deben de

definir para nuestro proyecto, cuales son los que se necesitarán para obtener un

equipo operativo funcional y apto para recibir el/los software que se manejan

para el levantamiento del nuevo sistema académico”.

15

SOFTWARE DE SISTEMA.- Según (Roger Pressman, 2012): “Es una aplicación

lógica desarrollada para la interacción entre el usuario y el computador, la

principal funcionalidad del Software, la reducción de tiempos en las tareas

cotidianas, en nuestro proyecto va a ser de utilidad para la creación,

mantenimiento y visualización de los HORARIOS DE CLASES Y RECURSOS

DISPONIBLES que ayudarán a manejar la data en línea recta y poder controlar

la información ingresada sea real y veraz”.

FRAMEWORK ZK.- Según (Roger Pressman, 2012): “Es una aplicación que nos

permite el manejo y desarrollo de aplicaciones Web, perteneciente a la empresa

“JAVA”, es una herramienta basadas en componentes “AJAX”, nos va a permitir

poder desarrollar las pantallas necesarias que corresponde a HORARIOS Y

RECURSOS DISPONIBLES y establecer la correcta conexión con nuestra base

de datos para la extracción segura de la información que se va mostrar en cada

uno de los procesos ya definidos. Entre sus características tenemos que es de

fácil acceso para el diseño de las aplicaciones Web, posee seguridades que nos

van a proteger de software maliciosos, los esquemas son personalizados en

cuanto a el uso de eventos y clases que permite ser compatible con demás

plataformas”.

GRÁFICO N° 1

Arquitectura de FrameworkZK

Elaborado: Fernando Gordon Yépez

Fuente: http://books.zkoss.org/wiki/ZK_Essentials

16

ECLIPSE LUNA.- Según (Roger Pressman, 2012): “Es un software de código

abierto, a esto se refiere que es libre para ser adquirido por personas u

organizaciones para la elaboración de sus aplicativos. No está bajo los

lineamientos de una empresa comercial sino bajo la organización de personas

que no buscan un lucro sino fomentar el buen uso de la herramienta para la

creación de software de calidad y sean aptos para el uso según los enfoques

varios de la sociedad tales como: personal, empresarial, comercial, etc.”.

GRÁFICO N° 2

Interfaz gráfica eclipse


Fuente: http://block.vogella.com/Eclipse_Essentials

HIBERNATE.- Según (Roger Pressman, 2012): “Es una herramienta que permite

establecer la correcta conexión y manipulación con la base de datos “mapeo

17

objeto-relacional”, está programada en “JAVA”. Esta herramienta ha sido

seleccionada para nuestro proyecto para evitar el problema de relación entre los

modelos que pueden existir en las bases datos al momento de aplicar la

extracción de la data y la generación en conjunto de los recursos que son

consumidos por nuestro computador. Esta herramienta maneja sentencias ya

definidas en cuanto a la relación con la base de datos lo que permite que se

optimice los recursos y el tiempo en la programación del modelo de nuestro

repositorio”.

GRÁFICO N° 3

Arquitectura Hibernate


Fuente: http://www.onlinetechvision.com

APACHE JMETER.- Según (Roger Pressman, 2012): “Su función principal, el

ofrecer el correcto rendimiento en cuanto a la aplicación Web y demás recursos

18

presentes en nuestro proyecto. Está enfocado como un servidor local y es el que

va a verificar que las aplicaciones o los componentes Web presentes, estén

correctamente aplicadas en el entorno o ambiente en el que se desarrolla las

aplicaciones”.

TOMCAT.- Según (Roger Pressman, 2012): “Esta herramienta funciona

literalmente como un repositorio de librerías, es las que contiene las

especificaciones de conexión entre las demás plataformas mediantes sus

especificaciones permite la relación entre los demás entornos Web que estén

alojados en un mismo servidor”.

SQL SERVER.- Es una herramienta que se usa como repositorio de datos

(BASE DE DATOS), creado por la empresa “Microsoft”, la cual nos va a permitir

el almacenamiento de nuestra información mediante tablas, manteniendo un

orden específico, determinado, etc., dicha información será extraída mediante las

sentencias determinadas en nuestro SOWFTWARE para el sistema académico.

Según (Jérôme GABILLAUD, 2013): “SQL Server, la amplia plataforma de base

datos de Microsoft, ofrece un rendimiento fiable gracias a la integración de

tecnologías en memoria, una rápida obtención de información útil a partir de

cualquier tipo de dato”.

GRÁFICO N° 4

Entorno de trabajo SQL


Fuente: http://technet.microsoft.com

19

PLAN DE PRUEBAS

Es primordial poder documentar los requerimientos de pruebas en nuestra etapa

de desarrollo de los casos de pruebas.

Mediante los diversos tipos de pruebas podemos establecer el nivel de confianza

requerido para obtener la aceptación de todos los futuros involucrados en la

creación, generación y mantenimiento de los HORARIOS DE CLASES Y

RECURSOS DISPONIBLES.

Los requerimientos deben cumplir con las especificaciones planteadas de

manera satisfactoria, las funcionalidades y características debe ser previamente

establecida para generar un alto nivel de satisfacción entre los usuarios finales.

Se debe puntualizar las áreas funcionales que son de mayor importancia en

nuestro proceso de pruebas:

1. Debe cumplir la Especificación de requisitos de software. Las

características de una buena ERS son definidas por el estándar IEEE

830-1998. Una buena ERS debe ser:

“Completa. Todos los requerimientos deben estar reflejados en ella y

todas las referencias deben estar definidas.

Consistente. Debe ser coherente con los propios requerimientos y

también con otros documentos de especificación.

Inequívoca. La redacción debe ser clara de modo que no se pueda mal

interpretar.

Correcta. El software debe cumplir con los requisitos de la

especificación.

Trazable. Se refiere a la posibilidad de verificar la historia, ubicación o

aplicación de un ítem a través de su identificación almacenada y

documentada.

20

Priorizable. Los requisitos deben poder organizarse jerárquicamente

según su relevancia para el negocio y clasificándolos en esenciales,

condicionales y opcionales.

Modificable. Aunque todo requerimiento es modificable, se refiere a que

debe ser fácilmente modificable.

Verificable. Debe existir un método finito sin costo para poder probarlo.”

2. Manejo de la información y la data a establecer en una base de datos y

las transacciones que estarán presentes en el ERS.

3. Beneficios de cumplir con el ERS.

Existen varios tipos de requisitos establecidos por el estándar IEEE 830-1998,

como lo son:

1. “Requisitos de Usuarios: Necesidades que los usuarios expresan

verbalmente

2. Requisitos del Sistema: Son los componentes que el sistema debe

tener para realizar determinadas tareas.

3. Requisitos Funcionales: Servicios que el sistema debe proporcionar

4. Requisitos no funcionales: Restricciones que afectaran al sistema.”

Existen varios tipos de categorías establecidos por el estándar IEEE 830-1998,

como lo son:

1. “Éxito: El resultado de la prueba es conforme al resultado esperado.

21

2. Aceptable: El resultado de la prueba indica que el sistema difiere de la

especificación aceptada pero es aceptable, no son necesarios cambios

en la aplicación, pero requiriendo un cambio en la especificación

funcional.

3. Tolerable: El resultado de la prueba es incorrecto, la aplicación en

prueba trabaja y podría ser aceptada, pero la falla deberá ser rectificada

en el periodo de tiempo acordado.

4. Intolerable: El resultado de la prueba es incorrecto, y la falla debe ser

corregida antes de concluir la fase de prueba.

5. Error: El resultado de la prueba observado es correcto, pero el resultado

esperado de acuerdo a los scripts de prueba son incorrectos.”

GRÁFICO N° 5

Ejecución plan de pruebas

Elaborado: Ministerio de Comunicación, República de Colombia

Fuente: Ministerio de Comunicación, República de Colombia

Se debe determinar el e

determinar en nuestro p

1. Las pruebas se

recibidos.

2. La estrategia de

escenarios a to

requerida.

Elaborado: M

Fuente: Min

ENTORNO DE PRUEBAS

l entorno de pruebas en base al ciclo de vida qu

proyecto:

e realizarán principalmente en base a los cas

de pruebas ayudará a establecer los posibles

tomar en el proyecto para obtener la docu

GRÁFICO N° 6

Construcción de pruebas

Ministerio de Comunicación, República de Colom

inisterio de Comunicación, República de Colomb

22

que se va a

sos de uso

s caminos y

cumentación

mbia

mbia

23

ROLES Y RESPONSABILIDADES DE LAS PRUEBAS

CUADRO N° 2

Roles y Responsabilidades

Recurso disponible para las pruebas

Rol

Responsable

Acciones a realizar

Administrador

Sr. Administrador

• Preparar logística. • Establecer comunicación entre los

involucrados. • Recepción de casos de pruebas. • Estrategia de pruebas.

Elaborador

Sr. Elaborador

• Diseño de pruebas en base a la

estrategia. • Determinar los posibles escenarios

en las pruebas.

Ejecutor

Sr. Ejecutor

• Realiza las pruebas. • Documentación de resultados. • Levante de informe de errores.

Validador

Sr. Validador

• Administrar el manejo de los casos

de pruebas.

Definición de informes

Sr. Definidor

• Depurar los datos de prueba para

levantamiento de informe final.


Fuente: Fernando Gordon Yépez

24

IDENTIFICACIÓN DE LAS PRUEBAS

Las pruebas son procedimientos de control y verificación que se aplican a un

software para conocer si el manejo de la información está siendo estipulada o

enviada según los estándares que se han definido para el proyecto. La finalidad

es encontrar errores y evitar situaciones que perjudiquen al desempeño laboral

de La Universidad de Guayaquil específicamente de la Facultades de Ciencias

Administrativas y la Facultad de Ciencias Matemáticas y Físicas dentro del

proceso de la implementación de nuestro prototipo de sistema académico para el

mantenimiento de los Horarios de clases y recursos disponibles.

GRÁFICO N° 7

Retroalimentación de pruebas



25

Hay varios tipos de pruebas que se aplican para la validación de un software y

antes de determinar las que usarán para nuestro proyecto explicaremos algunas

de ellas:

PRUEBAS DE CAJA NEGRA.- En esta prueba no se analiza el desarrollo del

software, está basada en verificar que los requerimientos planteados estén

contemplados en su totalidad dentro del sistema, su forma de verificarlo en

mediante la funcionalidad de los procesos, paso a paso se determina el la

operatividad del mismo, (Beizer, 1995): “Pueden aplicarse, por tanto, cuando aun

no están implementado el código fuente de programa pero si se conoce lo que

se espera que haga. Existen varios enfoques complementarios, para realizar

este tipo de pruebas, se mencionan los más relevantes:

• Partición del sistema: Consiste en realizar una división del dominio de

entrada en particiones para las que se supone un mismo comportamiento

y utilizar cada una de ellas para seleccionar casos de pruebas.

• Pruebas sobre los estados de software: Se obtienen casos de pruebas

que ejerciten los diferentes estados en los que puede estar el software.

• Pruebas de flujo lógico: Con este enfoque, los casos de pruebas se

especifican como un conjunto de operaciones que deben realizarse

consecutivamente sobre el software bajo prueba.”

EL MÉTODO V.- Describe las actividades y los resultados que se producen

durante el desarrollo del software.

Proporciona una guía para la planificación y realización de proyectos. Los

siguientes objetivos están destinados a ser alcanzados durante la ejecución del

proyecto.

OBJETIVOS:

Minimización de los riesgos del proyecto

Mejora la transparencia del proyecto y control del proyecto, especificando los

enfoques estandarizados, describe los resultados correspondientes y funciones

26

de responsabilidad. Permite una detección temprana de las desviaciones y los

riesgos y mejora la gestión de procesos, reduciendo así los riesgos del proyecto.

Mejora y Garantía de Calidad

Como un modelo de proceso estándar, asegura que los resultados que se

proporcionan sean completos y contengan la calidad deseada. Los resultados

provisionales definidos se pueden comprobar en una fase temprana. La

uniformidad en el contenido del producto mejora la legibilidad, comprensibilidad y

verificabilidad.

Reducción de los gastos totales durante todo el proyecto y sistema de

Ciclo de Vida

El esfuerzo para el desarrollo, producción, operación y mantenimiento de un

sistema puede ser calculado, estimado y control de manera transparente

mediante la aplicación de un modelo de procesos estandarizados. Reduciendo la

dependencia en los proveedores y el esfuerzo para las siguientes actividades y

proyectos.

Mejora de la comunicación entre todos los inversionistas

La descripción estandarizada y uniforme de todos los elementos pertinentes y

términos es la base para la comprensión mutua entre todos los inversionistas. De

este modo, se reduce la pérdida por fricción entre el usuario, comprador,

proveedor y desarrollador.

27

CONOCER EL CICLO DE VIDA Y DESARROLLO DE UN SOFTWARE

MEDIANTE EL MÉTODO EN V.

GRÁFICO N° 8

Metodología en V

·

Elaborado: Roger Pressman, 2012

Fuente: Ingeniería de Software básica

El nivel 1, está orientado al “cliente”. El inicio del proyecto y el fin del proyecto

constituyen los dos extremos del ciclo. Se compone del análisis de requisitos y

especificaciones, se traduce en un documento de requisitos y especificaciones.

El nivel 2, se dedica a las características funcionales del sistema propuesto.

Puede considerarse el sistema como una caja negra, y caracterizarla únicamente

con aquellas funciones que son directa o indirectamente visibles por el usuario

final, se traduce en un documento de análisis funcional.

28

El nivel 3, define los componentes hardware y software del sistema final, a cuyo

conjunto se denomina arquitectura del sistema.

El nivel 4, es la fase de implementación, en la que se desarrollan los elementos

unitarios o módulos del programa.

PRUEBAS DEL SISTEMA.- Esta en una prueba que se realiza para generalizar

los procesos de un sistema, es la verificación total del software, (Zhu et al.,

1997): “Las pruebas unitarias constituyen la identificación de defectos y su

corrección conllevan la necesidad de reproducir las pruebas ya realizadas con el

objetivo de asegurar que no se han introducido nuevos errores en el

funcionamiento. A estas pruebas se las denomina pruebas de regresión”.

Después de determinar lo más representativos en estos procedimientos y sus

conceptos, indicaremos a continuación cuales son las pruebas que seguiremos

para el análisis de este prototipo:

PRUEBAS DE CONTENIDO.- Mediante este procedimiento se debe determinar

que el contenido del sistema sea relacionado y robusto en los términos de

referencias establecidos, la información que se presenta en el prototipo debe ser

clara y concisa para evitar confusiones y mal manejo de la aplicación.

PRUEBAS FUNCIONALES.- Esta prueba va enfocada a la verificación de cada

módulo presente en el prototipo este apto para su correcto funcionamiento, se

analiza que esté realizando cada una de las especificaciones establecidas en los

requerimientos, para que esta prueba tenga el éxito esperado es muy importante

aplicar la retroalimentación, porque será de allí que se determine si funcionó de

la forma esperada nuestro prototipo.

PRUEBAS UNITARIAS.- El objetivo de esta prueba es verificar el correcto

funcionamiento por separado de cada módulo presente en nuestro prototipo,

29

para poder realizar un integración total del mismo y garantizar el 100% que es

operable, (Tuya, Ramos, 2009): “Las pruebas unitarias constituyen el primer

paso para detectar errores de código, pues se centra en la menor unidad del

diseño del software: el módulo. El objetivo principal de estas pruebas es detectar

errores en cada uno de los módulos del software al ser ejecutados

independientemente del resto de componentes”.

Debido a que este prototipo, no se ha establecido que sea escalado para la

implementación general y uso del sistema académico, todas las pruebas que se

realizaron fueron de la siguiente manera:

ENTORNO LOCAL.- Las pruebas se realizaron en máquinas independientes, y

de restringido acceso a personas no involucradas en el proceso de la generación

de Horarios y Recursos Disponibles. Las pruebas eran realizadas en cada

liberación obtenida por la parte de desarrollo y se le aplicaba las 3 pruebas

mencionadas anteriormente. La base de datos para este proceso era de ámbito

local y se alimentaba de datos ingresados por las personas de nuestro módulo.

PRUEBAS CON USUARIOS.- Basada en la experiencias de los usuarios se

buscó conocer si los procesos que están implementados en el prototipo, cubren

o cumplen las expectativas esperadas a diferencia del sistema que actualmente

poseen para sus labores cotidianas. En estas pruebas estuvieron involucrados el

Coordinador y las autoridades de la Carrera de Ingeniería en Sistemas.

30

CASOS DE PRUEBAS

Es un conjunto de análisis a realizar a una determinada aplicación o software,

para validar que cumpla con las características y requisitos, estableciendo que

cada uno de los procedimientos es revisado y garantizan que cumplen con cada

una de las etapas involucradas en el diseño del mismo, obteniendo un producto

final en su total satisfactorio produciendo resultados en su totalidad correctos.

GRÁFICO N° 9

Diseño de casos de pruebas



Según (Zhu et al, 1997): “Un método de pruebas se puede clasificar según la

fuente de información que utiliza para generar casos de pruebas y según el

criterio de suficiencia que deben cumplir los casos generados. De esta manera la

clasificación de un método de prueba puede realizarse atendiendo a tres criterios

distintos:

31

• La fuente de información a partir de la cual son generados los casos de

pruebas.

• El criterio de suficiencia que deben cumplir los casos de pruebas

generados.

• La técnica utilizada (o conjunto de técnicas) para la generación de los

casos de pruebas”.

GRÁFICO N° 10

Método generación de casos de pruebas

Elaborado: Técnicas Cuantitativas para la gestión en la Ing. de Software

Fuente: Técnicas Cuantitativas para la gestión en la Ing. de Software

32

CLASIFICACIÓN SEGÚN FUENTE DE INFORMACIÓN

Según (Zhu et al, 1997): “Hay cuatro tipo de métodos:

• Métodos basados en especificaciones: Generan los casos de pruebas sin

conocer la implementación interna del software bajo prueba, razón por la

que también se denomina métodos de prueba de caja negra.

• Métodos basados en el código: Generan los casos de pruebas

conociendo la implementación interna del software bajo prueba, razón por

la que también se denomina métodos de caja blanca.

• Métodos basados en las especificaciones y el código: Son una mezcla

de los métodos de caja negra y caja blanca. También se denomina

métodos de prueba de caja gris.

• Métodos no basados ni en las especificaciones ni en el código: Generan

los casos de pruebas a partir de una información existente sobre otros

sistemas similares. Puede considerarse también métodos de prueba de

caja negra puesto que desconoce la estructura interna del software bajo

prueba.

Independiente del tipo de fuente utilizada, el objetivo de los métodos de prueba

es generar casos de pruebas que sean buenos. Este criterio se denomina criterio

de suficiencia”.

CRITERIO DE SUFICIENCIA

Según (Zhu et al, 1997): “Es un criterio que define lo que constituye un conjunto

de pruebas suficiente. Se clasifican en tres tipos para la generación de casos de

pruebas:

• Métodos estructurales: Los casos de pruebas generados deben cubrir un

conjunto de elementos de la estructura o de la especificación del

programa bajo prueba.

• Métodos basados en encontrar defectos: Miden la capacidad de

encontrar defectos que tiene el conjunto de casos de pruebas

generados.

33

• Métodos basados en encontrar errores: Están centrados en generar

casos de pruebas que comprueben el programa en ciertos puntos

específicos dónde existe una mayor probabilidad de haber errores”.

CRITERIOS ESTRUCTURALES

Según (Myres, 1979): “La prueba estructural especifica los requisitos de la

prueba en términos de cobertura de un determinado conjunto de elementos de la

estructura o de la especificación del programa bajo prueba”.

Según (Woodwart et al,. 1980): “Este criterio se lo puede clasificar en dos tipos:

• Basados en flujo de control: Son métodos que generan los casos de

pruebas basándose en el conocimiento de la estructura de control del

programa bajo prueba. Dicha estructura puede ser representada

mediante un grafo dirigido (o grafo de flujo).

• Basados en flujo de datos: Son métodos que generan los casos de

pruebas basándose en el conocimiento de las operaciones que se

realizan sobre las variables en el programa bajo prueba. La idea principal

es cubrir subcaminos del programa bajo prueba en el que aparezca una

determinada variable o variables. El grafo de flujo es utilizado para

guardar información de las variables en sus nodos y los criterios de

cobertura se refieren a la cobertura de elementos relacionados con una o

varias variables”.

34

FUNDAMENTACIÓN LEGAL

Para nuestro prototipo enmarcado en HORARIOS Y RECURSOS DISPONIBLES

encontramos varios procesos que deben de ser validados o regirse a las leyes

actuales para cumplir con las normas del Órgano Interventor y La Ley de

Educación Superior, mencionamos los siguientes:

Programas, proyectos, estrategias, políticas, proyectos de ley y reglamentos

para uso de software libres en la dependencia del gobierno central; y, En el

ejercicio de la atribución que le confiere en el numeral 9 del artículo 171 Decreta:

Artículo 1.- Establecer como política para las entidades de la administración

pública central la utilización de software libres en sus sistemas y equipamientos

informáticos.

Artículo 2.- Se entiende por software libre, a los programas de computación que

se pueden utilizar y distribuir sin restricción alguna, que permitan su acceso a los

códigos fuentes y que sus aplicaciones puedan ser mejoradas. Estos programas

de computación tienen las siguientes libertades: Utilización del programa con

cualquier propósito de uso común, Distribución de copias sin restricción alguna,

Estudio y modificación del programa (Requisito: Código Fuente disponible),

Publicación del programa mejorado (Requisitos: Código Fuente disponible).

Artículo 3.- Las entidades de la administración pública central previa a la

instalación del software libre para sus equipos, deberá verificar la existencia de

capacidad técnica que brinde soporte necesario para el uso del software.

Artículo 4.- Se faculta la utilización de software propietario (no libre) únicamente

cuando no exista una solución de software libre supla las necesidades

requeridas, o cuando esté en riesgo la seguridad nacional, o cuando el proyecto

informático se encuentre en un punto de no retorno. Para efecto de este decreto

se comprende cómo seguridad nacional. Las garantías para la supervisión de la

colectiva y defensa del patrimonio nacional. Para efecto de este decreto se

35

entiende por el punto de no retorno, cuando el sistema o proyecto informático se

encuentre en cualquier de estas condiciones:

a) Sistema en producción funcionando satisfactoriamente y que el

análisis de costo beneficio muestra que no es razonable ni conveniente

una migración a software libre.

b) Proyecto en estado de desarrollo y que un análisis de costo –beneficio

maestre que no se conveniente modificar el proyecto de usar software

libre. Periódicamente se evaluaran los sistemas informáticos propietario

con la finalidad de migrarlos a software libres.

Articulo 5.- Tanto para software libres como software propietario, siempre y

cuando se satisfagan los requerimientos, se debe referir las soluciones en este

orden:

a) Nacionales que permitan autonomía y soberanía tecnológica.

b) Regionales con componente nacional

c) Regionales con proveedores nacionales

d) Internacionales con componentes nacionales

e) Internacionales con proveedores nacionales

f) Internacionales

Artículo 6.- La Subsecretaria de informática como órgano regulador y ejecutor

de las políticas y proyectos informáticos en las entidades del Gobierno Central

deberá realizar control de seguimiento de este decreto. Para todas las

evaluaciones constantes en este decreto la Subsecretaria de Informática

establecerá los parámetros y metodologías obligatorias.

El estado garantiza, que la educación superior esté al alcance de todos los

ecuatorianos y menciona:

36

Art. 8.- Serán Fines de la Educación Superior.- La educación superior

tendrá los siguientes fines:

a) Aportar al desarrollo del pensamiento universal, al despliegue de la

producción científica y a la promoción de las transferencias e

innovaciones tecnológicas;

b) Fortalecer en las y los estudiantes un espíritu reflexivo orientado al

logro de la autonomía personal, en un marco de libertad de pensamiento

y de pluralismo ideológico;

c) Contribuir al conocimiento, preservación y enriquecimiento de los

saberes ancestrales y de la cultura nacional;

d) Formar académicos y profesionales responsables, con conciencia ética

y solidaria, capaces de contribuir al desarrollo de las instituciones de la

República, a la vigencia del orden democrático, y a estimular la

participación social;

e) Aportar con el cumplimiento de los objetivos del régimen de desarrollo

previsto en la Constitución y en el Plan Nacional de Desarrollo;

f) Fomentar y ejecutar programas de investigación de carácter científico,

tecnológico y pedagógico que coadyuven al mejoramiento y protección

del ambiente y promuevan el desarrollo sustentable nacional;

g) Constituir espacios para el fortalecimiento del Estado Constitucional,

soberano, independiente, unitario, intercultural, plurinacional y laico; y,

h) Contribuir en el desarrollo local y nacional de manera permanente, a

través del trabajo comunitario o extensión universitaria.

Art. 28.- Fuentes complementarias de ingresos y exoneraciones tributarias:

Las instituciones de educación superior públicas podrán crear fuentes

complementarias de ingresos para mejorar su capacidad académica, invertir en

la investigación, en el otorgamiento de becas y ayudas económicas, en formar

37

doctorados, en programas de posgrado, o inversión en infraestructura, en los

términos establecidos en esta Ley.

Las instituciones de educación superior públicas gozarán de los beneficios y

exoneraciones en materia tributaria y arancelaria, vigentes en la Ley para el

resto de instituciones públicas, siempre y cuando esos ingresos sean destinados

exclusivamente y de manera comprobada a los servicios antes referidos.

Los servicios de asesoría técnica, consultoría y otros que constituyan fuentes de

ingreso alternativo para las universidades y escuelas politécnicas, públicas o

particulares, podrán llevarse a cabo en la medida en que no se opongan a su

carácter institucional sin fines de lucro. El Consejo de Educación Superior

regulará por el cumplimento de esta obligación mediante las regulaciones

respectivas.

Art. 71.- Principio de igualdad de oportunidades:

El principio de igualdad de oportunidades consiste en garantizar a todos los

actores del Sistema de Educación Superior las mismas posibilidades en el

acceso, permanencia, movilidad y egreso del sistema, sin discriminación de

género, credo, orientación sexual, etnia, cultura, preferencia política, condición

socioeconómica o discapacidad.

Las instituciones que conforman el Sistema de Educación Superior propenderán

por los medios a su alcance que, se cumpla en favor de los migrantes el principio

de igualdad de oportunidades. Se promoverá dentro de las instituciones del

Sistema de Educación Superior el acceso para personas con discapacidad bajo

las condiciones de calidad, pertinencia y regulaciones contempladas en la

presente Ley y su Reglamento. El Consejo de Educación Superior, velará por el

cumplimiento de esta disposición.

Art. 117.- Tipología de instituciones de Educación Superior: Las instituciones

de Educación Superior de carácter universitario o politécnico se clasificarán de

acuerdo con el ámbito de las actividades académicas que realicen. Para

establecer esta clasificación se tomará en cuenta la distinción entre instituciones

38

de docencia con investigación, instituciones orientadas a la docencia e

instituciones dedicadas a la educación superior continua.

En función de la tipología se establecerán qué tipos de carreras o programas

podrán ofertar cada una de estas instituciones, sin perjuicio de que únicamente

las universidades de docencia con investigación podrán ofertar grados

académicos de PhD o su equivalente.

Esta tipología será tomada en cuenta en los procesos de evaluación,

acreditación y categorización.

La creación del cronograma de actividades académico, las validaciones están

dadas por el siguiente artículo:

“LEY Y REGLAMENTO DE MATRICULACIÓN”

“Artículo 12.- Período académico ordinario.- A efectos de facilitar la movilidad

académica en el Sistema de Educación Superior, las IES implementarán al

menos dos períodos académicos ordinarios al año, con un mínimo de 16

semanas efectivas para la realización de actividades

formativas en cada período. En el caso de las carreras de Medicina Humana y

de nivel tecnológico superior o sus equivalentes, el período académico ordinario

tendrá una duración mínima de 18 semanas efectivas. En todos los casos, la

fase de evaluación podrá ser planificada dentro o fuera de cada periodo

académico ordinario”.

“Artículo 13.- Período Académico Extraordinario." Las instituciones de

educación superior podrán implementar, adicionalmente, períodos académicos

extraordinarios en un número menor a 16 se manas durante el año académico,

de tal manera que las actividades formativas y de evaluación se concentren en el

correspondiente período”.

La disponibilidad de los Docentes para las asignaciones de su carga horaria de

las diferente Facultades:

39

Art. 149.- Tipos de profesores o profesoras y tiempo de dedicación.- Los

profesores o profesoras e investigadores o investigadoras serán: titulares,

invitados, ocasionales u honorarios. Los profesores titulares podrán ser

principales, agregados o auxiliares. El reglamento del sistema de carrera del

profesor e investigador regulará los requisitos y sus respectivos concursos. El

tiempo de dedicación podrá ser exclusiva o tiempo completo, es decir, con

cuarenta horas semanales: semiexclusiva o medio tiempo, es decir, con veinte

horas semanales: a tiempo parcial, con menos de veinte horas semanales.

Ningún profesor o funcionario administrativo con dedicación exclusiva o tiempo

completo podrá desempeñar simultáneamente dos o más cargos de tiempo

completo en el sistema educativo, en el sector público o en el sector privado. El

Reglamento de Carrera y Escalafón del Profesor e Investigador del Sistema de

Educación Superior. Normará esta clasificación, estableciendo las limitaciones

de los profesores

40

HIPÓTESIS PREGUNTAS A CONTESTARSE

HIPÓTESIS

¿Se está diseñando la estrategia adecuada para la verificación de la correcta

funcionalidad del módulo de Horarios y Recursos Disponibles del prototipo de

sistema académico?

VARIABLES DE LA INVESTIGACIÓN

1. ESTRATEGIA A ELABORAR PARA DISEÑAR LOS CASOS DE

PRUEBAS PARA EL PROTOTIPO DE SISTEMA ACADÉMICO (variable

independiente).

2. CASOS DE PRUEBAS PARA LA CERTIFICACIÓN DEL PROTOTIPO

DE SISTEMA ACADÉMICO (Variable dependiente).

41

DEFINICIONES CONCEPTUALES

HORARIO DE CLASE.- Referencia conceptuales al organizar una o varias

actividades en un marco referencial de horas establecidas, enfocada en las

actividades de los interesados son organizados en jornadas académicas.

RECURSOS DISPONIBLES.- Los recursos son los bienes materiales que

aportan a la sociedad un beneficio en ámbito personal, profesional o académica.

Dentro del marco universitario son los bienes o materiales que soportarán el

correcto aprendizaje de los estudiantes generando un valor y perspectiva en la

calidad estudiantil.

CARGA HORARIA DOCENTE.- Es el conjunto o bloque de horas ya

determinadas por un ente superior y de acorde a la disponibilidad del docente,

en el que determinan las actividades a realizar dentro de una jornada académica

en uno o varios sectores del área de desempeño.

FACTIBILIDAD.- Representa el beneficio organizacional al contar con los

recursos disponibles para lograr u obtener uno o varios objetivos específicos

para el funcionamiento óptimo de un fin en común sobre los proyectos presentes.

REQUERIMIENTO.- Una o varias necesidades expuestas por los involucrados

en una actividad específica, la cual debe presentarse correctamente

documentada, determinando las cualidades y atributos a obtener.

42

FLUJO TRANSACCIONAL.- Son los requerimientos presentes que viajan por

medio de la red. Se debe determinar un flujo de datos alto para que las

transacciones sean receptadas en un tiempo adecuado y genere un tiempo de

respuesta mínimo y no afecte el giro del negocio.

OPERATIVIDAD.- Es la capacidad de poder responder de forma positiva a todos

los requerimientos que se presentan en las actividades cotidianas en las oficinas

de trabajo, pretendiendo tener atención activa en todo momento y cumplir con la

productividad efectiva del giro del negocio.

TIEMPO DE RESPUESTA.- Es el tiempo de trasmisión de la red para el envío

correcto de un requisito transaccional, el tiempo se considera debe ser bajo para

determinar la buena calidad de la red presente en el giro del negocio.

CAPACITACIÓN.- Es una actividad consistente y cotidiana para la correcta

instrucción de personas interesadas dentro de una organización para adquirir

conocimiento y suplir necesidades en toda ámbito profesional.

LEY DE EDUCACION SUPERIOR.- Son normas establecidas por las

autoridades de un país para obtener un correcto funcionamiento, el mayor

beneficio y mejores estándares en la educación de los jóvenes de los diferentes

países, para formar profesionales de calidad y aptos para cumplir con las

exigencias laborales del mercado actual.

43

CAPÍTULO III

METODOLOGÍA

DISEÑO DE LA INVESTIGACIÓN

INTRODUCCIÓN

La Universidad de Guayaquil en su prestigiosa trayectoria educativa ha

implementado soluciones de software para obtener soporte de acorde a las

necesidades que se han presentado en su centro de cómputo y cada una de las

Facultades Universitarias, en la actualidad con las nuevas leyes que rigen el

sistema de educación superior se debe tener en cuenta los reglamentos

exigidos, los cuales ayudarán a certificar que la Universidad esta apta para

desempeñar su labor de instruir profesionales.

En el presente un grupo de estudiantes de la Carrera de Ingeniería en Sistemas

Computacionales están desarrollando un prototipo de Sistema Académico que

cumpla con todas las exigencias de la “LOES” y los requerimientos que se han

recibido por parte de las autoridades de las facultades involucradas. Por tal

motivo se necesita ratificar que todas las implementaciones que se han

realizados en el desarrollo abarquen sus necesidades en la mayoría para el

correcto funcionamiento de las tareas del personal administrativo y docente, sin

dejar a un lado la más importante opinión, la de los estudiantes universitarios.

44

El Sistema Académico a implementar tiene la gran finalidad y un enorme desafío

de poder atender la demanda de la población universitaria que al censo que se

realizó en Marzo de 2015, arrojó un total de 67,532 estudiantes legalizados en

todas las Carreras, pero para un mejor enfoque y control del mismo se ha decido

implementarlo en dos Facultades tales como: Administración y Matemáticas &

Físicas.

El análisis que se aplicará a lo largo de este capítulo estará enfocado en la

generación de HORARIOS y como se debe administrar correctamente los

RECURSOS de las Facultades involucradas, los procesos acoplados a nuestro

sistema no dejarán a un lado los procesos actuales que llevan cada personal

administrativo, docente y estudiantil, lo que se busca es determinar el nivel de

satisfacción o desacuerdo en nuevos aplicativos u otros que han sido adaptados

para un mejor funcionamiento de las tareas y flujo de la información.

DEFINICIONES BÁSICAS

ESPACIO MUESTRAL

Se lo representa con el símbolo Ω “Omega” y conceptualmente Feller, W.

(1980), indica que: “El espacio de probabilidad (o espacio muestral)

asociado a un experimento aleatorio, es el conjunto de los resultados

posibles del mismo, o cualquier conjunto que los contenga”.

VARIABLE ALEATORIA

De acuerdo a Box, G., Hunter, W. y Hunter, J. (1978) es: “un valor que

depende del resultado de un experimento aleatorio”.

45

1. VARIABLE ALEATORIA DISCRETA.- Según Feller, W.

(1980), se dice: “que una variable aleatoria es discreta si toma

un numero finito o a lo más numerable de valores”.

2. VARIABLE ALEATORIA CONTINUA.- Según Martha García

Ben (2006) es: “Una variable aleatoria continua es una

función X que asigna a cada resultado posible de un

experimento un número real. Si X puede asumir cualquier

valor en algún intervalo I (el intervalo puede ser acotado o

desacotado), se llama una variable aleatoria continua”.

POBLACIÓN INVESTIGADA.- Según Ana Franca Olivo (2006) es: “Se

denomina Población Investigada al conjunto de entes disponibles al

momento de efectuar la investigación”.

POBLACIÓN OBJETIVO.- Es un subconjunto de la población

investigada. Ana Franca Olivo (2006) “En el caso de que todos los entes

están disponibles, entonces la población objetivo es igual a la población

Investigada”.

MARCO MUESTRAL.- Abarca los elementos que son seleccionados

para determinar la muestra que son tomados de la población objetivo.

MUESTRA.- Es una parte minoritaria tomada de la población objetivo. Se

la representa con la letra n

46

MUESTRA ALEATORIA.- Es la muestra que se toma con la finalidad de

obtener variantes dentro de la población objetivo, no se determinan

muestras fijas.

MUESTREO.- Se obtiene de la población investigada, con la finalidad de

determinar la parte más representativa debe ser investigada para obtener

resultados acordes a lo buscado.

Tenemos dos tipos de muestreo:

1. Muestreo Probabilístico

2. Muestreo No Probabilísticos.

VARIABLES.- Son valores determinados por la población a ser

investigada, los cambios se dan por circunstancias del tiempo y espacio.

Tenemos dos tipos de Variables:

1. VARIABLES CUANTITATIVAS.- Son variables que se

pueden identificar mediante los campos numéricos.

2. VARIABLES CUALITATIVAS.- Son las que identifican

atributos.

47

POBLACIÓN Y MUESTRA

POBLACIÓN.-

La población escogida para el estudio estadístico a realizar, son los estudiantes

de las Facultades de Administración y Matemáticas y Físicas, involucradas en el

proceso de adaptación del prototipo del Sistema Académico.

CUADRO N° 3

Población de las facultades


Fuente: Propia

MUESTRA.-

Se toma la muestra de un grupo minoritarios de estudiantes, docentes y personal

administrativo de las Facultades involucradas.

El tamaño de la muestra se determina mediante la siguiente fórmula:

Se identifica las variables a usar en nuestro proyecto

POBLACIÓN DE ADMINISTRACIÓN Y

MATEMÁTICAS

N

MATEMÁTICAS 5188

ADMINISTRACIÓN 15054

TOTAL 20242

48

Y se determina sus valores respectivos para hallar el valor de n:

CUADRO N°4

Muestra

N= 20242

n= calcular

Z= 1.96

d= 0.05

p= 0.5

Q= 0.5


Fuente: Propia

El valor hallado de es n = 377, este valor representa el tamaño de la muestra.

49

INSTRUMENTO DE RECOLECCIÓN DE DATOS

Los métodos a aplicar para recolectar los datos y poder elaborar el análisis

estadístico, serán la encuesta y la entrevista, las cuales se las aplicarán al

personal administrativo y población estudiantil, se la realizará de manera

equiparada entre las dos facultades para obtener el criterio de ambos sectores

de la Universidad de Guayaquil.

Primero se mostrará el esquema de la encuesta con sus respectivas

codificaciones.

Segundo se mostrará el esquema de la entrevista.

Tercero toda la tabulación de los datos recolectados en las encuestas y las

entrevistas por parte del personal docente y estudiantes de La Universidad de

Guayaquil.

50

DISEÑO DE ENCUESTA


CC.MM.FF. – C.I.S.C.

ENCUESTA SOBRE “MIGRACIÓN DE DATOS DE LAS ANTIGUAS

ESTRUCTURAS DE D.B. DE CC.MM.FF. AL NUEVO A SER IMPLEMENTADO

POR EL S.A.”

1. ¿Cuál es su edad? ______

2. Sexo: Masculino Femenino

3. ¿A qué facultad pertenece?

Matemáticas Administración

4. ¿Qué semestre cursa? ______

5. El sistema de matriculación que usted realiza es:

Manual Automatizado

6. ¿Está usted de acuerdo con el actual proceso de matriculación?

Totalmente de acuerdo

Parcialmente de acuerdo

Ni de acuerdo ni en desacuerdo

Parcialmente en desacuerdo

Totalmente en desacuerdo

7. ¿En dónde existe información clara de los pasos a seguir para escoger sus

Horarios?

Solo en ventanilla

Solo en la web

Tanto en ventanilla como en la web

8. ¿Está usted de acuerdo con la creación de un nuevo sistema para la

generación de Horarios de Clases?

Si No

9. ¿Qué tan de acuerdo está con el actual sistema de generación de Horarios

que lleva su carrera?



51




10. ¿Cuántas veces recuerda haber tenido inconvenientes con datos erróneos

en la asignación de Horarios de clases?

_____

11. ¿Cómo se realiza la generación de nuevos Horarios de clases en su carrera?

Vía Web

Secretaría

Coordinación

Automáticamente

12. ¿Qué tan de acuerdo está con la posibilidad de que usted pueda escoger y

asignar sus Horarios de clase al momento de matricularse vía Web?

De acuerdo


En desacuerdo

13. ¿Cuándo el sistema le permite realizar cambios en sus Horarios de clase?

Solo al inicio de la Carrera

Una vez por semestre (matriculación)

En cualquier momento (vía web)

14. ¿Qué tan de acuerdo está que se aginen recursos (proyector, escritorios,

pupitres, etc.…) al aula de clase sin pasar primero por Coordinación?

De acuerdo


En desacuerdo

15. ¿Qué tan de acuerdo está que se categoricen las aulas para dar prioridad a

los discapacitados?






Encuesta N° 1 Elaborada por: Fernando Vicente Gordon Yépez

52

DESCRIPCIÓN DE VARIABLES VARIABLES CUANTITATIVAS

Edad.- Dentro del rango de 18 a 25 años nos va a identificar la

edad del estudiante entrevistado.

Semestre.- Nivel del estudiante el cual cursa dentro de su malla

curricular.

Cantidad errónea.- Las veces que se ha visto el entrevistado en

un problema con la generación de horarios de clases.

VARIABLES CUALITATIVAS

Sexo.- Masculino o Femenino.

Facultad.- Población determinada: Administración y Matemáticas.

Proceso del Sistema Matriculación.- Manual o Automático.

Sistema actual de Matriculación.- Herramienta de apoyo para el

Personal administrativo, docente y estudiantil en las actividades

cotidianas de las Facultades.

Informativo de Horarios.- Medir la satisfacción del estudiante al

obtener la información clara y adecuada de los Horarios de clases

previa a la matriculación.

Nuevo Sistema Académico.- Solución integrada para dar mejor

tiempo de respuestas a las actividades de las Facultades y

manejo de recursos, medir la aprobación de los involucrados.

53

Actual generación de Horarios.- Actual proceso manual que se

usa para la generación de los horarios de clases en cada

Carrera universitaria, saber si están de acuerdo con el proceso.

Nueva generación de Horarios.- Nuevo proceso automatizado

para la creación de los horarios de clases.

Asignación inmediata de Horarios.- Reflejar horarios de clases

escogidos en el nuevo proceso automatizado sin la necesidad de

entregar documentos en secretaría.

Visualización de Horarios vía Web.- Poder revisar los horarios

de clases en su usuario sin la necesidad de acercarse a secretaria

para asentar la matrícula.

Asignación de Recursos Aulas.- Poder contar con los recursos

necesarios en el aula sin la necesidad de realizar solicitudes en

coordinación para la aprobación de los mismos.

Prioridad Discapacitados.- Asignar las aulas de la planta baja a

los paralelos que tenga alumnos discapacitados para dar las

facilidades a sus estudios.

CODIFICACIÓN DE VARIABLES

VARIABLES CUALITATIVAS

CUADRO N°5

Variable Sexo

SEXO

DESCRIPCION VALOR

Masculino 1

Femenino 2 Elaborado por: Fernando Gordon Yépez

Fuente: Propia

54

CUADRO N°6

Variable Facultad

FACULTAD

DESCRIPCION VALOR

Matemáticas 1

Administración 2 Elaborado por: Fernando Gordon Yépez

Fuente: Propia

CUADRO N°7

Variable Matriculación

PROCESO SISTEMA MATRICULACIÓN

DESCRIPCION VALOR

Manual 1

Automatizado 2 Elaborado por: Fernando Gordon Yépez

Fuente: Propia

CUADRO N°8

Variable Actual Matriculación

SISTEMA ACTUAL MATRICULACIÓN

DESCRIPCION VALOR

Total acuerdo 5

Parcial acuerdo 4

Indiferente 3

Parcial desacuerdo 2

Total desacuerdo 1 Elaborado por: Fernando Gordon Yépez

Fuente: Propia

55

CUADRO N°9

Variable Horarios de clase

INFORMATIVO HORARIOS DE CLASE

DESCRIPCION VALOR

Solo ventanilla 3

Solo web 2

Ambas 1 Elaborado por: Fernando Gordon Yépez

Fuente: Propia

CUADRO N°10

Variable Sistema académico

NUEVO SISTEMA ACADÉMICO

DESCRIPCION VALOR

Si 2

No 1 Elaborado por: Fernando Gordon Yépez

Fuente: Propia

CUADRO N°11

Variable Generación de horarios

ACTUAL GENERACIÓN DE HORARIOS

DESCRIPCION VALOR

Total acuerdo 5

Parcial acuerdo 4

Indiferente 3



Fuente: Propia

56

CUADRO N°12

Variable Nueva generación de horarios

NUEVA GENERACIÓN DE HORARIOS

DESCRIPCION VALOR

Vía Web 4

Secretaría 3

Coordinación 2

Automáticamente 1 Elaborado por: Fernando Gordon Yépez

Fuente: Propia

CUADRO N°13

Variable Asignación inmediata de horarios

ASIGNACIÓN INMEDIATA HORARIOS

DESCRIPCION VALOR

De acuerdo 3

Ni de acuerdo ni en desacuerdo 2

En desacuerdo 1 Elaborado por: Fernando Gordon Yépez

Fuente: Propia

CUADRO N°14

Variable Cambios horarios de clase

CAMBIOS HORARIOS DE CLASE

DESCRIPCION VALOR

De acuerdo 3



Fuente: Propia

57

CUADRO N°15

Variable Recursos aula

ASIGNACIÓN RECURSOS AULA

DESCRIPCION VALOR

De acuerdo 3



Fuente: Propia

CUADRO N°16

Variable Prioridad discapacitados

PRIORIDAD DISCAPACITADOS

DESCRIPCION VALOR

Total acuerdo 5

Parcial acuerdo 4

Indiferente 3



Fuente: Propia

ENTREVISTA

Se formula un pequeño cuestionario de 5 preguntas para poder conocer como

son llevados los procesos y las personas involucradas en los mismos. Se debe

determinar, el nivel de satisfacción de cada personal administrativo con el actual

sistema, ya que las experiencias y el diario vivir de ellos es primordial para poder

adaptar los requerimientos a los nuevos procesos y considerar establecer

interfaces gráficas que no alejen a los usuarios de nuestro sistema

automatizado.

58


FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS

CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES

1. Indique su nombre y a ¿qué Facultad pertenece?

2. ¿Cuál es su responsabilidad dentro del proceso de generación de

Horarios y Recursos Disponibles?

3. El proceso actual, ¿Cuántos pasos involucran la creación de los Horarios

de clases?

4. ¿El cronograma es creado localmente?, si es NO la respuesta indique el

proceso a seguir.

5. ¿Cuán capacitado está el personal para el manejo de nuevas

herramientas administrativas?

59

PROPUESTA DE LA ENTREVISTA

1.- ¿Considera que es necesario crear un plan de pruebas para la verificación de

la correcta creación de los horarios de clases?

2.- ¿Considera que es necesario crear un plan de pruebas para la correcta

asignación de los recursos disponibles de las Facultades involucradas?

3.- ¿Considera que es importante que el prototipo de sistema académico que se

quiere implementar este conectado directamente con Vicerrectorado General

para que los cronogramas tengan un estándar único entre todas las Facultades

involucradas?

4.- ¿Cuán importante sería implementar un plan de pruebas para que los

cronogramas generales sean las base para las Facultades armen sus

cronogramas internos de actividades?

60

OPERACIONALIZACIÓN DE VARIABLES

Se describe las variables presentes en la entrevista:

1. Nombre.- Identificador de la/las personas involucradas, puede ser de

sexo masculino y femenino.

2. Facultad.- Pertenece a Administración o Matemáticas.

3. Procesos involucrados actualmente.- Son todos los pasos que deben

de seguir la creación de los Horarios y las herramientas que se usan para

la generación y almacenamiento de los mismo

4. Cronograma.- Se debe conocer y determinar donde se crea el

cronograma, si es de ámbito local o universitaria, lo cual sería de suma

importancia determinar para conocer si los procesos de matriculación y

todo el esquema de estudio está estimado para mantener actividades

realizadas en paralelo con todas las Carreras.

5. Capacitaciones.- Se debe determinar cuál es el personal idóneo para

poder conocer de los procesos actuales del prototipo y quiénes serán los

encargados de replicar la información recibida a las demás personas

pertenecientes en los departamentos administrativos.

61

CUADRO N° 17

Matriz de Operacionalización de variables

Variables Dimensiones Indicadores Técnicas y/o

Instrumentos

Variable

Independiente:

El prototipo del

sistema

académico

Área

administrativa de

las Facultades de

Matemáticas y

Administración

En un 99% el

personal

administrativo

está de acuerdo

que las opciones

de manejo del

sistema actual

posee procesos

obsoletos y que

no guardan

relación entre si y

muchos procesos

fuera de las

Facultades

Se aplican Casos

de Usos

elaborados y se

refleja un proceso

futuro al personal

administrativo de

lo nuevo que

posee el prototipo

del sistema.

Área de

Coordinación

académica

Registro de todas

las actividades

presentes en las

Facultades.

Esquemas y

Horarios

históricos para la

guía de correcta

creación.

Variable

Dependiente:

Las Facultades,

los cronogramas

y las

capacitaciones

Interfaz gráfica de

las pantallas

futuras

Herramientas de

código abierto

Proporcionada

por los

encargados de la

Carrera de

Ingeniería en

Sistemas

62

Capacidad de

interpretar la

información sin

conocer el

proceso previo

Interpretación de

las acciones a

realizar para las

tareas

administrativas

Se contará con un

manual de

pruebas para que

se conozcan los

casos que

sucedieron

durante el

análisis.


Fuente: Ab. Mariana Roldós

PREVIO ANÁLISIS AL PLAN DE PRUEBAS

Conociendo la opinión del personal administrativo y población estudiantil de las

dos Facultades y la representación de sus respectivas variables, determinamos

que mediante el análisis es primordial poder contar con la aprobación y

satisfacción de los involucrados que también van a interactuar con el prototipo de

sistema académico.

Como todo estudio que se vaya a implementar se debe tabular las encuestas

que se han realizado para conocer hacia qué tipo de estudiantes se quiere

alcanzar, la factibilidad y el nivel de aprobación del mismo, este proceso será

acoplado a la muestra que se obtuvo del total de estudiantes de las dos

Facultades.

63

ANÁLISIS ESTADÍSITICO

EDAD

Obtenido los resultados podemos concluir que la edad promedio de entre un

grupo de estudiantes encuestados (18-26 años) es de 21 años de edad, y la

mayoría es de 24 años de edad (moda).

Revisando el histograma se observa que la diferencia entre la media y la

mediana (21,54 – 22,00) es significativa por los cual no se guarda simetría

porque el aglomerado de los datos están en el centro de la gráfica.

CUADRO N° 18

Estadísticos

Edad

N Válido 377

Perdidos 0

Media 21,54

Mediana 22,00

Moda 24

Desviación estándar 2,243

Varianza 5,031

Asimetría -,044

Curtosis -1,239

Mínimo 18

Máximo 25

Cuartiles 25% 20,00

50% 22,00

75% 24,00


Fuente: Propia

64

CUADRO N° 19

Frecuencia Edad

Frecuencia Porcentaje

Porcentaje

válido

Porcentaje

acumulado

Válido

18 41 9,5 10,9 10,9

19 50 11,5 13,3 24,1

20 49 11,3 13,0 37,1

21 41 12,4 10,9 48,0

22 53 12,2 14,1 62,1

23 46 13,6 12,2 74,3

24 58 16,4 15,4 89,7

25 39 12,0 10,3 100,0

Total

377 100,0 100,0


Fuente: Propia

GRÁFICO N° 11 Histograma de edad

Elaborado por: Fernando Gordon Yépez Fuente: Propia

65

Para analizar el cuadro de Cajas y bigotes se debe tomar como referencia sus

cuartiles:

• 20

• 22

• 24

Mediante estos valores se determina que la parte izquierda de la caja es igual a

la parte derecha, no están dispersos los datos e interpretamos que hay igualdad

entre el <25% - 50%> y el <50% - 75%>.

Analizando los bigotes se obtiene que el bigote izquierdo es más largo que el

bigote derecho lo cual determina que la población está concentrada en su

mayoría entre el 75% de los estudiantes en un promedio de edad de 22 años.

66

SEXO

En una población grande como la que se usa es importante determinar el sexo

de las personas entrevistadas e identificar a las personas involucradas, se

estipula que la media es de 1,51 lo cual determina que por un pequeño rango los

hombres han sido más encuestados que las mujeres, de tal forma lo corrobora la

moda con su valor de 2 (hombres)

Revisando el histograma ratifica el análisis presente y refleja en las barras que

los hombres en su mayoría forman la población de encuestados.

CUADRO N° 20

Estadísticos Sexo

Sexo

N Válido 377

Perdidos 0

Media 1,51

Mediana 2,00

Moda 2

Desviación estándar ,501

Varianza ,251

Asimetría -,048

Curtosis -2,008

Mínimo 1

Máximo 2

Cuartiles 25% 1,00

50% 2,00

75% 2,00


Fuente: Propia

67

GRÁFICO N° 12 Histograma Sexo


CUADRO N° 21

Frecuencia Sexo


Porcentaje

válido

Porcentaje

acumulado

Válido 1 184 49,4 48,8 48,8

2 193 50,6 51,2 100,0

Total 377 100,0 100,0


68

FACULTAD

Del gran conglomerado de estudiantes que ya han sido identificados y

clasificados podemos observar que en promedio (1,50) los estudiantes de

Administración dieron su criterio y nivel de satisfacción en la encuesta realizada,

lo corrobora la moda con su valor de 2 (Administración).

Revisando el histograma se ratifica el análisis presente y refleja en las barras

que Administración por un solo estudiante forma parte de la mayoría de

encuestados.

CUADRO N°22

Estadísticos Facultad

Facultad

N Válido 377

Perdidos 0

Media 1,50

Mediana 1,00

Moda 1


Varianza ,251

Asimetría ,005

Curtosis -2,011

Mínimo 1

Máximo 2

Cuartiles 25% 1,00

50% 1,00

75% 2,00


69

CUADRO N°23

Frecuencia Facultad


Porcentaje

válido

Porcentaje

acumulado

Válido 1 189 50,5 50,1 50,1

2 188 49,5 49,9 100,0

Total 377 100,0 100,0


GRÁFICO N°13 Histograma de facultad


70

NUEVA GENERACIÓN DE HORARIOS DE CLASE

Para poder establecer una nueva vía para la creación de horarios se necesita

saber en dónde se origina el actual proceso de generación de Horarios y se

puede visualizar que en la Media (2,34) indica que en general todos los

estudiantes concuerdan que se los realiza en Coordinación, de igual manera lo

ratifica la Moda (2).

Todo esto es corroborado por el diagrama de barras.

CUADRO N° 24

Estadísticos Nueva generación de

horarios

N Válido 377

Perdidos 0

Media 2,34

Mediana 2,00

Moda 2


Varianza ,963

Asimetría ,386

Curtosis -,841

Mínimo 1

Máximo 4

Cuartiles 25% 2,00

50% 2,00

75% 3,00


Fuente: Propia

71

CUADRO N° 25

Frecuencia Nueva Generación Horarios


Porcentaje

válido

Porcentaje

acumulado

Válido 1 74 17,1 19,6 19,6

2 167 38,5 44,3 63,9

3 71 16,4 18,8 82,8

4 65 15,0 17,2 100,0

Total 377 100,0 100,0


Fuente: Propia

GRÁFICO N° 14 Histograma nueva generación de horarios


72

SEMESTRE

Los semestres involucrados en la encuesta están entre el 1er. y 8va., lo que

determina que la media de los estudiantes encuestados se encuentra en 4to.


mediana (4,44 – 4,00) es significativa por los cual no se guarda simetría porque

el aglomerado de los datos están en el centro de la gráfica.

CUADRO N° 26

Estadísticos semestre

N Válido 377

Perdidos 0

Media 4,44

Mediana 4,00

Moda 5


Varianza 5,742

Asimetría ,038

Curtosis -1,328

Mínimo 1

Máximo 8

Cuartiles 25% 2,00

50% 4,00

75% 7,00


Fuente: Propia

73

CUADRO N° 27

Frecuencia Semestre


Porcentaje

válido

Porcentaje

acumulado

Válido 1 56 12,9 14,9 14,9

2 52 12,0 13,8 28,6

3 40 9,2 10,6 39,3

4 44 10,1 11,7 50,9

5 47 10,8 12,5 63,4

6 36 8,3 9,5 72,9

7 49 11,3 13,0 85,9

8 53 12,2 14,1 100,0

Total 377 100,0 100,0


Fuente: Propia

GRÁFICO N°15 Histograma de semestre


Fuente: Propia

74


cuartiles:

• 2

• 4

• 7

Mediante estos valores se determina que la parte izquierda de la caja es menor a

la parte derecha, donde los semestres dentro de ese rango están en su mayoría

dispersos entre el 50% y el 75%.

Analizando los bigotes se obtuvo que el bigote izquierdo es más pequeño que el


mayoría en los primeros semestres que en los últimos.

GRÁFICO N°16 Caja de bigotes semestre


Fuente: Propia

75

DATOS ERRONES EN LA ASIGNACIÓN DE HORARIOS

Con la final de obtener los días en general que un estudiante logra resolver

alguna mala asignación de sus horarios, se determina que la media en días para

dar solución a aquello es de 2,97 días (3 días), y para el mayor tiempo de espera

refleja 4 días.


mediana (2,97 – 3,00) es significativa por los cual no se guarda simetría porque

el aglomerado de los datos están en el centro de la gráfica.

CUADRO N° 28

Estadísticos datos erróneos

N Válido 377

Perdidos 0

Media 2,97

Mediana 3,00

Moda ´4


Varianza 2,135

Asimetría -,011

Mínimo 1

Cuartiles 25% 2,00

50% 3,00

75% 4,00


Fuente: Propia

76

CUADRO N° 29

Frecuencia datos erróneos


Porcentaje

válido

Porcentaje

acumulado

Válido 1 88 20,3 23,3 23,3

2 67 15,4 17,8 41,1

3 66 15,2 17,5 58,6

4 80 18,4 21,2 79,8

5 76 17,5 20,2 100,0

Total 377 100,0 100,0


Fuente: Propia

GRÁFICO N°17

Histograma de datos erróneos


Fuente: Propia

77


cuartiles:

• 2

• 3

• 4

Mediante estos valores se determina que la parte izquierda de la caja es igual a

la parte derecha, no están dispersos los datos e interpreta que hay igualdad

entre el <25% - 50%> y el <50% - 75%>.

Analizando los bigotes se obtuvo que el bigote izquierdo es más corto que el


mayoría entre el 25% de los día en solucionar un problema con los Horarios.

GRÁFICO N°18 Caja de bigotes datos erróneos


Fuente: Propia

78

ACTUAL PROCESO DE MATRICULACIÓN

El primer proceso para obtener una información veraz es saber sobre que

plataforma se está trabajando en la Universidad de Guayaquil, se determina que

los estudiantes en su actual proceso de matriculación lo realizan de forma

manual y es un gran paso para de aquí en adelante poder medir la satisfacción

de los estudiantes en cada uno de sus procesos. Se determina que la Media

(1,48) para el uso del sistema es entre manual y automatizado no es general

sino ciertos procesos y la Moda (1) confirma que la forma de matricularse es

manual.

Revisando el histograma corroboramos el análisis presente y refleja en las

barras que en su mayoría los procesos se realizan manualmente.

CUADRO N° 30

Estadísticos procesos de

matriculación

N Válido 377

Perdidos 0

Media 1,48

Mediana 1,00

Moda 1


Varianza ,250

Asimetría ,080

Curtosis -2,004

Mínimo 1

Máximo 2

Cuartiles 25% 1,00

50% 1,00

75% 2,00


Fuente: Propia

79

CUADRO N° 31

Frecuencia procesos de

matriculación


Porcentaje

válido

Porcentaje

acumulado

Válido 1 196 55,3 52,0 52,0

2 181 44,7 48,0 100,0

Total 377 100,0 100,0


Fuente: Propia

GRÁFICO N°19

Histograma de proceso de sistema matriculación


Fuente: Propia

80

ACTUAL SISTEMA DE MATRICULACIÓN

El nivel de satisfacción de los estudiantes de las carreras involucradas se refleja

mediante la Media (2,98) lo cual indica que les es indiferente la forma que se

lleva el proceso actual de matriculación, ratificado por el valor de la Moda (3).

Revisando el histograma ratifica el análisis y refleja en las barras que en su

mayoría los procesos se realizan manualmente (valor 3).

CUADRO N° 32 Estadísticos actual sistema de

matriculación

N Válido 377

Perdidos 0

Media 2,98

Mediana 3,00

Moda 3


Varianza 1,832

Asimetría ,001

Curtosis -1,186

Mínimo 1

Máximo 5

Cuartiles 25% 2,00

50% 3,00

75% 4,00


Fuente: Propia

81

CUADRO N° 33 Frecuencia actual sistema de

matriculación


Porcentaje

válido

Porcentaje

acumulado

Válido 1 69 17,9 18,3 18,3

2 77 17,7 20,4 38,7

3 87 20,0 23,1 61,8

4 80 20,4 21,2 83,0

5 64 16,7 17,0 100,0

Total 377 100,0 100,0


Fuente: Propia

GRÁFICO N°20

Histograma de actual sistema de matriculación


Fuente: Propia

82

INFORMATIVO DE LOS HORARIOS DE CLASES

Sobre el análisis de donde los estudiantes pueden obtener la información

necesaria y correcta para obtener sus horarios, se determina que hay una Media

(1,99) donde determina que se encuentran vía Web, pero en su mayoría los

estudiantes por medio del análisis de la Moda (1) determina que con seguridad

los obtienen en secretaría.

Revisando el histograma se ratifica el análisis y refleja en las barras que en

secretaría los estudiantes pueden obtener un horario de clases con la

información correcta y segura.

CUADRO N° 34 Estadísticos informativo horarios

de clases

N Válido 377

Perdidos 0

Media 1,99

Mediana 2,00

Moda 1


Varianza ,689

Asimetría ,015

Curtosis -1,549

Mínimo 1

Máximo 3

Cuartiles 25% 1,00

50% 2,00

75% 3,00


Fuente: Propia

83

CUADRO N° 35 Frecuencia informativo horarios de

clases


Porcentaje

válido

Porcentaje

acumulado

Válido 1 131 33,2 34,7 34,7

2 118 29,2 31,3 66,0

3 128 31,5 34,0 100,0

Total 377 100,0 100,0


Fuente: Propia

GRÁFICO N°20

Histograma de informativo de horarios de clases


Fuente: Propia

84

NUEVO SISTEMA ACADÉMICO

Es muy importante contar con un nuevo sistema académico y el alumnado se

manifiesta mediante las encuestas, da a conocer cuán importante es contar con

un proceso nuevo y se sienten satisfechos con la posibilidad de contar con

aquello, la Media (1,65) determina en su mayoría los estudiantes requieren de

nuevos métodos para realizar sus Horarios de clases, se puede observar en la

Moda (2) donde indica que los estudiantes escogieron la opción más necesaria

para ellos.

Revisando el histograma ratificamos el análisis.

CUADRO N° 36 Estadísticos nuevo sistema

académico

N Válido 377

Perdidos 0

Media 1,65

Mediana 2,00

Moda 2


Varianza ,227

Asimetría -,643

Curtosis -1,595

Mínimo 1

Máximo 2

Cuartiles 25% 1,00

50% 2,00

75% 2,00


Fuente: Propia

85

CUADRO N° 37 Frecuencia Nuevo Sistema Académico


Porcentaje

válido

Porcentaje

acumulado

Válido 1 131 33,8 34,7 34,7

2 246 64,2 65,3 100,0

Total 377 100,0 100,0


Fuente: Propia

GRÁFICO N°22

Histograma de nuevo sistema académico


Fuente: Propia

86

ACTUAL GENERACIÓN DE HORARIOS DE CLASES

A un grupo de los encuestados les es indiferente la actual generación de los

Horarios de clases y se puede observar mediante la Media (3.07), pero mientras

no se cuente con un sistema nuevo y no se garantice el correcto funcionamiento

del mismo los estudiantes reflejan que están de acuerdo con la generación

actual de los Horarios de Clases, Moda (5).

Revisando el Histograma ratifica el análisis planteado.

CUADRO N° 38 Estadísticos actual generación de horario de clases

N Válido 377

Perdidos 0

Media 3,07

Mediana 3,00

Moda 5


Varianza 1,998

Asimetría -,061

Curtosis -1,298

Mínimo 1

Máximo 5

Cuartiles 25% 2,00

50% 3,00

75% 4,00


Fuente: Propia

87

CUADRO N° 39 Frecuencia actual generación de horario de clases


Porcentaje

válido

Porcentaje

acumulado

Válido 1 70 16,1 18,6 18,6

2 74 17,1 19,6 38,2

3 74 17,1 19,6 57,8

4 79 18,2 21,0 78,8

5 80 18,4 21,2 100,0

Total 377 100,0 100,0


Fuente: Propia

GRÁFICO N°23

Histograma de actual generación de horarios de clases


Fuente: Propia

88

ASIGNACIÓN INMEDIATA DE HORARIOS DE CLASES

Uno de los procesos más importantes en la generación de Horarios de clases es

poder visualizarlos inmediatamente en el perfil de usuario que cada estudiante

maneja, proceso que actualmente no se puede realizar porque se deben hacer

varias procesos antes, pero mediante el análisis de las encuestas los estudiantes

determinan que se encontrarían satisfechos al poder visualizar su horarios

inmediatamente (Media 2,66) y lo ratifica la Moda (3).

En el Histograma se observar que el 76% de estudiantes consideran importante

incluir este nuevo proceso.

CUADRO N° 40 Estadísticos asignación inmediata de horario de clases

N Válido 377

Perdidos 0

Media 2,66

Mediana 3,00

Moda 3


Varianza ,455

Asimetría -1,701

Curtosis 1,343

Mínimo 1

Máximo 3

Cuartiles 25% 3,00

50% 3,00

75% 3,00


Fuente: Propia

89

CUADRO N° 41 Frecuencia asignación inmediata de horario de clases


Porcentaje

válido

Porcentaje

acumulado

Válido 1 43 9,0 11,4 11,4

2 44 11,2 11,7 23,1

3 290 75,8 76,9 100,0

Total 377 100,0 100,0


Fuente: Propia

GRÁFICO N°24

Histograma asignación inmediata de horario de clases


Fuente: Propia

90

CAMBIOS HORARIOS DE CLASES

En una pregunta analizada anteriormente se medía los tiempos en los que se

solucionan errores generados en los Horarios de clases, en este tema se busca

medir la satisfacción de los estudiantes en cuál sería el mejor canal para realizar

los cambio y sean asignados inmediatamente en su perfil de usuario. El análisis

determina en su media (2,57) que los estudiantes prefieren realizarlo en

cualquier momento dentro de las fechas estimadas para los procesos de

matriculación, la Moda (3) indica que es la opción más satisfactoria para los

estudiantes.

Lo podemos observar de manera gráfica en el Histograma.

CUADRO N° 42 Estadísticos cambio horarios de clases

N Válido 377

Perdidos 0

Media 2,57

Mediana 3,00

Moda 3


Varianza ,559

Asimetría -1,383

Curtosis ,217

Mínimo 1

Máximo 3

Cuartiles 25% 2,00

50% 3,00

75% 3,00


Fuente: Propia

91

CUADRO N° 43 Estadísticos cambio horarios de clases


Porcentaje

válido

Porcentaje

acumulado

Válido 1 59 13,6 15,6 15,6

2 43 9,9 11,4 27,1

3 275 63,4 72,9 100,0

Total 377 100,0 100,0


Fuente: Propia

GRÁFICO N°25

Histograma cambio horarios de clases


Fuente: Propia

92

ASIGNACIÓN RECURSOS AULAS

La educación debe estar complementado con los diferentes instrumentos que

son proporcionados por las diferentes carreas, en ciertos casos contar con

aquellos recursos, se deben realizar trámites previos a las horas de clases. Se

consulta a la muestra de estudiantes y se obtuvo que ellos estuvieran realmente

satisfechos si se pudiera contar con los instrumentos adecuados ya en las aulas

para no entorpecer o perder las clases. En el análisis estadístico se observa que

la media (2,79) se inclina para la opción 3 al igual que la moda, por ende los

estudiantes están totalmente de acuerdo en aquello y lo representamos en le

Histograma.

CUADRO N° 44 Estadísticos asignación recursos aula

N Válido 377

Perdidos 0

Media 2,79

Mediana 3,00

Moda 3


Varianza ,320

Asimetría -2,563

Curtosis 5,057

Mínimo 1

Máximo 3

Cuartiles 25% 3,00

50% 3,00

75% 3,00


Fuente: Propia

93

CUADRO N° 45 Estadísticos Asignación Recursos Aula


Porcentaje

válido

Porcentaje

acumulado

Válido 1 29 6,7 7,7 7,7

2 21 4,8 5,6 13,3

3 327 75,3 86,7 100,0

Total 377 100,0 100,0


Fuente: Propia

GRÁFICO N°26

Histograma asignación recursos aula


Fuente: Propia

94

PRIORIDAD ASIGNACIÓN AULAS DISCAPACITADOS

La inclusión social debe estar presente en todas las instituciones del país y se

mide la satisfacción de los estudiantes para saber el porcentaje de acuerdo en

categorizar las aulas, en la media indica el valor 3,91 parcialmente se inclinan

que están parcialmente de acuerdo pero lo ratifican al ver el análisis de la moda

(5), donde refleja su total acuerdo en la categorización.

CUADRO N° 46 Estadísticos prioridad asignación aulas discapacitados

N Válido 377

Perdidos 0

Media 3,91

Mediana 4,00

Moda 5


Varianza 1,497

Asimetría -1,035

Curtosis ,036

Mínimo 1

Máximo 5

Cuartiles 25% 3,00

50% 4,00

75% 5,00


Fuente: Propia

95

CUADRO N° 47 Frecuencia prioridad asignación aulas discapacitados


Porcentaje

válido

Porcentaje

acumulado

Válido 1 25 5,8 6,6 6,6

2 38 8,8 10,1 16,7

3 36 8,3 9,5 26,3

4 125 28,8 33,2 59,4

5 153 35,3 40,6 100,0

Total 377 100,0 100,0


Fuente: Propia

GRÁFICO N°27

Histograma prioridad asignación aulas discapacitados


Fuente: Propia

96

DIAGRAMA DE CAUSA Y EFECTO

GRÁFICO N° 28 – Diagrama de Causa y Efecto


Fuente: Propia

Horarios de Clases

Personal Docente

Recursos Disponibles

Personal Administrativo

Sistema

Proporcionar malsus horarios

Sobrecarga de trabajo

Información no verificada

Tiempo fuera de línea

ProyectosInterno/Externos No contar con los equipos

Informáticos necesarios

Trabajo (Docentes medio tiempo)

Falta de espaciofísico para las clases

Cruce de Horas

Falta de equiposdidácticos

Almacenamiento incorrectode la información

Daños de los equipos

Soportes no preventivos

97

PLAN DE PRUEBAS

INTRODUCCIÓN

Propósito

El propósito del plan de pruebas es definir una correcta estructura en sus

técnicas y herramientas, que satisfaga los requerimientos obtenidos para el

proyecto: “ELABORACIÓN DE CASOS DE PRUEBAS DEL PROCESO DE

CREACIÓN HORARIOS DE CLASES Y RECURSOS DISPONIBLES PARA

IMPLEMENTAR EL PROTOTIPO DE SISTEMA ACADÉMICO EN LA

UNIVERSIDAD DE GUAYAQUIL”, planteando soluciones claras y finales en la

que se garantiza la detección de errores y las correcciones con la ejecución y

validación del mismo, garantizando el cumplimiento de los objetivos de las

autoridades de la Universidad de Guayaquil.

El propósito General es:

• Establecer un documento que detalle la planeación y control de las pruebas.

• Establecer cuáles son los estándares a seguir en las pruebas para el

desarrollo ya establecido.

• Definir un entorno correcto de pruebas.

• Establecer la metodología de pruebas que será usada.

• Identificar recursos y el tiempo estimado de los mismos.

• Involucrar a todos los usuarios interesados en el manejo de la aplicación.

• Definir los entregables al final de las pruebas realizadas.

Alcance

Se analizará la documentación recibida por parte de las etapas previas a las

pruebas con la finalidad de certificar que lo recibido es lo correcto y adecuado,

procediendo a validar cada proceso antes del levantamiento del esquema de

pruebas.

98

Haciendo uso de la metodología de investigación, se definirá un paso a paso de

las pruebas, con la finalidad de documentar cada registro de lo elaborado

obteniendo así una guía organizada de cada una de las actividades presentes en

este proyecto.

Se contempla el desarrollo de los Casos de Prueba como filtro previo a la

validación de los requerimientos planteados para el sistema académico y la

elaboración de las Pruebas:

CUADRO N° 48 Tipos de pruebas

Pruebas Funcionales

Permite evaluar cada uno de los

componentes de manera concreta

obteniendo así una validación del

software.

Pruebas de Interfaz Gráfica

Permite validar la navegabilidad del

sistema con cada uno de los

componentes físicos que se tiene para

la interacción de los elementos

gráficos.


Fuente: Propia

Se contempla los factores la plataforma que se vaya a utilizar:

99

CUADRO N° 49 Recursos requeridos

Sistema Operativo Debe de soportar los componentes que

se vayan a instalar para el

levantamiento del sistema académico.

Carga Mide el volumen de dato de cada uno

de los requerimientos presentes en los

escenarios previo a las pruebas

funcionales.

Volumen Debe de medir las transacciones que

recibe el software en tiempos pico, lo

que pueda provocar algún fallo.

Robustez Debe de verificar que el sistema se

mantenga estable después de algún

daño o fallo presente.

Concurrente Debe de tener la capacidad de medir

que el sistema pueda atender múltiples

sesiones de usuarios en un mismo

tiempo.

Recuperación a fallas Debe asegurar que el sistema pueda

recuperarse después de alguna falla de

hardware y de software sin pérdida de

la información que se haya estado

generando al momento.

Seguridad Debe de cumplir con todas las políticas

de seguridad que requieran los

interesados y las del software.

Base de datos Debe de verificar que las sentencias

realizadas aseguren el acceso de la

información y que no se pierda la

conexión a la misma.


Fuente: Propia

100

Pruebas Finales:

CUADRO N° 50 Pruebas Finales

Usabilidad Es importante definir que los errores

que se generen no sean por factores

humanos.

Instalación

Se debe verificar que la instalación y

desinstalación del sistema académico y

demás herramientas se las pueda

realizar en el o los equipos de la

Universidad de Guayaquil.


Fuente: Propia

Es importante, luego de estos períodos de pruebas, tener la aceptación de los

usuarios, después de un tiempo determinado de uso del sistema académico,

para tener en claro sus especificaciones y funcionalidades.

De ser el caso, se pueden realizar ajustes, pero todo se basa en las

funcionalidades que se requieran establecer, ajustar o corregir para el sistema

académico, a esto se lo conoce como pruebas de regresión. De además de

permitir cambios nos ayuda a realizar las validaciones al sistema después de los

cambios requeridos, y dar la seguridad que seguirá su funcionamiento sin

problemas después de cada modificación que se le realice.

Audiencia

Este Plan de Pruebas está dirigido a las autoridades de La Universidad de

Guayaquil y todos los Revisores, Auditores y Tutores encargados de la

planeación, aprobación y ejecución del mismo.

101

Referencias

• Casos de Uso

• Cronograma del Proyecto

• Actas de entregas por parte de terceros involucrados

• Manuales técnicos.

• Ley Orgánica del Servidor Público

MISIÓN DE LAS PRUEBAS

Contexto del Proyecto y Antecedentes

La carencia de un monitoreo interno y externo ha provocado que se pierda la

eficacia al momento de establecer los parámetros adecuados para la

comprobación de errores que se han venido presentando a lo largo de vida útil

del sistema actual con el que cuenta La Universidad de Guayaquil.

Se plantea el análisis de la información proveniente de los Casos de Uso y de los

procesos levantados en cada una de las Carreras Universitarias con la finalidad

de poder establecer una estructura robusta en cuanto a la metodología y las

técnicas de pruebas, para poder optimizar el manejo de las mismas,

convirtiéndose en una guía organizada de cada una de las actividades que se

llevarán a cabo en nuestro plan de pruebas.

Misión de las Pruebas aplicable a este proyecto

La misión de las pruebas es evaluar que se cumpla con los parámetros

establecidos para asegurar la calidad de las técnicas a usar, de manera que

estos cumplan con las especificaciones de los requerimientos de La Universidad

de Guayaquil. Para esto se definen los siguientes lineamientos que constituyen

la misión y objetivos dentro este esfuerzo de pruebas:

• Identificar lo mayor cantidad de errores posibles

• Notificar los riesgos que pueden estar presentes en el proyecto

• Estudiar en general la funcionalidad del sistema y comprobar mediante el uso

de la aplicación que cumpla con todos los procesos y requerimientos

102

necesitados. De igual forma verificar que esté realizando las validaciones

correspondientes para que no realice actividades que den un mal uso de la

aplicación o permita el almacenamiento de información errónea o no

deseada.

• Validar y verificar que los resultados obtenidos por el prototipo de sistema

académico sean iguales y guarden relación con las especificaciones

recibidas, para así de tal forma cumplir con los estándares de calidad

necesarios.

Motivadores de las Pruebas

Optimizar la operativa transaccional de las Carreras Universitarias y que la

ejecución de todos sus procesos genere y acapare la confianza de la población

estudiantil, para agilitar todas las solicitudes que estén presentes en las

actividades cotidianas del personal administrativo, docente y estudiantil.

Los motivadores puntuales que van a contribuir a que satisfaga las necesidades

del usuario de manera puntual son los siguientes:

• Estudio y análisis de casos de uso

• Gestión de calidad.

• Riesgo de calidad.

• Estructura en línea de los requerimientos por parte de los usuarios finales.

Ciclo de Pruebas

El ciclo de vida está determinado por las siguientes actividades:

Planificación

Para nuestro plan de pruebas es necesario tener en cuenta los lineamientos que

se deben seguir, por lo cual detallamos los siguientes planteamientos:

• Las pruebas serán enfocadas a los estándares que se han establecido

para cada uno de los parámetros de diseño o desarrollo.

• Se establece los tipos de niveles en las pruebas que se vayan a realizar.

• Se define las técnicas a emplear.

103

• Se determina el tiempo para cada una de las pruebas a realizar.

• Tipos de herramientas a utilizar

• Criterios de aceptación de los recursos involucrados.

• En la validación de la aplicación se debe tomar en cuenta el alcance

definido

• La funcionalidad de cada proceso

• La plataforma en la cual debe de ser instalado el prototipo

• Recurso humano capacitado para realizar las pruebas

• Considerar la LEOP para la revisión del aplicativo

Es importante mencionar que las pruebas solo serán realizadas durante el ciclo

de vida del desarrollo, en el cual se podrá obtener soluciones y

recomendaciones. Dicho esto se recalca que no se puede asegurar se podrá

eliminar en su totalidad los errores porque siempre estarán presentes, por tiempo

o metodología es imposible realizar un examen exhaustivo al software, por lo

tanto tampoco es recomendado que el desarrollador realice sus propias pruebas

ya que su enfoque es limita al desarrollo de las soluciones planteadas y no al

enfoque en general de las personas involucradas en este proceso.

Una vez determinado los puntos a considerar en la planificación y siendo todos

estos ejecutados correctamente obtendremos como resultado:

• Cronograma de pruebas: tiempos, recursos.

• Formatos de los casos de pruebas

• Formatos para el registro de los casos de prueba funcionales

• Registros de antecedentes y actuales para realizar cambios

• Técnicas específicas y metodologías a aplicar en las pruebas.

Diseño de las pruebas

En las pruebas de validación y verificación se tomará en cuenta los factores que

nos permitirán encontrar los posibles defectos presentes en el desarrollo.

Definimos los puntos, en cómo se va a estructurar nuestro diseño:

104

• Alcance: Esta definido por los requerimientos dado por la Carreras

Universitarias involucradas en la integración de nuestro prototipo de

sistema académico, se lo define de la siguiente manera:

o Análisis del levantamiento de información

o Estudio de los procesos

o Validación de los Casos de Uso

o Diseño de datos

o Diseño de implementación

o Requerimientos no funcionales.

• Inventario de pruebas: Definimos:

o Prioridades a las pruebas

o Establecer prioridades de trabajo

o Definir qué tipos de pruebas se realizarán, cual es la factibilidad

de cada uno para nuestras pruebas.

o Documentar los casos de regresión y si fueron exitosos.

o Si es necesario redefinir el alcance

o Considerar que tiempo se tomara probar cada funcionalidad

o Valorar que los aspectos técnicos del sistema sean los correctos.

• Resultado de la ejecución de pruebas: Se resalta los puntos principales

que derivan en la ejecución de las pruebas:

o Inventarios de pruebas anticipado y estandarizado

o Plan de desarrollo gradual de las pruebas

o Plazos establecidos para el proyecto

Ciclo de vida

Se especifica toda las actividades que se van a realizar en el proyecto, mas al

detalle se puede determinar el ciclo validando las versiones, el tiempo en el que

se analizarán los componentes, en este tiempo se reportará los tipos de pruebas

que se van a realizar y todos los errores que se han encontrado así como el

reporte de incidentes,

motivos:

• Atrasos en la ent

• Mal interpretaci

levantamiento de

• Cambios en el al

• Si se ve involucr

Ejecución

En esta etapa especific

ejecución de las técnica

El

Fue

La metodología en V, e

ya que es un modelo e

vida del software.

, el ciclo de vida puede verse entorpecido

ntrega del desarrollo

ción de los requerimientos planteados al ini

de información

alcance del prototipo de sistema

crada la Calidad del producto.

ficamos la metodología que vamos a implemen

cas de pruebas:

GRÁFICO N° 29 Metodología en V


uente: Pressman, Ingeniería de Software

es nuestra referida para la estructura de nuestra

el cual extiende todas las pruebas a lo largo d

105

por varios

inicio en el

ntar para la

tras pruebas

del ciclo de

106

La ventaja que nos ofrece esta metodología es que mientras se obtiene los

requerimientos, análisis, diseño y la futura implementación, se puede diseñar con

antelación el formato de pruebas que se vayan a usar para cada una de ellas,

una vez que se llega a la etapa de pruebas se inicia la ejecución y se almacenan

los resultados en las plantillas ya establecidas. A cada una de las pruebas se les

realizara el siguiente procedimiento:

1. Ejecutar

2. Resultado

3. Comprobar

4. Evaluación de Resultados

5. Retroalimentación

Para la correcta ejecución del modelo en V se tomará en cuenta las siguientes

especificaciones:

1. En cada módulo, lo que se va a probar dará la solución que se

implementará en cada proceso.

2. Se creará una lista de entrada de cada una de las especificaciones para

la ejecución de los casos.

3. Se analizará las salidas obtenidas en la ejecución del módulo, se

determinará si es lo requerido y está establecido en las especificaciones.

4. Los recursos dentro de los procesos conformen un entorno adecuado

(hardware, software, personal humano).

5. De ser el caso existiere requisitos o restricciones especiales en los

procedimientos deben ser considerados para la ejecución de las pruebas.

Evaluación y cierre

Para esta etapa el/los informe elaborados se presentarán, y se revisará todo lo

documentado con respecto a las diferentes pruebas ejecutadas.

Este documento estará compuesto por cada una de las pruebas detalladas y

demostraremos que se cumple con lo establecido en la propuesta de nuestro

Plan de Pruebas.

107

Las pruebas serán aceptadas si cumplen con los requisitos que se han

planteado en los casos de uso, de no ser así, de deberá plantear nuevamente el

caso hasta que cumpla con lo necesario para el giro del negocio.

Seguimiento y control

Se establece que se debe realizar un seguimiento periódico ya sea diario,

semanal o mensual, para las evaluaciones correspondientes a los siguientes

temas:

1. Que se respete el cronograma para la realización de las pruebas

2. Informe al momento de todas las pruebas que se hayan realizado

3. Seguimiento a las incidencias reportadas en la ejecución de la pruebas

4. Se debe presentar plan de contingencia para aquellas incidencias que

sean de mayor riesgo para el proyecto.

5. Soporte de herramientas para el control usaremos:

a. Microsoft Project

b. Microsoft Excel

Si existiera más de una liberación los errores no deberán ser recurrentes, se

solventarán una sola vez, en el caso de que se estuviesen presentando en todas

las liberaciones, el plan de pruebas se verá obligado a detener y se pedirá a la

parte encargada del desarrollo que revise en total su código para que solvente

los errores y poder finiquitar el tema.

También se valida este escenario para la base de datos y la comunicaciones de

servicios internos o externos.

ELEMENTOS OBJETIVOS DE LAS PRUEBAS

A continuación mencionamos todos los elementos recibidos y entregados que

serán objeto de validación dentro de nuestro Plan de Pruebas:

Fase Inicial

• Documentación, entrega formal del desarrollo, código fuente,

instaladores, casos de uso, procesos del levantamiento de información

108

• Verificar la documentación

• Verificar los entregables

• Validar los requerimientos detallados en los casos de uso

• Modelos - Diagramas

• Levantamiento del ambiente de pruebas independiente (ambiente local)

• Revisión de manual técnico de instalación

• Checklist del proceso de instalación de las herramientas para el uso del

prototipo de sistema académico (verificación paso a paso la instalación)

• Revisión del documento de los estándares de diseño (importante para el

diseño de los formatos de prueba).

Fase Final

• Desarrollo de la metodología aplicada a las pruebas (Modelo en V)

• Desarrollo de la técnica aplicada a las pruebas (Caja Negra)

• Plan de Pruebas

• Casos de Pruebas

• Casos de Pruebas Funcionales

• Casos de Pruebas de Aceptación

• Casos de Pruebas de Interfaz gráfica.

109

PANORAMA DE PRUEBAS PLANEADAS

GRÁFICO N° 30 Panorama de pruebas planeadas


Fuente: Pressman, Ingeniería de Software

110

ENFOQUE DE LAS PRUEBAS

El plan de pruebas contempla la verificación del proceso de instalación de las

herramientas visualización del prototipo, proporcionado por desarrollo, el proceso

debe ser el correcto, que todos los componentes que se tenga que usar sean

compatibles con el sistema operativo, que los usuarios proporcionados para el

ingreso a las herramientas sean los correctos y que se cumplan con los roles

establecidos, en su totalidad las pruebas son enfocadas solo en las pruebas

funcionales, de interfaz gráfica, se aplicara retroalimentación teniendo en cuenta

los requerimientos no funcionales.

• Revisión de la documentación: Se debe revisar cada uno de los

documentos entregados formalmente por otras partes pertenecientes al

proyecto y los casos de uso, se necesita que estén completos y concuerden

siempre con los requerimientos y los mapas de procesos que se manejan

para el prototipo de sistema académico.

• Pruebas funcionales o de procedimientos: La estrategia para realizar

estas pruebas consiste en la elaboración y ejecución de las Pruebas,

teniendo en cuenta flujo normal y flujos alternativos, usando datos validos e

inválidos que permitan verificar lo siguiente:

• Los resultados esperados ocurren cuando se usan datos validos.

• Se despliegan mensajes de error cuando se usan datos inválidos.

• Cada regla de negocio es propiamente aplicada.

• Pruebas de Regresión: La estrategia para realizar estas pruebas consiste

en repetir las pruebas (funcionales y de carga) ejecutadas antes de corregir

defectos o de añadir nuevas funcionalidades, para comprobar que las

modificaciones no provocan errores donde antes no los había.

111

Medición de la Extensión de las Pruebas

Cuando se tiene un número determinado de casos de prueba por cada caso de

uso, la forma de medir la extensión de las pruebas será comparando el número

de casos de prueba ejecutados satisfactoriamente contra el número de casos de

prueba total, esto nos dará a conocer el porcentaje de pruebas ejecutado por el

grupo de pruebas.

Pruebas de Aceptación

Las pruebas de aceptación se basarán en su totalidad en pruebas funcionales,

instalación, y otras teniendo en cuenta los requerimientos funcionales las

pruebas. Adicionalmente estas pruebas serán de caja negra.

CUADRO N° 51

Pruebas de aceptación

Objetivo de la

técnica:

Verificar el funcionamiento interno de los componentes

desarrollados, así como el procesamiento de datos que tiene

lugar en cada uno de estas acciones.

Técnica Pruebas de Caja negra

Herramientas

requeridas:

• Prototipo de Sistema Académico

Criterio de éxito • Concordancia de los procedimientos del sistema con los

requerimientos de usuario

• Optimo manejo de excepciones y errores

• Fácil seguimiento de la ejecución por medio de los traces.


Fuente: Propia

112

CRITERIOS DE ENTRADA Y SALIDA

Entradas del Plan de Pruebas

• Formatos de pruebas completos y desarrollados.

• Paso a paso del desarrollo de las pruebas realizadas.

• Levantar un entorno de pruebas seguro y adecuado.

• Los formatos de pruebas deben estar listos previo a la validación del

software, no se puede iniciar esta etapa sin aquello porque saldríamos del

cronograma.

Salidas del Plan de Pruebas

• Todas la pruebas deben de ejecutarse exitosamente de acuerdo a lo

planteado en los casos de uso, se debe guardar relación entre lo realizado y

lo que se pido, ambas salidas deben ser iguales y cumplir con los parámetros

establecidos.

Suspensión y Reanudación del Plan de Pruebas

• Se debe evaluar en primera instancia que el desarrollo entregado tenga el

flujo requerido, ya que puede provocar la paralización de las pruebas y la

estructura del diseño de los formatos.

• Al no contar con herramientas y servicios estables que permitan una

conexión segura para las pruebas.

• El entorno de pruebas que se analiza debe ser igual al de entorno que se

vaya a implementar en producción para el prototipo de sistema académico.

• Si el código recibido no se puede instalar o realizar la actualización de las

versiones.

Requisitos para la reanudación

• Verificar que se haya superado los problemas presentes en el momento de la

paralización y llegar a un consenso entre los encargados del plan de

pruebas, determinando el momento adecuado para retomar los trabajos.

113

Necesidades de Ambiente

Hardware

Se detalla las características del o los equipos requeridos para soporte del

software del prototipo de sistema académico:

CUADRO N° 52

Pruebas de aceptación

Equipo Procesador HD RAM

Xtratech, IBM,

HP, SONY. Indiferente 500GB 6 GB


Fuente: Propia

Software

• Windows XP o versiones superiores

• Microsoft Office 2010 o superiores, Open Office.

• IBM SPSS STATISTICS 2.0

• Framework ZX Versión 7.0 o Versión 7.2

• Eclipse Luna Versión 3.0

• JDK Version 7 Uptdate 75

• Bootstrap Version 3

• Hibernate Version 4

• TomCat Version 7.0

• SqlServer 2012 Release 2 SP2

• Aplicación Prototipo sistema académico Versión 2.0

114

Configuración de Ambiente de Pruebas

El ambiente de desarrollo es proporcionado por la persona encargada el

desarrollo, el prototipo de sistema académico usa como sistema base el Eclipse

Luna. Las demás aplicaciones que se usan como soporte o sistema de

almacenamiento son levantados por las personas de pruebas al igual que los

script o backup de la base datos.

Todo estas herramientas tendrán que ser instalados en un ambiente controlado,

por lo que se decidió, para las pruebas instalarlo en uno de los laboratorios de la

carrera para que tenga acceso a las autoridades, revisores, personal de pruebas.

DATOS DE PRUEBA

Los datos de pruebas recibidos no deben se der generados aleatoriamente, no

deben de ser ficticios y lo más importante no deben ser datos “quemados” dentro

del código de desarrollo.

Para las pruebas los datos deben ser reales, lo más propicio es que se trabaje

con una base de datos actualizada de las Carreras Universitarias o por lo menos

con una base de datos de unos dos años atrás, porque se debe cumplir con las

expectativas de cubrir las necesidades actuales de la población estudiantil,

asemejando más a la realidad del caso.

Las pruebas respetarán todos los parámetros establecidos, no se deberá

considerar agregar o quitar procesos porque el equipo de pruebas considera que

es lo mejor para las actividades cotidianas de La Universidad de Guayaquil.

Políticas de Administración de los Datos de Prueba

Esta condición es representativa únicamente para el equipo de pruebas:

• Antes de empezar a realizar el trabajo se debe dejar indicios del inicio de las

pruebas y realizar backup diariamente.

• Se deberá crear respaldos de la base de datos, dichos datos deben de

generarse correctamente, de tal forma que se deba verificar que los respaldos

115

que se generan puedan actualizarse en cualquier equipo de trabajo.

• Los datos que se ingresan a la base de datos adicional a los principales

deben de considerarse y tener en cuenta para futuros cambios en datos

estadísticos.

• Se debe respetar los roles de pruebas, no se podrá permitir que personas

ajenas al personal encargado realiza las pruebas del prototipo de sistema

académico.

RESPONSABILIDADES Y EQUIPO DE TRABAJO

CUADRO N° 53

Personas y Roles

Recursos Humanos

Rol Persona encargada Responsabilidades Específicas o

Comentarios

Administrador

de Pruebas

Fernando Gordon

Yépez

Levanta el ambiente de pruebas,

analiza los informes de pruebas

generados, manejo de recursos.

Diseñador de

Pruebas

Fernando Gordon

Yépez

Diseño del Plan de Pruebas

Analista de

Pruebas

Fernando Gordon

Yépez

Ejecución de las Pruebas

Documentación de las Pruebas.


Fuente: Propia

116

RIESGOS DE LAS PRUEBAS

Se elabora mencionando los puntos más relevantes que puedan causar riesgos

en la entrega del desarrollo, pruebas o documentación.

CUADRO N° 54

Riesgos de las pruebas

Factor de

Prueba Requerimientos Consecuencia Responsable

Conformidad

Pasar por alto

algún tipo de

prueba, tomar en

consideración

todos los

escenarios

posibles.

Errores de

usuarios a nivel

de todos los roles

Analista de

pruebas

Portabilidad

No identificar a

tiempo problemas

de compatibilidad

entre las

estructuras

presentes en o los

módulos.

No se obtienen

los datos

requeridos

Analista de

pruebas

Facilidad de Uso

No tomar en

cuenta la opinión

de los usuarios

representativos y

no analizar las

entrevistas

realizadas

Procesos no

entendibles al

momento de

realizarlos en el

sistema

Diseñador de

pruebas

Facilidad de No tener en claro Interrupción de Administrador

117

Factor de

Prueba Requerimientos Consecuencia Responsable

Operación los requerimientos

dentro de los

casos de uso, se

trata de optimizar

tiempo de

respuesta.

las actividades

cotidianas del

personal

administrativo

Corrección

No encontrar

errores por

motivos de

ambigüedad, se

Se espera que el

sistema haga una

actividad pero

está realizando

una diferente a la

planteada

Administrador de

pruebas

Filtración de

información

Falta de filtros de

seguridad a los

lugares donde se

está desarrollando

el sistema

Sabotaje del

proyecto

Administrador de

pruebas

Diseño incorrecto

Entorpecerá al

personal que tiene

menos experiencia

que los demás y

retrasará el trabajo

Errores en el

software

Administrador de

pruebas


Fuente: Propia

118

DIAGRAMA DEL PLAN DE PRUEBAS

GRÁFICO N°31


Fuente: Propia

119

RESULTADO DE LAS PRUEBAS

RESULTADO DE LA PLANIFICACIÓN

El objetivo principal es poder determinar que se ha planteado un prototipo

claramente óptimo para ser utilizado en cada una de las tareas presentes en las

actividades cotidianas de Las Facultades involucradas.

Se determinan técnicas que sean aptas para poder ejecutar los procesos y poner

a relevancia los defectos encontrados, evitando que dentro de este proceso de

pruebas se encuentren dificultades que detengan las mismas.

Se determina que el plan de pruebas empieza a realizarse desde el momento

que se recibió el Análisis y Diseño por parte de los encargados del levantamiento

de información, con esta herramienta se puede establecer cuáles serán los

posibles eventos a desarrollarse en el prototipo dentro del ambiente de pruebas

para en un futuro sacar al ambiente de producción un prototipo listo para el uso

de la comunidad universitaria.

En el supuesto caso de considerar o determinar con criterios acertados que el

análisis y diseño tiene un enfoque mal realizada o está fuera de los parámetros

que se han identificado, se deberá abortar las pruebas ya que se podría

encontrar en un ciclo repetitivo y entorpecer la labor de los involucrados y poder

llegar a perjudicar a la Universidad por un mal análisis que no abarca sus reales

necesidades en todas sus actividades, tanto administrativa como académicas.

SEGUIMIENTO DE LAS PRUEBAS

Las pruebas fueron realizadas en base al código que se obtuvo de la primera y

única liberación, se la realizó en dos semanas, tiempo determinado por el

120

Sistema actual

Prototipo de

sistema

cronograma general establecido para el proyecto, estas dos semanas no fueron

consecutivas.

Las pruebas se las realizaron en un ambiente local y controlado, fue limitado

porque no existió relación entre los demás módulos que se han planteado en el

prototipo, la base de datos con la que se trabajó fue la que se recibió de un

proyecto anterior, similar al que se plantea este estudio.

Hubo pruebas principales, las cuales fueron ejecutadas por el analista de

pruebas y el desarrollador del módulo de Horarios y Recursos Disponibles, se

pudo determinar los errores encontrados en cuanto a la funcionalidad, diseño,

validación y código de desarrollo, las soluciones aplicadas en esta primera etapa

fueron basadas en los requerimientos obtenidos y plasmados en los casos de

uso y otras soluciones fueron autónomas, basadas en las experiencias de los

involucrados.

Mediante las gráficas demostraremos el porcentaje de errores en esta primera

etapa.

GRÁFICO N° 32


Fuente: Propia

Los nuevos procedimientos implementados dieron resultados favorables y se

logró mitigar los errores presentes en esta primera etapa, al tratarse de una

primera instancia aun reflejan pequeños errores por no haber una integración

total del prototipo del sistema.

121

Sistema actual

Prototipo de

sistema

GRÁFICO N° 33


Fuente: Propia

Luego de una retroalimentación interna se lograron obtener buenos resultados,

en su gran mayoría.

En la segunda etapa de las pruebas realizadas se involucraron a las autoridades

de la Carrera de Ingeniería en Sistemas donde determinaron que se requerían

incluir más procedimientos al módulo, se necesitó realizar un enfoque nuevo y

modificar el alcance. Dentro de estos requerimientos se presentaron

modificaciones en el código fuente y la interfaz gráfica, en este proceso se

enfocó más a las soluciones administrativas y el correcto manejo e ingreso de

los Recursos con los que cuentan o pueden contar las Carreras Universitarias.

122

Sistema actual

Prototipo de sistema

Nuevos requerimientos

Sistema actual

Prototipo de sistema

Nuevos

requerimientos

GRÁFICO N° 34


Fuente: propia

GRÁFICO N° 35


Fuente: Propia

123

En esta etapa de correcciones y validaciones se logró cumplir lo que estuvo

planteado y con lo solicitado al módulo de Horarios y Recursos Disponibles, los

módulos son operables y amigables para la interacción con los usuarios finales.

Mostramos los involucrados a las pruebas del Prototipo del Sistema.

CUADRO N°55

Involucrados en la validación

Institución

Nombre del

representante Factibilidad Retroalimentación

Universidad de Guayaquil

Carrera de Ingeniería en

Sistemas

Computacionales

Fernando Gordon Yépez Si Si



Sistemas

Computacionales

Erick Velasco Si Si



Sistemas

Computacionales

Ing. Harry Luna Si Si



Sistemas

Computacionales

Ing. Bernardo Iñiguez Si Si


Fuente: Propia

124

CONLUSIONES Y RECOMENDACIONES DEL PLAN DE PRUEBAS

Este proceso fue contemplado para 2 Facultades de la Universidad de

Guayaquil, pero a lo largo del desarrollo del mismo solo se pudo contar con las

apreciaciones de las personal de la Carrera de Ingeniería en Sistemas

Computacionales, por tal motivo se necesita elaborar un alcance para que las

demás personas interesadas presenten sus observaciones en cuanto a los

procesos que ellos manejan versus con el manejo acoplado y reestructurado de

nuestro prototipo del Sistema académico.

Este prototipo de sistema está enfocado a la correcta administración de los

Recursos, se ha demostrado que se puede reemplazar todos los procesos

manuales y las herramientas utilitarias que se manejaban por un solo sistema

automatizado, en el cual se va usar una sola base de la que se podrá extraer lo

necesario para el desarrollo de las actividades cotidianas, este prototipo es muy

importante recalcar que no realiza generaciones automáticas, no se contempló

dicho procedimiento por lo cual si necesitan en un futuro de aquel requerimiento

se debe plantear un nuevo alcance en base a lo que existe para verificar la

factibilidad de poder aplicar dichos procesos y facilite el trabajo de los usuarios.

Las asignaciones de las aulas también han sido contempladas en el proceso

pero su ingreso al sistema es de manera individual (una a una), se debe

considerar en un futuro que las creación de los paralelos deben ser automáticas,

tomando los estudiantes que se han inscrito en niveles pasados y en base a los

paralelos que han sido creados en el semestre anterior. Este proceso ahorrará

tiempo operativo de las autoridades y evitarán que estos procesos fallen a las

proyecciones manuales que se realizan en la actualidad en la Carrera

Universitaria.

Los demás procesos que se han elaborado para el prototipo de sistema están

enfocados a ser adaptados a las actividades cotidianas del personal

administrativo de las Carreras, estos procesos no necesitan ser modificados,

sino se debe instruir al personal para que se acople a las tareas que se pueden

realizar en el prototipo, todo el análisis que se implemento está enfocado a todas

125

las tareas presentes, por tal motivo se puede concluir que en cualquier instancia

está listo para su inmediata aplicación y uso.

CRITERIOS PARA LA ELABORACIÓN DE LA PROPUESTA

Se muestra los flujos requeridos que se planteen para los procesos que se

presentan en las actividades cotidianas de las actividades académicas.

MAPA DE PROCESOS ADMINISTRACIÓN

GRÁFICO N°36

Elaborado por: Abel Ávila

126

MAPA DE PROCESOS DEL PROTOTIPO DEL SISTEMA ACADÉMICO

GRÁFICO N°37

Diagrama de procesos


Fuente: Propia

127

ANÁLISIS MAPA DE PROCESOS

Se analizará los procesos presentes y como estos deben ser llevados en cada

Facultad, cuales son los beneficios de los mismos, manteniendo siempre el

enfoque de nuestro tema: HORARIOS Y RECURSOS DISPONIBLES.

Hoy en día no existe comunicación en varios procesos que se manejan en las

oficinas administrativas de las Facultades involucradas, algunos procesos

guardan relación pero no viajan en línea recta, algunos están divididos y otros

procesos simplemente no cumplen ninguna especificación.

Sin la presencia del Órgano interventor, los períodos lectivos y demás

actividades oficiales eran establecidos bajo autonomía de cada Facultad, no se

manejaban cronogramas a nivel universitario, por ende no se tenía concordancia

con las actividades realizadas en las Carreras o Escuelas Universitarias.

El planteamiento del prototipo de sistema se enfoca más a la administración de

la información, en la actualidad las actividades son llevadas manualmente y a su

vez usan herramientas de libre acceso para el almacenamiento de la misma,

esto en desventaja presenta que se tengan que llevar formas de trabajar

subdivididas y dependientes de programas que no son pertenecientes a la

Universidad, los nuevos procesos que se han definido nos ayudará a poder

manejar los datos en una sola vía y tenerlos almacenados de manera

centralizada, se estableció que estará abierto al manejo de cualquier evento que

se presente y es adaptable a los cambios.

En el diseño está presente el módulo de calendario, el que estará a disposición

de Rectorado y Vicerrectorado Académico, administrado por el centro de

cómputo, los que bajo su autoridad está la generación del cronograma para

el/los ciclos presente en el año o período lectivo, siendo estos una vez creados,

serán replicados por vía email a cada uno de los encargados de las Facultades y

ellos conformarán sus planes de trabajo internos, acorde al tiempo estimado, de

tal manera cumplir con lo dispuesto por las autoridades universitarias y dar a

conocer a los estudiantes inmediatamente vía Web o por publicaciones en los

predios .

128

La estructura de este proyecto permite poder filtrar la información y darle el

manejo adecuado a la misma para permitir que los módulos sean funcionales

entre sí. Una vez definido el arranque de todas las actividades mediante el

cronograma, se debe determinar el pensum académico, para conocer los niveles

y los docentes que se van a necesitar, esta interacción va de la mano con dos

módulos externos al del prototipo, los que proporcionarán los datos de la Malla

curricular con sus respectivos niveles y el estatus del estudiante para conocer

sus créditos para el nivel a cursar.

Se estimó la creación de una aplicación que permita conocer una proyección

cercana a la realidad para la generación de los paralelos o cursos de clases, se

determinó que para poder obtener una eficacia en este proceso se debería

generar dos tipos de proyecciones las que dará un numero acertado para recibir

a los estudiantes en aulas aptas para su estadía en el semestre de clases. Se

manejan dos opciones, la primera es una proyección por el total de estudiantes

que han cursado cada materia en el semestre y la segunda opción es generar

una proyección espejo, en caso éxito que todos los estudiantes inscritos hayan

aprobados sus respectivos niveles.

Previa la elaboración de los Horarios de clases de debe obtener la disponibilidad

del Docente, es importante que la información sea la correcta y adecuada para

evitar que haya cruce de materias o conflictos en los Recursos disponibles de las

Carreras. Esta información por lo general es manejada por las secretarias, pero

en otros son manejadas directamente por los Directores, se ha definido que en

este proceso, como en los demás que se han implementado en el prototipo

deben de ser manejados bajo roles de perfiles de usuarios, para evitar la mala

manipulación y asignación de los recursos estudiantiles.

Hay Facultades que no poseen representadas sus horas de clases, todo un día

es un bloque, lo que ha llevado que muchas veces haya conflicto en asistir a

clases por parte de los estudiantes por la mal distribución en los horarios de los

docentes, es de mucha importancia poder asignar a cada grupo de horas de

clases una Jornada Académica, esto ayuda a identificar y organizar cada uno de

los recursos disponibles para los estudiantes, docentes y laboratorios de apoyo o

refuerzo para los estudiantes.

129

Los Horarios de clases deben ser generados de acorde a la disponibilidad de los

docentes y los recursos con los que cuentan cada Facultad, en la actualidad

todo este proceso es llevado de forma manual hasta la confirmación de los

mismos y sean almacenados en un programa de código abierto, el proceso

definido para esta pantalla es de poder interactuar directamente con un sistema

que permita el ingreso de los Horarios de clases de manera amigable sin tener

que salir de un proceso y acudir a otro para continuar, está definido que se

llevará a cabo una sola pantalla en la que el encargado de la generación de los

mismos pueda en esa mismo momento asignar los Horarios junto a la Carga del

docente y a los Paralelos los cuales están vinculados directamente con las Aula

o espacio físico que posee las Carreras Universitarias.

Generados los Horarios y conociendo en cada aula que se va a desarrollar, la o

las personas que esté encargada del manejo de los Recursos Disponibles

procederán a la asignación de los materiales y equipos que se necesitan para

impartir las clases en cada hora perteneciente a las materias. El proceso actual

se define que para adquirir algún equipo se deba realizar una solicitud o espera

a que el docente se acerque a la hora de clase, ocasionando demora en el inicio

de las actividades y pérdida de tiempo en el ámbito práctico. Por tal motivo se

planteó la creación de una herramienta que administre los recursos y nos

permita conocer el estado de los mismos para un mejor control, mantenimiento y

adecuación de los mismos.

Esto es algo muy importante que hoy en día ninguna Carrera llevaba en sus

controles, además de aquello este proceso contempla el ingreso de

observaciones de las aulas, de cómo se encuentran en su interior hasta las

dimensiones de la misma y de ser requerido también se puede ingresar un

código catastral de los espacios físicos.

Mejoras que se han planificado y se han plasmado en un proyecto para mejorar

la imagen del Universidad de Guayaquil, en la cual mejorarán tiempos de

respuestas, la calidad de atención por parte del personal administrativo la

eficacia de los docentes para impartir su clases con los recursos que se

necesiten y se han asignado directamente a las aulas de clases y el fervor de los

130

estudiantes por aprender y estudiar en una espacio físico que satisfaga sus

necesidades y expectativas.

DISEÑO DEL PLAN DE PRUEBAS

Se detalla el formato de los casos de pruebas a usar

CUADRO N°56

Caso de Prueba

Código Este formato se recibe por parte de los casos de uso y

se lo relaciona con los casos de pruebas para el

análisis de los procesos.

Ej. “CP_CREACION_AULA”

Prueba No. Por cada prueba que se elaboré se guardará un orden

establecido para la correcta documentación de las pruebas

Descripción

prueba

La descripción total de la pantalla o caso de uso que se va a

realizar, se debe dar al detalle la navegación de lo que se

quiere analizar.

Pre-requisitos Perfiles de usuarios.

Procedimiento Como se debe hacer las pruebas, se detalla el

procedimiento que es necesario para llegar a la validación

correcta, las características adecuadas para el ingreso de

dato y el almacenamiento del mismo.

Observaciones Resultados diferentes a los esperados.

Captura de

Pantalla

Imagen de la pantalla, sea como referencia o sea la pantalla

que se va a manejar.


Fuente: Propia

131

Diseño de las Pruebas a documentar

CUADRO N°57

Caso de Prueba

Código Este formato se recibe por parte de los casos de uso y

se lo relaciona con los casos de pruebas para el

análisis de los procesos.

Ej. “CP_CREACION_AULA”

Prueba No. Por cada prueba que se elaboré se guardará un orden

establecido para la correcta documentación de las pruebas

Descripción

prueba

La descripción total de la pantalla o caso de uso que se va a

realizar, se debe dar al detalle la navegación de lo que se

quiere analizar.

Pre-requisitos Perfiles de usuarios.

Procedimiento Como se debe hacer las pruebas, se detalla el

procedimiento que es necesario para llegar a la validación

correcta, las características adecuadas para el ingreso de

dato y el almacenamiento del mismo.

Observaciones Resultados diferentes a los esperados.

Captura de

Pantalla

Imagen de la pantalla, sea como referencia o sea la pantalla

que se va a manejar.

Resultado Exitosa Fallida No aplica

Resultado obtenido en las pruebas


Fuente: Propia

132

CRITERIOS DE VALIDACIÓN DE LA PROPUESTA

Mediante la estrategia que se ha planteado en el plan de pruebas y en su

desarrollo se muestra los diseños de casos de pruebas que se vayan a utilizar en

cada uno de las pantallas que se cuenta en el prototipo de sistema académico

para la respectiva validación y la labor de mitigar errores del sistema.

El ambiente que se levantó debe estar correctamente validado para poder

recopilar las pruebas necesarias, las cuales serán una herramienta primordial

para la aplicación de soluciones a cada uno de los requerimientos que se han

planteado en los análisis respectivos o de ser el caso dar un nuevo enfoque a la

operativa del sistema sin afectar el giro del negocio del sistema.

Todos los resultados por parte de los analistas de pruebas serán recopilados y

validados en base a los requerimientos y ejecución de las pruebas.

Se manejará el siguiente formato del levantamiento de informe de las pruebas,

las cuales en filtros posteriores son validadas en un versus con los

requerimientos y procesos levantados de las actividades actuales.

Se describe el significado de la nomenclatura a utilizar:

CUADRO N. 58

Descripción de las pruebas

DETALLE REPRESENTACIÓN Prueba Unitaria U Prueba Funcional F Prueba Interfaz Gráfica IG Prueba Exitosa E Prueba Fallida F Prueba No Aplica NA

Elaborado por: Abel Ávila

133

CUADRO N. 59

Informe de Pruebas

Or

de

n

Tipo

Prueba

No Detalle Caso de Prueba Result

ado

U F IG E F N

A

1 X 1 CP_CATALOGO_EDIFICIO X

2 X 2 CP_CATALOGO_UBICACION X

3 X 3 CP_HORARIOS_AULA_CREACION X

4 X 4 CP_HORARIOS_CARGA_HORARIA X

5 X 5 CP_HORARIOS_CARGA_HORARIA_DOCE

NTE

X

6 X 6 CP_HORARIOS_JORNADA_ACADEMICA X

7 X 1 CP_HORARIOS_PLANIFICACION_CLASES X

8 X 2 CP_HORARIOS_PERIODO_LECTIVO X

9 X 3 CP_HORARIOS_PROYECCION_PARALEL

OS

X

10 X 4 CP_HORARIOS_GENERACION_PARALEL

OS

X


Fuente: Propia

Se mitigaron errores, ninguno de aquellos entorpeció el ciclo de vida del proyecto

ni más aún en las actividades cotidianas del personal administrativo, se

respetarán todos los procesos, no se involucró criterios de terceros (analistas de

desarrollo), sino que se respetó cada uno de los procesos que son necesarios

estén presentes por pedido de los involucrados en el manejo del sistema

académico.

134

La información desarrollada es analizada, depurada y recopilada para ser

preparada y entregar a la siguiente fase del proyecto, dejando en claro que las

validaciones se realizaron en base a planes y estudios para el beneficio de los

interesados en el uso del sistema académico.

135

CAPÍTULO IV

MARCO ADMINISTRATIVO

CRONOGRAMA

En el cronograma presente se establece los tiempos que se han considerado a

lo largo de la elaboración del proyecto. La finalidad es establecer procedimientos

que sean velados y cumplidos en base a las exigencias proporcionadas en la

planificación de gestión y calidad.

Se deberá considerar todos los factores presentes, corrección de

planteamientos, análisis de nuevos requerimientos, dentro de un rango de

tiempo considerable para no realizar tareas fuera del alcance, si los sucesos

entorpecen el actual proceso y se debe determinar que se necesita más tiempo,

se notificará a los encargados para la extensión o prórroga y de no ser aceptado

alguna extensión, el trabajo continuará según el cronograma principal.

136

CUADRO N° 60

Cronograma

Nombre de tarea Duración Comienzo Fin

Pruebas del Módulo de

HORARIOS Y RECURSOS

DISPONIBLES, para el

prototipo del Sistema

Académico

95 días mar

06/01/15 vie 15/05/15

Reunión con Ing. Iñiguez,

Tutor de la Tesis 1 día

lun

05/01/15 lun 05/01/15

Capacitación por parte del

personal del grupo anterior 9 días

mar

06/01/15 vie 16/01/15

Asignación de

responsabilidades y Módulo 2 días

lun

19/01/15 mar 20/01/15

Instalar herramientas para

levantamiento del Sistema

Académico

5 días mié

21/01/15 mar 27/01/15

Investigación métodos a

aplicar para la elaboración de

pruebas

5 días vie

30/01/15 jue 05/02/15

Levantamiento de ambiente

pruebas 4 días

vie

06/02/15 mié 11/02/15

Capacitación de la

arquitectura a implementar,

acceso vía Web

1 día jue

12/02/15 jue 12/02/15

Agrupación de Módulos, para

la revisión del primer

entregable

5 días vie

13/02/15 jue 19/02/15

Primera Revisión 2 días vie

20/02/15 dom 22/02/15

Filtro de la información

recibida por Levantamiento, 10 días

lun

23/02/15 vie 06/03/15

137

análisis y desarrollo de

esquemas para el desarrollo

previo a la revisión del

segundo entregable

Segunda Revisión 5 días lun

09/03/15 vie 13/03/15

Filtro de la información

recibida por Levantamiento,

análisis y desarrollo de

esquemas para el desarrollo

previo a la revisión del tercer

entregable

10 días lun

16/03/15 vie 27/03/15

Tercera Revisión 5 días lun

30/03/15 vie 03/04/15

Elaboración de Pruebas 4 días lun

06/04/15 jue 09/04/15

Elaboración de Pruebas 1 día vie

10/04/15 dom 12/04/15

Redacción de la Tesis 15 días lun

13/04/15 dom 03/05/15

Revisión y entrega de

Capítulos 9 días

lun

20/04/15 jue 30/04/15

Entrega de anillados 1 día lun

04/05/15 lun 04/05/15


Fuente: Propia

138

PRESUPUESTO

Se detalla los gastos incurridos para el desarrollo del proyecto, cabe recalcar que

este proyecto es elaborado para tema de tesis por lo cual se suprime el detalle

de los ingresos porque todas las actividades han sido cubiertas por el estudiante

egresado de la Carrera de Ingeniería en Sistemas Computacionales a cargo de

esta investigación.

CUADRO N° 61

Detalle de egresos del proyecto

EGRESOS DÓLARES

Fotocopias $ 70.00

Documentos 25.00

Computadora y servicios de Internet 115.00

Transporte 400.00

Refrigerio 50.00

Empastado, anillado de tesis de grado 100.00

TOTAL……………………………………… $ 810.00


Fuente: Propia

Egresos

• Para la revisión de los documentos con los Tutores se debe imprimir los

Capítulos y realizar el anillado de las hojas que posee la tesis, para la

presentación formal de la misma

• Entre los requisitos para la entrega de documentos a la subdirección se

deben presentar documentos, los cuales requieren de ser cancelados

previamente su presentación.

• Se estima el valor del servicio de internet que se ha usado a lo largo de

estos 5 meses de desarrollo del proyecto y el uso de computadoras

alquiladas dentro de un cyber.

139

• Al poseer vehículo propio e ir a la Universidad todos los días se incurría

en gastos de gasolina, mensualmente se destinó 80 dólares y se acudía

a las tutorías de lunes a sábado.

• Por lo general los días sábados se incurría en gastos de comida, el valor

es proporcional a un día por semana, ya que las jornadas eran extensas

y se acudía en el break al medio día.

• El empastado y los anillados son gastos comunes en los que se incurre

cuando se realiza una tesis, son valores que se tomaron en base al total

gastado en las fechas topes de entrega de documentos.

140

CAPÍTULO V

CONCLUSIONES Y RECOMENDACIONES

CONCLUSIONES

A lo largo del desarrollo de este proyecto se han determinado muchos factores

los cuales han sido determinantes para la continuidad del mismo o han

entorpecido ciertos procesos que han delimitado el nivel planteado, el fin es

mostrar que se superó todo inconveniente presente y se ha cumplido con los

objetivos expuestos por los interesados, logrando el fin, la creación de un

prototipo funcional para el nuevo Sistema Académico.

El objetivo principal era desarrollar un sistema académico concerniente a

HORARIOS Y RECURSOS DISPONIBLES, el cual se originaba de una versión

anterior realizada por un grupo de estudiantes de la Carrera de Ingeniería en

Sistemas Computacionales, se planteó necesariamente una retroalimentación de

todos los procesos de la Facultad de Matemáticas y Físicas, con el propósito de

abarcar el total de sus necesidades administrativas e integrar todos sus procesos

en una sola plataforma. Determinaron que el sistema y su alcance era capaz de

soportar el flujo transaccional que se decidió invitar a participar en este actual

proyecto a La Facultad de Ciencias Administrativas para que forme parte de la

automatización de las tareas administrativas, docentes y estudiantiles.

141

El principal reto era automatizar los procesos de cada Facultad para que sean

manejados en un solo sistema, actividad que se vio comprometida en cierta

parte por personal administrativo, el cual a lo largo de los años de su vida

profesional se habían acostumbrado a manejar muchas tareas acorde a sus

necesidades personales y de forma manual, nosotros no podíamos detener el

cambio por contar con personas renuentes y se tomó la decisión de además de

los procesos automatizados, manejar pantallas visualmente amigables y en las

cuales se manejaban más de dos procesos los cuales disminuían el tiempo de

transacción y el acceso a varias pantallas para llevar a cabo una sola tarea

administrativa.

El módulo de HORARIOS Y RECURSOS DISPONIBLES tiene como parte

sensible la elaboración de los cronogramas lo cual a medida que avanzó el

proyecto se logró integrar la creación de aquello a nivel de Vicerrectorado

General, otorgando la posibilidad de que una sola entidad logrará la creación de

actividades unificadas de todas las Facultades Universitarias, siendo esto muy

importante porque todas las actividades son manejadas de forma centralizada y

se guardan estándares y se cumplen leyes que son veladas por las autoridades

de la Universidad de Guayaquil.

De acorde a las actividades de integración social, se tomaron en cuenta

aplicativos que ayudan a la inclusión social, siendo esto en gran parte, las aulas

para personas con algún tipo de discapacidades, en el manejo de los

RECURSOS DISPONIBLES, se creó categorías que facilitan la correcta

identificación de los espacios físicos y la oportunidad adecuada distribución de

los mismos.

Gracias a la oportunidad del amplio mercado tecnológico se pudo contar con

herramientas y software libres, no era necesaria adquirir una licencia para los

mismos, que representó un aporte significativo para la Universidad de Guayaquil

porque no fue necesario invertir en recursos monetarios, lo cual genero sin duda

alguna el primer factor para la aprobación del proyecto, el cual iba enfocado al

aporte social y a una entidad pública con muchos años de prestigio en la

educación superior y que está al servicio de los jóvenes de la patria, lo que

142

permite emprender nuevos retos estratégicos y solventar problemas a futuro

dando paso a evidentes cambios en las bases universitarias, dando la

oportunidad de seguir confiando en el alumnado que está culminando su carrera

profesional y a las reformas que actualmente el Gobierno Central aplica, para

demostrar que la Universidad de Guayaquil fue, es y será el mejor lugar para

formar profesionales para nuestro país.

RECOMENDACIONES

Al conocer que las necesidades fueron cubiertas en su totalidad y se superaron

expectativas, lo óptimo, para el prototipo del sistema y llevar un correcto

funcionamiento del mismo, se debería implementar en el ámbito del Hardware,

equipos actualizados que soporten la plataforma desarrollada y no entorpezca

las actividades cotidianas además de evitar crear descontento entre los usuarios

y generar comentarios adversos por no cumplir con las especificaciones

requeridas para el manejo de la herramienta administrativa, confundiendo el mal

desempeño de equipos con la falta de recursos para que el/los aplicativos

puedan resolver y solventar los problemas planteados a un inicio de nuestro

proyecto.

Periódicamente se debe realizar análisis de funcionalidad al prototipo para

levantar informes y obtener resultados identificables, los cuales nos avalaran que

los procesos están siendo manejados por la vía correcta o se requiere un nuevo

análisis y/o retroalimentación para adecuarlos a corto plazo. Es importante

mencionar que la herramienta que se les proporciona es capaz de soportar

actividades no contempladas en el diseño y análisis, se trató de contemplar

eventos futuros relacionando la actividad de la Universidad y la Leyes que

actualmente rigen a la Educación Superior.

143

BIBLIOGRAFÍA

1. Balaguer, J. (2010) José María Escriva de Balaguer y la Universidad. En

el URL:

http://www.unav.es/servicio/opusdei/textos-de-san-josemaria-sobre-la-

universidad

Carlino P. (2005) “Escribir, leer y aprender en la universidad”. Bs As,

Fondo de Cultura Económica 2005, 208 p ISBN 978-950-557-653-1.

2. Piattini (2007). (Cap. 10)

3. Sommerville (2005). (Capítulo 22 y 23)

4. Jacobson, I., Booch, G., and Rumbaugh, J. (2000): El Proceso

5. Unificado de Desarrollo. Addison-Wesley. (Capítulo 11)

6. Pressman, R. (2005): Ingeniería del Software: Un Enfoque Práctico. 6º

7. Edición. McGraw-Hill. (Capítulos 13 y 14)

8. Pfleeger (2002). (Caps. 7, 8 y 9)

9. IEEE Computer Society (2004). SWEBOK - Guide to the Software

Engineering Body of Knowledge, 2004. (Capítulos 4 y 5)

http://www.swebok.org/

10. Bernd Bruegge y Allen H. Dutoit, (2002), Ingeniería de software O. O.,

Prentice Hall, México, ISBN 9789702600107.

11. Myers G. J, (1976), The Art of Software Testing. New York: John Wiley &

Sons, pp. 59-65.

12. Dustin E, (2003), Effective Software testing, Pearson Education.

13. Zuyu J., Tsao J., Wu Y., (2003), Testing y Quality assurance for

component-based software.

14. Burnstein I, (2003), Practical Software Testing, Estados Unidos, ISBN

978-0-387-95131-7.

15. Pressman, Roger S, ( 2005), Ingeniería del software, un enfoque práctico,

Ed. McGraw-Hill, 6ta Edición. ISBN: 9701054733.

16. Serna M., Edgar; Serna A., Alexei, (2012), Una evaluación a las

herramientas libres para pruebas de software, Revista Virtual Universidad

Católica del Norte, Septiembre-Diciembre

17. Sommerville Ian, (2005), Ingeniería de Software. Séptima edición.

144

18. García, Javier; de Amescua, Antonio; Velasco, Manuel. (2006). TOP 10

de factores que obstaculizan la mejora de los procesos de verificación y

validación en organizaciones intensivas en software. REICIS. Revista

Española de Innovación, Calidad e Ingeniería del Software, octubre, 18-

28.

19. Mario G. Piattini Velthuis, Coral Calero Muñoz, Mª Ángeles Moraga De La

Rubia, 2010, Calidad del producto y proceso software, Editor: RA-MA

S.A. Editorial y Publicaciones (11 de febrero de 2010), Idioma: Español,

ISBN-10: 8478979611.

20. Kendall-Kendall, 2011, Análisis y Diseño de-Sistemas.

21. Manchado V. E., Caraballo M. J., Darías C. Y., (2012), El camino a un

mejor programador.

22. Cervantes Ojeda J.; Gómez Fuentes María del Carmen, (2012),

Taxonomía de los modelos y metodologías de desarrollo de software más

utilizados. Universidades, Enero-Marzo.

ANEXOS

Elaborado por: Fernando Vicente Gordon Yépez

Revisado por:

Aprobado por: Fecha:

PRUEBA UNITARIA

Código CP_CATALOGO_EDIFICIO _V1.0

Prueba No. 1

Descripción prueba Horario > Catálogo > Edificio

Pre-requisitos Usuario debe iniciar sesión con perfil de administrador.

Procedimiento 1. Ingreso al sistema con clave y contraseña.

2. Escoge Universidad > Facultad > Carrera.

3. Navegar en: Catálogo.

4. Ingresar los campos requeridos.

5. Verificar criterios de ingresos de los datos.

6. Validar campos numéricos y alfanuméricos.

Observaciones • Caso de Prueba.

Captura de Pantalla



Revisado por:



Prueba No. 2






4. Campo esta deshabilitado.

5. El campo estado en la generación está inactivo.

6. Solo se habilita campo para la modificación.


Captura de Pantalla



Revisado por:



Prueba No. 3






4. Dar clic en Guardar.

5. Datos almacenados exitosamente.


Captura de Pantalla



Revisado por:



Prueba No. 4






4. Dar clic en Ignorar.

5. Se descarta los campos ingresados y regresa al menú principal.


Captura de Pantalla



Revisado por:



Prueba No. 5






4. Verificar la lista de Edificios ingresados.

5. Verificar que los campos sean ingresados correctamente.


Captura de Pantalla



Revisado por:



Prueba No. 6

Descripción prueba Horario > Catálogo > Edificio > Consultar





4. Verificar el edificio que se desea modificar en la lista.

5. Visualiza en primer plano.

6. Dar doble clic visualizar en segundo plano.


Captura de Pantalla



Revisado por:



Prueba No. 7

Descripción prueba Horario > Catálogo > Edificio > Modificar





4. Dar doble clic en el edificio que desea modificar.

5. Cambiar el/los campos que desea modificar.


7. Datos modificados exitosamente.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_CATALOGO_JORNADA _V1.0

Prueba No. 1

Descripción prueba Horario > Catálogo > Jornada





4. Ingresar el nombre de la Jornada.

5. Verificar criterios de ingreso de datos.


Captura de Pantalla



Revisado por:



Prueba No. 2






4. Verificar funcionalidad de los combos para el registro de las fechas.

5. Verificar que el formato de las fechas manejen los rangos conocidos.

6. Validar rangos entre fechas y fechas.

7. Validar fechas actuales reflejadas en las opciones.


Captura de Pantalla



Revisado por:



Prueba No. 3







5. Datos se han guardado exitosamente.

6. Regresa al menú principal.


Captura de Pantalla



Revisado por:



Prueba No. 4







5. Se descarta los datos ingresados.



Captura de Pantalla



Revisado por:



Prueba No. 5






4. El campo estado esta deshabilitado.

5. Cuando el registro es por primera vez se bloquea la opción de elegir.

6. Campo habilitado solo para la modificación.


Captura de Pantalla



Revisado por:



Prueba No. 6

Descripción prueba Horario > Catálogo > Jornada > Consultar





4. Ingresar criterio de búsqueda.


6. Dar clic en buscar.


Captura de Pantalla



Revisado por:



Prueba No. 7






4. Verificar lista de Jornadas creadas y/o modificadas.

5. Realizar el proceso para las demás jornadas restantes.

6. Validar todos los campos de ingresos.


Captura de Pantalla



Revisado por:



Prueba No. 8

Descripción prueba Horario > Catálogo > Jornada > Modificar





4. Dar doble clic en alguna jornada existente en la lista de Jornada

5. Realizar los cambios en el o los cambios necesitados.

6. Dar clic en guardar

7. Datos grabados exitosamente.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_CATALOGO_UBICACION_V1.0

Prueba No. 1

Descripción prueba Horario > Catálogo > Ubicación




3. Navegar en: Ubicación.

4. Ingresar los campos requeridos.

5. Verificar criterios de ingresos de los datos.

6. Validar campos numéricos y alfanuméricos.


Captura de Pantalla



Revisado por:



Prueba No. 2






4. Campo Estado deshabilitado.

5. En la generación el campo está bloqueado.

6. En la modificación el campo está habilitado.


Captura de Pantalla



Revisado por:



Prueba No. 3







5. Datos almacenados exitosamente.


Captura de Pantalla



Revisado por:



Prueba No. 4







5. Se descarta los datos ingresados y regresa a la pantalla principal.


Captura de Pantalla



Revisado por:



Prueba No. 5

Descripción prueba Horario > Catálogo > Ubicación > Consultar





4. Ir a Consultar ubicación.

5. Ingresar datos a consultar.

6. Verificar criterio de ingreso de datos.



Captura de Pantalla



Revisado por:



Prueba No. 6

Descripción prueba Horario > Catálogo > Ubicación > Modificar





4. Dar doble clic en la ubicación que desea modificar.

5. Se despliega la pantalla de ingreso con los campos cargados.

6. Ingresar los datos a modificar.



Captura de Pantalla



Revisado por:



Prueba No. 7







5. Datos modificados guardados exitosamente.

6. Verificar en la lista los cambios.


Captura de Pantalla



Revisado por:



Prueba No. 8







5. Se declina los datos ingresados a modificar.

6. Regresa a la pantalla principal de Catálogo.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_HORARIO_AULA_CONSULTAS _V1.0

Prueba No. 1

Descripción prueba Horario > Ingreso de Aula > Consulta Aulas

Pre-requisitos Usuario debe iniciar sesión con perfil de coordinador.



3. Navegar en: Horario > Aula > Consulta de aulas.

4. Ingreso de campo requerido para la búsqueda.

5. Validar criterios de ingreso de datos.

6. Visualizar resultados.


Captura de Pantalla



Revisado por:



Prueba No. 2






4. Visualizar pantalla de ingreso de aula desplegada.


Captura de Pantalla



Revisado por:



Prueba No. 4






4. Dar clic botón ignorar.

5. Se visualiza la pantalla de listado de consulta sin modificaciones.


Captura de Pantalla



Revisado por:



Prueba No. 4






4. Verificar datos de consultas.

5. Ubicar en puntero en el text siempre que se ingrese mal un campo, para evitar avanzar y generar errores involuntarios.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_HORARIO_AULA_CREACIÓN _V1.0

Prueba No. 1

Descripción prueba Horario > Ingreso de Aula > Llenar campos vacíos




3. Navegar en: Horario > Aula.



Captura de Pantalla



Revisado por:



Prueba No. 2

Descripción prueba Horario > Ingreso de Aula > Escoger datos de las listas





4. Validar listas tengan almacenando datos reales.


Captura de Pantalla



Revisado por:



Prueba No. 3

Descripción prueba Horario > Ingreso de Aula > Verificar prioridad





4. Validar si es necesaria una prioridad para el aula.


Captura de Pantalla



Revisado por:



Prueba No. 4

Descripción prueba Horario > Ingreso de Aula > Estado





4. Estado bloqueado, en la asignación deben siempre estar activos.


Captura de Pantalla



Revisado por:



Prueba No. 5

Descripción prueba Horario > Ingreso de Aula > Botón guardar





4. Ingreso de aula realizado exitosamente.


Captura de Pantalla



Revisado por:



Prueba No. 6

Descripción prueba Horario > Ingreso de Aula > Botón regresar





4. Se limpia la pantalla y regresa al menú principal.


Captura de Pantalla



Revisado por:



Prueba No. 7

Descripción prueba Horario > Ingreso de Aula > Campos obligatorios (*)





8. El sistema impide seguir con el ingreso de siguientes campos sino se llenan los demás que le precede.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_HORARIO_AULA_MODIFICACION _V1.0

Prueba No. 1

Descripción prueba Horario > Ingreso de Aula > Modificación de aulas




3. Navegar en: Horario > Aula > Modificación de aulas.

4. Seleccionar el aula a modificar dando doble clic.


Captura de Pantalla



Revisado por:



Prueba No. 2






4. Aceptar condición de continuar para modificar un aula o descartar y prevenir errores involuntarios.


Captura de Pantalla



Revisado por:



Prueba No. 3






4. Modificar campos a ser ingresados.

5. Verificar criterios de ingresos para los datos.


Captura de Pantalla



Revisado por:



Prueba No. 4






4. Dar clic en botón guardar y conversar los cambios.

5. Visualizar cambios en la lista de consulta de aulas.


Captura de Pantalla



Revisado por:



Prueba No. 5






4. Dar clic en botón ignorar.

5. Se descarta los cambio y se conversa los datos originales.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_HORARIO_AULA_MODIFICACION _RECURSOS_V1.0

Prueba No. 1

Descripción prueba Horario > Ingreso de Aula > Modificación de recursos




3. Navegar en: Horario > Aula > Modificación de recursos.

4. Seleccionar el aula a modificar y poder ingresar a los recursos dando doble clic.


Captura de Pantalla



Revisado por:



Prueba No. 2






4. Se despliega la pantalla de recursos y se verifica los datos que han sigo guardado en el primer caso.


Captura de Pantalla



Revisado por:



Prueba No. 3






4. Modificar los datos que se necesitan.

5. Verificar criterio de ingreso de datos.


Captura de Pantalla



Revisado por:



Prueba No. 4






4. Dar clic en botón guardar.

5. Verificar en la lista de registro los datos que se han modificado.


Captura de Pantalla



Revisado por:



Prueba No. 5






4. Dar clic en botón regresar.

5. Se descartará todos los cambios y se mantendrá la lista como se la ingreso desde la primera vez..


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_HORARIO_AULA_RECURSOS _V1.0

Prueba No. 1

Descripción prueba Horario > Ingreso de Aula > Recursos del aula > Ingreso de datos




3. Navegar en: Horario > Aula > Recursos del aula.

4. Ingreso de campos requeridos.



Captura de Pantalla



Revisado por:



Prueba No. 2

Descripción prueba Horario > Ingreso de Aula > Recursos del aula





4. Ingreso de campos requeridos de los combos.


Captura de Pantalla



Revisado por:



Prueba No. 3

Descripción prueba Horario > Ingreso de Aula > Recursos del aula





4. Validar datos ingresados en los combos, deben ser reales y acoplados a las necesidades de las Carreras.


Captura de Pantalla



Revisado por:



Prueba No. 4

Descripción prueba Horario > Ingreso de Aula > Recursos del aula > Estado





4. El estado estará inhabilitado a la aplicación del primer ingreso para respetar los parámetros de asignaciones.


Captura de Pantalla



Revisado por:



Prueba No. 5

Descripción prueba Horario > Ingreso de Aula > Recursos del aula > Botón guardar





4. Ingreso de recursos realizados existosamente.


Captura de Pantalla



Revisado por:



Prueba No. 6

Descripción prueba Horario > Ingreso de Aula > Recursos del aula > Botón regresar





4. Se perderán todos los datos ingresados y regresará al menú prinicipal.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_HORARIO_CARGA_HORARIA _V1.0

Prueba No. 1

Descripción prueba Horario > Carga Horaria > Horario Clase




3. Navegar en: Horario > Carga horaria > Horario Clase.

4. Del menú presente, escoger la opción de Horario de clases para la generación de un nuevo horario de clase de un periodo vigente.

5. Verificar que se despliegue una pantalla adicional a la que se está presentando para evitar un problema de secuencia.

6. Dar clic en Horarios de clase.


Captura de Pantalla



Revisado por:



Prueba No. 2






4. Verificar que los combos estén con datos correspondiente a los horarios de clases.

5. Verificar que los datos en los combos sean datos actuales y no caducados.

6. Escoger los datos a generar.

7. Dar clic en Generar.


Captura de Pantalla



Revisado por:



Prueba No. 3






4. Si desea declinar dar clic en Ignorar.

5. Regresa a la pantalla principal.


Captura de Pantalla



Revisado por:



Prueba No. 4






4. Dentro del menú de horario podemos escoger los paralelos que se despliegan según la malla curricular en la cual el estudiante esté cursando.

5. Verificar los parales que se reflejan porque tienen que estar acorde a los datos que han sido seleccionados previamente.


Captura de Pantalla



Revisado por:



Prueba No. 5






4. Dar doble clic en el paralelo al cual se le realizará la generación.

5. Dar clic en continuar para iniciar el proceso de generación.


Captura de Pantalla



Revisado por:



Prueba No. 6






4. Dar clic en Cancelar si desea declinar la operación.



Captura de Pantalla



Revisado por:



Prueba No. 7






4. Se despliega el conjunto de materia asignados al paralelo escogido.

5. El conjunto de materias debe de reflejar validado por otro módulo (Mallas) y que nuestro módulo solo consume esos datos.

6. Verificar que la jornada escogida este acorde a los horarios que se han desplegado.


Captura de Pantalla



Revisado por:



Prueba No. 8






4. Dar doble clic en la materia a asignarle horario de clases.

5. Se despliega una pantalla la que nos ayudará a validar los datos que debemos de ingresar.

6. Validar criterios de selección.

7. Dar clic en Añadir.


Captura de Pantalla



Revisado por:



Prueba No. 9






4. Dar clic en Regresar y se declina la transacción.

5. Se regresa a la pantalla anterior.


Captura de Pantalla



Revisado por:



Prueba No. 10






4. La hora de semana es proporcionado por la materia (MALLA).

5. La disponibilidad del docente es proporcionada por el módulo de personas.

6. Verificar que la selección sea en base a las horas que nos indican, caso contrario mostrará mensajes de error (Horario fuera del límite permitido).

7. Al dar clic en añadir teniendo en consideración lo mencionado se grabará los datos sin generar errores.


Captura de Pantalla



Revisado por:



Prueba No. 11






4. Validado los datos anteriores se procede a la selección del espacio físico.

5. El sistema da la oportunidad de escoger el aula para la materia en un espacio físico determinado o en varios, por tal motivo la asignación del aula se la realiza una a una.

6. Dar clic en Añadir y grabar los datos.


Captura de Pantalla



Revisado por:



Prueba No. 12






4. Dar clic en Regresar y se declina lo realizado.

5. Regresa a la pantalla anterior.


Captura de Pantalla



Revisado por:



Prueba No. 13






4. Verificar que los datos que se ha generado a lo largo de este proceso sean los que están plasmados en el horario de nuestro sistema.

5. Se presenta dos horarios, el primero es de las materias y el segundo es de las aulas asignadas para las clases.


Captura de Pantalla



Revisado por:



Prueba No. 14






4. Para Finalizar el proceso debemos dar clic en Guardar y todos los horarios generados se guardan para el registro oficial.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_HORARIO_CARGA_HORARIA _DOCENTE_V1.0

Prueba No. 1

Descripción prueba Horario > Carga Horaria > Horario Docente

Pre-requisitos Usuario debe iniciar sesión con perfil de coordinador o docente.



3. Navegar en: Horario > Carga horaria docente.

4. Al ingresar al sistema se reconoce el perfil del docente y muestra automáticamente las materias del docente.

5. Verificar que el horario de clases que se muestra sea el correcto.


Captura de Pantalla



Revisado por:



Prueba No. 2







5. Verificar que las materias asignadas sean las correctas.


Captura de Pantalla



Revisado por:



Prueba No. 3







5. Verificar que los paralelos asignados sean los correctos.


Captura de Pantalla



Revisado por:



Prueba No. 4







5. Verificar que las aulas asignados sean las correctas.


Captura de Pantalla



Revisado por:



Prueba No. 5






4. Se muestra el horario solo visual en la pantalla del sistema.

5. Para imprimir el archivo PDF dar clic en Descargar HORARIO.

6. Abrir archivo descargado.

7. Dar clic en imprimir.

8. Procesos completo.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_HORARIO_CARGA_HORARIA _EXAMEN_PARCIAL_V1.0

Prueba No. 1

Descripción prueba Horario > Carga Horaria > Examen Parcial




3. Navegar en: Horario > Carga horaria > Examen parcial.

4. Del menú presente, escoger la opción de Horario examen parcial.

5. Verificar que se despliegue otra pantalla y no muestre errores o se cicle en la misma opción.


Captura de Pantalla



Revisado por:



Prueba No. 2






4. Verificar combos de fechas estén generando fechas correctas.

5. Verificar criterios de ingresos de fechas (rango).


Captura de Pantalla



Revisado por:



Prueba No. 3






4. Verificar lista de Paralelos que se despliegan.

5. Verificar que no se reflejen paralelos no asignados al semestre.


Captura de Pantalla



Revisado por:



Prueba No. 4






4. Dar clic en el botón continuar para empezar el proceso de horarios examen parcial.


Captura de Pantalla



Revisado por:



Prueba No. 5






4. Dar clic en el botón cancelar y declina la solicitud, regresa a la pantalla anterior.

5. Verificar que mensajes de alerta se estén generando.


Captura de Pantalla



Revisado por:



Prueba No. 6






4. Verificar las materias sean las correctas de acuerdo al semestre que se ha seleccionado.

5. Dar doble clic en el Semestre que desea generar horario de examen parcial.


Captura de Pantalla



Revisado por:



Prueba No. 7






4. Seleccionar en donde se vaya a tomar el examen con su fecha y hora respectiva.

5. Verificar que no permita la selección de datos erróneos.

6. Las opciones deben ser validadas por lo establecido en los horarios de clases.

7. Dar clic en botón Añadir.


Captura de Pantalla



Revisado por:



Prueba No. 8






4. Dar clic en botón Regresar y declina la transacción retornando a la pantalla anterior.


Captura de Pantalla



Revisado por:



Prueba No. 9






4. Validados los datos anteriores, procedemos a la selección de las aulas en donde se vayan a tomar e o lo exámenes.

5. Dar clic en Añadir y guardar los datos.


Captura de Pantalla



Revisado por:



Prueba No. 10






4. Dar clic en botón Regresar y declina la realizado.



Captura de Pantalla



Revisado por:



Prueba No. 11






4. Verificar que los datos ingresados sean los correctos, a lo largo de este procesos la generación tiene que estar acorde a las mismas materias del horario de clases del semestre escogido.

5. Verificar los dos horarios, el primero refleja las materias y el segundo las aulas en donde se tomarán los exámenes.


Captura de Pantalla



Revisado por:



Prueba No. 12






4. Para finalizar el proceso de creación de horario de examen parcial, se debe dar clic en el botón guardar y todos los procesos realizados se guardarán automáticamente.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_HORARIO_CARGA_HORARIA _EXAMEN_PARCIAL_RECUPERACION_V1.0

Prueba No. 1

Descripción prueba Horario > Carga Horaria > Examen Parcial Recuperación




3. Navegar en: Horario > Carga horaria > Examen parcial recuperación.

4. Del menú presente, escoger la opción de Horario examen parcial recuperación.

5. Verificar que se despliegue otra pantalla y no muestre errores o se cicle en la misma opción.


Captura de Pantalla



Revisado por:



Prueba No. 2






4. Verificar combos de fechas estén generando fechas correctas.

5. Verificar criterios de ingresos de fechas (rango).


Captura de Pantalla



Revisado por:



Prueba No. 3






4. Verificar lista de Paralelos que se despliegan.

5. Verificar que no se reflejen paralelos no asignados al semestre.


Captura de Pantalla



Revisado por:



Prueba No. 4






4. Dar clic en el botón continuar para empezar el proceso de horarios examen parcial.


Captura de Pantalla



Revisado por:



Prueba No. 5






4. Dar clic en el botón cancelar y declina la solicitud, regresa a la pantalla anterior.

5. Verificar que mensajes de alerta se estén generando.


Captura de Pantalla



Revisado por:



Prueba No. 6






4. Verificar las materias sean las correctas de acuerdo al semestre que se ha seleccionado.

5. Dar doble clic en el Semestre que desea generar horario de examen parcial.


Captura de Pantalla



Revisado por:



Prueba No. 7






4. Seleccionar en donde se vaya a tomar el examen con su fecha y hora respectiva.

5. Verificar que no permita la selección de datos erróneos.

6. Las opciones deben ser validadas por lo establecido en los horarios de clases.



Captura de Pantalla



Revisado por:



Prueba No. 8






4. Dar clic en botón Regresar y declina la transacción retornando a la pantalla anterior.


Captura de Pantalla



Revisado por:



Prueba No. 9






4. Validados los datos anteriores, procedemos a la selección de las aulas en donde se vayan a tomar e o lo exámenes.

5. Dar clic en Añadir y guardar los datos.


Captura de Pantalla



Revisado por:



Prueba No. 10






4. Dar clic en botón Regresar y declina la realizado.



Captura de Pantalla



Revisado por:



Prueba No. 11






4. Verificar que los datos ingresados sean los correctos, a lo largo de este procesos la generación tiene que estar acorde a las mismas materias del horario de clases del semestre escogido.

5. Verificar los dos horarios, el primero refleja las materias y el segundo las aulas en donde se tomarán los exámenes.


Captura de Pantalla



Revisado por:



Prueba No. 12






4. Para finalizar el proceso de creación de horario de examen parcial, se debe dar clic en el botón guardar y todos los procesos realizados se guardarán automáticamente.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_JORNADA_ACADEMICA _V1.0

Prueba No. 1

Descripción prueba Horario > Jornada Académica




3. Navegar en: Jornada Académica.

4. Seleccionar datos de combo.

5. Verificar que los días de la semana estén todos considerados.

6. Verificar correcta generación de combos de horas.


Captura de Pantalla



Revisado por:



Prueba No. 2






4. Verificar que check option estén habilitados para poder seleccionar todos o varios días.


Captura de Pantalla



Revisado por:



Prueba No. 3






4. Verificar que los combos estén almacenando todas las horas del día (distribución en intervalo de 1 hora).


Captura de Pantalla



Revisado por:



Prueba No. 4






4. Seleccionar día y hora para su correcto ingreso y establecer la jornada académica.


Captura de Pantalla



Revisado por:



Prueba No. 5






4. Botón Editar, deshabilitado.

5. Solo debe estar habilitado para la opción de modificación.


Captura de Pantalla



Revisado por:



Prueba No. 6







5. Se guarda exitosamente los datos ingresados.


Captura de Pantalla



Revisado por:



Prueba No. 7






4. Dar clic en botón Ignorar.

5. Se declina de los cambios realizados y regresa al menú principal.


Captura de Pantalla



Revisado por:



Prueba No. 8






4. Verificar que esté establecida las 3 jornadas regulares.

5. Se debe repetir el proceso para cada jornada y validar funcionalidad.


Captura de Pantalla



Revisado por:



Prueba No. 9

Descripción prueba Horario > Jornada Académica > Consultar





4. Dar doble clic en la Jornada que desea modificar.

5. Dar clic en continuar y visualizar datos.


Captura de Pantalla



Revisado por:



Prueba No. 10

Descripción prueba Horario > Jornada Académica > Consultar





4. Dar doble clic en Cancelar y se retira de la pantalla

5. Regresa al menú principal


Captura de Pantalla



Revisado por:



Prueba No. 11

Descripción prueba Horario > Jornada Académica > Modificar





4. Verificar la lista de los períodos creados y seleccionar e o los que desea modificar.

5. Se debe abrir una ventana nueva.


Captura de Pantalla



Revisado por:



Prueba No. 12






4. Se verifica que la pantalla que refleja es la del menú principal de jornada.

5. Modificar los datos requeridos.


7. Datos almacenados correctamente.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_PARALELOS_GENERAR _V1.0

Prueba No. 1

Descripción prueba Horario > Paralelo




3. Navegar en: Paralelo.

4. Verificar combos estén correctamente con la información que se necesita para la generación de los paralelos.

5. Escoger Período activo.

6. Ingresar datos numéricos en capacidad, verificar validación de criterios de entrada.

7. Verificar que se carguen los semestres correspondientes a la Carrera.


Captura de Pantalla



Revisado por:



Prueba No. 2






4. Dar clic en Generar Paralelo.

5. Verificar que se despliegue un menú nuevo para la generación.


Captura de Pantalla



Revisado por:



Prueba No. 3






4. Dar clic en Cancelar.

5. Declina lo realizado y regresa a la pantalla principal.


Captura de Pantalla



Revisado por:



Prueba No. 4






4. Ingresar cantidad de paralelos a crear.

5. Verificar que solo se puedan ingresar datos numéricos.



Captura de Pantalla



Revisado por:



Prueba No. 5






4. Verificar que los paralelos que se desplieguen según el requerimiento ingresado previamente sean los correctos.

5. Verificar secuencia de los paralelos.

6. Verificar los combos posean información real y correcta.


Captura de Pantalla



Revisado por:



Prueba No. 6






4. Estado inhabilitado.

5. En la generación el estado debe estar siempre activo, en la modificación se activa el campo.


Captura de Pantalla



Revisado por:



Prueba No. 7







5. Se grabó exitosamente los datos generados.


Captura de Pantalla



Revisado por:



Prueba No. 8






4. Generados los datos podemos visualizarlos.

5. Ir a Lista de Paralelos.


Captura de Pantalla



Revisado por:



Prueba No. 9






4. Dar clic en Regresar.

5. Declina todo lo realizado y regresa a la pantalla principal de Paralelos.


Captura de Pantalla



Revisado por:



Prueba No. 10

Descripción prueba Horario > Paralelo > Consultar





4. En el menú principal tenemos un botón que nos da la opción de consultar sin criterios de búsqueda.

5. Dar clic en el botón consultar.

6. Revisar lista de Paralelos.


Captura de Pantalla



Revisado por:



Prueba No. 11

Descripción prueba Horario > Paralelo > Modificar





4. Revisar la lista de paralelos y escoger la opción a modificar.

5. Dar doble clic en el campo que deseas modificar.

6. Se despliega una nueva ventana con los datos actuales.


Captura de Pantalla



Revisado por:



Prueba No. 12






4. Modificar los campos necesarios o requeridos.

5. Verificar los criterios de ingreso de datos.

6. Verificar que los combos contengan la información requerida y correcta para el cambio.

7. En este caso se puede cambiar el estado porque no es una generación.


Captura de Pantalla



Revisado por:



Prueba No. 13







5. Los cambios han sido modificados exitosamente.


Captura de Pantalla



Revisado por:



Prueba No. 14






4. Dar clic en Regresar.

5. Descarta los cambios y regresa a la pantalla de consulta.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_PARALELOS_PROYECCION _V1.0

Prueba No. 1

Descripción prueba Horario > Paralelo > Proyectar





4. Dar clic en Proyectar grupo de paralelos

5. Verificar que los combos estén cargados con la información correspondiente.

6. Verificar que los OptionButton funciones correctamente.


Captura de Pantalla



Revisado por:



Prueba No. 2






4. Escoger opción Proyección espejo

5. Dar clic en Generar

6. Verificar lista generada.

7. Se creará la misma cantidad de paralelos del semestre pasado.

8. Criterio de validación para soporte, el listado del semestre anterior.


Captura de Pantalla



Revisado por:



Prueba No. 3






4. Escoger la opción proyectar por asignatura.


6. Visualizar nueva pantalla que muestra la proyección factible a realizar para los paralelos.

7. Se considera los criterios del historial, el máximo en los cupos para la generación de los paralelos.

8. Dar clic en Generar

9. Los Paralelos se han creado exitosamente.


Captura de Pantalla



Revisado por:



Prueba No. 4






4. Dar clic en Limpiar.

5. Los cambios se descartan y regresa a la pantalla anterior.


Captura de Pantalla



Revisado por:



Prueba No. 5







5. Declina lo realizado y regresa al menú principal.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_PERIODO_CARRERA _V1.0

Prueba No. 1

Descripción prueba Horario > Período Carrera




3. Navegar en: Período Carrera.

4. Verificar estructura de la pantalla y que las etiquetas estén elaboradas correctamente.

5. Verificar funcionalidad de los botones de esconder la pantalla que se estas utilizando.


Captura de Pantalla



Revisado por:



Prueba No. 2






4. Seleccionar de los combo los datos que desea ingresar al sistema.

5. Verificar que todos los combos estén cargados de información propia de la Carrera.


Captura de Pantalla



Revisado por:



Prueba No. 3






4. Seleccionar de los combo los datos que desea ingresar al sistema.

5. Verificar que todos los combos estén cargados de información propia de la Carrera.


Captura de Pantalla



Revisado por:



Prueba No. 4






4. Ingresar el Ciclo que se vaya a crear.

5. Por las leyes actuales solo se permite dos periodos.


Captura de Pantalla



Revisado por:



Prueba No. 5






4. Ingrese fecha de inicio y fin de la Carrera.

5. Verificar criterios de selección de fecha.

6. Se valida las selección de fechas.


Captura de Pantalla



Revisado por:



Prueba No. 6






4. Ingrese fecha de inicio y fin de matriculación




Captura de Pantalla



Revisado por:



Prueba No. 7






4. Ingrese fecha de inicio y fin de matriculación extra ordinaria.




Captura de Pantalla



Revisado por:



Prueba No. 8






4. Ingrese fecha de inicio y fin de prórroga.




Captura de Pantalla



Revisado por:



Prueba No. 9






4. Caja texto deshabilita para almacenar datos generados por el sistema l momento de confirmar la operación..


Captura de Pantalla



Revisado por:



Prueba No. 10






4. El campo estado está deshabilitado.

5. Se debe validar en el primer ingreso de los datos o inhabilitarlos.


Captura de Pantalla



Revisado por:



Prueba No. 11






4. Dar clic en guardar.

5. Si los datos cumplen con el parámetro se almacena en las tablas.


Captura de Pantalla



Revisado por:



Prueba No. 12






4. Dar clic en Ignorar

5. Se declina lo realizado y regresa a la pantalla principal.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_PERIODO_LECTIVO _V1.0

Prueba No. 1

Descripción prueba Horario > Periodo Lectivo




3. Navegar en: Periodo Lectivo.

4. Visualizar pantalla y verificar que los campos estén correctamente estructurados.

5. Revisar botón de esconder pantalla


Captura de Pantalla



Revisado por:



Prueba No. 2






4. Ingresar los datos respectivos en las cajas de texto.

5. Verificar criterios de ingresos para evitar errores.


Captura de Pantalla



Revisado por:



Prueba No. 3






4. Verificar que se puedan establecer rangos de fechas reales y no muy extenso.

5. Validar fecha caducidad automática


Captura de Pantalla



Revisado por:



Prueba No. 4





3. Navegar en Período.

4. Ingrese rangos de fechas con los calendarios predeterminados.

5. Validar rango de fechas por medio del sistema.


Captura de Pantalla



Revisado por:



Prueba No. 5






4. Caja de textos deshabilitadas.

5. Verificar que los textos ya definidos sean correctos, según leyenda establecida.

6. Verificar rangos de fechas generados automáticamente sean correctos,


Captura de Pantalla



Revisado por:



Prueba No. 6






4. Caja de textos del estado deshabilitada.

5. El estado en la generación debe ser obligatoriamente activo.


Captura de Pantalla



Revisado por:



Prueba No. 7







5. Los datos se han cargado exitosamente


Captura de Pantalla



Revisado por:



Prueba No. 8







5. Declina lo realizado y se regresa a la primera pantalla.


Captura de Pantalla



Revisado por:



Prueba No. 9





3. Navegar en Período > Consultar.

4. Ingresar parámetros de búsqueda.

5. Verificar criterios de ingreso de los datos.


Captura de Pantalla



Revisado por:



Prueba No. 10





3. Navegar en Período > Consultar.

4. Verificar lista de Períodos consultadas.


Captura de Pantalla



Revisado por:



Prueba No. 11





3. Navegar en Período > Modificar.

4. Luego de consultar la lista, dar doble clic en el período que desea modificar.


Captura de Pantalla



Revisado por:



Prueba No. 12






4. Dar clic en el botón cancelar.

5. Declina lo realizado y regresa a la pantalla anterior.


Captura de Pantalla



Revisado por:



Prueba No. 13






4. Refleja la primera pantalla y se muestra habilitados los campos para ser modificados.

5. Verificar criterios de ingresos a cada campo.


Captura de Pantalla



Revisado por:



Prueba No. 14






4. Dar clic en botón guardar.

5. Los cambios se han guardado exitosamente.


Captura de Pantalla



Revisado por:


PRUEBA UNITARIA

Código CP_PLANIFICACION_CLASES _V1.0

Prueba No. 1

Descripción prueba Horario > Planificación




3. Navegar en: Planificación.

4. Se debe verificar la interfaz gráfica y determinar si los datos que se reflejan son los correctos, acorde a los días de la semana y demás información presente.


Captura de Pantalla



Revisado por:



Prueba No. 2






4. Pa ingresar un evento en el calendario se debe dar doble clic en el día de creación.

5. Se abrirá una nueva ventana.

6. Los datos ingresados deberán reflejarse en la pantalla de la misma forma que lo ingreso el administrador.


Captura de Pantalla



Revisado por:



Prueba No. 3






4. Se debe ingresa los campos requeridos para completar el formulario de tírulo.

5. Verificar criterio de ingreso.

6. Ingresar datos alfanuméricos sin caracteres.


Captura de Pantalla



Revisado por:



Prueba No. 4






4. Se debe ingresa los campos requeridos para completar el formulario de contenido.

5. Verificar criterio de ingreso.

6. Ingresar datos alfanuméricos sin caracteres.


Captura de Pantalla



Revisado por:



Prueba No. 5






4. Escoger los datos que se muestran en el combo evento.

5. Se puede especificar si los ámbitos son locales, nacionales.

6. El campo anterior determina que se puede especificar actividades por Facultades.


Captura de Pantalla



Revisado por:



Prueba No. 6






4. Verificar que el combo categoría contenga datos.

5. Se determina el campo categoría para que se pueda personalizar evento entre las Facultades o a nivel interno en las Carreras.


Captura de Pantalla



Revisado por:



Prueba No. 7






4. Dar clic en botón Crear.

5. Se guarda con éxito la información.


Captura de Pantalla



Revisado por:



Prueba No. 8






4. Dar clic en botón Eliminar.

5. Se borrará algún evento que ha criterio del administrador tenga que ser eliminado del calendario.


Captura de Pantalla



Revisado por:



Prueba No. 9






4. Dar clic en botón Cancelar.

5. Se descarta todo lo ingresa en la pantalla de eventos y regresa a la pagina principal.


Captura de Pantalla



Revisado por:



Prueba No. 10






4. Visualizar actividades creadas por día

5. Dar clic en botón día.


Captura de Pantalla



Revisado por:



Prueba No. 11






4. Visualizar actividades creadas por semana

5. Dar clic en botón semana.


Captura de Pantalla



Revisado por:



Prueba No. 12






4. Visualizar actividades creadas por meses

5. Dar clic en botón meses.


Captura de Pantalla



Revisado por:



Prueba No. 13






4. Se desplaza el evento creado.

5. Dar un clic en el evento que se quiera desplazar y se lo arrastra al día o la fecha deseada..


Captura de Pantalla



Revisado por:



Prueba No. 14

Descripción prueba Horario > Planificación > Modificación




3. Navegar en: Planificación > Modificación.

4. Dar doble clic en el evento que se desea modificar

5. Se muestra una pantalla nueva.


Captura de Pantalla



Revisado por:



Prueba No. 15

Descripción prueba Horario > Planificación > Modificación




3. Navegar en: Planificación > Modificación.

4. Llenar los campos requeridos en las cajas de texto.

5. Verificar datos de ingresos, se debe manejar criterios de texto.

6. Dar clic en Crear.

7. Datos guardados exitosamente.


Captura de Pantalla


Elaborado por: Fernando

Revisado por:

Aprobado por:

Código CP_M

Prueba No. 1

Descripciónprueba Asiste

Pre-requisitos Usua

Procedimiento 1.

2.

3.

4.

5.

Observaciones •

Captura de Pantalla

Resultado Exito

o Abraham Mendoza Orrala

Fecha:

PRUEBA UNITARIA

_MENU_ASISTENCIA_INGRESO_ASISTENCIA_PRINCIP

tencia > Ingreso Asistencia > Clic Botón Guardar

ario debe iniciar sesión con perfil de docente.

Ingreso al sistema con la clave y contraseña de acceso.

Elegir Universidad > Facultad > Carrera.

Navegar en: Asistencia > Ingreso Asistencia.

Clic en el botón Guardar.

La acción no procede botón esta deshabilitado.

ASIGNADO A REPORTERÍA

tosa Fallida No aplica

IPAL_V1.0


Revisado por:

Aprobado por:

Código CP_M

Prueba No. 2


Pre-requisitos Usua

Procedimiento 1.

2.

3.

4.

5.

Observaciones •

Captura de Pantalla

Resultado Exito


Fecha:

PRUEBA UNITARIA


tencia > Ingreso Asistencia > Clic Botón Buscar





Clic en el botón Buscar.

Se solicita el ingreso de campos obligatorios (paralelo).


IPAL_V1.0


Revisado por:

Aprobado por:

Código CP_M

Prueba No. 3


Pre-requisitos Usua

Procedimiento 1.

2.

3.

4.

5.

Observaciones •

Captura de Pantalla

Resultado Exito


Fecha:

PRUEBA UNITARIA


tencia > Ingreso Asistencia > Clic Botón Cancelar





Clic en el botón Cancelar.

No se realiza acción botón deshabilitado antes de hacer bú


IPAL_V1.0

búsqueda.


Revisado por:

Aprobado por:

Código CP_M

Prueba No. 4


Pre-requisitos Usua

Procedimiento 1.

2.

3.

4.

Observaciones •

Captura de Pantalla

Resultado Exito


Fecha:

PRUEBA INTERFAZ GRAFICA


tencia > Ingreso Asistencia





Navegar con el botón TAB


IPAL_V1.0

PRUEBAS DEL SISTEMA DE GESTION ACADEMICA PARA LA UNIVERSIDAD DE GUAYAQUIL


Revisado por: Ángel Burgos

Aprobado por: Ing. Bernardo Iñiguez Fecha: 05 de Febrero del 2015

PRUEBAS UNITARIAS DEL SISTEMA ACADEMICO V1.0

Código CP_CU_CARGA_HORARIA_V1.0_PCARGAHORARIA

Prueba No. 1

Descripción prueba Horarios, carga horaria, nuevo, horario de clases

Pre-requisitos Usuario debe iniciar sesión con permisos de administrador

Procedimiento 1. Ingreso de la clave y contraseña para el acceso

2. Elegir Carrera de Ing. En Sistemas Computacionales

3. Navegar en Horario - Carga horaria

4. Ingresar a la pantalla de Carga Horaria ir creación

5. Dar clic en Nuevo

6. Dar clic en Horario de clase

7. Completar los datos requeridos


Observaciones • Al dar clic en guardar no muestra interfaz gráfica ni mensaje de erros, no se puede verificar si el proceso estuvo correcto o se debería de mostrar una pantalla consecuente a la acción realizada.

Captura de Pantalla







Prueba No. 2

Descripción prueba Horarios, carga horaria, nuevo, horario de clases, campos vacíos.







6. Dar clic en Horario de clase



Observaciones • Se muestra mensaje de error, indicando que los campos a llenar son obligatorios y no permite seguir con la operación.

Captura de Pantalla







Prueba No. 3

Descripción prueba Horarios, carga horaria, nuevo, horario de examen parcial







6. Dar clic en Horario de examen parcial



Observaciones • Nos muestra el mensaje de error: “No existen horarios disponibles”.

• Es correcto el mensaje, en la pantalla anterior se muestra que no se pudo ingresar horarios de clases por ende no permite el ingreso de horario de exámenes.

Captura de Pantalla







Prueba No. 4

Descripción prueba Horarios, carga horaria, nuevo, horario de examen parcial, campos vacíos.







6. Dar clic en Horario de examen parcial




Captura de Pantalla







Prueba No. 5

Descripción prueba Horarios, carga horaria, nuevo, horario de examen de recuperación







6. Dar clic en Horario de examen de recuperación



Observaciones • Nos muestra el mensaje de error: “No existen horarios disponibles”.

• Es correcto el mensaje, en la pantalla anterior se muestra que no se pudo ingresar horarios de clases por ende no permite el ingreso de horario de exámenes.

Captura de Pantalla







Prueba No. 6

Descripción prueba Horarios, carga horaria, nuevo, horario de examen de recuperación, campos vacíos.







6. Dar clic en Horario de examen de recuperación




Captura de Pantalla







Prueba No. 7

Descripción prueba Horarios, carga horaria, guardar.





12. Ingresar a la pantalla de guardar

13. Dar clic en Aceptar dentro del diálogo que se abre en un cuadro

14. Verificar mensaje de alerta.

Observaciones • No muestra alertas ni interfaz gráfica en esta opción, no se puede verificar la continuidad de las pantallas.

Captura de Pantalla







Código CP_CU_HORARIO_CREA_AULA_V1.0_PAULA

Prueba No. 1

Descripción prueba Horarios, creación de aula



2. Elegir Carrera de Ing. En Sistemas Computacionales.

3. Navegar en Horario - Aula

4. Ingresar a la pantalla de Aula y proceder a llenar los campos respectivos.

5. Realizar la creación dando clic en el botón guardar.

6. Asigna a la tabla el aula creada exitosamente.

Observaciones • Se muestra el mensaje: “Proceso ejecutado correctamente”.

Captura de Pantalla







Prueba No. 2

Descripción prueba Horarios, creación de aula duplicada







6. Se muestra mensaje de alerta.

Observaciones • Se muestra mensaje al usuario indicando “El aula que desea ingresar ya existe. Favor nuevo código de aula”.

Captura de Pantalla







Prueba No. 3

Descripción prueba Horarios, creación de aula exceso de estudiantes





4. Ingresar a la pantalla de Aula y proceder a llenar los campos respectivos y considerar exceder el número de estudiantes por aula.


6. Se muestra mensaje de alerta o confirmación.

Observaciones • Se muestra mensaje al usuario indicando “Proceso ejecutado correctamente”

• Se muestran el indicador (flecha roja).

o No debería de permitir ingresar tal magnitud de estudiantes.

o En este caso se debería de consultar con la parte legal cuál es el cupo establecido por el reglamento de educación superior.

o Esta acción debe de ser consecuente con la parte de creación de Laboratorios ya que el mismo curso que se ha creado asistirá en la misma cantidad de estudiantes.

Captura de Pantalla







Prueba No. 4

Descripción prueba Horarios, inactivar aula





4. Ingresar a la pantalla de Aula y consultar la tabla de las aulas creadas.

5. Seleccionar el aula a modificar y en estado colocar inactivo.

6. Se debe mostrar lo selecciona en la tabla de las aulas creadas.

Observaciones • Se muestra mensaje al usuario indicando “Proceso ejecutado correctamente”.

• El aula modificada ya no la puedes visualizar en la lista existente y no contamos con un botón para poder consultar todas las aulas que hayan sido desactivadas por el administrador.

Captura de Pantalla







Prueba No. 5

Descripción prueba Horarios, escoja edificio





4. Ingresar a la pantalla de Aula y consultar los edificios opcionales.

Observaciones • Se muestra más de una opción necesaria en el área de edificios.

• La Carrera de Ingeniería en Sistemas solo cuenta con el espacio físico del antiguo colegio María Auxiliadora, los demás datos que se presentan deberían ser ocultos para y ser mostrado a las Carreras correspondientes, para evitar confusión o un acción fortuita del usuario al escoger las alternativas.

Captura de Pantalla







Prueba No. 6

Descripción prueba Horarios, ingesar datos no numéricos capacidad aula





4. Ingresar a la pantalla de Aula e ingresar los datos requeridos por el sistema, considerar ingresar datos no numéricos.

5. Debe mostrar mensaje de alerta con respecto a la acción errónea.

Observaciones • Se muestra el mensaje: “Se debe especificar un dato entero, no “**”, en el caso de ingresar un número negativo muestra: “solo se puede ingresar números positivos” ”.

Captura de Pantalla







Prueba No. 7

Descripción prueba Horarios, ingresar código de aula





4. Ingresar a la pantalla de Aula e ingresar el código que se establecerá para el aula nueva, considerar ingresar datos no numéricos.

Observaciones • Al ingresar caracteres en el código de aula muestra el mensaje: “Solo se permite ingresar datos alfanuméricos”.

Captura de Pantalla







Prueba No. 8

Descripción prueba Horarios, ingesar código de aula no alfanumérico.





4. Ingresar a la pantalla de Aula e ingresar los datos requeridos por el sistema, considerar ingresar datos no numéricos.

Observaciones • No muestra mensaje de alerta en código aula, debe de mostrar al igual que en la capacidad del aula, se debería evitar que el usuario siga completando el formulario hasta que no corrija el error.

Captura de Pantalla







Prueba No. 9

Descripción prueba Horarios, codificación de aula.





4. Ingresa los datos requeridos del formulario.


6. Revisar las aulas creadas en la lista existente.

Observaciones • Se debe revisar la codificación que se está generando, los números asignados han sido establecidos de forma errónea. Aula de primer piso (3), aula de segundo piso (2), aula de tercer piso (1), aula de cuarto piso (9). Los códigos deben de ser consecuentes a los pisos y deben ser generados en orden.

Captura de Pantalla







Prueba No. 10

Descripción prueba Horarios, creación de aula sin ingresar datos







6. Verificar mensajes de alertas.

Observaciones • Se muestra los mensajes de alertas respectivos por cada uno de los campos vacíos: “Los campos son obligatorios de llenar o escoger”.

Captura de Pantalla







Código CP_CU_HORARIO_DOCENTE_V1.0_PHORARIODOCENTE

Prueba No. 1

Descripción prueba Horarios, horario docente




3. Navegar en Horario - Horario Docente

4. Ingresar a la pantalla de Horario Docente y navegar en el menú.

5. Verificar resultado de acción.

Observaciones • No existe interfaz gráfica.

• Al momento no contamos con caso de uso para esta pantalla, por tal motivo desconocemos los procesos y requerimientos de los involucrados.

• Este no es un caso de prueba, pero se documenta para dejar constancia de lo sucedido.

Captura de Pantalla






Código CP_CU_JORNADA_ACADEMICA_V1.0_PJORNADAACADEMICA

Prueba No. 1

Descripción prueba Horarios, Jornada nueva.




3. Navegar en Horario – Jornada Académica

4. Ingresar a la pantalla de Jornada Académica


Observaciones • Se muestra el mensaje: “Jornada es obligatorio”.

Captura de Pantalla






Prueba No. 2

Descripción prueba Horarios, Jornada nueva.






5. Seleccionar jornada matutina


Observaciones • Se muestra el mensaje: “Debe seleccionar al menos un día”. No le permite seguir navegando al usuario en el formulario.

Captura de Pantalla






Prueba No. 3

Descripción prueba Horarios, Jornada nueva duplicada







6. Selecciones Lunes


Observaciones • Se muestra el mensaje: “El o los días Lunes que selecciono ya tiene ingresada su jornada académica. No se guardarán los días mencionados”.

Captura de Pantalla






Prueba No. 4

Descripción prueba Horarios, Jornada nueva matutina, día sábado







6. Selecciones Sábado


Observaciones • Los horarios ya están establecidos en el sistema y no permite modificar para el día sábado donde los horarios son diferentes a los habituales.

Captura de Pantalla






Prueba No. 5

Descripción prueba Horarios, Jornada nueva tarde, día sábado






5. Seleccionar jornada tarde




Captura de Pantalla






Prueba No. 6

Descripción prueba Horarios, Jornada nueva nocturna, día sábado






5. Seleccionar jornada nocturna




Captura de Pantalla






Prueba No. 7

Descripción prueba Horarios, Jornada nueva matutino, intervalo de hora.






5. Seleccionar jornada matutino

6. Seleccione Lunes

7. Dar clic en editar.

Observaciones • Al querer editar los campos de intervalo de hora solo de habilita el estado y los horarios siguen deshabilitados. Revisar casos de uso para definir la necesidad de esta pantalla.

Captura de Pantalla






Prueba No. 8

Descripción prueba Horarios, Jornada nueva tarde, intervalo de hora.






5. Seleccionar jornada tarde

6. Seleccione Lunes



Captura de Pantalla






Prueba No. 9

Descripción prueba Horarios, Jornada nueva nocturno, intervalo de hora.






5. Seleccionar jornada nocturno

6. Seleccione Lunes



Captura de Pantalla






Prueba No. 10

Descripción prueba Horarios, Buscar jornada académica.






5. Ir Consulta de jornada académica

6. Seleccione Jornada Académica

7. Seleccione Día


Observaciones • Se muestra los datos seleccionados según el criterio ingresado.

Captura de Pantalla






Prueba No. 11

Descripción prueba Horarios,Consultar jornada.






5. Ir Consulta de jornada académica

6. Seleccione Jornada Académica

7. Seleccione Día

8. Dar doble clic sobre la jornada consultada

9. Dar clic en continuar.

Observaciones • Se debe revisar caso de uso para esta pantalla, al dar doble clic muestra mensaje de alerta para eliminar la jornada. Al dar clic en continuar la debería de eliminar pero aún sigue apareciendo en la lista de jornada.

Captura de Pantalla






Código CP_CU_PARALELO_V1.0_PPARALELO

Prueba No. 1

Descripción prueba Horarios, Ingreso paralelo nuevo.




3. Navegar en Horario – Paralelo

4. Ingresar a la pantalla de Paralelo y llene el formulario


Observaciones • NO se puede ingresar un paralelo, la información de período no está disponible.

Captura de Pantalla






Prueba No. 2

Descripción prueba Horarios, Ingreso paralelo nuevo datos vacíos.





4. Ingresar a la pantalla de Paralelo y llene el formulario


Observaciones • Se muestra el mensaje: “Los datos deben ser obligatorios”.

Captura de Pantalla






Prueba No. 3

Descripción prueba Horarios, Ingreso paralelo nuevo datos no numéricos y negativos.





4. Ingresar a la pantalla de Paralelo

5. Llenar Cupo con número negativo y no numérico

6. Llenar Aspirante con número negativo y no numérico

Observaciones • Se muestra los mensajes de alertas respectivos, obligando al usuario a cambiar lo ingresado y no dejando continuar navegando en el formulario.

Captura de Pantalla






Prueba No. 4

Descripción prueba Horarios, Proyección de Grupos.






5. Dar clic en proyección de grupos.

Observaciones • Se muestra el mensaje: “El Período de ciclo es obligatorio”.

• No se cuenta con la información de período, por tal motivo esta prueba esta desconocida, se la califica como fallida.

Captura de Pantalla






Prueba No. 5

Descripción prueba Horarios, Consultar Paralelo.







Observaciones • Se muestra el mensaje: “No se encontraron registros para el Paralelo a buscar”.

Captura de Pantalla






Prueba No. 6

Descripción prueba Horarios, Motivo de búsqueda.






5. Ir a lista de paralelo

6. Ingresar motivo de búsqueda datos no numéricos y número negativo.

Observaciones • No muestra mensaje de alerta al usuario y le permite seguir navegando en el formulario.

Captura de Pantalla






Código CP_CU_PERÍODO_CARRERA_V1.0_PPERÍODOCARRERA

Prueba No. 1

Descripción prueba Horarios, Ingreso de período y ciclo para la Carrera




3. Navegar en Horario – Período Carrera

4. Ingresar a la pantalla de Período Carrera, dejar los campos vacíos.


Observaciones • Se muestra mensaje: “Campos deben der obligatorios”.

Captura de Pantalla






Prueba No. 2

Descripción prueba Horarios, Ingreso de período y ciclo para la carrera.





4. Ingresar a la pantalla de Período Carrera y llenar los datos respectivos del formulario


Observaciones • No permite crear el período para la carrera porque no existen datos de períodos.

Captura de Pantalla






Prueba No. 3

Descripción prueba Horarios, Ingreso de período y ciclo para la carrera, Fecha inicio y Fecha fin





4. Ingresar a la pantalla de Período Carrera y escoger las fechas de inicio y fin

5. Verificar mensajes de alerta.

Observaciones • No se muestran mensajes de alerta y permite ingresar fechas con rangos mayores y menores a las actuales.

Captura de Pantalla






Prueba No. 4

Descripción prueba Horarios, Ingreso de período y ciclo para la carrera, Fecha inicio y Fecha fin Matricula.





4. Ingresar a la pantalla de Período Carrera y escoger las fechas de inicio y fin de Matricula



Captura de Pantalla






Prueba No. 5

Descripción prueba Horarios, Ingreso de período y ciclo para la carrera, Fecha inicio y Fecha fin Matricula Extraordinaria.





4. Ingresar a la pantalla de Período Carrera y escoger las fechas de inicio y fin de Matricula Extraordinaria



Captura de Pantalla






Prueba No. 6

Descripción prueba Horarios, Ingreso de período y ciclo para la carrera, Fecha Prorroga.





4. Ingresar a la pantalla de Período Carrera y escoger Fecha Prorroga



Captura de Pantalla






Prueba No. 7

Descripción prueba Horarios, Consultar ciclo por carrera.





4. Ingresar a la pantalla de Período Carrera

5. Ir Consultar período por ciclo

6. Dar doble clic en el ciclo a consultar

7. Dar clic en continuar


Captura de Pantalla






Prueba No. 8

Descripción prueba Horarios, Mostrar datos Consultados ciclo por carrera.






5. Ir Consultar período por ciclo

6. Dar doble clic en el ciclo a consultar

7. Dar clic en continuar

8. Verificar pantalla de consulta

Observaciones • Se muestra el mensaje: “La data proporcionado no se encuentra en el sistema”.

• No se pudo consultar en pantalla el período carrera que se encontraba en la lista de exitentes.

Captura de Pantalla






Prueba No. 9

Descripción prueba Horarios, Opción ESTADO.






5. Ir a Estado.

Observaciones • Se debería deshabilitar la opción de escoger obligatoriamente el estado y generarla automáticamente y a su vez desactivarla al final de cada período.

Captura de Pantalla






Prueba No. 10

Descripción prueba Horarios, Busqueda período por ciclo inactivos.






5. Ingresar a consultar período por ciclo


Observaciones • No podemos buscar períodos que hayan sido inactivados por el sistema o por el administrador.

Captura de Pantalla






Prueba No. 11

Descripción prueba Horarios, Busqueda período por ciclo.






5. Ingresar a consultar período por ciclo

6. Motivo de búsqueda datos no numéricos y números negativos.

Observaciones • No se muestra mensaje de alerta y deja continuar al usuario navegando en el formulario.

Captura de Pantalla






Código CP_CU_PERÍODO_V1.0_PPERÍODO

Prueba No. 1

Descripción prueba Horarios, Período nuevo




3. Navegar en Horario - Período

4. Ingresar a la pantalla de Período y llenar los datos respectivos para un período nuevo.


Observaciones • Se muestra mensaje: “Fallo al procesar script Unexpected token (SyntaxError)”.

Captura de Pantalla






Prueba No. 2

Descripción prueba Horarios, Modificar período.





4. Ingresar a la pantalla de Período y escoger un período activo.

5. Dar clic en continuar.

Observaciones • Si el cambio está dentro del rango de fecha un período existente no permite realizar el cambio.

Captura de Pantalla






Prueba No. 3

Descripción prueba Horarios, Rango de fechas período y año lectivo





4. Ingresar a la pantalla de Período y llenar los datos respectivos al período y año lectivo.

5. Verificar acción o acciones de alerta.

Observaciones • Permite ingresar rangos de fechas menores y mayores a la fecha actual.

• Se debería manejar mensajes de alertas en cada TEXT para evitar que el usuario siga normalmente con su procedimiento.

• Se debería inactivar automáticamente las fechas que ya han pasado para que el usuario no tenga opción de escogerlas.

Captura de Pantalla






Prueba No. 4

Descripción prueba Horarios, Fechas de inicio y fin de período.





4. Ingresar a la pantalla de Período y escoger fechas de inicio y fin de período.

5. Verificar acción o acciones de alerta.

Observaciones • Permite ingresar rangos de fechas menores y mayores a la fecha actual.

• Se debería manejar mensajes de alertas en cada COMBO para evitar que el usuario siga normalmente con su procedimiento.

• Se debería inactivar automáticamente las fechas que ya han pasado para que el usuario no tenga opción de escogerlas.

Captura de Pantalla






Prueba No. 5

Descripción prueba Horarios, Ingreso de período sin datos en formulario.





4. Ingresar a la pantalla de Período y llenar el formulario.

5. Dar clic e guardar.

Observaciones • Se muestra el mensaje: “Todos los campos deben ser obligatorios”.

Captura de Pantalla






Prueba No. 6

Descripción prueba Horarios, Ingreso datos no numéricos.





4. Ingresar a la pantalla de Período y llenar el formulario con datos no numéricos.

5. Verificar mensaje de acción.

Observaciones • Se muestra el mensaje: “Se debe especificar un número entero”, este mensaje se muestra siempre y cuando sean datos no numéricos.

Captura de Pantalla






Prueba No. 7

Descripción prueba Horarios, Ingreso datos negativos.





4. Ingresar a la pantalla de Período y llenar el formulario con datos negativos

5. Verificar mensaje de acción.

Observaciones • No muestra mensaje de alerta al usuario, por lo cual le permite continuar llenando el formulario y verificar el error al final de la transacción.

• Se debe considerar mostrar mensaje de alerta al igual que se lo muestra en los datos no numéricos.

Captura de Pantalla






Prueba No. 8

Descripción prueba Horarios, Estado período.





4. Ingresar a la pantalla de Período

5. Visualizar Estado se encuentra deshabilitado.

Observaciones • Esta opción debería estar oculta en la pantalla del usuario, para evitar confusión, se debería de generar automáticamente y al final del período transcurrido se desactivaría .

Captura de Pantalla






Prueba No. 9

Descripción prueba Horarios, Busqueda período.






5. Ir consulta período.

6. Dar clic en buscar

Observaciones • Se muestra mensaje: “No se encontraron registros para el período a buscar”.

Captura de Pantalla






Prueba No. 10

Descripción prueba Horarios, Busqueda período inactivo.






5. Ir consulta período.

6. Consultar opción diferente a activos.

Observaciones • No se puede consultar períodos inactivos o períodos pasados a la fecha actual.

Captura de Pantalla






Prueba No. 11

Descripción prueba Horarios, Período de fecha (inicio-fin) período.






5. Ir Inicio fecha período.

6. Ir Fin fecha período.

Observaciones • Permite ingresar fechas con rangos mayores a 6 meses, de debe consultar la parte legal y verificar en la Ley de Educación Superior cuales son los rangos que se permite para un período lectivo.

Captura de Pantalla






Código CP_CU_PLANIFICACION_CLASES_V1.0_PPLANIFICACIONCLASES

Prueba No. 1

Descripción prueba Horarios, Agregar evento.




3. Navegar en Horario – Planificación Clases

4. Ingresar a la pantalla de Planificación Clases y dar doble clic en el día del nuevo evento

5. Llenar el nuevo formulario que se muestra


Observaciones • Se muestra el mensaje: “Fallo al procesar script, error is not defined (ReferenceError)”.

Captura de Pantalla






Prueba No. 2

Descripción prueba Horarios, Agregar evento, datos no numéricos y números negativos.






5. Llenar el nuevo formulario que se muestra con datos erróneos.

Observaciones • Se muestra el mensaje para número negativo: “Ingrese un nombre correcto”.

• Se muestra el mensaje para no numérico: “Ingrese un nombre correcto”.

Captura de Pantalla






Prueba No. 3

Descripción prueba Horarios, Agregar evento, palabras tildadas.






5. Llenar el nuevo formulario que se muestra con palabras tildadas.

Observaciones • Se debería considerar corregir y permitir ingresar palabras tildadas.

Captura de Pantalla






Prueba No. 4

Descripción prueba Horarios, Visualizar calendario por día.





4. Ingresar a la pantalla de Planificación Clases

5. Dar clic en día.

Observaciones • Se muestra de forma correcta el ordenador por día.

Captura de Pantalla






Prueba No. 5

Descripción prueba Horarios, Visualizar calendario por semanas.






5. Dar clic en semanas.

Observaciones • Se muestra de forma correcta el ordenador por semanas.

Captura de Pantalla






Prueba No. 6

Descripción prueba Horarios, Visualizar calendario por mes.






5. Dar clic en mes.

Observaciones • Se muestra de forma correcta el ordenador por mes.

Captura de Pantalla







Código CP_CU_ASIGNACIÓN_AULA_V1.0_PASIGNACIÓNAULA

Prueba No. 1

Descripción prueba Horarios, asignación de aula jornada matutina




3. Navegar en Horario - Asignación de aula

4. Ingresar a la pantalla de Asignación de Aula y completar formulario

5. Escoger Jornada

6. Escoger Paralelo


Observaciones • No se puede completar la acción del formulario porque en paralelo no contiene información.

Captura de Pantalla







Prueba No. 2

Descripción prueba Horarios, asignación de aula jornada matutina, campos vacíos





4. Ingresar a la pantalla de Asignación de Aula y dejar vacío el formulario


Observaciones • Se muestra el mensaje de alerta: “Los campos deben ser obligatorios”.

• Además se muestra un segundo mensaje de error: “ZK Exception desconocida: java.lang.NullPointerException”.

Captura de Pantalla







Prueba No. 3

Descripción prueba Horarios, asignación de aula jornada tarde






5. Escoger Jornada

6. Escoger Paralelo



Captura de Pantalla







Prueba No. 4

Descripción prueba Horarios, asignación de aula jornada tarde, campos vacíos









Captura de Pantalla







Prueba No. 5

Descripción prueba Horarios, asignación de aula jornada nocturno






5. Escoger Jornada

6. Escoger Paralelo



Captura de Pantalla







Prueba No. 6

Descripción prueba Horarios, asignación de aula jornada tarde, campos vacíos









Captura de Pantalla


UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMATICAS …

Documents

Transcript of UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMATICAS …