Las tareas serán evaluadas de acuerdo a los siguientes criterios:
Los programas compilan sin errores ni warnings. En caso de que durante la compilación se presenten errores de sencilla solución, el ayudante intentará repararlos y se evaluará el ejercicio o etapa asociada, aplicando un descuento por compilación.
Si los errores son difíciles de corregir o no permiten la ejecución de la tarea, no se podrá comprobar si ésta cumple con los requisitos solicitados y por ende, el ejercicio o etapa asociada se evaluará con un cero.
Se evalúan los archivos readme, makefile y de documentación, respetando los formatos indicados. Se evalúa también gráficos y/o imágenes solicitadas en el enunciado de la tarea. Además, se evalúa el uso de la herramienta Git por cada uno de los miembros, en base a las indicaciones dadas en esta sección.
La tarea debe cumplir con cada uno de los hitos planteados para cada una de los ejercicios o etapas solicitadas.
No se debe aplicar "hard coding", que corresponde a la mala práctica de incrustar datos directamente en su código, en vez de obtenerlos a través de la definición de alguna constante con nombre acorde. Por ello, el uso de "hard coding" implica descuentos en el puntaje.
Su trabajo debe hacer uso de las técnicas cubiertas en la asignatura y cuyo aprendizaje se busca evidenciar.
La división del puntaje en dichas secciones queda al criterio de los ayudantes, quienes se compromenten a aplicarla de igual forma a todos los estudiantes.
Los elementos que deben estar presentes en la versión final de su tarea son: un archivo readme en formato de texto plano o markdown, una documentación simple en un archivo pdf, un archivo makefile y unos archivos fuente. Cualquier otro archivo que deba agregarse a la tarea, será notificado con anticipación.
Una descripción detallada de estos archivos se encuentra a continuación:
En este texto de formato txt o md se debe mencionar los archivos que componen la tarea, explicar cómo compilar cada ejercicio o etapa desarrollada, y detallar cómo se debe ejecutar cada una de ellas, con el objetivo de que un usuario que no tenga conocimientos sobre su programa sepa su función principal y como llevarla a cabo.
De ser necesario, otras cosas pueden ser agregadas para dar completitud al entendimiento de la tarea. Sólo debe generarse un archivo readme para toda la tarea, no es necesario generar uno por cada ejercicio o etapa desarrollada.
En caso de que la tarea a realizar cuente con un ejercicio o etapa adicional que brinde una bonificación extra de puntaje, se debe especificar en el documento si se decide optar a esta bonificación.
Sólo deben listar los archivos de la última etapa que desarrollaron.
Es un documento en formato pdf donde se debe incluir una explicación breve de la solución y un breve listado con 3 dificultades presentadas durante el desarrollo de la tarea y las soluciones implementadas para abordarlas.
Normalmente el archivo de documentación tiene un alto peso en la nota de la tarea. Por favor no omitir este ítem.
La explicación de la solución debe enfocarse en la estrategía utilizada por cada script desarrollado, además de indicar posibles situaciones donde puede fallar su script.
Las dificultades que se mencionen deben estar relacionadas con el proceso de elaboración de su tarea, no con elementos ajenos a ella. Por ejemplo, se acepta la falta de comprensión de una biblioteca como una dificultad. Por el contrario, no se acepta como una dificultad la falta de coordinación para el trabajo de un equipo o la falta de dominio de la herramienta Git.
En caso de no lograr solucionar las dificultades encontradas, se debe señalar lo que hizo falta para abordar el problema de mejor forma.
Por último, debes incluir la información que estimes importante para entender tu solución, además de otros elementos que pueden ser solicitados en los enunciados.
Este archivo permite compilar los módulos de la tarea, de modo que al ejecutar el comando make en la carpeta del código a utilizar, todos los archivos sean compilados y la tarea se encuentre lista para ser ejecutada.
Se debe generar un archivo makefile por cada etapa desarrollado y ubicarlo en su carpeta respectiva.
El código debe ser estéticamente correcto (buen uso de espacios, saltos de linea y debe estar indentado). Esto facilita la lectura y la comprensión del flujo del código.
Además, se espera que los nombres de las variables y funciones sean concisos y autoexplicativos (es decir, que su nombre sea corto y que además ofrezca indicios de su propósito).
Se debe comentar el código para clarificar el funcionamiento de las distintas secciónes de código.
En este sitio se pueden encontrar consejos para escribir un buen código.
Las tareas suelen estar divididas en etapas, por ello el desarrollo de cada una de estas debe estar almacenada en una carpeta diferente, con un nombre descriptivo (Etapa 1, Etapa A, etc). Esto permite la evaluación del método de desarrollo iterativo e incremental, permite un repositorio más ordenado y facilita la labor de corrección en ésta.
Las tareas deben ser almacenadas en repositorios GitLab, espacios centralizados donde se almacena, organiza, mantiene y difunde información digital. El título del repositorio creado para cada tarea debe cumplir con el siguiente formato:
Un ejemplo de título es el siguiente:
El repositorio debe tener como colaboradores a los ayudantes del ramo.
Los archivos finales de la tarea deben estar subidos en el branch principal ("master"). Al realizar la ultima publicación, agregar el tag "Final" al commit y realizar push con opción de tags habilitada:
Los tags son marcadores que se le aplican a los commits, pasa a ser una propiedad del commit en cuestión y por ello, es distinto del mensaje asociado al commit.
La revisión de la hora/fecha de entrega se realizará con respecto al último commit del tag "Final". Si este tag no se encuentra en el repositorio, ¡la tarea no se considerará entregada!. Por ello, recuerden utilizar el comando git Tag al finalizar su tarea.
Si tienen problemas usando Git, pueden ver una pequeña referencia en el apartado Ayuda Git.
Los repositorios deben ser privados, con el fin de evitar la copia entre grupos. Para privatizar su repositorio revisar la sección Privatizar Repositorio.
Se efectuará un descuento de 5 puntos por día de atraso cumplido. (incluyendo sábados, domingos y feriados).
Antes distintas situaciones que pudiesen ocurrir, los ayudantes se reservan el derecho de no evaluar las tareas entregadas por los grupos, siendo algunos de los casos más recurrentes los siguientes:
Si bien estas causas podrían generar la omisión de la evaluación de su trabajo, esto no es definitivo. Primero se avisa a los involucrados y al profesor de la asignatura de la situación vía e-mail, dando la posibilidad de refutar esta decisión.
Se denomina flujo de trabajo en Git a la serie de commit y merge que son incorporados a repositorio y que entregan los archivos al proyecto.
Es importante seguir una conducta adecuada al momento de formar el flujo de trabajo, con el propósito de que al ser inspeccionado por otros desarrolladores, sean capaces de entender como ha progresado el proyecto y cuales cambios se han realizado en él.
Es por ello que se establecen las siguientes normas para la evaluación del uso de la herramienta Git.
