VISIÓN GENERAL Y CONCEPTOS BÁSICOS Parte I da una visión general de los temas cubiertos en este libro y presenta los conceptos básicos

y definiciones relacionadas con la calidad, control de calidad (QA), pruebas, ingeniería de calidad y

así sucesivamente. Esta parte también abarca la planificación de calidad como parte integral de

ingeniería de calidad de software.

CAPÍTULO 1

VISIÓN GENERAL Equipos y sistemas de software está omnipresentes en la sociedad moderna. Los usuarios en todo

el mundo confían en equipos individuales e interconectados, así como la infraestructura mundial

de información, tales como la Internet y la World Wide Web (WWW), para satisfacer sus

necesidades de procesamiento de la información, almacenamiento, búsqueda y recuperación.

Todas estas necesidades con el apoyo del software subyacente. Esta dependencia requiere el

software funcione correctamente durante un tiempo prolongado, para ser fácil de usar y así

sucesivamente. En general, tales requisitos de alta calidad que deba cumplirse por las personas

involucradas en el desarrollo y soporte de estos sistemas de software a través de diversas

actividades de garantía de calidad, y las reclamaciones de alta calidad necesitan ser apoyados por

pruebas basadas en análisis y mediciones concretas.

Este capítulo presenta diversos conceptos relacionados con la ingeniería de calidad, calidad y

garantía de calidad (QA) y describe el contenido de este libro.

1.1 LAS EXPECTATIVAS DE CALIDAD de una REUNIÓN POPULAR En general, las expectativas de calidad popular para sistemas de software que utilizan y confían

son dobles:

1. Sistemas del software deben hacer lo que deben hacer. En otras palabras, deben hacer las

cosas.

2. Llevar a cabo estas tareas específicas correctamente o satisfactoriamente. En otras palabras,

que tienen que hacer las cosas derecho.

La primera requiere que el software sea el "software adecuado", o realizar las funciones de

derechos. Por ejemplo, un sistema de reserva de la aerolínea va a manejar las reservas, no

pretendía volar aviones automáticamente. El enfoque de las actividades es validar las funciones de

software necesario en su entorno operativo previsto. Este último requiere que los sistemas de

software realizan sus funciones sin problemas. En el ejemplo de sistema de reserva de aerolínea,

el sistema debe ayudar a agentes de viajes o viajeros individuales reservar válido dentro de un

límite de tiempo especificados previamente, en lugar de hacer que no válido, tomando demasiado

tiempo para hacer una reserva o negarse a hacer reservas sin justificación adecuada. El enfoque

de las actividades es verificar que las funciones de software implementado operan como

especificado.

Principales tareas de ingeniería de calidad de software Como los principales temas de este libro, son las tareas de ingeniería de calidad y software de

control de calidad garantizar la calidad del software a través de las actividades de validación y

verificación. Estas actividades deben llevarse a cabo por las personas y entidades responsables de

desarrollo y el apoyo de estos sistemas de software en una calidad general de ingeniería de

proceso que incluye:

· calidad de planificación; · ejecución de QA o software de validación y verificación actividades seleccionadas; · medición y análisis para proporcionar pruebas convincentes para demostrar la calidad del

software para todas las partes involucradas. En particular, los clientes y los usuarios necesitan tener la garantía de que sus expectativas de

calidad están satisfechos por los sistemas de software entregado. La experiencia y las lecciones

aprendidas en la entrega de dichos sistemas de software de alta calidad pueden ser envasadas en

el proceso de mejora de la calidad cuantificables en futuros proyectos de desarrollo o para

proporcionar el mejor soporte de productos de ingeniería de calidad del software.

Visto desde un ángulo diferente, también está aumentando el impacto negativo de problemas de

software, con que acompaña el uso generalizado de y la dependencia de sistemas de software en

la sociedad moderna. Los problemas podrían asociarse con funciones mal, o realizar destinados

funciones a incorrectamente, causando consecuencias no deseadas. Nos gustaría ver tal impacto

negativo eliminarse, si es posible. Sin embargo, debido a la creciente demanda de automatización,

funcionalidad adicional y comodidad por la sociedad moderna para el equipo y sistemas de

software y debido a la naturaleza ubicua de equipo moderno, el software y la infraestructura de la

información, el tamaño y la complejidad de los sistemas de software moderno también han

aumentado constantemente. Este aumento de tamaño y complejidad también tiene

consecuencias en términos de problemas de calidad.

Problemas de calidad en grandes sistemas Hoy en día, muchos sistemas de software son muy complejos y contienen millones de líneas de

código fuente. Ejemplos de dicho software de grande sistemas pueden encontrarse en

prácticamente todos los segmentos producto o cada dominio de aplicación, desde distintos

sistemas operativos, como comúnmente usado versiones de los sistemas Microsoft Windows y

UNIX las operaciones, a los productos de software comercial, tales como los productos de base de

datos, para software de entretenimiento a bordo para Boeing 777, a sistemas de software

relacionado, tales como sistemas de comando y comunicación/control (CCC) de defensa y

aviación.

Tales sistemas grandes y complejos típicamente involucran cientos o incluso miles de personas en

su desarrollo durante meses o incluso años y los sistemas son a menudo para funcionar en

entornos de aplicaciones diversas y a veces no previstos. Se puede argumentar que algunos

sistemas son innecesariamente grandes y complejos. Segun (Wirth, 1995), "software grasa" puede

deberse a indiscriminadamente agregar características no esenciales, mal diseño, inadecuadas

opciones de idiomas y metodologías, que podrían resolverse metodologías disciplinados y volver a

lo esencial "software ágil". Diversas técnicas de control de calidad, incluyendo muchos de los

contemplados en este libro, pueden ayudar a producir software de alta calidad, ágil.

Sin embargo, no hay ninguna "bala de plata", o una solución potente y eficaz todos a otros

problemas de ingeniería de software, debido a los requisitos fundamentales y las limitaciones que

un sistema de software debe satisfacer (Brooks, 1987), el tamaño, complejidad y calidad.

Acompañando a los problemas de tamaño y complejidad es las muchas posibilidades para otros

problemas a introducirse en los sistemas de software. Por lo tanto, problemas que pueden afectar

negativamente en los clientes y usuarios y tratar de administrar y mejorar la calidad del software

son una realidad para las personas involucradas en el desarrollo, administración, soporte de

marketing y operacional de los más modernos sistemas de software.

Pruebas, control de calidad (QA) e ingeniería de calidad Los factores mencionados hacen prácticamente imposible o prácticamente imposible para lograr

la completa prevención o eliminación de problemas de software y efectos negativos relacionados.

Por consiguiente, varias actividades de control de calidad de software se llevan a cabo para evitar

o eliminar ciertas clases de problemas que conducen a tales efectos negativos, o para reducir la

probabilidad o la gravedad de tales efectos negativos cuando es inevitable. Este libro describe

sistemáticamente temas y cuestiones relacionadas con estas actividades de control de calidad de

software, con énfasis en los aspectos técnicos.

Las pruebas de software desempeña un papel central entre las actividades de

control de calidad de software. Al ejecutar el sistema de software o ejecutar sus funciones

prescritas, probadores pueden determinar si el comportamiento observado sistema conforme a

sus especificaciones o requisitos. Si existen discrepancias entre los dos, las acciones de

seguimiento pueden llevarse a cabo para localizar y eliminar los problemas conexos en código de

software, que puede incluir también modificar el diseño de software.

Por lo tanto, la detección y eliminación de defectos a través de pruebas ayudan a reducir el

número de defectos en productos de software entregado, contribuyendo así a lograr los objetivos

de calidad. Incluso si no se observa ninguna discrepancia, las instancias específicas pueden

acumularse como evidencia para demostrar que el software se realiza

según lo especificado. En consecuencia, las pruebas son el medio más utilizado para

GARANTIZAR Y DEMOSTRAR LA CALIDAD DEL SOFTWARE. Una parte importante

de este libro está dedicada al software de prueba, con énfasis en las técnicas utilizadas que han

demostrado para ser eficaces en diversos entornos de aplicación práctica.

Más allá de las pruebas, hay muchas otras alternativas QA apoyados por técnicas relacionadas y

actividades, tales como inspección, verificación formal, prevención de defectos y

tolerancia a fallos. La inspección es un examen crítico de código de software u otros

artefactos por inspectores humanos para identificar y eliminar problemas directamente, sin tener

que recurrir a la ejecución. Tolerancia a errores evita fallas globales en el sistemas incluso si los

problemas locales existen, a través de varios despidos estratégicamente diseñado e implementado

en los sistemas de software. Otras técnicas de control de calidad emplean medios específicos para

asegurar la calidad del software. Este libro también proporciona una cobertura completa de estos

temas.

Además, todas estas actividades de control de calidad es necesario administrar dentro de un

proceso de ingeniería al que llamamos el:

PROCESO DE INGENIERÍA DE LA CALIDAD DEL SOFTWARE establecido, con

objetivos de calidad en el desarrollo del producto

Figura 1.1 Alcance y contenido jerarquía: pruebas, control de calidad (QA) y Ingeniería de calidad

de software.

y estrategias para el control de calidad seleccionan, llevado a cabo y supervisión para alcanzar

estas metas de calidad preestablecido. Como parte de este proceso general, los datos recogidos

durante las actividades de control de calidad, así como de las actividades de desarrollo general,

pueden ser analizados para proporcionar información para el proceso de desarrollo de

software para la toma de decisiones, administración de proyectos y mejora de la calidad

cuantificables. Este libro también proporciona una cobertura completa de estos temas.

1.2 ORGANIZACION DEL LIBRO Y VISION GENERAL DEL CAPITULO Figura 1.1 se muestra el alcance general de los temas presentado anteriormente: la prueba es un

subconjunto importante de las actividades de control de calidad; y control de calidad es un

subconjunto importante de las actividades de ingeniería de calidad.

Este diagrama también explica nuestro título de libro: "ingeniería de calidad de Software: pruebas,

control de calidad y mejora cuantificable". Este libro está organizado en cuatro partes principales y

22 capítulos, con los temas principales que se describen a continuación.

Parte I: introducción y conceptos básicos Parte I ofrece una introducción general y la introducción de los temas tratados en el libro y

presenta los conceptos básicos y definiciones relacionadas con la calidad, control de calidad,

pruebas, ingeniería de calidad, etc.. Preguntas específicas incluyen:

· Sobre este libro: ¿qué es? ¿Cómo utilizarlo? ¿Cómo está organizada? Además, ¿qué

conocimiento es necesario tener un entendimiento profundo de los aspectos técnicos de

este libro? Estas preguntas son respondidas en el capítulo 1.

· ¿Cuál es la calidad del software? En particular, ¿cuáles son las diferentes opiniones de

calidad? ¿Es un concepto único, atómico de calidad, o consiste de muchos diferentes

atributos o características? ¿Cuál es la relación entre calidad y exactitud defecto?

¿Podemos reducir la definición de calidad mejor centrar nuestra atención en diversas

actividades QA comúnmente realizadas durante software de ciclos de vida? Estas

preguntas son respondidas en el capítulo 2.

-¿Lo que es control de calidad? Se responde a la cuestión desde una perspectiva particular en

el capítulo 3, que representa una interpretación basada en defecto de calidad y control de

calidad.

-¿Cuáles son las diferentes actividades de control de calidad y técnicas relacionadas? También

se presenta una clasificación basada en el defecto en el capítulo 3, de las principales

alternativas de control de calidad y técnicas, tales como pruebas, inspección, verificación

formal, tolerancia a errores y así sucesivamente.

-¿Cómo para adaptarse a las distintas actividades de control de calidad en los procesos de

desarrollo de software? ¿Qué pasa con otros marcos de clasificar las actividades de control

de calidad? Estas preguntas son respondidas en el capítulo 4.

