Experimentación Ondas Cerebrales

Recientemente tuvimos la oportunidad de experimentar un poco con un sensor de ondas cerebrales (Emotiv Insight) que nos ha servido de introducción al fascinante mundo de los BCI (Brain-Computer Interface)

El proyecto que nos trajo a este punto trata de desarrollar formas de comunicación adicionales para personas con algunas dificultades físicas para comunicarse, incluyendo peronas con dificultades para el habla, la escucha o diversos niveles de parálisis cerebral.

En este artículo quiero condensar un poco una propuesta para una metodología de experimentación que nos permita capturar datos de este tipo de dispositivos y que sirvan de insumo para crear modelos de aprendizaje de máquinas que a su vez nos lleven a desarrollar modelos de interpretación de las ondas y por ende los deseos o necesidades de las personas.

Metodología de Experimentación

  1. Definir un repositorio para la documentación oficial de cada experimento y para los resultados de los experimentos.
  2. Definir personas y roles: facilitador, sujeto de experimentación, observadores.
  3. Definir objetivos y metas del experimento
  4. Definir características de los sujetos de experimentación.
  5. Definir un ambiente controlado para minimizar los estímulos no esperados y el ruido
  6. Establecer un guión o protocolo de pasos, tiempos y clases para el experimento,
    1. Definir tareas a realizar: preparación, arranque, ejecución, finalización y cierre.
    2. Identificar estímulos Intencionales: preparación, arranque, ejecución, finalización, cierre
    3. Identificar estímulos no intencionales: derivados, ruido aceptable, ruido no aceptable (invalidación temprana del experimento)
  7. El resultado de cada experimento será un archivo con la información sensada y la pre-clasificación de los diferentes eventos o estímulos ocurridos detectados por el observador. Este archivo se usará para generar modelos de aprendizaje de máquinas que nos permitan estudiar y entender los fenómenos documentados en cada experimento.

Como siempre, sus comentarios para enriquecer esta metodología serán de gran valor para nosotros.


Haga clic acá para una plantilla de ejemplo


Algunas Referencias Interesantes:

En mi experiencia – Un resumen sobre SCRUM

La administración de proyectos es una de las actividades más importantes de quehacer humano. En gran medida, la administración de proyectos determina el éxito o fracaso de proyectos y hasta de organizaciones enteras.

En la actualidad la administración de proyectos ha evolucionado de modelos como Waterfall, donde un gerente de proyecto establece un cronograma y dirige un conjunto de personas para cumplirlo al final de dicho cronograma, a modelos más iterativos donde los roles de administración de proyecto y de equipo han sido completamente redefinidos; dando lugar a interacciones de equipo de trabajo más ricas y productivas. Uno de estos modelos es SCRUM.

También pueden ver nuestro artículo: Realizando un Proyecto en SCRUM exitoso en 7 pasos

[toc]

El siguiente mapa mental ilustra los principales elementos que componen la metodología SCRUM:

En resumen

Proceso Iterativo

El modelo SCRUM permite llevar adelante proyectos simples y complejos mediante un proceso iterativo de planeamiento y ejecución, donde los equipos de trabajo son redefinidos para cubrir roles específicos como SCRUM Master, dueño de producto y ejecutores. Cada iteración usualmente se extiende por dos o tres semanas.


¿Qué es el proyecto? un conjunto de historias de usuario o metas

Un proyecto es entonces un conjunto de metas definidas por el dueño de producto (muchas veces con ayuda del equipo de ejecución). Cada meta (también llamada historia de usuario) se define en términos de descripción y criterio de aceptación.

Un ejemplo de una historia de usuario hipotética es el siguiente:

  • Descripción: Como cliente de uber, quiero poder pagar en efectivo
  • Criterio de aceptación:
    • La aplicación móvil tiene un botón para que el usuario escoja el medio de pago entre su tarjeta o efectivo
    • Cuando el usuario elige pagar en efectivo su tarjeta no es debitada con el costo del viaje
    • El conductor tiene un mecanismo para dar fe en su aplicación de haber recibido el dinero del pago

Esta lista de historias de usuario  es luego revisada por el equipo de ejecución para estimar a grosso modo el esfuerzo requerido para realizar cada una de ellas. Esta estimación de esfuerzo se hace en puntos relativos (1,2,3,5,8,13) . La siguiente lista muestra un ejemplo de la equivalencia de los puntos al esfuerzo requerido:

  • 1 punto: La historia de usuario se puede completar en 8 horas o menos con ningun riesgo previsible de extender su ejecución y ninguna dependencia externa.
  • 2 puntos: La historia de usuario se puede completar en 16 horas o menos y/o involucra una nivel bajo de riesgo y/o pocas dependencias externas.
  • 3 puntos: La historia de usuario se puede completar en 32 horas o menos y/o existen riesgos razoables de complejidad o dependencias externas.
  • 5 puntos: La historia de usuario se puede completar en 60 horas o menos  (más de una semana) y/o involucra riesgos importantes en complejidad o dependencias externas.
  • 8 puntos: La historia de usuario se puede completar en 80 horas o menos (dos semanas) y/o involucra riesgos críticos en términos de complejidad o dependencias externas.
  • 13 puntos: La historia de usuario se puede completar en 80 horas o más  (tres semanas o más) y/o involucra demasiados riesgos gríticos, demasiada complejidad o demasiadas dependencias externas.

