La matriz de consistencia obliga a que tu problema, tus objetivos, tus variables y tus indicadores respondan exactamente a la misma pregunta. En la mayoría de las carreras se construye igual, pero en Ingeniería Informática (o Ingeniería Civil en Computación) hay una diferencia que la plantilla genérica no resuelve: no toda memoria tiene hipótesis, y no toda variable es medible con una escala psicométrica. Esta guía muestra cómo adaptar la matriz cuando tu trabajo es un sistema, no un estudio de campo, con un ejemplo completo, un checklist final y los errores que más se repiten en esta carrera.
Qué es la matriz de consistencia y por qué tu memoria la necesita
La matriz de consistencia es una tabla de una página que alinea, fila por fila, el problema de investigación, el objetivo general, los objetivos específicos, las variables (o los requisitos, en una memoria de producto), los indicadores y el instrumento o método de medición. Su función no es decorativa: es la herramienta que tu profesor guía y la comisión usan para detectar, en segundos, si tu memoria promete algo en la marco teórico paso a paso e introducción y mide otra cosa en el capítulo de resultados. Una memoria de Ingeniería Informática suele devolverse por esta razón con más frecuencia que otras carreras, porque el alcance técnico (qué módulos se implementan, qué no) tiende a moverse durante el desarrollo sin que la matriz se actualice junto con él. Muchas escuelas la piden como anexo del anteproyecto y otra vez, actualizada, en el informe final; si tu escuela exige ambas versiones, guarda un historial de cambios para poder explicar en la defensa por qué algo se ajustó.
Las columnas de la matriz, adaptadas a un sistema
La matriz clásica tiene entre siete y nueve columnas. Para una memoria de Ingeniería Informática, estas son las que de verdad se necesitan completar, en línea con la estructura de una tesis de Ingeniería Informática capítulo por capítulo:
- Problema: la brecha o limitación concreta que el sistema debe resolver (no «falta digitalización», sino qué proceso específico falla y por qué).
- Objetivo general: lo que el sistema debe lograr, redactado con un verbo que sí se puede verificar al final (diseñar, implementar, evaluar), no con verbos de intención («mejorar», «optimizar») sin una métrica asociada.
- Objetivos específicos: las etapas del desarrollo que, sumadas, cumplen el objetivo general (levantamiento de requisitos, diseño de arquitectura, implementación, pruebas, evaluación con usuarios).
- Variable o requisito: en una memoria empírica es una variable de investigación medible (satisfacción, tiempo de tarea); en una memoria de producto es un requisito funcional o no funcional (tiempo de respuesta, disponibilidad, usabilidad).
- Indicador: el número o la condición concreta que demuestra que el requisito se cumplió (por ejemplo, «tiempo de respuesta menor a un umbral definido en el 95% de las consultas», como marcador ilustrativo que debes fijar según tu propio caso, no copiar).
- Instrumento o método: cómo se mide ese indicador (prueba de carga, cuestionario SUS, registro de logs, prueba de caja negra).
Una columna que muchas plantillas genéricas omiten y que en esta carrera conviene agregar es la de alcance técnico: qué queda explícitamente fuera del sistema que vas a entregar. Declarar el alcance dentro de la misma matriz evita la discusión más común en la defensa, que es «¿por qué no implementaron X si lo mencionan en el marco teórico?».
Memoria de investigación vs. memoria de producto: qué cambia
Si tu memoria pregunta algo sobre personas o procesos (por ejemplo, cómo afecta un sistema de recomendación al comportamiento de compra), necesitas variables independientes y dependientes como en cualquier otra carrera, y probablemente una hipótesis contrastable. Si tu memoria es de producto —diseñar e implementar un sistema— la columna de «variable» se reemplaza por requisitos funcionales y no funcionales, y la de «hipótesis» suele desaparecer o convertirse en un supuesto de diseño que se valida, no que se rechaza estadísticamente. Muchas escuelas chilenas de Ingeniería Informática aceptan ambos formatos; lo que no aceptan es mezclar el lenguaje de los dos sin declararlo, así que confirma con tu profesor guía cuál de las dos matrices corresponde a tu memoria antes de completarla. Un tercer formato, menos frecuente pero también válido en algunas escuelas, es la memoria mixta: un sistema que además mide su efecto sobre un grupo de usuarios reales, y que por lo tanto necesita las dos columnas —requisitos técnicos y variables de comportamiento— en la misma matriz. Si tu memoria nace de una práctica profesional convertida en memoria, este es también el punto donde conviene decidir qué formato de matriz corresponde a tu proyecto.
Ejemplo completo (ilustrativo): sistema de gestión de turnos para una pyme
El siguiente ejemplo es ficticio y sirve solo como plantilla de formato; los indicadores numéricos son marcadores de posición que debes reemplazar por los que definas para tu propio sistema y validar con tu profesor guía.
| Objetivo específico | Requisito | Indicador (ilustrativo) | Instrumento |
|---|---|---|---|
| Levantar los requisitos del proceso de agendamiento actual | Cobertura de los casos de uso identificados | 100% de los casos de uso priorizados documentados | Entrevistas con el equipo administrativo, diagrama de casos de uso |
| Diseñar la arquitectura del sistema | Modularidad y separación de responsabilidades | Diagrama de componentes validado por el profesor guía | Revisión de diseño (UML) |
| Implementar el módulo de agendamiento | Tiempo de respuesta de la consulta de disponibilidad | Umbral que definas y justifiques, medido en condición de carga normal | Prueba de carga con una herramienta de testing |
| Evaluar la usabilidad con usuarios reales | Percepción de facilidad de uso | Puntaje del cuestionario SUS por sobre el umbral que definas y justifiques en tu marco teórico | Cuestionario System Usability Scale (SUS), aplicado a una muestra piloto |
Nota cómo cada fila conserva la misma lógica de la carrera cuando el objeto medido cambia: si en lugar de un sistema de agendamiento tu memoria fuera un sistema de recomendación, la fila de usabilidad podría reemplazarse por precisión y exhaustividad del algoritmo (precision/recall), y la de tiempo de respuesta seguiría siendo válida casi sin cambios. La estructura de la matriz no depende del dominio del sistema; lo que cambia son los indicadores técnicos específicos de cada tipo de proyecto.
Indicadores técnicos que sí puedes medir en un sistema
Cuando la variable no es psicológica ni social, la comisión espera indicadores de ingeniería de software, no adjetivos. Algunos que sí son medibles y defendibles en la mayoría de los proyectos: tiempo de respuesta bajo carga, tasa de error o de excepciones no controladas, cobertura de pruebas unitarias, disponibilidad del servicio durante el periodo de evaluación, y percepción de usabilidad medida con un instrumento validado como el SUS (System Usability Scale), que es de uso libre y ampliamente citado en memorias de esta carrera. Para proyectos con componentes de aprendizaje automático, precisión, exhaustividad (recall) y la métrica F1 suelen ser más informativas que un porcentaje de acierto simple, y conviene declarar el conjunto de datos y el procedimiento de validación cruzada usado para calcularlas. Evita indicadores que no puedas medir con el tiempo y el acceso que realmente tienes: «adopción del sistema a nivel nacional» no es un indicador razonable para una memoria de pregrado con un piloto acotado a un grupo reducido de usuarios de prueba.
Herramientas para construir y mantener la matriz
La mayoría de las escuelas acepta la matriz en una tabla de Word o Excel; lo que exigen es que sea legible como una sola vista, sin que una fila se corte entre dos páginas. Si tu proyecto usa metodologías ágiles, puedes derivar la matriz directamente de tu backlog de historias de usuario: cada épica se convierte en un objetivo específico, y sus criterios de aceptación se convierten en indicadores. Mantener la matriz sincronizada con el tablero de gestión del proyecto (sea Trello, Jira o una planilla, en la misma lógica que una comparativa de software para analizar los datos de tu memoria) reduce el riesgo de llegar a la defensa con una matriz que ya no describe lo que realmente se implementó.
Checklist antes de entregar la matriz a tu profesor guía
- Cada objetivo específico tiene exactamente un indicador verificable, no una descripción vaga.
- Todos los indicadores tienen un umbral o condición explícita, no solo el nombre de la métrica.
- La columna de alcance técnico declara qué queda fuera del sistema.
- El instrumento de cada fila corresponde a algo que efectivamente vas a ejecutar, no a una herramienta mencionada solo en el marco teórico.
- La matriz cabe en una página o tabla legible sin cortes de fila entre páginas.
Errores frecuentes que devuelve la comisión
- Objetivos específicos que no corresponden a ningún módulo real del sistema implementado (se prometen en la propuesta y se abandonan durante el desarrollo sin actualizar la matriz).
- Indicadores sin umbral: decir que se medirá «el tiempo de respuesta» sin fijar qué valor cuenta como aceptable.
- Mezclar el lenguaje de hipótesis con el de requisitos de producto sin que el marco metodológico explique por qué.
- Usar como instrumento una herramienta que nunca se ejecuta realmente durante el desarrollo (citar una prueba de carga que no se corrió).
- Omitir la columna de alcance técnico y dejar que la comisión descubra en la defensa qué quedó fuera del sistema.
Preguntas frecuentes
¿Toda memoria de Ingeniería Informática necesita hipótesis?
No. Si tu memoria es de producto (diseñar e implementar un sistema), lo habitual es reemplazar la hipótesis por supuestos de diseño y usar requisitos funcionales y no funcionales en lugar de variables. Confírmalo con tu profesor guía, porque el formato varía entre escuelas.
¿Qué instrumento se usa para medir la usabilidad de un sistema?
El System Usability Scale (SUS) es el más citado en memorias de esta carrera por ser corto, de uso libre y con puntaje comparable entre estudios, aunque existen alternativas como cuestionarios de usabilidad más largos. Justifica tu elección en el marco metodológico y declara el tamaño de la muestra piloto que lo respondió.
¿Puedo entregar la matriz de consistencia después del anteproyecto?
Depende del reglamento de tu escuela: muchas la exigen como parte del anteproyecto, otras la piden recién en el informe final. Revisa el reglamento vigente de titulación de tu carrera antes de asumir cualquiera de las dos opciones, y si tu escuela pide ambas, guarda ambas versiones para explicar los cambios en la defensa.
¿Qué pasa si un objetivo específico no se puede medir con un indicador claro?
Es una señal de que el objetivo está mal formulado, no de que el indicador no existe. Reescribe el objetivo con un verbo verificable (implementar, evaluar, comparar) hasta que un indicador surja de forma natural; si sigue sin aparecer, es probable que ese objetivo en realidad sea una tarea, no un objetivo de investigación.
Redacta tu matriz sin perder tiempo en el formato
Tesify te ayuda a estructurar la matriz de consistencia de tu memoria de Ingeniería Informática capítulo por capítulo, a redactar un primer borrador de cada sección que después revisas y ajustas, y a dejar las referencias en APA 7 sin errores de formato. Tú sigues siendo quien decide los indicadores y valida cada dato del sistema; la plataforma se encarga de que la estructura no te haga perder tiempo.