Atributos de Calidad

ATRIBUTOS DE CALIDAD
DE SOFTWARE
Rubby Casallas
Departamento de Ingeniería de Sistemas y Computación
Uniandes
Calidad de Software
Una definición de calidad de enfatizar tres
aspectos:

1.
2.
3.
Los requerimientos de software es lo más importante
para medir la calidad. Si éstos no se satisfacen se
identificará mala calidad
La no definición o el no seguimiento de estándares y
guías llevará a mala calidad
El no hacer explícitos requerimientos no funcionales
llevará a que no se satisfagan (mantenibilidad,
portabilidad, etc. )
Modelos de Calidad de Software



Definir Calidad de Software es una tarea compleja.
Incluye muchos aspectos que deben ser
caracterizados.
Modelos más antiguos McCall (1977) y Boehm
(1978)
ISO 9126 es un estándar inspirado en esos modelos
ISO 9126



Necesidad de poder tener una definición
uniforme para calidad
Provee una definición de las características de
calidad
Define un proceso de evaluación de la calidad
ISO 9126
ISO 9126






Funcionalidad
Confiabilidad
Facilidad de uso
Eficiencia
Facilidad de mantenimiento
Portabilidad
Funcionalidad
Adecuación
Exactitud
Interoperabilidad
Seguridad de acceso
Cumplimiento funcional
Confiabilidad
Madurez
Tolerancia a Fallos
Facilidad de recuperación
Cumplimiento de la fiabilidad
Facilidad de uso
Facilidad para ser entendido
Facilidad para ser aprendido
Facilidad para ser operado
Facilidad de atracción
Cumplimiento de la usabilidad
Eficiencia
Comportamiento temporal
Utilización de recursos
Cumplimiento de la eficiencia
Facilidad de
mantenimiento
Facilidad para ser analizado
Facilidad para ser cambiado
Estabilidad
Facilidad para ser probado
Cumplimiento de la mantenibilidad
Portabilidad
Adaptabilidad
Facilidad de instalación
Coexistencia
Facilidad para
reemplazar
Estabilidad
Facilidad de
mantenimiento
Facilidad para ser
probado
Facilidad para ser
analizado
number of
number of
number of
number of
parameters referenced
global variables
parameters changed
called relationships
number of non-cyclic path
number of nested levels
cyclomatic number
number of call-paths
cyclomatic number
number of statements
comments rate
Atributos principales del modelo

Funcionalidad
 Grado
en que las necesidades asumidas o descritas se
satisfacen

(Con)fiabilidad
 Grado
en que el sistema responde bajo las
condiciones definidas durante un intervalo de tiempo
dado.
Atributos principales del modelo (2)

Facilidad de uso
 Conjunto
de características que influyen en el esfuerzo
requerido para el uso y la evaluación individual de
cada uso por parte de un conjunto de usuarios dados

Eficiencia
 Conjunto
de características que determinan la relación
entre el nivel de rendimiento del software y el número
de recursos usados, bajo ciertas condiciones dadas
Atributos principales del modelo (3)

Facilidad de mantenimiento
 Características
del software que determinaran el
esfuerzo requerido para implementar cambios

Portabilidad
 Conjunto
de características que determinan la facilidad
del software para ser transferido de un entorno de
operación a otro
Funcionalidad

Adecuación
 Facilidad
del producto software para proporcionar un
conjunto apropiado de funciones para tareas y
objetivos de usuario especificados

Exactitud
 Facilidad
del producto software para proporcionar los
resultados o efectos correctos o acordados, con el
grado necesario de precisión
Funcionalidad (2)

Interoperabilidad
 Facilidad
del producto software para interactuar con
uno o más sistemas especificados

Seguridad de acceso
 Facilidad
del producto software para proteger
información y datos de manera que las personas o
sistemas no autorizados no puedan leerlos o
modificarlos, al tiempo que no se deniega el acceso a
las personas o sistemas autorizados
Funcionalidad (3)

Cumplimiento funcional
 Facilidad
del producto software para adherirse a
normas, convenciones o regulaciones en leyes y
prescripciones similares relacionadas con
funcionalidad
Confiabilidad

Madurez
 Facilidad
del producto software para evitar fallar
como resultado de fallos en el software

Tolerancia a fallos
 Facilidad
del software para mantener un nivel
especificado de prestaciones en caso de fallos
software o de infringir sus interfaces especificados
Confiabilidad (2)

Facilidad de recuperación
 Facilidad
del producto software para reestablecer un
nivel de prestaciones especificado y de recuperar los
datos directamente afectados en caso de fallo

Cumplimiento de la fiabilidad
 Facilidad
del producto software para adherirse a
normas, convenciones o regulaciones relacionadas con
al fiabilidad
Facilidad de uso

Facilidad para ser entendido
 Facilidad
del producto software que permite al
usuario entender si el software es adecuado y cómo
puede ser usado para unas tareas o condiciones de
uso particulares

Facilidad para ser aprendido
 Facilidad
