A la hora de definir la calidad del software se debe diferenciar entre la calidad del producto software y la calidad del proceso de desarrollo de éste (calidad de diseño y fabricación) . No obstante, las metas que se establezcan para la calidad del producto van a determinar los objetivos a establecer de calidad del proceso de desarrollo, ya que la calidad del primero va a depender, entre otros aspectos, de ésta. Sin un buen proceso de desarrollo es casi imposible obtener un buen producto. Este proceso constituye el objeto del presente documento. Pero la calidad del producto software se diferencia de la calidad de otros productos de fabricación industrial, ya que el software tiene sus propias características específicas:

• El software es un producto mental, no restringido por las leyes de la Física o por los límites de los procesos de fabricación. Es algo abstracto, un intangible.
• Se desarrolla, no se fabrica. El costo está fundamentalmente en el proceso de diseño, no en la posterior producción en serie, y los errores se introducen también en el diseño, no en la producción.
• Los costos del desarrollo de software se concentran en las tareas de Ingeniería, mientras que en la fabricación clásica los costos se acentúan más en las tareas de producción.
• El software no se deteriora con el tiempo. No es susceptible de los efectos del entorno y su curva de fallos es muy diferente de la del hardware. Todos los problemas que surjan durante el mantenimiento estaban allí desde el principio y afectan a todas las copias del mismo; no se generan nuevos errores.
• Es artesanal en gran medida. El software, en su mayoría, se construye a medida, en vez de ser construido ensamblando componentes existentes y ya probados, lo que dificulta aún más el control de su calidad.
• El mantenimiento del software es mucho más complejo que el mantenimiento del hardware. Cuando un componente del hardware se deteriora se sustituye por una pieza de repuesto, pero cada fallo en el software implica un error en el diseño o en el proceso mediante el cual se tradujo el diseño en código máquina ejecutable.
• Es engañosamente fácil realizar cambios sobre un producto software, pero los efectos de estos cambios se pueden propagar de forma explosiva e incontrolada.
• Como disciplina, el desarrollo de software es aún muy joven, por lo que las técnicas de las que dispone aún no están perfeccionadas.
• El software con errores no se rechaza. Se asume que es inevitable que el software presente algunos errores de poca importancia.

También es importante destacar que la calidad de un producto software debe ser considerada en todos sus estados de evolución (especificaciones, diseño, códigos, etc). No basta con verificar la calidad del producto una vez finalizado cuando los problemas de mala calidad ya no tienen solución o su reparación es muy costosa. La problemática general a la que se enfrenta el software es:

• Aumento constante del tamaño y complejidad de los programas
• Carácter dinámico e iterativo a lo largo de su ciclo de vida, es decir que los programas de software a lo largo de su vida cambian o evolucionan de una versión a otra para mejorar las prestaciones con respecto a las anteriores.
• Dificultad de conseguir productos totalmente depurados, ya que en ningún caso un programa será perfecto.
• Se dedican elevados recursos monetarios a su mantenimiento, debido a la dificultad que los proyectos de software entrañan y a la no normalización a la hora de realizar los proyectos.
• No suelen estar terminados en los plazos previstos, ni con los costos estipulados, ni cumpliendo los niveles deseables de los requisitos especificados por el usuario.
• Incrementos constantes de los costos de desarrollo debido entre otros, a unos niveles de productividad bajos.
• Los clientes tienen una alta dependencia de sus proveedores por ser en muchos casos aplicaciones a "medida".
• Procesos artesanales de producción con escasez de herramientas.
• Insuficientes procedimientos normalizados para estipular y evaluar la productividad, costos, y calidad.

Todo lo anterior puede concretarse en:

• Ausencia de especificaciones completas, coherentes y precisas previas por parte del cliente, así como posteriores por parte de los proveedores del software.
• Ausencia de la aplicación sistemática de métodos, procedimientos y normas de ingeniería del software.
• Escasez o ausencia de entornos integrados de programación.
• Escasez de uso de técnicas actuales y automatizadas para la gestión de proyectos.
• Escasez de personal con formación y experiencia en los nuevos métodos, normas y uso de entornos y utilidades de programación.
• Otros derivados del grado de desarrollo técnico y organizativo de cada compañía.

En el nivel más alto de la jerarquía se encuentran los factores de calidad definidos a partir de la visión del usuario del software, y conocidos también como atributos de calidad externos. Cada uno de los factores se descompone en un conjunto de criterios de calidad, o sea aquéllos atributos que cuando están presentes contribuyen a obtener un software de la calidad. Se trata de una visión de la calidad técnica, desde el punto de vista del producto software y se les denomina también atributos de calidad internos. Finalmente para cada uno de los criterios de calidad se definen un conjunto de métricas o medidas cuantitativas de ciertas características del producto que indican el grado en que dicho producto posee un determinado atributo de calidad. De esta manera, a través de un modelo de calidad se concretan los aspectos relacionados con ella de tal manera que se puede definir, medir y planificar. Además el empleo de un modelo de calidad permite comprender las relaciones que existen entre diferentes características de un producto software.
Diferentes aspectos de la calidad

• Interna: medible a partir de las características intrínsecas, como el código fuente
• Externa: medible en el comportamiento del producto, como en una prueba
• En uso: durante la utilización efectiva por parte del usuario

ISO/IEC 9126: Tecnologías de la Información. Calidad de los productos software

