Generalidades del Proyecto

Aspectos a Considerar

Salvo los detalles puntuales que se enlistan a continuación, el proyecto debe cumplir con la especificación contenida en el siguiente documento: instructions.html. El archivo urlybird.zip contiene también el archivo de la base de datos no relacional.
El proyecto debe desarrollarse en equipos de 2 o 3 integrantes.
Se debe utilizar el lenguaje Clojure en lugar de Java. Se permite utilizar cualquier parte del API de Java 6, sin embargo se recomienda preferir el API de Clojure y el API de Clojure-contrib siempre que sea posible.
No se permite bajo ninguna circunstancia escribir código en lenguaje Java. Específicamente, en la subsección titulada Required Interface de la sección Server no se debe escribir la clase Data ni implementar la interfaz DBMain. En su lugar, se deben escribir varias funciones en Clojure que proporcionen una funcionalidad equiparable a lo ahí descrito. En lugar de candados se debe usar alguno de los esquemas propios de Clojure para el control de concurrencia (referencias con STM, átomos o agentes).
En lugar de usar javadoc se debe usar el API de gen-html-docs para generar las páginas de HTML con la documentación de todas las funciones públicas de cada espacio de nombres con el que cuente el proyecto. Cada función pública debe contar con un string de documentación con al menos un enunciado que explique qué hace, así como el propósito de cada uno de sus parámetros.
La interfaz gráfica de usuario (GUI) debe cumplir con las pautas establecidas en el documento titulado: Java Look and Feel Design Guidelines. En lo referente al uso de Swing, se sugiere revisar la sección correspondiente del Java Tutorial.
La manera de correr el programa debe ser la misma que está indicada en la especificación, pero añadiéndole al classpath los archivos clojure.jar y clojure-contrib.jar:
```
java -cp clojure.jar:clojure-contrib.jar -jar <path_and_filename> [<mode>]
```
El código debe incluir pruebas de unidad usando el API de clojure.test. Se debe procurar que las pruebas tengan una cobertura completa sobre la mayor parte del código. Quedan exentas de pruebas de unidad aquellas porciones de código que involucren la interacción directa con el usuario.
El desarrollo del proyecto se debe hacer de manera ágil, aplicando lo más posible las prácticas descritas en el libro de [SUBRAMANIAM]. Es importante que se vaya recolectando evidencia de la manera en que se está trabajando mediante fotos y video.
Se debe utilizar Google Code como repositorio SVN de todo el código fuente que se vaya generando. Se debe realizar al menos un commit por cada sesión de trabajo que tenga el equipo.
El equipo debe crear un blog en Blogger.com para ir documentando el desarrollo del proyecto. Por cada sesión de trabajo que tenga el equipo se debe realizar un post en el blog. Dicho post debe incluir en forma de prosa: las personas que estuvieron trabajando, los logros de la sesión, la cantidad de tiempo invertido, los problemas a los que se afrontaron y como los resolvieron, y cualquier otro aspecto que deseen compartir. Pueden incluir en sus posts las fotos que vayan tomando. Un buen post debe ser informativo y entretenido, y su extensión no debe ser menor a las 150 palabras. Debe haber consistencia con lo que se reporta en el blog y lo que se sube a Google Code.

Fechas Importantes

23 de marzo. Primera iteración: Interfaz gráfica de usuario y acceso a la base de datos de manera local para un solo usuario. Incluye la documentación y las pruebas de unidad correspondientes.
4 de mayo. Segunda iteración: Cliente/servidor para acceso a la base de datos de manera distribuida para múltiples usuarios. Incluye la documentación y las pruebas de unidad correspondientes.
Día del examen final. Video documental sobre el desarrollo del proyecto.

Proyecto de desarrollo de software

Generalidades del Proyecto

Aspectos a Considerar

Fechas Importantes