¿Dónde encajan las tecnologías para automatizar el desarrollo y asistir al desarrollador?

¿Dónde encajan las tecnologías para automatizar el desarrollo y asistir al desarrollador?

¿Cómo se produce y opera el software en la práctica?

Las herramientas Low Code y No Code (por ej. Appinventor ‎[4] , Budibase ‎[5] , WebRatio ‎[3] , Figma ‎[6] , Debuild ‎[7], etc.) nos permiten automatizar el desarrollo siguiendo un enfoque de diseño centrado en el usuario (utilizan interfaces gráficas y configuraciones fáciles de usar para crear las soluciones) ‎[1]‎[2]. Además, existen herramientas tecnológicas de IA (por ej. GitHub copiloto ‎[8] u OpenAI ‎[9] basadas en GPT3) que pueden usarse como asistente en las tareas de diseño y desarrollo de código. A continuación, para comprender mejor las implicaciones de estas tecnologías podrían tener en la producción y operaciones software, veremos cómo se llevan a cabo los proyectos software en la práctica y porque cada vez cobra más fuerza que seguimos un enfoque de diseño orientado al usuario en contraste con el ciclo de vida clásico de desarrollo que todos conocemos (independientemente de si lo hacemos en cascada o de forma iterativa-incremental).
Cualquiera que se haya enfrentado al diseño y desarrollo de un producto software, y más si el proyecto es de I+D, sabe de la incertidumbre inicial que tienen estos proyectos. El diseño y desarrollo de prototipos permite que con poco esfuerzo podamos adquirir conocimientos más rápidamente sobre la solución que se necesita. Además, cualquier cambio en el diseño exterior de un producto (sus interfaces) afectarán al diseño interior del producto, por lo que, no parece que tenga mucho sentido que diseñemos su interior antes de asegurarnos de que el suyo diseño exterior no va a cambiar (o va a cambiar poco). Una vez que estamos seguros de que el exterior es «más estable», podemos diseñarlo y construirlo de forma sistemática para que sea «útil» pero siempre, teniendo en cuenta que ofreceremos un servicio y que debemos asegurar ciertas «garantías» ”. La utilidad del artefacto es lo que estaría, principalmente, relacionado con los requisitos funcionales del producto mientras que la garantía (seguridad, capacidad, disponibilidad, continuidad, etc.) estaría más relacionada con lo que llamamos requisitos no funcionales. Al final, los requisitos están presentes en todo el ciclo de vida del producto como se observa en la Figura 1.

Como comentábamos, independientemente del ciclo de desarrollo que seguimos (por ej. rota o iterativo-incremental), tradicionalmente las etapas clásicas de un desarrollo de software, sin entrar en las operaciones, son: Elicitación de requisitos, Análisis de requisitos, Diseño, Construcción/Implementación, Pruebas. De hecho, las etapas anteriores son las que aparecen en las plantillas del ministerio que utilizamos los auditores para evaluar los proyectos que se realizan en nuestro país para calificar un proyecto como “innovación tecnológica” o “I+D”. En estos 3-4 años como evaluador he podido evaluar más de 50 proyectos de este tipo. De forma breve, algunas de las cuestiones que he observado son:

• Se mezcla el concepto de “Elicitación de requisitos” con el de “Análisis de requisitos”. La elicitación sólo debería cubrir la comprensión y definición del problema (por ej. un modelo de negocio que describa la realidad actual, sólo para entender las necesidades), mientras que en el análisis, debería abordarse la solución de modo independiente a la tecnología (por ej. interfaces, diagrama de clases, diagrama de casos, diagrama de actividades, diagrama de secuencia, etc.).

• Se mezcla el concepto de «Análisis de requisitos» con el de «Diseño». Mientras que el análisis es genérico, el diseño es específico de la plataforma o tecnología que se utilice para construir la solución. En la mayoría de proyectos evaluados, en el Diseño se incluyen diagramas de Análisis (es decir, genéricos, sin que se especifique tecnología alguna).

• La documentación técnica no suele seguir ningún modelo de referencia, estándar o normativa (por ejemplo técnicas UML o BPMN). En este sentido, sería importante que se normalizara un mínimo de documentación técnica para este tipo de proyectos (lo que estoy seguro de que agradeceríamos todos los que evaluamos este tipo de proyectos).

• Cuando se incluyen pruebas suelen ser de baja calidad. Sólo se aprecian actividades de verificación (pasado, después de diseñar y construir, asegurarnos de que hemos diseñado y construido la solución adecuada), siendo pocas las actividades de validación (futuro, antes de diseñar y construir, asegurarse de que la solución es la adecuada). Tampoco se mencionan actividades de monitorización continua (presente, asegurarse de que el software funciona en tiempo real) ‎[10].

