Estándares y Modelos de Calidad del Software
Fernando Rojas Cetina
Universidad
de Cartagena
Facultad
de Ciencias Sociales y Educación
Maestría
en Recursos Digitales Aplicados a la Educación
Mag. Gabriel de Jesús Torres Gómez
Villavicencio
y Chámeza
6 de diciembre 2020
La calidad del producto, junto con la calidad del proceso, es uno de los aspectos más importantes actualmente en el desarrollo de Software. Relacionada con la calidad del producto, recientemente ha aparecido la familia de normas ISO/IEC 25000, que proporciona una guía para el uso de la nueva serie de estándares internacionales llamada Requisitos y Evaluación de Calidad de Productos de Software (SQuaRE - System and Software Quality Requirements and Evaluation).
ISO/IEC 25000 constituye una serie de normas basadas en ISO/IEC 9126 y en ISO/IEC 14598 cuyo objetivo principal es guiar el desarrollo de los productos de software mediante la especificación de requisitos y evaluación de características de calidad.
GENERALIDADES
El objetivo general de la creación del estándar ISO/IEC 25000 SQuaRE (System and Software Quality Requirements and Evaluation) es organizar, enriquecer y unificar las series que cubren dos procesos principales: especificación de requisitos de calidad del software y evaluación de la calidad del software, soportada por el proceso de medición de calidad del software.
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. Esta familia de normas ISO/IEC 25000 se encuentra compuesta por cinco divisiones.
La Norma ISO 25000, proporciona una guía para el uso de las series de estándares internacionales llamados requisitos y Evaluación de Calidad de Productos Software (SQuaRE). La norma establece criterios para la especificación de requisitos de calidad de productos software, sus métricas y su evaluación, e incluye un modelo de calidad para unificar las definiciones de calidad de los clientes con los atributos en el proceso de desarrollo.
Las características de calidad y sus mediciones asociadas pueden ser útiles no solamente para evaluar el producto software sino también para definir los requerimientos de calidad.La serie ISO/IEC 25000:2005 reemplaza a dos estándares relacionados: ISO/IEC 9126 (Software Product Quality) e ISO/IEC 14598 (Software Product Evaluation).
Para la organización:
Para los clientes:
CRITERIOS DE EVALUACIÓN Y MÉTRICA DE EVALUACIÓN
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.
El primer paso del proceso de evaluación consiste en establecer los requisitos de la evaluación.
En esta tarea se documenta el propósito por el que la organización quiere evaluar la calidad de su producto software (asegurar la calidad del producto, decidir si se acepta un producto, determinar la viabilidad del proyecto en desarrollo, comparar la calidad del producto con productos de la competencia, etc.).
En esta tarea se identifican las partes interesadas en el producto software (desarrolladores, posibles adquirientes, usuarios, proveedores, etc.) y se especifican los requisitos de calidad del producto utilizando un determinado modelo de calidad.
Se deben identificar y documentar las partes del producto software incluidas en la evaluación. El tipo de producto a evaluar (especificación de requisitos, diagramas de diseño, documentación de las pruebas, etc.) depende de la fase en el ciclo de vida en que se realiza la evaluación y del propósito de ésta.
Se debe definir el rigor de la evaluación en función del propósito y el uso previsto del producto software, basándose, por ejemplo, en aspectos como el riesgo para la seguridad, el riesgo económico o el riesgo ambiental. En función del rigor se podrá establecer qué técnicas se aplican y qué resultados se esperan de la evaluación.
En esta actividad 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.
En esta tarea el evaluador selecciona las métricas de calidad, técnicas y herramientas (módulos de evaluación) que cubran todos los requisitos de la evaluación. Dichas métricas deben permitir que, en función de su valor, se puedan realizar comparaciones fiables con criterios que permitan tomar decisiones. Para ello se puede tener en cuenta la Norma ISO/IEC 25020.
Se deben definir los criterios de decisión para las métricas seleccionadas. Dichos criterios son umbrales numéricos que se pueden relacionar con los requisitos de calidad y posteriormente con los criterios de evaluación para decidir la calidad del producto. Estos umbrales se pueden establecer a partir de benchmarks, límites de control estadísticos, datos históricos, requisitos del cliente, etc.
Se deben definir criterios para las diferentes características evaluadas a partir de las sub características y métricas de calidad. Estos resultados a mayor nivel de abstracción permiten realizar la valoración de la calidad del producto software de forma general.
En esta actividad se define el plan con las actividades de evaluación que se deben realizar.
Se deben planificar las actividades de la evaluación teniendo en cuenta la disponibilidad de los recursos, tanto humanos como materiales, que puedan ser necesarios. En la planificación se debe tener en cuenta el presupuesto, los métodos de evaluación y estándares adaptados, las herramientas de evaluación, etc.
El plan de evaluación se revisará y actualizará proporcionando información adicional según sea necesario durante el proceso de evaluación.
En esta actividad se ejecutan las actividades de evaluación obteniendo las métricas de calidad y aplicando los criterios de evaluación.
Se deben realizar las mediciones sobre el producto software y sus componentes para obtener los valores de las métricas seleccionadas e indicadas en el plan de evaluación. Todos los resultados obtenidos deberán ser debidamente registrados.
Se aplican los criterios de decisión para las métricas seleccionadas sobre los valores obtenidos en la medición del producto.
En esta última tarea se deben aplicar los criterios de decisión a nivel de características y sub características de calidad, produciendo como resultado la valoración del grado en que el producto software cumple los requisitos de calidad establecidos.
En esta actividad 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.
Mediante esta tarea, el evaluador y el cliente de la evaluación (en caso de existir) realizan una revisión conjunta de los resultados obtenidos, con el objetivo de realizar una mejor interpretación de la evaluación y una mejor detección de errores.
Una vez revisados los resultados, se elabora el informe de evaluación, con los requisitos de la evaluación, los resultados, las limitaciones y restricciones, el personal evaluador, etc.
El evaluador revisará los resultados de la evaluación y la validez del proceso de evaluación, de los indicadores y de las métricas aplicadas. El feedback de la revisión debe servir para mejorar el proceso de evaluación de la organización y las técnicas de evaluación utilizadas.
Una vez finalizada la evaluación, el evaluador debe realizar el adecuado tratamiento con los datos y los objetos de la evaluación según lo acordado con el cliente (en caso de ser una tercera parte), devolviéndolos, archivándolos o eliminándolos según corresponda.
Modelo GQM
1. Establecer las metas, En este paso se definen metas u objetivos en el proyecto, asociadas a la producción y la calidad de un producto o proceso.
2. Generación de preguntas, Basado en modelos se crea una serie de preguntas que deben estar alineadas a los objetivos y a su vez puedan ser medibles.
3. Especificación de medidas, Se debe detallar las métricas o medidas contestando a las preguntas de manera que puedan ser recopiladas y evaluar el avance en los procesos o resultados del proyecto.
4. Preparar recolección de datos, Diseñar o desarrollar instrumentos para la recolección de los datos obtenidos de las métricas aplicadas.
5. Recolectar, validar y analizar los datos para la toma de decisiones, Estos procesos deben ser realizados en tiempo real, en la que permitan la realimentación correctiva del proyecto.
6. Analizar los datos para el logro de los objetivos y el aprendizaje, Este proceso se debe realizar finalizada el logro de una meta u objetivo determinando el nivel de satisfacción en la que se identifican oportunidades de mejora para un futuro.
Modelo definido por Gilb en 1988, presenta como aspecto fundamental la definición de atributos y el nivel de calidad que debe tener cada uno de ellos para satisfacer al usuario, pues no tiene sentido exigir calidad en un producto, sino se cuenta con esta base. La especificación de requisitos de calidad la realiza conjuntamente el usuario con el analista, está enfocado en la definición de atributos de calidad en la usabilidad, lo que quiere decir lo más importante del producto. La definición de los criterios no funcionales se realiza con la ayuda de los usuarios. Este modelo está orientado en la evaluación de software a partir de los siguientes atributos:
Capacidad de trabajo: en este atributo se evalúa la capacidad de procesamiento del sistema o software para realizar trabajos o tareas, la velocidad de respuesta en los comandos y la capacidad de almacenar información.
O Capacidad de proceso.
O Capacidad de respuesta.
O Capacidad de almacenamiento.
Adaptabilidad.
Disponibilidad.
Utilizabilidad.
Disponibilidad: Refleja la medida de la disponibilidad del sistema para realizar de forma útil el trabajo para el que fue diseñado. Sub atributos: fiabilidad, Mantenibilidad e integridad. Fuertes Castro José (2002), en su tesis de doctorado ilustra los conceptos que determinan la Disponibilidad mostrado en la Figura.
Adaptabilidad: Es la medida de la capacidad de un sistema para ser modificado de manera adecuada. Sub atributos: improbabilidad, extensibilidad y transportabilidad.
Utilizabilidad: Es la medida de la facilidad con que la gente será capaz y estará motivada para utilizar el sistema en la práctica. Sub atributos: requisitos de entrada, requisitos de aprendizaje y habilidad de manejo.
Estos a su vez se descomponen en sub atributos especificando cada una de ellas como nombre y definición, escala de definición, escala de medición, recogida de datos, valor previsto, valor óptimo, valor actual y comentarios en la que se convierte en un soporte para la gestión de proyectos proporcionando una guía para solucionar problemas y mitigar los riesgos.
* Nombre y definición de las características.
* Escala o unidades de medición.
* Recopilación de datos o prueba.
* Valor previsto.
* Valor óptimo.
* Valor en el sistema actual.
* Comentarios.
Consta de las siguientes características:
* Corrección: grado en el que el software lleva a cabo una función requerida. Si un programa no opera correctamente no dará valor agregado a sus usuarios.
* Facilidad de mantenimiento: posibilidad de corregir un programa si se encuentra un error, adaptarlo si cambia su entorno, o mejorarlo si el cliente desea un cambio.
* Integridad: habilidad del sistema para resistir ataques. Tanto accidentales como intencionados, contra su seguridad, en todos sus niveles. Para medir la integridad se sugiere otros atributos como son:
* Amenaza: es la probabilidad de que un ataque de cualquier tipo ocurra.
* Seguridad: es la probabilidad de que se pueda repeler un determinado ataque.
* Facilidad de uso: es un intento por cuantificar lo amigable que puede ser el producto con el usuario.
Características de alto nivel
Estándares y Modelos de Calidad del Software Lucero Villa Hernández Fernando Rojas Cetina Universidad de Cartagena Facultad de Cie...
