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.
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.
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.
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.
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:
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.
Saludos ágiles
Jorge Abad
