Prototipo de Aplicación WEB Tipo Simulador para el Entrenamiento de Estudiantes en las Pruebas SABER PRO

(1)

Prototipo de aplicación web tipo simulador para el entrenamiento de estudiantes en

las pruebas SABER PRO

Proyecto de grado para optar por el título de Ingeniero de Sistemas

Alejandro Arévalo Vásquez

Lilian Astrid Bejarano Garzón

Directora

Universidad Distrital Francisco José de Caldas

Facultad de Ingeniería

Proyecto curricular de Ingeniería de Sistemas

Bogotá

(2)

TABLA DE CONTENIDO

INTRODUCCIÓN ... 4

PARTE I. CONTEXTUALIZACIÓN DE LA INVESTIGACIÓN ... 6

CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN ... 6

1.1 Planteamiento/Identificación del problema ... 6

1.2 Objetivos ... 10

1.2.1 Objetivo general ... 10

1.2.2 Objetivos específicos ... 10

1.3 Justificación de la investigación ... 11

1.3.1 Justificación teórica ... 11

1.3.2 Justificación metodológica ... 12

1.3.3 Justificación Práctica ... 13

1.4 Marco referencial ... 13

1.4.1 Marco Teórico ... 15

1.4.1.1 ICFES ... 15

1.4.1.2 Prueba SABER PRO ... 16

1.4.1.3 Competencias Ingeniero de Sistemas ... 18

1.4.2 Marco Conceptual ... 18

1.4.2.1 La plataforma Java ... 18

1.4.2.2 Modelo de datos y motor de implementación ... 20

1.4.2.3 Arquitectura Física de la aplicación ... 22

1.4.2.4 Arquitectura lógica de la aplicación ... 23

1.4.2.5 Tecnologías de soporte para la implementación ... 25

1.5 Metodología... 27

1.5.1 Tipo de estudio ... 27

1.5.2 Método de investigación ... 28

1.5.3 Fuentes y técnicas para la recolección de la información ... 28

(3)

1.5.5 Metodología de desarrollo en Ingeniería ... 29

PARTE II. DESARROLLO DE LA INVESTIGACIÓN ... 35

CAPÍTULO 2. DESCRIPCIÓN DEL DESARROLLO ... 35

2.1 Análisis de la solución ... 35

2.2.2.1 Diagramas de actividades ... 52

2.2.2.2 Diagramas de secuencia ... 56

PARTE III. CIERRE DE LA INVESTIGACIÓN ... 61

CAPÍTULO 3. RESULTADOS Y DISCUSIÓN ... 61

CAPÍTULO 4. CONCLUSIONES ... 61

4.1 Verificación, contraste y evaluación de los objetivos ... 61

4.2 Síntesis del modelo propuesto ... 62

4.3 Aportes originales ... 63

4.4 Trabajos o Publicaciones derivadas ... 63

CAPÍTULO 5. PROSPECTIVA DEL TRABAJO DE GRADO... 64

4.5 Líneas de investigación futuras ... 64

4.6 Trabajos de Investigación futuros ... 64

(4)

INTRODUCCIÓN

Según los lineamientos de la República de Colombia los requisitos legales establecidos en la Ley 842 de 2003 – artículo 7° para tener la tarjeta profesional y poder ejercer como Ingeniero en Sistemas son aquellos que: “… Hayan adquirido el título académico de Ingeniero en cualquiera de sus ramas, otorgado por Instituciones de Educación Superior oficialmente reconocidas, de acuerdo con las normas legales vigentes…” (Congreso de la República de Colombia, 2003), de tal manera que para recibir el título la Universidad Distrital Francisco José de Caldas ofrece como opción de grado desarrollar un Trabajo de Grado.

El trabajo de grado debe estar relacionado al perfil adquirido en la carrera, el cual es descrito por el Ministerio de Educación Nacional de Colombia (2007) indicando que:

Muchos se acercan a la carrera con el sueño de ser programadores web, pero lo cierto es que gracias a que las nuevas Tecnologías de la Información y la Comunicación (TIC) han permeado prácticamente todo el campo productivo, los ingenieros de sistemas también pueden crear complejos desarrollos con incidencia en el sector financiero, de la salud, productivo y de la educación… (MEN, 2007)

Es así como la investigación desarrollada como trabajo de grado impacta directamente al campo de la educación, ya que se evidenció una situación problemática y es la preparación extracurricular de los estudiantes de instituciones de educación superior para presentar las pruebas SABER PRO. En este sentido se espera contribuir con dicha preparación a partir de un aplicativo web, el cual, a partir de la presente investigación se presenta un prototipo de software que refuerce las habilidades requeridas por las pruebas en los aspirantes.

(5)

necesidad de hacer una preparación extracurricular que les permita a los estudiantes asistir con conocimientos recordados y competencias practicadas recientemente, para que puedan obtener mejores puntajes, lo que a su vez también favorece a la Universidad.

(6)

PARTE I. CONTEXTUALIZACIÓN DE LA INVESTIGACIÓN

CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN

1.1 Planteamiento/Identificación del problema

La investigación: “Prototipo de aplicación informática WEB con miras al entrenamiento para la presentación exitosa de la prueba SABER PRO de los estudiantes de Ingeniería de Sistemas de la UDFJC”, surge de la necesidad de aportar una nueva estrategia de entrenamiento de los estudiantes de Ingeniería de Sistemas para la presentación exitosa de la prueba SABER PRO, el cual fue una necesidad detectada a partir de la determinación de los siguientes datos:

Imagen # 1: Deducción del tema de investigación. Fuente: propia, 2016

A partir de la Imagen # 1 se puede precisar que en temas de resultados y Ranking la Universidad y en sí el Programa de Ingeniería de Sistemas hace 6 años que fueron el primer puesto en el Ranking nacional basado en los resultados de la Prueba SABER PRO; en este sentido cabe preguntarse ¿Qué sucedió a partir de ese año? ¿Por qué no se ha vuelto a obtener el primer lugar? ¿Cuál lugar en el Ranking se ha ocupado en el rango 2010 – 2015?

En el 2016 la Universidad se encuentra en la posición N° 201 a nivel Latinoamérica (Top Universities, s/f)

El resultado de la prueba SABER PRO en el 2010 ubica a la Universidad en el Puesto N° 21 a nivel Nacional (El Observatorio de la Universidad Colombiana, 2010)

En el 2010 un estudiante del Programa de Ingeniería de Sistemas obtuvo el mejor resultado de la Prueba en la Universidad. (El Observatorio de la Universidad Colombiana, s/f)

(7)

Realizando una investigación previa en la Universidad se pude detectar que en ese entonces existía un Comité en el programa de Ingeniería de Sistemas que apoyaba la preparación de los estudiantes. Al finalizar este comité se evidenció un descenso en los resultados.

Bien se sabe que una de las principales variables para medir a las Instituciones de Educación Superior (IES) son los resultados de la prueba SABER PRO es por ello que el área de interés de la presente investigación fue la preparación que tienen los estudiantes de Ingeniería de Sistemas de la Universidad Distrital para presentar esta prueba nacional. En este sentido se hizo una propuesta de cómo contribuir con dicha preparación.

Ahora bien, ¿desde la Ingeniería de Sistemas cómo se pudiera apoyar el entrenamiento de los estudiantes para obtener dichos conocimientos y competencias? A partir de un aplicativo WEB, cuyo prototipo inicial se desarrolló como producto principal de la presente investigación. Es allí donde se centró: en desarrollar un prototipo de un aplicativo con interfaz de usuario WEB que le permita a los estudiantes de Ingeniería de Sistemas de la Universidad Distrital entrenarse para presentar la prueba SABER PRO.

Una vez contextualizado la temática que gira entorno al objeto de estudio, ahora se procede a presentar el planteamiento del problema, dando un breve repaso al origen e historia del objeto de estudio.

En Colombia, surgió la necesidad de estandarizar, por así decirlo, los conocimientos y hoy en día las competencias que desarrollan todos los estudiantes en las Instituciones de Educación Superior (IES). Si bien es cierto que cada IES es autónoma en ciertos procesos, también es cierto que el Ministerio de Educación Nacional de Colombia (MEN), como ente regulador de todos los procesos educativos del país, debe garantizar que los profesionales egresados, independientemente de la Institución, cumplan con los estándares de calidad que la Nación ha establecido.

(8)

sociales y filosofía, química, física, biología e inglés” (MEN, s/f), cuyo propósito principal fue determinar cómo los futuros profesionales tenían el nivel básico de conocimiento como bases para la construcción de la sociedad colombiana.

El ICFES se presenta a sí mismo como una:

… entidad especializada en ofrecer servicios de evaluación de la educación en todos sus niveles, y en particular apoyar al Ministerio de Educación Nacional en la educativos, por lo que existen básicamente tres tipos de pruebas que aplica el ICFES:

Imagen # 2: Tipos de pruebas del ICFES. Fuente: ICFES, s/f

Cada una de estas pruebas tiene objetivos, temáticas y poblaciones distintas. Es por ello que se debe determinar cuál fue el objeto de estudio de la presente investigación. Es así como se afirma que se trabajó con la prueba SABER PRO, anteriormente llamada ECAES (Exámenes de Estado de Calidad de la Educación Superior) (CVNE, 2010) debido a que tiene como población los futuros profesionales que egresarán de las Instituciones de Educación Superior, el cual fue el caso vivenciado propiamente por el investigador.

El ICFES ha ido evolucionando desde su creación hasta llegar a tener la estructura, alcance, importancia y organización que hoy se conoce. Lo que quiere decir que desde la

(9)

primera prueba aplicada en 1968 hasta el presente han tenido un recorrido y han debido adaptarse a los cambios culturales, sociales, económicos y políticos del país, para poder garantizar que los ciudadanos colombianos van de la mano con estos. Hoy en día estas pruebas son un requisito nacional para poder obtener el título profesional deseado por cada ciudadano colombiano.

Este contexto ha traído consigo que las IES contemplen en sus planes de estudio contenidos que permitan el desarrollo de las competencias que hoy día se evalúan y se requieren por parte del MEN. También se han creado organizaciones privadas que prestan el servicio de capacitación para los estudiantes, de manera tal que se encuentren preparados adecuadamente para aprobar el requisito de la prueba.

Aun así, con toda esta estructura e influencia existen IES que distan en medida de lo exigido por el MEN, es por ello que cada año se obtienen estadísticas que permiten armar listados sobre las mejores y peores IES medidas por el conocimiento que tienen sus estudiantes.

Por tal motivo las IES hacen esfuerzos año tras año para mejorar la calidad de sus enseñanzas, de sus procesos y lograr ubicarse en los altos estándares de calidad oficiales. La Universidad Distrital Francisco José de Caldas no es una excepción.

Por lo que cabe preguntarse ¿lo estudiantes de Ingeniería de Sistemas de la Universidad Distrital Francisco José de Caldas están preparados adecuadamente para presentar su prueba SABER PRO en el 2016? ¿Cuáles son las estrategias que aplica la Universidad para apoyar y fortalecer este proceso de preparación de los estudiantes?

Tal como se mencionó en líneas anteriores, por medio de unas entrevistas realizadas en la Universidad Distrital, se conoció que hace unos años atrás en la Facultad de Ingeniería existía un comité liderado por docentes que buscaban capacitar, adicionalmente a sus planes de estudio, a los estudiantes que se enfrentaban a las pruebas SABER PRO. Se apoyaron en su aplicativo oficial CONDOR, sin embargo por razones desconocidas aún en la presente investigación, este comité finalizó sus labores.

(10)

la Universidad? ¿Cómo desarrollar una herramienta web que permita reforzar las competencias evaluadas en las pruebas SABER PRO?

A partir de entonces los estudiantes no cuentan con un apoyo adicional a guías que ofrece el ICFES para prepararse adecuadamente a las pruebas nacionales. De tal manera que se evidencie un vacío que se completó con el desarrollo de la presente investigación.

De tal manera surgió la idea de diseñar un prototipo de aplicación Web que pueda probarse y desarrollarse posteriormente para capacitar a los estudiantes de Ingeniería de Sistemas para presentar exitosamente las pruebas SABER PRO y así contribuir con el posicionamiento de la Universidad.

Finalmente la pregunta problema de investigación es:

¿Cómo desarrollar una herramienta informática WEB con miras al entrenamiento para la

presentación exitosa de la prueba SABER PRO de los estudiantes de Ingeniería de

Sistemas de la UDFJC?

1.2 Objetivos

1.2.1 Objetivo general

Construir un prototipo de aplicación WEB tipo simulador para el entrenamiento de estudiantes en las pruebas SABER PRO por medio de la metodología de desarrollo de software SCRUM.

1.2.2 Objetivos específicos

1.2.2.1 Identificar los conocimientos y las competencias que evalúa la

prueba SABER PRO para estudiantes de Ingeniería a partir de una revisión documental para incluir preguntas en el prototipo adecuadas a la población objeto de estudio.

1.2.2.2 Describir la estructura de las preguntas de la prueba SABER PRO

(11)

documental que oriente cómo construir el modelo de datos del prototipo WEB.

1.2.2.3 Ejecutar las fases de construcción de un prototipo de aplicación

WEB utilizando las técnicas de ingeniería de software para contribuir con el entrenamiento de los estudiantes.

1.3 Justificación de la investigación

1.3.1 Justificación teórica

Tal como se ha venido planteando en líneas anteriores, el Ministerio de Educación Nacional de Colombia a través del Instituto Colombiano para la Evaluación de la Educación, realiza unas pruebas anualmente con el fin de determinar la calidad de la educación que están recibiendo los estudiantes y así poder señalar si son competentes para continuar con el ciclo de formación subsiguiente.

En este contexto la presente investigación se centró en la prueba SABER PRO que presentan los futuros profesionales del país. Específicamente se trabajó en el programa de Ingeniería de Sistemas de la Universidad Distrital Francisco José de Caldas con los estudiantes próximos a presentar sus pruebas en el año 2016.

Teóricamente se precisó cuáles son los conocimientos y competencias que requieren tener estos estudiantes para aprobar de manera satisfactoria la prueba que realiza el ICFES y cómo se entrenan para presentar dichas pruebas. En consecuencia se conocieron aspectos tales como:

 ¿Qué evalúa el ICFES a los estudiantes de Ingeniería?

 ¿Cómo se entrenan los estudiantes para presentar la prueba SABER PRO?

 ¿Cómo un prototipo de aplicación informática WEB puede contribuir con el entrenamiento?

 ¿Cómo sería ese prototipo?

(12)

Esta información teórica que podrá apoyar a la Universidad para tomar acciones de mejora tanto en sus procesos como en sus planes de estudio que les permita garantizar que los estudiantes estén totalmente preparados para presentar la prueba SABER PRO. También podrán conocer cómo los estudiantes se preparan y cómo pueden apoyar ese proceso de preparación con el fin de ubicar a la universidad entre los primeros puestos en cuanto a los resultados nacionales.

