Laboratorio Remoto Arduino para la realización de prácticas de Electrónica en la ESIS de la PUCESD

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas

LABORATORIO REMOTO ARDUINO PARA LA REALIZACIÓN DE PRÁCTICAS DE ELECTRÓNICA EN LA ESCUELA DE SISTEMAS DE LA PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO; PERIODO 2017 - 2018 Trabajo de Titulación previa a la obtención del título de Ingeniero de Sistemas y Computación

Línea de Investigación: Estudio, Diseño e Implementación de Software

Autor: GONZALO GABRIEL BONILLA BRAVO

Director: Mg. LUIS JAVIER ULLOA MENESES

Santo Domingo – Ecuador Agosto, 2018

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas HOJA DE APROBACIÓN LABORATORIO REMOTO ARDUINO PARA LA REALIZACIÓN DE PRÁCTICAS DE ELECTRÓNICA EN LA ESCUELA DE SISTEMAS DE LA PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO; PERIODO 2017 - 2018

Línea de Investigación: Estudio, Diseño e Implementación de Software Autor: GONZALO GABRIEL BONILLA BRAVO Luis Javier Ulloa Meneses, Mg.

f.

DIRECTOR DEL TRABAJO DE TITULACIÓN Willian Javier Ocampo Pazos, Mg.

f.

CALIFICADOR Jon Azcona Esteban, Mg.

f.

CALIFICADOR Luis Javier Ulloa Meneses, Mg.

f.

DIRECTOR DE LA ESCUELA DE SISTEMAS

Santo Domingo – Ecuador Agosto, 2018

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Gonzalo Gabriel Bonilla Bravo portador de la cédula de ciudadanía Nº 1713027637 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniero de Sistemas y Computación son absolutamente originales, auténticos y personales.

En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legal y académica.

Gonzalo Gabriel Bonilla Bravo CI 1713027637

iv

AGRADECIMIENTO

A mi familia, especialmente a mi madre Faty; a mis tíos Juanita y Gustavo, sin su apoyo incondicional jamás hubiera culminado esta etapa de mi vida, les estaré eternamente agradecido.

A mi profesor Jon Azcona por darme la idea inicial de este proyecto de investigación y por el constante soporte recibido de su parte; y al resto de profesores que aportaron con un granito de arena.

A mis amigos y compañeros de carrera, los cuales puedo contar con los dedos de una mano, son personas que al verlos culminar su periplo universitario podré llamarlos con orgullo “Señores Ingenieros”.

v

DEDICATORIA

Para mi eterna compañera de vida. Porque las experiencias vividas, junto a ti, a lo largo de los años han sido únicas y maravillosas; porque todavía quedan muchas más por compartir a tu lado.

Te amo…

vi

RESUMEN

El presente trabajo de investigación “Laboratorio Remoto Arduino” se caracteriza por dotar a los estudiantes de una herramienta integradora que facilite el proceso de enseñanza práctica en las asignaturas afines a la electrónica, en la Escuela de Sistemas PUCE-SD. Este instrumento ha sido construido con un microcontrolador Arduino y una microcomputadora Raspberry Pi que son componentes de hardware libre y de bajo costo, respaldados por una gran comunidad de personas en el mundo; para el desarrollo del software se ha empleado Python como lenguaje de programación principal y se ha apoyado en JavaScript para las tareas secundarias. Además, se ha recurrido a gran una variedad de tecnologías (WebSockets, AJAX, PostgreSQL, etc.) con el fin de conseguir la integración total de la plataforma, para su correcto funcionamiento. El marco de trabajo Scrum, ha sido el elegido para toda la fase de ejecución del producto en cuestión, sirviendo como guía de buenas prácticas en el desarrollo de software y dándole un valor agregado al mismo. El resultado obtenido es una herramienta confiable, escalable, robusta e interactiva; capaz de manipular remotamente dispositivos electrónicos para realizar la experimentación a través de un interfaz web, al cual el estudiante accede de forma organizada, controlado por un sistema de cola.

Palabras clave: Laboratorio remoto, Arduino, Raspberry Pi.

vii

ABSTRACT

The current research work "Arduino Remote Laboratory" is characterized by providing students with an integrating tool that facilitates the process of practical teaching in subjects related to electronics at School of Systems at PUCE-SD. This instrument has been built with an Arduino microcontroller and a Raspberry Pi microcomputer that are free and low cost hardware components, backed up by a large community of people in the world; for the development of the software, Python has been used as the main programming language and it has been supported by JavaScript for secondary tasks. In addition, a great variety of technologies (WebSockets, AJAX, PostgreSQL, etc.) has been used in order to achieve full integration of the platform for its proper functioning. The Scrum framework has been chosen for the entire execution phase of the product in question, serving as a guide to good practices in software development and giving added value to it. The outcome achieved is a reliable, scalable, robust and interactive tool which is able to remotely manipulate electronic devices to make experimentation through a web interface to which the student accesses in an organized manner, controlled by a queue system.

Keywords: Remote laboratory, Arduino, Raspberry Pi.

viii

ÍNDICE DE CONTENIDOS 1.

INTRODUCCIÓN ....................................................................................................... 1

2.

PLANTEAMIENTO DEL PROBLEMA .................................................................... 3

2.1.

Problema de Investigación ........................................................................................... 3

2.2.

Justificación de la Investigación .................................................................................. 4

2.3.

Objetivos de Investigación .......................................................................................... 5

2.3.1.

Objetivo General. ......................................................................................................... 5

2.3.2.

Objetivos Específicos. ................................................................................................. 5

3.

MARCO REFERENCIAL........................................................................................... 7

3.1.

Antecedentes ................................................................................................................ 7

3.2.

Revisión de la Literatura o Fundamentos Teóricos ..................................................... 9

3.2.1.

Ingeniería de software.................................................................................................. 9

3.2.1.1. Diversidad de la ingeniería de software..................................................................... 10 3.2.1.2. Metodologías de desarrollo de software. ................................................................... 10 3.2.1.3. Programación Extrema (XP)...................................................................................... 12 3.2.1.4. Scrum. ........................................................................................................................ 14 3.2.2.

Laboratorio Remoto. .................................................................................................. 17

3.2.2.1. Niveles de jerarquía. .................................................................................................. 17 3.2.2.2. Seguridad del laboratorio. .......................................................................................... 18 3.2.2.3. RLMS. ....................................................................................................................... 18 3.2.3.

Arquitectura Cliente/Servidor. ................................................................................... 19

3.2.3.1. Frond-End. ................................................................................................................. 20 3.2.3.2. Back-End. .................................................................................................................. 21 3.2.4.

Base de datos. ............................................................................................................ 23

3.2.4.1. Sistema de administración de base de datos. ............................................................. 23 3.2.5.

Hardware.................................................................................................................... 25

3.2.5.1. Arduino Uno. ............................................................................................................. 25 3.2.5.2. Arduino Mega 2560. .................................................................................................. 25 3.2.5.3. Comparativa entre microcontroladores...................................................................... 26 3.2.5.4. Raspberry Pi 3............................................................................................................ 27 3.2.5.5. Beaglebone Black. ..................................................................................................... 28

ix

3.2.5.6. Comparativa entre microcomputadores. .................................................................... 28 3.2.6.

Metodología de enseñanza práctica. .......................................................................... 29

3.2.6.1. El aprendizaje. ........................................................................................................... 29 3.2.6.2. Enfoque constructivista. ............................................................................................ 30 3.2.6.3. ABP (Aprendizaje Basado en Problemas). ................................................................ 30 3.2.6.4. Educación STEM. ...................................................................................................... 30 3.2.6.5. Laboratorio remoto como recurso didáctico. ............................................................. 31 4.

METODOLOGÍA DE LA INVESTIGACIÓN ......................................................... 32

4.1.

Enfoque / Tipo de Investigación ................................................................................ 32

4.1.1.

Enfoque de la investigación. ...................................................................................... 32

4.1.2.

Tipo de investigación. ................................................................................................ 32

4.1.2.1. Investigación documental. ......................................................................................... 32 4.1.2.2. Investigación de campo. ............................................................................................ 32 4.1.2.3. Investigación descriptiva. .......................................................................................... 32 4.1.2.4. Investigación aplicada. .............................................................................................. 33 4.2.

Población / Muestra ................................................................................................... 33

4.2.1.

Muestra. ..................................................................................................................... 34

4.3.

Técnicas e Instrumentos de Recogida de Datos ........................................................ 34

4.4.

Técnicas de Análisis de Datos ................................................................................... 34

4.5.

Metodología de Desarrollo de Software .................................................................... 35

4.5.1.

Diferencias entre Scrum y XP. .................................................................................. 35

4.5.2.

El proceso Scrum. ...................................................................................................... 35

4.5.2.1. Planificación del Sprint.............................................................................................. 36 4.5.2.2. Ejecución del Sprint. .................................................................................................. 36 4.5.2.3. Revisión del Sprint. ................................................................................................... 36 4.5.2.4. Retrospectiva del Sprint. ............................................................................................ 36 5.

RESULTADOS ......................................................................................................... 37

5.1.

Discusión y Análisis de los Resultados ..................................................................... 37

5.1.1.

Resultados de la entrevista......................................................................................... 37

5.1.1.1. Discusión de los resultados de la entrevista. ............................................................. 38 5.1.2.

Resultados de las encuestas. ...................................................................................... 39

5.1.2.1. Discusión de los resultados obtenidos en las encuestas............................................. 49

x

5.2.

Laboratorio Remoto Arduino – ArduiLab ................................................................. 50

5.2.1.

Sprint 1....................................................................................................................... 50

5.2.1.1. Planificación del Sprint.............................................................................................. 50 5.2.1.2. Plan de Release. ......................................................................................................... 54 5.2.1.3. Ejecución del Sprint. .................................................................................................. 56 5.2.1.4. Revisión del Sprint. ................................................................................................... 65 5.2.1.5. Retrospectiva del Sprint. ............................................................................................ 65 5.2.2.

Sprint 2....................................................................................................................... 66

5.2.2.1. Planificación del Sprint.............................................................................................. 66 5.2.2.2. Ejecución del Sprint. .................................................................................................. 68 5.2.2.3. Revisión del Sprint. ................................................................................................... 75 5.2.2.4. Retrospectiva del Sprint. ............................................................................................ 75 5.2.3.

Sprint 3....................................................................................................................... 76

5.2.3.1. Planificación del Sprint.............................................................................................. 76 5.2.3.2. Ejecución del Sprint. .................................................................................................. 78 5.2.3.3. Revisión del Sprint. ................................................................................................... 86 5.2.3.4. Retrospectiva del Sprint. ............................................................................................ 86 5.3.

Evaluación de Impacto del Proyecto de investigación .............................................. 88

5.3.1.

Impacto Tecnológico. ................................................................................................ 88

5.3.2.

Impacto Social. .......................................................................................................... 89

5.3.3.

Impacto Económico. .................................................................................................. 90

5.3.4.

Impacto General......................................................................................................... 90

6.

CONCLUSIONES ..................................................................................................... 92

7.

RECOMENDACIONES............................................................................................ 93

8.

LISTA DE REFERENCIAS ...................................................................................... 94

9.

GLOSARIO ............................................................................................................... 97

10.

ANEXOS ................................................................................................................. 100

xi

ÍNDICE DE TABLAS Tabla 1 Metodologías tradicionales vs metodologías ágiles .................................................... 12 Tabla 2 Comparativa entre PHP y Python ............................................................................... 22 Tabla 3 Comparativa entre bases de datos ............................................................................... 24 Tabla 4 Comparativa de Arduino ............................................................................................. 26 Tabla 5 Comparativa de microcomputadores .......................................................................... 28 Tabla 6 Estudiantes de la Escuela de Sistemas a partir de quinto semestre ............................ 33 Tabla 7 Diferencias entre Scrum y XP .................................................................................... 35 Tabla 8 Modelo didáctico en la asignatura de Diseño de lenguajes y autómatas .................... 39 Tabla 9 Relación del nivel de interés con el modelo didáctico cursado .................................. 41 Tabla 10 Relación de las actividades prácticas con el modelo didáctico cursado ................... 42 Tabla 11 Relación del nivel de desempeño con el modelo didáctico cursado ......................... 43 Tabla 12 Relación de la importancia práctica-teoría con el modelo didáctico cursado........... 44 Tabla 13 Relación de implementación del laboratorio con el modelo didáctico cursado ....... 45 Tabla 14 Comprensión del hardware a través de Arduino ....................................................... 46 Tabla 15 Inversión proyecto Arduino ...................................................................................... 47 Tabla 16 Necesidad del laboratorio remoto Arduino ............................................................... 48 Tabla 17 Conocimiento de Arduino como ayuda en la vida profesional ................................. 49 Tabla 18 Roles Scrum .............................................................................................................. 50 Tabla 19 Product Backlog versión final................................................................................... 51 Tabla 20 Sprint Backlog número 1 .......................................................................................... 55 Tabla 21 Formulario de reunión de retrospectiva 1 ................................................................. 66 Tabla 22 Sprint Backlog número 2 .......................................................................................... 67 Tabla 23 Formulario de reunión de retrospectiva 2 ................................................................. 76 Tabla 24 Sprint Backlog número 3 .......................................................................................... 77 Tabla 25 Formulario de reunión de retrospectiva 3 ................................................................. 87 Tabla 26 Niveles de impacto.................................................................................................... 88 Tabla 27 Impacto tecnológico .................................................................................................. 88 Tabla 28 Impacto social ........................................................................................................... 89 Tabla 29 Impacto económico ................................................................................................... 90 Tabla 30 Impacto general......................................................................................................... 90

xii

ÍNDICE DE FIGURAS Figura 1. Capas de la ingeniería de software. .......................................................................... 10 Figura 2. El proceso de la programación extrema. .................................................................. 13 Figura 3. Fases de un Sprint. .................................................................................................... 16 Figura 4. Diferentes tipos de arquitecturas de laboratorios remotos. ...................................... 17 Figura 5. Autentificación y autorización en un sistema web. .................................................. 18 Figura 6. El modelo cliente/servidor. ....................................................................................... 20 Figura 7. Arduino UNO, vista superior. .................................................................................. 25 Figura 8. Arduino Mega 2560, vista superior. ......................................................................... 26 Figura 9. Raspberry Pi 3 model B. ........................................................................................... 27 Figura 10. Beaglebone Black, vista superior. .......................................................................... 28 Figura 11. Modelo didáctico en la asignatura de Diseño de lenguajes y autómatas. ............... 40 Figura 12. Relación del nivel de interés con el modelo didáctico cursado. ............................. 41 Figura 13. Relación de las actividades prácticas con el modelo didáctico cursado. ................ 42 Figura 14. Relación del nivel de desempeño con el modelo didáctico cursado. ..................... 43 Figura 15. Relación de la importancia práctica-teoría con el modelo didáctico. ..................... 44 Figura 16. Relación de implementación del laboratorio con el modelo didáctico................... 45 Figura 17. Compresión del hardware a través de Arduino. ..................................................... 46 Figura 18. Inversión proyecto Arduino. ................................................................................... 47 Figura 19. Necesidad del laboratorio remoto Arduino. ........................................................... 48 Figura 20. Conocimiento de Arduino como ayuda en la vida profesional. ............................. 49 Figura 21. Serie Fibonacci Scrum. ........................................................................................... 52 Figura 22. Tablero Trello. ........................................................................................................ 53 Figura 23. Repositorio del proyecto en la herramienta Github. ............................................... 54 Figura 24. Maquetado del laboratorio remoto Arduino - Login. ............................................. 56 Figura 25. Maquetado del laboratorio remoto Arduino – Laboratorio. ................................... 57 Figura 26. Árbol del directorio de proyecto............................................................................. 58 Figura 27. Conexión cámara de Raspberry Pi. ........................................................................ 59 Figura 28. Herramienta de configuración Raspberry Pi. ......................................................... 59 Figura 29. Directorio StreamPy. .............................................................................................. 60 Figura 30. Modelo físico de la base de datos. .......................................................................... 63

xiii

Figura 31. Página principal administración. ............................................................................ 63 Figura 32. Página usuarios administración. ............................................................................. 64 Figura 33. Ejecución de prueba unitaria. ................................................................................. 64 Figura 34. BurnDown Chart 1. ................................................................................................ 65 Figura 35. Página carga Sketch Arduino. ................................................................................ 68 Figura 36. Arduino-mk ejecutándose en el servidor ................................................................ 70 Figura 37. Análogos Knob ....................................................................................................... 70 Figura 38. Filtro paso bajo. ...................................................................................................... 71 Figura 39. Capa intermedia Channel. ...................................................................................... 73 Figura 40. Puerto serial – led encendido.................................................................................. 74 Figura 41. Puerto serial – led apagado. .................................................................................... 74 Figura 42. BurnDown Chart 2. ................................................................................................ 75 Figura 43. Login – Laboratorio remoto Arduino. ................................................................... 79 Figura 44. Login – Error en credenciales................................................................................. 79 Figura 45. Acceso exitoso. ....................................................................................................... 80 Figura 46. Peticiones de actualización. .................................................................................... 81 Figura 47. Página de usuario en espera. ................................................................................... 82 Figura 48. Ejemplo código JavaScript. .................................................................................... 82 Figura 49. Ejemplo código Python. ......................................................................................... 83 Figura 50. Ejemplo función subir archivo y respaldos. ........................................................... 84 Figura 51. Respaldos generados. ............................................................................................. 84 Figura 52. Estados de botones digitales. .................................................................................. 85 Figura 53. BurnDown Chart 3. ................................................................................................ 86

xiv

ร NDICE DE ANEXOS Anexo 1: Carta de intenciรณn .................................................................................................. 100 Anexo 2: Acta de entrega-recepciรณn del proyecto ................................................................. 101 Anexo 3: Carta de impacto .................................................................................................... 102 Anexo 4: Modelo entrevista ................................................................................................... 103 Anexo 5: Modelo encuesta..................................................................................................... 104 Anexo 6: Historias de usuario ................................................................................................ 106 Anexo 7: Pruebas de aceptaciรณn ............................................................................................ 111

1

1. INTRODUCCIÓN En los últimos años, el desarrollo de las Tecnologías de la Información y Comunicación está consiguiendo estrechar cada vez más, la brecha que existe entre el ser humano y la máquina; dando pie a una mayor integración entre ambos entes. En ingeniería, al momento de estudiar el funcionamiento interno de estos aparatos, es preciso disponer de herramientas necesarias que faciliten la comprensión de los mismos; por ello la experimentación práctica dentro de un laboratorio es fundamental para el porvenir del estudiante universitario.

Cuando se dan situaciones en las que no es posible la implementación de laboratorios físicos para el desarrollo de la práctica, se buscan soluciones que sean adecuadas al contexto de la institución. Es ahí, donde surge la idea del presente trabajo de investigación, estudiando la forma de crear un recurso viable el “laboratorio remoto”, que pueda suplir al laboratorio físico en la gran mayoría de las funcionalidades que se requieren en la Escuela de Sistemas de la Pontificia Universidad Católica del Ecuador Sede Santo Domingo.

El trabajo que se va a presentar se encuentra dividido en cinco capítulos principales, detallándose en cada uno de ellos los contenidos más importantes para la correcta comprensión del lector; el primer capítulo es la Introducción, en él se da entrada a los ítems con los que contará el proyecto de investigación.

El segundo capítulo trata el Planteamiento del problema, en el que se describe las causas que han originado la realización de este trabajo; empezando por delimitar y definir el problema (de lo general a lo particular) que sirve de base para entender mejor la problemática que sigue a continuación. Después, se extiende con una justificación, que como la propia palabra lo dice, trata de evidenciar el “porque” de esta investigación. Y para terminar esta sección se abordan los objetivos tanto el general como los específicos.

A partir del tercer capítulo se adentra en todo el contenido que sustenta el desarrollo del presente trabajo, es decir, el Marco Referencial; subdividiéndose en los siguientes temas: Antecedentes, Ingeniería de Software, Laboratorio Remoto, Arquitectura Cliente/Servidor, Hardware, Metodología de enseñanza práctica.

2

Dentro del cuarto capítulo se va a revisar la Metodología de la Investigación, donde se detalla el enfoque y el tipo de investigación. Además, se describe la población y la muestra que a ser seleccionada como objeto de estudio; las técnicas e instrumentos de recogida y análisis de datos constituyen los penúltimos apartados dentro de este apartado, siendo la metodología de desarrollo de software escogida el último de ellos.

Finalmente, en el capítulo número cinco se discuten y analizan los resultados, de una forma muy detallada, siguiendo los pasos que dicta la metodología de desarrollo de software, recogiendo todo el proceso de construcción del proyecto de investigación; concluyendo y recomendando de manera resumida todos los objetivos que se abordan en este documento de manera clara y concisa.

3

