An´ alisis de la infraestructura del componente de evaluaci´ on de un MOOC Trabajo de fin de grado en Ingenier´ıa Inform´ atica

Enero del 2016

Autor/a: Mario Cavero Cahis Director/a: Llu´ıs Talavera M´endez, Antoni Soto i Riera Ponente: Marc Alier i Soler

ii Resumen Las TIC han favorecido la aparici´on, en los u ´ltimos a˜ nos, de cursos online con un gran n´ umero de participantes (MOOC) que responden a las necesidades de formaci´on de la sociedad actual. Esta masividad replantea la manera de presentar los materiales y c´omo evaluar a los estudiantes sin que estos denoten una falta de feedback en el proceso de aprendizaje, inexistente en los cursos presenciales. En este proyecto se presenta una plataforma de evaluaci´on de programas python basada en doctest y se utiliza para moldear un MOOC de programaci´on python instalado en una plataforma Moodle con permisos limitados, a trav´es de LTI. Se analiza el rendimiento de esta plataforma a trav´es de pruebas de carga y se proponen optimizaciones software para mejorarlo.

Resum Les TIC han afavorit, als ultims anys, l’aparici´o de cursos online amb un gran nombre de participants (MOOC) que responen a les necessitats de formaci´o de la societat actual. Aquesta massivitat replanteja la manera de presentar els materials i com avaluar als estudiants sense que aquests denotin una falta de feedback en el proc`es d’aprenentatge, inexistent als cursos presencials. En aquest projecte es presenta una plataforma d’avaluaci´o de programes python basada en doctest y s’utilitza per a modelar un MOOC de programaci´o python instal·lat a una plataforma Moodle amb permisos limitats, mitjan¸cant LTI. S’analitza el rendiment d’aquesta plataforma a trav´es de proves de c`arrega i es proposen optimitzacions software per a millorar-la-hi.

Abstract ICT has played an important role within the last years and it has brought new type of online courses that manage a huge number of students, the so-called MOOCs, that respond to the training needs’ of society. This massivity forces the educators to rethink the way they present materials and evaluate students, not to cause them a lack of feedback, compared to in-class courses. This project presents an assessment platform to evaluate python programs based on doctest, and uses it to complete a MOOC of python programming installed on a Moodle system with limited permissions, by using LTI. The performance of this system is proven by load testing it and some software modifications are proposed in order to improve this performance.

iii

´Indice general Lista de Tablas

v

Lista de Figuras

vii

1 Introducci´ on

1

1.1

Contexto

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2.1

Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2.2

Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2 Estado del Arte

4

2.1

¿Qu´e es un MOOC? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2

Plataformas MOOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.3

Evaluaci´ on de estudiantes en un MOOC . . . . . . . . . . . . . . . . . . . .

6

2.4

LTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.5

Selecci´ on de la herramienta de correcci´on . . . . . . . . . . . . . . . . . . .

8

3 Adecuaci´ on de las herramientas

11

3.1

Preparaci´ on del entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2

Adecuaci´ on VPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3

Modificaci´ on y extensi´on de doctest

4 Pruebas de carga 4.1

4.2

. . . . . . . . . . . . . . . . . . . . . . 12 15

Materiales y m´etodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.1

Material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1.2

Metodolog´ıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

An´ alisis de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.1

Primera fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.2

Segunda fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

iv 5 Instalaci´ on del sistema 5.1

27

Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Gesti´ on del proyecto 6.1

6.2

6.3

Metodolog´ıa y rigor

31 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.1

M´etodo de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.2

Partes implicadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.3

Seguimiento del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.4

Validaci´ on del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 32

Planificaci´ on temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.2.1

Descripci´ on de las tareas . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.2.2

Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.2.3

An´ alisis riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.2.4

Valoraci´ on de alternativas . . . . . . . . . . . . . . . . . . . . . . . . 35

Estimaci´ on de costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.3.1

Costes recursos humanos

. . . . . . . . . . . . . . . . . . . . . . . . 35

6.3.2

Costes recursos materiales . . . . . . . . . . . . . . . . . . . . . . . . 36

6.3.3

Costes imprevistos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.3.4

Coste total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.3.5

Control de gesti´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.4

Resultado planificaci´ on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.5

Sostenibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.6

6.5.1

Viabilidad econ´omica . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.5.2

Evaluaci´ on del impacto . . . . . . . . . . . . . . . . . . . . . . . . . 40

Leyes y regulaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7 Conclusi´ on

43

7.1

Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.2

Integraci´ on de los conocimientos . . . . . . . . . . . . . . . . . . . . . . . . 44

Bibliograf´ıa

45

A Manual de doctest mod

46

v

´Indice de cuadros 2.1

Listado de jueces y otros sistemas de evaluaci´on. . . . . . . . . . . . . . . .

4.1

Porcentajes de uso de memoria m´aximo y de uso de CPU medio de entre

9

todas las pruebas de 300 y 600 segundos con una relaci´on de 2 nuevos usuarios por segundo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1

Planificaci´ on de las tareas del proyecto . . . . . . . . . . . . . . . . . . . . . 32

6.2

Estimaci´ on salarial de los roles del proyecto. . . . . . . . . . . . . . . . . . . 35

6.3

Estimaci´ on desglosada del coste de los recursos humanos del proyecto. . . . 36

6.4

Estimaci´ on del coste de los recursos humanos del proyecto.

6.5

Estimaci´ on de los costes hardware del proyecto. . . . . . . . . . . . . . . . . 37

6.6

Material software utilizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.7

Estimaci´ on de los costes indirectos del proyecto. . . . . . . . . . . . . . . . . 38

6.8

Dedicaci´ on extra al proyecto fruto de desviaciones temporales.

6.9

Coste extra de los recursos humanos fruto de desviaciones temporales. . . . 38

. . . . . . . . . 36

. . . . . . . 38

6.10 Estimaci´ on de los costes totales del proyecto. . . . . . . . . . . . . . . . . . 39 6.11 Matriz de sostenibilidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

vi

´Indice de figuras 2.1

Ejemplo de ´ arbol de sintaxis y el c´odigo que representa. . . . . . . . . . . .

8

2.2

Esquema de funcionamiento de LTI. . . . . . . . . . . . . . . . . . . . . . .

8

3.1

Evaluaci´ on de un programa con doctest. . . . . . . . . . . . . . . . . . . . . 12

3.2

Nueva directiva de pesos en doctest mod. . . . . . . . . . . . . . . . . . . . 13

4.1

Esquema de paso de mensajes entre los diferentes componentes web. . . . . 16

4.2

Diagrama de peticiones generadas por n usuarios en una ventana de tiempo t. 18

4.3

Tiempos de respuesta medio por usuario y env´ıo para un n´ umero de usuarios y una configuraci´ on determinadas, durante una ventana de 60 segundos. . . 19

4.4

Tiempos de respuesta medio por usuario y env´ıo para un n´ umero de usuarios y una configuraci´ on determinadas, durante una ventana de 300 segundos. . 20

4.5

Tiempos de respuesta medio por usuario y env´ıo para un n´ umero de usuarios y una configuraci´ on determinadas, durante una ventana de 300 segundos. . 22

4.6

Porcentaje de uso de CPU, memoria y del espacio de intercambio (swap) de disco, durante una prueba con 600 usuarios en una ventana de 300 segundos, utilizando la optimizaci´on PHP3. . . . . . . . . . . . . . . . . . . . . . . . . 23

4.7

N´ umero de lecturas a disco por fallo en el InnoDB buffer durante una prueba de 300 segundos y 600 usuarios, con la configuraci´on SQL3 y SQL2. . . . . 23

4.8

N´ umero de Kilobytes le´ıdos a por el proceso mysql durante una prueba de 300 segundos con 600 usuarios y la configuraci´on SQL3. . . . . . . . . . . . 24

4.9

N´ umero de Kilobytes le´ıdos a por el proceso mysql durante una prueba de 300 segundos con 600 usuarios y la configuraci´on SQL2. . . . . . . . . . . . 24

4.10 Tiempos de respuesta medio por env´ıo y usuario para 1200 usuarios y la configuraci´ on predeterminada, durante 600 segundos. . . . . . . . . . . . . . 25 4.11 Tiempos de respuesta medio por env´ıo y usuario para 1200 usuarios y la configuraci´ on NGX2, durante 600 segundos. . . . . . . . . . . . . . . . . . . 26

vii 5.1

Esquema de sistema centralizado, con un solo nodo. . . . . . . . . . . . . . 28

5.2

Esquema de sistema distribu´ıdo, con varios nodos. . . . . . . . . . . . . . . 29

6.1

Diagrama de Gantt correspondiente a la planificaci´on del proyecto. . . . . . 33

1

Cap´ıtulo 1

Introducci´ on Las nuevas tecnolog´ıas han favorecido la creaci´on de nuevas aplicaciones y su puesta en marcha en distintos ´ ambitos de la sociedad: informarse a trav´es de peri´odicos digitales, realizar la compra a golpe de click o realizar una videollamada a la otra punta del mundo soy hoy en d´ıa tareas cotidianas para la mayor´ıa de habitantes en un pa´ıs avanzado. La educaci´ on tambi´en se ha adaptado a estos cambios. En las universidades resultar´ıa extra˜ no no disponer, hoy en d´ıa, de una plataforma que ayude a los alumnos a planificar el curso: horarios, avisos del profesor/a de una asignatura, material did´actico; en el mundo laboral, cada vez m´ as empresas dedicadas a la formaci´on de personal y servicios p´ ublicos a la formaci´ on de parados desarrollan su actividad de manera online. La mayor´ıa de estas actividades no sustituyen formas de ense˜ nanza tradicional, sin´ o que las complementan: los estudiantes y trabajadores deben seguir asistiendo a clases presenciales. En los u ´ltimos a˜ nos ha aparecido el t´ermino MOOC (Massive Online Open Course) para referirse a cursos dirigidos a un amplio n´ umero de usuarios (masivo) y cuyo u ´nico requisito para acceder es disponer de acceso a internet (online y abierto).

