Embed Size (px)
DESCRIPTION
Una Experiencia de Simulación en el Contexto de Sistemas de Información Presentación en JITICE 2014
Citation preview
UNA EXPERIENCIA DE SIMULACIÓN
EN EL CONTEXTO DE SISTEMAS DE
INFORMACIÓN
JITICE 2014: V JORNADAS EN INNOVACIÓN Y TIC EDUCATIVAS
MÓSTOLES, 25-26 DE NOVIEMBRE DE 2014
Carlos E. Cuesta
Paloma Cáceres García de Marina
José María Cavero
Belén Vela Sánchez
Almudena Sierra-Alonso
ÍNDICE
Introducción
Contexto: Sistemas de Información
Problema: las Prácticas de SI
El Juego de Simulación como Técnica Docente
Características Generales
Planteamiento en Informática
Experiencia: Prácticas en el Curso 2013/14
Resultados
Resultados en el contexto específico de la asignatura
Conclusiones2
INTRODUCCIÓN
La docencia práctica en Informática suele estar bien definida y adaptarse con cierta facilidad
Resolución de problemas prácticos con un ordenador
No ocurre así en todos los casos (Ing. Sw. / Sist. Inf.)
En los contextos donde este enfoque no es válido
Puede parecer poco realista o desproporcionada
A menudo se percibe como “poco práctico”
Afecta negativamente a la percepción de la disciplina
Se plantea realizarlo como un juego de simulación
Incide positivamente en la motivación del alumnado
Se describe una experiencia en un caso concreto
Simulación de BPM en contexto institucional3
CONTEXTO:SISTEMAS DE INFORMACIÓN
La disciplina de Sistemas de Información es considerada una de las cinco grandes á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, UPO
Mención del grado de Ingeniería Informática
USAL, UPV/EHU (“Gestión y SI”)4
CONTEXTO:SISTEMAS DE INFORMACIÓN
Se imparte como materia en dos grados de la 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
Hay además un Máster (online) con este nombre
Contenido de la asignatura/materia Concepto de Sistema de Información como estructura de
soporte para los procesos de una organización Destacando específicamente las grandes organizaciones
Modelado y gestión de dichos procesos (“de negocio”) Destacando la influencia del Sistema en esos procesos
Sistemas de Información Empresarial
Sistemas de Ayuda a la Toma de Decisiones5
PROBLEMA:LAS PRÁCTICAS DE SISTEMAS DE INFORMACIÓN
Resulta difícil plantear unas prácticas adecuadas al sentido de la asignatura
Una “gran organización” no deja acceso a su Sistema de Información “real” para que los alumnos practiquen
Un Sistema de Información “artificial” (no auténtico) no resulta suficientemente complejo
Cualquier simplificación causa un esfuerzo desproporcionado
La verdadera dificultad del problema EAI no se manifiesta
La infraestructura de un Sistema de Información Empresarial sin datos resulta vacía y carente de interés
El aspecto distintivo y esencial del Sistema de Información, su alineamiento con la organización, se pierde
No se influyen mutuamente ni tienen consecuencias mutuas 6
PROBLEMA:LAS PRÁCTICAS DE SISTEMAS DE INFORMACIÓN
Opciones
Prácticas de Modelado de Procesos de Negocio
La más sencilla, análoga a una práctica de Ingeniería de Software
Inconveniente: no hay alineamiento con una organización real
Prácticas con un ERP gratuito (o incluso comercial)
Tecnológicamente, tal vez la más representativa
Inconveniente: no hay datos reales con los que “jugar”
Resolver un problema de EAI a nivel de programación
Permite afrontar un problema técnicamente complejo
Inconveniente: no suele estar en el nivel de abstracción adecuado
Prácticas de análisis en un data warehouse (o similar)
Se pueden utilizar fuentes de datos públicas (opendata)
Inconveniente: no siempre es sencillo contextualizarlo para SI 7
EL JUEGO DE LA SIMULACIÓN
> COMO TÉCNICA DOCENTE
Se plantea un nuevo enfoque para la primera opción
BPM en el contexto de un juego de simulación
Los juegos de simulación
El jugador está en contacto directo con un entorno real
Aplicados frecuentemente con objetivos docentes
Existe una amplísima variedad de enfoques
Desde los muy reglamentados (p.e. similar a juego de mesa) hasta los muy abstractos (simulación oculta)
No se debe confundir con el juego de rol
El juego de rol es una dramatización
El estudiante interpreta un papel y sus reacciones son fingidas
El juego de simulación no es una dramatización
El estudiante sigue siendo él mismo, no interpreta
8
EL JUEGO DE LA SIMULACIÓN
> CARACTERÍSTICAS GENERALES (I)
En general, un juego de simulación:
Planteamiento distinto del juego de rol
Más formalizado y con relaciones más estructuradas
Vivir una situación real sin correr riesgo real
No es mecánico, sino dinámico (“adaptativo”)
Objetivo: aprender cómo reacciona el sistema real en un entorno de cambio
Abstracciones de situaciones reales complejas
Se convierten situaciones complejas en acciones simples
Reguladas por normas estrictas o bien definidas
Datos seleccionados (a menudo), circunstancias controladas
Pueden emplearse representaciones de diverso tipo
Pueden emplearse operadores humanos 9
EL JUEGO DE LA SIMULACIÓN
> CARACTERÍSTICAS GENERALES (II)
En un juego de simulación:
Cada participante asume un papel (no lo interpreta, sino que elige su lugar) dentro de la simulación
Participa en la toma de decisiones ( -> comprensión del modelo)
A menudo se plantean mecanismos de recompensas y sanciones, dentro de las reglas del modelo
Las decisiones tomadas modifican la simulación
Se plantean nuevas situaciones a partir de estos cambios
Dependen de la naturaleza de la simulación
Tiempo acelerado en la simulación
Tiene su tiempo propio, a menudo más rápido que el real
Dos objetivos globales
Reproducen la naturaleza compleja de los problemas reales
Entrenamiento en solución de conflictos
10
EL JUEGO DE LA SIMULACIÓN
> EN INFORMÁTICA
Muchas prácticas de informática pueden considerarse, en parte, un juego de simulación
Incluso en las de Programación, el alumno “simula” ser un programador profesional
En Ingeniería de Software, debe realizar todas las etapas de un proceso de desarrollo “simulado”
No obstante, en ambos casos:
No es una simulación “completa”: habitualmente el contexto es inequívocamente académico en todo momento
El énfasis en ambos casos está en los aspectos más técnicos
No hay muchas experiencias completas
El enfoque más favorable se da en Ingeniería de Requisitos
Depende del planteamiento de la práctica concreta11
EXPERIENCIA:PRÁCTICAS DE SI EN EL CURSO 2013/14
Enfoque basado en un problema de BPM
Solucionar problema de alineamiento
Modelado de los BP de una organización real
La propia Universidad Rey Juan Carlos
No los servicios académicos, sino los administrativos
Planteado como un juego de simulación
Los alumnos son ingenieros de software modelando los BP que eventualmente tendrían que definir el SI
Se captura la información de los BP mediante entrevistas
Colaboran distintos departamentos de la Universidad
Cada grupo modela los BP de un departamento distinto
Se simula así un problema característico de los Sistemas de Información: la dispersión de los SI particulares
12
EXPERIENCIA:PRÁCTICAS DE SI EN EL CURSO 2013/14
Segunda fase: integración de los modelos BP
Cada grupo conoce los resultados del resto y tiene que reinterpretar sus propios modelos en ese contexto
Han recibido feedback al final de la fase uno
Se llega a un modelado general del SI de la URJC
Se tienen que resolver los conflictos entre visiones parciales
Se ponen de relieve los principales problemas de integración
Se identifican “islas” y “cuellos de botella”
Los distintos grupos tienen que conciliar sus visiones
No tienen ocasión de comprobar si su nueva estructura coincide con los cambios planteados por otros grupos
Realizan espontáneamente la separación habitual entre funciones
Las visiones conflictivas se plantean en la propia clase
Cada grupo puede intervenir durante la presentación del resto13
RESULTADOS
Se divide la clase en grupos de distinto tamaño
Según la complejidad del departamento destino
Gestión de Alumnos (Secretaría de Campus)
Gestión de Alumnos (Rectorado)
Ordenación Académica (Rectorado)
Unidad de Prácticas Externas
Unidad de Discapacitados
Distinta experiencia según casos concretos
Procesos bien definidos, incluso en contextos complejos
Modelado sencillo y bien integrado
Procesos poco definidos, incluso en contextos sencillos
A menudo requieren un compromiso entre partes
Al menos un proceso poco estructurado (definición laxa)
Plantea una resolución muy difícil a pesar de su sencillez14
RESULTADOS
La fase de integración resulta muy significativa
Los grupos que plantean procesos muy relacionados logran una integración casi total
Gestión de Alumnos (Secretaría vs. Rectorado)
La percepción separada de las dos perspectivas de un mismo proceso generan una comprensión global del mismo
Se identifica un proceso centralizador
Prácticamente todos los BP “alimentan” a este proceso
Una gran complejidad, asumido por un único departamento
Fue la simulación realizada por el grupo más grande
Manifiesta una tendencia de control (natural en ese contexto)
Tiene el riesgo de definir un “cuello de botella”
Se identifica un proceso aislado (y poco formalizado)
Su impacto sobre el resto de procesos es prácticamente nulo15
CONCLUSIONES
Experiencia muy positiva
Una práctica recibida a menudo como “rutinaria” tuvo una recepción muy dinámica
Motivación muy alta de (casi) todos los grupos
Resultados mucho más realistas que en la práctica típica
La realimentación de la primera fase resulta decisiva
Los resultados de la segunda fase resultan mucho mejores
La resolución de “conflictos” hace destacar los aspectos más complejos con facilidad
La calificación global de la asignatura es más alta
Generalización – inconvenientes
Es difícil repetir esta práctica (sin reiterar el contexto)
Deseable poder realizarla en un entorno menos académico16
GRACIAS POR SU ATENCIÓN
17
