Ingeniería de Requerimientos en Proyectos de Ciencia de Datos

Bera Group

En ingeniería de software, antes de construir o diseñar cualquier proyecto, se lleva a cabo un proceso de reuniones y especificaciones de lo que el software a desarrollar debe y no debe hacer. Este es un proceso que en algunos casos es muy breve y en otros llega a tomar un tiempo considerable. Recientemente, estuve involucrado en realizar esta fase de ingeniería de requerimientos como parte de mi proyecto de grado, y siguiendo el mismo sendero del artículo de Favio Vázquez “Aprende a escuchar” y el episodio “Asking Good Questions as a Data Scientist” del webinar Data Science Live de Kristen Kehrer y Favio, en este artículo presento mi experiencia interactuando y haciendo preguntas con un stakeholder para mi proyecto de ciencia de datos desde una perspectiva un poco más de ingeniería de software.

Introducción y Contexto

El nombre de mi proyecto de grado es “Using Data Mining Techniques to Analyze and Predict Road Traffic Accidents in Barranquilla” y básicamente trata de utilizar datos públicos sobre accidentes de tráfico en la ciudad para diseñar un software de ciencia de datos tipo plataforma (DSaaP) con la intención de que no solo se pueda entender mejor el fenómeno de los accidentes en la ciudad, sino que también pueda hacerse una predicción de la frecuencia de los mismos teniendo en cuenta factores específicos de la ciudad. Como parte del proceso académico se debe contactar con un posible cliente (preferiblemente experto en el tipo de negocio donde se ubica el proyecto) y llevar a cabo un proceso de ingeniería de requerimientos de software, éste incluye fases de estudio de viabilidad, obtención, especificación y validación de requerimientos. En este artículo explicaré cómo se pueden aplicar algunas técnicas propias de esta metodología para un proyecto de ciencia de datos utilizando como ejemplo mi proyecto final.

Metodología para Proyectos de Ciencia de Datos

La metodología de trabajo utilizada para el proyecto es CRISP-DM (Cross Industry Standard Process for Data Mining) y la fase en la que nos ubicamos en este artículo es la primera, entendimiento del negocio (Business Understanding)

CRISP-DM es una metodología iterativa, quiere decir que los pasos no expresan un flujo lineal riguroso de las fases, y que cada proyecto puede requerir una cantidad de iteraciones diferente para cada tarea.

Según los expertos Foster Provost y Tom Fawcett, en esta fase es vital comprender los marcos de trabajo del cliente con la intención de diseñar la solución al problema como un conjunto de subproblemas que involucren la utilización de técnicas como clasificación, regresión o clustering.

A grandes rasgos las preguntas que se deberían tratar de resolver son, por ejemplo, ¿Qué se debe hacer exactamente en la compañía?, ¿Qué partes del contexto empresarial contribuirían con el diseño de la solución?

Si relacionamos lo anterior con la ingeniería de software, se podría hacer una analogía con el estudio de viabilidad. En él se comprende una evaluación y reportaje a un conjunto de preguntas que intentan determinar si el sistema a desarrollar (en nuestro caso el proyecto de ciencia de datos) realmente contribuye a los objetivos del negocio.

Así, podríamos agregar a las preguntas propuestas inicialmente por Provost y Fawcett las siguientes interrogantes del estudio de viabilidad del software:

• Teniendo en cuenta los objetivos generales de la compañía, ¿contribuye el proyecto a facilitar la realización de ese objetivo?
• ¿Cómo puede integrarse el proyecto a otros que existen en la organización?
• ¿Cuáles son los problemas actuales en los procesos?¿Cómo este proyecto los resuelve?
• ¿A qué NO necesita ayudar el proyecto?

Inicio del proyecto

Una vez se ha determinado que el proyecto es viable y realmente aporta a los objetivos de la compañía (incluyendo ya unas ideas generales de los subproblemas a solucionar) es necesario identificar las preguntas correctas para el análisis, más que todo porque hasta este punto se tiene una idea muy amplia del problema y de la pregunta inicial a la que como científicos de datos el gerente del proyecto nos ha pedido solucionar, pero como dice Kirill Eremenko en su libro, esa pregunta debe ser primero entendida, deconstruida y analizada. Algunas preguntas importantes cuya solución podrían ayudar a un mejor entendimiento de la verdadera pregunta a solucionar con el proyecto son:

• ¿Cómo ha solucionado la competencia problemas similares al que se pretende abordar?
• ¿Cómo obtiene la compañía sus datos?¿Qué métodos usa para recolectarlos?
• ¿Cuáles son los indicadores clave de rendimiento (KPI) de los proyectos en la misma área?
• ¿Qué características o patrones del contexto sería importante tener en cuenta para solucionar el problema? (pueden ser simples hipótesis o corazonadas)

Las anteriores preguntas llevadas al contexto de la ingeniería del software serían un equivalente a la segunda fase del proceso de ingeniería de requerimientos “obtención y análisis de requerimientos” que se compone de cuatro actividades principales:

• Descubrimiento de requerimientos: Es el proceso de interactuar con los stakeholders y recolectar sus requerimientos.
• Clasificación y organización de requerimientos: Implica tomar los requerimientos del ítem anterior y clasificarlos en grupos coherentes de acuerdo a la relación entre los requerimientos.
• Ordenación por prioridades y negociación de requerimientos: Aquí se debe negociar con los stakeholders un orden de prioridades de los grupos de requerimientos.
• Documentación de requerimientos: Se crea un reporte del proceso de los requerimientos y su prioridad final.

Aplicar estas técnicas de ingeniería de software en las primeras fases servirán para mantener informados a los stakeholders del alcance y la delimitación del proyecto además de ayudar a que no se pierda tiempo en fases posteriores redefiniendo los requerimientos. Llegados a este punto lo único que resta para poner en marcha las siguientes fases del proyecto es realizar una última validación de los requerimientos, en este paso se obtendría una noción del costo y el tiempo que requerirá llevar a cabo el proyecto de acuerdo a los lineamientos de los stakeholders.

La validación de requerimientos incluye las siguientes fases:

• Verificaciones de validez: Los resultados del proyecto están acordes a los objetivos de la compañía.
• Verificaciones de consistencia: Los requerimientos definidos no deben contradecirse de ninguna forma.
• Verificaciones de completitud: Las restricciones y limitaciones están bien definidas.
• Verificaciones de realismo: Todos los requerimientos se pueden implementar con las herramientas disponibles.
• Verificabilidad: Todos los requerimientos son medibles.

Una vez se finaliza la validación de requisitos se puede continuar con el proceso normal de desarrollo del proyecto.

Ejemplo

Para digerir de forma mucho más ligera toda la información anterior, contaré como apliqué ingeniería de requerimientos en mi proyecto de grado de la universidad. Utilizando datos públicos sobre accidentes de tránsito en la ciudad (divididos en tres conjuntos de datos: detalle de la zona, detalle de las víctimas, detalle de los vehículos) inicialmente se planteó el proyecto con la intención de construir un modelo para predecir la frecuencia de dichos accidentes usando técnicas de series de tiempo como ARIMA.

Mi stakeholder es un funcionario de la entidad pública encargada del estudio y las intervenciones en la ciudad en pro de la reducción de estos accidentes, contacto que conseguí por un tercero (amigo de un amigo que conoce a alguien…).

Para este caso, el problema como tal se tenia brevemente definido como “reducir la cantidad de accidentes de la ciudad”, con este planteamiento preliminar me reuní con mi contacto para comentarle del proyecto y hacerle preguntas.

Estudio de viabilidad

Dado mi reducido conocimiento en temas de administración pública, procedí a hacerle preguntas equivalentes a un estudio de viabilidad.

• ¿Qué tipo de acciones se llevan a cabo para alcanzar los objetivos de la compañía (reducción de accidentes)?
• ¿Existe alguna necesidad que deba ser resulta en la que un proyecto como el presente pueda ayudar?

Con estas preguntas, el stakeholder pudo explicarme la forma como trabaja la entidad pública encargada de los accidentes y además me comentó que él percibe una necesidad en la capacidad de hacer simulaciones para estudios más complejos que los actuales.

Así mismo, con la descripción de los marcos de trabajo que utilizan pude determinar claramente a qué NO debería apuntar el proyecto, ésto fue realmente útil para modelar la pregunta final con la que se continuará en las siguientes fases del proyecto.

Obtención y Análisis de Requerimientos

Para este punto ya había determinado que un proyecto cómo el que tenía en mente si es significativo para el objetivo de reducir los accidentes de tránsito y pude considerar algunas modificaciones pequeñas para adaptarlo a las necesidades del stakeholder.

Seguí con la obtención y análisis de requerimientos preguntando cómo se recolectan los datos, los tipos de patrones que se consideran más significativos en los accidentes de tránsito, cómo se evalúan proyectos en la misma área y qué tipo de usuarios utilizarían la solución y para qué tareas en específico.

Especificación de Requerimientos

Estas preguntas permitieron que entendiera el contexto en el que se desenvuelve el proyecto y encaminarlo hacia una solución de utilidad. Con estas preguntas entendí que la principal problemática en la forma de trabajar es que las decisiones sobre las intervenciones en las calles se toman basadas en reportajes que arroja de un sistema que marca las zonas críticas de la ciudad conforme más accidentes ocurren (reportados por la policía de tránsito).

El proyecto entonces debe ayudar a poder predecir dichos accidentes, cosa que las intervenciones se hagan anticipándose a lo que va a pasar y no sobre lo que ya está pasando. Adicionalmente, el modelo de predicción se cambió de ARIMA a Prophet by Facebook, el cambio basado en las caracteristicas de Prophet que permitirían realizar experimentos (simulaciones) de tal forma que el modelo las tenga en cuenta a la hora de hacer las predicciones tales como puntos de cambio que representan la fecha de las distintas intervenciones que se implementarían, patrones de estacionalidad a partir de las estadísticas reportadas en otros proyectos de la industria y por ultimo el efecto de días festivos.

Habiendo dejado todo esto claro se puede seguir a las fases de desarrollo con la certeza de que se han explorado los posibles caminos para resolver el problema y se ha escogido uno en el que se han puesto de acuerdo las necesidades del problema, las anteriores soluciones y los requerimientos de los stakeholders.

Bibliografía

• Provost, F., & Fawcett, T. (2013). Data Science for Business: What you need to know about data mining and data-analytic thinking. “ O’Reilly Media, Inc.”.
• Sommerville, I. (2005). Ingeniería del software. Pearson educación.
• Eremenko, K. (2018). Confident Data Skills: Master the Fundamentals of Working with Data and Supercharge Your Career. Kogan Page Publishers.