You are on page 1of 22

Principios de la Gestión de la Calidad según ISO 9000: 2000 Los ocho principios de la gestión de la calidad identificados para lograr

los objetivos de la calidad, según "ISO 9000:2000 Sistemas de Gestión de la Calidad. 1. Enfoque al cliente. Las organizaciones dependen de sus clientes y por la tanto deberían comprender las necesidades actuales y futuras de los clientes, satisfacer los requisitos de los clientes y esforzarse en exceder las expectativas de los clientes. 2. Liderazgo. Los líderes establecen la unidad de propósito y la orientación de la organización. Ellos deberían crear y mantener un ambiente interno, en el cual el personal pueda llegar a involucrarse totalmente en el logro de los objetivos de la organización. 3. Participación del personal. El personal, a todos los niveles, es la esencia de una organización y su total compromiso posibilita que sus habilidades sean usadas para el beneficio de la organización. 4. Enfoque basado en procesos. Un resultado deseado se alcanza más eficientemente cuando las actividades y los recursos relacionados se gestionan como un proceso. 5. Enfoque de sistema hacia la gestión. Identificar, entender y gestionar los procesos interrelacionados como un sistema, contribuye a la eficacia y eficiencia de una organización en el logro de sus objetivos. 6. Mejora continua. La mejora continua del desempeño global de la organización debería ser un objetivo permanente de ésta. 7. Enfoque basado en hechos para la toma de decisiones. Las decisiones eficaces se basan en el análisis de los datos y la información. 8. Relación mutuamente beneficiosa con el proveedor. Una organización y sus proveedores son interdependientes, y una relación mutuamente beneficiosa aumenta la capacidad de ambos para crear valor. Estos ocho principios de gestión de la calidad constituyen la base de las normas de sistemas de gestión de la calidad de la familia de Normas ISO 9000.

Ventajas  Estandarizar las actividades del personal que trabaja dentro de la organización por medio de la documentación.  Incrementar la satisfacción del cliente al asegurar la calidad de productos y servicios de manera consistente, dada la estandarización de los procedimientos y actividades.  Medir y monitorear el desempeño de los procesos.  Incrementar la eficacia y/o eficiencia de la organización en el logro de sus objetivos.  Mejorar continuamente en los procesos, productos, eficacia, entre otros.  Reducir las incidencias negativas de producción o prestación de servicios. Desventajas  Los esfuerzos y costos para preparar la documentación y actualizarla de forma regular.  Los costos necesarios para implementar y mantener las medidas necesarias para cumplir con el estándar.

Esta norma es aplicable a la adquisición de sistemas. operación y mantenimiento de productos software. y consta de procesos para adquirir y suministrar productos y servicios software. pero no especifica los detalles de cómo implementar o llevar a cabo las actividades y tareas incluidas en los procesos. suministrar. . controlar y mejorar el marco de trabajo del software. independientemente de que sea hecho interna o externamente a una organización. explotación y mantenimiento de un producto software.CALIDAD EN LOS PROCESOS ISO/IEC 12207 Historia La norma ISO 12207 fue creada con el propósito de establecer un marco común para el ciclo de vida del software para:  Adquirir. Este marco de referencia cubre el ciclo de vida del software desde la conceptualización de ideas hasta su retirada. actividades y las tareas involucradas en el desarrollo. dependiendo de sus necesidades. desarrollar. Una organización. al suministro. desarrollo. productos y servicios software. Incluye también aquellos aspectos de la definición del sistema necesarios para proporcionar el contexto de los productos y servicios software. y a la parte software del firmware. Según la norma ISO/IEC Standard 12207:2008: Software life-Cycle processes propuesta por la ISO (International Organization for Standardization): Ciclo de vida del software: “Es un marco de referencia que contiene los procesos. abarcando la vida del sistema desde la definición de requisitos hasta que se deja de utilizar. Los procesos que hay en esta norma forman un conjunto completo.  Gestionar.  Como base para el comercio internacional de software. Esta norma describe la arquitectura de los procesos del ciclo de vida del software. Cubre además el control y la mejora de estos procesos. puede seleccionar un subconjunto apropiado para satisfacer dichas necesidades. operar y mantener software.

el operador y el que da mantenimiento a los productos software. Procesos de apoyo del ciclo de vida. Estas partes principales son el cliente. para sus usuarios. esto es. el desarrollador. el proveedor. Hay ocho procesos de apoyo del ciclo de vida. cada actividad se subdivide a su vez en un conjunto de tareas. ocho procesos de apoyo y cuatro procesos organizativos. organización que adquiere un sistema. organización que proporciona el servicio de mantenimiento del producto software. producto software o servicio software al cliente. con un propósito bien definido. actualizado y operativo.Esta norma agrupa las actividades que pueden llevarse a cabo durante el ciclo de vida del software en cinco procesos principales. organización que proporciona el servicio de operar un sistema informático en su entorno real. 2) Proceso de suministro: Define las actividades del proveedor. 5) Proceso de mantenimiento: Define las actividades del mantenimiento. Cada proceso del ciclo de vida está dividido en un conjunto de actividades. la gestión de las modificaciones al producto software para mantenerlo. operación o mantenimiento de productos software. organización que proporciona el sistema. Una parte principal es la que inicia o lleva a cabo el desarrollo. organización que define y desarrolla el producto software. producto software o servicio software. Un proceso de . Este proceso incluye la migración y retirada del producto software. Un proceso de apoyo es el que apoya a otro proceso como parte esencial del mismo. Los procesos principales son: 1) Proceso de adquisición: Define las actividades del cliente. y contribuye al éxito y calidad del proyecto software. Los procesos principales del ciclo de vida son cinco procesos que dan servicio a las partes principales durante el ciclo de vida del software. 4) Proceso de operación: Define las actividades del operador. 3) Proceso de desarrollo: Define las actividades del desarrollador.

8) Proceso de solución de problemas: Define un proceso para analizar y eliminar los problemas (incluyendo las no conformidades) que sean descubiertos durante la ejecución del proceso de desarrollo. 5) Proceso de validación: Define las actividades (para el cliente. cualquiera que sea su naturaleza o causa . de una manera conjunta. operación. los productos software. proveedor o parte independiente) para validar los productos software del proyecto software. mantenimiento u otros procesos. 7) Proceso de auditoría: Define las actividades para determinar el cumplimiento de los requisitos. Este proceso puede ser empleado por dos partes cualesquiera. que los productos software y los procesos son conformes a sus requisitos especificados y se ajustan a sus planes establecidos. planes y contrato.apoyo se emplea y ejecuta por otro proceso según sus necesidades. Este proceso puede ser empleado por dos partes cualesquiera. 6) Proceso de revisiones conjuntas: Define las actividades para evaluar el estado y productos de una actividad. Se pueden emplear Revisiones Conjuntas. Los procesos de apoyo son: 1) Proceso de documentación: Define las actividades para el registro de la información producida por un proceso del ciclo de vida. 3) Proceso de aseguramiento de la calidad: Define las actividades para asegurar. 4) Proceso de verificación: Define las actividades (para el cliente. de una manera objetiva. Auditorías. Verificación y Validación como técnicas de Aseguramiento de la Calidad. donde una parte (la auditora) audita los productos software o actividades de otra parte (la auditada). proveedor o una parte independiente) para verificar hasta un nivel de detalle dependiente del proyecto software. donde una de las partes (la revisora) revisa a la otra parte (la revisada). 2) Proceso de gestión de la configuración: Define las actividades de gestión de la configuración.

