{"id":18800,"date":"2022-09-15T14:32:50","date_gmt":"2022-09-15T12:32:50","guid":{"rendered":"https:\/\/inlab.fib.upc.edu\/donde-encajan-las-tecnologias-para-automatizar-el-desarrollo-y-asistir-al-desarrollador\/2022\/"},"modified":"2023-04-04T10:53:35","modified_gmt":"2023-04-04T09:53:35","slug":"donde-encajan-las-tecnologias-para-automatizar-el-desarrollo-y-asistir-al-desarrollador","status":"publish","type":"post","link":"https:\/\/inlab.fib.upc.edu\/es\/articulos\/donde-encajan-las-tecnologias-para-automatizar-el-desarrollo-y-asistir-al-desarrollador","title":{"rendered":"\u00bfD\u00f3nde encajan las tecnolog\u00edas para automatizar el desarrollo y asistir al desarrollador?"},"content":{"rendered":"\n

\u00bfD\u00f3nde encajan las tecnolog\u00edas para automatizar el desarrollo y asistir al desarrollador?<\/h2>\n\n

\u00bfC\u00f3mo se produce y opera el software en la pr\u00e1ctica?<\/h3>\n\n

Las herramientas Low Code y No Code (por ej. Appinventor \u200e[4]<\/a> , Budibase \u200e[5]<\/a> , WebRatio \u200e[3]<\/a> , Figma \u200e[6]<\/a> , Debuild \u200e[7],<\/a> etc.) nos permiten automatizar el desarrollo siguiendo un enfoque de dise\u00f1o centrado en el usuario (utilizan interfaces gr\u00e1ficas y configuraciones f\u00e1ciles de usar para crear las soluciones) \u200e[1]<\/a>\u200e[2].<\/a> Adem\u00e1s, existen herramientas tecnol\u00f3gicas de IA (por ej. GitHub copiloto \u200e[8]<\/a> u OpenAI \u200e[9]<\/a> basadas en GPT3) que pueden usarse como asistente en las tareas de dise\u00f1o y desarrollo de c\u00f3digo. A continuaci\u00f3n, para comprender mejor las implicaciones de estas tecnolog\u00edas podr\u00edan tener en la producci\u00f3n y operaciones software, veremos c\u00f3mo se llevan a cabo los proyectos software en la pr\u00e1ctica y porque cada vez cobra m\u00e1s fuerza que seguimos un enfoque de dise\u00f1o orientado al usuario en contraste con el ciclo de vida cl\u00e1sico de desarrollo que todos conocemos (independientemente de si lo hacemos en cascada o de forma iterativa-incremental).Cualquiera que se haya enfrentado al dise\u00f1o y desarrollo de un producto software, y m\u00e1s si el proyecto es de I+D, sabe de la incertidumbre inicial que tienen estos proyectos. El dise\u00f1o y desarrollo de prototipos permite que con poco esfuerzo podamos adquirir conocimientos m\u00e1s r\u00e1pidamente sobre la soluci\u00f3n que se necesita. Adem\u00e1s, cualquier cambio en el dise\u00f1o exterior de un producto (sus interfaces) afectar\u00e1n al dise\u00f1o interior del producto, por lo que, no parece que tenga mucho sentido que dise\u00f1emos su interior antes de asegurarnos de que el suyo dise\u00f1o exterior no va a cambiar (o va a cambiar poco). Una vez que estamos seguros de que el exterior es \u00abm\u00e1s estable\u00bb, podemos dise\u00f1arlo y construirlo de forma sistem\u00e1tica para que sea \u00ab\u00fatil\u00bb pero siempre, teniendo en cuenta que ofreceremos un servicio y que debemos asegurar ciertas \u00abgarant\u00edas\u00bb \u201d. La utilidad del artefacto es lo que estar\u00eda, principalmente, relacionado con los requisitos funcionales del producto mientras que la garant\u00eda (seguridad, capacidad, disponibilidad, continuidad, etc.) estar\u00eda m\u00e1s relacionada con lo que llamamos requisitos no funcionales. Al final, los requisitos est\u00e1n presentes en todo el ciclo de vida del producto como se observa en la Figura 1. <\/p>\n\n

\"\"
\n Figura 1. C\u00f3mo se relacionan los requisitos en el ciclo de vida del producto.<\/em>\n <\/figcaption><\/figure>\n\n

Como coment\u00e1bamos, independientemente del ciclo de desarrollo que seguimos (por ej. rota o iterativo-incremental), tradicionalmente las etapas cl\u00e1sicas de un desarrollo de software, sin entrar en las operaciones, son: Elicitaci\u00f3n de requisitos, An\u00e1lisis de requisitos, Dise\u00f1o, Construcci\u00f3n\/Implementaci\u00f3n, 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\u00eds para calificar un proyecto como \u201cinnovaci\u00f3n tecnol\u00f3gica\u201d o \u201cI+D\u201d. En estos 3-4 a\u00f1os como evaluador he podido evaluar m\u00e1s de 50 proyectos de este tipo. De forma breve, algunas de las cuestiones que he observado son:<\/p>\n\n

\u2022 Se mezcla el concepto de \u201cElicitaci\u00f3n de requisitos\u201d con el de \u201cAn\u00e1lisis de requisitos\u201d. La elicitaci\u00f3n s\u00f3lo deber\u00eda cubrir la comprensi\u00f3n y definici\u00f3n del problema (por ej. un modelo de negocio que describa la realidad actual, s\u00f3lo para entender las necesidades), mientras que en el an\u00e1lisis, deber\u00eda abordarse la soluci\u00f3n de modo independiente a la tecnolog\u00eda (por ej. interfaces, diagrama de clases, diagrama de casos, diagrama de actividades, diagrama de secuencia, etc.).<\/p>\n\n

\u2022 Se mezcla el concepto de \u00abAn\u00e1lisis de requisitos\u00bb con el de \u00abDise\u00f1o\u00bb. Mientras que el an\u00e1lisis es gen\u00e9rico, el dise\u00f1o es espec\u00edfico de la plataforma o tecnolog\u00eda que se utilice para construir la soluci\u00f3n. En la mayor\u00eda de proyectos evaluados, en el Dise\u00f1o se incluyen diagramas de An\u00e1lisis (es decir, gen\u00e9ricos, sin que se especifique tecnolog\u00eda alguna). <\/p>\n\n

\u2022 La documentaci\u00f3n t\u00e9cnica no suele seguir ning\u00fan modelo de referencia, est\u00e1ndar o normativa (por ejemplo t\u00e9cnicas UML o BPMN). En este sentido, ser\u00eda importante que se normalizara un m\u00ednimo de documentaci\u00f3n t\u00e9cnica para este tipo de proyectos (lo que estoy seguro de que agradecer\u00edamos todos los que evaluamos este tipo de proyectos).<\/p>\n\n

\u2022 Cuando se incluyen pruebas suelen ser de baja calidad. S\u00f3lo se aprecian actividades de verificaci\u00f3n (pasado, despu\u00e9s de dise\u00f1ar y construir, asegurarnos de que hemos dise\u00f1ado y construido la soluci\u00f3n adecuada), siendo pocas las actividades de validaci\u00f3n (futuro, antes de dise\u00f1ar y construir, asegurarse de que la soluci\u00f3n es la adecuada). Tampoco se mencionan actividades de monitorizaci\u00f3n continua (presente, asegurarse de que el software funciona en tiempo real) \u200e[10].<\/p>\n\n

\u2022 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\u00f3digo como evidencias de que se llev\u00f3 a cabo el desarrollo.<\/p>\n\n

\n \u00bfQu\u00e9 estrategias podemos inferir a partir de la experiencia pr\u00e1ctica como estrategia para la producci\u00f3n\/operaciones software?<\/strong>\n \n <\/h3>\n\n

Si hacemos el esfuerzo de trasladar todas estas actividades a un modelo como el de la figura anterior, tendr\u00edamos 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\u00f3n (Discovery), siguiendo por su dise\u00f1o y desarrollo (Development), hasta su puesta en producci\u00f3n como un servicio (Operations) .<\/p>\n\n

\"\"
\n Figura 2. Ciclo de vida del producto (discovery, development, operations).<\/em>\n <\/figcaption><\/figure>\n\n

De forma muy resumida, los objetivos y las principales actividades ser\u00edan las siguientes:<\/p>\n\n

\u2022 Discovery:<\/strong> El objetivo es aprender cuanto antes sobre el problema y la soluci\u00f3n, reducir la incertidumbre t\u00e9cnica y de negocio. Se consigue mediante la construcci\u00f3n y validaci\u00f3n de un prototipo desechable (negocio) y peque\u00f1as damos t\u00e9cnicas para ayudarnos a tomar decisiones sobre los componentes tecnol\u00f3gicos que utilizaremos en la construcci\u00f3n. Es una actividad de investigaci\u00f3n y generaci\u00f3n de conocimientos.<\/p>\n\n

\u2022 Development:<\/strong> El objetivo es que la construcci\u00f3n sea lo m\u00e1s sistem\u00e1tica posible (no es ciencia, es ingenier\u00eda). Se logra obteniendo un software que sea \u201c\u00fatil\u201d para sus usuarios y que haya sido probado en un entorno de desarrollo. Es una actividad en la que se genera software.<\/p>\n\n

\u2022 Operations:<\/strong> El objetivo es poner a disposici\u00f3n 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 \u201cgarant\u00edas\u201d.<\/p>\n\n

Si trasladamos las actividades de un ciclo de desarrollo cl\u00e1sico a este ciclo de vida de producto, nos daremos cuenta de que no s\u00f3lo cubre Development. Por ejemplo, la elicitaci\u00f3n de requisitos, encajar\u00eda en la comprensi\u00f3n y definici\u00f3n del problema. La actividad de An\u00e1lisis de requisitos quedar\u00eda separada en dos actividades: (Discovery) aquellas que afectan a la definici\u00f3n externa de la soluci\u00f3n (interfaces o prototipado) y (Development) aquellas relacionadas con la definici\u00f3n interna de la soluci\u00f3n (diagrama de clases, diagramas de secuencia, etc.). <\/p>\n\n

Las actividades de Dise\u00f1o y Construcci\u00f3n, de igual modo, quedar\u00edan separadas en dos actividades: (Discovery) aquellas actividades que tienen como objetivo dise\u00f1ar y construir una peque\u00f1a demo t\u00e9cnica y (Development) aquellas actividades que tienen como objetivo dise\u00f1ar y construir el software.<\/p>\n\n

La actividad de Pruebas (y podemos incluir monitorizaci\u00f3n continua si incluimos las operaciones), quedar\u00edan separada en tres: (Discovery) pruebas del sistema que pueden definirse usando los prototipos para \u201cvalidar\u201d el software mediante un prototipo de un solo uso, (Development) pruebas unitarias y de integraci\u00f3n que nos permiten \u201cverificar\u201d el software y, finalmente (Operations) monitorizaci\u00f3n continua que nos permite, en tiempo real, controlar y realizar un seguimiento del servicio que estamos ofreciendo.<\/p>\n\n

\n Descubrimiento\/Investigaci\u00f3n, Desarrollo y Operaciones (Learn2Build vs Build2Learn)<\/strong>\n <\/h3>\n\n

Dependiendo de nuestro contexto, podr\u00edan darse diferentes situaciones que implicar\u00edan que podamos poner el foco m\u00e1s en Discovery (por ej. aplicando un proceso Design Thinking), o bien, en Development y Operations (por ej. aplicando el conjunto de buenas pr\u00e1cticas de DevOps). <\/p>\n\n

\"\"
\n Figura 3. Discovery, Development & Operations.<\/em>\n <\/figcaption><\/figure>\n\n

El enfoque Learn2Build permite potenciar el aprendizaje previamente en la construcci\u00f3n. Es \u00fatil cuando nos encontramos en un contexto con alta incertidumbre de negocio y t\u00e9cnica. Es decir, no tenemos claro cu\u00e1l es problema, qu\u00e9 debemos construir ni c\u00f3mo lo vamos a construir. Una estrategia que encajar\u00eda en este enfoque ser\u00eda un proceso Design Thinking o la metodolog\u00eda Design Sprint \u200e[12]. Tambi\u00e9n encajar\u00edan los m\u00e9todos de SAPIENS que veremos a continuaci\u00f3n. La validaci\u00f3n del artefacto (por lo menos sobre su utilidad, no su garant\u00eda) en etapas muy tempranas nos permite reducir los esfuerzos y el coste que implican encontrar posibles ventajas competitivas (que veremos m\u00e1s adelante y que es un concepto relacionado con la innovaci\u00f3n ).<\/p>\n\n

\"\"
\n Figura 4. Enfoque Learn2Build.<\/em>\n <\/figcaption><\/figure>\n\n

Por otra parte, el enfoque Build2Learn permite potenciar la obtenci\u00f3n de productos funcionales que aporten un valor real al usuario \u200e[11]\u200e[13]. Al respecto, es muy importante la definici\u00f3n de valor, y aqu\u00ed deber\u00eda diferenciarse el \u201cValor\u201d que se aporta:<\/p>\n\n

1. Si s\u00f3lo abordamos un \u201cDesarrollo\u201d donde el despliegue se lleva a cabo s\u00f3lo en un entorno de desarrollo y el usuario todav\u00eda no puede sacarle partido al software del que se aporta <\/p>\n\n

2. Si adem\u00e1s integramos las \u201cOperaciones\u201d en las que el despliegue se lleva a cabo tanto en entornos de pre-producci\u00f3n como en entornos de producci\u00f3n reales, permitiendo a los usuarios que utilicen el software bajo unas garant\u00edas de uso.<\/p>\n\n

Adem\u00e1s, este enfoque requiere que dispongamos de un equipo t\u00e9cnicamente muy maduro, ya que el coste de dise\u00f1ar y construir soluciones software debe ser muy similar al dise\u00f1o y construcci\u00f3n de un prototipo desechable. Adem\u00e1s, tambi\u00e9n podr\u00eda requerir la aplicaci\u00f3n de unas m\u00ednimas estrategias de descubrimiento y gesti\u00f3n de requisitos (por ej. Lean Inception [14] o Agile Inception), ya que es muy importante que se lleve a cabo una buena planificaci\u00f3n para priorizar aquellas caracter\u00edsticas funcionales (utilidad) y no funcionales (garant\u00edas) que preveemos que aportar\u00edan mayor valor al negocio.<\/p>\n\n

\"\"
\n Figura 5. Enfoque Build2Learn.<\/em>\n <\/figcaption><\/figure>\n\n

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

Adem\u00e1s es importante que se lleve a cabo una ejecuci\u00f3n sist\u00e9mica del proceso frente a lo que ser\u00eda una ejecuci\u00f3n improvisada. La principal diferencia es que tengamos clara nuestra estrategia (qu\u00e9 procesos y etapas de las anteriores llevamos a cabo) y nuestras t\u00e1cticas (qu\u00e9 m\u00e9todos, t\u00e9cnicas y artefactos software utilizas en estos procesos). Sobre esto \u00faltimo, les dejo una frase del Libro \u201cEl Arte de la guerra\u201d de Sun Tzu que da lugar a la reflexi\u00f3n sobre estrategia y t\u00e1ctica en ingenier\u00eda del software: \u201cEstrategia sin t\u00e1ctica es el camino m\u00e1s lento hacia la victoria, Las t\u00e1cticas sin estrategia son el ruido antes de la derrota\u201d.<\/p>\n\n

\"\"
\n Figura 6. Diferentes problemas (contexto) requieren soluciones (estrat\u00e9gicas) diferentes.<\/em>\n <\/figcaption><\/figure>\n\n

\n Gesti\u00f3n y mejora continua <\/strong>\n <\/h4>\n\n

Siendo conscientes de los distintos contextos y estrategias donde pueden aplicarse las diferentes estrategias, lo importante es que la organizaci\u00f3n lleve a cabo estas pr\u00e1cticas de la forma m\u00e1s sistem\u00e1tica posible, y no trabajar de forma improvisada.<\/p>\n\n

\"\"
\n Figura 7. Gesti\u00f3n y mejora continua.<\/em>\n <\/figcaption><\/figure>\n\n

Por otro lado, este proceso sist\u00e9mico (hacemos lo mismo, obtenemos resultados similares), nos permite identificar adem\u00e1s si un determinado cambio en nuestras estrategias y t\u00e1cticas (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\u00eda cualquier proceso de gesti\u00f3n. Cualquiera de los enfoques que hemos visto anteriormente que combinen enfoques Learn2Build y Build2Learn encajar\u00eda en la \u201cEjecuci\u00f3n\u201d del proceso de gesti\u00f3n. Mejorar nuestra eficacia implicar\u00eda cumplir nuestros objetivos (por ej. que cumplimos con el alcance planificado) mientras que mejorar nuestra eficiencia implicar\u00eda realizar alg\u00fan cambio en nuestra estrategia que mejorara nuestra ejecuci\u00f3n (por ej. cumplimos objetivos con menor coste en tiempo o recursos).<\/p>\n\n

\n Conclusiones<\/strong>\n <\/h4>\n\n
\n

Por \u00faltimo, finalizaremos con las conclusiones m\u00e1s relevantes:<\/p>\n\n\n\n

\u2022 Diferentes contextos (problemas) requieren estrategias distintas (soluciones). Considerar una estrategia que tenga en cuenta el ciclo de vida del producto (no s\u00f3lo del desarrollo):<\/p>\n\n\n\n