T03 Garantía de Calidad PDF

Tema 3.
Garantía de Calidad
1. Concepto de Calidad del SW

2. Garantía de Calidad del SW
3. Planificación de la Calidad
4. Control de Calidad del SW
5. Factores de calidad
6. Métricas de Calidad
1
Tema 3. Garantía de Calidad
La ingeniería del software tiene un objetivo principal:

producir software de calidad.
Pero, ¿Qué es la calidad del software?.
“El problema de la gestión de la calidad no es lo que la gente
no sabe sobre ella. El problema es lo que creen que saben...”
El primer concepto que debemos analizar es el de
calidad, ¿Qué es un producto de calidad?
La calidad es una característica o atributo de algo.
La calidad de un objeto físico es mensurable, sin
embargo, el software es una entidad intelectual.
2
La calidad del software se define como:

Concordancia con los requisitos funcionales y no-
funcionales explícitamente establecidos, con los
estándares de desarrollo explícitamente documentados,
y con las características implícitas que se espera de todo
software desarrollado profesionalmente.
De esta definición de calidad podemos extraer algunos
puntos importantes:
Los requisitos del software son la base de las medidas
de la calidad.
Debe existir un conjunto de criterios de desarrollo, que
guían la forma en que se aplica la ingeniería del
software.
Existe un conjunto de requisitos implícitos que a menudo
no se mencionan, pero que también deben ser
alcanzados.
3
La medición de la calidad nos lleva a clasificarla en dos

tipos:
Calidad de diseño: características que especifican los
ingenieros de software para un programa. Si se imponen
tolerancias más estrictas y mayor rendimiento, la calidad
de diseño aumenta.
Calidad de concordancia: grado de cumplimiento de las
especificaciones de diseño durante su realización.
Aumentando el nivel de cumplimiento aumentamos la
calidad de concordancia.
La Calidad de Diseño acompaña a los requisitos,
especificaciones y diseño del sistema.
La Calidad de Concordancia se centra principalmente
en la implementación.
4
Gestión de la Calidad
Asegurar el nivel requerido de calidad es conseguido
por el producto
Definir estándares y procedimientos de calidad y
asegurar su seguimiento
Desarrollar la cultura de calidad: responsabilidad de
todos los implicados
Separada de la Gestión de Proyectos
Proceso de desarrollo
Software
D1 D2 D3 D4 D5
Proceso de Gestión de
Calidad
Estándares y Plan de Informes de

procedimientos calidad revisiones
5

Los detalles concretos de un sistema de gestión de
calidad se recogen en el Manual de Calidad:
Contiene estándares(internacionales) para desarrollar
actividades que pueden ser aplicadas en los proyectos.
ISO 9001
Proporciona guías para
Sistema de gestión de calidad
Manual de Calidad
Estándares
Procedimientos
Proyecto Proyecto Proyecto

Plan de Calidad Plan de Calidad Plan de Calidad
6
Cuando un proyecto está definiéndose:
El gestor del proyecto identifica los factores de calidad
que son importantes.
Extrae del manual de calidad aquellos estándares y
procedimientos que son necesarios para asegurar que el
producto a desarrollar tendrá en cuenta dichos factores.
Estos factores quedan reflejados en el plan de calidad
del proyecto.
Un plan de calidad contiene:

Una lista de tareas (por ejemplo, la aplicación de un test
de sistema concreto), cuando y quien la realiza, ...
Estándares a ser adoptados
Herramientas que se usarán,
Etc...
7

Ejemplo: para un proyecto, el gestor decide que la
portabilidad va a ser un factor de calidad.
Consulta el manual para incorporar al plan de calidad del
proyecto aquellas partes que influyan en la portabilidad.
El manual puede contener:
− Descripciones de lenguajes para no usar características no
estándares.
− Pruebas para probar la portabilidad en varios ordenadores
y S.O.
− Chequeos de los resultados de herramientas propietarias
para buscar rasgos no portables.
− Desarrollo de técnicas, como la encapsulación, que
proporcionen un alto grado de portabilidad.
8
El plan de calidad contendrá controles de calidad que
comprueben que los factores están presentes en los
productos.
Control de calidad ≈ evidencias documentales
Ejemplos:
Controles Evidencias Factor

Documentales
Test de sistema Registros del test Corrección
Revisiones de código Las minutas firmadas por los Portabilidad

probando la portabilidad revisores
La ejecución de una La salida impresa de la Mantenibilidad
herramienta que prueba si herramienta indicando la
se cumplen ciertos ausencia de violaciones del
estándares de estándar.
programación
9

Actividades de Gestión de la Calidad SW
Garantía de calidad: auditoria y funciones de información de la
gestión
Objetivo: proporcionar la gestión para informar de los datos
necesarios sobre la calidad del producto.
Si los datos proporcionados por la garantía de calidad
identifican problemas, la gestión debe afrontarlos y resolverlos.
Planificación de la calidad: selección de los procedimientos y
estándares apropiados desde el marco proporcionado por la
garantía de calidad y la adaptación de estos a un proyecto concreto
Control de calidad: serie de inspecciones, revisiones, y pruebas
utilizados a lo largo del ciclo de desarrollo para asegurar que un
producto cumple con los requisitos que le han sido asignados
Incluye el bucle de realimentación (feedback).
El control de calidad es parte del proceso de desarrollo.
Coste de calidad: incluye todos los costes acarreados en la

