Calidad del software. Factores y métricas. Estrategias de prueba.

Las posibilidades de que aparezca el fallo humano en el proceso de desarrollo de software son enormes.

Es complicado realizar un buen software, y muchos de los productos que se construyen tienen calidad insuficiente, además de no acertar con las estimaciones de tiempo y recursos inexactos para la construcción de los mismos.

Todos los métodos, herramientas y procedimientos que constituyen la Ingeniería del Software van orientados a un único fin: producir software de calidad.

En este tema introduciremos el concepto de calidad de software, primero a un nivel general como concepto y procesos a nivel de organización, viendo después cuáles son los factores que influyen en la calidad del software, cómo medirlos, y por último qué estrategias podemos utilizar para conseguir un software de mayor calidad.

Aunque en el siguiente apartado se trata de la calidad del software a nivel de empresa, haré referencia en el tema principalmente a calidad de software a nivel de proyecto (factores, métricas y estrategias)

IMPORTANCIA DE LA CALIDAD DEL SOFTWARE.

Las posibilidades de que aparezca el fallo humano en el proceso de desarrollo de software son enormes. Es complicado realizar un buen software, y muchos de los productos que se construyen tienen calidad insuficiente, además de no acertar con las estimaciones de tiempo y recursos inexactos para la construcción de los mismos.

Todos los métodos, herramientas y procedimientos que constituyen la Ingeniería del Software van orientados a un único fin: producir software de calidad.

En este tema introduciremos el concepto de calidad de software, primero a un nivel general como concepto y procesos a nivel de organización, viendo después cuáles son los factores que influyen en la calidad del software, cómo medirlos, y por último qué estrategias podemos utilizar para conseguir un software de mayor calidad.

Aunque en el siguiente apartado se trata de la calidad del software a nivel de empresa, haré referencia en el tema principalmente a al calidad de software a nivel de proyecto (factores, métricas y estrategias)

Calidad del software

La calidad del software es, según Pressman, la “concordancia con los requisitos funcionales y de rendimiento, con los estándares de desarrollo y con las características implícitas que se espera del software desarrollado profesionalmente”

No existe una definición única de calidad, ya que:

• Es un concepto relativo (es una compleja mezcla de factores que varía para las diferentes aplicaciones y los clientes que las solicitan).
• Es un concepto multidimensional, referido a muchas cualidades.
• Está ligada a restricciones (por ejemplo, el presupuesto).
• Está ligada a compromisos aceptables (por ejemplo, plazos de fabricación).
• No es ni totalmente subjetiva ni objetiva.

Puede resultar transparente cuando está presente y reconocible cuando está ausente.

Actualmente, la calidad del SW debe tenerse en cuenta a dos niveles:

• A nivel de empresa: para conseguir software de calidad, las organizaciones deben tener una estructura organizativa apropiada para fomentar el trabajo por la calidad de todas las personas y departamentos de la empresa, además de fomentar procesos específicos para asegurar la calidad.

• A nivel de proyecto: se trata de llevar a la práctica en las actividades cotidianas las disposiciones fijadas en el sistema de calidad. Se aplica durante todo el proceso de ingeniería del software, es decir, en Análisis, Diseño, Codificación y Prueba.

En el resto del apartado vamos a ver los conceptos de calidad a nivel de empresa; en el resto del tema profundizaremos en la calidad a nivel de proyecto.

Calidad del software a nivel de empresa

La calidad del software a nivel de empresa se refiere a las acciones que se tomas de forma común para asegurar que se desarrolla software de calidad en todos los proyectos. Se divide en dos tipos de procesos:

• Gestión de la Calidad del SW: aspecto de la función general de la gestión que determina y aplica la política de calidad (objetivos y directrices generales de calidad de una empresa). Incluye planificación estratégica, asignación de recursos, etc.

• Aseguramiento o garantía de la Calidad del SW: conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto satisfará los requisitos dados de calidad. Incluye evaluaciones, auditorías, revisiones, etc.

Estándares de Calidad para el desarrollo de Software.

Los estándares de calidad de software son normas emitidas por organismos específicos, que sirven para sentar un marco con el que comparar si un proceso de desarrollo es o no de calidad. Las normas de calidad del software más conocidas han sido desarrolladas por ISO, y son la serie ISO-9000.

ISO 9000