2. PLANTEAMIENTO DEL PROBLEMA 2.1. Problema de Investigación Desde antaño los escenarios de experimentación en las carreras técnicas universitarias, han sido un factor muy importante para su desenvolvimiento práctico. Los laboratorios presenciales tradicionales, se han encargado de brindar solución al ensayo de los estudiantes, desde su nacimiento hasta la actualidad, pero con el paso del tiempo han ido apareciendo ciertos inconvenientes: el elevado costo de implementación y mantenimiento de estos salones siempre ha resultado ser muy elevado, la disponibilidad del recinto con frecuencia ha debido de atenerse a unos horarios establecidos por la institución, etc. Estos problemas, junto con el avance tecnológico, han sido el detonante para ir cambiando la idea de un laboratorio físico; en este aspecto aparecen los primeros laboratorios remotos como es el caso de iLabs creado por el MIT de Massachusetts o WebLab de Deusto, en España; universidades pioneras en la implementación de este tipo de laboratorios en el mundo. A partir de ahí, han ido apareciendo distintas plataformas de laboratorios remotos, en Ecuador, por ejemplo, se implementa un laboratorio remoto a través de una tesis de grado, para prácticas de control automático en la Facultad de Ingeniería en Electricidad y Computación de la ESPOL (Idrovo & Aguilar, 2010).

El nacimiento de la Pontificia Universidad Católica del Ecuador Sede Santo Domingo (PUCE-SD) es relativamente joven, su fundación data del año 1996, gracias a Msc. Emilio Lorenzo Stehle con el afán de crear una Universidad de prestigio dentro de la provincia; que pueda formar personas con las aptitudes necesarias para enfrentarse a la competencia en el mundo laboral y ayudar al próspero desarrollo de la región Tsáchila.

La Escuela de Sistemas se funda en el año 2002, debido a la necesidad de formar profesionales preparados, que puedan satisfacer la demanda tecnológica que existe en la provincia por parte de las empresas privadas e instituciones públicas. Los ingenieros que se gradúan en la PUCE-SD tienen un alto desempeño dentro de la parte intangible que compone la carrera, es decir, el software; ocurre todo lo contrario con el hardware, que resulta ser una asignatura pendiente dentro de la Escuela de Sistemas desde su creación.

Situándose en este contexto, el desarrollo de prácticas dentro del área de electrónica en la Escuela de Sistemas siempre ha sido a través de un software informático que simula el

4

comportamiento del hardware. Éste método no resulta ser la mejor opción para la enseñanza práctica de la asignatura, puesto que los estudiantes necesitan interactuar directamente con los componentes físicos. Para tratar de solucionar esta problemática se plantea la siguiente pregunta de investigación: ¿Cómo mejorar la realización de prácticas de electrónica en la Escuela de Sistemas de la PUCE-SD? La cuestión citada anteriormente, se usa como guía para elaborar las preguntas directrices que desglosarán el problema de modo más específico y son las siguientes: ¿Cuáles son los procesos que intervienen en la realización de prácticas de electrónica en la Escuela de Sistemas de la PUCE-SD? ¿Cuáles son las metodologías y herramientas de desarrollo de software y hardware que podrían aplicarse en la ejecución de este laboratorio remoto Arduino? ¿Cuáles son las funcionalidades que aportará este laboratorio remoto Arduino?

2.2. Justificación de la Investigación Dentro de una carrera universitaria técnica, como es la Ingeniería en Sistemas y Computación el componente práctico es una herramienta esencial en el entorno enseñanzaaprendizaje del estudiante. Con la realización de estas prácticas el futuro ingeniero podrá adquirir ciertas destrezas que se potencian, precisamente, con la experimentación dentro de un laboratorio.

Para los estudiantes de la Escuela de Sistemas, es importante realizar prácticas de electrónica en un laboratorio físico, pero la dificultad de implementar un laboratorio de esta magnitud en la PUCE-SD hace que se plantee la elaboración de la presente investigación.

Mediante el apoyo de un laboratorio remoto, los estudiantes podrán realizar las prácticas como si estuvieran trabajando con sus propias manos en uno de estos laboratorios físicos, ya que se logra total interacción entre el hardware y el software, comprobándose finalmente los resultados de los ejercicios, en tiempo real a través del interfaz web. Precisamente, el hecho de apreciar los resultados in situ despierta total interés en los estudiantes en la asignatura que se encuentran cursando, ayudando a comprender mejor todo el concepto de la teoría a través del desenvolvimiento práctico (Orduña, Almeida, López de Ipiña & García-Zubia, 2014).

5

En la actualidad, trabajar con herramientas de hardware libre se ha convertido en una necesidad; existe una gran cantidad de proyectos que se pueden desarrollar, dentro de la carrera de Sistemas y fuera de ella (cuando el ingeniero se enfrente al mundo laboral); ayuda a innovar dentro de la provincia y así, poder abrirse un enorme abanico de posibilidades donde se puede aplicar este tipo de tecnología. Además, el costo de la implementación de estos proyectos puede llegar a ser realmente bajo, debido a los componentes low-cost de hardware libre que se encuentra en el mercado actual; existe una gran variedad de sensores, actuadores, controladores, etc., los cuales tienen precios muy económicos, tanto que llegan a ser implementados fácilmente en cualquier proyecto que el ingeniero quiera desarrollar (Angulo, García-Zubia, Orduña & Dziabenko, 2013; Bermúdez, Besada, López, Bonache & Cruz, 2015).

Por último y no menos importante, éste proyecto tiene como finalidad contribuir al cumplimiento del objetivo número cuatro del Plan Nacional del Buen Vivir, “Fortalecer las capacidades y potencialidades de la ciudadanía”. Dentro de él, se enmarca como objetivo específico número 4.6, “Promover la interacción recíproca entre la educación, el sector productivo y la investigación científica y tecnológica, para la transformación de la matriz productiva y la satisfacción de necesidades” (Secretaría Nacional de Planificación y Desarrollo [SENPLADES], 2013). Todo esto se consigue mediante una formación técnica para el desarrollo y la innovación tecnológica, que pueda impulsar la producción nacional con altos estándares de calidad y con

ello conseguir finalmente el cambio de la matriz

productiva.

2.3. Objetivos de Investigación 2.3.1. Objetivo General.

Implementar un Laboratorio Remoto Arduino para la realización de prácticas de electrónica en la Escuela de Sistemas de la Pontificia Universidad Católica del Ecuador Sede Santo Domingo; periodo 2017 – 2018.

2.3.2. Objetivos Específicos. 

Determinar los procesos que intervienen en la realización de prácticas de electrónica de los estudiantes de la Escuela de Sistemas de la PUCE-SD.

6



Definir las metodologías de desarrollo de software, herramientas y recursos de hardware necesarios que podrían aplicarse en la realización del laboratorio remoto Arduino.



Desarrollar el laboratorio remoto Arduino cumpliendo con todas las funcionalidades necesarias para su ejecución.

7

3. MARCO REFERENCIAL 3.1. Antecedentes Actualmente, existe una amplia variedad de Laboratorios Remotos alrededor del mundo, la gran mayoría de ellos han sido creados para solucionar problemas específicos o para manipular ciertos componentes físicos dentro de la práctica, todos ellos disponiendo de innumerables recursos para su puesta en marcha; este proyecto se centra en la utilización de hardware libre y accesible económicamente, por ello se ha buscado estudios muy relacionados a estas variables.

Kalúz, Čirka, Valo & Fikar (2014) Esta investigación elaborada en Eslovenia, se integran Arduino junto con Raspberry Pi con el objetivo de crear un laboratorio remoto de bajo costo para la educación en la ingeniería, conocido como ArPi Lab; la motivación principal para desarrollar este proyecto han sido los escasos recursos financieros con los que contaban para desplegar su idea, optando por emplear este tipo de hardware. Dentro del software, se han utilizado diferentes tecnologías, en el servidor se ha empleado Apache con soporte PHP para atender las peticiones HTTP y para la comunicación con el cliente se ha servido de conexiones asíncronas (AJAX) y llamadas síncronas basadas en JSON. Para almacenar la información de los experimentos y la configuración se ha empleado la base de datos MySQL, albergada en el servidor del laboratorio. Para realizar las distintas prácticas en este laboratorio se ha localizado un Arduino por cada experimento, como por ejemplo: modelo de levitación magnética, tanque de sistema hidráulico, planta termal, etc. A modo de conclusión, los autores indican que este tipo de laboratorio remoto es un posible camino para el diseño e implementación del mismo, pudiendo ser aplicado a una gran variedad de experimentos que puedan estar disponibles 24/7 mientras haya conexión a Internet.

Otro estudio realizado en Ucrania, demuestra el desarrollo y la aplicación de un laboratorio remoto en sistemas embebidos; en primera instancia, se encarga de analizar las distintas plataformas de hardware existentes en el mercado, antes de la elección se prioriza el análisis y diseño de los escenarios para determinar los componentes que mejor se ajustan a las necesidades, por ello se debe realizar comparativas entre las distintas plataformas disponibles. Para implementar los experimentos se dispuso de cuatro escenarios: diodos LED, servomotor, display LCD y sensor de ultrasonidos. Dentro del laboratorio se puede escribir el código, compilarlo y enviarlo a la placa Arduino para observar los resultados a través de una

8

cámara web. El trabajo concluye destacando los beneficios del laboratorio como por ejemplo, la disponibilidad, escalabilidad y accesibilidad. Además, de la posible expansión de los experimentos para resolver cualquier tipo de tarea desde las distintas áreas de los sistemas embebidos (Parkhomenko, Gladkova, Sokolyanskii & Kurson, 2015).

Laboratorio remoto de Automática. Una solución de bajo coste basada en Raspberry Pi y Arduino, es una investigación realizada en España, concretamente en la Universidad de Málaga. Donde, por culpa de la crisis por la que atraviesa el país, ha sido muy complicado adquirir y renovar los equipos de sus laboratorios físicos, asimismo, el elevado número de estudiantes matriculados en carreras técnicas acentúa aún más el problema, debido a la falta de equipos para todos ellos. Por tanto, se buscan todo tipo de soluciones, siendo el objetivo de esta investigación el laboratorio remoto; para implementarlo ha sido necesario la utilización del dispositivo Arduino, que actúa como un sistema de envío y recepción de señales del sistema que se está analizando y se conecta, mediante un puerto USB, a la Raspberry Pi que lleva a cabo las funciones de servidor Web y de interfaz de datos, siendo el encargado de gestionar tanto la información desde/hacia el Arduino como el ofrecer al usuario un interfaz en el que se recoja toda la información disponible. Otro de los trabajos encargados a esta placa es la gestión de usuarios de la plataforma, la puesta en marcha de las prácticas, así como, la presentación de resultados (ya sea en tiempo real o en lotes). Los resultados que arroja esta investigación son muy prometedores, las personas que han utilizado dicho laboratorio, valoran positivamente la utilización del mismo, poniendo como punto negativo el diseño y el comportamiento responsivo de la aplicación (Arévalo, García-Morales & Cano, 2017).

En lo que concierne al país, no existen estudios relacionados directamente con laboratorios remotos que empleen Raspberry Pi y Arduino como base. Existen laboratorios remotos de otras índoles como por ejemplo el laboratorio remoto desarrollado en la ESPOL, donde a través de la comunicación cliente – servidor sirve para la ejecución de las prácticas de control automático en la Facultad de Ingeniería que pretende cumplir varios objetivos, entre ellos, la reducción de costos de los recursos para la enseñanza y el aprovechamiento del tiempo para el uso de dichos recursos, permitiendo al estudiante tener acceso al laboratorio sin horarios que restrinjan su utilización y sin importar la ubicación del alumno. (Idrovo & Aguilar, 2010).

9

3.2. Revisión de la Literatura o Fundamentos Teóricos A continuación, se va a redactar toda la parte documental, que sirve como base investigativa para realizar el presente trabajo. Se parte de una idea introductoria acerca de la Ingeniería de software y todo el material necesario que conlleva este amplio tema, de una manera clara y concisa. Después se da paso a la variable independiente en el que se incluye: laboratorio remoto, arquitectura cliente-servidor y hardware, en este punto, el fundamento teórico será más descriptivo; detallando cada uno de los ítems que intervienen en estos temas.

Para finalizar, se hablará de la variable dependiente, que en este caso se trata de la metodología de enseñanza a través de la experiencia en las universidades, centrándose en la importancia del conocimiento práctico en el aprendizaje del estudiante.

3.2.1. Ingeniería de software.

La ingeniería de software surge por la necesidad de elaborar un producto de calidad en el proceso de construcción del proyecto de software; es preciso entender, en primera instancia, el problema existente antes de desarrollar una aplicación. Una vez que se logra asimilar la problemática, se prosigue con la etapa de diseño, donde se debe cimentar toda la estructura del proyecto manteniendo unos altos estándares, se puede decir que el diseño es una etapa transcendental. Por último, a medida que la funcionalidad del software aumenta, las demanda de adaptarla y mejorarla también crecerá, por lo tanto dicho software debe ser capaz de recibir mantenimiento con cierta facilidad.

El IEEE señala que “La ingeniería de software es: 1) 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. 2) El estudio de enfoques según el punto 1” (Pressman, 2010, p. 11).

Pressman (2010) ve a la ingeniería de software como una tecnología con varias capas (ver Figura 1). Donde la calidad es la base fundamental para cualquier proyecto de desarrollo, y se sirve de procesos, métodos y herramientas que se complementan para conseguir un producto elaborado a tiempo y con calidad (p. 21).

10

Figura 1. Capas de la ingeniería de software. Recuperado de “Ingeniería del software: Un enfoque práctico (7ª ed.)” por Pressman, R, 2010, México: McGraw-Hill Educación.

3.2.1.1.

Diversidad de la ingeniería de software.

De acuerdo con Sommerville (2011) el factor más significativo, a la hora de elegir qué técnicas y métodos de ingeniería de software son lo más apropiados, es el tipo de aplicación que va a ser desarrollada. Existen diversos tipos de aplicaciones; aplicaciones independientes, sistemas de procesamiento en lotes, sistemas de entretenimiento, sistemas de adquisición de datos, sistemas de sistemas, entre otras varias, cabe destacar las siguientes: 

Aplicaciones interactivas basadas en transacción: son aplicaciones que se ejecutan en una computadora remota, a la que los usuarios acceden desde sus propias PC, a través de un interfaz Web.



Sistemas de control embebido: son sistemas de control de software que gestionan dispositivos de hardware (pp. 10-11).

3.2.1.2.

Metodologías de desarrollo de software.

Las metodologías en el desarrollo de software son un marco de trabajo que se usa para estructurar, planificar y registrar todo el proceso del desarrollo de cualquier software. En un principio, el desarrollo de software se centraba sólo en metodologías tradicionales, que emplean procesos iniciales muy tediosos, como consecuencia de la extensa documentación recogida antes de pasar a las etapas de análisis y diseño. Es cierto, que se consigue un proyecto de gran calidad pero al ser un proceso rígido que no admite cambios, trae consigo ciertas dificultades; al contrario que ocurre con las metodologías ágiles, que son más flexibles y pueden ser modificadas en cualquiera de sus fases dentro del proceso de desarrollo (Cervone, 2011; Navarro, Fernández & Morales, 2013).

11

3.2.1.2.1. Metodologías tradicionales.

Estas metodologías de desarrollo de software están orientadas por una planificación bien elaborada. Inician el desarrollo del proyecto con un riguroso proceso de recolección de requisitos, previo a las etapas de análisis y diseño, tratando de asegurar resultados de alta calidad. En estas metodologías se concibe un solo proyecto, de grandes dimensiones; se sigue un proceso secuencial en una sola dirección y sin vuelta a atrás; el proceso es rígido y no admite cambios. Por ello los requisitos son pactados de una vez y para todo el proyecto, demandando grandes plazos de planificación previa y muy poca comunicación con el cliente una vez concluido (Khurana & Sohal, 2011, pp. 4-5).

3.2.1.2.2. Metodologías ágiles.

Las metodologías ágiles son flexibles, pueden ser modificadas para que se ajusten a la realidad del proyecto. Los proyectos ágiles se convierten en proyectos más pequeños mediante un cuadro sistemático de características; cada proyecto es tratado de manera independiente y desarrolla los requisitos asignados a él en un periodo corto de tiempo, por lo general, de entre dos a seis semanas. La comunicación con el cliente es constante, llegando incluso a requerir un representante de él, durante todo el desarrollo. Los trabajos son altamente colaborativos y se adaptan de manera eficiente a los cambios; de hecho, el cambio en los requisitos es una particularidad deseada, al igual que las distintas entregas del software al cliente y la retroalimentación por parte de él (Ghosh, 2015, pp. 3-4).

3.2.1.2.3. Comparación entre metodologías.

La tabla 1 muestra las principales características de las metodologías tradicionales, que se diferencian notablemente con los rasgos que dictan las metodologías ágiles a la hora de desarrollar un producto de software. Actualmente, la gran mayoría de proyectos se centran en el desarrollo ágil, ya que la naturaleza cambiante que existe en el mundo moderno, permite a éste método adaptarse fácilmente a estos cambios sin ningún tipo de problema, y por ello se prefiere trabajar con las metodologías de desarrollo ágiles.

12 Tabla 1 Metodologías tradicionales vs metodologías ágiles Metodologías tradicionales

Metodologías ágiles

Predictivos

Adaptativos

Orientados a procesos

Orientados a personas

Proceso rígido

Proceso flexible

Se concibe como un proyecto

Se puede dividir en proyectos más pequeños

Entrega del software al finalizar

Entregas constantes de software

Documentación extensa

Poca documentación

Nota: Adaptado de “Revisión de metodologías ágiles para el desarrollo de software” por Navarro, A., Fernández, J., & Morales, J, 2013, Prospect, 11(2), pp. 30-39.

3.2.1.3.

Programación Extrema (XP).

Wells (2017) dentro de su página web extremeprogramming.org describe a la programación extrema como un marco de trabajo para el desarrollo de software ágil, el cual fue creado por Kent Beck con el objetivo de producir software de gran calidad. XP es la metodología ágil más utilizada por los desarrolladores, se basa en unas características generales básicas donde es asequile el emplear XP y son las siguientes: 

Cuando los requisitos de software cambian dinámicamente.



Cuando existen riesgos causados por proyectos de tiempo fijo que emplean nueva tecnología.



Donde coexiste un pequeño equipo de desarrollo.



Donde la tecnología permite pruebas unitarias y funcionales totalmente automatizadas.

Extreme Programming tiene como modelo base cinco valores, los cuales son: comunicación, simplicidad, retroalimentación, respecto y coraje. Éstos sirven, a su vez, como definición de sus principios, de los que cabe destacar los fundamentales; retroalimentación rápida, asumir la simplicidad en todo momento, el cambio incremental, la aceptación del cambio y el trabajo de calidad.

13

3.2.1.3.1. El proceso XP. Las prácticas de esta metodología emanan de los valores y principios a los que representa y se enfoca en proporcionar una solución a las actividades básicas en un proceso de desarrollo. Pressman (2010) recoge las actividades asociadas al proceso XP que se encuentran de manera resumida en la Figura 2, y las cuales se detallan a continuación:

Figura 2. El proceso de la programación extrema. Recuperado de “Ingeniería del software: Un enfoque práctico (7ª ed.)” por Pressman, R, 2010, México: McGraw-Hill Educación.



Planeación: define el alcance y la fecha de un release (entrega funcional), fracciona las responsabilidades entre el cliente y los desarrolladores. El cliente, para definir los requisitos de su producto, utiliza Historias de Usuario y les asigna un valor de importancia a cada una de ellas. Los desarrolladores en base a estas historias estiman el costo de implementación, las características de cada entrega y el número de iteraciones necesarias para terminar el proyecto.



Diseño: debe ser lo más simple posible, nada más y nada menos, lo que implica que los desarrolladores deben preocuparse por las historias de usuario planeadas para la iteración en la que se encuentran, sin importar los cambios futuros que estos tengan.



Codificación: el concepto clave en esta etapa es la programación en parejas, lo que indica que el código debe ser escrito por dos programadores (uno escribe, otro observa) que se intercambian los roles cada cierto tiempo, para una mejor

14

integración colectiva del equipo de desarrollo. 

Pruebas: las pruebas unitarias son un elemento clave, por eso se crean antes de empezar la codificación, basadas en una estructura que les permita ser automatizadas ahorrando mucho tiempo a los desarrolladores a la hora de encontrar errores en el código. Finalmente, junto con el cliente, se realizan las pruebas de aceptación (p. 64).

3.2.1.4.

Scrum.

En 1993, Jeff Sutherland crea el proceso Scrum, la palabra proviene de un concepto deportivo, propio de equipos de rugby, que se relaciona con la formación utilizada para la recuperación rápida del juego ante una infracción. Scrum es tomada como referencia del estudio realizado por Takeuchi y Nonaka en 1986, donde se da un nuevo enfoque al desarrollo de un producto, tratando de incrementar su flexibilidad y rapidez, con la integración de un grupo interdisciplinario y llevando a cabo múltiples fases que se solapan entre sí (Scrum Alliance, 2017).

La metodología ágil Scrum es un marco de trabajo ideado para lograr la colaboración eficaz entre sus distintos miembros (cada uno de ellos con un rol asignado), empleando un conjunto de reglas y artefactos con el objetivo de crear la estructura necesaria para un funcionamiento adecuado. Los equipos Scrum a través de la auto-gestión les permite elegir cómo hacer su trabajo, en vez de seguir lineamientos de personas que carecen de contexto; los integrantes del equipo son multifuncionales, es decir, tienen todos los conocimientos necesarios para realizar las tareas. La entrega del producto se da en iteraciones, pudiendo ser modificada por el dueño del producto (Navarro, Fernández, & Morales, 2013).

3.2.1.4.1. Roles Scrum.

Para el adecuado desarrollo de software aplicando esta metodología, Schwaber y Sutherland, (2016) dentro de su guía Scrum, define tres roles: El Scrum master: su función se basa en asegurar que el equipo de desarrollo está adoptando la metodología, sus valores, normas y prácticas; es el líder del equipo pero no gestiona el desarrollo.

El dueño del producto (Product Owner): se trata de una sola persona (representa al

15

cliente del producto), se encarga de maximizar el valor del producto, gestionando la lista de funcionalidades requeridas, conocida como Product Backlog.

El equipo de desarrollo: es responsable de convertir lo que el cliente quiere, en iteraciones funcionales del producto; dentro del equipo de desarrollo todos sus miembros se encuentran en el mismo nivel y cargo, por lo tanto, carecen de jerarquías. Un tamaño aconsejable para este equipo está entre tres y nueve personas.

3.2.1.4.2. El Sprint.

Schwaber y Sutherland (2016) Se trata del acontecimiento principal dentro de la metodología Scrum, que corresponde a un periodo de tiempo (ver Figura 3) donde se realiza una versión funcional del producto. El proyecto puede estar compuestos por varios Sprint, donde cada uno de ellos es considerado como un trabajo independiente; cada una de estas iteraciones tiene una duración máxima de un mes. Un sprint está combinado de los siguientes elementos: 

Planeación del Sprint: se define, qué se va a entregar y cómo se logrará; a través del diseño del sistema y la estimación del trabajo.



Scrum diario: es una reunión de aproximadamente quince minutos del equipo de desarrollo, que se realiza cada día para explicar básicamente tres cosas: que se ha conseguido desde la última reunión, que se conseguirá hasta la siguiente y cuáles han sido los obstáculos que se han presentado.



Revisión del Sprint: esta reunión se da entre el dueño del producto y el equipo de desarrollo; al final de cada Sprint, con el objetivo de revisar lo que se hizo, lo que no, comentar los problemas encontrados y la manera en cómo fueron resueltos, discutir acerca del Product Backlog, etc. Finalmente, se enseña la iteración funcional del producto.



Retrospectiva del Sprint: es una reunión del equipo Scrum, por lo general de tres horas, que se realiza entre cada iteración para analizar el funcionamiento de la comunicación, el proceso y las herramientas empleadas en el Sprint anterior de cara a mejoras para el siguiente.

16

Figura 3. Fases de un Sprint. Recuperado de “Revisión de metodologías ágiles para el desarrollo de software” por Navarro, A., Fernández, J., & Morales, J, 2013, Prospect, 11(2), pp. 30-39.

3.2.1.4.3. Artefactos Scrum.

Dentro de Scrum Alliance, (2017) se las consideran herramientas esenciales para el porvenir del equipo de desarrollo, brindándoles dirección y transparencia. Los artefactos Scrum son: 

Product Backlog: el dueño del producto es el responsable de esta lista ordenada por valor, riesgo, prioridad y necesidad de los requisitos del proyecto. Una característica importante para esta lista es que nunca está terminada, pues el dueño debe actualizar y ordenar conforme el producto vaya evolucionando.



Sprint Backlog: es un subconjunto de tareas del Product Backlog (construido con los requisitos más prioritarios), éste artefacto pertenece a el equipo de desarrollo, quienes los construyen, aceptan y modifican si es necesario. Según la prioridad que tengan los requisitos adicionales, serán añadidos al Product Backlog, para ser desarrollados en el siguiente Sprint.



Monitoreo de Progreso (BurnDown): se trata de todo lo que falta por hacer en el Sprint, el dueño del producto podrá informarse sobre el progreso del desarrollo, y esto es posible debido a que los integrantes del equipo actualizan la información del estado de los requisitos que tienen asignados constantemente.



Incremento: es la suma de todas las tareas terminadas en el Sprint Backlog, si alguna falta por concluir deberá ser devuelta al Product Backlog, con prioridad

17

alta (será incluida en el siguiente Sprint).

3.2.2. Laboratorio Remoto.

Un Laboratorio Remoto es una herramienta que se encarga de controlar dispositivos (hardware) a través de un entorno Web (software), el hardware que se puede implementar es muy variado (ver Figura 4) aunque en la mayoría de los casos la arquitectura del laboratorio se centra en prácticas específicas. La implementación de un laboratorio remoto se da, en enseñanzas donde realizar prácticas con equipos físicos es muy significativo; además, ayuda a reducir costos en equipamiento y en las restricciones de tiempo que surgen al manipular los equipos por distintos usuarios (Bermúdez, Besada, López, Bonache & Cruz, 2015; Kalúz, Garcia-Zubia, Fikar & Čirka, 2015; Marchisio, Lerro & Von Pamel, 2011).

Figura 4. Diferentes tipos de arquitecturas de laboratorios remotos. Recuperado de “Design and implementation issues for modern remote laboratories” por Guimaraes, E. G., Cardozo, E., Moraes, D. H., & Coelho, P. R, 2011, IEEE Transactions on Learning Technologies, 4(2), pp. 149-161.

3.2.2.1.

Niveles de jerarquía.

De acuerdo con Rojas & Fagua, (2014) es necesario poseer al menos tres niveles de jerarquía en los laboratorios remotos para tener una correcta administración de los recursos de hardware y software: 

Nivel de usuario: da acceso al usuario a través de una interfaz amigable, muestra visualmente los entornos de trabajo, administra las prácticas, etc.



Gestión de prácticas: peticiones del cliente hacia el servidor, es la capa

18

intermedia entre el nivel de usuario y el procesamiento de prácticas. 

Procesamiento de prácticas: se encarga de la ejecución del ejercicio, a través de los parámetros dados por el usuario.

3.2.2.2.

Seguridad del laboratorio.

La seguridad del laboratorio remoto es un factor de suma importancia, debe consistir en la autentificación y autorización (ver Figura 5) del usuario hacia el laboratorio remoto, independientemente de si es una red privada o una red pública como por ejemplo Internet. En aplicaciones basadas en la Web, el usuario se autentificará a través de un servidor de aplicaciones que mantiene activa la sesión mediante el protocolo HTTP (protocolo de transferencia de hipertexto) y se hará una consulta a la base de datos para comprobar las credenciales válidas del usuario. La autorización va a depender en gran medida de los filtros implementados dentro del protocolo HTTP (Guimaraes, Cardozo, Moraes & Coelho, 2011).

Figura 5. Autentificación y autorización en un sistema web. Recuperado de “Design and implementation issues for modern remote laboratories” por Guimaraes, E. G., Cardozo, E., Moraes, D. H., & Coelho, P. R, 2011, IEEE Transactions on Learning Technologies, 4(2), pp. 149-161.

3.2.2.3.

RLMS.

En la actualidad existen distintas plataformas que resuelven el problema de desarrollar un Laboratorio Remoto, MIT iLab, Sahara y WebLab-Deusto son las más conocidas mundialmente y se las considera como RLMS (Remote Laboratory Management Systems), que son sistemas de gestión para el correcto funcionamiento de los laboratorios. Ellos proveen Application Programming Interfaces (APIs) para la conexión con sus laboratorios y para integrar o programar nuevas interfaces, obteniendo una escalabilidad muy beneficiosa

19

(Kalúz et al., 2014; Kalúz et al., 2015).

3.2.2.3.1. MIT iLab. iLabs creado por el MIT de Massachusetts, es el sistema de gestión de laboratorios remotos más extendido mundialmente, con diferentes iniciativas para compartir laboratorios de Europa, Asia y Estados Unidos. Dentro de la arquitectura compartida de iLabs se enmarcan los siguientes objetivos: 

Minimizar el esfuerzo de desarrollo y administración.



Proporcionar un conjunto de servicios y herramientas de desarrollo común.



Escalar a un gran número de usuarios en todo el mundo.



Permitir el acceso a múltiples universidades con distintas infraestructuras de red (mit iCampus, 2017).

3.2.2.3.2. LabShare Sahara.

Es una sistema de gestión de laboratorios remotos desarrollado por la Universidad Tecnológica de Sídney como parte del proyecto Labshare. Cuenta con un extenso catálogo de servicios centralizados para la comunidad de laboratorios remotos, con el objetivo de dar una solución tecnológica a la ciencia y a la educación de la ingeniería (Labshare, 2017).

3.2.2.3.3. WebLab-Deusto.

Es un RLMS de código abierto utilizado por los estudiantes de la Universidad de Deusto (España) desde febrero del 2005, como una herramienta esencial para sus prácticas de laboratorio en diferentes asignaturas relacionadas con la ingeniería. La experiencia de la utilización de los experimentos que tienen los alumnos es exactamente igual a la que obtendrían delante de un laboratorio tradicional (García-Zubia, 2009).

3.2.3. Arquitectura Cliente/Servidor.

De acuerdo con López, et al., (2012) este tipo de arquitectura se fundamenta en la idea de servicio, donde el cliente es el componente que consume servicios y el servidor se encarga de proveerlos. En este contexto, se puede ver en la Figura 6 su funcionamiento de manera clara y sencilla; el cliente realiza una petición y el servidor se encarga de atenderla y

20

despacharla. Dentro del entorno Web, los servicios que ofrecen suelen estar agrupados en capas que se diferencian por su funcionalidad; por lo general, existen 3 tipos de capas: capa de presentación (lo que el cliente ve), capa de negocio (gestiona las funcionalidades) y la capa de persistencia (donde residen los datos) (pp. 14-15).

Figura 6. El modelo cliente/servidor. Recuperado de “Desarrollo Web en Entorno Servidor” por López, M., Vara, J., Verde, J., Sánchez, D., Jiménez, J., & De Castro, V, 2012, Madrid: RA-MA Editorial.

Las tecnologías usadas tanto en el cliente como en el servidor son un factor muy importante para el laboratorio remoto (García-Zubia, Orduña, López-de-Ipiña & Alves, 2009). Según Rojas & Fagua (2014), la arquitectura cliente – servidor sirve como base para crear estos laboratorios; el cliente funciona como medio de acceso y el servidor se encarga de gestionar los componentes físicos.

3.2.3.1.

Frond-End.

3.2.3.1.1. HTML5 Y CSS3.

HTML (HyperText Markup Language) es un lenguaje de marcado de hipertexto, que permite presentar la información en forma de texto estructurado a través de etiquetas. Un documento HTML también puede contener elementos multimedia como por ejemplo, imágenes, sonido y vídeo. Éste lenguaje de marcado no debe ser confundido con un lenguaje de programación; carece de características propias de este tipo de lenguajes (flujos de control, operadores, funciones, variables, etc.) (Rubiales, 2013, p. 38).

HTML5 es la última versión de este lenguaje, y trae consigo muchas mejoras que facilitan el desarrollo, entre sus novedades cabe destacar la inserción de nuevas etiquetas, que definen una nueva estructura dentro del documento HTML. Se agregan nuevos controles y funcionalidades en los formularios, soporta de forma nativa el audio y vídeo (anteriormente

21

se necesitaba plugins), no tiene una sintaxis tan estricta como en sus primeras versiones y se elimina varias etiquetas que pierden su funcionalidad gracias a esta nueva versión (Rubiales, 2013, pp. 142-143).

CSS3 se trata de la última versión de las hojas de estilo en cascada, siendo un lenguaje de diseño dentro de una página Web, comprende la presentación, el aspecto y la posición que tendrán todos los elementos disponibles. El uso de las hojas de estilo se ha convertido en un componente esencial en la actualidad, debido a que permite separar completamente la presentación del contenido (Rubiales, 2013, p. 205).

3.2.3.1.2. JavaScript.

(Orós, 2013) JavaScript es un lenguaje de programación que fue creado por Netscape con el objetivo de integrarse en HTML y facilitar la creación de páginas dinámicas. El código, llamado script, se intercala directamente en el documento HTML y no es necesaria su compilación, ya que el propio navegador se encarga de interpretarlo, gracias a esta funcionalidad no existe la necesidad de acceder al servidor. JavaScript fue adoptado como un estándar de la ECMA (European Computer Manufacturers Association) con el nombre de ECMAScript y desde entonces han sido varias las revisiones publicadas de este lenguaje (p.

73).

3.2.3.2.

Back-End.

Popularmente, dentro del back-end se ejecutan lenguajes de scripting, también conocidos como lenguajes embebidos, debido a que se inserta dentro de un documento HTML, con el objetivo de convertir una página estática en dinámica, esto se logra a través de la ejecución de las líneas de código por parte del servidor, previo a la instalación de componentes necesarios para su funcionamiento (López et al., 2012).

3.2.3.2.1. PHP. PHP (acrónimo recursivo de PHP: Hypertext Preprocessor) Como se puede leer en su página oficial “es un lenguaje de código abierto muy popular especialmente adecuado para el desarrollo web y que puede ser incrustado en HTML” (PHP, 2017). Puede ser ejecutado en distintas plataformas sin ningún inconveniente, además se especifica como un lenguaje imperativo con la posibilidad de construir funciones orientadas a objetos. PHP es soportado por la gran mayoría de servidores Web.

22

3.2.3.2.2. Python.

Python es un lenguaje de programación de alto nivel creado por Guido van Rossum a principio de los años 90 cuyo nombre está inspirado en el grupo de cómicos ingleses Monty Python, que en los últimos tiempos ha ido ganando bastante popularidad, hasta el punto de ser uno de los lenguajes más utilizados por los desarrolladores de software. Según Fernández (2013) “se trata de un lenguaje potente, flexible y con una sintaxis clara y concisa. Además, no requiere dedicar tiempo a su compilación debido a que es interpretado” (p. 2). Python es de código abierto, por lo tanto no es necesario pagar ningún tipo de licencia para distribuir software desarrollado con este lenguaje; es multiplataforma y orientado a objetos (Python Software Foundation, 2017).

3.2.3.2.3. Comparativa de lenguajes.

A continuación se muestra una tabla comparativa entre los dos lenguajes de programación de scripting que se han detallado con anterioridad: Tabla 2 Comparativa entre PHP y Python Característica

[a]

Tipo de Software

Open – source

Open – source

Tipo de lenguaje

Interpretado

Interpretado

Plataforma de uso

Multiplataforma

Multiplataforma

Sintaxis

Parecida a C/Perl

Sintaxis limpia y sencilla

Propósito

Enfocado al desarrollo Web

Amplia cobertura de campos

PHP

[b] [c]

Python

Desarrollo Web Computación científica

Usabilidad

Desarrollo Web (back-end)

Aplicaciones GUI

Scripts en línea de comandos

Desarrollo de videojuegos

Aplicaciones de escritorios

Programación de red Administración de sistemas (GPIO Raspberry Pi)

Nota: [a] Adaptado de “PHP” por PHP Foundation, 31 de Octubre de 2017. Obtenido de php.net: http://php.net/manual/es/intro-whatis.php. [b] Adaptado de “Python 3 al descubierto (2ª ed.)” por Fernández, A., 2013, México: Alfaomega Grupo Editor. [c] Adaptado de “Raspberry Pi 3” por Raspberry Pi Foundation, 29 de Octubre de 2017.

Obtenido de https://www.raspberrypi.org/documentation/usage/python/

Se decide seleccionar el lenguaje de programación Python, principalmente por la fácil integración que tiene junto a la plataforma de Raspberry Pi, permitiéndole administrarla de

23

una manera sencilla, puesto que la gran mayoría de programas y librerías (GPIO) que usa este dispositivo se encuentran escritos en lenguaje Python. Además, otro factor influyente es su curva de aprendizaje y su sintaxis, otorgando una lectura y escritura de código limpia y fácil de entender.

3.2.4. Base de datos.

Una base de datos es un gran conjunto de información, que pertenece a un mismo contexto, el cual se encuentra almacenado de manera organizada en una estructura conocida como tabla (filas y columnas); estas tablas se encuentran relacionadas con el fin de mantener la información ordenada y sin contradicciones. En gran medida, una base de datos se encarga de guardar, manejar y recuperar información que es requerida por los sistemas computarizados y por ello son tan necesarias en la actualidad (López, Castellano, & Ospino, 2014, p. 6).

3.2.4.1.

Sistema de administración de base de datos.

Un sistema de administración de bases de datos (DBMS, por sus siglas en inglés) es un conjunto de programas que se encargan de manejar la creación y todos los accesos a las bases de datos. La función del DBMS es la de servir como intermediario entre el usuario y la base de datos, gracias a él se oculta gran parte de los procesos internos que genera la comunicación de la aplicación del usuario con sus datos (Coronel, Morris, & Rob, 2011, p.

7).

3.2.4.1.1. MariaDB. MariaDB es una base de datos relacional, que entre sus características destaca, su robustez, rapidez, escalabilidad; y debido a su variedad de herramientas la convierte en un instrumento muy versátil. MariaDB es desarrollado como software de código abierto a partir del 2009, por los creadores originales de MySQL (tras el descontento de éstos por el modelo de negocio de MySQL), por lo que mantiene las mismas estructuras que ésta. Actualmente, se considera como una de las bases de datos más usadas (MariaDB Foundation, 2017).

24

3.2.4.1.2. PostgreSQL. PostgreSQL es un poderoso sistema de base de datos multiplataforma, de tipo objetorelacional, código abierto con más de 15 años de experiencia en desarrollo de proyectos, centrado en la confiabilidad e integridad de los datos que maneja. Es totalmente compatible con ACID, tiene soporte completo para claves foráneas, vistas, disparadores, procedimientos almacenados, etc. PostgreSQL utiliza herramientas útiles como por ejemplo ORM (Mapeo Objeto-Relacional) que sirve como intermediario entre el modelo orientado a objetos y la base de datos (PostgreSQL, 2017).

3.2.4.1.3. SQLite.

Es un sistema de base de datos de tipo modelo relacional, multiplataforma de código abierto. A diferencia del resto de base de datos SQL, este sistema no maneja el proceso del servidor por separado, es decir, tiene el motor embebido, permitiéndole leer y escribir directamente en los archivos de disco normal, con el consecuente de poder realizar consultas con mayor rapidez. SQLite es muy completo, con diversidad de tablas, disparadores, índices y vistas que se encuentran contenidos en un solo archivo de disco (SQLite, 2017).

3.2.4.1.4. Comparativas entre bases de datos.

Mediante el análisis de comparativa entre las distintas bases de datos expuestas, se pretende seleccionar una de ellas para el desarrollo, las cuales son: Tabla 3 Comparativa entre bases de datos Característica

[a]

Tipo de Software

Open – source

Open – source

Open – source

Plataforma

Multiplataforma

Multiplataforma

Multiplataforma

Tipo de BD

Relacional

Relacional

Relacional

Propiedades ACID

Determinados motores

Si

Si

Si

Si

No

Media

Alta

Alta

Escritura simultánea Eficiencia en Raspberry Pi

MariaDB

[b] [c]

PostgreSQL

[d]

SQLite

Nota: [a] Adaptado de “MariaDB” por MariaDB Foundation, 2 de Noviembre de 2017. Obtenido de mariadb.org: https://mariadb.org/about/ [b] Adaptado de “PosgreSQL” por PostgreSQL.org, 2 de Noviembre de 2017. Obtenido de postgresql.org: https://www.postgresql.org/about/ [c] Adaptado de “Raspberry PG” por Broccolo, G., 29 de Octubre de 2017.

Obtenido de http://raspberrypg.org/index.html@p=82.html. [d] Adaptado de “SQLite.org” por SQLite., 2 de Noviembre de 2017. Obtenido de sqlite.org: https://www.sqlite.org/about.html

25

Finalmente, se opta por PostgreSQL dado que provee una base de datos robusta, estable y potente. Además, puede integrarse eficientemente con la microcomputadora Raspberry Pi, permite una escritura de datos simultánea, es decir, la interacción de varios usuarios con la base de datos sin que afecte a la integridad de la misma.

3.2.5. Hardware.

3.2.5.1.

Arduino Uno.

Arduino UNO (ver Figura 7) es una placa microcontroladora de código abierto, que puede ser utilizada para interactuar con el mundo a través de sus entradas y salidas (Sobota, PiŜl, Balda & Schlegel, 2013). Esta microcontroladora cuenta con 14 pines de entradas o salidas digitales y 6 de estas pueden utilizarse para trabajar en modo PWM, para sustituir señales analógicas. Todos los pines digitales tienen 8 bits, por lo tanto pueden representar señales en un rango de números enteros de 0-255 o un voltaje de 0-5V. Arduino UNO también incluye 6 pines de entrada analógica, que emplean 10 bits (0-1023 o 0-5V). La gran ventaja de Arduino es precisamente que permite trabajar tanto con señales digitales como analógicas, haciendo que pueda conectarse con cualquier dispositivo electrónico que opere entre 0-5V (Kalúz et al., 2014).

Figura 7. Arduino UNO, vista superior. Recuperado de “Arduino Uno Rev” por Arduino, 29 de Octubre de 2017. Obtenido de https://store.arduino.cc/usa/arduino-uno-rev3

3.2.5.2.

Arduino Mega 2560.

Se basa en el microcontrolador ATmega 2560, posee 54 pines de entrada/salida digitales, pudiendo 15 de ellos ser utilizados como salidas analógicas PWM. Además, cuenta con 16 entradas analógicas, 4 UARTs (puertos seriales transmisión/recepción), memoria

26

Flash de 256 Kbytes, memoria SRAM de 8 KB, EEPROM de 4 KB. Esta placa tiene un voltaje de funcionamiento de 5V, siendo igual que su hermano pequeño el Arduino UNO (Torrente, 2013).

Mega 2560 (ver Figura 8) es open-source y está diseñado para proyectos más complejos, gracias a su gran cantidad de pines I/O y un mayor almacenamiento para los sketch. Este Arduino incorpora todo lo necesario para que el microcontrolador trabaje, solo es necesario conectarlo al PC o a una fuente de alimentación externa (9 hasta 12V en DC) para que empieze a trabajar.

Figura 8. Arduino Mega 2560, vista superior. Recuperado de “Arduino Mega 2560 Rev” por Arduino, 29 de Octubre de 2017. Obtenido de https:// store.arduino.cc/usa/arduino-mega-2560-rev3

3.2.5.3.

Comparativa entre microcontroladores.

Tabla 4 Comparativa de Arduino Característica

[a]

Tipo de microcontrolador

Atmega 328

Atmega 2560

Velocidad de reloj

16 MHz

16 MHz

Pines digitales E/S

14

54

Entradas analógicas

6

16

Memoria Flash

32 Kb

256 Kb

Memoria de datos (SRAM)

2 Kb

8 Kb

UNO

[b]

Mega 2560

Nota: Adaptado de “Arduino Uno Rev” por Arduino, 29 de Octubre de 2017. Obtenido de https://store.arduino.cc/usa/arduino-uno-rev3. [b] Adaptado de “Arduino Mega 2560 Rev” por Arduino, 29 de Octubre [a]

de 2017. Obtenido de https://store.arduino.cc/usa/arduino-mega-2560-rev3rduino.

27

En este caso, el factor determinante es el número de pines de entrada/salida disponibles, ya que en un principio, se pretende utilizar como mínimo 16 pines digitales; es evidente que se descarta al Arduino UNO (solo cuenta con 14 pines) y se decide trabajar con Arduino Mega 2560 que cumple de sobra con ese requisito.

3.2.5.4.

Raspberry Pi 3.

Raspberry Pi es un microcomputador del tamaño de una cédula de identidad (ver Figura 9) desarrollado en el Reino Unido por la Fundación Raspberry Pi, este dispositivo es capaz de hacer correr casi cualquier aplicación como si de una computadora normal se tratase. Todo esto lo consigue gracias a un chip Broadcom BCM2837 64bit CPU, que incluye un procesador Quad Core a 1.2GHz, además cuenta con 1 GB de RAM. La Raspberry Pi no incluye disco duro, sino que utiliza una tarjeta SD para el arranque y el almacenamiento de los datos permanentes. Además, trae incorporado un conector Ethernet para conectarlo a la red cableada, conectores USB y 40 pines GPIO para entradas y salidas digitales (Raspberry Pi Foundation, 2017).

Varios sistemas operativos pueden ser instalados fácilmente en este micro computador, resultando Rasbian (una versión optimizada de Debian Linux) como el más utilizado; viene integrado con herramientas de desarrollo que utilizan Python como lenguaje de programación. El objetivo de Raspberry Pi es ofrecer dos versiones, con precios que van desde 35 dólares la más económica a 60 dólares la opción superior (Sobota et al., 2013).

Figura 9. Raspberry Pi 3 model B. Recuperado de “Raspberry Pi 3 model B” por Raspberry Pi Foundation, 29 de Octubre de 2017. Obtenido de https:// www.raspberrypi.org/products/raspberry-pi-3-model-b/

28

3.2.5.5.

Beaglebone Black.

Es un microcomputador considerado como plataforma de desarrollo de bajo costo ideal para desarrolladores y entusiastas. Dentro de sus especificaciones técnicas cuenta con un microprocesador AM335x a 1GHz, basado en un procesador ARM Cortex-A8, memoria RAM de 512MB DDR3, tiene puertos de conexiones para: HDMI, Ethernet, USB, 92 pines GPIO. Beaglebone (ver Figura 10), a la hora de trabajar con software, es compatible con diversos sistemas operativos entre los que cabe destacar; algunas distribuciones de Linux (Debian, Ubuntu), Android, Cloud9 y varias más (Beaglebone Black, 2017).

Figura 10. Beaglebone Black, vista superior. Recuperado de “BeagleBone-Black” por BeagleBone, 2 de Noviembre de 2017.

Obtenido de beaglebone.org:http://beagleboard.org/black

3.2.5.6.

Comparativa entre microcomputadores.

Tabla 5 Comparativa de microcomputadores Característica

[a]

Raspberry Pi 3

[b]

BeagleBone Black

1.2GHz 64-bit quad-core

AM335X 1GHz ARM Cortex-

ARMV8 CPU

A8

RAM

1GB DDR3

512MB DDR3

USB

4

1

WIFI

Si

No

Pines GPIO

40

92

Precio

$35 aprox.

$55 aprox.

Comunidad de apoyo

Extensa comunidad

Mínima comunidad

Procesador

Nota: [a] Adaptado de “Raspberry Pi 3 model B” por Raspberry Pi Foundation, 29 de Octubre de 2017. Obtenido

de https://www.raspberrypi.org/products/raspberry-pi-3-model-b/ [b] Adaptado de “BeagleBone-Black” por BeagleBone, 2 de Noviembre de 2017. Obtenido de beaglebone.org:http://beagleboard.org/black

29

Raspberry Pi 3 es el dispositivo elegido para desarrollar el producto. En primer lugar, cuenta con una gran comunidad que lo respalda (foros, guías, etc.), por tanto se puede acudir a ellos en caso de cualquier duda o problema. En segundo lugar, posee mayores recursos de hardware en comparación con BeagleBone Black, dando un margen de maniobra mayor en lo que prestación se refiere. Y por último, el precio es mucho más asequible que el de su competidora, de esta manera se reduce en los costos totales del producto.

3.2.6. Metodología de enseñanza práctica.

3.2.6.1.

El aprendizaje.

El aprendizaje forma parte del proceso natural del individuo a lo largo de su vida, se cimienta sobre lo que conoce o puede hacer y se va edificando de forma interactiva para lograr el máximo potencial del individuo. Es acertado decir que el aprendizaje se da día a día y esta idea es acentuada por la siguiente cita de López (2013) “La vida misma consiste en un aprendizaje permanente: el aprendizaje a lo largo de nuestra existencia es parte de nuestra cotidianidad” (p.2).

3.2.6.1.1. Nuevas formas de aprendizaje.

Atrás quedó el aprendizaje de memorización, cuya función no era más que repetir y repetir cierto contenido hasta almacenarlo en la memoria. Ahora, gracias a las Tecnologías de la Información y Comunicación (TIC), han aparecido nuevas formas de obtener, guardar y compartir información provocando grandes cambios en la educación, que requieren nuevas formas de afrontar la realidad y de construir nuevos saberes. Con la aparición de nuevas estrategias de aprendizaje se consigue una formación integral del estudiante (López, 2013, p.

3).

3.2.6.1.2. Formación integral.

Una formación integral debe contemplar lo que es esencial para el desarrollo humano y el éxito profesional; los programas deben estar definidos de forma que faciliten la evaluación y el reconocimiento de lo aprendido. En el plan pedagógico, la accesibilidad de traduce como la búsqueda de una mejor adaptación de la enseñanza a los alumnos, así como la selección juiciosa de los métodos, actividades, material didáctico y medios de evaluación. El resultado de la formación integral es el desempeño profesional ético y eficiente, en el que se integran conocimientos,

30

habilidades, capacidades y actitudes (saber, saber hacer, saber ser) que, mediante la acción permiten construir las competencias. (Medina & Barquero, 2013, p. 50) 3.2.6.2.

Enfoque constructivista.

Tiene sus raíces en la filosofía, psicología, sociología y educación. La idea central es que el aprendizaje humano se construye, que la mente de las personas elabora nuevos conocimientos a partir de enseñanzas anteriores. Este aprendizaje, en la persona debe ser activo, participando en actividades que promuevan la instrucción, todo lo contrario al aprendizaje pasivo, donde el individuo es un mero objeto que permanece sentado observando lo que se le explica (Hernández, 2008).

3.2.6.2.1. Constructivismo.

El constructivismo se basa en la construcción propia del conocimiento, mediante experiencias adquiridas del aprendizaje constructivista utilizando herramientas tecnológicas en el proceso. Estas herramientas sirven de soporte a la hora de realizar actividades innovadoras dentro del aula, y convierten al alumno en el actor principal; mientras que el profesor pasa a un segundo plano, resolviendo dudas o problemas que puedan presentarse (Hernández, 2008).

3.2.6.3.

ABP (Aprendizaje Basado en Problemas).

“El Aprendizaje Basado en Problemas (ABP), es una metodología de enseñanza y aprendizaje que utiliza planteamientos de situaciones o escenarios en un contexto cercano a la realidad (problemas)” (Rivera & Turizo, 2015, p. 2).

El propósito del uso de esta metodología es que el alumno, a partir de su propia experiencia, sea capaz de abstraer las ideas más importantes de algún problema en concreto y las pueda emplear en la resolución de actividades parecidas. Con ello se favorece a la construcción del conocimiento por parte del alumno cumpliendo con las metas de aprendizaje.

3.2.6.4.

Educación STEM.

El término educación STEM (Science, Technology, Engineering and Mathematics), se refiere a la enseñanza y aprendizaje en los campos de la ciencia, tecnología, ingeniería y las matemáticas. Por lo general, incluye actividades educacionales desde la educación primaria

31

hasta la educación superior (Gonzalez & Kuenzy, 2012, p. 1).

La formación STEM, combina las cuatro áreas creando un enfoque interdisciplinario de manera ilustrativa que ayuda en el aprendizaje de matemáticas y ciencia. El componente de ingeniería hace énfasis en el proceso y el diseño de soluciones. Esta técnica logra que el estudiante investigue, junto con las matemáticas y la ciencia, de una manera más personalizada, ayudándolo a desarrollar su pensamiento crítico. El cuarto factor, el tecnológico, facilita el entendimiento de las tres áreas anteriores, ayudando a los estudiantes a poner sus conocimientos en práctica a través de la tecnología.

3.2.6.4.1. Importancia de la educación STEM. Con las habilidades STEM se pretende desarrollar el emprendimiento, la innovación y la competitividad, básicos dentro de la economía actual, con el fin de mejorar la inserción laboral en esta sociedad cada vez más avanzada tecnológicamente. De acuerdo a la nota escrita por la redactora Elena Paucar en el diario El Comercio “Los cambios previstos en la economía y el mercado laboral en los próximos 10 años afectarán a la demanda de profesionales STEM, que va a crecer en mayor medida que la de profesionales de otros sectores” (Paucar, 2014).

Un gran ejemplo de ello es la Fundación Telefónica que cree en la gran importancia que tiene esta herramienta, gracias a su enfoque de integración de conocimientos, que brindan a los alumnos la oportunidad de desplegar las competencias necesarias en los retos actuales, como el trabajo en la resolución de problemas, que posibilita el desarrollo del pensamiento crítico dentro de la ciencia y la tecnología. La educación STEM es una manera de preparación para los nuevos retos que vendrán en un futuro próximo y es primordial, el saber cómo enfrentarlos (Fundación Telefónica, 2017).

3.2.6.5.

Laboratorio remoto como recurso didáctico.

Un laboratorio remoto es un recurso valioso desde la perspectiva didáctica, se puede distinguir su potencial para constituirse en una herramienta útil para el aprendizaje y la formación científica tecnológica de los futuros ingenieros. Mediante el desarrollo de prácticas con este tipo de laboratorios, el estudiante, opera dispositivos reales remotamente guiándose por un interfaz, permitiendo la experimentación simultánea de grupos de alumnos con un mismo equipamiento.

32

4. METODOLOGÍA DE LA INVESTIGACIÓN 4.1. Enfoque / Tipo de Investigación 4.1.1. Enfoque de la investigación.

Para el desarrollo del presente proyecto se pretende trabajar con un enfoque mixto, el cual Hernández, Fernández, & Baptista (2014) lo definen como “un conjunto de procesos sistemáticos, empíricos y críticos de investigación e implican la recolección y el análisis de datos cuantitativos y cualitativos” (p. 534). La finalidad de la investigación, es analizar cada uno de los aspectos que engloban tanto el enfoque cuantitativo (mediante el análisis estadístico de los datos recogidos a los estudiantes de la carrera de Sistemas) y el enfoque cualitativo (a través del análisis situacional dentro de la enseñanza práctica en las materias afines a la electrónica).

4.1.2. Tipo de investigación.

4.1.2.1.

Investigación documental.

Según Casares Hernández, et al. citado por Bernal (2010), este tipo de investigación depende en mayor medida de la información que se obtiene a través de la revisión de documentos, entendiéndo a éstos como el material utilizado como fuente de referencia, dando testimonio a una realidad (p. 111).

Para ello, se cuenta con una amplia revisión de distinto material bibliográfico, como es el caso de libros (físicos y virtuales), actas de conferencia, artículos científicos, sitios de internet (páginas de documentación de herramientas de software y hardware), etc.

4.1.2.2.

Investigación de campo.

La investigación de campo es muy necesaria en cualquier proyecto, en este caso se realizan salidas tanto para la elaboración de las encuestas a los estudiantes de la universidad, como para recoger las funcionalidades y procesos que va a tener el laboratorio remoto y de esta manera llevar un correcto desarrollo de la aplicación.

4.1.2.3.

Investigación descriptiva.

La investigación descriptiva según expertos, es un nivel básico de investigación que

33

crea una base para otros tipos de investigación. Una de las funciones principales de este tipo de investigación la contempla Bernal (2010), diciendo que “es la capacidad para seleccionar las características fundamentales del objeto de estudio y su descripción detallada de las partes, categorías o clases de ese objeto” (p. 113). Es inherente, que con esta investigación se pretende especificar las características y propiedades destacadas del objeto de estudio.

4.1.2.4.

Investigación aplicada.

La investigación aplicada tiene por objeto la generación de conocimiento con aplicación directa a los problemas de la sociedad, teniendo esto como premisa se enmarca como objetivo la implementación del laboratorio remoto Arduino para realizar prácticas de electrónica dentro de la Escuela de Sistemas.

4.2. Población / Muestra “La población es el conjunto de todos los elementos a los cuales se refiere la investigación. Se puede definir también como el conjunto de todas las unidades de muestreo” (Bernal, 2010, p. 160). En este contexto, la población a estudiar son todos los estudiantes de la Escuela de Sistemas a partir del quinto nivel de la PUCE SD; se decide trabajar exclusivamente con estos estudiantes porque el modelo de la encuesta se aplica sobre la asignatura Diseño de lenguajes y autómatas, la cual se cursa en el quinto nivel de la carrera; la Tabla 6 muestra el número de estudiantes por semestre que suman un total de 50 alumnos.

Además, se incluye dentro de la población el docente afin a las materias de electrónica, sumando un total de 51 personas como cantidad total.

Tabla 6 Estudiantes de la Escuela de Sistemas a partir de quinto semestre Semestre

Frecuencia

Quinto

9

Sexto

10

Séptimo

8

Octavo

12

Noveno

11

Total

50

Nota: Fuente: Investigación de campo.

34

4.2.1. Muestra.

Al contar con una población menor a 100 personas, que es un valor poco significativo, no resulta necesario realizar una muestra; por lo tanto se decide trabajar directamente con el total de la población.

4.3. Técnicas e Instrumentos de Recogida de Datos En esta investigación se hace uso de la encuesta y la entrevista que son dos instrumentos muy conocidos a la hora de recolectar datos, tanto cuantitativos como cualitativos. El primero de ellos, Bernal (2010) lo fundamenta como: “un cuestionario o conjunto de preguntas que se preparan con el propósito de obtener información de las personas” (p. 194). Dado que se necesita conseguir información que sustente la investigación, se prepara una encuesta, formada por preguntas cerradas, que se realizará a los estudiantes de la Escuela de Sistemas a partir de quinto semestre seleccionados como muestra.

Así mismo Bernal (2010) define la entrevista como “técnica orientada a establecer contacto directo con las personas que se consideren fuente de información” (p. 191). Esta es utilizada como un instrumento para recoger información mediante preguntas abiertas al docente de electrónica, de la Escuela de Sistemas, referente a los procesos que se aplican en la enseñanza práctica de la materia. También se va a realizar varias reuniones con el docente teniendo como objetivo, recoger las funcionalidades que va a tener el laboratorio remoto, puesto que el mismo profesor es el dueño del producto dentro de la metodología Scrum.

4.4. Técnicas de Análisis de Datos En el presente proyecto se tiene una perspectiva de análisis estadístico, por consiguiente, se elabora una base de datos en el programa estadístico de ciencias sociales (SPSS) para la tabulación y el análisis de los datos, aplicando tablas de contingencia en algunas preguntas y tablas de frecuencia en otras. Además se va a servir del software Excel para la realización de las figuras de cada tabla, para representar de una manera más clara los resultados obtenidos.

35

4.5. Metodología de Desarrollo de Software 4.5.1. Diferencias entre Scrum y XP. Tabla 7 Diferencias entre Scrum y XP [a]

Scrum

[b]

XP

Iteraciones de entrega de dos a cuatro semanas

Iteraciones de entrega de una a tres semanas

Las tareas terminadas no se modifican

Las tareas terminadas son susceptibles a cambios

Cada miembro del equipo trabaja individualmente

Los miembros programan en parejas

Se puede modificar el orden de desarrollo de las

Se sigue estrictamente el orden de prioridad de las

tareas

tareas

Enfocado a desarrollo de proyectos

Centrado en la programación del producto

Nota: [a] Adaptado de “Scrum y XP desde las trincheras” por Kniberg, H, 2007, C4Media Inc. InfoQ. [b] Adaptado de “La guía Scrum” por Schwaber, K., & Sutherland, J, 2016. Obtenido de https://www.scrumguides.org/docs/scrumguide/v2016/ 2016-Scrum-Guide-Spanish-European.pdf

Al analizar las diferencias más destacables entre las dos metodologías de desarrollo de software, se opta por elegir a Scrum como método para desplegar el producto de esta investigación. En primer lugar, se prefiere Scrum porque las tareas no pueden ser modificadas una vez concluidas; si fuera lo contrario, resultaría molesto para el trabajo del desarrollador y hasta podría retrasar los plazos de entrega de cada iteración. En segundo lugar, XP dentro de su etapa de codificación obliga a trabajar en parejas, algo que no es posible puesto que este proyecto lo realiza una sola persona. Por último, Scrum es una metodología centrada al desarrollo de proyectos y no solamente al desarrollo de software como tal; este factor se considera como el más importante ya que la investigación se centra en la integración de software junto con el hardware para crear el laboratorio remoto Arduino.

4.5.2. El proceso Scrum.

El proceso Scrum básicamente está construido por todo lo que comprende la realización de una iteración (Sprint), en la que cada una de ellas va a constar de 4 semanas de trabajo. Cada uno de estos Sprint va a entregar un avance del producto totalmente funcional al cliente, que en este caso se trata del docente, para ello se va a llevar a cabo las actividades que se describen a continuación.

36

4.5.2.1.

Planificación del Sprint.

El punto de partida según la metodología Scrum, es el Product Backlog, donde el docente presenta la lista priorizada de requisitos necesarios para la construcción del laboratorio remoto Arduino, y el desarrollador (el equipo) pregunta sobre las posibles dudas que pueden surgir, recogiendo finalmente las Historias de Usuario a ser desarrolladas en el primer Sprint.

4.5.2.1.1. Plan de Release.