búsqueda de la calidad o en las actividades relacionadas con la
obtención de calidad.
10
Coste de Calidad
Incluye costes tanto de la búsqueda de calidad como de las
acciones realizadas para su obtención.
Los costes de calidad pueden dividirse según el enfoque en:
Costes de prevención: Planificación de la calidad, revisiones
técnicas formales, equipo de pruebas, formación.
Costes de evaluación: visión de la calidad real del producto. Ej:
Inspección en el proceso y entre procesos, calibrado y
mantenimiento del equipo.
Costes de fallos, que pueden dividirse en :
− Internos: errores antes de la entrega del producto al cliente. Ej:
Revisión, reparación, análisis de las modalidades de fallos.
− Externos: errores o defectos detectados después del envío al
cliente. Ej; Resolución de quejas, devolución y sustitución de
productos, soporte de línea de ayuda, trabajo de garantía.
Los costes relativos de calidad aumentan rápidamente de
prevención a detección y de error interno a externo.
11

Calidad Total
El término TQM (Total Quality Management) se acuña en 1985
para describir el estilo japonés de incremento de calidad.
Representa un estilo de gestión movido por conseguir éxito a
largo plazo enlazando calidad y satisfacción de usuario.
Creación de cultura de empresa
La adopción de ISO 9000 como estándar de gestión de calidad en
la Unión Europea ilustra la importancia de esta filosofía.
Ejemplos implementación exitosa de una estrategia TQM:
Hewlett-Packard’s Total Quality Control (TQC) Define
estrategias y planes para cada área (responsabilidad de
gestión, liderazgo, cliente, participación total, etc.) para
conducir un incremento de calidad, eficiencia y
responsabilidad.
Motorola’s Six Sigma Strategy Se centra en conseguir
niveles estrictos de calidad para obtener la satisfacción del
usuario.
IBM’s Market Driven Quality Lema: “El cliente es el árbitro
final”.
12
Calidad Total
Los elementos clave de TQM pueden resumirse en:
Orientado al cliente:
− Objetivo: conseguir una satisfacción total del cliente.
− Incluye: estudios de las necesidades de los clientes, recolección
de requisitos de cliente y medida y gestión de su nivel de
satisfacción.
Procesos:
− Objetivo: reducir las variaciones del proceso y conseguir una
mejora continua del proceso.
− Incluye: los procesos de negocio y los procesos de desarrollo del
producto.
Parte humana de la calidad:
− Objetivo: crear una cultura de calidad global a la compañía.
− Áreas objetivo: dirección, participación total, otorgar poderes a los
empleados y otros factores sociales, psicológicos y humanos.
Medida y análisis:
− Objetivo: conducir la mejora continua en todos los parámetros de
calidad
13 − Uilizan: sistema de medidas orientadas al objetivo.

Calidad Total
Gestión total de la calidad

Mejora continuada
Focalizado en Mejora de Parte humana

el cliente procesos de la calidad
Métricas, modelos, medidas y análisis
Una organización que practique TQM debe tener una

jefatura ejecutiva, y debe centrarse en infraestructura,
entrenamiento y educación, además de realizar
planificación estratégica de calidad.
14
Calidad Total
Varios marcos organizacionales para sustentar la filosofia TQM:
Plan-Do-Check-Act: Proceso de mejora de la calidad basado
en un ciclo de retroalimentación para optimizar un único
proceso de producción.
Quality Improvement Paradigm (QIP):Construir una
organización que mejora continuamente, basándose en sus
objetivos evolutivos y el aseguramiento de su estado relativo a
esos objetivos.
− Técnica Goal/Question/Metric.
SEI Capability Maturity Model: Proceso de mejora dividido en
fases y basado en la valoración con respecto a un conjunto
áreas clave de proceso. Objetivo:
− Nivel 5 donde se alcanza una mejora continuada de procesos
− Conseguir mejora continuada de procesos mediante prevención
de defectos, innovaciones tecnológicas y gestión del cambio de
procesos
Lean Enterprise Management: Basado en el principio de
concentración de la producción en actividades de valor
15 añadido.

La calidad de un producto debe asegurarse:
Garantía de Calidad del SW (SQA, Software Quality
Assurance).
La garantía de calidad del software (SQA) es un “diseño de
acciones planificado y sistemático” que se requiere para asegurar
la calidad del software:
Estandares internacionales, nacionales, organizacionales o de
proyecto
− Encapsulación de buenas prácticas evita errores pasados
− Marco para proceso de garantía de calidad: chequear el
cumplimiento del estandar
− Proporcionar continuidad: nuevo staff comprende la organización
comprendiendo los estandares aplicados
− Problema: Burocracia, No soporte automático, No visto como
relevante y actualizable por los ingenieros de SW
Estándares de producto: características que todos los
componentes deberían exhibir. Ej. Estilo de programación común
Estándares de proceso: como el proceso debería ser realizarse
16
Actividad de protección que se aplica a todo el proceso de

ingeniería del software, englobando los siguientes aspectos:
Enfoque de gestión de calidad.
Tecnología de ingeniería del software efectiva.
Revisiones técnicas formales que se aplican durante el
proceso del software.
Estrategia de prueba multiescalada.
El control de la documentación del software y de los cambios
realizados.
Proc. de aseguramiento delos estándares de desarrollo del SW
Mecanismos de medición y de generación de informes.
El grupo de SQA debe:
Inspeccionar el software desde el punto de vista del cliente.
Preguntarse: ¿satisface los factores de calidad?, ¿se han
seguido los estándares?, etc.
17

