1. Internet

¿C´omo escribo mi PFC?
Daniel Borrajo
4 de abril de 2003
1.
Introducci´
on
Este documento pretende ser una gu´ıa de c´omo escribir un Proyecto Fin
de Carrera (PFC). Aunque se hable de PFCs, se puede generalizar a cualquier
documento t´ecnico, como, por ejemplo, las tesis doctorales o los art´ıculos.
2.
Estructura del PFC
Portada (1 p´
agina). Mirar lo que debe aparecer en otros PFC: Logo de la
UC3M, T´ıtulo del PFC, “Proyecto fin de carrera”, Titulaci´on, Debajo a
la derecha: Autor, Director (por este orden), A˜
no (si se desea mes, a˜
no).
Agradecimientos (1 pg.). Si se quiere poner algo.
Indice (1-3 pgs.). Hasta tercer nivel de estructura del documento. No deber´
a aparecer ning´
un apartado (al nivel que sea) u
´nico. Es decir, no puede
aparecer un 3.2.1 si no tenemos un 3.2.2
Introducci´
on (2-5 pgs.) Descripci´on muy general de lo que has hecho.
Dentro de la inform´
atica est´
a la XXX, .... Dentro de ella est´
a el YYY, ...
Lo que pretend´ıa hacer en este PFC es ...
Puede incluir los objetivos y debe incluir una u
´ltima secci´on que describa los dem´
as cap´ıtulos del PFC, como, por ejemplo En el cap´ıtulo 2 se
describir´
a el estado de la cuesti´
on donde...
Estado de la cuesti´
on (m´ax. 30 pgs.) Qu´e es lo que se ha hecho en tu tema
y por qui´en. Piensa en algo que le sirva a alguien que se quiera meter en el
tema luego y quiera ir directo a los libros-art´ıculos-personas importantes.
Puede incluir la descripci´on de las herramientas/modelos/ideas que has
utilizado para el PFC. Al final puedes poner un apartado de qu´e es lo que
no est´
a hecho (que es lo que t´
u has hecho).
Objetivos del PFC (1-2 pgs.) Qu´e quer´ıas hacer y qu´e caracter´ısticas
quer´ıas que tuviera tu PFC. Por ejemplo, Construir un sistema que fuera
1
capaz de hacer XYZ. Adem´
as, el sistema/agente/arquitectura/modelo, deber´ıa ser: flexible, eficiente, eficaz, robusto, r´
apido, f´
acil de usar, din´
amico,
adaptable, ...
Memoria-Trabajo realizado. (con 50 pgs. deber´ıas tener suficiente) Qu´e has
hecho, pasando desde una descripci´on de alto nivel hasta los detalles. Nada de describir las funciones una por una: s´olo una descripci´on por m´odulos/clases gen´erica. Si quieres a˜
nadir el c´odigo o lo que hayas hecho, se
mete como ap´endice (comentado si es posible). La estructura de esta parte ser´
a (normalmente):
• Introducci´
on
• Arquitectura de la aplicaci´on (obligatorio gr´afico): m´odulos de los que
consta, entradas y salidas de los mismos, tipos de datos/documentos
que se intercambian los m´odulos, ... Puede incluir algo equivalente a
un diagrama de flujo o un algoritmo de muy alto nivel (llamadas a
m´
odulos en lugar de a funciones de un lenguaje concreto).
• Modelo de conocimiento de la aplicaci´on: equivalente a un diagrama
de clases, s´olo comentando las de m´as alto nivel (no las auxiliares) y
los atributos m´
as significativos
• Descripci´
on a alto nivel de cada m´odulo: funcionalidad, entradas,
salidas, subm´
odulos, ... Se deber´an poner tambi´en los principales algoritmos en pseudo-c´odigo. Debe explicarse a trav´es de un ejemplo,
o poner una secci´on luego con el ejemplo
• Manual de usuario: debe servir para que cualquier persona que no
sepa nada de lo desarrollado pueda ejecutar la aplicaci´on. Equivalente
a descripci´
on de la interfaz gr´afica paso por paso (en caso de que haya
interfaz) o c´
omo se ejecuta el sistema (sin interfaz)
• Manual de referencia: debe servir para que cualquier desarrollador
posterior pueda ampliar la aplicaci´on. Debe contener detalles t´ecnicos de implementaci´on, como lenguaje utilizado, instalaci´on, ficheros
generados, clases generadas, c´omo cambiar algo del c´odigo, ... Todo
ello, sin describir una a una las clases o funciones desarrolladas.
Resultados. Cualquier cosa que sirva para demostrar que el trabajo funciona bien/mejor que otros. % de acierto en la clasificaci´on, n´
umero de
problemas que resuelve, tiempo que tarda en hacerlo, n´
umero de entradas, ...
Conclusiones (max 5 pgs.) A muy alto nivel, qu´e es lo que se puede sacar
en claro de tu proyecto, ventajas e inconvenientes.
Futuras l´ıneas/trabajos (max 5 pgs.) Qu´e se puede hacer sobre tu trabajo
para ampliarlo/modificarlo, de forma que sea m´as eficiente, resuelva m´as
problemas, ...
2
Bibliograf´ıa. Debe contener todas las referencias al trabajo de otros. Consultar otros PFCs para formato en el que se debe referenciar.
Anexos
3.
Cuestiones generales
Altamente recomendable hacerlo en Latex
Hacer una p´
agina Web con parte de la memoria y con la descarga del
software; todo software desarrollado deber´a ser de dominio p´
ublico (salvo
casos muy excepcionales).
Cualquier aportaci´
on de otra persona debe aparecer referenciada en el texto. La forma en la que aparecer´a depender´a del formato escogido para las
referencias bibliogr´
aficas, pero puede ser desde [1] pare referencias cortas,
hasta [P´erez y Alonso, 1989] para referencias largas.
Cualquier figura o tabla debe referenciarse (hablar de ella en el texto y
poner una referencia como: La Figura XX muestra ...) y debe tener un pie
de figura/tabla indicativo (Figura XX. Arquitectura modular del sistema)
Conviene estructurar el texto en cap´ıtulos, secciones y subsecciones. Ir
m´
as all´
a no debe ser necesario normalmente.
La primera vez que se utiliza un acr´onimo, debe especificarse de d´onde
viene. Por ejemplo, “La Inteligencia Artificial (IA) ...”.
Se debe evitar la utilizaci´on de t´erminos en ingl´es. Si se desea poner alguno,
se incluir´
a en it´
alica o “con comillas”. Si se desea incluir la traducci´on al
ingl´es de una determinada palabra (psuedo-)castellana, se pondr´a, por
ejemplo, el retroceso (del ingl´es backtracking)...
3