archivo

Archivos diarios: enero 18, 2009

Uno de los aspectos que más me preocupan en el desarrollo de proyectos informáticos es que el producto llegue al entorno de producción con el menor número de errores funcionales, que tenga un buen rendimiento y sea fácilmente mantenible a nivel de código y de documentación.

Esto que parece de perogrullo, es tremendamente difícil sobre todo si nos encontramos con proyectos de una gran envergadura con un parque de usuarios heterogéneo en localizaciones dispersas con distintos nivel de calidad en su ancho de banda.

Después de analizar las metodologías de desarrollo clásicas como Métrica v.3 y tratar de hacer uso de ella en mis proyectos (más bien un subconjunto de ella, pero aunque sea un subconjunto, por definición de Métrica v.3 sigue siendo Métrica v.3) he llegado a la conclusión de que sin ser una mala opción, hay algunos aspectos que sí es conveniente centrarse y en otros menos:

– Plan de proyecto. Contendrá el cronograma del proyecto (lo mejor es que ese cronograma se mantenga con una herramienta informática compartida: Redmine, dotProject, etc…), por lo que valdrá con una referencia a la url donde se puede seguir el cronograma del proyecto, el equipo de proyecto (igualmente lo mejor es que ese equipo de proyecto se vaya actualizando, por tanto lo mejor es una herramienta informática compartida y si es la misma que la del cronograma, mejor que mejor y se sepa si así lo desea el cliente su imputación de horas al proyecto) y la documentación que deberá acompañar al proyecto.

– Lo fundamental en un proyecto de desarrollo de software son los requisitos. La empresa que posea analistas con la suficiente capacidad para obtener del usuario lo que quiere (cosa tremendamente difícil) tienen una ventaja muy importante respecto a sus competidores. Este catálogo de requisitos es fundamental tenerlo actualizado en todas las fases del proyecto, incluido el mantenimiento. Si es necesario dedicar tiempo a una fase del proyecto concreta esta es el análisis de requisitos. El catálogo de requisitos debe ser completo y fácilmente inteligible por el usuario. Si hay presupuesto en el proyecto y puede facilitar el proceso de desarrollo el analista puede trabajar con los diagramas de casos de uso.

– Modelo de datos. Muy importante tenerlo documentado en la versión 1 del proyecto. Para posteriores versiones, si en el mantenimiento hay presupuesto y tiempo (aspectos no siempre disponibles) se puede mantener la documentación del modelo de datos, en caso contrario no pasa nada, siempre hay herramientas que te los puede obtener por ingeniería inversa a través de la base de datos.

– Interfaz de usuario. Es fundamental que el usuario conozca y valide la interfaz de usuario, ya que es donde ellos van a trabajar, de nada vale saber lo que quiere el usuario si después la interfaz de usuario no es ágil. Por este motivo también conviene invertir en esta fase del proyecto. Cuanto más se aproxime esta interfaz de usuario a su implementación real, más conciencia tendrá el usuario de lo que se va a encontrar y por tanto más posibilidades de éxito existen en el proyecto.

– Arquitectura del sistema. Debe ser breve, conciso y cuanto más gráfico mejor. Es importante para proyectos donde se deleguen funcionalidades en terceras herramientas (motor de tramitación, plataformas de autenticación y firma electrónica, etc…).

– Plan de pruebas (unitarias, integración, sistema, implantación y aceptación). Aunque es una realidad que nosotros, los clientes, tengamos nuestros propios medios para garantizar la calidad de las entregas, son absolutamente necesarias dos premisas: Que la empresa desarrolladora realice un primer filtro de pruebas muy importante (nunca es perdido el tiempo que se dedica a probar) y que se entregue un manual de pruebas al cliente donde como mínimo se pueda garantizar, tras realizar las pruebas, que el sistema funciona y que además verifica los requisitos funcionales y no funcionales más importantes.

– Manual de usuario. Debe estar siempre actualizado. Ser muy completo y tener casos de uso reales en los que se refleje, al menos, el 90% de la casuística del programa. Si el manual está accesible on-line por los usuarios mejor que mejor, independientemente de eso es aconsejable que sea también fácilmente imprimible.

A todo lo anterior es necesario sumar la necesidad de utilizar un sistema de control de versiones buenos, como por ejemplo Subversion y hacer un buen uso del mismo (política correcta de etiquetado de versiones, etc…), utilizar unos mecanismos estándar para el despliegue de los proyectos: MAVEN + Hudson + Artifactory, por ejemplo y algo fundamental, un libro blanco de desarrollo que homogeinice los desarrollos que se realizan para tu organización.

Otro partido más derrotados. Esta vez 2 a 0 frente al Celta de Vigo.

Es muy difícil ganar cuando se sale al campo con un equipo sin un sentido ofensivo, es más, como dije en un post anterior de este blog, sin un sentido de juego.

No se puede esperar conseguir algo positivo en Vigo o en cualquier sitio con el trivote Javi Barranco, Cordero y Marc Valiente. De ahí, me sobra Marc, que es central.

Tampoco podemos pensar en ganar cuando el delantero es Mohammed, hombre con mucho gol, pero que no es delantero.

Lo mejor: que siga acumulando partidos Redondo.

Partido que se preveía fácil, dada la diferencia de calidad entre los jugadores de ambos equipos y además con el factor campo a favor del Sevilla.

Tras los primeros diez minutos de juego esta diferencia quedó patente, pero tras ese período de tiempo el Sevilla se atascó y no volvió a llegar con peligro a la meta del Numancia hasta un disparo muy claro que falló Kanouté.

Al inicio de la segunda parte el partido se puso muy de cara para el Sevilla tras la expulsión, algo rigurosa, del lateral izquierdo del Numancia.

Pese a eso el Sevilla, más dinámico con la entrada en juego de Romaric, no conseguía llegar con peligro a la meta contraria.

Tanto en la primera, como en la segunda parte al equipo lo he visto bastante afectado por los tres partidos que ha tenido que jugar seguidos frente al Depor, sobre todo los dos últimos, muy seguidos y fuera de casa. Esto ha provocado que el ritmo del Sevilla no fuera alto y eso ha facilitado mucho el trabajo del Numancia incluso con 10 jugadores.

Finalmente, la lógica se impuso y tras una estupenda jugada entre Navas y Renato, este último puso la pelota en las redes de Juan Pablo.

A destacar el debut de Javi Varas, con varias paradas que salvaron goles del Numancia.

También destacar el partido de Aquivaldo Mosquera, donde lo dió absolutamente todo. Evidentemente no es ni debe ser el lateral derecho del Sevilla actual ni el del futuro, pero si finalmente se queda en Sevilla y le dejan trabajar y no se le atosiga desde los medios, puede ser una buena solución para determinados partidos, ya no solamente en el lateral, sino en su posición natural de defensa central.

Desde que me dedico a la gestión de proyectos informáticos, uno de los principios que he aprendido y que se cumple prácticamente en la totalidad de los proyectos informáticos es el de la Navaja de Occam, es decir, en igualdad de condiciones la solución más sencilla en un proyecto informático es probablemente la correcta.