Sobre las tareas y controles

Lenguajes de Programación
Reglas del juego
Mauricio Araya Jorge Valencia
maray@inf.utfsm.cl jorjazo@labsd.inf.utfsm.cl
Roberto Bonvallet Jorge Avarias
rbonvall@inf.utfsm.cl javarias@alumnos.inf.utfsm.cl
Norman Saez
nsaez@alumnos.inf.utfsm.cl
Tomás Staig
tstaig@alumnos.inf.utfsm.cl
Martes 20 de marzo
Primer semestre de 2007

1. Introducción
Dada la relevancia de las tareas y controles en el ramo de Lenguajes de
Programación, es necesario explicar una metodologı́a de trabajo y corrección
clara para evitar problemas posteriores. El objetivo de este documento es contar
con una piedra angular donde se describan las reglas del juego y de esta forma
realizar un trabajo armónico entre evaluadores y evaluados.

2. Sobre las evaluaciones

El conjunto de evaluaciones que integran las tareas y controles será conside-
rado en la evaluación final con una poderación del 35 %. Este conjunto está de-
terminado por 5 tareas obligatorias y 2 controles obligatorios con la misma
ponderación cada ı́tem. En resumen:
Tarea 1 + Tarea 2 + Tarea 3 + Tarea 4 + Tarea 5 + Control 1 + Control 2
Nt =
7
En el caso de que el estudiante no cuente con todas las evaluaciones necesa-
rias (tanto de forma justificada como no), es responsabilidad del estudiante (y

1
sólo del estudiante) acercarse a los ayudantes o al profesor a aclarar el proble-
ma. En caso contrario, aquella evaluacion será considerada con nota 0. Cualquier
intento o efecto de fraude o copia, será automáticamente evaluado con nota 0.

2.1. Sobre los controles

Se considerará 2 controles de lectura de carácter individual para cubrir algu-
nos temas de difı́cil evaluación práctica mediante tareas. Estos controles serán
realizados en los últimos 30 minutos de las catedras del ramo. Las fechas de los
controles serán informados oportunamente por los canales oficiales.
Existirá un control y un certamen recuperativo, pero estas instancias son
sólo para estudiantes que falten a alguna evaluación. No se podrá asistir al
recuperativo para borrar, ponderar o cambiar alguna nota de las evaluaciones
anteriores.

2.2. sobre las tareas

Se considerará 5 tareas prácticas de programación (una por cada paradigma
de programación), las cuales deberan cumplir las siguientes restricciones:

2.2.1. Entrega
Las tareas son de caracter individual, es decir en grupos de a lo más una
sola persona.
Las tareas tienen una fecha lı́mite de entrega, la que será especificada con
cada tarea. En el caso de que el curso solicite aplazamiento y éste sea
concedido, las fechas de publicación y entrega de la siguiente tarea no
serán modificada bajo ninguna circunstancia.

El formato de entrega es rol-tareaX.tar.gz1 siendo rol el número único

designado por la Universidad, y X el número de tarea que se está entregan-
do. Por ejemplo, la primera tarea del ayudante Jorge Avarias hjavarias@alumnos.inf.utfsm.cli
serı́a 2273020-7-tarea1.tar.gz. La información que debe contener se es-
pecifica en cada tarea, dentro de un directorio llamado tareaX (en nuestro
ejemplo, tarea1). Si no se sigue este formato, se penalizará con un des-
cuento en la nota final de la tarea.

El método de entrega es mediante el uso de la plataforma de e-learning del

Departamento de Informática: .LRN http://dotlrn.inf.utfsm.cl. Ca-
da tarea debe ser depositada en la carpeta correspondiente a la tarea, por
ejemplo: La tarea 1 debe ser depositada en la carpeta denominada Tarea1,
y asi con las demás. Si por cualquier motivo la tarea no se encontrase en
su lugar correspondiente, ella no será corregida.
1 Lea el manual en linea de tar(1)

2
 El atraso de entrega de tareas será penalizado con 20 puntos por dı́a, inclu-
yendo sábados y domingos, hasta llegar a una nota 0 la cual no será recom-
pensable, cambiable o eliminable. En caso de que no entregar una tarea,
esto deberá indicarse explı́citamente a los ayudantes dentro del plazo de
entrega.

La entrega de multiples versiones de la misma tarea no esta permitido. Si

el estudiante desea hacer algun cambio debe realizarlo sobre la copia ya
entregada y no agregar una nueva copia a la carpeta de tareas. De omitir
esto, el afectado se arriesga a un descuento de por lo menos 20 puntos y a
la corrección de la ultima versión de la tarea entregada.

