FACULTAD DE INGENIERA, ARQUITECTURA Y

URBANISMO
ESCUELA PROFESIONAL DE INGENIERA DE
SISTEMAS
Asignatura

Ingeniera de Software I

Administracin de la Calidad del Software

AUTORES:
-

Cantos Morante Augusto Enrique.

Chinguel Rodrguez Milagros Maribel.
Otero Arrascue Danny Frank.
Santisteban Ayasta Leonardo Euler.
Zea Zea Edinson Omar.

Pimentel Per 2016

1

PRESENTACION
Hoy en da donde el mundo es ms globalizado, donde todo lo que se realiza
es cada vez ms automatizado, donde el recurso ms valioso es el tiempo se
necesita estar a la vanguardia de la tecnologa y estar a nivel de la
competencia para poder subsistir en el mercado y aspirar hacer lderes del
mismo.
Los Autores de dicho trabajo buscan facilitar y agilizar las tareas con este
sistema en un negocio como es su administracin de la Calidad del Software.

INDICE:
PRESENTACION........................................................................................... 2
INDICE:........................................................................................................ 3
I.- ADMINISTRACION DE LA CALIDAD DEL SOFTWARE.....................................4
Objetivos:.................................................................................................... 4
1.1.-CALIDAD DE SOFTWARE.......................................................................5
1.2.-LAS REVISIONES DEL SOFTWARE.........................................................5
1.2.1.-Revisiones Tcnicas Formales..........................................................6
1.2.1.1.-Quienes participan en la reunin?.............................................7
1.2.1.2.-Registro e informe de la revisin.................................................7
1.2.1.4.-Directrices para la revisin..........................................................8
1.3.-ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE...............................9
1.3.1.-Surgimiento de SQA (Software Quality Assurance)................................9
1.3.2.-SQA no es lo mismo que SQC (Software Quality Control)....................10
1.3.3.-Funciones generales del SQA.........................................................11
1.3.4.-Consideraciones............................................................................ 12
1.4.-PLANIFICACIN DE LA CALIDAD DE SOFTWARE..................................13
1.4.1.-A Nivel De Las Normas ISO.............................................................13
1.4.2.-A Nivel De Gestin De Calidad.........................................................14
1.5.-CONTROL DE CALIDAD........................................................................14
1.6.-NORMAS DE CALIDAD.........................................................................15
1.6.1.-Estndares ISO 9000.......................................................................16
CONCLUSIONES:....................................................................................... 17
LINKOGRAFA............................................................................................ 18

I.- ADMINISTRACION DE LA CALIDAD DEL SOFTWARE

Objetivos:
*Introducir los conceptos esenciales del manejo de calidad y los estndares
ISO 9000.

*Discutir los procesos del manejo de calidad.

*Explicar como los estndares pueden ser usados en el proceso de manejo de

calidad.

1.1.-CALIDAD DE SOFTWARE

La calidad del software es el conjunto de cualidades que lo caracterizan y que

determinan su utilidad y existencia. Es medible y varia de un sistema o programa a
otro. Un software hecho para ejecutarse una sola vez no requiere el mismo nivel de
calidad mientras que un software para ser explotado durante un largo necesita ser
confiable, mantenible y flexible para disminuir los costos.
La calidad del software puede medirse despus de elaborado el producto. Pero esto
puede resultar muy costoso si se detectan problemas deriva dos de imperfecciones en
el diseo, por lo que es imprescindible tener en cuenta tanto la obtencin de la calidad
como su control durante todas etapas del ciclo de vida del software.
Callaos y Callaos (1996) proponen un concepto de calidad del software en el cual
estn involucrados tanto caractersticas internas como el contexto organizacional, lo
que genera un enfoque sistmico del concepto de Calidad del Software.

1.2.-LAS REVISIONES DEL SOFTWARE

Las revisiones del software, son el conjunto de actividades que suceden como
resultado del anlisis, el diseo y la codificacin y que sirven para depurar las
actividades de ingeniera del software.
Una revisin, tiene como objetivos:
1. Sealar la necesidad de mejoras en el producto
2. Continuar las partes de un producto en las que no es necesaria o no es
deseable una mejora
3. Conseguir un trabajo tcnico de una calidad ms uniforme, o al menos ms
predecible, que la que puede ser conseguida sin revisiones, con el fin de hacer
ms manejable el trabajo tcnico.
Las revisiones de software se usan como modelo para la amplificacin de defectos y
para ilustrar la generacin y deteccin de errores durante los pasos de diseo
preliminar, diseo detallado y codificacin del proceso de ingeniera del software.

En cada paso del proceso de desarrollo de software, se presentan errores que

pasan inadvertidos y que producen un mayor nmero de errores si las
revisiones no lo detectan.
Los errores amplificados corresponden, a aquellos errores que pasan
inadvertidos desde pasos anteriores. De igual forma se representa el porcentaje
de eficiencia de la deteccin de errores.
Las revisiones software pueden ser:
a) Informales
No hay procedimientos definidos, por lo que la revisin se realiza de
la forma ms flexible posible.
Ventajas menor coste y esfuerzo, preparacin corta, etc.
Desventajas Detectan menos defectos
b) Semi -formales
Se definen unos procedimientos mnimos a seguir (walkthroughs)
b) Formales (Inspecciones)
Se define completamente el proceso
Revisin en detalle, por una persona o grupo distintos del autor, para:
Verificar si el producto se ajusta a sus Verificar si el producto
se ajusta a sus especificaciones o atributos de atributos de
calidad y a los estndares utilizados en la empresa
Sealar las desviaciones sobre los estndares y las
especificaciones

Recopilar datos que realimenten inspecciones posteriores

(defectos recogidos, esfuerzo empleado, etc.).

1.2.1.-Revisiones Tcnicas Formales

Una revisin tcnica formal (RTF) es un medio efectivo para mejorar la calidad
del software.
Los objetivos de la RTF son:
1. Descubrir errores en la funcin, la lgica o la implementacin de
cualquier representacin del software
2. Verificar que el software bajo revisin alcanza sus requisitos
3. Garantizar que el software ha sido representado de acuerdo con ciertos
estndares predefinidos
4. Conseguir un software desarrollado de forma uniforme
5. Hacer que los proyectos sean manejables
La RTF incluye:
Recorridos
Inspecciones
Revisiones cclicas
Evaluaciones tcnicas del software
Cada RTF debe estar debidamente planificada, controlada y atendida por el
grupo encargado de cada RTF.
Cada reunin debe tener las siguientes caractersticas:

Deben convocarse para la revisin entre tres y cinco personas

Se debe preparar por adelantado,

La duracin de la reunin de revisin, debe ser menor de dos horas

1.2.1.1.- Quienes participan en la reunin?

o

El jefe de revisin: quien lidera la reunin.

Los revisores: uno de los cuales se encarga de registrar todos los

sucesos de la reunin.

El

productor.

1.2.1.2.-Registro e informe de la revisin

Como se mencion anteriormente, uno de los revisores es el encargado de
registrar todos los acontecimientos y conclusiones que van surgiendo
durante la RTF.
Al final de la reunin, hace un resumen de las conclusiones y genera una lista
de sucesos de revisin. Adems, prepara un informe sumario de la revisin
tcnica formal que responda a las siguientes preguntas:
Que fue revisado?
Quin lo revis?
Qu se descubri y cules son las conclusiones?
La lista de sucesos de revisin que se genera permite:

Identificar reas problemticas dentro del producto

Servir como lista de comprobacin para hacer las correcciones.

Adems, se adjunta, la lista de conclusiones al informe sumario.

1.2.1.4.-Directrices para la revisin

1. Revisar el producto, no al Se deben sealar los errores de forma constructiva y no

productor
dificultar el proceso de revisin. Es importante mantener el
control de la reunin y descartar situaciones que se
escapen de control.

2. Fijar una
mantenerla

agenda

y Se debe tener un plan de trabajo antes de la reunin. Se

debe seguir el orden del plan para que la reunin tenga
8

xito y cumplir con los tiempos asignados al plan.

3. Limitar el debate y las

impugnaciones

No se debe perder tiempo debatiendo situaciones que no

presenten unanimidad, es importante registrar el hecho y
dedicar otros tiempos para su debate.

4. Enunciar reas problemas, La resolucin de problemas se debe programar para otros

pero no intentar resolver los espacios despus de la reunin de revisin.
problemas que se pongan de
manifiesto.

5. Tomar notas escritas

Es buena idea utilizar diferentes herramientas para la toma

de notas, por ejemplo, pizarras, tableros, computador, para
que se pueda hacer seguimiento a la asignacin de
prioridades.

6. Limitar el nmero de Se debe limitar el nmero de revisores, los cuales deben

participantes e insistir en la estar preparados para cada reunin y participar
preparacin anticipada
activamente en el proceso de revisin.

7. Desarrollar una lista de Se deben desarrollar listas de comprobacin para los

comprobacin para cada documentos de anlisis, diseo, codificacin y pruebas.
producto que haya de ser
revisado.

8. Disponer recursos y una

agenda para las RTF

9.
Capacitacin
entrenamiento
de
revisores

Cada

RTF debe estar

modificaciones.

planificada

involucrar

y Todas las personas que participen en el proceso de

los revisin deben recibir un entrenamiento que se debe basar
en:

El proceso

Psicologa humana

10. Revisar las revisiones Son beneficiosas porque permiten descubrir problemas del
anteriores
proceso de revisin.

1.3.-ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

1.3.1.-Surgimiento de SQA (Software Quality Assurance):
En los aos 50, el software comenz a encontrar su camino dentro de los
sistemas del DoD (del ingls Deparment of Defense of USA). Usualmente
estos proyectos estaban muy alejados de la planificacin, se pasaban del
presupuesto y tenan muchos problemas tcnicos. Frecuentemente no
funcionaban como se esperaba y muchos proyectos eran cancelados antes de
ser entregados. Durante este periodo los contratistas para el desarrollo de
software a menudo hacan estimaciones muy optimistas sobre el estado del
desarrollo del software. El DoD normalmente no era notificado de los
problemas en la planificacin, en la gestin del presupuesto y de problemas
tcnicos hasta muy avanzado el proyecto, cuando ya no eran capaces de
entender los problemas ni de evaluar el impacto de stos.
Para intentar resolver este problema se estableci la Verificacin y Validacin
Independientes (IV&V del ingls Independent Verification and Validation), un
proceso de ingeniera que empleaba metodologas rigurosas para evaluar la
correctitud y calidad del software a lo largo de su ciclo de vida.
El primer software en usar IV&V fue el programa del misil atlas a finales de los
aos 50. Desde el proyecto atlas se ha recolectado mucha informacin que
indica que los proyectos con IV&V se realizan o ejecutan mucho mejor que los
proyectos sin IV&V. Con el tiempo el rol del IV&V se convirti crtico. La
actividad que llamamos SQA evoluciona directamente de la Verificacin y
Validacin Independientes(IV&V), muchas de las tareas que asociamos con
SQA son originarias de IV&V.
Luego durante los aos 70 la actividad de desarrollo de software comenz a
expandirse y las compaas de desarrollo de software fueron experimentando
los mismos pobres resultados que las agencias gubernamentales (DoD, NASA
etc.) en las dcadas tempranas. Las compaas tenan dificultad para entregar
el software dentro de los plazos, presupuesto y calidad planificados. Varios
proyectos desarrollados entre 1980 y 1990 fueron desastrosos, muchos
excedan ampliamente el presupuesto y la planificacin o entregaban software
de baja calidad que no se poda usar. Durante los 80 esta experiencia se
convirti en lo que conocemos como crisis del software, el tiempo consumido
10

en el mantenimiento exceda el tiempo insumido en la construccin de nuevos

productos de software.
Luego de la crisis del Software en los aos 80, SQA evoluciono hacia una
herramienta que las compaas de desarrollo de software utilizaban para
identificar de forma temprana los problemas de calidad en el proceso de
desarrollo. Mientras SQA era visto como un pequeo paso dentro del proceso
del desarrollo del software, muchos jefes de proyectos vieron beneficios
cuantificables a partir de integrar SQA dentro del proceso de desarrollo de
software.
En los 90 varias compaas de software ya tenan funciones de SQA dentro de
sus organizaciones.

1.3.2.-SQA no es lo mismo que SQC (Software Quality Control):

