Cómo construí una revisión sistemática sobre IA en la gestión de proyectos de software

Una revisión sistemática de literatura no consiste en buscar algunos artículos, resumirlos y unir sus conclusiones. El verdadero trabajo está en convertir una pregunta amplia en un proceso reproducible: definir qué se busca, dónde se busca, qué evidencia se acepta, cómo se descarta lo irrelevante y de qué manera se comparan estudios que no siempre usan las mismas métricas.

Ese fue el reto de mi artículo “Artificial-Intelligence-Based Technologies to Increase the Level of Tool Integration in Software and Technology Project Management”. Analicé cómo se está integrando la inteligencia artificial en la gestión de proyectos de software y tecnología, qué herramientas aparecen en la literatura y cómo se evalúa su desempeño.

En este texto explico el proceso detrás del artículo, las decisiones que tomé y lo que aprendí al transformar 249 registros iniciales en una síntesis de 56 estudios.

El problema que quise investigar

La gestión de proyectos de software continúa enfrentando problemas conocidos: estimaciones de esfuerzo imprecisas, riesgos detectados tarde, asignación deficiente de recursos y dificultades para controlar cronogramas y presupuestos. Al mismo tiempo, cada vez aparecen más propuestas basadas en aprendizaje automático, modelos híbridos, agentes inteligentes y modelos de lenguaje.

El problema no era demostrar simplemente que “la IA ayuda”. Quería entender dónde se integra, con qué tecnología y cómo se demuestra que funciona. Por eso organicé la revisión alrededor de tres preguntas:

1. ¿Qué significa integrar IA en la gestión de proyectos de software y cómo se evalúa esa integración?
2. ¿Qué tecnologías, herramientas o alternativas basadas en IA se están utilizando?
3. ¿Qué métricas se emplean para medir el desempeño de esas soluciones?

Estas preguntas marcaron la estructura completa del trabajo. Si un dato no ayudaba a responder una de ellas, no debía ocupar el centro del análisis.

Diseñar una búsqueda que otra persona pueda repetir

Consulté Scopus y Web of Science. La estrategia combinó cuatro grupos conceptuales: inteligencia artificial, gestión de proyectos, contexto de software o tecnología y actividades de integración, automatización o predicción.

Una versión legible de la lógica fue:

(AI OR machine learning OR deep learning OR LLM OR intelligent agents)
AND (project management OR software project management OR agile project management)
AND (software OR information systems OR IT projects)
AND (integration OR automation OR prediction OR planning OR risk management)

No basta con guardar la frase de búsqueda. También es necesario registrar los campos consultados, el intervalo temporal, la fecha de ejecución y las diferencias de sintaxis entre bases. Esa trazabilidad permite explicar por qué el conjunto final tiene esa forma y no otra.

Del universo inicial a los estudios incluidos

Seguí el protocolo PRISMA para documentar la identificación, el cribado y la selección. Scopus aportó 90 registros y Web of Science 159. Después eliminé duplicados, revisé títulos y resúmenes, evalué textos completos y apliqué los criterios de inclusión y exclusión.

El diagrama resume el proceso, pero cada transición implicó una decisión. Incluí trabajos publicados entre 2024 y 2026 que presentaban tecnologías, procesos, beneficios, limitaciones o métricas relacionadas directamente con IA y gestión de proyectos de software. Excluí documentos incompletos, duplicados, trabajos fuera del periodo y estudios donde la IA sólo aparecía como una mención general. También descarté investigaciones centradas exclusivamente en sectores ajenos al alcance, como construcción o BIM.

La tasa final de inclusión respecto del universo identificado fue:

El porcentaje no representa “calidad” por sí mismo. Sólo muestra cuánto se redujo el conjunto al aplicar el protocolo definido.

Construir una matriz antes de interpretar

Para cada estudio extraje autores, año, fuente, tecnología de IA, proceso de gestión abordado, métricas utilizadas y resultados principales. Esta matriz fue más importante que comenzar a redactar de inmediato: permitió comparar trabajos con vocabularios distintos y detectar patrones sin depender de la memoria.

Separé el análisis en tres niveles:

• Tecnología: aprendizaje automático, aprendizaje profundo, LLM, aprendizaje por refuerzo, agentes y enfoques híbridos.
• Proceso de gestión: estimación de esfuerzo, gestión ágil, predicción de riesgos, asignación de recursos, cronogramación y otras actividades.
• Evidencia: métricas de clasificación, métricas de estimación y resultados operativos del proyecto.

Esta separación evitó confundir el algoritmo utilizado con el problema resuelto o con la forma de evaluar el resultado.

Comparar métricas que responden preguntas diferentes