En cuanto a la responsabilidad. Para conseguirlo.. En 1991 por tanto. Improvement Capability Determination. también conocido como Software SPICE.” ISO decidió entonces se hiciera el desarrollo por pasos de un estándar para la evaluación de procesos. se busca establecer un responsable para cada proceso. ISO/IEC 15504 El ISO/IEC 15504. en Process español. abreviado «Determinación de la Capacidad de Mejora del Proceso de Software» es un modelo para la mejora. mantenimiento de sistemas de información y productos de software. Los pasos fueron los siguientes: 1.. Con la modularidad se pretende conseguir procesos con un mínimo acoplamiento y una máxima cohesión. no importando el uso que se le dé a este. el proyecto SPICE fue creado bajo los auspicios del Comité Internacional de estándares de Ingeniería de Software y Sistemas a través de su Grupo de Trabajo sobre Evaluación de proceso (WG10). facilitando la aplicación del estándar en proyectos en los que pueden existir distintas personas u organizaciones involucradas. Publicación inicial como Informe Técnico ‘Technical Report’ (“borrador de estándar”) para que después de su uso real pase a . En 1992. evaluación de los procesos de desarrollo. el estándar se basa en dos principios fundamentales: Modularidad y responsabilidad.la comunidad internacional debería poner recursos para desarrollar un estándar para la evaluación de procesos software.Estructura La estructura del estándar ha sido concebida de manera que pueda ser adaptada a las necesidades de cualquiera que lo use. el informe del grupo de estudio dijo que: “. incorporando lo mejor de los métodos de evaluación de procesos existentes.

 Promover la transferencia de tecnología de la evaluación de procesos de software a la industria del software a nivel mundial. El Borrador de Trabajo se denominaba comúnmente como el conjunto de documentos SPICE (o SPICE Versión 1).  Llevar a cabo los ensayos de la industria de la norma emergente. El primer objetivo del proyecto se logró en junio de 1995. Objetivos El proyecto SPICE tenía tres objetivos principales:  Desarrollar un borrador de trabajo para un estándar de evaluación de procesos de software. Revisión y publicación como estándar internacional IS ISO/IEC 15504 – Tecnologías de la Información – Evaluación de Procesos („ISO/IEC 15504 – Information Technology – Process Assessment’). Importancia Reducción de Costos y Aumento en la satisfacción del Cliente. como indicadores primarios de la mejora del proceso. .2. con la entrega del borrador de trabajo de la norma para la evaluación de procesos de software al WG10 para su votación entre la comunidad de estandarización internacional.

En aquel momento se comenzó a trabajar en la versión "Internacional Standard" de la norma. y desde 2006 está completamente publicado. el proyecto SPICE se cerró oficialmente. La Red SPICE se estableció posteriormente con el encargo de seguir coordinando las actividades de la comunidad SPICE. Fue entonces.  Proporciona guías para la definición de las competencias de un evaluador de procesos.spiceusergroup. Características  Establece un marco y los requisitos para cualquier proceso de evaluación de procesos y proporciona requisitos para los modelos de evaluación de los procesos. La Red de SPICE está formalmente organizada por el „The Spice User Grupo‟ (www. Con el fin de apoyar la excelencia y la coherencia de la formación de los evaluadores.  Actualmente tiene 10 partes: de la 1 a la 7 completas y de la 8 a la 10 en fase de desarrollo. Los ensayos de estos primeros documentos SPICE han sido el foco del proyecto SPICE durante el período 1994 a 1998. en 1998 cuando se publicó la primera familia de estándares ISO TR 15504. En este momento se efectúan actividades promocionales que se realizan a través de la Conferencia Internacional Anual SPICE y la publicación de artículos y libros.  Proporciona también requisitos para cualquier modelo de evaluación de organizaciones.Este primer borrador se basó en modelos existentes en aquél momento.org). el proyecto SPICE también desarrolló y lanzó un Plan de Estudios de formación de los evaluadores SPICE que es utilizado actualmente por el Esquema de Registro Internacional de Evaluadores (IntRSA). . exceptuadas las partes nuevas que se estén produciendo. En marzo de 2003.

un Modelo de evaluación de procesos para los procesos de servicios TIC que serán definidos en el estándar ISO/IEC 20000-4 que definirá los procesos contenidos en la norma ISO/IEC 20000-1. determinación de capacidad. mantenimiento y operación de sistemas. en su parte 8.  Equivalencia y compatibilidad con CMMI.  Por o en nombre de una organización. Fomenta a la organización a una adecuada evaluación de Procesos y debe fomentar los siguientes puntos: . en su parte 6. ISO forma parte del panel elaborador del modelo CMMI y SEI mantiene la compatibilidad y equivalencia de ésta última con 15504. con el objetivo de determinar la idoneidad de sus propios procesos para un requisito particular o un conjunto de requisitos.  Proporciona.  Proporcionará. Propósitos  Por o en nombre de una organización. en su parte 5. un Modelo de evaluación de procesos para los procesos de ciclo de vida del sistema definidos en el estándar ISO/IEC 15288 que define los procesos del ciclo de vida del desarrollo. mantenimiento y operación de los sistemas de software. con el objetivo de determinar la idoneidad de los procesos de otra organización para un contrato determinado o un conjunto de contratos. Sin embargo CMMI-DEV aún no es un modelo conforme con esta norma (según lo requiere la norma ISO 15504 para todo modelo de evaluación de procesos).  Proporciona.  Por o en nombre de una organización. con el objetivo de comprender el estado de sus propios procesos para la mejora de procesos. mejora de procesos. un Modelo de evaluación de procesos para los procesos de ciclo de vida del software definidos en el estándar ISO/IEC 12207 que define los procesos del ciclo de vida del desarrollo. Comprende: evaluación de procesos.

 La optimización de recursos. contenido en la Parte 5 de la Norma ISO/IEC 15504 define el Modelo de procesos de referencia como los procesos contenidos en la norma ISO/IEC 12207 Amd1/Amd2. La cultura de mejora continua y el establecimiento de los mecanismos adecuados para apoyar y mantener la cultura. Ejemplos de Modelos de evaluación de procesos ISO/IEC 15504 . el modelo de evaluación de procesos de software.la dimensión de la capacidad: niveles de capacidad y atributos de los procesos.  La ingeniería de procesos para alcanzar los requisitos del negocio. Dimensiones Tiene una arquitectura basada en dos dimensiones: de proceso y de capacidad de proceso. Los niveles de capacidad para todo modelo de evaluación de procesos pueden tener desde el 0 y al menos hasta el nivel 1 de los siguientes niveles de capacidad estándar:  Nivel 0: Incompleto  Nivel 1: Realizado  Nivel 2: Gestionado  Nivel 3: Establecido  Nivel 4: Predecible  Nivel 5: En optimización Para cada nivel existen unos atributos de procesos estándar que ayudan a evaluar los niveles de capacidad.5 Modelo de evaluación de procesos de ciclo de vida de software Por ejemplo. que contienen tres categorías de procesos y cada una con diferentes grupos de procesos: .la dimensión de procesos: el modelo de procesos de referencia (dimensión de las abscisas) . Define que todo modelo de evaluación de procesos debe definir: .

.Dimensión procesos Procesos Primarios:  ACQ: Procesos de Cliente  SPL: Procesos de Proveedor  ENG: Ingeniería  OPE: Procesos de operación Procesos de soporte  SUP: Soporte Procesos de organización  MAN: Procesos de Gestión  REU: Procesos de Recursos humanos  RIN: Procesos de Infraestructura  PIM: Procesos de mejora de procesos. Dimensión de la capacidad La dimensión de capacidad del modelo de evaluación de procesos de software de la Parte 5 define un conjunto completo de indicadores para todos los atributos de procesos correspondientes a la escala de los 6 niveles de capacidad de la Parte 2 de la norma. incluyendo indicadores para evaluar los atributos de estos procesos correspondientes a la escala de los 6 niveles de capacidad de la Parte 2 de la norma. ISO/IEC 15504-6 modelo de evaluación de procesos de ciclo de vida de sistema El modelo de evaluación de procesos de la parte 6 contiene otro Modelo de procesos de referencia (para sistemas).

