2.2.2. Project B

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,

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

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

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

8. Can we combine inherent defects from previous releases, defects found within the current release and defects

wireless network system, where projects A and B can be found in the diagram.

respectively.

46 Telecommunication Networks - Trends and Developments

2.2. Defect data sets

2.2.1. Project A

architecture.

3. Are we ready for delivery?

deferred to next release? 9. Are we finding defects as expected?

11. Can we predict software availability?

Table 1. BRACE use cases (motivating questions).

1. How many defects are we going to find by delivery date? 2. How many residual defects will remain at delivery?

5. How many defects are we going to find after delivery?

6. How does the defect curve of a new release compare to past releases? 7. Which location/severity/component is generating the most defects?

10. Can we adjust for DevOps continuous integration & delivery (CI/CD)?

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

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 quality impact will be shown in Section 4.
