ATRIBUTOS DE CALIDAD DE SOFTWARE. Rubby Casallas Departamento de Ingeniería de Sistemas y Computación Uniandes

Transcripción

1 ATRIBUTOS DE CALIDAD DE SOFTWARE Rubby Casallas Departamento de Ingeniería de Sistemas y Computación Uniandes

2 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. )

3 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

4 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

5 ISO 9126

6 ISO 9126 Funcionalidad Confiabilidad Facilidad de uso Eficiencia Facilidad de mantenimiento Portabilidad

7 Funcionalidad Confiabilidad Facilidad de uso Eficiencia Facilidad de mantenimiento Adecuación Exactitud Interoperabilidad Seguridad de acceso Cumplimiento funcional Madurez Tolerancia a Fallos Facilidad de recuperación Cumplimiento de la fiabilidad Facilidad para ser entendido Facilidad para ser aprendido Facilidad para ser operado Facilidad de atracción Cumplimiento de la usabilidad Comportamiento temporal Utilización de recursos Cumplimiento de la eficiencia Facilidad para ser analizado Facilidad para ser cambiado Estabilidad Facilidad para ser probado Cumplimiento de la mantenibilidad

8 Portabilidad Facilidad de mantenimiento Adaptabilidad Facilidad de instalación Coexistencia Facilidad para reemplazar Estabilidad Facilidad para ser probado Facilidad para ser analizado number of parameters referenced number of global variables number of parameters changed number of called relationships number of non-cyclic path number of nested levels cyclomatic number number of call-paths cyclomatic number number of statements comments rate

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

10 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

11 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

12 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

13 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

14 Funcionalidad (3) Cumplimiento funcional Facilidad del producto software para adherirse a normas, convenciones o regulaciones en leyes y prescripciones similares relacionadas con funcionalidad

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

24 Portabilidad (3) Cumplimiento de la portabilidad Facilidad del producto software para adherirse a normas o convenciones relacionadas con la portabilidad

25 Maintainability metrics Analyzability: cyclomatic number number of statements comments rate Changeability: number of nested levels average size of statement number of variables

26 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

27 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

28 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

29 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

30 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

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

32 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)

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