2.2.2. Contenido
Los tarballs de entrega (archivos rol-tareaX.tar.gz) deben contener
el código fuente completo, un archivo Makefile2 , un archivo README y
cualquier otro archivo necesario para la compilación y ejecución de la
tarea.

El archivo Makefile debe generar mediante make(1) los binarios o ejecu-

tables especificados en cada tarea. Estos binarios/ejecutables deben tener
exactamente los mismos nombres especificados en cada tarea. En el caso
de lenguajes interpretados, el Makefile debe preparar la tarea para su
limpia ejecución.

El archivo README deberá contener toda la información del autor y progra-

ma, ademas de los supuestos necesarios. Se deberá describir la estrategia
utilizada para solucionar el problema.

Se indicará precisamente los formatos de entrada y salida de cada una

de las tareas, y se dará entradas y salidas de ejemplo. Programas que no
respeten estos formatos serán automáticamente consideradas incorrectas.

2.2.3. Corrección
El Laboratorio destinado para trabajar en estas tareas es el Laboratorio
de Computación del Departamento de Informática3 , por lo que las herra-
mientas de corrección, ejecución y compilación a utilizar serán las provistas
por este laboratorio. Es responsabilidad de cada uno verificar que la tarea
compile y se ejecute correctamente en este ambiente. En caso de no ocurrir
ası́, la tarea se considerará incorrecta automáticamente.

El formato de interacción de las tareas intentará ser el más sencillo po-

sible, y se describirá en cada tarea. En consecuencia, utilizarán archivos
2 Lea el manual en lı́nea de make(1)
3 Ubicado en el piso 0 del edificio F

3
 (generalmente entrada y salida estándares, o archivos con nombres prede-
finidos). Tareas con menúes interactivos o interfaces gráficas automática-
mente serán consideradas incorrectas por no respetar el formato.
Existirán dos métodos de evaluación de una tarea determinada, que se
elegirán para cada uno en forma “aleatoria”:
1. El programa se compilará y ejecutará con un conjunto de casos de
prueba, aplicándose la pauta de corrección general indicada más ade-
lante.
2. Mediante una interrogación oral en el computador, en la cual el es-
tudiante deberá explicar cómo desarrolló el programa que entregó, y
su comprensión de los conceptos involucrados.

En cada caso, el plazo para apelar será de una semana después de entregar las
notas.

3. Pauta de corrección de tareas

La pauta de evaluación de tareas consta de los siguientes conceptos:

Compilación y ejecución (30 %)

• Compila y ejecuta sin warnings (5 %)
Compila (con -Wall en el caso de C) sin ningún tipo de aviso o se
ejecuta sin lanzar errores
• Correctitud (25 %)
El programa funciona correctamente con los casos de prueba provistos
en la tarea y con casos de prueba que el estudiante desconoce. No se
probarán datos no válidos, por lo que no es necesario el chequeo de
los valores de entrada.
Evaluación del código4 (70 %)
• Organización (20 %)
El código es modular, manejable, lógico y ordenado. Las funciones,
tipos, estructuras, condiciones, etc. estan coherentemente definidas.
• Indentación (5 %)
El código esta indentado en forma consistente. Se recomienda revisar
el comando indent(1), en particular el estilo Kernighan y Ritchie.
• Comentarios (5 %)
El código está debidamente comentado, es decir, se explican aquellas
secciones que pueden ser un tanto confusas, claro que código confuso
en sı́ descontará puntos. Si el comentario y el código no coinciden se
4 Se recomienda visitar http://www.doc.ic.ac.uk/lab/secondyear/cstyle/cstyle.html,

y el archivo Documentation/CodingStyle del núcleo de Linux

4
 considerará que ambos están malos. Deberı́a ir un comentario corto
explicando cada función, dar el nombre de cada archivo y su objeti-
vo, etc. La forma de comentar es consistente (encabezados similares
para cada archivo, descripciones de cada función, etc.). Nótese que
comentarios excesivos o inútiles llevarán a descontar puntos por este
concepto.
• Nombres de variables y funciones (10 %)
El espacio de nombres, y en particular de variables, estructuras, y
funciones, son descriptivos y coherentes con el contexto/dominio del
problema.
• Uso del lenguaje (25 %)
Se utiliza correctamente las sentencias, operadores, bibliotecas, paráme-
tros, constantes, macros, etc. del lenguaje.
• Archivo README (5 %) Se evaluará en conjunto con el codigo,
la breve (no más de 20 lı́neas) reseña incluı́da en el archivo README
(texto plano) sobre la estrategia utilizada para resolver el problema,
poniendo especial énfasis en la congruencia de su estrategia con el
código de fuente entregado.

MA/JA/LATEX