Actividades
Existen gran variedad de tareas, realizadas tanto por:
los ingenieros de software: realizan el trabajo técnico,
− aplican métodos sólidos y medidas, realizan revisiones y llevan a
cabo pruebas de software.
por el grupo de SQA: planifican el proceso de garantía de
calidad, supervisión, mantenimiento de registros, análisis e
informes.
− Establecimiento de un plan de SQA para un proyecto.
− Participación en el desarrollo de la descripción del proceso de
software del proyecto.
− Revisión de las actividades de ingeniería del software para
verificar su ajuste al proceso de software definido.
− Auditoría de los productos de software designados para verificar el
ajuste con los definidos como parte del proceso de software.
− Asegurar que las desviaciones del trabajo y los productos del
software se documenten y se manejen de acuerdo con un
procedimiento establecido.
− Registrar lo que no se ajuste a los requisitos e informar a sus
superiores.
18
Calidad de Producto y Proceso
Calidad de un producto influenciada por la calidad del proceso:
Importante por la dificultad para evaluar los atributos de calidad
de un producto
Dificultad para establecer relación entre producto y proceso
SW:
− Aplicación de habilidades y experiencias individuales
− Factores externos como la novedad de la aplicación
Desarrollar
Desarrollar
Definir
Definirproceso
proceso Evaluar
EvaluarCalidad
CalidadProducto
Producto
Producto
Producto
NO SI
Mejorar
Mejorarproceso
proceso Calidad
CalidadOK
OK Estandarizar
EstandarizarProceso
Proceso
Prácticas de calidad de proceso:

Definir estándares de proceso tales como revisiones
Monitorizar el proceso de desarrollo para asegurar el
seguimiento de los estándares
Informar del proceso a la gestión de proyectos
19
3. Planificación de la Calidad
Un plan de calidad fija las calidades deseadas de

producto y como estas son evaluadas y define los
atributos más significativos
Debería definir el proceso de evaluación de calidad
Debería establecer que estándares organizacionales
deberían ser aplicados y, si son necesarios, los nuevos
RUP:
Durante la fase de inicio
Plan Garantía de Calidad

Plan de Medidas
20
Chequear el proceso de desarrollo para asegurar que los
procedimientos y estándares se cumplen
Dos aproximaciones:
Revisiones de calidad
Software de Evaluación y Medida Automatizado
Revisiones: filtro para el proceso de ingeniería del software.
Se aplican en varios momentos del desarrollo del software.
Corrigen errores del análisis, diseño y codificación
Ante el hecho de que se producen errores, es bueno que otras
personas revisen el trabajo
Se trata de aprovechar la diversidad para: señalar necesidades,
confirmar partes del producto, conseguir uniformidad
Existen muchos tipos de revisiones:
Reunión al lado de la máquina de café.
Presentación formal de un diseño de software.
Revisiones técnicas formales(RTF)
21

Revisiones: Impacto de los defectos
Dentro del contexto software, el término defecto y fallo son
sinónimos.
Implican un problema de calidad.
Objetivo primario de las RTF: encontrar errores durante el proceso
de forma que no se conviertan en defectos después de la entrega
del software.
La detección y eliminación de un gran porcentaje de
errores se reduce el coste en los pasos siguientes del
desarrollo y mantenimiento.
Se puede usar un modelo de ampliación de defectos para
ilustrar la generación y detección de errores.
ETAPA DE DESARROLLO
Defectos Detección
Errores de Errores amplificados Porcentaje de

Errores pasados al
1:x eficiencia de la
Pasos Errores inadvertidos detección de errores
siguiente paso
anteriores
Errores nuevamente
generados
22
Revisiones: RTF
Una revisión técnica formal es una actividad de garantía de calidad
del software que es llevada a cabo por los ingenieros del software.
Objetivos: descubrir errores, verificar requisitos, garantizar el
seguimiento de los estándares, conseguir uniformidad y aumentar
su manejabilidad.
Las reuniones de revisión:
Deben convocarse entre tres y cinco personas.
Se debe preparar por adelantado (no mas de dos horas de
trabajo para cada persona).
Debe durar menos de dos horas.
Se inspecciona una parte concreta del software (limitación del
centro de atención).
Cuando se finaliza un producto (modulo), el desarrollador lo
comunica al jefe de proyecto, para que este informe al jefe de
revisión, que organiza la revisión del producto finalizado.
Todos los resultados de la revisión quedan registrados.
Lista de sucesos de revisión.
23 Informe de revisión.

Revisiones: RTF
Directrices para la revisión:
Revisar el producto, no al productor.
Fijar una agenda y mantenerla.
Limitar el debate y las impugnaciones.
Enunciar áreas de problemas, pero no intentar resolver
cualquier problema que se ponga de manifiesto.
Tomar notas escritas.
Limitar el número de participantes e insistir en la
preparación anticipada.
Desarrollar una lista de comprobación para cada
producto que haya de ser revisado.
Disponer recursos y una agenda para las RTF.
Llevar a cabo un buen entrenamiento de todos los
revisores.
Repasar las revisiones anteriores.
24
La calidad es una característica subjetiva.

