Desde hace muchos años, muchos, cuando se intentó, con un éxito yo diría que mediano, convertir la ingeniería de software en eso, una ingeniería, y hacer de la creación, despliegue y operación del software un proceso productivo más o menos similar al industrial, se han intentado definir metodologías que consigan esa operativización.
Desde las primeras metodologías funcionales, seguidas de las orientadas a objetos todas ellas bajo el marco, en general, del algo injustamente denostado modelo en cascada, hasta los modernos (bueno, en realidad tampoco tan modernos) enfoques agile en que se pierde parte de esa visión industrial y de línea de producción para centrarse en un enfoque más adaptativo, se ha intentado estructurar el proceso de definición, construcción, despliegue y operación.
Ingeniería software y necesidad de adaptaciones
El caso es que, el software se encuentra hoy en día omnipresente. Pero esa omnipresencia hace que existan variantes del software de circunstancias bastante diferenciadas que parecen reclamar ciertas adaptaciones metodológicas. Por ejemplo, la creciente introducción de características ‘low-code‘ o ‘no-code‘ apuntan a la necesidad de una cierta revisión (quizá ligera) a unas metodologías pensadas para un proceso productivo que en su mayor parte tenía que ver con la edición de código fuente, compilación y prueba.
Igualmente el éxito creciente del modelo DevOps supone en sí mismo una cierta adaptación o reflexión sobre la metodología tradicional.
En realidad, al menos hasta donde yo lo percibo, esas revisiones no afectan realmente al ‘core’ de las metodologías y sus planteamientos, ni de las tareas básicas a realizar, pero pueden llevar a ciertos ajustes o addendas. Así, por ejemplo, cuando se intentan definir metodologías para RPA (Robotic Process Automation) en el fondo, el marco general es el de la ingeniería de software (en general con un enfoque más predictivo que agile) pero con pequeños detalles, como la introducción de elementos de BPM (Business Process Management) o la definición, en el diseño, de los mecanismos de escalabilidad de robots. En el fondo, es básicamente ingeniería de software, más o menos la de siempre…pero con ciertas adaptaciones.
Metodología para ciencia de datos y machine learning
Un poco con esa idea, voy a resumir, en este artículo y alguno que siga, algunos planteamientos metodológicos relativos al machine learning y la ciencia de datos. No pretendo ser exhaustivo (para eso existen fuentes mucho más completas) sino, más bien, señalizar algunas metodologías o planteamientos que puede resultar interesante conocer.
Si en el caso de RPA lo que de alguna manera marca la necesidad de revisión metodológica en su orientación a la automatización de procesos/tareas y su carácter low-code, en el caso del machine learning / ciencia de datos, lo que marca la diferencia son los datos y sus especiales necesidades de comprensión y procesamiento.
El modelo CRISP-DM
En el artículo de hoy voy a mencionar, brevemente el modelo CRISP-DM cuyas siglas significan Cross Industry Standard Process for data Mining, un modelo definido por NCR, Daimler Chrysler y SPSSS (actualmente integrada en IBM).
El hecho de que aparezca el termino Data Mining ya nos avisa de dos cosas. Por un lado de que se trata de un marco metodológico con ciertos años (se definió en 1999) y que está muy orientado a la analítica y la obtención de modelos basados en datos y no es un planteamiento tan válido, entiendo, para otros usos del machine learning y de la inteligencia artificial..
El caso es que, según nos explica Jaume Miralles en su libro ‘Proyectos de Inteligencia Artificial‘, se trata, al menos así era en 2014, de la metodología más utilizada en Data Mining, aunque con ciertas adaptaciones dependiendo de si se emplea en una analítica descriptiva, machine learning, deep learning o con el uso de AutoML (del cual hablaremos en algún momento).
CRISP-DM establece fundamentalmente un modelo de proceso que es de naturaleza jerárquica, comenzando por el nivel fase y luego bajando a tareas genéricas, tareas específicas e instancias de proceso según se puede ver en la figura superior.
A lo largo del documento de definición de la metodología ‘CRISP-DM 1.0‘ se van desgranando esos diferentes niveles. A modo de ilustración se muestra el gráfico de descomposición de la fase de ‘Data Preparation‘ en el que la fase se descompone en tareas genéricas como selección de datos, limpieza de datos, construcción de datos, integración de datos y formateado de datos.
Fases de CRISP-DM
El método propuesto por CRISP-DM incluye, en el nivel jerárquico superior, seis fases, a saber:
- Business Understanding: Se trata de entender los objetivos del proyecto y los requisitos desde un punto de vista de negocio y convertir esas necesidades en un plan de data mining.
- Data Understanding: Se realiza una recolección inicial de datos con la intención de familiarizarse con ellos, detectar problemas de calidad del dato, obtener ya alguna conclusión o ‘insight‘ preliminar y, eventualmente, descubrir subconjuntos de datos interesantes.
- Data Preparation: Construye, a partir de los datos en bruto, los conjuntos de datos (‘datasets‘) que alimentarán finalmente los modelos. Incluye la selección de datos, su limpieza, transformación, etc
- Modeling: Quizá la fase central (aunque no necesariamente la que más tiempo ocupa) y que consiste en la selección y aplicación de diferentes modelos de machine learning / data mining. Con frecuencia, y durante esta fase, se plantea la necesidad de retomar la fase anterior para adaptar o refinar datos.
- Evaluation: Se trata de valorar si los modelos construidos satisfacen las necesidades de negocio. Al final de esta fase se decide si los resultados obtenidos consiguen los objetivos perseguidos y si, por tanto, se puede pasar a desplegarlos.
- Deployment: Una fase más técnica y de software que consiste en desplegar los modelos definidos para que puedan ser usados ya en los procesos de análisis y decisión de la compañía.
Conclusión
Como se puede observar, algunas fases de CRISP-DM recuerdan a la de la ingeniería de software tradicional. Así, ‘Business Understanding‘ no parece muy diferente del Ánálisis de requisitos ‘de tda la vida’. En ‘Evaluation‘ nos encontramos también con elementos similares a las pruebas de aceptación de usuario, especialmente en sus aspectos de validación de negocio y de decisión de ‘go – no go‘ a producción. Y el ‘Deployment‘ es plenamente un despliegue de software.
A cambio, y como elemento claramente diferencial, está todo el foco en los datos y modelos que ocupa las fases centrales.
Como casi todas las metodologías, en el fondo, se trata simplemente de orden y sentido común, sin que sorprendan las ideas, las fases o tareas que se proponen.
Pero, en el fondo, de eso es de lo que se trata: de poner orden y aplicar buenas prácticas. Ni más ni menos.
En próximos artículos, exploraremos algún otro planteamiento metodológico en el entorno de la ciencia de datos y el machine learning.
