SUS, QUIS, TAM, ISO 25010 o heurísticas de Nielsen: con qué instrumento validas el software de tu trabajo de grado (2026)
El sistema funciona. Está desplegado, la base de datos responde, los módulos hacen lo que prometiste en el anteproyecto. Y entonces llega la pregunta que hunde trabajos de grado en Ingeniería de Sistemas: «¿cómo validó usted que el software cumple su objetivo?». Si la respuesta es «le pregunté a diez compañeros si les había gustado», el capítulo de resultados no existe.
La validación no es un trámite: es el capítulo que convierte un desarrollo en un trabajo de grado. Esta comparativa te dice qué instrumento corresponde a cada objetivo, cuántos usuarios necesita, qué cuesta y cuáles son sus límites reales, incluidos los que casi nadie menciona.
Primero: qué objetivo específico estás evaluando
La elección del instrumento la determina el verbo de tu objetivo específico, no la moda. Hay cuatro objetivos distintos que se confunden todo el tiempo:
- Usabilidad percibida: qué tan fácil le resulta el sistema a quien lo usa. → SUS, UMUX-Lite, QUIS.
- Aceptación e intención de uso: si la gente lo adoptaría. → TAM, UTAUT.
- Calidad del producto software: si el sistema cumple características técnicas definidas. → ISO/IEC 25010.
- Detección de problemas de interfaz: qué hay que arreglar. → evaluación heurística, pruebas con tareas.
Un error costoso: aplicar SUS cuando tu objetivo dice «evaluar la calidad del software». SUS no mide calidad de software, mide usabilidad percibida. El jurado que sabe la diferencia lo va a señalar.
1. SUS (System Usability Scale)
Qué es: 10 ítems en escala Likert de 5 puntos, alternando enunciados positivos y negativos. Produce un puntaje único de 0 a 100 (que no es un porcentaje).
Cálculo: en los ítems impares se resta 1 al valor marcado; en los pares se resta el valor marcado a 5; se suman los diez resultados y se multiplican por 2,5.
Interpretación: la referencia más usada en la literatura sitúa el promedio de sistemas evaluados alrededor de 68 puntos, con escalas de calificación por percentiles publicadas por Sauro y Bangor. Un puntaje por debajo de 68 indica usabilidad por debajo del promedio de los sistemas evaluados en esos estudios.
Participantes: funciona con muestras pequeñas; entre 12 y 20 usuarios da estimaciones razonables para un trabajo de grado.
Costo: gratuito y de uso libre para fines académicos.
Ventajas: es el estándar de facto, rapidísimo de aplicar (dos minutos), tiene benchmark publicado y existen versiones traducidas y validadas al español que puedes citar en lugar de traducir tú.
Límites que debes declarar: da un número global sin diagnóstico —te dice que hay un problema, no cuál—; es sensible al momento de aplicación; y con menos de 10 usuarios el intervalo de confianza es tan amplio que el puntaje pierde utilidad comparativa.
Advertencia importante: no traduzcas tú mismo el cuestionario. Usa una versión ya validada al español y cítala. Los criterios sobre permisos y adaptación están en la guía sobre usar la escala de otro autor.
2. UMUX-Lite
Qué es: dos ítems (utilidad percibida y facilidad de uso) que, según la literatura, correlacionan alto con SUS.
Cuándo conviene: cuando necesitas medir de forma repetida, dentro de la aplicación, o cuando el tiempo del usuario es escasísimo (personal de salud, operarios en turno).
Límite serio: con dos ítems no puedes reportar consistencia interna de forma convincente, y el jurado suele preferir SUS por familiaridad. Úsalo como complemento, no como instrumento único, salvo que justifiques muy bien la restricción de tiempo.
3. QUIS (Questionnaire for User Interaction Satisfaction)
Qué es: cuestionario extenso, con versiones de 27 ítems y superiores, organizado en factores: reacción general, pantalla, terminología, aprendizaje, capacidades del sistema.
Ventaja real sobre SUS: es diagnóstico. Al estar organizado por factores, te dice dónde está el problema, lo que alimenta directamente un capítulo de recomendaciones.
Costo: la versión oficial se licencia a través de la Universidad de Maryland, con tarifa reducida para uso académico. Verifica las condiciones antes de usarlo: aplicar una versión no autorizada es un problema de integridad, no solo de forma.
Participantes: al ser más largo, conviene tener al menos 25-30 respuestas para que el análisis por factores tenga sentido.
Límite: la tasa de abandono sube con la longitud, y en muestras pequeñas los factores no se sostienen estadísticamente.
4. TAM (Technology Acceptance Model)
Qué es: un modelo, no un cuestionario suelto. Mide utilidad percibida, facilidad de uso percibida, actitud e intención de uso, y postula relaciones entre esos constructos.
Cuándo usarlo: cuando tu objetivo es explicar la adopción, no medir usabilidad. Es frecuente y pertinente en trabajos donde el sistema se implanta en una organización real.
El problema del que nadie advierte: TAM se evalúa correctamente con modelos de ecuaciones estructurales. Con 20 respuestas no puedes estimar un modelo estructural. Las reglas prácticas para PLS-SEM sugieren muestras que en la práctica rara vez bajan de 60-100 casos, según el número de constructos y de indicadores. Si tu población total son 15 usuarios del sistema, TAM no es tu instrumento por más elegante que se vea en el anteproyecto.
Alternativa honesta: si tienes pocos usuarios pero quieres el marco TAM, reporta estadística descriptiva por constructo y declara explícitamente que no se estimó el modelo estructural por tamaño de muestra. Es defendible; simular un SEM con 20 casos no lo es.
5. ISO/IEC 25010 (SQuaRE)
Qué es: un modelo de calidad de producto software con ocho características —adecuación funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad— cada una con subcaracterísticas.
Por qué es tan usado en trabajos de grado colombianos: porque permite evaluar el software como producto, sin depender de una muestra grande de usuarios, y porque encaja bien con objetivos redactados como «evaluar la calidad del sistema desarrollado».
Lo que casi todos hacen mal: no basta con nombrar la norma. Hay que operacionalizar: seleccionar qué características se evalúan y justificar por qué se descartan las otras, definir métricas concretas para cada subcaracterística (tiempo de respuesta en segundos bajo carga X, tasa de defectos por módulo, cobertura de pruebas en porcentaje), y fijar valores de aceptación antes de medir. Un capítulo que dice «se evaluó según ISO/IEC 25010» y muestra una encuesta de 15 preguntas inventadas no está usando la norma: está usando su nombre.
Costo: el texto oficial de la norma es de pago. Puedes construir tu instrumento a partir de literatura académica que la documenta, citando esas fuentes.
Combinación recomendada: ISO/IEC 25010 para las características técnicas, medidas con métricas objetivas, más SUS para la subcaracterística de usabilidad medida con usuarios. Es la combinación que mejor resiste preguntas del jurado.
6. Evaluación heurística de Nielsen
Qué es: inspección de la interfaz contra diez principios de usabilidad, realizada por evaluadores con conocimiento del área, no por usuarios finales.
Cuántos evaluadores: la recomendación clásica es de 3 a 5 evaluadores independientes, porque un solo evaluador detecta una fracción de los problemas.
Qué se reporta: lista de problemas encontrados, heurística violada en cada uno, y calificación de severidad (habitualmente en una escala de 0 a 4) promediada entre evaluadores.
Ventaja: es barata, rápida y no requiere reclutar usuarios. Excelente cuando tu sistema es interno y tiene pocos usuarios reales.
Límite que hay que decir en voz alta: la evaluación heurística no sustituye la prueba con usuarios. Detecta problemas potenciales de interfaz, no comportamiento real. Presentarla como validación completa es la debilidad más frecuente de estos capítulos.
7. Pruebas de usabilidad con tareas
Qué es: se le pide al usuario ejecutar tareas concretas y se registran métricas objetivas: tasa de éxito, tiempo por tarea, número de errores, número de solicitudes de ayuda.
Por qué vale tanto: son los únicos datos de comportamiento real. Un usuario puede darte 80 en SUS y no haber logrado completar la tarea principal.
Participantes: la literatura de usabilidad sostiene que 5 usuarios por perfil detectan la mayoría de los problemas de interfaz. Para estimar tasas de éxito con precisión, necesitas más.
Cómo se reporta: tabla con tarea, tasa de éxito, tiempo medio y desviación, y errores. Combinado con SUS, produce un capítulo de validación sólido y difícil de objetar.
Tabla de decisión rápida
- Sistema con muchos usuarios y objetivo de usabilidad → SUS + pruebas con tareas.
- Sistema interno con 5-15 usuarios → evaluación heurística (3-5 expertos) + pruebas con tareas + SUS descriptivo, declarando la limitación de muestra.
- Objetivo de calidad del producto → ISO/IEC 25010 operacionalizada con métricas + SUS para usabilidad.
- Objetivo de adopción organizacional y ≥ 60 respuestas → TAM o UTAUT con modelo estructural.
- Necesitas diagnóstico detallado de interfaz → QUIS (verificando licencia) o heurísticas.
Lo que debes reportar sí o sí en el capítulo
- Perfil y número de participantes, con criterio de selección. «Diez estudiantes» no es un perfil; «diez auxiliares administrativos del área de facturación, con antigüedad mayor a seis meses» sí lo es.
- Instrumento con su fuente: autor, año, versión en español utilizada y referencia completa. Si lo adaptaste, cuáles fueron los cambios.
- Validez de contenido, si construiste ítems propios. El procedimiento de juicio de expertos y cálculo de la V de Aiken es lo que convierte un cuestionario improvisado en un instrumento defendible.
- Confiabilidad: alfa de Cronbach por dimensión, no global, cuando el instrumento es multidimensional. Si te sale bajo, no lo escondas: diagnostícalo y explica qué hiciste.
- Procedimiento: cómo se aplicó, en qué contexto, con qué instrucciones y en qué momento respecto al uso del sistema.
- Consentimiento informado y tratamiento de datos personales conforme a la Ley 1581 de 2012, con el formato en anexos.
- Limitaciones: tamaño de muestra, sesgo de selección, efecto de deseabilidad social cuando el evaluador es el propio desarrollador.
Sobre el último punto: que tú apliques el instrumento a usuarios que saben que tú lo desarrollaste introduce un sesgo real. No lo puedes eliminar en un trabajo de grado, pero declararlo en la sección de limitaciones te protege de la objeción. Para el análisis de las respuestas Likert, las reglas de puntuación y de nivel de medición están en la guía sobre cómo diseñar, puntuar y analizar una escala de Likert, y si necesitas dimensionar la muestra con criterio estadístico, el cálculo está en la guía de tamaño de muestra y potencia.
Un asunto aparte pero del mismo capítulo: si tu desarrollo incorpora bibliotecas, fragmentos de repositorios públicos o código sugerido por asistentes de IA, revisa las licencias y declara el origen. Los criterios están en la guía sobre plagio de código, datos e imágenes.
Si el instrumento ya está definido y lo que te falta es redactar el capítulo de validación con la estructura y las referencias que pide tu programa, puedes escribirlo en Tesify y dedicar tus horas a lo que sí requiere tu criterio de ingeniero: el sistema y la interpretación de los resultados.
Preguntas frecuentes
¿Cuántos usuarios necesito para aplicar SUS en un trabajo de grado?
Entre 12 y 20 usuarios es el rango que produce estimaciones razonables para un trabajo de grado de pregrado. Con menos de 10 el intervalo de confianza del puntaje se vuelve tan amplio que comparar contra el promedio de referencia pierde sentido. Si tu sistema tiene una población total menor que esa, aplica censo, reporta el número exacto y declara la limitación en el capítulo; es preferible a inflar la muestra con usuarios que no corresponden al perfil real.
¿Puedo inventar mi propio cuestionario de usabilidad?
Puedes, pero entonces debes validarlo, y eso agrega trabajo: validez de contenido por juicio de expertos con cálculo de un índice de acuerdo, prueba piloto y reporte de confiabilidad. Un instrumento propio sin validación es la observación más frecuente en las actas de jurado. Usar un instrumento ya validado con versión en español publicada te ahorra ese proceso y además te da un referente de comparación externo que tu cuestionario propio nunca tendrá.
¿Un puntaje SUS de 75 es bueno?
Está por encima del promedio de referencia de aproximadamente 68 puntos reportado en la literatura sobre sistemas evaluados con este instrumento, lo que suele interpretarse como usabilidad aceptable. Dos precauciones: el puntaje no es un porcentaje, así que 75 no significa «75 % de usabilidad»; y con muestras pequeñas conviene reportar también el intervalo de confianza, porque un promedio de 75 con 12 usuarios puede tener un margen amplio.
¿ISO/IEC 25010 reemplaza la evaluación con usuarios?
No. El modelo incluye la usabilidad como una de sus características, y esa característica se mide con usuarios. Lo que la norma aporta es un marco para evaluar el producto de forma integral, incluyendo dimensiones técnicas —fiabilidad, seguridad, mantenibilidad, eficiencia— que ninguna encuesta de usuario captura. La combinación adecuada es métricas objetivas para las características técnicas y un instrumento validado con usuarios para la usabilidad.
¿Necesito aval de comité de ética para evaluar mi sistema con usuarios?
Depende de tu universidad y del perfil de los participantes. Evaluar usabilidad con usuarios adultos en su contexto laboral suele clasificarse como riesgo mínimo y muchas facultades lo resuelven con consentimiento informado. Si tu sistema es del sector salud, involucra menores de edad o maneja datos sensibles, casi siempre se exige aval formal. En todos los casos necesitas consentimiento informado por escrito y cumplir la normativa de tratamiento de datos personales.