Un proveedor me comentó un día que el mayor enemigo para la calidad del software es el tiempo, entendiéndose este en sus dos vertientes: en las existencia de fechas de entrega y que los costes del proyecto están directamente relacionados con el tiempo dedicado al mismo.
Desde luego que no le falta razón, pero estoy seguro que el simple hecho de tener más tiempo o algo de más presupuesto no implica tener un producto de mayor calidad. Muchas veces disponer de más tiempo supone simplemente tener más tiempo que perder.
Por tanto, el tiempo puede ser un factor importante pero más lo es la existencia de unos procesos internos de revisión funcional y de código de las aplicaciones. Ahí sí que se marca la diferencia. Cuesta dinero, claro que sí, pero ¿más que tener que dedicar tiempo al proyecto una vez entregado teniendo en cuenta que probablemente interrumpirá otras actividades en otros proyectos?, ¿más que los beneficios que se obtienen por tener una imagen de empresa asociada a la calidad de los desarrollos?.
Como he comentado en otros artículos, la calidad del software no empieza por el final, es decir, por retocar lo ya construido porque eso es costoso, sino que parte desde la realización de un buen análisis funcional (el principio de todo), pasando por la seleccion de una arquitectura y framework que sienten las bases para un desarrollo posterior de calidad, no asegura nada, pero mejor partir de una buena base que carecer de ella.
Desde que comienza a codificarse tomando como base el framework empezarán las desviaciones en cuanto a la calidad del producto final desde el punto de vista de la programación, como es lógico si el análisis no es bueno, las deficiencias empiezan desde antes, pero si a un análisis mejorable le sucede un diseño o una codificación mala, serán mayores los problemas a los que tengan que enfrentarse cliente y proveedor en un futuro debido a que cuando se tenga que tocar la aplicación para ajustar los requisitos funcionales costará muchísimo más trabajo si el código no facilita el mantenimiento.
Por ese motivo las revisiones funcionales y de código deben empezar desde el principio ya que cuanto más tiempo pase hasta que se detecten los defectos más costoso será tomar soluciones, tanto, que determinados tipos de problemas se obviaran debido al coste que tendría solucionarlos. ¿Tiene esto un coste? Desde luego, ya que las revisiones además deberían hacerlas personas ajenas al equipo de desarrollo, pero realmente la clave está en pensar que la entrega de un mal producto implica que ese coste (probablemente mayor que la inversión a realizar por aplicar estas revisiones) repercute tras la entrega en lugar de repartirse a lo largo del proyecto.
Tengo muy claro que la mayoría de los proveedores de desarrollo de software estarán en desacuerdo con este artículo por la sencilla razón de que habla de un «mundo ideal» en el que el cliente es un comprensivo corderito y desde ese punto de vista tengo que dar la razón, ya que el cliente va a ser exigente y además de eso va a tratar de meter evoluciones del producto dentro de la garantía y eso va a pasar independientemente de si el trabajo ha sido bueno o malo o si la calidad del software ha sido óptima o regular. Llegado a ese punto toca negociar y mejor hacerlo siempre con un producto en las mejores condiciones ya que será más fácil hacerlo teniendo el as en la manga de una buena ejecución y también porque las modificaciones que haya que hacer se realizarán con mayor facilidad.
Sé que esta estrategia de revisión continua se ve como ciencia ficción en el mundo real, lo cual no quita que piense que puede traer buenos resultados e incluso haciendo media, una reducción de costes en los proyectos tanto para el cliente como para el proveedor.
Jummp 