Contexto
En la década de los 80, la mayoría de los automóviles que se producían en fábricas estadounidenses se compraban en Estados Unidos, esto se debía principalmente a que el mercado americano se había mantenido leal a los productos que fabricaba su país.
Esto empezó a cambiar con la llegada de productos japoneses, que eran relativamente más baratos y ofrecían algunas características atractivas. Con el paso de los años, estos autos demostraron tener menos defectos que el auto americano, lo que provocó que el mercado comenzara a darse cuenta de esta gran diferencia de calidad y olvidó su lealtad nacionalista. El auto japonés comenzó a tener mayor participación en una de las industrias más difíciles, mientras que las fábricas americanas fueron orilladas a reducir su producción a tal punto que tuvieron que cerrar, dejando sin empleo a miles de personas. Este cambio de paradigma en la industria automotriz fue motivado por la filosofía del control total de la calidad, cero defectos y análisis estadístico de datos, que permitían a los japoneses implementar cambios en sus procesos de fabricación. Algunos eran cambios insignificantes cuando se les veía de forma aislada, sin embargo constituían una mejora sustancial en cada nueva unidad producida.
Este es un vivo ejemplo de la importancia que tiene la calidad en los productos. A las personas les agrada tener en sus manos productos a los que se les ha dedicado un minucioso proceso de fabricación y la industria del software no es la excepción. Las compañías dedicadas a la fabricación de software necesitan incluir aspectos de calidad en sus procesos si desean generar productos libres de defectos y que cumplan con las expectativas de sus clientes.
Explicación
Uno de los principales miedos que enfrentan los directores de empresas que requieren de un software para apoyar a sus operaciones, radica en la posibilidad de hacer un gasto, que generalmente es considerable, en algo intangible y que no cumpla con sus expectativas o resuelva sus necesidades, y sobre todo un software hecho a la medida es prácticamente imposible revender a otra compañía.
11.1 Conceptos de calidad
Aquí es donde entra la calidad en el software. Primero debes tener claro el concepto de calidad.
La calidad se define como las características de un producto o servicio que permiten satisfacer una necesidad declarada o implícita. La calidad la define el cliente, sin embargo dos clientes diferentes pueden tener percepciones distintas de la calidad de un mismo producto.
Pressman (2010) define a la calidad del software como “el proceso eficaz del software que se aplica de manera que crea un producto útil que proporciona un valor medible a quienes lo producen y a quienes lo utilizan”.
Si analizas con cuidado los elementos de esta definición encontrarás lo siguiente:
En la opinión de Humphrey (2005), la calidad del producto de software empieza por su buen funcionamiento. Si la aplicación no alcanza un mínimo razonable de consistencia en la funcionalidad que el usuario espera, poco importarán otros atributos como la seguridad, usabilidad, compatibilidad, mantenibilidad, etc. Las organizaciones deben considerar enfocar sus esfuerzos, trabajar con calidad desde el inicio del proyecto y no esperar a que el equipo de pruebas verifique que el software está libre de errores, porque puede llegar a ser bastante tarde, sobre todo porque existen plazos específicos que se deben cubrir para evitar retrasar el lanzamiento del producto.
Principios de la calidad:
Humphrey (2006) ofrece los siguientes principios de la calidad que todo equipo de trabajo debe tener presente:
La principal razón por la que un equipo de desarrollo debe buscar la calidad del producto del software es asegurar que el cliente reciba el mejor producto por lo que paga. Incluso cuando el mismo cliente desconoce sus necesidades o los atributos de la calidad, por lo que se debe involucrar al cliente en el proceso de desarrollo y tener claridad de lo que realmente está esperando obtener.
La gerencia que se encuentra frente a equipos de desarrollo de software debe considerar a la calidad como la máxima prioridad. Cuando el equipo trabaja con calidad, es posible controlar el resto de los indicadores operativos como el costo, productividad, retrabajo, bugs en el código, etc., sin mucho esfuerzo.
“La gerencia debe entender y apoyar el principio que hacer un trabajo de calidad es redituable, incluso si no puede comprobar su valor en algún momento” (Humphrey, 2005).
Es importante que el equipo de desarrollo de software comprenda que la calidad no es la responsabilidad de una sola área o grupo de personas, sino que es parte de un programa integral en el que todos participan y se esfuerzan por generar un producto libre de defectos.
Generar un producto de software de calidad no es cuestión de la casualidad, sino el resultado del proceso que se utilizó para generarlo. Cualquier mejora que introduzca el equipo en su proceso de desarrollo, invariablemente afectará de manera positiva a la calidad del producto.
Establecer las métricas que miden el proceso de desarrollo es esencial para reconocer las áreas de oportunidad que tiene.
Si existe un incremento en los costos cuando la calidad mejora es porque hay algo que se está haciendo de manera incorrecta. Cuesta mucho menos hacer bien el trabajo desde el principio que tratar de corregirlo después.
Estándares de calidad
Según el IEEE (Instituto de Ingeniería Eléctrica y Electrónica) un estándar del software es un objeto o medida de comparación que define o representa la magnitud de una unidad. Otra forma de definirlo es el nivel o grado en el que la excelencia requerida es alcanzada. Establecer un estándar de calidad en el desarrollo del software permite generar un criterio en el que es posible que el ingeniero de software pueda basarse para realizar su trabajo. Si este criterio no es seguido, la calidad puede verse afectada de forma negativa. A nivel mundial existen organismos conformados por expertos que han propuesto algunos estándares aplicables al software. En la siguiente tabla puedes revisar los estándares más reconocidos. Con las primeras siglas de cada estándar, puedes identificar la organización que lo propone.
Recuperado de El-Haik, B. y Shaout, A. (2010). Software Design for Six Sigma: A Roadmap for Excellence. EEUU: John Wiley & Sons.
Costo de la calidad
De acuerdo con El-Haik & Shaout (2010), el costo de la calidad (COQ: Cost f quality) es aquel que se encuentra asociado a las acciones de prevenir, encontrar, y corregir trabajo considerado como defectuoso. El costo de una pobre calidad (COPQ: Cost of poor quality) que es un término utilizado en Six Sigma, es aquél que se genera como resultado de producir un software defectuoso. En el siguiente diagrama puedes darte una idea de cómo se incrementa el costo de la calidad al descubrir defectos en diferentes momentos del proceso de software.
Costo de la calidad al descubrir errores de manera interna en comparación a una vez entregado al cliente.
Recuperado de El-Haik, B. y Shaout, A. (2010). Software Design for Six Sigma: A Roadmap for Excellence. EEUU: John Wiley & Sons.
11.2 Planeación de la calidad
Los usuarios de esta década son particularmente más exigentes que antes. La exposición que tienen frente a productos de software es cada vez más frecuente y habitual, sobre todo por la inmensa cantidad de productos que se ponen a su disposición a través de las tiendas de software como Apple store, Google store, y Windows store. Los usuarios pueden descargar aplicaciones para su celular y computadoras personales con un simple clic. Esta frecuente interacción que tienen los usuarios con el software provoca que sus expectativas sean cada vez más altas, incluso para desarrollos de software empresarial hechos a la medida.
Un mercado cada vez más exigente de productos de software de calidad hace que las compañías fabricantes de aplicaciones vean la forma de producir mejores productos, y la mejor forma de hacerlo es planear la calidad.
Objetivos de la calidad
El primer paso hacia la planeación de la calidad es establecer objetivos claros sobre la calidad. Eso significa analizar cuáles son los atributos o características que hacen del software un producto deseable por el usuario. Los usuarios valoran de forma diferente las características de calidad del software dependiendo del uso que le darán. Por ejemplo, los usuarios del software de control de tráfico aéreo valorarán más los atributos relacionados con la seguridad de los aviones, aunque su interfaz gráfica sea deficiente. Tomando en consideración lo que para el cliente es más importante, es posible enfocar los esfuerzos del proyecto desde la planeación.
Humphrey (2005), considera que los siguientes atributos constituyen la preocupación principal del usuario:
Plan de la calidad
El plan de calidad debe ser realizado con el apoyo del equipo de trabajo involucrado. TSP sugiere realizar los siguientes pasos en la elaboración del plan:
Haz clic en cada paso para conocer más detalle
Según Humphrey (2006), el aspecto más importante de este tipo de plan de calidad consiste en mostrar a los desarrolladores la cantidad de defectos que se pueden introducir y eliminar en un proyecto de software. Cuando los equipos de trabajo revisan este plan, por lo general se sorprenden de la cantidad de posibles errores que afectan la calidad del producto, y sobre todo de la cantidad de tiempo que le dedicarán a corregirlos. Esto hará conciencia en que realizar un buen trabajo durante las revisiones e inspecciones es mucho menos esfuerzo que corregirlos después.
11.3 Métodos de la gestión de la calidad
Dentro de la metodología TSP, existen los siguientes métodos para gestionar la calidad, que tienen por objetivo realizar acciones que permitan entregar el producto esperado por el cliente.
“Si no han planeado hacer un trabajo de calidad, probablemente no lo harán” (Humphrey, 2006).
Revisiones del plan de calidad
Los miembros del equipo de trabajo deben establecer un plan de calidad, por lo que es necesario que el coach del equipo se asegure de su existencia, que los miembros lo conocen y sobre todo que lo apliquen. Si es necesario, el coach debe solicitar explicaciones sobre cómo llegaron a generar el plan y cerciorarse que sus objetivos van encaminados hacia la calidad del software.
Los principales aspectos de revisión del plan de calidad deben ser los siguientes:
Por lo general, los equipos de trabajo no planifican suficiente tiempo para el diseño, para las revisiones de código y las inspecciones, por lo que el coach debe intervenir para realizar ajustes en beneficio de la calidad del software.
Revisiones del método de diseño
A diferencia del concepto de cero defectos en la industria de la manufactura, pocas veces los desarrolladores de software generan productos libres de errores, incluso los desarrolladores con amplia experiencia. Según Humphrey (2006), esto se debe principalmente a diseños inadecuados, ya que en muy pocas ocasiones se les dedica el tiempo y el esfuerzo para generar diseños detallados y exhaustivos, lo que provoca que inevitablemente se cometan errores sutiles y difíciles de encontrar. Una forma de guiar y controlar la calidad del diseño es definir métodos y estándares para el equipo de desarrollo. Estas normas del diseño deben ser aprendidas a través de un programa de entrenamiento para asegurarse que se entienden, se apliquen y se mantienen. Esto debe aplicar tanto para desarrollos grandes como pequeños.
Marco de referencia del diseño.
Recuperado de Humphrey, W. (2005). PSP(SM): A Self-Improvement Process for Software Engineers. EEUU: Pearson Education.
El proceso de diseño que todo profesional del software debe seguir, empieza por revisar el propósito del producto, recopilar información relevante, generar un diseño de alto nivel y finalmente, completar los detalles. Según Humphrey (2005), estos pasos no son tareas secuenciales independientes, sino que frecuentemente son actividades iterativas que se realizan en paralelo. Estos pasos deben seguirse independientemente del tamaño del software, en todo caso cualquier producto está conformado de pequeños programas, que si todos pasaron por este método de diseño, mejorarán sin lugar a duda el producto final.
Inspecciones
Las inspecciones del producto del software inician una vez que el desarrollador ha realizado algunas pruebas y removido errores obvios. Esta aclaración es importante, dado de que algunos desarrolladores desean omitir estas primeras pruebas confiando que todos los errores serán detectados por el área de pruebas, provocando alargar el periodo de pruebas, además que el área de testing puede pasar por alto errores que pueden llegar al cliente.
Las inspecciones deben realizarse por una persona independiente organizacionalmente del desarrollador (normalmente es el gerente de calidad) y debe cerciorarse que el desarrollador haya llevado a cabo el estándar de diseño de la organización, comprobar que haya realizado una revisión del diseño, registrado los defectos detectados en la fase de codificación, se haya apegado al estándar de codificación y documentación.
Perfiles de calidad y criterios de calidad
El perfil de calidad permite visualizar de una manera gráfica el cumplimiento de cinco criterios de calidad que son los siguientes:
Considera que en cada cálculo el resultado debe estar en un rango de 0.0 a 1.0 para poderse graficar de la siguiente forma:
Ejemplo del perfil de calidad de un programa.
Recuperado de Humphrey, W. (2006). TSP(SM) Coaching Development Teams. EEUU: Pearson Education.
Al graficar estos cinco criterios se obtiene un perfil de calidad del producto. Lo ideal es presentar una gráfica que toque la mayor cantidad de vértices del pentágono externo. Tener un buen perfil de calidad indica que es poco probable que el programa presente más defectos.
Humphrey (2005), calcula el índice de proceso de calidad (PQI: Process Quality Index) multiplicando cada uno de los valores obtenidos en la gráfica.
PQI = (calidad del diseño)*(calidad de la revisión del diseño)*(calidad de la revisión del código)*(calidad del código)*(calidad del programa)
El objetivo será acercar el valor PQI a 1.0.
En los ejemplos 5 y 6 se presentaron mayor cantidad de defectos después de realizar las pruebas unitarias.
Recuperado de Humphrey, W. (2005). PSP(SM): A Self-Improvement Process for Software Engineers. EEUU: Pearson Education.
Cierre
Un buen producto de software es aquel que hace lo que se espera de él cada vez que se utiliza, de manera consistente y sin errores. Es muy posible que sólo valores la calidad de un producto de software cuando has pasado por una mala experiencia. Es allí donde podemos comparar la calidad entre productos que son similares. Por ejemplo, cada vez que realizas un documento en Word como parte de alguna actividad de este curso, lo que esperas es que la aplicación funcione bien siempre y no pierda el trabajo al que le has dedicado algunas horas de tu valioso tiempo. Cuando funciona de una manera inesperada, te hace pensar si no hubiera sido mejor haber utilizado alguna otra aplicación.
La preocupación en la industria del software por la calidad se ve reflejada en la cantidad de estándares internacionales enfocados a este aspecto del software. Cada uno ofrece diversos lineamientos que pueden seguir las organizaciones en pro de la calidad, sobre todo para sistemas considerados como críticos para la seguridad de las personas. El camino hacia la generación de un producto de calidad no es sencillo, se requiere dedicar varias horas de análisis, establecimiento de métricas adecuadas, monitoreo del plan de calidad y el compromiso del equipo de desarrollo de enfocar todos sus esfuerzos por conseguir el mejor producto de software.
Checkpoint
Asegúrate de poder:
Referencias