Currently, the information technology (IT) industry is developing at a fairly rapid pace. IT is increasingly being used in a variety of industries, from the catering sector (delivery of food, groceries, etc.) to the aerospace industry. At the same time, new technologies and tools appear, the number of software end users increases, requirements increase, etc. To reduce the influence of these factors on the product, it is necessary to ensure the necessary quality in software products. How to determine the “necessary” quality? Quality models have been proposed to define and measure the required quality of a software product. For example, the article [1] discusses the following models:
Currently, the use of quality models in the creation of software products is a fairly relevant topic. In this essay, we will look at the main well-known quality models and try to speculate on how they can be implemented in modern software development processes.
The source [2] gives the following definition of the Quality Model:
Quality Model is a model with the objective to describe, assess and/or predict quality.
Let's briefly consider the main quality models:
McCall's model categorizes software quality into three dimensions: product operation, which assesses aspects like correctness, reliability, efficiency, integrity, and usability; product revision, which considers maintainability, flexibility, and testability; and product transition, which evaluates portability, reusability, and interoperability. Source [3] notes that this model does not explicit account for aspects like analyzability or architectural integrity. However, as the model moves deeper into its hierarchy of factors, criteria, and metrics, some of these measurable properties, such as simplicity and modularity, are indirectly related to analyzability. However, architectural integrity in the model remains unaddressed.
Boehm’s model goals to outline software program high-quality by means of the use of predefined attributes and metrics. It's organized hierarchically, with high-level characteristics, like general utility, representing fundamental requirements. These characteristics are in addition broken down into factors, which consist of various criteria. The factors consist of portability, utility (subdivided into reliability, efficiency, and human engineering), and maintainability (subdivided into testability, understandability, and modifiability).
Dromey's Model presents a framework for evaluating the Requirement determination, design, and implementation phases, comprising three models: Requirement quality, Design quality, and Implementation quality. The Implementation quality model focuses on correctness, internal deployment, contextual use, and descriptiveness, with an emphasis on process maturity and reusability, but it doesn't fully take into account all aspects of evolvability [4]. The Design quality model prioritizes requirements satisfaction, understandability, adaptability, and mature processes but lacks capturing architectural design decisions and extensibility. Testability is indirectly embedded in the internal property, and domain-specific attributes are not considered. Additionally, the model's disadvantage is that reliability and maintainability cannot be assessed until the software is operational.
FURPS Model categorizes software characteristics into functional (F) and non-functional (URPS) requirements, focusing on user needs. Functional requirements pertain to input and expected output, while non-functional requirements encompass usability, reliability, performance, and supportability. The article [1] provides a full description of these characteristics. IBM Rational Software extended this model into FURPS+, which continued to prioritize user requirements but overlooked developer considerations. Nevertheless, FURPS+ still lacks coverage of certain product characteristics, such as portability and maintainability.
ISO 9126 Model are organized hierarchically, with primary characteristics (Functionality, Reliability, Usability, Efficiency, Maintainability, and Portability) further broken down into 21 sub-attributes. These sub-attributes become apparent during software usage, originating from internal software properties. These characteristics are relevant to diverse software types, providing a unified terminology for evaluating software quality and enabling comparisons between software capabilities.
Let's imagine that there is a software product - a reporting service that provides clients with the opportunity to download a file with analytical data and documents for signing. It has a specific interface. It is very important for a business that the functionality works correctly and without failures. Let's consider applying the quality models listed above to this software.
The use of McCall's model can be very useful for ensuring a high level of quality of functionality, for example, we can assess how correctly and efficiently the service performs basic functions. However, this model does not cover some aspects, such as performance and scalability. This can lead to a problem if our customer base and data volumes begin to grow. Boehm’s model may also face performance and scalability issues. But it allows you to cover additionally some missed aspects. For example, it allows you to evaluate the interface and the convenience for customers when downloading files. Dromey's Model focuses on analysis and architecture, which can be important for a service as it processes complex analytical data. The model will also allow you to evaluate the software development process. For example, for a business it is very critical to know about the development time frame. But at the same time, it does not cover such criteria as supportability and ease of use, which are also very critical in the modern world. Applying the FURPS model to the reporting service will add supportability to the product. For a reporting service, this is critical, since documents for signature may change regularly, and clients may require additional data in analytical reports. This model also does not cover software security criteria. The latest ISO 9126 model provides a wide range of attributes and evaluation criteria. But does not include explicit mention of security attributes. For a reporting service, it is very important that data does not leak, or, for example, users cannot download other people’s reports. And assessing all attributes may require significant resources, time and effort.
In the IT industry at the moment, in most cases, they focus not on existing quality models, but rather on the specifics of the software product. Quality models do not keep pace with IT developments and become outdated. However, it cannot be said that companies do not currently use quality models. Many companies actively use tools to collect quality metrics and display them. Tools such as metabase and grafana allow you to display dashboards and graphs based on the collected data. Rather, many companies are now building their models by combining existing ones and adding their own quality criteria [5].
In conclusion, at the moment there are no universal quality models for assessing software quality. Taking into account the development of information technology, existing quality models cannot cover all quality needs. In this regard, the task is to constantly improve existing models by combining, introducing new attributes and quality criteria. It should be kept in mind that the choice of quality model depends on the context and the specifics of the software.