Integrando Problemas Reales en las Prácticas de Sistemas de Información: Experimentos con Big Data

1. INTEGRANDO PROBLEMAS REALES EN LAS
PRÁCTICAS DE SISTEMAS DE INFORMACIÓN:
EXPERIMENTOS CON BIG DATA
JITICE 2015:
VI JORNADAS EN INNOVACIÓN Y TIC EDUCATIVAS
MÓSTOLES, 24-25 DE NOVIEMBRE DE 2015
Carlos E. Cuesta
Paloma Cáceres
José María Cavero
Belén Vela
Almudena Sierra-Alonso

2. ÍNDICE
 Introducción
 Entorno: Sistemas de Información – Prácticas
 Problema: dependencia del contexto – organización
 Ventaja: versatilidad del alumnado
 Propuesta: experimento de laboratorio
 Simulación, pero con problemas reales
 Experiencia: Prácticas en el Curso 2014/15
 Grado en Ingeniería del Software
 Máster Universitario en Ingeniería Informática
 Resultados
 Resultados específicos en cada asignatura
 Conclusiones 2

3. INTRODUCCIÓN
 A diferencia de otras disciplinas, la docencia práctica en
informática suele plantearse de manera simple
 No necesita materiales fungibles ni grandes espacios
 Basta tener el hardware y software (incluso libre)
 Habitualmente, basta un enfoque directo
 Siempre complementario a la docencia teórica
 Funciona muy bien en áreas muy características:
 Programación – usar un entorno/lenguaje
 Bases de Datos – usar un SGBD concreto
 Inteligencia Artificial – usar una técnica concreta
 La excepción: la “informática-en-su-contexto”
 Ingeniería de Software – los procesos de la informática
 Sistemas de Información – la informática en la organización
3

4. INTRODUCCIÓN
 Cuando la práctica “directa” no es válida:
 Simulación demasiado simple, o bien desproporcionada
 Afecta negativamente a la percepción de la disciplina
 La propia práctica se percibe como “poco pragmática”
 La materia queda ligada al contexto
 Replicar esa relación en clase resulta a menudo imposible
 La práctica no se puede concebir como neutral
 Se dedica mayor esfuerzo al entorno que a la técnica
 La simulación resulta insuficiente
 Proporciona mayor “realismo” que otros enfoques
 Pero sólo permite considerar algunos aspectos
 Proporciona una perspectiva necesariamente parcial
4

5. CONTEXTO:
SISTEMAS DE INFORMACIÓN
 La disciplina de Sistemas de Información es considerada
una de las cinco áreas de la Informática
 Ref. ACM/IEEE CC2001 y Resolución VI/2009 del MEC
 Las otras cuatro ramas son: Ciencias de la Computación,
Ingeniería de Software, Ingeniería de Computadores y
Tecnologías de la Información
 Se imparte como grado específico con el nombre:
 Sistemas de Información
 UAH, UPM
 Ingeniería de Sistemas de Información
 UAX, USP-CEU, UCH-CEU, UCAV
 Mención del grado de Ingeniería Informática
 USAL, UPO, UPV/EHU (“Gestión y Sistemas de Información”)
5

6. CONTEXTO:
SISTEMAS DE INFORMACIÓN
 Se imparte como materia en tres títulos oficiales URJC
 Grado en Ingeniería Informática
 Asignatura: Sistemas de Información
 Grado en Ingeniería de Software
 Asignatura: Ingeniería de Sistemas de Información
 Máster Universitario en Ingeniería Informática
 Asignatura: Gobierno y Auditoría de Sistemas Informáticos
 Asignatura: Sistemas de Información Empresarial
 Contenido de la materia
 Sistema de Información como estructura que da soporte a los
procesos de una organización
 Afectando áreas tales como: BPM, EAI, ERP, CRM.
 Relación directa con los almacenes de datos (DW/BI)
6

7. PROBLEMA:
LAS PRÁCTICAS DE SISTEMAS DE INFORMACIÓN
 No permite utilizar un enfoque “directo” adecuado al
sentido de la asignatura
 Una “gran organización” no proporciona su Sistema de
Información para que los alumnos practiquen
 La infraestructura de un Sistema de Información Empresarial
sin datos carece de interés
 Un Sistema de Información simulado (artificial) no resulta tan
complejo como la realidad
 Se pierde el vínculo con el contexto
 La raison d’être del Sistema de Información es precisamente
su alineamiento con la organización
 Una práctica puramente organizativa pierde la parte técnica
 Pero una puramente técnica pierde el alineamiento
7

8. EXPERIENCIA PREVIA:
PRÁCTICAS DE SI COMO SIMULACIÓN
 Planteamiento previo: un juego de simulación
 Tiene diversas ventajas (ref. JITICE 2014 
 Supone un planteamiento práctico, realista, sin riesgo
 Incide positivamente en la motivación de los estudiantes
 Inconveniente: se adapta bien sólo a un tipo de problema
 Modelado de procesos de negocio (BPM)
 No permite realizar una práctica “convencional”
 Sin embargo, los SI tienen técnicas propias
 En varios sentidos más cercanas al enfoque “clásico”
 Desarrollo ERP vs. Programación
 Integración EAI vs. Concurrencia, Sistemas Operativos
 Almacenes de datos (DW) vs. Bases de Datos
8

9. ASPECTOS A FAVOR:
UBICACIÓN DE LA ASIGNATURA
 La asignatura suele estar ubicada en los cursos finales
 Alumnos versátiles y bastante autónomos
 Se pueden usar en la práctica los recursos aprendidos en
cualquier otra asignatura
 Incluso los aspectos propios de Ingeniería de Software
 Permite mayores niveles de dificultad
 Posible plantear cuestiones que en otras serían inviables
 Se puede plantear la práctica como un “repaso general” o
una integración de recursos de aprendizaje
 Se usan otras materias integradas en un contexto global
 En el caso de nuestro experimento/experiencia
 Ingeniería de Sistemas de Información: 4º de GIS
 Gobierno y Auditoría de SI: nivel de máster (1º MUII) 10

10. HACIA UN MODELO GENERAL DE PRÁCTICA
 El enfoque directo no es suficiente
 Se pierden aspectos esenciales de alineamiento
 El enfoque de simulación tiene limitaciones
 Sólo es apto para cierto tipo de práctica
 Produce una visión parcial de la disciplina
 Es muy costoso en tiempo – anula otras opciones
 No incide especialmente en los aspectos más técnicos
 No es fácilmente repetible
 Se plantea un enfoque mixto
 Realizar una práctica más “convencional”, simulada en un
entorno “de laboratorio”
 Pero se integran en esta práctica dificultades reales
11

11. PROPUESTA:
LABORATORIO CON PROBLEMAS REALES (I)
 Tiene aspectos de dos técnicas ya planteadas
 Aprendizaje basado en problemas
 Simulación
 Pretende usar la simulación de otra manera
 El enfoque anterior se centraba en el alineamiento entre el
sistema y la organización
 Dejaba al margen la mayoría de los aspectos restantes
 Este enfoque pretende simular estos aspectos
 En especial los de índole técnica
 Se plantea un entorno de laboratorio, controlado
 Similar al de otras prácticas (“enfoque directo”)
 El realismo viene dado por la dificultad del problema 12

12. PROPUESTA:
LABORATORIO CON PROBLEMAS REALES (II)
 Se plantea la simulación con un problema real
 Deberá ser elegido según el dominio concreto de práctica
 En nuestro caso, ámbito de escalabilidad
 Aumenta la dificultad, pero se simula una situación real
 En realidad, no es una simulación: el problema es auténtico
 Aprendizaje basado en Problemas (PBL)
 Se presenta el problema, sin plantear su solución
 El alumno (típicamente en equipo) debe identificar sus
necesidades de aprendizaje
 Debe asumir su responsabilidad y tomar decisiones
 Busca la información necesaria para resolverlo
 Se vuelve al problema, y se resuelve como una práctica 13

13. PROPUESTA:
LABORATORIO CON PROBLEMAS REALES (III)
 Aprendizaje basado en Problemas (PBL)
 Incide positivamente en múltiples aspectos del proceso
 Motivación (¿por qué?)
 Aprendizaje significativo (¿para qué?)
 Mayor retención de información
 Mayor integración del conocimiento
 Autonomía + Autodirección
 Mayor trabajo para el profesor (en su rol “facilitador”)
 Varios puntos en común con el enfoque directo
 Muchas prácticas tienen aspectos en común con el BPL
 El alumno de informática/ingenierías lo asume con facilidad
 El hecho diferencial es la dificultad del problema real 14

14. PROPUESTA:
LABORATORIO CON PROBLEMAS REALES (Y IV)
 Puntos en común con otras técnicas
 Método del Caso (design thinking)
 Resolver problemas reales mediante análisis, innovación
 Hay aspectos concretos que aquí no consideramos
 No se plantea como una técnica estructurada
 La información sobre el problema a menudo es incompleta
 Planteamiento del problema real
 El alumno ha de enfrentarse al tipo de cuestiones que se dan
en la praxis real de la disciplina
 Desarrolla destrezas propias de la disciplina
 Tiene que diseñar su propia estrategia de resolución
 Este aspecto no es una simulación, sino que es real
 El resto es un experimento de laboratorio, explícitamente
15

15. EXPERIENCIA REALIZADA:
EXPERIMENTOS CON BIG DATA
 Se plantean dos casos
 Dos asignaturas: grado (último curso) y máster
 Misma naturaleza para el problema real
 En ambos casos, escalabilidad
 Contexto: se usan técnicas/cuestiones de big data
 Se diseñan específicamente para aspectos diferentes
 Para adaptarse a la naturaleza de cada asignatura
 Para comprobar la versatilidad real de este enfoque
 Primer caso: Almacén de Datos
 Asignatura del Grado en Ingeniería de Software
 Segundo caso: Implantación de Servicios TIC
 Asignatura del Máster de Ingeniería Informática
16

16. PRIMER CASO:
ALMACÉN DE DATOS (I)
 Contexto: aspectos de DW/BI
 Gestión de un Almacén de Datos (más allá de BD)
 Transformación y Análisis de Datos
 Problema Real: Volumen
 Se utilizó un dataset real, con un volumen significativo
 Las herramientas habituales no podían procesarlo
 Estructura de la práctica
 Fase 1: Se plantea el problema con todos sus detalles
 Se indican los objetivos mínimos, ampliables
 Fase 2: Cada equipo plantea sus objetivos
 Fase 3: Se proporciona una “solución parcial”
 Permite la repesca de los casos más complicados
17

17. PRIMER CASO:
ALMACÉN DE DATOS (II)
 Estructura de la práctica (cont.)
 Fase 4: Defensa pública y exposición de la solución
 Resultados obtenidos
 Experiencia muy positiva
 A pesar de la dificultad, la práctica fue muy bien acogida
 En algunos casos, incluso con entusiasmo
 Clara división entre distintos grupos
 28% - solución totalmente original
 28% - solución de muy buen nivel
 16% - solución “esperada”
 28% - recurren a la solución por defecto
 Un único grupo tuvo un mal planteamiento (parcial) 18

18. SEGUNDO CASO:
IMPLANTACIÓN DE SERVICIOS TIC (I)
 Contexto: Gobierno de las TIC
 Implantación de servicios (aspectos organizativos)
 Análisis de información y toma de decisiones
 Aplicación de estándares de Gobierno TIC
 Menos alumnos, más experimentados
 Problema Real: Volumen
 Se plantea una implantación en una organización ficticia,
pero de un servicio real
 Aun así, es esencialmente una simulación, de nuevo
 Puntos en común con la experiencia previa
 Los datos del servicio son reales
 Gestión de un gran volumen de datos
 Decidir sobre dimensión del servicio y enfoque
19

19. SEGUNDO CASO:
IMPLANTACIÓN DE SERVICIOS TIC (II)
 Estructura de la Práctica
 Fase 1: Se plantea el problema con todos sus detalles
 Fase 2: Cada equipo plantea sus objetivos
 Dos alternativas: cloud vs. on premise
 Fase 3: Entrega de la práctica (como un informe)
 Resultados
 Demasiado homogéneos: no muy creativo
 El grupo es reducido (puesta en común)
 El 100% eligen la misma solución
 Todos eligen la misma alternativa (“solución cloud”)
 Los informes son demasiado similares
 Probablemente la simulación era poco flexible 20

20. CONCLUSIONES
 El enfoque tiene indudables aspectos positivos
 La práctica en grado fue un éxito
 Mucho trabajo (por ambas partes)
 Muy bien valorada por docentes y por alumnos
 Se tocaron aspectos muy complejos
 Se incluyeron aspectos previamente no considerados
 La percepción de la asignatura mejoró notablemente
 Tan bien recibida, al menos, como el caso anterior
 Mucho más versátil (en este contexto, al menos)
 El enfoque tiene aún que mejorar
 Es (todavía) muy dependiente del contexto
 La práctica en máster no fue memorable
21

21. GRACIAS POR SU ATENCIÓN
22