"Conjunto de propiedades y características de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades explícitas o implícitas." ISO 8402
"Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente" R.S.Pressman (1992)
"Calidad es la idoneidad de uso. Es decir, las características del producto que satisfacen las necesidades del cliente y, por tanto, producen satisfacción de producto. La calidad es la inexistencia de deficiencias" Juran
"La calidad se define, desde el punto de vista del cliente, como cualquier cosa que aumenta su satisfacción" Deming
"Nivel al que una serie de características inherentes satisfacen los requisitos" ISO 9000: 2000
"La capacidad de un conjunto de características inherentes de un producto, o componente del producto, o proceso, de satisfacer por completo los requisitos del cliente" CMMI® (S.E.I)
Distintas perspectivas de la calidad
Para cualquier organización que entregue productos software, la calidad juega un papel importante. Por lo tanto es importante entender lo que compromete la buena calidad. Pero la calidad se puede ver desde diferentes perspectivas.
Perspectiva de calidad del cliente
Un producto está construido para cumplir los requisitos del cliente. Estos requisitos son de dos tipos:
- Explícitos: Lo que el cliente plantea explícitamente
- Implícitos: Lo que el cliente no especifica pero espera
Perspectiva de calidad del desarrollador
Para los desarrolladores un producto es de calidad cuando todas las especificaciones dadas por el cliente se han cumplido. Sin embargo, los clientes pueden fallar al especificar algunos requisitos o especificarlos de forma no clara.
A menudo, el fracaso al construir un producto de calidad es el resultado de una mala especificación de requisitos o de la especificación de requisitos ambiguos. En el contexto del software, el entendimiento entre los desarrolladores es distinto cuando los requisitos implícitos no son recogidos durante la fase de análisis. Por lo tanto estos requisitos no son incluidos en las especificaciones que los desarrolladores intentan cumplir.
Además, el desarrollador puede interpretar especificaciones ambiguas de forma diferente a lo que el cliente intentó. Como resultado, el producto creado puede no ser útil para el cliente
