1. Introduction

Emerging technology breakthroughs in a number of fields, such The Internet of Things, 5G, artificial intelligence, etc., are propelling a continuous increase in the size and complexity of software in communication systems. In such applications, software must have—among others —two important characteristics: (1) quality and (2) agility. Software quality is important to

© 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.

limit downtime and vulnerabilities that might have unprecedented consequences for the anticipated societal-critical applications, while agility helps to continuously improve services to meet customer needs. In order to meet business objectives, and supported by advances in virtualization technologies, Telecom service providers are recently moving towards service agility, where the aim is to create new or improve the services provided to their users [1]. To this end, network software vendors must have the capability to continuously deliver and integrate software from which such services are composed.

fixed during every development phase as well as during customer site test and actual operation periods. In a traditional development process, most defects are found by testers, independent of developers. The test phase includes integration, feature, system, robustness, stability, and performance testing, just to name a few.<sup>1</sup> Most software defects are expected to be found

Software Quality Assurance

43

http://dx.doi.org/10.5772/intechopen.79839

A proportion of defects that remain at the end of the test phase are normally encountered during operation in the field, and usually, only a fraction of them lead to failures or outages. However, an outage puts a system down, making it go through a process of respond-recover-resolve. Finally, some of the residual defects will usually not be found even during field operation. These

The quality of software is measured in terms of software defects found during the customer operation period. SRGM is usually used to quantify the quality of software products before they are delivered to customers. SRGM is a very well-studied subject, with over 200 SRGMs developed since early 1970s [3–15]. These models can generally be categorized as either being

Parametric models are based on explicit mathematical expressions and physical interpretation. They were originally designed for system test but continue to be extended to include functional, integration, and other earlier test phases. They are the earliest developed models, are easily understood, and widely used. Most of the frequently used parametric models can be systematically grouped based on the shape of the function (i.e. S-shaped curve or exponential curve). S-shaped curve models use various types of S-shaped distributions such as Gamma, logistic, Weibull functions to match with actual data trends [6, 9], while exponential models (e.g. [3, 4, 7, 10, 11]) consider that defects are found at a constant rate through the different test phases. S-curve models have flexibility in describing different shapes of the trend since they have more than two parameters. Compared with S-shaped models, exponential models are simple with only two parameters and have been successfully demonstrated with practical data from large-scale software development projects [16, 17]. There have been many comparison studies performed and various tools have been developed for evaluating individual models in

Recently, non-parametric SRGMs are being proposed. Such models typically use machine learning techniques considering the inherent characteristics of the software (such as code size, test resources, test duration, complexity, etc.) as input. Although non-parametric models are promising, their use in practical applications is still limited by their need for (big amounts of) input data which is not always available, or whose quality may be unacceptable. Therefore, practical implementations and application of SRGMs are still mainly based on parametric models. Even then, there is no single model which can be used in every situation [20]. Models that work well during the early development phases are typically not efficient in the later

and removed during these testing phases.

1.2. SRGM background

parametric or non-parametric.

1

then become base or old defects for the following release.

terms of how well each model fits to the data [18, 19].

It is worth noting that test phase names vary across projects and organizations.

These requirements mean that development teams must be able to produce quality software in very short time periods. This calls for accurate ways of planning team resource requirements or software size (number/complexity of features) ahead of time to avoid failing to meet customer needs. A useful approach for this assessment is predicting the number of defects during the requirements and design phase, which may allow for time to take preventive actions such as additional reviews and more extensive testing, finally improving software process control and achieving high software quality [2].

#### 1.1. Software development phases

Software quality can be significantly affected by the number of defects and amount/type of testing carried out at the different stages of the software development phase. In this subsection, we examine the defect flow through various development phases and in the field. Once a set of new features is identified, each of them goes through the phases shown in Figure 1. It can be observed that there are a number of activities overlapping in time (x-axis). New defects are introduced during the requirement, design and coding phases while old defects are carried over from previous releases into the current release. The thickness of the arrows indicates the relative numbers of defects expected at each point in time. Defects are found and removed or

Figure 1. Defect flow development, test, field (traditional vs. agile).

fixed during every development phase as well as during customer site test and actual operation periods. In a traditional development process, most defects are found by testers, independent of developers. The test phase includes integration, feature, system, robustness, stability, and performance testing, just to name a few.<sup>1</sup> Most software defects are expected to be found and removed during these testing phases.

A proportion of defects that remain at the end of the test phase are normally encountered during operation in the field, and usually, only a fraction of them lead to failures or outages. However, an outage puts a system down, making it go through a process of respond-recover-resolve. Finally, some of the residual defects will usually not be found even during field operation. These then become base or old defects for the following release.
