Documentos de Académico
Documentos de Profesional
Documentos de Cultura
06
Ingeniera de Software
Presentado por:
Camilo Esteban Rodriguez
Andres Mauricio Clavijo
Brayan Andres Valero
Jhon Alexander Chacon
Presentado a:
Juan Carlos Guevara Bolaos
Tabla de contenido
1. Introduccin ...................................................................................................... 4
2. Calidad.............................................................................................................. 4
2.1.
Definicin ................................................................................................... 4
2.2.
2.3.
Caractersticas ........................................................................................... 5
2.4.
Nombre ................................................................................................... 9
3.1.2.
Descripcin ............................................................................................. 9
3.1.3.
Criterios................................................................................................... 9
Nombre ................................................................................................. 14
4.1.2.
Descripcin ........................................................................................... 14
4.1.3.
Criterios................................................................................................. 14
Nombre ................................................................................................. 17
5.1.2.
Descripcin ........................................................................................... 17
Nombre ................................................................................................. 19
5.2.2.
Descripcin ........................................................................................... 19
6.1.1.
Nombre ................................................................................................. 21
6.1.2.
Descripcin ........................................................................................... 21
6.2.
6.2.1.
Nombre ................................................................................................. 22
6.2.2.
Descripcin ........................................................................................... 22
7.1.1.
Nombre ................................................................................................. 23
7.1.2.
Descripcin ........................................................................................... 23
7.2.
7.2.1.
Nombre ................................................................................................. 26
7.2.2.
Descripcin ........................................................................................... 26
8.1.1.
Nombre ................................................................................................. 27
8.1.2.
Descripcin ........................................................................................... 27
8.2.
8.2.1.1.
Nombre.............................................................................................. 29
8.2.1.2.
Descripcin ........................................................................................ 29
11.
Conclusiones ............................................................................................... 38
12.
Bibliografa................................................................................................... 39
1. Introduccin
Se presenta la gestin de la calidad del software como instrumento principal para asegurar
que el software se realice de buena manera, tanto para el desarrollador como para el cliente,
por lo que existen diferentes aplicaciones que ayudan a desarrollar este tipo de
administracin para el proyecto y se podrn encontrar en este taller de investigacin sin
antes definir el concepto de calidad, las caractersticas, modelos, normas, entre otros.
2. Calidad
2.1.
Definicin
La calidad en el momento cuenta con no solo una definicin si no con varias las
cuales las expondremos a continuacin:
2.2.
Importancia de calidad
2.3.
Caractersticas
2.4.
3.1.1. Nombre
Mccall
3.1.2. Descripcin
El modelo de McCall fue el primero en ser presentado en 1977 y se origin por Air
Forc y Dod.
Adems, Se focaliza en el producto final identificando atributos claves desde el
punto de vista del usuario. Estos atributos se denominan factores de calidad y son
normalmente atributos externos, pero tambin se incluyen algunos atributos
posiblemente internos.
Los factores de calidad son demasiados abstractos para ser medidos directamente,
por lo que por cada uno de ellos se introduce atributos de bajo nivel denominados
criterios de calidad. Algunos criterios de calidad son atributos internos segn McCall
que el atributo interno tiene un efecto directo en el atributo externo correspondiente.
3.1.3. Criterios
McCall propone tres perspectivas para agrupar los factores de calidad:
Revisin del producto: habilidad para ser cambiado.
Transicin del producto: adaptabilidad al nuevo ambiente.
Operacin del producto: caractersticas de operacin.
3.2.1. Nombre
Modelo de Boehm
3.2.2. Caractersticas
El segundo modelo de calidad ms conocido es presentado por Barry Boehm en
1978. Este modelo introduce caractersticas de alto nivel, caractersticas de nivel
intermedio y caractersticas primitivas, cada una de las cuales contribuye al nivel
general de calidad.
Caractersticas de alto nivel: las caractersticas de alto nivel representan
requerimientos generales de uso pueden ser:
3.2.3. Criterios
Aunque los modelos McCall y Boehm parezcan similares, la diferencia est en que
McCall focaliza en medidas precisas de alto nivel, mientras que Boehm presenta un
rango ms amplio de caractersticas primarias. Adems, la Mantenibilidad est ms
desarrollada en Boehm. Otras diferencias entre estos dos modelos las podemos ver
en el siguiente cuadro comparativo:
3.3.1. Nombre
Modelo ISO
3.3.2. Caractersticas
La ISO ha emitido algunas normas que definen un modelo de calidad del software,
en varios contextos de uso.
ISO 9126-1 define 6 caractersticas de calidad principales, y 27 subcaractersticas.
Incluye 3 reportes tcnicos (ISO/IEC 9126-2, 3 e 4).
ISO/IEC 9241 define las caractersticas de un software usable.
ISO 12119 define las caractersticas de calidad para un software COTS
(Commercial off the shelf).
La ISO tambin ha publicado la norma 14598 que gua en el proceso de valoracin
de la calidad del software segn los criterios de la 9126.
Modelo ISO 9126: Durante muchos aos se busc en la Ingeniera de Software un
modelo nico para expresar calidad. La ventaja era fcil de conocer: poder comparar
productos entre s en 1992, una variante del modelo de McCall fue propuesta como
estndar internacional para medicin de calidad de software.
ISO 9126 Software Product Evaluation: Quality Characteristics and Guidelines for
their Use es el nombre formal. La ltima revisin ha sido realizada en el 2004; est
en proceso de una nueva revisin. No se proveen certificados de calidad por esta
norma.
3.3.3. Criterios
En ISO 9126 se reconocen seis factores de calidad que se pueden considerar
tanto internos como externos:
Funcionalidad.
Confiabilidad.
Eficiencia.
Usabilidad.
Mantenibilidad.
Portabilidad.
Los cuatro factores de calidad de uso que se conocen en el modelo ISO 9126:
Eficacia.
Seguridad.
Productividad.
Satisfaccin.
3.4.1. Nombre
Modelo EFQM
3.4.2. Caractersticas
El Modelo EFQM es un modelo no normativo, cuyo concepto fundamental es la
autoevaluacin basada en un anlisis detallado del funcionamiento del sistema de
gestin de la organizacin usando como gua los criterios del modelo.
Esto no supone una contraposicin a otros enfoques (aplicacin de determinadas
tcnicas de gestin, normativa ISO, normas industriales especficas, etc.), sino ms
3.4.3. Criterios
El Modelo EFQM consta de dos partes:
Un conjunto de criterios de excelencia empresarial que abarcan todas las reas del
funcionamiento de la organizacin.
Un conjunto de reglas para evaluar el comportamiento de la organizacin en cada
criterio. Hay dos grupos de criterios:
Los Resultados (Criterios 6 al 9) representan lo que la organizacin consigue para
cada uno de sus actores (Clientes, Empleados, Sociedad e Inversores).
Los Agentes (Criterios 1 al 5) son aspectos del sistema de gestin de la
organizacin. Son las causas de los resultados. Para cada grupo de criterios hay un
conjunto de reglas de evaluacin basadas en la llamada lgica REDER.
Los resultados han de mostrar tendencias positivas, compararse favorablemente
con los objetivos propios y con los resultados de otras organizaciones, estar
causados por los enfoques de los agentes y abarcar todas las reas relevantes.
Los agentes han de tener un enfoque bien fundamentado e integrado con
otros aspectos del sistema de gestin, su efectividad ha de revisarse
peridicamente con objeto de aprender y mejorar, y han de estar sistemticamente
desplegados e implantados en las operaciones de la organizacin.
4.1.2. Descripcin
La organizacin para la estandarizacin, mejor conocida como la ISO es la agencia
especializada en estandarizacin fue establecida el 23 febrero de 1947 con el de
promover estandarizacin internacional de manera que se facilitara el intercambio
internacional de bienes y servicios, as como el desarrollo cientfico y tecnolgico.
Actualmente abarca los estndares nacionales de 91 pases y en estados unidos la
representacin se llama The American National Standards Institute.
4.1.3. Criterios
ISO comprende alrededor de 180 comits tcnicos cada uno es responsable de una
o ms reas de especializacin abarcan desde las abreviaturas de los sistemas de
medicin hasta la especificacin de protocolos de transferencia pasando por
especificacin de tornillos, lentes, contenedores martimos, medios magnticos,
hojas de papel, cables, elementos estructurales, pruebas de seguridad, simbologa,
medio ambiente, etc., principalmente el software.
Con el estndar ISO 9000-3, las 3 fallas predomnales que existen dentro de la
industria de software son: los altos costos en cuanto a depuracin de un sistema,
tiempo perdido en la correccin del sistema y la falla de conocer todas las
necesidades del usuario. Hoy en da la industria del software est implementando
modelos para mejorar sus operaciones y corregir sus fallas y la expectativa es
colocar el desarrollo de software bajo un control estadstico para verificar cuales son
las actividades repetitivas que continuamente se tienen que programar y que
producen el mismo resultado. Uno de los modelos base son las normas estndares
ISO 9000 que en especial han creado un inters masivo para la industria del
software a causa de su aceptacin internacional de muchas compaas importantes.
ISO 9000-3
Ttulo: Normas de gestin de calidad y garanta de la calidad.
Naturaleza: internacional
mbito: desarrollo de sistemas de informacin, procesos de ciclo de vida, calidad
del software.
4.2.1. Nombre
Estndar Spice
4.2.2. Caractersticas
El creciente nmero de mtodos de evaluacin disponibles, y la creciente utilizacin
de la tcnica comercial en reas sensibles, fueron los factores clave que impulsaron
el desarrollo y la aceptacin de una propuesta para desarrollar un estndar
internacional para la evaluacin de procesos de software.
4.2.3. Criterios
Una norma internacional sobre evaluacin de procesos de software ofrecer los
siguientes beneficios a la industria y los usuarios del software:
Beneficios para la Industria del Software.
Los proveedores de software se sometern a un solo esquema de proceso de
evaluacin.
Las organizaciones de desarrollo de software tendrn una herramienta para iniciar
y sostener un proceso continuo de mejora.
Los directores de programas tendrn un medio para garantizar que su desarrollo de
software est en consonancia con, y apoya, las necesidades comerciales de la
organizacin.
4.3.1. Nombre
Estndar CCM
4.3.2. Caractersticas
CMM es el mximo estndar en ingeniera de software Innovacin, velocidad y
satisfaccin del cliente se han convertido en la consigna de las organizaciones que
quieren sobrevivir y crecer en el cada vez ms competitivo mundo moderno. Como
las tecnologas de informacin resultan fundamentales para lograrlas, el software se
ha constituido en la piedra angular sobre la cual se soportan la gran mayora de los
nuevos modelos de empresa.
La creciente necesidad, sumada a dcadas de promesas incumplidas en cuanto a
calidad, costos y cumplimiento en el desarrollo de software, condujo al Instituto de
4.3.3. Criterios
Los niveles progresan desde el 1, que representa el estado catico, hasta el nivel
5, que representa el estado de optimizacin continua.
Nivel 1. Inicial.
Nivel 2. Repetible.
Nivel 3. Definido.
Nivel 4. Administrado.
Nivel 5. Optimizacin.
Nivel 1. Inicial. En este nivel, los procesos y mtodos de ingeniera no se encuentran
definidos. Por esa razn, los proyectos son adelantados de manera incoherente,
incontrolada y poco profesional.
Nivel 2. Repetible. Se establecen algunos procesos y mtodos de ingeniera a nivel
de proyectos, an incipientes.
Nivel 3. Definido. Los procesos, actividades y mtodos relacionados con la
ingeniera y administracin de proyectos se encuentran documentados,
estandarizados y construidos alrededor de un marco integrado para toda la
compaa.
Nivel 4. Administrado. La compaa opera bajo Control Estadstico de Procesos,
tanto en procesos como en productos.
Nivel 5. Optimizacin. En este nivel, las organizaciones se encuentran en un
proceso de mejoramiento continuo. Todos los procesos y tcnicas modernas estn
en pie, lo mismo que la administracin cuantitativa.
5.1.2. Descripcin
El mtodo se compone de tres pasos:
Los valores de los factores ontolgicos son, en algunos casos, estimados por los
usuarios, y en otros calculados mediante frmulas.
Los procedimientos son los siguientes:
Adecuacin del modelo al problema (o1).
Validez del modelo (o2).
Consistencia del modelo (o3).
Concisin del modelo (o4).
Complecin del contenido (o5).
Cohesin del contenido (o6).
Validez del contenido (o7).
El modelo est poco experimentado, por eso se necesita mucha interaccin
entre los diseadores y los usuarios para su retroalimentacin. El propio Kesh
considera que el valor de Q no es una estimacin precisa, sino un indicador de
la calidad del modelo ER y que, por consiguiente, habra que seguir trabajando
sobre el modelo.
5.2.
5.2.2. Descripcin
Moody present un conjunto de mtricas, algunas objetivas y otras subjetivas, para
evaluar algunos factores de calidad de los modelos de datos. Estas mtricas son,
para los diferentes factores de calidad:
Complecin:
o Nmero de elementos del modelo de datos que no corresponden con
los requisitos de usuario.
o Nmero de elementos del modelo de datos que corresponden con los
requisitos de usuario, pero definidos incorrectamente.
o Nmero de requisitos del usuario no representados en el modelo.
o Nmero de inconsistencias con el modelo de procesos.
Integridad:
o Nmero de restricciones de integridad incluidas en el modelo que no
corresponden a polticas de negocio.
o Nmero de reglas del negocio que no se cumplen por el modelo de
datos.
Flexibilidad:
o Costes estimados de los cambios.
o Importancia estratgica de los cambios.
o Nmero de elementos del modelo que en el futuro estarn sometidos
a cambios.
Correccin:
o Nmero de violaciones a las formas normales.
o Nmero de violaciones a las convenciones de modelos de datos.
Simplicidad:
o Nmero de entidades.
o Nmero de entidades y relaciones.
o Nmero de constructores.
Integracin:
o Nmero de conflictos con los sistemas existentes.
o Nmero de conflictos con el modelo de datos corporativo.
o Valoracin de los representantes de todas las reas del negocio.
Implementabilidad:
o Valoracin de riesgo tcnico.
o Valoracin de riesgo de planificacin.
o Estimacin del coste del desarrollo.
o Nmero de elementos fsicos del modelo de datos.
Comprensilidad:
o Valoracin de los usuarios sobre la comprensibilidad del modelo.
o Capacidad de los usuarios de interpretar el modelo correctamente.
o Valoracin de los desarrolladores sobre la comprensibilidad del
modelo.
6.1.2. Descripcin
Abreu y Melo presentaron las mtricas MOOD (Metrics for Object Oriented Design)
para medir algunos de los principales mecanismos de los modelos orientados a
objetos (encapsulamiento, polimorfismo, herencia y paso de mensajes,...) para
poder evaluar la productividad del desarrollo y la calidad del producto.
Estn encuadradas dentro de lo que se conoce como mtricas a nivel de sistema.
Las mtricas MOOD se definieron para aplicarlas a nivel de diagramas de clases y
se pueden utilizar en la fase de diseo.
Las definiciones de las diferentes mtricas son:
MHF: El Method Hiding Factor (factor de ocultamiento de los mtodos) se define
como el cociente entre la suma de las invisibilidades de todos los mtodos definidos
en todas las clases y el nmero total de mtodos definidos en el sistema. La
invisibilidad de un mtodo es el porcentaje total de clases desde las cuales el
mtodo es invisible.
AHF: El Attribute Hiding Factor (factor de ocultamiento de los atributos) se define
como el consiente entre el nmero de invisibilidades de todos los atributos definidos
en todas las clases y el nmero total de atributos definidos en el sistema. Se propone
tambin como medida de encapsulacin. Idealmente el valor de esta mtrica
debera ser siempre del 100%, siendo necesario para ello ocultar todos los atributos.
MIF: El Method Inheritance Factor (factor de herencia de los mtodos) es el cociente
entre el nmero de mtodos heredados en todas las clases del sistema y el nmero
total de mtodos (heredados y locales) en todas las clases.
AIF: El Attribute Inheritance Factor (factor de herencia de los atributos) est definido
como el cociente entre el nmero de atributos heredados en todas las clases del
sistema y el nmero total de atributos existentes (heredados y definidos localmente)
en todas las clases.
PF: El Polymorphism Factor (factor de polimorfismo) se define como el ratio entre el
nmero actual de situaciones diferentes posibles de polimorfismo y el nmero
mximo de posibles situaciones distintas de polimorfismos para cada clase.
6.2.2. Descripcin
En 1994, Chindamber y Kemerer propusieron seis mtricas para la complejidad del
diseo OO, aunque no todas pueden aplicarse a nivel conceptual, y adems han
sido muy criticadas por su ambigedad e imprecisin.
Algunas de estas mtricas estn encuadradas dentro de los que se conoce como
mtricas a nivel de herencia, otras mtricas a nivel de acoplamiento, otras a nivel
de clases.
El acoplamiento es el empleo de mtodos o atributos definidos en una clase que
son usados por otra.
Las clases tienen que interactuar unas con otras para formar sistemas, y esta
interaccin puede indicar su complejidad.
Las mtricas que se consideran a nivel de herencia son:
DIT: La mtrica Depth of Inheritance Tree (profundidad en rbol de herencia
) se define como la profundidad del rbol de una clase (en los casos de
herencia mltiple es la mxima longitud desde el nodo hasta la raz del rbol).
NOC: La mtrica Number Of Children (nmero de hijos) se define como el
nmero de subclases inmediatas subordinadas a una clase, es decir, la
cantidad de subclases que pertenecen a una clase.
CBO: Coupling Between Objects (acoplamiento entre objetos) de una clase
se define como el nmero de clases a las cuales una clase est ligada. Se
da dependencia entre dos clases cuando una de ellas usa mtodos o
variables de la otra clase.
7.1.2. Descripcin
Funcionalidad
Fiabilidad
Madurez: Capacidad del producto software para evitar fallar como resultado de
fallos en el software.
Tolerancia a fallos: Capacidad del software para mantener un nivel especificado de
prestaciones en caso de fallos software o de infringir sus interfaces especificados.
Capacidad de recuperacin: Capacidad del producto software para reestablecer un
nivel de prestaciones especificado y de recuperar los datos directamente afectados
en caso de fallo.
Cumplimiento de la fiabilidad: Capacidad del producto software para adherirse a
normas, convenciones o regulaciones relacionadas con al fiabilidad.
Usabilidad
Capacidad para ser entendido: Capacidad del producto software que permite al
usuario entender si el software es adecuado y cmo puede ser usado para unas
tareas o condiciones de uso particulares.
Capacidad para ser aprendido: Capacidad del producto software que permite al
usuario aprender sobre su aplicacin.
Capacidad para ser operado: Capacidad del producto software que permite al
usuario operarlo y controlarlo.
Capacidad de atraccin: Capacidad del producto software para ser atractivo al
usuario.
Cumplimiento de la usabilidad: Capacidad del producto software para adherirse a
normas, convenciones, guas de estilo o regulaciones relacionadas con la
usabilidad.
Eficiencia
Utilizacin de recursos: Capacidad del producto software para usar las cantidades
y tipos de recursos adecuados cuando el software lleva a cabo su funcin bajo
condiciones determinadas.
Cumplimiento de la eficiencia: Capacidad del producto software para adherirse a
normas o convenciones relacionadas con la eficiencia.
Mantenibilidad
Capacidad para ser analizado: Es la capacidad del producto software para serle
diagnosticadas deficiencias o causas de los fallos en el software, o para identificar
las partes que han de ser modificadas.
Capacidad para ser cambiado: Capacidad del producto software que permite que
una determinada modificacin sea implementada.
Estabilidad: Capacidad del producto software para evitar efectos inesperados
debidos a modificaciones del software.
Capacidad para ser probado: Capacidad del producto software que permite que el
software modificado sea validado.
Cumplimiento de la mantenibilidad: Capacidad del producto software para adherirse
a normas o convenciones relacionadas con la mantenibilidad.
Portabilidad
Efectividad: Capacidad del producto software para permitir a los usuarios alcanzar
objetivos especificados con exactitud y completitud, en un contexto de uso
especificado.
Productividad: Capacidad del producto software para permitir a los usuarios gastar
una cantidad adecuada de recursos con relacin a la efectividad alcanzada, en un
contexto de uso especificado.
Seguridad fsica: Capacidad del producto software para alcanzar niveles aceptables
del riesgo de hacer dao a personas, al negocio, al software, a las propiedades o al
medio ambiente en un contexto de uso especificado.
Satisfaccin: Capacidad del producto software para satisfacer a los usuarios en un
contexto de uso especificado.
7.2.2. Descripcin
Planeamiento y Gestin: Recomendaciones y orientaciones que sirven como apoyo
para el proceso de validacin del producto software. Ej. desarrollo, adquisicin,
transferencia de tecnologas de validacin.
ISO/IEC 14598-3 Procesos para Desarrolladores: Seleccin y registro de
indicadores que pueden ser medidos y evaluados a partir de resultados intermedios
obtenidos durante las fases de desarrollo para que en base a stos se tomen
decisiones acerca del proyecto.
ISO-IEC 14598-4: proceso para los compradores: establece un proceso sistemtico
para la evaluacin de productos de software comercial, de productos de software
personalizado o modificar los productos existentes. Usado para garantizar que un
producto desarrollado o modificado cumple los requisitos inicialmente
especificados.
ISO-IEC 14598-5: proceso para evaluadores orientaciones y recomendaciones para
la aplicacin prctica de la evaluacin de producto de software cuando las diversas
partes, necesitan comprender, aceptar y confiar en los resultados de la evaluacin.
ISO-IEC 14598-6: Documentacin de mdulos de evaluacin. Documento
estructurado.
Producto final:
8.1.2. Descripcin
La norma ISO/IEC 90.003, como aplicacin de la norma ISO 9001 en el
desarrollo de software, nos indica que, en toda actividad, hay que buscar los
procesos que la componen, para poder asegurar la calidad en cada uno de ellos
y, por tanto, asegurar la calidad final de la actividad realizada.
Un documento debe contener toda la informacin necesaria relacionada con un
proceso. Asimismo, un proceso puede estar compuesto, o no, por sub-procesos,
cada uno de los cuales tiene su correspondiente documento. En funcin de la
longitud del documento del proceso, ste contendr 1 ms artculos (o partes).
Esquema documentacin
Correspondencia
Proceso
ISO/IEC 90003:2004
Documento
Joomla!
Categora
8.2.1.2. Descripcin
Problemas
Aplicabilidad
Prototipado
8.2.2.2. Descripcin
Objetivos.
Restricciones.
Alternativas.
Riesgos.
Resolucin de riesgos.
Resultados.
Planes.
Garantas (commitments).
Restricciones:
Alternativas:
Riesgos.
Solucin de riesgos.
Resultados.
Planes.
Garantas.
Check Style.
Checkstyle es una herramienta de desarrollo que ayudar a los programadores
a escribir cdigo Java para que se adhiera a un estndar de codificacin.
Automatiza el proceso de comprobacin de cdigo Java. Esto lo hace ideal
para los proyectos a los que se desea aplicar un estndar de codificacin.
Checkstyle es altamente configurable y se puede hacer para apoyar casi cualquier
estndar de codificacin. De tal manera que se puedan suministrar diferentes
estndares de cdigo para su posterior comprobacin mediante la herramienta.
de
tamao: Define
un
mximo
para
el
tamao
de
tus
un
orden
para
los
modificadores
evita
innecesarios.
Bloques: reglas para los bloques de cdigo y sus llaves.
Problemas en la codificacin: Ac hay de todo, desde malas prcticas tipo
asignaciones internas y posibles fuentes de bugs como definir un mtodo
equals que no es el equals(Object), a cosas ms estticas o poco prolijas,
como que el default sea el ltimo elemento en un switch o parntesis innecesarios.
Diseo de clases: varias reglas sobre el diseo de interfaces y clases, con
especial atencin en las excepciones.
Duplicados: te permite definir un mnimo de lneas para buscar cdigo
duplicado
en tus clases.
Mtricas: define
mximos
para
mtricas
como
complejidad
ciclomtica,
Caractersticas
10.
PMD
Check Style.
Agrupacin de reglas
Ahorro de tiempo/costes para atacar problemas
de calidad
concretos
Seguridad y fiabilidad en las interpretaciones
Facilitar la priorizacin y correccin (toma
decisiones)
de
Google
CodePro
Analytix.
Kiuwan
11.
Conclusiones
12.
Bibliografa
http://dbcalidad.blogspot.com.co/2015/06/los-factores-criticos-de-exito.html
http://es.slideshare.net/tegsistemas/modelo-de-calidad-del-software
file:///C:/Users/Angy%20Alvarado/Downloads/cap1.pdf
file:///C:/Users/Angy%20Alvarado/Downloads/Medida%20del%20SW.pdf
http://issuu.com/myti/docs/my_primer_doc
file:///C:/Users/Angy%20Alvarado/Downloads/cap5.pdf
http://es.slideshare.net/albert317/calidad-del-producto-software
http://alarcos.esi.uclm.es/per/fruiz/cur/santander/mrodriguez-iso25000update.pdf
http://www.infor.uva.es/~manso/calidad/trasmedicion1-intro-medida2011.pdf
http://sg.com.mx/revista/40/midiendo-la-calidad-delsoftware#.Vg4DLPl_Oko
http://conaiisi.unsl.edu.ar/2013/62-438-1-DR.pdf
http://www.kmkey.com/software_gestion_calidad
http://www.sinap-sys.com/es/content/programas-informaticos-para-lagestion-de-sistemas-calidad-medio-ambiente-y-prevencion-de-ri
http://www.guiadelacalidad.com/modelo-efqm/modelo-efqm