Generalmente cuando le preguntamos a un profesional de sistemas que es lo
que entiende por aseguramiento de la calidad del software, inmediatamente
comienza a hablar de testing, algunos de ellos incluyen a la validacin y
verificacin y luego empiezan a hablar de revisiones, las cuales son slo
extensiones del testing. Es decir, a menudo hay una confusin entre SQA y el
testing (el cual actualmente forma parte del rea de control de calidad del
software SQC).
Haciendo slo testing y revisiones no aseguramos la calidad de los productos,
sino aseguramos el cumplimiento de especificaciones tanto funcionales como
tcnicas. En el desarrollo de software la diferencia entre SQC y SQA no est
clara y estos trminos a menudo se confunden, SQA se encarga de controlar el
cumplimiento del proceso, mientras que SQC son aquellas acciones del
aseguramiento de la calidad que proporcionan un medio para controlar y medir
las caractersticas de un elemento, proceso o facilidad respecto a los requisitos
establecidos.
La siguiente tabla expone sintticamente las diferencias entre control de
calidad y aseguramiento de la calidad.

Control de calidad
Detecta
problemas

en

los

Aseguramiento de la calidad
Asegura la adherencia a los procesos,
11

productos de trabajo.
Verifica que los productos de
trabajo
cumplan
con
los
estndares
de
calidad
especificados en el plan de
proyecto.
Revisa el contenido del producto

estndares y planes.
Evala que los procesos, planes y
estndares utilizados en el proyecto
cumplan
con
los
estndares
organizacionales.
Revisa procesos

En conclusin, el rol del SQA es auditar que los distintos equipos de la

organizacin, inclusive el de SQC siguen los procedimientos, estndares y
procesos establecidos. El equipo de SQA debera establecer mtricas para
medir la efectividad del proceso. Como complemento el rol de SQC es tomar
una actitud activa de verificacin y validacin del resultado o salida del proceso
implementado.

1.3.3.-Funciones generales del SQA

Describir los diferentes roles que puede jugar el equipo de SQA en una
organizacin nos dar una visin clara de las funciones que puede llevar a
cabo.
Como polica del proceso: el trabajo del equipo de SQA es asegurar que el
desarrollo sigue el proceso establecido. Entre sus funciones en este rol se
encuentran:

Auditar los productos del trabajo para identificar deficiencias.

Determinar el cumplimiento del plan de desarrollo del proyecto y del

proceso de desarrollo de software.

Juzgar el proceso y no el producto.

Como abogado del cliente: el trabajo del equipo de SQA es representar al

cliente. Entre sus funciones en este rol se encuentran:

Identificar la funcionalidad que al cliente le gustara encontrar.

Ayudar a la organizacin a sensibilizarse con las necesidades del

cliente.

12

Actuar como un cliente de prueba para obtener una alta satisfaccin del
cliente.

Como analista el trabajo del equipo de SQA es recabar informacin. Entre sus
funciones en este rol se encuentran:

Juntar muchos datos sobre todos los aspectos del producto y del
proceso.

Con esta informacin ayudar a mejorar los procesos y los productos.

Como proveedor de informacin el trabajo del equipo de SQA es revisar qu

es lo que est hecho y decir cules objetivos tcnicos realmente estn
cumplidos para que la gerencia pueda tomar mejores decisiones de negocios.
Entre sus funciones en este rol se encuentran:

Proveer informacin tcnica objetiva para que la gerencia pueda usarla

para tomar mejores decisiones.

Proveer informacin apropiada de las clases de productos y de los

riesgos asociados con estos.

Concentrarse ms en la reduccin de los riesgos que en el

cumplimiento del proceso.

Como responsable de la elaboracin del proceso el trabajo del equipo de

SQA es participar en la definicin de los planes, procesos, estndares y
procedimientos para asegurar que se ajustan a las necesidades del proyecto y
que pueden ser usados para realizar las evaluaciones de QA y cumplir los
requerimientos del proyecto y las polticas de la organizacin. Para cumplir
este rol el aseguramiento de la calidad debera comenzar en las fases
tempranas del proyecto.
Aqu conviene aclarar que no necesariamente las personas que definen la
metodologa a seguir pertenecen al equipo de QA. Definir la metodologa
puede llegar a ser o no una actividad del equipo de QA. Una estructura posible
en el proceso de mejora del software puede ser contar con un SEPG (Software
Engineering Process Group) totalmente independiente del equipo de QA,
encargado de definir la metodologa mientras que el equipo de QA se limita a
verificar que se cumpla dicha metodologa.

13

1.3.4.-Consideraciones

