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.
http://jummp.wordpress.com/2009/01/18/lo-importante-de-las-metodologias-de-desarrollo-en-un-proyecto-de-desarrollo-de-software/
No hay comentarios.:
Publicar un comentario