Es por ello que se considera que esta investigación aportó conocimiento teórico que tanto la Universidad como los estudiantes podrán utilizar para mejorar los resultados de las pruebas SABER PRO en los siguientes años académicos.

1.3.2 Justificación metodológica

La metodología escogida para la presente investigación fue deductiva, mediante cual se estableció una consideración global, genérica, a partir de la cual se trabajó en el desarrollo de un prototipo de aplicativo móvil que permite, al finalizar, obtener información precisa y concreta.

De esta manera se procedió a:

a. Conocer la manera en que los estudiantes se entrenan para presentar la prueba SABER PRO.

b. Identificar los conocimientos y las competencias que se estipulan en la prueba y que se evalúan a los estudiantes de Ingeniería.

c. Desarrollar un prototipo de aplicativo WEB que contengan dichos conocimientos y competencias.

(13)

Se consideró viable dicha metodología puesto que se quiso demostrar, como futuro Ingeniero de Sistemas, que el investigador tiene la capacidad de desarrollar un aplicativo web que a su vez servirá de insumo a la Universidad para preparar a sus estudiantes a las pruebas SABER PRO.

1.3.3 Justificación Práctica

Una de las variables que mide la calidad de las Instituciones de Educación Superior es el resultado que obtienen anualmente en la prueba nacional SABER PRO. De tal manera que es indispensable que los estudiantes de los últimos semestres de cada carrera estén debidamente preparados para presentarlas, ya que, dependiendo de sus resultados individuales, se medirá el resultado global de la educación de la Universidad.

Es así como el presente trabajo de grado tuvo como objeto de estudio contribuir con el entrenamiento de los estudiantes de Ingeniería de Sistemas de la Universidad Distrital a partir del desarrollo de un prototipo de aplicación WEB, en el cual los estudiantes encontrarán una base de datos de preguntas que les permitirá reforzar sus conocimientos previamente a la presentación de la prueba.

A través de esta investigación, que generó el prototipo descrito anteriormente, se permitió resolver el problema del apoyo al entrenamiento de los estudiantes de cara a la presentación exitosa de la prueba detectado; adicionalmente si la Universidad, en un futuro la podrá ejecutar y evidenciar mejoras en los resultados y también podrá aplicar este prototipo a otros programas académicos que imparte.

1.4 Marco referencial

(14)

A partir de la pregunta problema: ¿Cómo sería un prototipo de aplicación informática WEB con miras al entrenamiento para la presentación exitosa de la prueba SABER PRO

de los estudiantes de Ingeniería de Sistemas de la UDFJC.? Se establecieron las siguientes categorías conceptuales a desarrollar:

Imagen # 3: Categorías Conceptuales del Marco Referencial. Fuente: propia, 2016

De acuerdo a las categorías conceptuales determinadas se investigó toda la información bibliográfica pertinente que permita responder la pregunta problema y en sí alcanzar el objetivo general planteado para la presente investigación.

ICFES

Pruebas SABER PRO

Prototipo de Aplicación

Web

Competencias Ingeniero de

(15)

1.4.1 Marco Teórico

A continuación se presenta un breve recorrido por la teoría existente en las categorías conceptuales de: ICFES, Pruebas SABER PRO Y Competencias de los Ingenieros de Sistemas.

1.4.1.1 ICFES

El Instituto Colombiano para el Fomento de la Educación Superior (ICFES) es un organismo adscrito al Ministerio de Educación Nacional de Colombia que tiene como misión: “Ofrecer el servicio de evaluación de la educación en todos sus niveles y adelantar investigaciones sobre factores que inciden en la calidad educativa, con la finalidad de ofrecer información para mejorarla” (ICFES, 2009) lo cual quiere decir que es el ente encargado de evaluar la calidad de la educación colombiana en todos sus niveles, desde la Educación Básica Primaria hasta el nivel Profesional.

De acuerdo al objeto de estudio de la presente investigación, se encuentran relacionadas las siguientes funciones:

 Establecer las metodologías y procedimientos que guían la evaluación externa de la calidad de la educación.

 Diseñar, implementar, administrar y mantener actualizadas las bases de datos con la información de los resultados alcanzados en las pruebas aplicadas y los factores asociados, de acuerdo con prácticas internacionalmente aceptadas.

 Organizar y administrar el banco de pruebas y preguntas, según niveles educativos y programas, el cual tendrá carácter reservado. (ICFES, 2007)

De tal manera que es el encargado que ejecutar y regular la evaluación nacional de la educación y además de procesar y analizar los resultados obtenidos anualmente con el fin de encontrar oportunidades de mejora en los programas académicos, de acuerdo con las exigencias internacionales sobre perfiles de egresados.

(16)

PRO, en la que participan los estudiantes de últimos semestres y que a continuación se hará un recorrido breve por su fundamentación teórica.

1.4.1.2 Prueba SABER PRO

Haciendo un recorrido histórico, se ha podido determinar que inicialmente las pruebas SABER PRO se llamaban ECAES (exámenes de Estado de Calidad de la Educación programas académicos de pregrado que ofrecen las Instituciones de Educación Superior. Así mismo, a través de los ECAES se obtiene información sobre el estado actual de la formación en las diferentes áreas. Esta información proporciona una visión de conjunto sobre los estudiantes, los programas y las instituciones, así como también sobre el país, los departamentos y municipios. (Colombia Aprende, s/f) Es decir, que son las pruebas que deben presentar los estudiantes de Ingeniería de Sistemas de la Universidad Distrital, en este caso puntual, para poder determinar el nivel de competencias profesionales que tienen para ser egresados del programa, tal como lo afirma Guía Académica (2010): “Estas deben, como requisito, presentar una lista de sus estudiantes que hayan superado el 75 por ciento de los créditos.” Y que se convertirán en la población a la cual va dirigida la presente investigación.

(17)

Académica, 2010), de tal manera que se pueden encontrar aún registros de ECAES y a partir de este año las nuevas llamadas pruebas SABER PRO.

A partir de una entrevista realizada a Francisco Reyes, el Director de Producción y Operación del ICFES, publicada por Guía Académica (2010), se pudo conocer que la principal función de esta prueba es: “Incrementar la calidad académica tanto en carreras técnicas, tecnológicas y profesionales a través de la competitividad, promoviendo la selección de practicantes entre las empresas, el otorgamiento de becas y mayores oportunidades para posgrados.” (Guía Académica, 2010) de tal manera que busca medir las competencias de los futuros profesionales, a fin de establecer el nivel de formación y competitividad con la que las IES están formando a sus egresados.

Los resultados de estas pruebas “permiten contribuir a la formación de políticas y a la toma de decisiones para los distintos actores del proceso, que contribuyen al desarrollo de la educación integral del país.” (Guía Académica, 2010) por lo cual cada IES, deberá tomar sus resultados como aprendizaje y reflexión para mejorar cada vez más sus programas académicos y transformarlos de manera tal que realmente respondan a los estándares que se espera en el mercado laboral de los egresados.

Por último se conocen como objetivos de las pruebas SABER PRO:

1. Comprobar el grado de desarrollo de competencias en estudiantes próximos a culminar su educación superior.

2. Producir indicadores de valor agregado de la educación superior. Comparar las competencias existentes antes de ingresar y al terminar la carrera.

3. Servir como fuente de información para construir indicadores de evaluación a la calidad de programas e instituciones. (Guía Académica, 2010)

(18)

1.4.1.3 Competencias Ingeniero de Sistemas

