No es lo mismo calidad del PRODUCTO software, que calidad del PROCESO software, que calidad del EQUIPO

En el mundo del software, y supongo que en otras disciplinas también, cuando nos referirnos al amplio concepto de “calidad software” hemos de ser muy conscientes de que en realidad ese “etéreo” concepto de calidad se subdivide, principalmente, en tres tipos de calidad: la del proceso, la del producto y la de las personas/equipos.
No se vosotros, pero yo demasiadas veces me encuentro con que este tema, aun siendo tan antiguo, en el mundo empresarial no está tan claro y maduro. Y, a la hora de la verdad, cuando se entrega el software, aquello que en la oferta / contrato parecía tan claro resulta que produce enormes desengaños. “¿Pero cómo puede ser qué la empres x con CMMI nivel y nos entregue este producto tan malo?” “¿Pero no usaban la metodología z?”
Sin pretender, ni poder, resolver el mundo, dejáme que en este post haga un breve resumen de estas tres tan diferentes y determinantes áreas de la calidad software.

La calidad del proceso

La calidad vista desde el mundo de los PROCESOS nos dice que la calidad del PRODUCTO software está determinada por la calidad del PROCESO. No me voy a perder en definiciones de libro, pero por proceso se entiende las actividades, tareas, entrada, salida, procedimientos, etc., para desarrollar y mantener software.
Modelos, normas y metodologías típicas aquí son los CMMI, ISO 15504 / ISO 12207, el ciclo de vida usado, e incluso las metodologías ágiles entran aquí (aunque en el mundo ágil la palabra proceso no guste nada, no entiendo muy bien porque, aunque creo que es porque hay quien aún piensa que proceso = a ciclo de vida en cascada, lo cual no es nada cierto, véase este post para más detalle)
Un buen proceso sin duda segura un buen producto, pero, claro, también podemos seguir un modelo de procesos famoso, y que no sea el más adecuado para nuestra organización y que por ello el producto no acabe siendo el mejor. Por ello, una mala, algunas veces perversa, interpretación es asumir que cumpliendo cierto modelo, nivel de madurez, norma, metodología, ciclo de vida, o cualquier otra cosa relacionada con el proceso… se ASEGURA por ello directamente productos de calidad. ¿Realmente es garantía suficiente? ¿Una certificación sobre la calidad del proceso garantiza un producto de calidad?…

La calidad del producto

Comentaban en IEEE software que hay poca evidencia en que cumplir un modelo de procesos (CMMI, ISO 12207, una metodología ágil o no, etc.) asegure la calidad del producto. Y en Computer, que las evaluaciones de calidad deberían estar basadas en evidencias del producto (auditando el software), y no en evidencias circunstanciales o suposiciones.
Y es por ello que existen los modelos de calidad de producto, destacando entre ellos la ISO 9126, o la nueva serie ISO 25000, que especifica diferentes dimensiones de la calidad de producto. Aunque aquí la dura tarea de evaluación recae en el uso de métricas software, amplio mundo que no voy a tratar porque excedería el objetivo de este post.
una empresa que desarrolla software debe preocuparse de la calidad del PROCESO y del PRODUCTO que desarrolla y entrega, una empresa que solo compra software (el típico cliente) debería, principalmente, preocuparse de la calidad del PRODUCTO que compra. Aunque vemos que en la realidad, las empresas que compran software lo hacen al revés, se preocupan por el proceso que usa su proveedor (CMMI, ISO, etc.) y apenas del producto que les llega. Cosas de la industria.

La calidad del equipo y/o personas

Ya lo decíamos en aquel post… ¿Qué es lo más determinante para el éxito, o fracaso, de un proyecto (o para el producto software)? Las personas. Lo más determinante, complejo, y sobre lo que menos “guías”, “maneras de puntuar” o “métodos” hay. Tema complejo donde los haya.
Aquí podemos encontrar decenas de aproximaciones para mejorar, que van desde el tan de moda coaching, a la filosofía ágil de lograr la auto-organización de los equipos, estrategias de motivación, combinaciones de los anteriores, etc. E incluso hasta hay modelos, como son los TSP y PSP.
Alguna conclusión…
Si quieres calidad, vas a necesitar los tres anteriores. Aunque depende del rol que juegues te puede importar más uno u otro, y esto es muy importante saberlo. Si eres un cliente que solo compra software no puedes perder la prioridad, procesos, productos y personas son importantes, pero la calidad del producto es para ti determinante. Si eres fabricante de software, vas a necesitar los tres y no puedes olvidar ninguno.

0 comentarios en “No es lo mismo calidad del PRODUCTO software, que calidad del PROCESO software, que calidad del EQUIPO”

  1. Pingback: Bitacoras.com

  2. Pingback: ¿Cuál es el PRIMER paso para empezar a implantar y mejorar la calidad software? - Javier Garzás, sobre calidad software y otros temas relacionados

  3. Pingback: ¿Quieres aprender a evaluar – auditar calidad software? ¿y quieres venir Gratis al curso del viernes? Sigue leyendo… - Javier Garzás | Javier Garzás

  4. Buenos días,
    Primero de todo comentar que tu post me ha resultado de lo más interesante (al igual que el resto del blog). En mi caso particular, como cliente (administración pública), tenemos en cuenta también la calidad del proceso dado que el software se va a construir de la siguiente forma:
    análisis y diseño en casa y programación externalizada.
    El modelo es pseudo-cascada (con iteraciones dentro del bloque de análisis y diseño) pero es el que mejor encaja dado el modelo de contratación que dispone (aún) hoy día las administraciones públicas,ya que para poder ofrecer un pliego en condiciones, el análisis (y en nuestro caso también el diseño) es importante que todo este bien cerrado y sin ‘agujeros’ que den pie a interpretaciones erróneas, especialmente en la fase de implementación. Es por ello que solemos interesarnos por que modelos de proceso habitualmente implementan las empresas de desarrollo de software, ya que parte del proceso subsiguiente, en el caso de contratación, ha de ‘encajar’ con el nuestro.
    En nuestra experiencia no exigimos ninguna certificación de nivel de madurez (CMMI-DEV) u otras aplicables como las que comentas en el blog, pero sí que consideramos necesario tener que fijar ciertas ‘formas’ en cuanto a la ejecución, dado que hay un equipo tanto interno a la administración como externo a ella que ha de confluir durante la fase de implementación y sobre todo guiar al equipo de desarrollo en caso de dudas sobre las decisiones tomadas en la fase donde ellos no participaron (entran aquí en juego los criterios de disponibilidad y continuidad de equipos).
    En resumen, con este ejemplo quiero expresaros que como cliente tienes también que fijarte no solo en la calidad del producto final exclusivamente, sino también en como se va a construir aquello que compras si tu pones las especificaciones y quieres hacer un seguimiento ordenado de como se va a construir para poder pasar después a validar el producto final.
    Un saludo y felicidades por el blog.

  5. Javier, excelente post, felicidades, mi pregunta sería si los modelos de evaluación de producto que mencionas (ISO9126 e ISO25000), también son aplicables a otros modelos de procesos además del ISO 15504 / ISO 12207.
    Gracias, saludos.

  6. Iba navegando recopilando información para una tarea y me encontré con tu post. Excelente, me ha sido de gran utilidad. Te vas a mis sitios concurridos para estar al tanto de lo que escribes.
    Saludos.

  7. requiero ponerme en contacto con usted profesor, su correo
    me encuentro realizando la tesis doctoral sobre este punto y requiero su valiosa intervencion

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba