Normas de Entrega

A continuacin, se detallan las normas de entrega de las prcticas:

1. Toda prctica entregada que no compile o con errores de ejecucin se considerar como no entregada. 2. Una prctica no entregada supone un suspenso en las prcticas. 3. La evaluacin de las prcticas puede requerir la realizacin de una entrevista por cada grupo donde se evaluar la
realizacin de la prctica, as como sobre los conocimientos de la asignatura que han sido tenidos en cuenta en su realizacin. Sern enviados por e-mail para entrega de prcticas los ficheros generados en la realizacin de la prctica, y entregada en el buzn de la asignatura una memoria sobre el desarrollo realizado. La entrega consistir en un fichero comprimido (.zip), en el que se incluir, para cada una de las prcticas realizadas, lo siguiente: Cdigo fuente, debidamente comentado, de todos los programas realizados en la prctica (ficheros .c). Ficheros de cabecera (ficheros.h)

Ficheros de datos necesarios para la ejecucin del programa, si los hay. No se entregarn, por tanto, los ficheros ejecutables (.exe), con el cdigo objeto (*.obj), pero s se pueden entregar los ficheros de los proyectos y los entornos de trabajo. Dentro del fichero comprimido, cada fichero tendr un nombre significativo que indique su funcin. Las extensiones dadas a los nombres de los ficheros sern las usuales: c para los fuentes, h para los ficheros de cabecera, etc. Las prcticas entregadas fuera del plazo establecido tendrn una penalizacin en la calificacin que depender del nmero de das de retraso en la entrega y del estado general de la prctica entregada.

Criterios de Evaluacin
Cada prctica se evaluar sobre 20. Los aspectos a evaluar en cada prctica son: Compilacin del cdigo. Ejecucin del programa. Documentacin presentada. Evaluacin del cdigo, teniendo en cuenta las normas de programacin que se comentan a continuacin.

Respuesta a las cuestiones planteadas por el profesor relativas a la prctica. Aspectos Importantes en la Evaluacin del Cdigo La Ingeniera del software, como cualquier otra rama de la ingeniera elabora productos, en este caso programas. Al igual que en el anlisis de cualquier otro producto debe ponerse nfasis en la calidad del mismo. Esta calidad, sin embargo, es cuanto ms difcil de medir que un producto convencional (piensa por ejemplo en un coche, ste puede ser evaluado en funcin a sus prestaciones, la calidad de sus acabados, etc.). Los siguientes aspectos pueden considerarse fundamentales a la hora de evaluar la calidad de un programa. 1. CORRECCIN Se debe poder establecer una equivalencia "matemtica" entre la especificacin y el funcionamiento del software. La correccin funcional de un programa de software significa que ste responde exactamente a lo especificado, por tanto:

2.

El programa debe funcionar correctamente y estar libre de errores. El funcionamiento debe ceirse estrictamente a las especificaciones y no hacer cosas innecesarias o no especificadas por el usuario. CONFIABILIDAD La correccin funcional en condiciones normales de un programa de software no asegura que aparezcan errores derivados de cambios en las condiciones de contexto. En consecuencia: El programa debe responder adecuadamente tanto a los datos de entrada esperados, como a los datos extremos y/o errneos. El programa debe chequear fuentes potenciales de error y reportar los mensajes adecuados cuando stos se produzcan.

Ejemplo: Se debe vigilar que las pilas y otros TAD similares no se saturen, etc. Antes de usar una variable, estructura o TAD asegurarse de que est inicializado apropiadamente.

3. EFICIENCIA
Un atributo de calidad importante es la eficiencia en el uso de los recursos. Normalmente la eficiencia de los algoritmos se mide por el tiempo de ejecucin de los mismos y por la memoria que estos requieren. Las siguientes cuestiones pueden afectar directamente a la eficiencia de un programa software: Se debe utilizar la estructura ms adecuada al tipo y tamao del dato que se pretenda almacenar. Ejemplo: Si en un programa se necesitase almacenar un array de cadenas de caracteres de longitudes muy dispares, es menos costoso utilizar un array de punteros a cadenas de caracteres que un array de caracteres. char *a[2]; a[0]="cadena"; a[1]="cadena mucho mas larga, debe reservar espacio suficiente"; Debe liberarse la memoria que se haya reservado dinmicamente cuando sta sea innecesaria.

