Software Reliability Analysis Models

Software reliability is the probability that software will cause a system failure over a specified operating time. Software does not fail because of wear, but because of faulty functionality, timing, sequencing, data, and exception handling. Software fails as a function of operating time, not calendar time. Since the early 1970s, more than 225 models have been developed, although some of them have similar, if not identical, assumptions. Models are of two main types: predictive modeling and estimation modeling.

A software (SW) reliability analysis model helps to assess and predict its resistance to errors, failures, and various external influences. Here are some key aspects:

1. Stages of analysis:

   • Collecting data on system operation.

   • Building a mathematical model describing reliability.

   • Testing and verification of the system.

2. Methods of analysis:

   • Using statistical failure data.

   • Building models based on probability theory.

   • Simulating program operation under various loads.

3. Goals:

   • Minimizing the number of errors in the code.

   • Increasing resistance to external influences.

   • Predicting the system's time to failure.

The subsequent security analysis of an information system (IS), in the absence of malicious destabilizing factors, is based on a model of the interaction of the main components shown in the figure. The following are considered as vulnerability objects:

• the dynamic computing process of data processing, automated preparation of decisions, and generation of control actions;

• information accumulated in databases;

• the object code of programs executed by computing facilities during IS operation;

• information issued to consumers and to actuating mechanisms.

These objects are affected by various unintentional destabilizing factors, which can be divided into internal ones, inherent in the vulnerability objects themselves, and external ones, caused by the environment in which these objects operate. The internal sources of threats to the operational security of complex ISs are:

• systemic errors in setting the goals and objectives of IS design, in formulating requirements for the functions and characteristics of problem solving, and in defining the conditions and parameters of the external environment in which the IS is to be used;

• algorithmic design errors made during the direct algorithmization of the functions of software and databases, in defining the structure and interaction of the components of program complexes, and in using database information;

• programming errors in program texts and data descriptions, as well as in the source and resulting documentation for IS components;

• insufficient effectiveness of the methods and means used for operational protection of programs and data and for ensuring the operational security of the IS under random negative influences.

The external destabilizing factors creating threats to the operational security of the listed IS vulnerability objects are:

• errors of operating and maintenance personnel during IS operation;

• distortions in telecommunication channels of information received from external sources and transmitted to consumers, as well as unacceptable changes in the characteristics of information flows;

• hardware malfunctions and failures;

• changes in the composition and configuration of the IS beyond the limits verified during testing or certification.

It is impossible to eliminate all these factors completely. Therefore, it is necessary to develop means and methods of reducing their influence on the reliability of SW (software). The degree of influence of all internal destabilizing factors and some external ones on SW reliability is determined to the greatest extent by the quality of the technologies for designing, developing, maintaining, and documenting the SW.

Methods of preventing threats to reliability:

• prevention of design errors;

• systematic testing;

• mandatory certification.

• Methods of improving reliability:

• time redundancy;

• information redundancy;

• software redundancy.

In modern automated technologies for creating complex SW, from the standpoint of ensuring the required and specified reliability, one can identify methods and tools that make it possible to:

• create software modules and functional components of high, guaranteed quality;

• prevent design defects through effective technologies and automation tools covering the entire life cycle of program complexes and databases;

• detect and eliminate various defects and errors in the design, development, and maintenance of programs through systematic testing at all stages of the SW life cycle;

• certify the achieved quality and operational reliability of SW during its testing and certification before it is handed over for regular operation;

• promptly identify the consequences of program and data defects and restore normal, reliable operation of program complexes.

Ensuring SW quality implies formalizing and certifying the technology of their development, as well as singling out, as a special process, the stage-by-stage measurement and analysis of the current quality of the components being created and used.

The main methods of preventing threats to reliability:

• prevention of design errors in CASE technologies;

• systematic testing;

• redundancy;

• mandatory certification

• The combined use of these methods makes it possible to significantly weaken the influence of threats. Thus, the level of reliability achieved depends on the resources allocated to achieving it and on the quality of the technologies used at all stages of the software life cycle.

A computing process is the process of executing a program together with its data on a processor (text editing, translation, execution of some program).

Object code is an intermediate representation of code. It is not yet machine code, but no longer source code. It is used at the stage of assembling a program from several pieces (possibly written in source code by different people and at different times).

Information redundancy (InformationRedundancy) is most characteristic of telecommunication systems, in which information is transmitted multiple times. Information redundancy consists in duplicating the accumulated source and intermediate data.