del producto software que permite al
usuario aprender sobre su aplicación
Facilidad de uso (2)

Facilidad para ser operado
 Facilidad
del producto software que permite al usuario
operarlo y controlarlo

Facilidad de atracción
 Facilidad
del producto software para ser atractivo al
usuario

Cumplimiento de la usabilidad
 Facilidad
del producto software para adherirse a
normas, convenciones, guías de estilo o regulaciones
relacionadas con la usabilidad
Eficiencia

Comportamiento temporal
 Facilidad
del producto software para proporcionar
tiempos de respuesta, tiempos de proceso y potencia
apropiados, bajo condiciones determinadas

Utilización de recursos
 Facilidad
del producto software para usar las
cantidades y tipos de recursos adecuados cuando el
software lleva a cabo su función bajo condiciones
determinadas

Cumplimiento de la eficiencia
 Facilidad
del producto software para adherirse a
normas o convenciones relacionadas con la eficiencia
Facilidad de mantenimiento

Facilidad para ser analizado
 Es
la Facilidad del producto software para serle
diagnosticadas deficiencias o causas de los fallos en el
software, o para identificar las partes que han de ser
modificadas

Facilidad para ser cambiado
 Facilidad
del producto software que permite que una
determinada modificación sea implementada
Facilidad de mantenimiento (2)

Estabilidad
 Facilidad
del producto software para evitar efectos
inesperados debidos a modificaciones del software

Facilidad para ser probado
 Facilidad
del producto software que permite que el
software modificado sea validado

Cumplimiento de la mantenibilidad
 Facilidad
del producto software para adherirse a
normas o convenciones relacionadas con la
mantenibilidad
Portabilidad

Adaptabilidad
 Facilidad
del producto software para ser adaptado
a diferentes entornos especificados, sin aplicar
acciones o mecanismos distintos de aquellos
proporcionados para este propósito por el propio
software considerado

Facilidad de instalación
 Facilidad
del producto software para ser instalado
en un entorno especificado
Portabilidad (2)

Coexistencia
 Facilidad
del producto software para coexistir con
otro software independiente, en un entorno común,
compartiendo recursos comunes

Facilidad para reemplazar
 Facilidad
del producto software para ser usado en
lugar de otro producto software, para el mismo
propósito, en el mismo entorno
Portabilidad (3)

Cumplimiento de la portabilidad
 Facilidad
del producto software para adherirse a
normas o convenciones relacionadas con la
portabilidad
Maintainability metrics

Analyzability:
 cyclomatic
number
 number of statements
 comments rate

Changeability:
 number
of nested levels
 average size of statement
 number of variables
Maintainability metrics

Stability:
 number
of parameters referenced
 number of global variables
 number of parameters changed
 number of called relationships

Testability:
 number
of non-cyclic path
 number of nested levels
 cyclomatic number
 number of call-paths
Measuring aspects of quality, defects




Measuring many of the quality factors described in quality
models is dependent on subjective ratings
In order to suppress variability those performing rating should
be made aware of the need for consistency
Software quality measurement using the decomposition
approach requires careful planning and data collection in
order to keep down the extra costs involved
One solution is to look at quality as the lack of defects and thus
concentrate on recording errors, faults, and failures
Measuring aspects of quality, defects



A de facto standard measure of software quality is defect
density
Defects can be classified as known defects and latent defects
Then defect density can be defined as:
defect density = # known defects / product size
Measuring aspects of quality, defects

For using defect density in decision making the
following should be noted:
The terminology differs widely: fault rate, fault density,
and failure rate are used almost interchangeably
 Defect rate is dependent on time and defect density on
size
 Remember that size can be measured in many different
ways
 Defect finding is also dependent on the efficiency of the
testing process

Measuring aspects of quality, defects
Even if our measurement otherwise are OK, you should
remember that defects are not equally serious, and that
the faults which eventually lead to failures is also
affected by the specific users
 Despite these problems defect density is an important
quality measure

Measuring aspects of quality, Usability


Usability of a software product is the extent to which the
product is convenient and practical to use (right help in the right
way)
For measurement we must decompose usability in more
fundamental attributes, each of which must be assessed by the
user for the product in question:
Entry level: experience of user.
 Learnability: speed of learning: eg. hours of training.
 Handling ability: speed of working when trained, or errors
made.

Measuring aspects of quality,
Maintainability



Suppose we seek measures to characterize the ease of
applying maintenance to a specific product
We can then define a measure called mean time to repair
(MTTR)
To calculate this measure, we need the following information:
 problem recognition time
 administrative delay time
 maintenance tools collection time
 problem analysis time
 change specification time
 change time (including testing and review)
Maintainability


To determine which measures (relating to specific
internal attributes) most affect maintainability, we must
gather them in combination with external
maintainability measures
So for instance we may find empirically that bad
structure (measured in some way) normally means high
MTTR. If this is the case then badly structured modules
should be analyzed and appropriate guidelines
established and actions taken.