Prototipo de aplicación web tipo simulador para el ...

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á

2016

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

1.5.4 Alcance .................................................................................................................. 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.1.1 Pila de producto ..................................................................................................... 36

2.1.2 Historias de usuario ............................................................................................... 36

2.1.3 Bitácora de Sprint .................................................................................................. 42

2.1.3.1 Sprint 1 .............................................................................................................. 42

2.1.3.2 Sprint 2 .............................................................................................................. 45

2.1.4 Burn-down Chart ................................................................................................... 48

2.2 Diseño de la solución ................................................................................................... 49

2.2.1 Diseño de base de datos ........................................................................................ 49

2.2.2 Diseño de la aplicación ......................................................................................... 51

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

REFERENCIAS BIBLIOGRÁFICAS .......................................................................................... 65

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.

Es decir que, a pesar que los estudiantes desarrollan competencias en el perfil de un

Ingeniero de Sistemas durante la carrera, a la hora de presentar las pruebas nacionales

SABER PRO se evidencian algunos vacíos, debido al olvido, falta de práctica o

simplemente la concentración en otros puntos académicos, por lo que se ha evidenciado la

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.

A continuación encuentra, el planteamiento del problema (justificación y objetivos de la

investigación), el desarrollo del proyecto y las conclusiones a las que se llegaron a partir de

su ejecución.

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)

Se requiere apoyar el proceso de preparación de los estudiantes para presentar la prueba SABER PRO.

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.

Es así como en 1968 se crea el Instituto Colombiano para la Evaluación de la

Educación (ICFES), en cuyo momento aplicó una primera evaluación que buscó medir la

“Aptitud matemática, aptitud verbal, razonamiento abstracto, relaciones espaciales, ciencias

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

realización de los exámenes de Estado y en adelantar investigaciones sobre los

factores que inciden en la calidad educativa, para ofrecer información pertinente y

oportuna para contribuir al mejoramiento de la calidad de la educación. (ICFES,

2015)

De tal manera que el alcance que tienen las evaluaciones abarca todos los niveles

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

SABER 3°, 5°

Y 9°

SABER PRO

(ECAES)

ICFES

(SABER 11°)

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.

Lo que ahora permite preguntarse ¿Cómo los estudiantes se están preparando para

las pruebas SABER PRO? ¿Cómo se puede apoyar dicho proceso de capacitación? ¿Cómo

se pueden mejorar los resultados de las pruebas por parte de los estudiantes de Ingeniería de

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

para estudiantes de Ingeniería de Sistemas a partir de una revisión

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?

¿Cómo un aplicativo WEB puede fortalecer dichos conocimientos y competencias

en los estudiantes?

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.

Con esta metodología se pretendió ir de lo más general a lo más particular, lo que

terminó aportando a la Universidad Distrital Francisco José de Caldas un prototipo de

aplicativo móvil que podría fortalecer el proceso de preparación de los estudiantes de

Ingeniería de Sistemas de cara a las pruebas SABER PRO en los siguientes años.

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

A continuación se presenta un breve recorrido teórico por la información que

contribuye con la respuesta a la pregunta problema planteada en líneas anteriores. De tal

manera que se considera necesario conocer el ICFES, la Prueba SABER PRO, las

competencias evaluadas para estudiantes de Ingeniería de Sistemas de la Universidad

Distrital, entre otros aspectos epistemológicos que se desarrollarán a profundidad una vez la

presente propuesta sea aprobada.

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

Sistemas

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.

Para lograr esto el ICFES ejecuta anualmente tres tipos de prueba a cada nivel

educativo; el tipo de prueba que compete a la presente investigación es la prueba SABER

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

Superior), a pesar que cambió el nombre, sigue teniendo la misma funcionalidad y

descripción:

… son pruebas académicas de carácter oficial y obligatorio que forman parte, con

otros procesos y acciones, de un conjunto de instrumentos de que el Gobierno

Nacional dispone para evaluar la calidad del servicio educativo. A través de esta

prueba, el Ministerio de Educación Nacional pretende comprobar el grado de

desarrollo de las competencias de los estudiantes que cursan el último año de los

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.

Así mismo el mismo autor señala que: “Una de las razones por las que su nombre

cambió, es debido a que las nuevas pruebas pretenden posicionarse como un método

efectivo de evaluación en la calidad de la educación superior desde el Estado.” (Guía

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)

Es así como, la presentación de estas pruebas se ha convertido en una presión política,

social y sobre todo de calidad para las IES y los estudiantes que la presentan. De tal manera

que sustentan la importancia de establecer una estrategia de capacitación y preparación para

los estudiantes, para que asistan con el pleno conocimiento de lo que se espera de ellos en

los resultados.

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

Java como lenguaje de programación fue concebido en el año de 1991 bajo el nombre

de “Lenguaje Oak”. Este proyecto fue iniciado por James Gostling y otros ingenieros de la

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