Características La norma define las principales características del proceso de evaluación . Fiat. diseñar y realizar acciones de evaluación y para concluir la evaluación de cualquier tipo de producto de software. métricas y requisitos para los procesos de evaluación de los mismos. Jaguar.EVALUACIÓN DE PRODUCTOS DE SOFTWARE Norma ISO/IEC 14598. Se definen y describen las actividades necesarias para analizar los requisitos de evaluación. Ford. es utilizada para aplicar los conceptos descritos en la norma ISO/IEC 9126. Automotive SPICE El 21 de agosto del 2005 el Special Interest Group (SIG). pero es un modelo conforme con los requisitos de parte de la ISO/IEC 15504 . En sus diferentes etapas. CALIDAD EN EL PRODUCTO NORMA ISO/IEC 14598 .Otros modelo de evaluación de procesos El modelo de evaluación de procesos de AutomotiveSPICE no es norma ISO. Se añadieron algunos procesos (que en ISO/IEC 15504) estaban agrupados y se adaptó la terminología a la industria automovilística. establece un marco de trabajo para evaluar la calidad de los productos de software proporcionando. El contenido así como los métodos de evaluación no se diferencian de forma sustancial del ISO/IEC 15504. Daimler. Este estándar es el que actualmente utilizan los miembros del SIG para evaluar y comparar sus proveedores de software. En particular. un grupo de trabajo de la industria del automóvil (con representación de AUDI. El nivel que normalmente demandan las empresas automovilísticas de sus proveedores electrónicos es el Nivel 3. para especificar. BMW. además. Volkswagen y Volvo Car) creó una versión específica de SPICE para las particularidades de la industria del automóvil denominado Automotive SPICE.para todo modelo de evaluación de procesos). por ello su transcendencia entre los proveedores del sector del automóvil.

 Reproducibilidad.  Evaluación de las especificaciones.  ISO/IEC 14598-4 Proceso para adquirientes: provee los requisitos y guías para que la evaluación del producto software sea llevada a cabo en función a los compradores que planean adquirir o reutilizar un producto de software existente o pre-desarrollado. .  Evaluación del diseño y definición del plan de evaluación. Partes La Norma ISO/IEC 14598 define el proceso para evaluar un producto de software.  Objetividad.  ISO/IEC 14598-3 Proceso para desenvolvedores: provee los requisitos y guías para la evaluación del producto software cuando la evaluación es llevada a cabo en paralelo con el desarrollo por parte del desarrollador. Repetitividad. Para estas características se describen las medidas concretas que participan:  Análisis de los requisitos de evaluación.  Imparcialidad.  Evaluación de la conclusión.  Ejecución del plan de evaluación. el mismo consta de seis partes:  ISO/IEC 14598-1 Visión General: provee una visión general de las otras cinco partes y explica la relación entre la evaluación del producto software y el modelo de calidad definido en la ISO/IEC 9126  ISO/IEC 14598-2 Planeamiento y Gestión: contiene requisitos y guías para las funciones de soporte tales como la planificación y gestión de la evaluación del producto del software.

 La reingeniería del software.  ISO/IEC 14598-6 Documentación de Módulos: provee las guías para la documentación del módulo de evaluación.  Las comparaciones entre productos. Servicios Los servicios relacionados con la evaluación de software de productos son generalmente adaptados a las necesidades de los usuarios finales individuales o proveedores. Gestión de resultados . en función de por qué se pidió la evaluación. ISO/IEC 14598-5 Proceso para avaladores: provee los requisitos y guías para la evaluación del producto software cuando la evaluación es llevada a cabo por evaluadores independientes.  Orientación del Evaluador hacia el Solicitante en la definición de requerimientos. ¿Quiénes conforman la norma?  Desarrolladores  Adquirientes  Evaluadores Actividades de los Desarrolladores  Planteo de requerimientos del Solicitante.  Certificación de la calidad del software de acuerdo a los modelos de calidad y normas. Los servicios de evaluación de software incluyen:  Definición de perfiles de calidad de referencia de software.  Acuerdo mutuo en la definición de requerimientos.  Definición del cubrimiento de la evaluación por parte del Solicitante.  Servicio de Monitoreo de calidad del producto.  Evaluación de acuerdo con los modelos de calidad predefinidos.

Recomienda que los requisitos de calidad deban ser proporcionales a las necesidades de la aplicación y lo crítico que sea el correcto funcionamiento del sistema implementado. División del modelo de calidad.ISO/IEC 25000 El objetivo general de la creación del estándar ISO/IEC 25000 SQuaRE (Software Product Quality Requeriments and Evaluation) es organizar. soportada por el proceso de medición de calidad del software. Las características de calidad y sus mediciones asociadas pueden ser útiles no solamente para evaluar el producto software sino también para definir los requerimientos de calidad. Los estándares pertenecientes a esta división incluyen un modelo de referencia de calidad del . términos y referencias a los que se alude en las demás divisiones de SQuaRE. las cuales a su vez se componen de subcaracterísticas. División de gestión de calidad.  ISO/IEC 2502n. externa y en uso. Los estándares que forman esta división definen todos los modelos comunes. División de mediciones de calidad. Fue desarrollada por el subcomité SC 7 (Ingeniería de software y sistemas) del comité técnico conjunto ISO/IE JTC. El estándar que conforma esta división presenta un modelo de calidad detallado. incluyendo características para la calidad interna. Divisiones  ISO/IEC 2500n. enriquecer y unificar las series que cubren dos procesos principales: especificación de requisitos de calidad del software y evaluación de la calidad del software.  ISO/IEC 2501n. Establece que la calidad del producto software está compuesta de características de calidad. La serie ISO/IEC 25000:2005 reemplaza a dos estándares relacionados: ISO/IEC 9126 (Software Product Quality) e ISO/IEC 14598 (Software Product Evaluation).