· Las actividades de control de la calidad se ampliaron en el capítulo 5 en ingeniería de calidad

que incluye calidad planificación antes a actividades específicas de control de calidad y

medición, análisis y actividades de retroalimentación para cerrar el bucle para la

evaluación de la calidad y mejora cuantificables.

Parte II: Pruebas de Software La parte aborda todos los temas importantes relacionados con el software de prueba, con énfasis

en las técnicas usadas de pruebas que han demostrado para ser eficaces y eficientes en muchos

entornos de aplicación práctica. Los capítulos de esta parte se organizan en dos subpartes:

descripciones de técnicas de pruebas específicas (capítulos 8 a 11) están rodeadas por capítulos

sobre las cuestiones generales de pruebas (capítulos 6, 7 y 12). A continuación se describen los

capítulos individuales:

· Preguntas generales, problemas, terminología sobre las pruebas, incluyendo el proceso de

pruebas genérico y una taxonomía para pruebas, se examinan en el capítulo 6.

· Las principales actividades de pruebas, popular roles y responsabilidades en estas actividades,

gestión de prueba y prueba automatización cuestiones están incluidas en el capítulo 7.

· Lista de comprobación y basada en la partición de pruebas: capítulo 8 comienza con la prueba

más simple de todos ellos, pruebas especiales, luego progresa más organizada pruebas

utilizando modelos simples como listas y particiones. Técnicas de pruebas específicas

contempladas en el capítulo 8 incluyen:

· pruebas con diferentes tipos de listas generales;

· decisión y predicado pruebas;

· basada en el uso estadístico pruebas utilizando perfiles planos operacional.

· Límite pruebas: como un caso especial y la extensión de las pruebas de partición, cubrimos límite

pruebas en el capítulo 9. Aplicación de las ideas de prueba de límite en otras situaciones de

pruebas también está cubierto.

· Basado en estado pruebas: tanto las finito-máquinas de Estado (FSMs), que sirven como base

para las pruebas basadas en el Estado y los FSMs aumentadas, que forman cadenas de Markov

para más profunda basada en el uso estadístico pruebas, se tratan en el capítulo 10.

· Interacción pruebas: en lugar de centrarse en las particiones individuales o Estados, las pruebas

técnicas describen en el capítulo 11, ocuparse de las interacciones a lo largo de una ruta de

ejecución completa o un segmento de la dependencia. Específicamente, este capítulo abarca

las siguientes técnicas tradicionales de pruebas:

· pruebas de control de flujo (CFT);

· pruebas de flujo de datos (DFT).

· 12 Capítulo trata sobre la aplicación de técnicas de pruebas específicas para tareas específicas

para las pruebas en diferentes sub-phases o en tareas especializadas. También se discute la

integración de diferentes pruebas técnicas para cumplir algunos propósitos comunes.

Parte III: Calidad más allá de pruebas I11 parte cubre importantes técnicas de control de calidad distintos de pruebas, incluidos los que

se describen a continuación y una comparación de todas las alternativas de control de calidad al

final.

· Diversas técnicas de prevención de defecto se describen en el capítulo 13.

· Inspección de software o examen crítico de los artefactos de software por inspectores humanos,

se describe en el capítulo 14.

· Verificación formal de la corrección del programa con respecto a sus especificaciones formales se

trata en el capítulo 15.

· Tolerancia a fallas técnicas que evitar errores a través de algunos redundancia o duplicación se

tratan en el capítulo 16. Técnicas relacionadas basados en ideas similares, como la contención

de fracaso para minimizar el impacto de la falla, también se exponen en el capítulo 16.

· Algunas técnicas de análisis de programa, específicamente el análisis estático, también están

cubiertos en el capítulo 14 en conexión con la inspección. Temas relacionados en análisis

dinámico programa están cubiertos brevemente en el capítulo 12 en conexión con las técnicas

especializadas de pruebas.

· Comparación de diferentes alternativas de control de calidad y técnicas, los contemplados en la

parte III, así como pruebas cubierto en parte 11, incluidos se presenta en el capítulo 17.

Parte IV cuantificables mejora de la calidad Parte IV cubre las importantes actividades llevadas a cabo en paralelo o como seguimiento de las

principales actividades de control de calidad describen en parte I1 y parte 111. El objetivo de estas

actividades es supervisar las actividades de control de calidad para proporcionar evaluación

cuantitativa de calidad e información para el proceso de ingeniería de calidad. Dicha evaluación y

comentarios pueden utilizarse para ayudar con la toma de decisiones, administración de proyectos

y diversas iniciativas de mejora. El contenido principal de los capítulos específicos en esta parte se

describe a continuación:

· Primero, el paralelo y las actividades de seguimiento, así como la colección y uso de los datos sin

procesar y transformados en análisis relacionados para proporcionar comentarios específicos

para diversos fines, se describen en el capítulo 18.

· Capítulo 19 describe diferentes modelos y medidas para la evaluación de la calidad y mejora y

clasifica de acuerdo a las informaciones y los tipos específicos de los datos requeridos.

· Defecto clasificación y análisis de modelos se describen en el capítulo 20, como un importante

subclase de modelos de evaluación de la calidad que se centra en la recogida y análisis de

información defecto detallada.

· Aún más el análisis de los defectos descubiertos y otra medición de datos de control de calidad y

las actividades de desarrollo global pueden llevarse a cabo identificar las áreas de alto riesgo o

alta defecto para centrado medidas correctivas destinadas a la mejora de la calidad eficaz.

Diversas técnicas de identificación de riesgos y modelos relacionados para hacerlo se

presentan en el capítulo 21.

· Como alternativa a la base de defecto ver de calidad que está más cerca de los desarrolladores

"perspectiva, fiabilidad es una medida de calidad que está más cerca de los usuarios"

perspectiva y más significativa para los clientes de destino. Capítulo 22 presenta modelos de

confiabilidad de software y técnicas de análisis para proporcionar evaluaciones de fiabilidad y

orientación para la mejora de la confiabilidad.

1.3 DEPENDENCIA Y USO SUGERIDO La integración de los capítulos interconectados es una característica importante de este libro. A

continuación examinamos los temas y capítulo dependencias y discutir formas diferentes que se

pueden combinar estos temas para que los lectores diferentes con diferentes propósitos en

mente.

Dependencia de capítulo La figura 1.2 muestra las dependencias entre diferentes capítulos, así como entre diferentes

partes, cada agrupados por líneas de puntos. Usamos líneas sólidas para representar las

dependencias esenciales y líneas de guiones para representar las dependencias que están

deseable pero no esenciales. Un ejemplo de este último tipo de dependencias es la Dependencia

no esenciales entre la evaluación de la calidad y análisis en temas parte IV y QA en partes I1 y 111:

el conocimiento de los temas tratados en partes I1 y I11 haría que la mayoría de los temas

tratados en la parte IV más significativa. Sin embargo, se puede tener una comprensión general de

la parte IV sin un conocimiento profundo de partes I1 y 111. Del mismo modo, aunque todos los

capítulos en la parte I11 excepto la última pueden tratarse como los paralelo, 13 capítulos a través

de 16 generalmente siga la secuencia de actividades o fases en el proceso de desarrollo. Por lo

tanto, sería más lógico a seguir esta secuencia. A continuación se explican algunas dependencias

específicas:

· Además de dependencia del capítulo 17 capítulos anteriores de parte 111, que debe también ser

precedida por capítulos en parte 11, al menos 6 del capítulo, ya que la comparación de

alternativas de control de calidad en el capítulo 17 se basan en los conocimientos generales de

alternativas individuales y técnicas.

· Los capítulos sobre pruebas técnicas en parte I1 siguen la evolución natural de los modelos

simples a complejos. Sin embargo, es no esencial dependencia entre aquellos basados en

particiones simples (capítulos 8 y 9) y modelos aquellas basadas en más complejo (capítulos 10

y 11).

· Los dos últimos capítulos en la parte IV pueden tratarse como capítulos paralelos salvo que parte

del capítulo 22, el tema de modelos basados en el árbol de la fiabilidad (TBRMs), utiliza la

técnica de modelado llamado modelado basado en árbol cubierto en el capítulo 21.

Uso sugerido Este libro es adecuado como el libro de texto principal para un curso de un semestre en diversos

programas

programas de ingeniería. Otras personas que están interesados en aprender todos los temas

importantes en

Ingeniería de calidad de software también debe leer todo el libro. Sin embargo, para las personas

que

sólo quiere hacerse una idea general de los temas tratados en este libro, son los capítulos

siguientes

su caso:

El conjunto mínimo: capítulos 1-6,17 y 18. Este conjunto mínimo incluye todos los cinco

capítulos de la parte I y un capítulo de partes 11,111 y IV, respectivamente.

Entre estos dos extremos (el conjunto mínimo y todos los capítulos), también existen otros usos

posibles de este libro. Todos los followingwould asumir el conjunto mínimo de coverageof básica

de capítulos anteriores y algunos otros capítulos a ella. A continuación se dan algunos usos

sugeridos:

· Semestre la mitad del curso: cubrir todo en detalles selectivas, con énfasis en cualquier parte 11,

111, o IV.

· Corto curso sobre temas especializados: conjunto mínimo sobre más de la parte de partes II, III y

IV. Estos cursos cortos sería similares en longitud a unas diez horas o 3-4 semanas de clases de

clase.

· Otras combinaciones de capítulos también son posibles, pero requeriría al lector a realizar un

seguimiento de las referencias cruzadas en temas y dependencias relacionadas con la figura

1.2 como guía.

Además de su uso como un libro de texto, o como un libro técnico que presenta a otras personas a

los temas importantes de ingeniería de calidad de software, la cobertura completa de todos los

temas importantes y punteros a lecturas adicionales también deberían hacer este libro una buena

referencia para los lectores en su carrera profesional.

1,4 PREPARACIÓN DE LECTOR DE Y FONDO DE CONOCIMIENTOS Para tener un buen conocimiento de los detalles técnicos, los lectores deben tener un

conocimiento general de matemáticas, estadísticas, informática e ingeniería de software,

equivalente al nivel de juniors de colegio, personas mayores o nuevos estudiantes graduados en

Ciencias de la computación, ingeniería de software, o un campo relacionado. Lo siguiente es servir

de una lista de comprobación general para los lectores: si encuentra que carecen de ciertos

conocimientos de fondo figuran ser baja, necesita estudiar o revisarlos en su propia antes de

proceder a discusiones técnicas relacionadas. Esta lista ayudará a los lectores a vincular piezas

específicas de conocimiento a partes específicas del libro.

Conocimientos matemáticos y estadísticos Sería útil si no está familiarizado con algunos de ellos revisar los libros de texto estándar en

matemáticas y estadísticas sobre los siguientes temas:

· Conceptos básicos de las relaciones, álgebra y teoría de conjuntos: utilizado en todo el libro y

especialmente en los siguientes:

· Conjuntos, subconjuntos, particiones, tipos básicos de las relaciones y clases de equivalencia

en

· Uso de ecuaciones algebraicas para definir los límites en el capítulo 9 de límite

· Prioridad y las relaciones de dependencia en el capítulo 11 de flujo de control y datos-

· Las relaciones de causa y efecto en el capítulo 16 para la garantía de seguridad y análisis de

riesgo y en el capítulo 20 para análisis de defecto.

· Lógica, lógica booleana particular y formalismos relacionados: utilizado en todo el libro y

especialmente en los siguientes:

· Lógica booleana de predicado y decisión de pruebas en el capítulo 8.

· Lógica matemática y formalismos en el capítulo 15 de verificación formal de corrección del

programa.

· Algunos conceptos básicos de teoría de grafos: utilizado en todo el libro y especialmente en los

siguientes:

· Decisión de árboles en el capítulo 8 para perfiles operacionales utilizados en pruebas

estadísticas.