1.1

Contexto

Este trabajo se enmarca dentro de un proyecto de desarrollo de un MOOC de programaci´ on de python. El gran n´ umero de estudiantes en un MOOC hace dif´ıcil cualquier forma de evaluaci´ on manual de los estudiantes. Es por ello que el proyecto precisa una plataforma, basada en doctest, que permita evaluar autom´aticamente programas escritos en python. Esta plataforma, adem´ as, se debe poder invocar desde un Moodle con administraci´ on

2 limitada, a trav´es de LTI. En este proyecto se buscan las herramientas para poder crear esta plataforma y se modifica el m´ odulo doctest para mejorar la calidad de la evaluaci´on, minimizando as´ı la falta de feedback que causa la ausencia de un corrector humano hacia el estudiante. Se analiza esta plataforma y se le aplican modificaciones para mejorar el rendimiento; se estima la carga m´ axima de usuarios que puede soportar para un escenario determinado. Por u ´ltimo, se instala y se prepara el sistema para su puesta en marcha.

1.2

Alcance del proyecto

1.2.1

Requisitos

Este proyecto debe respetar los siguientes requisitos: • La plataforma de correcci´on debe admitir LTI para poder interactuar no s´olo con el propio curso en Moodle donde ser´a alojado, sin´o con cualquier otra plataforma que soporte LTI. • La plataforma de correcci´on debe ser capaz de evaluar programas escritos en el lenguaje de programaci´ on python a trav´es de la herramienta doctest. • Todo el software utilizado debe ser open source. Asimismo, todo el material u ´til que pueda ser utilizado en un futuro por terceros se publicar´a bajo una licencia de software libre.

1.2.2

Objetivos

Este proyecto tiene como objetivos principales: • Dise˜ nar e implementar una plataforma para llevar a cabo de forma autom´atica las tareas de evaluaci´ on y calificaci´on de los estudiantes de un MOOC de introducci´ on a la programaci´ on. M´ as concretamente: – Estudiar software disponible para la correcci´on autom´atica a trav´es de LTI y seleccionar el m´ as adecuado, o crearlo si fuera necesario. – Modificar el m´ odulo doctest para mejorar su uso como herramienta de evaluaci´ on. – Analizar el rendimiento de la plataforma de correcci´on y proponer mejoras a nivel de software; definir la infraestructura hardware necesaria para que la plataforma funcione correctamente.

3 – Instalar y preparar el sistema para su puesta en funcionamiento en un ambiente de producci´ on. – Documentar cualquier creaci´on o modificaci´on de software que se derive del proyecto.

4

Cap´ıtulo 2

Estado del Arte 2.1

¿Qu´ e es un MOOC?

MOOC ´es el acr´ onimo en ingl´es de Massive Online Open Course y como su propio nombre indica tiene las siguientes caracter´ısticas: • Es un curso: dispone de contenido dise˜ nado para el aprendizaje y pr´actica de una materia, impartido por unos profesores y limitado en el tiempo. • Es abierto y online: el u ´nico requisito para acceder es disponer de una conexi´ on a internet e inscribirse al curso, si bien es cierto que en algunos MOOC hay que pagar una cuota para obtener un certificado al finalizarlo. • Es masivo: participan un gran n´ umero de usuarios. El t´ermino MOOC fue acu˜ nado en 2008 por Dave Cormier y Bryan Alexander para referirse a un curso online creado por George Siemenes y Stephen Downes, llamado Connectivism and Connective Knowledge, que crearon con el objetivo de demostrar que era posible una ense˜ nanza basada en el conectivismo. Esto es, el conocimiento no est´a en un s´olo sitio sin´ o distribuido a trav´es de una red (internet). Siemens (2012b) A medida que los MOOC han ido evolucionando, han surgido dos tendencias en su desarrollo, diferenci´ andose entre los que enfatizan el aprendizaje conectivista y aquellos que se parecen un poco m´ as a cursos tradicionales. Siemens (2012a) propuso los t´erminos xMOOC y cMOOC para distinguirlos: • xMOOC: cursos tradicionales adaptados a una plataforma online, con una estructura y metodolog´ıa parecida a los cursos impartidos en las universidades: un profesor

5 experto en una materia selecciona el contenidos y construye las pruebas que posteriormente evaluar´ an a los alumnos. Es el tipo de MOOC m´as extendido hoy en d´ıa. • cMOOC: cursos con una estructura mucho m´as abierta donde el aprendizaje se basa en la participaci´ on; los alumnos de este tipo de cursos interact´ uan y debatne entre ellos para mejorar los materiales del curso. En este tipo de MOOCs se suele lograr una gran implicaci´ on por parte de sus alumnos. Generalmente no contemplan el uso de pruebas de evaluaci´ on.

2.2

Plataformas MOOC

Una plataforma MOOC es un sistema web que proporciona cursos y servicios a los estudiantes y herramientas a los dise˜ nadores de estos cursos para preparar los materiales incluidos. Estas plataformas deben estar preparadas para soportar cantidades masivas de inscripciones en el curso. Algunas funcionalidades de los MOOC incluyen: • Gestionar los usuarios del curso y definir los roles (estudiantes, profesores). • A˜ nadir recursos en diferentes formatos (documentos de texto, im´agenes, v´ıdeos). • A˜ nadir actividades: de evaluaci´on (tests, entregas de archivos) o de colaboraci´ on (foros, chats). • Planificar el curso: definir la duraci´on (fecha de inicio y fin) y la organizaci´on del curso (semanal o por temas). Hoy en d´ıa podemos encontrar MOOCs ofrecidos por instituciones acad´emicas e incluso empresas. Algunas de las m´ as utilizadas: • Stanford Online: promovido por la Standford University (USA), desde el 2006 ofrece varios MOOCs. Ofrece dos modalidades de curso: profesionales, cursos de pago que cuentan con la colaboraci´on de escuelas y departamentos de la universidad; y gratuitos, impartidos por un n´ umero reducido de docentes tambi´en vinculados a la instituci´ on. • Udacity y Coursera: organizaciones con ´animo de lucro que cuentan con m´as de 1.6 millones (2014) y 11.8 millones de usuarios registrados, respectivamente. Ofrecen cursos gratuitos y de pago.

6 • edX: creado por el MIT, tambi´en cuenta con la colaboraci´on de la Standford University. Ofrece cursos de varias universidades y organizaciones privadas, gratuitos y de pago. Aun siendo gratuitos, muchos proveedores de MOOC ofrecen un certificado al finalizar con ´exito el curso a cambio de pagar una cuota. En realidad las funcionalidades de las plataformas MOOC no difieren tanto de las que se han venido proporcionando tradicionalmente en los cursos en l´ınea a trav´es de los LMS. Desde el punto de vista de funcionalidades, la diferencia es muy difusa y, posiblemente, reside b´ asicamente en que las plataformas MOOC deben estar preparadas para atender n´ umeros de estudiantes muy superiores a los previstos en los cursos online. Esto explica que recientemente, independientemente de las plataformas surgidas espec´ıficamente para los MOOC, se haya potenciado el uso de LMS como proveedores de MOOC. Hay un gran n´ umero de LMS de c´odigo abierto (Moodle, Sakai, Canvas) y otros tantos privativos (CourseSites, Latitude). Otros ni siquiera se pueden utilizar (es el caso de las plataformas que utilizan Coursera o Udacity; herramientas propias, desarrolladas desde cero). Concretamente, en el marco de este proyecto el MOOC de referencia se desarrolla sobre la plataforma Moodle. Utilizada principalmente por universidades y escuelas, este entorno educativo virtual open source creado en 2002 cuenta con m´as de 75 millones de usuarios y numerosos m´ odulos creados por la comunidad. Moodle (2015)

2.3

Evaluaci´ on de estudiantes en un MOOC

Si evaluar las entregas de los alumnos ya es algo tedioso per se, lo es m´as aun cuando el n´ umero de estudiantes es muy grande. En un MOOC, resulta inviable que los profesores se dediquen a corregir manualmente las entregas. Conviene, por tanto, avanzar hacia formas de correcci´ on autom´ atica que minimicen la dedicaci´on del profesorado a esta tarea. Aparte de la propia correcci´on, no obstante, hay otros aspectos que forman parte del proceso de evaluaci´ on de un estudiante: distribuir el ejercicio a los alumnos, recoger las respuestas, detectar copias, asignar una nota y dar feedback. Una buena herramienta de evaluaci´ on autom´ atica tambi´en deber´a tener en cuenta cada uno de estos aspectos. Una alternativa bastante extendida entre algunos MOOC (especialmente los cMOOC) es la forma de evaluaci´ on entre pares (peer asessment), donde son los propios estudiantes del curso los que se eval´ uan entre ellos, utilizando unas r´ ubricas definidas por el instructor.

7 Algunos ejemplos de actividades que facilitan la correcci´on autom´atica: Debiasi L. (2013)

Actividades de selecci´ on Un ejemplo claro de actividad de selecci´on son los test: un conjunto de preguntas, cada una con varias opciones de respuesta y de las cu´ales s´olo una (o m´as de una) es correcta; de este grupo de respuestas, el estudiante selecciona aquellas que cree v´alidas. La correcci´ on autom´ atica de este tipo de ejercicios es trivial.

