Reglas obligatorias para la entrega de prácticas


Criterio Notable Suficiente Insuficiente
Correcto La aplicación funciona bien en todas las pruebas realizadas, como mucho ha fallado una vez. Ha fallado en tres o cuatro ocasiones. Falla con mucha frecuencia.
Robusto La aplicación resiste sin bloquearse todos los errores típicos que puedan aparecer. No ha sido posible hacer que se cuelgue. Razonablemente robusta. No es fácil conseguirlo, pero en tres o cuatro ocasiones se bloqueó. No es robusta en absoluto. Se queda bloqueada ante situaciones típicas.
Amigable El usuario no tiene ninguna duda en ningún momento sobre cómo interactuar con la aplicación, qué datos debe introducir, o cómo interpretar los mensajes o resultados que le muestra. La aplicación da la suficiente información, y es suficientemente intuitiva como para trabajar bien, aunque en alguna ocasión no se comprende del todo qué es lo que hay que hacer o cómo hacerlo. El usuario tiene dudas constantes sobre lo que hay que hacer, y no es sencillo interpretar los mensajes o resultados que muestra.
Organizada y documentada El código está bien organizado y estructurado. Sería muy sencillo encontrar el código a cambiar para una modificación puntual. Cada clase y función tienen un mensaje explicativo sobre su funcionalidad en su parte superior (en el caso de las funciones se explican también los parámetros de entrada). El código está bien indentado, y los diferentes identificadores se han escogido de manera que sean significativos, y son homogéneos (mismos identificadores para ciertas funcionalidades muy comunes, mismas abreviaturas para los mismos conceptos). En general el código está bien organizado, si bien en algunos puntos se echa de menos algún comentario, o un comentario más explicativo. La estructura de clases o funciones es correcta, aunque podría mejorarse. Los identificadores no siempre son los más intuitivos, o no son homogéneos. La estructura del código no tiene lógica, la separación entre clases o funciones no es intuitiva o no está bien documentada. Los identificadores no son intuitivos u homogéneos en absoluto.
Comparado con el nuestro El código es mejor. El código es similar. El código es peor.


Notas:
  1. Los ejecutables siempre (no sólo en prácticas de una asignatura) se entregan en modo release (nunca en modo debug (depuración)), y de manera que sean lo más independientes posible, es decir, incluyendo las dll's u otras librerías necesarias. Es probable incluso el tener que probar el ejecutable en un ordenador que no tenga instalado el entorno de desarrollo elegido.
  2. El formato PDF es portable y estándar, y es por ello un formato adecuado para entregar documentación en cualquier situación (otros formatos también adecuados, si bien hoy en día menos extendidos, son PS y DVI). Formatos como odt son estándar, pero no sólo están pensados para leer un documento sino para editarlo (cosa que un profesor nunca hará con una documentación de una práctica), por lo que no tiene sentido entregar la documentación en él (lo mismo es aplicable a docx). El formato doc es absolutamente inexcusable: es un formato no estándar, y no portable excepto entre aplicaciones MS Word. Se ruega abstenerse de entregar documentación en este formato.
  3. Dirección de correo electrónico del profesor: jbgarcia@uvigo.es