CRITERIOS DE CALIDAD PARA LOS PRODUCTOS

En las etapas iniciales del ciclo de vida de la adquisición, se deben especificar los atributos de calidad que debe satisfacer el producto a desarrollar, dado que mediante esta especificación se puede comunicar a otros (por ejemplo, al equipo desarrollador) bajo qué atributos y valores de cada uno de ellos se considerará que el producto final es de calidad. Lo anterior significa que es necesario documentar los atributos de calidad del producto y asignarle a cada uno de ellos un valor o rango de valores aceptables [34]. Dicha especificación o definición de los atributos de calidad debe ser expresada cuantitativamente [34].

Para la implementación de un producto, se seleccionan los atributos más significativos para los usuarios, se le asignan valores de acuerdo a las necesidades de los mismos usuarios, y entonces se evalúa o mide la calidad del producto o el grado de satisfacción del criterio [34].

Las técnicas de comprobación de la calidad de los productos, se pueden dividir en dos conjuntos [8]:

• Métodos objetivos, donde después de su aplicación se puede obtener como resultado un “Si” o un “No” a la pregunta de si el producto es de calidad. Ejemplos de este tipo de técnicas son los medidores, pruebas y listas de comprobación.

• Métodos subjetivos, donde el criterio involucra juicios u opinión. Estos métodos se utilizan para validar aspectos como la usabilidad del producto, y la conformidad con la estrategia del negocio.

Como se ha mencionado en secciones anteriores, el aseguramiento de la calidad define el marco de trabajo para lograr la calidad en el desarrollo de productos software, lo cual se consigue mediante la definición o selección de estándares aplicables tanto al proceso como al producto [17].

A continuación se presentan algunas consideraciones para algunos productos específicos generados en distintas etapas del proceso.

2.7.1. Calidad de la documentación

El estándar ISO/IEC 12207:2008 [38] recomienda para la validación de la documentación, los siguientes criterios:

• La documentación es adecuada, completa y consistente.

• La preparación de la documentación se realiza a tiempo.

• La gestión de configuración de los documentos sigue procedimientos especificados.

Entre los estándares a aplicar a los productos se encuentran [17]: Estándares de documentos, Estándares de documentación, y Estándares de codificación.

68

Los estándares de documentación incluyen [17]:

• Estándar del proceso de documentación, es decir, la definición de los pasos a seguir para producir un documento.

• Estándar del documento, el cual define la estructura y presentación de los documentos.

• Estándar de intercambio de documentos, cuyo objetivo es asegurar que todas las copias electrónicas sean compatibles.

Algunos ejemplos de artefactos que ayudan a estandarizar los productos son [17]:

• Formulario para revisión del diseño.

• Estructura de la especificación de requisitos de software.

• Definición del estilo de programación.

• Formato del plan de proyecto.

• Formulario de petición de cambios.

2.7.2. Calidad de los Requisitos

Un error común en organizaciones desarrolladoras de software de tamaño mediano y pequeño, es incorporar las actividades de aseguramiento de la calidad, después de haber determinado los requisitos. El problema de esta estrategia es que el personal de aseguramiento de la calidad, no cuenta con requisitos adecuados contra los cuales verificar si la aplicación o sus componentes están bien desarrollados [12].

El estándar ISO/IEC 12207:2008 [38] recomienda para la validación de los requisitos, los siguientes criterios:

• Los requisitos del sistema son coherentes, factibles y verificables.

• Los requisitos del sistema han sido asignados adecuadamente a los elementos de hardware, elementos software y manual de operaciones de acuerdo a los criterios de diseño.

• Los requisitos de software son coherentes, factibles, comprobables y reflejan con precisión los requisitos de sistema.

• Los requisitos de software relacionados con la seguridad y criticidad son correctos como lo demuestran adecuadamente métodos rigurosos.

El aseguramiento de la calidad de los requisitos debería incorporar medidas para determinar [12]:

• Cómo de bien están escritos los requisitos.

• Efectividad de la inspección de requisitos.

• Efectividad del proceso de análisis de requisitos.

69

Se sugiere el uso de una tabla [12], cuyas filas representen cada requisito, y las columnas las características deseadas en cada uno de ellos. En las intersecciones irían los comentarios o resultados del análisis de una característica particular, para un requisito particular. Las columnas podrían ser:

• Trazable hacia atrás (relación del requisito con activos previamente desarrollados). • Completo. • Consistente. • Factible. • No ambiguo. • Claro. • Preciso. • Modificable. • Comprobable.

• Trazable hacia adelante (relación del requisito con activos desarrollados con posterioridad).