Actividades de texto Unas actividades m´ as complejas de evaluar ser´ıan aquellas donde el estudiante da una respuesta abierta, pues hay muchas formas de responder de forma correcta o incorrecta. La evaluaci´ on de una actividad de texto puede basarse en el contenido o en el estilo (o en ambas). Un ejemplo de herramienta de correcci´on basada en el contenido es el IEA (Intelligent Essay Assessor), basado en una t´ecnica utilizada para indexar documentos y extraer texto. PEG (Project Essay Grader) es otro ejemplo de herramienta de correcci´on de textos, esta vez basada en el estilo. PEG analiza, entre otros: la longitud del texto, cantidad de preposiciones, pronombres relativos... que hay en bloques de texto.

F´ ormulas matem´ aticos La dificultad de este tipo de actividades reside en que una f´ormula que lleve a un mismo resultado puede ser escrita de diferentes formas. Algunos ejemplos de herramientas de correcci´ on de f´ ormulas matem´aticas utilizan m´aquinas de vectores de soporte (SVM).

Programas inform´ aticos La forma m´ as com´ un de evaluar programas inform´aticos es ver si el comportamiento de los mismos es el esperado. Pueden utilizarse algunas m´etricas presentes en la mayor´ıa de lenguajes de programaci´ on y evaluar la calidad de un programa en funci´on del n´ umero de variables o de bucles. Otras formas de evaluaci´on m´as complejas incluyen la b´ usqueda de patrones o el an´ alisis del c´ odigo, previa transformaci´on a un ´arbol de sintaxis.

8

Figura 2.1: Ejemplo de ´arbol de sintaxis y el c´odigo que representa.

2.4

LTI

Learning Tools Interoperability (LTI) es un est´andar desarrollado por el IMS Global Consortium que tiene el objetivo de facilitar la integraci´on, en un LMS determinado, de aplicaciones educativas de terceros. Una aplicaci´on (LTI Provider) y un LMS (LTI Consumer) que sigan las especificaciones LTI pueden interactuar entre s´ı de numerosas maneras; el l´ımite lo marca el programador de la aplicaci´on.

Figura 2.2: Esquema de funcionamiento de LTI.

2.5

Selecci´ on de la herramienta de correcci´ on

Los jueces son entornos que permiten la correcci´on autom´atica de programas inform´aticos y que nacieron con el objetivo de entrenar a los participantes de competiciones de programaci´ on A. Mani and Roura (2014). El mecanismo de evaluaci´on de estos jueces se basa, principalmente, en comparar la salida generada por un programa con una entrada deter-

9 minada y la salida correcta (previamente definida). Si estas salidas difieren, el ejercicio se marca como incorrecto. Pueden existir algunas variaciones como considerar un programa correcto si no sobrepasa un tiempo de CPU fijado o comparar varias salidas con la ejecuci´on del mismo programa ante varias entradas. En cualquier caso, nos encontramos con unos resultados que poco ayudan al estudiante a detectar y corregir sus fallos de manera aut´onoma. Los jueces no se han creado para ense˜ nar un lenguaje de programaci´on sin´o permitir que alumnos ya iniciados o que est´an aprendiendo por otros medios practiquen. De hecho, los jueces acostumbran a ser plataformas ad-hoc, adaptadas a requisitos muy espec´ıficos y poco orientados al auto-aprendizaje. Mart (2013) muestra algunos ejemplos de jueces; es obligado mencionar la plataforma Jutge.org, desarrollada por Jordi Petit y Salvador Roura, utilizada en algunos concursos y asignaturas de programaci´ on de la FIB. Julio C. Caiza (2013) muestra algunos m´odulos open source que implementan la funcionalidad de los jueces y que pueden ser integrados en LMS. De esta manera se combinan las funcionalidades de ambos y se supera el problema anterior (cuadro 2.1). Las caracter´ısticas y requisitos del proyecto determinan: Primero Se dispone de acceso limitado al MOOC al que queremos dotar de la herramienta de correcci´ on de programas; esto obliga a utilizar una herramienta que soporte LTI. Segundo Esta herramienta debe soportar la correcci´on de programas escritos en el lenguaje de programaci´ on python. Tercero Esta herramienta debe estar basada en el m´odulo doctest; ser´a necesario, por tanto, seleccionar una herramienta que permita integrar este m´odulo. Cuarto La herramienta debe estar cubierta por una licencia de software libre. Cuadro 2.1: Listado de jueces y otros sistemas de evaluaci´on.

Herramienta

Licencia

C´odigo p´ ublico

CourseMarker Marmoset WebCat VPL Grading Tool Autograder Jutge

? apache 2.0 GNU GPL GNU GPL ? ? ?

no s´ı s´ı s´ı no s´ı no

Correcci´on programas python no si potencial s´ı s´ı s´ı1 s´ı

Soporte LTI no no no s´ı (Moodle) no s´ı no

Integraci´on m´odulo doctest no potencial potencial potencial potencial potencial potencial

10 A partir del an´ alisis anterior hemos seleccionado VPL (Virtual Programming Lab) porque satisface los requisitos anteriores. Esta herramienta, constantemente actualizada, es un plugin de Moodle que permite la gesti´ on de actividades de programaci´on y que soporta la correcci´on de programas python. Entre otros, permite crear entregas de ejercicios de programaci´on; corregir estas entregas autom´ aticamente (despu´es de que los estudiantes env´ıen los ficheros) y detectar copias entre los alumnos. Moodle por defecto ya permite a˜ nadir (invocar) actividades LTI-compliant a (desde) un curso. Esto quiere decir que para poder utilizar nuestros ejercicios de programaci´ on VPL desde el MOOC externo (en el que disponemos de permisos limitados) debemos conseguir que estas actividades VPL sean tambi´en LTI-compliant. Precisamente ser un plugin de Moodle hace que la plataforma VPL pueda ser LTIcompliant sin tener que extenderla utilizando la especificaci´on LTI gracias al m´odulo LTI Provider, un plugin de Moodle que convierte cualquier tipo de actividad o recurso en una aplicaci´ on LTI-compliant. Por tanto, una vez instalado junto al m´odulo VPL en un Moodle que controlamos al 100 %, el MOOC externo ya podr´a invocar nuestras actividades VPL. Notemos que el hecho de utilizar el est´andar LTI permite invocar una aplicaci´on determinada desde cualquier tipo de LMS, no s´olo Moodle.

1

Utiliza Skulpt, una implementaci´ on de python en javascript.

11

Cap´ıtulo 3

Adecuaci´ on de las herramientas 3.1

Preparaci´ on del entorno

La selecci´ on de VPL como herramienta de correcci´on nos lleva a utilizar Moodle. Necesitaremos, por tanto, un entorno web que nos permita alojar este LMS. Para ello optamos por el grupo de software LEMP que hace referencia a una instalaci´ on sobre un SO Linux con los paquetes nginx y PHP y MySQL como gestor de bases de datos, ambos open source. Despu´es de instalar y configurar m´ınimamente Moodle, el plugin VPL y el plugin LTI Provider ya tenemos un entorno web capaz de servir actividades de programaci´on VPL a trav´es de LTI.

3.2

Adecuaci´ on VPL

VPL consta de dos grandes partes: • El propio plugin de Moodle que u ´nicamente gestiona datos. No ejecuta ning´ un programa entregado en actividades VPL sin´o que se comunica con un servidor de ejecuci´ on para que lo haga por ´el. • Un servidor de ejecuci´ on encargado de compilar, ejecutar y devolver el resultado de los programas enviados por una actividad VPL. Esta separaci´ on responde a motivos de seguridad; para minimizar el efecto de cualquier intento de ataque se separa la parte que gestiona los datos con la parte encargada de ejecutar unos programas cuyo contenido es desconocido. Si hubiera alguna vulnerabilidad en el servidor de ejecuci´ on no se comprometer´ıa el entorno Moodle.

12 T´ecnicamente, VPL utiliza peque˜ nos scripts que dictan los pasos a seguir para corregir programas en cada uno de los lenguajes que soporta. Estos scripts se env´ıan, junto al c´odigo del programa, al servidor de ejecuci´on, donde se procesan. Para cumplir con los requisitos del proyecto, debemos modificar este comportamiento por defecto de VPL y utilizar el m´ odulo doctest para corregir los programas python. La flexibilidad de VPL permite definir nuestro propio script de correcci´on, para una actividad determinada. Si no se define ninguno, se utilizan los scripts por defecto. No ser´a necesario, por tanto, modificar la implementaci´on de VPL para integrar el m´ odulo doctest; si ser´ a necesario instalar este m´odulo en el servidor de ejecuci´on.

3.3

Modificaci´ on y extensi´ on de doctest

Doctest es un m´ odulo de python para realizar pruebas unitarias sobre programas escritos en el mismo lenguaje; este m´ odulo extrae el c´odigo interactivo definido dentro del mismo programa o en un archivo de texto, lo ejecuta y compara el output con el esperado, previamente definido. El hecho de trabajar con docstrings permite utilizar cualquier lenguaje de marcado (LaTeX, reStructuredText...), pudiendo acompa˜ nar los resultados con informaci´on u ´til y bien estructurada que aumente el feedback hacia el estudiante que ha entregado el programa. Figura 3.1: Evaluaci´on de un programa con doctest. # ejemplo_doctest.py def suma(a,b): """ >>> suma(0,0) 0 """ return a + b $ python -m doctest ejemplo_doctest.py -v Trying: suma(0,0) Expecting: 0 ok

El funcionamiento de VPL requiere que el mecanismo de correcci´on proponga una nota, que es la que se asignar´ a al alumno en esa actividad. Si nuestro mecanismo de correcci´ on es doctest, debemos adaptarlo primero para que sea capaz de generar esta nota.

13 En este caso, imitaremos el comportamiento por defecto de VPL; la nota vendr´ a determinada por el n´ umero de pruebas (tambi´en llamadas ejemplos) cuya ejecuci´on difiera o coincida con la salida definida como correcta en el doctest.

