“Año de la Consolidación del Mar de Grau”

UNIVERSIDAD NACIONAL “SAN LUIS

GONZAGA DE ICA”
FACULTAD DE INGENIERIA DE SISTEMAS
CALIDAD, SOFTWARE Y ASEGURAMIENTO
DE LA CALIDAD DEL SOFTWARE

CURSO
Control de Calidad de Software

INGENIERO
Morales Loaiza, Alonso

INTEGRANTES
Chuquín De la Cruz, Sofía Lisset
Mitacc Alvarez, José Antonio
Mitacc Gutierrez, Emily Estefany
Ñañez Andres, Moises Albeiro

CICLO
VIII

Ica – Perú
2016

1
AGRADECIMIENTOS

Agradecemos a Dios, ya que gracias a él

tenemos a nuestros padres maravillosos, los
cuales nos apoyan en nuestras derrotas y
celebran nuestros triunfos.

A nuestros profesores quienes son nuestros

guías en el aprendizaje, dándonos los últimos
conocimientos para nuestro buen
desenvolvimiento en la sociedad.

2
 ÍNDICE
INTRODUCCIÓN........................................................................................................................................................7
CALIDAD, SOFTWARE Y ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE............................. 8
1. Calidad y software .......................................................................................................................................... 8
1.1. Que es software ......................................................................................................................................... 8
1.2. Ingeniería de software ............................................................................................................................. 8
1.3. Que es CASE................................................................................................................................................ 9
1.4. Atributos de un buen software ............................................................................................................ 9
1.5. ¿Cuáles son los retos fundamentales que afronta la ingeniería del software? ..........10
1.5.1. El reto de la Heterogeneidad....................................................................................................10
1.5.2. El reto de la entrega .....................................................................................................................10
1.5.3. El reto de la confianza .................................................................................................................10
1.6. Que es calidad ...........................................................................................................................................10
1.6.1. Control de calidad .........................................................................................................................12
1.6.2. Garantía de calidad .......................................................................................................................12
1.6.3. Gestión de calidad.........................................................................................................................12
1.7. Problemas de calidad en grandes sistemas...................................................................................13
2. Calidad de software ......................................................................................................................................14
2.1. Corrección y defectos: Definiciones, propiedades y mediciones..........................................14
2.1.1. Definiciones: Error, falla, avería y defecto ............................................................................14
2.1.2. Conceptos y relaciones ilustradas ...........................................................................................16
2.1.3. Propiedades de corrección centrada y mediciones......................................................... 17
2.1.4. Defectos en el contexto de la ingeniería de calidad y control de calidad..............19
2.2. Una perspectiva histórica de Calidad ..............................................................................................20
2.2.1. Evolución de las percepciones de calidad ..........................................................................20
2.2.2. Calidad en ingeniería de software ..........................................................................................21
2.3. ¿Qué es Calidad de Software? ...........................................................................................................22
3. Aseguramiento de calidad de software y técnicas asociadas.....................................................22
3.1. Clasificación: Como tratar defectos..................................................................................................22
3.1.1. Esquema de clasificación ...........................................................................................................22
3.1.2. Representación gráfica del esquema de clasificación ....................................................23
3.2. Prevención de defectos.........................................................................................................................24

3
 3.2.1. Inspección: detección de fallos y la eliminación directa................................................25
3.2.2. Método Formal ..............................................................................................................................25
3.2.3. Otras técnicas e identificación de riesgos ...........................................................................26
3.3. Reducción de defectos ..........................................................................................................................26
3.3.1. Inspección: Detección de fallas indirectas y eliminación...............................................26
3.3.2. Pruebas: observación y culpa eliminación de interrupción ......................................... 27
3.3.3. Otras técnicas e identificación de riesgos ........................................................................... 27
3.4. Contención de defectos........................................................................................................................ 27
3.4.1. Software de tolerancia a fallos.................................................................................................28
3.4.2. Aseguramiento de la seguridad y la falta de contención .............................................28
CONCLUSIONES Y RECOMENDACIONES...................................................................................................30
BIBLIOGRAFÍA ...........................................................................................................................................................31

4
 ÍNDICE DE FIGURAS
Figura 1 - Aseguramiento de la calidad de software ..................................................................................7
Figura 2 - Control, garantía y gestión de calidad ......................................................................................13
Figura 3 - Conceptos y relaciones relacionados con defectos .............................................................15
Figura 4 - Formas genéricas para hacer frente a los defectos ............................................................24

5
 ÍNDICE DE TABLAS
Tabla 1 - Atributos de un buen software ........................................................................................................ 9
Tabla 2 - Cómo lograr que el consumidor se convierta en nuestro cliente ....................................11
Tabla 3 - Tipos de calidad ....................................................................................................................................11
Tabla 4 - Corrección – centrado a propiedades de acuerdo a la calidad de vistas y atributos
........................................................................................................................................................................................18

6
 INTRODUCCIÓN
Actualmente hay una variedad de equipos y sistemas de software que están presentes en la
sociedad moderna. Los usuarios de 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.

Aquella dependencia requiere que el software funcione correctamente durante un tiempo

prolongado, para ser fácil de usar y así sucesivamente.

Y para ello, tales requisitos de alta calidad deben 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.

Por ello en el siguiente trabajo nos enfocaremos en explicar los diferentes conceptos que se
relacionan con la calidad, software, calidad de software y aseguramiento de la calidad (QA).

Figura 1 - Aseguramiento de la calidad de software

