Desarrollo de software: Revisiones funcionales y de código durante el desarrollo

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.

Anuncios
2 comentarios
  1. soyfelix dijo:

    No es el mundo ideal. Es la guerra contra los comerciales y funcionales. Hay y habrá desarrolladores buenos y malos. Pero una funcionalidad mal definida no distingue entre desarrolladores buenos y malos, ambos serán malos. El mundo de la consultoría están llenos de funcionales vagos que solo pasan el marrón y se aseguran de que no les vuelvan. Cansado estoy de esta situación. Se nota que soy desarrolador, no?? 🙂

  2. jummp dijo:

    En mi concepción de los proyectos de desarrollo de software, los analistas deben formar parte activa en el proyecto y no solo participar en la fase de definición, análisis y diseño. No digo que tengan que participar directamente en la construcción pero sí estar implicados en ella.

    Esto que estoy comentando anda alejado del concepto de factoría del software, tal y como es entendido por muchos, ya que no comparto una división del trabajo de esa manera, ya que da lugar a circunstancias como la que comentas, es decir, analistas que hacen análisis pero que después no tienen responsabilidad en el proceso de construcción o bien si la tienen pueden mirar para otro lado ya que tendrán relativamente fácil echarles las culpas a los que están desarrollando, al cliente o a ambos. Como es lógico, esto es una generalización y como tal habrá casos (tal vez muchos) en que no se cumpla y existan empresas de desarrollo con procesos sólidos que minimicen este tipo de circunstancias.

    El proceso de análisis es complicado, muy complicado y hay que valorar el trabajo que realizan los analistas, como también hay que valorar el trabajo de los programadores y por supuesto el de los comerciales, ya que sin ventas no hay ingresos y sin ingresos no hay empresas. Por supuesto que comerciales y analistas pueden dejar marrones tremendos, pero eso entra dentro del margen de error que tenemos cada uno, si un comercial o un analista tiene un fallo grande o una acumulación de fallos más pequeños ponen en riesgo su continuidad en la empresa o su capacidad de proyección salarial y/o profesional en la misma, lo mismo le sucede a los desarrolladores. Todos se juegan mucho en esto.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: