archivo

Archivos diarios: septiembre 29, 2011

Si en el nivel 3 de CMMI se entra en el detalle de cómo obtener los requisitos resulta razonable que no ignore los procesos de diseño y construcción y de esto trata este área de proceso.

Es muy importante no caer en la trampa de definir procesos poco flexibles que no permitan una adaptación a la tipología de sistemas de información y circunstancias que pueden producirse en el desarrollo y mantenimiento de los mismos. Puede ser razonable hacerlo en entornos controlados, pero en entornos variantes (como son la mayoría) hay que establecer una serie de pautas que normalicen el proceso de diseño y construcción de manera que lo que se marque sea un camino con la suficiente anchura como para elegir dentro de él la trayectoria más adecuada al proyecto pero lo suficientemente estrecho como para tener un control de la manera en que se diseñan y construyen los sistemas.

Dentro de este área de proceso se determina en qué condiciones se deben ofrecer alternativas de solución y cuál es la información que se debe suministrar en cada caso, qué criterios utilizar para seleccionar una de ellas, qué criterios, técnicas, estrategias, precondiciones, etc… tener en cuenta a la hora de realizar el diseño del sistema, qué circunstancias se deben tener en cuenta a la hora de elegir la opción más ventajosa para obtener la solución que se demanda (comprar, reutilizar o construir), qué prácticas se deben seguir para realizar la construcción del sistema y para escribir la documentación de soporte.

¿Se basa este proceso en tener y seguir un libro blanco? Hay aspectos de este área de proceso que escapan de un libro blanco convencional, como aspectos de un libro blanco convencional que van más allá de este área de proceso, no obstante para imaginarnos qué contenido tendría un proceso como este es una buena aproximación, si bien equipararlos, tal y como acabo de comentar sería caer en el error.

La siguiente reflexión de Michael Anthony Jackson muestra uno de los problemas con los que nos encontramos habitualmente cuando nos empezamos a dedicar a este negocio, si bien no todos terminan aprendiendo de la experiencia: “El origen de la sabiduría de un programador (desarrollador) se basa en conocer la diferencia entre un programa que funciona y un programa correcto. Un programa que no funciona es indudablemente incorrecto; pero un programa que funciona no es necesariamente correcto; ya sea porque es difícil de entender (utilizar), porque es difícil de mantener ante cambios en los requisitos, porque su estructura es diferente a la estructura del problema o porque no estemos seguros si funciona”.

La reflexión es del año 1975 y como suele pasar con muchas de estas máximas del desarrollo de software, más de treinta y cinco años después continúa vigente.

Un software de calidad no es un software que corre, necesita más, mucho más. Y ahí es donde está la diferencia entre un desarrollador y otro y entre una empresa de desarrollo de software y otra.

Soy consciente de que en muchas ocasiones el contexto en el que se ha desarrollado el proyecto no permite o no facilita la obtención de un sistema de calidad o de una aplicación totalmente correcta, pero la diferencia está en la intención, es decir, hay equipos de desarrollo que permanecen planos tanto cuando hay cuestas arriba como cuando las hay hacia abajo, en los que solo importa ejecutar trabajo sin preocuparse por la eficiencia del mismo, en los que solo importa que el taxímetro esté funcionando para facturar al cliente, en los que solo importa cerrar el proyecto cuanto antes, caiga quien caiga.