Para el cliente, un producto de calidad es aquél al que
puede colocar la etiqueta “fitness for purpose”.
Factor de calidad (también llamados parámetros de
calidad): cualidad cuya presencia o ausencia en un
producto software condiciona su calidad.
Factores externos:
− Detectados por los usuarios.
− Son los factores que realmente interesan (objetivo).
Factores internos:
− Únicamente percibidos por los desarrolladores.
− Un medio para conseguir la calidad externa.
25
5. Factores de calidad.
Desde un punto de vista más formal, podemos decir que un
producto software es de calidad si cumple o tiene algunos o todos
de los siguientes factores de calidad:
Corrección: cumple la especificación de requisitos.
Mantenibilidad: facilidad para cambiar el software.
Portabilidad: esfuerzo para trasladar el software a otra
plataforma.
‘Testabilidad’: facilidad para probar que el SW es correcto.
Facilidad de uso: esfuerzo para aprender, usar e interrumpir
un sistema en marcha.
Confiabilidad: capacidad para continuar el trabajo aunque
haya interrupciones. (sistemas seguros)
Eficiencia: recursos que se necesita para la aplicación.
Integridad: datos y sistemas inaccesible por personas no
autorizadas.
Reusabilidad: facilidad para reutilizar cosas en otros
proyectos.
26 Interoperabilidad: habilidad para operar con otros sistemas.
Factores de calidad de McCall
Facilidad de mantenimiento ¿Puedo arreglarlo? Portabilidad ¿Podré usarlo?
Flexibilidad ¿Puedo cambiarlo? Reusabilidad ¿Podré reusar algo de SW?
Facilidad de prueba ¿Puedo probarlo? Interoperabilidad ¿Podré hacerlo interactuar con otro?
Revisión de Transición de
producto producto
Operaciones de
producto
Corrección ¿Hace lo que quiero?
Fiabilidad ¿Lo hace de forma fiable todo el tiempo?
Eficiencia ¿Se ejecutará en mi hardware lo mejor que pueda?
Integridad ¿Es seguro?
Facilidad de uso ¿Puedo ejecutarlo?
Otros ejemplos:
Hewlett-Packard se centra en FURPS (Funcionality, usability,
reliability, performance and serviceability).
IBM monitoriza el nivel de satisfacción CUPRIMDSO. (capability,
usability, performance, reliability, installability, maintainability,
27 documentation/information, service, and overall)
6. Métricas de Software
La medición es crucial en el progreso de cualquier ciencia.
La afirmación “cuanto más rigurosas sean las primeras fases
de desarrollo mejor calidad se obtendrá al final”, ¿cómo se
puede confirmar?.
Teoría Concepto
Mundo
abstracto Proposición Definición
Mundo
Definición
empírico Hipótesis
operacional
Medida en el mundo
Análisis de datos
real
Los bloques de construcción de una teoría son conceptos y
definiciones.
Una definición operacional detalla las métricas y procedimientos a
usar para obtener datos.
28
Niveles de medición
Antes que nada necesitamos considerar la escala de medida.
Escala nominal (nominal scale):
Clasificación en categorias dependiendo de algún atributo.
Ej: Clasificar productos software en función del proceso de
desarrollo utilizado: cascada, espiral iterativo, OO y otros.
Se requiere exhaustividad conjunta y exclusión.
No existen relaciones de orden.
Escala ordinal (ordinal scale):
Operaciones de medida en las que los sujetos pueden
compararse en orden.
Ej: Clasificar los proyectos de software dependiendo de su
rigor: cumplimiento total, cumplimiento parcial y sin
cumplimiento.
No hay información acerca de la magnitud de la diferencia
entre elementos.
En ocasiones, en el mundo real se asume que las distancias
son iguales y se permiten aplicar operaciones como la media
29 (ej. escalas de cinco, siete o diez puntos de Likert).
Niveles de medición
Escalas de intervalo y proporción (ratio):
Una escala de intervalo puede indicar las diferencias exactas entre los
puntos de medida.
Permite aplicar operaciones de suma o resta.
Ej: si el defectos del producto A son 5 defectos por KLOC y el B 3.5
por KLOC, podremos decir que el nivel de defectos de A es 1.5
defectos por KLOC mayor que el de B.
Cuando se puede localizar un cero absoluto o no arbitrario en la
escala de intervalo, se convierte en una escala de ratio.
El ratio está en el nivel superior de las medidas y se le pueden aplicar
todas las operaciones.
Ej: la medición de la temperatura: si la diferencia entre la temperatura
media de invierno (5) y verano (20) son 15 grados, podríamos decir
también que la temperatura de verano es cuatro veces más cálida que
la de invierno.
Excepto para ciertos ejemplos casi todas las medidas de intervalo lo
son de ratio.
Una medida de más alto nivel siempre puede convertirse a una de
menor (cálida, templada, fría).
30
Medidas básicas
Ratio:
Resulta de dividir una cantidad entre otra. El numerador y
denominador son de poblaciones distintas y mutuamente exclusivas.
Ej: el ratio testeadores/desarrolladores puede variar entre 1:1 y 1:10.
Proporción:
Se diferencia del ratio en que el numerador es una parte del
denominador.
p=a/(a+b)
Más apropiado para grupos de categorias.
Cuando las medidas no son en enteros se denomina fracción.
Porcentaje:
Una proporción o fracción expresada en términos de cientos de
unidades. p=100p %.
Los errores de requisitos fueron el 15% del total, los de diseño el 25%,
los de codificación el 50% y otros errores el 10%.
El proyecto consiste en 8 KLOC. Durante su desarrollo se detectaron
y corrigieron 200 defectos, dando un ratio de 25 defectos por KLOC.
De los 200 defectos, el 15% fueron de requisitos, el 25% de diseño, el
50% de codificación y otros errores el 10%.
31
Medidas básicas
Porcentaje (cont.):
El porcentaje debe usarse únicamente con un número alto de
casos.
− Dependiendo del número de categorías, nunca menor de 30.
− Se deben usar valores absolutos.
Tasa (rate):
Asociado con el dinamismo (cambio) del fenómeno de interés.
Generalmente puede definirse como una medida del cambio
de una cantidad y por unidad de otra cantidad x.
Ej: tasa de nacimientos en demografía:
(Nacimientos/Población)*K.
Ej: ratio de defectos=(Nº de defectos/oportunidades de
error)*K.
32
Medidas básicas
Seis sigma:
Introducida por Motorola a finales de los 80: 1er. premio nacional de
calidad (MBNQA).
Representa un nivel riguroso de calidad.
Tasa de error específica: 3.4 partes defectuosas por millón (ppm)
Concretamente, representa el área que queda bajo una distribución
normal en el intervalo [-6σ,+6σ] (suponiendo media cero).
Si tomamos el área dentro de seis sigma como un porcentaje de