· Gráfico elementos para pruebas relacionadas en Chap - y máquinas de estado finito (FSMs)

· Diagrama como situaciones de flujo de control pruebas en el capítulo 1 1.

· Gráficos de dependencia de datos (un estructura de árbol gráfico) para pruebas en Chap-en el

flujo de datos

· Árboles en análisis de árbol de fallas y análisis de árbol de evento en el capítulo 16 de riesgo

· Modelos basados en el árbol de identificación de riesgos en el capítulo 21 y analter de

fiabilidad en el capítulo 22.

Capítulo 2 ¿CUÁL ES LA CALIDAD DEL SOFTWARE?

2.1 CALIDAD: PERSPECTIVAS Y EXPECTATIVAS

A continuación examinaremos las diferentes opiniones de calidad en forma sistemática, basada en

el dif-tintos roles, responsabilidades y expectativas de calidad de diferentes personas y zoom en

un pequeño conjunto de puntos de vista y las propiedades relacionadas a seguir constantemente a

lo largo de este libro.

Vistas principales cinco según (Kitchenham y Pfleeger, 1996; Pfleeger et al., 2002) son:

trascendental, usuario, fabricación, producto y vistas basadas en el valor, como se indica a

continuación:

· En la vista trascendental, calidad es difícil de definir o describir en términos abstractos, pero

puede ser reconocido si está presente. Se asocia generalmente con algunos bienes

inmateriales que las delicias de los usuarios.

· En la vista del usuario, la calidad es la idoneidad para un propósito o las necesidades. del

usuario de la reunión

· En la vista de la fabricación, calidad significa conformidad para procesar las normas.

· En la vista de producto, el enfoque es sobre características inherentes en el propio

producto, con la esperanza de que controlar estos indicadores de calidad interna (o las

producto llamado - métricas internas se describe en el capítulo 18) dará como resultado

un comportamiento mejor producto externo (calidad en uso).

· En la vista basada en el valor, la calidad es la disposición de los clientes a pagar por un

software.

Funciones y responsabilidades de las personas

Cuando se refiere a calidad del software, diferentes personas tendría diferentes puntos de vista y

ex-pectations, basado en sus funciones y responsabilidades. Con la garantía de calidad (QA) y

enfoque de ingeniería de calidad de este libro, podemos dividir al pueblo en dos grupos:

· Consumidores de software de productos o servicios, incluidos los clientes y usuarios, ya sea

interna o externamente. En algún momento también hacemos la distinción entre los cus-

tomers, que son responsables de la adquisición de productos de software o servicios y los

usuarios, que utilizan los productos de software o servicios para diversos fines, aunque los

dos roles de los clientes y los usuarios son bastante comunes. También podemos extender

el concepto de los usuarios para incluir dichos usuarios no humanos o "invisibles" como

otro software, hardware integrado y el entorno operativo general que el software

funciona bajo e interactúa con (Whittaker, 2001).

· De productores de software de productos, o cualquier persona involucrada con el desarrollo,

gestión, mantenimiento, marketing y servicio de productos de software. Adoptamos una

amplia

definición de los productores, que también incluyen a participantes de terceros que pueden ser

participantes en complementos y servicios, software empaquetado, certificación de software,

cumpliendo con una verificación independiente y responsabilidades de validación (IV y V) y así

sucesivamente.

Subgrupos dentro de los grupos anteriores pueden tener intereses diferentes, aunque hay muchas

preocupaciones comunes dentro de cada grupo. En los debates posteriores, utilizamos vista

externa para la perspectiva del primer grupo, que está más preocupada por el comportamiento

observado o externo, y no los detalles internos que conducen a este tipo de comportamiento.

Asimismo, utilizamos una vista interna de etiqueta genérica de perspectiva del segundo grupo,

porque son típicamente familiarizado con o al menos conscientes de diversos característica

interna de los productos. En otras palabras, la vista exterior principalmente ve un sistema de

software como una caja negra, donde uno puede observar su comportamiento pero no ver a

través de interior; mientras la vista interna en su mayoría lo ve como un cuadro blanco, o más bien

un cuadro claro, donde se puede ver lo que es interior y cómo funciona.

Expectativas de calidad en el lado del consumidor

Las expectativas de calidad básica de un usuario son que un sistema de software realiza funciones

útiles como se especifica. Hay dos elementos básicos a esta expectativa: en primer lugar, realiza

funciones derechos como especificado, que, esperemos que se adapta a las necesidades

(apropiado para uso) del usuario. En segundo lugar, realiza las siguientes funciones especificadas

correctamente sobre uso repetido o durante un largo período de tiempo, o desempeña sus

funciones de forma fiable. Estos dos elementos están relacionados con los aspectos de validación y

verificación de QA hemos introducido en el capítulo anterior, que se ampliará aún más en el

capítulo 4. Looking'into el futuro, podemos trabajar hacia el cumplimiento de esta expectativa

básica y más allá de las delicias de los clientes y usuarios por prevenir impactos negativos

imprevistos y producir efectos positivos inesperados (Denning, 1992).

Para muchos usuarios de hoy omnipresente software y sistemas, facilidad de uso, o la facilidad de

uso, puede ser una expectativa de calidad más importante que la fiabilidad o otras

preocupaciones. Por ejemplo, la adopción de interfaces gráficas de usuario (GUI) en computadoras

personales para reemplazar basadas en texto intérpretes de comandos usados en mainframes se

basa principalmente en las preocupaciones de la facilidad de uso para su población masiva. Del

mismo modo, la facilidad de instalación, es otra tendencia importante para software destinado a

la misma población, para permitir la instalación sin dolor (y casi sin esfuerzo) y operación o el

llamado "plug-and-play". Sin embargo, los diferentes usuarios del mismo sistema pueden tener

diferentes opiniones y prioridades, tales como la importancia de la facilidad de uso para los

usuarios novatos y la importancia de confiabilidad para los usuarios sofisticados de la web

(Vatanasombut et al., 2004).

Si tenemos en cuenta la definición ampliada de usuarios más allá de usuarios humanos, las

principales expectativas de calidad sería garantizar el buen funcionamiento y la interacción entre

estos usuarios no humanos en forma de mejor interoperabilidad y capacidad de adaptación y el

software para que el software puede trabajar bien con otros y dentro de su entorno.

Las expectativas de calidad básica de un cliente son similares a las de un usuario, con el motivo de

preocupación para el costo del software o servicio. Esta preocupación adicional puede reflejarse

en la llamada vista basada en el valor de calidad, es decir, si un cliente está dispuesto a pagar por

ello. Los intereses en competencia de calidad y otras preocupaciones de ingeniería de software,

como el costo, programación, funcionalidad y sus desventajas, se examinan en la sección 2.4.

Expectativas de calidad en el lado del productor

Para los productores de software, la cuestión más fundamental de la calidad es cumplir sus

obligaciones contractuales para producir productos de software que se ajustan a las

especificaciones del producto o pro - viding servicios que cumplan con el acuerdo de servicio. Por

extensión, diversas características interna producto que facilitan a ajustarse a las especificaciones

del producto, tales como signos de buenas que mantienen la integridad conceptual de los

componentes del producto y reducen el acoplamiento a través de diferentes componentes,

también están asociadas con buena calidad.

Para los administradores de productos y servicios, respeto proceso software preseleccionado y

rele-vant estándares, la correcta elección de los métodos de software, idiomas y herramientas, así

como otros factores, puede estar estrechamente relacionado con la calidad. También están

interesados en la gestión y satisfacer las expectativas de calidad del usuario, traducir esas

expectativas de calidad en los objetivos de calidad realista que pueden definir y administrar

internamente, seleccionando apropiadas y eficaces estrategias de control de calidad y verlos a

través de. Para otras personas en el lado del productor, sus preocupaciones diferentes también

pueden producir calidad

opiniones y expectativas diferentes de la anterior. Por ejemplo, usabilidad y modificabilidad

pueden ser fundamental para las personas involucradas con el servicio de software,

mantenimiento para personal de Mante-nance, portabilidad para proveedores de servicios de

terceros o software empaquetado y valor de rentabilidad y cliente para la comercialización de los

productos.

2.2 MARCOS DE CALIDAD Y ISO-9126

Basado en las opiniones de diferentes calidades y expectativas antes mencionados, calidad puede

definirse en consecuencia. De hecho, ya hemos mencionado anteriormente varios llamados "-

ilities" conectado a la calidad del término, como confiabilidad, facilidad de uso, portabilidad,

mantenimiento, etc.. Se han propuesto varios modelos o marcos para acomodar estas vistas

diferentes de calidad y las expectativas y para definir la calidad y atributos relacionados,

funciones, características y mediciones. A continuación brevemente describimos ISO-9 126 (ISO,

2001), que en su mayor parte influyente en la comunidad de ingeniería de software hoy y discutir

varias adaptaciones de esos marcos de calidad para entornos de aplicaciones específicas.

ISO-9126

ISO-9 126 (ISO, 2001) proporciona un marco jerárquico para la definición de la calidad, organizada

en sub-characteristics y características de calidad. Hay seis nivel superior calidad charac-teristics,

con cada asociado con sus propio sub-characteristics exclusivos (no superpuestos), que se

resumen a continuación:

· Funcionalidad: conjunto de atributos relacionados con la existencia de un conjunto de

funciones y sus propiedades especificadas. Las funciones son las que satisfacen

necesidades declaradas o implícitas.

Los sub-characteristics incluyen:

-La idoneidad

-Precisión

-Interoperabilidad

-Seguridad

· Fiabilidad: un conjunto de atributos relacionados con la capacidad del software para

mantener su nivel de rendimiento bajo declaró condiciones durante un período de tiempo

establecido. Los sub-characteristics incluyen:

-Madurez

-Tolerancia

-Capacidad de recuperación

· Usabilidad: un conjunto de atributos relacionados en el esfuerzo necesario para su uso y en la

evaluación individual de dicho uso, por un conjunto declarado o implícito de los usuarios.

Las sub-características incluyen:

-Comprensibilidad

-Learnability

-Capacidad de operación.

· Eficiencia: un conjunto de atributos relacionados con la relación entre el nivel de

funcionamiento por el software y la cantidad de recursos utilizados, bajo condiciones

expuestas. Los sub-characteristics incluyen:

-Comportamiento tiempo

-Comportamiento de los recursos

· Mantenimiento: un conjunto de atributos relacionados con el esfuerzo necesario para hacer

modificaciones especificadas. Los sub-characteristics incluyen:

-Analyzability

-Mutabilidad

-Estabilidad

-Testabilidad

· Portabilidad: un conjunto de atributos relacionados con la capacidad del software de

transferirse de un entorno a otro. Los sub-characteristics incluyen:

-Adaptabilidad

-Ignorará

-Conformidad

-Replaceability

Marcos alternativos y enfoque de corrección

ISO-9 126 ofrece un marco amplio para describir muchos atributos y propiedades que asociamos

con calidad. Hay una estricta jerarquía, donde no sub-characteristics se comparten entre las

características de calidad. Sin embargo, ciertas propiedades del producto están vinculados a

múltiples características de calidad o sub-characteristics (Dromey, 1995; Dromey, 1996). Por

ejemplo, diversas formas de redundancia afectan a la eficiencia y capacidad de mantenimiento. En

consecuencia, se han propuesto marcos de calidad alternativos de var-pagarés para permitir las

relaciones más flexibles entre los atributos de calidad diferente o factores y para facilitar una

transición suave de preocupaciones específicas de calidad a las propiedades específicas del

producto y métricas.

Muchas empresas y comunidades asociadas con distintos dominios de aplicación han adaptado y

personalizar marcos de calidad existentes para definir la calidad de los mismos, teniendo en

cuenta su entorno específico de negocio y mercado. Un ejemplo concreto de esto para las

