PLATAFORMA PARA LA EVALUACIÓN DE LA COMPRENSIÓN LECTORA Trabajo Fin de …tauja.ujaen.es/bitstream/10953.1/8856/1/Memoria_PereaDe... · 2019-03-09 · Escuela Politécnica Superior

Escu

ela

Polit

écn

ica S

up

eri

or

de J

aé

n

UNIVERSIDAD DE JAÉN Escuela Politécnica Superior de Jaén

Trabajo Fin de Grado



PLATAFORMA PARA LA

EVALUACIÓN DE LA

COMPRENSIÓN LECTORA

DEL ALUMNADO APLICADA A

TAREAS DE BÚSQUEDA DE

INFORMACIÓN EN LA WEB

Alumno: Javier Perea de la Casa Tutor: Prof. D. Fernando Javier Martínez

Santiago Dpto: Informática

Febrero, 2019

Javier Perea de la Casa Plataforma para la evaluación de la comprensión lectora del alumnado aplicada a tareas de búsqueda de información en la Web

2 Escuela Politécnica Superior de Jaén



Universidad de Jaén

Escuela Politécnica Superior de Jaén

Departamento de Informática

Don Fernando Javier Martínez Santiago , tutor del Proyecto Fin de Carrera titulado:

Plataforma para la evaluación de la comprensión lectora del alumnado aplicada a

tareas de búsqueda, que presenta Javier Perea de la Casa, autoriza su

presentación para defensa y evaluación en la Escuela Politécnica Superior de Jaén.

Jaén, FEBRERO de 2019

El alumno: El tutor:

Javier Perea de la Casa Fernando Javier Martínez Santiago



Índice Capítulo 1. Introducción ....................................................................................................... 7

1.1. Motivación ............................................................................................................... 7

1.2. Nivel esperado de comprensión lectora................................................................... 8

1.3. Niveles reales de comprensión lectora .................................................................... 8

1.3.1. Resultados del informe PISA sobre comprensión lectora en estudiantes de

secundaria...................................................................................................................... 8

1.4. Objetivos del proyecto ............................................................................................11

1.5. Concepto, uso e importancia de la Recuperación de Información Interactiva .........12

Capítulo 2. Descripción de los módulos que integra la plataforma ......................................14

2.1. Módulo I: Preprocesamiento de consultas y documentos .......................................14

2.1.1. Colecciones de documentos empleadas .........................................................15

2.1.2. Diseño de las consultas ..................................................................................16

2.2. Módulo II: Test de Fluidez Lectora .........................................................................17

2.2.1. El Test de Woodcock-Muñoz ..........................................................................18

2.2.2. Protocolo del Test de Fluidez Lectora .............................................................19

2.3. Módulo III: Plataforma PIR (Personalized Information Retrieval) para la evaluación

de la comprensión lectora .................................................................................................20

2.3.1. Protocolo de la plataforma PIR ......................................................................21

Capítulo 3. Proceso de desarrollo del software...................................................................22

3.1. Metodología utilizada: Scrum ..................................................................................23

3.1.1. ¿Por qué Scrum? ............................................................................................24

3.2. Comunicación .........................................................................................................24

3.2.1. Personal involucrado .......................................................................................25

3.3. Planificación ............................................................................................................26

3.3.1. Especificación de requisitos.............................................................................26

3.3.2. Aspectos técnicos ............................................................................................35

3.3.3. Riesgos posibles .............................................................................................36

3.3.3. Estimación de costes del proyecto...................................................................36

3.4.4. Estimación temporal del proyecto ....................................................................40

3.4. Modelado y diseño ..................................................................................................42

3.4.1. Arquitectura del sistema ..................................................................................43

3.4.2. Diagramas de máquina de estado ...................................................................45

3.4.3. Diagramas de flujo de datos (DFD) ..................................................................48

3.4.4. Diseño de la base de datos .............................................................................53

3.5. Construcción y evolución ........................................................................................62



3.5.1. Uso de tecnologías ..........................................................................................62

3.5.2. Estructura de directorios ..................................................................................64

3.5.3. Detalles de la implementación .........................................................................67

3.5.4. Pruebas realizadas y fallos encontrados .........................................................75

3.6. Despliegue y entregas ............................................................................................78

3.6.1. Sprints .............................................................................................................78

Capítulo 4. Interfaz .............................................................................................................80

4.1. Storyboards ............................................................................................................80

4.2. Metáforas visuales empleadas ................................................................................83

4.3. Usabilidad ...............................................................................................................85

4.3.1. Evaluación de la usabilidad .............................................................................86

4.4.3. Accesibilidad ...................................................................................................89

4.5. Uso del color en la interfaz ......................................................................................90

4.6. Capturas finales ......................................................................................................90

4.6.1. Módulo I – Test de Fluidez Lectora ..................................................................91

4.6.2. Módulo II – Plataforma PIR ..............................................................................93

Capítulo 5. Obtención y análisis de resultados ...................................................................98

5.1. Análisis e interpretación de los resultados ............................................................ 100

5.1.1. Módulo II: Test de Fluidez Lectora ................................................................. 100

5.1.2. Módulo III: Sistema PIR ................................................................................. 104

5.1.3. Mejores y peores participantes de los experimentos...................................... 113

5.1.4. Correlación de resultados entre experimentos ............................................... 115

5.2. Capturas resultado de consultas SQL lanzadas para la extracción de datos ........ 117

Capítulo 6. Futuros trabajos ............................................................................................. 122

6.1. Experimento con electroencefalogramas .............................................................. 122

6.2. Interfaz gráfica para la visualización de los resultados obtenidos.......................... 122

6.3. Sistema optimizado para plataformas móviles y tablets. ....................................... 123

6.4. Uso de Machine Learning para inferir conocimiento .............................................. 123

Capítulo 7. Conclusiones y valoración personal ............................................................... 124

7.1. Conclusiones ........................................................................................................ 124

7.2. Valoración personal .............................................................................................. 125

Bibliografía ....................................................................................................................... 126

Anexo A. Manual de instalación ....................................................................................... 128

Anexo B. Índice de ilustraciones ....................................................................................... 132

Anexo C. Índice de tablas ................................................................................................. 134





Capítulo 1

Introducción

1.1. Motivación

La información textual es uno de los recursos humanos más antiguos que

caracterizan la comunicación del ser humano. Aunque la propagación de la

información textual ha evolucionado a lo largo de la historia humana: inscripciones en

piedra, en papel... no fue hasta la creación de la World Wide Web por Tim Berners-

Lee cuando la información comenzó a pasar de tener un carácter restringido de menor

accesibilidad (la consulta de información debía hacerse a través de enciclopedias,

libros...etc) a un carácter universal e interconectado.

Día tras día, la globalización y extensión de la información textual es cada vez

mayor gracias a la WWW, teniendo al alcance una cantidad ingente de información

incluso sin percatarnos de ello. En el mundo académico y profesional, los estudiantes

de universidades e institutos hacen de esta plataforma su principal recurso de

búsqueda de información textual, puesto que el acceso es rápido y basta con una o

varias consultas en el motor de búsqueda hasta que uno de los documentos más

relevantes recuperados se corresponda con lo que se busque.

Sin embargo, la accesibilidad a la información no garantiza su comprensión, y en

el proceso educativo, la comprensión lectora es un factor determinante para que el

alumnado pueda desarrollar sus capacidades cognitivas para así poder extraer

conclusiones de la información leída que fomenten la tarea del aprendizaje en la

materia que esté consultando.

Las preguntas que nos llegaremos a plantear, por lo tanto, serán:

¿En qué nivel los alumnos de universidad y secundaria nos consideramos

consumidores pasivos de información textual, cuál es el nivel de atención que

prestamos generalmente a los textos que consultamos?, ¿Cómo influye la

comprensión lectora en el rendimiento académico?



1.2. Nivel esperado de comprensión lectora

El informe PISA establece [1] que el umbral para determinar el nivel esperado

de comprensión lectora (los niveles más bajos de rendimiento en lectura establecidos

por PISA se sitúan por debajo de este nivel) se sitúe en la evaluación de una serie de

tareas:

• El lector debe localizar uno o más fragmentos de información, mediante

inferencias.

• Reconocimiento de la idea principal de un texto, la comprensión de las

relaciones, o la interpretación de su significado dentro de una parte

limitada del texto cuando la información no está destacada.

• En ocasiones se pueden incluir comparaciones o contrastes basadas en

una sola característica del texto.

• Se espera que los lectores realicen una comparación o varias conexiones

entre el texto y el conocimiento exterior, y hagan uso de la experiencia y

actitudes personales.

Satisfaciendo dichas tareas, se puede decir que ya se superan los niveles

inferiores de rendimiento en el ámbito de la comprensión lectora, y por lo tanto,

satisface el nivel mínimo esperado de comprensión lectora.

1.3. Niveles reales de comprensión lectora

1.3.1. Resultados del informe PISA sobre comprensión lectora en

estudiantes de secundaria

Los datos recopilados de nuestro interés por el informe PISA del 2015 [1]

evalúan los niveles de rendimiento correspondientes a la escala de lectura sobre un

alumnado de 15-16 años (la mayoría escolarizados en 4º ESO). Cabe destacar que el

informe PISA se realiza con una frecuencia de 3 años por lo que, los resultados del

mismo en 2018 aún no han sido publicados.

Según el informe PISA los países que presentan mejor rendimiento en lo que

concierne a las aptitudes lectoras están encabezados por Irlanda, siendo el país con



el porcentaje menor (10,2%) de alumnos con niveles más bajos de rendimiento,

siguiéndoles países como Estonia (10,6%), Canadá (10,7%), Singapur (11,1%) y

Finlandia (11,1%). España presenta un porcentaje del 16,2% de alumnos de 15 años

que se encuentran en los niveles más bajos de rendimiento en lectura, mientras que

en el conjunto de países de OCDE este porcentaje se eleva al 20,1%, y el total de la

UE, a su vez, se sitúa en el 19,7%.

Estos porcentajes justifican que, el número alumnos que están por debajo de su

rendimiento en lectura es menor en España, pues España consigue una puntuación

media (en cuanto a alumnos que se encuentran en niveles inferiores de la

competencia) ligeramente inferior a la de la OCDE (Organización para la Cooperación

y el Desarrollo Económicos, compuesta por 37 estados de ámbito internacional) y a la

Unión Europea. En las comunidades autónomas, las mejores puntuaciones en lectura

corresponden a Castilla y León, seguido de Comunidad de Madrid, Navarra y Galicia,

presentando éstos puntuaciones significativamente superiores al promedio del

conjunto de países de la OCDE.

Por otra parte, el porcentaje de los alumnos con un mayor rendimiento en lectura

en España es del 5,5%, inferior en 2,8 puntos porcentuales al promedio OCDE (8,3%)

y en 3,2 puntos porcentuales al promedio de la UE (8.7%).

España muestra una proporción de alumnos rezagados en lectura inferior a la

OCDE y a la Unión Europea (16% frente al 20%, de ambos), lo que podría

interpretarse como un indicador de mayor equidad, es decir mayor uniformidad en

cuanto a las capacidades lectoras del alumnado.

En el informe PISA 2015, como en ediciones anteriores, se siguen observando

diferencias de rendimiento por género. En lectura, las chicas muestran un rendimiento

significativamente más alto que los chicos en todos los países analizados (no sólo

España), sin excepciones.



Ilustración 1. Niveles de Puntuación en la prueba de Comprensión Lectora

Los datos que arroja el Informe PISA 2015 sobre Lectura para España [2] son

históricos ya que nuestro país consigue una puntuación media de 496, lo que supone

3 puntos por encima de la OCDE (493). Es la primera vez desde que se realiza el

estudio que España se sitúa por encima de la media en Lectura y se coloca al nivel

de los países más avanzados en esta materia.



1.4. Objetivos del proyecto

Usando como base el informe PISA, nuestro proyecto consistirá en el desarrollo

de una plataforma que web que permita al alumnado realizar un test de comprensión

lectora, y su evaluación en tareas concretas asociadas a la captura de información a

través de recursos disponibles en la web, como diarios.

Los objetivos del presente trabajo son los siguientes:

• Revisión de corpus etiquetados con la complejidad textual del texto, tal como

Newsela.

• Creación de un corpus propio para la evaluación de la comprensión lectora.

• Desarrollo de un módulo para capturar información del perfil de usuario.

• Desarrollo de un módulo para aplicar el test de comprensión lectora de

Woodcock-Muñoz.

• Desarrollo de un módulo para evaluar y contrastar la comprensión lectora del

alumno en tareas relacionadas con la búsqueda de información en la web.

• (Opcional) Desarrollo de un módulo para obtener información estadística a

partir de la evaluación que ha completado tanto el test como la tarea de

comprensión.

El proyecto tiene el propósito de verificar, evaluar y mostrar a modo comparativo,

los distintos niveles de comprensión lectora de los estudiantes de secundaria y

universidad.

Nos basaremos en informes oficiales para justificar si los resultados presentados

en ellos se corresponden con los resultados extraídos de la plataforma o mantienen

cierta analogía.



1.5. Concepto, uso e importancia de la Recuperación de

Información Interactiva

A grosso modo, cuando se habla de Recuperación de Información (IR) se hace

referencia a lo siguiente:

• Obtención de una colección de documentos que generalmente

constituyen un subconjunto de una colección mayor, ordenados bajo una

determinada condición (generalmente por relevancia) en base a la

consulta que lanza un usuario.

Por ello, resulta sencillo deducir que la Recuperación de Información constituye

el eje central de los motores de búsqueda Web (Google, Bing, etc).

Ilustración 2. Esquema general de un Sistema de Recuperación de Información

Tanto la consulta como los documentos no tienen por qué ser exclusivamente

textuales, éstos se pueden presentar en forma de audio, vídeo e imagen. En el

proyecto, solamente se abarcará el ámbito textual, ya que la comprensión lectora

depende exclusivamente del factor textual.

De la misma manera, se nos presenta la Recuperación de Información Interactiva

(IIR) que podríamos definirla de la siguiente manera:

• Estudio de técnicas por las que el intelecto humano interviene en el

proceso de búsqueda, es decir, donde existe una acción más allá de la

recepción de información. [3]



En el proyecto, se pretende que dicha Recuperación de Información tome un

carácter interactivo, es decir que el usuario participe activamente no sólo explorando

documentos, si no también interactuando con los mismos. Para ello, detallaremos la

importancia y las razones de su uso en la plataforma.

El concepto de Recuperación de Información es esencial en el desarrollo de

nuestra plataforma, puesto que la comprensión lectora de un texto dependerá en gran

medida de cómo se le presentan los documentos al usuario. Es decir, no podemos

obtener resultados significativos de una interacción del usuario con la herramienta de

recuperación de información, si ésta no está bien construida. Por lo tanto, será

fundamental una buena construcción de la herramienta para que el participante ejerza

correctamente la interacción sobre ella, facilitando el acceso a los documentos y

garantizando que pueda entender semánticamente el texto que se dispone a leer.

En nuestro proyecto, el participante lanzará una consulta e interactuará con los

documentos presentados no sólo visitándolos sino también evaluándolos y

considerándolos como relevantes o irrelevantes. Esta interacción podría llegar a

mejorar la eficacia de un sistema de Recuperación de Información en base a la

relevancia dada a los documentos por usuarios expertos en las consultas lanzadas.

Ilustración 3. Esquema de un Sistema de Recuperación de Información Interactivo

Nuestra plataforma registrará los distintos eventos que el participante realice

sobre los documentos leídos (directa o indirectamente), para que así a través de la

interacción, se puedan recopilar datos y extraer resultados relevantes con los que

podamos medir y contrastar la comprensión lectora del alumnado.



Capítulo 2

Descripción de los módulos que

integra la plataforma

Antes de detallar el ciclo de vida de nuestro proyecto software se realizará una

descripción de los distintos módulos, así como de los recursos que completarán el

proyecto en su conjunto, para que el lector adopte cierta noción y conocimiento de en

qué va a consistir y cómo se va a estructurar el proyecto a desarrollar.

2.1. Módulo I: Preprocesamiento de consultas y

documentos

Esta sección consistirá en el desarrollo de un corpus o una colección consulta-

documentos resultado de la combinación de 3 fuentes de información, ClueWeb,

Newsela y Google. El desarrollo de este módulo es totalmente indispensable para

que el Módulo III pueda llevar a cabo la tarea de recuperación de información.

Cabe destacar que la colección inicial tendría un tamaño de 100 documentos por

consulta (en su mayoría documentos ClueWeb) ordenados por ranking, optando por

sustituir los 5 primeros documentos irrelevantes encontrados de ClueWeb por

documentos de Google asociados a la consulta.

Cada una de las 20 consultas previamente definidas, se lanzarán sobre ClueWeb

mediante un rastreador web que recupere las páginas HTML relacionadas con la

consulta enviada; esto lógicamente debe de ser preprocesado para obtener el texto

plano que contenga exclusivamente la información que el texto pretende transmitir.

Así mismo, las consultas se lanzan sobre Newsela y Google y se extrae

manualmente el texto derivado del documento.

Sin embargo, debido a las complicaciones surgidas a raíz de la ilegibilidad que

presentan la gran mayoría de textos de ClueWeb, donde la codificación textual (ver

más Construcción e Implementación) mantiene en la gran mayoría de documentos un

número considerable de caracteres de reemplazamiento (� - En Unicode: U+FFFD)



que presentan siempre el mismo valor en cualquier formato de caracteres, haciendo

imposible que se pueda aplicar un formato determinado para decodificar este carácter

en una letra o símbolo legible.

La primera solución viable que encontramos fue la de eliminar dicho carácter de

reemplazamiento, sin embargo, no solo teníamos el problema de la codificación de

caracteres. Los textos mantenían en gran parte de las ocasiones formatos de

codificación de texto distintos (Latin-9, UTF-8…), y al usar herramientas de

preprocesado HTML para extraer el texto plano del documento; había ocasiones en

las que los documentos HTML mantenían una estructura de etiquetas anómala que

nos hacía extraer texto que no tuviera nada que ver con el propósito del mismo

(breadcrumbs, índices de página, funciones JavaScript…).

Debido a que nos interesa que los distintos documentos que vayan a formar el

corpus sean totalmente legibles para que su uso en el módulo III por parte de un

usuario sea medianamente fluido, optamos por descartar el corpus ClueWeb, dejando

solo los conjuntos que conforman Google y Newsela.

Finalmente, por esta razón se opta por cambiar el tamaño de la colección final,

debido a que tendrá 20 documentos por cada una de las 20 consultas.

2.1.1. Colecciones de documentos empleadas

2.1.1.1. Newsela

Newsela es una Plataforma de Contenido Educativo [4] que sobrealimenta el

