Tema 10 Calidad Software. Ingeniería del Software I

(1)

Tema 10

Calidad Software

(2)

www.kybele.es www.kybele.etsii.urjc.es Ingeniería del Software I – 2011/2012

Calidad Software



La calidad software es el grado con el que un sistema,

componente o proceso cumple los requisitos funcionales

definidos y las necesidades del cliente o usuario. (IEEE, Std

610-1900).



La calidad del software es el conjunto de cualidades que lo

caracterizan y que determinan su utilidad y existencia.



Concordancia del software producido con los requisitos

explícitamente establecidos, con los estándares de

desarrollo prefijados y con los requisitos implícitos no

establecidos formalmente, que desea el usuario

(3)

ENTRADA SW

Factoría Software

(4)

(5)



Conseguir productos software de calidad es uno

de los objetivos principales de las factorías de

software.



¿Cómo podemos obtener software de calidad?



_{¿Cómo podemos medir y evaluar la calidad de un}

producto software?

El software al no ser físico es difícil medir su función, ventajas y costes. Por lo tanto, los procesos y los métodos para manejar, para supervisar, y para medir su calidad pueden

(6)



¿Qué propiedades puedo medir en un software para

poder evaluarlo?

 _{Clasificación de propiedades}

 Propiedades o características operativas.

 Propiedades adaptabilidad a nuevos entornos.  Propiedades de soportar cambios.

(7)

Calidad Software: propiedades de calidad



Propiedades operativas:

 Son aquellas que nos indican las características del propio programa.

Propiedades operativas

(8)

 Funcionalidad: el grado en que un programa satisface sus

especificaciones y cubre los requisitos funcionales solicitados por el cliente.

 Aspectos:

 Adecuación: capacidad para ofrecer al cliente los requisitos

funcionales que éste solicita.

 Exactitud: capacidad del software para proporcionar los

resultados con el grado necesario de precisión (sin fallos).

 Interoperabilidad: capacidad del sistema para interactuar

con otros sistemas.

 Seguridad de acceso o integridad: capacidad del sistema

(9)

 Facilidad de uso/Usabilidad: se mide mediante los factores

humanos. Es el esfuerzo requerido para aprender un programa. Se debe conocer el target al que va dirigido el software.

 Aspectos:

 Capacidad de ser entendido: ¿el usuario entiende cómo

manejar el sistema?

 Capacidad para ser operado: ¿la facilidad que el usuario

tiene para llevar a cabo las tareas?

 Capacidad de atracción: ¿es un software donde el usuario se

encuentra cómodo?

 Cumplimiento de la usabilidad: ¿tiene el software la

(10)

 Rendimiento o eficiencia: cantidad de recursos requeridos por

un programa para llevar a cabo sus funciones. Se puede mediar a través del la velocidad de proceso o por el tiempo de

respuesta.

 Aspectos:

 _{Comportamiento temporal: ¿cuál es su tiempo de}

respuesta? ¿Cuál es su tiempo de proceso? (Medido todo bajo unas condiciones determinadas).

 Utilización de recursos: ¿utiliza los recursos (memoria RAM)

necesarios?

 Cumplimiento de la eficacia: capacidad para adaptarse a

(11)

 Fiabilidad: grado con el cual un programa lleva a cabo sus

funciones con precisión y sin fallos. Se mide por la frecuencia de los fallos.

 Aspectos:

 Madurez: capacidad del software para evitar fallar.

 Tolerancia a fallos: capacidad del software de mantenerse

operativo aun habiendo sucedido algún fallo.

 Capacidad de recuperación: capacidad del software para

recuperar su estado inicial antes de ocurrir el fallo y de recuperar los datos que se han visto afectados por éste.

 Cumplimiento de la fiabilidad: capacidad del producto

(12)



Propiedades para soportar cambios:

(13)

 Facilidad de mantenimiento: esfuerzo requerido para localizar

y solventar un error en el programa

 Aspectos:

 _{Capacidad para ser analizado: ¿Es fácil poder diagnosticar}

deficiencias en el software o encontrar la causa de un fallo? ¿Es fácil saber qué partes deben ser tratadas para solucionar el fallo?

 Estabilidad: A pesar de sufrir una modificación , ¿puedo

controlar los efectos que puede producir ésta al resto del sistema?

 Capacidad de probar las modificaciones: ¿Puedo validar la

(14)

 Facilidad de prueba: ¿Cuál es el esfuerzo a invertir para probar

un programa y asegurar así el buen funcionamiento del sistema software?

 Flexibilidad: ¿Cuál es el esfuerzo que tengo que invertir para

hacer una modificación (añadir algún componente, eliminar algún componente, reunificar componentes, etc…) en el