Corregir no es suficiente Hemos visto que un buen proceso de evaluaci´on consiste en dar el mayor feedback posible al estudiante, no s´ olo corregirle. Que el MOOC en el que se enmarca este proyecto est´e basado en el auto-aprendizaje obliga a adaptar nuestro mecanismo de correcci´on para que de la mayor retroalimentaci´ on posible. En ese sentido, se expanden las funcionalidades de doctest a˜ nadiendo dos nuevas directivas (flags): peso, que permite ponderar el peso de las pruebas dentro de un mismo doctest; bloque, que permite agrupar un conjunto de pruebas y determinar su peso dentro del doctest. La primera modificaci´ on no s´olo ayudar´a a los estudiantes a saber qu´e nota tiene sin´ oa los propios profesores del curso: podr´an decidir cu´anto cuenta cada ejemplo dentro de un doctest, aumentando la flexibilidad de la plataforma. El segundo cambio ayudar´a sobretodo a los alumnos a concentrarse y asimilar los errores de un grupo determinado de pruebas en lugar de distraerse con el resto de resultados del doctest. Este cambio va acompa˜ nado de peque˜ nos cambios en el formato de salida de los resultados de doctest; entre otros, se a˜ naden cabeceras al inicio de cada bloque y se muestra un cuadro al final con la nota del ejercicio, desglosada por bloques. Para acabar, esta nueva versi´on del m´odulo, llamada doctest mod, se instala en el servidor de ejecuci´ on de VPL. Figura 3.2: Nueva directiva de pesos en doctest mod. # ejemplo_doctest_mod.py def suma(a,b): """ >>> suma(0,0) # doctest_mod: +PES=0.75 0 >>> suma(-1,-1) # doctest_mod: +PES=0.25 -2 """ return a + b

14 Estrategia de dise˜ no El m´etodo testfile en el m´ odulo doctest original es la encargada de procesar los archivos doctest. Este m´etodo utiliza la clase DocTestParser para extraer las directivas de cada ejemplo del archivo doctest y DocTestRunner para ejecutar y verificarlos estos ejemplos. Una vez recorridas todas las pruebas, testfile devuelve informaci´on del n´ umero de pruebas totales y cu´ antas han fallado. Para implementar las funcionalidades de doctest mod, la estrategia utilizada ha sido: • Modificar la clase DocTestParser, que se encarga de buscar todas las directivas del fichero doctest, para que reconozca los nuevos flags peso y bloque. • Modificar la clase DocTestRunner, para que anote la relaci´on de ejemplos que han fallado. • Crear un nuevo m´etodo obtePesosDoctest que recorre todas las pruebas de un doctest, extrae el valor de las directivas a˜ nadidas y genera una estructura que contiene, entre otros, informaci´ on sobre el bloque (peso, n´ umero de ejemplos) y los pesos de los ejemplos que contiene. • Crear un nuevo m´etodo calculaNotaFinal que, dado el resultado de la ejecuci´ on de un doctest (clase DocTestParser ) y una relaci´on de los ejemplos con sus respectivos pesos, calcula una nota. • Modificar el m´etodo testfile para que utilice obtePesosDoctest, ejecute los ejemplos del doctest a trav´es de la clase modificada DocTestRunner, ejecute la funci´ on calculaNotaFinal y devuelva el n´ umero de pruebas totales, falladas y la nota correspondiente.

15

Cap´ıtulo 4

Pruebas de carga

4.1

4.1.1

Materiales y m´ etodos

Material

Las pruebas se realizan sobre una m´aquina virtual. La configuraci´on de este equipo son 2 CPU cores @ 3.00 Ghz, 1024 MB de memoria RAM, 10 GB de disco y un enlace de 100 Mbps.

El SO utilizado durante las pruebas es Debian Jessie, el servidor web Nginx 1.6, PHP 5.6 y el sistema de gesti´ on de bases de datos MariaDB 14.14. La versi´on de Moodle es la 2.9.

La figura 4.1 muestra, a grandes rasgos, c´omo interaccionan entre s´ı los componentes web que alojan nuestra plataforma Moodle.

16 Figura 4.1: Esquema de paso de mensajes entre los diferentes componentes web.

Disponemos de un servidor web escuchando sobre el puerto 80 (HTTP). Cuando llega una nueva conexi´ on, un proceso (worker) de nginx responde con el contenido del archivo solicitado. Cuando la petici´ on es una p´agina din´amica (archivo PHP), nginx solicita a PHPFPM (PHP FastCGI Process Manager) realizar los c´alculos necesarios antes de responder al cliente. PHP-FPM mantiene activos un conjunto (pool) de procesos encargados de procesar estas peticiones PHP, interaccionando si cabe con la base de datos y finalmente respondiendo al worker nginx solicitante. Se utiliza Apache JMeter como generador de pruebas de carga; iotop y dstat como herramientas de monitorizaje de recursos. Lanzar las pruebas y recoger manualmente los resultados cuando estas hayan terminado tiene sus riesgos y problemas: • Por una parte, el factor humano puede llevar a errores y a no respetar la misma metodolog´ıa para cada una de las pruebas. Por ejemplo, lanzar una prueba antes que los componentes encargados de recabar los datos (m´etricas) que despu´es analizaremos no est´en listos. • Por otro lado, dada la cantidad de experimentos a realizar, el tiempo que se dedicar´ıa a esta fase del proyecto resultar´ıa inasumible y no se garantizar´ıa cumplir los plazos del proyecto. Para evitar estos problemas, se decide crear una herramienta que automatize el proceso

17 de lanzamiento de pruebas de carga. Esta herramienta, escrita en python y con el apoyo de la librer´ıa Fabric, permite aplicar configuraciones sobre una m´aquina, sincronizar el inicio de las pruebas de carga con el monitoraje de recursos en esta y, en acabar, obtener los resultados, etiquetarlos y almacenarlos.

El formato de los resultados que devuelven las herramientas de monitorizaje no son interpretables por un humano y deben procesarse para poder ser analizados. Este proceso se repetir´ a para cada una de las pruebas. Para no repetirse durante esta fase de an´ alisis de los resultados se crea un entorno web, basado en el framework de python Pyramid, que permite acceder a los resultados, debidamente presentados en formato utilizando la librer´ıa Matplotlib, para su posterior an´alisis.

4.1.2

Metodolog´ıa

Nuestra plataforma Moodle act´ ua de contenedor de ejercicios del MOOC de programaci´ on python. Por tanto, la u ´nica parte en la que analizaremos el rendimiento ser´an las actividades VPL. M´ as concretamente, nos interesa saber cu´antos usuarios accediendo e interactuando con este tipo de actividades puede soportar la plataforma dando unos tiempos de respuesta aceptables.

El mayor impacto en rendimiento sobre una aplicaci´on VPL se produce cuando se realiza el env´ıo de ficheros. Por ello, el plan de pruebas consiste en un n´ umero determinado de usuarios (n) que durante un tiempo determinado (ventana de tiempo, t) acceden a una misma actividad VPL y realizan el env´ıo de 3 ficheros python, generados pseudoaleatoriamente. Estos usuarios se lanzan uniformemente en el tiempo (figura 4.2) y no repiten el ciclo de peticiones cuando acaban. Si durante una prueba de carga hay una o m´ as peticiones que no se satisfacen, la prueba se interrumpte y queda marcada como fallida.

18 Figura 4.2: Diagrama de peticiones generadas por n usuarios en una ventana de tiempo t.

Las pruebas se realizan en ventanas de tiempo de 1, 5 y 10 minutos. Para cada ventana de tiempo se realizan 10 pruebas. En cada prueba se aumenta progresivamente el n´ umero de usuarios, tal y como determina la f´ormula de la figura 4.1. Notemos que la relaci´ on de usuarios lanzados por unidad de tiempo en la prueba i-´esima se mantiene independientemente de la ventana de tiempo. Consideraremos un tiempo de respuesta aceptable si es menor de 2 segundos, tal y como sugiere Fiona Fui-Hoon (2004). Aplic´andolo a este escenario, ser´an consideradas aceptables aquellas pruebas que consigan un tiempo de respuesta medio por usuario y env´ıo de 2 segundos.

usuariosi (t) =

t·i 2

(1 ≤ i ≤ 10)

(4.1)

Mediante estas pruebas de carga se prueban diferentes combinaciones de configuraciones de los paquetes de software involucrados en la plataforma Moodle y por tanto los que m´ as condicionan el rendimiento de la plataforma: nginx, encargado de gestionar las conexiones de los clientes; PHP, encargado de procesas las p´aginas o scripts de Moodle y MySQL, la base de datos del sistema.

4.2 4.2.1

An´ alisis de resultados Primera fase

Necesitamos obtener un baseline para determinar si optimizacines futuras en la configuraci´ on de los paquetes resultar´a en una mejora de rendimiento. En esta primera fase, realizamos pruebas de carga aplicando optimizaciones gen´ericas sobre nginx, PHP y MySQL.

19 La configuraci´ on por defecto (PRED) y estas optimizaciones consisten en: • PRED: Configuraci´ on predeterminada de Nginx, PHP y MySQL. • NGX2: permite que un proceso de nginx acepte m´ ultiples conexiones en un instante determinado (por defecto, s´olo acepta una conexi´on a la vez). • PHP2: limita a 40M la memoria que puede utilizar un proceso PHP (128M por defecto). • SQL2: habilita la query cache con una capacidad de 36M y un tama˜ no m´ınimo de bloque de 2K bytes. Cambia el tama˜ no del InnoDB buffer a 115M (128M por defecto). La figura 4.3 muestra el tiempo de respuesta medio por usuario y env´ıo en todas las pruebas realizadas en una ventana temporal de 60 segundos.

