Explicación

15.1 Gestión de la calidad de software

La gestión o administración de la calidad se encarga del aseguramiento de la calidad o Quality Assurance (QA), que define procesos y estándares que conducirán a obtener un producto de alta calidad.

Según Sommerville (2011), el objetivo de la gestión de la calidad es proporcionar una comprobación independiente sobre el proceso de desarrollo de software. Este autor hace hincapié en dos características fundamentales, la primera es sobre la necesidad tener un equipo de QA que sea independiente de la parte operativa del software, para evitar estar comprometido con el cumplimiento de la fecha de entrega, limitar el número de observaciones o ser tentado a omitir el reporte de errores que pudieran retrasar el proyecto. La segunda característica es crear una cultura de calidad y que no sólo se limite a seguir los estándares y procedimientos. Esta cultura impulsa el comportamiento profesional de los miembros del equipo, haciendo que todos se sientan responsables de la calidad del producto, además que es la mejor forma de incorporar aspectos intangibles de la calidad, como la elegancia y la legibilidad del software, y es el mejor camino para implementar planes de mejora continua.
En el siguiente diagrama, Sommerville (2011) muestra cómo se relaciona el proceso de desarrollo y el proceso de gestión de la calidad.

Gestión de calidad y desarrollo de software.
Recuperado de Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson Educación.

Gestión de la calidad según el tamaño del equipo de trabajo

En equipos de desarrollo grandes es necesaria la gestión de la calidad formalizada, enfocada a la documentación de las actividades que cada grupo ha realizado. Esta documentación servirá para mantener un registro histórico y es un medio de comunicación entre los grupos de desarrollo. En la opinión de Sommerville (2011) esto ayuda a comprobar que no se olvidaron tareas importantes o que un grupo no hizo suposiciones incorrectas acerca de lo que hicieron otros grupos. Cuando los equipos de desarrollo son pequeños es posible implementar un enfoque informal de calidad, sin demasiada documentación, ya que la comunicación es más directa. El éxito en estos grupos radica en la implantación de una cultura de calidad.

15.2 Gestión de defectos

Los defectos en el software tienen un impacto directo en el desempeño del software y por consecuencia en la calidad del producto entregado al cliente. El origen de algunos defectos que pasaron por alto durante las pruebas (revisiones, inspecciones y auditorías) es diverso, y en este sentido Chemuturi (2010) nos propone el siguiente listado:

Origen del defecto	Observaciones
Codificación	El defecto proviene de la fase de construcción del software.
Análisis de requerimientos	El defecto surgió debido a un error en la etapa de la ingeniería de requerimientos.
Diseño del software	El defecto surgió debido a un error en la etapa de diseño y arquitectura del software.
Documentación	El defecto surgió debido a un error en la preparación de la documentación.

Para darte una idea de la cantidad de defectos que se esconden, Humphrey (2005) propone la siguiente estimación sobre la tasa de defectos según su origen, por puntos de función y por miles de líneas de código.

Origen	Defectos/Puntos de función	Defectos/KLOC
Requerimientos	0.23	2.3
Diseño	0.19	1.9
Codificación	0.09	0.9
Documentación	0.12	1.2
Soluciones defectuosas	0.12	1.2
Total	0.75	7.5

Los defectos deben ser detectados haciendo uso de una metodología adecuada que los registre y los elimine del producto antes de que lleguen a manos del cliente.

Reporteo de defectos

Los defectos pueden aparecer durante las actividades de verificación y validación del software, y en cualquier etapa del desarrollo del mismo; no necesariamente durante la etapa de pruebas, por lo que es importante establecer un procedimiento de registro y seguimiento hasta su resolución. Cada proyecto de desarrollo debe tener sólo una herramienta de registro que concentre la gestión de defectos, eso facilitará el análisis estadístico posterior. Ten en cuenta que el registro de estos defectos es diferente a los defectos detectados durante la fase de pruebas, ya que su objetivo es registrar defectos que no fueron oportunamente encontrados. El proceso que debe seguir la gestión de defectos se describe en los siguientes pasos:

Paso 1. Se detecta un defecto en alguna actividad de aseguramiento de la calidad.

Paso 2. La persona que detecta el error registra el defecto en un formulario predeterminado.

Paso 3. Se realiza un análisis del defecto en el que se replica el escenario, para confirmar que efectivamente es un error, de lo contrario se cierra el defecto. Se determina su categoría, origen, se estima el esfuerzo, impacto en costo y tiempo para el proyecto. Toda esta información se incorpora al registro del defecto.

Paso 4. Se asigna el reporte a la persona que implementará la solución.

Paso 5. El ingeniero asignado realiza la corrección y reporta los detalles de la solución en el reporte.