empresas es la lista de atributos de calidad CUPRIMDS (capacidad, facilidad de uso, perfor-mance,

fiabilidad, instalación, mantenimiento, documentación y servicio) IBM utilizada para sus productos

de software (Kan, 2002). CUPRIMDS a menudo se utiliza junto con la satisfacción general del cus-

tomer (así las siglas CUPRIMDSO) para caracterizar y medir la calidad del software para productos

de software de IBM.

Asimismo, se ha identificado un conjunto de atributos de calidad para aplicaciones web (de-futt,

2002), con los atributos de calidad primaria como confiabilidad, facilidad de uso y seguridad y los

atributos de calidad secundaria como tiempo, escalabilidad, disponibilidad y mantenimiento al

mercado. Dichos planes con prioridad se suelen utilizan para dominios de aplicación específica.

Por ejemplo, rendimiento (o eficiencia) y fiabilidad que prevalecen sobre la usabilidad y principal-

tainability para productos de software en tiempo real. Por el contrario, sería lo contrario para

productos de mercado de masas para los usuarios finales.

Entre los atributos o características de calidad de software, algunos tratan directamente con la

corrección func internacional o la conformidad con las especificaciones como lo demuestra la

ausencia de problemas o casos de no conformidad. Otros atributos o características de calidad

tratan de usabilidad, portabilidad, etc.. Corrección normalmente está relacionado con varios

characteris de calidad-tics o sub-characteristics en marcos de calidad descritos anteriormente. Por

ejemplo, en 126 de ISO-9 está relacionada con la funcionalidad, particularmente su sub-

characteristics de precisión (en otras palabras, conformidad) y confiabilidad.

Corrección suele ser el aspecto más importante de la calidad para situaciones donde cotidiana o

negocio depende del software, como en la gestión de redes corporativas, bases de datos

financieros y software de control en tiempo real. Incluso para los segmentos de mercado donde

nuevas características y funcionalidad tienen prioridad, como para las aplicaciones basadas en web

y software para su uso personal en el mercado de masas, corrección es todavía una parte

fundamental de las expectativas de los usuarios (Offutt, 2002; Prahalad y Krishnan, 1999). Por lo

tanto, aprobamos la vista centrada en la corrección de calidad a lo largo de este libro. Nos

centraremos en corrección - relacionados con atributos de calidad y las formas conexas para

garantizar y demostrar la calidad definida como tal.

2.3 CORRECCIÓN Y DEFECTOS: DEFINICIONES, PROPIEDADES Y MEDICIONES

Cuando muchas personas asocian calidad o alta calidad con un sistema de software, es un indica-

ción que pocos, si alguno, problemas de software, se espera que durante sus operaciones. Es más,

cuando surgen problemas, el impacto negativo se espera sea mínimo. En esta sección se examinan

cuestiones relacionadas.

Definiciones: Error, error, fallo y defecto

Clave para el aspecto de la corrección de la calidad del software es el concepto de defecto, error,

error y error. El "defecto" de término generalmente se refiere a algún problema con el software,

con su comportamiento externo o con sus características internas. El 610.12 estándar IEEE (IEEE,

1990) define los siguientes términos relacionados con defectos:

· Error: la incapacidad de un sistema o componente para realizar sus funciones necesarias en

especifica requisitos de rendimiento.

· Error: una definición de paso, proceso o datos incorrecta en un programa de ordenador.

· Error: una acción humana que produce un resultado incorrecto.

Por lo tanto, el fracaso del término se refiere a una desviación del comportamiento de la exigencia

del usuario o en el pliego de condiciones; error se refiere a una condición subyacente en un

software que hace que algunos failure(s) a ocurrir; mientras que el error se refiere a una falta o

incorrecta acción humana resultante en ciertos fault(s) ser había inyectado .into un software.

También extendemos errores para incluir fuentes de error, o las causas de las acciones de

faltantes o es incorrectas, como errores humanos, malentendidos, etc.. Errores, fallas y errores se

denominan conjuntamente como defectos en la literatura. En este libro en este sentido colectivo o

cuando sus derivados se usan comúnmente en la literatura, como en el manejo de defecto

utilizaremos el defecto de término.

Problemas de software o defectos, son también conocido como "errores". Sin embargo, nunca

precisamente se define el error de plazo, como los diferentes aspectos de los defectos que se

define como errores, fallos y fracasos anteriores. Algunas personas también han planteado la

objeción moral o filosófica al uso de error como evadir la responsabilidad de algo personas

comprometidas. Por lo tanto, intentamos evitar usar el término "bug" en este libro.

Del mismo modo, también intentamos evitar mediante los términos relacionados "depuración" o

la "depuración" por razones similares. El término "Depurar" medios generales "deshacerse de los

errores". A veces, también incluye actividades relacionadas con la detección de la presencia de

errores y hacerles frente. En este libro, utilizará, en su lugar, los siguientes términos:

· Utilizamos detección de defecto y eliminación para el concepto global y las actividades

relacionadas con lo que muchas personas comúnmente llaman "depuración".

· Cuando se trate de actividades específicas relacionadas con la "depuración", señalamos las

especificaciones usando términos definidos más precisamente, incluyendo,

-Actividades relacionados con el descubrimiento del defecto, incluyendo pruebas,

inspección, etc..

-Actividades de seguimiento específicas después de descubrimiento del defecto,

incluyendo el diagnóstico de defecto, análisis, fijación y reverificación.

Todos estos términos específicos serán definidos más precisamente en este libro cuando se

introduzcan o cuando se tratan los temas más estrechamente relacionados conexas ellos.

Conceptos y relaciones ilustradas

Los conceptos de error (incluyendo el código de error), errores, fallas y defecto pueden colocarse

en el contexto de artefacto de software y actividades de desarrollo de software de uso

operacional, como se muestra en la figura 2.1. Información específica ilustrado incluyen:

· El sistema de software representada por sus artefactos se muestra en el cuadro central. Los

artefactos incluyen sobre todo código de software y en algún momento otros artefactos

como diseños, especificaciones, documentos de requisito. Thefaults diseminadas entre

estos artefactos se representan como entidades en un círculo en el cuadro central.

· Las actividades de desarrollo dela entrada para el software, representadas en el cuadro de la

izquierda, incluyen modelos conceptuales y información, los desarrolladores con ciertos

conocimientos y experi-ence, componentes de software reutilizables, etc.. Diversas

fuentes de error también se representan como entidades en un círculo dentro de este

cuadro de la izquierda.

· Los errores como las acciones humanas faltantes o directamente no aparecen dentro de un

cuadro, sino como acciones hacia la inyección de errores en el cuadro central debido a

algunas fuentes de error en el cuadro izquierdo.

· Uso de escenarios y resultados de la ejecución, representados en el cuadro de la derecha,

describen la entrada a la ejecución del software, su comportamiento dinámico y salida y

los resultados generales. Un subconjunto de estos patrones de comportamiento o

resultados puede clasificarse como errores cuando se desvían el comportamiento

esperado y se muestra como la colección de instancias de fracaso en un círculo.

Con las anteriores definiciones e interpretaciones, podemos ver que errores, fallas y errores son

aspectos diferentes de defectos. Existe una relación causal entre estos tres aspectos de defectos:

errores fallas fallas

Es decir, errores pueden causar fallas a inyectar en el software, y fallas pueden causar fallas

cuando se ejecuta el software. Sin embargo, esta relación no es necesariamente 1-a-1: un solo

error puede causar muchos defectos, como en el caso de que un algoritmo mal se aplica en varios

módulos y provoca fallos múltiples, y un fallo único puede causar muchos fracasos en repetidas

ejecuciones. Por el contrario, el fracaso de la mismo puede ser causado por varios errores, como

un error de interfaz o interacción con la participación de varios módulos, y el mismo fallo puede

existir debido a errores diferentes. Figura 2.1 también ilustra algunas de estas situaciones, como

se describe a continuación:

· La e3 de fuente de error provoca múltiples fallas, f2 andfJ.

· El faultfl es causada por múltiples fuentes de error, el y e2.

· a veces, una fuente de error, tales como e5, no puede causar cualquier inyección de errores,

y un fallo, tales asf4, no puede causar cualquier avería, bajo los escenarios determinados o

circum-posturas. Dichos fallos se denominan normalmente fallas latentes o latentes, que

todavía pueden causar problemas en un conjunto diferente de situaciones o

circunstancias.

Mediciones y centrada en la corrección propiedades

Con el enfoque de corrección adoptado en este libro y la partición binaria de personas en los

grupos de consumidores y productores, podemos definir calidad y propiedades relacionadas con

estas vistas (opiniones externas para productores frente internos vistas para los consumidores) y

atributos (corrección vs otros) en la tabla 2.1.

La calidad centrada en la corrección de la visión externa, o desde la vista de los consumidores

(usuarios y clientes) de un producto de software o servicio, puede definir y medir por diversas

propiedades relacionadas con el fracaso y la medición. Para un usuario o un cliente, la principal

preocupación es que el software funciona sin falla, o con tan pocos fracasos como sea posible.

Cuando se producen tales fallas o undesirableevents, el impacto debe ser lo menos posible.

Estas preocupaciones pueden ser capturadas por diversas propiedades y relacionados con las

mediciones, como sigue:

Propiedades de fracaso y medición de falta directa: fracaso propiedades incluyen

información sobre los errores específicos, lo que son, cómo se producen, etc.. Estas

propiedades pueden medirse directamente mediante el examen de recuento de fracaso,

distribución, densidad, etc.. Examinaremos propiedades de error detallado y medidas en

relación con la clasificación de defecto y análisis en el capítulo 20.

· Error de medición de probabilidad y fiabilidad: cómo a menudo o cómo probablemente no va

a ocurrir es de preocupación para los usuarios de software y clientes. Esta probabilidad es

capturado en varias medidas de confiabilidad, donde fiabilidad puede definirse como la

probabilidad de operaciones libres de error para un período de tiempo específico o para

un determinado conjunto de entrada (Musa et al., 1987; LYU, 1995; Tian, 1998).

Analizaremos este tema en el capítulo 22.

· Garantía de seguridad y medición de gravedadfracaso: el impacto del fallo también es una

cuestión esencial para los usuarios y clientes de muchos productos de software y servicios,

especialmente si el daño causado por fallas podría ser sustancial. Accidentes, que se

definición como fallas graves consecuencias, necesitan ser evitado, figura o tratadas para

garantizar la seguridad para el personal involucrado y minimizar otros daños.

Analizaremos este tema en el capítulo 16.

En contraste con la perspectiva de calidad por encima de los consumidores, los productores de

sistemas de software ver calidad desde una perspectivas diferentes en su interacción con los

sistemas de software y problemas conexos. Necesitan para solucionar los problemas o errores que

causó los fracasos, así como hacer frente a la inyección y la activación de otras fallas que podría

causar otras fallas que aún no se han observado.

Similares a las propiedades de fracaso y las medidas conexas mencionadas, tenemos que examinar

diversas propiedades de fallas y medidas relacionadas de la vista de los productores o interno.

Podemos recopilar y analizar información sobre errores individuales, como así como hacerlo

colectivamente. Fallas individuales pueden analizar y examinar con arreglo a sus tipos, sus

relaciones a fallos específicos y accidentes, sus causas, el tiempo y circunstancias cuando que se

inyectan, etc.. Fallos pueden ser analizadas colectivamente según para su distribución y densidad

en fases de desarrollo y componentes de software diferentes. Estos temas se tratarán en detalle

en el capítulo 20 en relación con la clasificación de defecto y análisis. Técnicas para identificar las

áreas de alta-defecto para mejorar la calidad centrado se tratan en el capítulo 2 1.

Defectos en el contexto de la ingeniería de calidad y control de calidad

Para la mayoría organizaciones de desarrollo de software, garantizar la calidad significa tratar de

defectos. Tres maneras genéricos para lidiar con defectos incluyen: prevención de defecto 1), 2)

