11.3. Constructive quality characteristics of complex software systems

Constructive characteristics are divided into two groups: quantitative and qualitative, which differ in their possibilities for concretizing measures and scales. Two groups of standardized characteristics of software quality — Reliability and Efficiency are most amenable to quantitative measurement. For them, Table 11.2 presents examples of possible measures and measurement scales for the main quantitative attributes of the quality subcharacteristics. They can serve as guidelines when selecting and establishing the required values of these quality indicators in software specifications.

Table 11.2 Main quantitative characteristics of software systems and their attributes

Reliability: the property of a program complex to ensure a sufficiently low probability of loss of operability — failure — during the functioning of the software system in real time. The main reliability attributes can be objectively measured and compared against requirements. Requirements for the values of the attributes of the completeness subcharacteristic — the permissible mean time between failures — are established in the absence of automatic restart and in the presence of an administrator monitoring the operability of the software system. By applying software-hardware mechanisms for automatic restart, this mean time between failures can be increased when failures occur, i.e., for some failures automatic detection and prompt restoration of operability become possible, as a result of which the values of robustness and mean time between failures increase. This must be taken into account when determining the requirements for the availability factor — the probability of finding the software system in an operable state. As with the formation of correctness requirements (see Table 11.1), for reliability the test coverage of the structure and functions of the software components and of the software system as a whole during debugging is of great importance.

The reliability of program functioning is a dynamic concept, manifesting itself over time, and differs substantially from the concept of static program correctness. The reliability of a software system is most fully characterized by its robustness, or ability to function without failure, and by its recoverability of an operable state after malfunctions or failures have occurred. In turn, robustness depends on the degree of test coverage of the functions and structure of programs, on the level of uncorrected defects and errors (completeness), and on the ability of the software system to react to their manifestations so that this does not affect the reliability indicators. The latter are determined by the effectiveness of control over data coming from the external environment and by the means of detecting anomalies in the functioning of the software system. In real conditions, for various reasons, input data may fall within ranges of values that were not verified during development and testing, and also not specified by the requirements of the specification and technical assignment, causing malfunctions and failures. In this case, an incorrect program can function completely reliably.

Completeness: the property of a software system of not entering failure states as a result of errors and defects in programs and data. The number or density of manifestation of hidden defects and errors is directly reflected in the duration of normal functioning of the program complex between failures. Completeness can be characterized by the mean time (duration) between failures (in the absence of automatic recovery — restart), usually measured in hours. This subcharacteristic is affected only by failures resulting from defects that have manifested themselves. These can be caused by incomplete test coverage during testing of components and of the software system as a whole, as well as by insufficient completeness of testing of their functions.

Robustness to defects and errors: the property of a software system to automatically maintain a specified level of functioning quality when defects and errors manifest themselves or when the established interface is violated. For this, the software system must introduce time, program and information redundancy that implements prompt detection of defects and functioning errors, their identification, and automatic restoration (restart) of normal functioning of the software system. The effective, prompt elimination of manifestations of defects, errors, and incorrect interaction with the operating and external environment determine the subcharacteristic — the robustness of program complexes.

Recoverability: the property of a software system, in the event of a failure, to resume the required level of functioning quality, as well as to repair damaged programs and data. After a failure, a software system is sometimes inoperable for a certain time, the duration of which is determined by its recoverability. This requires computational resources and time to detect the inoperable state, diagnose the causes of the failure, and implement the recovery processes. The main indicators of the recovery process are its duration and probabilistic characteristics. Recoverability is also characterized by the completeness of the restoration of normal program functioning during manual or automatic restart. Restart must ensure the resumption of normal functioning of the software system, which requires computer resources and time that can be characterized by a relative value (% of total resources).

Availability or readiness: the property of a software system to be able to perform the required function at a given moment in time under specified conditions of use. Externally, availability can be assessed by the relative time during which the software system is in an operable state, as a proportion of the total time of use. Consequently, availability is a combination of completeness (on which the frequency of failures depends), robustness to errors, and recoverability, which together determine the duration of downtime for recovery after each failure, as well as the duration of the mean time between failures. The generalization of failure and recovery characteristics is expressed in the criterion of the availability factor. This indicator reflects the probability of having recoverable programs and data in an operable state at an arbitrary moment in time.