Application Programming Interfaces (API’s) para conexiones a través de la Web, manejo

de interfaces gráficas de usuario, telefonía, seguridad informática, y comercio, entre otras,

que garantizaron el posicionamiento de esta plataforma de programación como una de las

más grandes del mercado.

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”, donde sugirió 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)

Es allí cuando en su trabajo realiza la formulación formal teórica y matemática de lo

que se convirtió rápidamente en el modelo de base de datos más usado en la actualidad. Su

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)

En el mismo trabajo el creador del modelo propuso la adopción del álgebra relacional.

Este es un lenguaje formal matemático basado en la teoría de conjuntos que le dio la

consistencia teórica final al modelo propuesto, y su principal objetivo fue poder describir

las operaciones posibles a efectuar entre las relaciones existentes sin la necesidad de

modificar las relaciones base de las operaciones. En medida de que estas operaciones solo

se pueden realizar entre relaciones, y producto de ellas se obtiene una nueva relación, se

cumple a plenitud la propiedad clausurativa de conjuntos. Aunque Codd propuso el uso de

8 operandos, solo 5 de ellos son fundamentales: restricción, proyección, diferencia, unión y

producto cartesiano. Los otros 3 (concatenación o junta, división e intersección) pueden

ser obtenidos a través de la combinación de los 5 primeros definidos. Con la teoría

plasmada, Edgar Codd construyó el primer lenguaje relacional formal (ALPHA), antecesor

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)

Este paradigma también provee una ventaja en términos de seguridad de la información,

puesto que la entrada de información al sistema solo es recibida a través de las interfaces

mostradas en el browser, que a su vez solo renderiza la información suministrada por el

servidor central de la aplicación. Tener un servidor centralizado permite agregar o quitar

clientes sin necesidad de centrar esfuerzos en la configuración de red de los mismos. Basta

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

En concordancia con los patrones de diseño de aplicaciones, se propone realizar la

implementación de la aplicación con una arquitectura de 4 capas; se implementará el patrón

de diseño MVC (Modelo, Vista, Controlador), agregando una cuarta capa para acceso a

datos (separando así la capa de modelo o lógica de negocio de la capa de acceso a datos).

Esta última se llevará a cabo mediante la implementación del patrón DAO (Data Access

Object), que permite responsabilizar a una capa exclusivamente de las operaciones CRUD

https://goo.gl/AkjH5N

https://goo.gl/uin1wY

https://goo.gl/jKfA6y

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).

Imagen # 5: Arquitectura de 4 capas. Fuente: propia.

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.

Número de perfiles en redes profesionales en los que cada motor es mencionado.

Relevancia en las redes sociales.

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 Enterprise Java 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

Java Server Faces (JSF) es un framework para desarrollo de aplicaciones empresariales

que permite la generación de interfaces gráficas de usuario del lado del servidor. Dicho de

otro modo, JSF permite construir dinámicamente la interfaz de usuario a visualizar en el

navegador siguiendo la filosofía de las RIA (Rich Internet Applications), donde se intentan

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

Se considera que con estas fases se pudo obtener información útil para el desarrollo del

prototipo para finalmente diseñarlo y así responder la pregunta problema planteada y

concluir la investigación.

Planteamiento del

Problema

Construcción del Marco Teórico

Recolección de

datos

Diseño del Prototipo

Conclusiones y Recomendaciones

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

El alcance que tuvo la presente investigación fue descriptivo, debido a que se hizo una

caracterización sobre cómo un aplicativo web puede contribuir con el entrenamiento de los

estudiantes para presentar la prueba SABER PRO y cómo debe estar estructurado este

aplicativo.

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).

A continuación se presenta el esquema conceptual de la metodología SCRUM:

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?

o ¿Qué objetivo tienes para la siguiente reunión?

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

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

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

aceptación necesarias para considerarlo como terminado. En caso de no llenar las

expectativas del cliente, se producirá un efecto feedback que debe ser traducido en el

refinamiento de la bitácora de producto, lo que garantiza la construcción iterativa del

producto final.

Es importante tener en cuenta la definición de roles dentro del marco de gestión

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

El equipo de desarrollo SCRUM debe tener naturaleza multifuncional y ser altamente

colaborativo; todos deben estar preparados para todo, pues la filosofía de SCRUM acepta el

cambio constante como una forma en la que se puede mejorar el producto final en objeto de

entregar una ventaja competitiva al cliente final. Este debe ser auto-gestionado (no debe

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 Scrum Master 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)

Esta característica señala que la historia de usuario pueda ser planificada sin importar su

orden. En otras palabras, Cada historia de usuario debe ser independiente entre sí, de tal

manera que el equipo al tomarla pueda realizar la implementación propuesta sin necesidad

de haber completado una historia anterior.

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)

La historia de usuario debe ser comprobable. Es decir que durante la fase de

