archivo

Archivos diarios: septiembre 15, 2011

Comenta Assaad Chalhoub que «un software sin documentación es como un barco sin brújula». Como cita está bien pero me quedo sobre todo del espíritu de la misma, la necesidad de un método de trabajo para desarrollar software en el cual la documentación juega un rol importante siempre y cuando sea la adecuada a la naturaleza del proyecto.

La solución a una mala elección del tipo de documentación a generar en un proyecto no debe suponer su eliminación de la metodología de desarrollo (que puede ser lo más fácil pero lo más perjudicial) sino de seleccionar la apropiada.

Si la madurez de la organización en base a CMMI se basa en la definición y aplicación de procesos en diferentes áreas resulta fundamental la verificación de que los mismos se están aplicando de forma correcta.

Definir procesos y procedimientos puede resultar sencillo, incluso entretenido (ya que al fin y al cabo se están escribiendo las reglas del juego), sin embargo el cumplimiento de los mismos por parte de las personas que intervienen en ellos es más complicado.

En el caso concreto de los desarrolladores de software juega en nuestra cuenta nuestro carácter, nuestro individualismo, nuestra creatividad y tendemos a anteponer esos sentimientos al cumplimiento de las especificaciones y estándares que componen los procesos, como si fueran incompatibles, algo que es simplemente una ilusión, ya que los procesos determinan un orden, una forma de hacer las cosas, te marca un camino, dentro del cual se tiene un margen de maniobra. Es evidente que hay que renunciar a cosas pero es que la situación contraria donde todos actúen como quieran y cuando quieran, siempre va a ser más perjudicial.

Por tanto, resulta fundamental que exista un área de proceso que precisamente se encargue de fiscalizar el cumplimiento de las reglas del juego. Si tenemos procesos es para respetarlos. Por supuesto que nos hemos podido equivocar al definirlos, pero la solución no pasa por obviar al proceso, sino por corregir sus deficiencias.

En los procesos existen hitos y entregables, resulta importante evaluar la consecución de los mismos, así como la calidad y adecuación de los artefactos producidos.

Los procesos se llevan a cabo para que el desarrollo del producto se realice dentro de un entorno controlado y medible (o por lo menos lo más controlado y medible posible), es decir, los procesos no son un fin en sí mismo, no tendrían sentido sin la existencia de un producto software a desarrollar. Por ese motivo, de la misma forma que es necesario asegurar la calidad del proceso también lo es la verificación de la calidad del producto, dentro de los umbrales de calidad definidos en la propia organización y/o combinados con los especificados por el cliente.

Mediante este análisis es posible que se encuentren disconformidades, las cuales deben ser reportadas y resueltas. Puede resultar adecuada la existencia de personal específico independiente a los equipos de proyectos que se encarguen de realizar este tipo de evaluaciones, sin menoscabo de que en el propio plan de proyecto se definan diferentes hitos internos para el control de la calidad del proceso y del producto.

¿Deben llegar las disconformidades al nivel de gerencia? Dependerá del proceso que se defina. En mi opinión, el mecanismo de control del equipo externo al proyecto resulta suficiente, si bien sí que entendería que desviaciones importantes respecto a los procesos especificados o la no corrección de deficiencias detectadas fueran comunicadas a niveles superiores en la organización para que conozcan las circunstancias y puedan tomar decisiones conducentes a normalizar la situación.

Cualquier cambios que se le haga a un usuario respecto a su forma de trabajar no suele ser acogido de buena gana, es más, cuando mayor sea la diferencia, mayor será su resistencia al cambio. En general, cualquier ruptura de hábitos y/o automatismos provoca estas sensaciones, a todos nos pasa, por lo que es inteligible que ese tipo de circunstancias tenga esas consecuencias.

Cuando se desarrolla un sistema de información, hay que tener en cuenta ese salto entre la situación actual y la situación objetivo, teniendo en cuenta también las características de los usuarios que va a tener la aplicación. Es importante, por tanto, que el usuario sienta la menor hostilidad con respecto al entorno, para ello es esencial la gestión del cambio, la cual puede empezar (y debe empezar) desde el mismo proceso de desarrollo y no esperar hasta que se ha realizado la implantación, como suele suceder casi siempre.

El papel lo aguanta todo. Sería estupendo que todo lo que se diseña, todo lo que se imagina después se convirtiera en realidad. El problema del diseño es que después hay que ejecutarlo y el proceso real de construcción puede estar lleno de problemas que den al traste con el planteamiento inicial y/o que demuestre que ese diseño que parecía perfecto se alejaba mucho de las expectativas del usuario.

La solución a este problema no es prescindir de un diseño. El Cowboy coding no es la solución. Un proyecto sin una metodología adecuada a sus características, sin una guía que determine dónde y cómo dirigir el esfuerzo, es un proyecto sin cabeza y que solo con suerte puede salir adelante en unas condiciones aceptables y creo que, en un mundo como este, con la competencia que hay, con los presupuestos tan ajustados que existen, hay que dejar a la suerte o a la casualidad el menor pese posible.

Sobre este asunto me parece muy acertada la siguiente reflexión de Assaad Chalhoub: «El diseño sin código es solo un sueño. El código sin diseño es una pesadilla».

Cometer errores en el desarrollo de software es algo natural como lo es en el resto de profesiones, por supuesto que tenemos que intentar reducir la criticidad y cantidad de los que cometemos, pero es necesario desdramatizar un poco este asunto porque tan malo como equivocarse es tener miedo a cometer errores, ya que bloquea al individuo e impide o retrasa la toma de decisiones posibles.

Lo importante, por tanto, no es no equivocarse sino poder detectar los errores a tiempo, ya que cuanto más tarde se descubran más costoso será corregirlos. Con el empleo de buenas prácticas (tanto individuales como en el proyecto) y existiendo una metodología de desarrollo adecuada que contemple la realización de testing en distintos momentos del proceso de desarrollo se reducirán las posibilidades de que nuestros errores se propaguen a etapas posteriores, si bien hay que tener en cuenta que salvo que se empleen mecanismos muy rígidos de testing (y en muchos casos aún así), siempre nos encontraremos con errores que irán traspasando esas barreras.

Assaad Chalhoub es un ingeniero de software libanés que trabaja como director técnico en una empresa de desarrollo y consultoría de software y es profesor universitario en la Universidad de Notre Dame.

Este técnico tiene un par de reflexiones muy válidas para reflejar la realidad de los errores en el proceso de desarrollo de software:

– «Quién haya realizado un software libre de errores que tire la primera piedra».

– «La única manera de eliminar los bugs es asesinando al tester».

La respuesta la he obtenido en una cita anónima que dice que: «Cualquier programa que funciona correctamente está obsoleto».

Es decir, la evolución del producto se puede extender a lo largo de todo su ciclo de vida porque en cualquier momento pueden aparecer nuevas funcionalidades que incorporar al sistema o la modificación de las ya existentes.

El desarrollo de software es así, evolutivo, cambiante y es importante que tengamos en cuenta ese aspecto a la hora de enfocar un proyecto, sobre todo si es complejo y/o de gran tamaño. También resulta fundamental la actitud pedagógica con la dirección de la organización y con otros departamentos para que tengan en cuenta este aspecto a la hora de designar los presupuestos para el Departamento TIC.