detección y eliminación de defectos y 3) defectos de contención. Estas diferentes maneras de

tratar con defectos y las actividades conexas y técnicas de control de calidad se describe en el

capítulo 3. Diversas alternativas de control de calidad y técnicas relacionadas pueden utilizarse en

un esfuerzo concertado para abordar con defectos y eficazmente asegurar la calidad del software.

En el proceso de tratar de defectos, podrían adoptarse diversas mediciones de defecto directa y

otras mediciones de calidad indirecta (utilizados como indicadores de la calidad), formando un

espacio multidimensional de medición se denomina perfil de calidad (Humphrey, 1998). Estos

resultados de medición deben analizarse mediante diversos modelos para proporcionar la

evaluación de la calidad y los comentarios para el proceso general de desarrollo de software. Parte

IV trata estos temas. Por extensión, la ingeniería de calidad puede verse también como defecto

gestión. Además de la ejecución de las actividades planificadas de control de calidad, ingeniería de

calidad también incluye:

· calidad planificación antes de actividades específicas de control de calidad se llevan a cabo,

· medición, análisis y comentarios para supervisar y controlar las actividades de control de

calidad.

En este sentido, gran parte de la planificación de calidad puede ser vistos como estimación y

planificación para defectos previstos. Gran parte de la información se proporciona en términos de

varios defectos relacionados con las evaluaciones de calidad y predicciones. Estos temas se

describen en el capítulo 5 y la parte IV, respectivamente.

2.4 UNA PERSPECTIVA HISTÓRICA DE CALIDAD

A continuación examinamos popular opiniones y percepciones de calidad en un contexto histórico

y seguimiento de la evolución de la función de la calidad del software en ingeniería de software.

Evolución de las percepciones de calidad

Antes de software y las industrias de tecnología (IT) entraron en la existencia de información,

calidad ha sido asociado con objetos físicos o sistemas, tales como automóviles, herramientas,

receptores de radio y televisión, etc.. En este entorno tradicional, QA es típicamente asociada con

el proceso de fabricación. El objetivo es garantizar que los productos son conformes a sus

especificaciones. Es más, estas especificaciones a menudo acompañan los productos terminados,

para que los compradores o usuarios les pueden comprobar para referencia. Por ejemplo, la Guía

del usuario para equipos estéreo a menudo muestra sus especificaciones de dimensiones físicas,

las respuestas de frecuencia, distorsión armónica total y otra información pertinente.

Ya que muchos elementos en las especificaciones del producto se especifican de rangos y

tolerancia a errores, reducir la variación en el sector manufacturero ha sido el punto central de

control estadístico de calidad. Problemas de calidad son sinónimos de no conformidad con las

especificaciones o defectos observados, definidos por la no conformidad. Por ejemplo, la utilizadas

"calidad inicial" para automóviles por el industrial grupo J.D. Power and Associates (en línea en

www. jdpa. maíz) se define como el número promedio de problemas denunciados por vehículo

100 por propietarios durante los tres primeros años (que solían contar sólo el primer año) de su

propiedad basada en los resultados de la encuesta actual. Otra medida de calidad usados para

automóviles, fiabilidad, se mide por el número de problemas durante un tiempo para así, ¿cuál es

la calidad del SOFTWARE? 25 diferentes etapas de la vida de un automóvil. Por lo tanto, se trata

generalmente como la medida más importante de la calidad de los vehículos usados.

Con el desarrollo de las industrias de servicios, una visión emergente de calidad es que el negocio

necesita adaptarse a las expectativas dinámicamente cambiantes de los clientes, con el centro de

control de calidad pasando cero defectos en productos cero deserción de clientes (Jr. Reichheld y

Sasser1990). La lealtad del cliente debido a su experiencia general con el servicio es más

importante que sólo conforme a algunas especificaciones prescritas o normas.

Segun (Prahalad y Krishnan, 1999), la industria del software ha incorporado la conformidad y los

puntos de vista de servicio de calidad, y software de alta calidad puede definirse por tres

elementos básicos: conformidad, la adaptabilidad y la innovación. Esta vista está de acuerdo en

general con las múltiples facetas de calidad del software que descritos hasta ahora. Cambian

muchas razones para esta vista de la calidad y el control de calidad diferente centra (Beizer, 1998).

Por ejemplo, los supuestos fundamentales de las limitaciones físicas, continuidad,

cuantificabilidad, compositioddecomposition, etc., no pueden ampliar o asignados para el mundo

del software flexible. Por tanto, diferentes técnicas de control de calidad cubiertos en este libro

que se utiliza.

Calidad en ingeniería de software

Dentro de la ingeniería de software, la calidad ha sido uno de los varios factores importantes,

incluyendo el costo, programación y funcionalidad, que han sido estudiados por investigadores y

profesionales (Blum, 1992; Humphrey, 1989; Ghezzi et al, 2003; von Mayrhauser, 1990). Estos

factores determinan el éxito o el fracaso de un producto de software en entornos de mercado en

evolución, pero pueden tener importancia distinto para diferentes periodos de tiempo y distintos

segmentos del mercado.

En Musa y Everett (1990), estas variables principales preocupaciones convenientemente fueron

usadas para dividir ingeniería de software en cuatro fases progresivas:

1. En la etapa de thefunctional, fue el foco en proporcionar las funciones automatizadas para

reemplazar

2. En la etapa de planificación, fue el foco en la introducción de características importantes y

nuevas sys-

3. En la etapa de costo, el foco fue sobre la reducción de los precios para mantenerse competitivo

acompañado por el uso generalizado de las computadoras personales.

4. En la etapa de fiabilidad, el foco fue gestionar las expectativas de calidad de los usuarios bajo la

dependencia creciente de software y alto costo o graves daños relacionados con errores de

software.

Podemos ver un aumento gradual en la importancia de la calidad en ingeniería de software. Esta

caracterización general está de acuerdo con lo que hemos discutido hasta ahora, a saber, la

importancia de centrarse en atributos de calidad centrada en la corrección en nuestro esfuerzo QA

de modernos sistemas de software.

2.5 ¿CUÁL ES LA CALIDAD DEL SOFTWARE?

A la conclusión de este capítulo, podemos responder la pregunta inicial, "¿qué es la calidad del

software?' como sigue:

· Calidad de software pueden incluir muchos atributos diferentes y puede ser de definidas y

percibidas diferente en función de personas diferentes funciones y responsabilidades. 26

¿Cuál es la calidad del SOFTWARE?

· Aprobamos en esta vista de libro centrada en la corrección de calidad, es decir, alta calidad

significa ninguno o pocos problemas de daños limitados a los clientes. Estos problemas

son encontrados por los usuarios de software y causados por defectos de software

interno.

La respuesta a una pregunta relacionada, "¿Cómo garantiza calidad como se definió

anteriormente?' incluyen muchos software de control de calidad y calidad de las actividades que

se describen en el resto de este libro de ingeniería.

Problemas

2.1 ¿Qué es la calidad del software?

2.2

¿Qué otras vistas no mencionan en la sección 2.1 puede piensas?

2.3

¿(atributos de calidad)?

2.4

falla, accidente. ¿Cuál es la relación entre ellos? ¿Qué errores de (software)?

2.5

(Observe que empezamos con la fabricación en nuestra perspectiva histórica de calidad).

2.6

¿Entre pruebas y calidad?

CAPÍTULO 3 ASEGURAMIENTO DE LA CALIDAD

Con las definiciones de calidad centrada en la corrección adoptadas en el capítulo anterior para

este libro, se pueden ver las actividades centrales para la garantía de calidad (QA) como para

garantizar que pocas, o ninguna, defectos en el sistema de software cuando se entregan a sus

clientes o se lanzó al mercado. Además, queremos asegurarnos de que estos defectos restantes

causará daños o interrupciones mínimas. En este capítulo, la encuesta alternativas existentes de

control de calidad y técnicas relacionadas y examinar las formas concretas que se emplean para

hacer frente a defectos.

A través de este examen, nos podemos abstraer a varias maneras genéricos para lidiar con

defectos, que pueden utilizarse para clasificar estas alternativas de control de calidad.

Descripciones detalladas y una comparación general de los relacionados con las actividades de

control de calidad y técnicas se presentan en parte I1 y parte 111.

3.1 CLASIFICACIÓN: QA COMO TRATAR DE DEFECTOS

Un examen detallado de cómo diferentes alternativas QA acuerdo con defectos puede ceder un

esquema de clasificación genérica que puede utilizarse para ayudarnos a seleccionar mejor,

adaptar y utilizar distintas alternativas de control de calidad y técnicas relacionadas para

aplicaciones específicas. A continuación describimos un esquema de clasificación inicialmente

propuesto en Tian (2001) y lo ilustran con ejemplos.

Un esquema de clasificación

Con las definiciones de defecto que figuran en el capítulo anterior, podemos ver diferentes

actividades de control de calidad como intentar prevenir, eliminar, reducir o contener diversos

problemas específicos con diferentes aspectos de defectos. Podemos clasificar estas alternativas

de control de calidad en las siguientes tres categorías genéricas:

· Defecto de prevención a través de error de bloqueo o eliminación de código de error:

actividades de control de calidad de estos impiden que ciertos tipos de errores que se

inyecta en el software. Dado que los errores son las acciones humanas falte o sea

incorrectas que conducen a la inyección de fallas en los sistemas de software, podemos

directamente corregir o bloquear estas acciones o eliminar las causas subyacentes para

ellos. Por lo tanto, prevención de defecto puede hacerse de dos maneras genéricos:

-Eliminar ciertas fuentes de error, tales como eliminar ambigüedades o corregir errores

humanos, que son la raíz causas de los errores.

-Faultprevention o bloqueo directamente corregir o bloqueando estas acciones humanas

faltantes o son incorrectas. Este grupo de técnicas rompe a la relación causal entre las

fuentes de errores y fallas mediante el uso de algunas herramientas y tecnologías,

aplicación de ciertas normas de proceso y producto, etc..

· Defecto reducción a través de la detección de fallas y eliminación: QA estas alternativas

detectar y eliminar ciertas fallas, una vez que han sido inyectados en los sistemas de

software. De hecho, las actividades de control de calidad más tradicionales entran en esta

categoría. Por ejemplo,

-Inspección directamente detecta y elimina los errores del código de software, diseño, etc..

-Pruebas elimina errores basados en observaciones de error relacionados durante la ejecución del

programa.

Varios otros medios, basadas en análisis estáticos o en observaciones de ejecuciones dinámicas,

pueden aplicarse a reducir el número de errores en un sistema de software.

· Contención de defecto por incumplimiento de prevención y contención: estas medidas de

contención se centran en los fracasos que los contengan áreas locales por lo que no hay

observable de errores global para los usuarios, o limitar los daños causados por fallas en el

sistema software. Por lo tanto, contención de defecto puede hacerse de dos maneras

genéricos:

-Algunas alternativas de control de calidad, tales como el uso de técnicas de tolerancia a

fallos, rompen a la relación causal entre fallas y errores para que fallas locales no causará

fallas globales, por lo tanto "tolerar" esas fallas locales.

-Una extensión relacionada con tolerancia a errores es medidas de contención para evitar

consecuencias catastróficas, como la muerte, lesiones personales y propiedad grave o

daños ambientales, en caso de fallas. Por ejemplo, contención de fracaso para el software

de control en tiempo real utilizado en reactores nucleares puede incluir muros de

hormigón rodear y contienen material radiactivo de reactor de fusión-abajo debido a fallas

de software, a fin de evitar daños al medio ambiente y la salud de las personas.

Tratar con defectos de previo y posterior-la release

Diferentes alternativas de control de calidad pueden verse como un esfuerzo concertado para

hacer frente a errores, fallos o errores, a fin de lograr el objetivo común de calidad y mejora.