partes libres de error tenemos que seis sigma es igual a dos partes
defectuosas por millardo, o 0.002 parte por millón.
Objetivo: producir partes o prod. SW en los límites de la especificación
Si las variaciones en el proceso de producción están dentro de seis
sigma diremos que tenemos un nivel de calidad seis sigma.
33
Medidas básicas
Seis sigma (cont.):
En la realidad, debido a variaciones en la ejecución de un
proceso existe un desplazamiento.
El desplazamiento máximo es 1.5 σ (Harry, 1989).
La definición estandar
para seis sigma es 3.4
ppm
34
Fiabilidad y validez
Fiabilidad: consistencia entre un número de medidas hechas
usando el mismo método de medida al mismo sujeto.
Una definición operacional vaga puede provocar una fiabilidad
baja.
Índice de variación (IV)
IV = Desviación estándar / media
Validez: cuando la medida o métrica mide realmente lo que se
pretende.
Cuando la medida es simple se convierte en precisión.
Se definen varios tipos de validez:
− De construcción: validez de la medida operacional que representa
la medida teórica
− De criterio: validez predictiva
− De contenido: si una medida cubre el rango posibilidades del
concepto medido
35
Errores de medición
Dos tipos de errores:
Sistemáticos (validez).
Aleatorios (fiabilidad).
En general:
M=T+s+e
M es el resultado
T es el valor verdadero
s es el error sistemático
e es el error aleatorio
Si el error es aleatorio, se puede asumir que la media es cero: E(e)=0.
E(M)= E(T) + E(e)
= E(T) + 0
= E(T) + 0
=T
Lo que se debe asegurar es la fiabilidad:
Método de reprueba: volver a realizar la misma medida un tiempo
después y calcular la correlación entre la primera y segunda medida.
36
Las métricas de software pueden clasificarse en tres categorías:
Métricas de producto.
− Describen características del producto.
Métricas de proceso.
− Usadas para mejorar el proceso software de desarrollo y
mantenimiento.
Métricas de proyecto.
− Describen las características del proyecto y su ejecución.
Las métricas de calidad son un subconjunto de las métricas de
software, que se enfocan a medir los aspectos de calidad.
Las métricas de calidad del software pueden dividirse también en:
Métricas del producto final (end-product).
Métricas de desarrollo (in-process).
La esencia de la ingeniería de calidad es investigar la relación
entre las métricas in-process, de proyecto y del producto final.
Calidad software:
Intrínseca del producto
37 Satisfacción del cliente
Métricas de Calidad del Producto
Calidad software:
Intrínseca del producto
Satisfacción del cliente
Calidad de producto:
Tiempo medio de fallo
Densidad media de defectos
Problemas del cliente
Satisfacción del cliente
38
Mét. de Calidad del Producto: Densidad de Defectos
La tasa de defectos se define como el número de defectos sobre

las oportunidades de error durante un determinado tiempo.
Se usa el numero de causas únicas de fallos observados para
aproximar el número de defectos.
El denominador es el tamaño del software (KLOC
generalmente).
El marco temporal varia de uno a muchos años después de la
disponibilidad del software.
− Más del 95% de los defectos se encuentra en los primeros cuatro
años. IBM utiliza 4 años como vida del producto (LOP).
Problema a la hora de comparar: definir operacionalmente LOC.
¿Código ensamblador?.
¿Código de alto nivel?.
− Líneas ejecutables.
− Líneas ejecutables + definición de datos.
− Líneas ejecutables + definición de datos + comentarios.
− Líneas ejecutables + definición de datos + comentarios + jdl.
− Contar líneas físicas (en la pantalla).
39 − Contar líneas lógicas (buscar delimitadores).
Mét. de Calidad del Producto: Densidad de Defectos
Ejemplo IBM Rochester:

Esta división cuenta las líneas de código como sentencias
(incluyendo código y definición de datos pero no comentarios).
Se mide LOC para producto total y código nuevo o cambiado.
SSI (versión actual) = SSI (versión previa) + CSI (instrucciones
nuevas y cambiadas para la nueva versión) - código borrado
(generalmente poco) - código cambiado (para evitar conteo
duplicado en SSI y CSI)
Métricas:
− APARs = defectos identificados después de la distribución del SW
− TVUA/KSSI (APARs en el informe de la versión)
− TFVUA/KSSI (APARs de campo)
− TVUA/KCSI (APARs en el informe de la versión)
− TFVUA/KCSI (APARs de campo origen)
− Donde:
– TVUA= APARs total válidos únicos
– TFVUA= APARs de campo válidos únicos
– KSSI= miles de instrucciones totales
40 – KCSI= miles de instrucciones nuevas/cambiadas

Mét. de Calidad del Producto: Problemas del cliente
Desde el punto de vista del cliente, los problemas que encuentra

utilizando el programa, no solamente los válidos, son problemas
con el software.
Generalmente esta métrica se expresa en problemas por usuario y
mes (PUM):
PUM= Problemas totales de los que informan los usuarios para
un periodo de tiempo / Número total de licencias-mes del
software durante ese periodo.
Licencias-mes = Número de licencias instaladas x número de
meses del periodo de cálculo.
Para rebajar el PUM se eligen diferentes aproximaciones:
Mejorar el proceso de desarrollo.
Reducir los problemas no orientados a defectos (usabilidad,
documentación, formación, soporte, etc).
Incrementar el número de ventas.
El control de PUM puede no estar bajo el control total de los
desarrolladores.
41 No es aconsejable marcar una restricción.
Mét. de Calidad del Producto: Problemas del cliente
Defectos/KLOC PUM
Numerador Defectos válidos y únicos Todos los problemas del
en el producto cliente (no defectos y
repetidos)
Denominador Tamaño del producto Uso del producto por el
cliente
Perspectiva de medida Productor (Organización Cliente
de desarrollo)
Alcance Calidad intrínseca Calidad intrinsica más
otros factores
Representan dos perspectivas de la calidad del producto.

Si se mezclaran denominadores y numeradores se obtendrían
métricas pobres (ej. problemas de cliente/tamaño del producto).
La métrica de problemas de cliente es una medida intermedia entre
la tasa de defectos y la satisfacción del usuario.
42
Mét. de calidad del producto: Satisfacción del cliente
Se mide frecuentemente mediante encuestas al cliente y con una escala