Ahora bien, luego de conocer el ICFES y las pruebas SABER PRO, fue indispensable para la presente investigación tener un acercamiento a las competencias que se evalúan para los estudiantes de Ingeniería de Sistemas. Para ello se profundizó en la Guía: “Orientaciones para el examen de Estado de calidad de la educación superior SABER PRO (ECAES). Ingeniería de Sistemas” que construyó y publicó el ICFES en el 2010.

En esta guía se hace un recorrido por el marco normativo, los antecedentes de la evaluación y finalmente por la composición del examen: qué y cómo se evalúa, cuál es la población, cuáles son los objetivos y ejemplos de preguntas.

La presente investigación hizo un análisis de esta guía con el fin de componer el prototipo de aplicación web que será de utilidad a los estudiantes de Ingeniería de Sistemas de la Universidad Distrital, a la hora de prepararse para la presentación de la prueba SABER PRO.

Se considera que se contribuye con la formación extra curricular de los estudiantes, y se podrá influenciar positivamente los resultados y a la vez a la educación que imparte la universidad.

1.4.2 Marco Conceptual

A continuación se presentará un recorrido conceptual por la fundamentación de la construcción y el diseño del prototipo de aplicativo web que se desarrolló a partir de la ejecución de la presente investigación, cuyo objetivo principal fue contribuir con la preparación de los estudiantes de Ingeniería de Sistemas de la Universidad Distrital para la presentación de las pruebas SABER PRO.

1.4.2.1 La plataforma Java

(19)

extinta compañía Microsystems (esta compañía fue comprada por Oracle en el año 2009) que conformaban lo que se conoció en su época como el “Green Team”.

Su principal objetivo era desarrollar una plataforma de programación con la que se pudiera manipular cualquier procesador independiente de su arquitectura, bajo la premisa futurista de que todos los dispositivos electrónicos tendrían un procesador algún día. Aunque esta idea fue demasiado adelantada para su época, y no fuera exitosa para lo que fue creada, su concepción coincidió con la creación y difusión de la World Wide Web

(WWW), para la cual Sun Microsystems realizó una adaptación de esta plataforma inicial. A pesar del fracaso de ingresar en el negocio de la televisión interactiva, Sun concentró sus esfuerzos en la posibilidad de ejecución de sus programas a través de un “browser” (navegador) por la creciente demanda de usuarios en la Web. Es allí cuando en 1994, ingenieros de Sun Microsystems implementan el prototipo del navegador WebRunner, capaz de ejecutar código Java (este último nombre adoptado por temas de derechos de autor, pues el nombre “Oak” ya estaba siendo utilizado por otro lenguaje) sobre el navegador Web, lo que más adelante la compañía Netscape aprovechó en su versión 2.002 (1995) e introdujo en su navegador soporte al lenguaje de programación Java. Esto le permitió a Netscape ejecutar aplicaciones Java dentro su navegador (el código fuente era incrustado dentro de la etiqueta <applet>) con independencia del sistema operativo en ejecución dentro de la maquina cliente.

La aceptación de esta plataforma en el mercado, junto con la aceptación de Microsoft de permitir la ejecución de aplicaciones Java dentro de su navegador (Internet Explorer) popularizaron este lenguaje hasta tal punto de que Sun Microsystems liberó la versión 1.0 de su ambiente de desarrollo para fomentar el crecimiento de la comunidad de programadores Java y lo logró. Para el año de 1996, ya existían alrededor de 1000 compañías haciendo uso fuerte de las tecnologías Java entre las que se encontraban las

(20)

En el año 1999, la plataforma Java ya superaba los 2.000.000 de descargas e ingresaba en el mercado de los sistemas operativos para teléfonos móviles con su extensión Java 2 Micro Edition (J2ME). Este último no tuvo la acogida esperada debido a la limitación de recursos (memoria principal, procesamiento, memoria secundaria) existente en este tipo de dispositivos, lo que no le permitió posicionarse en el mercado de las aplicaciones móviles con suficiente comodidad. Para el año 2003, la plataforma ya lanzaba su cuarta actualización (Java JDK 1.4 - Merlín) y tenía casi 3.000.000 de usuarios. Desde entonces su ascenso en la industria ha sido vertiginoso, entregando a los diferentes desarrolladores a través del mundo un sinnúmero de API’s (Aplication Programming Interfaces) que proporcionan millones de distintas soluciones para problemas de índole computacional.

En el año 2014, según datos de Oracle Inc., esta plataforma ya se encuentra en ejecución en más de 3 billones de dispositivos, y se estima que existe una comunidad alrededor de 9.000.000 de desarrolladores, lo que le da la consistencia esperada para desarrollar cualquier tipo de proyecto; desde aplicaciones con fines académicos y de aprendizaje hasta las más grandes aplicaciones que administran múltiples dispositivos simultáneamente en los sectores financiero, salud, telecomunicaciones, transporte, comercio, construcción e investigación científica alrededor del mundo.

1.4.2.2 Modelo de datos y motor de implementación

El modelo de datos escogido para el desarrollo de este proyecto es el modelo de base de datos relacional, formulado por Edgar Codd en el año de 1970 en su trabajo “A Relational Model of Data for Large Shared Data Banks”, dondesugirió la necesidad de independizar la representación física de los datos de los usuarios finales de la base de datos. Para Codd era importante que la forma de acceder a los datos fuera transparente de cómo se encontraran estos organizados dentro de los dispositivos de almacenamiento. (Codd, E., 1970)

(21)

principal objetivo era mostrar una forma en la que se podían tratar los datos a través de relaciones (tablas) que describen las propiedades importantes abstraídas de una entidad del mundo real (columnas). Cada ejemplar de la relación (tupla) es una combinación de los diferentes posibles valores que pueden tomar las columnas (dominios) para describir unívocamente un ejemplar de las relaciones (no se deben confundir las relaciones del modelo relacional con las relaciones del modelo entidad relación, pues este último solo es una representación semántica de alto nivel para describir las asociaciones existentes entre distintas entidades). (Quiroz, J., 2003)

Otro concepto que introdujo Edgar Codd en sus postulados se conoce como “normalización”. Su intención es evitar la repetición de los datos innecesariamente, repartiéndolos entre las distintas relaciones existentes y enlazándolos a través de referencias por valor mediante las claves primarias de cada tupla (un atributo o conjunto de atributos que definen una característica única para todos los ejemplares de una relación). Esto garantiza que el espacio utilizado sea el mínimo requerido por la base de datos, y garantiza la consistencia de los datos eliminando la posibilidad de realizar cambios parciales o incompletos en los datos que den lugar a inconsistencias. Aunque existen 6 formas normales, se considera una práctica robusta realizar la normalización hasta la tercera forma normal (3NF). (Quiroz, J., 2003)

(22)

del lenguaje SQL (anteriormente SEQUEL), el más utilizado hasta la actualidad para las operaciones CRUD necesarias en cualquier modelo de datos. (Quiroz, J., 2003)

Desde la publicación de Codd hasta la actualidad han pasado más de 40 años en los cuales este modelo tomo la fuerza suficiente para convertirse en un estándar de facto en la industria del desarrollo de software. Varias compañías acogieron los escritos de Codd y desarrollaron rápidamente motores que cumplían con las 13 reglas establecidas por el autor en 1985 en la publicación “The relational model for database management” (Codd, E.,

1990). El caso más prominente es el la compañía Oracle Inc., donde Lawrence Joseph Ellison (su fundador) percibió la potencia del sustento teórico de Codd (quien trabajaba para IBM, donde no se recibió con mayor gratitud) e implementó un motor de base de datos que hasta la actualidad es uno de los más utilizados alrededor del mundo.