Para ser efectivo, el equipo que realiza SQA debe ser independiente de la
organizacin de desarrollo. Aunque tener un grupo de auditora independiente
es difcil de aplicar en organizaciones chicas donde hay pequeos ambientes
de desarrollos. Pero si la organizacin es madura y tiene una cultura orientada
a la calidad, la funcin de SQA puede estar embebida en el proceso. Cuando el
equipo de SQA esta embebido en el proceso, se deben resolver varios
inconvenientes para garantizar la objetividad:

Todo aquel que realice actividades de aseguramiento de la calidad

debera estar entrenado en el aseguramiento de la calidad.

Las actividades de aseguramiento de la calidad realizadas para un

producto deberan ser separadas de aquellas involucradas en el
desarrollo y mantenimiento del mismo.

Debe estar disponible un canal de comunicacin independiente en el

nivel apropiado de la gerencia para poder escalar las no conformidades
cuando sea necesario.

El equipo de SQA provee a la gerencia de informacin fehaciente, objetiva en

el momento adecuado. La clave aqu est en que el grupo de SQA provee a la
gerencia de informacin tcnica objetiva. La gerencia necesita ver a la gente
de SQA como una fuente de informacin significativa que puede ayudarla a
tomar decisiones difciles. La Gerencia usa esta informacin para tomar
decisiones de negocio apropiadas. La objetividad en la evaluacin de calidad
de los procesos y productos es crtica para el xito del proyecto.
La objetividad se logra con independencia del equipo de SQA y sentido comn
o criterio. Hay diferentes maneras de realizar evaluaciones objetivas, entre las
que se incluyen:

Auditoras formales realizadas por un rea de SQA independiente de la

organizacin.

Revisiones de a pares que pueden se realizadas con distintos niveles

de formalidad.

Revisiones rigurosas en el lugar de desarrollo.

14

Revisiones distribuidas y comentarios del producto.

Teniendo en cuenta estas consideraciones podemos decir que la tarea del

equipo de SQA es un conjunto planificado de tareas, actividades y acciones
ejecutadas independientemente de la organizacin que desarrolla software,
que provee a la gerencia del proyecto informacin fehaciente en un momento
preciso que puede ser usada para tomar decisiones de negocio apropiadas.

1.4.-PLANIFICACIN DE LA CALIDAD DE SOFTWARE:

1.4.1.-A Nivel De Las Normas ISO
Segn la norma ISO 9000:2000, la planificacin de la calidad es la parte de la
gestin de la calidad enfocada al establecimiento de los objetivos de la calidad
y a la especificacin de los procesos operativos necesarios y de los recursos
relacionados

para

cumplir

los

objetivos

de

calidad.

Segn la norma ISO/IEC 90003:2004, la planificacin de la calidad facilita el

modo de adaptar la planificacin del sistema de gestin de la calidad a un
proyecto especfico, producto o contrato. La planificacin de la calidad puede
incluir referencias genricas, el proyecto, el producto y/o el contrato especfico
de procedimientos, como apropiados. La planificacin de la calidad debera ser
revisada de nuevo junto con el progreso del diseo y desarrollo, y los
elementos, en cada fase, deberan ser completamente definidos al comienzo
de

dicha

fase.

La Planificacin de la Calidad del Software a nivel de proyectos debera

considerar lo siguiente:
1. Inclusin de los planes de desarrollo.
2. Los requisitos de calidad relacionados con los productos y/o procesos.
3. Los sistemas de gestin de la calidad adaptando y/o identificando los procesos
e instrucciones especficos apropiados para el mbito del manual de calidad y
algunas exclusiones expuestas.

15

4. Los

procesos

de

proyectos especficos e

instrucciones,

tales

como, especificacin de pruebas del software, detallando los planes, diseos,

casos de pruebas y procesos para la unidad, integracin, sistemas y pruebas
de aceptacin.
5. Los

mtodos,

modelos,

herramientas,

convenios

de

lenguajes

de

programacin, bibliotecas, marcos de trabajo y otros componentes reutilizables

para ser usados en los proyectos.
6. Los criterios para el comienzo y final de cada fase o proyecto.
7. Los tipos de anlisis y otras verificaciones y actividades de verificacin para
ser llevadas a cabo.
8. Los procesos de gestin de la configuracin junto con las actividades de
seguimiento y las medidas para ser llevados a cabo.
9. Las personas responsables de aprobar los procesos de salida para su uso
posterior.
10. La formacin necesaria para el uso de herramientas, tcnicas y la organizacin
de la formacin previa a la habilidad necesaria.
11. Los registros para ser mantenidos y la gestin de cambios, como por ejemplo,
para recursos, escalas de tiempo y cambios de contrato.