compromiso de lectura y aprendizaje en todas las materias. Asimismo, Newsela pone

a disposición recursos para la investigación sobre la dificultad del texto, la

simplificación del texto y otras disciplinas que ayudan a facilitar una mayor

accesibilidad al proceso de comprensión del texto escrito.

El corpus de Newsela incluye miles de artículos de noticias profesionalmente

adaptados a diferentes complejidades de lectura.

A grosso modo, cada documento Newsela distinguimos dos partes principales

que clasifican a cada documento:



1. Nivel de Complejidad: Los documentos de Newsela tendrán hasta cinco

niveles de complejidad (0: más complejo – 4: menos complejo), conforme

mayor sea el nivel, más simplificada estará la información respectiva a ese

documento, es decir, la información pasa a ser un subconjunto del nivel

anterior.

2. Juicio de relevancia: La relevancia (0 no relevante, 1 relevante) de cada

documento conlleva analizar el documento hasta el punto de encontrar

información significativa a la consulta asociada, es decir, que permita dar

respuesta en mayor o menor medida a la pregunta-consulta que se plantea.

2.1.1.2. ClueWeb

La colección de documentos ClueWeb fue creada para apoyar la investigación

en torno a la recuperación de información y las tecnologías relacionadas con el

lenguaje humano. Consiste en unos 1000 millones de páginas webs en 10 en diez

idiomas que se recopilaron en enero y febrero de 2009. [5]

La colección es utilizada por diversas actividades organizadas en la conferencia

TREC (Text REtrieval Conference).

2.1.2. Diseño de las consultas

En cuanto a la elaboración de las consultas se han definido los siguientes pasos:

• Tenemos que ser cuidadosos en que no sean ni excesivamente genéricas

ni excesivamente precisas. Que las haya más o menos factuales (por

ejemplo, "empresas creadas por adolescentes" pero también más

abstractas ("estrategias para luchar contra la obesidad infantil").

• Hay que poner consultas que no necesariamente coincidan con el tema

principal del documento, si no que sea algo que en el mismo se pueda

llegar a comentar con cierto grado de adyacencia.

• Los campos que conformarán cada consulta vendrán dados desde un

comienzo en formato XML con los siguientes campos:



o Num: identificador de la consulta

o Title: título de la consulta

o desc: descripción de la consulta

o auth: autor de la consulta

o lang: idioma de la consulta

Ilustración 4. Ejemplo de consulta en XML

2.2. Módulo II: Test de Fluidez Lectora

El experimento correspondiente al Test de Fluidez Lectora formará parte

explícita de lo que sería la plataforma web experimental a desarrollar (constituida por

los módulos II y III).

Como su propio nombre indica, el principal propósito del test es proporcionar al

cliente de nuestra plataforma una herramienta que le permita poder evaluar no sólo si

las afirmaciones son correctamente evaluadas, sino también la rapidez con la que se

contesta a las preguntas.

Así pues, podemos decir que este experimento puede garantizar al cliente un

medio para evaluar la relación que existe entre la rapidez con la que el usuario

responde y la comprensión lectora derivada de responder correcta o incorrectamente

a las afirmaciones.



Este experimento constituye una serie de afirmaciones a evaluar extraídas

directamente del Test de Woodcock-Muñoz, estas oraciones dispondrán de un

carácter booleano en su evaluación (Verdaderas o Falsas), siempre bajo un marco

temporal de 3 minutos; si el participante del experimento excede los 3 minutos en el

test, éste finalizara automáticamente, dando paso a un formulario de datos

personales.

2.2.1. El Test de Woodcock-Muñoz

El Test de comprensión lectora de Woodcock-Muñoz consiste en un subconjunto

de preguntas perteneciente a la Batería III de Woodcock-Muñoz, Dicha batería de

preguntas está basada en la traducción al castellano de la batería original,

desarrollada en inglés, Woodcock-Johnson III. [6]

Ilustración 5. Ficha técnica de la batería III de Woodcock-Muñoz

Se trata de una técnica de amplio uso internacional para poder evaluar aspectos

educacionales, clínicos (desarrollo cognitivo) y de investigación en distintos campos

de la cognición humana, como lo son la habilidad lectora, matemática, el lenguaje

escrito y el oral.

Cabe destacar que la edad de la población sobre la que se enfocan las

preguntas es totalmente determinante para poder llevar a cabo un análisis que permita



hacer una estimación del desarrollo cognitivo en esa franja edad, o bien una predicción

de logro académico, en caso de ser estudiantes.

Nuestro propósito, abarcará el subconjunto de preguntas de la batería que

permitan medir la comprensión lectora, en concreto, la fluidez lectora del alumnado,

principalmente universitario. A través de la recopilación de sus respuestas y datos

personales, se buscará entender, analizar y determinar los resultados para extraer

conclusiones relevantes sobre los mismos.

2.2.2. Protocolo del Test de Fluidez Lectora

El Test de Fluidez Lectora formará parte del módulo II de nuestra plataforma y

estará basado como se ha mencionado previamente, en un conjunto de frases

garantizadas por el Test de Woodcock-Muñoz, concretamente extraídas del campo

que mide la habilidad lectora.

A continuación, se detallarán los distintos pasos a seguir que deberá satisfacer

el participante de nuestro Test para poder completarlo:

1. Se le informa de las condiciones del Test, con algún ejemplo. Es decir, antes

de comenzar el Test el participante podrá leer los requisitos que se necesitan

para completarlo satisfactoriamente.

2. Se deben dar respuesta a 4 o 5 frases de ejemplo, para que así el participante

pueda tener cierta noción de la interacción con las respuestas antes de

comenzar el Test.

3. Se pulsa "Empezar Test" en el momento que estén las frases de ejemplo

resueltas, no antes.

4. Si alguna frase de ejemplo está mal resuelta por el usuario se le notifica y

continua con las frases de ejemplo.

5. Se le muestra el listado de frases oficiales a evaluar, con las opciones

Verdadero/Falso para cada una. El usuario tendrá 3 minutos para evaluar todo

el listado de frases.

6. A los tres minutos se le advierte que acabó el Test, y se da paso al formulario

de perfil de usuario.



Las sentencias que debe evaluar el participante serán afirmaciones muy simples

y sencillas que el participante debe leer y responder rápidamente para no sobrepasar

los 3 minutos de tiempo límite.

Algunas frases modelo a evaluar en la prueba son las siguientes:

La manzana es azul V | F

El sol está en el cielo V | F

El hombre tiene dos piernas V | F

El hielo es caliente V | F

La importancia principal de realizar este Test en lo que respecta a nuestro

proyecto es contrastar y medir la agilidad lectora del participante, pues la rapidez en

la lectura es un factor fundamental en la tarea que concierne a la comprensión de

textos.

Por último, cabe mencionar que, el participante debe hacer uso del sentido

común general para responder correctamente a las preguntas, es decir, no debe

plantearse por ejemplo en la pregunta “El hombre tiene dos piernas” que no todos los

hombres tienen dos piernas, puesto que lo normal es que sí que las tengan.

2.3. Módulo III: Plataforma PIR (Personalized Information

Retrieval) para la evaluación de la comprensión

lectora

La plataforma PIR para evaluar la comprensión lectora constituirá el último

experimento que conforma la plataforma web de la comprensión lectora. Éste estará

basado en la propia aplicación de la tarea de la recuperación de información

interactiva, previamente mencionada en el punto 1.4. Concepto, uso e importancia de

la Recuperación de Información, concretamente en una interacción del usuario basada

en la evaluación de una serie de documentos como relevantes o irrelevantes.



2.3.1. Protocolo de la plataforma PIR

El participante que desee intervenir en esta sección de nuestra plataforma web

debe seguir una serie de pasos para poder completar el experimento correctamente.

Podemos resumir las distintas etapas por las que se lleva a cabo en las siguientes:

1. Inicio de sesión: para poder acceder al experimento se requiere un ID de

participante.

2. Exploración de documentos: se va lanzando cada consulta y se visitan

algunos los documentos que se recuperan ordenados por ranking. No es

indispensable que el participante visite documentos, pero es severamente

recomendable para las posteriores fases Resumen de lo aprendido y

Evaluación de Documentos

3. Resumen de lo aprendido: se da una respuesta a la consulta lanzada en

base a los documentos explorados.

4. Evaluación de documentos: se presenta una serie de documentos que el

participante debe evaluar como relevantes o no relevantes.

Los documentos se presentan de uno en uno y hasta que no emita su juicio

de relevancia no puede acceder a evaluar el siguiente documento.

5. Finalizar sesión: se terminan de evaluar los documentos para una consulta,

pero todavía no se han lanzado las 20 consultas.

6. Finalizar experimento: se han evaluado todos los documentos

correspondientes a las 20 consultas disponibles.



Capítulo 3

Proceso de desarrollo del software

En los últimos 50 años, el software ha pasado de ser la solución de un problema

especializado y herramienta de análisis de información a una industria en sí misma.

Por ello, siguen apareciendo problemas para desarrollar software de alta calidad en

un tiempo razonable bajo un determinado marco económico de presupuesto. Para

ello, se desarrolla el campo denominado ingeniería de software que IEEE define como

[7]:

• La aplicación de un enfoque sistemático, disciplinado y cuantificable al

desarrollo, operación y mantenimiento de software; es decir, la aplicación

de la ingeniería al software.

• El estudio de enfoques según el punto 1)

La ingeniería de software está constituida por procesos, métodos y herramientas

que facilitan la elaboración a tiempo y con calidad de proyectos basados en software.

Las tareas fundamentales que constituyen el proceso de software podrían resumirse

en: comunicación, planificación, modelado, construcción y despliegue. [7]

Sin embargo, el ambiente moderno de negocios que genera sistemas basados

en computadora y productos de software evoluciona rápida y constantemente, no

basta con definir un conjunto de paradigmas si el software requiere cambios

inmediatos. Es por ello, que la denominada ingeniería de software ágil representa una

alternativa razonable a la ingeniería de software convencional en diversas situaciones.

Asimismo, se ha demostrado que la ingeniería de software ágil concluye con

rapidez sistemas exitosos donde el equipo ágil concuerda en que el proceso funciona

y en que produce incrementos de software utilizables que satisfagan a cliente.

Concretamente, nuestro proyecto requiere que los cambios en el mismo se

hagan de la forma más rápida posible, por lo que se ha optado por adaptar el

desarrollo software a una perspectiva ágil, facilitando una entrega rápida de software

incremental.



3.1. Metodología utilizada: Scrum

Para el desarrollo del trabajo, se ha optado por usar como metodología ágil

Scrum, un marco de trabajo por el cual las personas pueden acometer problemas

complejos adaptativos, a la vez que entregar productos del máximo valor posible

productiva y creativamente [8]. Según la ilustración 6, el flujo del proceso Scrum es

el siguiente, aunque las reuniones Scrum serán llevadas a cabo cada 3-4 días, y no

diariamente:

Ilustración 6. Patrones de proceso del método Scrum

• Retraso ó backlog: lista de requisitos que se van definiendo y

manipulando a lo largo de la vida del proceso software. Se puede agregar

en cualquier momento otros aspectos al backlog (siendo ésta la forma en

la que se introducen cambios). El Scrum Master del proyecto evaluará el

retraso y actualizará las prioridades según se requiera.

• Sprints: Intervalo de tiempo de máximo un mes, en donde se desarrolla

el incremento de un producto, potencialmente entregable.

• Reuniones Scrum: reuniones breves (de 15 minutos por lo general), que

efectúa el equipo de trabajo cada cierto tiempo. En nuestro caso, con

intervalo variable cada 3-7 días.



3.1.1. ¿Por qué Scrum?

Tras definir la estructura de esta metodología ágil, detallamos las distintas

razones que justifican el uso de Scrum en nuestro proyecto:

• Scrum es ligero y fácil de entender, además, acentúa el uso de patrones

de proceso del software (que describen las tareas del marco de trabajo)

que han demostrado ser eficaces para proyectos con plazos de entrega

muy apretados y requerimientos cambiantes.

• Las reuniones Scrum bajo periodos de tiempo cortos ayudarán al

descubrimiento de problemas potenciales tan pronto como sea posible.

• A diferencia de otras metodologías ágiles como pueden ser Programación

extrema (XP) donde se recomienda que las tareas de programación se

lleven a cabo por parejas; en Scrum, cada miembro del equipo trabaja de

forma independiente al resto, garantizando una estructura de equipo con

organización propia. Esto, por lo tanto, deriva en una mayor autonomía de

desarrollo software.

A continuación, indagaremos en el papel que han jugado cada una de las tareas

estructurales en el desarrollo de nuestra Plataforma para la evaluación de la

Comprensión Lectora.

3.2. Comunicación

Es necesario colaborar desde un comienzo con el cliente (y con otros agentes)

para comprender los objetivos que se establecen en el proyecto, y así, poder reunir

los requerimientos necesarios para formalizar las funciones y características del

software.

Al tratarse de una plataforma experimental, el cliente lo constituye el equipo de

investigación o profesorado que desea usar el sistema para recopilar los datos y así

generar información. Para ello, la comunicación debe establecerse en este caso con

psicólogos y profesores que definan correctamente las tareas a seguir por la población

objetiva (estudiantes de universidad) y que, asimismo, coordinen el proceso.



Así pues, los clientes con los que se mantenido este proceso de comunicación

son el profesor Fernando Javier Martínez Santiago del área de Lenguajes y Sistemas

Informáticos perteneciente al grupo de investigación Sistemas Inteligentes de Acceso

a la Información, y el profesor Nicolás Gutiérrez Palma del área de Psicología

Evolutiva y de la Educación.

Cabe también considerar la participación en el proyecto del desarrollador

Francisco Javier Collado Barrachina, alumno de Formación Profesional dentro del

módulo I del proyecto.

3.2.1. Personal involucrado

Nombre Javier Perea de la Casa

Rol Desarrollador principal del proyecto

Profesión Estudiante

Responsabilidades Diseñar e implementar la plataforma para la

evaluación de la comprensión lectora del alumnado

aplicada a tareas de búsqueda de Información Web

Nombre Fernando Javier Martínez Santiago

Rol Jefe de Proyecto

Profesión Profesor e investigador de la Universidad de

Jaén

Responsabilidades Dirigir el desarrollo del proyecto

Nombre Nicolás Gutiérrez Palma

Rol Colaborador de Proyecto

Profesión Profesor e investigador de la Universidad de Jaén

Responsabilidades Orientar el proceso cognitivo en aspectos psicológicos

de la plataforma



Nombre Francisco Javier Collado Barrachina

Rol Colaborador auxiliar del Proyecto

Profesión Estudiante

Responsabilidades Combinación de corpus ClueWeb y Newsela

supervisado por el desarrollador principal.

Por lo tanto, el equipo Scrum lo conformarán Javier, Fernando, Nicolás y

Francisco Javier que serán con los que se mantendrán las reuniones presenciales

donde para cada sprint del producto, se han ido redefiniendo los objetivos y

requerimientos del producto. A parte de dichas reuniones presenciales, se han usado

otros medios de comunicación vía web para el control del proyecto como lo ha sido

GitLab, mediante asignación de Issues o tareas específicas, o bien, mediante emails

a través de Gmail (generalmente para dudas muy puntuales).

3.3. Planificación

En esta sección describiremos los distintos requisitos que deberán satisfacerse

para otorgar cierto grado de consistencia a nuestro sistema, así como los aspectos

técnicos a desarrollar, posibles riesgos, recursos requeridos, productos de trabajo que

se obtendrán y una planificación de las actividades a realizar.

3.3.1. Especificación de requisitos

Para el desarrollo de nuestro sistema, la principal función que nos aportará el

Backlog será la de definir una lista priorizada de requisitos basados en historias de

usuario (descripción de una funcionalidad que debe incorporar un sistema de software

en lenguaje natural) más o menos detalladas. [9]

También definimos los distintos requisitos funcionales y no funcionales de

nuestro sistema:

• Requisito Funcional: Especifica una acción que debe ser capaz de

realizar el sistema.



• Requisito No Funcional: Especifica propiedades del sistema, como

restricciones de entorno o de implementación, rendimiento,

mantenibilidad, extensibilidad o fiabilidad.

Para definir los requisitos funcionales nos apoyaremos en los diagramas de caso

de uso del módulo II y el módulo III.

Para definir el listado de características del producto que desea el cliente con

prioridad se agruparán las historias de usuario mediante el método MoSCoW [9], que

podría traducirse como:

• “imprescindibles” (Must Have)

• “importantes” (Should Have)

• “interesantes” (Could Have)

• “opcionales” (Won’t Have and Would Have)

En esta sección describiremos la lista de tareas identificadas por el equipo Scrum

que deben ser completadas durante el sprint correspondiente para cada uno de los

módulos. Si se desea leer cada uno de los sprints que se han realizado durante la

realización del proyecto, visite el apartado Despliegue y Entregas.

3.3.1.1. Módulo I: Preprocesamiento de consultas y documentos

Esta fase la ha desarrollado el desarrollador principal Javier Perea con la

intervención de los miembros del equipo, Fernando Martínez y Francisco Javier

Collado.

En la fase de preprocesamiento, no se han realizado diagramas de Casos de

Uso ya que ésta no forma parte de la plataforma web de comprensión lectora, sino

que es una fase previa a lo que es la propia aplicación web.



ID Descripción requisito Prioridad Tipo Sprint Asignado a

1 Se deben redactar las

consultas que se van a lanzar

Imprescindible Funcional 3 Fernando

2 Recuperar los documentos

ClueWeb asociados a las

consultas a través de crawler

Importante Funcional 3 Javier y Francisco

3 Hacer uso de bibliotecas

específicas para tratamiento

de texto HTML de ClueWeb

(BeautifulSoup)

Imprescindible No

funcional

3 Javier

4 El corpus final de

documentos debe constar de

100 documentos por consulta

Interesante No

funcional

3 Javier y Francisco

5 Sustituir manualmente

documentos irrelevantes por

documentos Google si se

encuentran entre los 5

primeros

Importante Funcional 3 Francisco

6 Combinar documentos de

Newsela, Google y ClueWeb

en corpus final

Interesante Funcional 3 Francisco

7 Los documentos recuperados

de ClueWeb deben de ser

legibles

Interesante (no

satisfecho)

No

funcional

3 Javier

8 Corpus final debe estar

formado por documentos

Newsela + Google (Se

eliminan ClueWeb por

ilegibles)

Imprescindible No

funcional

5 Javier

9 El corpus final de

documentos debe pasar de

100 a 20 documentos

Importante No

funcional

5 Javier

10 Todos los documentos deben

tener un título

Interesante No

funcional

5 Javier



3.3.1.2. Módulo II y III: Sistema-Plataforma web

Distinguiremos dos roles principales, el participante y el administrador-