No obstante, la cantidad de motores existentes que implementaron este paradigma en la actualidad es incalculable, desde motores con fines educativos, hasta motores propietarios de compañías para uso privativo. En el apartado V.2.5 del presente documento se presenta un cuadro comparativo de algunos de los motores de bases de datos relacionales más populares en el mercado para tomar una elección de implementación basada en la evaluación de características relevantes de cada uno de ellos.

1.4.2.3 Arquitectura Física de la aplicación

La arquitectura física de la aplicación se basará en el paradigma cliente-servidor, siendo este el más utilizado en el mundo por la gran ventaja de proveer recursos centralizados que son comunes a todos los usuarios (por ejemplo, una base de datos centralizada que evita la redundancia e inconsistencia de datos). (CCM, 2016)

(23)

con que los clientes accedan al servidor tal como todos lo hacen (esto hace que no se altere el funcionamiento de la red) para obtener datos de la aplicación central. (CCM, 2016)

La arquitectura física se propone sea de 2 capas; la primera (o capa cliente) accederá a la aplicación a través de un navegador regular (Internet Explorer, Mozilla Firefox, Google Chrome, etc.) mientras que en la máquina del servidor se pondrá en funcionamiento un servidor de aplicaciones (Glassfish, Weblogic, Jboss, Webshpere, etc.) que servirá como huésped de la aplicación WEB construida, junto con el servidor de base de datos (PostgreSQL, Oracle, MySql, etc.) que mantendrá la información de manera persistente a través del tiempo. La siguiente imagen se muestra a modo de ejemplo:

Imagen # 4: Arquitectura física de la aplicación. Fuente: propia. Imágenes tomadas de:

https://goo.gl/AkjH5N, https://goo.gl/uin1wY y https://goo.gl/jKfA6y respectivamente.

1.4.2.4 Arquitectura lógica de la aplicación

(24)

referentes al tratamiento de la información frente a la base de datos. Las funciones de cada capa se describen así:

 Vista: Capa encargada de la presentación de los datos al usuario final. Esta capa no se preocupa por el contenido de los mismos, sino de las formas en la que el usuario visualiza la información (colores, tamaños, posiciones y animaciones)

 Controlador: Capa encargada de la gestión de eventos del sistema. Se encargará de recibir las peticiones HTTP realizadas por el cliente y entregarlas a los módulos responsables de realizar los cálculos pertinentes para generar nueva información.

 Modelo: Capa encargada del procesamiento de los datos recibidos. En esta capa se realiza la implementación gruesa que permite al sistema tomar decisiones según políticas de negocio y reglas programadas.

 Acceso a datos: Capa responsable de las operaciones de lectura y escritura en la base de datos de la aplicación. Su única responsabilidad es mantener sincronizada la base de datos con los cambios de información solicitados por los usuarios finales (extracción, inserción, modificación y eliminación de la información).

(25)

1.4.2.5 Tecnologías de soporte para la implementación

En el marco del desarrollo de un Prototipo de aplicación informática WEB con miras al entrenamiento para la presentación exitosa de la prueba SABER PRO de los estudiantes de Ingeniería de Sistemas de la Universidad Distrital Francisco José de Caldas, se propone el uso de las siguientes tecnologías:

 Base de datos MySQL 5.6

Según una publicación realizada por la compañía Solid IT (2016) se puede obtener un estudio de los motores de bases de datos más populares alrededor del mundo y se obtienen los resultados presentados en la siguiente imagen:

Imagen # 6: Los diez motores de bases de datos más utilizados en la actualidad. Fuente: Solid IT (2016)

Los criterios utilizados para realizar esta medición son:  Número de nombramientos en sitios WEB.

 Interés general en el sistema en la WEB.  Frecuencia de discusiones técnicas en la WEB.

 Número de ofertas laborales, donde cada uno es mencionado en la WEB.

(26)

Aunque se puede apreciar que el motor seleccionado no es el primero en tendencia, la principal motivación de su elección se decide por el licenciamiento necesario para el funcionamiento de Oracle. MySQL es un motor con condiciones Open Source de alto rendimiento gracias a su implementación multihilo que además dispone de gran portabilidad entre distintos sistemas operativos y de gran facilidad de uso, sin contar con la consistencia e integridad referencial (configuración InnoDB) de la que se puede o no disponer según la configuración de preferencia por los usuarios finales.

 Java Persistence API 2.0

Java Persistence API (JPA) es un framework que permite el manejo de información distribuida de manera relacional desde el paradigma de la programación orientada a objetos (POO). Su intención es la de evitar al desarrollador tener que preocuparse por la forma de recuperar y/o actualizar la base de datos con las sentencias clásicas del lenguaje SQL para así centrarse en el desarrollo de la lógica de negocio de la aplicación implementada. Este

framework se encuentra clasificado dentro de las tecnologías ORM (Object-Relational Mapping) y su potencia lo ha hecho un estándar de facto en el desarrollo de aplicaciones empresariales.

 Enterprise Java Beans (EJB) 3.1

Los EnterpriseJava Beans son parte de la interfaz de programación de aplicaciones de la plataforma JAVA y su objetivo es brindar a los desarrolladores la capacidad de centrarse en el desarrollo de la lógica de negocio de estas sin enfocar esfuerzos en los temas subsecuentes (concurrencia, transacciones, asincronismo, seguridad, etc.). La gran potencia de dichos objetos es que permiten la invocación remota de métodos (esto permite realizar llamados a operaciones del sistema sin ser una parte fuertemente acoplada del mismo).

 Java Server Faces 2.2

(27)

emular las vistosas aplicaciones de escritorio en un navegador web. JSF también permite realizar la gestión de eventos sobre los componentes de las aplicaciones sin mayor esfuerzo, todo orientado a que los desarrolladores se enfoquen en el “que” sin pensar en el “como”.

1.5 Metodología

En el presente apartado se hace una breve descripción del camino metodológico que se tomó para desarrollar la presente investigación.

1.5.1 Tipo de estudio

Es un estudio con enfoque cualitativo que permitió apoyar el proceso de capacitación de los estudiantes de X semestre de Ingeniería de Sistemas de la Universidad Distrital Francisco José de Caldas. El estudio permitió desarrollar un prototipo de aplicativo web, donde se encontrará información útil para los estudiantes, tal como ejemplos de preguntas, repaso de conceptos, etc., que refuerce los conocimientos y las competencias que deben tener para aprobar de manera exitosa la prueba SABER PRO del 2016.

Se cumplieron con las siguientes fases de investigación:

Imagen # 7: Fases del proyecto de investigación. Fuente: propia, 2016

(28)

1.5.2 Método de investigación

El método que se utilizó en la investigación fue el deductivo, en el cuál se partió de la base del desarrollo de un prototipo de aplicativo web que permita fortalecer los conocimientos y las competencias de los estudiantes objeto de estudio, para prepararse adecuadamente para la presentación de la prueba SABER PRO 2016. Se considera deductivo ya que, a partir de lo macro (la necesidad de aprobar la prueba) se llegó a lo particular (cómo reforzar la formación de los estudiantes para prepararse para las pruebas)

1.5.3 Fuentes y técnicas para la recolección de la información

La fuente principal de recolección de la información fue directamente el ente regulador de los exámenes de calidad para la educación superior (ECAES), el Icfes.

