La mayoría de los errores en la evaluación interna de Informática del IB no proceden de una programación deficiente. Surgen cuando el alumno desarrolla sin especificar el problema, presenta un diseño incoherente, realiza pruebas superficiales o evalúa sin evidencias.
Este artículo se ajusta al programa de Informática del Programa del Diploma cuya primera evaluación será en mayo de 2027. La tarea se denomina oficialmente solución computacional y exige aplicar el pensamiento computacional a un problema del mundo real. Si tu convocatoria es noviembre de 2026, utiliza la guía anterior y confirma los requisitos con tu profesor.
Qué ha cambiado en el nuevo programa
Según la actualización oficial del currículo de Informática, la evaluación interna conserva el desarrollo de una solución, pero se centra expresamente en el pensamiento computacional. Debes mostrar cómo especificaste, descompusiste, modelizaste, desarrollaste, probaste y evaluaste el problema.
La solución computacional ocupa 35 horas lectivas y representa el 30 % en NM y el 20 % en NS. La tarea y los criterios son iguales en ambos niveles. La sinopsis oficial para la primera evaluación de 2027 confirma que debe utilizar conceptos, habilidades y herramientas adquiridos durante el curso.
| Criterio | Función principal |
|---|---|
| A: Especificación del problema | Definir el problema, los requisitos mensurables y los criterios de logro. |
| B: Planificación | Descomponer el problema y establecer una secuencia de trabajo. |
| C: Descripción general del sistema | Modelizar el sistema, formular algoritmos y diseñar pruebas. |
| D: Desarrollo | Construir la solución y justificar las técnicas aplicadas. |
| E: Evaluación | Determinar si se cumplieron los criterios y proponer mejoras. |
Error 1: elegir el proyecto antes que el problema
Un proyecto no es sólido por tener muchas funciones. Debe responder a un problema concreto, con entradas, procesos, salidas, restricciones y resultados observables. Ideas como “crear una aplicación de estudio” son demasiado amplias hasta identificar la dificultad que resolverán.
Antes de programar, define:
- Qué sucede actualmente y por qué constituye un problema.
- Quién experimenta el problema o utilizará la solución.
- Qué tareas realizará el sistema.
- Qué datos recibirá, almacenará o producirá.
- Qué limitaciones técnicas, temporales o de privacidad existen.
- Cómo comprobarás que funciona.
En el programa nuevo, no se exige formalmente un cliente como en la evaluación anterior. Consultar a usuarios reales puede ayudarte a obtener requisitos y comentarios, pero es una recomendación, no un requisito.
Error 2: redactar criterios de logro vagos
Expresiones como “la aplicación será rápida” o “guardará los datos correctamente” no permiten evaluar el resultado. Un criterio debe describir un comportamiento verificable y, cuando corresponda, incluir condiciones mensurables.
“El usuario podrá buscar una reserva por fecha y el sistema mostrará los resultados correspondientes” es más útil que “habrá un buen buscador”. Cada criterio debería convertirse en uno o varios casos de prueba.
| Identificador | Criterio de logro | Componente | Prueba y evidencia |
|---|---|---|---|
| CL1 | Registrar una reserva con campos obligatorios | Formulario y base de datos | Datos válidos, campo vacío y captura del resultado |
| CL2 | Impedir reservas duplicadas | Validación y consulta | Dos reservas equivalentes y resultado esperado |
Esta matriz de trazabilidad no es un formulario oficial. Es una estrategia para mantener conectados los criterios A, B, C, D y E.
Error 3: confundir planificación con calendario
Un diagrama de Gantt por sí solo no demuestra una planificación completa. El criterio B también exige descomponer el problema y presentar una cronología que cubra diseño, desarrollo, pruebas y evaluación.
Divide el sistema por responsabilidades, no solo por pantallas. Una solución de reservas podría incluir autenticación, validación, disponibilidad, almacenamiento y búsqueda. Relaciona cada componente con los criterios y muestra las dependencias entre tareas.
Error 4: diseñar después de programar
Terminar el código y reconstruir después los diagramas produce contradicciones entre el modelo, los algoritmos y la implementación. También oculta el proceso de pensamiento computacional.
La descripción general del sistema debe mostrar cómo se relacionan sus componentes. Puede incluir arquitectura, flujos de datos, modelos de datos, clases, interfaces y algoritmos mediante pseudocódigo o diagramas de flujo. Cada representación debe aclarar información relevante y coincidir con el producto desarrollado.
Error 5: describir funciones sin justificar decisiones
En el criterio D, escribir “creé un botón que guarda registros” demuestra poco. Debes identificar técnicas concretas, explicar cómo implementan los algoritmos y justificar por qué son apropiadas.
Presenta una dificultad técnica, un fragmento breve de código, su funcionamiento y la relación con un criterio o prueba. Evita grandes bloques de código en el informe. La explicación de los criterios de la IA de Informática puede servir como lista de comprobación, pero debes contrastarla con la guía de tu convocatoria.
Error 6: probar únicamente casos que funcionan
Una demostración correcta no sustituye una estrategia de pruebas. Comprueba corrección, fiabilidad y eficiencia mediante casos normales, valores límite y entradas erróneas.
Registra el objetivo, los datos de entrada, el resultado esperado, el resultado obtenido y cualquier corrección. Mostrar un fallo y explicar la modificación demuestra mejor el proceso que ocultar los problemas. Planifica las pruebas en C, aplícalas durante D y utiliza sus resultados en E.
La guía sobre errores habituales en la IA de Informática ofrece consejos sobre alcance y pruebas, aunque algunas referencias al cliente pertenecen al programa anterior.
Error 7: presentar un vídeo poco demostrativo
El vídeo debe probar que el producto realiza las tareas declaradas. Recorrer menús o explicar el código sin ejecutar casos relevantes no demuestra funcionalidad.
Prepara un guion vinculado a los criterios de logro. Introduce datos representativos, muestra resultados y enseña la respuesta ante alguna entrada no válida. El montaje debe permitir distinguir qué hace realmente el programa.
Error 8: convertir la evaluación en elogios
No afirmes simplemente que “todos los objetivos se cumplieron”. Examina cada criterio por separado y basa las conclusiones en pruebas, resultados observables y, cuando corresponda, comentarios de usuarios.
Cada mejora debe responder a una limitación identificada. En vez de “añadiría más seguridad”, especifica el riesgo, el mecanismo que incorporarías y su efecto. La guía sobre evaluaciones internas demasiado débiles ayuda a distinguir limitaciones concretas de observaciones genéricas.
Error 9: documentar todo al final
Dejar la documentación para la última semana hace que se olviden decisiones, fallos y cambios de diseño. Además, aumenta el riesgo de que los diagramas no coincidan con el código.
Después de cada sesión, registra qué cambió, por qué y qué evidencia lo demuestra. Utiliza control de versiones, copias de seguridad y un registro de pruebas. La guía general de evaluación interna puede ayudarte a establecer revisiones periódicas.
Revisión antes de entregar
Comprueba estos aspectos por separado:
- Coherencia: problema, criterios, diseño, desarrollo y evaluación describen el mismo producto.
- Evidencia: cada afirmación importante está respaldada por una prueba.
- Criterios: utilizas los descriptores de tu convocatoria, no ejemplos antiguos.
- Técnica: ejecutas la solución desde una instalación limpia y verificas dependencias.
- Autenticidad: citas bibliotecas, código adaptado y asistencia externa.
- Concisión: eliminas descripciones obvias y conservas las justificaciones técnicas.
Los ejemplos de evaluación interna de Informática ayudan a estudiar formas de presentar evidencia. Muchos corresponden al programa anterior, por lo que no debes copiar su estructura ni asumir que sus criterios siguen vigentes.
Conclusión
Una buena solución computacional no tiene que ser la aplicación más compleja. Debe partir de un problema bien especificado, mantener la trazabilidad entre criterios y pruebas, justificar sus decisiones y evaluar sus limitaciones con honestidad.
Trabaja desde los criterios, registra evidencias durante el desarrollo y verifica la convocatoria aplicable. Para la revisión final, puedes combinar Coursework Review de RevisionDojo con Jojo AI para detectar secciones poco justificadas, sin delegar la autoría ni el razonamiento.
Sources and referenced URLs
- Actualización oficial del currículo de Informática del IB
- Sinopsis oficial de Informática, primera evaluación en 2027
- Criterios actuales de la IA de Informática en RevisionDojo
- Errores habituales en la IA de Informática
- Por qué muchas evaluaciones internas son demasiado débiles
- Guía general de evaluación interna del IB
- Ejemplos de evaluación interna de Informática