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

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

Introducción

Son muchos los proyectos que no se completan en costes, plazos, alcance y nivel de calidad.

Cuando hablamos de procesos de desarrollo de software, no estamos hablando de temas puramente técnicos porque está demostrado que la mayoría de los problemas son organizativos.

Es necesario un enfoque holístico: y es por ello cada vez más organizaciones se preocupan por la implantación de modelos de calidad en el desarrollo del software.

Dentro de ese proceso y con la aspiracion de dotar al producto de la mayor calidad se encuentran las pruebas con sus diferentes estrategias.

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.

Factores y métricas

Factores

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.

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.
Índice de madurez del software
El IMS nos permite medir si un producto se ha asentado.
Mt: Modulos totales
Mm: Módulos modificados
Ma: Módulos añadidos
Me: Módulos eliminados
IMS = [Mt-(Mm + Ma + Me)]/ Nt
IMS aproximado a 1 uno implica software asentado; IMS aproximado a cero implica software joven
TMEF o tiempo medio entre fallos
TMDF es el tiempo medio del fallo
TMDR es el tiempo medio de reparacion
TMEF = TMDF + TMDR
Disponibilidad = ((TMDF)/(TMDF+TMDR)) x 100
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.

Modelos

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:

Estructura de un modelo de calidad

De esta forma se aborda la evaluación desde lo general a lo particular.

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:

FURPS
Modelo de calidad fija propuesto por Robert Grady y Hewlett Packard (HP) en 1987.
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.
Six SIGMA
Es una metodología de mejora de procesos creada en Motorola por el ingeniero Bill Smith en la década de los 80; está centrada en la reducción de la variabilidad, consiguiendo reducir o eliminar los defectos o fallos en la entrega de un producto o servicio al cliente

Algunos de ellos se desarrollarán a continuación en mayor profundidad.

FURPS

Modelo de calidad fija propuesto por Robert Grady y Hewlett Packard (HP) en 1987; tiene en cuenta cinco características a la hora de evaluar la calidad del producto y de las 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
FURPS
Sigla Requirimiento (inglés) Requirimiento (español) Atributos
F Funcionality Funcionalidad Características y capacidades
Generalidad de las funciones
Seguridad del Sistema
U Usability Usabilidad Factores humanos
Factores estéticos
Consistencia de la Interfaz
Documentación
R Reliability Fiabilidad
Frecuencia y severidad de los fallos
Exactitud de las salidas
Tiempo medio de fallos
Capacidad de recuperación de fallos
Capacidad de prediccoón
P Performance Rendimiento Velocidad del procesamiento
Tiempo de respuesta
Consumo de recursos
Rendimiento efectivo total
Eficacia
S Supportability Capacidad de soporte Extensibilidad
Adaptabilidad
Capacidad de pruebas
Capacidad de configuración
Compatibilidad
Requisitos de instalación

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

Las restricciones de diseño
especifican o restringen el diseño del sistema.
Las restricciones de implementación
especifican o restringen la codificación o construcción de un sistema.
Las restricciones de interfaz
especifican el comportamiento de los elementos externos con los que el sistema debe interactuar.
Las restricciones físicas
especifican ciertas propiedades que el sistema debe poseer, en términos de materiales, forma, peso, tamaño,etc.
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

CMMI

