1. Introduction

According to the ISO/IEC 17000 standards, the main procedures of software compliance evaluation include acceptance tests, certifications tests, and follow-up inspection control.

For the purpose of certification tests, the software to be assessed for compliance is submitted in a complete form, usually upon the final completion of acceptance testing. At the same time, during preliminary and acceptance tests, the assessed software is revised in order to correct

© 2016 The Author(s). Licensee InTech. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and eproduction in any medium, provided the original work is properly cited. © 2018 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

detected errors of different types. Considering all this, at the stage of certification, the information systems and software products can be regarded as non-modifiable, while at the stage of acceptance tests, they are defined as modifiable systems. This defines the difference in approaches to developing the mathematical test models.

• Test confidence models that allow assessing confidence parameters of the test procedure • Program complexity models based on the relationship between the software complexity

Models for Testing Modifiable Systems http://dx.doi.org/10.5772/intechopen.75126 149

It should be noted that the latter three classes of test models are rather well developed2 [3–14]. For example, today, about 200 time models are known, mainly, NHPP models (e.g., [15–21]). At the same time, debugging models (also known as reliability growth models based on input data areas and revisions) are usually related only to Nelson's model and its modifications [22] developed at the dawn of the programming theory and do not reflect peculiarities of the

The early stage of testing is the typical scope of application for the debugging models. This is due to the fact that this period of a software system lifecycle is characterized by active modification of the programs aimed at correcting the detected errors. The models described in the literature reflect monotonic (typically, exponential, or logistic) growth of software operation reliability, which is not always true, as, for instance, in the case of implementation of the open-source software, multi-version or multiple replica software developed at different times by absolutely different teams of developers with diverse qualification, different styles, using various technologies and development systems, etc. This chapter is devoted to justification of new non-monotonic models and calculation of expressions of their parameters. We shall assume that the software reliability is a set of properties that characterize the ability of the program to maintain the specified level of availability in specified conditions during the specified period of time.<sup>3</sup> It is important to note that if the level of availability is restricted by security and vulnerability defects, the term reliability shall be equal to the term information

Definition of the software reliability is fundamentally different from that of the hardware, mainly, due to the fact that the software is not prone to aging in time. Two characteristics of

1. As a characteristic, reliability can alter only as the result of the software modification (i.e., when the tested object is changed), and the level of reliability can either increase or

2. Values of the software reliability parameters are valid for those input data classes that were

A number of debugging models were described in the literature, namely, Nelson's model, matrix model, LaPadula model, and other models [2, 5, 12, 13, 22], that reflect the stepwise monotonic growth of reliability and thus do not take into account the possibility of obvious reliability decrease, for example, due to introduction of global wavefront errors or addition of new functionality. Experience gathered by the test laboratory shows that application of such mathematical models either gives unreliable results or significantly increases the time required

metrics and program quality, reliability, and safety parameters

modern team software development methods.

the software reliability can be mentioned:

IEEE Std. 1633–2008 (R2016). Recommended Practice on Software Reliability.

GOST 28806–90. Software quality. Terms and definitions.

used for their calculation.

security.

2

3

decrease.