Normalmente cuando una historia de usuario se estima en 5 puntos o más, se realiza el ejercicio de dividirla en historias de usuario más pequeñas que puedan ejecutarse en menos de una semana cada una.

Como nota final, existen dos tipos de historia de usuario: las historias de negocio y las historias de investigación (SPIKES). Las historias de investigación normalmente miden 2 a 3 puntos, tienen como objetivo aprender cómo se hace algo (crear conocimiento en el equipo)  y culminan con documentación sobre el resultado de la investigación y posiblemente nuevas historias de negocio a ser ejecutadas en iteraciones posteriores.

Al conjunto de historias de usuario que definen un proyecto se le llama “backlog”


Iteraciones, tareas y ejecución

Cada iteración de dos o tres semanas se inicia con un proceso detallado de planeamiento donde cada historia de usuario del backlog que se vaya a trabajar en la iteración es desglosada en tareas y miembros del equipo que realizarán cada tarea, más una estimación en horas del esfuerzo necesario para realizar cada tarea.

Al conjunto de historias  de usuario y tareas elegidas o planeadas para ejecutarse en una iteración se le conoce como el compromiso del equipo en esa iteración. El equipo entonces hará todo lo necesario para cumplir con su compromiso para con el cliente o el dueño del producto; incluyendo trabajos interdisciplinarios, investigaciones, sesiones de trabajo, etc.

Una historia de usuario se considera terminada cuando (1) todas sus tareas han sido completadas con éxito, (2) se han cumplido todos los criterios de aceptación y por ende ha sido aceptada por el dueño de producto y (3) la historia de usuario cumple con la definición de terminado que normalmente incluye documentación, integración de resultados, demostraciones, pruebas, etc.


Rituales o Ceremonias

Se dice que la vida del ser humano está definida por sus rituales, por aquellas cosas que realiza frecuentemente. Por ejemplo una persona que tiene el ritual de levantarse a las 4 de la mañana a correr tiene una definición de vida diferente de una persona que tiene el ritual de levantarse a las 8am a tomar capuccino dulce.

Los principales rituales del modelo SCRUM inclyen:

  • Planeamiento Incremental del Producto: Es cuando se revisa el backlog en equipo y se determinan los cambios necesarios (remover historias de usuario, agregar nuevas historias de usuario, nuevas dependencias, etc.)
  • Poda del backlog (grooming): Es cuando se realiza la estimación de cada historia de usuario en términos de puntos. Para esto el equipo (incluyendo el dueño del producto) se reunen por dos o más horas y revisan la definición de cada historia, el criterio de aceptación de cada historia y la definición de “terminado” adoptada por el equipo.
  • Planeamiento de Iteración: En esta ceremonia de aproximadamente 1 a 2 horas se planea la itereación siguiente. Normalmente se realiza inmediatamente después del cierre de la iteración anterior. Aquí se identifican (1) aspectos limitantes como la disponibilidad de cada miembros del equipo, vacaciones, etc; (2) las historias de usuario que se trabajarán en la iteración siguiente y (3) las tareas específicas y la estimación en horas de cada tarea. De nuevo, al conjunto de historias de usuario y tareas de una iteración se le conoce como el compromiso del equipo.
  • Reunión de Actualización Diaria (DSU): Esta es una ceremonia de máximo 15 minutos donde cada miembro del equipo comunica sus avances, la ayuda que pudiera necesitar y sus planes para el día. Es importante aclarar que un DSU donde nadie necesita ayuda es probablmente un DSU demasiado superficial.
  • Cierre de Iteración: En esta sesión normalmente de 1 hora se da por concluida una iteración y se identifican logros, correcciones de equipo necesarias y planes. Normalmente se realiza junto con el Planeamiento de Iteración en una sesión conjunta que ronda de 2 a 3 horas.
    • Demostraciones: Cada miembo del equipo demuestra sus logros de la iteración.
    • Retrospectiva: Esta ceremonia tiene como objetivo la mejora continua del equipo. Acá cada miembro del equipo expresa qué cosas considera que el equipo debería (1) dejar de hacer, (2) continuar haciendo/profundizando y (3) comenzar a hacer; especialmente con miras a la parte del compromiso de iteración que no se haya logrado o a las dificultades que se enfrentaron durante la iteración.
    • Movimientos de historias de usuario no terminadas a la iteración siguiente

Estado del Proyecto, Métricas y Velocidad de Equipo

Como ya mencionamos un proyecto es definido como el conjunto de historias de usuario que componen el backlog y por sus recursos, es decir el equipo de ejecución.

El tamaño del backlog se define como la suma de los puntos asignados a todas las historias de usuario del backlog.

Luego de tres iteraciones es probable que el equipo de ejecución sea capaz de preveer cuantos puntos pueden ejecutar por iteración. Esta métrica es importante para el proyecto por que permite estimar en el tiempo la duración aproximada del proyecto.

