28 de diciembre de 2006

Algunas ideas sobre la calidad en el desarrollo de software

Hace unos momentos leía una presentación sobre calidad sobre las normas ISO, para ser más específicos. Debo admitir que tiene conceptos interesantes ya que menciona que son una referencia internacional para exigencias de dirección de calidad entre empresas y que se aplica a toda empresa que busca tanto aumentar la satisfacción del cliente como una mejora continua. Suena muy bien, al menos hasta ahora.

Dice también que dos razones por las que se busca la certificación en la calidad de los procesos son dos por requerimientos del cliente y por presión de la competencia. Vamos al día con día.

La aplicación de normas rigurosas en las etapas tempranas del desarrollo de software necesariamente conlleva un aumento en el tiempo que se toman las fases de análisis y validación de requerimientos. Lamentablemente esto no siempre se comprende y se toma muy poco tiempo para estas fases, perdiendo de vista (ambos lados) el objetivo de la satisfacción del cliente.

Esto pasa, pienso yo, cuando tanto el proveedor, como el cliente no concuerdan en la prioridad de los procesos de calidad, de entrada, cuando el cliente no se involucra adecuadamente en el desarrollo de su software al no asignar tiempo para que el proveedor entreviste al personal operativo que seguramente conoce los intríngulis de los procesos. O bien cuando el cliente propone a alguien que no conoce del todo el proceso como interfaz con el cliente, siempre es bueno hablar directamente con quienes “hacen las cosas”.

Bajo estas condiciones, el análisis de requerimientos saldrá mal o no contemplará todos los aspectos de un proceso.

Posteriormente, durante la fase de validación de requisitos es posible que el cliente detecte omisiones y las haga patentes, en cuyo caso habrá que regresar a revisar los faltantes y a corregir los errores potenciales. Si no se detectan, aún hay posibilidad de que salgan a la luz posteriormente. De cualquier modo, ya se tuvo que invertir un poco de tiempo que quizás no estaba contemplado de inicio, ¿quién planea que las cosas pueden salir mal?

Otro problema común es cuando el cliente quiere las cosas “para ayer”. Es obvio que esta práctica elimina la posibilidad de hacer un buen análisis del impacto de los requisitos de adecuación y tiene como resultado común un código parchado que se vuelve inestable con el paso del tiempo y que será complicado de mantener y que seguramente no estará debidamente documentado.

Durante la fase de diseño del software, el cliente debe estar informado y ser consultado hasta el cansancio a fin de hallar, en la medida de lo posible, cualquier defecto de análisis y con ello garantizar que el proyecto quede bien delimitado.

Al principio al cliente, puede parecerle un poco engorroso pero a la larga redundará en la satisfacción por el producto final. Esto es lo que hace la diferencia entre una empresa comprometida con la calidad y aquella que no cuenta al menos con una política interna de desarrollo.

Estos son algunos beneficios que una certificación de calidad otorga.

Internos:

- Mayor sistematización y documentación de los procesos

- Aumento de la productividad

- Mejoramiento de la organización interna

- Incremento en la rentabilidad

- Orientación a la mejora continua

- Mayor capacidad de respuesta

- Mejoramiento en la gestión de costos y riesgos.

Externos:

- Mejoramiento de la imagen empresarial

- Refuerzo de la confianza entre los clientes actuales y potenciales

- Apertura de nuevos mercados

- Mejoramiento de la posición competitiva

- Aumento de la fidelidad de los clientes

Finalmente, pongo a su consideración tres ideas que podrían mejorar las prácticas en la industria del desarrollo de software:

1) La calidad es necesaria tanto para el cliente como para el proveedor.

2) No es necesario comenzar con normas ISO, CMM, RUP o cosas así, vale más, adoptar de entrada algo cómodo y adecuado al tamaño de la empresa, sin dejar de buscar la mejora continua.

3) A veces es necesario enrolar al cliente en la cultura de la calidad y hacerle comprender la importancia de los procesos.

No hay comentarios.: