Post on 25-Oct-2015
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