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

De MediaWiki
Ir a la navegación Ir a la búsqueda

Introducción

Calidad del software

Concepto de calidad

La definición oficial, y más completa, es la de la norma ISO 8402, que define la calidad, en general, como: "Totalidad de características de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades expresadas o implícitas". Por tanto, tenemos que tener claro que la calidad es multidimensional, y no se trata de un concepto absoluto, ya que el consumidor la juzga con todo relativismo.

Calidad en la ingeniería del software

Para entender el concepto de calidad aplicado al software, podemos apoyarnos en la definición oficial del estándar IEEE Std.610-1990, el cual define la calidad del software como el grado con el que un sistema, componente o proceso cumple:

  • Los requisitos especificados.
  • Las necesidades o expectativas del cliente o usuario.

Modelos de calidad de software

El carácter multidimensional y relativo de la calidad junto con su complejidad inherente dificultan en gran medida la evaluación formal de la calidad del software. Es por ello que existen modelos de calidad, los cuales establecen como se debe hacer dicha evaluación. Estos generalmente están estructurados como se muestra en la siguiente figura:

De esta forma se aborda la evaluación desde lo general a lo particular. Así mismo, los modelos de calidad de software se clasifican de acuerdo con el enfoque de evaluación o ámbito en:

  1. Organización
  2. Proyecto
  3. Producto

Como ejemplos de modelos de calidad que se aplican en la actualidad en el sector productivo tenemos:

CMMI (Capability Maturity Model Integration)
Es de los modelos más utilizados en las empresas de construcción de software, con el propósito de verificar el cumplimiento de estándares de calidad de una organización a partir de la medición con niveles de madurez.
ISO 25000
También llamada como SQuaRE, es la sucesora de la norma ISO 9126, la cual estaba basada a su vez en el modelo de McCall. Se muestra continuación en más detalle.

Factores y métricas

Factores

Como hemos visto anteriormente, los modelos de calidad recogen atributos denominados factores de calidad (atributos de alto nivel), los cuales a su vez pueden descomponerse en atributos de bajo nivel denominados criterios de calidad.

Clasificación

Si observamos la forma de medir estos factores los podemos clasificar en dos grandes grupos:

Factores directos
Se pueden medir directamente del software. Por ejemplo, podemos estudiar el tiempo que tarda el programa en hacer una tarea, contar el número de errores que tiene nuestro proyecto, etc.
Factores indirectos
No se pueden medir directamente del software. Por ejemplo, la facilitad de uso o de mantenimiento.

FURPS

Modelo de calidad fija propuesto por Robert Grady y Hewlett Packard Co (HP) en 1987, tiene en cuenta cinco características a la hora de evaluar la calidad del producto.

Este modelo propone tener en cuenta 5 características como aspecto de calidad para todas las actividades del proceso de desarrollo de un Red de calidad y de los cuales se deriva su nombre:

  • Funcionality
  • Usability
  • Reliability
  • Performance
  • Supportability

  • FURPS

  • Diagrama FURPS

También propone una clasificación de los requisitos en dos categorías:

Requisitos funcionales
especifican funciones que el sistema debe ser capaz de realizar sin tener en cuenta las restricciones físicas.
Requerimientos no funcionales
puntualizan atributos del sistema o del medio ambiente del sistema

El modelo FURPS fue extendido por IBM Rational Software; el FURPS+ incluye restricciones de diseño, implementación, interfaces y físicos.

FURPS +
Sigla Requirimiento (inglés) Requirimiento (español) Descripción
F Funcionality Funcionalidad
U Usability Usabilidad
R Reliability Fiabilidad
P Performance Rendimiento
S Supportability Soportabilidad }
Ventajas e inconvenientes de FURPS
Ventajas Inconvenientes
Se pueden reducir los riesgos de no considerar alguna de las facetas del desarrollo de un sistema. El modelo tiene bastante métricas lo que puede generar mayor demanda en tiempo y costos.
Es posible estandarizar algunos criterios para poder obtener los requerimientos. Una limitación de este modelo de calidad es que no tiene en cuenta la portabilidad de los productos software
Los criterios son de fácil comprensión lo que facilita su implementación

Factores definidos en la ISO 25000