Así, si un backlog mide 100 puntos, y la velocidad del equipo es de 10 puntos por iteración de dos semanas, se puede preveer que se requerirán al menos 10 iteraciones para completar el proyecto, es decir 20 semanas o lo que es lo mismo 5 meses.

Estas métricas aparte de ser muy simples permiten también conocer en el tiempo el estado del proyecto, tanto respecto a la iteración que se está ejecutando (cuantos puntos han sido aceptados, cuantos puntos están siendo ejecutados (WIP), cuantos puntos no se han empezado) así como respecto al proyecto como un todo (cuantos puntos se han ido ejecutando por iteración, cuantos puntos faltan para completar el proyecto, incrementos o disminuciones de velocidad de equipo en el tiempo, etc.)


Enlace a Plantilla

Como un aporte final les adjunto este enlace donde resumo los roles, ceremonias y presento una plantilla para un backlog de historias de usuario.

También en esta plantilla muestro la construcción de un gráfico de “burn-down” que permite visualizar el avance de la iteración vs el ideal esperado.

 

Espero que les sea de utilidad.

Enlace de Google Sheets. Plantilla SCRUM (haga clic acá)

 

 

Algunos conceptos interesantes de Machine Learning usando Anaconda / Python

Continuando con nuestras recientes publicaciones sobre “Machine Learning” (artículo anterior sobre fundamentos), en esta oportunidad compartimos algunas cosas que hemos aprendido siguiendo el tutorial “Machine Learning in Python Step by Step“.

Para poder entender este artículo recomendamos seguir el tutorial paso a paso… no se toma más de 30 minutos.

  1. Anaconda: Aprendimos que se puede configurar un ambiente relativamente completo para experimentación con Machine Learning y Python usando Anaconda.
  2. Dataset IRIS: Existe un “Hello World” para Machine Learning basado en un dataset llamado “IRIS” 3. Este consiste en un conjunto de datos que describe tres tipos de flores Iris (setosa, virginica y versicolor) por las dimensiones de su sépalo y pétalo; se puede usar para entrenar un modelo de aprendizaje de máquina para que este infiera el tipo de flor (clasificación) con base en la combinación de parámetros.
  3. Arreglos: Python provee mecanismos para expresar y manipular arreglos de forma sumamente robusta. Podemos resumirlos de la siguiente manera:
    • Básicamente [a:b,c:d] donde a:b representa un rango de filas y c:d representa otro rango de columnas.
    • array[:,0:4] retorna todas las filas de la matriz y las primeras 4 columnas a partir de la columna cero.
    • array[:,4] retorna todos los elementos (filas) de la quinta columna (índice 4)
      
      
  4. Entrenamiento y Validación: El entrenamiento y validación de modelos de aprendizaje de máquinas usualmente suele dividir los datos conocidos en 80% para aprendizaje o creación del modelo y 20% para validación del modelo generado. En este tutorial se usa la función model_selection.train_test_split(X,Y, test_size, random_state) de la libreria sklearn.
  5. SKLEARN LIB: Existen diversos algoritmos de clasificación en la librería sklearn:
    1. LogisticRegression
    2. LinearDiscriminationAnalysis
    3. KNeighborsClassifier
    4. DecisionTreeClassifier
    5. GaussianNB
    6. SVM/SVC
  6. Precisión de Los Algoritmos: Diferentes algoritmos presentan diferentes niveles de precisión dependiendo del problema a resolver. Estos se pueden evaluar usando funciones como model_selection.cross_val_score que da como resultado medidas estadísticas como la media y la desviación estandar. Esta validación se puede confirmar con gráficos de tipo box charts, scattered matrix e histogramas. Estos gráficos se generan en python usando librerías como matplotlib
  7. Aprender y Predecir: Una vez entrenado el modelo (con knn.fit()) se pueden generar predicciones (knn.predict())
  8. Matriz de Confusión: Las predicciones pueden ser validadas mediante mecanismos como confusion_matrix que provee una análisis simple de valores esperados y valores predichos de manera correcta y errónea.
    • La matriz de confusión tiene un eje (x) que representa los valores conocidos, y un eje (y) que representa los valores predichos.
      setosa     ==> [[ 7   0   0]
      versicolor ==>  [ 0  11   1]
      virginica  ==>  [ 0   2   9 ]]
                        se  ve  vi
    • Esto se interpreta así:
      • Se identificaron 7 setosas adecuadamente.
      • De las 12 versicolor se identificaron 11 correctamente y una como virginica
      • De las 11 virginicas se identificaron 9 correctamente y 2 como versicolor.

Referencias:

  1. Machine Learning Step by Step: https://machinelearningmastery.com/machine-learning-in-python-step-by-step/
  2. Confusion Matrix: http://scikit-learn.org/stable/auto_examples/model_selection/plot_confusion_matrix.html
  3. IRIS: https://es.wikipedia.org/wiki/Iris_flor_conjunto_de_datos
  4. Iris Setosa Imagehttps://www.rhs.org.uk/Plants/9355/Iris-setosa/Details