## Normas y Procedimientos de Entrega de Tareas

- Criterios de Evaluación de Tareas
- Archivos a Entregar
- Procedimiento de Entrega de Tareas
- Norma de Atrasos
- Casos Especiales de No Evaluación
- Flujo de Trabajo de Repositorio Git

### Criterios de Evaluación de Tareas

Las tareas serán evaluadas de acuerdo a los siguientes criterios:

- Compilación (10%):

  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.

- Documentación General (30%):

  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.

- Cumplimiento De Requerimientos (60%):

  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.

### Archivos a Entregar

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:

#### Readme

- 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.

#### Documentación

- 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.

#### Makefile

- 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.

#### Archivos fuente (.c .cpp .java .sh) y de encabezado (.h)

- 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.

#### Organización de Archivos

- 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.

### Procedimiento de Entrega de Tareas

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:

apellido_alumno_1.nombre_alumno1-apellido_alumno_2.nombre_alumno2-apellido_alumno_3.nombre_alumno3-TareaX.año.semestre

Un ejemplo de título es el siguiente:

arancibia.pilar-marquez.jesus-rojas.gonzalo-Tarea1.2023.2.

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:

$ git commit -m "This is a Final commit"
$ git tag Final
$ git push origin master --tags

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.

#### Importante

Los repositorios deben ser privados, con el fin de evitar la copia entre grupos. Para privatizar su repositorio revisar la sección Privatizar Repositorio.

### Norma de Atrasos

Se efectuará un descuento de 5 puntos por día de atraso cumplido. (incluyendo sábados, domingos y feriados).

### Casos Especiales de No Evaluación

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:

- El grupo entrega su tarea con un atraso mayor a 8 días y/o posterior a la finalización de evaluación del resto de los grupos.
- El grupo no respeta el formato para el nombre del repositorio, no agrega a los ayudantes como colaboradores al proyecto y no se marca un tag Final.
- Si luego de una inspección de su trabajo, el posible puntaje obtenido por su grupo es de la misma magnitud que los descuentos aplicados.

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.

### Flujo de Trabajo de Repositorio Git

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.

- Todos los integrantes deben realizar un número similar de commits, con el fin de demostrar un dominio individual en el uso de esta herramienta y una buena coordinación del trabajo grupal.
- En general, el número de commits totales de la tarea deberá ser igual o mayor al triple del número de ejercicios o etapas de la tarea.
- Se debe mantener la formalidad en los commits (no crear commit con lenguaje vulgar u ofensivo).
- Los commits deben poseer información relevante: deben indicar los cambios realizados a los códigos de forma resumida. No son aceptados commits que sólo dicen: “actualización”, “readme”, “etapa 1”.
- No se deben subir las etapas completas en uno o dos commits ni subir todos los códigos el mismo día de la entrega. Se debe subir el código a medida que es confeccionado. Esto principalmente por los varios beneficios que conlleva la práctica sugerida, tales como tener un respaldo de estados anteriores ante posibles cambios que dañen su programa.