ATRIBUTOS DE CALIDAD

DE SOFTWARERubby Casallas

Departamento de Ingeniería de Sistemas y Computación

Uniandes

Calidad de Software

Una definición de calidad de enfatizar tres

aspectos:

1. Los requerimientos de software es lo más importante

para medir la calidad. Si éstos no se satisfacen se

identificará mala calidad

2. La no definición o el no seguimiento de estándares y

guías llevará a mala calidad

3. 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

Facilidad de

mantenimiento

Estabilidad

number of parameters referenced

number of global variables

number of parameters changed

number of called relationships

Facilidad para ser

probado

number of non-cyclic path

number of nested levels

cyclomatic number

number of call-paths

Facilidad para ser

analizado

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

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

Atributos principales del modelo (3)

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.