Se tuvieron en cuenta otras fuentes alternativas como:

 Instituciones de educación superior que cuenten con procesos estructurados de preparación y entrenamiento para las pruebas SABER PRO de Ingeniería de Sistemas

 Universidad Distrital Francisco José de Caldas (docentes y estudiantes)

 Artículos científicos publicados con relación al desarrollo del prototipo de aplicación web.

 Entre otros.

1.5.4 Alcance

(29)

 Para el prototipo se soportan los diferentes tipos de preguntas mediante parametrización. Esto permitió cargar diferentes tipos de preguntas de distintas carreras, lo que extiende la funcionalidad

 Se pudo simular una prueba ECAES con un número configurable de preguntas.

 Se pudo parametrizar el tiempo máximo de respuesta de una pregunta.

 Se programó un mecanismo de registro y autenticación para los usuarios finales del prototipo.

 Se puede ver en un cuadro de mando a modo estadístico el progreso a través del tiempo de cada usuario.

1.5.5 Metodología de desarrollo en Ingeniería

La metodología de desarrollo elegida para la construcción de la aplicación WEB fue SCRUM. Este marco de gestión surgió en el año 1993 dentro del marco de lo que se conoce como el “manifiesto ágil”, cuya filosofía se puede entender desde la definición de agilidad proporcionada por Quomer y Henderson Sellers:

La agilidad es un comportamiento persistente o habilidad, de entidad sensible, que presenta flexibilidad para adaptarse a los cambios esperados o inesperados rápidamente; persigue la duración más corta en tiempo, usa instrumentos económicos y utiliza experiencias y conocimientos previos para aprender tanto del entorno interno como del externo. (Quomer y Henderson citado por Trigas, M., s/f.).

Dicho lo anterior, se puede tipificar a SCRUM como un marco de gestión donde se realizan desarrollos incrementales a través de la alta cohesión de los miembros involucrados y comprometidos en la creación del producto final. SCRUM permite definir los roles, artefactos, reglas y reuniones relevantes para la construcción del producto final a través de lo que se conoce como SPRINTS (intervalos de tiempo de 15 o 30 días) donde se hacen desarrollos que extienden o incrementan la funcionalidad inicial (de allí el nombre de incrementos).

(30)

Imagen # 8: Esquema

conceptual de SCRUM. Imagen

tomada de:

http://www.giks.org/wp-content/uploads/2015/05/scru.png

De la anterior imagen se pueden describir varios de los elementos importantes de la metodología como son:

 Product Backlog (Bitácora de producto)

La bitácora de producto tiene como objetivo el registro de todas las acciones priorizadas a nivel macro para llevar a buen término la construcción del producto. En esta bitácora se deben registrar todos los requerimientos realizados por el cliente, los que a su vez en curso de las iteraciones a realizar se irán resolviendo.

 Sprint Backlog (Bitácora de iteración)

La bitácora de iteración le permite al equipo en cada Sprint tomar la cantidad de requerimientos que se piensa se pueden resolver dentro de un sprint. Esto permite involucrar al equipo de desarrollo directamente con la planificación, ya que al hacerlos parte de la planificación se tiene un panorama real de los entregables realizables en la realidad por el equipo. Esto se promueve en contraposición con las metodologías de desarrollo tradicionales que realizan las estimaciones sin evaluar la real posibilidad del cumplimiento de los hitos por parte del equipo desarrollador.

 Daily Sprint (Seguimiento diario)

Este ítem consiste en una reunión diaria de no más de 15 minutos con el equipo de desarrollo en el cual a cada uno de los miembros se le formulan tres preguntas:

o ¿Qué has realizado desde nuestra última reunión?

(31)

o ¿Qué tipo de inconvenientes has presentado en el cumplimiento de tus compromisos?

Esto permite conocer de cerca cómo se está llevando el proyecto a corto plazo. Si existen retrasos, es posible evaluar sus causas y mitigar los riesgos de manera pronta.

 Deliverable (Entregable)

Es el producto de la finalización del Sprint. Este es un producto software plausible y funcional, que se ha construido con base en las prioridades que el cliente ha definido. El entregable se considera terminado cuando este ha sido sometido a las pruebas de SCRUM, los cuales se dividen en las siguientes categorías:

 Product Owner (Dueño del producto)

Es el responsable de la construcción del producto final. Su objetivo en el proyecto es el producto en sí y debe velar por la correcta y oportuna priorización de las tareas en la bitácora general del producto (Product Backlog). Dentro de su razón de ser en el proyecto está determinar la aceptación o rechazo de los incrementos del producto, poner en consideración los intereses de los “stakeholders”, determinar la real función de cada

requerimiento del entregable final y tomar las decisiones de liberación de las versiones entregadas en los diferentes Sprints.

 Equipo de desarrollo

(32)

necesitar la asignación de roles tácitamente) y proactivo, pues debe ser capaz de identificar los posibles riesgos técnicos de implementar una solución como el cliente la desea. El equipo de desarrollo, al basarse en políticas de alta colaboración debe estar en el mismo lugar para ayudar a sus miembros a la resolución de un problema. Se recomienda que estos equipos sean de 7 ± 2 miembros para no complejizar el ámbito social del mismo.

 Scrum Master (Maestro Scrum)

El ScrumMaster debe ser una persona experta en el manejo de equipos y construcción de proyectos de software; sus principales funciones son apoyar al equipo de desarrollo en la resolución de los impedimentos, cubrir al equipo de desarrollo de posibles interrupciones externas y distracciones, aplicar los timeboxes (intervalos de tiempo en los cuales se debe garantizar cumplimiento de las tareas), promover el cumplimiento de las practicas estándar de ingeniería y verificar el funcionamiento de las soluciones implementadas por el equipo a través de la captura de datos empíricos (casos de prueba de condiciones de frontera, pruebas de carga y estrés del sistema y visualización de escenarios no previstos en el levantamiento inicial de requisitos).

 Historias de usuario

Las historias de usuario son un conjunto de descripciones realizadas por el cliente que le aportan valor al producto final. Estas son el resumen de lo que “debería” hacer el sistema y se debe asegurar que cumplan con el criterio INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable), el cual se describe a continuación:

 Independent (Independiente)

(33)

 Negotiable (Negociable)

Se entiende por negociable aquello que se puede pactar como compromiso por ambas partes. Una historia de usuario se comprende como negociable cuando tienen el concepto básico de una funcionalidad, pero no debe contener alto detalle ya que pueden limitar o malinterpretar la idea inicial. Se busca así poder tener una interacción directa con el cliente en la fase de conversación.

 Valuable (Valiosa)

Las historias de usuarios se hacen valiosas cuando entregan valor para el cliente. Es decir que la funcionalidad descrita al momento de la implementación debe tener un beneficio para el usuario final

 Estimable (Estimable)

Una historia de usuario debe estar suficientemente bien escrita como para que el esfuerzo que conlleva su materialización en un producto pueda ser medido por el equipo de desarrollo además de entregar el beneficio de poder priorizarla (en caso de ser muy larga se tiene el perjuicio de necesitar más fases de conversación para lograr su total comprensión)

 Small (Pequeña)

La característica principal de una historia de usuario es que esta debe ser pequeña para poder englobar poco tiempo de implementación. Una historia pequeña facilita la estimación del esfuerzo para la implementación de la misma.

 Testable (Comprobable)

(34)

(35)

PARTE II. DESARROLLO DE LA INVESTIGACIÓN

CAPÍTULO 2. DESCRIPCIÓN DEL DESARROLLO