Figura 4.3: Tiempos de respuesta medio por usuario y env´ıo para un n´ umero de usuarios y una configuraci´ on determinadas, durante una ventana de 60 segundos. En vista de esta figura, podemos considerar que el tiempo de respuesta medio por env´ıo y usuario se mantiene estable hasta los 120 usuarios (o 2 nuevos usuarios por segundo). A partir de entonces, los tiempos crecen desmesuradamente (150 o 2.5 nuevos usuarios por segundo). Notar que las pruebas fallidas no se muestran en el gr´afico. Aunque no se cuantifica en el proyecto, existe una alta variabilidad al realizar las pruebas en esta ventana de tiempo (1 minuto). A medida que se dispone de una ventana m´ as

20 extensa (5 y 10 minutos), las inestabilidades que puedan darse durante una prueba no tienen capacidad de doblegar la tendencia generalizada y por ende de alterar significativamente los resultados. Esto nos obliga a realizar las mismas pruebas en la ventana de tiempo de 5 minutos (figura 4.4).

Figura 4.4: Tiempos de respuesta medio por usuario y env´ıo para un n´ umero de usuarios y una configuraci´ on determinadas, durante una ventana de 300 segundos. En esta ventana, el tiempo de respuesta medio por usuario y env´ıo se mantiene estable hasta los 600 usuarios (2 nuevos usuarios por segundo). A partir de entonces e igual que en la ventana anterior (2.5 nuevos usuarios por segundo) los tiempos vuelven a crecer. A continuaci´ on nos centramos en las pruebas realizadas durante la ventana de 5 minutos. En concreto, lo haremos en las pruebas con 600 y 750 usuarios. Todas las pruebas se completan con ´exito con 600 usuarios; PHP2 y PRED son las u ´nicas pruebas que, con 750 usuarios, fallan (recordemos que consideramos una prueba fallida cuando el servidor no ha sido capaz de satisfacer todas las peticiones). En ambos casos, el motivo es que el socket por donde se encaminan las peticiones PHP desde nginx se llena, o lo que es lo mismo, el m´odulo PHP-FPM es incapaz de atender las peticiones al mismo ritmo que se generan. Observando m´ as atentamente las pruebas de la figura 4.4 con 750 usuarios: • El tiempo de respuesta medio por env´ıo y usuario de la combinaci´on NGX2 y NGX2+PHP2 es muy similar. Combinado con NGX2 parece que PHP2 no es, a

21 priori, una buena opci´ on. • El tiempo de la configuraci´on SQL2 es mucho menor que la combinaci´on NGX2+SQL2, siendo esta la que peores tiempos da entre todas las pruebas realizadas con 750 usuarios. Observemos tambi´en que la combinaci´on NGX2+PHP2 da peores resultados que NGX2+PHP2+SQL2.

4.2.2

Segunda fase

Una vez obtenido un baseline, empezamos a analizar m´as al detalle el comportamiento en las pruebas de la primera fase. Cuando la m´ aquina empieza a agotar los recursos (pruebas con una relaci´on de 2 nuevos usuarios por segundo) el porcentaje de uso de tiempo de CPU medio en todo el sistema no supera el 90 %. En cuanto a la memoria, en ning´ un caso utiliza m´as del 50 % del total disponible (figura 4.1). Cuadro 4.1: Porcentajes de uso de memoria m´aximo y de uso de CPU medio de entre todas las pruebas de 300 y 600 segundos con una relaci´on de 2 nuevos usuarios por segundo.

PRED NGX2 SQL2 PHP2 NGX2+PHP2 NGX2+SQL2 NGX2+PHP2+SQL2

% uso memoria 44.4 43.3 42.9 43.6 43.0 46.5 44.0

% uso CPU (media) 86.9 86.6 89.3 86.0 87.7 87.2 87.0

Para ver hasta qu´e punto puede aprovecharse ese margen de recursos sobrante (sobretodo en memoria), se proponen las optimizaciones PHP3 y SQL3.

• PHP3: mismos cambios que en PHP2. Adem´as, aumenta la disponibilidad de procesos PHP-FPM preparados para atender una petici´on. Se garantizan: – 10 procesos preparados, como m´ınimo; 20 como m´aximo. – 40 procesos como m´aximo en total (sirviendo peticiones y preparados para hacerlo). • SQL3: mismos cambios que en SQL2, pero con un InnoDB buffer de 230M de capacidad (se dobla).

22

Figura 4.5: Tiempos de respuesta medio por usuario y env´ıo para un n´ umero de usuarios y una configuraci´ on determinadas, durante una ventana de 300 segundos.

La figura 4.5 muestra el tiempo de respuesta medio por usuario y env´ıo en todas las pruebas realizadas en una ventana temporal de 300 segundos, despu´es de a˜ nadir las nuevas configuraciones. Observamos que, para 750 usuarios, las configuraciones PHP3 y las combinaciones PHP3+SQL2 y PHP3+SQL3 se sit´ uan en torno a los 2 segundos, siendo las que mejor resultados dan hasta ahora (las combinaciones son levemente mejores).

Sobre la configuraci´ on PHP3, podemos afirmar que aumentar el n´ umero de procesos esperando a servir peticiones PHP ha servido para aumentar notablemente el uso de memoria y exprimir al m´ aximo los procesadores (figura 4.6), consiguiendo unos tiempos de respuesta medios por env´ıo y usuario r´ecord, ya observados en la figura 4.5.

23

Figura 4.6: Porcentaje de uso de CPU, memoria y del espacio de intercambio (swap) de disco, durante una prueba con 600 usuarios en una ventana de 300 segundos, utilizando la optimizaci´ on PHP3.

Sobre SQL3, podemos afirmar que el aumento del InnoDB buffer ha servido para reducir las lecturas en disco (menos fallos de InnoDB buffer). En la figura figura 4.7 puede observarse un decremento en el n´ umero de accesos a disco determinados por un fallo al intentar acceder a un bloque en el InnoDB buffer.

Figura 4.7: N´ umero de lecturas a disco por fallo en el InnoDB buffer durante una prueba de 300 segundos y 600 usuarios, con la configuraci´on SQL3 y SQL2.

Esto se traduce en un descenso notable en la cantidad de datos le´ıdos de disco (figuras 4.9 y 4.8).

24

Figura 4.8: N´ umero de Kilobytes le´ıdos a por el proceso mysql durante una prueba de 300 segundos con 600 usuarios y la configuraci´on SQL3.

Figura 4.9: N´ umero de Kilobytes le´ıdos a por el proceso mysql durante una prueba de 300 segundos con 600 usuarios y la configuraci´on SQL2.

Aun con estos buenos resultados a priori y volviendo a la 4.5 SQL2 obtiene un tiempo de respuesta medio algo mejor que SQL3. Esto puede verse no s´olo comparando el tiempo entre s´ı sin´ o tambi´en comparando sus respectivas combinaciones con NGX2 y NGX2+PHP2. Sumado a esto y despu´es de realizar la combinaci´on PHP3+SQL3 y ver que los tiempos respecto PHP3+SQL2 son casi id´enticos (las marcas en el gr´afico se superponen), no podemos llegar a ninguna conclusi´on sobre cu´al de las dos configuraciones es mejor. Por u ´ltimo nos centraremos en la configuraci´on NGX2 (figura 4.5). • Observemos que NGX2+PHP3 obtiene mejores resultados que NGX2+PHP2. Esto da a pensar que hay un salto cualitativo importante entre la configuraci´on PHP3 y PHP2.

25 • La combinaci´ on NGX2+PHP2+SQL2 se ajusta a los niveles de respuesta de NGX2+PHP3.

Analizado todo lo anterior (inclu´ıdos los resultados la primera fase), m´as que una mejora de rendimiento lo que hace la configuraci´on NGX2 es convertir el componente nginx en un lastre. El hecho de que un worker de nginx atienda a m´as de un cliente a la vez no est´ a dando buenos resultados en nuestro escenario. Al recibir un flujo constante de clientes en el tiempo los procesos nginx pueden saturarse con un n´ umero de peticiones que no pueden servir al mismo ritmo que llegan. Si el tiempo de resoluci´on de las peticiones PHP (de las que se encarga PHP-FPM) fuera menor, estos procesos de nginx tendr´ıan la capacidad de soportar este flujo y por tanto los tiempos de respuesta mejorar´ıan. El problema tambi´en se resolver´ıa si el flujo fuera menor; observemos este caso en las figuras 4.10 y 4.11. La primera usa la configuraci´on PRED, mientras que la segunda aplica la optimizaci´ on NGX2. Las pruebas se dan en la misma ventana de tiempo y el mismo n´ umero de usuarios. La variabilidad en los tiempos de respuesta disminuye notablemente (sd = 2.7 a 1.49). Notemos tambi´en que el tiempo de respuesta disminuye.

Figura 4.10: Tiempos de respuesta medio por env´ıo y usuario para 1200 usuarios y la configuraci´ on predeterminada, durante 600 segundos.

26

Figura 4.11: Tiempos de respuesta medio por env´ıo y usuario para 1200 usuarios y la configuraci´ on NGX2, durante 600 segundos.

27

Cap´ıtulo 5

Instalaci´ on del sistema

Creamos una m´ aquina virtual con las mismas caracter´ısticas y la misma versi´on de software utilizado durante el desarrollo del sistema y posteriores pruebas de carga.

Necesitamos una direcci´ on IP fija asignada a la m´aquina, que resuelva a un nombre de dominio a trav´es del servidor DNS autoritativo correspondiente. Supongamos asignada una direcci´ on IP 147.83.92.13 y el nombre ’taronger.cs.upc.edu’ asignado a ´esta.