Ejemplo: El siguiente programa es incorrecto, aunque es posible que se ejecute en la mayora de los compiladores de C. Tal como se haya implementada, la funcin FuncionIncorrecta() no libera la memoria direccionada con la variable p. Una vez abandonada FuncionIncorrecta() aquella no podr ser accedida generndose un hueco inaccesible de memoria. int FuncionIncorrecta() { int *p; p = (int *) malloc(sizeof(int)); ........... *p = 3; return *p; } void main() { int a; a = FuncionIncorrecta(); } Deben gestionarse adecuadamente los recursos del sistema. Ejemplos: Una vez que dejen de ser necesarios, deben cerrarse los ficheros abiertos. Tngase adems en cuenta que muchos sistemas operativos limitan el nmero de ficheros simultneos. No deben hacerse bucles ni clculos innecesarios. Es desaconsejable romper un bucle con break, return o exit.

4. FACILIDAD DE MANTENIMIENTO (CLARIDAD)

Cuando se habla de mantenimiento de un programa de software se debe tener en cuenta no solo los aspectos orientados hacia la correccin de posibles fallos, sino tambin los relacionados con la mejora de las capacidades del mismo. Teniendo en cuenta que la facilidad de mantenimiento se mide en el tiempo que se requiere para llevar a cabo modificaciones y cambios en el software, es absolutamente necesario que se respeten los siguientes requisitos: El cdigo debe de estar escrito de manera clara. Utiliza una nica instruccin por lnea. No se deben emplear nombres sin sentido en las variables: nada de i, j, k... a, b, c, excepto para contadores en bucles pequeos.

Ejemplo: En un programa dado en el se utilizan dos bucles anidados para recorrer los ndices de un array bi-dimensional, las variables pueden ser llamadas: fila, columna, en vez de: a, b. Los nombres empleados en la definicin de variables y funciones no deben excederse ms de lo necesario. Ejemplo: En vez de denominar a una funcin: Inicializa_los_pesos_del_laberinto() utilizar el indicador ms abreviado: InicializaPesos() Procurad utilizar "normas ortogrficas comunes" a lo largo de todo el programa. Ejemplo: Los nombres de las funciones empiezan por mayscula y las palabras siguientes por mayscula

InicializaPila() Las constantes se denominan con maysculas #define VACIO 0 Documenta apropiadamente el cdigo:

Todo programa debe tener un encabezamiento donde, al menos, se especifiquen los siguientes datos. /**************************************************** Nombre del mdulo: Descripcin: Autores: Fecha: Mejoras pendientes: Notas: otros mdulos propios que necesita: ****************************************************/ TODAS las funciones deben estar comentadas. En su cabecera indicar lo que hace, cules son sus parmetros de entrada y qu devuelve. /******************************* Nombre: Descripcin: Parmetros de entrada: Retorno: *******************************/ Acostmbrate a poner comentarios en aquellas sentencias que no sean evidentes y que requieran explicacin. Es aconsejable poner un comentario detrs de los cierres de llaves que finalizan bloques de cdigo anidados. Las consideraciones anteriores no implican que deban comentarse TODAS las sentencias, ni poner comentarios detrs de TODAS las llaves que se cierren. El sentido comn debe indicarnos cuando es apropiado comentar una sentencia. Ejemplo: El siguiente comentario es innecesario i++ ; /*incremento en una unidad el contador i */ Ejemplo: Supongamos varios bucles anidados: while (entrada > 9) {

..........
while (estado == 0) {

............
if (primero > 6) { } else { }

} /* fin del while estado */ } /* fin del while entrada */ Utiliza la identacin para facilitar el seguimiento del flujo del programa

Ejemplo: Procura utilizar un estilo similar al del ejemplo anterior en lo que respecta a los espacios entre llaves: Con el fin de resaltar el bloque de cdigo incluido en una llave, se han dejado unos pocos espacios respecto a la columna que delimita el principio de dicho bloque de cdigo. Las llaves se cierren en la misma columna donde empieza la instruccin que abre el siguiente bloque de cdigo. Se ha evitado aadir cdigo en la lnea que abre / cierra una llave .