Cuando se establece el Product Backlog, el equipo se reúne para definir el plan de trabajo: qué se va a entregar y cómo se logrará, es decir, el diseño del sistema y la estimación tanto de la cantidad de trabajo como la estimación real de las historias de usuario y sus respectivas tareas a través de la serie Fibonacci. Finalmente, todo ello se recoge en el Sprint Backlog, puntualizando un objetivo alcanzable al terminar el Sprint.

4.5.2.2.

Ejecución del Sprint.

En esta etapa, es donde se efectúa el desarrollo del proyecto como tal; durando 4 semanas como se mencionaba con anterioridad, en donde cada día se lleva a cabo una reunión corta de 15 minutos para conocer la situación actual y el avance que se tiene en el proyecto.

Dentro del Sprint se realizan actividades propias de las metodologías ágiles como: elaborar, integrar, revisar y ajustar el proyecto de desarrollo.

4.5.2.3.

Revisión del Sprint.

Es una reunión que se realiza justo al final de cada Sprint, el equipo presenta al docente los requisitos completados en el Sprint, es decir, el incremento funcional del producto, donde se evalúa para ver si cumple con lo requerido por parte del docente, de no ser el caso pasaría a formar parte de un nuevo ítem dentro del Product Backlog.

4.5.2.4.

Retrospectiva del Sprint.

En esta fase, el equipo se encarga de analizar su manera de trabajo y los posibles problemas que se podría tener a la hora de continuar con los siguientes Sprint; esta es una reunión que ayudara al desarrollador a mejorar de manera continua su productividad a la hora de trabajar en el proyecto.

37

5. RESULTADOS 5.1. Discusión y Análisis de los Resultados 5.1.1. Resultados de la entrevista.

La entrevista (Ver Anexo 4) ha sido realizada al docente de la Escuela de Sistema, el Mg. Jon Azcona, que es el encargado de impartir las materias afines a la electrónica dentro de la malla curricular de la carrera. Los resultados obtenidos se muestran a continuación: Pregunta 1: ¿Cómo se da el proceso de enseñanza práctica en sus asignaturas?

Respuesta: Se aplica la metodología STEM (acrónimo de Science, Technology, Engineering and Mathematics), primero se imparten los conocimientos teóricos, luego se realizan ejercicios en la pizarra y finalmente se intenta hacer prácticas en un simulador por la ausencia de un laboratorio especializado para electrónica.

Pregunta 2: En general, ¿cuál es el nivel de desempeño de sus estudiantes respecto a las materias que imparte?

Respuesta: Cuando la enseñanza era sólo teoría, el desempeño era muy bajo, los estudiantes se centraban en aprender solo los ejercicios; al introducir el simulador, las calificaciones subieron un poco pero al no implicarse tan directamente con la manipulación del hardware, esto no es tan notorio.

Pregunta 3: ¿Cree en la necesidad de cambiar el esquema de enseñanza práctica en sus materias?

Respuesta: Si, tratar de tener una herramienta para que los estudiantes se impliquen en la asignatura.

Pregunta 4: ¿Por qué es tan importante el ensayo práctico dentro de la electrónica?

Respuesta: Tiene que ver con una ingeniería, por tanto sus asignaturas están enfocadas a la práctica y si los estudiantes no las realizan, luego en el desempeño laboral tienen deficiencias.

Pregunta 5: ¿Piensa usted que una herramienta como el laboratorio remoto Arduino,

38

ayudará a comprender mejor la temática impartida?

Respuesta: Sí, totalmente de acuerdo.

Pregunta 6: ¿Cuáles cree que serán los resultados que reflejen sus estudiantes una vez implementado el laboratorio remoto Arduino?

Respuesta: Se espera que las calificaciones de los alumnos mejoren y no tengan dificultades en emprender proyectos que relacionen a la electrónica dentro de la informática.

Pregunta 7: ¿Considera la posibilidad de que el laboratorio remoto Arduino pueda ser escalable para otras materias?

Respuesta: Sí, todas las asignaturas que tengan prácticas que requieran de una computación física, son perfectamente aplicables.

Pregunta 8: ¿Cree que el laboratorio remoto Arduino debería estar disponible 24/7?

Respuesta: Si la PUCE SD tiene la posibilidad de almacenar el laboratorio en la nube sería lo ideal.

5.1.1.1.

Discusión de los resultados de la entrevista.

Pese a que el docente aplica la metodología de enseñanza STEM en sus estudiantes, en el cual trata de vincular toda la teoría junto con actividades prácticas (simulador) para que las asignaturas sean más llevaderas para sus alumnos, el desempeño estudiantil no es tan bueno como debería ser. Por tanto se ve en la necesidad de buscar una herramienta que pueda suplir esas deficiencias que arrastran los estudiantes, que a la postre les servirá a lo largo de su vida profesional; dicho instrumento es el que se propone en este trabajo de titulación “laboratorio remoto Arduino”, que se espera sirva como un gran apoyo práctico; viéndose reflejado los resultados en las calificaciones positivas de los alumnos y animándoles a que puedan emprender proyectos innovadores que integren a la informática con la electrónica.

Existe la posibilidad que el laboratorio remoto Arduino pueda ser utilizado en otras asignaturas, que utilicen la programación como parte de sus prácticas y de este modo, conseguir extender su campo de acción. Otro factor de suma importancia, es la disponibilidad de este laboratorio remoto, que no solo se centraría a los horarios de clases, sino que pueda estar operativo las 24 horas del día, permitiendo a los estudiantes ingresar desde sus hogares

39

y continuar efectuando sus actividades prácticas.

5.1.2. Resultados de las encuestas.

Las encuestas fueron aplicadas a los estudiantes a partir del quinto semestre de la Escuela de Sistemas de la PUCE SD, el formato de dicho documento se encuentra en el Anexo 5. Para realizar de manera correcta las encuestas se ha tomado como referencia la materia de Diseño de lenguajes y autómatas, que se engloba dentro de las materias en las que se trabaja la electrónica como base. Además, la encuesta consta de dos partes: las primeras seis preguntas fueron dirigidas a toda la población de estudiantes y las cuatro últimas solo fueron contestadas por los alumnos que respondieron a la tercera opción dentro de la primera pregunta, es decir, al modelo didáctico Teórico-Simulador-Proyecto Arduino; esto se ha realizado con el objetivo de determinar otros factores como por ejemplo: el económico. A continuación se muestran los resultados que se han podido apreciar: Pregunta 1: ¿Cómo es/fue el modelo didáctico en la asignatura de Diseño de lenguajes y autómatas?

Tabla 8 Modelo didáctico en la asignatura de Diseño de lenguajes y autómatas

[a]

Modelo didáctico

Frecuencia

Porcentaje

Teórico

7

14,0%

Teórico-Simulador

26

52,0%

17

34,0%

50

100,0%

Teórico-Simulador-Proyecto Arduino Total

Nota: [a] Los estudiantes que eligieron este modelo didáctico se encuentran cursando actualmente quinto y sexto semestre.

Fuente: Investigación de campo

40

Figura 11. Modelo didáctico en la asignatura de Diseño de lenguajes y autómatas.

Fuente: Investigación de campo

Análisis e Interpretación: De acuerdo a la información que entrega la tabla 8, se puede apreciar que los alumnos que estudiaron solo teoría en la asignatura constituye un 14%, puesto que este modelo se ha dejado de impartir hace ya varios años, quedando unos pocos estudiantes (antiguos) con esta guía. Una gran porcentaje (52%) corresponde al modelo teórico-simulador, donde se introdujo el software de experimentación con autómatas JFLAP para realizar prácticas en el periodo 2015-01; allí los alumnos combinaban teoría y práctica aunque solo fuera a través de una computadora. Por último, el 34% corresponde al modelo teórico-simulador-proyecto Arduino, implantado en el periodo 2017-01, este modelo es el que se usa en la actualidad, por lo que se prevé que este porcentaje crezca a futuro. A través del estudio de clústers (clasificación de los tres modelos didácticos) servirán como base para relacionar las respuestas que se analizan en las preguntas posteriores.

41

Pregunta 2: ¿Cuál es/fue el nivel de interés que ha demostrado por la asignatura?

Tabla 9 Relación del nivel de interés con el modelo didáctico cursado Modelo didáctico Nivel de interés

Muy interesado Algo interesado Nada interesado Total

Teórico

T-Simulador

T-S- Arduino

Recuento

0

5

10

Porcentaje Recuento Porcentaje Recuento Porcentaje Recuento

0,0% 3 42,9% 4 57,1% 7

19,2% 15 57,7% 6 23,1% 26

58,8% 7 41,2% 0 0,0% 17

Porcentaje

100,0%

100,0%

100,0%

Nota: Fuente: Investigación de campo.

Figura 12. Relación del nivel de interés con el modelo didáctico cursado.

Fuente: Investigación de campo.

Análisis e Interpretación: En la figura 12, se puede apreciar con claridad el nivel de interés que demuestran o han demostrado los alumnos de la materia conforme se ha ido adaptando los distintos modelos. En el modelo teórico lo que más predomina es el “nada interesado” con un 57,1%; en cambio los alumnos que trabajaron con el simulador en sus prácticas fueron interesándose un poco más por la asignatura hasta alcanzar un nivel intermedio, sobresaliendo el 57,7% en “algo interesado”. Sin embargo, en el modelo número tres, se puede apreciar cómo ha aumentado el interés de los estudiantes por Diseño de lenguajes y autómatas, desapareciendo por completo el “nada interesado” del modelo tres, y subiendo notablemente el interés de los estudiantes por la materia a través del apoyo del simulador y el proyecto Arduino.

42

Pregunta 3: ¿Cómo considera que son/fueron las actividades prácticas de esta materia?

Tabla 10 Relación de las actividades prácticas con el modelo didáctico cursado Modelo didáctico Actividades prácticas

Muy interesantes Algo interesantes Nada interesantes Total

Teórico

T-Simulador

T-S-Arduino

Recuento

0

6

12

Porcentaje Recuento Porcentaje Recuento

0,0% 1 14,3% 6

23,1% 14 53,8% 6

70,6% 5 29,4% 0

Porcentaje Recuento

85,7% 7

23,1% 26

0,0% 17

Porcentaje

100,0%

100,0%

100,0%

Nota: Fuente: Investigación de campo.

Figura 13. Relación de las actividades prácticas con el modelo didáctico cursado.

Fuente: Investigación de campo.

Análisis e Interpretación: La figura 13 deja en evidencia como la gran mayoría de la población del modelo teórico encuentran “nada interesantes” las actividades prácticas de la asignatura, esto es lógico debido a la poca práctica que se realizaba; al adaptar el modelo con simulador los resultados mejoran considerablemente respecto al primer modelo. Al introducir dentro del modelo didáctico el proyecto Arduino se puede ver como la experimentación práctica se vuelve muy interesante, ya que éstas prácticas se convierten en entretenidas al interactuar directamente con el hardware.

43

Pregunta 4: ¿Cuál es/fue el nivel de desempeño en la asignatura Diseño de lenguajes y autómatas?

Tabla 11 Relación del nivel de desempeño con el modelo didáctico cursado Modelo didáctico Nivel de desempeño Teórico Alto Medio Bajo Total

T-Simulador

T-S-Arduino

Recuento

0

11

7

Porcentaje Recuento Porcentaje Recuento

0,0% 6 85,7% 1

42,3% 13 50,0% 2

41,2% 9 52,9% 1

Porcentaje Recuento

14,3% 7

7,7% 26

5,9% 17

Porcentaje

100,0%

100,0%

100,0%

Nota: Fuente: Investigación de campo.

Figura 14. Relación del nivel de desempeño con el modelo didáctico cursado.

Fuente: Investigación de campo.

Análisis e Interpretación: Conforme a los datos presentados en la figura 14, se puede ver cómo ha afectado positivamente a los estudiantes, dentro de su nivel de desempeño en la asignatura, el introducir, en primera instancia, el simulador JFLAP y después el proyecto Arduino.

44

Pregunta 5: ¿Piensa que las actividades prácticas dentro de esta asignatura son de vital importancia para comprender el contenido teórico de una mejor forma?

Tabla 12 Relación de la importancia práctica-teoría con el modelo didáctico cursado Modelo didáctico Importancia del contenido

Si No Total

Teórico

T-Simulador

T-S-Arduino

Recuento

7

25

17

Porcentaje Recuento Porcentaje Recuento

100,0% 0 0,0% 7

96,2% 1 3,8% 26

100,0% 0 0,0% 17

Porcentaje

100,0%

100,0%

100,0%

Nota: Fuente: Investigación de campo.

Figura 15. Relación de la importancia práctica-teoría con el modelo didáctico.

Fuente: Investigación de campo.

Análisis e Interpretación: Como se puede apreciar en los resultados que arroja esta pregunta, existe casi una total conformidad por el “Si”, en los tres modelos; afianzando la importancia de las actividades prácticas en la materia, para así comprender, con mayor facilidad el contenido teórico que se imparte. Justamente, éste es uno de los principales objetivos que se persigue con la implementación de estos nuevos modelos didácticos en la formación integral del ingeniero.

45

Pregunta 6: ¿Cree que mejoraría o hubiera mejorado el nivel de interés en la materia con la implementación del laboratorio remoto Arduino?

Tabla 13 Relación de implementación del laboratorio con el modelo didáctico cursado Modelo didáctico Interés con implementación

Si No Total

Teórico

T-Simulador

T-S-Arduino

Recuento

7

25

17

Porcentaje Recuento Porcentaje Recuento

100,0% 0 0,0% 7

96,2% 1 3,8% 26

100,0% 0 0,0% 17

Porcentaje

100,0%

100,0%

100,0%

Nota: Fuente: Investigación de campo.

Figura 16. Relación de implementación del laboratorio con el modelo didáctico.

Fuente: Investigación de campo.

Análisis e Interpretación: Como ocurre con la pregunta anterior, la inmensa mayoría de los estudiantes (en los tres modelos), creen que mejoraría o hubiera mejorado su nivel de interés por la asignatura al implementarse el laboratorio remoto Arduino, ayudándoles con sus prácticas de experimentación.

46

Pregunta 7: ¿Le ha ayudado a comprender mejor el funcionamiento del hardware a través de Arduino?

Tabla 14 Comprensión del hardware a través de Arduino Opciones

Frecuencia

Porcentaje

Si

16

94,1%

No

1

5,9%

Total

17

100,0%

Nota: Fuente: Investigación de campo.

Figura 17. Compresión del hardware a través de Arduino.

Fuente: Investigación de campo.

Análisis e Interpretación: En la figura 17 se puede apreciar como los estudiantes que pudieron realizar sus prácticas de la materia de Diseño de lenguajes y autómatas con proyectos Arduino, les ayudó a comprender mejor el funcionamiento interno del hardware con un resultado casi rotundo, cerca del 94,1%; deduciendo por tanto, que el microcontrolador Arduino es una herramienta de gran apoyo en el desenvolvimiento práctico de la asignatura.

47

Pregunta 8: Aproximadamente, ¿cuánto dinero invirtió en su proyecto Arduino?

Tabla 15 Inversión proyecto Arduino Opciones

Frecuencia

Porcentaje

Más de 80 dólares

2

11,8%

Entre 40 y 80 dólares

8

47,1%

Menos de 40 dólares

7

41,2%

Total

17

100,0%

[a]

Nota: [a] Los dos estudiantes que contestaron esta opción gastaron un total de 90 dólares americanos.

Fuente: Investigación de campo.

Figura 18. Inversión proyecto Arduino.

Fuente: Investigación de campo.

Análisis e Interpretación: Dentro de la figura 19 se puede ver, como la mayoría de los proyectos realizados por los estudiantes (cerca del 90%) se encuentran en 80 o por debajo de 80 dólares; en general, es un cantidad bastante económica debido a los componentes de hardware libre que emplearon para su implementación, incluyendo la placa Arduino. Las dos personas que contestaron más de 80 dólares, gastaron un total de 90 dólares siendo una cantidad muy aproximada a los valores que se manejan en las dos opciones anteriores.

48

Pregunta 9: ¿Le parece necesario la implementación de un laboratorio remoto Arduino para las prácticas de la materia?

Tabla 16 Necesidad del laboratorio remoto Arduino Opciones

Frecuencia

Porcentaje

Muy necesario

14

82,4%

Algo necesario

2

11,8%

Nada necesario

1

5,9%

Total

17

100,0%

Nota: Fuente: Investigación de campo.

Figura 19. Necesidad del laboratorio remoto Arduino.

Fuente: Investigación de campo.

Análisis e Interpretación: De acuerdo a los datos presentados el 82,4% de los encuestados consideran muy necesario la implementación del laboratorio remoto Arduino, un 11,8% lo consideran algo necesario, mientras que el 5,9% no creen que sea necesario tener este laboratorio. Los estudiantes que han trabajado con Arduino, ven muy preciso el hecho de poder contar con este laboratorio, gracias al gran potencial que puede demostrar este microcontrolador. Además, los alumnos podrán ahorrarse todos los costos asociados que se plantearon en la pregunta anterior, en la realización de sus prácticas.

49

Pregunta 10: ¿Piensa que realizar prácticas con Arduino le puede ayudar en su vida profesional como futuro ingeniero?

Tabla 17 Conocimiento de Arduino como ayuda en la vida profesional Opciones

Frecuencia

Porcentaje

Si

16

94,1%

No

1

5,9%

Total

17

100,0%

Nota: Fuente: Investigación de campo.

Figura 20. Conocimiento de Arduino como ayuda en la vida profesional.

Fuente: Investigación de campo.

Análisis e Interpretación: Los resultados obtenidos de los encuestados se pueden observar en la figura 20, donde la gran mayoría de ellos (94,1%), piensan que los conocimientos que se adquieren con Arduino les puede ayudar en su vida profesional al terminar la carrera de Sistemas, poniéndolo en práctica en el ámbito laboral. Por lo contrario, un 5,9% piensan que no les ayudará en nada el hecho de obtener estos conocimientos.

5.1.2.1.

Discusión de los resultados obtenidos en las encuestas.

Conforme a lo descrito en el apartado anterior se puede evaluar los avances académicos que han ido teniendo los estudiantes al ir introduciendo los distintos modelos didácticos. Existe una cierta mejora, desde el primer modelo que se impartía con anterioridad

50

hasta el modelo cursado actualmente, sin embargo, resulta insuficiente, ya que todavía hay un margen de mejora bastante grande. Esto deja en evidencia la necesidad de implementar el laboratorio remoto Arduino para realizar prácticas tanto en la asignatura de Diseño de lenguajes y autómatas como en el resto de materias afines a la electrónica.

5.2. Laboratorio Remoto Arduino – ArduiLab Para solventar la problemática del presente proyecto de investigación, se procede al desarrollo del Laboratorio Remoto Arduino (ArduiLab) para la Escuela de Sistemas de la Pontificia Universidad Católica del Ecuador Sede Santo Domingo. Scrum es el marco de trabajo elegido para la construcción del producto y los pasos a seguir se detallan en los apartados siguientes.

5.2.1. Sprint 1.

5.2.1.1.

Planificación del Sprint.

Dentro de cualquier metodología de desarrollo, la etapa de planificación es considerada como una de las más importantes para el porvenir del producto. En el caso de Scrum, la planificación viene dada por cada sprint que se realiza; sin embargo, es conveniente organizar inicialmente el propósito de cada iteración y definir globalmente lo que se realizará en cada sprint, además de asignar los roles con los que contará el producto.

5.2.1.1.1. Roles.

Es necesario mencionar los roles asignados en Scrum, es decir, el equipo humano de trabajo que colaborará en conjunto para realizar el producto. En este caso, los roles se encuentran conformados según como se describe en la tabla 18.

Tabla 18 Roles Scrum Rol

Persona

Área

Dueño del producto

Mg. Jon Azcona

Docente PUCE-SD

Scrum Master

Mg. Luis Ulloa

Docente PUCE-SD

Equipo de desarrollo

Gonzalo Bonilla

Desarrollador

Nota: Fuente: Investigación de campo.

51

5.2.1.1.2. Product Backlog.

El Product Backlog contiene la funcionalidad total del producto, siguiendo los parámetros que dicta el marco de trabajo, se mantuvo una primera reunión con el dueño del producto para identificar las funcionalidades, priorizar cada una de ellas y realizar una estimación del tiempo requerido para su implementación. El Product Backlog (ver tabla 19) contiene un ID (número de identificación), la prioridad dada por el dueño del producto (asignado a una escala de 0 – 100, donde 100 es la prioridad más alta), el nombre de la historia de usuario y la estimación de cada historia.

Tabla 19 Product Backlog versión final [a]

ID

Historia de usuario

Prioridad

[b]

Estimación

01

Señales de entrada digitales

100

13

02

Webcam remota para placa Arduino

90

21

03

Módulo de administración

80

13

04

Carga Sketch Arduino

70

21

05

Señales de entrada analógicas

60

13

06

Visualización monitor serie

50

13

07

Sistema de acceso de usuarios