(15)



Propiedad de adaptabilidad a nuevos entornos:

(16)

 Portabilidad: ¿Qué esfuerzo tengo que hacer para migrar el

software a otro entorno (diferente hardware o interacción con otros sistemas)?

 Aspectos:

 Adaptabilidad: capacidad para adaptarse a nuevos entornos

sin tener que realizar modificaciones.

 Instalabilidad: ¿es muy compleja la instalación del sw?

 _{Coexistencia: ¿es capaz de interactuar con otro software en}

un entorno común y compartiendo recursos comunes?

 Capacidad para reemplazar: ¿Nuestro software puede

reemplazar a otros del mercado?

 Cumplimiento de la portabilidad: adherirse a normas de

(17)

 Reusabilidad: ¿qué partes de mi programa podrían ser

reutilizadas por otros sistemas de información?

 Facilidad de interoperación: ¿Qué esfuerzo debo invertir para

(18)



Satisfacción del usuario = Producto manejable + Buena

Calidad + Entrega dentro de presupuesto y tiempo.



La calidad del software puede medirse después de que el

producto haya sido implementado:

 Si se hace así, nos puede salir muy caro si detectamos

problemas en la arquitectura, en los requisitos funcionales…



La calidad del software se puede evaluar y controlar

durante el proceso de desarrollo del software para

asegurar que vamos a obtener un producto de calidad y no

llevarnos sorpresas:

(19)

Aseguramiento de la Calidad Software



El aseguramiento de la calidad se planifica antes de

empezar a desarrollar un producto software.



Las actividades comprendidas dentro del

aseguramiento de la calidad software se aplican

durante todo el proceso de desarrollo.



El aseguramiento de la calidad software aumenta la

(20)



Algunas de las actividades que están involucradas con

el Aseguramiento de la Calidad Software:

 Revisiones Técnicas Formales (RTF) en todos los pasos de desarrollo de software.

 Control de la documentación.

 _{Control de los cambios.}

 Asegurar que se sigue la metodología adoptada.

 Definir mecanismos y técnicas de medida de la calidad.

(21)



Objetivos:

 Satisfacción del cliente: la satisfacción del cliente significa relaciones a largo plazo (opinión positiva del cliente)

 Reducir costes del desarrollo: se lleva a cabo este plan para prevenir defectos e ineficacias del software. La idea es que siguiendo un plan de SQA el plan termine a tiempo y dentro del presupuesto establecido. Se reduce inversión en

pruebas.

 Reducir costes en el mantenimiento: siguiendo un plan de aseguramiento de la calidad del software se generan

(22)



Objetivos:

 Reducir tiempos de desarrollo: se ahorra tiempo en la fase de testing.

 Hace que la gestión de cambio sea más fácil de realizar. (permeabilidad al cambio).

 Asegura los requisitos funcionales que ha solicitado el cliente.

 Asegura que se están siguiendo la metodología de desarrollo adoptada por la organización.

(23)

 ¿Qué debemos hacer para elaborar y seguir un eficaz

Aseguramiento de la Calidad Software?

 _{Primero la planificación del plan de aseguramiento de la} calidad.

 Descripción del sistema.

 Estimación de los objetivos y requisitos del sistema  Gestión de los riesgos elaboración plan contingencia.  Diagrama de Gantt.

 Definir qué características de calidad se van a tener en cuenta a la hora de evaluar la calidad del producto.

 Elegir las herramientas necesarias.

(24)



Para garantizar que el Plan de Aseguramiento de la

Calidad Software se está cumpliendo se realizan

auditorías:



Auditorías internas llevadas a cabo por la misma

empresa



Auditorías externas llevadas a cabo por empresas

ajenas. Normalmente estas empresas expiden

(25)

 Actividades del Plan de Aseguramiento de la Calidad Software

clasificadas por fases:  Fase de análisis:

 Verificar requisitos consistentes.

 Verificar requisitos comprobables y alcanzables.  Versión preliminar de casos de prueba.

 Fase de diseño arquitectónico:

 Inspección de diseño arquitectónico. Estructuras de datos.

Arquitectura modular.

(26)

Aseguramiento de la Calidad Software  Fase de diseño detallado:

 Diseño detallado de módulos.

 Diseño detallado de estructuras de datos.  Actualización del plan de pruebas.

 Actividades en la fase de implementación:  Inspección del software.

 Validar pruebas de unidad.  Finalizar el plan de pruebas.  Fase de integración:

(27)



¿Quién lleva a cabo las actividades de

Aseguramiento de la Calidad Software?



_{Directivos (promueven y motivan)}



Ingenieros software (máximo responsable).

(28)