controlador. Todos los requisitos serán asignados al desarrollador principal.

Los requisitos no funcionales serán comunes en los módulos II y III de la

aplicación, ya que las propiedades del sistema deben ser semejantes al formar parte

del mismo experimento y servir a un mismo propósito, la evaluación de la comprensión

lectora. Por lo tanto, definimos los siguientes requisitos no funcionales:

El módulo II constituirá la parte más simple de la plataforma web a desarrollar,

puesto que no requerimos de ningún tratamiento de la información previo (módulo I)

para poder completarlo en su totalidad. Sin embargo, se necesitan cumplir ciertos

requerimientos en forma de acciones para satisfacer un progreso adecuado en el

desarrollo del software de este módulo. Estos requerimientos, cada uno de ellos

asignado a uno de los actores principales, deberán ser satisfechos por los mismos.

Definimos los siguientes requisitos funcionales, a través de historias de usuario,

para el Módulo II:

11 Todos los documentos deben

tener una relevancia respecto

a la consulta

Importante No

funcional

5 Javier

Tabla 1. Definición de requisitos para el módulo I

ID Historia de usuario – Descripción requisito Prioridad Sprints

1 Como administrador debo hacer una interfaz intuitiva Importante 1,2,4,5

2 Como administrador debo garantizar la estabilidad del

sistema ante cualquier posible interacción anómala

Importante 2,5

3 Como administrador debo maximizar el rendimiento y

la eficiencia de la aplicación

Interesante 2,5

4 Como participante debo ser estudiante universitario Interesante 2

Tabla 2. Definición de requisitos no funcionales de módulos II y III



En base a las historias de usuario y requisitos que se han definido, podemos

establecer los distintos casos de uso que facilitarán el modelado y la implementación

del software para el módulo II:

ID Historia de usuario – Descripción requisito Prioridad Sprint

4a Como participante deseo un ID de usuario para

tener acceso a los experimentos

Imprescindible 1

5a Como administrador necesito comprobar si el

usuario ya ha realizado el Test

Imprescindible 1

6a Como participante me gustaría poder realizar un

test de entrenamiento-prueba para saber cómo va

a ser el Test.

Importante 1

7a Como administrador del sistema debo comprobar

que el test entrenamiento-prueba debe haberse

realizado correctamente

Importante 1

8a Como participante debo interactuar con el test

oficial de fluidez lectora

Imprescindible 2

9a Como administrador debo almacenar las

respuestas dadas por el participante al test oficial

de fluidez lectora

Imprescindible 2

10a Como participante debo rellenar un formulario de

datos personales

Imprescindible 1

11a Como administrador debo almacenar la

información extraída del Formulario de Datos

Personales

Imprescindible 1

12a Como administrador la aplicación debería enviar

un correo al participante con su ID cuando éste

rellene sus datos personales

Interesante 2

13a Como participante debería finalizar el experimento Imprescindible 2

Tabla 3. Definición de requisitos funcionales del módulo II: Test de Fluidez Lectora



Caso de Uso Actor

Iniciar Sesión Participante

Realizar test de entrenamiento-prueba Participante

Realizar Test oficial de Fluidez Lectora Participante

Rellenar Formulario de Datos

Personales

Participante

Finalizar experimento Participante

Comprobar si ya se ha realizado el test Controlador

Comprobar test entrenamiento-prueba

realizado correctamente

Controlador

Actualizar la información extraída del

Formulario de Datos Personales

Controlador

Tabla 4. Roles asignados a los casos de uso para el módulo II



Ilustración 7. Diagrama de Casos de Uso para el Test de Fluidez Lectora

En lo que respecta al módulo III, debemos asegurar indispensablemente los

siguientes prerrequisitos para que el usuario pueda comenzar el experimento:

• El participante ya ha realizado el test de comprensión lectora de

Woodcock-Muñoz.

• El participante debe conocer su ID de participante.

Asimismo, definimos un mayor número de requisitos funcionales en el módulo

III, ya que la complejidad que abarca el desarrollo de este módulo es mayor que la

correspondiente al Test de Fluidez Lectora (Módulo II), y por lo tanto se necesitan un

mayor número de funcionalidades entre los dos roles principales que intervienen en el

progreso del software y que se han mencionado previamente, el participante y el

controlador o propio sistema PIR.



Definimos los siguientes requisitos funcionales para el Módulo III:

En base a las historias de usuario y requisitos que se han definido, podemos

establecer los distintos casos de uso que facilitarán el modelado y la implementación

del software para el módulo II:

ID Historia de usuario – Descripción requisito Prioridad Sprint

4b Como participante debo introducir mi ID para iniciar una

nueva sesión de búsqueda

Imprescindible 4

5b Como administrador debo consultar si el participante existe

en la Base de Datos

Imprescindible 4

6b Como participante debo seleccionar la consulta que quiero

lanzar

Imprescindible 4

7b Como administrador debo registrar la consulta lanzada Imprescindible 4

8b Como administrador debo eliminar la consulta para que no

aparezca en la siguiente sesión de búsqueda

Importante 5

9b Como participante debo explorar los documentos

recuperados cuando lanzo la consulta

Importante 5

10b Como administrador debo comprobar si se visitan

documentos (registrando el tiempo de entrada y salida al

documento)

Imprescindible 5

11b Como participante debería realizar un resumen de lo

aprendido en la fase de exploración de documentos

Importante 4

12b Como administrador debo almacenar el resumen de lo

aprendido

Imprescindible 4

13b Como administrador debo actualizar el conjunto de

documentos a evaluar por el participante

Imprescindible 5

14b Como participante debo evaluar los documentos que se

muestran

Imprescindible 5

15b Como administrador debo registrar las evaluaciones dadas Imprescindible 5

16b Como participante debería finalizar la sesión de búsqueda Importante 5

17b Como participante debería llegar a finalizar el experimento Interesante 5

Tabla 5. Definición de requisitos funcionales del módulo III: Sistema PIR para la evaluación de la comprensión lectora



Caso de uso Actor

Introducir ID Participante

Seleccionar Consulta Participante

Explorar documentos recuperados Participante

Realizar un resumen de lo aprendido Participante

Evaluar documentos Participante

Finalizar sesión Participante

Finalizar Experimento Participante

Consultar si el usuario existe Controlador

Crear nuevo inicio de sesión de

búsqueda

Controlador

Registrar la consulta lanzada Controlador

Comprobar si se visitan documentos Controlador

Actualizar conjunto de documentos a

evaluar

Controlador

Almacenar resumen de lo aprendido Controlador

Registrar evaluaciones dadas Controlador

Tabla 6. Roles asignados a los casos de uso para el módulo III



Ilustración 8. Diagrama de Casos de Uso para el sistema PIR

3.3.2. Aspectos técnicos

El sistema que se desarrollará estará basado en un prototipo experimental de

aplicación web optimizado para su uso desde ordenadores convencionales

(sobremesa o portátiles).

El hecho de que la aplicación tenga un carácter de experimentación donde la

legibilidad, rapidez y atención juegan un papel fundamental han hecho que optemos

por no orientar su uso a dispositivos móviles.

Al ser una aplicación web, el acceso a nuestro sistema está garantizado

prácticamente desde cualquier sistema operativo; además se garantizará que pueda

accederse mínimamente desde 3 clientes web de alto uso como lo son Google

Chrome, Mozilla y Opera.



3.3.3. Riesgos posibles

Ningún proyecto está exento de sufrir errores, en nuestro caso los posibles

riesgos que podemos encontrar son los siguientes:

• Puesto que no está optimizado para dispositivos móviles (no cuenta con

diseño Responsive), si el experimento se realizara en estos dispositivos

podría dar problemas en la interacción del usuario.

• Las interacciones y evaluaciones anómalas por parte del participante ya

sean deliberadas o sin consciencia de ello, ponen en riesgo que los

resultados sean coherentes.

3.3.3. Estimación de costes del proyecto

Nuestro proyecto a pesar de ser un trabajo académico que tiene como fin la

experimentación y recopilación de resultados, requiere de un estudio de la viabilidad

económica del proyecto al tratarse de un desarrollo software a medio plazo (6-7 meses

de desarrollo). Por lo tanto, a continuación, se describirá la relación económica

existente entre los distintos recursos requeridos y los productos de trabajo que se

obtendrán en la fase final de entrega del proyecto.

Nos basaremos en las tablas salariales establecidas por el BOE el 6 de marzo

de 2018, en el convenio colectivo estatal para empresas de consultoría, al que se

deben ajustar todas las empresas de servicios de informática.

En la tabla 7, distinguimos las funciones a desarrollar por las diversas categorías

profesionales que define el BOE [10] para el sector laboral informático, mientras que

en la tabla 8, se expondrán los salarios totales que deben fijarse para cada una de

dichas categorías (en día, mes y año).



Categoría profesional Función Asignado a

Analista de sistemas Personas con perfil profesional adecuado,

con experiencia profesional en las tareas

de grupo. Amplia autonomía en la

ejecución de sus tareas. Supervisa y

asigna tareas a personas a su cargo.

Fernando

Javier

Martínez

Santiago

Analista programador;

Diseñador de páginas

webs

Cuenta con los conocimientos necesarios

y con amplia experiencia profesional en el

grupo. Los procesos que se le asignan los

desarrolla con autonomía.

Javier Perea

de la Casa

Programador Senior Realiza tareas de complejidad media y con

poca supervisión.

Propone mejoras en los procesos que se

le asignan, pero sin contar con capacidad

de decisión

-

Programador Junior;

Técnico de

mantenimiento web

Personas con un adecuado perfil

profesional que realizan tareas propias de

su grupo con complejidad baja y bajo

supervisión y sin autonomía.

Javier Perea

de la Casa

Codificador

Informático

Personas con o sin experiencia que

desempeñan tareas básicas propias de su

entorno laboral.

Francisco

Javier

Collado

Barrachina

Tabla 7. Funciones que desempeñan categorías profesionales del sector informático.



Categoría profesional Día Mes Año

Analista de sistemas 67,7 € 2099 € 25189 €

Analista programador; Diseñador de

páginas webs

66,24 € 2053€ 24640 €

Programador Senior 47,62 € 1476,25 € 17715,65 €

Programador Junior; Técnico de

mantenimiento web

42,63 € 1321,71 € 15860,56 €

Codificador Informático 33,89 € 1050,58 € 12607 €

Tabla 8. Tabla salarial a partir del 01-01-2019 (BOE)

Finalmente nos basaremos en la tabla 8 para fijar los sueldos a las condiciones

que nuestro proyecto exige en cuanto a mano de obra.

De esta forma, estableceremos el coste mínimo de producción del proyecto para

que el equipo de investigación o empresa correspondiente evalúe así, el presupuesto

qué poder destinar al desarrollo del proyecto.



Producto Estimación tiempo de entrega

Mano de obra Coste estimado de producción

Corpus final consulta-documento 2 meses -1 Analista de sistemas -1 Programador Junior -1 Codificador Informático

8942,58 €

Test de Fluidez Lectora 3 meses -1 Analista de sistemas -1 Diseñador de páginas web

12456 €

Sistema PIR para la Evaluación de la Comprensión Lectora

4 meses -1 Analista de sistemas -1 Diseñador de páginas web

16608 €

Base de Datos pir 2 meses -1 Analista de sistemas -1 Programador Junior

6841,2 €

Coste total de recursos humanos en la producción del proyecto

44847,78 €

Tabla 9. Estimación de coste humano del proyecto

Además de los costes de producción obtenidos, tenemos que añadirle al precio

final el uso de recursos no humanos que intervienen indirectamente en el proceso de

desarrollo.

Definimos cada uno de los factores y recursos requeridos en los distintos

productos desarrollados:

• Hardware

o Ordenador principal de desarrollo, Lenovo Ideapad Y520-15IKBN:

900 €

o Otros recursos hardware utilizados: 1500 €

• Software

o Microsoft Word (Office 365 Personal): 69 € (anual) → 34,5 € (coste

de 2 meses amortizados)



o Windows 10 Home: 145 €

• Formación en tecnologías: 1500 €

• Conexión a internet: aprox. 26,90 € (mensual) → 188,3 € (7 meses -

duración aprox. del proyecto)

Si sumamos el coste de producción humano al coste de formación y recursos

empleados obtendremos:

Recursos Coste

Humanos 44847,78 €

Hardware, software, formación y conexión 4267,8 €

Presupuesto final del proyecto 49115,58 €

Tabla 10. Coste de Producción Total del Proyecto

3.4.4. Estimación temporal del proyecto

Para entender cómo se ha planificado cada tarea a través del tiempo, resulta

fundamental controlar el tiempo de ejecución de estas. Por ello, por medio del

programa GanttProject, se ha llevado a cabo el Diagrama de Gantt, cuyo propósito es

gestionar y planificar el tiempo en el que se ha desarrollado cada tarea que abarca el

proyecto.

Así, el lector podrá verificar y contrastar si el coste de desarrollo del software es

el previamente mencionado.





Debido a las grandes dimensiones del diagrama, si la visualización del diagrama

en la documentación le resulta tediosa, puede acceder al informe (generado por

GanttProject) adjuntado junto con la documentación en pdf, denominado

DiagramaDeGantt_PereaJavier.pdf.

3.4. Modelado y diseño

El propósito de esta etapa es facilitar a través de modelos una mejor

comprensión de los requerimientos del software y el diseño que los satisfará. No

obstante, estos modelos estarán compuestos por diversos diseños que definirán la

estructura del sistema a desarrollar.

Se utilizará el Lenguaje Unificado de Modelado (UML) como lenguaje visual y

de modelado para preparar los esquemas gráficos de los diagramas de máquina de

estados (3.4.2.) del sistema software a desarrollar.

UML define reglas sintácticas que especifican cómo combinar los elementos del

lenguaje, de forma que debemos garantizar que se cumplen esas reglas en el diseño

de los diagramas de estado. Esta posibilidad está fuera del alcance de los productos

de dibujo habituales, donde no se comprueban reglas. [11]

Cabe mencionar que UML es hoy un estándar industrial ampliamente utilizado,

por lo que su uso en los proyectos software es ampliamente recomendable.

Nuestra intención es formalizar el modelado de nuestro sistema final definiendo

una arquitectura basada en el Modelo Vista Controlador (MVC), y haciendo uso de

diagramas UML (concretamente diagramas de estado) y diagramas de flujo de datos

para definir el diseño de nuestra plataforma web (módulos II y III).

Además, se hará uso del modelo entidad-relación para el diseño de la base de

datos, para así definir las entidades que constituirán nuestro sistema de información,

y establecer las relaciones existentes entre estas.



3.4.1. Arquitectura del sistema

La primera fase de modelado la constituirá la arquitectura de nuestro sistema,

puesto que, en nuestro proyecto, constituye la fase más “superficial” dentro del diseño

del software.

La arquitectura podemos decir que estará compuesta por un conjunto de

decisiones donde algunas se tomarán en la etapa temprana del diseño y tendrán un

efecto profundo en las demás acciones, mientras que otras se dejan para más

adelante, eliminando así restricciones prematuras para evitar un mal planteamiento

del estilo arquitectónico del sistema. [7]

Según Jerrold Grochow la arquitectura de un sistema es “un marco general que

describe su forma y estructura: sus componentes y la manera en la que se ajustan

entre sí”.

Dicho esto, se propone la siguiente representación gráfica como modelo

arquitectónico de nuestro proyecto:

Ilustración 9. Representación genérica de la arquitectura del sistema

Indagando un poco más en detalle la arquitectura presentada, planteamos

seguidamente, el patrón arquitectónico que seguiremos.



Los patrones arquitectónicos se adhieren a un problema de aplicación específica

dentro de un contexto dado y sujeto a limitaciones y restricciones. El patrón propone

una solución arquitectónica que sirve como base para el diseño de la arquitectura. [7]

Nuestro proyecto se ajustará al Modelo Vista Controlador (MVC) como patrón

arquitectónico, ya que divide una aplicación interactiva en 3 componentes distintos

que perfectamente se corresponden con 3 partes distinguidas e independientes que

compondrían nuestra plataforma:

• Modelo: Contiene la funcionalidad (actualizaciones, inserciones, etc) y los

datos básicos. Lo constituirá tanto el Sistema de Gestión de Base de

Datos como la propia base de datos (bajo el nombre pirdb)

• Vista: muestra la información al usuario, la constituyen las partes que

hacen posible la visualización de la interfaz.

• Controlador: gestiona la entrada de datos por parte del usuario, y en

nuestro caso, además, la integración de la plataforma en un servidor web.

Ilustración 10. Modelo Vista Controlador de nuestra plataforma



3.4.2. Diagramas de máquina de estado

Los diagramas de máquina de estado son diagramas UML que modelan los

distintos estados críticos o clave, así como los eventos que pueden desencadenar un

cambio de estado [12]. De esta forma, esquematiza el comportamiento de un objeto

(en nuestro caso el propio sistema), detallando la secuencia de estados por la que

pasa dicho objeto durante su ciclo de vida desde su estado inicial hasta su estado

final.

Se proponen los siguientes diagramas de estado para los módulos que integran

íntegramente la plataforma web a desarrollar (Módulo II y Módulo III):



3.4.2.1. Módulo II: Test de Fluidez Lectora

Ilustración 11. Diagrama de máquina de estado del Test de Fluidez Lectora



3.4.2.2. Módulo III: Plataforma PIR

Ilustración 12. Diagrama de máquina de estado de la plataforma PIR



3.4.3. Diagramas de flujo de datos (DFD)

Debido a que nuestro proyecto no está orientado a objetos puesto que el número

de clases que interactúan con la aplicación es ínfimo (a lo sumo 2 clases – el

participante y el controlador-administrador), definiremos un modelo alternativo que nos

permita ver cómo se van transformando los datos y distinguir cómo fluyen a través de

los diferentes procesos en un sistema de información, es decir las Entradas-Salidas

que van recibiendo-produciendo nuestros sistemas de información.

Según [13], los DFD se estructuran modularmente en 3 niveles:

• Nivel 0 – Diagrama de contexto: constituye el panorama básico de todo

el sistema o proceso que se está analizando o modelando. Diseñado para

una visualización fácil y sencilla que muestra el sistema como un único

proceso, así como sus interrelaciones con las entidades externas que

interaccionan con él.

• Nivel 1 – Diagrama de nivel superior: desglose de elementos más

detallado del diagrama de contexto. Se destacan las principales funciones

que el sistema lleva a cabo, el proceso principal del diagrama de contexto

se desglosa en una serie de subproceso. Se incluyen Almacenes de Datos

en el diagrama.

• Nivel 2 – Diagrama de detalle o expansión: supone el máximo nivel de

detalle de entrada/salida de datos. Profundiza aún más en cada uno de

los procesos e interrelaciones existentes.