40

13

08

Sistema de cola

30

21

09

Respaldo de archivos .ino

20

8

10

Refinamiento señales de entrada digitales

10

5

Nota: [a] El detalle completo de las historias de usuario se recoge en el Anexo 6. [b] La estimación se calcula a través de la serie Fibonacci, que se explica en el apartado 5.2.1.3. Fuente: Investigación de campo.

5.2.1.1.3. Estimación.

La estimación del producto se ha realizado conforme a la métrica muy empleada en el desarrollo ágil, conocida como puntos de historia, que está determinada por unos rangos (Baja 1 – 5, Media 8 – 13, Alta a partir de 21), y sirve para estimar con mayor precisión la complejidad aproximada que tendrá la historia en su conjunto en el momento del desarrollo.

52

Una vez establecida la métrica, el equipo de desarrollo ha procedido a aplicar la técnica (que mide la complejidad) de serie Fibonacci (Ver figura 21). Básicamente, el proceso consistió en asignar un valor estimado (de acuerdo a la experiencia en el desarrollo) conforme se daba lectura a cada una de las tareas de ingeniería y así se obtuvo el valor de la suma total perteneciente a cada historia de usuario de una manera aproximada, dando como resultado la estimación en puntos de historia que se ha detallado en el Product Backlog del apartado anterior.

Figura 21. Serie Fibonacci Scrum. Recuperado de “Scrumdesk” por Scrum, 17 de Enero de 2018. Obtenido de https://www.scrumdesk.com/agile-estimation-principles/#iLightbox[postimages]/0

Por último, se ha definido la velocidad de desarrollo del equipo, este valor se estableció en 50 puntos, los cuales serían desarrollados en un periodo de 4 semanas, trabajando en el producto 5 días por semana.

5.2.1.1.4. Gestor de tareas técnicas.

La gestión de las tareas se ha realizado a través de Trello, que es una herramienta de gestión de tareas muy versátil y disponible en la web. En Trello se ha construido todo lo necesario para poder organizar eficientemente el trabajo a realizar. En primer lugar, se ha creado un tablero (ver Figura 22) que contiene 4 columnas: 

Primera columna: Contiene el objetivo a lograr en cada Sprint y el Burn Down Chart para monitorear el avance de las tareas.



Segunda columna: Por hacer, en ella se encuentran las tareas que todavía no

53

han sido asignadas para su desarrollo. 

Tercera columna: En proceso, como la propia palabra lo indica, son las tareas que ya se encuentran en fase de desarrollo.



Cuarta columna: Terminadas, las tareas colocadas en esta columna se hallan en el estado de finalizadas.

Finalmente, se han replicado las historias de usuario, con sus respectivas tareas y así se pudo comenzar con el desarrollo del primer sprint.

Figura 22. Tablero Trello. Adaptado de “Trello” por Bonilla, G., 18 de Enero de 2018. Obtenido de https://trello.com/b/MiTiI0rS/desarrollo-scrum

5.2.1.1.5. Gestor de versiones.

Github ha sido otra de las herramientas empleadas, en este caso, para la gestión de versiones del software, integración de código y disponibilidad remota del repositorio; en donde se iba desarrollando el producto “laboratorio remoto Arduino”. A través de commits se ha ido actualizando dicho repositorio conforme iban culminándose las historias de usuario, para mostrar los avances realizados.

54

Figura 23. Repositorio del proyecto en la herramienta Github. Adaptado de “Github” por Bonilla, G., 1 de Febrero de 2018. Obtenido de https://github.com/maclife26/arduilab

5.2.1.2.

Plan de Release.

Para realizar este primer sprint se ha elegido las tres primeras historias con la prioridad más alta entregada por el dueño del producto, que sumando sus puntos de estimación cumple con un total de 47 puntos; estando por debajo de los 50 puntos dados para cada sprint a desarrollar. Después, se ha construido el Sprint Backlog (ver Tabla 20), dando tareas específicas a cada historia de usuario con el fin de trabajar de manera más simple y adecuada; el objetivo que se ha marcado para este primer sprint es: Desarrollar un primer prototipo funcional del laboratorio remoto Arduino.

Además, esta figura muestra los avances que han ido teniendo las distintas tareas técnicas (hasta su culminación) a lo largo del tiempo de desarrollo cumpliendo con la planificación dada para el Sprint.

55 Tabla 20

Sprint Backlog nĂşmero 1

56

5.2.1.3.

Ejecución del Sprint.

Cuando se ha realizado toda la planificación correspondiente al primer sprint, se ha seguido con la fase de ejecución del producto; donde todos los días (mientras duraba el sprint) se ha elaborado el Scrum diario, con una duración de 10 minutos, que ha servido para sincronizar el trabajo hecho, el que quedaba por hacer y las complicaciones encontradas en él.

Aquí es donde el panel de Trello entra en juego, gracias a él, se ha podido llevar un seguimiento continuo al producto por parte del equipo de desarrollo. A continuación, se detalla las tareas más importantes desarrolladas por cada historia de usuario.

5.2.1.3.1. Historia de usuario 1: Señales de entrada digitales.

El primer trabajo realizado ha sido la maquetación de las pantallas de visualización (ver Figura 24 y 25) para tener una idea inicial de cómo quedaría el diseño de las interfaces principales del laboratorio remoto Arduino. Para ello se ha empleado la herramienta web “moqups”, éstas maquetas fueron realizadas y aprobadas junto con el Product Owner en la primera reunión que se tuvo.

Figura 24. Maquetado del laboratorio remoto Arduino - Login.

Fuente: Investigación de campo

57

Figura 25. Maquetado del laboratorio remoto Arduino – Laboratorio.

Fuente: Investigación de campo

Después, se ha dado paso a la configuración necesaria para trabajar con el framework Django de Python: pi@gonzapi:~ $ sudo apt-get update pi@gonzapi:~ $ sudo apt-get upgrade pi@gonzapi:~ $ sudo apt-get install python3.6-pip pi@gonzapi:~ $ pip3.6 install django==1.11.7

Se ha creado una carpeta donde se aloja el proyecto Django y se ha iniciado dándole un nombre: pi@gonzapi:~ $ mkdir projects pi@gonzapi:~ $ cd projects pi@gonzapi:~/projects $ django-admin startproject arduilab pi@gonzapi:~/projects $ cd arduilab

Dentro de arduilab, se ha creado la aplicación perteneciente al proyecto en este caso con el nombre de Laboratorio: pi@gonzapi:~/projects/arduilab $ django-admin startapp Laboratorio

58

Quedando un directorio de la siguiente manera:

Figura 26. Árbol del directorio de proyecto.

Fuente: Investigación de campo

Una vez realizado esto, se ha añadido la aplicación dentro del proyecto, para ello se ha configurado el archivo setting.py agregando la última línea dentro de INSTALLED_APPS de la siguiente manera: INSTALLED_APPS = ( 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'Laboratorio', )

Para trabajar con GPIO de una manera más cómoda se ha instalado la librería gpiozero: pi@gonzapi:~ $ sudo pip3.6 install gpiozero

Una vez realizada toda la configuración necesaria se ha procedido a la codificación del interfaz web donde va a ser alojado el laboratorio remoto Arduino, priorizando las entradas digitales pertenecientes a esta historia.

59

5.2.1.3.2. Historia de usuario 2: Webcam remota para placa Arduino.

Poder hacer streaming en directo de los resultados de las prácticas del laboratorio es un factor muy importante para el proyecto. Primeramente, con la Raspberry Pi apagada, se ha enchufado la cámara levantando el conector del puerto CSI e introduciendo la cinta con la banda azul como se puede observar en la figura 27.

Figura 27. Conexión cámara de Raspberry Pi. Recuperado de “Amazon” por Amazon.com, 17 de Marzo de 2018. Obtenido de https://www.amazon.com/kuman-Raspberry-Camera-Module-Supports /dp/B01ICLLOZ8/ref=sr_1_9?ie=UTF8&qid=1534778743&sr=8-9& keywords=camera+raspberry+pi+3

Lo siguiente fue habilitar el módulo webcam en la configuración de la Raspberry, tecleando en la consola: pi@gonzapi:~ $ sudo raspi-config

Se abre la ventana de configuración (ver Figura 28), donde se ha elegido la opción 5 (Interfacing Options), y después la opción 1 para habilitar la cámara web.

Figura 28. Herramienta de configuración Raspberry Pi. Fuente: Investigación de campo

60

Una vez que se ha hecho la configuración necesaria, se ha dado paso a la instalación de las dependencias necesarias para el correcto funcionamiento del servidor con el servicio webcam. Los pasos que se han realizado se redactan a continuación: a) Tornado servidor web para conexión asíncrona. pi@gonzapi:~ $ sudo pip3 install tornado

b) Python Image Library para el procesamiento de imágenes con el intérprete. pi@gonzapi:~ $ sudo apt install python3-pil

c) Pygame (usado para capturar imágenes de una webcam) pi@gonzapi:~ $ sudo apt install python3-pygame

d) La cámara debe ser compatible con Video4Linux2 y debe aparecer como /dev/video0 en el sistema de ficheros. e) Añadir la siguiente línea ‘bcm2835-v4l2’ en la ruta “/etc/modules” para cargar el módulo de manera permanente.

Después, se ha codificado los archivos necesarios para la ejecución del servicio de streaming tanto en lenguaje Python como en JavaScript formando un directorio como se muestra en la figura 29.

Figura 29. Directorio StreamPy. Fuente: Investigación de campo

61

Finalmente, para levantar el servicio automáticamente cada vez que reinicie la Raspberry Pi ha sido necesario realizar unas configuraciones adicionales, utilizando la herramienta crontab de UNIX, que sirve para programar la ejecución de otros comandos; primero ejecutando: pi@gonzapi:~ $ crontab –e

Se ha añadido la siguiente línea en crontab: @reboot sleep 5 && /home/pi/project/StreamPy/start.sh

Como el servidor guarda datos en el archivo “server.log”, ha sido necesario crear una función que borre los datos semanalmente y así evitar el crecimiento infinito de este archivo, ejecutando el comando siguiente: pi@gonzapi:~ $ sudo nano /etc/logrotate.d/StreamPy.save

Escribir la función: /home/pi/project/StreamPy/server.log { weekly rotate 4 compress missingok copytruncate }

5.2.1.3.3. Historia de usuario 3: Módulo de administración.

Para desarrollar el módulo de administración ha sido necesario instalar en la Raspberry Pi el motor de base de datos PostgreSQL y el sistema gestor pgAdmin III: pi@gonzapi:~ $ sudo apt-get install postgresql libpq-dev postgresqlclient postgresql-client-common pi@gonzapi:~ $ sudo apt-get install pgadmin3

También, se ha necesitado de la instalación de psycopg2, que es el adaptador de PostgreSQL para Python más famoso. pi@gonzapi:~ $ sudo pip3.6 install psycopg2

62

Además, se ha tenido que configurar Django para que pueda admitir dicha conexión; dentro del archivo settings.py se han modificado los siguientes parámetros: DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': 'arduilab', 'USER': 'admin', 'PASSWORD': '4dm1n', 'HOST': 'localhost', 'PORT': '', } }

Django, por defecto, tiene integrado un módulo de administración muy completo, cumpliendo con las funcionalidades necesarias requeridas por el dueño del producto en cuando a roles de usuarios (estudiante y profesor) y grupos de trabajo se refiere, por lo tanto para utilizar este módulo se ha establecido un super-usuario (rellenando los datos que se solicitan) con el siguiente comando dentro del directorio de trabajo: pi@gonzapi:~/projects/arduilab $ python manage.py createsuperuser

Posteriormente, se ha realizado la migración para actualizar el modelo de la base de datos. Django Auth se encarga de crear las tablas a partir de modelos existentes dentro de la aplicación (Ver Figura 30): pi@gonzapi:~/projects/arduilab $ python manage.py migrate

63

Figura 30. Modelo físico de la base de datos.

Fuente: Investigación de campo

Acto seguido, se ha configurado el sitio administrativo para manejar usuarios y grupos de usuarios quedando una interfaz como se muestra a continuación:

Figura 31. Página principal administración.

Fuente: Investigación de campo

64

Figura 32. Página usuarios administración.

Fuente: Investigación de campo

Las pruebas unitarias fueron realizadas una por cada historia de usuario verificando en el servidor de desarrollo que los datos y los archivos estáticos eran correctamente cargados en la página HTML. Estas pruebas constituyeron el 70% de todas las pruebas realizadas en el desarrollo del producto de software, y gracias a ellas se ha podido comprobar el funcionamiento correcto de cada uno de los módulos que integra el laboratorio. A continuación se muestra un ejemplo de una prueba unitaria ejecutada satisfactoriamente:

Figura 33. Ejecución de prueba unitaria.

Fuente: Investigación de campo

Por último, se presenta el BurnDown Chart perteneciente al Sprint, donde se ha podido ir monitoreando los puntos de historias restantes hasta finalizar dicha iteración. Si se aprecia la figura 34, la línea de color verde representa el avance ideal de los puntos de historia, mientras que la línea azul representa el avance real de la misma.

65

Burn Down Chart Balance Day Planned Actual

Done Today

50 45

0

47

47

0

1

44

45

2

2

42

42

3

3

39

38

4

4

37

36

2

5

34

34

2

6

32

31

3

7

29

29

2

8

27

28

1

9

24

27

1

10

22

23

4

11

19

22

1

12

17

21

1

13

14

18

3

14

12

15

3

15

9

11

4

16

7

9

2

17

4

6

3

18

2

3

3

19

1

1

2

20

0

0

1

40

35 30 25 20

15 10 5 0 0

1

2

3

4

5

6

7

8

Done Today

9

10

11

Planned

12

13

14

15

16

17

18

19

20

Actual

Figura 34. BurnDown Chart 1.

Fuente: Investigación de campo

5.2.1.4.

Revisión del Sprint.

Una vez concluida la ejecución del primer sprint, se ha llevado a cabo una reunión con el dueño del producto con el objetivo de realizar una demostración del incremento del producto y comprobar si cumple o no con las funcionalidades requeridas. Gracias a ello, se consigue una retroalimentación que será de gran ayuda en los Sprints venideros. El documento que avala esta revisión es la prueba de aceptación (tiene como propósito demostrar al cliente el cumplimiento de un requisito del software); esta prueba se ha realizado por cada una de las historias de usuario pertenecientes al Sprint (ver Anexos 7).

5.2.1.5.

Retrospectiva del Sprint.

Esta reunión se encuentra dentro del marco de trabajo Scrum y se la ha realizado junto con el Scrum Master para reforzar en énfasis la transparencia y comunicación entre el equipo de trabajo. Debido a que esta reunión es totalmente informal, se ha decidido crear una tabla (ver tabla 20) donde aparecen tres columnas indicando los aciertos del equipo (lo que salió bien en la iteración), los errores (lo que salió mal), y las mejoras identificadas, que serán implementadas en el siguiente Sprint.

Con ello, se consigue mejoras continuas, que es uno de los principios que persigue el desarrollo ágil; además ayuda al equipo inspeccionando las relaciones, los procesos y las

66

herramientas empleadas, por ello se la considera como una de las reuniones más importantes dentro de este marco de trabajo.

Tabla 21 Formulario de reunión de retrospectiva 1 Aciertos Comunicación constante

Errores

Mejoras

Inexperiencia en desarrollo de

Mayor experiencia, mejor

varias tareas

estimación

Tiempos de desarrollo correctos Correcta elección de tecnologías Nota: Fuente: Investigación de campo.

5.2.2. Sprint 2.

5.2.2.1.

Planificación del Sprint.

Continuando con la planificación del segundo sprint, se han elegido las historias de usuario número cuatro, cinco y seis; que, de acuerdo a sus puntos de estimación suman un total de 47 puntos a ser desarrollados en esta etapa. Se tiene como historia de mayor complejidad “Carga Sketch Arduino” por ello, se le asigna una mayor estimación para su realización. Al igual que ocurría en el sprint uno, se ha creado el Sprint Backlog (ver Tabla 22) y se ha marcado como objetivo en esta iteración: Desarrollar una versión mejorada del prototipo laboratorio remoto Arduino.

67 Tabla 22

Sprint Backlog nĂşmero 2

68

5.2.2.2.

Ejecución del Sprint.

Al ser una metodología iterativa, la forma de trabajo entregado en el sprint uno sirve como guía en los sprint siguientes (manteniendo la filosofía de “mejora continua”). Por tanto, se han mantenido las pequeñas reuniones diarias, actualización del panel Trello y el desarrollo de las historias de usuario correspondientes.

5.2.2.2.1. Historia de usuario 4: Carga Sketch Arduino.

Para la construcción de esta historia, se ha restructurado la idea inicial de colocar la carga del Sketch Arduino, en la misma pantalla donde se encuentra el laboratorio, por una pantalla independiente consiguiendo aislarla de posibles conflictos, además de la sobrecarga de elementos HTML dentro de dicha página.

En primer lugar se ha creado una nueva página con todos los elementos requeridos dando como resultado la siguiente figura:

Figura 35. Página carga Sketch Arduino.

Fuente: Investigación de campo

Después, se ha procedido a codificar en primera instancia el envío del archivo .ino hacia la Raspberry Pi (en una carpeta específica dentro del servidor). Una vez se tuvo el archivo disponible, se ha realizado como segundo paso, siendo el más importante, la compilación de éste; generando varios archivos (entre ellos el binario que se enviará hacia Arduino), para ello se ha llevado a cabo los siguientes pasos:

69

a) Instalar librería necesaria para comunicación serial. pi@gonzapi:~ $ sudo pip3.6 install pyserial

b) Librería para compilación y carga Arduino: muy robusta y altamente customizable. pi@gonzapi:~ $ sudo apt-get install arduino-mk

c) Crear directorio de trabajo dentro de la carpeta /media del proyecto. pi@gonzapi:~/projects/arduilab/media $ sudo mkdir sketchbook

d) Crear archivo Makefile dentro del directorio sketchbook con el siguiente contenido: ARDUINO_DIR = /usr/share/arduino ARDUINO_PORT = /dev/ttyACM0 USER_LIB_PATH = /home/pi/sketchbook/libraries BOARD_TAG = mega2560 include /usr/share/arduino/Arduino.mk

e) Crear archivo bash con el nombre Make.sh y el contenido: #!/bin/bash sudo make upload clean sudo find . -maxdepth 1 -type f -name "*.ino" -exec rm -f {} \;

Finalizado estos pasos, se ha procedido a codificar los controladores necesarios para que funcione adecuadamente este módulo. De manera que cuando el usuario pulse en “Compilar y cargar”, el servidor internamente realice paso a paso las tareas necesarias (ver figura 36), tomándole alrededor de 10 segundos antes de redirigir a la página principal del laboratorio para las respectivas pruebas.

70

Figura 36. Arduino-mk ejecutándose en el servidor Fuente: Investigación de campo

5.2.2.2.2. Historia de usuario 5: Señales de entrada analógicas.

Para poder representar las entradas analógicas se ha optado por utilizar la librería jQuery-Knob, que simula la forma de un dial al cual se le pueden dar valores entre 0 – 100.

Al ver la figura 37 se puede apreciar como ha quedado el diseño dentro del laboratorio. Esto servirá para que el usuario pueda interactuar con componentes electrónicos de tipo analógico e analizar su comportamiento según el código que haya escrito la persona que esté usando el laboratorio en ese momento.

Figura 37. Análogos Knob Fuente: Investigación de campo

71

Una vez realizado el diseño, se ha continuado con la codificación en el front-end haciendo uso de AJAX, para mantener una conexión asíncrona con el usuario en todo momento y que no sea necesario la recarga de toda la página. En el back-end, se ha configurado y codificado la recepción de estas peticiones AJAX (con valores) y poder enviarlas hacia GPIO 23 y 24 respectivamente que serán los encargados, a su vez, de transmitir estos valores a través de PWM hacia la placa Arduino. Pero, como la señal PWM no es una señal analógica de tensión, sino más bien un valor promedio del deseado, es necesario aplicar mecanismos para que se aproxime mejor a una señal analógica auténtica.

Una de las más sencillas es aplicar un filtro de paso bajo para suavizar la señal.

El filtro (ver Figura 38) se aplica entre la Raspberry Pi y la placa Arduino, y como se puede observar la señal de salida no llega a ser analógicamente perfecta, pero suficiente para el objetivo principal de este módulo.

Figura 38. Filtro paso bajo. Recuperado de “Ingeniería, informática y diseño” por Llamas, L., 28 de Marzo de 2018. Obtenido de https:// www.luisllamas.es/salida-analogica-mediante-pwm-y-filtro-paso-bajo/

5.2.2.2.3. Historia de usuario 6: Visualización monitor serie.

Otra manera de visualizar los resultados de la práctica en el laboratorio es a través del monitor serie del IDE de Arduino. A través de esta herramienta se pueden comprobar los resultados del sketch de una forma más específica, sirviendo de apoyo al servicio de streaming.