Una dificultad importante fue la fragmentación métrica. Un clasificador de riesgos no se evalúa igual que un modelo de estimación de costos. Para clasificación aparecen medidas como precisión, exhaustividad y F1:

Para estimación continua son más comunes MAE y RMSE. Si $y_i$ es el valor real y $\hat{y}_i$ la predicción para cada proyecto:

MAE mantiene el error en la unidad original y resulta fácil de interpretar. RMSE penaliza con más fuerza los errores grandes. Ninguna métrica es universalmente superior: debe elegirse según la decisión que el modelo apoyará y el costo real de equivocarse.

Lo que encontré

La estimación de esfuerzo y costos fue el proceso más estudiado: apareció en 22 de los 56 trabajos, equivalente al 39.3 %. Le siguieron la gestión ágil de sprints, la predicción de riesgos y la asignación de recursos.

El aprendizaje automático fue la tecnología dominante. Sin embargo, la tendencia más interesante no fue un algoritmo aislado, sino la convergencia hacia enfoques ensemble e híbridos, que combinan varios modelos para reducir sesgo, varianza y sensibilidad frente a conjuntos de datos pequeños o heterogéneos.

Los LLM y la IA generativa aparecieron como una frontera emergente. Sus aplicaciones incluyen documentación, ingeniería de requisitos, selección de metodologías y apoyo al razonamiento. La literatura también deja una advertencia: una demostración técnica no equivale a integración organizacional. La falta de datos históricos, habilidades, interpretabilidad y procesos de adopción continúa limitando el uso real.

Del conjunto de métricas a una propuesta propia

Al comparar los estudios observé que medir sólo la precisión del modelo no explica cuánto se ha integrado la IA en un proyecto. Un sistema puede predecir bien y, aun así, estar aislado del flujo de trabajo, no automatizar acciones o no apoyar ninguna decisión real.

Por eso propuse el Índice Compuesto de Integración de IA (ICIAI). El índice reúne cinco dimensiones normalizadas entre 0 y 1: tecnología ($T$), procesos cubiertos ($P$), automatización ($A$), toma de decisiones ($D$) y desempeño del modelo ($M$).

Los pesos $w_k$ pueden establecerse mediante juicio experto o análisis estadístico. Un valor cercano a 1 representaría una integración profunda y efectiva, no únicamente un buen resultado de laboratorio. El ICIAI es una propuesta conceptual: el siguiente paso es validarlo con casos reales y comprobar si sus dimensiones y pesos discriminan adecuadamente distintos niveles de madurez.

Cómo conecta esta investigación con mis proyectos

Esta revisión también cambió mi forma de pensar productos como mi asistente empresarial de IA. La pregunta dejó de ser “¿qué modelo vamos a usar?” y pasó a ser “¿en qué proceso participa, qué decisión mejora, qué puede automatizar y con qué evidencia lo comprobaremos?”.

En un asistente conectado con CRM, documentación y operaciones, una evaluación responsable necesita varias capas:

• calidad técnica de la respuesta o predicción;
• cobertura del proceso empresarial;
• nivel de automatización autorizado;
• intervención humana y trazabilidad de decisiones;
• efecto observable en tiempo, costo, errores o satisfacción.

Esa conexión entre investigación y construcción práctica es, para mí, el valor principal del trabajo.

Lo que aprendí al redactar el artículo

Primero, una revisión sistemática se diseña antes de escribirse. Las preguntas, criterios y campos de extracción deben existir antes de leer selectivamente los resultados más llamativos.

Segundo, una cifra necesita contexto. Decir que un modelo mejora otro no sirve si no sabemos qué dataset usó, cómo dividió los datos, cuál fue su baseline o si la diferencia es reproducible.

Tercero, las limitaciones forman parte del resultado. Mi revisión se concentra en Scopus y Web of Science, en publicaciones recientes y en contextos de software y tecnología. También existe heterogeneidad suficiente como para impedir un metaanálisis directo de todos los resultados.

Finalmente, redactar con LaTeX me ayudó a mantener ecuaciones, referencias, figuras y estructura académica de forma consistente. Pero la herramienta no reemplaza el criterio metodológico: el rigor depende del protocolo, de la trazabilidad y de que las conclusiones no excedan la evidencia.

Próximos pasos

El trabajo abre tres líneas claras: validar el ICIAI mediante estudios de caso en empresas de software, ampliar la búsqueda hacia bases regionales y publicaciones en español, y realizar un metaanálisis específico sobre modelos de estimación de esfuerzo.

La conclusión más importante no es que la IA sustituirá la gestión de proyectos. La evidencia apunta a una relación más útil: sistemas que complementan la experiencia humana con predicción, automatización y apoyo a decisiones, siempre que su integración se mida más allá de la precisión aislada del modelo.