Seguidamente configuramos los paquetes de software Nginx, PHP, MariaDB/MySQL y realizamos la instalaci´ on de Moodle. Instalamos y configuramos el plugin VPL, el plugin LTI Provider y preparamos el servidor de ejecuci´on y correcci´on de los programas (que forma parte del paquete VPL).

La figura 5.1 muestra una aproximaci´on del esquema de la red y la distribuci´on de los equipos.

28

Figura 5.1: Esquema de sistema centralizado, con un solo nodo.

Las pruebas de carga se generaron en una m´aquina que formaba parte de la misma red que la m´ aquina donde estaba Moodle. No olvidemos que en el MOOC que planteamos acceder´ an usuarios de Internet y por tanto el tiempo real medio de respuesta por env´ıo se ver´a incrementado por esta latencia.

En caso de ser necesario absorber una mayor carga de usuarios podr´ıa optarse por aumentar el n´ umero de m´ aquinas virtuales con las mismas caracter´ısticas. Una topolog´ıa v´alida para conseguirlo se muestra en la figura 5.2.

29

Figura 5.2: Esquema de sistema distribu´ıdo, con varios nodos.

Esta configuraci´ on contar´ıa con un reverse HTTP proxy que se encargar´ıa de interactuar con los clientes y atender sus peticiones. Estas peticiones las encaminar´ıa por una de las n m´ aquinas virtuales, que son las que realmente atender´ıan la petici´on, har´ıan los c´alculos necesarios y responder´ıan al proxy, que trasladar´ıa la respuesta al cliente. Notemos que ahora la instalaci´on de Moodle est´a distribuida; estas n m´aquinas deben ser capaces de atender las consultas que anteriormente (figura 5.1) atend´ıa el u ´nico nodo virtual; este nodo ten´ıa la base de datos y utilizaba su propio sistema de ficheros para dar cabida a los archivos que maneja Moodle (por defecto, directorio moodledata). Por tanto ser´ a necesario disponer de un sistema de bases de datos y un sistema de ficheros compartido por todas las n m´ aquinas, que garantice que todos los nodos dispongan de los datos que sus semejantes hayan realizado con anterioridad. Tambi´en es necesario compartir las sesiones de los usuarios entre los diferentes nodos; si las peticiones de un cliente las encamina el proxy a un nodo A y m´as tarde a un nodo B, ´este u ´ltimo debe poder recuperar el estado de la sesi´on tal y como la dej´o A. Esto puede conseguirse de varias formas:

• Trasladando la gesti´ on de sesiones de Moodle a la base de datos. • Almacen´ andolas en un directorio compartido (sistema de ficheros compartido).

30 • Utilizando una instancia de memcached. Notar que dificilmente esta topolog´ıa multiplicar´ıa el rendimiento de la primera por las n m´ aquinas virtuales.

5.1

Seguridad

Seguridad A continuaci´ on se analizan elementos externos que pueden afectar la disponibilidad del servicio y c´ omo podr´ıan resolverse, as´ı como algunas consideraciones de seguridad. • Red el´ectrica: el sistema se conecta a tomas de corriente de un SAI (sistema alimentaci´ on ininterrumpida). Este sistema corrige todas las deficiencias de la red el´ectrica. Ante bajadas o subidas de tensi´on o cortes de corriente el sistema se mantendr´ıa funcionando, en el u ´ltimo caso durante un tiempo determinado. • Fallo en el nodo: notemos que la figura 5.1 procesa todas las peticiones a trav´es de un s´ olo nodo. Si en este nodo se produce un fallo hardware, el servicio quedar´ a interrumpido. Esto podr´ıa solventarse a gracias a la figura del proxy (ver figura 5.2): ante un nodo que no respondiera a una petici´on, ´esta podr´ıa enviarse a cualquiera de los n-1 nodos restantes. • Control de accesos: por defecto, el servidor de ejecuci´on VPL acepta peticiones de cualquier m´ aquina. Es deseable (y configurable) limitarlo para que s´olo atienda a los nodos de nuestro sistema. De la misma manera, en el segundo escenario, los nodos virtuales deber´ıan aceptar peticiones HTTP(S) u ´nicamente del proxy.

31

Cap´ıtulo 6

Gesti´ on del proyecto 6.1

Metodolog´ıa y rigor

6.1.1

M´ etodo de trabajo

La forma de trabajar se basa en la metodolog´ıa Scrum; cada semana se definen una serie de objetivos que deben estar listos para la siguiente. Dependiendo si los objetivos se han cumplido o no, se definen nuevos.

6.1.2

Partes implicadas

En este proyecto participan directamente los siguientes actores: • Autor: encargado de resolver el problema formulado en el proyecto, alcanzando los objetivos y respetando los requisitos de ´este. • Directores: encargados de monitorizar el proyecto y asesorar al autor en todo aquello relativo a las competencias t´ecnicas. • Estudiantes: futuros alumnos del MOOC de programaci´on planteado en el proyecto.

6.1.3

Seguimiento del proyecto

Se realizan reuniones semanales con los directores del proyecto, donde se plantean problemas, se repasan los avances y se definen los siguientes pasos a seguir. Los directores pueden consultar el estado del proyecto en cualquier momento a trav´es de un repositorio git al que tienen acceso y donde el autor introduce todos los cambios que va efectuando.

32

6.1.4

Validaci´ on del proyecto

Se considera que el proyecto es v´alido si lo es el objetivo de ´este, dividido en tres partes. Los directores son los encargados de determinar si se cumplen o no cada una de estas partes: • En el caso de los dos primeros sub-objetivos, se muestra un MOOC, de prueba pero funcional, que cumple los requisitos del proyecto. • En el caso del tercer objetivo, se define un escenario sobre el cual realizar pruebas de rendimiento; se muestran las mejoras y qu´e cambios software se han adoptado para conseguirlo. • En el u ´ltimo objetivo, se instala y se deja preparado el sistema en el escenario anterior.

6.2

Planificaci´ on temporal

Es necesario definir qu´e tareas van a realizarse durante el proyecto, estimar su duraci´ on y ubicarlas en el tiempo (cuadro 6.1). Esta planificaci´on permite tener m´as margen de maniobra frente a posibles imprevistos. En las reuniones semanales con los directores, que no se incluyen en el listado de tareas, se controla que los plazos acordados se cumplen. Cuadro 6.1: Planificaci´on de las tareas del proyecto ID 1 2 3 4 5 6

Tarea B´ usqueda de herramientas existentes Prueba y selecci´ on de herramientas existentes Adecuaci´ on de herramientas seleccionadas Pruebas de carga y optimizaci´ on Prueba piloto Documentaci´ on Total

Duraci´on (horas)

Inicio

Final

Precedida por

30

07/09/2015

11/09/2015

60

14/09/2015

25/09/2015

1

90

28/09/2015

16/10/2015

2

150

19/10/2015

20/11/2015

3

66 72

23/11/2015 08/12/2015 313 horas

07/12/2015 23/12/2015 107 horas

4 5

El proyecto se inicia el 7 de septiembre del 2015 y est´a previsto que finalice el 23 de diciembre de 2015. La duraci´ on estimada es de 468 horas de trabajo (repartidas en 3 meses y 16 d´ıas).

33

6.2.1

Descripci´ on de las tareas

Sigue una breve descripci´ on de las diferentes tareas del proyecto: • B´ usqueda de herramientas existentes: buscar herramientas que puedan servir para realizar un curso online de introducci´on a la programaci´on: recopilar MOOCs, LMS y sistemas de evaluaci´ on ya creados. • Prueba y selecci´ on de herramientas existentes: probar las herramientas encontradas y analizarlas; seleccionar aquellas que mejor se ajusten a los requisitos del proyecto. • Adecuaci´ on de herramientas seleccionadas: agrupar e interconectar las herramientas de forma que resuelvan uno de los objetivos principales de este proyecto: disponer de una plataforma que permita crear un MOOC de introducci´on a la programaci´ on; modificar estas herramientas, si cabe. • Pruebas de carga y optimizaci´on: crear un entorno espec´ıfico, de pruebas, a partir de herramientas propias y/o ya existentes, que permita analizar el rendimiento de esta plataforma. Adoptar cambios que mejoren su rendimiento. • Prueba piloto: crear un entorno de producci´on donde poder instalar la plataforma; utilizarla con usuarios reales y confirmar su correcto funcionamiento. • Documentaci´ on: escribir la memoria del proyecto, as´ı como gu´ıas y manuales destinados a las partes interesadas de ´este. Todas las fases, excepto la primera, tienen como dependencia de precedencia su fase inmediatamente anterior. La figura 6.1 muestra las tareas mencionadas anteriormente en un diagrama de Gantt.

Figura 6.1: Diagrama de Gantt correspondiente a la planificaci´on del proyecto.

6.2.2

Recursos

Se necesitan los siguientes recursos para el proyecto:

34 • Recursos materiales: – Hardware: ∗ Servidores web: m´aquinas f´ısicas sobre la que funcionar´a el MOOC. ∗ Ordenador: para desarrollar el proyecto. – Software ∗ Sistemas operativos: sistema base sobre el que funcionan todas las aplicaciones involucradas en el proyecto. ∗ Sistema de control de versiones: programa que organiza todo el material del proyecto. ∗ Generadores de carga: software que realiza pruebas de rendimiento. ∗ Otros: frameworks para agilizar el desarrollo, herramientas para recopilar datos durante las pruebas de carga. – Consumo: (luz y) electricidad. • Recursos humanos: una persona que pueda dedicar al proyecto entre 30 y 35 horas semanales.

6.2.3

An´ alisis riesgos