1.4.2.-A Nivel De Gestin De Calidad

Es la parte de la Gestin de la Calidad encargada de realizar el proceso

administrativo de desarrollar y mantener una relacin entre los objetivos y recursos
de la organizacin; y las oportunidades cambiantes del mercado.
El objetivo es modelar y remodelar los negocios y productos de la empresa, de
manera que se combinen para producir un desarrollo y utilidades satisfactorias.
Los aspectos a considerar en la Planificacin de la Calidad de Software son:
Modelos/Estndares de Calidad de Software a utilizar, Costos de la Calidad de
16

Software,

Recursos

humanos

materiales

necesarios,

entre

otras.

El plan de calidad define los atributos de calidad ms importantes del producto a

ser desarrollado y define el proceso de evaluacin de la calidad.
En la Planificacin de la Calidad de Software se debe determinar:

Rol de la Planificacin.

Requerimientos de la Calidad de Software.

Preparacin de un Plan de Calidad de Software.

Implementacin de un Plan de Calidad de Software

Preparar un Manual de Calidad.

1.5.-CONTROL DE CALIDAD
7 Principios de Control de Calidad
Hacer pruebas muestra la presencia de defectos
Hacer pruebas exhaustivas es imposible
Hacer pruebas anticipadamente
Agrupacin de errores
Paradoja del pesticida
Hacer pruebas depende del contexto
Falacia de ausencia de errores

17

1.6.-NORMAS DE CALIDAD
Principales organismos de normalizacin

Los estndares ANSI/IEEE estn orientados al aseguramiento de la calidad a nivel del

proyecto:

Std. 730: proporciona la estructura de la documentacin del plan de

aseguramiento de la calidad.

Std.1061: definicin de mtricas para productos y para procesos, as como

procedimientos para la recogida de valores de mtricas.

Existen tambin estndares para otras actividades relacionadas con la calidad

como pruebas, verificacin y validacin, revisiones, etc. Los principales se
recogen en la siguiente tabla.

1.6.1.-Estndares ISO 9000

18

Aspectos positivos:

Es un elemento competitivo para las empresas.

Proporciona confianza a los clientes.

Ahorra tiempo y dinero una vez que est implantado.

Implantado en ms de 90 pases y en todo tipo de empresas

industriales y de servicios.

Proporciona cierta seguridad de que las cosas se hacen tal y como se

han dicho que se han de hacer.

Aspectos negativos:

Es costoso de implantar, especialmente en las pequeas empresas.

Muchas veces se hace por obligacin.

Puede existir diferentes interpretaciones de los apartados del estndar.

Existe publicidad engaosa.

CONCLUSIONES:

19

 El manejo de la calidad del software se refiere a asegurar que el

software cumple con estndares requeridos.
Los procedimientos de aseguramiento de calidad debern estar
documentados en un manual de calidad organizacional.
Un plan de calidad de un proyecto deber identificar los requerimientos
especficos de calidad.
Los estndares de software son la reunin de las mejores prcticas.
Las revisiones son el medio principal para la implementacin del
aseguramiento de la calidad.

20

LINKOGRAFA

http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-softwareii/materiales/tema1-pruebasSistemasSoftware.pdf

http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLinea/lec
cin_34__revisiones_del_software.html

http://es.slideshare.net/lidizzg/definicion-de-calidad-y-calidad-de-software

http://sedici.unlp.edu.ar/bitstream/handle/10915/3956/3__Aseguramiento_de_la_calidad_del_software.pdf?sequence=11

http://ocw.uc3m.es/ingenieria-informatica/desarrollo-de-sistemas-deinformacion-corporativos-1/documentos/calidad-del-software

http://www.lsi.us.es/docencia/get.php?id=359

http://dankocs2012.blogspot.pe/2012/12/planificacion-de-la-calidad-desoftware.html

http://www.liderdeproyecto.com/articulos/gestion_de_la_calidad.html

https://jorgemontanoblog.files.wordpress.com/2011/10/control-de-calidad-desoftware-final.pdf

21