作为负责软件产品的开发和构造以及提供相关服务的学科的软件工程不能逃脱质量的要求，从这个意义上说，已经制定了一些标准来关注与软件开发方式有关的内容。产品的制造和精加工或提供的服务，以及产品的质量以及客户和最终用户的看法。
本文简要介绍了自古以来质量的重要性，以及其影响如何直接影响到最近的软件开发行业，在此，针对软件事实的一系列标准和方法论应运而生并得到了发展。保证质量的目的。根据软件开发过程的质量及其质量和使用，根据几位作者的标准及其主要特征，汇编了被认为最具影响力的不同标准。
关键词：质量，质量保证，软件质量，软件工程，过程，产品。
质量与软件工程
自古以来，质量就一直存在。在第二次世界大战中，古埃及人展示了检查样本和高精度检查，直到第二次世界大战，他们才开始对质量问题进行更严格的培训，直到今天，不同的技术和随着时间的推移，开发的方法已发生了重大变化，为当前的组织做出了积极的贡献。
作为负责软件产品的开发和构造以及提供相关服务的学科的软件工程不能逃脱质量的要求，从这个意义上说，已经制定了标准，目的是解决与产品生产方式有关的问题。产品的质量，客户和最终用户对产品的了解。
本文简要介绍了自古以来质量的重要性以及其影响如何直接影响到最近的软件开发行业的历史历史记录，在该行业中，已经出现并发展了一系列针对软件事实的标准和方法。保证质量的目的。根据几位作者的标准以及根据软件开发过程的质量以及软件的质量和用途而定的主要特征，认为最有影响力的不同标准的汇编。
关键字：质量，质量保证，软件质量，软件工程，过程，产品。
从软件工程看质量
质量是运营的四个基本目标之一，同时也是成本，灵活性和交付的保证。即使质量管理是跨职能的并且涉及整个组织，运营领域也有责任特别为客户精心设计优质产品。这需要整个组织的合作以及管理和质量控制的仔细关注。
（Schroeder et al。，2011）。
质量保证通常与某种形式的测量和检查相关联，这是质量管理中的两个基本问题，并且一直是整个生产过程中的重要方面（ Colliers和Evans，2009年）。从公元前1,450年左右的埃及壁画开始进行测量和检查，再到经过精确切割的金字塔石，仅举两个古代的例子。埃及人的成功归因于不断使用完善的方法和程序以及精密的测量设备（Colliers和Evans，2009年）。
后来，在工业革命期间，可互换零件的使用和将劳动分工成较小的任务需要进行细致的质量控制，这导致依靠检查来识别和消除缺陷。随着时间的流逝，组织创建了独立的质量部门；人为地将生产工人从质量保证责任中分离出来，导致工人和经理（Colliers和埃文斯，2009年）。
第二次世界大战为质量保证的发展奠定了新的里程碑，许多专家接受了统计工具使用方面的培训，从而成为众所周知的统计质量控制手段，并逐渐在所有制造业中得到采用。但是，由于高层管理人员将太多的质量责任委派给了其他人，他们对此几乎一无所知，而几年后质量危机来临时，他们就没有做好应对的准备（Colliers和Evans，2009年）。
在此期间，两名美国顾问约瑟夫·朱兰（Joseph Juran）和爱德华兹·戴明（W. Edwards Deming）向日本人介绍了统计控制技术，以帮助他们进行重建。其教育活动的很大一部分集中在高级管理层，而不是独立的质量专家。在高级管理人员的支持下，日本人将质量融入其所有组织中，并形成了持续改进的文化（Colliers和Evans，2009年）。
日本品质的改善缓慢而稳定；到1970年代，日本产品的质量超过西方制造商的质量大约需要20年的时间，主要是由于其产品的卓越质量水平，日本公司已经有了相当大的渗透在市场上。大多数美国公司的反应是发起详细的质量改进活动，不仅关注合规性，而且关注改进设计质量（Colliers和Evans，2009年）。
随着组织开始将质量原则整合到他们的管理系统中，全面质量管理的概念开始流行。总体质量代表了整个价值链的利益，而不仅仅是在生产运营过程中以及组织中每个人和职能部门的参与。质量在整个组织的绩效中表现出卓越的新含义，而不是基于工程的技术学科（Colliers和Evans，2009）。
近年来，公司董事会对质量提出了新的要求，即六西格码（Six Sigma）的概念，这是一种以客户为中心，以结果为导向的方法来改善业务。六西格码（six Sigma）整合了经过多年测试和验证的高质量工具和技术，并提供了对管理人员非常有吸引力的基本指导。 （Colliers和Evans，2009年）。
当前，为了找到并保持备受赞赏的质量，出现了许多技术和方法，这就是为什么在大多数组织中，无论其方向（制造或服务）如何，都构成了不同的系统赋予生命的管理。在这些系统中包括质量管理系统，财务管理系统，环境管理系统，安全管理系统等，这些系统中的每一个都是组织和组织内部的支柱。其中之一的失败可能会导致组织的整体失败，从这个意义上讲，质量管理体系是组织的一部分，它通过改善组织的质量来支持客户满意度。组织，包括改善其核心流程，产品和服务（Souri，2016年）。
核心流程是与目的或任务直接相关的流程，即那些最初被认为是实现组织存在理由的必要流程，在提供服务是组织存在理由的情况下也是如此。在这种情况下，核心流程将由与该服务提供相关的所有活动组成（Souri，2016年）。
在谈论服务质量时，有必要进行一些区分，因为定义和度量与制造质量完全不同。服务质量涉及的维度包括发货产品，有形服务（显性）和心理服务（隐含），尽管所提供产品的质量可以通过制造，有形服务和心理上需要不同的测量方法。制造度量可能是高度客观的，而许多服务度量是感知或主观的。符合性的质量可以通过报废和工厂返工的成本来计算（Schroeder等，2011）。
重要的是要知道与质量相关的概念如何在不断发展的软件行业及其构建或开发过程中应用。当前，软件具有双重作用，因为它是一种产品，同时也是通过提供服务来交付产品的渠道。它的形式是一种产品，它具有集成在计算硬件中的计算潜力，或者更广泛地存在于通过本地硬件访问的计算机网络中，无论是驻留在移动电话中还是驻留在其中。在中央计算机或服务器内部运行，该软件是一个信息转换器：它产生，管理，获取，修改，显示或传输的信息可以很简单，也可以很复杂，就像从数十个独立来源获得的数据生成的多媒体演示一样复杂。因此，庞大的软件产业已成为工业化世界经济中的主导因素（Pressman，2010）。
尽管成百上千的作者已经制定了有关软件工程的个人定义，但Fritz Bauer的建议还是作为分析的基础，这表明软件工程是工程的基本原理的建立和使用，以便以某种方式进行开发。价格合理，可靠，高效的软件产品。
软件工程也是对软件的开发，操作和维护进行系统，有纪律和可量化的方法的应用，也就是说，将工程应用到软件是多层技术，任何工程方法，甚至包括软件必须基于组织对质量的承诺。全面质量管理，六个西格玛（Six Sigma）和其他类似的哲学推动了持续改进的文化，而正是这种文化最终导致了软件工程日益有效的方法的发展。软件工程的基础是对质量的承诺。 （出版社，2010年）。
随着时间的推移，已经提出了软件质量的几个维度和因素，所有这些维度和因素都试图定义一组特性，如果实现这些特性和特性，将允许开发高质量的软件，一些标准则建立了诸如可靠性，可用性，维护性等特性。 ，功能和可移植性，作为质量存在的指标。
（出版社，2010年）。
每个组织都面临软件质量的困境。本质上，每个人都希望构建高质量的系统，但是在市场驱动的世界中，您根本没有时间和精力来生产“完美”的软件（Pressman，2010年）。不管选择哪种方法，质量都会付出可预防，评估和失败的代价。预防成本包括旨在防止缺陷的软件工程的所有措施。评估成本与评估软件工作产品质量的那些操作相关。故障成本包括故障的内部价格和导致质量下降的外部影响（Pressman，2010）。
根据ISO 8402（1986）标准，可以将质量模型定义为一组质量因子及其之间的关系，这为质量要求的规范和软件组件质量的评估提供了基础。 。
质量模型通常被构造为层次结构（树或有向图），其中可能将更通用的质量因数（例如效率或可用性）分解为更具体的因数，例如响应时间或易学习性在不同程度的分解。可以将软件质量模型应用于各种特定活动中：根据模型的质量因数建立组件选择的质量要求，针对模型的每个质量因数评估组件的质量，针对选择过程建立的要求比较不同组件的质量，并起草正式合同，供应商认证的组件的质量评估在此处明确显示。通常，模型中出现的质量因子可以用作所有与组件质量有关的问题的清单。
自从提出质量模型概念以来，提出了许多建议。所述建议试图解决以下问题：应成为软件组件质量模型一部分的质量因子；构造模型有意义的质量因子类型是什么？模型的结构如何；品质因数之间可以存在什么样的关系；如何评估品质因数？以下是质量模型类型的分类，最常用的质量模型标准建议书以及不同建议书的属性之间的描述和比较（Carvallo等，Nd）。
根据评估方法将软件质量模型分类为过程，产品或使用的质量级别（Callejas等，2017），在此阶段可以方便地阐明每个软件的范围焦点。
从过程级别的质量角度来看，必须从项目开始就进行计划和评估，然后在软件开发过程的每个阶段都必须对相关方面进行控制和监视。为了最大程度地降低风险并提供持续支持，以确保达到最佳质量水平（预先设定），并考虑到以下因素，确保施工过程的执行质量：在这些阶段中，因素和标准的验证被搁置了，其中一些可能存在缺陷，因此过程的质量将下降，并且可能还会开发产品（Callejas等人，2017） 。
Cuando la calidad es medida a nivel de producto, el objetivo principal es evaluar el cumplimiento de criterios previamente especificados para el mismo. Este enfoque está orientado a verificar el cumplimiento de las características que permitan alcanzar la satisfacción del cliente en cuanto a los requisitos definidos en las etapas iniciales del proceso de desarrollo de software (Callejas et al ., 2017).
Finalmente, sobre la calidad en el uso, es importante resaltar que aunque en diferentes escenarios se utilizan los términos de usabilidad y calidad en uso con el mismo propósito y de forma intercambiable, tienen significados distintos, debido principalmente a que el concepto de calidad en uso es mucho más amplio y abarca más elementos que la usabilidad y ésta última es una de las características de calidad de un producto de software. La calidad en uso se define como el conjunto de atributos relacionados con la aceptación por parte del usuario final y está basada en la eficacia, productividad, seguridad y satisfacción de acuerdo a las pautas de ISO/IEC 9126 (Callejas et al ., 2017).
Sobre el aseguramiento de la calidad del software, esta es una actividad de la ingeniería de software que se aplica en cada etapa del proceso de desarrollo de software de forma transversal y en paralelo al resto de las actividades. El aseguramiento de la calidad incluye procedimientos para la aplicación eficaz de métodos y herramientas, supervisa las actividades de control de calidad, tales como las revisiones técnicas y las pruebas de software, procedimientos para la administración y control del cambio y procedimientos para asegurar el cumplimiento de las normas y mecanismos de medición y elaboración de reportes. (Pressman, 2010).
Para llevar a cabo el aseguramiento de la calidad de software de manera adecuada, deben recabarse, evaluarse y divulgarse datos sobre el proceso de la ingeniería de software, los métodos estadísticos aplicados al aseguramiento de la calidad de software ayudan a mejorar la calidad del producto y del proceso de software mismo. Los modelos de confiabilidad de software amplían las mediciones, lo que permite que los datos obtenidos acerca de los defectos se extrapolen hacia las tasas de falla proyectadas y hacia la elaboración de pronósticos de confiabilidad. (Pressman, 2010).
En cuanto a los modelos a nivel de proceso, Callejas et al., (2017) realizó una revisión cronológica de algunos modelos a nivel de procesos de desarrollo de software obteniendo como resultado los siguientes:
- ITIL (año 1989): desarrollado en el Reino Unido, con el fin de fortalecer la gestión gubernamental, a partir de cinco (5) elementos fundamentales: la perspectiva del negocio, entrega del servicio, soporte del servicio, manejo de la infraestructura y manejo de aplicaciones, con el propósito de ofrecer una estructura integral para prestar a la organización un servicio completo, cubriendo necesidades de apoyo de instalación, adecuación de redes, comunicaciones, hardware, servidores, sistema operativo, y software necesarios.ISO/IEC 15504: permite adaptar la evaluación para procesos en pequeñas y medianas empresas (pymes) y grupos de desarrollo pequeños, mediante la estructuración en seis niveles de madurez: nivel 0: organización inmadura, nivel 1: organización básica, nivel 2: organización gestionada, nivel 3: organización establecida, nivel 4: organización predecible y nivel 5: organización optimizando. Su objetivo es llegar a que la organización logre ser madura, lo cual conlleva a que la organización tenga procesos definidos, responsabilidades definidas, predicción de resultados, productos entregados con calidad, que las entregas se den en los tiempos pactados, incrementar la productividad, clientes satisfechos y empleados felices. Esta norma, denominada “tecnologías de información: proceso de evaluación”, está constituida por cinco (5) partes. La segunda parte guía la evaluación del proceso y la aplicación del proceso de evaluación para el mejoramiento y determinación de la capacidad, precisa los requisitos mínimos para realizar una evaluación que asegure un nivel de consistencia y capacidad de repetición y que los resultados de la evaluación sean objetivos, imparciales, repetibles, consistentes y representativos. Identifica el marco de trabajo de medida para la capacidad del proceso y los requisitos para el modelo de procesos de referencia, el modelo de evaluación de procesos y la verificación de la conformidad del proceso de evaluación. El modelo del proceso de evaluación contiene una dimensión del proceso y una dimensión de la capacidad del proceso (Pino et al ., 2005).Dromey (año 1995): la finalidad de este modelo es evaluar varias etapas del proceso de desarrollo como: levantamiento de requisitos, diseño e implementación. Se estructura con características y subcaracterísticas de calidad; propone tres modelos distintos para cada etapa de construcción del producto: modelo de requerimientos, modelo de diseño y modelo de calidad de la implementación, a partir de la evaluación establecida en cinco etapas, para características como: eficiencia, confiabilidad, mantenibilidad, portabilidad, facilidad de uso y funcionalidad (Scalone, 2006). Personal Software Process (PSP por sus siglas en inglés): este modelo propuesto en el año 1995 está enfocado al desarrollo profesional del ingeniero, fomentando una adecuada administración de calidad de los proyectos de desarrollo, reducción de defectos del producto, estimación y planeación del trabajo (Vargas, 2010). Team Software Process (TSP) (año 1996): TSP por sus siglas en inglés,es la fase posterior de PSP, está diseñado para el trabajo de equipos de desarrollo de software autodirigidos, que se orienta al desarrollo de producto con el mínimo de defectos en tiempo y costos estimados. Cuenta con planes detallados y procesos como revisiones personales, inspecciones e índices de desempeño de calidad y el fomento de la integración del equipo (Mondragón, 2011). El PSP y el TSP incluyen reconocidas técnicas para el asentamiento de una base de información útil en la obtención de indicadores, pero aún así requieren de mucho trabajo por parte del ingeniero para lograr llevar a cabo el control necesario de sí mismo y del equipo respectivamente (Lugo et al , 2009).IEEE / EIA 12207 (año 1996): establece un marco común para los procesos del ciclo de vida del software, con una terminología bien definida, que puede ser referenciada por la industria del software. Está conformada por procesos, actividades y tareas que se aplican en la adquisición de sistemas y productos de software y servicios, para el suministro, desarrollo, operación, mantenimiento y eliminación de los productos de software y la parte de software de un sistema, ya sea realizado internamente o externamente a una organización. La IEEE 12207 proporciona procesos para definir, mejorar y controlar los procesos del ciclo de vida del software. El marco descrito por el estándar está diseñado para ser adaptado a toda organización y proyecto (IEEE SA-12207, 2008). El estándar aplica los principios relacionados con la gestión total, este estándar trata todas las actividades incluidas las relacionadas con la calidad, como parte integral del ciclo de vida del software, Estas actividades afines con la calidad son asignadas a cada proceso. Cada proceso está equipado con un plan “do check-act” (PDCA), por lo tanto a cada proceso y al personal encargado de llevarlo a cabo se le asignan sus actividades y procesos relacionados con la calidad incluyendo las evaluaciones (Gaibor, 2015).Cobit 4.0 (año 1996): se caracteriza por ser orientado a negocios y procesos, además de ser basado en controles, trabaja con siete criterios de información que son definidos como requerimientos de control del negocio: efectividad, eficiencia, confidencialidad, integridad, disponibilidad, cumplimiento y confiabilidad (IT Governance Institute, 2005).CMMI ( Capability Maturity Model Integration por sus siglas en inglés, año 2000): es de los modelos más utilizados en las empresas de construcción de software, con el propósito de verificar el cumplimiento de estándares de calidad a partir de la medición con niveles de madurez. Este modelo se representa de dos maneras: escalonada y continua, donde el modelo escalonado está dirigido al software y permite clasificar las organizaciones en cinco tipos de nivel establecidos: inicial, gestionado, definido, gestionado cuantitativamente y en optimización. Por su parte el modelo continuo se enfoca al análisis de la capacidad de cada proceso inmerso en las áreas de la ingeniería de sistemas y lo clasifica en uno de los siguientes seis niveles: nivel 0: incompleto: nivel 1: ejecutado, nivel 2: gestionado, nivel 3: definido, nivel 4: cuantitativamente gestionado y nivel 5: en optimización (Petrie et al 2009).ISO/IEC 20000-1:2005 (año 2005): el objetivo principal de esta norma es el de avalar que la prestación de servicios gestionados de tecnologías de información de una empresa cuentan con la calidad necesaria para brindar dichos servicios a los clientes. Se subdivide en dos partes: “Especificaciones“, publicada como ISO 20000- 1:2005 y “Código de buenas prácticas” publicada como ISO 20000-2:2005, promueve la adopción de un enfoque de procesos integrados, para una provisión eficaz de servicios gestionados que satisfaga los requisitos del negocio y de los clientes. Con la intención de desarrollar una guía para la aplicación de la norma ISO 9001 a la gestión de servicios de tecnologías de información, ISO inició en 2008 un nuevo proyecto denominado ISO/IEC NP 90006 (Mesquida et al , 2010). De igual manera Callejas et al (2017) y Fuertes (2002) realizaron en distintos trabajos revisiones cronológicas de algunos modelos a nivel de productos empleados para la evaluación del software desde esta perspectiva.McCall (año 1977): uno de los más renombrados predecesores de los modelos de calidad actuales es el modelo McCall, que fue presentado por
Jim McCall en 1977. Este modelo se basa en tres perspectivas generales que son utilizadas para definir e identificar la calidad de un producto de software: revisión del producto, transición del producto y operación del producto. Los once criterios base, son: exactitud, confiabilidad, eficiencia, integridad, usabilidad, mantenibilidad, testeabilidad , flexibilidad, portabilidad, reusabilidad e interoperabilidad (Córdoba et al , sf).
- Modelo de Arthur (año 1985): L. J. Arthur presentó una pequeña variación al modelo de McCall consistente en añadir tres nuevos criterios, así como en modificar las relaciones existentes entre éstos y factores. Los nuevos criterios son: auditabilidad, complejidad y seguridad (Fuertes, 2002).GQM o Goal Question Metric, por sus siglas en inglés (año 1984): modelo cuyo objetivo es el de de evaluar distintos atributos de calidad del producto, partiendo de los objetivos y las preguntas respecto a qué hace una organización para mejorar y en base a esto se establecen las métricas correspondientes (Lugo et al , 2009).Boehm (año 1986): el modelo McCall sirvió de base para el modelo de calidad Boehm, otro predecesor de los modelos de calidad actuales, creado por Barry W. Boehm. Este modelo fue el primero en proponer la evaluación de la calidad del software por medio de métodos automáticos y cuantitativos, es un modelo incremental, dividido en regiones de tareas y estas a su vez en conjuntos de tareas, las cuales se ajustan a la cantidad de iteraciones que el equipo defina, y cada iteración se divide en cuatro sectores: planeación, análisis de riesgo, ingeniería y evaluación. (Córdoba et al , sf).FURPS (año 1987): posteriormente Robert Grady, en 1987, creó el modelo FURPS, no tan conocido como los mencionados anteriormente pero basado en los mismos principios. Su principal aportación es que divide los factores principales de evaluación en dos grupos: los basados en requerimientos funcionales y los basados en requerimientos no funcionales (Córdoba et al , sf).GILB (año 1988): T. Gilb definió una jerarquía de los atributos de un sistema que para él resultaban habitualmente interesantes en el campo de la ingeniería del software. Gilb llamaba atributo a una medida de la calidad de un sistema. Dicha medida podía variar entre ciertos límites, siendo aún el sistema aceptable para el usuario. El objetivo fundamental del ingeniero de software sería identificar los atributos críticos y los límites de cada atributo entre los cuales el sistema sigue siendo aceptable. Estos atributos se aplican a la lógica, a los datos, a la documentación, a la interfaz y demás aspectos del software. Los atributos del modelo son: capacidad de trabajo, adaptabilidad, disponibilidad y utilizabilidad, cada uno de los cuales se divide, a su vez, en sub atributos (Fuertes, 2002).Modelo de Deutsch y Willis (año 1988): publicaron una jerarquía similar a la de McCall, aunque incluía nuevos factores y criterios, así como nuevas relaciones entre éstos. La jerarquía parte de que las necesidades del usuario pueden descomponerse en necesidades operacionales y de mantenimiento. Las necesidades operacionales tienen que ver con la capacidad del software para llevar a cabo las tareas que se supone que debe realizar. Las necesidades de mantenimiento tienen relación con la modificación del software, con el fin de ayudar al usuario. Dentro de las necesidades operacionales, la funcionalidad trata de lo que hace el software al ejecutarse, mientras que la realización trata de lo bien que lo hace. En cuanto a las necesidades de mantenimiento, el cambio trata de las modificaciones del software para corregir errores, adaptarse a nuevos entornos o añadir nuevas funcionalidades, mientras que la gestión tiene que ver con la planificación para cambiar, controlar versiones, pruebas e instalación (Fuertes, 2002).Modelo de Schulmeyer (año 1991): Schulmeyer publicó una serie de indicadores de la calidad del software. Estos indicadores de la calidad no deben ser interpretados como medidas, sino que sirven de base para dichas medidas. Los indicadores serían de ayuda pues podrían dar una idea de la tendencia de la calidad (adecuación a requisitos) en el desarrollo del software. Los indicadores son: completitud de las pruebas, completitud, densidad de defectos, densidad de fallos, documentación, estructura del diseño: se utiliza para determinar la simplicidad o claridad del diseño, suficiencia de las pruebas. Schulmeyer se sale de la línea habitual y descompone la calidad en un único nivel de unos pocos indicadores, que pueden emplearse para evaluar la calidad del desarrollo, basándose en los paradigmas tradicionales (Fuertes, 2002).IEEE 1061 (año 1998): tiene como objetivo la definición de métricas de software y su uso en la evaluación de componentes software. Fue aprobado en 1992 y revisado y modificado en 1998. Propone la construcción de modelos de calidad a medida adaptados a cada proyecto. No fija ningún factor de calidad, pero sí una clasificación de los factores de los que debe constar un modelo en un nivel más alto y abstracto de factores, que deben descomponerse en subfactores, que a su vez se descomponen en métricas.ISO/IEC 9126: tiene como objetivo la definición de un modelo de calidad y su uso como marco para la evaluación de software. Los modelos de calidad concordantes con este estándar pertenecen a la categoría de modelos mixtos, ya que el estándar propone una jerarquía de factores de calidad clasificados como características, subcaracterísticas y atributos según su grado de abstracción, entre los que se propone un conjunto de factores de partida compuestos de seis (6) características y veintisiete (27) subcaracterísticas. El estándar distingue entre calidad interna y calidad externa, e introduce también el concepto de calidad en uso. La calidad interna tiene como objetivo medir la calidad del software mediante factores medibles durante su desarrollo. La calidad externa pretende medir la calidad del software teniendo en cuenta el comportamiento de este software en un sistema del cual forme parte. Finalmente, la calidad en uso corresponde a la calidad del software desde el punto de vista de un usuario.
El ISO/IEC 9126 original fue sustituido en 2001 por dos estándares relacionados, el ISO/IEC 9126 de calidad del software y el ISO/IEC 14598 de evaluación de productos software. La versión de 2001 del ISO/IEC 9126 consta de cuatro partes: 9126-1 (2001), presenta un modelo de calidad, que es común para medir la calidad interna y externa, y uno distinto para medir la calidad en uso; 9126-2 (2003), presenta posibles métricas externas para atributos de calidad externos; 9126-3 (2003), presenta posibles métricas para atributos de calidad internos; y 9126-4 (2004), presenta posibles métricas para evaluar atributos de calidad en uso. Cabe destacar que en este cambio, las sub características mencionadas anteriormente pasaron de ser recomendadas en un anexo, a formar parte del estándar (Carvallo et al , sf). Sólo la primera parte de la norma ISO 9126-1 (2001) es un estándar aprobado y publicado, siendo los restantes informes que componen la parte identificada como Reportes Técnicos ( Technical Report TR ). A continuación se definen las características descritas en la ISO/IEC 9126 (2001):
○ Usabilidad: capacidad del producto software de ser entendido, aprendido y usado por los usuarios bajo condiciones específicas.
○ Funcionalidad: capacidad del producto software de proporcionar funciones que ejecuten las necesidades explícitas e implícitas de los usuarios cuando el software es usado bajo condiciones específicas.
○ Confiabilidad: capacidad del producto software de mantener un nivel especificado de rendimiento cuando es usado bajo condiciones específicas.
○ Eficiencia: representa la relación entre el grado de rendimiento del sitio y la cantidad de recursos (tiempo, espacio, entre otros) usados bajo ciertas condiciones.
○ Mantenimiento: capacidad del producto software de ser modificado y probado.
○ Portabilidad: capacidad del producto software de ser transferido de un ambiente a otro. (Alfonzo y Mariño, 2013).
- Modelo de Gillies (año 1992): A. C. Gillies presentó su modelo de calidad que se diferenciaba de otros trabajos previos en el sentido de que consideraba todos los criterios como un subconjunto de corrección, dividiéndola en corrección funcional y empresarial. Esto requería la incorporación de nuevos criterios asociados con la corrección desde el punto de vista de los negocios. Según el autor, este modo de ver el modelo le permitiría reflejar tanto el punto de vista de calidad del diseñador como el del usuario (Fuertes, 2002).Modelo REBOOT: surge del proyecto ESPRIT, está basado en la división habitual de la calidad en factores, criterios y métricas, así como en las relaciones entre sí representadas mediante una jerarquía. (Fuertes 2002).WebQEM (año 1998): es una metodología de evaluación de calidad de sitios web ( Web-site Quality Evaluation Method por sus siglas en inglés), diseñada para la evaluación siguiendo seis fases: planificación y programación de la evaluación de calidad¸ definición y especificación de requerimientos de calidad, definición e implementación de la evaluación elemental¸ definición e implementación de la evaluación global¸ análisis de resultados, conclusión y documentación¸ validación de métricas. Entre las actividades que plantea la metodología WebQEM, se encuentra el diseño de indicadores parciales/globales para obtener el grado de cumplimiento global de las características de alto nivel que se estén evaluando. Para realizar esto, WebQEM utiliza el método Logic Scoring of Preference (LSP por sus siglas en inglés), el cual es un método cuantitativo basado en técnicas de puntuación y lógica continua de preferencias. Básicamente, LSP permite establecer criterios de evaluación, especificando las propiedades esperadas de un sistema. En este punto, todos los valores de los indicadores elementales pueden agruparse adecuadamente diseñando una estructura de agregación por niveles, que permite obtener una preferencia (valor de indicador global/parcial) de acuerdo a las necesidades del usuario y el punto de vista de la evaluación. (Gallardo et al ., sf).Estándar ISO/IEC 25000:2005 (año 2005): su propósito es guiar el desarrollo con los requisitos y la evaluación de atributos de calidad, teniendo como referencia la adecuación funcional, la eficiencia de desempeño, la compatibilidad, la capacidad de uso, la fiabilidad, la seguridad, la mantenibilidad y la portabilidad. Los aspectos más importantes en el desarrollo de software bajo este enfoque son la calidad del producto y del proceso. ISO/IEC 25000, proporciona una guía para el uso de las nuevas series de estándares internacionales, llamados Requisitos y Evaluación de Calidad de Productos de Software (SQuaRE). Constituyen una serie de normas basadas en la ISO 9126 y en la ISO 14598 y su objetivo principal es guiar el desarrollo de los productos de software con la especificación y evaluación de requisitos de calidad (Portal ISO 25000).
La familia ISO 25000 está orientada al producto software, permitiendo definir el modelo de calidad y el proceso a seguir para evaluar dicho producto. La familia de normas SQuaRE está compuesta por cinco (5) divisiones: ISO 2500n: Gestión de la calidad, ISO 2501n: Modelo de calidad, ISO 2502n: Medida de la calidad, ISO 2503n: Requisitos de calidad e ISO 2504n: Evaluación de la calidad. El estándar ISO/IEC 25000 (2005), contiene una explicación sobre el proceso de transición entre el estándar ISO/IEC 9126, las series 14598 y SQuaRE. También presenta información sobre cómo utilizar la norma ISO/IEC 9126 y la serie 14598 en su forma anterior. Ofrece términos y definiciones, modelos referencia, guía general, guías de división individual y los estándares para fines de especificación, planificación y gestión, medición y evaluación. (Alfonzo y Mariño, 2013).
- El estándar ISO/IEC 25010:2011: reemplaza y actualiza el estándar ISO
9126-1 (2001). Define un modelo de calidad en uso que se compone de cinco (5) características (algunas de las cuales se subdividen en subcaracterísticas). Se relacionan con el resultado de la interacción cuando un producto se emplea en un contexto particular de uso. Un modelo de calidad del producto que se compone de ocho (8) características (que se subdividen en subcaracterísticas). Se refieren a propiedades estáticas de software y las propiedades dinámicas del sistema informático. El modelo es aplicable a los productos de software y sistemas informáticos. Las características definidas por ambos modelos son relevantes para todos los productos de software y sistemas informáticos. Las características y subcaracterísticas proporcionan coherencia terminológica para especificar, medir y evaluar la calidad del producto software y sistemas informáticos. El modelo de calidad de producto abarca cualidades internas y externas del sistema y está compuesto por ocho (8) características y treinta y un (31) subcaracterísticas.
Algunos modelos de calidad clásicos han sido la base para los más recientes y han permitido que los modelos actuales se consolidan como los más completos con base en la evolución del software, para así optimizar los procesos de las organizaciones y garantizar que se cumple con criterios o estándares que respaldan la calidad de la gestión de procesos del negocio. (Callejas et al ., 2017).
Es importante que las empresas cuyo objeto o razón de ser sea el desarrollo de software, se certifiquen bajo alguna norma o estándar, el que mejor se adapte a sus características y objetivos organizacionales, ya que esto permite que la misma tenga una mejor posición, reconocimiento y demanda en el mercado, al estar avalada por alguna entidad competente se garantiza un nivel de satisfacción mayor para los clientes y mejora su competitividad a nivel internacional.
Referencias bibliográficas
- Alfonzo, P., Mariño, S., (2013). Los estándares internacionales y su importancia para la industria del software . Consultado el: 26/06/2018. Disponible en: http://www.cyta.com.ar/ta1202/v12n2a3.htm.Callejas, M., Alarcón, A., Álvarez, A. Modelos de calidad del software, un estado del arte . En: Entramado. Enero – Junio, 2017. vol. 13, no. 1, p. 236-250, Consultado el: 26/06/2018. Disponible en: http://revistasojs.unilibrecali.edu.co/index.php/entramado/article/view/525.Carvallo, J., Franch, X., Quer, C. (sf). Calidad de componentes de software . Consultado el: 28/06/2018. Disponible en: http://www.essi.upc.edu/~franch/papers/libro-calidad-cap-10-jpc-xf-cq-10-versi on-preliminar.pdf.Collier, D., Evans, J., (2009). Administración de operaciones. Bienes,Servicios y Cadenas de Valor. Segunda edición. CENGAGE Learning. México.Córdoba, J., Cachero, C., Calero, C., Marhuenda, Y., (sf). Modelo de calidad para portales bancarios. Consultado el: 28/06/2018. Disponible en: https://www.researchgate.net/profile/Julio_Cordoba_Retana/publication/228869245_Modelo_de_Calidad_para_Portales_Bancarios/links/545aefd00cf25c508c31a2e1.pdfFuertes, J., (2002). Modelo de calidad para el software orientado por objetos . Tesis doctoral. Universidad Politécnica de Madrid. Consultado el: 28/06/2018. Disponible en: http://oa.upm.es/34988/1/TD_Fuertes_JOSE_LUIS.pdf.Gaibor, J,.(2015). Determinación del cumplimiento de las metodologías SCRUM y XP con relación al estándar IEEE-12207 aplicado al sistema de control de proveeduría en la cacech . Tesis de grado. Consultado el: 28/06/2018. Disponible en:http://dspace.espoch.edu.ec/handle/123456789/4339.Gallardo, C., Funes, A., Ahumada, H., (sf). Modelo integral para la evaluación de la calidad de la accesibilidad al contenido web . Consultado el: 28/06/2018. Disponible en: http://sedici.unlp.edu.ar/bitstream/handle/10915/54094/Documento_completo.pdf-PDFA.pdf?sequence=1.IT Governance Institute (2006). Cobit 4.0. Consultado el: 28/06/2018. Disponible en: https://www.gob.mx/cms/uploads/attachment/file/82967/CobiT4_Espanol.pdfLugo, J., García A., Delgado R,. (2009). Gestión de indicadores en proyectos de software. Perspectivas actuales y futuras . Revista Cubana de Ciencias Informáticas 3 (Julio-Diciembre). Consultado el: 28 de junio de 2018. Disponible en: http://www.redalyc.org/articulo.oa?id=378343637002.Mesquida, A., Mas, A., Esperança, C. (2010). Sistema de Gestión Integrado según las Normas ISO 9001, ISO/IEC 20000 e ISO/IEC 27001 . REICIS. Revista Española de Innovación, Calidad e Ingeniería del Software. 6 (Noviembre-Sin mes). Consultado el: 28/06/2018. Disponible en: http://www.redalyc.org/articulo.oa?id=92218768002.Mondragón, O,. (2011). Integrando TSP y CMMI: Lo mejor de dos mundos. Consultado el: 28/06/2018. Disponible en: https://sg.com.mx/revista/31/integrando-tsp-cmmi.Pino, F. J., García, F., Ruiz, F., Piattini, M. (2005). Adaptación de las Normas ISO/IEC 12207: 2002 e ISO/IEC 15504: 2003 para la evaluación de la madurez de procesos software en países en desarrollo . In JISBD (pp. 187-194). Consultado el: 28/06/2018. Disponible en: https://www.gestiopolis.com/la-calidad-vista-desde-la-ingenieria-de-software/?preview_id=345852&preview_nonce=cf2e3652ba&post_format=standard&_thumbnail_id=345854&preview=truePressman, R., (2010). Ingeniería de software. Un enfoque práctico . Séptima edición. Mc Graw Hill.Petrie, M., Medina, V., Méndez., G., (2009). Modelo de Registro y Acreditación de Instituciones de Educación Superior basado en el Modelo CMMI . In Seventh LACCEI Latin American and Caribbean Conference for Engineering and Technology. Consultado el: 28/06/2018. Disponible en:http://laccei.org/LACCEI2009-Venezuela/Papers/Acc116_LarrondoPetrie.p dfScalone, F. (2006). Estudio comparativo de los modelos y estándares de calidad del software. Tesis Ingeniería de Calidad. Buenos Aires: Universidad Tecnológica Nacional Regional de Buenos Aires.. 488 p. Consultado el: 28/06/2018. disponible en:http://laboratorios.fi.uba.ar/lsi/scalone-tesis-maestria-ingenieria-en-calidad.PDF.Schroeder, R., Meyer, S., Rungtusanatham, J. (2011). Administración de operaciones. Conceptos y casos contemporáneos . Quinta edición. Mc Graw Hill.Souri, A., (2016). Implantación y gestión de la Norma ISO 9001:2015. Una guía paso a paso para implantar y mantener cada requisito de la Norma ISO 9001:2015 . Editorial Melvin C.A. Venezuela.Vargas, F., Soto, D. “ Introduciendo PSP (Personal Software Process) en el aula” . En: Revista Colombiana de Tecnologías de Avanzada. 2010. vol. 2, no. 16. Consultado el: 28/06/2018. Disponible en:http://www.unipamplona.edu.co/unipamplona/portalIG/home_10/recursos/g eneral/pag_contenido/publicaciones/revista_tec_avanzada/2010/numero2/09 112010/rcta_16.pdfVelazco，A.（2016年）。螺旋图案。简介Boehm。检索2018-07-28。可在以下网址获得：https：//www.academia.edu