Prevención de defectos y las actividades de reducción de defecto tratan directamente con los

procesos que compiten de inyección de defecto y eliminación durante el proceso de desarrollo de

software (Humphrey, 1995).

Afectan a los contenidos de defecto, o el número de fallos, en los productos de software terminó

trabajando para reducir las inyecciones de defecto preliminar o quitar tantos tales defectos como

sea posible antes del lanzamiento del producto. La izquierda de fallas en los productos de software

terminado a menudo se denomina "defectos latentes", que pueden permanecer inactivo durante

algún tiempo, pero tienen el potencial de causar problemas a los clientes y usuarios de los

productos - una situación que nos gustaría aliviar o evitar. Más análisis de diferentes tipos de

defectos pueden encontrarse en el capítulo 20. Técnicas relacionadas para identificar áreas de alto

riesgo enfoca defecto reducción y control de calidad puede encontrarse en el capítulo 2 1.

Después de la versión del producto, las fallas observaron y problemas notificados por los clientes y

los usuarios también deben corregirse, que a su vez, podría conducir a la reducción de defectos y

producto de mejor calidad. Sin embargo, uno no puede confiar en estos informes de problemas

excelente y renunciar a actividades de prevención y reducción de defecto preliminar, porque el

costo de corregir defectos después de versión del producto es significativamente superior antes de

producto liberar debido a las numerosas instalaciones. Además, el daño a la reputación de los

proveedores de software puede ser devastador.

Controlado de pruebas de campo, conocido como "los pruebas beta", y técnicas similares

discutidos aún más en el capítulo 12 han sido sugeridas y utilizados para complementar las

actividades QA preliminares. En el capítulo 4 se examinan cuestiones de procesos relacionados.

Por otro lado, defecto contención actividades tienen por objeto reducir al mínimo el impacto

negativo de estos fallos restantes durante uso operativo después de la versión del producto. Sin

embargo, la mayoría de las técnicas de contención de defecto implica despidos o duplicaciones y

requiere mucho más esfuerzo de desarrollo para diseñar e implementar funciones relacionadas.

Por lo tanto, se limitan normalmente a las situaciones de fallas en el campo asociados con daños

sustanciales, como en toda la empresa de base de datos para datos críticos, redes de

telecomunicaciones global y diversos sistemas críticos de seguridad controlados por computadora

tales como dispositivos médicos y reactores nucleares. Los detalles sobre estas cuestiones pueden

encontrarse en el capítulo 16.

Representación gráfica del esquema de clasificación

La anterior clasificación de actividad de control de calidad puede ser ilustrada en la figura 3.1,

formando una serie de barreras que representa las líneas de fractura puntos. Cada barrera elimina

o bloques evita consecuencias indeseables o defecto de fuentes. Incluye información específica

que representa:

· La barrera entre la entrada a actividades de desarrollo de software (cuadro de la izquierda) y

el sistema de software (cuadro central) representa las actividades de prevención de

defectos.

· La curva barrera entre el sistema de software (cuadro central) y el escenario de uso y

comportamiento observado (cuadro de la derecha) representa las actividades de

eliminación de defecto o fallo como la inspección y pruebas.

· La barrera recta a la derecha, cerca de la barrera de eliminación de fallos anteriores

representa las actividades de prevención de fallos como tolerancia de fallos.

· Representa la última barrera, que rodea los casos de error seleccionado, actividades de

contención de fracaso.

En la figura 3.1, fallas se representan como entidades en un círculo en el cuadro central para el

sistema de software. Fuentes de error se representan como entidades en un círculo en el cuadro

de la izquierda para la entrada a las actividades de desarrollo de software. Fallas se representan

como las instancias en un círculo en el cuadro de la derecha para escenarios de uso y resultados

de la ejecución. Figura 3.1 muestra también la

Figura 3.1 genérico maneras para lidiar con defectos

entre estas actividades de control de calidad y errores relacionados, errores y fallas a través de

ejemplos concretos, como sigue:

· Algunos de los errores conceptuales humanos, tales como e6 de origen del error, se eliminan

directamente por las actividades de la eliminación de origen del error, como a través de

una educación mejor para corregir la específica humana conceptual errores.

· Otras acciones incorrectas o errores, como algunas de las causadas por error fuente e3 y e5,

están bloqueados. Si una fuente de error puede bloquearse constantemente, como e5, es

equivalente a ser eliminado. Por otra parte, si una fuente de error está bloqueada a veces,

como e3, complementarias o alternativas técnicas de prevención de defectos deben

utilizarse, similar a la situación de otras fuentes de error como el y e2 e4, donde fallos

puedan ser inyectada en el sistema debido a estas fuentes de error.

· Algunos errores, como f4, son detectados directamente a través de la inspección o otros

análisis estático y eliminados como parte de o como seguimiento a estas actividades, sin la

participación de la observación de fallas.

· Otros errores, como la f3, se detectan a través de pruebas o de otras alternativas de control

de calidad basado en la ejecución mediante la observación de su comportamiento

dinámico. Si no se observa en estas actividades de control de calidad, los fallos

relacionados se encuentra examinando el registro de ejecución y eliminados como parte

de o como seguimiento a estas actividades. En consecuencia, no fallas operacionales

después de versión del producto se ser causadas por estos errores.

· Aún están bloqueados otros fallos, tal asfl, a través de tolerancia a errores de algunos casos

de ejecución. Sin embargo, técnicas de tolerancia a errores normalmente no identificar y

corregir las fallas subyacentes. Por lo tanto, estos fallos todavía podrían conducir a fallas

operacionales en diferentes entornos dinámicos, tal asp a x 2.

· Entre las instancias de fracaso, estrategia de contención del fracaso puede aplicarse para

aquellos con consecuencias graves. Por ejemplo, XI es una instancia, donde se aplica

contención de fracaso, como se muestra en el círculo punteado circundante.

A continuación nos encuesta distintas alternativas de control de calidad, organizados en el

esquema de clasificación anterior y proporcionan punteros a capítulos relacionados que se

describen en detalle.

3.2 PREVENCIÓN DE DEFECTOS DE

Las alternativas QA comúnmente conocida como las actividades de prevención de defecto pueden

utilizarse para la mayoría de los sistemas de software para reducir la posibilidad de inyecciones de

defecto y el posterior costo para hacer frente a estos defectos inyectados. La mayoría de las

actividades de prevención de defectos asume que hay fuentes de error conocido o acciones de

missinghncorrect que las inyecciones de culpa, como sigue:

· Si los errores humanos son las fuentes de error, educación y formación pueden ayudarnos

quitar estas fuentes de error.

· Si imprecisos diseños e implementaciones que difiera de las especificaciones de producto o

intenciones de diseño son las causas de los fallos, métodos formales pueden ayudarnos

prevenir tales desviaciones.

· Si no conformidad para selecciona procesos o normas es el problema que conduce a las

inyecciones de falla, entonces conformidad de proceso o aplicación estándar puede

ayudar a uso impedir la inyección de errores relacionados.

· Si determinadas herramientas o tecnologías pueden reducir las inyecciones de culpa en

entornos similares, que deben ser aprobadas.

Por lo tanto, análisis de causa raíz se describe en el capítulo 21 son necesarios para establecer

estas condiciones previas, o causas, por faltas inyectadas o potenciales, para que las actividades

de prevención adecuadas defecto pueden aplicarse para evitar la inserción de fallos similares en el

futuro. Una vez establecidas estas relaciones causales, actividades adecuadas de control de

calidad, a continuación, se pueden seleccionadas y aplicadas para prevención de defectos.

3.2.1 Educación y formación

Educación y formación proporcionan soluciones basadas en la gente para eliminación de origen

del error. Se ha tiempo observado por los profesionales de software que el factor de la gente es el

factor más importante que determina la calidad y, en última instancia, el éxito o el fracaso de la

mayoría de los proyectos de software. Educación y formación de profesionales de software

pueden ayudarles a controlar, administrar y mejorar su forma de trabajar. Esas actividades

también pueden ayudar a garantizar que tienen pocas, o ninguna, errores relacionados con el

producto y el desarrollo de productos. La eliminación de estos errores humanos ayudará a impedir

que ciertos tipos de errores que se inyecta en productos de software. La educación y el esfuerzo

de formación para la eliminación de código de error deberían centrarse en las siguientes áreas:

· Conocimiento de producto y el dominio specijic. Si las personas involucradas no están

familiarizadas con el dominio de aplicación o tipo de producto, hay una buena posibilidad

de que se apliquen soluciones mal. Por ejemplo, los desarrolladores familiarizados con

software integrado pueden diseñar software sin tener en cuenta sus limitaciones

ambientales, provocando a diversos problemas de la interfaz y la interacción entre el

software y su entorno físico.

· Software desarrollo conocimientos y experiencia desempeña un papel importante en el

desarrollo de productos de software de alta calidad. Por ejemplo, la falta de experiencia

con la especificación de análisis y producto de requisito generalmente conduce a muchos

problemas y repasar en posterior diseño, codificación y pruebas de actividades.

· Conocimientos sobre metodología, tecnología y herramientas de desarrollo también

desempeña un papel importante en el desarrollo de productos de software de alta

calidad. Por ejemplo, en una implementación de la tecnología de contorsionista (Mills et

al., 1987b), si los desarrolladores no están familiarizados con los componentes clave de

verificación formal o pruebas estadísticas, hay pocas posibilidades para la producción de

productos de alta calidad.

· Conocimiento del proceso de desarrollo. Si el personal de proyectos no tienen un buen

conocimiento del proceso de desarrollo, es poco probable que el proceso puede aplicarse

correctamente. Por ejemplo, si las personas involucradas en el desarrollo de software

incremental no sé cómo encajan los esfuerzos de desarrollo individuales para diferentes

incrementos, el desarrollo sin coordinación puede llevar a muchos problemas de interfaz o

interacción.

3.2.2 Método formal

Métodos formales proporcionan una forma para eliminar ciertas fuentes de error y para

comprobar la ausencia de fallos relacionados. Métodos de desarrollo formal, o métodos formales

en corto, incluyen la especificación formal y verificación formal. Especificación formal se ocupa de

producir un conjunto claro de especificaciones del producto para que los requerimientos del

cliente, así como las limitaciones ambientales y las intenciones de diseño, se reflejan

correctamente, lo que reduce las posibilidades de las inyecciones de errores accidentales.

Verificación formal comprueba la conformidad de diseño de software o código contra estas

especificaciones formales, garantizando así que el software está libre de errores con respecto a

sus especificaciones formales.

Diversas técnicas existen para especificar y verificar la "corrección" de los sistemas de software, es

decir, para responder a las preguntas: "¿cuál es el comportamiento correcto?", y "cómo

comprobarlo?' Se describen algunas de estas técnicas en el capítulo 15, con las ideas básicas que

presentó brevemente a continuación.

· Métodoel oficial más antiguo y más influyente es el enfoque axiomático así llamada (Hoare,

de 1969; Zelkowitz, 1993). En este enfoque, el "significado" de un elemento de programa

o la interpretación formal de los efectos de su ejecución se resumieron en un axioma.

Reglas y axiomas adicionales se usan para conectar diferentes piezas juntos. Un conjunto

de condiciones formales que describe el estado del programa antes de la ejecución de un

programa había llamado sus condiciones previas y el conjunto después de la ejecución del

programa los postcondiciones. Este método comprueba que un determinado programa

satisface su prescrito pre y post-conditions.

· Otras técnicas de verificación formal influyentes incluyen la transformación de predicados

basado en ideas de condición más débiles (Dijkstra, 1975; Gries, 1987), y cálculo de

programa o enfoque funcional basado en funciones matemáticas y ejecuciones simbólicas

(Mills et al, 1987a). Las ideas básicas son similares al enfoque axiomático, pero los

procedimientos de pruebas son algo diferentes.