Las normas ISO-9000 son un estándar de calidad para todo tipo de industrias. Contiene una normativa específica para el desarrollo de software, la ISO-9003. Consiste en una serie de cláusulas que deben aplicarse en el marco de trabajo, en el ciclo de vida del proyecto y en las actividades de apoyo al mismo.

La aplicación de las normas ISO en un proyecto ha de demostrarse mediante una evaluación formal por un organismo competente.

Las normas ISO tienen sin embargo ciertos inconvenientes:

• Son estáticas, de escaso valor, lentas y muy caras
• No está plenamente orientado al software.
• En muchos casos se ha adoptado por obligación y para “cubrir el expediente” , lo que no mejora demasiado la calidad.

Marcos de trabajo de calidad del software.

Los marcos de trabajo recogen una serie de metas y procesos comunes que debe cumplir una organización. A diferencia de los estándares, dicen qué se debe hacer a nivel general, no cómo. Por ejemplo, una directiva de un marco de trabajo (simplificada) sería: “se prueban las aplicaciones antes de entregarlas”

CMMI

CMM fue desarrollado por el Software Engineering Institute en estados unidos, y sirve para comprobar la habilidad de los procesos de las organizaciones para realizar determinados proyectos. Se desarrolló a petición del departamento de defensa de USA, y servía para evaluar a sus proveedores.

Dado que CMM se comenzó a utilizar para medir la capacidad de otras áreas distintas al desarrollo de software, evolucionó a la versión CMMI, más general.

CMMI clasifica el grado de madurez de las empresas en cinco niveles: desde 1-caótico hasta 5-optimizado

SPICE

SPCE es el modelo de madurez propuesto por ISO, similar a CMMI. Clasifica las organizaciones en seis niveles de madurez, desde 0-incompleto hasta 5-optimizado.

Factores de calidad del software.

Los factores de calidad del software sirven para descomponer el concepto genérico de “calidad” en otros más sencillos, para facilitar su control y su medición.

Dado que la división en factores es una división subjetiva, existen varias clasificaciones de los factores de calidad. Veremos la de McCall, que los agrupa en tres perspectivas: operativa, de mantenimiento y evolutiva.

Factores operativos de la calidad del software.

Los factores operativos son aquellos que afectan al uso del software:

• Corrección: el software cumple las especificaciones
• Fiabilidad: grado en el que el software es confiable, es decir, no tiene fallos
• Eficiencia: necesidad de recursos software y hardware del producto
• Seguridad: grado en el que puede controlarse el acceso al software y a los datos
• Facilidad de uso: grado de esfuerzo necesario para utilizar el software

Factores de mantenimiento de la calidad del software.

Los factores de mantenimiento son aquellos que se aplican a la capacidad de modificación del software:

• Flexibilidad: esfuerzo necesario para modificar un programa
• Facilidad de prueba: esfuerzo requerido para realizar las pruebas de un programa
• Facilidad de mantenimiento: esfuerzo requerido para localizar y reparar un error

Factores evolutivos

Los factores evolutivos son aquellos que indican si el software se puede trasladar con facilidad a otra máquina o a otro producto de base (SO, SGBD, etc.), o incrementar sus prestaciones:

• Portabilidad: facilidad para migrar el software de un entorno de operación a otro
• Capacidad de reutilización: grado en el que un programa o parte del mismo se puede utilizar en otras aplicaciones.
• Capacidad de interoperación: esfuerzo necesario para que un software opere conjuntamente con otros sistemas

Métricas para medir la calidad del software.

Las métricas del software se aplican para valorar cualitativamente algún factor relativo al mismo. No existen métricas generales y únicas, aún menos para la calidad, ya que se puede examinar el software a través de múltiples perspectivas y con diferentes objetivos.

En lo que sí que hay acuerdo es en las características que debe tener una buena métrica :

• Simple y fácil de calcular
• Empírica
• Consistente y objetiva
• Independiente del lenguaje de programación
• Que proporcione información útil

Veremos las más representativas en cada fase del ciclo de vida.

Fase de análisis

No existen demasiadas métricas en esta etapa debido a que se están tratando temas de muy alto nivel conceptual, difíciles de cuantificar. Las más representativas miden el tamaño del software a desarrollar:

Punto función