3.4.3.1. Módulo II: Test de Fluidez Lectora

Ilustración 13. Diagrama de Contexto (Flujo de Datos - Nivel 0)

Ilustración 14. Diagrama de nivel superior (Flujo de datos – Nivel 1)



Ilustración 15. Diagrama de Detalle o Expansión (Flujo de datos – Nivel 2)



3.4.3.2. Módulo III: Plataforma PIR

Ilustración 16. Diagrama de Contexto (Flujo de Datos - Nivel 0)

Ilustración 17. Diagrama de nivel superior (Flujo de datos – Nivel 1)



Ilustración 18. Diagrama de Detalle o Expansión (Flujo de datos – Nivel 2)



3.4.4. Diseño de la base de datos

3.4.4.1. Fase I: Desarrollo del esquema conceptual de los datos – Diagrama Entidad/Relación

La primera fase del modelado de datos consistirá en desarrollar un esquema que

nos permita distinguir las relaciones existentes entre las distintas entidades que

conforman el módulo II (Test de Fluidez Lectora) y el módulo III (Evaluación del

Participante a través de un Sistema de Recuperación de Información).

Se propone, por lo tanto, el siguiente esquema conceptual correspondiente a la

ilustración 19, bajo un diagrama entidad/relación que esquematiza las entidades y

relaciones presentes en el proyecto:

Ilustración 19. Diagrama E/R



Las 5 entidades que componen nuestro diseño serán las siguientes:

• SENTENCE_TEST: Conjunto de afirmaciones tipo test (verdaderas o

falsas) que se le van a presentar al participante en el módulo II.

• PARTICIPANT: Es el usuario que va a realizar los distintos experimentos

propuestos.

• SEARCH_SESSION: Sesión de búsqueda del participante dentro de la

plataforma de evaluación en el módulo III.

• QUERY: conjunto de consultas que pueden ser lanzadas en el módulo III.

• DOCUMENT: colección de documentos que se visitarán o evaluarán

dentro del módulo III.

A continuación, se describen las distintas relaciones entre las entidades

presentes en el diagrama:

• R1~responde (PARTICIPANT ↔ SENTENCE_TEST): un participante

responde a 1 o más oraciones del test en un momento determinado, y una

misma oración puede ser respondida por 1 o más participantes del test de

fluidez lectora.

• R2~realiza (PARTICIPANT → SEARCH_SESSION): un participante

realiza 1 o más sesiones de búsqueda, mientras que una sesión de

búsqueda solamente puede corresponderse a un solo participante.

• R3~se lanza (SEARCH_SESSION ↔ QUERY): en una misma sesión de

búsqueda se lanzan 1 o más consultas, y 1 misma consulta puede ser

lanzada por varios participantes de la aplicación.

• R4~visita (R3 ↔ DOCUMENT): Cuando se lanza una consulta, el

participante podrá visitar 1 o más documentos, y a su vez, un mismo

documento podrá visitarse en distintas sesiones de búsqueda.

• R5~evalúa (R3 ↔ DOCUMENT): tras realizar un resumen de los

documentos visitados en la fase de búsqueda, en una sesión de búsqueda

el participante evalúa uno o más documentos asociados a la consulta. A



la misma vez, un mismo documento puede ser evaluado en 1 o más

sesiones de búsqueda, pudiendo estar asociado a 1 o más consultas.

• R6~recupera (QUERY ↔ DOCUMENT): una misma consulta puede

recuperar uno o más documentos, mientras que un documento puede ser

recuperado por una o más consultas a través de los valores de relevancia

y ranking.

3.4.4.2. Fase II: Desarrollo del lógico de los datos – Modelo Relacional

A continuación, se transforma el diagrama entidad/relación a tablas. Para ello

deberemos observar las distintas entidades que conforman el diagrama E/R y analizar

las relaciones entre ellas para ver las claves foráneas y claves candidatas que

corresponden a cada entidad, así como comprobar si se generarán nuevas tablas a

partir de algunas de las relaciones existentes en el diagrama.

Tras obtener las tablas inferidas del esquema E/R, deberemos asegurarnos de

que permanezca como mínimo en tercera forma normal (3NF), observando el conjunto

de dependencias funcionales que existen sobre el conjunto de tablas y que sólo hay

funcionales completas no transitivas.

Se propone el siguiente esquema lógico normalizado en Tercera Forma Normal:



Ilustración 20. Esquema lógico normalizado en 3FN

Verificación del proceso de normalización

Según [14], el proceso de normalización de datos puede considerarse como un

proceso de análisis de un esquema relacional para llegar a obtener las propiedades

deseables de:

1. Minimizar las redundancias

2. Minimizar las anomalías en la inserción, borrado y actualización



Por las razones previamente mencionadas, llevaremos a cabo un proceso de

normalización que nos permita comprobar que los datos se estructuren de forma que

estén ordenados, ocupando el menor espacio posible, eliminando errores lógicos y de

repetición de datos.

En nuestro caso, nos aseguraremos de que al menos, el diseño de la base de

datos cumpla la Tercera Forma Normal, para ello primero debemos comprobar que se

cumplan la Primer y Segunda Forma.

• Primera Forma Normal (1FN)

Afirma que el dominio de un atributo sólo debe incluir valores atómicos que sean

simples e indivisibles, y que el valor de cualquier atributo en una tupla debe ser un

valor simple del dominio de ese atributo.

En términos simples, aseguramos que la tabla estará en 1FN si no existe ningún

campo o columna de la tabla, que tenga más de 1 valor para cualquiera de las tuplas

que la conforman.

Cada una de las distintas tablas que conforman nuestro modelo relacional

permite únicamente valores de atributo que son atómicos (o indivisibles) y los atributos

definen un solo dominio (un solo campo que identifica al participante, la respuesta,

etc); por lo tanto, podemos afirmar que nuestro esquema relacional está en 1FN.

• Segunda Forma Normal (2FN)

Basada en el concepto de dependencia funcional total. Una dependencia

funcional X → Y es total si la eliminación de cualquier atributo A de X implica que la

dependencia deje de ser válida.

Implica la verificación de las dependencias funcionales totales cuyos atributos

del lado izquierdo (X) forman parte de la clave principal, de forma que se debe

garantizar que en caso de que uno de los atributos que forman la clave principal es

eliminado, cualquier atributo que dependa de la clave principal no llegue a tener

sentido por sí mismo en la tabla, es decir, que no sirva para identificar los atributos.



Como ejemplo para verificar la 2FN pondremos la tabla PARTICIPATION:

PARTICIPATION (id, id_participant, id_sentence, answer, timestamp)

Para que la verificación adopte un tono más representativo y explicativo se ha

optado por tomar como conjunto X, el conjunto de claves candidatas

id_participant, id_sentence → answer,timestamp

Una respuesta a una pregunta siempre dependerá de la persona que lo realice

(id_participant) y lógicamente de la oración a la que responde (id_sentence).

La marca de tiempo en la que responde el participante a una pregunta no se

podrá determinar si no existe un elemento que identifique al participante

(id_participant) y otro que permita saber a qué oración está dando respuesta

(timestamp).

Siguiendo el mismo procedimiento para el resto de las tablas, podemos afirmar

que el modelo relacional se encuentra en 2FN.

• Tercera Forma Normal (3FN)

Fundamentada en el concepto de dependencia transitiva, donde partiendo de

una relación entre atributos X → Y (dependencia funcional total: 2FN), existan uno o

más atributos no claves Z que cumplan que X→ Z y Z → Y.

Por lo tanto, se podrá pasar a 3FN si contiene alguna dependencia transitiva

entre los atributos, es decir, si existen campos que no son clave y que dependen de

otro campo que no es clave. En términos simples: “ningún campo no clave depende

de otro campo no clave”.

Como ejemplo para verificar la 3FN pondremos la tabla QUERY:

QUERY (id_query, title, description, lang, author)

Supongamos que queremos comprobar si a través del título podemos determinar

algún atributo no clave como descripción, lenguaje o autor:



X: id_query

Y: title

Z: (description, lang,author)

Observamos que el título de una consulta no puede determinar ni la descripción

de ésta, puesto que pueden existir títulos iguales, pero con descripciones distintas,

concretando el dominio en el que se quiere buscar.

Tampoco el título podrá determinar el lenguaje en el que se quiere consultar, ya

que el título puede ser una entidad, un acrónimo o unas siglas en inglés, pero se podría

buscar información en castellano sobre el mismo.

Así mismo, el título no podrá determinar el autor, puesto que un mismo título de

consulta puede ser escrito por una o más personas.

Probamos con el resto de los atributos no clave, siguiendo el mismo

procedimiento y finalmente obtenemos que la tabla QUERY está en 3FN.

Aplicamos este proceso al resto de tablas para concluir que nuestro modelo

relacional se encuentra finalmente en 3FN.

Descripción de tablas generadas

A continuación, se detallará qué función desempañan, dentro del proceso de

ejecución de las aplicaciones desarrolladas, cada una de las tablas extraídas de las

entidades y relaciones establecidas en el modelo E/R, y que han sido definidas en el

modelo relacional.

Es importante mencionar que el vínculo que entrelaza el Módulo II y el Módulo

III para una posible recopilación y combinación de los datos será el identificador del

participante, garantizado al principio del test de fluidez lectora (y enviado al correo

electrónico cuando rellena sus datos personales).



Módulo II: Test de Comprensión Lectora

• SENTENCE_TEST: contendrá el conjunto de oraciones a evaluar en el test de

comprensión lectora. Constará de un identificador para cada oración, el texto

de esta, la respuesta oficial y el lenguaje en el que está escrita.

• PARTICIPATION: tabla generada a partir de la relación R1 del esquema

conceptual. Representa la interacción del participante (respuesta y momento

en el que responde) con las preguntas del test, usando de nexo el identificador

del participante y de la oración a la que responde.

• PARTICIPANT: almacenará los datos personales del participante que haya

realizado el test: sexo, edad, nacionalidad, educación, dificultad de aprendizaje,

email y nivel de inglés-español oficial y no oficial.

Módulo III: Sistema de Evaluación de la Comprensión Lectora a través de

Recuperación de Información

• SEARCH_SESSION: registrará el momento en el que cada una de las sesiones

de búsqueda por parte de los participantes (relación R2) se inician y finalizan.

• QTIME: tabla generada a partir de la relación R3, para cada tupla almacenará

el momento en el que el participante lanza la consulta, así como la respuesta a

la consulta dada por el participante tras indagar en los documentos que se

recuperan.

• PARTICIPANT_VISIT: tabla generada a partir de la relación R4. En la etapa de

búsqueda de información, previa a la de evaluación, almacenará los

documentos que vaya visitando el participante, concretamente cada tupla

registrará el momento de apertura y de cierre de cada documento que haya

decidido abrir para la consulta lanzada.

• PARTICIPANT_ASSESSMENT: tabla generada a partir de la relación R5,

contendrá la evaluación del participante, que se hará a través de un valor

booleano que indicará si el documento que ha leído el participante es o no

relevante para el mismo. Además, se registrará el momento en el que abre el

documento para leerlo, así como el momento que lo cierra, con el fin de



comprobar el tiempo que tarda en leerlo (sin contar los posibles factores

externos que incidan en el participante y lo interrumpan de su lectura)

• DOCUMENT: esta tabla almacena la colección completa de documentos,

registrando el título del documento, el texto que incluye, así como la fuente

original de donde proviene (Google ó Newsela).

• QREL: tabla generada a partir de la relación R6, contiene el ranking o posición

asociada del documento para la consulta lanzada, así como el juicio de

relevancia predeterminado para ese documento (si es realmente relevante o

no, para la consulta lanzada).

• QUERY: almacenará cada una de las consultas que el participante podrá

lanzar, cada consulta estará estructurada con un título, una descripción, un

idioma y el autor.

3.4.4.3. Fase III: Diseño físico – Inclusión de estructuras destinadas a mejorar el rendimiento del sistema

En contraposición con el modelo lógico de datos, se propone mejorar la eficiencia

de la base de datos maximizando el rendimiento, principalmente minimizando los

tiempos de ejecución de consultas facilitando así un diseño más dinámico, que

evoluciona a lo largo de la vida de la BBDD según varían las necesidades de

información. [15]

En nuestro caso, se opta por usar como estructura física los índices, puesto que

usualmente mejoran el acceso a las consultas. Dichos índices se aplicarán a las

distintas claves primarias y claves foráneas de la aplicación, así, garantizamos un

acceso más rápido a las tablas y un funcionamiento más eficiente de la aplicación.

No se han implementado otras estructuras físicas como pueden llegar a serlo las

particiones porque las tablas no tendrán un tamaño lo suficientemente grande como

para distribuir cada tabla en diferentes segmentos. Estimamos, por lo tanto, que la

ganancia que obtendríamos de llevarlo a cabo sería mínima.



3.5. Construcción y evolución

Distinguimos dos actividades principales en esta fase de desarrollo, una relativa

a la generación del código y organización de los directorios y ficheros que lo contienen

(construcción) y otra que hace referencia al progreso del código derivado de las

pruebas realizadas sobre la plataforma (evolución).

La fase de construcción vendrá determinada por las distintas tecnologías

usadas sobre las que se sustenta el software de nuestra plataforma, así como también

cómo se ha ido generando el código del proyecto (de forma automática o manual) a

través de las mismas y a lo largo de los distintos módulos.

Finalmente, la evolución del código generado hará que nuestra plataforma web

de evaluación para la comprensión lectora se realimente y mejore en base a los

errores que aparezcan en las distintas pruebas realizadas.

3.5.1. Uso de tecnologías

• Lenguajes

o Javascript, EJS, CSS, SQL, Python

• Sistema de Gestión de Base de Datos

o MySQL

• Librerías

o Bootstrap

• Framework

o AngularJS

• Entorno de Ejecución del Servidor

o NodeJS

• IDE y editor de código fuente

o Spyder, Atom

3.5.1.1. ¿Por qué se han usado las tecnologías NodeJS y AngularJS?

Antes de entrar en las ventajas de uso que presentan Node y Angular, cabe

destacar que ambas tecnologías desempeñan un papel distinto en el proceso de

ejecución de una aplicación. Mientras que AngularJS se encarga de trabajar en la

parte del cliente (navegador web), NodeJS se encargará del lado del servidor.



• NodeJS [16]

o El gestor de paquetes que ofrece, NPM, incluye una gran cantidad

de librerías/paquetes que poder instalar en la aplicación gracias a

la comunidad que hay detrás creando nuevos módulos y

documentando los existentes.

o La comunicación I/O se realiza de forma sencilla (acceso a

ficheros, exportación de ficheros, actualización y acceso a bases

de datos).

o Resulta fácil de aprender, puesto que usa JavaScript como

soporte, siendo uno de los lenguajes más utilizados en la parte del

front-end (cliente); haciendo mucho más sencillo para los

conocedores del lenguaje el uso de Node.js en la parte del servidor

(back-end).

• AngularJS [17]

o Mientras que en la mayoría de frameworks se requiere que los

programadores separen la app en múltiples componentes MVC

teniendo después que escribir el código necesario para

ponerlos juntos de nuevo, en AngularJS, sin embargo, se

anexan todas estas partes automáticamente ahorrando tiempo

de desarrollo.

o Su uso como framework resulta intuitivo puesto que usa HTML

como lenguaje declarativo. Además, extiende el vocabulario

HTML con directivas y atributos, de forma que permite

prescindir de librerías externas como jQuery.

3.5.1.2. ¿Por qué se ha usado EJS?

EJS (Embedded Javascript Templates) es un lenguaje que permite generar

páginas HTML en el servidor antes de servirlas al cliente, de forma que éstas podrán

tener partes dinámicas, cambiantes a lo largo del proceso de ejecución de la

aplicación. En definitiva, EJS es un motor para generar plantillas dinámicas de HTML

en JavaScript.



Por lo tanto, según [18] EJS destaca principalmente por tres características:

• EJS proporciona una rápida compilación y renderizado incluyendo soporte

tanto para el servidor como para el navegador.

• El carácter dinámico de EJS nos garantiza una mayor flexibilidad en el

código que de otra forma sería imposible conseguir con HTML estático.

• Fácil de utilizar.

Por estas razones se ha optado por usar la tecnología EJS como motor de

visualización de NodeJS, y así poder pasar los datos generados en NodeJS a nuestras

vistas de forma eficiente, dinámica y sencilla.

3.5.2. Estructura de directorios

A continuación, se mostrará y se describirá el árbol de directorios final que se ha

generado para el módulo I (versión sin documentos ClueWeb), así como el que

contiene a los módulos II y III conjuntamente.

3.5.2.1. Módulo I – Preprocesamiento de consultas y documentos

Ilustración 21. Estructura de directorios del módulo I

• Módulo I: Contiene ficheros y carpetas relativos al preprocesamiento de

documentos y sus relaciones con las consultas predefinidas

o data: colección final que contiene un directorio para cada una de

las 20 consultas que contendrá a su vez los 20 documentos

(Newsela + Google) asociados a dicha consulta.



o documentQrel_SQL_InsertGeneration: contiene los scripts en

Python que generan los ficheros de inserción sql para las tablas

DOCUMENT y QREL.

▪ json: Contiene las tablas DOCUMENT y QREL en formato

json para su posterior transformación a formato sql.

▪ sqlScripts: scripts sql de inserción para las tablas

DOCUMENT y QREL.

▪ writeDocumentsJson.py: lee la carpeta data y escribe en

Json, cada uno de los documentos existentes (sin que se

repitan) con sus campos correspondientes.

▪ writeQrelJson.py: lee la carpeta data y escribe en Json,

cada una de las relaciones consulta-documento existentes

con sus campos correspondientes.

▪ generateSqlScript.py: genera los scripts de inserción sql

para los ficheros json correspondientes a las tablas

DOCUMENT y QREL.

▪ README.md: descripción de los scripts en Python

utilizados.

▪ qrels.txt: fichero de texto que define las relaciones

existentes consulta-documento para la colección completa

de artículos de Newsela.



3.5.2.2. Módulo II y Módulo III: Plataforma para la evaluación de la comprensión lectora

Ilustración 22. Estructura de directorios de módulos II y III

• APP_Comprension_Lectora: contiene todos los ficheros relativos a la

plataforma de evaluación de la comprensión lectora

o package-lock.json:

o app.js: contiene todo lo relativo al back-end de la aplicación,

gestión del servidor y de entrada/salida de datos.

o bbdd: scripts necesarios para la puesta en marcha de la base de

datos Mysql.

o node_modules: módulos predeterminados e instalados en

NodeJs a través de la orden npm install nombre_módulo

o views: contiene todo lo relativo al front-end de la aplicación, es

decir, recursos y visualización-interactividad de la interfaz.

▪ fluidezlectora: contiene las plantillas ejs (HTML+JS) del