También, antes de formalizar el compromiso entre la organización que adquiere el producto de software y el proveedor, se deben revisar los requisitos para asegurarse que [49]:

• Están definidos los requisitos del producto.

• Se han resuelto las diferencias entre los requisitos del contrato y los expresados previamente.

• El proveedor tiene la capacidad de cumplir los requisitos pedidos.

2.7.3. Calidad de la arquitectura o diseño de alto nivel

Además de revisar la arquitectura, el personal de aseguramiento de la calidad debe desarrollar los planes de prueba de cada componente de la misma [12]. Se debe asegurar que la elección de la arquitectura, se realice después de analizar varias alternativas. Para comparar la calidad de estas arquitecturas alternativas, se sugiere ponderar los atributos requeridos, y asignar un calificador a cada arquitectura candidata. Se sugiere el uso de una tabla [12], donde cada columna representa una arquitectura posible, y cada fila contenga los atributos deseados. Las entradas de la tabla almacenan el calificador de un atributo particular, para una arquitectura candidata dada. Las filas serían:

• Extensión.

• Cambio.

• Sencillez.

• Rapidez.

70 Las métricas aplicables al diseño incluyen [12]:

• Número de entradas y salidas de cada módulo o paquete.

• Complejidad de la arquitectura (en base a teoría de grafos).

• Complejidad del flujo de información o datos.

2.7.4. Calidad del diseño detallado

El estándar ISO/IEC 12207:2008 [38] recomienda para la validación del diseño, los siguientes criterios:

• El diseño es correcto y coherente con la trazabilidad de los requisitos.

• El diseño implementa la secuencia correcta de eventos, entradas, salidas, interfaces, flujo lógico, asignación del calendario y costes, y definición, aislamiento y recuperación de errores.

• El diseño seleccionado puede ser derivado a partir de los requisitos.

• El diseño implementa correctamente la seguridad y otros requisitos críticos y es demostrable a través de métodos rigurosos.

La inspección del diseño debe incorporar [12]:

• Preparar el registro de métricas.

• Asegurar que cada módulo de la arquitectura se expande.

• Asegurar que cada detalle es parte de la arquitectura.

• Asegurar que el diseño cumple las funciones requeridas.

• Asegurar que el diseño está completo.

• Asegurar que el diseño se puede probar.

• Verificar que el diseño sea sencillo, general, expandible, eficiente y portátil (usualmente se deben realizar negociaciones entre éstos).

• Asegurar que se proporcionan todos los detalles.

2.7.5. Calidad del Código

Braude [12] define un código de calidad como aquél que cumple con las siguientes afirmaciones:

• Satisface los requisitos establecidos.

• Verifica sus entradas y reacciona de manera predecible ante entradas ilegales.

• Ha sido inspeccionado íntegramente por ingenieros que no son los autores.

• Ha sido probado en varias formas independientes, de manera exhaustiva.

• Está bien documentado.

• Posee una tasa de defectos confiable y conocida. A la hora de inspeccionar código, se sugiere determinar:

• Si el código es consistente con el diseño.

• Si el código supone sólo las precondiciones establecidas.

71

• Si todos los ciclos tienen una finalización.

• Si se respetaron los estándares de notación.

• Si se verificó exhaustivamente cada línea de código.

• Si el código considera parámetros ilegales.

• Si el código retorna los tipos de datos correctos.

• Si el código está bien comentado.

Las sugerencias anteriores son una adaptación de la propuesta presentada por Braude [12].

El estándar ISO/IEC 12207:2008 [38] recomienda para la validación del diseño, los siguientes criterios:

• El código es trazable al diseño y requisitos, es comprobable, correcto y cumple con los requisitos y estándares de documentación.

• El código implementa la secuencia correcta de eventos, interfaces consistentes, datos correctos y control de flujo, una apropiada asignación del calendario y de costes, y la definición, aislamiento y recuperación de errores.

• El código seleccionado puede ser derivado desde el diseño o los requisitos.

• El código implementa correctamente la seguridad y otros requisitos críticos y es demostrable a través de métodos rigurosos.

Las métricas para el código fuente consideran entre otras [12]:

• Cantidad de líneas de código.

• Longitud estimada del programa (Halstead).

• Dificultad del programa (Halstead).

• Complejidad ciclomática.

A la hora de inspeccionar el código, se debe informar de los siguientes tipos de errores [12]:

• Problemas de lógica.

• Problemas de cálculo.

• Problemas de interfaz.

• Problemas de manejo de datos.

• Cumplimiento de estándares de codificación.

• Documentación.