Sirve para cuantificar la cantidad de funcionalidad que tiene un sistema a partir de la descripción del mismo. Se basa en la ponderación de cinco elementos clave:

1.Entradas de usuario.
2.Salidas de usuario.
3.Peticiones.
4.Archivos.
5.Interfaces externas.

Métrica bang

Esta métrica, propuesta por DeMarco, sirve para calcular el tamaño del software a desarrollar a partir del modelo de análisis.

Métrica de calidad de especificación

Propuesta por Pressman, mide la calidad del análisis y de los requisitos capturados. A pesar de medir factores cualitativos, propone métricas como por ejemplo el número de requisitos donde los revisores han interpretado lo mismo.

Fase de diseño

Trabajan frecuentemente con parámetros típicos de la estructura de los programas (métricas morfológicas) o con medidas del grado de cohesión, acoplamiento y complejidad de los algoritmos. Estas métricas son de caja negra en el sentido que no requieren ningún conocimiento del trabajo interno de un módulo en particular del sistema.

Algunas de ellas son:

Métrica de complejidad de Card y Glass

Esta métrica se basa en dos factores, calculados para cada módulo a partir del diagrama de estructuras:

• Complejidad estructural: número de módulos que controla un módulo dado
• Complejidad de datos: suma de variables de entrada y salida de un módulo (dividido por el número de módulos que controla, para que no influya la complejidad estructural)

La complejidad del sistema se calcula como la suma de la complejidad estructural y la complejidad de datos de cada módulo

Métrica de cohesión y acoplamiento

Estas métricas sirven para cuantificar la cohesión y acoplamiento de los módulos en programación estructurada. A partir de los parámetros de entrada, los parámetros de salida, las variables globales utilizadas y el fan-in y fan-out de los módulos, genera un valor que es menor cuanto mejores son la cohesión y el acoplamiento.

Métricas orientadas a objetos

Las técnicas estructuradas no se aplican fácilmente en la POO. Para ello, se han diseñado otras métricas basadas en clases, no en módulos, que dan una idea

Profundidad árbol de herencia

Esta métrica se basa en la media de profundidad de la jerarquía de herencias: cuanto mayor es la profundidad, menor es la calidad del software

Número de hijos

Cuanto mayor es la media de clases derivadas de otra en la jerarquía de herencias, más probabilidades hay de que se haya realizado un mal diseño

Acoplamiento entre clases

Cuanto más clases se relacionen entre sí para realizar una función, mayor será el acoplamiento y menor la calidad del software.

Fase de codificación

Las métricas de la fase de codificación intentan dar una medida de la complejidad del software construido. Algunas de ellas son las siguientes:

Complejidad ciclomática y esencial

Las métricas de complejidad ciclomática y esencial fueron desarrolladas por McCabe para medir la complejidad lógica de un programa. Se basan en pintar el flujo de control como un grafo, donde los nodos son instrucciones y están conectadas si una se puede ejecutar después de otra.

La complejidad ciclomática mide el número de ciclos que existen en el grafo de control. La complejidad esencial, el máximo número de anidamiento de estructuras de control.

Métricas orientadas a objetos

En programación orientada a objetos, además de las métricas de programación estructurada pueden utilizarse otras como el número de métodos de la clase, el número de métodos que pueden invocarse desde otras clases, o la cohesión entre los métodos de la clase.

Estrategias de prueba del software.

Las pruebas son un método para determinar si el sistema funciona correctamente. Si examinamos un ciclo de vida en V, se puede ver que existen diferentes niveles de prueba, en base a la etapa de desarrollo que se deba probar: desde las de validación, que prueban que el sistema se comporta como se esperaba (alto nivel conceptual) a las unitarias, que prueban que una codificación cumple las especificaciones (bajo nivel conceptual):

Para realizar unas pruebas correctas de un sistema, estas deben planificarse en cada uno de estos niveles. Al proceso de planificación, documentación y realización de pruebas se le denomina ciclo de pruebas. Las pruebas de cada uno de los niveles se denominan pasos de pruebas, y a la documentación de las mismas, registro de pruebas.

El ciclo de pruebas debe adaptarse al paradigmas de ciclo de vida (espiral, prototipado, etc.) aunque aquí se haya dibujado el ciclo en V para mayor claridad.

A continuación se expone la función y técnicas principales de cada uno de los niveles de pruebas