7
CALIDAD, SOFTWARE Y ASEGURAMIENTO
DE LA CALIDAD DEL SOFTWARE
1. Calidad y software
1.1. Que es software
Muchas personas asocian el termino software con los programas de
computadora. Sin embargo, una definición más amplia donde el software no
son solo programas, sino todos los documentos asociados y la configuración
de datos que se necesitan para hacer que estos programas operen de manera
correcta.

Los ingenieros de software se concentran en el desarrollo de productos de

software, es decir, software que se vende a un cliente. Existen dos tipos de
productos de software:

 Productos Genéricos: Son sistemas aislados producidos por una

organización de desarrollo y que se venden al mercado abierto a
cualquier cliente que le sea posible comprarlos.
 Productos Personalizados: Son sistemas requeridos por un cliente en
particular. Un contratista de software desarrolla el software especialmente
para ese cliente.

Una diferencia importante entre estos diferentes tipos de software es que, en

los productos genéricos, la organización que desarrolla el software controla
su especificación. La especificación de los productos personalizados, por lo
general, es desarrollada y controlada por la organización que compra el
software. Los desarrolladores de software deben trabajar con esa
especificación.

1.2. Ingeniería de software

La ingeniería de software es una disciplina de la ingeniería que comprende
todos los aspectos de la producción de software desde las etapas iniciales de
la especificación del sistema, hasta el mantenimiento de este después que se
utiliza.

En general, los ingenieros de software adoptan un enfoque sistemático y

organizado en su trabajo, ya que es la forma más efectiva de producir software
de alta calidad. Sin embargo, aunque la ingeniería consiste en seleccionar el
método más apropiado para un conjunto de circunstancias, un enfoque más
informal y creativo de desarrollo podría ser efectivo en algunas circunstancias.

8
 1.3. Que es CASE
CASE (Ingeniería del Software Asistida por Computadora) comprende un
amplio abanico de diferentes tipos de programa que se utilizan para ayudar
a las actividades del proceso del software como el análisis de requerimientos,
el modelado de sistemas, la depuración y las pruebas. En la actualidad, todos
los métodos vienen con tecnología CASE asociada, como los editores para las
anotaciones utilizadas en el método, módulos de análisis que verifican el
modelo del sistema según las reglas del método y generadores de informes
que ayudan a crear la documentación del sistema. Las herramientas CASE
también incluyen un generador de códigos que automáticamente genera
código fuente a partir del modelo del sistema y de algunas guías de procesos
para los ingenieros de software.

1.4. Atributos de un buen software

Los productos de software tienen un cierto número de atributos asociados
que reflejan la calidad de ese software. Estos atributos no están directamente
asociados con lo que el software hace. Más bien, reflejan su comportamiento
durante su ejecución y en la estructura y organización del programa fuente y
en la documentación asociada. Ejemplos de estos atributos (algunas veces
llamados atributos no funcionales) son el tiempo de respuesta del software a
una pregunta del usuario y la compresión del programa fuente.

El conjunto especifico de atributos que se espera de un sistema de software

depende obviamente de su aplicación. Por lo tanto, un sistema bancario debe
ser seguro, un juego interactivo debe tener la capacidad de respuesta, un
interruptor de un sistema telefónico debe ser fiable.

Esto se generaliza en el conjunto de atributos que se muestra en la tabla 1 el

cual tiene la característica esencial de un sistema de software bien diseñado.

El software debe escribirse de tal El software no debe hacer que se

forma que pueda evolucionar para
cumplir las necesidades de cambio
de los clientes.
Mantenibilidad Este es un atributo critico debido a
que el cambio en el software es una
consecuencia inevitable de un
cambio en el entorno de negocios.
La confiabilidad del software tiene
un gran número de características,
incluyendo la fiabilidad, protección y
Confiabilidad seguridad.
El software confiable no debe causar
daños físicos o económicos en el
caso de una falla del sistema.
Tabla 1 - Atributos de un buen software
malgasten los recursos del sistema,
como la memoria y los ciclos de
procesamiento.
Eficiencia Por lo tanto, la eficiencia incluye
tiempos de respuesta y de
procesamiento, utilización de la
memoria entre otros.
El software debe ser fácil de utilizar,
sin esfuerzo adicional, por el usuario
para quien está diseñado.
Usabilidad
Esto significa que debe tener una
interfaz de usuario apropiada y una
documentación adecuada.

9
1.5. ¿Cuáles son los retos fundamentales que afronta la
ingeniería del software?
En el siglo XXI la ingeniería de software afronta tres retos fundamentales:

1.5.1. El reto de la heterogeneidad

Cada vez más, se requiere que los sistemas operen como sistemas
distribuidos en redes que incluyen diferentes tipos de computadoras
y con diferentes clases de sistemas de soporte. A menudo es necesario
integrar software nuevo con sistemas heredados más viejos escritos
en diferentes lenguajes de programación. El reto de la heterogeneidad
es desarrollar técnicas para construir software confiable que sea lo
suficientemente flexible para adecuarse a esta heterogeneidad.

1.5.2. El reto de la entrega

Muchas técnicas tradicionales de ingeniería del software consumen

tiempo. El tiempo que están consumen es para producir un software
de calidad. Sim embargo, los negocios de hoy en día deben tener una
gran capacidad de respuesta y cambiar con mucha rapidez. Su
software de soporte también debe cambiar con la misma rapidez. El
reto de la entrega es reducir los tiempos de entrega para sistemas
grandes y complejos sin comprometer la calidad del sistema.

1.5.3. El reto de la confianza

Puesto que el software tiene relación con todos los aspectos de

nuestra vida, es esencial que podamos confiar en él. Esto es
esencialmente importante en sistemas remotos de software a los que
se accede a través de páginas web o de interfaces de servicios web. El
reto de la confianza es desarrollar técnicas que demuestren que los
usuarios pueden confiar en el software.

Por supuesto, estos no son independientes. Por ejemplo, es necesario hacer

cambios rápidos a los sistemas heredados para proveerlos de una interfaz de
servicio web. Para tratar estos retos, necesitaremos nuevas herramientas y
técnicas, así como formas innovadoras de combinación y uso de métodos de
ingeniería de software existentes.

1.6. Que es calidad

La mayoría de los clientes busca calidad al mejor precio, sin embargo, lo que
puede ser "excelente" para algunos, no lo es para otros. Cuando un individuo
adquiere un producto o servicio, lo hace para satisfacer una necesidad, pero
siempre espera que la "nueva adquisición" funcione como lo esperado, o al
menos como se lo prometieron en el anuncio publicitario.

10
 Muchas veces la calidad se paga, justificando de esta forma el dicho de que
"lo barato sale caro".

La calidad es el conjunto de características del producto que potencialmente

pueden satisfacer las necesidades o deseos del cliente. La posibilidad de que
nuestro producto satisfaga al consumidor, está directamente relacionada con
la calidad.

La calidad es la manera de ser de un producto, bueno o malo, mejor o peor,

en relación con las características que solicita el consumidor. Esto quiere decir,
que el consumidor suele juzgar los productos según la calidad, y que de
acuerdo con su juicio ubicará a nuestro producto delante, detrás o en el
mismo nivel que los productos de la competencia. Así pues, se entiende por
calidad el grado o lugar que ocupan los productos al ser comparados entre
sí, por la medida en que satisfacen necesidades o deseos.

En la tabla 2 explicamos cómo lograr que el consumidor se convierta en

nuestro cliente y en la tabla 3 sobre los tipos de calidad:

LA NECESIDAD EL DESEO

Requiere de factores útiles para: Requiere de factores útiles para:

 
 
La subsistencia Alcanzar un nivel de vida
El bienestar Mantener un nivel de vida
 La felicidad  Disfrutar de la posesión de un
artículo o servicio

Tabla 2 - Cómo lograr que el consumidor se convierta en nuestro cliente

Calidad que se espera Calidad que satisface Calidad que deleita

Se da cuando existen Se da cuando existen Se da cuando existen

propiedades y características que propiedades y características que propiedades y características que
los consumidores dan por los consumidores solicitan los consumidores no solicitan
sentado que encontrarán en los específicamente. porque no saben que puedan
productos o servicios. Cuando están presentes estas existir, pero que cuando están
Cuando encuentran estas propiedades y características, los presentes y agradan, los
propiedades y características, los consumidores quedan consumidores quedan muy
consumidores quedan satisfechos, pero cuando no está satisfechos; sin embargo, si no las
satisfechos, pero cuando no las presentes, quedan insatisfechos. encuentran, no quedan
encuentran, quedan muy La calidad que satisface cumple insatisfechos.
insatisfechos. con las expectativas del La calidad que deleita supera las
consumidor, pero sin llegar a expectativas del consumidor.
superarlas.

Tabla 3 - Tipos de calidad

11
1.6.1. Control de calidad

Es el conjunto de los mecanismos, acciones y herramientas realizadas

para detectar la presencia de errores.

La función principal del control de calidad es asegurar que los

productos o servicios cumplan con los requisitos mínimos de calidad.
Existe primordialmente como una organización de servicio, para
conocer las especificaciones establecidas por la ingeniería
del producto y proporcionar asistencia al departamento de
fabricación, para que la producción alcance estas especificaciones.
Como tal, la función consiste en la recolección y análisis de grandes
cantidades de datos que después se presentan a diferentes
departamentos para iniciar una acción correctiva adecuada.

Todo producto que no cumpla las características mínimas para decir

que es correcto, será eliminado, sin poderse corregir los posibles
defectos de fabricación que podrían evitar esos costos añadidos y
desperdicios de material.

Para controlar la calidad de un producto se realizan inspecciones o

pruebas de muestreo para verificar que las características del mismo
sean óptimas.

1.6.2. Garantía de calidad

La garantía de calidad es un proceso sistemático para cubrir la brecha

entre el desempeño real y los resultados esperados.

También implica que los sistemas que brindan el servicio o producto

están comprometidos a realizar las cosas bien y sostener los logros,
pero también son conscientes de que en algún momento puede que
no se cumplan algunas de las necesidades. Por lo cual tienen un valor
agregado a tales servicios o productos, que garantiza que ante
cualquier inconveniente vamos a estar comprometidos con resolver
dicho problema.

Y para ello tienen planificado un conjunto de actividades que se llevan

a cabo para fijar normas, vigilar y mejorar el desempeño de tal manera
que la atención prestada sea lo más eficaz y segura posible.

1.6.3. Gestión de calidad

Es una estrategia operacional de trabajo, bien documentada e

integrada a los procedimientos técnicos y gerenciales, para guiar las
acciones de la fuerza de trabajo, la maquinaria o equipos, la

12
 información de la organización de manera práctica y coordinada que
asegure la satisfacción del cliente y bajos costos para la calidad.

La gestión de calidad se centra no solo en la calidad de un producto,

servicio o la satisfacción de sus clientes, sino en los medios para
obtenerla. Por lo tanto, la gestión de calidad utiliza la garantía de
calidad y el control de los procesos para obtener una calidad más
consistente.

Figura 2 - Control, garantía y gestión de calidad

1.7. 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. 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.
Según (Wirth, 1995), "Software Graso" puede deberse indiscriminadamente a
agregar características no esenciales, mal diseño, inadecuadas opciones de
idiomas y metodologías, que podrían resolverse con técnicas de control de
calidad, metodologías disciplinadas y volver a lo esencial produciendo
“Software Ágil" y de alta calidad.

Todo esto no solo afecta a la empresa encargada de realizar el sistema, sino

que también a los clientes y usuarios. Y tratar de administrar y mejorar la
calidad del software es una tarea para las personas involucradas en el
desarrollo, administración, soporte de marketing y operacional de los más
modernos sistemas de software.

13
2. Calidad de software
2.1. Corrección y defectos: Definiciones, propiedades y
mediciones.
Cuando muchas personas asocian calidad o alta calidad con un sistema de
software, es un indicativo, que pocos problemas de software se esperan
durante sus operaciones. Es más, cuando surgen problemas, el impacto
negativo se espera que sea mínimo. En esta sección se examinan cuestiones
relacionadas.

2.1.1. Definiciones: Error, falla, avería y defecto

Clave para el aspecto de la corrección de la calidad del software es el

concepto de defecto, avería, fallo y error.

El término "defecto" generalmente se refiere a algún problema con el

software, con su comportamiento externo o con sus características
internas. El estándar IEEE 610.12 (IEEE, 1990) define los siguientes
términos relacionados con defectos:

 Avería (Failure): La incapacidad de un sistema o componente

para realizar sus funciones necesarias con requerimientos
específicos.
 Fallo (Fault): Un paso, proceso o datos incorrecto en un
programa de ordenador.
 Error (Error): Una acción humana que produce un resultado
incorrecto.

Por lo tanto, el término avería se refiere a una desviación del

comportamiento de la exigencia del usuario o en el pliego de
condiciones; fallo se refiere a una condición subyacente en un software
que hace que alguna avería(s) ocurra; mientras que el error se refiere
a una falta o incorrecta acción humana resultante en cierto fallo(s) que
se había inyectado en un software.

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

de las acciones faltantes o incorrectas, como errores humanos,
malentendidos, etc. Averías, 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 defectos.

Problemas o defectos de software, son también conocido como

"bugs". Sin embargo, el término “bug” nunca es precisamente
definido, como los diferentes aspectos de los defectos definidos como

14
 errores, fallos y averías anteriores. Algunas personas también han
planteado la objeción moral o filosófica al uso de bug como evadir la
responsabilidad de algo las personas comprometidas. Por lo tanto,
intentamos evitar usar el término "bug" en el presente documento.

Del mismo modo, también intentamos evitar los términos relacionados

"Debug" o "Debugging" por razones similares. El término "Debug"
generalmente significa "Deshacerse de los errores (Bugs)". A veces,
también incluye actividades relacionadas con la detección de la
presencia de bugs y hacerles frente. En esta ocasión, utilizaremos, en
su lugar, los siguientes términos:

Figura 3 - Conceptos y relaciones relacionados con defectos

 Utilizamos detección de defecto y eliminación para el concepto

global y las actividades relacionadas con lo que muchas personas
comúnmente llaman "Debugging".
 Cuando se trate de actividades específicas relacionadas con
"Debugging", señalamos las especificaciones usando términos
más precisos, incluyendo:

15
  Actividades específicas relacionadas 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 re verificación.

2.1.2. Conceptos y relaciones ilustradas

Los conceptos de error (Incluyendo la fuente del error), fallas, averías

y defecto pueden colocarse en el contexto de artefacto de software,
actividades de desarrollo de software y uso operacional, como se
muestra en la figura 3 Alguna información específica ilustrada incluye:

 El sistema de software representada por sus artefactos se muestra

en el cuadro central. Los artefactos incluyen sobre todo código
de software y algunas veces otros artefactos como diseños,
especificaciones, documentos de requisitos, etc. Las fallas
dispersas entre estos artefactos se representan como entidades
en un círculo en el cuadro central.
 La entrada a las actividades de desarrollo del software,
representadas en el cuadro de la izquierda, incluyen modelos
conceptuales e información, los desarrolladores con ciertos
conocimientos y experiencia, 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 acciones humanas incorrectas o faltantes
directamente no aparecen dentro de un cuadro, sino como
acciones hacia la inyección de fallas 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 pueden clasificarse como averías cuando se desvían
del comportamiento esperado y se muestra como la colección de
instancias de averías en un círculo.

Con las anteriores definiciones e interpretaciones, podemos ver que

averías, fallas y errores son aspectos diferentes de defectos. Existe una
relación causal entre estos tres aspectos de defectos:

errores  fallas  averías

16
 Es decir, errores pueden causar fallas inyectadas en el software, y
fallas pueden causar averías cuando se ejecuta el software. Sin
embargo, esta relación no es necesariamente 1 a 1. Un solo error
puede causar muchas fallas, como en el caso de que un mal algoritmo
se aplica en varios módulos y provoca fallos múltiples, y un fallo único
puede causar muchas averías en repetidas ejecuciones. Por el
contrario, la misma avería puede ser causado por varias fallas, como
una avería de interfaz o interacción con la participación de varios
módulos, y el mismo fallo puede existir debido a errores diferentes.
Figura 3 también ilustra algunas de estas situaciones, como se
describe a continuación:

 La fuente de error e3 provoca múltiples fallas, f2 and f3.

 La falla f1 es causada por múltiples fuentes de error, e1 y e2.
 A veces, una fuente de error, tales como e5, no puede causar
cualquier inyección de fallas, y un fallo, tal como f4, no puede
causar alguna avería, bajo los escenarios determinados o
circunstancias. Dichos fallos se denominan normalmente fallas
dominantes o latentes, que todavía pueden causar problemas en
un conjunto diferente de situaciones o circunstancias.

2.1.3. Propiedades de corrección centrada y mediciones

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 vs. vistas internas para los
consumidores) y atributos (Corrección vs otros) en la tabla 4.

La calidad de la corrección centrada desde el punto de vista externo,

o desde la vista de los consumidores (usuarios y clientes) de un
producto de software o servicio, puede ser definido y medido por
diversas propiedades relacionadas con la avería y la medición. Para un
usuario o un cliente, la principal preocupación es que el software
funcione sin avería, o con menos averías como sea posible.

Cuando se producen tales averías o eventos indeseables, el impacto

debe ser lo menos posible. Estas preocupaciones pueden ser
capturadas por diversas propiedades y relacionados con las
mediciones, como se menciona a continuación:

 Propiedades de avería y medición de averías directa:

propiedades de averías incluyen información sobre las averías
específicas, lo que son, cómo se producen, etc. Estas propiedades
pueden medirse directamente mediante el examen de recuento
de averías, distribución, densidad, etc.

17
 Atributo
Vista
Corrección Otros
Usabilidad
Mantenibilidad
Consumidor/
Portabilidad
Externo (Usuario y Avería (Failure) –
Rendimiento
consumidor) propiedades relacionadas
Capacidad de instalación
Legibilidad
Etc.
Productor / Diseño
Interno
Tamaño
(Desarrollador, Fallo (Fault) –
Cambio
administrador, propiedades relacionadas
jefe, testeador, Complejidad
etc) Etc.

Tabla 4 - Corrección – centrado a propiedades de acuerdo a la calidad de vistas y atributos

 Avería de medición de probabilidad y fiabilidad: Con qué

frecuencia o qué tan probable es una avería va a ocurrir es de
interés fundamental para los usuarios de software y clientes. Esta
probabilidad es capturada en varias medidas de confiabilidad,
donde fiabilidad puede definirse como la probabilidad de
operaciones libres de avería para un período de tiempo específico
o para un determinado conjunto de entrada (Musa et al., 1987;
LYU, 1995; Tian, 1998).
 Averías en la medición de gravedad y de la seguridad: el
impacto de la avería 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 averías podría ser
sustancial. Accidentes, que se define como averías con graves
consecuencias, necesitan ser evitado, contenido o tratados para
garantizar la seguridad para el personal involucrado y minimizar
otros daños.

En contraste con la perspectiva de calidad por encima de los

consumidores, los productores de sistemas de software ven la calidad
desde una perspectiva diferente en su interacción con los sistemas de
software y problemas conexos. Necesitan solucionar los problemas o
fallas que causó las averías, así como hacer frente a la inyección y la
activación de otras fallas que podría causar otras averías que aún no
se han observado.

Similares a las propiedades de averías y las medidas conexas

mencionadas, tenemos que examinar diversas propiedades de fallas y

18
 medidas relacionadas de la vista interna de los productores. Podemos
recopilar y analizar información sobre fallas individuales, así como
hacerlo colectivamente. Fallas individuales pueden ser analizadas y
examinadas de acuerdo a sus tipos, sus relaciones a averías específicas
y accidentes, sus causas, el tiempo y circunstancias cuando que se
inyectan, etc. Fallos pueden ser analizadas colectivamente según su
distribución y densidad en fases de desarrollo y componentes de
software diferentes.

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

calidad

Para la mayoría de organizaciones de desarrollo de software,

garantizar la calidad significa tratar de defectos. Tres maneras
genéricas para lidiar con defectos incluyen:

 Prevención de defecto
 Detección y eliminación de defectos
 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.

Por extensión, la ingeniería de calidad puede verse también como

defecto de gestión. Además de la ejecución de las actividades
planificadas de control de calidad, ingeniería de calidad también
incluye:

 Planificación de la calidad antes de las actividades de control de

calidad específicos se llevan a cabo.
 Medición, análisis y comentarios para supervisar y controlar las
actividades de control de calidad.

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

2.2. Una perspectiva histórica de Calidad

A continuación, examinamos opiniones y percepciones de personas, 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.

2.2.1. Evolución de las percepciones de calidad

Antes de software y tecnología de información (IT) las industrias

entraron en existencia, la calidad ha sido asociado con objetos o
sistemas físicos, tales como automóviles, herramientas, receptores de
radio y televisión, etc. En este entorno tradicional, control de calidad
(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 las pueden
comprobar como 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 utilizada "Calidad inicial" para
automóviles por el grupo industrial J.D. Power and Associates (En línea
en www. jdpa.com) 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 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

20
 calidad pasando cero defectos en productos a cero deserciones de
clientes (Reichheld Jr. y Sasser 1990). 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
descritos hasta ahora. Hay muchas razones de su postura cambiante
de la calidad y los diferentes enfoques de control de calidad (Beizer,
1998). Por ejemplo, los supuestos fundamentales de las limitaciones
físicas, continuidad, cuantificabilidad, composición, etc., no pueden
ampliar o asignar al mundo del software flexible. Por lo tanto, las
diferentes técnicas de control de calidad que se traten en el
documento deben ser utilizados.

2.2.2. Calidad en ingeniería de software

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

muchos 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 diversa importancia para diferentes periodos de tiempo
y distintos segmentos del mercado.

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

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

 Etapa funcional: El foco fue proporcionar las funciones

automatizadas para reemplazar lo que se había realizado antes
manualmente.
 Etapa de planificación: La atención se centró en la introducción
de características importantes y nuevos sistemas de manera
oportuna y ordenada para satisfacer las necesidades urgentes
del usuario.
 Etapa de costo: El foco fue la reducción de los precios para
mantenerse competitivo acompañado por el uso generalizado de
las computadoras personales.

21
  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 averías 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 para control de calidad (QA) de modernos sistemas de
software.

2.3. ¿Qué es Calidad de Software?

Concluyendo este capítulo, responderemos la pregunta a continuación:

 Calidad de software puede incluir muchos atributos diferentes y puede

ser definidas y percibidas de manera diferente basado en diferentes roles
y responsabilidades de las personas.
 Adoptamos en este libro el punto de vista correcto y centrado de la
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.

3. Aseguramiento de calidad de software y técnicas

asociadas
En este capítulo, hablaremos sobre las alternativas existentes de control de calidad y técnicas
relacionadas examinando las formas específicas que se emplean para hacer frente a defectos.

3.1. Clasificación: Como tratar defectos

Las actividades de prevención de defecto pueden utilizarse para la mayoría
de los sistemas de software para reducir la posibilidad de inyecciones por
defecto y el posterior costo para hacer frente a éstas. La mayoría de las
actividades de prevención de defectos asume que hay fuentes de error
conocida o acciones incorrectas que resultan en inyecciones de fallo.

3.1.1. Esquema de clasificación

Podemos ver las diferentes actividades de QA como un intento de

prevenir, eliminar, reducir o contener diversos problemas específicos
asociados a los diferentes aspectos de defectos. Podemos clasificar
estas alternativas de control de calidad en las siguientes tres categorías
genéricas:

22
  La prevención de defectos a través del bloqueo de error o
remoción fuente de error: Estas actividades de QA previene
ciertos tipos de fallos de ser inyectado en el software. Se puede
hacer de dos formas genéricas:
 La eliminación de ciertas fuentes de error, tales como la
eliminación de ambigüedades o corregir los conceptos
erróneos humanos, que son las causas fundamentales de los
errores.
 La prevención de fallos o el bloqueo mediante la corrección
directa o bloqueo de las acciones humanas incorrectas.
 La reducción de defectos a través de la detección de fallos y la
eliminación: Estas alternativas de control de calidad detectan y
eliminan ciertos fallos una vez que se han inyectado en los
sistemas de software. De hecho, la mayoría de las actividades de
control de calidad tradicionales entran en esta categoría. Por
ejemplo:
 Inspección, detecta directamente y elimina los fallos desde el
código de software, diseño, etc.
 Pruebas, elimina los fallos basados en observaciones
relacionadas durante la ejecución del programa.
 Contención de defecto a través de la prevención de fallos y
contención: Estas medidas de contención se centran en los
fracasos, ya sea que los contiene a las áreas locales de modo que
no hay fracasos globales observable a los usuarios, o limitar los
daños causados por fallas en el sistema de software. Por lo tanto,
la contención de defecto se puede hacer de dos formas
genéricas:
 Algunas alternativas de control de calidad, tales como el uso
de técnicas de tolerancia a fallos, rompen la relación causal
entre fallos y los errores de modo que los fallos locales no
provocarán fallos globales.
 Una extensión relacionada con la tolerancia a fallos es
medidas de contención para evitar consecuencias
catastróficas, como la muerte, lesiones personales y
materiales graves o daños ambientales, en caso de fallos.

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

La clasificación de la actividad de control de calidad anteriormente se

puede ilustrar en la figura 4, la formación de una serie de barreras
representados por líneas de trazos punteados. Cada barrera elimina o
bloquea fuentes de defecto, o previene consecuencias indeseables.

23
  La barrera entre la entrada a las 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 barrera curva entre el sistema de software (cuadro central) y el
escenario de uso y el comportamiento observado (cuadro de la
derecha) representa defectos o fallos de eliminación de
actividades tales como la inspección y pruebas.
 La barrera directamente a la derecha y cerca de la barrera por
encima de la eliminación de fallos representa las actividades de
prevención de fallos tales como la tolerancia a fallos.
 La última barrera, que rodea los casos de fracaso seleccionados,
representa las actividades de contención de fallo.

Figura 4 - Formas genéricas para hacer frente a los defectos

3.2. Prevención de defectos

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 incorrectas que resultan por culpa de
las inyecciones, como las siguientes:

24
 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.

3.2.1. Inspección: detección de fallos y la eliminación directa

El factor humano es el factor más importante que determina la calidad

y a la vez, el éxito o el fracaso de la mayoría de los proyectos de
software. La educación y formación de profesionales de software
pueden ayudarle a controlar, administrar y mejorar la forma de
trabajar. Estas actividades también pueden ayudar a garantizar que
tienen pocos o ningún error relacionados con el producto y su
desarrollo. Debe estar enfocadas en las siguientes áreas:

 Conocimiento específico del producto y dominio.

 Conocimiento y experiencia de desarrollo de software.
 Conocimientos sobre metodología, tecnología y herramientas de
desarrollo.
 Conocimiento del proceso de desarrollo.

3.2.2. Método formal

Proporciona una forma para eliminar ciertas fuentes de error y para

comprobar la ausencia de fallos relacionados, incluyen la
especificación formal y verificación formal.

 La especificación formal se ocupa de producir un conjunto claro

de especificaciones del producto para que los requerimientos del
cliente se reflejan correctamente, lo que reduce las posibilidades
de las inyecciones de errores accidentales.
 La 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 respecto a
sus especificaciones formales.

25
 El mayor obstáculo para métodos formales es el alto costo asociado
con la tarea de llevar a cabo estas actividades correctamente sin
suficiente apoyo automatizado.

3.2.3. Otras técnicas e identificación de riesgos

 El uso del principio de ocultación de información (Parnas , 1972)

puede ayudar a reducir la complejidad de las interfaces de
programa y de las interacciones entre los diferentes componentes
, lo que reduce la posibilidad de problemas relacionados.
 Un proceso mejor administrado puede eliminar muchos
problemas sistemáticos.
 A veces, las herramientas de software específicas también pueden
ayudar a reducir las posibilidades de que las inyecciones de falla.

3.3. Reducción de defectos

Es poco realista esperar que las actividades de prevención de defecto sean
100% eficaces en la prevención de las inyecciones de errores accidentales. Por
lo tanto, necesitamos técnicas eficaces para eliminar la mayor cantidad de
defectos inyectados como sea posible en virtud de las restricciones del
proyecto.

3.3.1. Inspección: Detección de fallas indirectas y eliminación

Las inspecciones de software son exámenes críticos de artefactos de

software por parte de inspectores humanos, el objetivo de descubrir y
corregir los fallos en los sistemas de software. La inspección es una
bien conocida alternativa familiar de QA para la mayoría de los
profesionales con experiencia de calidad de software. Las básicas ideas
de la inspección se describen a continuación:

 Las inspecciones son la lectura y análisis de código de software.

 Las inspecciones se realizan normalmente por varios inspectores
humanos, a través de algunos procesos de coordinación.
 Los fallos se detectan directamente en la inspección por
inspectores humanos, ya sea durante sus inspecciones
individuales o varios tipos de sesiones de grupo.
 Los fallos identificados deben ser eliminados como resultado del
proceso de inspección, y su eliminación también necesita ser
verificada.
 Los procesos de inspección varían, pero suelen incluir un poco de
planificación y seguimiento actividades.
 La formalidad y la estructura de las inspecciones pueden variar.

26
 La inspección se aplica más comúnmente a código, pero también se
podría aplicar a las especificaciones de requerimiento, diseños, planes
y casos de prueba, manuales de usuario y otros documentos o
artefactos de software. Por lo tanto, la inspección se puede utilizar
durante todo el proceso de desarrollo, especialmente al comienzo del
desarrollo de software antes de que algo se puede probar.

3.3.2. Pruebas: observación y culpa eliminación de interrupción

El testing es una de las partes más importantes de QA y es realizado

con la mayor frecuencia. Las pruebas consisten en la ejecución de
software y la observación del comportamiento o resultado del
programa. Si se observa un fallo, el registro de ejecución se analiza y
se localiza el fallo que causó el error para corregirlo.

3.3.3. Otras técnicas e identificación de riesgos

La inspección es una de las técnicas estáticas más usadas para la

detección de defectos y remoción. Varias otras técnicas estáticas están
disponibles, incluyendo el análisis de algoritmos, análisis de tabla de
decisiones, análisis de valores límite, de estados finitos máquina, etc.

Del mismo modo, además de las pruebas, otras dinámicas, basadas

en técnicas de ejecución, también existen para detección de fallos y la
eliminación. Por ejemplo, la ejecución simbólica, la simulación y
prototipado puede ayudarnos a detectar y eliminar varios defectos
temprano en el proceso de desarrollo de software, antes de la prueba
a gran escala se convierte en una alternativa viable.

Por otro lado, en el campo de la medición y análisis relacionados, tales

como la sincronización y la persona análisis de rendimiento para
sistemas de tiempo real y análisis de accidentes y reconstrucción
utilizando árboles de fallos de software y árboles de eventos para los
sistemas críticos para la seguridad, también puede ayudar a localizar
y eliminar los defectos relacionados.

3.4. Contención de defectos

Debido al gran tamaño y alta complejidad de la mayoría de los sistemas de
software en uso hoy en día, las actividades de reducción por encima de
defectos sólo pueden reducir el número de faltas a un nivel bastante bajo,
pero no los elimina completamente. Para sistemas de software donde el
impacto de fracaso es sustancial, este riesgo de defecto bajo nivel y el fracaso
puede ser insuficiente. Se necesitan algunas alternativas adicionales de control
de calidad.

27
Por otra parte, estos pocos fallos restantes pueden ser provocados en
condiciones raras o escenarios dinámicos inusuales, por lo que es realista
tratar de generar el número enorme de casos de prueba para cubrir todas
estas condiciones o para realizar una inspección exhaustiva sobre la base de
todos los escenarios posibles. En lugar de ello, algunos otros medios necesitan
ser usados para prevenir las fallas por romper las relaciones causales entre
estos defectos y las fallas resultantes para contener los fallos mediante la
reducción de los daños resultantes.

3.4.1. Software de tolerancia a fallos

Las ideas de tolerancia a fallos de software se originan a partir de

diseños de tolerancia a fallos en los sistemas tradicionales de hardware
que requieren niveles más altos de fiabilidad, disponibilidad o
fiabilidad. En tales sistemas, repuestos 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 unidad o parte de los fracasos. Las técnicas de tolerancia
a fallos de software incluyen bloques de recuperación primaria,
programación N-versión (NVP), y sus variaciones (Lyu, 1995b).

 Los bloques de recuperación utilizan las ejecuciones repetidas (o

redundancia con el tiempo) como el mecanismo básico para la
tolerancia a fallos. Si se detectan fallos dinámicos en algunas áreas
locales, una parte de la última ejecución se repite, con la
esperanza de que esta ejecución repetida no dará lugar a la
misma falla. Por lo tanto, los fallos locales no se propagarán a los
fallos globales.
 NVP utiliza redundancia en paralelo, donde N copias, cada una
de una versión diferente, de los programas que cumplen las
mismas funciones se ejecutan en paralelo. El algoritmo de
decisión de NVP se asegura de que los fallos locales en número
limitado de estas versiones paralelas no van a comprometer los
resultados globales de ejecución.

Un hecho a destacar es que, en la mayoría de las técnicas de tolerancia

a fallos, averías no se identifican típicamente, por lo tanto, no se
eliminan.

3.4.2. Aseguramiento de la seguridad y la falta de contención

Para los sistemas críticos de seguridad, la principal preocupación es

nuestra capacidad para prevenir la ocurrencia de accidentes, donde
un accidente es un fracaso con una consecuencia grave. Incluso las
bajas probabilidades de fallo de software no son tolerables en tales
sistemas si estos fallos probablemente aún pueden provocar

28
accidentes. Por lo tanto, además de las técnicas de control de calidad
superiores, diversas técnicas específicas también se utilizan para los
sistemas críticos de seguridad basados en el análisis de los riesgos, o
pre-condiciones lógicas de accidentes (Leveson, 1995). Estas técnicas
de garantía de la seguridad y de mejora son:

 Eliminación del peligro a través de la sustitución, la simplificación,

el desacoplamiento, la eliminación de errores humanos
específicos, y la reducción de materiales o condiciones peligrosas.
 La reducción del peligro a través del diseño para la capacidad de
control (por ejemplo, la liberación automática de la presión en las
calderas), el uso de dispositivos de seguridad y el fracaso de
minimización por los márgenes de seguridad y redundancia.
 El control de peligros a través de la reducción de la exposición, el
aislamiento y contención (por ejemplo, las barreras entre el
sistema y el medio ambiente), los sistemas de protección y un
diseño a prueba de fallos.
 El control de daños a través de las vías de evacuación, el
abandono seguro de los productos y materiales, y los dispositivos
de limitación de daños físicos a los equipos o personas. Estas
técnicas reducen la gravedad de los accidentes, lo que limita el
daño causado por estos accidentes y fallos de software
relacionados.

29
 CONCLUSIONES Y RECOMENDACIONES
En conclusión, la calidad es muy importante en cualquier servicio o producto y está presente
en muchos lados y sobretodo en el software que utilizamos y hacemos.

Un producto como software será de calidad cuando siga los estándares propuestos por
organizaciones dedicadas a la calidad de software, de tal forma que pueda cumplir con todos
los requerimientos especificados por el cliente.

Dentro de la calidad de software debemos entender los conceptos claves de (Error, Fallo y
Avería), ya que con ellos nos aseguraremos de donde proviene dicho error, también incluye
etapas:

 Etapa funcional
 Etapa de planificación
 Etapa de costo
 Etapa de fiabilidad

Producir un software con un gran éxito, es hacerlo con calidad y sobretodo demostrarlo. Esto
sólo es posible con la implantación de un sistema para el Aseguramiento de la Calidad
del Software (SQA). Por lo cual el SQA es el esfuerzo total para plantear, organizar, dirigir y
controlar la calidad en un sistema de producción con el objetivo de dar al cliente productos
con la calidad adecuada.

Recomendamos no solo a las empresas, sino a todos los desarrolladores que empiecen a
introducirse con el control de software y aseguramiento de la calidad de software. Ya que
ayuda a tomar decisiones en el ámbito de gestión, mejorando el tema de coordinación y
productividad.

También nos da un enfoque en los objetivos de la lógica de negocios y las expectativas de

sus clientes, confianza en que la calidad que se busca se está logrando y evidencia a los
clientes y clientes potenciales de las capacidades de la organización.

30
 BIBLIOGRAFÍA
Biblioteca Virtual. (2014). Obtenido de Biblioteca Virtual:
http://www.bvs.sld.cu/revistas/aci/vol3_3_95/aci05395.htm

Crespo, G. O. (13 de Mayo de 2011). Gestiopolis. Obtenido de Gestiopolis:

http://www.gestiopolis.com/una-definicion-de-calidad/

Debitoor. (2014). Debitoor. Obtenido de Debitoor: https://debitoor.es/glosario/definicion-

control-calidad

DM, T. (2008). Slideshare. Obtenido de Slideshare: http://es.slideshare.net/Tonymx/control-

de-calidad-del-software

Experto, G. (13 de Abril de 2001). Gestiopolis. Obtenido de Gestiopolis:

http://www.gestiopolis.com/que-son-calidad-aseguramiento-de-la-calidad-y-
control-de-calidad/

Sommerville, I. (2005). Ingeniería del Software. Madrid: Pearson.

Tian, J. (2005). Software Quality Engineering. IEEE.

UPV. (2011). Aproximación al concepto de calidad. Obtenido de

https://www.youtube.com/watch?v=796tam6_cP8

31