Para responder a la pregunta de investigación que a su vez permita el cumplimiento del objetivo general del presente documento, el cual propone la construcción de un prototipo con acceso WEB para simular la prueba SABER PRO, se propuso dividir la construcción de la solución en cuatro fases; el análisis del problema (permitirá conocer el “qué” de la solución), el diseño de la solución (explicará a través de distintos puntos de vista el “cómo”), la implementación en un lenguaje formal de programación (construcción técnica del prototipo) y las pruebas que permitirán mostrar que el producto final cumple con los criterios mínimos de aceptación.

2.1 Análisis de la solución

En concordancia con el objetivo principal del presente documento, se dispone a realizar una especificación formal de los requisitos para la construcción de una solución tipo Software que permita entrenar a los estudiantes de Ingeniería de Sistemas de la Universidad Distrital Francisco José de Caldas. Esta solución debería contar con las siguientes características:

 La aplicación debe servir para brindar entrenamiento a los estudiantes de cara a la prueba SABER PRO, permitiéndoles “simular” una prueba de este tipo con preguntas lo más cercanas posibles a las preguntas de la prueba real.

 Esta aplicación debe ser parametrizable a nivel de preguntas y programas académicos. Con esto se busca poder extender su funcionalidad a permitir entrenar estudiantes de cualquier programa académico alrededor del territorio nacional.

 Se requiere poder parametrizar la aplicación para que al momento de ejecutar una simulación se pueda configurar la cantidad de tiempo de la que dispone un estudiante para responder a una pregunta.

(36)

tiempo diferentes, se debe poder contar con mecanismos que tengan “la fotografía” de una simulación para poder continuarla en cualquier instante. Si el estudiante desea, puede abandonar una simulación e iniciar una nueva.

 Dado que la naturaleza geográfica de los usuarios finales puede ser distinta, se hace necesario que esta aplicación esté disponible desde cualquier lugar.

 Se requiere que la aplicación muestre estadísticas de rendimiento de los estudiantes que han realizado simulaciones para poder medir su rendimiento y mejora a través del tiempo y de las distintas simulaciones realizadas.

2.1.1 Pila de producto

Bajo el marco de trabajo de la metodología seleccionada para el desarrollo del proyecto (SCRUM), a continuación se hace la construcción de la pila o bitácora de producto (Product Backlog) que permitirá hacer una separación de requisitos de alto nivel con un nivel de prioridad que permita ir construyendo la solución iterativamente; esto es, realizar entregables con valor para los usuarios finales.

Id Requisito Prioridad Estimación

(horas/hombre)

1 Registro en el sistema Alta 4,5

2 Autenticación del sistema Alta 4,5

3 Simulador de prueba Muy alta 27

4 Almacenamiento de simulación Media 18

5 Registrar programa académico Muy alta 27

6 Registro de preguntas manual Media 18

7 Registro de preguntas masivo Muy alta 27

8 Contador de tiempo por simulación Baja 18

9 Cuadro de estadísticas Media 36

Imagen # 8: Pila de producto. Fuente: propia, 2016

2.1.2 Historias de usuario

(37)

Historia de usuario

Número: 1 Usuario: Estudiante

Nombre historia: Registro de usuario en el sistema

Prioridad en el negocio 4 Riesgo en desarrollo 1 (Muy bajo)

Puntos estimados 100 Costo 270

Programador responsable: Alejandro Arévalo Vásquez

Descripción: El sistema debe permitir a los usuarios registrarse dentro de la aplicación para poder utilizarlo.

Información de entrada Concepto

Primer nombre Primer nombre del usuario a registrar

Segundo nombre Segundo nombre del usuario a registrar

Primer apellido Primer apellido del usuario a registrar

Segundo apellido Segundo apellido

Tipo de identificación Tipo de identificación del usuario

Número de identificación Número de identificación del usuario

Programa académico Programa académico o carrera en la cual está inscrito el usuario

Correo electrónico Correo electrónico que utilizará el usuario como credencial de autenticación

Contraseña Contraseña que utilizará el usuario como credencial de autenticación

Información de salida Concepto

Mensaje de confirmación/rechazo de registro

Se debe obtener un mensaje de registro exitoso o de rechazo con la causa por la que el registro del usuario no puede ser llevado a cabo

Criterios de validación: Un usuario se encuentra registrado cuando este se puede autenticar con sus credenciales (usuario y contraseña) en el sistema.

Observaciones: Ninguna.

Imagen # 9: Historia de usuario Registro en el sistema. Fuente: propia, 2016

Nombre historia: Autenticación de usuario en el sistema

Prioridad en el negocio 4 Riesgo en desarrollo 2 (Bajo)

Descripción: El sistema debe permitir a los usuarios autenticarse dentro de la aplicación con credenciales de usuario (correo electrónico) y contraseña.

Correo electrónico Dirección de correo electrónico previamente registrada

Contraseña La contraseña del usuario registrado

(38)

Pantalla de información general del usuario autenticado

En caso de que la autenticación se realice exitosamente, se debe cargar pantalla con información general del usuario registrado. Mensaje de error en autenticación Si el usuario ingresa incorrectamente sus credenciales, el sistema

debe mostrar mensaje de error en la autenticación con la causa.

Criterios de validación:

 Un usuario se encuentra autenticado cuando puede visualizar su información general registrada previamente.

 Se debe garantizar que el nombre de cada usuario sea único.

 El usuario que se encuentra autenticado puede ver su información general, junto con el cuadro de estadísticas y puede iniciar una simulación.

Imagen # 10: Historia de usuario Autenticación de usuario en el sistema. Fuente: propia, 2016

Nombre historia: Realizar simulación ECAES

Prioridad en el negocio 5 Riesgo en desarrollo 4 (Alto)

Descripción:

 El sistema debe permitir a los usuarios iniciar una simulación de un número de preguntas parametrizado con un tiempo límite definido.

 Cada simulación debe estar formada por un conjunto de preguntas tipo ECAES previamente cargadas en el sistema.

 Al terminar la simulación, se debe mostrar una puntuación final a cada usuario que debe verse reflejada en el cuadro de estadísticas de la información general.

Evento <Iniciar nueva simulación> Orden al sistema para cargar un número de preguntas que el usuario irá respondiendo de a una a la vez.

Respuestas elegidas Cada pregunta contiene una cantidad de respuestas seleccionables, de las cuales el usuario deberá elegir una a la vez hasta completar el total de preguntas de la simulación.

Preguntas tipo ECAES Al inicio y durante la simulación, deberán aparecer preguntas tipo ECAES al usuario que este debe ir respondiendo antes de que el contador de tiempo llegue a cero.

Mensaje de finalización de simulación.

En caso de terminar una simulación, o de que el contador de tiempo llegue a cero, el sistema debe emitir un mensaje indicando la terminación de la simulación con la causal.

Resultados de la simulación Al terminar la simulación, el sistema debe mostrar el desempeño del usuario en la simulación realizada.

 Una simulación es exitosa cuando se ha terminado por tiempo, o porque todas sus preguntas han sido contestadas.

(39)

Nombre historia: Almacenar simulación en curso

Prioridad en el negocio 3 Riesgo en desarrollo 3 (Medio)

Descripción:

 El sistema debe permitir a los usuarios almacenar una simulación en curso para poder continuarla desde otra sesión iniciada.

Evento <Guardar progreso de simulación>

Orden al sistema para almacenar las preguntas previamente contestadas en caso de necesitar continuar más tarde la simulación.

Mensaje de almacenamiento correcto con cantidad de guardados restantes.