módulo II: Test de Fluidez Lectora.

▪ pir: contiene las plantillas ejs (HTML+JS) del módulo III:

Sistema PIR.

▪ resources: recursos utilizados por las plantillas ejs



• css: contiene las hojas de estilo empleadas

• imgs: imágenes utilizadas

• jQuery: biblioteca jQuery.

• js: contiene un directorio con las librerías utilizadas

en Angular y client.js donde se genera el código

asociado al framework.

• json: ficheros json que utiliza Angular (y en

ocasiones Node.js a través de app.js) para la lectura-

escritura.

3.5.3. Detalles de la implementación

3.5.3.1. Base de datos

Como previamente se ha mencionado en el apartado 3.5.1 Uso de tecnologías,

se ha usado como Sistema de Gestión de Bases de Datos, MySQL, por su facilidad

de uso, su carácter multiplataforma, y soporte que proporciona toda la comunidad de

usuarios que hay detrás. Además, el hecho de que tratemos con conjuntos de datos

estructurados potencia el uso de este SGBD para el proyecto.

La creación de las tablas que componen nuestro modelo relacional se ha

desarrollado a través de la herramienta MySQL Workbench generando el script

principal pirdb.sql. Además, a través de la herramienta se han insertado las distintas

tuplas que conforman las tablas SENTENCE_TEST y QUERY, puesto que para

extraer éstas no se ha requerido de ningún tipo de preprocesamiento específico.

Sin embargo, para las tablas DOCUMENT y QREL se ha requerido el uso de

Python para darle formato a los datos y generar dos scripts de inserción (uno para

DOCUMENT y otro para QREL) en estas tablas que dependen del corpus de

documentos que se usa para el Módulo III.



3.5.3.2. Módulo I: Preprocesamiento de consultas y documentos

Esta sección se ha desarrollado plenamente bajo el lenguaje de scripting Python,

puesto que su uso, facilita considerablemente la tarea del tratamiento-preprocesado

de texto respecto a otros lenguajes de programación.

Partiendo de que ya disponemos de las 20 consultas a lanzar, distinguiremos 2

partes dentro de este módulo, una que incluirá documentos HTML de ClueWeb dentro

del corpus final y otra que no los incluirá (debido al problema de legibilidad de los

documentos ClueWeb previamente mencionado). Independientemente de la parte,

ambas se desarrollan bajo la implementación de las siguientes dos tareas:

1. Generación del corpus de documentos-consulta

• Versión con ClueWeb (No usada finalmente en el módulo III -

Salida: corpus data): se lanza el script main.py que generará un

árbol de directorios y hará uso de un rastreador web para ClueWeb

que recupere una descripción de los 100 primeros documentos (por

ranking) en JSON.

Tras obtener las descripciones de cada uno de los documentos, se

hace uso del identificador de estos para descargar ahora sí la

página completa HTML, y extraer el título y el texto de los

documentos a través de la librería Python para análisis de textos

HTML BeautifulSoup. Tras este preprocesado de los documentos

HTML, se generan, ya sí, los 100 documentos ClueWeb en formato

JSON teniendo como campos el título y el texto y se integran en el

corpus final.



Ilustración 23. Adquisición y preprocesamiento de documentos HTML

Clueweb

Tras recuperar y preprocesar los 100 documentos ClueWeb, se

sustituirán por documentos Newsela aquellos que ocupen el mismo

ranking (empezando por 1) que los documentos Newsela para

cada una de las consultas. Estos cambios se harán en base al

archivo qrels.txt que contendrá las relaciones de los documentos

Newsela con las 20 consultas preasignadas.

Ilustración 24. Captura del fichero qrels.txt (id_query, nombre_fichero, relevancia)

Finalmente se sustituirán los primeros documentos ClueWeb (en

orden de ranking) irrelevantes por documentos extraídos

manualmente de Google.



La salida del script main.py generará el directorio data como la

colección de consultas-documentos final.

• Versión sin ClueWeb (Usada en el módulo III - Salida: corpus

data): en este caso se reutilizará la salida para la versión que

incluye los documentos ClueWeb, eliminaremos manualmente los

documentos de ClueWeb, mantendremos los de Newsela y Google

previamente incorporados, y recopilaremos tantos documentos de

Google como sean necesarios para completar un conjunto de 20

documentos recuperados por consulta.

Puesto que cada documento de Neswsela tiene un valor de

relevancia predefinido para la consulta en la que se integra, a cada

documento de Google le será asignado un juicio de relevancia

predeterminado (tras la comprensión y varias lecturas del mismo).

Ilustración 25. Colección de documentos para la consulta Q001 (DOCranking_consulta_relevancia)



2. Uso del corpus generado para generar los scripts de inserción sql

en las tablas DOCUMENT y QREL:

Tras tener el corpus generado nos interesa que se integre en nuestra base

de datos. De él derivaremos las tuplas que componen la tabla DOCUMENT (cada

documento existente) y la tabla QREL (cada relación documento-consulta

existente).

En este caso la única diferencia entre la versión que integra ClueWeb de la

que no lo hace es que el corpus es distinto.

• Primero, se hará uso del script writeDocumentsJson.py que leerá

cada documento existente, y distinguirá entre los identificadores de

los documentos Newsela y ClueWeb (en caso de que se haya

integrado) para que no se repitan, en pos de generar un json,

documents.json, que contenga los distintos documentos

estructurados en los mismos campos que atributos tenga la tabla

DOCUMENT.

• Segundo, se hará uso del script writeQrelJson.py que escribirá en

un Json, qrel.json las relaciones documento-consulta existentes

pudiendo inferir a través de los elementos del fichero, los atributos

que la tabla QREL.

Ilustración 26. qrel.json – la clave key se corresponde con la clave primaria de QREL puesto que contiene el par (id_consulta,id_documento)

3.5.3.3. Módulo II y III: Plataforma para la evaluación de la comprensión lectora

En lo que respecta a la implementación de las tareas que nos han llevado más

tiempo, o bien, son de gran importancia en cuanto al cumplimiento de los objetivos

planteados, distinguimos la tarea de seleccionar y visualizar las 65 frases a evaluar

en el módulo II y la tarea de obtener el conjunto de documentos a evaluar en el módulo

III (que será un subconjunto de los 20 que se recuperan para esa consulta).



Para la visualización de las distintas frases a evaluar en el test de fluidez lectora

del módulo II se ha hecho uso de Angular, permitiendo almacenar las distintas frases

en una estructura de datos partiendo de un fichero json origen (que ya contenga las

frases en uno de los idiomas disponibles ES/EN). De esta forma, la vista

correspondiente ejs se encargará de su visualización en la interfaz, recorriendo esta

estructura a través de un bucle.

En cuanto al método de extracción de documentos a evaluar, se ha optado por

usar un subconjunto formado por los siguientes grupos de documentos:

• Los 5 primeros documentos en el ranking para la consulta lanzada,

puesto que es probable que estos den respuesta a la misma y por

lo tanto sean relevantes.

• Documentos visitados por el participante en la fase 1.

Recuperación de información; ya que el participante debería tener

una previa idea de los mismos y podrá emitir un juicio de relevancia

más rápido y eficaz (al ser posiblemente releídos parcialmente)

• 4 documentos aleatorios, que garanticen una mayor variedad de

valores de relevancia al subconjunto de documentos a evaluar (ya

que es probable que el participante explore únicamente los

primeros documentos recuperados en orden de ranking).

Back-End

En la parte Back-End de nuestra plataforma se implementará en Node.js e

integrará el código vinculado a la comunicación del servidor con las vistas y base de

datos, a través de la gestión de entrada-salida de datos.

El script que gestione el backend será app.js, la creación del servidor se hará a

través del protocolo de transferencia de hipertexto http, que se instalará como paquete

en node y nos proporcionará la función createServer que integra node.

A la función createServer le pasaremos como parámetro el entorno de aplicación

web sobre el que queramos ejecutar nuestra plataforma, en nuestro caso, se ha hecho



uso del framework Express de carácter minimalista y flexible que garantiza un conjunto

robusto y amplio de características para aplicaciones web. [19]

El servidor escuchará por el puerto 8080, ya que tiene los permisos requeridos

para poder usar la plataforma a través de la dirección sobre la que se instalará

(150.214.174.56), sin necesidad de estar conectado a una red interna.

Cabe destacar que, pese a que la plataforma se haya instalado en dicha url,

todas las pruebas pertinentes y el desarrollo se ha hecho desde el servidor local

localhost.

Ilustración 27. Establecimiento de la conexión con el servidor

En el mismo fichero definiremos el motor de plantilla para la visualización de las

distintas páginas que integran la plataforma, en nuestro caso seleccionamos ejs,

app.set(‘view engine’, ‘ejs’).

El direccionamiento de las distintas rutas estará marcado por la visualización

de los ficheros ejs por medio de la función render de la variable res, encargada de

proporcionar una respuesta a las solicitudes recibidas del cliente (variable req) en la

ruta que defina la función app.get().

Ilustración 28. Direccionamiento de la ruta ‘/fluidezlectora/entrenamientoTest’



Front-End

Constituye la parte de la plataforma web que se encargará de la visualización de

elementos (interfaz), así como de la interacción con los participantes. Esta parte se

ejecutará siempre de lado del cliente (navegador web).

Los lenguajes que intervienen en esta parte serán JavaScript, HTML y CSS junto

con la librería Bootstrap y el framework Angular.

Se ha hecho uso además de las variables cedidas por node a través de la plantilla

ejs, así, por ejemplo, podemos cambiar el modo de visualización en el test de fluidez

lectora en función de la ruta que se proporcione a inglés

(localhost:8080/fluidezlectora?lan=EN) o a español (localhost:8080/fluidezlectora).

Por lo tanto, los valores de las variables EJS recibidas de node también servirán para

determinar qué visualizar en un determinado momento.

Ilustración 29. El título del test se muestra en inglés o español en función del lenguaje indicado por la ruta

En Angular se han definido diversos controladores para distintas partes de la

plataforma, en los que para cada uno de ellos, se configura el estado inicial del objeto

$scope definiendo variables y funciones en torno al mismo, accesibles desde la

plantilla ejs.

Para la activación de eventos relativos a una interacción del partcipante con el

sistema, por ejemplo, en el sistema PIR, que se visualice la descripción de la consulta

cuando se ésta se seleccione. Para ello, se ha hecho uso de variables y funciones

JavaScript, la mayoría implementadas en Angular, otras en el propio fichero ejs.

Ilustración 30. Descripción de la consulta cuando se selecciona y función del objeto $scope que la almacena en una variable.



Además, también se han usado funciones JavaScript para evitar interacciones

anómalas por parte del participante, y así verificar que el flujo de ejecución de la

plataforma se desarrolle con total normalidad.

3.5.4. Pruebas realizadas y fallos encontrados

3.5.4.1. Módulo I – Preprocesamiento de consultas y documentos

Prueba 1 – Comprobar si el script principal main.py combina correctamente los

corpus ClueWeb, Newsela, Google.

• Fallos encontrados: ninguno

Prueba 2 – Buscar codificación de caracteres adecuada para los documentos de

ClueWeb.

• Fallos encontrados: la codificación textual de numerosos documentos es

ilegible, por mucho que se intente decodificar a cualquier formato (UTF-8, ISO-

8859-1, …), debido a la aparición del carácter: �, usado para reemplazar un

carácter desconocido, irreconocible o imposible de representar.

• Solución: Cambio de hoja de ruta, eliminamos el corpus ClueWeb de la

colección de documentos. Las consultas pasan a tener de 100 documentos a

20. La colección final estará formada por documentos de Newsela y de Google.

Prueba 3 – Comprobar los scripts de inserción sql para las tablas DOCUMENT y

QREL generados con Python.

• Fallos encontrados: ninguno, los documentos y sus relaciones con las

consultas se integran correctamente en la base de datos.

3.5.4.2. Módulo II – Test de Fluidez Lectora

Prueba 1 – Comprobar al evaluar una afirmación como Verdadera o Falsa en el

Test de Fluidez Lectora, el sistema registra el momento en el que se da la respuesta.



• Fallos Encontrados: El Test Fluidez Lectora no registra correctamente el

momento en el que el participante emite su respuesta

• Solución: a través de una función JavaScript implementada en Angular, se

implementa el evento que recoge la muestra de tiempo en el momento en

el que se pulsa el botón.

Prueba 2 – Observar si los botones de radio para evaluar las afirmaciones como

Verdaderas o Falsas son mutuamente excluyentes.

• Fallos Encontrados: El Test Fluidez Lectora no restringe que la

respuesta dada se pueda reevaluar. Es decir, los botones verdadero-falso

no son mutuamente excluyentes.

• Solución: a través de una función JavaScript implementada en Angular,

se garantiza la exclusión de botones, para que así el participante no pueda

cambiar de respuesta si lo desea.

Prueba 3 – Se prueba la funcionalidad de un test entrenamiento-prueba con 4

afirmaciones que deben ser respondidas correctamente, antes de iniciar el test.

• Fallos encontrados: ninguno

3.5.4.3. Módulo III – Sistema PIR

Prueba 1 – Demo de la fase de recuperación de información mediante

documentos y consultas de prueba.

• Fallos encontrados: el desplegable para seleccionar la consulta no

muestra la descripción de esta cuando se selecciona.

• Solución: incluir la descripción de la consulta en la vista mediante una

variable definida en Angular.



Prueba 2 – Integración de los 100 documentos por consulta reales (Newsela,

ClueWeb, Google)

• Fallos encontrados: La mayor parte de documentos que se visualizan

de ClueWeb son ilegibles.

• Solución: el conjunto posible de documentos que se pueden visualizar

es de 20 documentos por consulta solo de Newsela y Google (Se integran

más documentos de Google)

Prueba 3 – Comprobar si los documentos que se van a evaluar para una

consulta forman el conjunto correspondiente (4 aleatorios + 5 primeros + todos los de

Newsela + documentos visitados) y observar si no hay inconsistencias en la emisión

de juicios de relevancia.

• Fallos encontrados:

a. Conjunto para evaluar (si es el correspondiente): ninguno

b. Interacción en la emisión de juicios de relevancia (relevante o no

relevante): el botón que permite pasar al siguiente documento no

está deshabilitado en ningún momento, pudiendo generar que el

participante no evalúe el documento y pase al siguiente.

• Solución: Función JavaScript que en el momento en el que el participante

evalúe el documento actual como relevante o irrelevante, llama al evento

que habilita el botón que dirige al siguiente documento a evaluar.

Prueba 4 – Realización de varias sesiones de búsqueda

• Fallos encontrados: no se eliminan las consultas lanzadas en sesiones

previas.

• Solución: función implementada en Angular que reciba como parámetro

la consulta que ha sido previamente lanzada y la elimine de la estructura

de datos que contiene las consultas disponibles para dicho participante.



Ilustración 31. Función que elimina las consultas previamente lanzadas

3.6. Despliegue y entregas

Se realizan entregas del software al cliente (parciales o completas), que éste

evalúa y que retroalimenta. Estas entregas vendrán determinadas por los distintos

sprints que se hayan realizado en el ciclo de vida del proyecto software. Mientras que

las entregas parciales no garantizan la completitud en el desarrollo del producto, las

entregas completas supondrán el despliegue final del producto.

3.6.1. Sprints

En la tabla 11 se detallará cada sprint realizado en el proyecto y se indicará si su

realización tiene como consecuencia el despliegue final de dicho producto o no

(entrega parcial o completa):



Sprint Mes Producto entregado Fecha de

Entrega

Tipo de

entrega

1 Julio Diseño e implementación de la Base de

Datos (posteriormente actualizado)

31/07/18 Parcial

Test de Fluidez Lectora: Inicio + Test

Entrenamiento-Prueba + Formulario de

datos web implementados

20/07/18 Parcial

2 Septiembre Actualización del diseño e implementación

de la Base de Datos

7/09/18 Completa

Test de Fluidez Lectora 26/09/18 Completa

3 Octubre Corpus consulta-documentos: ClueWeb +

Newsela + Google

(posteriormente modificado debido a

ilegibilidad de los documentos ClueWeb)

31/10/18 Parcial

4 Noviembre Plataforma PIR hasta resumen de lo

aprendido

(*) Nota: La entrega todavía no incluye la

visualización para la lectura de los

documentos

22/11/18 Parcial

5 Diciembre Plataforma PIR con consultas-documentos

oficiales

21/12/18 Completa

Corpus consulta-documentos: Newsela +

Google

4/12/18 Completa

6 Enero Documentación del proyecto 31/01/18 Completa

Tabla 11. Incrementos realizados durante el desarrollo del proyecto



Capítulo 4

Interfaz

En este capítulo abarcaremos diversos aspectos relacionados con la

visualización gráfica de la aplicación web y el grado de interacción del participante de

los experimentos con esta.

Desde el uso de Storyboards que marcarán el flujo visual de la interfaz, así como

de iconos e imágenes gráficas (metáforas visuales empleadas) hasta aspectos que

abarcan el análisis de la usabilidad de la interfaz o la influencia de los distintos colores

empleados.

4.1. Storyboards

Los storyboards representan una narración gráfica que describen el flujo de

ejecución y sus distintas vías posibles en la aplicación desarrollada, en nuestro caso,

la plataforma web para la evaluación de la comprensión lectora.

Cada Storyboard marca un escenario de interacción posible, permitiendo indicar

los enlaces a diferentes páginas a partir de los resultados de las interacciones de los

usuarios. [20]

El flujo de interacciones de nuestro sistema se dividirá en los dos módulos de

software que aportan una interfaz gráfica en nuestro proyecto: el módulo II-Test de

Fluidez Lectora y el módulo III-Sistema PIR para la evaluación de la comprensión

lectora.

A través de Storyboard, no solo acercamos al lector a un ‘croquis’ visual de la

plataforma, sino que también le haremos ver los distintos escenarios posibles de la

plataforma, resultantes de una interacción del participante de los experimentos en uno

de los escenarios de la misma.



Ilustración 32. Storyboard del Test de Fluidez Lectora



Ilustración 33. Storyboard del Sistema PIR



4.2. Metáforas visuales empleadas

Las distintas imágenes empleadas en la interfaz gráfica de la plataforma tienen

una carga semántica importante en la misma, si no representan lo mismo para los

usuarios que para el desarrollador, esto puede lentificar el progreso de la interacción,

debido a la confusión al participante,

Por lo tanto, es oportuno describir mínimamente cada una de las que se han

empleado.

Ilustración 34. Símbolo de la UJA

Metáfora visual Símbolo de la UJA

Descripción La plataforma ha sido desarrollada por

miembros de la universidad, y en

consecuencia es conveniente usar el

logo de la organización

Ilustración 35. Libro con páginas abiertas – Módulo III

