Software engineering as a discipline in charge of the development and construction of software products and the provision of associated services does not escape the demands of quality, in this sense, standards have been developed in order to attend to what is related to the way in which the that the product is built and elaborated or the service is provided, as well as the quality of the product and the perception that customers and end users have.
This article makes a brief historical account of the importance of quality since ancient times and how its influence directly impacted the recent software development industry, where a series of standards and methodologies specific to the fact of software have emerged and evolved with the purpose of guaranteeing its quality. A compilation of different standards considered as the most influential was made according to the criteria of several authors as well as their main characteristics based on both the quality of the software development process and its quality and use.
Keywords: quality , quality assurance, software quality, software engineering, processes, product.
The quality and the software engineering Abstract
The quality has been present since antiquity, where the ancient Egyptians showed samples of inspections and inspections with high precision, going through the Second World War, where they began to train more strongly on the issue of quality, until today, where The different techniques and methodologies developed over time have evolved significantly, allowing positive contributions in current organizations.
Software engineering as a discipline responsible for the development and construction of software products and provision of associated services does not escape the requirements of quality, in this sense standards have been developed with the purpose of addressing the related to the way in which that the product is built and elaborated or the service is provided as well as the quality of the product and the perception that customers and end users have of it.
This article gives a brief historical account of the importance of quality since ancient times and how its influence directly impacted the recent software development industry, where a series of standards and methodologies specific to the fact of software have arisen and evolved. purpose of guaranteeing the quality of it. A compilation of different standards considered as the most influential according to the criterion of several authors as well as their main characteristics based on the quality of the software development process as well as the quality and use of the same.
Keywords: quality, quality assurance, software quality, software engineering, processes, product.
Quality seen from software engineering
Quality is one of the four fundamental objectives of operations, along with cost, flexibility and delivery, even when quality management is cross-functional and involves the entire organization, the operations area has a responsibility special regarding the elaboration of a quality product for the client. This requires the cooperation of the entire organization and careful attention from management and quality control.
(Schroeder et al., 2011).
Quality assurance is generally associated with some form of measurement and inspection, which are two fundamental issues in quality management and have been important aspects of production operations throughout history (Colliers and Evans, 2009). From the Egyptian wall paintings of around 1,450 BC, which show measurement and inspection, through the stones of the pyramids, which were cut exactly, to mention just two examples from antiquity. The success of the Egyptians was due to the constant use of well-developed methods and procedures and precise measuring devices (Colliers and Evans, 2009).
Later, during the industrial revolution, the use of interchangeable parts and the division of labor into smaller tasks, required meticulous quality control, which led to a reliance on inspection to identify and eliminate defects. Over time, organizations created separate quality departments; this artificial separation of production workers from responsibility for quality assurance led to a disregard for quality on the part of workers as well as managers (Colliers and Evans, 2009).
The Second World War constituted a new milestone for the evolution of quality assurance, many specialists were trained in the use of statistical tools, becoming the statistical quality control well known and little by little adopted in all manufacturing industries. However, as top management had delegated so much responsibility for quality to others, they had little knowledge of it, and when the quality crisis came a few years later, they were ill-prepared to deal with it (Colliers and Evans, 2009).
During this period Joseph Juran and W. Edwards Deming, two American consultants, presented statistical control techniques to the Japanese to aid them in their reconstruction efforts. A significant part of its educational activity was concentrated in senior management, rather than independent quality specialists. With the support of senior managers, the Japanese integrated quality into all their organizations and developed a culture of continuous improvement (Colliers and Evans, 2009).
The improvements in Japanese quality were slow and steady; It took about 20 years before the quality of Japanese products exceeded that of Western manufacturers, by the 1970s, mainly due to the superior quality levels of their products, Japanese companies had had considerable penetration in the markets. The reaction of most US companies was to initiate detailed quality improvement campaigns, focused not only on compliance but also on improving design quality (Colliers and Evans, 2009).
As organizations began to integrate quality principles into their management systems, the notion of total quality management became popular. Total quality represented an interest throughout the value chain rather than just during production operations and the involvement of every person and function in the organization. Quality acquired a new meaning of excellence in the performance of the entire organization, rather than an engineering-based technical discipline (Colliers and Evans, 2009).
In recent years, a new interest in quality emerged in corporate boardrooms under the concept of Six Sigma, a customer-centric, results-oriented approach to improving business. Six Sigma integrates quality tools and techniques that have been tested and validated over the years, with essential guidance that has great appeal to management. (Colliers and Evans, 2009).
Currently, a large number of techniques and methodologies have emerged in order to find and maintain the much appreciated quality, which is why, in most organizations, regardless of their orientation (manufacturing or services), different systems are constituted management that give life. Within these systems are the quality management system, the financial management system, the environmental management system, the safety management system and others, each of these systems is a pillar within the organization and the Failure of one of them could cause the total failure of the organization, in this sense, the quality management system is a part of the organization that acts towards customer satisfaction, by improving the quality of the organization,including the improvement of its core processes, products and services (Souri, 2016).
Core processes are those directly related to the purpose or mission, that is, those that were originally thought as necessary processes to fulfill the organization's reason for being, in the same way it applies when the provision of services is the reason for being of entity, in which case, the core process will be formed by all the activities related to the provision of that service (Souri, 2016).
When talking about the quality of services, it is pertinent to make certain distinctions since the definition and measurement is entirely different from those of the quality of manufacturing. Service quality involves dimensions consisting of shipped product, tangible service (explicit), and psychological service (implicit), although the quality of the product offered can be measured using the dimensions of manufacturing, tangible services, and psychological require different measurements. Manufacturing measurements can be highly objective while many service measurements are perceptual or subjective. The quality of compliance can be calculated through the cost of scrap and factory rework (Schroeder et al., 2011).
It is important to know how the concepts associated with quality apply in the growing software industry and in the process for its construction or development. Currently, software has a dual role, since it is a product and at the same time it is the channel to deliver a product, through the provision of a service. In its form it is a product, which provides the computing potential incorporated in the computing hardware or more widely in a computer network accessed through local hardware, whether it resides in a mobile phone or operates inside a central computer or server, the software is an information transformer: it produces, manages, acquires, modifies,displays or transmits information that can be as simple as a single bit or as complex as a multimedia presentation generated from data obtained from dozens of independent sources. For this reason, the huge software industry has become a dominant factor in the economies of the industrialized world (Pressman, 2010).
Although hundreds of authors have developed personal definitions about software engineering, the proposal by Fritz Bauer serves as the basis for the analysis, indicating that software engineering is the establishment and use of fundamental principles of engineering in order to develop in a way cost-effective, reliable and efficient software products.
Software engineering is also the application of a systematic, disciplined and quantifiable approach to the development, operation and maintenance of software, that is, the application of engineering to software is a multi-layered technology, any engineering approach, even that of Software must be based on an organizational commitment to quality. Total quality management, Six Sigma, and other similar philosophies fuel the culture of continuous improvement, and it is this culture that ultimately leads to the development of increasingly effective approaches to software engineering. The foundation on which software engineering rests is a commitment to quality. (Pressman, 2010).
Over time, several dimensions and factors of software quality have been proposed, all of them try to define a set of characteristics that, if achieved, will allow the development of high-quality software, some standards establish characteristics such as reliability, usability, maintenance, functionality and portability, as indicators of the existence of quality.
(Pressman, 2010).
Every organization faces the dilemma of software quality. In essence, everyone wants to build high-quality systems, but in a market-driven world, you simply don't have the time and effort required to produce “perfect” software (Pressman, 2010). Regardless of the approach chosen, quality comes at a cost that can be studied in terms of prevention, evaluation and failure. Prevention costs include all actions of software engineering designed to prevent defects. Evaluation costs are associated with those actions that evaluate software work products for quality. Failure costs include the internal price of failure and the external effects that precipitate poor quality (Pressman, 2010).
According to the ISO 8402 (1986) standard, a quality model can be defined as the set of quality factors and the relationships between them, which provides a basis for the specification of quality requirements and for the evaluation of the quality of software components..
Quality models are generally structured as a hierarchy (either a tree or a directed graph), where more generic quality factors, such as efficiency or usability, are broken down into more particular ones, such as response time or ease of learning, probably at various levels of decomposition. Software quality models can be applied in various particular activities: establishing the quality requirements for the selection of a component based on the quality factors of the model, evaluating the quality of a component for each of the quality factors of the model, compare the quality of different components with respect to the requirements established for a selection process and draft formal contracts,where the quality evaluations of the components that the supplier certifies appear explicitly. Normally, the quality factors that appear in the model can be used as a checklist for all those questions related to the quality of the components.
Since the quality model concept was formulated, multiple proposals have been made. Said proposals try to solve, among others, the following questions: What are the quality factors that should be part of a software component quality model? What are the types of quality factors in which it makes sense to structure the models? How are the models structured? What kind of relationships can exist between quality factors? How are quality factors evaluated? Below is a classification of the types of quality models, the most commonly used quality model standard proposals and a description and comparison between the properties of the different proposals (Carvallo et al., Nd).
The software quality models are classified according to the evaluation approach, either at the level of processes, product or quality in use, (Callejas et al., 2017) at this stage it is convenient to make a clarification regarding the scope of each focus.
From the point of view of quality at the process level, it must be planned and estimated from the beginning of the project and subsequently, at each stage of the software development process, control and monitoring of the associated aspects must be carried out. quality in the execution of the processes for its construction, in order to minimize risks and offer continuous support, guaranteeing an optimal level of compliance with the quality factors (pre-established), taking into account that if in any of the In the stages, the verification of the factors and criteria is left aside, it is possible that there is a deficiency in some of these and therefore the quality of the process will decrease and probably the product under development as well (Callejas et al., 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). Spiral pattern. Introduction Boehm. Retrieved 2018-07-28. Available at:
