2.1. System design

BRACE consists of three main processes: (1) pre-processing, (2) core processing and (3) postprocessing as illustrated in Figure 2.

Figure 2. BRACE main processes.

stages, in which case a complete solution may require more than one model. In addition, the fact that the rate at which defects are found can change overtime requires that even for the same phase, the same model may need to be applied more than once each covering a specific trend. In practice, applying such models in an efficient way can be effort intensive and usually

This chapter discusses advances to the above techniques and approaches using BRACE [21], a cloud-based, fully-automated tool for software defect prediction, reliability and availability modeling and analytics. BRACE includes a number of technical contributions to make software defect prediction more practical for every software development project. First, the tool unifies and automates the entire process of data extraction, pre-processing, core processing and post-processing. Second, the core data analytics engine of BRACE—SRGM—provides a robust, consistent, flexible, fast, statistically sound approach to defect prediction for any defect data set without human intervention. This is achieved by modeling the entire defect trend as a series of piece-wise exponential curves, and incorporating a mechanism to automatically detect when to transition from one curve to the next. Moreover, to enhance the accuracy, whenever available, the algorithm can also take as input feature arrival data (which is a measure of development effort). This allows the enhanced SRGM to provide defect prediction from the project planning phase through the internal testing phase and the customer site test and customer operation periods. Finally, BRACE exposes a user interface which displays the output generated from the core processing. It makes it easier for projects to understand the current progress towards quality improvement. To the best of our knowledge, this is the first attempt to propose a practical software defect prediction and reliability management solution

The rest of this chapter is organized as follows: In Section 2, we present the design, implementation and use cases of BRACE. We also describe datasets from two example projects that are used as references throughout the chapter. In Section 3, we detail an automated SRGM algorithm which is the core analytics engine of BRACE. The algorithm enhances traditional SRGMs by enabling accurate early defect prediction, which, as mentioned earlier, is a necessity for most projects. Sections 4 and 5 will discuss key post-delivery metrics: customer defects and software availability respectively. The Chapter is concluded in Section 5. Data sets from two large-scale software development projects from telecom products are used to illustrate the

BRACE consists of three main processes: (1) pre-processing, (2) core processing and (3) post-

that can be re-used across multiple teams at industrial scale.

effectiveness of BRACE throughout the chapter.

2. BRACE system overview

processing as illustrated in Figure 2.

2.1. System design

requires an expert.

44 Telecommunication Networks - Trends and Developments

1.3. Chapter overview


<sup>2</sup> While defect trend analysis is typically performed with weekly data, as we move towards continuous delivery, it is necessary to investigate the use of daily data. Therefore, the proposed tool has been applied to daily defect data from several projects, and has been able to produce results consistent with those from weekly data. Allowing the use of daily data is important as this allows SRGM to be applied in real time (daily), and hence help detect possible problems earlier.

3. Finally, the post-processing step takes as input the metrics from the core processing so as to generate various types of tables and charts, depending on project's needs. As an example, this step may be able to present outputs such as software failure rate, software availability & reliability, software annual downtime, defect rate, and predicted defects. Moreover, it also provides confidence limits for each of the calculated metrics. Therefore, the postprocessing stage is aimed at providing answers (using a GUI) to the questions presented in Table 1. Answers to these use cases are the main motivations of the work done by software reliability experts, and by extension the main motivations of BRACE. As such, answers to the questions below will be provided throughout the rest of this chapter. We discuss details regarding these outputs and final processing steps in Sections 4 and 5, respectively.

## 2.2. Defect data sets

Defect data sets, called Projects A & B, are briefly described. Both projects represent large-scale software development from telecom products. Figure 3 shows an example of a 3G & 4G wireless network system, where projects A and B can be found in the diagram.

> software component as many pairs of active-standby software configurations. As discussed in Section 4, this feature helped improve the capacity as well as the availability since the impact of failure software becomes very small due to a pair of active-standby. The quality impact of the major changes will be highlighted in Section 4. The data sets used in this chapter cover 11

Software Quality Assurance

47

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

It represents a radio access part of the latest 4G mobile network technology. The two 3G key functions were combined into one, called eNB, to meet high data rate requirements. It performs the control and management of radio resources in a wireless network, plus radio frequency transmitters and receivers used to directly communicate with mobile devices. It is built on a highly complex hardware design and sophisticated software architecture. The software development is required to deliver many complex new features to meet demand in fast growing markets. Recent releases contain over 1 million non-commentary source lines (MNCSL) new features and deploy a new delivery scheme of multiple deliveries per release to satisfy the needs for additional features by multiple customers. Similar to Project A, this project also went through a major hardware platform change and drastic software redesign. The

As earlier mentioned, exponential models assume that defects can be found and resolved at a constant rate [10]. While this results into a simple and flexible model with well understood

releases over 5 years.

quality impact will be shown in Section 4.

Figure 3. Sample 3G & 4G wireless telecom network system.

3.1. Automated SRGM

3. Software reliability growth model (SRGM)

2.2.2. Project B

#### 2.2.1. Project A

This is a key wireless product, called RNC, which is responsible for the control and management of radio resources in a wireless network. It is a large-scale software development for a key 3G wireless telecommunication product with a high availability redundant hardware configuration. Code size varies from over 500 KNCSL (1000 non-commentary source lines) in earlier releases to less than 100 KNCSL as customers migrate from 3G to 4G systems. A traditional delivery scheme of one delivery per release was used. A major hardware platform change took place during the reported period, which resulted in redesigning the software architecture.

It takes advantages of hardware technological improvement, by introducing additional software redundancy as well as upgrading and re-designing the hardware platform with a pair of active-active processors. The new hardware platform supports multiple copies of a key



Table 1. BRACE use cases (motivating questions).

<sup>1.</sup> How many defects are we going to find by delivery date?

<sup>4.</sup> When do we expect the defect closure curve to catch up with the defect arrival curve?

Figure 3. Sample 3G & 4G wireless telecom network system.

software component as many pairs of active-standby software configurations. As discussed in Section 4, this feature helped improve the capacity as well as the availability since the impact of failure software becomes very small due to a pair of active-standby. The quality impact of the major changes will be highlighted in Section 4. The data sets used in this chapter cover 11 releases over 5 years.