• En algunos casos, se aportan pantallas que a veces no sabes si son prototipos o capturas de pantalla reales del software desarrollado. Sin embargo, suelen solicitarse extractos de código como evidencias de que se llevó a cabo el desarrollo.

¿Qué estrategias podemos inferir a partir de la experiencia práctica como estrategia para la producción/operaciones software?

Si hacemos el esfuerzo de trasladar todas estas actividades a un modelo como el de la figura anterior, tendríamos algo como el que se muestra en la Figura 2. En la siguiente figura, se ha considerado un ciclo de vida completo del producto software, desde su concepción (Discovery), siguiendo por su diseño y desarrollo (Development), hasta su puesta en producción como un servicio (Operations) .

De forma muy resumida, los objetivos y las principales actividades serían las siguientes:

• Discovery: El objetivo es aprender cuanto antes sobre el problema y la solución, reducir la incertidumbre técnica y de negocio. Se consigue mediante la construcción y validación de un prototipo desechable (negocio) y pequeñas damos técnicas para ayudarnos a tomar decisiones sobre los componentes tecnológicos que utilizaremos en la construcción. Es una actividad de investigación y generación de conocimientos.

• Development: El objetivo es que la construcción sea lo más sistemática posible (no es ciencia, es ingeniería). Se logra obteniendo un software que sea “útil” para sus usuarios y que haya sido probado en un entorno de desarrollo. Es una actividad en la que se genera software.

• Operations: El objetivo es poner a disposición de los usuarios el software para que puedan realizar sus actividades. Se consigue mediante la puesta en marcha de un servicio que permita a los usuarios utilizar el software con “garantías”.

Si trasladamos las actividades de un ciclo de desarrollo clásico a este ciclo de vida de producto, nos daremos cuenta de que no sólo cubre Development. Por ejemplo, la elicitación de requisitos, encajaría en la comprensión y definición del problema. La actividad de Análisis de requisitos quedaría separada en dos actividades: (Discovery) aquellas que afectan a la definición externa de la solución (interfaces o prototipado) y (Development) aquellas relacionadas con la definición interna de la solución (diagrama de clases, diagramas de secuencia, etc.).

Las actividades de Diseño y Construcción, de igual modo, quedarían separadas en dos actividades: (Discovery) aquellas actividades que tienen como objetivo diseñar y construir una pequeña demo técnica y (Development) aquellas actividades que tienen como objetivo diseñar y construir el software.

La actividad de Pruebas (y podemos incluir monitorización continua si incluimos las operaciones), quedarían separada en tres: (Discovery) pruebas del sistema que pueden definirse usando los prototipos para “validar” el software mediante un prototipo de un solo uso, (Development) pruebas unitarias y de integración que nos permiten “verificar” el software y, finalmente (Operations) monitorización continua que nos permite, en tiempo real, controlar y realizar un seguimiento del servicio que estamos ofreciendo.

Descubrimiento/Investigación, Desarrollo y Operaciones (Learn2Build vs Build2Learn)

Dependiendo de nuestro contexto, podrían darse diferentes situaciones que implicarían que podamos poner el foco más en Discovery (por ej. aplicando un proceso Design Thinking), o bien, en Development y Operations (por ej. aplicando el conjunto de buenas prácticas de DevOps).

El enfoque Learn2Build permite potenciar el aprendizaje previamente en la construcción. Es útil cuando nos encontramos en un contexto con alta incertidumbre de negocio y técnica. Es decir, no tenemos claro cuál es problema, qué debemos construir ni cómo lo vamos a construir. Una estrategia que encajaría en este enfoque sería un proceso Design Thinking o la metodología Design Sprint ‎[12]. También encajarían los métodos de SAPIENS que veremos a continuación. La validación del artefacto (por lo menos sobre su utilidad, no su garantía) en etapas muy tempranas nos permite reducir los esfuerzos y el coste que implican encontrar posibles ventajas competitivas (que veremos más adelante y que es un concepto relacionado con la innovación ).

Por otra parte, el enfoque Build2Learn permite potenciar la obtención de productos funcionales que aporten un valor real al usuario ‎[11]‎[13]. Al respecto, es muy importante la definición de valor, y aquí debería diferenciarse el “Valor” que se aporta:

1. Si sólo abordamos un “Desarrollo” donde el despliegue se lleva a cabo sólo en un entorno de desarrollo y el usuario todavía no puede sacarle partido al software del que se aporta

2. Si además integramos las “Operaciones” en las que el despliegue se lleva a cabo tanto en entornos de pre-producción como en entornos de producción reales, permitiendo a los usuarios que utilicen el software bajo unas garantías de uso.