Bulky code, difficulty in getting rid of malware embedded in the code, difficulty of modification, low-level code is not intended for ordinary users and does not run on most compilers.

Time redundancy (TimeRedundancy) consists in using some part of the computer's performance to monitor program execution and to restore (restart) the computing process (a time reserve for repeating an operation, for example, double or triple calculation on a computer).

Database information - Data is registered information, a representation of facts, concepts, or instructions in a form suitable for transmission, communication, and processing by a human or by a machine.

Information for consumers – a subject that turns to an information system or an intermediary to obtain the information it needs and uses it in accordance with the procedure established by the owner or holder of the information.

Personally identifiable information leakage vulnerability is a vulnerability in which information provides specific details about specific individuals that, in turn, help distinguish those individuals from all other people. Moreover, this vulnerability becomes critical when the information is used to track, identify, or contact a specific person. For example, information used to pinpoint a person's identity includes an address, name, phone number, an identification number such as an Aadhaar number or PAN card details, gender, date of birth, an email address, or a combination of these data. Non-sensitive information about a person, such as name, gender, etc., may be transmitted in an insecure form without causing any harm to the person, but sensitive information, such as Aadhaar card details, a PAN card number, etc., must be transmitted in a secure way, such as data encryption, to prevent any unwanted disclosure of data or harm to the individual. Organizations use PIIL (personally identifiable information leakage) to understand which information needs to be kept secure and which information does not need additional protection.

Such models are especially important for mission-critical applications, for example in the medical, aviation, or banking industries.

List of software reliability models

Software reliability is a special aspect of reliability engineering. It focuses on the fundamentals and methods for making software more reliable, i.e. resistant to failures. System reliability, by definition, includes all parts of the system, including hardware, software, supporting infrastructure (including critical external interfaces), operators, and procedures. Traditionally, reliability engineering focuses on the critical hardware parts of the system. Since the widespread use of digital integrated circuit technology, software has become an increasingly important part of most electronic devices and, consequently, of almost all modern systems. Therefore, software reliability has gained prominence within the field of system reliability.

However, there are significant differences in the behavior of software and hardware. Most hardware unreliability results from the failure of a component or material, as a result of which the system does not perform its intended function. Repairing or replacing a hardware component restores the system to its original operating state. Software, however, does not fail in the same sense as hardware. Instead, software unreliability results from unforeseen outcomes of software operations. Even relatively small programs can have astronomically large combinations of inputs and states that cannot be exhaustively tested. Restoring software to its original state works only until the same combination of inputs and states leads to the same unforeseen result. Software reliability engineering must take this into account.

Despite this difference in the source of failures between software and hardware, several statistics-based software reliability models have been proposed to quantify what we experience when working with software: the longer the software runs, the higher the probability that it will eventually be used in an untested way and reveal a latent defect that leads to a failure (Shooman 1987), (Musa 2005), (Denney 2005).

As with hardware, software reliability depends on good requirements, design, and implementation. Software reliability engineering relies heavily on a disciplined software engineering process to anticipate and design for unintended consequences. There is more overlap between software quality engineering and software reliability engineering than between quality and reliability for hardware. A good software development plan is a key aspect of a software reliability program. The software development plan describes the design and coding standards, peer reviews, unit tests, configuration management, software metrics, and software models to be used during software development.

Models come in two main types: predictive modeling and estimation modeling.

1.0 Overview of software reliability prediction models

These models are derived from real historical data from real software projects. The user answers a list of questions that calibrate the historical data to produce a software reliability prediction. The accuracy of the prediction depends on how many parameters (questions) and data sets the model contains, how relevant the data are, and how confident the user is in their inputs. One of the earliest prediction models was Rome Laboratory TR-92-52. It was developed in 1987, last updated in 1992, and was focused on software in avionics systems.

2.0 Overview of software reliability growth (estimation) models

Software reliability growth (or estimation) models use failure data obtained during testing to predict the future failure rate or MTBF. The models depend on assumptions about the failure rate during testing, which may increase, peak, decrease, or follow some combination of decrease and increase. Some models assume that there is a finite and fixed number of inherent defects, while others assume that it is infinite. Some models require effort to estimate parameters, while others have only a few parameters to estimate. Some models require the exact time between each failure found in testing, while others need only the number of failures found during any given time interval, such as a day.

Software reliability tools that implement some of these models include CASRE (Computer-Aided Software Reliability Estimation) and the open-source SFRAT (Software Failure and Reliability Assessment Tool).