Paso 6. Otra persona realiza una revisión para asegurar que el defecto efectivamente haya sido corregido. De lo contrario se regresará a la persona asignada.

Paso 7. Se asigna una persona para realizar pruebas de regresión, que aseguran que no existan más errores al resto del producto del software.

Paso 8. Si el defecto fue detectado durante el proceso de desarrollo, se cierra el reporte. Si el defecto ya fue entregado al cliente se procederá a realizar una prueba de aceptación, para finalmente cerrar el reporte; registrando las acciones realizadas.

Recuperado de Chemuturi, M. (2010). Mastering Software Quality Assurance. EEUU: J. Ross Publishing

La herramienta de registro de defectos debe ofrecer los siguientes campos:

Campo	Descripción
Número del defecto	Es un identificador único e irrepetible de cada defecto. Puede ser numérico o una combinación de letras y números, según la preferencia de la organización. Es preferible que este dato sea generado de forma automática.
Fecha/Hora de registro	Fecha y hora en la que se está registrando. Debe ser un dato automático no editable.
Descripción del defecto	Descripción detallada del defecto.
Reportado por	Nombre de la persona que está registrando el defecto.
Fase del desarrollo	Se coloca la fase del desarrollo de sistemas en la que se descubrió el defecto. Recuerda que se puede reportar un defecto en cualquier momento del desarrollo del sistema: análisis, diseño, construcción, planeación de pruebas, implementación, soporte (se excluye la fase de pruebas).
Actividad de QA	Actividad del aseguramiento de calidad en la que se detectó el defecto: revisión, inspección, auditoría.
Componente afectado	Nombre del componente del sistema en el que se detectó el defecto, puede estar relacionado a cualquier artefacto del desarrollo: documento o código.
Tipo de componente	El tipo de componente puede ser una pantalla, un reporte, un documento de requerimientos, el documento de diseño y arquitectura, un stored procedure, etc.
Tamaño del componente	El tamaño del componente puede ser expresado en número de páginas cuando es un documento, número de líneas de código cuando es un programa, o bien cantidad de puntos de función.
Analizado por	Nombre de la persona que analizó el defecto detectado.
Fecha de inicio y fecha de fin de análisis	Fechas en la que inició y terminó el análisis.
Solucionado por	Nombre de la persona que resolvió el defecto.
Fecha de inicio y fecha de fin de la solución	Periodo de tiempo que comprendió la solución del defecto.
Revisado por	Nombre de la persona que revisó que la solución haya corregido el defecto.
Fecha de inicio y fecha de fin de la revisión	Periodo de tiempo que comprendió la revisión del defecto.
Prueba de regresión realizada por	Nombre de la persona que realizó la prueba de regresión.
Fecha de inicio y fecha de fin de la regresión	Periodo de tiempo que comprendió la regresión de la solución del defecto.
Estatus	Estatus del defecto: abierto o cerrado. El defecto se cierra cuando ha pasado por el análisis, la revisión y la regresión de forma exitosa.
Categoría del defecto	La organización puede determinar las categorías de los defectos que servirán para agrupar defectos que tengan relación.
Origen del defecto	Se registra la etapa del proceso de desarrollo a la que se le atribuye el defecto.
Fecha de la prueba de aceptación	Fecha en la que se probó con el cliente. Este dato se registra si el software ya fue entregado al cliente.
Entregado el	Fecha de la versión en la que se entregó al cliente.

El éxito en la gestión de defectos es la constancia y consistencia. Cualquier defecto que no haya sido oportunamente detectado se debe registrar y solucionar, y se debe seguir un estándar al registrar el defecto. Los registros deben mantenerse como histórico para cualquier análisis posterior o comparativo.

15.3 Cultura de calidad

Seguramente has escuchado la frase “la calidad no sucede por accidente”, y es totalmente cierta cuando se trata del software, la calidad es el resultado del esfuerzo consciente del equipo de desarrollo.

El primer paso para asegurar la calidad de cualquier cosa es reconocer que la propia calidad es la clave de la verdadera satisfacción de los clientes y de la supervivencia de una organización”(Chemuturi, 2010).

Según Chemuturi (2010), para implementar una cultura de calidad en la organización se debe considerar lo siguiente:

Instaurar un departamento de calidad, encargado de las actividades de QA (Quality Assurance).
Definir un proceso de desarrollo de software enfocado en la calidad, que además incluya actividades relacionadas con el aseguramiento de la calidad y la mejora continua.
Un sistema que reconozca y premie el logro de la excelencia en calidad.
El compromiso e involucramiento de la alta dirección es fomentar la cultura de calidad en toda la organización.

