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 ejecución de una rutina, lo que conlleva a resultados incorrectos. Por ello, su uso implica descuentos en el puntaje.
Su trabajo debe hacer uso de las técnicas cubiertas en la asignatura y cuyo aprendizaje se busca evidenciar.
En ELO 329 se espera el uso de la programación orientada a objetos, el no uso de este paradigma implicará descuentos.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.
Los alumnos de ELO 329 sólo deben listar los archivos de la última etapa que desarrollaron.
Es un documento en formato pdf donde se debe incluir un diagrama UML del desarrollo de la tarea, 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.
Para ELO 329 sólo se acepta un diagrama de clases de la última etapa desarrollada para el diagrama UML. Para ELO 330 se acepta el uso de diagramas de secuencia, diagramas de estado o diagramas de casos de uso del último ejercicio desarrollado.
En ELO 329 la explicación de la solución debe centrarse en la interacción entre las clases que componen la última etapa desarrollada al momento de ejecutar su código. No basta con describir que representa cada clase y cuales son sus atributos. En ELO 330 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.
Alumnos de ELO 329 deben generar un archivo makefile por cada etapa desarrollado y ubicarlo en su carpeta respectiva.
Alumnos de ELO 330 deben generar un único makefile que compile todos sus scripts desarrollados.
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 de ELO 329 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 de ELO 330 suelen consistir en varios programas independientes que desempeñan diversas tareas. Por esta razón basta con tener una sola carpeta que almacene todos los archivos utilizados.
Las tareas deben ser almacenadas en repositorios GitLab, espacios centralizados donde se almacena, organiza, mantiene y difunde información digital. Para las asignaturas ELO 329 y 330, estos repositorios deben ser creados y almacenados en el servidor GitLab del departamento de Electrónica. Para hacer uso de éste, se les entregarán una credencial vía e-mail que les permitirá acceder al sitio. Cuando entren por primera vez, deben generar una contraseña usando un enlace seguro proporcionado en el mismo correo. Procuren anotarla en un lugar seguro, será necesaria para crear y administrar sus repositorios!.
Realizado el proceso de registro, se debe crear el repositorio en los servidores de Electrónica. 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.
Se descontará puntaje si no se hace uso de la programación orientada a objetos en la solución de alguna etapa.
En el archivo readme se tiene que listar sólo los archivos de la última etapa desarrollada.
El diagrama UML debe corresponde a un diagrama de clase de la última etapa desarrollada.
En la explicación de la solución se debe describir la interacción entre clases de la última etapa desarrollada.
Almacenar cada etapa en una carpeta diferente con un nombre descriptivo.
Se debe desarrollar un makefile por etapa, ubicándolos en sus respectivas carpetas.
El número de commits en el flujo de trabajo de su repositorio debe ser igual o mayor al triple número de etapas de la tarea.
En el archivo readme se tiene que listar todos los archivos asociados a los scripts desarrollados.
El diagrama UML puede ser un diagrama de secuencia, un diagrama de estado o un par de diagramas de casos de uso del último ejercicio desarrollado.
En la explicación de la solució se debe detallar la estrategia utilizada por cada script desarollado e indicar posibles situaciones de error de éstos.
Almacenar todos los scripts en una única carpeta.
Se debe desarrollar un único makefile para todos los scripts.
El número de commits en el flujo de trabajo de su repositorio debe ser igual o mayor al triple del número de ejercicios de la tarea.
