Detectar incidencias a tiempo en la construcción del sistema de información
Hace unos días hice una prueba en uno de los sistemas de información que están bajo mi responsabilidad y que había comenzado el proceso de construcción pocas semanas antes. Dicha prueba consistió en que tanto el arquitecto Java de mi departamento como uno de los integrantes de la Oficina de Calidad revisaron junto a técnicos de la empresa desarrolladora, tanto la arquitectura que iba a tener la aplicación, la implementación elegida en los distintas capas de la misma, ejemplos significativos de clases que tuvieran ya construidas y el fichero pom.xml.
Es cierto que la revisión de la arquitectura y de la implementación elegida en cada capa se debería haber realizado antes de iniciarse la construcción, pero la ventaja de utilizar un libro blanco de desarrollo en la organización, que dicho documento sea de uso obligatorio y que indique con claridad qué arquitectura utilizar y qué posibilidad de implementación hay de sus distintos niveles, da bastante tranquilidad en este aspecto. Además, antes de iniciarse la construcción recalqué al proveedor el marco de desarrollo base que tenía que tomarse como referencia.
La revisión permitió detectar algunos aspectos en la construcción que hacían la aplicación menos mantenible y por tanto corregirse a tiempo para que el resto del proceso tuviera en cuenta esas políticas, lo cual llevará consigo que cuando la aplicación se entregue tendrá una mayor calidad.
La política que había empleado en mis aplicaciones hasta ahora es que la Oficina de Calidad interviniera a partir de la entrega del producto (ya sea de uno nuevo o de una evolución del mismo), esto permite detectar y corregir errores funcionales y no funcionales, pero corregir, cuando se producen, malas prácticas de programación o la no adecuación al libro blanco de desarrollo es tan costoso en este punto, que la mayoría de las veces no se actúa contra ellas, salvo que afecte al funcionamiento, rendimiento o seguridad de la aplicación.
También aproveché para que la Oficina de Calidad tuviera la oportunidad de conocer de qué iba el sistema de información, ya que la mayoría de las veces se enteran cuando se le entrega el producto final. En este caso, dada la complejidad del mismo, creí conveniente que cuanto antes empezasen a conocer las características del sistemas, más fácil iban a tener después la comprensión del mismo y de la documentación del proyecto una vez realizada la entrega.
La experiencia ha sido muy positiva y pienso aplicarla a partir de ahora en todos los desarrollos que estén bajo mi responsabilidad ya que estoy seguro que va a incrementar la calidad de los productos que se entreguen y el mayor conocimiento por parte de la Oficina de Calidad del sistema de información le permitirá ser más preciso en la realización de las pruebas del sistema de información e incluso en la revisión del plan de pruebas antes de ser entregado.
Jummp 