Para poner en marcha esta historia, en primer lugar ha sido necesario un cambio de versión de Python3.4 hacia Python3.6, para aprovechar las bondades que ofrece esta nueva versión sobre todo en lo que se refiere a WebSockets a través de Channels, siguiendo los

72

siguientes pasos: a) Actualizaciรณn de los paquetes: pi@gonzapi:~ $ sudo apt-get update

b) Instalaciรณn de librerรญas necesarias: pi@gonzapi:~

$

sudo

apt-get

install

build-essential

tk-dev

libncurses5-dev libncursesw5-dev libreadline6-dev libdb5.3-dev libgdbm-dev libsqlite3-dev libssl-dev libbz2-dev libexpat1-dev liblzma-dev zlib1g-dev

c) Descarga del paquete Python3.6 y descompresiรณn: pi@gonzapi:~ $ wget https://www.python.org/ftp/python/3.6.5/ Python-3.6.5.tar.xz pi@gonzapi:~ $ sudo tar xf Python-3.6.5.tar.xz

d) Se accede a la carpeta creada y se realiza la configuraciรณn: pi@gonzapi:~ $ cd Python-3.6.5 pi@gonzapi:~/Python-3.6.5 $ ./configure

e) Se realiza la compilaciรณn y la instalaciรณn: pi@gonzapi:~/Python-3.6.5 $ sudo make pi@gonzapi:~/Python-3.6.5 $ sudo make altinstall

f) Con Python3.6 instalado correctamente se procede a instalar Channels: pi@gonzapi:~ $ pip3.6 install -U channels

g) Debido a que el paquete de channels instala django==2 y la aplicaciรณn se encuentra trabajando con 1.11.7, se vuelve a instalar esta versiรณn: pi@gonzapi:~ $ sudo pip3.6 install django==1.11.7

Ademรกs, ha sido necesario la reinstalaciรณn de todas las dependencias anteriores que se encontraban con la versiรณn de pip3, a la nueva versiรณn de pip3.6.

73

Para terminar con la configuración, dentro del archivo settings.py agregar en INSTALLED_APPS la aplicación ‘Channels’. Después, se ha dado paso a la codificación, manejando Channel (ASGI) que funciona de manera asíncrona para mantener una conexión constante (debido a la necesidad de leer el puerto serial de la Raspberry Pi y transmitir esos datos hacia el interfaz web), agregando una capa intermedia (ver Figura 39) que reciba la petición, la procese y avise cuando acabe con ella. Todo ello para evitar sobrecargar al servidor, procesando acciones extra en segundo plano.

Figura 39. Capa intermedia Channel. Recuperado de “Platzi” por Platzi, 25 de Marzo de 2018. Obtenido de https://platzi.com/django/tutoriales/realtime-django-con-celery-for-dummies/

Los resultados de la lectura del puerto serial se representan dentro de la página principal del laboratorio, mediante una tabla que irá imprimiendo el valor, dependiendo de la codificación que el usuario haya hecho en el sketch cargado.

A continuación se muestran dos ejemplos de la funcionalidad solicitada para esta historia de usuario:

74

Figura 40. Puerto serial – led encendido.

Fuente: Investigación de campo

Figura 41. Puerto serial – led apagado.

Fuente: Investigación de campo

Para finalizar la ejecución de este segundo sprint, se presenta el BurnDown Chart (ver figura 42) con sus avances correspondientes y todo el tiempo de desarrollo ocupado en esta fase. Al mirar la gráfica con detenimiento se puede observar como en casi todo el proceso del Sprint, el trabajo real se encontraba muy por encima del ideal, por lo tanto, en los últimos días ha sido necesario realizar más puntos de historia.

75

Burn Down Chart Balance Day Planned Actual

Done Today

50 45

0

47

47

0

1

44

44

3

2

42

43

1

3

39

39

4

4

37

38

1

5

34

36

2

6

32

34

2

7

29

31

3

8

27

30

1

9

24

28

2

10

22

26

2

11

19

24

2

12

17

22

2

13

14

19

3

14

12

16

3

15

9

13

3

16

7

12

1

17

4

9

3

18

2

4

5

19

1

1

3

20

0

0

1

40

35 30 25 20

15 10 5 0 0

1

2

3

4

5

6

7

8

Done Today

9

10

11

Planned

12

13

14

15

16

17

18

19

20

Actual

Figura 42. BurnDown Chart 2.

Fuente: Investigación de campo

5.2.2.3.

Revisión del Sprint.

De acuerdo al incremento que se ha entregado en este Sprint, el Product Owner ha podido observar un gran avance del producto y como ha ido tomando una mejor forma en comparación con el primer Sprint. La reunión ha durado no más de 2 horas, y en ella se han revisado todos los criterios pertenecientes a las historias de usuario, las pruebas de aceptación (ver Anexo 7) que han sido aprobadas de manera satisfactoria, con ciertas observaciones.

5.2.2.4.

Retrospectiva del Sprint.

Segunda reunión de retrospectiva (tabla 23), donde los puntos a tratar han estado más claros y definidos. Se ha mantenido, dentro de los aciertos, la comunicación constante entre los implicados del producto; gracias a ello, el proceso de desarrollo del producto ha sido más transparente y fluido, resolviendo los inconvenientes de una manera rápida, efectiva y consensuada.

76 Tabla 23 Formulario de reunión de retrospectiva 2 Aciertos

Errores

Mejoras

Reestructura de páginas HTML

Falla en ciertos eventos de usuario

Controlar los eventos de usuario

Comunicación constante

Criterios de aceptación confusos

Definir correctamente los criterios

Tiempos de desarrollo correctos Nota: Fuente: Investigación de campo.

5.2.3. Sprint 3.

5.2.3.1.

Planificación del Sprint.

De acuerdo con la planificación que se plantea para este último sprint, se han escogido las historias de usuario restantes: siete, ocho, nueve y diez respectivamente. Siendo estas historias las de menor prioridad dentro del Product Backlog proyectado en un principio junto con el Product Owner. Estas historias suman un total de 49 puntos de estimación y en este caso la historia del sistema de colas ha resultado ser la de mayor estimación con un total de 21 puntos.

El objetivo que se ha trazado para este sprint es: Finalizar el prototipo del laboratorio remoto Arduino exitosamente. Como ocurría con los anteriores Sprint se ha desarrollado el Sprint Backlog (ver Tabla 24) correspondiente a esta iteración.

Cabe destacar que, la historia de usuario número diez es una funcionalidad agregada dentro de la historia número uno, por lo tanto, pasó a formar parte del Product Backlog y por consiguiente a este Sprint, con una prioridad baja, al carecer de mayor relevancia en el proceso de desarrollo.

77 Tabla 24

Sprint Backlog nĂşmero 3

78

5.2.3.2.

Ejecución del Sprint.

El desarrollo de esta etapa ha ido ocurriendo incluso mejor que las anteriores iteraciones, conforme han ido avanzando los sprint se ha ido ganando experiencia tanto en el desarrollo de las tareas técnicas como en el seguimiento del marco de trabajo Scrum, puesto que en el primer sprint, al carecer de práctica metodológica, el uso de las herramientas que brinda este marco de trabajo no ha sido tan evidente como lo es ahora; ofreciendo al desarrollador una guía de buenas prácticas para construir el producto.

5.2.3.2.1. Historia de usuario 7: Sistema de acceso de usuarios.

La seguridad del laboratorio remoto depende tanto de la autentificación como de las políticas de autorización implantadas en el servidor. En este caso, los usuarios serán creados únicamente por el administrador y el profesor a cargo de la asignatura, que brindarán las credenciales necesarias a los estudiantes para poder acceder al laboratorio remoto Arduino.

Partiendo de que la base de datos ya fue creada con anterioridad, el framework Django se encargó de habilitar automáticamente la autentificación cuando se creó la aplicación y su configuración se encuentra dentro de settings.py: INSTALLED_APPS = [ ... 'django.contrib.auth', its default models.

#Core authentication framework and

'django.contrib.contenttypes', #Django content system (allows permissions to be associated with models).

type

....

MIDDLEWARE = [ ... 'django.contrib.sessions.middleware.SessionMiddleware', #Manages sessions across requests ... 'django.contrib.auth.middleware.AuthenticationMiddleware', #Associates users with requests using sessions. ....

79

Después, se ha creado el template de acceso de usuarios, siendo éste el primero que verá el usuario al acceder al servicio. A continuación se muestran algunos ejemplos:

Figura 43. Login – Laboratorio remoto Arduino.

Fuente: Investigación de campo

Figura 44. Login – Error en credenciales.

Fuente: Investigación de campo

Observando la figura 45, se puede ver como al realizar un acceso exitoso, el usuario sabrá en todo momento que se encuentra registrado, esta información se muestra en la

80

esquina inferior derecha de dicha figura. Además, en la misma esquina se encuentra el cierre de sesión del usuario, que en caso de presionar dicho cierre, volverá a la página de acceso inicial.

Figura 45. Acceso exitoso.

Fuente: Investigación de campo

Otro factor que se ha tenido en cuenta dentro de esta historia, fue el tiempo de sesión para cada usuario, en este caso al ser un laboratorio de pruebas, se ha dictaminado un periodo de 5 minutos. Este tiempo es más que suficiente para realizar los experimentos requeridos; en el caso de agotarse dicho tiempo el usuario dependerá de dos condiciones: la primera de ellas sería si no hubiera nadie más esperando por el servicio del laboratorio, entonces se le volvería a asignar 5 minutos más de tiempo y la segunda, sería si hubieran más usuarios esperando este servicio, entonces pasaría a formar parte del sistema de colas que se redactará en la historia siguiente.

5.2.3.2.2. Historia de usuario 8: Sistemas de colas.

Para que los usuarios puedan acceder al laboratorio de manera organizada, se ha optado por implementar un sistema de colas que gestione a dichos usuarios. En el momento que el usuario accede correctamente y existe una persona utilizando el laboratorio en ese mismo instante, entonces ese usuario pasa a formar parte de la cola esperando su turno para poder ingresar, mientras aguarda puede visualizar a través del servicio de streaming la práctica que está realizando el otro usuario, de igual manera puede ver el tiempo restante que

81

le queda para acceder al laboratorio.

El sistema de colas ha necesitado de un contador para poder sincronizar el servidor con los clientes que atiende mientras se hace uso de la aplicación, es por ello que constantemente se envían peticiones de actualización de tiempo y de usuario (ver Figura 46) hacia el servidor.

Figura 46. Peticiones de actualización.

Fuente: Investigación de campo

Conforme los usuarios van ingresando, el servidor se encarga de ir colocándolos en la posición correspondiente dentro de la cola. En la plantilla HTML se ha dispuesto de una tabla para representar a estos usuarios (ver Figura 47). El tiempo restante se irá sumando conforme vayan entrando los usuarios a la cola, de manera que ese tiempo coincida con la espera necesaria antes de acceder al laboratorio.

82

Figura 47. Página de usuario en espera.

Fuente: Investigación de campo

Para la codificación se ha servido tanto del lenguaje Python (servidor) como de JavaScript (cliente) integrándose ambos lenguajes para que funcione correctamente este sistema de colas (ver Figuras 48 y 49).

Figura 48. Ejemplo código JavaScript.

Fuente: Investigación de campo

83

Figura 49. Ejemplo código Python.

Fuente: Investigación de campo

5.2.3.2.3. Historia de usuario 9: Respaldo de archivos .ino.

Debido a que el microcontrolador Arduino recibe código escrito por los usuarios que lo prueban dentro del laboratorio y para controlar la existencia de código malicioso capaz de dañar tanto el Arduino como la Raspberry Pi se ha dispuesto de esta solución preventiva. Para ello, se guarda un respaldo de cada archivo .ino que sube el usuario hacia el servidor, manteniendo un registro (ordenado por fecha_hora_nombreUsuario_ nombre_Archivo) de cada uno de esos archivos. En caso de que existiera código malicioso en alguno de los Sketch cargados en el Arduino, el administrador podrá analizarlos y comprobar cuál de los usuarios fue el causante del problema.

Para realizar estos respaldos se ha necesitado aumentar código dentro de una función (ver Figura 50) ya creada con anterioridad que se encargaba de subir el archivo al servidor (historia de usuario cuatro), aprovechando toda la funcionalidad que brinda dicha función.

Además, se ha tenido que crear una carpeta específica para guardar los respaldos (ver Figura 51) dentro del directorio que almacena los archivos: pi@gonzapi:~/projects/arduilab/media/sketchbook $sudo mkdir Respaldos

84

Figura 50. Ejemplo función subir archivo y respaldos.

Fuente: Investigación de campo

Figura 51. Respaldos generados.

Fuente: Investigación de campo

Con el propósito de mantener la carpeta de Respaldos el tiempo que requiera el administrador, él mismo se encargará de realizar los borrados pertinentes de los archivos, para evitar que se llene en demasía dicho directorio.

85

5.2.3.2.4. Historia de usuario 10: Refinamiento señales de entrada digitales.

La primera disposición de la funcionalidad requerida por el Product Owner había contemplado los botones digitales, sin tomar en cuenta, los estados en los que se encontraban dichos botones. Para ello, se ha procedido a eliminar toda una fila de botones y mantener una de ellas; ésta fila de botones, al ingresar al laboratorio en un primer momento, deberá presentarse de color “Rojo”, un estado de 0 lógico y al pulsar la primera vez deberá volverse de color “Verde”, es decir, un estado de 1 lógico y así sucesivamente. El resultado final de esta historia se presenta en la siguiente figura:

Figura 52. Estados de botones digitales.

Fuente: Investigación de campo

Como último paso, dentro de la ejecución de esta iteración se presenta el gráfico de avance que corresponde a este sprint (ver Figura 53), donde se puede apreciar que a partir del doceavo día el trabajo real se encontraba por encima del ideal, por lo que era necesario estar pendiente y no despegarse demasiado de dicha línea, para poder cumplir con los días planeados.

86

Burn Down Chart Balance Day Planned Actual

Done Today

50 45

0

47

47

0

1

44

45

2

2

42

43

2

3

39

39

4

4

37

36

3

5

34

34

2

6

32

31

3

7

29

26

5

8

27

25

1

9

24

24

1

10

22

20

4

11

19

19

1

12

17

19

0

13

14

15

4

14

12

13

2

15

9

11

2

16

7

7

4

17

4

4

3

18

2

3

1

19

1

2

1

20

0

0

2

40

35 30 25 20

15 10 5 0 0

1

2

3

4

5

6

7

8

Done Today

9

10

11

Planned

12

13

14

15

16

17

18

19

20

Actual

Figura 53. BurnDown Chart 3.

Fuente: Investigación de campo

5.2.3.3.

Revisión del Sprint.

Tercera y última reunión de demostración con el Product Owner, se ha entregado el último incremento, analizando todos los criterios de aceptación pertenecientes a este Sprint y comprobando que todo funcionara correctamente. Dado que se trataba de una reunión final, estas pruebas de aceptación han sido presentadas de una manera más exhaustiva, para que el dueño del producto quedase conforme en la integración del hardware junto con el software desarrollado.

5.2.3.4.

Retrospectiva del Sprint.

Última reunión de retrospectiva (ver Tabla 25), donde se ha podido comprobar el gran avance, en lo que mejoras se refiere, corrigiendo todos los errores cometidos por el equipo de desarrollo en los anteriores Sprint, han dado como resultado un aprendizaje constante y una mejora progresiva en el proceso de desarrollo de un producto de software con una metodología ágil. Con esta reunión definitiva se concluye las fases de Scrum, dando por finalizado el proyecto.

87 Tabla 25 Formulario de reunión de retrospectiva 3 Aciertos

Errores

Mejoras

Mejoras progresivas

Ninguno

Ninguna

Comunicación constante

Ninguno

Ninguna

Correcta elección de tecnologías

Ninguno

Ninguna

Nota: Fuente: Investigación de campo.

88

5.3. EvaluaciĂłn de Impacto del Proyecto de investigaciĂłn Para poder evaluar de una mejor manera el impacto que ha tenido el proyecto de investigaciĂłn, una vez que se haya implementado, se determinan los diferentes niveles de impacto (positivo o negativo) y los indicadores numĂŠricos de cada uno (ver Tabla 26). El nivel de impacto se calcula mediante la siguiente fĂłrmula: Nivel de impacto = total sumatorio, dividido para la cantidad de indicadores FĂłrmula

(NI = ∑ / N°)

Tabla 26 Niveles de impacto Nivel

DescripciĂłn

-3

Impacto de alto nivel negativo

-2

Impacto de medio nivel negativo

-1

Impacto de bajo nivel negativo

0

No hay impacto

1

Impacto de bajo nivel positivo

2

Impacto de medio nivel positivo

3

Impacto de alto nivel positivo

Nota: Adaptado de “MetodologĂ­a para el trabajo de gradoâ€?, por M. A. Posso, 2009. Tesis y Proyectos Cuarta ed. Ibarra: NINA Comunicaciones.

5.3.1. Impacto TecnolĂłgico.

Tabla 27 Impacto tecnolĂłgico Nivel de impacto

-3

-2

-1

0

1

2

3

Indicadores Desarrollo tecnolĂłgico

X

IntegraciĂłn hardware - software

X

Total

-

-

Sumatoria ∑ Total

∑=3+3=6

Resultado de FĂłrmula Resultado

-

-

đ?‘ đ??ź =

-

6 =3 2

Impacto de alto nivel positivo

Nota: ∑= sĂ­mbolo para operaciones de suma. Fuente: InvestigaciĂłn de campo

-

6

89

Anålisis 

Fomenta el desarrollo tecnolĂłgico aplicando las nuevas tecnologĂ­as de la informaciĂłn, a travĂŠs de los diversos mĂŠtodos y herramientas disponibles para la creaciĂłn de software funcional y de alto valor de calidad.



Integra de manera adecuada, hardware y software libre para alcanzar el desarrollo de un producto que cumpla con las necesidades establecidas por el dueĂąo del producto a partir de una idea inicial.

5.3.2. Impacto Social.

Tabla 28 Impacto social Nivel de impacto

-3

-2

-1

0

1

2

3

Indicadores

Disponibilidad del laboratorio remoto

X

Herramienta interactiva para la enseĂąanza

X

Condiciones de desarrollo de prĂĄcticas

X

Total

-

Sumatoria ∑ Total

-

-

-

2

6

∑=2+6=8 đ?‘ đ??ź =

Resultado de FĂłrmula Resultado

-

8 = 2.66 3

Impacto de alto nivel positivo

Nota: ∑= sĂ­mbolo para operaciones de suma. Fuente: InvestigaciĂłn de campo

Anålisis 

El laboratorio podrĂĄ estar disponible 24/7, lo que permitirĂĄ al estudiante realizar prĂĄcticas a cualquier hora del dĂ­a sin ceĂąirse a un horario establecido.



Esta herramienta busca ser interactiva manipulando hardware a travĂŠs del software, para una enseĂąanza prĂĄctica de las materias afines.



Se mejora el ĂĄmbito en el que se desarrollan las prĂĄcticas, motivando a los estudiantes en la experimentaciĂłn prĂĄctica mediante el laboratorio remoto Arduino.

90

5.3.3. Impacto EconĂłmico.

Tabla 29 Impacto econĂłmico Nivel de impacto

-3

-2

-1

0

1

2

3

Indicadores Apoyo a hardware de bajo coste

X

Ahorro en componentes electrĂłnicos Total

X -

-

-

Sumatoria ∑ Total

-

-

2

3

∑=3+2=5

Resultado de FĂłrmula

đ?‘ đ??ź =

Resultado

5 = 2.5 2

Impacto de alto nivel positivo

Nota: ∑= sĂ­mbolo para operaciones de suma. Fuente: InvestigaciĂłn de campo

Anålisis 

Al trabajar con hardware libre y de bajo coste, los gastos necesarios para el desarrollo de este tipo de laboratorios es mĂ­nimo, fomentando el uso de estos controladores gracias a sus precios asequibles.



Debido a que el laboratorio usa un determinado nĂşmero de componentes para las prĂĄcticas, no es necesario la compra de un kit de componentes para cada estudiante.

5.3.4. Impacto General.

Tabla 30 Impacto general Nivel de impacto

-3

-2

-1

0

1

2

3

Indicadores Impacto TecnolĂłgico

X

Impacto Social

X

Impacto EconĂłmico Total

X -

-

-

Sumatoria ∑ Total

-

∑=6+2=8

Resultado de FĂłrmula Resultado

-

đ?‘ đ??ź =

8 = 2.66 3

Impacto de alto nivel positivo

Nota: ∑= sĂ­mbolo para operaciones de suma. Fuente: InvestigaciĂłn de campo

2

6

91

Análisis 

El Laboratorio Remoto Arduino para la realización de prácticas de las materias afines a la electrónica muestra un impacto de alto nivel positivo, mediante el análisis que se realiza de forma general se determina la viabilidad del producto desarrollado. Efectuar las prácticas de laboratorio a través de esta herramienta ayudará al estudiante notablemente en su proceso de formación técnica dentro de la carrera de Ingeniería de Sistemas.

92

6. CONCLUSIONES 

Con la implementación del laboratorio remoto Arduino se aspira conseguir una notable mejora, a futuro, en el proceso de enseñanza práctica dentro de las asignaturas afines a la electrónica en la Escuela de Sistemas de la universidad, gracias a que el alumno ahora posee una herramienta totalmente interactiva, que le permite manipular remotamente el hardware (Arduino), a través del software específicamente desarrollado para este entorno.



La correcta elección de la metodología de software a emplear en la gran mayoría de ocasiones afecta a la calidad del producto entregado. En este caso, el marco de trabajo Scrum ha resultado ser un método idóneo para el desarrollo de este producto, debido en gran parte, a las reuniones que se recogen dentro de Scrum, posibilitando una comunicación constante entre el equipo de desarrollo y los interesados. Además, al ser un proceso iterativo e incremental, se ha podido obtener retroalimentación cada vez que se realizaban las revisiones y las retrospectivas de los diferentes Sprints.



Por medio del análisis, de la entrevista, se ha podido determinar la necesidad de un cambio de paradigma a la hora de impartir este tipo de materias, a través de la aplicación de la metodología STEM e incorporación de nuevas herramientas que ayuden al alumno en su proceso de aprendizaje. Del mismo modo, al haber analizado la encuesta se ha podido comprobar que la problemática residía dentro de la Escuela de Sistemas y que era necesario mitigar dicha contrariedad de alguna manera.



Trabajar con hardware y software libre ha ayudado enormemente al proceso de desarrollo del laboratorio remoto Arduino, tanto es así, que la Raspberry Pi es perfectamente capaz de actuar como servidor, soportando de forma notoria, la carga de trabajo dada por el software. Por ello, la elección de las tecnologías a emplearse, ha sido un proceso variado y muy minucioso tratando de minimizar el consumo de los recursos del servidor de manera eficaz.

93

7. RECOMENDACIONES 

En la actualidad, debido a los constantes cambios que se generan en el entorno, elegir una metodología ágil para el desarrollo de software es prácticamente una obligatoriedad, si se desea concluir eficientemente el producto. Además, seguir lo más fielmente posible la metodología a emplearse, permite obtener un software de calidad, debido a las “buenas prácticas” aplicadas en el proceso y facilita, en gran medida, todo el ciclo de vida por el que transcurre el producto de software.



Implicar de manera activa los roles que participan en el desarrollo del producto, ya que la interacción constante entre los participantes es uno de los valores que persigue el desarrollo ágil y posibilita la entrega de los incrementos de manera adecuada y sin contratiempos que demoren el proceso.



Utilizar herramientas como Trello o Github que faciliten el seguimiento, por parte de los miembros del equipo, del proceso de desarrollo del producto en todos los Sprints que lo conforman. Asimismo, servirse de la documentación oficial de las tecnologías utilizadas evitará posibles problemas a la hora de codificar los módulos que se vayan a necesitar.



Si se trata de minimizar costos, optar por hardware libre es una opción muy viable; en la actualidad, existe una gran variedad de microcontroladores y microcomputadoras que pueden servir de prototipos para cualquier tipo de investigación que requiera de estos componentes.



En un futuro próximo, tener la posibilidad de que el Laboratorio Remoto Arduino pueda estar operativo en Internet, posibilitando a los estudiantes el acceso desde sus hogares para realizar las debidas prácticas.

94

8. LISTA DE REFERENCIAS Arduino. (29 de Octubre de 2017). Arduino Mega 2560 Rev3. Obtenido de https://store.arduino.cc/usa/arduino-mega-2560-rev3 Arévalo, V., García-Morales, I., & Cano, J. (2017). Laboratorio remoto de Automática. Una solución de bajo coste basada en Raspberry PI y Arduino. (Tesis de grado). Escuela Superior Politécnica del Ecuador. Ecuador Beaglebone Black. (2 de Noviembre de 2017). BeagleBoard.org - black. Obtenido de beaglebone.org: http://beagleboard.org/black Bernal, C. (2010). Metodología de la investigación (3ª ed.). Bogotá: Pearson Educación.

Coronel, C., Morris, S., & Rob, P. (2011). Bases de datos. Diseño, implementación y administración. México: Cengage Learning Editores.

Fernández, A. (2013). Python 3 al descubierto (2ª ed.). México: Alfaomega Grupo Editor.

Fundación Telefónica. (26 de Mayo de 2018). La Educación STEM. Obtenido de http://fundaciontelefonica.com.ec/2017/04/18/la-educacion-stem-la-educacion-delsiglo-xxi/ Ghosh, S. (2015). Systemic comparison of the application of EVM in traditional and agile software project. Integration, 5, 3.

Gonzalez, H. B., & Kuenzi, J. J. (2012, August). Science, technology, engineering, and mathematics (STEM) education: A primer. Congressional Research Service, Library of Congress.

Hernández, R., Fernández, C., & Baptista, M. (2014). Metodología de la investigación (6ª ed.). México D.F.: McGRAW-HILL. Idrovo Cristhian, Aguilar Humberto. (2012). Laboratorios Remotos: Comunicación clienteservidor y ejecución remota para las prácticas del laboratorio de control automático de la facultad de Ingeniería en Electricidad y Computación (FIEC). (Tesis de grado).

Escuela Superior Politécnica del Litoral. Ecuador Kalúz, M., Čirka, Ľ., Valo, R., & Fikar, M. (2014). ArPi lab: A low-cost remote laboratory for control education. IFAC Proceedings Volumes, 47(3), pp. 9057-9062. doi: 10.3182/20140824-6- ZA-1003.00963

95

Khurana, H., & Sohal, J. (2011). Agile: The necessitate of contemporary software developers.

International Journal of Engineering Science & Technology, 3(2), pp. 1031-1039.

Kniberg, H. (2007). Scrum y XP desde las trincheras. C4Media Inc. InfoQ. Labshare.

(4

de

Noviembre

de

2017).

Labshare

-

Service.

Obtenido

de

http://www.labshare.edu.au/about/services Llamas, L. (28 de Marzo de 2018). Ingeniería, informática y diseño. Obtenido de https:// https://www.luisllamas.es/salida-analogica-mediante-pwm-y-filtro-paso-bajo/ López, I., Castellano, M., & Ospino, J. (2014). Bases de datos. México: Alfaomega Grupo Editor.

López, M. (2013). Aprendizaje, competencias y TIC. México: Pearson Educación.

López, M., Vara, J., Verde, J., Sánchez, D., Jiménez, J., & De Castro, V. (2012). Desarrollo Web en Entorno Servidor. Madrid: RA-MA Editorial.

MariaDB Foundation. (2 de Noviembre de 2017). About MariaDB - MariaDB.org . Obtenido de mariadb.org: https://mariadb.org/about/ Medina, M., & Barquero, J. (2013). 20 competencias profesionales para la práctica docente.

México D.F.: Trillas. mit

iCampus.

(4

de

Noviembre

de

2017).

iLabs.

Obtenido

de

http://icampus.mit.edu/projects/ilabs/ Navarro, A., Fernández, J., & Morales, J. (2013). Revisión de metodologías ágiles para el desarrollo de software. Prospect, 11(2), pp. 30-39.

Orós, J. (2013). Guía práctica de XHTML, JavaScript y CSS. México: Alfaomega Grupo Editor.

Parkhomenko, A. V., Gladkova, O., Ivanov, E., Sokolyanskii, A., & Kurson, S. (2015).

Development and application of remote laboratory for embedded systems design.

International Journal of Online Engineering (iJOE), 11(3), pp. 27-31.

Paucar, E. (27 de agosto de 2014). Las competencias STEM el desafío de la nueva educación.

El Comercio. Obtenido de http://www.elcomercio.com/tendencias/competenciasstem-desafio-educacion.html

96

PHP. (31 de Octubre de 2017). PHP: ¿Qué es PHP? - Manual. Obtenido de php.net: http://php.net/manual/es/intro-whatis.php Platzi.

(25

de

Marzo

de

2018).

Platzi.

Obtenido

de

https://platzi.com/django/tutoriales/realtime-django-con-celery-for-dummies/ PostgreSQL. (2 de Noviembre de 2017). PostgreSQL: About. Obtenido de postgresql.org: https://www.postgresql.org/about/ Pressman, R. (2010). Ingeniería del software: Un enfoque práctico (7ª ed.). México: McGraw-Hill Educación.

Python Software Foundation. (29 de Octubre de 2017). About Python. Obtenido de python.org: https://www.python.org/about/ Raspberry Pi Foundation. (29 de Octubre de 2017). Raspberry Pi 3 Model B. Obtenido de https://www.raspberrypi.org/products/raspberry-pi-3-model-b/ Rubiales, M. (2013). HTML5, CSS3 y JavaScript. Madrid: Grupo Anaya S.A. Schwaber, K., & Sutherland, J. (Julio de 2016). La guía Scrum. Obtenido de https://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-SpanishEuropean.pdf Scrum Alliance. (29 de Octubre de 2017). Scrum Alliance - Learn About Scrum. Obtenido de scrumalliance.org: https://www.scrumalliance.org/why-scrum#why-its-called-scrum Scrumdesk.

(17

de

Enero

de

2018).

Scrumdesk.

Obtenido

de

https://www.scrumdesk.com/agile-estimation-principles/planning-poker/ SENPLADES (Secretaría Nacional de Planificación y Desarrollo). (2013). Plan Nacional para el Buen Vivir 2013-2017. Quito, Ecuador: SENPLADES Sommerville, I. (2011). Ingeniería de software (9ª ed.). México: Pearson Educación.

SQLite.

(2

de

Noviembre

de

2017).

About

SQLite.

Obtenido

de

sqlite.org:

https://www.sqlite.org/about.html Torrente, Ó. (2013). Arduino curso práctico de formación. México: Alfaomega Grupo Editor.

Wells,

D.

(26

de

Octubre

de

2017).

Extremeprogramming.org.

http://www.extremeprogramming.org/when.html

Obtenido

de

97

9.

GLOSARIO

AJAX Acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es una técnica de desarrollo web para crear aplicaciones que se ejecutan en el lado del cliente mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas.

ASGI (Asynchronous Server Gateway Interface) es la especificación sobre la que se basan los channels, diseñada para desvincular las aplicaciones channel de un servidor de aplicaciones específico y proporcionar una forma común de escribir código y aplicaciones middleware.

Bash (Bourne-again shell) es un programa informático, cuya función consiste en interpretar órdenes, y un lenguaje de consola. Fue uno de los primeros intérpretes importantes de Unix.

Commit Es un comando dentro de la herramienta Git, que al efectuarlo forma un grupo de cambios sobre uno o varios ficheros, con una descripción, una fecha, un autor, etc. Ejemplo: git commit –m “Descripción”.

CSI (Camera Serial Interface) Es un puerto de quince pines, que se dispone en la placa Raspberry Pi para la conexión de un módulo de cámara desarrollada por la fundación.

Framework Es una estructura conceptual y tecnológica de asistencia definida, normalmente, con artefactos o módulos concretos de software, que puede servir de base para la organización y desarrollo de software.

98

Github Es una plataforma de desarrollo colaborativo para alojar proyectos utilizando el sistema de control de versiones Git. Se utiliza principalmente para la creación de código fuente de programas de computadora.

HTTP Abreviatura de la forma inglesa Hypertext Transfer Protocol, que significa protocolo de transferencia de hipertextos, se utiliza en algunas direcciones de internet.

IDE Entorno de desarrollo integrado (Integrated Development Enviroment por sus siglas en inglés), es una aplicación informática que proporciona servicios integrales para facilitarle al desarrollador o programador el desarrollo de software.

Middleware Lógica de intercambio de información entre aplicaciones, es un software que asiste a una aplicación para interactuar o comunicarse con otras aplicaciones, o paquetes de programas, redes, hardware y/o sistemas operativos. Éste simplifica el trabajo de los programadores en la compleja tarea de generar las conexiones y sincronizaciones que son necesarias en los sistemas distribuidos.

MVC Es un estilo de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos, en español significa Modelo Vista Controlador.

Sketch Es un programa de Arduino y tiene la extensión .ino, su estructura básica consta al menos de dos partes, que son obligatorias y encierran bloques que contienen instrucciones: void setup() y void loop().

99

Streaming También denominado transmisión por sus siglas en inglés, es la distribución digital de contenido multimedia a través de una red de computadoras. Se refiere a una corriente continua que fluye sin interrupción, y habitualmente a la difusión de audio y video.

UNIX Es un sistema operativo portable, multitarea y multiusuario; desarrollado en 1969 por un grupo de empleados de los laboratorios Bell de AT&T. WebSocket Es una tecnología que proporciona un canal de comunicación bidireccional y full-dúplex sobre un único socket TCP. Está diseñada para ser implementada en navegadores y servidores web, pero puede utilizarse por cualquier aplicación cliente-servidor.

100

10. ANEXOS Anexo 1: Carta de intenciรณn

101

Anexo 2: Acta de entrega-recepciรณn del proyecto

102

Anexo 3: Carta de impacto

103

Anexo 4: Modelo entrevista

104

Anexo 5: Modelo encuesta

105

106

Anexo 6: Historias de usuario Historia de Usuario Número: 01

Usuario: Estudiante/Docente

Nombre historia: Señales de entrada digitales Prioridad en negocio: 100

Riesgo en desarrollo: Medio

Puntos estimados: 13

Sprint: 1

Programador responsable: Gonzalo Bonilla Bravo Descripción: Como estudiante, quiero tener señales de entrada digitales, para poder asignarlos a variables dentro del Sketch.

Criterios de aceptación: Dada las señales de entrada digitales cuando el usuario pulsa en ON, entonces se visualiza el resultado positivo en la pantalla de streaming.

Dada las señales de entrada digitales cuando el usuario pulsa en OFF, entonces se visualiza el resultado positivo en la pantalla de streaming.

Historia de Usuario Número: 02

Usuario: Estudiante/Docente

Nombre historia: Webcam remota para placa Arduino Prioridad en negocio: 90

Riesgo en desarrollo: Alto

Puntos estimados: 21

Sprint: 1

Programador responsable: Gonzalo Bonilla Bravo Descripción: Como estudiante, quiero visualizar la placa Arduino para saber si el Sketch cargado funciona correctamente.

Criterios de aceptación: Dado la visualización de la placa Arduino, cuando se compila y carga el sketch correctamente, entonces aparece el interfaz web con el streaming.

107

Historia de Usuario Número: 03

Usuario: Administrador/Docente

Nombre historia: Módulo de administración Prioridad en negocio: 80

Riesgo en desarrollo: Bajo

Puntos estimados: 13

Sprint: 1

Programador responsable: Gonzalo Bonilla Bravo Descripción: Como administrador, quiero crear, editar, eliminar y buscar usuarios y/o grupos, para poder asignar permisos.

Criterios de aceptación: Dado la creación de usuarios y/o grupos cuando selecciono el rol y doy clic en aceptar, entonces visualizo el permiso correspondiente.

Dado la edición de los datos, eliminación del usuario y/o grupo cuando pulso aceptar, entonces visualizo el cambio realizado.

Dada la búsqueda de usuario y/o grupo, cuando pulso en filtrar, entonces visualizo el resultado.

Historia de Usuario Número: 4

Usuario: Estudiante/Docente

Nombre historia: Carga Sketch Arduino Prioridad en negocio: 70

Riesgo en desarrollo: Alto

Puntos estimados: 21

Sprint: 2

Programador responsable: Gonzalo Bonilla Bravo Descripción: Como estudiante, quiero cargar el Sketch de Arduino hacia la placa, para probar el funcionamiento del programa.

Criterios de aceptación: Dado la carga del Sketch con extensión .ino, cuando pulso el botón “Enviar”, entonces aparece un mensaje de confirmación.

Dado la carga del Sketch con extensión diferente, cuando pulso el botón “Enviar” entonces, aparece un mensaje de error.

Dado la carga del Sketch, cuando pulso el botón “Compilar y cargar”, entonces aparece un mensaje de espera y al terminar me redirige al laboratorio.

108

Historia de Usuario Número: 5

Usuario: Estudiante/Docente

Nombre historia: Señales de entrada analógica Prioridad en negocio: 60

Riesgo en desarrollo: Medio

Puntos estimados: 13

Sprint: 2

Programador responsable: Gonzalo Bonilla Bravo Descripción: Como estudiante, quiero entrada de señales analógicas, para poder asignarlos a variables dentro del Sketch.

Criterios de aceptación: Dada la entrada de señales analógicas cuando giro la ruleta, entonces asigno un valor analógico determinado en dicha ruleta.

Historia de Usuario Número: 6

Usuario: Estudiante

Nombre historia: Monitor serie Arduino Prioridad en negocio: 50

Riesgo en desarrollo: Alto

Puntos estimados: 13

Sprint: 2

Programador responsable: Gonzalo Bonilla Bravo Descripción: Como estudiante, quiero visualizar la salida por consola para confirmar los resultados del Sketch.

Criterios de aceptación: Dada la visualización de la salida por consola, cuando cargo el Sketch y pulso en la señal de entrada, entonces visualizo los resultados.

109

Historia de Usuario Número: 7

Usuario: Estudiante/Docente

Nombre historia: Sistema de acceso de usuarios Prioridad en negocio: 40

Riesgo en desarrollo: Bajo

Puntos estimados: 13

Sprint: 3

Programador responsable: Gonzalo Bonilla Bravo Descripción: Como estudiante, quiero ingresar usuario y contraseña, para poder acceder al laboratorio.

Criterios de aceptación: Dado el ingreso de usuario y contraseña, cuando pulso en el botón de “Login”, entonces accedo al laboratorio.

Dado el ingreso de usuario y contraseña incorrecto y/o incompleto, cuando pulso en el botón de “Login”, entonces aparece un mensaje de error.

Historia de Usuario Número: 8

Usuario: Todos

Nombre historia: Sistema de cola Prioridad en negocio: 30

Riesgo en desarrollo: Alto

Puntos estimados: 21

Sprint: 3

Programador responsable: Gonzalo Bonilla Bravo Descripción: Como estudiante, quiero un sistema de colas, para ingresar de manera organizada a los servicios que brinda el laboratorio.

Criterios de aceptación: Dado un sistema de cola, cuando inicio sesión de manera correcta y el laboratorio no está ocupado, entonces accedo directamente al laboratorio con tiempo estimado.

Dado un sistema de cola, cuando inicio sesión de manera correcta y el laboratorio está ocupado, entonces accedo a la cola en la posición correspondiente con un tiempo estimado.

Dado un sistema de cola, cuando el Administrador inicia sesión de manera correcta y el laboratorio está ocupado, entonces accede directamente al laboratorio poniendo en cola a la persona que lo usa en ese momento.

Dado un sistema de cola, cuando el docente inicia sesión de manera correcta y el laboratorio está ocupado, entonces accede directamente al laboratorio poniendo en cola a la persona que lo usa en ese momento.

110 Dado un sistema de cola, cuando el tiempo estimado expira y no hay usuarios en la cola entonces, se le reasigna el tiempo estimado.

Dado el sistema de cola, cuando el usuario accede al sistema y el laboratorio está ocupado, entonces aparece la pantalla de streaming mientras espera en cola.

Historia de Usuario Número: 9

Usuario: Administrador

Nombre historia: Respaldo de archivos .ino Prioridad en negocio: 20

Riesgo en desarrollo: Bajo

Puntos estimados: 13

Sprint: 3

Programador responsable: Gonzalo Bonilla Bravo Descripción: Como administrador, quiero respaldos de los archivos .ino subidos por los estudiantes, para monitorizar el trabajo realizado por ellos.

Criterios de aceptación: Dado un respaldo de archivos .ino, cuando el estudiante sube el Sketch al servidor, entonces se realizar una copia en otra carpeta con el formato fecha_hora_nombreUsuario_nombreArchivo.

Historia de Usuario Número: 10

Usuario: Estudiante/Docente

Nombre historia: Refinamiento señales de entrada digitales Prioridad en negocio: 10

Riesgo en desarrollo: Bajo

Puntos estimados: 5

Sprint: 3

Programador responsable: Gonzalo Bonilla Bravo Descripción: Como estudiante, quiero entrada de señales digitales, para poder asignarlos a variables dentro del Sketch.

Criterios de aceptación: Dado las señales de entrada digitales cuando el usuario pulsa en ON, entonces se visualiza el resultado positivo en la pantalla de streaming.

Dado las señales de entrada digitales cuando el usuario pulsa en OFF, entonces se visualiza el resultado positivo en la pantalla de streaming.

111

Anexo 7: Pruebas de aceptaciรณn

112

113

114

115

116

117

118

119

120