Los principales escollos que pueden aparecer durante el desarrollo del proyecto y que podr´ıan producir desviaciones temporales en la planificaci´on del proyecto son: • La limitada experiencia del autor en cuanto a pruebas de carga: saber interpretar los resultados correctamente es esencial para no dar palos de ciego en el proyecto. Sumado a esto, debido al gran n´ umero de pruebas de carga a las que puede someterse un MOOC, es vital descartar aquellas que no reproduzcan el comportamiento real de los usuarios de un curso de programaci´on online. Esto podr´ıa retrasar la fase 4 (Pruebas de carga y optimizaci´on). Dado que la propia metodolog´ıa de trabajo del proyecto ya controla este tipo de desviaciones, la etapa podr´ıa demorarse no m´ as de 2 jornadas laborales. • Una dedicaci´ on no-exclusiva: el autor compagina el desarrollo del proyecto con la asistencia a un curso universitario; las entregas y/o ex´amenes de este curso puede causar retrasos en la planificaci´on del proyecto.

35 Esto puede hacer que algunas etapas se retrasen durante periodos de ex´amenes y/o entregas. La planificaci´ on temporal inicial ya lo contempla y no es necesario prever ninguna dilaci´ on. • Resoluci´ on de errores: como todo proyecto, no es de extra˜ nar que aparezcan problemas que puedan alargar su duraci´on, especialmente durante la implementaci´ on o instalaci´ on del MOOC. Ante la posibilidad que aparezcan problemas puntuales durante la implementaci´ on o instalaci´ on del MOOC (etapas 3 y 5), se estima que ambas fases podr´ıan demorarse 2 y 3 jornadas laborables, respectivamente.

6.2.4

Valoraci´ on de alternativas

Estas posibles desviaciones temporales suponen una duraci´on m´axima del proyecto de 510 horas, 42 m´ as que las planificadas. Este n´ umero de horas extras (considerando el peor de los casos) podr´ıan dedicarse durante los numerosos fines de semana ubicados entre la fecha de inicio y final del proyecto. Es por ello que se garantiza la finalizaci´on del proyecto en el tiempo planificado inicialmente. En caso de producirse, estas desviaciones de 42 horas supondr´ıa, u ´nicamente, un aumento en el coste del consumo de electricidad asociado al ordenador donde se desarrollar´ıa el proyecto.

6.3

Estimaci´ on de costes

Es fundamental estimar de la manera m´as exacta posible los recursos humanos y materiales que se destinar´ an al proyecto; a fin de cuentas, recursos que se traducir´an en un coste econ´ omico que en algunos casos puede llegar a plantear la viabilidad del proyecto.

6.3.1

Costes recursos humanos

El cuadro 6.2 muestra una estimaci´on del salario de cada uno de los roles presentes en el proyecto. Cuadro 6.2: Estimaci´on salarial de los roles del proyecto. Rol Jefe de proyecto Analista Programador

Salario 20 euros/hora 20 euros/hora 15 euros/hora

36 La relaci´ on de estos salarios con las horas estimadas que cada rol dedica al proyecto, para cada una de las etapas del diagrama de planificaci´on Gantt, resulta en los costes de personal del proyecto (tablas 6.3, 6.4). Cuadro 6.3: Estimaci´ on desglosada del coste de los recursos humanos del proyecto. Tarea

Duraci´on

B´ usqueda de herramientas existentes Prueba y selecci´ on de herramientas existentes Adecuaci´ on de herramientas seleccionadas Pruebas de carga y optimizaci´ on Prueba piloto Documentaci´ on Total

Dedicaci´on (horas) Jefe de Proyecto

Analista

Programador

30

0

30

0

60

10

50

0

90

0

15

75

150

0

150

0

66 72

16 22 48 horas

50 18 313 horas

0 32 107 horas

Cuadro 6.4: Estimaci´on del coste de los recursos humanos del proyecto. Rol Jefe de proyecto Analista Programador Total

Dedicaci´on 48 313 107

Salario 20 euros/hora 20 euros/hora 15 euros/hora

Total 960 euros 6260 euros 1605 euros 8825 euros

Estos costes de los recursos humanos ascienden a 8825 euros.

6.3.2

Costes recursos materiales

A la hora de planificar los costes del proyecto tambi´en se deben tomar en consideraci´ on todas las herramientas, tangibles e intangibles, que el equipo humano utiliza. Se distinguen los costes directamente relacionados con el proyecto en dos grupos: hardware y software. Por u ´ltimo, se muestran los costes indirectamente relacionados.

Hardware La tabla 6.5 muestra una estimaci´on del coste de los elementos f´ısicos necesarios en el proyecto.

37 Cuadro 6.5: Estimaci´on de los costes hardware del proyecto. Concepto Ordenador Servidor Total

Precio 800 euros 1800 euros 2600 euros

Estos costes ascienden a 2600 euros. En cuanto al tiempo de amortizaci´on, se considera el m´aximo fijado por Hacienda; a d´ıa de hoy, permite liquidar los equipos inform´aticos en 8 a˜ nos, con un coeficiente lineal m´aximo del 25 % (Ley 27/2014). Hay que diferenciar que el uso del ordenador estar´a limitado a 6 horas diarias (duraci´ on de una jornada laboral, de acuerdo con la planificaci´on del proyecto); el servidor, en cambio, estar´ a en funcionamiento sin interrupci´on los 365 del a˜ no. Los costes de amortizaci´ on del hardware del proyecto ascienden a 482.05 euros. 800 · 0,25 · 468 1800 · 0,25 · 365 · 8 + = 482,05 euros 365 · 8 365 · 8

(6.1)

Software El coste de los componentes l´ ogicos del proyecto ser´a nulo puesto que s´olo se utiliza software libre (cuadro 6.6). Cuadro 6.6: Material software utilizado. Concepto Sistemas operativos: Debian, CentOS Servidor web: nginx Control de versiones: git Pruebas de carga: Jmeter, dstat An´ alisis de datos: matplotlib Total

0 euros

Otros Se estima que el equipo de sobremesa, encendido durante toda la jornada laboral, consume 230 W; la iluminaci´ on del puesto de trabajo, 96 W; otros aparatos (telecomunicaciones), 10W; el servidor, 180W; tambi´en se aproxima el precio de la electricidad, impuestos incluidos, a 0.14 euros por KWh.

consumoservidor =

180 W 365 dias 24 horas · 8 anos · · = 1766,02 euros 1000 ano dia

38

consumopc =

consumootros =

0,14 euros 230 W · 468 horas · = 15,07 euros 1000 kW h 96 + 10 W 0,14 euros · 468 horas · = 6,95 euros 1000 kW h

El cuadro 6.7 muestra una estimaci´on del coste de los elementos indirectamente relacionados con el proyecto. Cuadro 6.7: Estimaci´on de los costes indirectos del proyecto. Consumos Servidor web Ordenador Otros Total

Precio 1766.02 euros 15.07 euros 6.95 euros 1788.04 euros

Estos costes ascienden a 1788.04 euros.

6.3.3

Costes imprevistos

Las posibles desviaciones temporales suponen, en el peor de los casos, una dedicaci´on extra al proyecto de 42 horas. Esta dedicaci´on se repartir´ıa entre los diferentes roles y etapas como muestra el cuadro 6.8 y aumentar´ıa el coste de los recursos humanos en 780 euros (cuadro 6.9). Cuadro 6.8: Dedicaci´ on extra al proyecto fruto de desviaciones temporales. Tarea Adecuaci´ on de herramientas seleccionadas Pruebas de carga y optimizaci´on Prueba piloto Total

Dedicaci´on (horas) Analista 0 12 18 30 horas

Programador 12 0 0 12 horas

Cuadro 6.9: Coste extra de los recursos humanos fruto de desviaciones temporales. Rol Analista Programador Total

Dedicaci´on extra 30 12

Salario 20 euros/hora 15 euros/hora

Total 600 euros 180 euros 780 euros

Tambi´en se decide destinar una partida de 500 euros para afrontar gastos de reparaci´ on de los equipos inform´ aticos (servidor web y ordenador), en caso de que estos fallen. Un total de 1280 euros se destinar´an, por tanto, a posibles imprevistos.

39

6.3.4

Coste total

A continuaci´ on se agrupan todos los costes del proyecto (cuadro 6.10). Cuadro 6.10: Estimaci´on de los costes totales del proyecto. Concepto Recursos humanos Materiales directos Materiales indirectos Imprevistos Total

Precio 8825 euros 2600 euros 1788.04 euros 1280.00 euros 14,493.04 euros

El precio total asciende a 14,493.04 euros.

6.3.5

Control de gesti´ on

Para llevar un control de las posibles desviaciones presupuestarias que puedan aparecer a medida que se desarrolla este proyecto se contabilizar´a el n´ umero de horas dedicadas a cada etapa. Una vez termine el proyecto, se calcular´a el coste asociado a esta cantidad real de horas, se comparar´ a con el presupuesto planificado y se evaluar´an las desviaciones.

6.4

Resultado planificaci´ on

Se ha respetado la planificaci´ on inicial (cuadro 6.1) a excepci´on de la cuarta etapa (Pruebas de carga y optimizaci´ on), que se complet´o el 11 de diciembre (90 horas m´as de las previstas). Los motivos principales del retraso se deben a: • La baja experiencia del autor en la materia, insuficiente para detectar a tiempo unas bajadas puntuales de rendimiento de la m´aquina sobre la que se realizaban los experimentos. Sin entrar m´as en detalle, este decremento en el rendimiento era causado por el sistema de monitorizaci´on del servidor. • Errores puntuales de disco en la m´aquina donde se realizaban los experimentos y que han obligado, en varias ocasiones, a repetir pruebas de carga. Se desconoce el motivo real, aunque un cambio de configuraci´on solvent´o el problema. En la planificaci´ on inicial del proyecto ya se contabilizaron 42 horas de trabajo extras asumibles, es decir, que el proyecto pod´ıa soportar aun manteniendo la fecha de finalizaci´ on (23/12/2015). El proyecto se ha demorado 90 horas.