de cinco puntos:
Muy satisfecho Insatisfecho
Satisfecho Muy insatisfecho
Neutro
Se pueden construir varias métricas a partir de las encuestas:
% de clientes totalmente satisfechos.
% de clientes satisfechos.
% de clientes insatisfechos (insatisfechos y muy insatisfechos).
% de clientes no satisfechos (neutrales, insatisfechos y muy
insatisfechos).
También aproximaciones ponderadas: Net satisfaction index (NSI)
Muy satisfecho. 100%
Satisfecho. 75%
Neutro. 50%
Insatisfecho. 25%
Muy insatisfecho. 0%
43
Mét. de calidad del producto: Puntos función
Surge con el fin de estandarizar la medida operacional del tamaño.

Función: colección de sentencias ejecutables que realizan una
tarea, junto con la declaración de parámetros y variables locales.
Es un total ponderado de cinco componentes principales:
Número de entradas externas x 4
Número de salidas externas x 5
Número de archivos lógicos internos x 10
Número de archivos externos x 7
Número de consultas externas x 4
También hay pesos para la complejidad:
Complejidad baja Complejidad alta
Entradas externas 3 6
Salidas externas 4 7
Archivos lógicos internos 7 15
Archivos externos 5 10
Consultas externas 3 6
44
Primer paso: calcular el número de funciones (FC).

5 3
FC = ∑∑w
i =1 j =1
ij × x ij
donde wij son los pesos (cinco componentes y

complejidad baja, media o alta) y xij el número de cada
componente en la aplicación.
Segundo paso: usar una escala de 0 a 5 para calcular
el impacto de 14 características generales en función
de su impacto en la aplicación
Comunicación de datos. Actualización en línea.
Funciones distribuidas. Procesamiento complejo.
Rendimiento. Reusabilidad.
Configuración de uso frecuente. Fácil instalación.
Transacciones. Fácil operación.
Entrada de datos en línea. Ubicaciones múltiples.
Eficiencia de usuario final. Facilitación del cambio.
45
El resultado de estas características se obtiene

mediante (Value Adjustment Factor):
14
VAF = 0.65+ 0.01∑ci
i =1
Finalmente el número de puntos función se obtiene

multiplicando el número de funciones y el valor de
ajuste:
FP = FC × VAF
Esta ecuación es una simplificación del cálculo de
puntos función.
− Consultar, por ejemplo, el International Funcion Point
User´s Group Standard para obtener un tratamiento
completo.
− http://ftp.tuwien.ac.at/softeng/lambs-
archive/www/funcpoints.html
46
Mét. de Cal. Desarrollo: Densidad Defectos Durante Pruebas
La tasa de defectos durante las pruebas de sistema generalmente

está correladas positivamente con la tasa de defectos de campo
(clientes).
La densidad de defectos software nunca sigue la distribución
uniforme.
Cuantos más defectos se detecten durante las fases de
prueba, más defectos se encontrarán más tarde.
La simple métrica de defectos por KLOC es un buen indicador de la
calidad mientras que el software se está probando.
Útil cuando se desarrollan versiones sucesivas (comparación).
Se pueden utilizar dos escenarios para juzgar la calidad de un
producto:
Tasa de defectos igual o menor que la de versiones anteriores.
− ¿Se ha deteriorado la fase de prueba?
Tasa de defectos mayor que la de versiones anteriores.
− ¿Se planificó un incremento de la efectividad de las pruebas?
47
Mét. de Cal. Desarrollo: Patrón de llegada de errores
El patrón de llegada de errores (tiempo entre fallos) indica diferentes

niveles de calidad.
El objetivo es que la llegada de defectos:
Se estabilice a un nivel muy bajo.
O que el tiempo entre fallos sea tan alejado como sea posible.
La unidad de tiempo es generalmente semanas (ocasionalmente meses).

Existen tres métricas ligeramente diferentes:
Llegada de defectos (válidos o no) durante la fase de prueba por
intervalo de tiempo.
Patrón de llegadas de defectos válidos.
Patrón de tiempo de retraso de los defectos. Permite analizar la carga
48 de trabajo así como medida de calidad.
Mét. Cal. Desarrollo: Patrón eliminación defectos (por fase)
Extensión de la métrica de densidad de defectos.

El patrón de eliminación de defectos por fase refleja la capacidad
de eliminación de defectos del proceso de desarrollo.
Para las fases de diseño y codificación se utilizan también métricas
como el esfuerzo de inspección o la cobertura de inspección.
En el ejemplo (IBM):
Proyecto A: carga inicial.
Proyecto B: dependiente de la fase de prueba.
A da mejor rendimiento que B.
49
Mét. Cal. Desarrollo: Efectividad de la eliminación de errores
La efectividad de eliminación de defectos puede definirse como:

Defectos eliminados durante una fase de desarrollo
DRE = × 100 %
Defectos latentes en el producto
Puesto que el número de defectos latentes no se conoce el
denominador únicamente puede estimarse.
Normalmente: Defectos Latentes = Defectos eliminados +
defectos encontrados más tarde
La métrica puede calcularse para:
El proceso de desarrollo completo.
Para el front end: Eliminación temprana de defectos
Una fase específica: Efectividad de fase.
Cuanto más alta sea esta métrica más efectivo es el proceso de
desarrollo y menor el número de errores que pasa a fases
siguientes o al cliente.
50
Métricas de mantenimiento: Retardo de las correcciones
Medida de la carga de trabajo para el mantenimiento del software.