Unitarias

Las pruebas unitarias se centran en comprobar la funcionalidad de los componentes individuales (módulo, clase, función, etc.). ya que si los componentes no funcionan de forma aislada, no podrán funcionar conjuntamente con otros.

Las técnicas que más se utilizan son las de caja blanca, entre ellas:

• Prueba del camino básico
• Prueba de cobertura de condiciones

Y algunas de caja negra como:

• Hipótesis de error
• Clases de equivalencia
• Valores límite.

De integración

Una vez que cada componente funciona de manera correcta se debe pasar a comprobar el funcionamiento conjunto de todos ellos. Para ello, se pueden seguir diferentes estrategias de integración

Integración súbita

La integración súbita consiste en juntar de una sola vez todos los módulos y realizar las pruebas. Es adecuada cuando hay pocos niveles de integración, si no, retrasan la detección de errores. Con las herramientas de pruebas automáticas de los modernos frameworks de programación, esto no resulta tan descabellado.

Integración ascendente

En la integración ascendente, se crean primero los componentes de más bajo nivel, creando componentes ficticios para simular las llamadas a esos módulos. Cuando están listos, se prueba el nivel superior, y así sucesivamente

Integración descendente

Es el caso contrario: se empieza desde el nivel superior y se simulan los valores devueltos por los otros módulos. Permite comprobar el diseño correcto de los interfaces desde el principio.

De validación

Una vez probado el funcionamiento correcto de los módulos de forma continua, debe comprobarse que el sistema realiza aquello para lo que fue diseñado: este es el objetivo de las pruebas de validación.

Estas pruebas son realizadas por el usuario del sistema y diseñadas por él, con ayuda del equipo de desarrollo. Son pruebas de caja negra en las que el usuario realiza casos de prueba que emulan las funciones que realizará luego el sistema.

Existen dos tipos de prueba de validación: las pruebas alfa, que se realizan por un cliente en el lugar de desarrollo, y las pruebas beta, que se realizan en un entorno del software en el que trabajan los usuarios que informan de los problemas encontrados.

De sistema

Las pruebas de sistema se realizan sobre el sistema completo, para comprobar la integración del mismo con otros subsistemas y también, algunos aspectos del mismo que sólo se pueden comprobar de forma global. Algunas de ellas son:

• Pruebas de rendimiento
• Pruebas de seguridad
• Pruebas de recuperación
• Pruebas de interface

Conclusiones

Conseguir software de calidad es algo muy complejo que implica no sólo una alta calificación de los profesionales encargados del desarrollo, sino de la existencia de procesos en la empresa que realiza el software encargados de una gestión integral de la calidad, desde la concepción del producto hasta el mantenimiento del mismo.

Dado lo amplio del concepto, deberemos enseñárselo a nuestros alumnos desde una perspectiva más práctica, cercana, y orientada a los procesos de prueba y a la integración de los mismos en el ciclo de desarrollo. Será de mucha más utilidad centrarse en estrategias y técnicas de pruebas concretas antes que entrar en las profundidades conceptuales de CMMI, por ejemplo.

Así, en los módulos de ASI más orientados al desarrollo, y en la mayoría de los de DAI, sería interesante incluir las estrategias de prueba en las programaciones ya que no sólo lo indica así el currículum sino que enseñará a los alumnos a realizar mejor los diseños de software.

ASI - Administración de Sistemas Informáticos
Curso Módulo
1 Fundamentos de programación
2 Implantación de aplicaciones informáticas de gestión

DAI - Desarrollo de Aplicaciones Informáticas
Curso Módulo
1 Análisis y diseño detallado de aplicaciones informáticas de gestión
1 Programación en lenguajes estructurados
2 Desarrollo de aplicaciones en entornos de cuarta generación y con herramientas CASE
2 Diseño y realización de servicios de presentación en entornos gráficos

SMR - Sistemas Microinformáticos y Redes
Curso Módulo
Sistemas operativos monopuesto
Aplicaciones ofimáticas.
Sistemas operativos en red.
Redes locales.
Seguridad informática.
Servicios en red.

Bibliografía

• Roger S. Pressman. Ingeniería del Software. Un enfoque práctico.

Si te ha gustado esta entrada, suscríbete para recibir las próximas entradas por correo electrónico. Por favor, apoya este blog.