Buscando la bala de plata de la industria del software

Introducción

Para quienes no son técnicos, un proyecto de software puede parecer un paso simple y directo para su negocio. Lamentablemente, ignoran una verdad básica: desarrollar software no es para nada sencillo.

El presente artículo tiene por objetivo plantear una serie de herramientas surgidas de la experiencia que nos acercan a resolver la paradoja planteada por Frederick P. Brooks –ganador del Premio Turing, el reconocimiento anual que otorga la Association for Computing Machinery de Estados Unidos– en su artículo “No hay balas de plata: lo esencial y lo accidental de la ingeniería del software”, publicado en 1986, donde plantea que la ingeniería del software era tan compleja que, en los siguientes diez años, no surgiría ninguna técnica única o “bala de plata” capaz de producir un avance de orden de magnitud en la productividad de la ingeniería en sistemas. Tenía razón.

Las dificultades esenciales

El proceso de desarrollo de software está plagado de dificultades desde una conceptualización del problema errónea, los constantes cambios en los requerimientos o en el contexto del cliente, etc.

Es clave entender que el software se crea en la mente de los desarrolladores, que es un producto intelectual. Luego, con buenas prácticas y estándares, se traducen a un lenguaje de programación y a un sistema, agregando una capa de dificultades a una criatura esencialmente compleja. Es como que existe una cierta dosis de arte, que deja una huella única, en el desarrollo de software.

Volviendo al artículo, Brooks habla de la que el desarrollo de software es un problema de complejidad esencial y menciona cuatro propiedades inherentes a la esencia irreductible de los modernos sistemas de software: complejidad, conformidad, variabilidad e invisibilidad.

Complejidad

Brooks postula que en esta disciplina no hay dos partes iguales que puedan ser programadas y, si las hay, las hacemos una, convirtiéndolas en una subrutina. En este sentido, los sistemas de software son muy distintos a las computadoras, los edificios o los automóviles, donde podemos encontrar varios elementos que se repiten.

Si bien en la actualidad hemos avanzado mucho en aspectos de patrones, software libre y medios sociales que nos ayudan a compartir soluciones, usualmente, el desarrollo de software no consiste en la repetición de los mismos elementos, sino en el aumento de la cantidad de elementos diferentes y, en la mayoría de los casos, los elementos estables interactúan unos con otros de una manera no lineal.

Conformidad

Muchas veces al desarrollar un nuevo sistema de software, tenemos que integrarlo con otros sistemas que fueron diseñados y modificados a lo largo del tiempo por otras personas. Gran parte de la complejidad viene de la conformación o la integración con otros sistemas, y esto no se puede simplificar.

Variabilidad

Los sistemas de software se encuentran bajo presión constante para cambiar o adaptarse: las empresas pretenden usar software ya existente para situaciones nuevas y, por lo tanto, espera que los programas incluyan la posibilidad de extender sus funcionalidades, o que pueda sobrevivir a los cambios tecnológicos.

Invisibilidad

Brooks sostiene que el software es invisible, o bien, muy difícil representar. Los arquitectos usan planos y los mecánicos, diseños a escala. Pero si un ingeniero en software quiere representar una estructura, termina en un laberinto infinito de flujo de datos, patrones de dependencia, secuencias temporales y relaciones entre los nombres, todos elementos que no son ni planos ni jerárquicos. La falta de representación visual —una gran herramienta para muchas ciencias— vuelve más complejo el proceso de diseño, y la comunicación entre los desarrolladores resulta más difícil.

La reacción de la industria del software

Especulando con que la industria del software ha entrado en una etapa de madurez, donde hemos capitalizado grandes avances: lenguajes de programación más sofisticados y colaborativos, procesos de desarrollo más maduros, entornos más complejos y diversos, entre otros argumentos. Debemos reconocer que, como señala Grady Booch en sus conferencias, que “el desarrollo de software ha sido, es y probablemente será fundamentalmente difícil”.

Desde la década del ochenta, cuando los grandes maestros comenzaron a estudiar la complejidad de la industria del software, se han realizado grandes intentos por darle una estructura formal a nuestra disciplina tan cercana al arte (estándares de proceso, herramientas y lenguajes de programación modernos y simples, metodologías de desarrollo que integran agilidad y equilibrio, etc.)

Las ciencias de datos y la ingeniería de software

Podemos leer en publicaciones de tecnología del 2020 que el interés y crecimiento de los proyectos basados en Data Science y es con éstas que se agregan nuevas posibilidades de solución a problemas anteriormente inabarcables, entre otros el omnipresente asunto de la complejidad de los proyectos de software.

Algunas que propongo

Ahora bien, podemos reconocer en las ciencias de datos algunas estrategias usadas en otras ingenierías más maduras que podríamos implementar en la ingeniería de software. Menciono un par de ellas:

1)     Estimaciones de costos probabilísticas que capturan la incertidumbre y proveen herramientas más justificables para la toma de decisiones

2)     Registros de Riesgos adaptados a proyectos de software que soportan la gestión de problemas recurrentes pero que no deberían ser incluidos en ningún backlog

Estos modelos ya maduros aportan mayor seguridad a los encargados de proyectos y reducen la incertidumbre que es natural al desarrollo de software. Proveen una forma simple de mitigar los efectos de esas dificultades esenciales que mencionamos al principio del artículo.

Estimación de Costos Probabilística con Simulación de Montecarlo (SMC)

Este tipo de aplicaciones de analítica avanzada es ampliamente aceptado en el mundo de los negocios para predecir, explicar y ayudar a identificar soluciones óptimas. En particular, aplicaremos la simulación Monte Carlo a un proyecto con el fin de poder estimar el riesgo de un fracaso, usando para este propósito una simple hoja de Excel con @RISK, que nos facilita la definición del modelo estocástico.

Para nuestros modelos de estimación de costos o de calendario usaremos esta técnica para modelar la incertidumbre de las tareas (en costos o en duración) para finalmente tener un total representado por una serie de valores posibles que serán analizados usando la estadística descriptiva para la toma final de decisiones.

Gestión de Registros de Riesgos

Este tipo de estrategias de gestión de eventos de riesgos es ampliamente usado (y exigido) en ingenierías maduras, aunque algo novedoso en proyectos de software.

Estos modelos de análisis prospectivo analizan el impacto de eventos de riesgos y observan sus efectos en los presupuestos de nuestros proyectos de software. El estado de evolución de nuestra disciplina requiere un uso efectivo de sus experiencias y, por consecuencia, una gestión efectiva de estos eventos de baja probabilidad y alto impacto.

Los registros de riesgos estudian los eventos en dos instancias y en dos dimensiones:

·        Riesgo en Pre-Mitigación o Inherente: es la evaluación cualitativa o cuantitativa de un evento antes de la aplicación de una estrategia de mitigación

o  Frecuencia o Probabilidad de Ocurrencia

o  Severidad o Impacto

·        Riesgo en Post-Mitigación o Residual: es la evaluación cualitativa o cuantitativa de un evento luego de la aplicación de una estrategia de mitigación

o  Frecuencia o Probabilidad de Ocurrencia

o  Severidad o Impacto

En este modelo también nos valemos de la SMC para el análisis prospectivo y usamos distribuciones de probabilidad discretas para modelar las frecuencias u ocurrencias:

Para modelar las severidades de los eventos usamos distribuciones de 3 puntos:

Finalmente, una vez modelados los eventos en su estado inherente y residual, procedemos a simular y a la toma de decisiones.

Conclusiones

Encontrar la bala de plata es una utopía evidentemente. Una ingeniería basada en la imaginación humana - supeditada a un contexto cambiante - condiciona mucho las tareas más básicas de las ingenierías maduras.

El objetivo de este artículo es acercar herramientas de analítica avanzada que permiten reducir la incertidumbre y gestionar eventos de alto riesgo de forma justificable. Ayudar a la toma de decisiones en una industria que tiene mucho que aprender de disciplinas maduras.

Los invito a seguir buscando lo imposible como nos enseña Ana Frank en su famoso diario.