El supuesto objetivo final de estos aparatos, es reducir el número de accidentes, supongo que a través del miedo que tienen los conductores a ser multados. Digo yo que se basarán en la fórmula:
- más radares = más miedo = menos velocidad = menos accidentes.

En esto que sale un guardia civil, al lado de uno de estos radares tecnología punta y viene a decir que el radar se había puesto ahí, porque era un punto negro donde había muchos accidentes, debido a que se salía de una autovía a mucha velocidad, y se llegaba a una curva ciega, bla bla bla. Y ahí es donde yo, y creo que la gran mayoría, pongo un poco de sentido común y digo, ¿y no será mejor invertir dinero en arreglar los puntos negros de las carreteras españolas en vez de en tantos cacharritos? Pero claro, si arreglan el punto negro sin más, dejaran de recaudar dinero con las multas de los nuevos radares. Vamos, que estos radares tecnología punta, son una inversión segura.

Este es otro claro ejemplo de como utilizar la mejor tecnología para no solucionar el problema.

Son ya varios los casos, en los que hemos conocido demandas de empresas, a blogs y a webs, por contar opiniones que la dejaban en mal lugar, o historias que no querían que se supieran.

¿Que está ocurriendo? Al fin y al cabo a las personas siempre nos ha gustado criticar aquello que no nos parecía bien. Pero claro, cambia mucho hablarlo con cuatro amigos, a utilizar la red para difundirlo a miles de personas.

Que la gente de a pie, tengamos este instrumento, con el que podemos quejarnos, y ser escuchados por el gran público, es algo que escama a las grandes empresas, organizaciones y medios, que antes tenían el control absoluto sobre lo que debía darse a conocer y lo que no. Pues es algo a lo que tendrán que acostumbrarse y aprender a gestionar, ya que se está comprobando que es algo imparable.

Con un servicio propio, que podemos arrancar en cualquier máquina, y nuestro lenguaje de programación favorito, podemos crear tantos casos de prueba como queramos una sola vez, y ejecutarlos todas las veces necesarias. La utilidad es obvia, ejecutar periódicamente pruebas de la aplicación, para asegurar la integridad del sistema, y todo, de manera automática.

La gran virtud de Selenium, es su extrema facilidad de uso, como ejemplo (en Java y Firefox) solo tienes que seguir estos cuatro pasos para hacerlo funcionar.

1. Descárgate el zip de Selenium y descomprímelo en una carpeta (p.ej. c:/selenium).

2. Arranca el servidor Selenium:
java -jar c:\selenium\selenium-remote-control-0.8.1\server\selenium-server.jar

3. Asegúrate que la JVM y el ejecutable del Firefox, están en el PATH del sistema.

4. Compila y ejecuta la siguiente clase Java.

package test;

import com.thoughtworks.selenium.DefaultSelenium;
import com.thoughtworks.selenium.Selenium;

public class Maintest {

private static Selenium sel;
public static void main(String[] args) {

sel = new DefaultSelenium("localhost",
4444, "*firefox", "http://www.google.com");
sel.start();

sel.open("http://www.google.com/webhp");
sel.type("q", "hello world");
sel.click("btnG");
sel.waitForPageToLoad("5000");
System.out.println(sel.getTitle());
}
}

Este ejemplo, lanza una búsqueda en google, y saca el título de la pagina de resultados.

Para más información sobre Selenium, te aconsejo que veas el tutorial del RC de Selenium, y que veas el Javadoc incluido en el zip que te descargaste.

Selenium también dispone de un IDE para Firefox que te permite grabar macros simplemente navegando por la web, y ejecutarlas de nuevo posteriormente.

Documentación puede haber mucha: del API, del diseño y arquitectura, comentarios en el propio fuente ... pero seamos sinceros, cuesta mucho trabajo programar y hacer la documentación a la vez. Alguien podría decir, "pues programa, y luego dedicas una fase a documentación". Es posible, pero aun pasando por alto la falta de tiempo habitual, la calidad de la documentacion puede bajar debido a que ha pasado cierto tiempo desde la codificación.

El último handicap de la documentación es, lo rápidamente que se queda desfasada ante cambios del programa, volviéndose inservible.

Desde mi pundo de vista, no hay mejor documentación que un código limpio. Él hablará por si solo de las funcionalidades que implementa, siempre estará actualizado, y requiere un esfuerzo adicional menor.

Para ayudar a este código limpio, y a facilitar la herencia de fuentes de programadores de la misma empresa, toda la organización debe adoptar unos estándares de desarrollo comunes, de manera que una misma cosa, la hagan igual en todas partes, para que a simple vista pueda identificarse lo que se ve, y cada cual sepa buscar lo que necesita en el lugar adecuado.

Comparando con esto, cualquier aplicación que se desarrolle, necesita su propio hello world. El usuario, en cuestión de pocos minutos, tiene que poder ejecutar algo sencillo, que sea representativo de la funcionalidad que se ofrece y que le motive para seguir explorando. De esto, desde mi punto de vista, depende en gran medida el éxito de la aplicación, entendiendo por éxito, que el usuario la utilice.