The lower boundary of the scale of reliability attributes in Table 11.2 is reflected by values at which functional suitability sharply decreases and the use of this type of software system becomes inconvenient, dangerous, or unprofitable. Examples of such worst-case, limiting values for many classes of software systems can be a mean time between failures of less than ten hours, an availability factor below 0.9, and a recovery time of more than ten minutes. On the other hand, the best values of these attributes are practically limited by the resources that can be allocated to achieve them during development and operation. The computational and program resources of the target computer allocated directly to ensuring the reliability of the functioning of the software system are usually in the range from 10% to 90%, with the latter values corresponding to critical, especially high-reliability systems. Even for such critical software systems, the mean time between failures rarely exceeds several thousand hours, the availability factor is no higher than 0.999, and the recovery time for failures is no less than several seconds.

Efficiency: the ISO 9126 standard reflects two quality subcharacteristics — time efficiency and computer resource utilization, which are recommended to be described mainly by quantitative attributes characterizing the dynamics of functioning of the software system's components. This standardized characteristic reflects only partial constructive efficiency of the use of computer resources, which should not be confused with system efficiency of the functional suitability of the software system when used within a specific system.

The main requirements for the attributes of the time efficiency of the use of the system's computational resources characteristic are focused on the most critical performance indicators and the duration of solving functional tasks. Unlike memory volumes, timing characteristics are harder to establish and measure, and their limitations have a stronger effect on the functional suitability of the software system. Usually, for the operational work of users it is important to have a short response time from the computer after receiving a typical task and beginning to solve the required functional task. The required throughput for solving functional tasks depends on their content and the number of active users. The utilization of memory resources and the performance of computing facilities can be established, on the one hand, based on the economic feasibility of using the cheapest computer with minimal resources, whose load will on average be no lower than 0.5. On the other hand, high load (above 0.9) can lead to undesirable delay or even loss of tasks during a random, short-term increase in their intensity, which can negatively affect functional suitability.

Time efficiency: the properties of a software system that characterize the required response and processing times of tasks, as well as the performance of task solving taking into account the amount of computational resources used under established conditions. These resources may include other software products, hardware, telecommunication facilities, etc. The time efficiency of a software system is determined by the duration of performing specified functions and waiting for results in average and/or worst cases, taking into account task priorities. It depends on the speed of data processing, which directly affects the time interval for completion of a specific computational process, and on the throughput — performance, i.e., on the number of tasks that can be carried out on a given computer in a given time interval (see Table 11.2). These quality indicators are closely related to the scheduling discipline and the reaction (response) time of the software system to tasks when solving various functional tasks. The value of this time depends on the duration of solving the set of tasks by the computer's central processor, on the time spent exchanging data with external memory, on data input and output, and on the duration of waiting in a queue before the task begins to be solved. This subcharacteristic is closely related to the duration of processing a typical task, as well as to the time interval for solving typical or most frequently invoked functional tasks of the given software system. The throughput of the program complex on a specific computer is reflected by the number of messages or tasks for solving specific problems, processed per unit of time, which depends on the characteristics of the external environment.

Resource utilization: the degree of loading of available computational resources during a given time while performing the functions of the software system under established conditions. Resource economy is reflected in the occupancy of the resources of the central processor, main, external, and virtual memory, input-output channels, terminals, and communication network channels. This value is determined by the structure and functions of the software system, as well as by the architectural features and available resources of the computer. Depending on the specific features of the software system and the computer, when selecting attributes either the value of the absolute occupancy of resources of various types, or the relative value of the use of resources of each type during normal functioning of the software system, may dominate. Resource economy affects not only the cost of solving functional tasks, but often, especially for embedded computers, determines the fundamental possibility of full-fledged functioning of a specific software system under conditions of genuinely limited computational resources. Despite the rapid growth of available memory resources and computer performance, the needs for them to solve specific tasks of the software system often outpace their technical increase, and the task of evaluating and efficiently using computational resources remains relevant.

By means of qualitative analysis, taking into account the effect on functional suitability, it is possible to determine the limiting values for the main attributes of the constructive characteristic — efficiency. The utilization of computational memory resources and computer performance for each functional task or application program may amount to several percent. However, for the entire program complex, stable use of computer resources below 50—70% is unprofitable and, in principle, allows switching to a cheaper computer with fewer resources. At the same time, resource utilization of more than 95% can lead to significant delays or failures when solving low-priority tasks. Under non-stationary flows of tasks for solving the main functional tasks of the software system, some reserves of memory and computer performance are necessary, which determines rational values of resource utilization up to 80—90% of the maximum values. The time efficiency attribute — the response time to a user task — directly depends on the functional tasks being solved and, in general, can be set in the range from 0.1 second to several tens of seconds. These values depend on the dynamic characteristics of the external environment objects for which the functional tasks of the software system are solved. In administrative systems an average response time of several seconds may be acceptable, while for the real-time control of dynamic objects (aircraft, missiles) it is reduced to tenths and hundredths of a second. Three groups of constructive characteristics of software quality— usability, maintainability and portability — are difficult to measure quantitatively, and are mainly available to qualitative assessments of their properties. In some projects, for the maintainability and portability subcharacteristics, technical-economic measures of labor intensity (man-hours) and duration (hours) for the procedures ensuring the implementation of the attributes of these subcharacteristics may dominate during system design. However, for a number of attributes in this group of characteristics, it is necessary to apply ordinal measures of expert scoring scales with a small number (2—4) of gradations. Table 11.3 presents examples of possible measures and measurement scales for the main subcharacteristics and their quality attributes. They can serve as guidelines when selecting and establishing the required values of these quality indicators in software specifications.

Table 11.3 Main qualitative characteristics of software systems and their attributes

End of Table 11.3

Usability — applicability: properties of a software system that reflect the complexity of understanding, learning and using it, as well as its attractiveness for qualified users when applied under the specified conditions. The requirements for usability and its subcharacteristics — understandability and ease of use — depend on the purpose and functions of the software system and can be formalized by customers as a set of properties necessary to ensure convenient and comfortable operation of the programs. Quantitatively, ease of use can be characterized by requirements for the permissible average duration of entering typical tasks and the response time to them. The requirements for the duration of learning a software system, sufficient for effective operation of the system by qualified specialists, may amount to hours or weeks. To ensure full-fledged learning of the processes of applying the software system by these specialists, operational documentation is necessary, the volume of which substantially depends on the purpose and functions of the software system and can be set based on the analysis of precedents of similar successful projects. For some software system projects intended for wide distribution, electronic tutorials adequate in content may be desirable, and the requirements for their volume and functions are also advisable to assess based on precedents. It should be taken into account that a small volume of operational documentation can reduce the quality and completeness of the use of the functions of a complex software system, while a very large volume — can also worsen operation due to the difficulty of distinguishing the most essential properties and features of using the software system from a multitude of secondary details.

The set of users may include administrators, operators, end users and indirect users, who are affected by or depend on the quality of the software system's functioning. Usability should take into account the entire diversity of the characteristics of the users' external environment that can be affected by the software system, including the training required for using and evaluating the results of the programs' functioning. Applicability (usability) of use is a fairly subjective concept that is difficult to formalize, but ultimately often significantly determines the functional suitability and usefulness of applying the software system.

Understandability: the properties of a software system that give the user an understanding of whether the program is suitable for their purposes and how it can be used for specific tasks and conditions of application. Understandability depends on the quality of the documentation and the subjective impressions of the functions and characteristics of the software system. It can be described qualitatively by the clarity of the functional concept, the breadth of demonstration capabilities, and the completeness, comprehensiveness and clarity of the presentation, in the operational documentation, of the possible functions and features of their implementation.

It must be ensured by the correctness and completeness of the description of the input and output information, as well as of all the details of the software system's functions for users.

Ease of use: the ability of the user to conveniently and comfortably operate and control the software system. Aspects of changeability, adaptability and ease of installation can be prerequisites for ease of use and the choice of a specific software system. It corresponds to controllability, robustness to errors, and consistency with the expectations and skills of users. This subcharacteristic must take into account the physical and psychological characteristics of users and reflect the level of controllability and comfort of the conditions of operation of the software system, and the possibility of preventing user errors. Simplicity of controlling the functions of the software system and a sufficient volume of control parameters implemented by default, informativeness of messages to the user, clarity and unification of screen control, as well as the availability of changing functions in accordance with the user's qualification and the minimum number of operations necessary to launch a specific task and analyze results, must be ensured. In addition, ease of use is characterized by a number of dynamic parameters: input and response time to a task, the duration of solving typical tasks, and the time for recording results, which overlap with the attributes of the time efficiency subcharacteristic.

The ease of use of program complexes of administrative information systems is largely characterized by the correctness and adequacy of the descriptions of interactive control directives, the volume and time of entering tasks, and the time users wait for results during their execution. Ease of use can be generally assessed qualitatively using scales with two to four categories. The same method is most adequate for assessing the comfort of operation and the simplicity of controlling the functions of the software system. However, some attributes of this subcharacteristic are available for a more complete quantitative assessment by measuring the labor intensity and duration of the corresponding processes of preparing and training qualified users for full-fledged and effective operation of the software system.

