Calidad del "software". Factores y métricas. Estrategias de prueba.
Sumario
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.
Por ello cada vez más organizaciones se preocupan por la implantación de modelos de calidad en el desarrollo del software.
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:
De esta forma se aborda la evaluación desde lo general a lo particular.
Clasificación
Los modelos de calidad de software se clasifican de acuerdo con el enfoque de evaluación o ámbito en:
- Organización
- Proyecto
- 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
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 (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
| 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 | 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:
- Inicial
- Repetible
- Definido
- Gestionado
- Optimizado.
La versión 2.0 se publicó en 2018
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.
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
- https://oposicionestic.blogspot.com/2013/03/calidad-del-software-factores-y.html
- https://www.oposinet.com/temario-de-informatica/temario-1-informatica/tema-57-calidad-del-software/
- http://uoc.gitlab.io/2015/desarrollo%20proyecto/2.pdf
- https://virtual.itca.edu.sv/Mediadores/stis/52___factores_de_calidad_del_software.html
- https://www.uv.mx/personal/asumano/files/2012/08/MetricasTecnicas.pdf
- Tema 39 apuntes EGAP
- https://blog.nimbleways.com/checkstyle-pmd-and-findbugs-why-and-how-part-1/
- ISO/IEC/IEEE 29119 El nuevo estándar internacional para pruebas de software
