archivo

Archivos diarios: junio 29, 2011

Se entrega una iteración de un sistema, se realiza una evolución del mismo mediante tareas de mantenimiento evolutivo o se corrigen incidencias y no paran de producirse efectos colaterales, una vez, otra vez y otra vez.

Además de dar muestras de que no se realizan pruebas de regresión de manera adecuada (o directamente no se llevan a cabo), el sistema de información da muestras de tener un diseño y/o una codificación deficiente, ya que cuando se toca un componente empiezan a salir grietas por todos lados.

Cuando esto pasa, la sensación de desconfianza entre los usuarios o los responsables tećnicos del cliente es tal que cualquier cambio en el sistema da sensación de pánico y lo peor de todo es que esas sensaciones se terminan convirtiendo en un hecho.

Cuando nos encontramos con estos problemas, hay que estudiar cuanto antes su origen. A veces serán aspectos concretos que se podrán más o menos controlar y otras veces serán tantas las minas en el código que cualquier cambio presenta un riesgo de efectos colaterales.

Una vez detectadas las causas toca tomar decisiones que dependerán de la envergadura del problema, de la disponibilidad presupuestaria y de la frecuencia con que se esperen tareas de mantenimiento sea del tipo que sea.

Una continuación de este artículo se puede leer en Testing Baires.

Si la mayoría de los sistemas de información de una organización no reutilizan código generado en el desarrollo de los mismos o en otros, nos encontramos con que estaremos reinventando la rueda una y otra vez.

La teoría dice eso, pero la realidad pone bastante difícil el proceso de reutilización, sobre todo en entornos con muchos proveedores, con un portfolio de aplicaciones alto y con diferentes estados en su ciclo de vida.

Hay que tener en cuenta que decir que no se reutiliza, no es cierto, ya que la mayoría de los desarrollos utilizan librerías de repositorios estándar, como por ejemplo las que componen determinados frameworks. Además, los proveedores también reutilizan determinadas librerías propias.

Si además se utilizan generadores de código, hay que sumar a las librerías todo el software que se ha escrito automáticamente, que si bien no es código reutilizado es fruto de un componente que se reutiliza una y otra vez (y que también va evolucionando, mejorando y adaptándose a los cambios en la tecnología y en los frameworks).

La reutilización se puede hacer principalmente a dos niveles, uno a nivel de librerías, es decir, que se puedan reutilizar desarrollos de otros proveedores, lo que requiere tener las mismas bien catalogadas y otro a nivel de delegación de funcionalidades en componentes de más alto nivel.

Este segundo nivel de reutilización, se basa en el uso de un componente que realiza una funcionalidad concreta a través de la comunicación con el mismo a través de un API. Estos componentes realizan una funcionalidad de cierta complejidad y nuestro sistema lo utilizará para que realice una determinada competencia, como por ejemplo, la gestión de usuarios, la autenticación, la gestión de documentos a firmar electrónicamente, la generación de documentos, la gestión de su almacenamiento, etc…

Además de las ventajas que supone reutilizar el componente en el desarrollo, tenemos las propias de no tener código duplicado (o funcionalidades duplicadas), es decir, el mantenimiento y testing de esos componentes está centralizado en una sola instancia, lo que además de ahorrar esfuerzo permite incrementar la estabilidad de nuestros sistemas.

Opciones hay muchas. Precisamente hoy he estado hablando de este asunto con algunos compañeros. Hemos consensuado que la solución con menos overhead y más flexible, es utilizar un documento por cada tipo de documento del proyecto, es decir, un catálogo de requisitos, un documento de casos de uso o cualquiera que se utilice en función de la metodología y del tipo de proyecto, siendo extensible por ejemplo a historias de usuario, diagramas de despliegue, etc… que vaya creciendo de manera incremental con cada evolución, pero que en contenido vaya creciendo de manera diferencial.

Es decir, el documento contiene el contenido de las iteraciones anteriores y el de la actual, pero en la parte dedicada a la actual solo se incluye lo correspondiente a esta evolución y solo recoge de las anteriores lo estrictamente necesario para ayudar a la comprensión de la misma.