archivo

Archivos diarios: diciembre 15, 2012

Realmente hasta que no tienes software funcionando y preferentemente en el entorno de producción no tienes certeza de que el camino escogido ha sido el correcto.

¿Quiere decir esto que la ingeniería del software no sirve para nada?, ¿quiere decir esto que todo trabajo previo no es válido?

No, no quiero decir eso. Como he repetido en muchas ocasiones, el desarrollo de software debe hacerse con intención minimizando la especulación. La especulación da lugar a iteraciones de más y en consecuencia a trabajo de más que en función del presupuesto existente en el proyecto puede impactar en la calidad del producto final y en el cumplimiento de las expectativas del usuario. Por tanto, es serio desarrollar con intención.

La intención te la da el estudio y el conocimiento del problema, no solo a nivel técnico sino también a nivel funcional. Cada proyecto podría requerir soluciones particulares para la obtención de ese conocimiento.

Ese conocimiento sirve de ayuda para adaptarnos de manera más consciente al cambio, es ágil tener ese conocimiento y no es ágil lo contrario.

El enfoque de cómo se adquiere ese conocimiento y cómo se plasma, tal y como decía, depende del proyecto y también tiene mucho que ver, porque podrá haber diferentes opciones, nuestro conocimiento, nuestra experiencia y nuestra forma de trabajar (pero todos ellos deben ponerse a servicio del proyecto y no al revés). Aquí es donde pueden centrar el debate los más ortodoxos de la ingeniería del software de aquellos que aplican la ingeniería de otra manera (generalmente con otro estilo e instrumentos).

Tan malo es tirarse a la piscina sin agua (sin conocer qué es lo que vamos a hacer desde un nivel general) como esperar “eternamente” a tener todo “sobre plano”. Tal vez pueda bastar con tener solo ciertas partes “sobre plano” conservando una visión global de lo que se requiere. Lo primero porque hay que desarrollar con intención y lo segundo porque lo más probable es que el plan salte por los aires, teniendo en cuenta que el mismo ha sido desarrollado desde una imagen abstracta del sistema por parte del usuario que una serie de desarrolladores se han encargado de interpretar. A eso hay que sumar la incertidumbre inherente al desarrollo de software y a los cambios que se producirán a lo largo de todo el proceso de desarrollo.

Después, cuando tengamos el producto en producción, vendrán los ajustes. Mucho mejor tratarlos cuanto antes porque si la desviación de las expectativas es importante el coste siempre será mucho menor, todavía podría haber tiempo de revertir la situación.

Una cosa es la documentación propia del proceso de desarrollo de la cual ya sabéis mi opinión (actual): debe proporcionar valor real a quien va dirigida y debe ser la justa y la necesaria acorde al contexto del proyecto y a las características del sistema de información (más documentación de la necesaria o, siendo necesaria, más información de la que resulta práctica es un peso muy importante con el que cargar en el proyecto y que termina derivando generalmente en documentación que se queda obsoleta y que generalmente no ha amortizado el esfuerzo que ha sido necesario para elaborarla y mantenerla hasta el momento en que se decide abandonar).

Hay determinados sistemas que su principal misión es proporcionar servicios a terceros o servir de plataformas que se configuran y/o son ampliables para contener en ellas diferentes tipos de aplicaciones. En estos casos la documentación necesaria para integrarse u operar con ellos debería ser algo innegociable y el esfuerzo en mantenerla con la mayor calidad posible y actualizada un objetivo prioritario dentro de este tipo de sistemas. En caso contrario el esfuerzo necesario para que los desarrolladores investiguen cómo trabajar con esas herramientas se multiplica prácticamente tantas veces como integraciones o desarrollos se realicen sobre ellas lo que al final deriva en esfuerzo que ha podido ser perfectamente evitado (y en dinero que se podía haber ahorrado o esfuerzo que se podía haber invertido en mejorar en lo posible las funcionalidades más importantes del sistema) y que se puede considerar como un interés a pagar por la deuda de esa falta de documentación.