Durante mucho tiempo, hablar de procesos modernos de desarrollo de software
parecía reducirse a una discusión sobre Agile, Scrum, DevOps o alguna
combinación de prácticas conocidas.
Pero la ingeniería de software está entrando en dominios donde esa respuesta
ya no es suficiente.
¿Qué proceso se necesita para desarrollar un sistema que debe adaptarse
autónomamente al entorno? ¿Cómo cambia la ingeniería cuando el software está
compuesto por agentes de inteligencia artificial que toman decisiones? ¿Cómo
se valida un sistema de realidad aumentada donde la experiencia del usuario,
la latencia y los derechos sobre el contenido son parte del producto? ¿Y
cómo se desarrolla un videojuego cuando una compilación exitosa no significa
necesariamente que el juego sea divertido?
Estas fueron algunas de las preguntas abordadas por los estudiantes del
curso
Procesos Modernos de Desarrollo de Software de la Universidad
EAFIT.
El reto no consistía simplemente en escoger una metodología existente. Los
equipos debían estudiar un dominio, identificar sus problemas particulares,
analizar diferentes enfoques de ingeniería de software y diseñar un modelo
de proceso capaz de responder a esas características.
El resultado son cuatro propuestas que exploran sistemas ciberfísicos,
aplicaciones agénticas, realidad aumentada y videojuegos.
Una idea atraviesa los cuatro trabajos:
un proceso moderno de desarrollo de software no debería comenzar preguntando
“¿qué metodología vamos a usar?”, sino
“¿qué características de este sistema hacen necesario diseñar una forma
particular de construirlo, validarlo y operarlo?”
1. MDM: cuando el software debe coordinarse con el mundo físico
MAPE-Driven Methodology (MDM): Aplicación a un Sistema de Riego Inteligente
para Cultivos de Café
Joan Sebastian Herrera M., Santiago Mesa V., Sergio Alfredo Juanca V., Tomas
Echavarria G. y Mateo Muñoz B.
El primer trabajo se mueve hacia un territorio particularmente complejo: los
sistemas ciberfísicos autoadaptables.
En ellos el software deja de vivir únicamente dentro de computadores y
comienza a interactuar directamente con sensores, dispositivos físicos y
condiciones cambiantes del mundo real.
El caso estudiado es un sistema inteligente de riego para cultivos de café
mediante drones. La propuesta combina
Spec-Driven Development, Domain-Driven Design, DevOps y MAPE-K.
Uno de los aspectos más interesantes del modelo es la separación entre los
equipos de hardware y software. Ambos pueden avanzar en paralelo utilizando
un principio de
“contrato primero”, sincronizándose únicamente en puntos
definidos del proceso.
La metodología se estructura en seis fases y utiliza simulación, ciclos de
retroalimentación, especificaciones y trazabilidad para conectar las
decisiones técnicas con las reglas del dominio agrícola.
La lección: cuando el software controla el mundo físico,
integración continua ya no significa únicamente integrar código. También hay
que integrar modelos, sensores, hardware, simulaciones y comportamiento
físico.
Abrir MDM en Google Drive
2. AGORA: desarrollar agentes de IA no es simplemente escribir prompts
AGORA: Modelo de Procesos para el Desarrollo de Aplicaciones Agénticas
Juan José Henao Aristizábal, Ioav Mizrachi Muñoz, Juan Miguel Castro
Martínez y Julián Giraldo Chica
Las aplicaciones agénticas introducen un cambio importante en la ingeniería
de software.
Un sistema tradicional recibe una entrada, ejecuta una lógica relativamente
determinada y produce un resultado. Un agente basado en modelos de lenguaje
puede interpretar un objetivo, elaborar un plan, seleccionar herramientas,
ejecutar acciones, observar sus resultados y modificar posteriormente su
estrategia.
Eso cambia incluso la forma de probar software.
La pregunta deja de ser únicamente “¿la prueba pasa?” y comienza a
convertirse en
“¿con qué nivel de confiabilidad logra el agente el objetivo y qué
evidencia tenemos de ello?”.
AGORA integra cuatro perspectivas:
Desarrollo Dirigido por Objetivos, Diseño de Sistemas Multiagente,
Spec-Driven Development y DevOps/DevSecOps complementado con
AgentOps.
El modelo propone cinco fases:
Iniciativa, Organización, Especificación, Realización y
Despliegue, y las materializa mediante ocho roles, catorce artefactos, treinta y una
tareas y veintiséis productos de trabajo.
Una de sus ideas centrales es particularmente relevante para la ingeniería
de agentes:
la autonomía no debería descubrirse accidentalmente en producción; debe
diseñarse explícitamente.
También propone que cada objetivo pueda rastrearse hasta criterios de
evaluación y posteriormente hasta evidencia obtenida durante la operación.
La lección: cuando construimos agentes inteligentes,
gobernanza, observabilidad, evaluación, autonomía y trazabilidad dejan de
ser preocupaciones secundarias. Se convierten en parte del proceso de
desarrollo.
Abrir AGORA en Google Drive
3. ARCA: en realidad aumentada, la experiencia también forma parte de la
ingeniería
ARCA: un modelo de proceso para el desarrollo de software en realidad
aumentada con aseguramiento continuo de experiencia, rendimiento y derechos
Quinnie Villarreal Aragón, José Manuel Carvajal, Jonathan Sandoval, Lina
Ballesteros y Alejandro Ríos
La realidad aumentada combina software, dispositivos, sensores, contenido
gráfico, interacción humana y representación del entorno físico.
Por eso una entrega técnicamente correcta puede seguir siendo una mala
solución: puede tener problemas de latencia, usabilidad, registro espacial,
experiencia de usuario, privacidad o derechos sobre el contenido.
ARCA —Augmented Reality Continuous Assurance— combina
Human-Centered Design, DevOps, Event-Driven Architecture e Inteligencia
Artificial Generativa.
La metodología propone siete fases y distingue explícitamente dos cadenas de
construcción:
una para software y otra para contenido.
También introduce tres cadencias anidadas, compuertas de retorno cuando una
validación falla y responsabilidades específicas sobre producto, decisiones
técnicas, derechos, licencias y responsabilidad social.
Esta última característica es especialmente interesante: privacidad,
procedencia del contenido y responsabilidad social no aparecen simplemente
como recomendaciones éticas al final del proyecto, sino como condiciones
verificables dentro del proceso.
La lección: la calidad de un producto digital no siempre
está contenida completamente en su código. En algunos dominios, experiencia,
contenido, contexto de uso y responsabilidad también necesitan sus propios
mecanismos de aseguramiento.
Abrir ARCA en Google Drive
4. Videojuegos: una build que compila no necesariamente es un buen juego
Metodología integrada para la ingeniería de software de videojuegos
Angélica María Martínez Carmona, Ángel David Martínez Doria, David Gustavo
Moreno Morán, Diego Mauricio Sánchez Buitrago y Tomás Olarte Hernández
El desarrollo de videojuegos muestra con claridad los límites de pensar
únicamente en requisitos funcionales.
Un videojuego puede compilar correctamente, superar sus pruebas unitarias y
aun así no ser divertido, tener una mala experiencia de juego o producir
comportamientos emergentes no previstos.
La propuesta utiliza como unidad fundamental el
incremento jugable verificable: una porción integrada de
código y contenido que permite comprobar una hipótesis sobre la experiencia.
El modelo combina
DevOps, BDD complementado con aprendizaje por refuerzo e imitación,
Sistemas Multiagente e Inteligencia Artificial Generativa.
Los ciclos de los incrementos oscilan entre una y dos semanas, pero
diferentes actividades —integración continua, entrenamiento de agentes o
playtesting— pueden tener cadencias distintas.
La metodología se formaliza mediante SPEM 2.0 en siete fases, doce roles y
treinta y dos productos de trabajo. Sin embargo, establece un límite
importante a la automatización:
solo las personas pueden cerrar determinadas compuertas de
decisión.
El playtesting humano conserva así la responsabilidad sobre algo que ningún
pipeline puede determinar completamente: la experiencia del jugador.
La lección: automatizar más no siempre significa delegar
más. En sistemas donde existe creatividad, comportamiento emergente o
experiencia humana, automatización y autoridad son dos decisiones
diferentes.
Abrir metodología de videojuegos en Google Drive
La principal lección aprendida
Después de revisar los cuatro trabajos aparece una conclusión que considero
especialmente valiosa para quienes estudiamos ingeniería de software:
No existe un proceso moderno universal.
DevOps, Agile, Spec-Driven Development, Domain-Driven Design, BDD, sistemas
multiagente, GenAI o diseño centrado en el humano no deberían entenderse
como metodologías que compiten por ser “la correcta”.
Son conjuntos de principios, prácticas y mecanismos que responden a
problemas diferentes.
El verdadero trabajo de ingeniería consiste en entender primero la
naturaleza del sistema y después diseñar la manera en que debe construirse.
Los cuatro trabajos muestran precisamente eso.
- Un sistema ciberfísico necesita sincronizar software y hardware.
- Un agente necesita gobernar su autonomía y demostrar que alcanza
- objetivos.
- Una aplicación de realidad aumentada necesita validar simultáneamente
tecnología y experiencia.
- Un videojuego necesita verificar comportamiento sin eliminar la creatividad
ni el juicio humano.
Quizá esa sea una buena definición de lo que significa estudiar
Procesos Modernos de Desarrollo de Software:
no aprender cuál metodología utilizar, sino desarrollar el criterio
necesario para comprender
por qué, cuándo y bajo qué condiciones utilizar —o incluso diseñar— una
forma determinada de desarrollar software.
Estos documentos son entregables académicos desarrollados por estudiantes de
la Universidad EAFIT y se publican aquí como material de aprendizaje,
discusión y consulta.