Integración de sistemas modelos de madurez de capacidades o Capability Maturity Model Integration (CMMI) es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software. Administrado por el Instituto CMMI, una subsidiaria de ISACA, se desarrolló en la Universidad Carnegie Mellon (CMU.

CMU pretende que CMMI pueda ser usado para guiar la mejora de procesos en un proyecto, división o una organización completa. CMMI define los siguientes niveles de madurez para los procesos:

  1. Inicial
  2. Repetible
  3. Definido
  4. Gestionado
  5. Optimizado.

La versión 2.0 se publicó en 2018

ISO 25000

ISO/IEC 25000, conocida como SQuaRE (System and Software Quality Requirements and Evaluation), es una familia de normas que tiene por objetivo la creación de un marco de trabajo común para evaluar la calidad del producto software.

La familia ISO/IEC 25000 es el resultado de la evolución de otras normas anteriores, especialmente de las normas ISO/IEC 9126, que describe las particularidades de un modelo de calidad del producto software, e ISO/IEC 14598, que abordaba el proceso de evaluación de productos software.

Divisiones

Esta familia de normas ISO/IEC 25000 se encuentra compuesta por cinco divisiones.

La división de extensión de SQuaRE (ISO/IEC 25050 a ISO/IEC 25099) se reserva para normas o informes técnicos que aborden dominios de aplicación específicos o que puedan ser utilizados para complementar otras normas de la familia SQuaRE.

Divisiones para gestión de la calidad

ISO/IEC 2500n – División de Gestión de Calidad

Las normas que forman este apartado definen todos los modelos, términos y definiciones comunes referenciados por todas las otras normas de la familia 25000. Actualmente esta división se encuentra formada por:

ISO/IEC 25000 - Guide to SQuaRE
Contiene el modelo de la arquitectura de SQuaRE, la terminología de la familia, un resumen de las partes, los usuarios previstos y las partes asociadas, así como los modelos de referencia.
ISO/IEC 25001 - Planning and Management
Establece los requisitos y orientaciones para gestionar la evaluación y especificación de los requisitos del producto software.

ISO/IEC 2501n – División de Modelo de Calidad

Las normas de este apartado presentan modelos de calidad detallados incluyendo características para calidad interna, externa y en uso del producto software. Actualmente esta división se encuentra formada por:

ISO/IEC 25010 - System and software quality models
Describe el modelo de calidad para el producto software y para la calidad en uso. Esta Norma presenta las características y subcaracterísticas de calidad frente a las cuales evaluar el producto software.
ISO/IEC 25012 - Data Quality model
Define un modelo general para la calidad de los datos, aplicable a aquellos datos que se encuentran almacenados de manera estructurada y forman parte de un Sistema de Información.

ISO/IEC 2502n – División de Medición de Calidad

Estas normas incluyen un modelo de referencia de la medición de la calidad del producto, definiciones de medidas de calidad (interna, externa y en uso) y guías prácticas para su aplicación. Actualmente esta división se encuentra formada por:

ISO/IEC 25020 - Measurement reference model and guide
Presenta una explicación introductoria y un modelo de referencia común a los elementos de medición de la calidad. También proporciona una guía para que los usuarios seleccionen o desarrollen y apliquen medidas propuestas por normas ISO.
ISO/IEC 25021 - Quality measure elements
Define y especifica un conjunto recomendado de métricas base y derivadas que puedan ser usadas a lo largo de todo el ciclo de vida del desarrollo software.
ISO/IEC 25022 - Measurement of quality in use
Define específicamente las métricas para realizar la medición de la calidad en uso del producto.
ISO/IEC 25023 - Measurement of system and software product quality
Define específicamente las métricas para realizar la medición de la calidad de productos y sistemas software.
ISO/IEC 25024 - Measurement of data quality
define específicamente las métricas para realizar la medición de la calidad de datos.

SO/IEC 2503n – División de Requisitos de Calidad

Las normas que forman este apartado ayudan a especificar requisitos de calidad que pueden ser utilizados en el proceso de elicitación de requisitos de calidad del producto software a desarrollar o como entrada del proceso de evaluación. Para ello, este apartado se compone de:

ISO/IEC 25030 - Quality requirements
Provee de un conjunto de recomendaciones para realizar la especificación de los requisitos de calidad del producto software.

ISO/IEC 2504n – División de Evaluación de Calidad

Este apartado incluye normas que proporcionan requisitos, recomendaciones y guías para llevar a cabo el proceso de evaluación del producto software. Esta división se encuentra formada por:

ISO/IEC 25040 - Evaluation reference model and guide
Propone un modelo de referencia general para la evaluación, que considera las entradas al proceso de evaluación, las restricciones y los recursos necesarios para obtener las correspondientes salidas.
ISO/IEC 25041 - Evaluation guide for developers, acquirers and independent evaluators
Describe los requisitos y recomendaciones para la implementación práctica de la evaluación del producto software desde el punto de vista de los desarrolladores, de los adquirentes y de los evaluadores independientes.
ISO/IEC 25042 - Evaluation modules
Define lo que la Norma considera un módulo de evaluación y la documentación, estructura y contenido que se debe utilizar a la hora de definir uno de estos módulos.
ISO/IEC 25045 - Evaluation module for recoverability
Define un módulo para la evaluación de la subcaracterística Recuperabilidad (Recoverability).

Factores

Los factores definidos en la ISO 25010 para el producto software y la calidad en uso, denominados atributos, 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

Características

Desde el punto de vista dependiente del sistema, la Calidad de Datos depende del dominio tecnológico en el que los datos se utilizan, y se alcanza mediante las capacidades de los componentes del sistema informático tales como: dispositivos hardware (e.g., Respaldo Software para alcanzar la Recuperabilidad), y otro software (e.g., Herramientas de migración para alcanzar la Portabilidad).

El modelo de Calidad de Producto de Datos definido por el estándar ISO/IEC 25012 se encuentra compuesto por las 15 características:

Características de ISO 25012

Las características de Calidad de Datos están clasificadas en dos grandes categorías:

Calidad de Datos Inherente
Se refiere al grado con el que las características de calidad de los datos tienen el potencial intrínseco para satisfacer las necesidades establecidas y necesarias cuando los datos son utilizados bajo condiciones específicas. Desde el punto de vista inherente, la Calidad de Datos se refiere a los mismos datos, en particular a:
Valores de dominios de datos y posibles restricciones (e.g., Reglas de Negocio gobernando la calidad requerida por las características en una aplicación dada).
Relaciones entre valores de datos (e.g., Consistencia).
Metadatos.
Calidad de Datos Dependiente del Sistema
Se refiere al grado con el que la Calidad de Datos es alcanzada y preservada a través de un sistema informático cuando los datos son utilizados bajo condiciones específicas.

Evaluación del producto software

ISO/IEC 25040 define el proceso para llevar a cabo la evaluación del producto software. Dicho proceso de evaluación consta de un total de cinco actividades

Características de ISO 25012
Actividades y tareas en el proceso de evaluación del software
Actividad Tarea Descripción
Actividad 1: Establecer los requisitos de la evaluación El primer paso del proceso de evaluación consiste en establecer los requisitos de la evaluación.
Tarea 1.1: Establecer el propósito de la evaluación
Tarea 1.2: Obtener los requisitos de calidad del producto
Tarea 1.3: Identificar las partes del producto que se deben evaluar
Tarea 1.4: Definir el rigor de la evaluación
Actividad 2: Especificar la evaluación Se especifican los módulos de evaluación (compuestos por las métricas, herramientas y técnicas de medición) y los criterios de decisión que se aplicarán en la evaluación.
Tarea 2.1: Seleccionar los módulos de evaluación
Tarea 2.2: Definir los criterios de decisión para las métricas
Tarea 2.3: Definir los criterios de decisión de la evaluación
Actividad 3: Diseñar la evaluación Se define el plan con las actividades de evaluación que se deben realizar.
Tarea 3.1: Planificar las actividades de la evaluación
Actividad 4: Ejecutar la evaluación Se ejecutan las actividades de evaluación obteniendo las métricas de calidad y aplicando los criterios de evaluación.
Tarea 4.1: Realizar las mediciones
Tarea 4.2: Aplicar los criterios de decisión para las métricas
Tarea 4.3: Aplicar los criterios de decisión de la evaluación
Actividad 5: Concluir la evaluación Se concluye la evaluación de la calidad del producto software, realizando el informe de resultados que se entregará al cliente y revisando con éste los resultados obtenidos.
Tarea 5.1: Revisar los resultados de la evaluación
Tarea 5.2: Crear el informe de evaluación
Tarea 5.3: Revisar la calidad de la evaluación y obtener feedback
Tarea 5.4: Tratar los datos de la evaluación

Metodologías ágiles: Scrum y la calidad

La literatura tradicional sobre desarrollo de software habla del triángulo de hierro, formado por el alcance, costo y duración de un proyecto.

Triángulo de hierro en gestión de proyectos

Este triángulo siempre ha presupuesto que la calidad era inherente a los desarrollos; sin embargo, ha resultado ser la variable que más sufre en numerosos proyectos. La gestión tradicional de proyectos fija un alcance a desarrollar en un determinado tiempo con un costo establecido. Con esas tres variables fijas, ante cualquier problema, la respuesta más probable será que la calidad disminuye. Las prisas por terminar en tiempo, por no rebasar el presupuesto o el hecho de cumplir con el contrato firmado no dan muchas opciones.

Se busca con las perspectivas ágiles integrar el control de la calidad en el propio proceso de desarrollo; y que la única posibilidad de desarrollo sea crear entregables que funcionen correctamente, que cumplan con una definición del producto acabado, que sea un requerimiento participar colaborativa y constantemente con el equipo de desarrollo y el cliente o Product Owner.

Para ello están todas las personas incluídas en el equipo: incluso los testers ya que comparten el mismo objetivo que el resto del equipo.

Otro objetivo imprescindible es el cumplimiento de las expectativas del cliente. El uso de iteraciones de manera incremental permite alinear esas expectativas con el avance del proyecto. Uno de los principios básicos define que el grado de progreso de un proyecto únicamente se puede medir por el software que ya brinda valor al cliente, y que es potencialmente utilizable.

Ciclo de vida en scrum

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

FURPS

CMMI

ISO 25000

En metodologías ágiles

Relaciones

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