Se relaciona con la tasa de llegada de defectos y la tasa con que
se generan correcciones.
Es simplemente la medida de problemas que permanecen abiertos
al final de cada mes o semana.
Otra métrica relacionada es el índice de gestión de retardos (BMI).
Problemas cerrados durante el mes
BMI = × 100%
Problemas surgidos durante el mes
Si BMI:
es mayor que 100, el retardo se reduce.
si es menor, el retardo aumenta.
Se debe examinar el gráfico de evolución del BMI junto con los
gráficos de evolución de llegada de defectos, errores cerrados y
número de problemas en el retardo.
51
Métricas de mantenimiento: Retardo de las correcciones
En el ejemplo se muestra el gráfico de errores abiertos

y cerrados y un pseudo diagrama de control para el
BMI.
Comienza desde la distribución de una nueva versión.
Subida/bajada de la llegada/cierre de problemas.
La media resulta 102.9% (se cumple el objetivo).
52
Métricas de mantenimiento:Tiempo de respuesta
En numerosas ocasiones las compañías establecen un límite

temporal para disponer de la solución a un problema.
El criterio está de acuerdo con la severidad del problema.
Para problemas de software que pongan en riesgo el
negocio el límite será bajo.
Esta métrica se calcula generalmente, para todos los problemas o
por nivel de severidad, de la siguiente forma:
Tiempo medio de todos los problemas
desde su apertura hasta su cierre
Si hay puntos con valores extremos se usa la mediana en vez de la
media.
Se evitan problemas con defectos con los que los
clientes puede estar satisfechos y no requieran una
corrección.
53
Métricas de mantenimiento: Porc. de correcciones delictivas
La media (o mediana) del tiempo de respuesta es una

medida de tendencia central. Una métrica sensible es el
porcentaje de correcciones delictivas.
Si el tiempo para una corrección excede el límite
especificado, se clasifica como delincuente:
Correccion es que exceden el límite temporal
PDF = × 100 %
Total de correccion es a tiempo
No es una métrica para tiempo real (utilizada para

problemas cerrados).
Para tiempo real se recomienda usar ésta métrica en el
retraso activo (todos los problemas abiertos para una
semana, anteriores más los detectados).
54
Métricas de mantenimiento: Calidad de las correcciones
Un indicativo importante de la calidad de la fase de mantenimiento

es la métrica de calidad de correcciones.
Es malo que los clientes encuentren errores en el software, pero
por aún es que los encuentren en las correcciones.
Es simplemente el tanto por ciento de correcciones defectuosas
respecto de todas las correcciones (en un intervalo de tiempo).
Una corrección se considera defectuosa cuando no corrige el
defecto para el que se creo u origina un nuevo defecto.
Puede tenerse en cuenta:
En el mes en que se produce el error.
− Medida del cliente.
En el mes en el que se distribuye la corrección.
− Medida del proceso.
La métrica debe utilizar la cuenta de errores y no el tanto por
ciento, con el fin de no ocultar un número de correcciones
defectuosas relativamente alto (objetivo cero).
55
Ejemplo de programa de métricas
Programa de Motorola.
Sigue el paradigma Objetivo/Pregunta/Métrica de Basili y Weiss
(1984).
Identifica objetivos.
Se formulan preguntas en términos cuantificables.
Se establecen métricas.
Objetivos y áreas de medición identificadas en el Motorola Quality
Policy for Software Development (QPSD):
Objetivos.
− Mejorar la planificación del proyecto.
− Incrementar la contención de defectos.
− Incrementar la fiabilidad del software.
− Decrementar la densidad de errores.
− Mejorar la atención al cliente
− Reducir el coste de la no conformidad.
56 − Incrementar la productividad del software.
Áreas de medición.
− Defectos distribuidos y distribuidos por tamaño.
− Efectividad total a lo largo del proceso.
− Adhesión a la planificación.
− Precisión de la estimación.
− Defectos distribuidos y distribuidos por tamaño.
− Efectividad total a lo largo del proceso.
− Adhesión a la planificación.
− Precisión de la estimación.
Para cada objetivo se realizan unas preguntas y se
formulan las métricas correspondientes.
57
Objetivo 1: Mejorar la Objetivo 2: Incrementar la contención de
planificación del proyecto. defectos.
Pregunta 2.1: ¿Cuál es la efectividad
Pregunta 1.1: ¿Cuál fue la conocida del proceso de detección de
precisión de la estimación defectos anterior a la distribución?
del valor actual de la − Métrica 2.1: Total Defect Containment
planificación del proyecto? Effectiveness (TDCE)
−
Número de defectos antes de la distribución
Métrica 1.1: Schedule TDCE =
Número de defectos antes +
Estimation Accuracy (SEA)
Número de defectos después de la distribución
Duración actual del proyecto
SEA = Pregunta 2.2: ¿Cuál es la efectividad
Duración estimada del proyecto
actual de la contención de defectos
Pregunta 1.2: ¿Cuál fue la durante cada fase de construcción?
− Métrica 2.2: Phase Containment
precisión de la estimación Effectiveness for phase i (PCEi)
del valor actual del esfuerzo Número de errores de la fase i
PCEi =
del proyecto? Número de errores de la fase i +
− Métrica 1.2: Effort Número de defectos de la fase i
Estimation Accuracy (EEA) − Error = Problema durante la revisón de
la fase.
Esfuerzo actual del proyecto − Defecto = Problema encontrado durante
EEA =
Esfuerzo estimado del proyecto fases posteriores.
58
Objetivo 3. Incrementar fiabilidad − Métrica 4.1b: In-Process
SW Defects (IPD)
Número de defectos in - process causados
Pregunta 3.1: ¿Cuál es la
por desarrollo incremental
tasa de fallos software y IPD =
Tamaño del fuente equivalente en ensamblador
cómo cambia a lo largo del
tiempo? Pregunta 4.2: ¿Cuál es el
Métrica 3.1: Fault Rate (FR) contenido de defectos
Número de fallos
FR = conocidos del software
Tiempo de ejecución
distribuido a clientes?
Objetivo 4. Decrementar la
− Métrica 4.2a: Total Released
densidad de errores.
Defects total (TRD total)
Pregunta 4.1: ¿Cuál es el
Nº de defectos distribuid os
número de fallos in-process, TRD total =
Tamaño equivalent e ensamblado r
y cómo se compara con los
defectos in-process? − Métrica 4.2b: Total Released
Defects delta (TRD delta)
− Métrica 4.1a: In-Process
Faults (IPF) Número de defectos distribuid os
Número de fallos in - process causados causados por desarrollo incrmental
TRD delta =
por desarrollo incremental Tamaño equivalente en ensamblador
IPF =
59 Tamaño del fuente equivalente en ensamblador
Pregunta 4.3: ¿Cuál es − Métrica 5.1: New Open
contenido de defectos Problems (NOP)
encontrado por el cliente NOP = Número total de problemas después de la
actualmente conocido? distribuci ón abiertos durante el mes
− Métrica 4.3a: Customer-
Found Defects total (CFD Pregunta 5.2: ¿Cuál es el
total) número de problemas
Número de defectos encontrado s por el cliente abiertos al final mes?
CFD total =
Tamaño equivalent e en ensamblado r − Métrica 5.2: Total Open
− Métrica 4.3b: Customer- Problems (TOP)
Found Defects delta (CFD TOP = Número total de problemasdespués de la distribución
delta) que permanecenabiertos al final del mes
Número de defectos encontrados por el cliente
CFD delta =
causados por desarrollo incremental Pregunta 5.3: ¿Cuál es la
Tamaño equivalente en ensamblador
edad media de los problemas
Objetivo 5. Mejorar la atención al abiertos al final del mes?
cliente
− Métrica 5.3: Mean Age of
Pregunta 5.1: ¿Cuál es el Open Problems (AOP)
número de nuevos problemas Tiempo total de los problemas que
abiertos durante el mes? permanece abiertos al final de mes
AOP =
Número total de problemas abiertos al final
60 del mes después de la distribuci ón
Pregunta 5.4: ¿Cuál es la Objetivo 7. Incrementar la
edad media de los productividad del software.
problemas cerrados? Pregunta 7.1: ¿Cuál fue la
− Métrica 5.4: Mean Age of productividad de
Closed Problems (ACP) desarrollo de software
Tiempo total de los problemas después de entrega (basado en código
cerrados durante el mes en que fueron abiertos
ACP = fuente)?
Número total de problemas abiertos después de
la distribuci ón cerrados durante el mes Métrica 7.1a: Software
Objetivo 6. Reducir el coste de Productivity total (SP total)
la no conformidad. SP total =
Código fuente total equivalente en ensamblador
Esfuerzo de desarrollo de software
Pregunta 6.1: ¿Cuál fue el
coste de corrección de Métrica 7.1b: Software
errores durante el més? Productivity delta (SP
− Métrica 6.1: Cost of delta)
Fixing Problems (CFP) Código fuente delta equivalente en ensamblador
SP delta =
CFP = Coste en dólares asociado a la corrección de problemas Esfuerzo de desarrollo de software
durante el mes después de la distribución
61

