Proyecto final de carrera

Reorganizando los CDs he encontrado por casualidad mi proyecto final de carrera de hace 9 años. Este proyecto hoy mismo no tendría ningún valor comercial de los cambios que han habido pero quizá si tenga un valor académico o como simple curiosidad. Por ello, he decidido en subirlo aquí para compartirlo con quien esté interesado. Comentar de que hay partes de la documentación que dan pena pues fueron un simple tramite y la versión que utilice era la más actual de la época JDK 1.1.6. Creo que aún no habían sacado la JDK 1.2.

El proyecto consiste en una aplicación cliente-servidor para la creación de juegos online. Desde la aplicación servidor se disponen de huecos en los cuales el administrador puede poner en los huecos el juego que queria. En el ejemplo se disponía de dos juegos pero la idea era que era ampliable a los juegos que se quisieran siempre que derivasen de una clase base que tenía precisamente la posibilidad de ser añadido a cualquier sala y ser gestionado.

Una vez creadas las salas, las aplicaciones clientes, pueden conectarse al servidor y una vez dentro chatear o entrar a una sala a jugar con otros jugadores. Los juegos disponibles son el "siete y medio" y el "tres en raya". Comentar que el código fuente está muy mal organizado y seguramente no sigue ciertos patrones, no hay un uso de packages correctos (tal y como se realiza ahora) y en ocasiones se cuelga el sistema. Aquí estaba en mis primeros contactos con java, pero está bién darle un ojo como curiosidad.

En lo que respecta a la documentación teníamos que entregar:

• Pliegue de condiciones: Condiciones contractuales del proyecto.
  
• Prespuesto: ¡Curioso! La regla que teníamos que llevar era 40% de Analisis-Diseño, 20% de desarrollo y 40% de pruebas. Al final puse 6€/hora la hora en pruebas porque si no se me iba de presupuesto. ¿A quién tendríamos explotado cobrando menos de 6€/hora?. Creo que me pase de poco, pero si llego a saber como estaban las cosas le pongo el logo de Accenture y le clavo 100€/h de pruebas :P
• Memoria: Un gran tocho de todo lo que se me ha pasado por la cabeza y si lo he decidido usar por qué lo he decidio usar y si no lo he decidido usar por qué no. Y aunque no se me haya pasado por la cabeza, por si acaso, buscar todas las posibles cosas que puedo utilizar y explicar los pros y contras de utilizar eso acabando en una conclusión y un razonamiento de porque he utilizado lo que he utilizado. Menos mal que aún no había salido Android, iPhone, etc y la gran cantidad de lenguajes que hay ahora porque si no... (modo ironic on)Además en este documento, se plasmarán esos interesantísimos diagramas, los cuales sin ellos, los programadores no sabrían hacer el trabajo o tendríamos que hacer pensar al programador.(/modo ironic off)
  
• Planificación: Por supuesto, hay que hacer una planificación de como vas a organizar los recursos. Si os quereis reir un poco, aquí teneis todos los posibles diagramas que permite hacer el MS Project poniendo como recursos 1 persona y 1 ordenador. Yo la verdad, no sé que esperaban que iba a presentar si los proyectos finales de carrera, (que yo sepa,) son individuales.
  
• Manual: Una parte importante del proyecto es el manual. Esta documentación si la considero importante hoy en día. Es una forma rápida de reducir las llamadas a soporte en un 50%. Por lo que, si desarrollais un sistema que vendeis a diferentes clientes, hacerles un manual para que no estén llamando para cosas que podían estar documentadas.

Como conclusión, interesantes documentos en un proyecto real: Condiciones contractuales y presupuesto para la parte comercial, un manual o circulares para los clientes informando de la evolución del proyecto y una memoria y planificación objetiva y real (no lo que solicitan en la universidad). Cuando digo una memoria es una metodología básica, es decir tomar cuatro reglas básicas de implementación y en el caso de existir casos particulares documentarlos en el proyecto/cliente correspondiente. En cuanto a la planificación es complicado ya que mi opinión es hacer pequeños hitos pero esto va en contraposición a tener un presupuesto cerrado. Quizá la mejor opción para desarrollos a medida no es vender una aplicación, si no un paquete de horas y que el cliente sea consciente que esas horas se le gastan a medida que va pidiendo. Pero como siempre digo, es mucho más fácil vender algo material que algo abstracto, ideas o productos a medida por el problema de la comunicación.

Pulsar aquí para descargar el proyecto (código fuente, instalables y documentación)