El mensaje debe avisar al usuario que su simulación fue almacenada correctamente, junto con la cantidad restante de almacenamientos disponibles.

 Una simulación ha sido guardada satisfactoriamente cuando al cerrar la sesión de un usuario y volverla a abrir, este puede continuar con la última pregunta no contestada.

 Se debe restringir la cantidad de veces que se puede almacenar una simulación proporcionalmente a la cantidad de preguntas por simulación configuradas (10%).

 Cada vez que sea almacenada una simulación, se debe advertir al usuario final la cantidad de posibles almacenamientos restantes

 En caso de que no queden almacenamientos restantes, la opción de guardar simulación en curso debe ser desactivada

Imagen # 12: Historia de usuario Almacenar simulación en curso. Fuente: propia, 2016

Número: 5 Usuario: Administrador

Nombre historia: Registrar programa académico

Descripción: El sistema debe permitir al administrador registrar un programa académico.

Nombre del programa Nombre del programa académico

Área de conocimiento Área de conocimiento del programa (Ciencias de la salud, Bellas artes, Ingeniería, etc.)

Núcleo básico de conocimiento Núcleo básico de conocimiento del programa (Odontología, Ingeniería de sistemas, Medicina, etc.)

(40)

Nivel de formación Nivel de formación del programa (Universitario, Tecnológica, Especialización, Doctorado, etc.)

Metodología Metodología del programa (Presencial, Distancia, Virtual)

Periodo de duración Periodo de duración del programa (Semestral, Trimestral, Anual, etc.)

Titulación Título que otorga el programa

Mensaje de registro correcto/erróneo de programa académico

El mensaje debe mostrar al usuario que el programa académico ha sido registrado satisfactoriamente. En caso de error, debe

especificar cuál es la causa del mismo.

Criterios de validación: Se pueden ver el programa académico agregado en el listado de programas académicos existentes.

Imagen # 13: Historia de usuario Registrar programa académico. Fuente: propia, 2016.

Nombre historia: Registrar preguntas manual para programa académico

Descripción: El sistema debe permitir al administrador registrar las preguntas de un programa académico.

Enunciado/Imagen Enunciado de la pregunta o imagen en caso de contener fórmulas y/o dibujos

Respuestas Las respuestas de las posibles preguntas.

Mensaje de registro correcto/erróneo de pregunta

El mensaje debe mostrar al usuario que la pregunta ha sido registrada satisfactoriamente. En caso de error, debe especificar cuál es la causa del mismo.

Criterios de validación: Se pueden ver la pregunta registrada en el listado de preguntas de un programa académico.

Imagen # 14: Historia de usuario Registrar preguntas para programa académico. Fuente: propia, 2016.

Nombre historia: Registrar preguntas masivamente para un programa académico

(41)

Descripción: El sistema debe permitir al administrador registrar las preguntas de un programa académico masivamente, es decir, varias preguntas a la vez.

Archivo de carga de preguntas Archivo en formato .txt o .xlsx con todas las preguntas a cargarle al sistema, con sus respectivas respuestas y que resalta la respuesta correcta.

Imágenes de preguntas Las imágenes que contienen el contenido previo a la pregunta (se utilizará para los casos donde las respuestas dependan de analizar alguna imagen)

Mensaje de registro correcto/erróneo de pregunta

El mensaje debe mostrar al usuario que la pregunta ha sido registrada satisfactoriamente. En caso de error, debe especificar cuál es la causa del mismo.

Criterios de validación: Se pueden ver todas las preguntas registradas masivamente en el listado de preguntas de un programa académico.

Imagen # 15: Historia de usuario Registro de preguntas masivo. Fuente: propia, 2016.

Número: 8 Usuario: Administrador/Estudiante

Nombre historia: Contador de tiempo por simulación

Descripción: El sistema debe contar con control de tiempo configurable para las simulaciones del sistema.

Tiempo en minutos de simulación (configuración)

Es el tiempo máximo que puede durar en curso una simulación.

Cronómetro con contador de cuenta regresiva en simulaciones en curso

Contador para controlar el tiempo límite de una simulación.

Criterios de validación: En una simulación en curso, cuando el temporizador marca 0 segundos restantes debe terminar con mensaje al usuario que le indica que se ha terminado el tiempo disponible.

Imagen # 16: Historia de usuario Contador de tiempo por simulación. Fuente: propia, 2016.

Nombre historia: Sección de estadísticas

(42)

Descripción: El sistema debe contar con cuadros de mando que permitan visualizar el progreso en el tiempo de cada estudiante.

Cuenta de simulaciones realizadas y aprobadas por un estudiante.

Cantidad de preguntas formuladas vs aprobadas

Cuenta del total de preguntas formuladas en el sistema y respondidas correctamente.

Cantidad de preguntas formuladas vs aprobadas agrupadas por área de conocimiento

Cuenta total de preguntas formuladas y respondidas correctamente de cada área o competencia medida.

Criterios de validación: Al cursar una simulación, estos datos se deben mostrar actualizados en tiempo real. Así, después de terminar una simulación, se debe actualizar el cuadro estadístico de información.

Imagen # 17: Historia de usuario Sección de estadísticas. Fuente: propia, 2016.

2.1.3 Bitácora de Sprint

A continuación, se realiza la construcción de la bitácora para los Sprints que tienen como objetivo la realización del listado de actividades atómicas para la realización del prototipo funcional. Se elige un formato de tabla en el que se pueda apreciar el esfuerzo a realizar según cada actividad de acuerdo a la capas de la arquitectura lógica de la aplicación que fueron diseñadas para construir el sistema. El esfuerzo invertido se mide en minutos y fue estimado contando con la colaboración de dos (2) desarrolladores con 2 años de experiencia mediante la técnica Planning Poker (Ver anexo A).

(43)

Imagen # 18: Tabla de estimación de esfuerzo para preparación del sistema. Fuente: propia, 2016.

Imagen # 19: Tabla de estimación de esfuerzo para Registro en el sistema. Fuente: propia, 2016. Base de datos Acceso a datos (DAO) Capa de negocio Control de eventos Interfaz de usuario Total (Mins)

Preparación del sistema 60 60 60 60 30 270

Creación del esquema de

Base de datos Acceso a datos (DAO) Capa de negocio Control de eventos Interfaz de usuario Total (Mins)

Registro en el sistema 60 60 30 60 60 270

Tablas para almacenar

información de usuario 60 0 0 0 0

(44)

Imagen # 20: Tabla de estimación de esfuerzo para Autenticación en el sistema. Fuente: propia, 2016.

Imagen # 21: Tabla de estimación de esfuerzo para registrar programa académico. Fuente: propia, 2016. Base de datos Acceso a datos (DAO) Capa de negocio Control de eventos Interfaz de usuario Total (Mins) Autenticación del

Base de datos Acceso a datos (DAO) Capa de negocio Control de eventos Interfaz de usuario Total (Mins) Registrar programa

académico 180 540 180 240 480 1620

Tablas para el registro de los

programas académicos 180 0 0 0 0

(45)

Base de datos Acceso a datos (DAO) Capa de negocio Control de eventos Interfaz de usuario Total (Mins)

Registro de preguntas masivo 0 240 600 540 240 1620

Construcción de procedimiento iterativo de cargue de preguntas a la base de datos

Imagen # 22: Tabla de estimación de esfuerzo para registro de preguntas masivo. Fuente: propia, 2016.

2.1.3.2 Sprint 2

Base de datos Acceso a datos (DAO) Capa de negocio Control de eventos Interfaz de usuario Total (Mins) Registro de preguntas manual

120 120 270 210 360 1080

Tablas para el registro de las

preguntas tipo ECAES 120 0 0 0 0

Implementación de clases e para control de eventos y gestión de excepciónes en guardado y