confirmación, tanto el equipo como el usuario final deben poder medir si el requisito se

cumple. Si el equipo no puede probar una historia de usuario no se puede determinar la

terminación de la implementación.

34

Fue importante contar con un criterio que permitió priorizar las historias de usuario de

acuerdo a la cantidad de esfuerzo que debe ser invertido versus la ganancia que tienen los

estudiantes al utilizar cada módulo de la aplicación.

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.

Es deseable que la aplicación permita guardar parcialmente el curso de una

simulación. Es decir, si el estudiante desea realizar la simulación en dos instantes de

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

A continuación se procede a escribir los requisitos iniciales dentro del formato de

historia de usuario presentado:

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

Historia de usuario


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

Historia de usuario


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.


Imagen # 11: Historia de usuario Realizar simulación ECAES. Fuente: propia, 2016

39

Historia de usuario


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

Historia de usuario

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.)

Nivel académico Nivel académico del programa (Pregrado, Postgrado)

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.

Historia de usuario


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.



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.

Historia de usuario


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)



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.

Historia de usuario

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.

Historia de usuario


Nombre historia: Sección de estadísticas


Puntos estimados 50 Iteración asignada 2160

42 Programador responsable: Alejandro Arévalo Vásquez

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

tiempo de cada estudiante.


No aplica No aplica


Cantidad de simulaciones realizadas

vs aprobadas

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).

2.1.3.1 Sprint 1

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

datos y configuración de

reglas del motor de BD

60 0 0 0 0

Creación de clases e

interfaces de uso

genéricos para

operaciones CRUD en la

BD

0 60 0 0 0

Construcción de clases e

interfaces útiles para

procedimientos comunes

de las capas

0 0 60 0 0


interfaces de uso genérico

para gestión de

excepciones del sistema

(tolerancia a fallos)

0 0 0 60 0

Declaración de archivos

de propiedades para

internacionalización

0 0 0 0 30

BITÁCORA DE SPRINTSCapas

Sp

rin

t 1


Registro en el sistema 60 60 30 60 60 270

Tablas para almacenar

información de usuario60 0 0 0 0


interfaces para acceso a

datos

0 60 0 0 0


interfaces para

validaciones (Modelo de

negocio)

0 0 30 0 0

Construcción de clases

para control de eventos

de usuario y gestión de

excepciones

0 0 0 60 0

Construcción de pantalla

de autenticación0 0 0 0 60


Sp

rin

t 1

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.


Autenticación del

sistema 0 60 75 75 60 270


interfaces con método de

autenticación para

consulta de usuarios

registrados

0 60 0 0 0


interfaces para validación

de reglas de autenticación

0 0 60 0 0

Gestión de usuario en

sesión para evitar ataque

de acceso ilegal por URL

0 0 15 15 0

Construcción de clases

para control de eventos

de usuario y gestión de

excepciones de

autenticación

0 0 0 60 0

Construcción de pantalla

de autenticación0 0 0 0 60


Sp

rin

t 1


Registrar programa

académico 180 540 180 240 480 1620

Tablas para el registro de los

programas académicos180 0 0 0 0

Definifición de clases e

interfaces para el

almacenamiento de la

información de los programas

académicos

0 180 0 0 0

Adición de procedimientos

para recuperación de

programas académicos

registrados

0 180 0 0 0

Adición de procedimientos

para eliminación de programas

académicos registrados

0 180 0 0 0


interfaces para validación de

existencia de programas

académicos

0 0 180 0 0

Elaboración de clases e

interfaces para control de

eventos y gestión de

excepciónes en guardado y

borrado de programas

academicos

0 0 0 240 0

Implementación de formulario

para registro de programas

académicos

0 0 0 0 240

Implemetación de pantalla

para visualización de listado

de programas académicos

registros

0 0 0 0 240


Sp

rin

t 1

45


Registro de preguntas masivo 0 240 600 540 240 1620

Construcción de procedimiento

iterativo de cargue de preguntas a

la base de datos

0 240 0 0 0


de validación de estructura de

preguntas masivas a cargar

0 0 360 0 0


para lectura de archivo de

preguntas masivas

0 0 240 360 0

Construcción de procedimientos

para gestión de exceptiones y

mensajes en lectura de archivo

masivo de cargue

0 0 0 180 0

Adición de componentes para

disparar evento de cargue y

selección de archivo de preguntas

masivas

0 0 0 0 240


Sp

rin

t 1

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

2.1.3.2 Sprint 2


Registro de preguntas manual120 120 270 210 360 1080

Tablas para el registro de las

preguntas tipo ECAES120 0 0 0 0

Implementación de clases e

interfaces para el almacenamiento

de las preguntas

0 120 0 0 0


para recuperación de preguntas

almacenadas en el sistema

0 0 90 0 0


para eliminación de preguntas

almacenadas en el sistema