¿Qué significa que un software sea fiable?

 Que las operaciones que ejecuta (en un entorno determinado y en un tiempo específico) estén libres de fallos.



Las pruebas contribuyen a mejorar la fiabilidad, pero

no la garantizan.



Las pruebas son técnicas estáticas que se aplican a

(29)



Las pruebas a las que puede ser sometido el software

para evaluar su calidad.

 Prueba de validación: se introducen datos de prueba que

sabemos que son erróneos Ejemplo, introducir una cadena de caracteres en un campo numérico.

 _{Comparación de los datos: comparar la salida del sistema a}

partir de unos parámetros con la salida esperada.

 _{Prueba de tensión: se utiliza el software de forma}

exhaustiva y durante mucho tiempo para asegurar que es capaz de aguantar altos niveles de carga.

 Prueba de la utilidad: los usuarios utilizan el software

(30)



Verificación: “¿Estamos construyendo el producto

correctamente?”

 El software debería ajustarse a su especificación



Validación: “¿estamos construyendo el producto

correcto?”

(31)



Todas las evaluaciones y datos extraídos de las

actividades del Aseguramiento de la Calidad

deben ser almacenadas para proyectos futuros

(los resultados de las pruebas, datos sobre

(32)

Modelos de Calidad Software



Los Modelos de Calidad sirven para evaluar la calidad

del producto y/o del proceso.



Son MODELOS y no de METODOLOGÍAS. Un modelo

de calidad nos dice qué hacer pero no el cómo

hacerlo.



Descomponen la calidad de software en una serie de

(33)

Modelos de Calidad Software



Tienen una estructura de 3 niveles:



_{Factores de calidad: nivel más alto. Se definen los}

factores de calidad que se van a medir y evaluar.



_{Criterios de calidad del producto: cada factor se}

descompone en un conjunto de criterios de calidad.

Visión de la calidad desde el punto de vista de

producto.



Métricas del producto: para cada criterio se definen

(34)

Modelos de Calidad Software: Boehm



Presentado por Barry Boehm en 1978.



Presenta una jerarquía de características que sirven

para medir la calidad del producto software.



Características de alto nivel: representan requisitos

generales de uso o usos primarios.



_{Características de nivel intermedio: representan los}

factores de calidad de Bohem.



_{Características primitivas: nivel más bajo que}

(35)

Características de alto nivel Características de nivel

Características primitivas

(36)

Modelos de Calidad Software: McCall



Conocido como modelo de factores/criterios/métricas.



Presentado en 1977.



Se focaliza en el producto software.



Identifica atributos (llamados factores de calidad)

claves desde el punto de vista del usuario.



Los factores de calidad son demasiado abstractos para

ser medidos. Por esta razón, para cada uno de ellos se

introducen atributos de bajo nivel denominados

criterios de calidad.



A cada criterio de calidad se le asigna un conjunto de

(37)

Modelos de Calidad Software: McCall



Define 3 vistas

 vista de usuario: clasifica los factores de calidad.

 _{vista de la dirección: clasifica los criterios de calidad.}  vista del desarrollador: clasifica las métricas de calidad.



Los 3 factores de calidad comprendidos en la vista de

usuario coinciden con 3 de las características de un

producto software:

 Revisión del producto: habilidad para ser cambiado.

(38)

(39)

Modelos de Calidad Software: Paradigma GQM (Goal-Question-Metric)



Paradigma que permite evaluar la calidad del producto y

del proceso.



Evalúa la calidad del software basado en la identificación

de objetivos a lograr.



Tres etapas:



Lista de objetivos principales en el desarrollo y

mantenimiento del proyecto.



Para cada objetivo obtener las preguntas que deben

contestarse para saber si se están cumpliendo los

objetivos.

(40)

(41)

Modelos de Calidad Software: CMM (Capability Madurity Model)



Es motivado por los problemas que tenía el

departamento de defensa de los estados unidos

cuando encargaba el desarrollo de un software a otra

empresa: se disparaban los presupuestos, las fechas se

alargaban.



Convocaron un concurso de participación libre en el

que se proponía resolver esos problemas.



La Universidad Carnegie Mellon ganó el concurso y

(42)



Es un modelo que evalúa los procesos de desarrollo.



Orientado a la mejora de procesos de desarrollo

software.



Describe prácticas que conducen a mejores productos de

software.



Ofrece un conjunto de prácticas importantes que deben

ser implantadas por cualquier entidad que desarrolla o

mantiene software.



CMM tiene como objetivo evaluar los procesos en sus

(43)

 Clasifica las empresas según su nivel de madurez de sus

procesos de desarrollo.

 Existen 5 niveles.

 Nivel 1 - Inicial

 No existe un proceso de desarrollo.  Los presupuestos se disparan.

 No se entrega en plazo.

 Los trabajadores trabajan noches y fines de semana (no hay control temporal)

(44)

Es el típico proyecto en el que se da la siguiente situación:

¿Cómo va el proyecto? - Bien, bien.

Dos semanas después… - ¿Cómo va el proyecto?

- Bien, bien.

Tres semanas después…

- El lunes hay que entregar el proyecto.- No se por qué pero los proyectos se entregan los lunes.

- El lunes !!?. Todavía falta mucho!!

- ¿Cómo? Me dijiste que el proyecto iba bien!! Arréglatelas como quieras, pero el proyecto tiene que estar terminado para el lunes.

(45)

 Nivel 2 – Gestionado o Repetible

 Quiere decir que el éxito de los resultados obtenidos se pueden repetir

 Existe un proceso.

 Existe una planificación.

 El proceso se revisa y se evalúa.

 El proyecto es controlado y gestionado durante el desarrollo.  Desarrollo no opaco (se conoce qué se desarrolla y por quién).  Se puede saber el estado del proyecto en todo momento.

 Nivel más difícil de obtener ya que supone un cambio drástico en la forma de trabajar.

(46)

 Nivel 2 – Gestionado o Repetible

 Los procesos que se implantan en este nivel son:

• Gestión de requisitos.

• Planificación de proyectos (plan de proyecto). • Seguimiento y control de proyectos.

• Gestión de proveedores • Medición y análisis

(47)

 Nivel 3 – Definido

 La forma de desarrollar proyectos (gestión e ingeniería) esta definida, documentada y existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos.

 Los procesos que se implantan en este nivel son:

• Desarrollo de requisitos • Solución Técnica

• Integración del producto • Verificación y validación

• Desarrollo y mejora de los procesos de la organización • Definición de los procesos de la organización

(48)

 Nivel 4 – Cuantitativamente Gestionado

 Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización.

Los procesos que hay que implantar para alcanzar este nivel son:

• Gestión cuantitativa de proyectos

(49)

 _{Nivel 5 – Optimizado}

 Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras

incrementales e innovadoras de los procesos que

mediante métricas son identificadas, evaluadas y puestas en práctica.

Los procesos que hay que implantar para alcanzar este nivel son:

• Innovación organizacional

• Análisis y resolución de las causas.

(50)

 Es un enfoque escalonado.  Para llegar a un nivel

debemos haber conseguido los precedentes.

 La implantación de este

modelo es un proceso

largo y costoso que puede costar varios años de

esfuerzo.

 Aún así el beneficio

(51)

Modelos de Calidad Software: SPICE (Software Process Improvement and

Capability Determination)

 Orientado a la mejora de procesos de desarrollo.

 Es un modelo de madurez de procesos internacional. Se ha

convertido en la ISO/IEC 15504.

 Fomenta productos de calidad, promueve la optimización de

procesos y facilita la evaluación del producto durante el proceso de desarrollo.

 Se aplica tanto a nivel directivo como a nivel de usuario.

 El modelo describe los procesos que una organización puede

ejecutar, adquirir, suplir, desarrollar, operar, evolucionar,

(52)

Certificación



Procedimiento mediante el cual, un determinado

organismo, acredita mediante un documento escrito,

que un servicio, proceso o producto resulta conforme

a unas exigencias.



Nos permite demostrar la excelencia del sistema de

calidad y el proceso de desarrollo que sigue una

empresa.



Podemos considerar la certificación como una garantía

(53)

Certificación



¿Por qué las empresas están interesadas en

certificarse?

 Incentiva el disponer de un sistema de calidad que aumenta la calidad de sus productos.

 Incrementa su prestigio en el mercado. Buena imagen.

 _{Consiguen ventajas competitivas frente a los competidores.}

Se hacen estables.

(54)

 Solicitud: La empresa envía la documentación necesaria a la empresa certificadora.

 Certificación: se evalúa el sistema de calidad que sigue la empresa.

¿Se documenta? ¿Cada cuanto tiempo hay una RTF? ¿existe un estándar de documentación? ¿existe un estándar de variables? ¿se utilizan pruebas de caja negra y de caja blanca?...

 Concesión: Si el sistema de calidad

supera las evaluaciones, la empresa obtendrá el certificado.

 Seguimiento: Periodicamente la

empresa se evalua para ver si aún es merecedora del certificado.

(55)

Certificación

 AENOR (Asociación Española de normalización y

certificación)

 _{Certificado de medio ambiente: Los productos}

certificados deberán fabricarse cumpliendo unos criterios ecológicos y el proceso de fabricación no afecta al medio ambiente.

 _{Certificado de gestión ambiental: los productos}