Learnability: the properties of a software system that provide convenient mastery of its use by sufficiently qualified users. It can be determined by the labor intensity and duration of preparing the user for full-fledged operation of the software system. The attributes of learnability depend on the possibility of preliminary training and the improvement of knowledge during operation, on the availability of prompt help and hints when using the software system, as well as on the completeness, availability and convenience of use of the manuals and operating instructions. The quality of the learnability of a software system depends on the internal properties and complexity of the program complex, as well as on the subjective characteristics of the qualification of specific users.

The values of learnability are significantly affected by the demonstration capabilities of reference training tools, the quality and volume of operational documentation, as well as of electronic tutorials, which can be assessed respectively by the number of accompanying document pages or the kilobytes of computer memory occupied by the tutorials. Learnability can be reflected by the labor intensity and duration of learning, by users of the corresponding qualification, of the methods and instructions for applying the software system for full-fledged operation. These attributes can be characterized by a labor intensity of from units to hundreds of man-hours and a duration of from units to thousands of hours, necessary for mastering the qualified application of particularly complex program complexes.

Assessments of usability depend not only on the inherent characteristics of the software system, but also on the organization and adequacy of the documentation of its operating processes. This assumes that the contract, technical assignment or specification has fixed and approved requirements for the main parameters and quality of the organizational methods and tools supporting the use of the software system. These requirements can affect the functional suitability and success of the implementation of the program complex among users, and can also differ significantly depending on the functional purpose and field of application of the software system. On an ordinal scale — «excellent, good, satisfactory or unsatisfactory» — it is possible to assess understandability: the clarity of the software system concept, its demonstration capabilities, the clarity and completeness of the documentation, and also, partially, ease of use: the comfort of operation and the simplicity of controlling functions.

Maintainability: the adaptedness of a software system to modification and configuration change. Modifications can include corrections, improvements, or adaptation of the software system to changes in the external environment of application, as well as in the customer's requirements and functional specifications (see Lecture 15). The simplicity and labor intensity of modifications are determined by the internal quality metrics of the program complex, which are reflected in the external quality and quality in use, as well as in the complexity of managing the configuration of software system versions (see Lecture 16).

The requirements for maintainability can be established quantitatively for the changeability and testability subcharacteristics using economic categories of the permissible labor intensity and duration of the implementation of these tasks under certain conditions. In general, this is reflected in the duration and labor intensity of preparing and implementing typical changes, caused by the need to eliminate defects and to improve the functions of the software system. For the preparation and execution of each change (excluding the time spent on detecting and localizing the defect), it is necessary to establish the permissible average duration and the total labor intensity of the specialists' work in implementing them.

Analyzability: the readiness of a software system for diagnosing its defects or the causes of failures, as well as for identifying and isolating its components for modification and correction. This subcharacteristic depends on the coherence of the architecture, the unification of interfaces, and the completeness and correctness of the technological and operational documentation for the software system (see Table 11.3). Analyzability is affected by the quality of the tools for monitoring and tracking changes in functional characteristics, as well as defects and corrections of programs and data.

Changeability: the adaptedness of a software system for the simple implementation of specified changes and for configuration management. The implementation of modifications includes the design, coding and documentation of changes. This requires a certain labor intensity and time associated with correcting defects and/or upgrading functions, as well as with changing operating processes. When selecting the attributes of this subcharacteristic, the influence of the structure, interfaces and technical features of the software system should be taken into account. Changeability depends not only on the internal properties of the software system, but also on the organization and tool support of the maintenance and configuration management processes, to which the architecture and the external and internal interfaces of the programs are oriented.

Testability: the property of a software system that ensures the ease of verifying the quality of changes and accepting modified program components. This subcharacteristic depends on the size of the area of impact of the changes that need to be tested when modifying programs and data, and on the complexity of the tests for verifying their characteristics. Its attributes depend on the clarity of the rules for the structural construction of the components and of the entire program complex, on the unification of inter-module and external interfaces, and on the completeness and correctness of the technological documentation. This subcharacteristic mainly takes into account the technical and organizational components of the process of testing modifications and does not include the functional part of their preparation. In general, it can be assessed by the labor and time costs of testing certain program modifications of average volume and complexity.