T03 Garantía de Calidad PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

T03 Garantía de Calidad PDF

Caricato da

Copyright:

Formati disponibili

Tema 3.

1. Concepto de Calidad del SW

1. Concepto de Calidad del SW

La ingeniería del software tiene un objetivo principal:

La calidad del software se define como:

1. Concepto de Calidad del SW

La medición de la calidad nos lleva a clasificarla en dos

Estándares y Plan de Informes de

1. Concepto de Calidad del SW

Proporciona guías para

Sistema de gestión de calidad

Proyecto Proyecto Proyecto

Un plan de calidad contiene:

1. Concepto de Calidad del SW

Controles Evidencias Factor

Revisiones de código Las minutas firmadas por los Portabilidad

1. Concepto de Calidad del SW

Coste de calidad: incluye todos los costes acarreados en la

1. Concepto de Calidad del SW

1. Concepto de Calidad del SW

Gestión total de la calidad

Focalizado en Mejora de Parte humana

Una organización que practique TQM debe tener una

2. Garantía de Calidad del SW

Actividad de protección que se aplica a todo el proceso de

2. Garantía de Calidad del SW

Prácticas de calidad de proceso:

Un plan de calidad fija las calidades deseadas de

Plan Garantía de Calidad

4. Control de Calidad del SW

Errores de Errores amplificados Porcentaje de

4. Control de Calidad del SW

La calidad es una característica subjetiva.

Si tomamos el área dentro de seis sigma como un porcentaje de

La tasa de defectos se define como el número de defectos sobre

Ejemplo IBM Rochester:

40 – KCSI= miles de instrucciones nuevas/cambiadas

Desde el punto de vista del cliente, los problemas que encuentra

Representan dos perspectivas de la calidad del producto.

Se mide frecuentemente mediante encuestas al cliente y con una escala

Surge con el fin de estandarizar la medida operacional del tamaño.

Primer paso: calcular el número de funciones (FC).

donde wij son los pesos (cinco componentes y

El resultado de estas características se obtiene

Finalmente el número de puntos función se obtiene

La tasa de defectos durante las pruebas de sistema generalmente

El patrón de llegada de errores (tiempo entre fallos) indica diferentes

La unidad de tiempo es generalmente semanas (ocasionalmente meses).

Extensión de la métrica de densidad de defectos.

La efectividad de eliminación de defectos puede definirse como:

Medida de la carga de trabajo para el mantenimiento del software.

En el ejemplo se muestra el gráfico de errores abiertos

En numerosas ocasiones las compañías establecen un límite

La media (o mediana) del tiempo de respuesta es una

No es una métrica para tiempo real (utilizada para

Un indicativo importante de la calidad de la fase de mantenimiento

Potrebbero piacerti anche