Además, este enfoque requiere que dispongamos de un equipo técnicamente muy maduro, ya que el coste de diseñar y construir soluciones software debe ser muy similar al diseño y construcción de un prototipo desechable. Además, también podría requerir la aplicación de unas mínimas estrategias de descubrimiento y gestión de requisitos (por ej. Lean Inception [14] o Agile Inception), ya que es muy importante que se lleve a cabo una buena planificación para priorizar aquellas características funcionales (utilidad) y no funcionales (garantías) que preveemos que aportarían mayor valor al negocio.

Con todo lo anterior, lo importante es que tengamos un equipo que, en cada momento se adapte a las circunstancias según el contexto como se muestra en la Figura 6, donde en un momento determinado podríamos empezar aplicando sólo un enfoque Learn2Build (Discovery ), en otro momento combinar ambos enfoques pero sin desplegar en producción (Discovery & Development), o bien, sólo aplicar un enfoque Build2Learn desplegando en entornos de producción (Development & Operations).

Además es importante que se lleve a cabo una ejecución sistémica del proceso frente a lo que sería una ejecución improvisada. La principal diferencia es que tengamos clara nuestra estrategia (qué procesos y etapas de las anteriores llevamos a cabo) y nuestras tácticas (qué métodos, técnicas y artefactos software utilizas en estos procesos). Sobre esto último, les dejo una frase del Libro “El Arte de la guerra” de Sun Tzu que da lugar a la reflexión sobre estrategia y táctica en ingeniería del software: “Estrategia sin táctica es el camino más lento hacia la victoria, Las tácticas sin estrategia son el ruido antes de la derrota”.

Gestión y mejora continua

Siendo conscientes de los distintos contextos y estrategias donde pueden aplicarse las diferentes estrategias, lo importante es que la organización lleve a cabo estas prácticas de la forma más sistemática posible, y no trabajar de forma improvisada.

Por otro lado, este proceso sistémico (hacemos lo mismo, obtenemos resultados similares), nos permite identificar además si un determinado cambio en nuestras estrategias y tácticas (por ejemplo, utilizar una nueva herramienta en lugar de otra) nos permite mejorar o no. En la siguiente figura se muestra la estrategia que seguiría cualquier proceso de gestión. Cualquiera de los enfoques que hemos visto anteriormente que combinen enfoques Learn2Build y Build2Learn encajaría en la “Ejecución” del proceso de gestión. Mejorar nuestra eficacia implicaría cumplir nuestros objetivos (por ej. que cumplimos con el alcance planificado) mientras que mejorar nuestra eficiencia implicaría realizar algún cambio en nuestra estrategia que mejorara nuestra ejecución (por ej. cumplimos objetivos con menor coste en tiempo o recursos).

Conclusiones

REFERENCIAS

[1]. El País, “Low Code cómo aparender a programar sin saber programar”, accesible online: https://elpais.com/tecnologia/2022-05-06/low-code-como-aprender-a-programar-sin-saber-programar.html, últim accès: Juliol 2022

[2]. Mobile World Capital Barcelona (MWCapital) y NTT Data, en el marco Barcelona Digital Talent, “Análisis del low-code: nuevo paradigma en el desarrollo del software”, accesible online: https://barcelonadigitaltalent.com/report/analisis-low-code/, últim accès: Juliol 2022

[3]. WebRatio, accessible online: https://www.webratio.com/site/content/es/plataforma-de-desarrollo, últim accès: Juliol 2022

[4]. MIT Appinventor, accesible online: https://appinventor.mit.edu, últim accès: Juliol 2022

[5]. BuidBase, accesible online: https://budibase.com, últim accès: Juliol 2022

[6]. Figma, accesible online: https://www.figma.com/, últim accès: Juliol 2022

[7]. Debuild, accessible online: https://debuild.app/, últim accès: Juliol 2022

[8]. GitHub copilot, accesible online: https://github.com/features/copilot, últim accès: Juliol 2022

[9]. OpenAI examples, accesible online: https://beta.openai.com/examples/, últim accès: Juliol 2022

[10]. Morales-Trujillo et al. «A Testability and Observability Framework to Assure Traceability Requirements on System of Systems.» Journal of Web Engineering (2020): 297-318.

[11]. Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press, LLC. Print ISBN:978-1942788003.

[12]. Jake Knapp, J. Z. (15 de 12 de 2016). Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. First Simon & Schuster. ISBN 978-1-5011-2174-6. Obtenido de http://www.gv.com/sprint/

[13]. Forsgren, N., Humble, J., & Kim, G. (2018). The Science of Lean Software and DevOps. ACCELERATE. Building and Scaling High Performing Technology Organizations. IT REVOLUTION. ISBN:9781942788331.

[14]. Paulo Caroli (2019), Lean Inception: How to Align People and Build the Right Product, ISBN 10: 8594377134.