· Varios otros limitado alcance o también existen técnicas semiformales, que compruebe para

determinadas propiedades en lugar de probar la corrección completa de programas. Por

ejemplo, técnicas control de modelo están ganando popularidad en la comunidad de

investigación de ingeniería de software (Ghezzi et al., 2003). Varios métodos semiformales

basados en formularios o tablas, como (Parnas y Madey, 1995), en lugar de lógica formal o

funciones matemáticas, han encontrado también aplicaciones importantes.

Hasta ahora, el mayor obstáculo para métodos formales es el alto costo asociado con la difícil

tarea de llevar a cabo estas actividades intensivas humanas correctamente sin suficiente apoyo

automatizado. Este hecho también explica, en un grado, la creciente popularidad de alcance

limitado y enfoques semiformales.

3.2.3 Otras técnicas de prevención de defectos

Otras técnicas de prevención de defecto, que se describen en el capítulo 13, los basados en

tecnologías, herramientas, procesos y estándares, incluidos se presentan brevemente a

continuación:

· Además de los métodos formales encuestados por encima, el uso de otros métodos de

software apropiado o tecnologías también pueden ayudar a reducir las posibilidades de las

inyecciones de fallas. Muchos de los problemas de baja calidad "software de grasa"

podrían abordarse por metodologías disciplinados y regreso a elementos esenciales de

alta calidad "software de inclinarse" (Wirth, 1995).

· Del mismo modo, el uso de la información oculta el principio (Parnas, 1972) puede ayudar a

reducir la complejidad de las interfaces de programa y las interacciones entre los

diferentes componentes, reduciendo así la posibilidad de problemas relacionados.

· Un mejor administrado proceso también puede eliminar muchos problemas sistemáticos. Por

ejemplo, no tener un proceso definido o no lo siguiente para la administración de la

configuración de sistema puede dar lugar a incoherencias o problemas entre los diferentes

componentes de la interfaz. Por lo tanto, garantizar la conformidad y la definición de

proceso adecuado ayuda a eliminar algunas de esas fuentes de error. Del mismo modo,

aplicación de determinadas normas para determinados tipos de productos y actividades

de desarrollo también reduce las inyecciones de fallas.

· a veces, herramientas de software específico también pueden ayudar a reducir las

posibilidades de las inyecciones de fallas. Por ejemplo, un editor de sintaxis dirigida que

equilibra automáticamente cada paréntesis de apertura, "{", con un paréntesis de cierre,

"}", puede ayudar a reducir los problemas sintácticos en programas escritos en el lenguaje

C.

Se necesita trabajo adicional para guiar la selección de procesos adecuados, estándares,

herramientas y tecnologías, o adaptar las existentes para el entorno de aplicaciones específicas.

Sistemas eficaces de vigilancia y enforceqent también son necesarios para garantizar que se sigan

los procesos seleccionados o normas, o se utilizan las herramientas seleccionadas o tecnologías

correctamente, para reducir la posibilidad de inyecciones de fallas.

3.3 DEFECTO REDUCCIÓN

Para la mayoría de los grandes sistemas de software en uso hoy en día, es poco realista esperar

que las actividades de prevención de defecto encuestadas por encima de 100% eficaz en la

prevención de las inyecciones de errores accidentales.

Por lo tanto, necesitamos técnicas eficaces para eliminar como muchas de las fallas inyectadas

posible bajo las restricciones del proyecto.

3.3.1 Inspección: Detección de fallas directas y eliminación

Inspecciones de software son críticos exámenes de artefactos de software por inspectores

humanos encaminados a descubrir y corregir fallas en los sistemas de software. Inspección es una

alternativa QA conocida familiar para los profesionales con mayor experiencia de calidad de

software. La obra más antigua y más influyente en la inspección de software es Fagan inspección

(Fagan, 1976). Varias otras variaciones han sido propuestos y solía realizar eficazmente la

inspección en diferentes entornos. Una discusión detallada sobre los procesos de inspección y

técnicas, aplicaciones y resultados y muchos temas relacionados puede encontrarse en el capítulo

14. Las ideas básicas de inspección se describen a continuación:

· Inspecciones son lectura crítica y análisis de código de software u otros artefactos de

software, tales como diseños, especificaciones de productos, planes de pruebas, etc.

· Inspecciones normalmente llevan a cabo varios inspectores humanos, a través de un proceso

de coordinación. Pueden utilizar varias fases de inspección o sesiones.

· Se detectaron errores directamente en la inspección por los inspectores humanas, ya sea

durante sus inspecciones individuales o varios tipos de sesiones de grupo.

· Identificado errores deben ser eliminados por el proceso de inspección, y también su

eliminación debe verificarse.

· Los procesos de inspección varían, pero generalmente incluyen algunas actividades de

planificación y seguimiento, además de la actividad de inspección de núcleo.

· La formalidad y la estructura de las inspecciones pueden variar, de opiniones muy informales

y tutoriales, a variaciones bastante formales de inspección de Fagan, inspecciones de

corrección acercando el rigor y la formalidad de métodos formales.

Inspección más comúnmente se aplica al código, pero también se podría aplicar a las

especificaciones de requisitos, diseños, planes de pruebas y casos de prueba, manuales de usuario

y otros documentos o artefactos de software. Por lo tanto, inspección puede utilizarse durante el

proceso de desarrollo, particularmente en el desarrollo de software antes de que nada puede ser

probado. En consecuencia, inspección puede ser una alternativa eficaz y económica de control de

calidad debido al mucho mayor costo de corregir defectos finales frente a fijar los principios.

Otro beneficio potencial importante de inspección es la oportunidad de llevar a cabo análisis

causal durante el proceso de inspección, por ejemplo, como un paso adicional en la inspección de

Gilb (Gilb y Graham, 1993). Estos resultados de análisis causal pueden utilizarse para orientar las

actividades de prevención de defectos quitando fuentes de error identificados o corregir

identificado las acciones humanas missinghncorrect. Estas ventajas de inspección se describen con

más detalle en el capítulo 14 y en comparación con otras alternativas de control de calidad en el

capítulo 17.

3.3.2 Prueba: Eliminación de observación y fallas de fallo

La prueba es una de las partes más importantes de control de calidad y la actividad de control de

calidad más comúnmente realizada. Pruebas implica la ejecución de software y la observación del

comportamiento del programa o del resultado. Si se observa una falla, el registro de ejecución, a

continuación, se analiza para localizar y corregir el fault(s) que produjo el error. Como una parte

importante de este libro, diversas cuestiones relacionadas con pruebas y comúnmente usados

técnicas de pruebas están cubiertas en parte I1 (capítulos 6 a 12).

Individuo pruebas técnicas y actividades puede clasificarse mediante diversos criterios y

examinado en consecuencia, como se explica a continuación. Aquí prestamos especial atención a

cómo tratan de defectos. Un esquema más amplio de la clasificación se presenta en el capítulo 6.

¿Cuando puede una actividad específica de prueba realizadas y se detectaron errores

relacionados?

Porque pruebas son una actividad de control de calidad basado en la ejecución, un requisito previo

para pruebas reales es la existencia de la unidades de software implementado, componentes o

sistema a prueba, aunque la preparación para las pruebas puede llevarse a cabo en fases

anteriores de desarrollo de software. Como resultado, pruebas reales pueden dividirse en varias

sub-phases desde la fase de codificación hasta apoyo excelente producto, incluyendo: pruebas

unitarias, componente pruebas, pruebas, pruebas, pruebas, pruebas beta, etc. de aceptación de

sistema de integración. La observación de las fallas puede asociarse con estos sub-phases

individuales, y la identificación y eliminación de errores relacionados pueden estar asociadas con

el sistema completo, componentes o unidades individuales correspondientes.

Si prototipos de software se usan, como en el proceso de espiral, o si un sistema de software se

desarrolla mediante un proceso iterativo o incremental, pruebas pueden suele comenzar mucho

antes. Más tarde pruebas de integración desempeña un papel mucho más importante en la

detección de problemas de interoperabilidad entre componentes de software diferentes. Esta

cuestión se examina más detalladamente en el capítulo 4, en relación con la distribución de las

actividades de control de calidad en los procesos de software.

¿Lo que probar y qué tipo de errores se encuentran?

Pruebas de caja negra (o funcional) verifica el manejo correcto de las funciones externas que

proporciona el software, o si el comportamiento observado se ajusta a las expectativas del usuario

o las especificaciones del producto. Pruebas de caja blanca (o estructurales) comprueba la

correcta implementación de unidades internas, estructuras y relaciones entre ellos. Diversas

técnicas pueden utilizarse para crear modelos y generar casos de prueba para realizar pruebas

sistemáticas de cuadro de negro o blanco.

Cuando se realizan pruebas de caja negra, se observan fallas relacionadas con funciones externas

específicas, líder correspondientes acusa a ser detectado y eliminado. El énfasis está en la

reducción de las posibilidades de encontrar problemas funcionales por los clientes de destino. Por

otro lado, cuando pruebas de caja blanca, realiza, pueden observarse fallos relacionados con las

implementaciones internas, llevando a los fallos correspondientes ser detectado y eliminado. El

énfasis está en la reducción de errores internos para que hay menos posibilidades de errores más

tarde no importa el tipo de entorno de aplicaciones, el software está sujeto a.

¿Cuando, o en qué defecto nivel, para detener la prueba?

La mayoría de las técnicas tradicionales de pruebas y pruebas sub-phases utiliza algún tipo de

información de cobertura como criterio de parada, con el supuesto implícito que 36 la cobertura

mayor Garantía de calidad

significa mayor calidad o niveles inferiores de defectos. Por ejemplo, listas de comprobación a

menudo se utilizan para hacer seguro principales funciones y escenarios de uso se prueban antes

del lanzamiento del producto. Cada instrucción o unidad en un componente debe estar cubierta

antes de pruebas de integración posterior pueden proceder. Técnicas de pruebas más formales

incluyen pruebas de flujo de control que intenta cubrir rutas de ejecución y dominio pruebas que

intenta cubrir los límites entre diferentes subdominios de entrada. Dicha información de cobertura

formal sólo puede obtenerse mediante análisis de cobertura caro y herramientas de pruebas. Sin

embargo, medición de cobertura aproximada puede obtenerse fácilmente mediante el examen de

la proporción de elementos probados en varias listas.

Por otro lado, objetivos de confiabilidad del producto pueden utilizarse como un criterio más

objetivo para detener la prueba. El uso de este criterio requiere las pruebas a que se realice en un

entorno similar a uso real por los clientes de destino, por lo que puede obtenerse evaluación

realista de fiabilidad, resultando en la llamada basada en el uso estadístico pruebas.

El criterio de cobertura asegura que ciertos tipos de errores son detectados y eliminados, lo que

reduce el número de defectos a un nivel inferior, aunque la calidad no es evaluada directamente.

La prueba basada en el uso y el criterio de fiabilidad relacionados garantizan que las fallas que son

más susceptibles de causar problemas a los clientes tienen más probabilidades de ser detectado y

eliminado, y la confiabilidad del software alcanza ciertos objetivos antes de probar paradas.

3.3.3 Otras técnicas y la identificación de riesgos

La inspección es las estáticas técnicas más comúnmente utilizadas por detección de defecto y

eliminación.

Varias otras técnicas estáticos están disponibles, incluyendo varios análisis de modelo formal

basado, como análisis de algoritmos, análisis de tabla de decisión, análisis del valor límite,

autómata finito y modelado de la red de Petri, control y análisis de flujo de datos, árboles de fallas

de software, etc..

Del mismo modo, además de pruebas, otras técnicas dinámicas, basada en la ejecución, también

existen para la eliminación y detección de fallas. Por ejemplo, creación de prototipos, simulación y

simbólica ejecución pueden ayudarnos a detectar y eliminar varios defectos en el proceso de