División de requisitos de calidad. Incluyen requisitos para la calidad de productos de software “Off -The-Self” y para el formato común de la industria (CIF) para informes de usabilidad. Presenta aplicaciones de métricas para la calidad de software interna. los cuales propusieron un modelo para especificar la calidad del software. definiciones matemáticas de las métricas de calidad y una guía práctica para su aplicación. Estos estándares proporcionan requisitos. El modelo de calidad McCall está organizado sobre tres tipos de Características de Calidad:  Factores (especificar): Describen la visión externa del software.  Métricas (controlar): Se definen y se usan para proveer una escala y método para la medida. Los estándares que forman parte de esta división ayudan a especificar los requisitos de calidad. ISO/IEC 9126 El estándar ISO/IEC 9126 proviene desde el modelo establecido en 1977 por McCall y sus colegas. 2003). Estos requisitos pueden ser usados en el proceso de especificación de requisitos de calidad para un producto software que va a ser desarrollado o como entrada para un proceso de evaluación. como es visto por los usuarios.  Criterios (construir): Describen la visión interna del software.  ISO/IEC 2503n. Estándares de extensión SQuaRE.  ISO/IEC 2504n. División de evaluación de la calidad. recomendaciones y guías para la evaluación de un producto software. El proceso de definición de requisitos se guía por el establecido en la norma ISO/IEC 15288 (ISO.producto software. tanto si la llevan a cabo evaluadores.  ISO/IEC 25050–25099. . como clientes o desarrolladores. externa y en uso. como es visto por el desarrollador.

. la noción de usuario se amplía tanto a operadores como a programadores. El estándar internacional posee otras tres partes con carácter de reportes técnicos (aún no son estándares propiamente tales):  ISO / IEC TR 9126-2 Ingeniería de software .Parte 2: indicadores externos  ISO / IEC TR 9126-3 Ingeniería de software . y b) Calidad en uso. ISO/IEC 9126 es un estándar de calidad de productos compuesto por 4 partes. El objetivo es abarcar todos los aspectos que pueden afectar a la calidad de los productos de software. ISO 25000:2005. Como resultado.Calidad del producto .Calidad del producto . los cuales son usuarios de componentes como son bibliotecas software.Calidad del producto . Una distinción similar es la que se establece entre validación y verificación. Un fallo es el incumplimiento de los requisitos previos. ISO/IEC 9126-1 describe un modelo de dos partes para calidad de productos de software: a) Calidad interna y externa. el cual sigue los mismos conceptos. código fuente. y así. descripciones de arquitectura.ISO/IEC 9126 es un estándar internacional para la evaluación del Software.Parte 3: métricas internas  ISO / IEC TR 9126-4 Ingeniería de software . ISO/IEC 9126 distingue entre fallo y no conformidad. Está supervisado por el proyecto SQuaRE. mientras que la no conformidad es el incumplimiento de los requisitos especificados.Parte 4: La calidad en el uso de métricas Un producto software está definido en un sentido amplio como: los ejecutables.

 Identificar el criterio de aceptación para un producto de software completo.ISO/IEC 9126: CALIDAD EN EL CICLO DE VIDA DEL SOFTWARE Ámbitos de uso de ISO/IEC 9126  Validar la integridad de una definición de requisitos.  Identificar los objetivos del diseño del software.  Identificar los requisitos del software. con el grado necesario de precisión.  Exactitud: Capacidad del producto software para proporcionar los resultados o efectos correctos o acordados.  Priorizar los recursos en los aspectos más importantes en términos de calidad. Factores de la Norma para Calidad Externa e Interna 1.  Identificar el criterio de aseguramiento de calidad. . FUNCIONALIDAD  Adecuación: Capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas y objetivos de usuario especificados.  Identificar los objetivos de la prueba de software.