No importa lo completo y potente que sea el programa, no importan las miles de posibilidades que ofrezca, si no consigues enganchar al usuario con una demostración sencilla y rápida, abandonará rápidamente su uso y se irá a buscar otra cosa.

No perder ni un minuto de este tiempo, es otro de los factores por el que las redes P2P tienen tanto éxito. La demanda de series de televisión en estas redes, cada vez es mayor, y ¿cual es el motivo?, al fin y al cabo, las series también puedes verlas gratis en TV. Pues el motivo, lógicamente, es la libertad de poder verlo cuando quieras, y sin tener que tragarte minutos y minutos de publicidad, ya que estos minutos que estas desperdiciando ... son oro para ti.

Es una herramienta que te permite hacer gráficos de distintos tipos, recuperarlos, almacenarlos e incluso compartirlos, accediendo desde tu navegador. No necesitas ningún software adicional instalado, no tienes que preocuparte de preparar tu portátil con todo lo que necesitas antes de cada viaje, puedes recuperarlo en cualquier parte del mundo ... desde mi punto de vista, esta forma de software es muy útil, y la utilidad es el primer objetivo del software.

Otros artículos relacionados:
La era en directo

Derechos del cliente
- Establecer los objetivos del proyecto, y tener seguiento de los mismos.
- Saber cuanto tiempo y cuanto dinero va a costar el software.
- Decidir qué funcionalidades están o no en el proyecto.
- Realizar cambios razonables durante el curso del proyecto, y conocer el coste de realizar esos cambios
- Conocer el estado del proyecto de manera clara y confidencial.
- Ser informado regularmente de riesgos que puedan afectar coste, planificación o calidad, y disponer de una herramienta para comunicar problemas potenciales.
- Tener acceso real a los entregables a lo largo del proyecto.

Derechos del equipo de proyecto
- Conocer los objetivos del proyecto y las prioridades.
- Conocer en detalle el producto que se supone que debe desarrollarse, y poder aclararlo si no lo está.
- Tener acceso real y continuo al responsable de la toma de decisiones por parte del cliente.
- Trabajar en cada fase de una manera técnicamente responsable, sin ser forzado a comenzar la codificación demasiado pronto.
- Dado que en cada etapa del proyecto, se tiene mayor conocimiento para poder reestimar tareas, realizar nuevas estimacions y reajustar la planificación.
- Trabajar en un entorno productivo, sin interrupciones y distracciones.

Conseguir que esto se respete a lo largo del proyecto es tarea difícil, pero no lo lograrás si no lo planteas desde la primera reunión.

Otros consejos:
Marca hitos y reestima tras alcanzarlos.
Desarrollo del proyecto por etapas

El enfoque por etapas, se basa en entregar el software por "trozos" en vez de todo al final del proyecto. Esto reporta importantes beneficios:

- La funcionalidad crítica estará pronto disponible, si la planificas y abordas en las primeras etapas.

- Se reducen riesgos, al detectarlos antes en el tiempo.
* De integración entre subsistemas al tener que entregar algo que funcione.
* De fallo en la toma de requerimientos.
* Da señales del progreso del proyecto, y se puede identificar si no es el apropiado.

- Los problemas se hacen antes evidentes.

- El trabajo extra para informar del estado del proyecto se reduce, ya que las entregas son el mejor indicativo del estado del proyecto.

Basándome en esto, una de las primeras tareas que te aconsejo hacer en tu proyecto, es planificar las etapas en las que lo particionaras, teniendo en cuenta la prioridad a la hora de establecer el orden del desarrollo.

¿Tienes algún consejo sobre gestión de proyectos de software? Me encantaría que me los contaras.

Otros consejos:
Marca hitos y reestima tras alcanzarlos.
Conocer y respetar los derechos de las partes implicadas

De la lectura de este y otros libros, y de mi experiencia personal, me gustaría dar algunos consejos prácticos que me han resultado útiles, y que pueden ponerse en marcha en cualquier proyecto, por pequeño que sea.

Consejo: Marca hitos y reestima tras alcanzarlos.

- Marca hitos intermedios en el desarrollo, y evita dejarlo todo para una única entrega final. Estos hitos intermedios son más fáciles de gestionar.

- Las metas son importantes para tener la percepción de que el proyecto avanza, y es la mejor forma para representar el estado del mismo. La lista de hitos alcanzados es muy útil para informar a clientes y partes implicadas de la marcha del proyecto.

- Tras cada hito, tenemos mayor conocimiento del proyecto, por lo que si reestimamos una vez alcanzados, estas estimaciones serán más exactas que las previas, lo que también nos dará una idea más precisa de lo que falta.

- Los hitos deben ser 100% hechos o 100% no hechos, otro porcentaje nos llevaría a engaño.

¿Tienes consejos sobre gestión de proyectos de software? Me encantaría que me los contaras.

Otros consejos:
Desarrollo del proyecto por etapas
Conocer y respetar los derechos de las partes implicadas