"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