• Parte 1: Modelo de Calidad
• Parte 2: Métricas Externas
• Parte 3: Métricas Internas
• Parte 4: Métricas de Calidad en Uso

Modelo de calidad para calidad interna y externa
Funcionalidad

• Adecuación: Capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas y objetivos de usuario especificados.
• Exactitud Capacidad del producto software para proporcionar los resultados o efectos correctos o acordados, con el grado necesario de precisión.
• Interoperabilidad Capacidad del producto software para interactuar con uno o más sistemas especificados.
• Seguridad de acceso Capacidad del producto software para proteger información y datos de manera que las personas o sistemas no autorizados no puedan leerlos o modificarlos, al tiempo que no se deniega el acceso a las personas o sistemas autorizados
• Cumplimiento funcional Capacidad del producto software para adherirse a normas, convenciones o regulaciones en leyes y prescripciones similares relacionadas con 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 recuperación 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.

 
Facilidad de Uso

• Capacidad para ser entendido: Capacidad del producto software que permite al usuario entender si el software es adecuado y cómo 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 aplicación.  
 
• Capacidad para ser operado: Capacidad del producto software que permite al usuario operarlo y controlarlo 
• Capacidad de atracción: Capacidad del producto software para ser atractivo al usuario. 
• Cumplimiento de la usabilidad: Capacidad del producto software para adherirse a normas, convenciones, guías de estilo o regulaciones relacionadas con la Usabilidad.  
 

  Eficiencia

• Comportamiento temporal Capacidad del producto software para proporcionar tiempos de respuesta, tiempos de proceso y potencia apropiados, bajo condiciones determinadas.
• Utilización de recursos Capacidad del producto software para usar las cantidades y tipos de recursos adecuados cuando el software lleva a cabo su función 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 modificación 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

• Adaptabilidad Capacidad del producto software para ser adaptado a diferentes entornos especificados, sin aplicar acciones o mecanismos distintos de aquellos proporcionados para este propósito por el propio software considerado.
• Instalabilidad Capacidad del producto software para ser instalado en un entorno especificado.
• Coexistencia Capacidad del producto software para coexistir con otro software independiente, en un entorno común, compartiendo recursos comunes.
• Capacidad para reemplazar Capacidad del producto software para ser usado en lugar de otro producto software, para el mismo propósito, en el mismo entorno.
• Cumplimiento de la portabilidad Capacidad del producto software para adherirse a normas o convenciones relacionadas con la portabilidad.

Cómo emplear el modelo de McCall. Antes de comenzar a utilizar el modelo de McCall hay que seguir las siguientes pautas:

• Se aceptan los factores, criterios y métricas que propone el modelo.
• Se aceptan las relaciones entre factores y criterios, y entre criterios y métricas.
• Se selecciona un subconjunto de factores de calidad sobre los que aplicar los requisitos de calidad establecidos para el proyecto.

Al comienzo del proyecto habrá que especificar los requisitos de calidad del producto software, para lo cual se seleccionarán los aspectos inherentes a la calidad deseada del producto, teniendo que considerarse para ello:

• Las características particulares del propio producto que se está diseñando: por ejemplo, su ciclo de vida que si se espera que sea largo implicará un mayor énfasis en la facilidad de mantenimiento y la flexibilidad, o bien si el sistema en desarrollo está destinado a un entorno donde el hardware evoluciona rápidamente implicará como requisito su portabilidad.
• La relación calidad-precio, que puede evaluarse a través del costo de cada factor de calidad frente al beneficio que proporciona

Métricas Utilizadas para evaluar la Calidad del Software

Características	Subcaracteristicas	Métrica
Funcionabilidad	Adecuación	¿Cumple con los requisitos?
	Exactitud	Casos de Prueba
	Interoperabilidad	¿Interactúa con otros sistemas? ¿Cuales?
	Seguridad de Acceso	¿Tiene control de acceso?
Fiabilidad	Madurez	Pruebas exhaustivas
	Tolerancia a fallos	Pruebas exhaustivas
	Capacidad de recuperación	Pruebas exhaustivas
Usabilidad	Capacidad para ser entendido	Ayuda en línea, manual de usuario, encuesta
	Capacidad para ser aprendido	Ayuda y ejemplo en línea, caso de prueba, encuesta
	Capacidad para ser operado	Ayuda en línea, manual de usuario, encuesta
	Capacidad de atracción	Interfaz grafica de usuario, nivel de navegabilidad, encuesta
Eficiencia	Comportamiento temporal	Tiempo promedio utilizado para realizar un procedimiento de alta
	Utilización de recurso	Cantidad de memoria utilizada durante la ejecución
Mantenibilidad	Capacidad para ser analizado	Complejidad ciclomatica, % de comentarios, notación húngara, funciones comentadas
	Capacidad para ser cambiado	% de comentarios, modularidad, Fan in, fan out, notación húngara
	Estabilidad	Cantidad de fallas en X cantidad de pruebas
	Capacidad para ser probado	Cantidad de funciones, Complejidad ciclomatica
Portabilidad	Adaptabilidad	Funciona sobre cualquier plataforma
	Instalabilidad	Incluye un programa de instalación, manual de instalación
	Coexistencia	El software funciona paralelamente con cualquier otro software
	Capacidad para reemplazar	No puede ser utilizado en otro entorno