desarrollo de software, antes de pruebas a gran escala se convierte en una alternativa viable.

Por otro lado, en el campo medición y análisis relacionados, tales como análisis de rendimiento y

tiempo para sistemas en tiempo real, y análisis de accidentes y reconstrucción mediante árboles

de fallos de software y evento para sistemas críticos de seguridad, puede también nos ayudan a

localizar y eliminar defectos relacionados. Aunque estas actividades son una parte importante de

soporte de productos, no son considerados como parte de las actividades tradicionales de control

de calidad debido a los daños que ha hecho a las aplicaciones de los clientes y a la reputación de

los proveedores de software. Como se menciona en la sección 3.1, debido a los beneficios de

tratar problemas antes del producto versión en lugar de después de la versión del producto, el

objetivo de estas actividades es proporcionar información útil para las futuras actividades de

control de calidad.

Un completo estudio de técnicas para la detección de fallas y eliminación puede encontrarse en

los capítulos 6 y 14, en relación con las técnicas de pruebas y de control. Técnicas relacionadas

para tratar de excelente defectos están cubiertos en el capítulo 16 en relación con tolerancia a

errores y técnicas de contención de fracaso.

Distribución de culpa es muy desigual para la mayoría de los productos de software,

independientemente de su tamaño, funcionalidad, lenguaje y otras características. La evidencia

empírica mucho ha acumulado durante los años para apoyar la regla 80: 20 llamados, que afirma

que el 20% de los componentes de software son responsable del 80% de los problemas. Estos

componentes problemáticos general se caracteriza por propiedades de medidas específicas sobre

su diseño, tamaño, complejidad, historial de cambios y otras características del producto o

proceso. Debido a la distribución desigual de fallos entre los componentes de software, hay una

gran necesidad para que técnicas de identificación de riesgos analizar estos datos de medición tan

esa inspección, pruebas, 37 de contención de defecto

y otras actividades de control de calidad se puede ettectively más centrado en los componentes

potencialmente alto defecto. Estas técnicas de identificación de riesgos se describen en el capítulo

2 1, incluyendo: técnicas de análisis estadístico tradicional, análisis de componentes principales y

análisis discriminante, redes neuronales, modelado basado en árbol, técnicas de coincidencia de

patrón y algoritmos de aprendizaje.

Estas técnicas se comparan con arreglo a varios criterios, incluyendo: precisión, simplicidad,

disponibilidad temprana y estabilidad, facilidad de interpretación del resultado, constructivo

información y orientación para mejorar la calidad y disponibilidad de herramientas de soporte.

Técnicas de identificación de riesgos adecuado pueden seleccionarse para adaptarse a entornos de

aplicación específicos para identificar los componentes de software de alto riesgo para inspección

centrado y pruebas.

3.4 DEFECTO CONTENCIÓN

Debido a la gran tamaño y alta complejidad de la mayoría de sistemas en uso hoy en día, las

actividades de reducción de defecto anterior pueden sólo reducir el número de fallos a un nivel

bastante bajo, pero no completamente eliminarlos. Para sistemas de software donde impacto de

fracaso es sustancial, como muchos en tiempo real los subsistemas de software de control utilizan

en médica, nuclear, transporte y otros sistemas integrados, este riesgo de defecto bajo nivel y el

fracaso puede ser insuficiente. Se necesitan algunas alternativas adicionales de control de calidad.

Por otro lado, se pueden desencadenar esos pocos defectos restantes bajo condiciones raras o

inusuales escenarios dinámicos, haciéndolo poco realista para intentar generar el enorme número

de casos de prueba para cubrir todas estas condiciones o realizar una inspección exhaustiva

basada en todos los escenarios posibles. En cambio, otros medios deben utilizarse para prevenir

fallas por romper las relaciones causales entre estos errores y los fracasos resultantes, así "tolerar"

esos fallos, o contener los fracasos reduciendo el daño resultante.

3.4.1 Tolerancia a errores software

Ideas de tolerancia de fallos de software proceden de diseños de tolerancia de fallos en los

sistemas de hardware tradicionales que requieren mayores niveles de confiabilidad, disponibilidad

y fiabilidad. En esos sistemas, piezas de repuesto y unidades de copia de seguridad se utilizan

comúnmente para mantener los sistemas en condiciones operativas, tal vez en una capacidad

reducida, en la presencia de errores de unidad o parte. Las técnicas de tolerancia de fallos de

software principal incluyen bloques de recuperación, programación de N-versión (NVP) y sus

variaciones (Lyu, 1995b). Vamos a describir estas técnicas y examinar cómo lidiar con fallas y

errores relacionados en el capítulo 16, con las ideas básicas que se resumen a continuación:

· Recuperación bloques utilizan repetidas ejecuciones (o redundancia en el tiempo) como el

mecanismo básico para tolerancia a fallas. Si se detectan fallas dinámicos en algunas áreas

locales, se repite una parte de la última ejecución, con la esperanza de que esto repite

ejecución no dará lugar a la misma falla. Por lo tanto, fallas locales no se propagarán a

fallas en el mundiales, aunque algunos retardo de tiempo puede estar involucrado.

· NVP usos paralelos de redundancia, donde n copias, cada una de una versión diferente, de

programas cumpliendo las mismas funciones se ejecutan en paralelo. El algoritmo de

decisión en NVP le asegura que las fallas locales en un número limitado de estas versiones

paralelas no pongan en peligro los resultados globales de ejecución. 38 Hecho uno de

aseguramiento de calidad destacar es que en mayoría técnicas de tolerancia a errores,

fallos son normalmente no identificados, por lo tanto, no se elimina, pero sólo tolerados

dinámicamente. Esto es en contraste con las actividades de detección y eliminación de

defecto, como la inspección y pruebas.

3.4.2 Contención de aseguramiento y falla de seguridad

Sistemas críticos de seguridad, la principal preocupación es nuestra capacidad para prevenir

accidentes ocurran, donde un accidente es un error con una grave consecuencia. Probabilidades

de falla incluso bajo software no son tolerables en estos sistemas si estos fracasos todavía es

probable que pueden provocar accidentes. Por lo tanto, además de las técnicas de control de

calidad superior, también se utilizan diversas técnicas específicas para sistemas críticos de

seguridad basados en el análisis de riesgos o lógicos precondiciones para accidentes (Leveson,

1995). Estas técnicas de aseguramiento y mejora de la seguridad se tratan en el capítulo 16. A

continuación se ofrece un breve análisis de cómo cada una de ellas trata con defectos:

· Eliminación de peligro a través de la sustitución, simplificación, disociación, eliminación de

errores humanos específicos y la reducción de materiales peligrosos o condiciones. Estas

técnicas reducen ciertas inyecciones de defecto o sustituyen los no peligrosos para los

peligrosos. El enfoque general es similar a la prevención de defectos y técnicas de

reducción de defecto encuestados antes, pero centrándose en los problemas involucrados

en situaciones peligrosas.

· Reducción de riesgo a través del diseño de la capacidad de control (por ejemplo, liberación de

presión automática en calderas), uso de bloqueo de dispositivos (por ejemplo, bloqueo de

hardwarehoftware) y minimización de fracaso con márgenes de seguridad y redundancia.

Estos

· técnicas son similares a las técnicas de tolerancia de fallos encuestadas arriba, donde se

encuentran las fallas locales sin llegar a fallas del sistema.

· Peligro control mediante la reducción de la exposición, aislamiento y contención (por

ejemplo, las barreras entre el sistema y el medio ambiente), sistemas de protección

(protección activa activada en caso de peligro) y diseño a prueba de fallos (protección

pasiva, error en un estado seguro sin causar más daños). Estas técnicas reducen la

gravedad de las fallas, por lo tanto, debilitando el vínculo entre las fallas y accidentes.

· Control de daños a través de rutas de escape, seguras abandono de productos y materiales y

dispositivos de limitación de daños físicos a personas o equipos. Estas técnicas reducen la

gravedad de los accidentes, lo que limita los daños causados por estos accidentes y

relacionados con errores de software.

Aviso que controlar los riesgos y control de daños anterior son actividades post-failure que

intentan "contener" los fracasos para que no conducirán a accidentes o el daño de accidente

puede controlado o minimizado. Estas actividades son específicas para los sistemas esenciales de

seguridad, que generalmente no están cubiertos en las actividades de control de calidad para

otros sistemas. Por otro lado, muchas técnicas para la prevención de defectos, la reducción y la

tolerancia también pueden utilizarse en sistemas críticos de seguridad para la eliminación de

riesgos y la reducción a través de actividades concretas de seguridad crítica producto

componentes o funciones.

3,5 OBSERVACIONES FINALES DE

De acuerdo a las diferentes formas de abordar diferentes alternativas de control de calidad con

defectos, se pueden clasificar en tres categorías generales: prevención de defectos de 39 de

problemas a través de la eliminación de código de error y bloqueo de actividades de error, tales

como la educación y formación, especificación formal y verificación y adecuada selección y

aplicación de tecnologías apropiadas, herramientas, procesos o normas. Las descripciones

detalladas de estas técnicas específicas y actividades conexas figuran en el capítulo 15 de técnicas

de verificación formal y en el capítulo 13 para el resto.

· Reducción de defecto a través de la inspección, pruebas y otro estática análisis o actividades

dinámicas, para detectar y eliminar los errores de software. Como una de las alternativas

más importantes y ampliamente utilizadas, pruebas se describen en parte I1 (capítulos 6 a

12). Análisis dinámicos relacionados también se describen en el capítulo 12. La otra

alternativa importante, inspección, se describe en el capítulo 14, donde también viene una

breve descripción de las técnicas de análisis estático relacionados.

· Contención de defecto a través de la tolerancia a errores, prevención de fracaso o impacto de

fracaso de minimización, para asegurar la confiabilidad de software y seguridad. La

descripción detallada de estas técnicas específicas y actividades conexas se da en el

capítulo 16.

Literatura de calidad existentes de software generalmente técnicas de reducción de defecto de

portadas como pruebas y control en más detalles de las actividades de prevención de defectos,

mientras que en gran medida ignorar el papel de defecto contención en control de calidad. Este

capítulo reúne información de diversas fuentes para ofrecer un punto de partida común y la base

de información para estudiantes de ingeniería de software y profesionales de calidad de software.

Seguimiento capítulos describen cada alternativa específica con mucho más detalle y ofrecen una

cobertura completa de importantes técnicas de control de calidad, así como la integración de las

actividades de control de calidad en el proceso de mantenimiento y desarrollo de software global

Problemas

3.1 ¿Cuál es la garantía de calidad?

3.2. ¿Cuáles son los distintos tipos de actividades de control de calidad? ¿Conoces cualquier

clasificación distintas de la que se describe en este capítulo basado en enfrentar con defectos? ¿

3.3 Para el producto está trabajando, qué estrategia de control de calidad se utiliza? ¿Otras

estrategias de control de calidad y técnicas podrían ser aplicable o eficaz?

3.4 Puede utilizar las estrategias de control de calidad y técnicas que se describen en este capítulo

para tratar otros problemas, no necesariamente relacionados con el defecto, como la facilidad de

uso, performance, modificabilidad? ¿Además, se pueden generalizar las actividades de control de

calidad descritas en este capítulo para hacer frente a defectos relacionados con cosas que no sea

software?

3.5 Métodos formales de están relacionados con la prevención de defectos y defecto

detectionhemoval. ¿Se puede pensar de otras actividades de control de calidad que abarcan varias

categorías en nuestra clasificación de las actividades de control de calidad en prevención de

defecto, reducción y contención.

3.6 ¿Cuáles son las similitudes y diferencias entre los elementos de los siguientes pares: un)

software de pruebas y el hardware prueba b) software inspección y control de calidad c) otras

cosas (por ejemplo, inspección de vehículos, inspección de casa, inspección de armas de

destrucción masiva) y garantía de seguridad