5. PORTABILIDAD
Los programas portables son aquellos que se pueden adaptar a diferentes cambios de contexto (en este caso nos referimos a, por ejemplo, diferentes sistemas operativos, diferentes compiladores, etc.) con cambios mnimos en el software. Para ello: El cdigo debe de estar escrito en C estndar. En particular, no se deben utilizar funciones grficas especficas del compilador particular. Ejemplo: La librera conio.h no es estndar. Si tienes alguna duda sobre otra librera consulta la bibliografa recomendada o al profesor de prcticas. Cuando se desee reservar memoria dinmica para almacenar un determinado tipo de dato utiliza SIEMPRE el operador sizeof. No usarlo compromete seriamente la portabilidad del programa. Ejemplo: int *p; p = (int) malloc(4); /* no */ p = (int) malloc(sizeof(int)); /* correcto */

6. REUSABILIDAD
Desde el punto de vista de Ingeniera del Software la reusabilidad del sistema es un atributo esencial de calidad. El grado de generalidad de la solucin y su adaptabilidad tiene un impacto fundamental en la rentabilidad de un organizacin que desarrolla sistemas de software. Las siguientes estrategias ayudan a la reusabilidad del cdigo: La modularizacin facilita el desarrollo de los programas. Evita el uso de funciones que realicen ms de una accin. La extensin del cdigo incluido en una funcin no debera ser superior a una carilla de folio. Abstraccin. Definir las constantes apropiadas al principio del programa. Evitar el uso de nmeros mgicos.

7. Pautas para la elaboracin de la memoria

Se pretende que la documentacin que acompaa a la prctica siga las siguientes pautas. En concreto la memoria deber constar de los siguientes apartados:

Identificacin del Proyecto Nombre de los estudiantes, equipo, turno, fecha y nmero de prctica. Anlisis y Especificacin de los Requisitos Diseo Diseo de la aplicacin. Los siguientes puntos deben especificarse: o o o o o o Tipos abstractos de datos seleccionados. Estructuras de datos utilizadas en la implementacin de los tipos abstractos de datos del punto anterior. Identificacin de los controles y correcciones de errores pertinentes. Algoritmos empleados (con diagramas de flujo o pseudo-cdigo). Organizacin en mdulos y ficheros. Documentacin de las funciones a implementar. Descripcin de la prctica en cuestin, incluyendo interpretaciones del enunciado y posibles cambios introducidos por el profesor. Anlisis para la resolucin de la prctica, posibles soluciones para los problemas planteados, discusin sobre las alternativas y justificacin de las decisiones tomadas.

Criterios de Validacin o Diseo de las pruebas a las que se sometern las funciones y los programas, datos y ficheros de prueba que se utilizarn.

Manual de uso de las aplicaciones, con descripcin de las interfaces de entrada y salida. Implementacin Listados comentados de los ficheros de cdigo generados, ficheros de entrada y salidas. Equipo DISTRIBUCIN DE ROLES. Debis identificar con nombres y apellidos cada integrante del equipo y consignar los principales roles que cada uno habis desempeado en la realizacin de cada prctica y el esfuerzo de dedicacin. Los roles pueden ser: diseador del algoritmo, codificador, verificador del cdigo, documentalista. Ejemplo: Mara realiz un 20% de esfuerzo del rol de diseador del algoritmo, un 60% de codificador y un 20% de documentalista. ELABORACIN DE PLANIFICACIN PROPIA. Debis adjuntar una planificacin propia que el equipo hubiera realizado para cumplir con las fechas de entrega de cada prctica, consignando las actividades, la fecha estimada y la fecha real. Incluso si habis adelantado la fecha de entrega de la prctica, consignar tambin esta decisin en este apartado. TIEMPO EXACTO DEMANDADO FUERA DE LAS HORAS DE LABORATORIO PREDETERMINADAS PARA FINALIZAR LA PRCTICA. Debis especificar exactamente las horas de trabajo que habis dedicado para cumplir con la entrega de cada prctica adems de las horas de laboratorio propias destinadas a cada prctica.

Conclusiones y consideraciones adicionales sobre el trabajo realizado. (Si las hubiese).

7. 8.

6 Desde el punto de vista de Ingeniera del Software la reusabilidad del sistema es un atributo esencial de calidad. El grado de generalidad de la solucin y su adaptabilidad tiene un impacto fundamental en la rentabilidad de un organizacin que desarrolla sistemas de software. Las siguientes estrategias ayudan a la reusabilidad del cdigo:

El grado en que se contemplen estas normas se reflejar en la nota final de prcticas. Siempre que se escriba un cdigo se debe tener presente todas estas normas. << volver ndice