Departamento independiente de QA

Es común que las organizaciones dedicadas al desarrollo de software consideren que el departamento de QA sea el encargado de realizar las pruebas al software, limitando su campo de acción a la verificación del código del sistema. El problema de este enfoque es que asegurar la calidad sólo por las pruebas al código no da garantías de poder mejorar el producto. Este departamento debe estar enfocado en dos aspectos fundamentales: la calidad de los procesos y calidad del producto, eso incluye funciones de la verificación, validación, monitoreo, control y mejora continua.

Los beneficios de tener un departamento de QA son los siguientes:

Los desarrolladores pueden recurrir a esta entidad para consultar temas de calidad y hacer sugerencias de cambios.
Las actividades relacionadas con el aseguramiento de la calidad no se diluyen con otras responsabilidades operativas.
Los esfuerzos por mantener una filosofía de cero defectos y hacerlo bien la primera vez se concentran en un área y permite vigilar la productividad de todas las áreas que intervienen en el proceso de desarrollo en su conjunto en lugar de tener esfuerzos aislados.
Las metas de calidad y umbrales de control de procesos son establecidos por un área independiente, lo que garantiza su imparcialidad.

La efectividad de las acciones que emprenda el departamento de QA dependerá de su independencia organizacional de las áreas operativas de desarrollo. Para ello debe reportar directamente al director general de la empresa. Si el departamento de QA depende de la gerencia de sistemas podrían surgir conflictos de interés.

Definición de un proceso de desarrollo y mejora continua

Las organizaciones de software deben establecer una definición inicial del proceso de desarrollo que incluya la identificación de las personas que documentarán los procesos, facilitándoles las herramientas necesarias para crear, pilotear y desplegar artefactos que consideren necesarios.

Este proceso debe ser conocido y utilizado por toda la organización como un estándar, siendo la base sobre la que se realizarán auditorías y evaluaciones de cumplimiento. Al mismo tiempo el proceso debe establecer formas en las que se puedan manejar excepciones con las adecuadas aprobaciones, que servirán de válvula de escape para todas aquellas situaciones que no sean incluidas en la definición del proceso.

En la misma definición del proceso se incluyen las métricas e indicadores de desempeño que servirán para controlar las tareas del proceso y obtener información valiosa para identificar áreas de oportunidad que generen planes de mejora.

Es notorio cuando una organización mantiene una cultura de calidad. El personal que participa en el proceso reconoce su propia aportación a la calidad, los beneficios de seguir el proceso, las métricas que debe vigilar y la apertura que existe para implementar cambios.

Un sistema que reconozca y premie el logro de la excelencia en calidad.

Cualquier empresa tiene el reto de mantener motivado a su personal para lograr un desempeño excepcional de sus miembros. Para hacerlo, Chemuturi (2010) propone un sistema de premios y reconocimientos con las siguientes características:

Debe ser un mecanismo formal utilizado por la organización para reconocer y premiar el esfuerzo por mejorar la calidad.
Debe basarse en los resultados obtenidos a través de una medición sistemática.
Las ocasiones para entregar premios y reconocimientos deben ser calendarizados periódicamente y no ser sólo sucesos eventuales.
Para mantener motivado a todo el equipo es necesario reconocer por separado a los miembros que constantemente son premiados por su excelente actuación, dando así la oportunidad al resto de los miembros a que también sean reconocidos.
La cantidad de premios y reconocimientos debe ser adecuada, según la cantidad de miembros del equipo, dando esperanza a todos los miembros de poder ser reconocidos. El sistema debe enfocarse en el reconocimiento más que en el valor material.

Compromiso e involucramiento de la alta dirección

El involucramiento y compromiso de la alta dirección por mantener los esfuerzos de la calidad son esenciales en cualquier organización. Los directores y gerentes deben realizar lo siguiente:

Ser los primeros en reconocer los beneficios de la calidad y fomentar la cultura por la calidad.
Involucrarse en la conformación de una política de calidad que exprese las normas y conductas esperadas por los miembros del equipo.
Estar al tanto de los resultados obtenidos por el equipo de trabajo en relación a productos que excedan las expectativas de sus clientes.
Solucionar conflictos entre el departamento de QA y los departamentos operativos, sobre todo en aplicar recomendaciones de mejoras al proceso de desarrollo.
Establecer un presupuesto para los gastos justificados en relación a las actividades del aseguramiento de la calidad.

Estas acciones ayudan a generar un ambiente propicio para que la organización trabaje a favor de la calidad del producto de software, incremente la productividad, elimine el retrabajo, reduzca costos, mejore la satisfacción de los clientes y sobre todo, incremente las ganancias.