Metáfora visual Libro con páginas abiertas

Descripción Logo empleado para la etapa 1.

Recuperación de Información del

módulo III – Asociado a la búsqueda de

información en un libro



Ilustración 36. Lápiz escribiendo sobre un folio – Módulo III

Metáfora visual Lápiz escribiendo sobre un folio


Resumen de lo Aprendido del módulo

III – Asociado a que debe escribirse un

texto, intuyendo que será en el panel de

entrada de texto visible

Ilustración 37. Lupa observando un documento – Módulo III

Metáfora visual Lupa observando un documento


Evaluación de documentos del módulo

III – Asociado al análisis de un

documento, que en nuestro caso será

textual

Ilustración 38. Flecha que indica el retorno a algún lugar – Módulo III

Metáfora visual Flecha de retorno

Descripción Logo empleado para la etapa Fin del

módulo III – Asociado a regresar a algún

lugar de la página, en nuestro caso esta

imagen aparecerá cuando el participante

desee finalizar sesión de búsqueda e

iniciar una nueva (el logo se acompaña

expresamente de texto que informa de

ello)



Ilustración 39. Check de verificado – Modulo III

Metáfora visual Check de verificado

Descripción Logo empleado para la etapa Fin del

módulo III – Asociado a que algún

proceso ha finalizado correctamente,

utilizado para indicar el fin del

experimento (cuando se hayan evaluado

todos los documentos de las 20

consultas).

4.3. Usabilidad

Según [21], el concepto de usabilidad podremos definirlo como:

Medida en la que un producto se puede usar por determinados usuarios para

conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un

contexto de uso especificado.

La tarea de evaluar la comprensión lectora no es tan trivial si debe ir acompañada

de una interfaz gráfica a la que se amolde. El tamaño de letra, de los botones, la fuente

de letra empleada, y la disposición de los elementos en la página web son

fundamentales para satisfacer la definición dada de usabilidad y facilitar la

visualización de los experimentos al participante.

Garantizando una buena usabilidad a través de la evaluación de la misma,

permitiremos que se realicen los experimentos bajo las condiciones óptimas, y así, los

resultados sean verdaderamente representativos.



4.3.1. Evaluación de la usabilidad

A continuación, a través de la metodología de evaluación heurística

analizaremos la usabilidad de nuestro sistema interactivo a lo largo del ciclo de vida.

La evaluación heurística consiste en analizar la conformidad de la interfaz con

unos principios reconocidos de usabilidad mediante la inspección de varios

evaluadores expertos (en nuestro caso, desarrollador y director del proyecto). En el

caso que nos ocupa declararemos 10 reglas heurísticas y veremos si hemos cumplido

con cada una de ellas: [21]

1. El estado del sistema siempre debe ser visible, es decir el usuario debe

saber en qué lugar de la página se encuentra.

Esto se cumple tanto en el test de fluidez lectora como en el sistema de

evaluación de documentos PIR, ya que en el test cada página comienza

con un título que indica el lugar donde se encuentra el participante,

mientras que en el sistema PIR el breadcrumb va indicando en cada

momento el lugar dónde se encuentra el participante.

2. Utilizar el lenguaje de los usuarios.

En nuestra plataforma, el principal objetivo es proporcionar una

herramienta para medir la comprensión lectora, y en consecuencia, la

información procedente de la misma debe ser comprensible, al menos

para el sector para el que está destinado (estudiantes).

3. Control y libertad para el usuario.

Al tener un carácter experimental, el flujo de visualización de las distintas

páginas de la plataforma es secuencial, pero a su vez, en cada una de

ellas el participante puede interactuar como lo crea más oportuno.

4. Consistencia y estándares

El sistema informa al inicio de cómo debe de proceder para que cada uno

de los dos experimentos se realicen de la forma más eficiente posible.



Tras esto, el participante puede navegar por la aplicación, libre pero

secuencialmente, sin necesidad de que el sistema le indique en cada

momento cómo debe de proceder o cómo dirigir la interacción, otorgando

cierto grado de consistencia a nuestra plataforma web.

Ciertamente, no se ha seguido ningún tipo de estándar, como el estándar

de facto W3C que garantizaría una mayor consistencia en la usabilidad

del sistema.

5. Prevención de errores

A lo largo del ciclo de vida de la plataforma, se han anticipado y corregido

los posibles errores en la interacción que pueda cometer el usuario

participante.

De esta forma, aseguramos en mayor medida que el flujo de interacción

esté controlado.

6. Minimizar la carga de la memoria del usuario

El participante no deber tener que recordar información que sea de utilidad

en más de una de las páginas que integren los experimentos. En nuestra

plataforma se mantienen los elementos que juegan un papel fundamental

en las distintas páginas por las que pasa.

Véase, como ejemplo, que una vez que se lanza una consulta en el

sistema PIR, se mantiene en cada momento visible el título y descripción

de la consulta lanzada, para que mientras explore los documentos no

tenga que recordar en ningún momento qué consulta había lanzado y la

temática sobre la que trataba.

7. Flexibilidad y eficiencia de uso

Los elementos de interacción, así como las imágenes y texto utilizado en

la visualización tiene un tamaño adecuado para que sea visible o



fácilmente accesible, garantizando un flujo de interacción-ejecución fluido

en la medida que lo requiera cada una de las partes de la plataforma web,

integrada por el módulo II (Test de Fluidez Lectora) y el módulo III

(Sistema PIR para la evaluación de documentos).

8. Diálogos estéticos y de diseño minimalista

Las páginas que conforman la plataforma siempre cuentan con la misma

estructura-disposición de los elementos que las integran, con un orden de

lectura de arriba abajo, de izquierda a derecha.

La información que la plataforma web transmite al participante

(exceptuando la visualización de los documentos del sistema PIR) es

siempre la mínima posible, para no agobiar al participante con excesivo

texto innecesario.

9. Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de errores.

Cuando se realiza una interacción anómala, los mensajes mostrados

tienen como color de fuente el rojo, asociado comúnmente en la web a

una anomalía que se ha producido en la interacción. Además, el mensaje

de error siempre será breve y su significado estará lo suficientemente

claro como para que el participante identifique cómo ha generado la

interacción anómala.



Ilustración 40. Error si se pulsa en Iniciar Búsqueda de Información sin seleccionar ninguna consulta previamente.

10. Ayuda y documentación

Al participante se le informa en cada uno de los experimentos de las

condiciones y prerrequisitos que debe satisfacer para que pueda

interactuar correctamente.

4.4.3. Accesibilidad

Es importante que el diseño de nuestra aplicación, no sólo se centre en

estudiantes que no tengan ninguna discapacidad, debemos contar con aquellos que

presentan dificultades cognitivas y visuales en cuanto a lectura de texto se refiere.

Por ello, y como hemos dicho previamente nos hemos asegurado de que el

tamaño de letra, la fuente de letra utilizada, la disposición de los elementos, metáforas

visuales empleadas, etc, sean escogidos lo más óptimamente posible para que la

interfaz se ajuste y acomode al mayor número de personas posible,

independientemente de la dificultad cognitiva o visual del participante de los

experimentos.



4.5. Uso del color en la interfaz

Para finalizar el proceso de análisis de la interfaz se hará una especial mención

al uso de colores empleados, mientras que para el background se ha usado verde

oliva para la cabecera y blanco para el resto de la página, para las letras

principalmente se han usado el verde, negro, gris, azul (para enlaces a documentos).

El uso de estos colores no es casualidad, el uso del verde oliva para la cabecera

que se combina con el logotipo de la UJA es claramente indicativo de la identidad que

la figura del olivar representa para la provincia de Jaén donde se encuentra ubicada

la universidad.

Además, se han evitado la combinación de colores oponentes en una pantalla:

rojo-verde, amarillo-azul; y se han seguido las siguientes recomendaciones generales:

• Usar altos contrastes de color entre la letra y el fondo.

• Limitar el número de colores (5±2). En nuestro caso, se ha hecho uso de

4 colores en total (verde, negro, gris azul).

• Evitar colores muy saturados.

4.6. Capturas finales

A continuación, se mostrarán distintas imágenes con el apartado visual de cada

uno de los experimentos, página por página:



4.6.1. Módulo I – Test de Fluidez Lectora

Ilustración 41. Página inicial del Test de Fluidez Lectora

Ilustración 42. Test de entrenamiento-prueba



Ilustración 43. Captura de prueba oficial de Test de Fluidez Lectora en español

Ilustración 44. Captura de prueba oficial de Test de Fluidez Lectora en inglés



Ilustración 45. Formulario datos personales

4.6.2. Módulo II – Plataforma PIR

Ilustración 46. Página inicial del sistema PIR



Ilustración 47. Página donde se lanza la consulta



Ilustración 48. Recuperación de documentos



Ilustración 49. Resumen de lo aprendido

Ilustración 50. Evaluación de documentos



Ilustración 51. Fin de sesión



Capítulo 5

Obtención y análisis de resultados

En esta sección extraeremos y analizaremos los resultados de lanzar el test

sobre un grupo de estudiantes de máster de Ingeniería Informática de la universidad

de Jaén.

Los resultados recopilados se expondrán en forma de valores estadísticos

(media, desviación típica), tablas y gráficas. De esta manera, usaremos estos recursos

para analizar e inferir conocimiento en torno a la tarea objetivo de evaluación de la

comprensión lectora.

Para recopilar los datos de los experimentos correspondientes al módulo II: test

de fluidez lectora y al módulo III: Sistema PIR, se ha procedido a realizar un conjunto

de consultas SQL sobre la base de datos pirdb, que da soporte físico al conjunto de

tablas y relaciones previamente definidas en el esquema relacional.

Para que los resultados sean lo más significativos en nuestro objetivo,

deberemos observar aquellas tablas que reciban directamente la interacción y que

tengan que ver con una determinada evaluación por parte del participante.

En el caso del módulo II, interesa analizar los datos recopilados en torno a las

distintas evaluaciones de las afirmaciones de la prueba (Verdadero/Falso) emitidas

por el participante; donde las tabla que contenga la interacción con la pregunta

(PARTICIPATION) y la tabla que tenga registradas las respuestas oficiales

(SENTENCE_TEST) a esas preguntas juegan un papel fundamental.

Respecto módulo III, los datos recopilados de mayor relevancia en nuestro

propósito principal girarán, como es de suponer, en torno a la evaluación

(Relevante/No relevante) del subconjunto seleccionado de documentos para cada una

de las consultas, para ello se observará si coinciden los juicios de relevancia reales

de los documentos y los emitidos por el participante. en su evaluación serán

fundamentales para analizar el nivel de comprensión de los documentos dicho lector.



A partir de dichos datos correspondientes a los módulos II y III, podemos inferir

con cierta aproximación el nivel de comprensión lectora de los participantes del

experimento.

Lógicamente, a parte de la coincidencia entre la respuesta dada y la respuesta

real, la variable temporal podrá jugar un papel algo más secundario, pero no por ello

menos significativo, para obtener unos resultados-análisis más precisos deben

analizarse los rasgos temporales de las interacciones de los usuarios con el sistema.

Por ejemplo, el tiempo que le lleva terminar la prueba de fluidez lectora o el momento

en el que abre-cierra un documento en el sistema PIR son factores que influyen

directamente en el análisis de la comprensión lectora, y como tal se registra también

en la base de datos.

Definido el escenario, tras esta descripción de cómo se recopilarán y analizarán

los resultados, se procede ahora sí a la muestra y análisis de estos. Cabe destacar

que se escogerá una muestra de 22 participantes que han realizado el test de fluidez

lectora (2 de ellos presentarán valores outliers) y 9 que han sido los que han evaluado

diversos documentos en el sistema PIR.



5.1. Análisis e interpretación de los resultados

5.1.1. Módulo II: Test de Fluidez Lectora

La tabla 12 muestra el número de afirmaciones correctas, incorrectas y no

contestadas por parte de los participantes del experimento.

ID del participante Correctas Incorrectas No contestadas

466629 1 0 64

3383141 64 1 0

8136538 59 3 3

10646265 38 3 24

10774654 49 2 14

14026151 34 1 30

15238342 57 3 5

15914868 14 1 50

22489028 65 0 0

25509978 36 3 26

25648544 54 0 11

25650700 64 1 0

26066724 40 1 24

26277827 57 2 6

26523925 0 1 64

27673121 0 1 64

29958612 47 2 16

30094473 25 0 40

30165510 0 1 64

30384520 24 1 40

30420422 43 1 21

30535092 47 1 17

30759827 56 1 8

31014032 59 1 5

31280813 17 2 46

31408446 64 0 1



31646728 64 0 1

33489939 65 0 0

34260775 60 1 4

37653462 38 2 25

40116631 60 0 5

40460880 24 2 39

40757058 33 1 31

41039763 6 0 59

41326319 6 1 58

41653979 45 0 20

41895155 40 1 24

42147032 51 0 14

44634602 0 1 64

47887568 46 0 19

49741952 36 0 29

54028305 45 1 19

54564458 63 2 0

56410993 2 1 62

57138201 60 0 5

57347310 54 0 11

57497740 46 1 18

57923140 51 2 12

59190421 59 1 5

59200218 35 1 29

59571850 57 0 8

Tabla 12. Resultados del Test de Fluidez Lectora

Las filas remarcadas en color rojo serán outliers o valores fuera de lo normal que

se descartarán a la hora de representar las gráficas y generar los distintos resultados

estadísticos. Estos outliers se basan en una interacción atípica con el sistema, no

cumpliendo con un mínimo de respuestas contestadas (mínimo 3).



Ilustración 52. Número de respuestas dadas por participante

En el gráfico de barras anterior, los participantes 56410993 y 41039763 han sido

los que menos respuestas han registrado en el test de fluidez lectora; así mismo, en

cuanto al rango de respuestas registradas como incorrectas por lo general hay cierto

grado de equidad y no se disparan mucho entre los participantes.

Finalmente, los participantes 22489028 y 33489939 han sido los que han

registrado los mejores resultados con las 65 afirmaciones de la prueba contestadas

correctamente en el tiempo establecido; aun así, los participantes 31408446 y

31646728 no se distancian mucho de los mejores resultados con un total de 64

respuestas correctas y ninguna incorrecta.



Ilustración 53. Proporción de respuestas dadas por participante

Como podemos observar en el gráfico circular, la mayor parte de las respuestas

registradas por el sistema (69%) cuentan como correctas, aun así, cabe destacar el

porcentaje significativo que encontramos de las aquellas que no han sido contestadas,

o bien son incorrectas, representando un 31% del total, donde podemos enfatizar en

el hecho de que el factor temporal, bajo un tiempo límite de 3 minutos para realizar la

prueba, ha jugado un papel fundamental, pues el 29% del total son afirmaciones que

no han llegado a ser evaluadas por el participante.

Ciertamente al tratarse de un test con afirmaciones muy simples a evaluar, el

porcentaje de respuestas correctas registradas es el esperado, un 2% del total.

A continuación, presentaremos algunas medidas estadísticas derivadas del total

de afirmaciones contestadas:

Promedio Desviación típica

Correctas 44,76 17,15

Incorrectas 1,02 0,93

No contestadas 19,22 17,08

Tabla 13. Valores estadísticos de las afirmaciones del test de fluidez lectora por participante

69%2%

29%

Proporción de respuestas correctas, incorrectas y no contestadas

Correctas Incorrectas No contestadas



El promedio (media) de respuestas correctas es de 44,76~48 evaluaciones por

participante, el de respuestas incorrectas, 1,02~1, y el de respuestas no contestadas

19,22~19. Sin embargo, a través de las medidas de dispersión utilizadas que

garantizan si existe una mayor o menor separación de los valores respecto al

promedio.

Respecto a la desviación típica, cuanto mayor sea ésta, más dispersos serán los

datos obtenidos y menos representativo será el promedio; mientras que en el caso

contrario los datos se encontrarán más agrupados en torno al promedio (media) y, por

lo tanto, éste será más representativo.

Así, podemos inferir que el promedio de respuestas correctas y no contestadas

por participantes es poco representativo, puesto que presentan unos valores de

desviación típica bastante altos: 17,15 (Correctas) y 17,08 (No contestadas). Sin

embargo, para el conjunto de respuestas incorrectas, la desviación típica sí que hace

representativo al promedio de éstas, puesto que presenta un valor muy bajo: 0,93

(Incorrectas).

Por lo que interpretamos que las respuestas incorrectas se encontrarán mucho

más agrupadas en torno al promedio (garantizando que éste sea realmente

representativo) mientras que las respuestas correctas y no contestadas presentan

cierta equidad en el alto grado de disparidad respecto al promedio (haciendo de éste

una medida poco representativa de dichos datos).

5.1.2. Módulo III: Sistema PIR

La tabla 14 muestra el número de respuestas correctas-incorrectas emitidas por

cada participante para cada documento evaluado.

ID del participante Correctas Incorrectas

466629 15 20

3383141 55 21

10646265 30 24

25650700 6 6



26523925 31 47

27673121 50 75

30165510 21 16

30420422 102 37

31646728 69 56

40116631 18 11

49741952 18 7

56410993 12 13

57497740 13 12

57923140 69 60

Tabla 14. Resultados de las evaluaciones de documentos emitidas por participante

Ilustración 54. Proporción de evaluaciones emitidas por participante

En el diagrama de barras apiladas que representa la ilustración 54, podemos

observar qué participantes presentan el mayor grado de comprensión lectora de

documentos, en base a los que mantengan una mayor proporción de documentos

evaluados correctamente y la menor para los evaluados incorrectamente. Estimamos

en consecuencia que los participantes que presentan el mejor grado de comprensión

15

5530 6

31 5021

10269 18

18

12 13 69

20

2124 6

47 7516

3756 11

7

13 12 60

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Proporción de evaluaciones correctas-incorrectas por participante

Correctas Incorrectas



lectora son el participante 3383141 (55 correctamente evaluados, frente a 21

incorrectos) y 30420422 (102 correctamente evaluados, frente a 37 incorrectos).

Ilustración 55. Dispersión en las evaluaciones emitidas por participante

El gráfico de la ilustración 55, se muestra la comparativa de respuestas

correctas/incorrectas, así como la disparidad que presentan entre las diversas

respuestas correctas e incorrectas dadas por los participantes. Como podemos ver

en la función azul, hay una gran diferencia en el número de evaluaciones correctas

en cada participante (mucha disparidad entre el número de evaluaciones correctas

emitidas).

En cuanto a evaluaciones incorrectas, a diferencia de las correctas, a pesar de

seguir teniendo cierto grado de disparidad, presentan una mayor uniformidad en el

número de evaluaciones emitidas por participante.




Tabla 15. Valores estadísticos de las evaluaciones de documentos por participante

En la tabla 15, vemos como ni las 36,35~36 respuestas correctas de media ni

las 28,92~29 incorrectas son significativamente representativas, puesto que los

valores de desviación típica son altos.

0

20

40

60

80

100

120

0 2 4 6 8 10 12 14 16

Grado de dispersión de las evaluaciones por participante




Esto no quita que las evaluaciones de documentos incorrectas agrupen los datos

mejor en torno a la media que las evaluaciones correctas, ya que presentan una

desviación típica considerablemente menor que las evaluaciones correctas. Es decir,

el número de evaluaciones incorrectas emitidas por cada participante es más próximo

que el de las evaluaciones correctas.

A continuación, la tabla 16 mostrará el conjunto de evaluaciones correctas-

incorrectas emitidas por consulta:

ID de la consulta Título de la consulta Correctas Incorrectas

1 Factores que inciden positivamente

en la generación de riqueza en los

países

40 39

2 Animales salvajes en cautividad 101 74

3 Lesiones en accidentes deportivos 43 61

4 Biografía de pintores perteneciente a

la escuela flamenca

5 5

5 Acciones de discriminación positiva 31 27

6 Actividad laboral en áreas

subdesarrolladas o en vías de

desarrollo

2 10

7 Procesos químicos aplicados a la

investigación

17 23

8 Hábitos saludables en países

desarrollados

41 39

9 Situación de pueblos precolombinos

en la actualidad

4 6

10 Población cubierta por Medicaid 10 -

11 Comunidades interculturales 11 13

12 Estrategias educativas en

enseñanzas regladas

19 9



13 Desarrollo tecnológico de vehículos

sin conductor

21 14

14 Causas de la Guerra de Secesión 36 8

15 Políticas de integración social de los

inmigrantes

24 21

16 Efectos adversos del cambio

climático

36 15

17 Protección de especies amenazadas 16 15

18 Discursos televisados de Obama en

su último año legislativo

18 13

19 Acuerdos internacionales para luchar

contra el cambio climático

27 8

20 Especies autóctonas amenazadas

por la presencia de especies

invasoras

7 5

Tabla 16. Resultados de las evaluaciones de documentos por consulta

Ilustración 56. Número de evaluaciones emitidas por consulta

Como se puede observar en el gráfico de la ilustración 56, la consulta con

identificador 2, titulada Animales salvajes en cautividad presenta mayor número de

respuestas correctas por participante. Sin embargo, también es el que presenta

mayor número de respuestas incorrectas, esto puede se debe a que existe una

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Núm

ero

de r

espuesta

s

Identificador de la consulta

Evaluaciones de documentos por consulta




preferencia por parte de los participantes a lanzar dicha consulta, es decir, no es la

consulta con mejores índices de respuesta correcta frente a incorrecta, pero la

temática de la consulta sí que puede resultar la más interesante para los

participantes.

Ilustración 57. Proporción de evaluaciones emitidas por consulta

Según el diagrama de proporciones anterior representado en la ilustración 57,

la consulta 10 titulada Población cubierta por Medicaid presenta el mejor índice de

respuestas correctas frente a incorrectas (100%), con todos los documentos (10 en

total) evaluados correctamente.

Además, hay que destacar que la consulta 14 con título Causas de la Guerra de

Secesión, pese a no ser la consulta que registre mayor índice de evaluaciones, cabe

destacar el hecho de que presenta la mejor proporción de evaluaciones correctas

frente a incorrectas tras la consulta 10. Por lo que se puede apreciar que, para esa

consulta, el grado de comprensión del lector es muy bueno. Otras consultas donde se

puede apreciar un buen grado de comprensión lectora son la 16 (Efectos adversos del

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

Proporción

Identificador

de la c

onsulta

Proporción de evaluaciones correctas e incorrectas




cambio climático), 12 (Estrategias educativas en enseñanzas regladas) y 19

(Acuerdos internacionales para luchar contra el cambio climático).

Las consultas con las que inferimos peor grado de comprensión lectora son la 6

(Actividad laboral en áreas subdesarrolladas o en vías de desarrollo) y la 9 (Situación

de los pueblos precolombinos en la actualidad).




Tabla 17. Valores estadísticos de las evaluaciones de documentos por consulta

El promedio de evaluaciones correctas por consulta es de 25,45~25, mientras

que el número promedio de incorrectas por consulta es algo menor, aproximadamente

21 evaluaciones incorrectas por consulta.

Otro factor para destacar es que, tanto en el número de evaluaciones por

consulta como por participante, el grado de dispersión del número de evaluaciones

incorrectas respecto a la media es menor. Es decir, los promedios de las evaluaciones

incorrectas de documentos (por participante y consulta) son más representativos que

los de las evaluaciones correctas (más dispares).

5.1.2.1. Análisis de los resultados en función de la complejidad de los documentos

Como ya se sabe, los documentos de Newsela integrados en el módulo III

presentan diversos niveles de complejidad lectora (0 más complejo; 4 menos

complejo), para una misma consulta es probable que el participante llegue a evaluar

el mismo documento de Newsela pero con diferente grado de dificultad. Por ello, para

profundizar en el análisis de la comprensión lectora del participante, se analizará si

hay diferencia estadísticamente significativa entre los resultados si distinguimos entre

documentos fáciles y difíciles.



ID del

participante

Correctas

Newsela

Difíciles

Correctas

Newsela Fáciles

Incorrectas

Newsela

Difíciles

Incorrectas

Newsela

Fáciles

3383141 11 12 4 3

10646265 6 9 8 6

25650700 1 1 1 1

30420422 22 18 7 11

31646728 11 7 10 12

40116631 3 4 1 0

49741952 3 2 1 2

56410993 3 3 2 1

57497740 3 6 5 2

57923140 9 11 19 17

Tabla 18. Número de evaluaciones por participante en función de la complejidad de los documentos

Ilustración 58. Documentos evaluados correctamente en función de su complejidad

0

5

10

15

20

25

Nº

de E

valu

acio

nes

ID del participante

Documentos evaluados de Newsela correctos según grado de complejidad

Correctas Newsela Difíciles Correctas Newsela Fáciles



Ilustración 59. Documentos evaluados incorrectamente en función de su complejidad

Media Desviación

típica

Difíciles 7,2 6,33859431

Fáciles 7,3 5,29255242

Tabla 19. Valores estadísticos del número de documentos evaluados correctamente según grado de complejidad

Media Desviación

típica

Difíciles 5,8 5,63323471

Fáciles 5,5 5,8357138

Tabla 20. Valores estadísticos del número de documentos evaluados incorrectamente en función de su complejidad

Como se observa en las gráficas de las ilustraciones 58 y 59, y en tablas 19 y

20, no existe diferencia estadísticamente significativa entre los resultados si

distinguimos entre documentos fáciles y difíciles, indicando que los participantes han

fallado y acertado en la misma medida, independientemente de la complejidad del

texto.

Sin embargo, podemos observar que el número de documentos evaluados

correctamente fluctúa significativamente más (desviación típica) cuando tienen una

0

5

10

15

20

Nº

de E

valu

acio

nes

ID del participante

Documentos evaluados de Newsela incorrectos según grado de complejidad

Incorrectas Newsela Difíciles Incorrectas Newsela Fáciles



mayor complejidad lectora que cuando son más fáciles de leer: 6,34 (difíciles) frente

a 5,29 (fáciles).

En el caso de los documentos evaluados incorrectamente, pasa justo lo

contrario, los documentos fáciles se encuentran más dispersos en torno a la media

que los difíciles, aunque la diferencia entre estos es minúscula, por lo que se

encuentran más equitativamente dispersos en torno a la media: 5,6 (difíciles) frente

5,84 (fáciles).

5.1.3. Mejores y peores participantes de los experimentos

El propósito de esta sección será analizar si existen correspondencias entre los

resultados emitidos en el módulo II y III por los participantes, para así llegar a

comprobar si en algún caso, existe algún participante que especialmente haya

desempeñado un buen o mal trabajo en ambos experimentos.

Para comprobar si existe alguna correspondencia, en la tabla 23 separaremos

de la población aquellos participantes con un desempeño especialmente bueno en el

test de fluidez lectora, ordenando el número de respuestas correctas emitidas de

menor a mayor, nos quedaremos con el subconjunto que representa al 10% de

participantes que han evaluado más respuestas correctas; es decir, aquellos valores

por encima del percentil 90.

Del mismo modo, para la tabla 21 seleccionaremos aquellos participantes con

un desempeño especialmente malo en el test, por debajo del 10% de evaluaciones

correctas; es decir, aquellos valores que están por debajo del percentil 10.

Obviamente, se han descartado aquellos participantes que han emitido evaluaciones

outliers.

Finalmente, respecto al experimento del Sistema PIR, en la tabla 24 se

mostrarán los 5 mejores participantes del módulo III que han emitido el mayor número

de juicios de relevancia correctos. Mientras que en la tabla 22, se hará lo mismo con

los 5 participantes que han tenido un peor desempeño en dicho experimento.

Para determinar la medida de desempeño del sistema PIR se ha hecho uso de

la proporción evaluaciones correctas / evaluaciones incorrectas por participante; que,



ordenándose de menor a mayor, representará la escala que va de un peor índice de

comprensión lectora hasta el mejor.


41326319 6 1 58

41039763 6 0 59

15914868 14 1 50

31280813 17 2 46

40460880 24 2 39

Tabla 21. Peores participantes del test de fluidez lectora


26523925 31 47

27673121 50 75

466629 15 20

56410993 12 13

25650700 6 6

Tabla 22. Peores participantes PIR


30420422 102 37

3383141 55 21

49741952 18 7

31646728 18 11

57923140 21 16

Tabla 24. Mejores participantes PIR


22489028 65 0 0

33489939 65 0 0

31408446 64 0 1

31646728 64 0 1

3383141 64 1 0

Tabla 23. Mejores participantes del test de fluidez lectora



Observando la tabla 23 y la tabla 24, vemos que 2 de los mejores participantes

están presentes en ambas tablas, concretamente los participantes 31646728 y

3383141.

Por lo que podemos concluir que entre los mejores participantes hay un pequeño

grado de equivalencia mientras que para los peores no existe ninguna

correspondencia. Esta afirmación deriva a su vez en que los participantes 31646728

y 3383141 son definitivamente los mejores participantes de toda la plataforma y, por

ende, tienen los mejores niveles de comprensión lectora.

5.1.4. Correlación de resultados entre experimentos

Para comprobar si realmente existe una correlación entre los juicios de

relevancia del usuario y su nivel de fluidez lectora calcularemos el coeficiente de

correlación de Pearson, R, a través de la herramienta de cálculo que nos proporciona

Social Science Statistics [22] que mide cómo de fuerte es la relación existente entre

las dos variables que se deseen medir. Se nos presentan 3 posibles valores límite

para R:

• Valor R = 1: correlación perfecta positiva, es decir, si una variable

aumenta entonces la otra también lo hará. De la misma forma, si una

decrece, la otra también lo hará.

• Valor R = -1: implica una correlación perfecta negativa, existe una

relación inversa entre ambas variables; mientras que una aumenta la otra

disminuye, y viceversa.

• Valor R = 0: las variables son intrínsicamente independientes entre sí, y

no existe alguna relación.

Así a través del coeficiente de correlación de Pearson, indagaremos en si existe

alguna correlación entre la fluidez lectora del participante y su habilidad cognitiva para

evaluar documentos como relevantes o irrelevantes.

Para la tabla 25 extraeremos dos coeficientes de Pearson (R Correctas, R Incorrectas)

donde uno determinará si existe correlación entre los experimentos en base a las

respuestas correctas dadas, y otro si existe correlación en base a las respuestas



incorrectas (incorrectas + no contestadas en caso del test). Como es obvio, no se

considerarán aquellos participantes que sean outliers en el test de fluidez lectora.

ID

participante

Correctas

Test

Correctas

PIR

Incorrectas Test

(no contestadas

inclusive)

Incorrectas PIR

3383141 64 55 1 21

10646265 38 30 27 24

25650700 64 6 11 6

30420422 43 102 22 37

31646728 64 69 1 56

40116631 60 18 5 11

49741952 36 18 29 7

56410993 2 12 63 13

57497740 46 13 19 12

57923140 51 69 14 60

Tabla 25. Coeficientes de Pearson para respuestas correctas e incorrectas

El coeficiente de Pearson para el conjunto de respuestas correctas R Correctas en

cada experimento es de 0,245; esto quiere decir que, aunque técnicamente represente

una correlación positiva, la relación existente entre los juicios de relevancia emitidos

correctamente y las respuestas correctas en el test de fluidez lectora es débil, y, por

lo tanto, debido a que el valor es próximo a 0, existe un pequeño grado de equivalencia

entre las respuestas correctas de ambos experimentos.

Del mismo modo, obtenemos un coeficiente de correlación de Pearson para las

respuestas incorrectas R Incorrectas de -0,3024, que, aunque represente técnicamente

una correlación negativa, la relación entre el número de respuestas incorrectas dadas

por cada participante en ambos experimentos es débil, al igual que para las respuestas

correctas.

R Correctas = 0,245 R Incorrectas = -0,3024



5.2. Capturas resultado de consultas SQL lanzadas para la

extracción de datos

Para verificar que el análisis de resultados es veraz, se adjuntan las distintas

capturas del resultado que generan el conjunto de consultas SQL lanzadas para la

recopilación de datos.

Cabe destacar que las capturas que se mostrarán con el resultado de las

consultas serán en su mayoría un subconjunto del total debido al número considerable

de tuplas que muestran algunas.

• Test Fluidez Lectora

1. Consulta 1 para extraer los resultados del test del participante (ID

participante, Correctas, Incorrectas o no contestadas):

Ilustración 60. Captura resultado de la consulta 1



2. Consulta 2 para extraer los resultados del test del participante (ID

participante, Correctas, Incorrectas o no contestadas):

Ilustración 61. Resultado de la consulta 2



• Plataforma de Recuperación de Información

3. Consulta 3 (Identificador de la evaluación, identificador de la consulta,

título de la consulta, identificador del documento, juicio de relevancia del

participante, relevancia real del documento)

Ilustración 62. Captura resultado de la consulta 3

4. Consulta 4 – Evaluaciones Correctas (por participante):




5. Consulta 5 – Evaluaciones incorrectas (por participante):


6. Consulta 6 – Evaluaciones correctas (por consulta):




7. Consulta 7 – Evaluaciones incorrectas (por consulta):


8. Consulta 8.1 y 8.2 – Newsela Correctas:

Ilustración 67. Resultado de las consultas 8.1 y 8.2

9. Consulta 9.1 y 9.2 – Newsela Incorrectas:

Ilustración 68. Resultado de las consultas 9.1 y 9.2



Capítulo 6

Futuros trabajos

El proyecto proporciona una herramienta para la investigación de las

capacidades lectoras de las personas, en consecuencia, nuestro desarrollo puede

complementarse y mejorarse con diversas tareas no llevadas a cabo para que la

lectura e interpretación de los resultados se haga más simple para el equipo que se

encargue de recolectar los datos referentes a la interacción del usuario con el

participante.

6.1. Experimento con electroencefalogramas

Sería interesante complementar los dos experimentos expuestos (test de fluidez

lectora y sistema PIR de evaluación de documentos) con otro experimento consistente

en el uso de electroencefalogramas que midan la actividad cerebral mientras el

participante lee un documento bajo un marco de tiempo. Cuando finaliza este marco

de tiempo se daría paso a una serie de preguntas que debe responder relacionadas

con el texto del documento.

Los datos de actividad cerebral que nos proporcionaría el electroencefalograma

y las respuestas dadas a las preguntas que se lanzan para cada documento, podrían

ser de gran utilidad si se integran junto con las que recopilamos a través del test de

fluidez lectora y el sistema PIR.

6.2. Interfaz gráfica para la visualización de los resultados

obtenidos

En cuanto a la mejora de la exposición de los resultados, se propone para un

desarrollo futuro una interfaz gráfica, sólo accesible vía administrador que recopile en

cada momento los datos relevantes para inferir e interpretar los resultados de las

consultas SQL correspondientes.

El aspecto gráfico de los resultados facilitaría un proceso de visualización más

rápido de los mismos, puesto que este proceso estaría automatizado y el



administrador no necesitaría de conocimientos SQL (bastaría con la puesta en marcha

de la aplicación mantenida por el equipo de desarrollo), realizando consultas cada

cierto tiempo para mantener ajustadas las gráficas y datos de la interfaz con la base

de datos principal pirdb.

6.3. Sistema optimizado para plataformas móviles y tablets.

Además, no sólo la visualización de los resultados sino también sería interesante

que nuestro sistema estuviera optimizado para multiplataforma, estando optimizado

para su uso no sólo a través de una computadora sino también a través de tablets y

teléfonos móviles, aplicando un diseño responsive que lo permitiera.

6.4. Uso de Machine Learning para inferir conocimiento

A pesar de que la inferencia de conocimiento a partir de los datos obtenidos de

la interacción de los participantes con los experimentos de la plataforma web se haya

realizado de forma manual, sería interesante mejorar está inferencia a través de la

aplicación de técnicas de Machine Learning. Esto nos permitiría una mayor

consistencia a la hora de clasificar el grado de comprensión lectora, por ejemplo, de

un participante de los experimentos en base a un conjunto de atributos que tienen

relación con la evaluación de las capacidades lectoras (evaluación dada, tiempo de

interacción, resumen de lo aprendido…).



Capítulo 7

Conclusiones y valoración personal

7.1. Conclusiones

La puesta en marcha de la plataforma es el mecanismo que permite que nuestro

trabajo sirva como herramienta para cualquier equipo de investigación que desee

evaluar la comprensión lectora. El propósito principal no es el desarrollo de la

plataforma en sí, sino los datos subyacentes que ésta nos proporciona a través de las

interacciones de los participantes con la misma.

Es por ello, que el diseño e implementación de la base de datos relacional ha

jugado un papel fundamental en el proceso de desarrollo ágil del software.

Se espera, por lo tanto, que esta plataforma no caiga en el olvido, ya que sienta

las bases de una herramienta que permite la evaluación de la comprensión lectora

adaptada a la era de las tecnologías y de las comunicaciones.

Como es de suponer, esta plataforma, no está desarrollada específicamente

para los estudiantes de universidad, puede sustentar las interacciones de cualquier

otro sector poblacional sobre el que se quieran recopilar datos. Además, la propia

prueba de fluidez lectora finaliza con un formulario web que registra el grupo social y

el nivel educativo en el que se encuentra el participante. Por lo que, si algo destaca

nuestra plataforma, es por su versatilidad.

Puede que el tiempo de desarrollo de nuestra plataforma haya sido mayor que

el esperado, esto se debe a la siguiente razón:

El hecho de que en el módulo I, el corpus de ClueWeb presentara documentos