40 Se prevee que estas 48 horas no previstas inicialmente alarguen el proyecto 16 jornadas m´as; aunque 48 horas correspondan a 8 jornadas de 6 horas, la necesidad del autor de compaginar el proyecto con ex´amenes y entregas har´a que este se dilate 16 jornadas en total (de 3 horas cada una). Por tanto, la nueva fecha de finalizaci´on del proyecto ser´ a el d´ıa 10/01/2016. En cuanto a los costes; la planificaci´on inicial ya cubr´ıa los costes de 30 horas extras del analista (12 de la etapa de Pruebas de carga y 18 de la Prueba Piloto, que finalmente no se han utilizado). El coste de 60 horas extras del analista, a 20 euros/hora, suponen 1020 euros (despu´es de restar el coste extra del programador, que finalmente no se ha llevado a cabo) a asumir de m´as respecto a la planificaci´on inicial en cuanto a los costes extra de recursos humanos. Por tanto, el coste total final del proyecto, se sit´ ua en 15,513.04 euros. Esta desviaci´ on no supone un aumento de los costes materiales.

6.5

Sostenibilidad

Despu´es de estudiar los costes materiales y humanos del proyecto, es necesario preguntarse si es sostenible y econ´ omicamente viable.

6.5.1

Viabilidad econ´ omica

Este proyecto no busca ninguna forma de ingreso. Despu´es de estimar los costes totales del proyecto y mostrarlos a los directores, el proyecto se considera viable econ´omicamente.

6.5.2

Evaluaci´ on del impacto

Impacto econ´ omico El uso de Internet est´ a cada vez m´as extendido en el mundo; cada vez m´as personas acceden al contenido que ofrece esta gran red. Este proyecto pone a disposici´on de todas estas personas un curso que puede acercarles al mundo de la programaci´ on, ya sea inici´andoles o ayud´andoles a perfeccionar la t´ecnica. Siendo este curso abierto y gratuito, el impacto econ´omico que puede tener este proyecto es muy positivo, m´ as aun si hablamos de gente con pocos recursos a los que, de otro modo, les ser´ıa imposible asistir a un curso de estas caracter´ısticas.

41 Impacto social Como se acaba de ver, este proyecto no solo repercute econ´omicamente en las personas que lo utilizan, sino que adem´ as les proporciona una fuente de conocimiento libre, accesible sin ning´ un tipo de restricci´ on. El factor social, por tanto, est´a altamente integrado en el proyecto. Sumado a esto, s´ olo se adquieren para el proyecto aquellos componentes el proceso de fabricaci´ on del cual haya sido respetuoso con sus trabajadores (condiciones dignas y sin ninguna forma de explotaci´ on). Para acabar, todo el material utilizado en el documento (software, documentaci´ on, manuales) ser´ a liberado bajo licencia GNU GPL para que cualquier persona pueda usar, estudiar, copiar y modificar el software de manera libre.

Impacto ambiental Uno de los puntos del proyecto es optimizar el rendimiento de la plataforma, esto es, conseguir la m´ axima capacidad de procesado con el m´ınimo uso de recursos posible. Esta mejora se aplica durante la etapa de pruebas de carga y optimizaci´on. Tambi´en hay que destacar que los ordenadores y especialmente los procesadores actuales auto-regulan su velocidad y por tanto su consumo en base a la carga que soportan; cuanto m´ as baja es, menos recursos consumen. Se priorizan dentro del proyecto los componentes de bajo consumo y aquellos cuyo proceso de fabricaci´on deje la menor huella ecol´ ogica posible. Por u ´ltimo, y no menos importante, se adoptan medidas que contribuyen a cuidar el medio ambiente:

• Uso de papel reciclado; imprimir documentos s´olo cuando sea imprescindible.

• Desconectar equipos inform´aticos cuando no se vayan a utilizar (apagar monitor del ordenador; poner el equipo en suspensi´on; apagarlo al finalizar la jornada laboral).

• Abrir las ventanas para aclimatar el lugar de trabajo; si es necesario, encender el aire acondicionado con una temperatura entre 23 y 25 grados.

42 Cuadro 6.11: Matriz de sostenibilidad. ¿Sostenible? Planificaci´ on Valoraci´ on Resultados Valoraci´ on Riesgos Puntuaci´ on

6.6

Econ´omica Viabilidad econ´omica 7 Desviaci´on en previsi´on 9 Cambios de escenario 0

Social Mejora en calidad de vida 6 Impacto en entorno social 6 Da˜ nos sociales 0

Ambiental An´alisis de recursos 8 Consumo de recursos 8 Da˜ nos ambientales 0

Leyes y regulaciones

Se tienen en cuenta y se respetan todas las condiciones de uso de todo el software utilizado en este proyecto. Notar que todo el software no propio utilizado es libre (tabla 6). De igual manera, todo el material propio creado para este proyecto (software, documentaci´ on, manuales) ser´ a liberado bajo licencia GNU GPL para que cualquier persona pueda usar, estudiar, copiar y realizar modificaciones de manera libre. Dado que este proyecto no ha trabajado con datos personales, las regulaciones que pudieran aplicarse en materia de protecci´on de datos (Ley Org´anica 15/1999) quedan fuera del ´ ambito del proyecto.

43

Cap´ıtulo 7

Conclusi´ on En este proyecto se repasa la problem´atica de la masividad en los MOOC a la hora de corregir y evaluar a los estudiantes, m´as concretamente en cursos de programaci´on. Primeramente hemos buscado herramientas que permitieran crear una plataforma para evalaur y calificar de forma autom´atica a los estudiantes de un MOOC de programaci´ on python, utilizando el m´ odulo doctest, para minimizar la problem´atica del feedback. Se selecciona el m´ odulo VPL, integrable facilmente en Moodle como plugin. Se ha analizado la posibilidad de poder incluir actividades VPL en plataformas externas en las que no se tienen permisos especiales, a trav´es de LTI. Esto es posible con el m´odulo LTI Provider de Moodle. Hemos mejorado doctest y lo hemos integrado en el m´odulo VPL como mecanismo de correcci´ on de programas python. Seguidamente se buscan los l´ımites de esta plataforma; el flujo de usuarios capaz de atender con demoras no superiores a los 2 segundos. A trav´es de pruebas de carga consistentes en enviar archivos a una actividad VPL, se estresa la plataforma. Se aplican modificaciones en la configuraci´on del software que sirve esta plataforma y se analiza si suponen una mejora de rendimiento. Se determinan las configuraciones m´as apropiadas y las que m´ as perjudican el rendimiento de la plataforma. Por u ´ltimo, se instala y prepara el sistema en un ambiente de producci´on. Se propone un esquema de sistema distribuido para aumentar la capacidad multiplicando el n´ umero de nodos.

7.1

Trabajo futuro

Ser´ıa interesante explotar la red distribu´ıda planteada en la figura 5.2 y cuantificar la penalizaci´ on al a˜ nadir los elementos comunes (sistema de ficheros, bases de datos) respecto

44 al primer esquema. Tambi´en ser´ıa interesante analizar la conveniencia de extraer la funcionalidad de VPL y convertirla en una herramienta independiente de Moodle, LTI-compliant. Esta herramienta podr´ıa utilizarse para casos como el que nos ocupa, en que no estamos aprovechando las funcionalidades principales de Moodle (el curso se desarrolla en un LMS externo).

7.2

Integraci´ on de los conocimientos

Un gran n´ umero de conocimientos adquiridos durante el grado se ponen en pr´actica en este proyecto. Son necesarios conocimientos de programaci´on para interpretar y escribir c´odigo; las asignaturas de programaci´ on juegan, por tanto, un papel fundamental en este proyecto (etapas Adecuaci´ on de herramientas seleccionadas y Pruebas de Carga y Optimizaci´ on). En la etapa de Pruebas de Carga y Optimizaci´on se desarrolla una interfaz para poder analizar y comparar el resultado de los experimentos (etapa Pruebas de Carga y Optimizaci´ on) con m´ as facilidad. El an´alisis estad´ıstico es necesario para interpretar correctamente los resultados. No menos importante son los conocimientos adquiridos en asignaturas de arquitectura y sistemas operativos; conocer c´omo se organiza un computador es crucial para saber qu´e partes/procesos del sistema son susceptibles de ser mejorados y qu´e optimizaciones se deben aplicar en cada momento. Por u ´ltimo, un conocimiento b´asico de redes y administraci´on de sistemas inform´aticos garantizar´ a un correcto despliegue del sistema y un nivel de seguridad de los servicios que presta ´ optimos.

45

Bibliograf´ıa A. Mani, D. Venkataramani, J. P. and Roura, S. (2014). Better feedback for educational online judges. 8 Debiasi L., A. S. (2013). Automated assessment in massive open online courses. 7 Fiona Fui-Hoon, N. (2004). A study on tolerable waiting time: how long are web users willing to wait? 18 Julio C. Caiza, J. M. D. A. (2013). Programming assignments automatic grading: Review of tools and implementations. 9 Mart, J. (2013). Juez autom´ atico para la evaluaci´o de problemas de programaci´on en los primeros cursos de estudios de inform´atica. [Online; consultado el 12-Dic-2015]. 9 Moodle (2015). Moodle statistics. https://moodle.net/stats/. [Online; consultado el 20-Sep-2015]. 6 Siemens, G. (2012a). Moocs are really a platform. http://www.elearnspace.org/blog/ ?p=5659. [Online]. 4 Siemens, G. (2012b). What is the theory that underpins our moocs? http://www. elearnspace.org/blog/?p=5603. [Online]. 4

46

Ap´ endice A

Manual de doctest mod