Desde Linux Hispano publican una lista de nueve consejos a tener en cuenta para poder realizar el proyecto final de grado o proyecto final de ingeniería informática en software libre (me refiero a liberar el software generado como proyecto final).

He perdido la cuenta de los proyectos que he dirigido, pero os aseguro que en todos hay que tener presente un aspecto importante (en el artículo lo resumen en el punto 2): la propiedad intelectual del software creado no tiene porque ser del futuro ingeniero, sino de todas las partes involucradas en el proyecto, y hay que pedir permiso a todas las partes, en primer lugar para presentarlo como proyecto final, y en segundo lugar para licenciarlo como software libre.

Otra cosa que no debe de olvidarse es que todo el software base sobre el que se vaya a ejecutar vuestra futura aplicación debe de tener una de las licencias opensource. De no ser así, no tendría porque considerarse software libre puro, ya que requiere de licencias adicionales para ejecutarse.

El último aspecto importante es dejar claro con todas las partes uno de los puntos que más se nos suele escapar: cómo se llevará a cabo el mantenimiento (no está prohibido decir que se libera pero no se continúa, aunque todos sabemos que esa forma de actuar es la que ha llevado a pensar a mucha gente que el software libre no tiene garantías, evolución, ni soporte).

RCL es un intento de definición de lenguaje para la toma de requisitos en la fase de análisis dentro del ciclo de vida del desarrollo de software. IEEE está trabajando para convertirlo en estándar (ver también este artículo). Uno de los puntos más importantes en la definición de un sistema de información y, en general, de aplicaciones software, es la estimación de trabajo basada en la toma de requisitos iniciales (durante la definición del alcance en el preanálisis). El primer problema es precisamente conseguir una definición lo más perfecta de los requisitos durante la definición del alcance y, tal vez utilizando un lenguaje como RCL (ver tutorial) y una buena herramienta, como la que se nos propone desde eConcinnity, podríamos lograr estimaciones (planificaciones de proyectos) más ajustadas a la realidad.

Ya sé que no es lo mismo la fase de análisis que la de preanálisis, pero os animo a que lo utilicéis durante la planificación y veamos si se ajusta mejor.

Vía Variable Not Found, he leído un artículo acerca de cómo detectar que una pantalla ha sido diseñada por un programador, y no por un analista técnico o diseñador técnico. Programar no es fácil y es un punto crítico de un proyecto de desarrollo de software, pero diseñar un buen interface de usuario también es una parte del puzzle.

Un buen truco para aquellos programadores que no tengan nociones de diseño está en utilizar algunos ya realizados para los diferentes componentes de los interfaces de usuario. Una buena biblioteca de estos componentes la podemos ver en http://www.free-css.com/.

Si lo que queremos es mejorar, además de evitar cosas que no deberíamos hacer, podemos seguir algunos consejos de artículos que he leído estos días, como por ejemplo “la programación es como un juego de ajedrez” o “cómo acumular deuda técnica rápidamente“.

Sin duda la mejor opción es formarse, y a modo de ejemplo, dejo unos enlaces recopilados de SentidoWeb:

• Ejemplos interesantes de uso de CURL
• Programación en paralelo con PHP
• Uso de corrector ortográfico en webs mediante JavaScript
• Ofusca tu código PHP
• Motor 3D para jQuery
• O3D: 3D en la web por Google