The subcharacteristics of analyzability and stability, as part of maintain-ability, are qualitatively characterized by attributes close to the attributes of usability: the coherence of the program complex's architecture, the unification of interfaces, and the completeness and correctness of the documentation. The simplest ordinal scale can be applied for these subcharacteristics. The subcharacteristics of changeability and testability are available for quantitative assessment based on the labor intensity and duration of implementing these functions during typical operations using various methods and automation tools. The preparation and each test of a program, depending on the complexity of the change, taking into account its verification and correction of the documentation, may require a labor intensity of from one to several hundred man-hours and a time of up to a thousand hours when releasing a new version of a complex program complex.

Portability: the readiness of a software system to be transferred from one hardware-operating environment to another (see Lecture 15). The portability of programs and data to various hardware and operating platforms is an important indicator of the functional suitability of many modern software systems. Establishing the requirements for the portability of a software system can be reduced to formalizing the labor intensity and duration of the processes of: adaptation to new characteristics of the users and the external environment, installation of software system versions in the users' environment, and replacement of large components of software system versions at the request of customers or specific users.

The simplest and most easily formalized of the listed processes is the installation of a ready-made version of the software system with a set of documentation on the user's platform without additional changes, which may require several hours of specialists' work. A more complex process involves adapting the software system according to formalized instructions to a new specific hardware, operating, or external environment of a particular user, which may require more time and more specialists. An even more complex and labor-intensive process is the replacement of large components of the software system and their transfer to a different hardware and operating platform.

This property can be assessed by the volume, labor intensity and duration of the necessary rework of components and adaptation operations that must be performed to ensure the full-fledged functioning of the software system after transfer to a different platform (see Table 11.3). Portability can be carried out at the level of the program source code in a programming language or at the level of the object code executed by the computer. It depends on the structuredness and extensibility of the program and data complexes, as well as on the availability of additional resources necessary for implementing portability and modifying components during their transfer.

Adaptability: the suitability of programs and database information for modification for operation in various hardware and operating environments without the use of actions or tools other than those intended for this purpose during the original development of the initial version of the software system. It depends on the properties and structure of the hardware and operating environment, and on the methods and tools built into the software system for preparation for transfer to new platforms. Adaptability includes the scalability of internal capabilities (for example, screen fields, table sizes, transaction volumes, report formats). If the software system must be adapted by the end user, adaptability corresponds to the suitability for customizing the program complex when the external environment changes and can be a component of ease of use.

Ease of installation — installability: the ability of a software system for simple implementation (installation) in a new hardware and operating environment of the customer or user. If the software system must be installed by the end user, ease of installation will be a prerequisite for ease of use. Like adaptability, it can be measured by the labor intensity and duration of the installation procedures, as well as by the degree to which the requirements of the customer and users for the characteristics and complexity of the installation are satisfied.

Replaceability: the suitability of each component of a software system for being relatively easily used in place of another designated and specified component being replaced. It can include attributes of both ease of installation and adaptability. A major role for this property is played by the clear structuredness of the architecture and the standardization of the internal and external interfaces of the software system. This property is reflected in the labor intensity and duration of replacing, mainly, large components of the software system.

The measures and scales of portability are, to some extent, similar to the qualitative and quantitative measures and scales of maintainability. The components of portability: adaptability, ease of installation and replaceability are available for quantitative technical-economic assessment. When selecting the characteristics of a software system, the strictest requirements are usually imposed on the labor intensity and duration of installing software system versions on a new platform, which can take from several minutes to several tens of hours and require a corresponding labor intensity of up to tens of man-hours. Adapting software system versions to the conditions of a new external environment and to user requirements, as well as replacing and introducing large components into a new software-hardware environment, are usually characterized by a greater need for time and labor intensity. On the whole, portability affects functional suitability when transferring programs and data to other operating and hardware platforms, and when expanding and changing their functions. For this, the implementation of the main functions of the program complex must be prepared for portability, which requires additional labor, time and computational resources. The absence of such preparation during the design of the software system is reflected in an increase in the costs of the procedures that make up portability, and for some types of software systems can limit their functional suitability.

See also

• Database quality
• software quality
• external quality
• internal quality
• [[b7898]]
• [[b9537]]
• [[b9538]]
• [[b9539]]
• [[b9540]]

See also

• 11 SPECIFICATIONS OF QUALITY OF SOFTWARE TOOLS
• 11.2. Properties and quality attributes of the functionality of complex software systems
• 11.3. Constructive quality characteristics of complex software systems
• 11.4. Quality characteristics of databases
• 11.5. Protection and operational safety characteristics of software