Reglas para la entrega de prácticas

Reglas obligatorias para la entrega de prácticas

Descarga Veriprac, que automatiza el empaquetamiento de tus prácticas.

Las prácticas no deben ser entregadas, en su caso, más allá del día del examen en primera, segunda convocatoria o convocatoria extraordinaria. En caso de que se especifique una fecha de entrega sera esta la que rija.

La entrega se realizará utilizando la plataforma de docencia, a no ser que se indique lo contrario. El título del trabajo y el nombre del archivo seguirán el esquema [asignatura]_[número de práctica | proyecto]- [apellido1_apellido2_nombre-dni]. Por ejemplo, "ALS-proyecto-rdgz_gcia_manuel-12345678D".

Además de entregar el código como se indica (debido a cuestiones de archivo), se subirá el mismo a un repositorio a elección del alumno. Este se indicará en el archivo info.txt (ver más adelante).

Cada práctica se entregará en un envío diferente³, siendo obligatorio incluir los distintos archivos en un fichero adjunto en formato zip (absténgase de usar cualesquiera otros formatos, con mención especial al no estándar rar).

A no ser que se especifique lo contrario, el archivo zip contendrá las siguientes carpetas. El nombre del archivo será igual al del asunto del envío. El contenido principal del archivo zip, serán las carpetas src/, bin/ y doc/, que estarán a su vez dentro de una carpeta con el mismo nombre que el archivo zip.

ALS_1-rdgz_gcia_manuel.zip

ALS_1-rdgz_gcia_manuel/

src/

Código fuente completo de la práctica.

bin/ (si no es aplicación web)

Ejecutable de la práctica¹. Debe de ser capaz de funcionar sin librerías externas, en una medida razonable. Así, se cree con el entorno que se cree, debe ser compilado de manera estática, es decir, con todas las dll's necesarias en su interior.

doc/

info.txt
- Título del proyecto.
- URL del proyecto (si es web).
- Apellidos y nombre.
- DNI
Documentación de la práctica, en formato PDF².
Diagramas (si fueren necesarios), en formato png o jpg.

Todas las prácticas son estricta y exclusivamente individuales (a no ser que se especifique lo contrario). Deben seguirse al menos las normas de diseño, formato y documentación vistas en clase.

La inobservancia de estas normas conllevará la no consideración de la práctica.

Recomendaciones: autoevaluación (tomado del curso: Aprendizaje basado en problemas, Javier Bará y Miguel Valero)

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:

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.

El formato PDF/A. 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.

Dirección de correo electrónico del profesor: baltasarq@uvigo.gal