al tiempo que no se deniega el acceso a las personas o sistemas autorizados  Cumplimiento funcional: Capacidad del producto software para adherirse a normas.  Capacidad de atracción: Capacidad del producto software para ser atractivo al usuario.  Capacidad para ser operado: Capacidad del producto software que permite al usuario operarlo y controlarlo. 2. convenciones o regulaciones relacionadas con la fiabilidad. . 3.  Capacidad para ser aprendido: Capacidad del producto software que permite al usuario aprender sobre su aplicación. convenciones o regulaciones en leyes y prescripciones similares relacionadas con funcionalidad. CONFIABILIDAD (FIABILIDAD)  Madurez: Capacidad del producto software para evitar fallar como resultado de fallos en el software.  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.  Cumplimiento de la fiabilidad: Capacidad del producto software para adherirse a normas. FACTIBILIDAD DE USO (USABILIDAD)  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 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. Interoperabilidad: Capacidad del producto software para interactuar con uno o más sistemas especificados.  Tolerancia a fallos: Capacidad del software para mantener un nivel especificado de prestaciones en caso de fallos software o de infringir sus interfaces especificados.

sin aplicar acciones o mecanismos distintos de aquellos proporcionados para este propósito por el propio software considerado. 4. 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.  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. 6. Cumplimiento de la usabilidad: Capacidad del producto software para adherirse a normas.  Estabilidad: Capacidad del producto software para evitar efectos inesperados debidos a modificaciones del software.  Cumplimiento de la mantenibilidad: Capacidad del producto software para adherirse a normas o convenciones relacionadas con la mantenibilidad. tiempos de proceso y potencia apropiados. guías de estilo o regulaciones relacionadas con la usabilidad.  Capacidad para ser probado: Capacidad del producto software que permite que el software modificado sea validado. PORTABILIDAD  Adaptabilidad: Capacidad del producto software para ser adaptado a diferentes entornos especificados. convenciones. EFICIENCIA  Comportamiento temporal: Capacidad del producto software para proporcionar tiempos de respuesta.  Cumplimiento de la eficiencia: Capacidad del producto software para adherirse a normas o convenciones relacionadas con la eficiencia. bajo condiciones determinadas. .  Capacidad para ser cambiado: Capacidad del producto software que permite que una determinada modificación sea implementada. 5.

Productividad: Capacidad del producto software para permitir a los usuarios gastar una cantidad adecuada de recursos con relación a la efectividad alcanzada. al negocio.  Coexistencia: Capacidad del producto software para coexistir con otro software independiente. 4.  Cumplimiento de la portabilidad: Capacidad del producto software para adherirse a normas o convenciones relacionadas con la portabilidad. Seguridad física: Capacidad del producto software para alcanzar niveles aceptables del riesgo de hacer daño a personas. compartiendo recursos comunes. para el mismo propósito. Atributos para Calidad en uso 1. Instalabilidad: Capacidad del producto software para ser instalado en un entorno especificado. al software. . 2. en un entorno común. en un contexto de uso especificado. a las propiedades o al medio ambiente en un contexto de uso especificado. Efectividad: Capacidad del producto software para permitir a los usuarios alcanzar objetivos especificados con exactitud y completitud. Satisfacción: Capacidad del producto software para satisfacer a los usuarios en un contexto de uso especificado. 3.  Capacidad para reemplazar: Capacidad del producto software para ser usado en lugar de otro producto software. en el mismo entorno. en un contexto de uso especificado.

En un perfil están definidos:  Los atributos y subcaracterísticas relevantes para el producto de software.  Métricas externas son aquellas aplicables al software en ejecución. Haciendo esto así.  Las métricas que se usarán en la medición. por ejemplo. La calidad en las métricas de uso están sólo disponibles cuando el producto final es usado en condiciones reales. Idealmente.  Métricas internas son aquellas que no dependen de la ejecución del software (medidas estáticas). El estándar provee un entorno para que las organizaciones definan un modelo de calidad para el producto software. especificando los objetivos para las métricas de calidad las cuales evalúan el grado de presencia de los atributos de calidad. sin embargo.  Los rangos de aceptación de esas métricas. la calidad interna determina la calidad externa y esta a su vez la calidad en el uso. . Esto podría ser hecho. se lleva a cada organización la tarea de especificar precisamente su propio modelo.Perfil de Calidad usando ISO/IEC 9126 Un perfil de calidad permite localizar la definición o evaluación de calidad de un producto de software en los criterios de calidad más importantes según el contexto requerido.