mal estructurados en el parsing HTML y con una codificación textual para algunas

palabras imposible de decodificar, ha hecho que el tiempo malgastado en esta tarea

haya sido muy considerable debido a la puesta en marcha del crawler que recupera

las páginas ClueWeb.



7.2. Valoración personal

Este proyecto, que me ha hecho indagar en el uso de tecnologías web, me ha

supuesto un verdadero reto puesto que, a pesar de que contaba con cierto

conocimiento previo del uso de lenguajes web (JavaScript, HTML y CSS), lo cierto es

que nunca había construido una aplicación basada en el paradigma del modelo vista-

controlador.

La formación que he recibido en desarrollo web a lo largo del proyecto me ha

otorgado no sólo un mejor conocimiento de las tecnologías utilizadas sino también una

visión global de cómo, cuándo y por qué deben hacerse uso de determinadas

tecnologías en sistemas basados en la web; gracias a la formación recibida en este

trabajo, siento que he ampliado mi espectro laboral, profundizando en metodologías y

tecnologías que prácticamente desconocía antes de embarcarme en el proyecto.

Las tareas que tienen que ver con el lenguaje humano y la comprensión de este

son un campo que realmente me llama la atención y al que me gustaría dedicarme

profesionalmente.

Mi énfasis por el desarrollo del trabajo no sólo se sustenta en el aprendizaje de

nuevos entornos, frameworks, etc, sino en la tarea que comprende el propósito del

proyecto, la tarea de evaluar la comprensión lectora, que bajo mi punto de vista debe

tener no sólo un carácter factual (ver dónde suele tener la gente más dificultad) sino

también un carácter activo que ayude a la población, mejorando la comprensión

textual en base a los resultados inferidos por los experimentos.

Me hubiera gustado poder seguir ampliando, mejorando y complementando el

sistema desarrollado, pero debido a la complejidad que ya de por sí me ha supuesto

desarrollar la plataforma, todo esto queda en manos de trabajos futuros pendientes

de desarrollo.

Para entender mejor por qué este trabajo puede asentar las bases para cubrir,

en cierta medida, una necesidad en el razonamiento humano (la tarea de comprender

textos), me quedo con la frase del escritor inglés Joseph Addison:

«La lectura es para la mente lo que el ejercicio es para el cuerpo»



Bibliografía

[1] Ministerio de Educación, Cultura y Deporte, «PISA. Programa para la Evaluación

Internacional de los Alumnos,» 2015.

[2] Ministerio de Educación, Cultura y Deporte, «España rompe la brecha educativa y se

sitúa, por primera vez en la historia, al nivel de los países más avanzados del mundo,»

6 Diciembre 2016. [En línea]. Available: http://www.educacionyfp.gob.es/prensa-

mecd/actualidad/2016/12/20161207-pisa.html.

[3] D. Robins, «Interactive Information Retrieval: Context and Basic Notions,» Lousiana

State University, School of Library and Information Science.

[4] Newsela, «Newsela | Request Newsela Data,» [En línea]. Available:

https://newsela.com/data/.

[5] Lemur, «The ClueWeb09 Dataset,» [En línea]. Available:

https://lemurproject.org/clueweb09.php/.

[6] A. F. Muñoz-Sandoval, R. W. Woodcock, K. S. McGrew y N. Mather, «Batería III

Woodcock-Muñoz,» [En línea]. Available:

http://www.scielo.edu.uy/scielo.php?script=sci_arttext&pid=S1688-

42212009000200013.

[7] R. S. Pressman, Ingeniería del Software. Un Enfoque Práctico. (7ª ED.), MCGRAW-

HILL.

[8] K. Schwaber y J. Sutherland, La Guía Definitiva de Scrum: Las Reglas del Juego,

2013.

[9] jmbeas, «Product backlog (o pila de producto),» [En línea]. Available:

https://jmbeas.es/guias/product-backlog/.

[10] Ministerio de Empleo y Seguridad Social, «BOE. Convenio colectivo estatal de

empresas de consultoría y estudios de mercado y de la opinión pública.,» Martes 6 de

marzo de 2018.

[11] I. Jacobson, El proceso unificado de desarrollo de software, Pearson Educación, 2000.

[12] «Tutorial de diagrama de máquina de estados | Lucidchart,» [En línea]. Available:

https://www.lucidchart.com/pages/es/diagrama-de-maquina-de-estados?a=0.

[13] «¿Qué es un diagrama de flujo de datos? | Lucidchart,» [En línea]. Available:

https://www.lucidchart.com/pages/es/que-es-un-diagrama-de-flujo-de-datos?a=0.



[14] R. Elmasri y B. N. Shamkant, de Fundamentos de Sistemas de Bases de Datos,

Pearson, 2007, p. 299.

[15] F. J. M. Santiago, «Tema 4: Diseño físico de la base de datos,» de Teoría de la

asignatura Gestión y Administración de Bases de Datos - UJA.

[16] J. Bruce, «What are the advantages of node.js? - Quora,» 29 Agosto 2017. [En línea].

Available: https://www.quora.com/What-are-the-advantages-of-node-js-1.

[17] S. Mohan, «AngularJS - What, Why, Advantages and Disadvantages,» 6 Julio 2016.

[En línea]. Available: https://www.weblineindia.com/blog/angularjs-what-why-

advantages-and-disadvantages/.

[18] B. Kataru, «Why do developers have to use Jade and EJS instead of HTML with

Express and Node?,» 18 Febrero 2018. [En línea]. Available:

https://www.quora.com/Why-do-developers-have-to-use-Jade-and-EJS-instead-of-

HTML-with-Express-and-Node.

[19] Expressjs, «Express - Node.js web application framework,» [En línea]. Available:

https://expressjs.com/.

[20] M. G. Vega, «Tema V - Ingeniería de la Interfaz. Escenarios: Storyboard,» de Teoría de

la asignatura Interacción Persona Ordenador - Universidad de Jaén.

[21] M. G. Vega, «Tema IX - Evaluación. Usabilidad,» de Teoría de la asignatura

Interacción Persona Ordenador - Universidad de Jaén.

[22] S. S. Statistics, «Pearson Correlation Coefficient Calculator,» [En línea]. Available:

https://www.socscistatistics.com/tests/pearson/Default2.aspx.



Anexo A

Manual de instalación

En este capítulo se detallará la guía de instalación de la plataforma web para la

evaluación de la comprensión lectora (módulos II y III) en modo local, distinguiendo la

instalación en los dos sistemas operativos que se han utilizado para su

implementación y despliegue: Windows y Ubuntu.

Por lo tanto, a través del siguiente manual, se describirán los pasos que el lector

deberá seguir para poder libremente poner en marcha la aplicación en su

computadora.

1. Instalación de node

a. Windows

i. Descargue e instale el ejecutable de Node (.msi o .exe) de

la página oficial: https://nodejs.org/es/ (preferiblemente la

versión LTS)

ii. Comprueba que node ha sido instalando entrando al

Símbolo del Sistema (Terminal) y escribiendo: node -v

b. Linux (Ubuntu)

i. Entre en la terminal, actualice el índice de paquetes local

(sudo apt-get update)

ii. Instale node introduciendo el siguiente comando: sudo apt-

get install nodejs

iii. Finalmente, instalamos el gestor de paquetes de node: sudo

apt-get install npm

2. Carga de la base de datos en MySQL

a. Tanto en Windows como en Linux, debe tener instalado MySQL

antes de proceder con la carga de nuestra base de datos. Mientras

que en Linux la carga de la base de datos se hace desde la propia

https://nodejs.org/es/



terminal cabe considerar que en Windows se ha hecho uso de

MySQLShell para dicha tarea.

b. Windows

i. Abra MySQLShell y escriba los siguientes comandos

seguido de intro (el último comando 4. no es indispensable

para el funcionamiento de la aplicación):

i. \sql: cambia a modo SQL

ii. \connect (su_usuario_bbdd)@localhost: para

establecer conexión.

iii. \source (rutaCarpeta_pirdb.sql)/pirdb.sql: carga el

script pirdb.sql en la base de datos.

iv. \use pirdb: accede al esquema de tablas de nuestra

base de datos por si, por ejemplo, se desean

consultar las tablas y sus tuplas de la base de datos.

c. Linux (Ubuntu)

i. Abra la terminal de Ubuntu y ejecute los siguientes

comandos:

i. mysql -u (su_usuario_bbdd) -p: para establecer

conexión.

ii. source (rutaCarpeta_pirdb.sql)/pirdb.sql: carga el

script pirdb.sql en la base de datos.

iii. use pirdb: se selecciona el esquema de tablas que

describirá nuestra plataforma

3. Instalación de dependencias de node

En la carpeta del proyecto instalaremos las siguientes dependencias

a través de los siguientes comandos en la terminal (sin sudo en

Windows):

sudo npm install express

sudo npm install http

sudo npm install path

sudo npm install jquery



sudo npm install fs

sudo npm install mysql

sudo npm install ejs

sudo npm install forever -g

sudo npm install url

sudo npm install nodemailer

sudo npm install consolidate

sudo npm install uniqid

sudo npm install http-auth

4. Ejecutar aplicación

a. Primero accederemos al archivo app.js (a través de cualquier

editor de texto), en la carpeta raíz del proyecto, y modificaremos

la contraseña y el usuario de la base de datos acorde al usuario

con el que ha cargado la base de datos en MySQL.

Ilustración 69. Establecer conexión Node y Base de Datos MySQL (fichero app.js)

b. Iniciamos la aplicación desde la terminal situándonos en la carpeta

raíz del proyecto. Podemos iniciarla con dos comandos:

i. node app (va mostrando en tiempo de ejecución el estado

de la aplicación en la terminal).

ii. forever start app.js asegura que la aplicación se ejecute

continuamente (ver logs para ver el estado ejecución de la

aplicación).

iii. Si al iniciar la aplicación a través de uno de los anteriores

comandos, le da un error inicial



ER_NOT_SUPPORTED_AUTH_MODE esto se debe a que

no usa mysql_native_password como modo de

autenticación por defecto, si es así proceda de la siguiente

manera:

i. Abra MySQLShell (Windows) o la terminal, y escriba

las siguientes órdenes seguidas de intro:

1. use mysql (Terminal – Ubuntu) o \use mysql

(MySQLShell - Windows)

2. ALTER USER 'nombre_usuario'@'localhost'

IDENTIFIED WITH mysql_native_password

BY 'password';

c. Cuando acceda a través de un navegador a

localhost:8080/fluidezlectora o localhost:8080/pir se le solicitarán

las siguientes credenciales:

• Nombre de usuario: participante

• Contraseña: lectuJa.2019

d. Si se desea detener la ejecución de la aplicación. Optamos

igualmente por los siguientes 3 comandos:

i. killall -9 node (Ubuntu)

ii. taskkill /F /IM node.exe (Windows)

iii. forever stop app.js (Windows y Ubuntu)



Anexo B

Índice de ilustraciones

Ilustración 1. Niveles de Puntuación en la prueba de Comprensión Lectora .......................10

Ilustración 2. Esquema general de un Sistema de Recuperación de Información ...............12

Ilustración 3. Esquema de un Sistema de Recuperación de Información Interactivo ..........13

Ilustración 4. Ejemplo de consulta en XML .........................................................................17

Ilustración 5. Ficha técnica de la batería III de Woodcock-Muñoz .......................................18

Ilustración 6. Patrones de proceso del método Scrum ........................................................23

Ilustración 7. Diagrama de Casos de Uso para el Test de Fluidez Lectora .........................32

Ilustración 8. Diagrama de Casos de Uso para el sistema PIR ...........................................35

Ilustración 9. Representación genérica de la arquitectura del sistema ................................43

Ilustración 10. Modelo Vista Controlador de nuestra plataforma .........................................44

Ilustración 11. Diagrama de máquina de estado del Test de Fluidez Lectora .....................46

Ilustración 12. Diagrama de máquina de estado de la plataforma PIR ................................47

Ilustración 13. Diagrama de Contexto (Flujo de Datos - Nivel 0) .........................................49

Ilustración 14. Diagrama de nivel superior (Flujo de datos – Nivel 1) ..................................49

Ilustración 15. Diagrama de Detalle o Expansión (Flujo de datos – Nivel 2) .......................50

Ilustración 16. Diagrama de Contexto (Flujo de Datos - Nivel 0) .........................................51

Ilustración 17. Diagrama de nivel superior (Flujo de datos – Nivel 1) ..................................51

Ilustración 18. Diagrama de Detalle o Expansión (Flujo de datos – Nivel 2) .......................52

Ilustración 19. Diagrama E/R ..............................................................................................53

Ilustración 20. Esquema lógico normalizado en 3FN ..........................................................56

Ilustración 21. Estructura de directorios del módulo I ..........................................................64

Ilustración 22. Estructura de directorios de módulos II y III .................................................66

Ilustración 23. Adquisición y preprocesamiento de documentos HTML Clueweb ................69

Ilustración 24. Captura del fichero qrels.txt (id_query, nombre_fichero, relevancia) ............69

Ilustración 25. Colección de documentos para la consulta Q001

(DOCranking_consulta_relevancia) ......................................................................................70

Ilustración 26. qrel.json – la clave key se corresponde con la clave primaria de QREL

puesto que contiene el par (id_consulta,id_documento) .......................................................71

Ilustración 27. Establecimiento de la conexión con el servidor ............................................73

Ilustración 28. Direccionamiento de la ruta ‘/fluidezlectora/entrenamientoTest’ ..................73

Ilustración 29. El título del test se muestra en inglés o español en función del lenguaje

indicado por la ruta ...............................................................................................................74

Ilustración 30. Descripción de la consulta cuando se selecciona y función del objeto $scope

que la almacena en una variable. .........................................................................................74

Ilustración 31. Función que elimina las consultas previamente lanzadas ............................78

Ilustración 32. Storyboard del Test de Fluidez Lectora .......................................................81

Ilustración 33. Storyboard del Sistema PIR .........................................................................82

Ilustración 34. Símbolo de la UJA .......................................................................................83

Ilustración 35. Libro con páginas abiertas – Módulo III .......................................................83

Ilustración 36. Lápiz escribiendo sobre un folio – Módulo III ...............................................84

Ilustración 37. Lupa observando un documento – Módulo III ..............................................84

Ilustración 38. Flecha que indica el retorno a algún lugar – Módulo III ................................84



Ilustración 39. Check de verificado – Modulo III ..................................................................85

Ilustración 40. Error si se pulsa en Iniciar Búsqueda de Información sin seleccionar ninguna

consulta previamente. ..........................................................................................................89

Ilustración 41. Página inicial del Test de Fluidez Lectora ....................................................91

Ilustración 42. Test de entrenamiento-prueba .....................................................................91

Ilustración 43. Captura de prueba oficial de Test de Fluidez Lectora en español ................92

Ilustración 44. Captura de prueba oficial de Test de Fluidez Lectora en inglés ...................92

Ilustración 45. Formulario datos personales .......................................................................93

Ilustración 46. Página inicial del sistema PIR ......................................................................93

Ilustración 47. Página donde se lanza la consulta ..............................................................94

Ilustración 48. Recuperación de documentos .....................................................................95

Ilustración 49. Resumen de lo aprendido ............................................................................96

Ilustración 50. Evaluación de documentos ..........................................................................96

Ilustración 51. Fin de sesión ...............................................................................................97

Ilustración 52. Número de respuestas dadas por participante ........................................... 102

Ilustración 53. Proporción de respuestas dadas por participante ...................................... 103

Ilustración 54. Proporción de evaluaciones emitidas por participante ............................... 105

Ilustración 55. Dispersión en las evaluaciones emitidas por participante .......................... 106

Ilustración 56. Número de evaluaciones emitidas por consulta ......................................... 108

Ilustración 57. Proporción de evaluaciones emitidas por consulta .................................... 109

Ilustración 58. Documentos evaluados correctamente en función de su complejidad ....... 111

Ilustración 59. Documentos evaluados incorrectamente en función de su complejidad .... 112

Ilustración 60. Captura resultado de la consulta 1 ............................................................ 117

Ilustración 61. Resultado de la consulta 2......................................................................... 118

Ilustración 62. Captura resultado de la consulta 3 ............................................................ 119





Ilustración 67. Resultado de las consultas 8.1 y 8.2 ......................................................... 121

Ilustración 68. Resultado de las consultas 9.1 y 9.2 ......................................................... 121

Ilustración 69. Establecer conexión Node y Base de Datos MySQL (fichero app.js) ......... 130



Anexo C

Índice de tablas

Tabla 1. Definición de requisitos para el módulo I ................................................................29

Tabla 2. Definición de requisitos no funcionales de módulos II y III ......................................29

Tabla 3. Definición de requisitos funcionales del módulo II: Test de Fluidez Lectora ...........30

Tabla 4. Roles asignados a los casos de uso para el módulo II ...........................................31

Tabla 5. Definición de requisitos funcionales del módulo III: Sistema PIR para la evaluación

de la comprensión lectora ....................................................................................................33

Tabla 6. Roles asignados a los casos de uso para el módulo III ..........................................34

Tabla 7. Funciones que desempeñan categorías profesionales del sector informático. .......37

Tabla 8. Tabla salarial a partir del 01-01-2019 (BOE) ..........................................................38

Tabla 9. Estimación de coste humano del proyecto .............................................................39

Tabla 10. Coste de Producción Total del Proyecto ...............................................................40

Tabla 11. Incrementos realizados durante el desarrollo del proyecto ...................................79

Tabla 12. Resultados del Test de Fluidez Lectora .............................................................. 101

Tabla 13. Valores estadísticos de las afirmaciones del test de fluidez lectora por participante

........................................................................................................................................... 103

Tabla 14. Resultados de las evaluaciones de documentos emitidas por participante ......... 105

Tabla 15. Valores estadísticos de las evaluaciones de documentos por participante ......... 106

Tabla 16. Resultados de las evaluaciones de documentos por consulta ............................ 108

Tabla 17. Valores estadísticos de las evaluaciones de documentos por consulta .............. 110

Tabla 18. Número de evaluaciones por participante en función de la complejidad de los

documentos ........................................................................................................................ 111

Tabla 19. Valores estadísticos del número de documentos evaluados correctamente según

grado de complejidad ......................................................................................................... 112

Tabla 20. Valores estadísticos del número de documentos evaluados incorrectamente en

función de su complejidad .................................................................................................. 112

Tabla 21. Peores participantes del test de fluidez lectora ................................................... 114

Tabla 22. Peores participantes PIR .................................................................................... 114

Tabla 23. Mejores participantes del test de fluidez lectora ................................................. 114

Tabla 24. Mejores participantes PIR .................................................................................. 114

Tabla 25. Coeficientes de Pearson para respuestas correctas e incorrectas ..................... 116