Estándares DSC
Home ] [ Estándares DSC ] Reglas Académicas ]

 

Estándares de Programación y Evaluación

Release 1.0 21 de Julio del 2000

Programación defensiva.

Los programas deben poder manejar adecuadamente situaciones inesperadas. Ejemplo: Si el programa toma dos números (A,B) y debe retornar el cociente (A/B), entonces debe contemplar situaciones como que el input este incompleto o que B tenga valor 0 (cero). En ambos casos debiera informar de las anomalías encontradas y proceder a la finalización del programa.

Opciones incompletas.

Si se requiere cierta funcionalidad que no es implementada, manejar por lo menos mensajes que informen de la falta de funcionalidad. Ejemplo: Si un programa debe implementar +, -, * y / para dos números (A,B), pero la división (A/B) no fue implementada, debe por lo menos leer los datos de entrada e informar que "La División no está implementada.".

Nombres de variables y procedimientos.

Los nombres de variables y procedimientos deben ser significativos en relación a su significado. El uso de nombres como J, K, L, M, debe restringirse a variables de control de ciclos ( for K = 1 ... ), contadores cuyo significado resulte obvio (N para n parámetros), o variables nombradas directamente en la definición del problema (A y B si el problema es definido como "Encontrar el producto de dos enteros A y B.").

Nombrar variables y procedimientos utilizando el estilo mostrado en los siguientes ejemplos: Primer_Nombre o PrimerNombre, Fecha_Nac o FechaNac, Sdo_Inicial o SdoInicial, Calcular_Seguro_Social o CalcularSeguroSocial.

Constantes.

No deben usarse constantes no nombradas. Las únicas constantes permitidas deben ser las obvias tal como 1 en "for j = 1 ...".

Las constantes deben nombrarse en letras mayúsculas como TRUE = 1, FALSE = 0, etc.

Operadores.

Todos los operadores deber rodearse de un espacio antes y después del operador. Ejemplo: A = A + B.

Documentación interna de programas.

Todas las rutinas deben ser precedidas por un comentario organizado de la siguiente forma:

//

// Procedure Valor_Futuro (Monto, Tasa, Meses: real): real;

//

// Toma tres valores: monto inicial, tasa de interés anual y meses. Retorna el valor

// futuro a los meses indicados dado el monto inicial y la tasa de interés

// indicada.

//

Comentarios internos a los procedimientos se sugiere que se hagan en la misma linea de código o en lineas separadas siempre con una linea blanca antes y después del comentario. Ejemplo:

//

// calcular formula hashing

//

Declaraciones de variables y de constantes cuyo nombre no sea auto explicativo, deben incluir un comentario indicando su significado.

Las rutinas deben mantenerse de un tamaño tal que sea relativamente fácil seguir su lógica de un solo vistazo. Una regla simple es que la parte de código de un procedimiento se pueda ver en no más de dos pantallas de texto.

Documentación de Proyectos.

Para todo programa, la mínima documentación requerida es la siguiente:

Descripción del problema en términos de los datos de entrada y de salida esperados.

Descripción general del método (algoritmo) utilizado para solucionar el problema. Esta documentación debe hacer referencia a la lógica principal

Listado del programa documentado.

Ejemplos de corridas: Dos juegos diferentes de datos de entrada con sus resultados.

Para las clases avanzadas, cada maestro indicará la documentación extra considerada estandar para esa materia. Ejemplo: Para Compiladores debiera incluirse un detalle de la gramática y el automata para procesarlo, para Análisis de Sistemas debiera incluirse el Diagrama de Alcance del Sistema, Diccionario de Datos (Datos elementales y compuestos, DFDs, y descripciones de procesos).

Eficiencia.

En todas las clases que tienen proyectos de programación debe aplicarse los conceptos y técnicas adquiridas en los cursos previos en especial todo lo referente a eficiencia. Ejemplo:Si en Compiladores se requiere que cada string sea buscada entre las palabras reservadas del lenguaje implementado, esta búsqueda debe implementarse eficientemente, ya sea con el uso de un árbol balanceado de búsqueda binaria o con el uso de una tabla de hashing. Si en un curso adelante de Estructura de Datos se requiere de un ordenamiento de datos, debe esperarse del uso de un método de ordenamiento eficiente en lugar del típico uso del ordenamiento por burbuja.

Trabajo en Grupo.

Todas los trabajos deben ser estrictamente individuales a excepción de los siguientes cursos:

Sistemas de Información.

Análisis de Sistemas

Diseño de Sistemas

Ingeniería de Software.

En las clases antes mencionadas, el grupo de trabajo no debe exceder de cuatro estudiantes. Si la clase es multi-carrera, cada grupo debe organizarse multi-disciplinariamente. Debe requerirse una propuesta inicial del proyecto en el cual debe detallarse las tareas de cada miembro del grupo. Queda a criterio del maestro, la aceptación de la propuesta basada en la distribución equitativa y justa de las tareas.

Evaluación.

Todo proyecto tendrá una revisión final en la que el alumno lo ejecuta frente al maestro, lo prueba con diferentes datos, y ejecuta modificaciones al código fuente. Esat revisón es ineludible y no puede ser dispensada de ninguna forma. La evaluación del proyecto considerará los siguientes aspectos:

  1. Robustez. Programas que no hacen nada, que se cuelgan o que su comportamiento está muy lejano de lo esperado pueden obtener un máximo de 10% de la nota total.
  2. Funcionalidad. Todo proyecto debe tener claramente definida la funcionalidad esperada. Cada falta en la funcionalidad será penalizada rigurosamente con un porcentaje de la nota total del proyecto. Si se esperan n funcionalidades, el porcentaje deducido por cada funcionalidad no desarrollada o incompleta será (100/n).
  3. Originalidad. Los proyectos deben ser totalmente desarrollados por el estudiante. Si el profesor detecta que el proyecto ha sido parcial o totalmente copiado, o desarrollado por otros, el proyecto será calificado con 0%. En el caso de que el alumno no pueda hacer cambios en su programa, se entenderá como que fue desarrollado por otras personas.
  4. Puntualidad. La fecha y hora de entrega de los programas es fijada durante la definición del proyecto. Todo proyecto que se entregue dentro de las siguientes 24 horas, se evaluará sobre 75%, y si se entrega dentro de las siguientes 24 horas se evaluará sobre un 50%. Después de esas 48 horas no debe aceptarse ningún trabajo.
  5. Estándares. Se espera que los estándares arriba mencionados sean aplicados en todos los proyectos. Queda a criterio del maestro el grado de penalización pero dicha penalización es obligatoria por lo menos en los siguientes aspectos: nomenclatura de variables y constantes, documentación interna de programas, y documentación externa de programas.

El maestro tiene la libertad de requerir que sus trabajos sean entregados por medios convencionales (diskette y papel) o por medios electrónicos (e-mail). Sin embargo, el estudiante debe estar bien entendido que si el proyecto no es recibido, no se aceptará ningún tipo de excusa, y se dará nota de 0%.

Cuando el maestro programe revisiones/entregas parciales para verificación de adelanto, la revisión siempre debe realizarse sobre la entrega final. Sin embargo, queda a criterio del maestro penalizar hasta un 20% el hecho de fallar en las entregas parciales.

El maestro puede reconocer hasta 10 puntos extras por trabajos por esfuerzos sobresalientes..