0 0 90 0 0



existencia de preguntas repetidas

0 0 90 0 0

Elaboración de clases e interfaces

para control de eventos y gestión

de excepciónes en guardado y

borrado de preguntas

0 0 0 210 0

Implementación de formulario

para registro de preguntas de

cada programa académico

0 0 0 0 180

Construcción de formulario para

presentación de preguntas

registradas al usuario

0 0 0 0 120

Construcción de elementos de

visualización de imágenes (aplica

para preguntas con imágenes

adjuntas

0 0 0 0 60


Sp

rin

t 2

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

46


Simulador de prueba 240 240 420 240 480 1620

Tablas para almacenar

información de la simulación en

curso

240 0 0 0 0


interfaces para carga de

preguntas de la simulación

0 240 0 0 0



respuestas correctas e

incorrectas

0 0 420 0 0



eventos de usuario y gestión e

excepciones de simulación

0 0 0 240 0


presentación de preguntas al

usuario

0 0 0 0 480


Sp

rin

t 2

Imagen # 24: Tabla de estimación de esfuerzo para creación de simulador de prueba. Fuente: propia, 2016.


Almacenamiento de

simulación 120 240 240 420 60 1080

Tablas y campos para controlar

el estado de una simulación en

curso

120 0 0 0 0


interfaces para almacenamiento

de estados que definen una

simulación en curso

0 120 0 0 0


para recuperar el estado de una


0 120 0 0 0



cantidad de ocasiones en las que

se ha guardado una simulación

en curso

0 0 120 0 0

Adición de procedimientos para

determinar el estado de una


0 0 120 0 0



eventos y gestión de excepciónes

en guardado del estado actual de

la simulación

0 0 0 240 0

Adición de advertencia para

cantidad de simulaciones

restantes

0 0 0 180 0

Adición de objeto gráfico de

evento para almacenar estado de

la simulacion en curso

0 0 0 0 60


Sp

rin

t 2

Imagen # 25: Tabla de estimación de esfuerzo para almacenamiento de simulaciones. Fuente: propia, 2016.

47


Contador de tiempo por

simulación120 120 300 300 240 1080

Definifición de tablas y atributos

en modelo de datos para guardar

tiempo disponible para respuesta

de simulación (parametros

configurables)

60 0 0 0 0


interfaces para el

almacenamiento de cantidad de

tiempo máximo para curso de

simulación (parámetros

configurables)

0 60 0 0 0

Construcción de interfaces y

clases para validación de

parámetro de tiempo máximo

por simulación

0 0 120 0 0

Implementación de clases e


eventos en parámetro de tiempo

por simulación

0 0 0 120 0


registro de parámetro de tiempo

máximo de simulación

0 0 0 0 120


para almacenar tiempo restante

para respuesta de simulación

60 0 0 0 0


para consulta de tiempo

disponible restante en respuesta

de simulación

0 60 0 0 0

Implementación de

procedimiento para validación de

tiempo agotado en ejecución de

simulación

0 0 180 0 0


para control de eventos y gestión

de excepciones en validación de

tiempo agotado para terminar

simulación

0 0 0 180 0


para redireccionamiento de

usuario a cuadro de estadísticas

al momento de agotarse el

tiempo de simulación

0 0 0 0 120


Sp

rin

t 2

Imagen # 25: Tabla de estimación de esfuerzo para crear contador de tiempo por simulación. Fuente: propia,

2016.

48


Cuadro de estadísticas 960 600 120 120 360 2160

Construcción de consultas SQL

para la extracción de relación

entre cantidad de simulaciones

cursadas vs aprobadas

320 120 0 0 0



entre cantidad de preguntas

formuladas vs respondidas

correctamente

320 120 0 0 0



entre cantidad de simulaciones

cursadas vs aprobadas

agrupadas por área de

conocimiento

320 120 0 0 0


interfaces para encapsulación de

consultas

0 240 0 0 0


interfaces para solicitud de

información a la capa de datos

0 0 120 0 0


interfaces de control de eventos

y gestión de excepciones en

cargue de información de

cuadros estadísticos

0 0 0 120 0


presentación de estadísticas0 0 0 0 360


Sp

rin

t 2

Imagen # 26: Tabla de estimación de esfuerzo para crear cuadro de mando y estadísticas. Fuente: propia,

2016.

2.1.4 Burn-down Chart

A continuación, se muestran las gráficas de estimación de esfuerzo para los dos Sprints

a realizar.

Imagen # 27:

Gráfica de

esfuerzo faltante

al inicio del Sprint

1. Fuente: Propia,

2016

49

Imagen # 28: Grafica de esfuerzo faltante al inicio del Sprint 2. Fuente: Propia, 2016

2.2 Diseño de la solución

Una vez culminada la etapa de análisis, donde se hace el levantamiento de

requerimientos, procedemos a describir las actividades pertinentes para el proceso de

diseño de aplicación y de base de datos.

2.2.1 Diseño de base de datos

Según los requisitos descritos en el numeral anterior del presente documento, se

realiza la construcción de un modelo semántico que permite identificar las posibles

relaciones entre las distintas “entidades” relacionadas en el proyecto. A continuación, se

hace una breve descripción de ellas:

Entidad Descripción

Usuario Entidad que describe las propiedades de los usuarios finales del sistema

Tipo de usuario Diferencia los tipos de usuarios que pueden usar el sistema. Esto se puede entender

como “perfiles”

Programa académico Área del conocimiento evaluada en las pruebas SABER PRO

50 Pregunta Componente que evalúa una competencia dentro de una prueba SABER PRO

Respuesta Opción de afirmación sobre una pregunta formulada.

Simulación Conjunto de preguntas y respuestas mostradas y elegidas respectivamente por un

usuario con perfil “estudiante”

Imagen # 29: Entidades identificadas para modelo semántico de datos. Fuente: Propia, 2016

A continuación, se muestra el modelo semántico definido según la descripción anterior.

Imagen # 30: Modelo semántico o entidad-relación del esquema de base de datos. Fuente: propia, 2016

Para efectos de conocer el modelo lógico establecido ya normalizado, se muestra el

modelo relacional de la aplicación, con los campos y relaciones necesarias para soportar la

construcción del prototipo de simulador.

51

Imagen # 30: Modelo relacional de base de datos del prototipo UDECAES. Fuente: Propia, 2016

2.2.2 Diseño de la aplicación

Para proporcionar una mejor orientación en la construcción de la aplicación, se

establecen los diagramas de actividades pertinentes para cada una de las historias de

52

usuario definidas en la etapa de análisis. A continuación se modelan las actividades de

acuerdo a las necesidades de cada proceso.

2.2.2.1 Diagramas de actividades

Imagen # 31: Diagrama de actividad para registro en el sistema. Fuente: propia, 2016

Imagen # 32: Diagrama de actividades para historia de usuario autenticación en el sistema. Fuente: propia,

2016

53

Imagen # 33: Diagrama de actividades para registro de programas académicos. Fuente: propia, 2016

Imagen # 34: Diagrama de actividades para registro masivo de preguntas. Fuente: propia, 2016

54

Imagen # 35: Diagrama de actividades para registro manual de preguntas. Fuente: propia, 2016

Imagen # 36: Diagrama de actividades para realización de simulación ECAES con contador de tiempo límite.

Fuente: propia, 2016

55

Imagen # 37: Diagrama de actividades para almacenar simulación parcialmente Fuente: propia, 2016

Imagen # 38: Diagrama de actividades para mostrar estadísticas de usuario Fuente: propia, 2016

56

2.2.2.2 Diagramas de secuencia

Imagen # 39: Diagrama de secuencia para registro de usuario en el sistema. Fuente: propia, 2016

Imagen # 40: Diagrama de secuencia para registro de usuario en el sistema. Fuente: propia, 2016

57

Imagen # 41: Diagrama de secuencia para registro de programas académicos. Fuente: propia, 2016

Imagen # 42: Diagrama de secuencia para registro de preguntas masivo. Fuente: propia, 2016

58

Imagen # 43: Diagrama de secuencia para registro de preguntas manual. Fuente: propia, 2016

Imagen # 44: Diagrama de secuencia para realizar simulación ECAES. Fuente: propia, 2016

59

Imagen # 45: Diagrama de secuencia para realizar simulación en curso. Fuente: propia, 2016

60

Imagen # 46: Diagrama de secuencia para contador de tiempo en cero. Fuente: propia, 2016

Imagen # 47: Diagrama de secuencia para obtener estadísticas. Fuente: propia, 2016

61

PARTE III. CIERRE DE LA INVESTIGACIÓN

CAPÍTULO 3. RESULTADOS Y DISCUSIÓN

A partir de la investigación realizada se pudo obtener como resultados:

- Evidencia de la falta de preparación extracurricular impartida por la Universidad

para preparar a los estudiantes para la presentación de la prueba SABER PRO.

- La información teórica – conceptual que permitió desarrollar el prototipo WEB

propuesto como producto de la presente investigación.

- La información sobre las competencias que evalúa el ICFES a través de la prueba

SABER PRO a los estudiantes de Ingeniería.

- El desarrollo del prototipo WEB.

CAPÍTULO 4. CONCLUSIONES

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

Al culminar la presente investigación, cuyo objetivo general planteado fue:

“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” se puede verificar, mediante el presente documento, que fue un objetivo

alcanzado de manera completa y exitosa.

Para alcanzar el objetivo general se propusieron 3 objetivos específicos (Ver Parte I,

Capítulo I, Objetivos) los cuales se concluye que fueron alcanzados ya que:

- Se identificaron los conocimientos y las competencias que evalúa la prueba SABER

PRO para estudiantes de Ingeniería.

- Se describió la estructura de las preguntas de la prueba SABER PRO para

estudiantes de Ingeniería de Sistemas.

62

- Se ejecutaron 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.

4.2 Síntesis del modelo propuesto

Con el objetivo de construir una solución integral a la pregunta de investigación que

dio como resultado el presente proyecto, se han adoptado los estándares vigentes de la

ingeniería de software para que los objetivos y los resultados sean medibles; Las etapas de

análisis y diseño fueron cuidadosamente detalladas en la observación de la necesidad

identificada y en el cómo convertirla en un producto de software que cumpla con los

requisitos identificados en la parte de conceptualización.

La etapa de análisis cumple con la observación de puntos clave en la parte

fundamental del proyecto (la identificación de puntos que permiten evaluar y reforzar las

competencias de los estudiantes próximos a convertirse en futuros profesionales),

plasmados a modo de requisitos identificados, medidos en esfuerzo temporal y con

herramientas que permiten realizar el seguimiento detallado de las actividades claves que

determinan el éxito del proyecto.

En la etapa de diseño se ha identificado, desde varios puntos de vista y según la

propuesta inicial, la forma correcta de construir el sistema de información propuesto. Los

esfuerzos fueron centrados de manera común para cualquier ingeniero de sistemas

globalmente preparado, con capacidad de interpretar la forma de realizar la implementación

con la descripción de los escenarios posibles e interacción de los elementos modelados en

el sistema a través de un lenguaje universal construido por ingenieros y para ingenieros; el

Lenguaje Unificado de Modelado (UML)

Así, con requisitos bien definidos (el “qué” del sistema) y la construcción de

escenarios e interacciones (el “como” del sistema) llevar a cabo la implementación ha sido

claro, sencillo y ha permitido generar un entregable en un tiempo relativamente corto,

manteniéndose fiel al concepto del manifiesto ágil plasmado con la metodología SCRUM.

63

4.3 Aportes originales

Más allá de buscar construir una aplicación que cumpla unos requisitos, se ha

pensado en la robusta estructuración de parámetros de la misma. Si bien hoy en día el

mercado se encuentra lleno de aplicaciones, también es cierto que el mantenimiento y

soporte de las mismas resulta altamente costoso y en algunos casos impagable. Es por esta

razón que se han invertido esfuerzos notables en la construcción de un modelo de datos que

permita parametrizar en la mayor medida posible el sistema para evitar largos tiempos en

modificaciones sencillas. Se ha orientado el desarrollo a un modelo de capas que permita

incluir nuevas funcionalidades para la aplicación, a su vez que permite realizar extensiones

sobre las ya existentes.

Se propone a la Universidad Distrital Francisco José de Caldas tomar la

implementación e instaurarla en la nube, para que la comunidad universitaria pueda tener

un beneficio directo del presente trabajo y así reforzar a los estudiantes próximos a salir a

un mercado laboral altamente competido y exigente.

4.4 Trabajos o Publicaciones derivadas

Se considera y se recomienda que, a partir de la presente investigación desarrollada y

finalizada se puedan iniciar los siguientes trabajos:

a. Se pueda desarrollar el prototipo planteado en esta investigación.

b. Se pueda probar el prototipo.

c. Se evalúe el rendimiento de los estudiantes de Ingeniería de Sistemas antes y

después de utilizar la aplicación WEB propuesta.

d. Se incluyan un banco de preguntas más robusto y completo al propuesto en el

prototipo.

e. Se incluyan otros perfiles profesionales con el fin de que otros programas

académicos de la universidad puedan también beneficiarse de la preparación

extracurricular para la prueba SABER PRO.

64

CAPÍTULO 5. PROSPECTIVA DEL TRABAJO DE GRADO

4.5 Líneas de investigación futuras

A partir del eje temático central de la presente investigación se pueden proponer dos líneas

de investigación:

a. Fortalecimiento de competencias extracurriculares.

b. Estrategias de Ingeniería para la preparación extracurricular.

c. Aporte de la Ingeniería de Sistemas a la Educación Superior.

4.6 Trabajos de Investigación futuros

Relacionado con el ítem 4.4 del presente documento, se considera que se pueden

llevar a cabo investigaciones con las siguientes preguntas problemas:

a. ¿Cuáles estrategias pueden incluirse en el aplicativo WEB para que sea más

didáctico?

b. ¿Cómo es la experiencia de los estudiantes en su entrenamiento realizado a partir

del aplicativo WEB diseñado?

c. ¿Cuál es el rango de mejora de los resultados de la prueba SABER PRO en

estudiantes que utilicen el aplicativo y los que no lo utilizaron?

65

REFERENCIAS BIBLIOGRÁFICAS

Centro Virtual de Noticias de la Educación (CVNE) (2010) Las Pruebas Saber Pro (antes

Ecaes), una ventaja competitiva en el campo laboral. Recuperado el 6 de febrero de 2016

de: http://www.mineducacion.gov.co/cvn/1665/w3-article-255873.html

Codd, E. (1970) A Relational Model of Data for Large Shared Data Banks. Revista:

Communication of the ACM. Vol. 13 N° 6.

Codd, E. (1990) The relational model for database management. Editorial: Addison-

Wesley Publishing Company, Inc.

Colombia Aprende (s/f) ¿Qué son los ECAES?. Recuperado el 24 de octubre de 2016 de:

http://www.colombiaaprende.edu.co/html/estudiantesuperior/1608/article-74133.html

El Observatorio de la Universidad Colombiana (s/f) Ingeniería de Sistemas. Recuperado el

24 de octubre de 2016 de: http://www.orangesys.net/webs/universidad/index.php/ecaes-

ranking-mainmenu-52/resultados-de-ingeniermainmenu-159/ingenierde-sistemas-

mainmenu-162

El Observatorio de la Universidad Colombiana (2010) Ubicación de las IES colombianas

según resultados de la prueba saber pro en 2010. Recuperado el 24 de octubre de 2016 de:

http://universidad.edu.co/images/cmlopera/descargables/ubicacion_de_las_ies_segun_result

ados_saberpro_2010.pdf

Guía Académica (2010) ¿Qué son las pruebas 'Saber Pro'?. Recuperado el 24 de octubre

de 2016 de:

http://www.guiaacademica.com/educacion/personas/cms/colombia/pregrados/2010/ARTIC

ULO-WEB-EEE_PAG-8260881.aspx

ICFES (2007) Funciones y deberes. Recuperado el 24 de octubre de 2016 de:

http://www2.icfes.gov.co/quienes-somos/funciones

ICFES (2009) Misión y Visión del Icfes. Recuperado el 24 de octubre de 2016 de:

http://www2.icfes.gov.co/quienes-somos/mision-y-vision

http://www.mineducacion.gov.co/cvn/1665/w3-article-255873.html

http://www.mineducacion.gov.co/cvn/1665/w3-article-255873.html

http://www.colombiaaprende.edu.co/html/estudiantesuperior/1608/article-74133.html

http://www.orangesys.net/webs/universidad/index.php/ecaes-ranking-mainmenu-52/resultados-de-ingeniermainmenu-159/ingenierde-sistemas-mainmenu-162



http://universidad.edu.co/images/cmlopera/descargables/ubicacion_de_las_ies_segun_resultados_saberpro_2010.pdf

http://universidad.edu.co/images/cmlopera/descargables/ubicacion_de_las_ies_segun_resultados_saberpro_2010.pdf

http://www.guiaacademica.com/educacion/personas/cms/colombia/pregrados/2010/ARTICULO-WEB-EEE_PAG-8260881.aspx

http://www.guiaacademica.com/educacion/personas/cms/colombia/pregrados/2010/ARTICULO-WEB-EEE_PAG-8260881.aspx

http://www2.icfes.gov.co/quienes-somos/funciones

http://www2.icfes.gov.co/quienes-somos/mision-y-vision

66

ICFES (2010) Guía: “Orientaciones para el examen de Estado de calidad de la educación

superior SABER PRO (ECAES). Ingeniería de Sistemas”. Recuperado el 24 de octubre de

2016 de:

http://www.acofi.edu.co/portal/documentos/Guia%20Ingenieria%20de%20sistemas%5B1

%5D.pdf

ICFES (2015) Presentación. Recuperado el 6 de febrero de 2016 de:

http://www.icfes.gov.co/index.php/quienes-somos

Menzinsky, A., López, G., Palacio, J. (2016) Scrum Manager. Guía de formación. Versión

2.6. Recuperado el 29 de noviembre de 2016 de:

http://www.scrummanager.net/files/scrum_manager.pdf

Ministerio de Educación Nacional de Colombia (s/f) Examen de Estado Para el Ingreso a

la Educación Superior ICFES. Recuperado el 6 de febrero de 2016 de:

http://www.colombiaaprende.edu.co/html/home/1592/article-156080.html

Ministerio de Educación Nacional de Colombia. Observatorio Laboral para la Educación

(2007) Ingeniería de Sistemas entre las más pedidas. Recuperado el 29 de octubre de 2016

de: http://www.mineducacion.gov.co/1621/article-136429.html

Oracle Inc. (s/f) The History of Java Technology. Recuperado el 1 de octubre de 2016 de:

http://www.oracle.com/technetwork/java/javase/overview/javahistory-timeline-

198369.html

Pressman, R. (2010) Ingeniería del software. Un enfoque práctico. Editorial McGraw Hill.

Séptima Edición. México

Quiroz, J. (2003) El modelo relacional de bases de datos. Boletín de Política Informática.

N° 6. Recuperado el 2 de noviembre de 2016 de:

http://www.doanalytics.net/Documents/Modelo_Relacional.pdf

Solid IT (2016) DB-Engines Ranking. Recuperado el 2 de noviembre de 2016 de: http://db-

engines.com/en/ranking

http://www.acofi.edu.co/portal/documentos/Guia%20Ingenieria%20de%20sistemas%5B1%5D.pdf

http://www.acofi.edu.co/portal/documentos/Guia%20Ingenieria%20de%20sistemas%5B1%5D.pdf



http://www.scrummanager.net/files/scrum_manager.pdf



http://www.mineducacion.gov.co/1621/article-136429.html

http://www.oracle.com/technetwork/java/javase/overview/javahistory-timeline-198369.html

http://www.oracle.com/technetwork/java/javase/overview/javahistory-timeline-198369.html

http://www.doanalytics.net/Documents/Modelo_Relacional.pdf

http://db-engines.com/en/ranking

http://db-engines.com/en/ranking

67

Top Univerties (s/f) Universidad Distrital Francisco José de Caldas. Recuperado el 24 de

octubre de 2016 de: http://www.topuniversities.com/universities/universidad-distrital-

francisco-jose-de-caldas#322891

Trigas, M. (s/f) Metodología SCRUM. Recuperado el 31/10/2016 de:

http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612memoria.

pdf

http://www.topuniversities.com/universities/universidad-distrital-francisco-jose-de-caldas#322891

http://www.topuniversities.com/universities/universidad-distrital-francisco-jose-de-caldas#322891

http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612memoria.pdf

http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612memoria.pdf

68

ANEXO A: Estimación de póquer (Planning Poker)

La estimación de póker es una técnica utilizada y popularizada por James Grenning con el

objeto de eliminar las dilatadas discusiones entre los miembros del equipo de desarrollo al

intentar realizar la conciliación de cuánto esfuerzo se hace necesario para la ejecución de

una actividad en un sprint. Según su propuesta inicial, cada miembro del equipo

participante en la estimación debe constar de un mazo de 7 cartas con los números 1, 2, 3,

5, 7, 10 e infinito

La idea es sencilla: En la estimación de cada tarea cada uno de los miembros del equipo

debe destapar una combinación de cartas cuya suma sea el resultado en horas del esfuerzo

que debe ser invertido para completar la tarea en cuestión. Cuando se considera que el

tamaño de esta tarea es más grande que la estimación inicial propuesta en la historia de

usuario, se debe destapara la carta de infinito. En caso de ser así, esta tarea debe

descomponerse en tareas de menor tamaño para así poder estimar su esfuerzo.

Existe una variante para este juego de estimación que se basa en la premisa de que cuando

la el tamaño de cada tarea aumenta, su incertidumbre también y junto con está crece el

margen de error en la estimación. La variante propone jugar el mismo juego, pero las cartas

solo contienen números de la sucesión de Fibonacci, y en esa medida, la estimación no se

realiza levantando varias cartas para componer la cifra exacta de esfuerzo sino una sola

carta que contiene la cifra más aproximada a la estimación. Así, al estimar una tarea una

persona debe considerar bien cuánto tiempo puede llevarle hacerla; bien sea por que con un

poco de esfuerzo puede hacerla en menos tiempo, o porque debe reconsiderar la cantidad de

esfuerzo a invertir y holgarse un poco para no caer en incumplimientos.

Imagen # 30: Mazo de cartas para la estimación de póquer. Imagen tomada de:

http://cdn.softwaretestinghelp.com/wp-content/qa/uploads/2016/05/planning-poker-cards.jpg

http://cdn.softwaretestinghelp.com/wp-content/qa/uploads/2016/05/planning-poker-cards.jpg

69

Se suele incluir una carta con una imagen de un signo de interrogación para indicar que, por

alguna razón no es posible realizar una estimación. También se puede incluir una carta con

una imagen alusiva a tomar un descanso.

En caso de que las estimaciones resulten muy distintas entre los miembros del equipo, se

deben discutir las razones de por qué se cree que una tarea pueda llevar más tiempo que a

otros, y reconsiderar la estimación con este razonamiento. En caso de no llegar a un

acuerdo, se debe procurar favorecer al equipo de trabajo, o bien descomponiendo la tarea en

tareas más pequeñas, o tomando la media de todas las estimaciones de los miembros del

equipo.

Bajo este orden de trabajo, se evita quedar atascados en largas discusiones que impiden el

avance de la estimación en el Sprint. Es una muestra de respeto hacia los puntos de vista de

todos los miembros que participan en el proyecto y permite rápidamente establecer

consensos sin discusiones, al mismo tiempo que dinamiza y hace más divertida la reunión.

Prototipo de aplicación web tipo simulador para el ...

Documents

Transcript of Prototipo de aplicación web tipo simulador para el ...