Como ejemplo, vamos a ver los factores definidos en la ISO 25000 para el producto software y la calidad en uso, los cuales son denominados atributos, y son:

Adecuación funcional
Representa la capacidad del producto software para proporcionar funciones que satisfacen las necesidades declaradas e implícitas.
Eficiencia de desempeño
Esta característica representa el desempeño relativo a la cantidad de recursos necesarios para utilizar el software.
Usabilidad
Capacidad del producto software para ser entendido, aprendido, usado y resultar atractivo para el usuario.
Mantenibilidad
Esta característica representa la capacidad del producto software para ser modificado efectiva y eficientemente.
Compatibilidad
Capacidad de dos o más sistemas o componentes para intercambiar información y/o llevar a cabo sus funciones requeridas cuando comparten el mismo entorno hardware o soft ware
Portabilidad
Capacidad del producto o componente de ser transferido de forma efectiva y eficiente de un entorno hardware, o software, a otro.
Fiabilidad
Capacidad de un sistema o componente para desempeñar las funciones especificadas, cuando se usa bajo unas condiciones y periodo de tiempo determinados
Seguridad
Capacidad de protección de la información y los datos de manera que personas o sistemas no autorizados no puedan leerlos o modificarlos.
Características de la calidad

Métricas

Los criterios de calidad, a su vez, pueden asociarse con un conjunto de atributos de bajo nivel medibles directamente mediante métricas de calidad. Éstas son imprescindibles en los procesos de aseguramiento de la calidad, ya que difícilmente puede mejorar algo, si no se mide.

A continuación, presentaremos algunas de las métricas más utilizadas en la actualidad.

LOC (Line of code)
Mide el número de líneas, como indicador del tamaño de un producto.
Densidad de comentarios
Mide el número de líneas de comentarios entre el número total de líneas del sistema.
Porcentaje de código duplicado
Indica el porcentaje de líneas de código que se encuentra duplicado frente al total de líneas de código.
LCOM4 (Lack of Cohesión in Methods 4)
Es una propuesta a partir de la métrica inicial LCOM1 de Chidamber y Kemerer, para indicar la falta de cohesión. Si es mayor de 1 quiere decir que se nos aconseja que dividamos la clase en varias subclases. Para el cálculo del LCOM4 de una clase básicamente lo que hace es medir el número de relaciones diferentes que se establecen entre métodos.
Profundidad del árbol de herencia
Longitud del camino máximo entre un nodo y la raíz del árbol, en una jerarquía de clases. Depende del proyecto, pero no se aconseja normalmente tener un valor por encima de 3.
Complejidad ciclomática de McCabe
Esta métrica es un indicador del número de caminos independientes que existen en un grafo, sirviendo para indicar la complejidad inherente de un programa. La complejidad de McCabe V(G) se puede calcular:
V (G) = a - n + 2, siendo a el número de arcos o aristas del grafo y n el número de nodos.

En el sector productivo, para calcular estas métricas, normalmente se utilizan herramientas automáticas de análisis estáticos de código, como por ejemplo SonarQube.

Estrategias de prueba

En este epígrafe sería conveniente contar todo lo relacionado con Pruebas del tema 30 de una forma más sintetizada.

Conclusiones

La generación de conocimiento necesita un poso de calidad que se extiende desde el dato mismo hasta el programa desarrollado para interactuar con la información. Las métricas de calidad de software permiten monitorizar un producto para determinar su nivel de calidad, aunque, el seguimiento que este tipo de medidas permiten llevar a cabo brinda la oportunidad de conocer muchas más de una solución.

Un enfoque proactivo permite la identificación temprana de errores o defectos que pueden ser corregidos a tiempo, eliminando de raíz problemas mayores. Los efectos positivos empiezan a notarse y sus beneficios aumentan en un ciclo de mejora continúa propiciado por el control de las métricas de calidad de software.

Relación con el sistema educativo

GS - DAW - DAM -Entornos de Desarrollo (PES)

Biografía

Referencias

Relaciones

Obtenido de «https://wiki.cifprodolfoucha.es/index.php?title=Calidad_del_%22software%22._Factores_y_métricas._Estrategias_de_prueba.&oldid=14626»