# Using GQIM Model and Gompertz Model to Measure, Analyze, and Optimize the Whole Process of Software Project

Authors: Li Zhao; Yongchun Wu; Xiujuan Wang; Meihong Zhu
Journal: Mathematical Problems in Engineering
 (2023)

---

## Abstract

This paper proposes a novel concept of using defect management technology to measure, predict, and optimize the management of the entire software project cycle. It first utilizes the software defect measurement GQIM model and prediction Gompertz model to track and quantify the defects of the entire project cycle. Then, the specific optimization strategy is proposed to manage the core processes of the project management, including project scope management, project time management, project quality management, project human resource management, project communication management, and project risk management. This study solves the quantification problems that are common in the current software project management process, such as complex testing procedures, high defect repair costs, and high communication costs. Furthermore, it contributes to promote the overall level of project management in the software industry. Taking the SDLM’s electronic banking software project management as an example, the various management quality indicators before and after the optimization of the project management process strongly indicate that using software defect management technology to optimize the software project management process is feasible and effective.


---

## Body

## 1. Introduction

With the advent of the era of big data and intelligence, the complexity of software development and software functions is increasing dramatically. In addition, with the development of the big data and artificial intelligence, the software project team is getting bigger since software project management has become more prominent.Different from physical projects, software development has few requirements for physical resources; so, a key resource of software development is software developers. The outputs of the software project are generally application programs and documents. There are no material results similar to entities such as buildings or bridges. Therefore, compared with other types of projects, the project management methods required for software projects are very specific. Software project management is more about managing the process.Compared with other industries with relatively complete project management theory, the development and practice of software project management theory are still in the exploratory stage. The main research on software project management includes the following: (1) Research on software development methods, such as Cleanroom [1], Extreme programming XP [2], Scrum [3, 4], DSDM [5] (Dynamic systems development method), FDD [6] (Feature Driven development), etc. (2) Research on managing the software development process via Capability Maturity Model CMM and CMMI [7, 8]. (3) Research on software project life cycle models, such as waterfall model [9], iterative model, incremental model [10, 11], and spiral model [12]. However, there are limited studies on the optimization of software project management processes using defect management.Software Defect Management (SDM) refers to the tracking and management of identifying, confirming, locating, modifying, and closing the defects in the software life cycle [13]. According to the research in recent years, analysis on SDM mainly focuses on the establishment and application of SDM and SDP models, such as the following:(1)
Improving the measurement models [14, 15] (e.g., CMMI, GQM, GQIM, and so on).CMMI is a successful and widely used software process improvement model, which provides a canonical process for enterprises to implement software measurement and control, and improve software project process. However, there are still some problems in the implementation process of this model. For example, the CMMI model describes the goals and requirements of software measurement and analysis but does not specify how to establish and implement these measurement processes.GQM measurement is a model that define software measurement with the goal-driven thinking. By dividing the measurement structure into three layers, the model corresponds the enterprise objective to the project objective data that needs to be collected. Although the GQM model is simple and convenient, there will be situations in the practical application that the measurement and the problem do not correspond well. This model is especially not suitable for some small or medium-sized enterprises, because they often lack financial and technical support, have larger turnover of personnel, and have less risk tolerance capacity.GQIM model is an improved GQM model. An indicator I is introduced between questionQ and measurement M on the basis of the GQM model, which can directly reflect the question. It is a measurement model driven by both goal G and information. It can avoid the limitation caused by GQM model that the problems and reasons cannot be found in time during the process of implementing measurement.(2)
Analyzing defect prediction through delayed S-curve and deformed S-curve [16] and Saving test time and test resources by improving the performance of software defect model [17, 18], especially Gompertz model.Gompertz model is one of the most popular S-curve distribution models, originally proposed by Gompertz (1825) as a model to describe population extinction. The tendency of the Gompertz curve is characterized by a slow growth at the beginning, and then an increasing acceleration [19]. When it reaches a certain level, the growth rate gradually decreases, and finally approaches a horizontal line. At the early test stage of each iteration of the software project, the defects found in the initial stage are limited since the testers are unfamiliar with the newly added functions. When testers start to fit into the new functions, the test efficiency will be improved. However, at the late stage of the test, the defects will be more insidious and thus increase the test difficulty. The growth rate of the defects found in the later test will grow slowly and even steadily. In the process of software testing, the growth tendency of defects test is a typical S-shaped curve, which satisfies the application conditions of Gompertz growth model.Gompertz model provides a good quantitative tool for quality evaluation and testing process evaluation of software product, and provides a theoretical basis for reasonable arrangement of test activities. The quantitative prediction of software product quality and testing process can be realized based on Gompertz model, and it also can provide a basis to determine whether the testing activity is finished.Defect management runs through the entire life cycle of a software project. During the early stage of project development, SDM analyzes the defect trend chart or uses related methods to identify whether the testing stage can be completed, to help the project team grasp the project process from a macro perspective to achieve long-term optimization. Besides, SDM forms a defect management experience library, which can be shared with the organizations to provide experience support for future project management. SDM can also learn from the experience and lessons through defect analysis to improve the firm-level software process, and finally becomes an organization-level asset. Thus, valid defect management can provide a reliable guarantee for the smooth implementation of the software project.Quantitative management and continuous optimization of software projects have become a developing trend of software industry. This paper proposes a novel idea that employs defect management technology to measure, predict and optimize the whole software project cycle: software defect measurement model GQIM is used to count the measurement index values from multiple dimensions respectively, including defect density, defect severity, proficiency of developers and testers and progress of the project; the Gompertz model is adopted to predict the effectiveness of software testing, track the defects and quantify the management of the entire project cycle.In Section2, the theory of GQIM model and Gompertz model are described. Section 3 carries out a concrete design to the proposed idea of this paper; In Section 4, SDLM e-bank software project management is taken as an example. The project management process optimization measures based on defect management are specifically analyzed in the process of project execution and project supervision. Section 5 compares and analyzes the value change of measurement index before and after project optimization, and shows the effect of optimization. Section 6 summarizes our work and future research direction.


## 2. Theoretical Background

SDM includes defect tracking and defect measurement. Defect tracking is based on bugs which manages the entire software life cycle from the start to the end of the project. In this process, it is required to track defect situation, monitor the modification process, and verify the modification results as well as conduct defect statistics. Defect measurement is to measure a series of technical indicators useful for project management and data support to provide project managers with the convincing information. The main theoretical models of defect management and the defect tracking tool used in our research are as follows.


### 2.1. Software Defect Measurement (SDM) Model–GQIM

The Software Engineering Institute at Carnegie Mellon University (1996) proposed to use the Goal Question Indicator Metric (GQIM) model to define the goal-related metrics. The core of GQIM is gradually to be optimized from top to bottom oriented by goals. The GQIM measurement model adds indicators on the basis of GQM, including four layers: goal layer, problem layer, indicator, and measurement layer [20, 21]. More specifically, the goal layer defines the object, focus, measurement purpose and target environment. The problem layer refines each goal into a set of questions, describing the evaluation goal or completing method. The indicator constructs the connection between the problem and the measurement data. It defines the indicator according to the problem as well as determining the metric element by the indicator. The metric layer quantifies the description of the problem, and establishes a one-to-one correspondence to clarify each metric item. This paper mainly uses the GQIM measurement model to measure software defects, as shown in Figure 1.Figure 1
Software defect metric GQIM model.The significance of GQIM compared with GQM is that the indicator is available, the problem can be found quickly according to the indicator in the software project, which can save time and cost for the project and improve efficiency. In conclusion, GQIM improves the reliability of analysis results, and has better practicability and credibility [22, 23].


### 2.2. Software Defect Prediction (SDP) Model–Gompertz

Benjamin Gompertz, a British mathematician and statistician, put forward the Gompertz curve through a large number of observations and studies. This curve reflects the process of the occurrence, development, maturity and decay of things. It has a “s” shape on the geometric curve and has been widely used as a mathematical model in the fields of environment, ecology, demography economy and software defect prediction. Gompertz reliability growth model is the most commonly common data processing model when the data to be processed contains characteristics of different stages and times. Gompertz model is generally suitable for processing data with smooth change curve. Gompertz model can be formulated as,(1)R=Cabt,0%<C<100%,0<a<1,0<b<1. Where R represents the reliability of the software product with the test time t and 0 < R < 100%, C represents the extremum of the product R when t ⟶ ∞, b represents the growth rate of the curve. And the larger the b is, the slower the reliability grows, and vice versa. Further, equation (1) can also be rewritten as:(2)IfR=N∙CabtY=N∙R,K=N∙C,soY=Kabt.Where Y is the total number of software defects found, K represents the number of tested defects, when K is the total number of all the defects that can be discovered theoretically, and b represents the increased speed of the defect testing. Different values of parameters a, b, and K will cause different shapes and changing trends, as shown in Figure 2, (a) ln a < 0, 0 < b < 1, (b) ln a < 0, b > 1, (c) ln a > 0, 0 < b < 1, (d) ln a > 0, b > 1.Figure 2
Shape and trend diagram of Gompertz model. Where there are four conditions of Gompertz curve.
(a)(b)(c)(d)Gompertz model is widely used in software defect prediction, it has a relatively high prediction accuracy of general defect data, and simple to use. Gompertz model is mainly used to analyze the adequacy of software testing and software defect discovery rate. The principle behind this model is using Gompertz function to draw the fitting curve, and then draw the accumulated defect curve of actual test process; comparing the two curves to analyze the test adequacy and software defect discovery rate [24, 25].


### 2.3. Software Defect Tracking Tool–ClearQuest

The software defect tracking management tool used in this study is IBM ClearQuest. Software defects tracking can be divided into some stages like “submitted, confirmed, assigned, processed, designed, applied for release, issued, closed, subsequent development and problem termination.” The process of ClearQuest tool defect tracking is shown in Figure3:Figure 3
Flowchart of ClearQuest defect tracking management.The demand confirmation is conducted by the party in quest. The CQ allocation is performed by project manager. Development review includes design review and code review. According to the overall human resource allocation of the project, the personnel participating in the review (design review, code review, test case or result review) must be the experts in this industry.


## 2.1. Software Defect Measurement (SDM) Model–GQIM

The Software Engineering Institute at Carnegie Mellon University (1996) proposed to use the Goal Question Indicator Metric (GQIM) model to define the goal-related metrics. The core of GQIM is gradually to be optimized from top to bottom oriented by goals. The GQIM measurement model adds indicators on the basis of GQM, including four layers: goal layer, problem layer, indicator, and measurement layer [20, 21]. More specifically, the goal layer defines the object, focus, measurement purpose and target environment. The problem layer refines each goal into a set of questions, describing the evaluation goal or completing method. The indicator constructs the connection between the problem and the measurement data. It defines the indicator according to the problem as well as determining the metric element by the indicator. The metric layer quantifies the description of the problem, and establishes a one-to-one correspondence to clarify each metric item. This paper mainly uses the GQIM measurement model to measure software defects, as shown in Figure 1.Figure 1
Software defect metric GQIM model.The significance of GQIM compared with GQM is that the indicator is available, the problem can be found quickly according to the indicator in the software project, which can save time and cost for the project and improve efficiency. In conclusion, GQIM improves the reliability of analysis results, and has better practicability and credibility [22, 23].


## 2.2. Software Defect Prediction (SDP) Model–Gompertz

Benjamin Gompertz, a British mathematician and statistician, put forward the Gompertz curve through a large number of observations and studies. This curve reflects the process of the occurrence, development, maturity and decay of things. It has a “s” shape on the geometric curve and has been widely used as a mathematical model in the fields of environment, ecology, demography economy and software defect prediction. Gompertz reliability growth model is the most commonly common data processing model when the data to be processed contains characteristics of different stages and times. Gompertz model is generally suitable for processing data with smooth change curve. Gompertz model can be formulated as,(1)R=Cabt,0%<C<100%,0<a<1,0<b<1. Where R represents the reliability of the software product with the test time t and 0 < R < 100%, C represents the extremum of the product R when t ⟶ ∞, b represents the growth rate of the curve. And the larger the b is, the slower the reliability grows, and vice versa. Further, equation (1) can also be rewritten as:(2)IfR=N∙CabtY=N∙R,K=N∙C,soY=Kabt.Where Y is the total number of software defects found, K represents the number of tested defects, when K is the total number of all the defects that can be discovered theoretically, and b represents the increased speed of the defect testing. Different values of parameters a, b, and K will cause different shapes and changing trends, as shown in Figure 2, (a) ln a < 0, 0 < b < 1, (b) ln a < 0, b > 1, (c) ln a > 0, 0 < b < 1, (d) ln a > 0, b > 1.Figure 2
Shape and trend diagram of Gompertz model. Where there are four conditions of Gompertz curve.
(a)(b)(c)(d)Gompertz model is widely used in software defect prediction, it has a relatively high prediction accuracy of general defect data, and simple to use. Gompertz model is mainly used to analyze the adequacy of software testing and software defect discovery rate. The principle behind this model is using Gompertz function to draw the fitting curve, and then draw the accumulated defect curve of actual test process; comparing the two curves to analyze the test adequacy and software defect discovery rate [24, 25].


## 2.3. Software Defect Tracking Tool–ClearQuest

The software defect tracking management tool used in this study is IBM ClearQuest. Software defects tracking can be divided into some stages like “submitted, confirmed, assigned, processed, designed, applied for release, issued, closed, subsequent development and problem termination.” The process of ClearQuest tool defect tracking is shown in Figure3:Figure 3
Flowchart of ClearQuest defect tracking management.The demand confirmation is conducted by the party in quest. The CQ allocation is performed by project manager. Development review includes design review and code review. According to the overall human resource allocation of the project, the personnel participating in the review (design review, code review, test case or result review) must be the experts in this industry.


## 3. Research Design

Due to the complexity and abstraction of software projects, errors or defects may occur in all stages of the software project life cycle. Therefore, software defect management should run through all stages of the software project life cycle instead of being taken as an independent stage after software development. The software defect management should be introduced into project management from the startup of a project, this will help finding defects in time, and will effectively prevent defects, thereby significantly reduces the number of software defects, improves the quality of software. Moreover, it will greatly shorten the development cycle, and reduce the cost of software development.This study proposes that defect management technology can be used to measure, predict and optimize the entire software project cycle, which provides a new idea for software project managers to optimize the management process through data quantification. It can effectively solve the problems in the current software project management process, such as, complicated testing process, high cost of defect fixing, high cost of communication and difficult quantification of test results [26, 27].Software project management includes the main contents of project management, such as scope, schedule, quality, human resources, communication, risks and so on. Among them defect management is the core of the software project development process. It runs through the entire project process and relates with staff members, tools, and source codes. Integrating and optimizing the main content of software project management by defect management are the focus of our research.


### 3.1. Software Project Defect Measurement

The definition of a software project defect measurement aims to count the overall defects, and effectively track and manage the defects as well as obtain the quality of the project in real-time. We adopt the commonly used ODC orthogonal defect classification method to analyze the defect type, severity and tendency curve of the project.


### 3.2. Software Project Defect Prediction

In our research, we apply the Gompertz model to predict project defects, which verifies the validity of the defect data statistics at the current test stage. Besides, it also estimates the number of hidden defects and the amount of testing work required in future so that the overall quality of the project can be evaluated based on these statics. Therefore, it shows instructive significance for future project test.


### 3.3. Software Project Management Optimization

#### 3.3.1. Defect Management in Project Scope Management

The main tasks of project scope management include clarifying project boundaries, monitoring project execution, and preventing the spread of project scope. The defects mainly include two categories, i.e., software errors and the changes of customer’s requirements. Therefore, project managers regard changes of customer requirement as the improvement or optimization of defects to process simultaneously. In the defect processing process, we can obtain the input man-hours and costs by confirming the changed defects, tracking the modification process and verifying the modification results. In addition, the workload of each link and project resources are calculated during the process, and thus contribute to improving the project management.


#### 3.3.2. Defect Management in Project Time Management

Project time management refers to the management of the progress of each stage and the completion period of the project during project process. It mainly aims to split and sort project activities, and estimate the duration. If the submitted defects are regarded as tasks to be processed, and the division of the severity and priority of the defects are regarded as the priority of task setting, it can be seen that the defect management mode and project time management are interoperable via comparative analysis. Therefore, the unified processing of defect management can facilitate the orderly progress of project development.


#### 3.3.3. Defect Management in Project Quality Management

Project quality management requires the promise of project demand should be fulfilled, including product requirements are met and confirmed. The CMMI model divides capability maturity of software into five levels: the initial level finds and corrects defects; the second level is applied to a single project process; the third level analyzes and summarizes the defect management methods within the project; the fourth level measures the defect management data and achieves quantitative management; the fifth level improves the software process capability within the organization, and conducts continuous improvement to prevent defects. The model includes the basic elements of the entire production cycle such as product demand proposal, design, development, coding, testing, etc. It is also an organic synthesis of process improvement. All of them have a clear definition of defect management.


#### 3.3.4. Defect Management in Project Human Resource Management

Human resources are playing an essential role in all activities in the process of a project. The purpose of project human resource management is to plan and set up a project team according to the needs of the project, and provide effective guidance and management to the team so that the complishment of project tasks and the realization of project goals can be ensured. The workloads generated in the defect management process include demand confirmation, defect repairing time, defect closure time, and defect reviewing time. The production efficiency and testing efficiency of developers can be evaluated according to the cost of human resources, the actual workload, and the number of lines of code. Therefore, the knowledge level of project team members can be revised.


#### 3.3.5. Defect Management in Project Communication Management

The software project management process requires constant communication, and project communication management must ensure that the project information is generated, collected, distributed, stored, and finally processed. Using defect management as a communication channel and establishing a unified communication mechanism reduce the number of face-to-face communication and avoid distortion of information transmission. In addition, developers and testers pay attention to tasks and update tasks immediately to ensure the timeliness of communication by using defect management tools to assign tasks. At the same time, project team members perform their duties, to speed up the project process and optimize the project communication management process.


#### 3.3.6. Defect Management in Project Risk Management

Project risk includes threats to project goals and opportunities to promote project goals. The goals of risk management are to increase the probability and impact of active practice and reduce the probability and impact of negative project events. Risk management is similar to other project management, which needs to be updated in the entire project process. Defect management and software quality risks are mostly related, and the quality risk plans and thresholds can be formulated at the beginning of the project. When the defect density reaches the warning signal or the defect is not completed within the specified time, it will remind the project team that there is a risk and the risk should be handled immediately.


## 3.1. Software Project Defect Measurement

The definition of a software project defect measurement aims to count the overall defects, and effectively track and manage the defects as well as obtain the quality of the project in real-time. We adopt the commonly used ODC orthogonal defect classification method to analyze the defect type, severity and tendency curve of the project.


## 3.2. Software Project Defect Prediction

In our research, we apply the Gompertz model to predict project defects, which verifies the validity of the defect data statistics at the current test stage. Besides, it also estimates the number of hidden defects and the amount of testing work required in future so that the overall quality of the project can be evaluated based on these statics. Therefore, it shows instructive significance for future project test.


## 3.3. Software Project Management Optimization

### 3.3.1. Defect Management in Project Scope Management

The main tasks of project scope management include clarifying project boundaries, monitoring project execution, and preventing the spread of project scope. The defects mainly include two categories, i.e., software errors and the changes of customer’s requirements. Therefore, project managers regard changes of customer requirement as the improvement or optimization of defects to process simultaneously. In the defect processing process, we can obtain the input man-hours and costs by confirming the changed defects, tracking the modification process and verifying the modification results. In addition, the workload of each link and project resources are calculated during the process, and thus contribute to improving the project management.


### 3.3.2. Defect Management in Project Time Management

Project time management refers to the management of the progress of each stage and the completion period of the project during project process. It mainly aims to split and sort project activities, and estimate the duration. If the submitted defects are regarded as tasks to be processed, and the division of the severity and priority of the defects are regarded as the priority of task setting, it can be seen that the defect management mode and project time management are interoperable via comparative analysis. Therefore, the unified processing of defect management can facilitate the orderly progress of project development.


### 3.3.3. Defect Management in Project Quality Management

Project quality management requires the promise of project demand should be fulfilled, including product requirements are met and confirmed. The CMMI model divides capability maturity of software into five levels: the initial level finds and corrects defects; the second level is applied to a single project process; the third level analyzes and summarizes the defect management methods within the project; the fourth level measures the defect management data and achieves quantitative management; the fifth level improves the software process capability within the organization, and conducts continuous improvement to prevent defects. The model includes the basic elements of the entire production cycle such as product demand proposal, design, development, coding, testing, etc. It is also an organic synthesis of process improvement. All of them have a clear definition of defect management.


### 3.3.4. Defect Management in Project Human Resource Management

Human resources are playing an essential role in all activities in the process of a project. The purpose of project human resource management is to plan and set up a project team according to the needs of the project, and provide effective guidance and management to the team so that the complishment of project tasks and the realization of project goals can be ensured. The workloads generated in the defect management process include demand confirmation, defect repairing time, defect closure time, and defect reviewing time. The production efficiency and testing efficiency of developers can be evaluated according to the cost of human resources, the actual workload, and the number of lines of code. Therefore, the knowledge level of project team members can be revised.


### 3.3.5. Defect Management in Project Communication Management

The software project management process requires constant communication, and project communication management must ensure that the project information is generated, collected, distributed, stored, and finally processed. Using defect management as a communication channel and establishing a unified communication mechanism reduce the number of face-to-face communication and avoid distortion of information transmission. In addition, developers and testers pay attention to tasks and update tasks immediately to ensure the timeliness of communication by using defect management tools to assign tasks. At the same time, project team members perform their duties, to speed up the project process and optimize the project communication management process.


### 3.3.6. Defect Management in Project Risk Management

Project risk includes threats to project goals and opportunities to promote project goals. The goals of risk management are to increase the probability and impact of active practice and reduce the probability and impact of negative project events. Risk management is similar to other project management, which needs to be updated in the entire project process. Defect management and software quality risks are mostly related, and the quality risk plans and thresholds can be formulated at the beginning of the project. When the defect density reaches the warning signal or the defect is not completed within the specified time, it will remind the project team that there is a risk and the risk should be handled immediately.


## 3.3.1. Defect Management in Project Scope Management

The main tasks of project scope management include clarifying project boundaries, monitoring project execution, and preventing the spread of project scope. The defects mainly include two categories, i.e., software errors and the changes of customer’s requirements. Therefore, project managers regard changes of customer requirement as the improvement or optimization of defects to process simultaneously. In the defect processing process, we can obtain the input man-hours and costs by confirming the changed defects, tracking the modification process and verifying the modification results. In addition, the workload of each link and project resources are calculated during the process, and thus contribute to improving the project management.


## 3.3.2. Defect Management in Project Time Management

Project time management refers to the management of the progress of each stage and the completion period of the project during project process. It mainly aims to split and sort project activities, and estimate the duration. If the submitted defects are regarded as tasks to be processed, and the division of the severity and priority of the defects are regarded as the priority of task setting, it can be seen that the defect management mode and project time management are interoperable via comparative analysis. Therefore, the unified processing of defect management can facilitate the orderly progress of project development.


## 3.3.3. Defect Management in Project Quality Management

Project quality management requires the promise of project demand should be fulfilled, including product requirements are met and confirmed. The CMMI model divides capability maturity of software into five levels: the initial level finds and corrects defects; the second level is applied to a single project process; the third level analyzes and summarizes the defect management methods within the project; the fourth level measures the defect management data and achieves quantitative management; the fifth level improves the software process capability within the organization, and conducts continuous improvement to prevent defects. The model includes the basic elements of the entire production cycle such as product demand proposal, design, development, coding, testing, etc. It is also an organic synthesis of process improvement. All of them have a clear definition of defect management.


## 3.3.4. Defect Management in Project Human Resource Management

Human resources are playing an essential role in all activities in the process of a project. The purpose of project human resource management is to plan and set up a project team according to the needs of the project, and provide effective guidance and management to the team so that the complishment of project tasks and the realization of project goals can be ensured. The workloads generated in the defect management process include demand confirmation, defect repairing time, defect closure time, and defect reviewing time. The production efficiency and testing efficiency of developers can be evaluated according to the cost of human resources, the actual workload, and the number of lines of code. Therefore, the knowledge level of project team members can be revised.


## 3.3.5. Defect Management in Project Communication Management

The software project management process requires constant communication, and project communication management must ensure that the project information is generated, collected, distributed, stored, and finally processed. Using defect management as a communication channel and establishing a unified communication mechanism reduce the number of face-to-face communication and avoid distortion of information transmission. In addition, developers and testers pay attention to tasks and update tasks immediately to ensure the timeliness of communication by using defect management tools to assign tasks. At the same time, project team members perform their duties, to speed up the project process and optimize the project communication management process.


## 3.3.6. Defect Management in Project Risk Management

Project risk includes threats to project goals and opportunities to promote project goals. The goals of risk management are to increase the probability and impact of active practice and reduce the probability and impact of negative project events. Risk management is similar to other project management, which needs to be updated in the entire project process. Defect management and software quality risks are mostly related, and the quality risk plans and thresholds can be formulated at the beginning of the project. When the defect density reaches the warning signal or the defect is not completed within the specified time, it will remind the project team that there is a risk and the risk should be handled immediately.


## 4. The Experiment of SDLM’S E-Banking Software Project

### 4.1. The Current Status of SDLM’s e-Banking Software Project

#### 4.1.1. Project Framework

The project framework of SDLM’s e-banking software project is illustrated as Figure4.Figure 4
Architecture of SDLM’s E-banking software project.SDLM’s e-banking software project mainly develops the bank’s public business. The main functional modules include enterprise online banking customer contract management, enterprise online banking group management, enterprise online banking major information changes, bank-enterprise direct customer management and other business management modules. The functional modules under development include enterprise e-banking generation of receipt printing, enterprise online banking transaction processing, entrustment and approval of enterprise e-banking group accounts, and so on. The functional modules developed in the early stage have been tested in member banks.


#### 4.1.2. Problems in Project Management

The project team adopts an iterative development model. After investigation of project team management and interviews with internal members, we found that the main problems in the process of software project management are as follows:(a)
The turnover of project team members is relatively high, resulting in the delay of the overall progress of the project (which is also a common problem in software industries).(b)
Unified encoding standards and technical review principles are not defined in the early project management process.(c)
There are too many ClearQuest (CQ) proposed in the project, and new functions have not been developed, resulting in a very tight project period.(d)
New employees account for 20% of all members in the project team, resulting in a low efficiency of the project team.(e)
The project team has a large number of CQ backtracking and modification, which takes up a lot of test time and leads to slow test progress. Besides, due to the tight schedule, testers have no time to arrange regression tests and enter a vicious circle.(f)
Inadequate requirement analysis in the project start-up stage leads to a large number of optimization problems raised by member banks during acceptance. It mainly exists in the use of the function, and provides a warning to the project team.


### 4.2. The Comprehensive Defect Measurement and Analysis of SDLM’s e-Banking Software Project

#### 4.2.1. Project Definition Objectives and Overall Defect Statistics

SDLM’s development and testing work are counted according to CQ, and the function code is based on the checked-in and checked-out of CQ. The main attributes of CQ include the proposed bank, proposed person, source of problems, severity, requirement type, developer, tester and status. The objectives of SDLM’s e-banking software project are shown in Table1, and the overall defect statistics are shown in Table 2:Table 1
Project index values defined by SDLM.
Indicator nameIndicator upper limitIndicator lower limitCoding productivity0.60.03Unit coverage rate10.9Project start-up rate10.85Defect return rate0.120.04Project defect rate0.039.98Code (design) review discovery rate0.660.03Defect removal rate10.9Test productivity3.61.03Table 2
SDLM e-banking software project overall defect statistics.
Metric nameIndicator valueDefect density1.3Defect return rate (%)18.42Defect removal rate (%)99.04Unit test coverage rate (%)90Project start-up rate (%)99.04Percentage of defective CQ (%)54.57Percentage of CQ affecting putting into use (%)37.33Test productivity3.13Test result review rate (%)2.37Average time to defect closure13.58Coding productivity0.79Design review discovery rate (%)5.2Code review discovery rate (%)3.64Test case review discovery rate (%)78.72Software productivity17184.07Defect rate per project team member (%)91.63Test case execution rate72.81Test coverage rate8.52Average time to repair defect17.94Average time to defect review8.8The important indicators analysis for these two tables as following.The defect return rate is 18.42% in Table2, which exceeds the upper limit of 12%, indicating that the defect escape rate during the development phase of the project is relatively high. Defect return rate reflects the tester’s testing ability as well as the developer’s coding and unit testing abilities. The higher the value, the more problems the tester finds.Coding productivity is high, but the discovery rate of design and code review is low. The main reasons can be summarized as follows. (a) unit testing is not abundant at the early stage of the project. (b) most developers do not carry out unit testing. (c) the unit self-testing is not qualified. (d) Due to the project time limitation, the coding speed is improved, but the quality is weakened. (e) The preliminary demand survey is not in enough detail; the business is not fully understood. And thus, the overview connection between functional modules could not be grasped, which causes problems of functional connection.Unit coverage, design and code review problem detection rate and test result review rate are all within the predefined value range, but only slightly higher than the project lower limit. Defect repair time, defect closing time and defect review time reflect the whole process of defects and reveal the response ability of developers, testers and CQ person to deal with defects. The shorter the time of this indicator, the timelier the treatment and the stronger the strain capacity. According to the indicators in Table2, the staff of all positions in SDLM needs to be strengthened.


#### 4.2.2. Tracking Management of Project Defects

In Figures5–7, we analyze the defect type, defect severity and defect trend of the project using the ODC orthogonal defect classification method.Figure 5
Distribution of defective requirement types in SDLM’s E-banking software project.Figure 6
Distribution of defect severity of SDLM’s E-banking software project.Figure 7
Trend of defect in SDLM’s E-banking software project.Specifically, it can be seen from Figure5 that the defect CQ account for 54.57%, which exceeds half of the defect problem during the entire project development, indicating that the overall development coding quality of the project is low. In addition, new business and business adjustment types also account for a large part, which indicates that requirements analyst should pay attention to the different needs of the industry and the logical way of function realization as soon as possible.In Figure6, the affect rate of CQ is 37.33%, which shows that this type of defect should be focused on to avoid affecting the entire project.Figure7 shows a chart of the defect CQ trend from the beginning to the current stage of the project, which is used to analyze the overall progress of the project. The figure shows the four conditions, i.e., submitted, confirmed, assigned and closed defect CQ tracking curves.


### 4.3. Defect Prediction of SDLM Company’s Electronic Banking Software Project

According to the test time, test workload and the number of CQs found (statistics per day), the cumulative test workload and the cumulative found defects can be calculated, as shown in Table3.Table 3
Cumulative number of defects in the testing phase of the project.
Raw dataCumulative valuePredicted valueTimeTest input workloadNumber of defects found in this testCumulative test input workloadCumulative number of defectsPredicted value of cumulative number of defects2020/6/816516.00577.32020/6/114120.00678.52020/6/273323.00979.3………………2021/3/121131516.00710696.12021/3/131031526.00713698.82021/3/18811534.00714700.92021/3/201621550.00716705.12021/3/221121561.00718707.72021/3/25421565.00720708.82021/3/27211567.00721709.3The data in Table3 were substituted into equation (2), Matlab was used for calculation and curve fitting with Levenberg-Marquardt General and Global Optimization Algorithm. We got the parameters of Gompertz that meet the convergence criteria are as Figure 8: root mean square error (RMSE): 21.1526; error sum of squares (SSE): 75616.2097; related coefficient (R): 0.9949; square of correlation coefficient (R2): 0.9898; coefficient of determination (DC): 0.9897; chi-square (Chi-Square): 371.4746; F-Statistic: 16293.3467. The best estimate obtained of the parameters: K = 901.4255, a = 0.0808, b = 0.9985 [28].Figure 8
Results of Gompertz model parameter fitting.We can calculate the parameters of the Gompertz model by submitting the values into equation (2) using Matlab tools. The fitting curve is shown in Figure 8 (Y: cumulative defect prediction value; X: cumulative testing hours). According to the calculation, we can get Y = 901.4255∗0.0808^0.9985^t. Setting the regret rate of defect to 3%, in order to achieve 97% defect removal rate, we still need the invested workload and primed number of CQ, as shown in Figure 9. (Y: cumulative defect prediction value; X: cumulative testing hours) [29, 30].Figure 9
Fitting curve of Gompertz model using matlab tools.According to Table4, the number of required tests is 91.8 times, and the expected test workload is 520.2 hours. Besides, from Figure 7 it can be seen that the growth rate of defects in the initial stage of the project is relatively stable. When the test workload reaches 200 manhours, the growth rate of defects continues to rise for a period of time, and then gradually becomes more stable in the later period. However, the defects began to increase suddenly at the working time of 1300. It indicates that the defects in the current project have not reached the stable stage, and the project team needs to increase the intensity and depth of testing.Table 4
Table of the predictive analysis using Gompertz model.
Predictive analysis using gompertz modelParameters of the modelIdentification of rapidly rising inflection pointsDefect objective value calculationPositive prediction of objectiveK (the maximum of y)901.4255Inflection:t614.59Omissive defect rate objective3%Estimated additional tests times91.80a0.0808Inflection:y331.62Objective defect numbers874.00Estimated additional works520.20b0.9985Sample size169Defect numbers that should remain27.43Negative prediction of objectiveyt=KabtFound defect numbers726.00Estimated additional tests times2771.43Discrepancy with objective defect numbers153.00Estimated additional works15704.74


### 4.4. SDLM Company e-Banking Software Project Management Process Optimization

The specific optimization strategies are mainly proposed from the aspects of project scope management, quality management, communication management, human resource management and project risk management.


#### 4.4.1. Optimization of Project Scope Management

Firstly, we should set out the rules of demand change in the project team to control demand change management. Secondly, the document tracking and traceability of proposed demands should be achieved to strictly control the demand change process. Thirdly, it should be ensured that reducing and controlling the scope of the project, and optimizing it for the functional lines with low usage. Fourthly, easy usability issues should be uniformly modified after the confirmed demands, and the developers have no right to refuse. Finally, if there is a dispute between development and testing, we should directly seek confirmation from the requirements analyst.


#### 4.4.2. Optimization of Project Time Management

Firstly, regular project meetings should be arranged every week, and the work summary and progress report are conducted weekly. Secondly, we should formulate unified specifications to reduce defect repair time. Besides, the business needs should not exceed 3 months, and the development and repair time should be controlled within 7 days. Thirdly, defect test closure time cannot exceed 15 days. The CQ test completion rate is required to reach 80% one week before the major version in each month, and all CQs in the last week of the major version must be closed. Finally, we should also adjust the test schedule and increase the number of test rounds to do a comprehensive regression test.


#### 4.4.3. Optimization of Project Quality Management

In order to improve the optimization quality, we list the most valuable issues that should be concerned.(a)
Improve the technical and coding reviews, formulate review specifications and determine review personnel qualifications.(b)
Standard the problem discovery rate and ensure employees with low index values can be reported automatically.(c)
Establish project management procedures and systems, clarify the responsibilities of personnel in each role, and achieve all problems can be traced.(d)
Add code debug gadgets to avoid code bugs, and improve code specifications and quality.(e)
Develop a new testing system. That is all problems will be registered with special test records and no additional CQ optimization will be mentioned. Once the violation operation is discovered, it will be modified immediately.


#### 4.4.4. Optimization of Project Human Resource Management

(a)
Optimize assessment indicators, including defect recall, test efficiency and other indicators into the assessment system.(b)
Re-formulate the performance assessment system and reward and punishment system within the group, and all staff should follow the standard uniformly.(c)
Share the same problem development or test experience in the group to improve department work efficiency.(d)
Testers summarize common problems and report them within the group to assist developers to avoid similar problems.


#### 4.4.5. Optimization of Project Communication Management

(a)
Set up an agile development team to report the work daily or weekly.(b)
Developers or testers (to complete the workload as required) need to work overtime and report the reasons if they cannot complete their tasks.(c)
Establish project tracking frequency, i.e., daily, weekly, monthly or periodically.(d)
The project manager should report to the team leader, and the team leader reports to the department leader.


#### 4.4.6. Optimization of Project Risk Management

(a)
Test content optimization, consider multiple legal person, non-impact test and abnormal scene test cases.(b)
Missed test analysis describes several major classification issues that require everyone to focus on.(c)
Strengthen and deepen the test intensity, increase test rounds, and conduct comprehensive regression testing for all functions.(d)
Analyze the risks listed in the project risk management plan, identify possible high-risk situations in advance and propose effective preventive measures, respond to the thresholds that have exceeded the threshold immediately, and propose countermeasures.(e)
Regression testing needs to count defects on a daily basis in the week before going online, and track and solve the problems immediately.


## 4.1. The Current Status of SDLM’s e-Banking Software Project

### 4.1.1. Project Framework

The project framework of SDLM’s e-banking software project is illustrated as Figure4.Figure 4
Architecture of SDLM’s E-banking software project.SDLM’s e-banking software project mainly develops the bank’s public business. The main functional modules include enterprise online banking customer contract management, enterprise online banking group management, enterprise online banking major information changes, bank-enterprise direct customer management and other business management modules. The functional modules under development include enterprise e-banking generation of receipt printing, enterprise online banking transaction processing, entrustment and approval of enterprise e-banking group accounts, and so on. The functional modules developed in the early stage have been tested in member banks.


### 4.1.2. Problems in Project Management

The project team adopts an iterative development model. After investigation of project team management and interviews with internal members, we found that the main problems in the process of software project management are as follows:(a)
The turnover of project team members is relatively high, resulting in the delay of the overall progress of the project (which is also a common problem in software industries).(b)
Unified encoding standards and technical review principles are not defined in the early project management process.(c)
There are too many ClearQuest (CQ) proposed in the project, and new functions have not been developed, resulting in a very tight project period.(d)
New employees account for 20% of all members in the project team, resulting in a low efficiency of the project team.(e)
The project team has a large number of CQ backtracking and modification, which takes up a lot of test time and leads to slow test progress. Besides, due to the tight schedule, testers have no time to arrange regression tests and enter a vicious circle.(f)
Inadequate requirement analysis in the project start-up stage leads to a large number of optimization problems raised by member banks during acceptance. It mainly exists in the use of the function, and provides a warning to the project team.


## 4.1.1. Project Framework

The project framework of SDLM’s e-banking software project is illustrated as Figure4.Figure 4
Architecture of SDLM’s E-banking software project.SDLM’s e-banking software project mainly develops the bank’s public business. The main functional modules include enterprise online banking customer contract management, enterprise online banking group management, enterprise online banking major information changes, bank-enterprise direct customer management and other business management modules. The functional modules under development include enterprise e-banking generation of receipt printing, enterprise online banking transaction processing, entrustment and approval of enterprise e-banking group accounts, and so on. The functional modules developed in the early stage have been tested in member banks.


## 4.1.2. Problems in Project Management

The project team adopts an iterative development model. After investigation of project team management and interviews with internal members, we found that the main problems in the process of software project management are as follows:(a)
The turnover of project team members is relatively high, resulting in the delay of the overall progress of the project (which is also a common problem in software industries).(b)
Unified encoding standards and technical review principles are not defined in the early project management process.(c)
There are too many ClearQuest (CQ) proposed in the project, and new functions have not been developed, resulting in a very tight project period.(d)
New employees account for 20% of all members in the project team, resulting in a low efficiency of the project team.(e)
The project team has a large number of CQ backtracking and modification, which takes up a lot of test time and leads to slow test progress. Besides, due to the tight schedule, testers have no time to arrange regression tests and enter a vicious circle.(f)
Inadequate requirement analysis in the project start-up stage leads to a large number of optimization problems raised by member banks during acceptance. It mainly exists in the use of the function, and provides a warning to the project team.


## 4.2. The Comprehensive Defect Measurement and Analysis of SDLM’s e-Banking Software Project

### 4.2.1. Project Definition Objectives and Overall Defect Statistics

SDLM’s development and testing work are counted according to CQ, and the function code is based on the checked-in and checked-out of CQ. The main attributes of CQ include the proposed bank, proposed person, source of problems, severity, requirement type, developer, tester and status. The objectives of SDLM’s e-banking software project are shown in Table1, and the overall defect statistics are shown in Table 2:Table 1
Project index values defined by SDLM.
Indicator nameIndicator upper limitIndicator lower limitCoding productivity0.60.03Unit coverage rate10.9Project start-up rate10.85Defect return rate0.120.04Project defect rate0.039.98Code (design) review discovery rate0.660.03Defect removal rate10.9Test productivity3.61.03Table 2
SDLM e-banking software project overall defect statistics.
Metric nameIndicator valueDefect density1.3Defect return rate (%)18.42Defect removal rate (%)99.04Unit test coverage rate (%)90Project start-up rate (%)99.04Percentage of defective CQ (%)54.57Percentage of CQ affecting putting into use (%)37.33Test productivity3.13Test result review rate (%)2.37Average time to defect closure13.58Coding productivity0.79Design review discovery rate (%)5.2Code review discovery rate (%)3.64Test case review discovery rate (%)78.72Software productivity17184.07Defect rate per project team member (%)91.63Test case execution rate72.81Test coverage rate8.52Average time to repair defect17.94Average time to defect review8.8The important indicators analysis for these two tables as following.The defect return rate is 18.42% in Table2, which exceeds the upper limit of 12%, indicating that the defect escape rate during the development phase of the project is relatively high. Defect return rate reflects the tester’s testing ability as well as the developer’s coding and unit testing abilities. The higher the value, the more problems the tester finds.Coding productivity is high, but the discovery rate of design and code review is low. The main reasons can be summarized as follows. (a) unit testing is not abundant at the early stage of the project. (b) most developers do not carry out unit testing. (c) the unit self-testing is not qualified. (d) Due to the project time limitation, the coding speed is improved, but the quality is weakened. (e) The preliminary demand survey is not in enough detail; the business is not fully understood. And thus, the overview connection between functional modules could not be grasped, which causes problems of functional connection.Unit coverage, design and code review problem detection rate and test result review rate are all within the predefined value range, but only slightly higher than the project lower limit. Defect repair time, defect closing time and defect review time reflect the whole process of defects and reveal the response ability of developers, testers and CQ person to deal with defects. The shorter the time of this indicator, the timelier the treatment and the stronger the strain capacity. According to the indicators in Table2, the staff of all positions in SDLM needs to be strengthened.


### 4.2.2. Tracking Management of Project Defects

In Figures5–7, we analyze the defect type, defect severity and defect trend of the project using the ODC orthogonal defect classification method.Figure 5
Distribution of defective requirement types in SDLM’s E-banking software project.Figure 6
Distribution of defect severity of SDLM’s E-banking software project.Figure 7
Trend of defect in SDLM’s E-banking software project.Specifically, it can be seen from Figure5 that the defect CQ account for 54.57%, which exceeds half of the defect problem during the entire project development, indicating that the overall development coding quality of the project is low. In addition, new business and business adjustment types also account for a large part, which indicates that requirements analyst should pay attention to the different needs of the industry and the logical way of function realization as soon as possible.In Figure6, the affect rate of CQ is 37.33%, which shows that this type of defect should be focused on to avoid affecting the entire project.Figure7 shows a chart of the defect CQ trend from the beginning to the current stage of the project, which is used to analyze the overall progress of the project. The figure shows the four conditions, i.e., submitted, confirmed, assigned and closed defect CQ tracking curves.


## 4.2.1. Project Definition Objectives and Overall Defect Statistics

SDLM’s development and testing work are counted according to CQ, and the function code is based on the checked-in and checked-out of CQ. The main attributes of CQ include the proposed bank, proposed person, source of problems, severity, requirement type, developer, tester and status. The objectives of SDLM’s e-banking software project are shown in Table1, and the overall defect statistics are shown in Table 2:Table 1
Project index values defined by SDLM.
Indicator nameIndicator upper limitIndicator lower limitCoding productivity0.60.03Unit coverage rate10.9Project start-up rate10.85Defect return rate0.120.04Project defect rate0.039.98Code (design) review discovery rate0.660.03Defect removal rate10.9Test productivity3.61.03Table 2
SDLM e-banking software project overall defect statistics.
Metric nameIndicator valueDefect density1.3Defect return rate (%)18.42Defect removal rate (%)99.04Unit test coverage rate (%)90Project start-up rate (%)99.04Percentage of defective CQ (%)54.57Percentage of CQ affecting putting into use (%)37.33Test productivity3.13Test result review rate (%)2.37Average time to defect closure13.58Coding productivity0.79Design review discovery rate (%)5.2Code review discovery rate (%)3.64Test case review discovery rate (%)78.72Software productivity17184.07Defect rate per project team member (%)91.63Test case execution rate72.81Test coverage rate8.52Average time to repair defect17.94Average time to defect review8.8The important indicators analysis for these two tables as following.The defect return rate is 18.42% in Table2, which exceeds the upper limit of 12%, indicating that the defect escape rate during the development phase of the project is relatively high. Defect return rate reflects the tester’s testing ability as well as the developer’s coding and unit testing abilities. The higher the value, the more problems the tester finds.Coding productivity is high, but the discovery rate of design and code review is low. The main reasons can be summarized as follows. (a) unit testing is not abundant at the early stage of the project. (b) most developers do not carry out unit testing. (c) the unit self-testing is not qualified. (d) Due to the project time limitation, the coding speed is improved, but the quality is weakened. (e) The preliminary demand survey is not in enough detail; the business is not fully understood. And thus, the overview connection between functional modules could not be grasped, which causes problems of functional connection.Unit coverage, design and code review problem detection rate and test result review rate are all within the predefined value range, but only slightly higher than the project lower limit. Defect repair time, defect closing time and defect review time reflect the whole process of defects and reveal the response ability of developers, testers and CQ person to deal with defects. The shorter the time of this indicator, the timelier the treatment and the stronger the strain capacity. According to the indicators in Table2, the staff of all positions in SDLM needs to be strengthened.


## 4.2.2. Tracking Management of Project Defects

In Figures5–7, we analyze the defect type, defect severity and defect trend of the project using the ODC orthogonal defect classification method.Figure 5
Distribution of defective requirement types in SDLM’s E-banking software project.Figure 6
Distribution of defect severity of SDLM’s E-banking software project.Figure 7
Trend of defect in SDLM’s E-banking software project.Specifically, it can be seen from Figure5 that the defect CQ account for 54.57%, which exceeds half of the defect problem during the entire project development, indicating that the overall development coding quality of the project is low. In addition, new business and business adjustment types also account for a large part, which indicates that requirements analyst should pay attention to the different needs of the industry and the logical way of function realization as soon as possible.In Figure6, the affect rate of CQ is 37.33%, which shows that this type of defect should be focused on to avoid affecting the entire project.Figure7 shows a chart of the defect CQ trend from the beginning to the current stage of the project, which is used to analyze the overall progress of the project. The figure shows the four conditions, i.e., submitted, confirmed, assigned and closed defect CQ tracking curves.


## 4.3. Defect Prediction of SDLM Company’s Electronic Banking Software Project

According to the test time, test workload and the number of CQs found (statistics per day), the cumulative test workload and the cumulative found defects can be calculated, as shown in Table3.Table 3
Cumulative number of defects in the testing phase of the project.
Raw dataCumulative valuePredicted valueTimeTest input workloadNumber of defects found in this testCumulative test input workloadCumulative number of defectsPredicted value of cumulative number of defects2020/6/816516.00577.32020/6/114120.00678.52020/6/273323.00979.3………………2021/3/121131516.00710696.12021/3/131031526.00713698.82021/3/18811534.00714700.92021/3/201621550.00716705.12021/3/221121561.00718707.72021/3/25421565.00720708.82021/3/27211567.00721709.3The data in Table3 were substituted into equation (2), Matlab was used for calculation and curve fitting with Levenberg-Marquardt General and Global Optimization Algorithm. We got the parameters of Gompertz that meet the convergence criteria are as Figure 8: root mean square error (RMSE): 21.1526; error sum of squares (SSE): 75616.2097; related coefficient (R): 0.9949; square of correlation coefficient (R2): 0.9898; coefficient of determination (DC): 0.9897; chi-square (Chi-Square): 371.4746; F-Statistic: 16293.3467. The best estimate obtained of the parameters: K = 901.4255, a = 0.0808, b = 0.9985 [28].Figure 8
Results of Gompertz model parameter fitting.We can calculate the parameters of the Gompertz model by submitting the values into equation (2) using Matlab tools. The fitting curve is shown in Figure 8 (Y: cumulative defect prediction value; X: cumulative testing hours). According to the calculation, we can get Y = 901.4255∗0.0808^0.9985^t. Setting the regret rate of defect to 3%, in order to achieve 97% defect removal rate, we still need the invested workload and primed number of CQ, as shown in Figure 9. (Y: cumulative defect prediction value; X: cumulative testing hours) [29, 30].Figure 9
Fitting curve of Gompertz model using matlab tools.According to Table4, the number of required tests is 91.8 times, and the expected test workload is 520.2 hours. Besides, from Figure 7 it can be seen that the growth rate of defects in the initial stage of the project is relatively stable. When the test workload reaches 200 manhours, the growth rate of defects continues to rise for a period of time, and then gradually becomes more stable in the later period. However, the defects began to increase suddenly at the working time of 1300. It indicates that the defects in the current project have not reached the stable stage, and the project team needs to increase the intensity and depth of testing.Table 4
Table of the predictive analysis using Gompertz model.
Predictive analysis using gompertz modelParameters of the modelIdentification of rapidly rising inflection pointsDefect objective value calculationPositive prediction of objectiveK (the maximum of y)901.4255Inflection:t614.59Omissive defect rate objective3%Estimated additional tests times91.80a0.0808Inflection:y331.62Objective defect numbers874.00Estimated additional works520.20b0.9985Sample size169Defect numbers that should remain27.43Negative prediction of objectiveyt=KabtFound defect numbers726.00Estimated additional tests times2771.43Discrepancy with objective defect numbers153.00Estimated additional works15704.74


## 4.4. SDLM Company e-Banking Software Project Management Process Optimization

The specific optimization strategies are mainly proposed from the aspects of project scope management, quality management, communication management, human resource management and project risk management.


### 4.4.1. Optimization of Project Scope Management

Firstly, we should set out the rules of demand change in the project team to control demand change management. Secondly, the document tracking and traceability of proposed demands should be achieved to strictly control the demand change process. Thirdly, it should be ensured that reducing and controlling the scope of the project, and optimizing it for the functional lines with low usage. Fourthly, easy usability issues should be uniformly modified after the confirmed demands, and the developers have no right to refuse. Finally, if there is a dispute between development and testing, we should directly seek confirmation from the requirements analyst.


### 4.4.2. Optimization of Project Time Management

Firstly, regular project meetings should be arranged every week, and the work summary and progress report are conducted weekly. Secondly, we should formulate unified specifications to reduce defect repair time. Besides, the business needs should not exceed 3 months, and the development and repair time should be controlled within 7 days. Thirdly, defect test closure time cannot exceed 15 days. The CQ test completion rate is required to reach 80% one week before the major version in each month, and all CQs in the last week of the major version must be closed. Finally, we should also adjust the test schedule and increase the number of test rounds to do a comprehensive regression test.


### 4.4.3. Optimization of Project Quality Management

In order to improve the optimization quality, we list the most valuable issues that should be concerned.(a)
Improve the technical and coding reviews, formulate review specifications and determine review personnel qualifications.(b)
Standard the problem discovery rate and ensure employees with low index values can be reported automatically.(c)
Establish project management procedures and systems, clarify the responsibilities of personnel in each role, and achieve all problems can be traced.(d)
Add code debug gadgets to avoid code bugs, and improve code specifications and quality.(e)
Develop a new testing system. That is all problems will be registered with special test records and no additional CQ optimization will be mentioned. Once the violation operation is discovered, it will be modified immediately.


### 4.4.4. Optimization of Project Human Resource Management

(a)
Optimize assessment indicators, including defect recall, test efficiency and other indicators into the assessment system.(b)
Re-formulate the performance assessment system and reward and punishment system within the group, and all staff should follow the standard uniformly.(c)
Share the same problem development or test experience in the group to improve department work efficiency.(d)
Testers summarize common problems and report them within the group to assist developers to avoid similar problems.


### 4.4.5. Optimization of Project Communication Management

(a)
Set up an agile development team to report the work daily or weekly.(b)
Developers or testers (to complete the workload as required) need to work overtime and report the reasons if they cannot complete their tasks.(c)
Establish project tracking frequency, i.e., daily, weekly, monthly or periodically.(d)
The project manager should report to the team leader, and the team leader reports to the department leader.


### 4.4.6. Optimization of Project Risk Management

(a)
Test content optimization, consider multiple legal person, non-impact test and abnormal scene test cases.(b)
Missed test analysis describes several major classification issues that require everyone to focus on.(c)
Strengthen and deepen the test intensity, increase test rounds, and conduct comprehensive regression testing for all functions.(d)
Analyze the risks listed in the project risk management plan, identify possible high-risk situations in advance and propose effective preventive measures, respond to the thresholds that have exceeded the threshold immediately, and propose countermeasures.(e)
Regression testing needs to count defects on a daily basis in the week before going online, and track and solve the problems immediately.


## 4.4.1. Optimization of Project Scope Management

Firstly, we should set out the rules of demand change in the project team to control demand change management. Secondly, the document tracking and traceability of proposed demands should be achieved to strictly control the demand change process. Thirdly, it should be ensured that reducing and controlling the scope of the project, and optimizing it for the functional lines with low usage. Fourthly, easy usability issues should be uniformly modified after the confirmed demands, and the developers have no right to refuse. Finally, if there is a dispute between development and testing, we should directly seek confirmation from the requirements analyst.


## 4.4.2. Optimization of Project Time Management

Firstly, regular project meetings should be arranged every week, and the work summary and progress report are conducted weekly. Secondly, we should formulate unified specifications to reduce defect repair time. Besides, the business needs should not exceed 3 months, and the development and repair time should be controlled within 7 days. Thirdly, defect test closure time cannot exceed 15 days. The CQ test completion rate is required to reach 80% one week before the major version in each month, and all CQs in the last week of the major version must be closed. Finally, we should also adjust the test schedule and increase the number of test rounds to do a comprehensive regression test.


## 4.4.3. Optimization of Project Quality Management

In order to improve the optimization quality, we list the most valuable issues that should be concerned.(a)
Improve the technical and coding reviews, formulate review specifications and determine review personnel qualifications.(b)
Standard the problem discovery rate and ensure employees with low index values can be reported automatically.(c)
Establish project management procedures and systems, clarify the responsibilities of personnel in each role, and achieve all problems can be traced.(d)
Add code debug gadgets to avoid code bugs, and improve code specifications and quality.(e)
Develop a new testing system. That is all problems will be registered with special test records and no additional CQ optimization will be mentioned. Once the violation operation is discovered, it will be modified immediately.


## 4.4.4. Optimization of Project Human Resource Management

(a)
Optimize assessment indicators, including defect recall, test efficiency and other indicators into the assessment system.(b)
Re-formulate the performance assessment system and reward and punishment system within the group, and all staff should follow the standard uniformly.(c)
Share the same problem development or test experience in the group to improve department work efficiency.(d)
Testers summarize common problems and report them within the group to assist developers to avoid similar problems.


## 4.4.5. Optimization of Project Communication Management

(a)
Set up an agile development team to report the work daily or weekly.(b)
Developers or testers (to complete the workload as required) need to work overtime and report the reasons if they cannot complete their tasks.(c)
Establish project tracking frequency, i.e., daily, weekly, monthly or periodically.(d)
The project manager should report to the team leader, and the team leader reports to the department leader.


## 4.4.6. Optimization of Project Risk Management

(a)
Test content optimization, consider multiple legal person, non-impact test and abnormal scene test cases.(b)
Missed test analysis describes several major classification issues that require everyone to focus on.(c)
Strengthen and deepen the test intensity, increase test rounds, and conduct comprehensive regression testing for all functions.(d)
Analyze the risks listed in the project risk management plan, identify possible high-risk situations in advance and propose effective preventive measures, respond to the thresholds that have exceeded the threshold immediately, and propose countermeasures.(e)
Regression testing needs to count defects on a daily basis in the week before going online, and track and solve the problems immediately.


## 5. Analysis on Optimization Results of SDLM’S E-Banking Software Project

### 5.1. Overall Defect Measurement and Prediction Analysis after Project Management Process Optimization

#### 5.1.1. Overall Defect Measurement Analysis

The overall defect measurement data statistics and measurement index values after the optimization of SDLM’s e-banking software are shown in Tables5 and 6.Table 5
Overall project metric statistics after project management process optimization.
Data nameValueTotal project size (KLOC)115.6Total number of CQ closures164Function point150Value (day)CQ close time524CQ development time5473Test time1950Value (hour)Total workload2508Development workload1917Test workload553Table 6
Overall project metric values after project management process optimization.
Metric nameIndicator valueProject defect rate1.92Defect return rate (%)12.11Defect removal rate (%)92.38Test case review discovery rate (%)14.86Project start-up rate (%)92.38Percentage of defective CQ (%)25.56Percentage of CQ affecting putting into use (%)13.45Test productivity1.84Test result review rate (%)2.12Average time to defect closure9.61Coding productivity0.44Design review discovery rate (%)15.7Code review discovery rate (%)8.5Unit test coverage (%)98Software productivity9645.53Defect rate per project team member (%)31.85Test case execution rate47.24Test coverage6.97Average time to repair defect36.73Average time to defect review2.54


#### 5.1.2. Overall Defect Prediction Analysis

After SDLM’s e-banking software project is optimized, the tester indicators are counted, and the cumulative test workload and cumulative defects are calculated according to the project defects, as shown in Table7.Table 7
Cumulative number of defects after project management process optimization.
Raw dataCumulative valuePredicted valueTimeTest input workloadNumber of defects found in this testCumulative test input workloadCumulative number of defectsPredicted value of cumulative number of defects2021/1/28111.00110.22021/3/20112.00210.32021/3/2829631.00812.9………………2021/7/10103780.00153146.62021/7/11995879.00158159.92021/7/12434922.00162164.9We use the Matlab tool to calculate the parameters of the Gompertz model. According to equation (2), Y=212.0162∗0.0478∧0.9973∧t is obtained, the target of residual defect rate is set as 3%. In order to achieve 97% defect removal rate, the required cumulative number of defects is Y = 212.0162 ∗97% = 206. By substituting it into equation (2), 206 = 212.0162∗0.0478∧0.9973^t, and the solution is t = 328 (in hours). The length of a working day in SDLM company is 7.5 hours, which means that about 43.7 working days are still needed to remove 97% defects.The data in Table7 were substituted into equation (2), Matlab was used for calculation and curve fitting with Levenberg-Marquardt General and Global Optimization Algorithm. We got the parameters of Gompertz that meet the convergence criteria are similar to Figure 8: root mean square error (RMSE): 3.5145; error sum of squares (SSE): 716.4002; related coefficient (R): 0.9972; square of correlation coefficient (R2): 0.9944; coefficient of determination (DC): 0.9943; chi-square (Chi-Square): 19.0802; F-Statistic: 9909.2073. The best estimate obtained of the parameters: K = 212.0161, a = 0.0478, b = 0.9973.The fitting curve obtained after project management process optimization is shown in Figure10. According to the prediction analysis of the Gompertz, it is estimated that the number of tests required is 11 and the test time is 44 working days (per person), so the later stage of the project needs to increase the test intensity and progress.Figure 10
The fitting curve obtained after project management process optimization.


### 5.2. Analysis of the Effect of Project Implementation after the Optimization of the Project Management Process

Comparing Tables2 and 6, we can see that the overall defect recall of the optimized project, various index values are significantly reduced, such as, the test case review discovery rate, the defect rate of each project team member, the average length of defect repair, the average length of defect closure, and the average length of defect review. It indicates that the optimization effect of the project management process is significant.The CQ demand type analysis after the optimization of the project management is shown in Figure11.Figure 11
Distribution of defect demand types after optimization.Based on analysis, it can be seen that the defect CQ accounts for 25.56%, which decreases 50% compared with the previous one. The project management process is optimized to eliminate the first and second defects. The business adjustment defect increases, indicating that most of the functional optimization or suggestion defects are available. Continuous optimization is carried out for this type of problem. The coding quality has been greatly improved after the optimization of the project management process.The defect severity distribution before and after the optimization of the project management is shown in Figure12.Figure 12
Distribution of defect severity before and after optimization.The analysis shows that the CQ of undefined project urgency has been greatly reduced. The proportion of CQ that affect the online is 13.45%, which is significantly lower than the proportion of the first batch of online. The emergency CQ processing group can respond quickly, and the flexibility of the entire team promoted.Improved defect trend chart, is shown in Figure13.Figure 13
Defect trend after optimization.The analysis shows that the overall CQ shows a decreasing trend. The total number of closed CQs in June is greater than the number submitted at this stage. The confirmed number remains basically stable, and the allocated number (current remaining workload) shows a decreasing trend. The quality of the system is continuously improving.


## 5.1. Overall Defect Measurement and Prediction Analysis after Project Management Process Optimization

### 5.1.1. Overall Defect Measurement Analysis

The overall defect measurement data statistics and measurement index values after the optimization of SDLM’s e-banking software are shown in Tables5 and 6.Table 5
Overall project metric statistics after project management process optimization.
Data nameValueTotal project size (KLOC)115.6Total number of CQ closures164Function point150Value (day)CQ close time524CQ development time5473Test time1950Value (hour)Total workload2508Development workload1917Test workload553Table 6
Overall project metric values after project management process optimization.
Metric nameIndicator valueProject defect rate1.92Defect return rate (%)12.11Defect removal rate (%)92.38Test case review discovery rate (%)14.86Project start-up rate (%)92.38Percentage of defective CQ (%)25.56Percentage of CQ affecting putting into use (%)13.45Test productivity1.84Test result review rate (%)2.12Average time to defect closure9.61Coding productivity0.44Design review discovery rate (%)15.7Code review discovery rate (%)8.5Unit test coverage (%)98Software productivity9645.53Defect rate per project team member (%)31.85Test case execution rate47.24Test coverage6.97Average time to repair defect36.73Average time to defect review2.54


### 5.1.2. Overall Defect Prediction Analysis

After SDLM’s e-banking software project is optimized, the tester indicators are counted, and the cumulative test workload and cumulative defects are calculated according to the project defects, as shown in Table7.Table 7
Cumulative number of defects after project management process optimization.
Raw dataCumulative valuePredicted valueTimeTest input workloadNumber of defects found in this testCumulative test input workloadCumulative number of defectsPredicted value of cumulative number of defects2021/1/28111.00110.22021/3/20112.00210.32021/3/2829631.00812.9………………2021/7/10103780.00153146.62021/7/11995879.00158159.92021/7/12434922.00162164.9We use the Matlab tool to calculate the parameters of the Gompertz model. According to equation (2), Y=212.0162∗0.0478∧0.9973∧t is obtained, the target of residual defect rate is set as 3%. In order to achieve 97% defect removal rate, the required cumulative number of defects is Y = 212.0162 ∗97% = 206. By substituting it into equation (2), 206 = 212.0162∗0.0478∧0.9973^t, and the solution is t = 328 (in hours). The length of a working day in SDLM company is 7.5 hours, which means that about 43.7 working days are still needed to remove 97% defects.The data in Table7 were substituted into equation (2), Matlab was used for calculation and curve fitting with Levenberg-Marquardt General and Global Optimization Algorithm. We got the parameters of Gompertz that meet the convergence criteria are similar to Figure 8: root mean square error (RMSE): 3.5145; error sum of squares (SSE): 716.4002; related coefficient (R): 0.9972; square of correlation coefficient (R2): 0.9944; coefficient of determination (DC): 0.9943; chi-square (Chi-Square): 19.0802; F-Statistic: 9909.2073. The best estimate obtained of the parameters: K = 212.0161, a = 0.0478, b = 0.9973.The fitting curve obtained after project management process optimization is shown in Figure10. According to the prediction analysis of the Gompertz, it is estimated that the number of tests required is 11 and the test time is 44 working days (per person), so the later stage of the project needs to increase the test intensity and progress.Figure 10
The fitting curve obtained after project management process optimization.


## 5.1.1. Overall Defect Measurement Analysis

The overall defect measurement data statistics and measurement index values after the optimization of SDLM’s e-banking software are shown in Tables5 and 6.Table 5
Overall project metric statistics after project management process optimization.
Data nameValueTotal project size (KLOC)115.6Total number of CQ closures164Function point150Value (day)CQ close time524CQ development time5473Test time1950Value (hour)Total workload2508Development workload1917Test workload553Table 6
Overall project metric values after project management process optimization.
Metric nameIndicator valueProject defect rate1.92Defect return rate (%)12.11Defect removal rate (%)92.38Test case review discovery rate (%)14.86Project start-up rate (%)92.38Percentage of defective CQ (%)25.56Percentage of CQ affecting putting into use (%)13.45Test productivity1.84Test result review rate (%)2.12Average time to defect closure9.61Coding productivity0.44Design review discovery rate (%)15.7Code review discovery rate (%)8.5Unit test coverage (%)98Software productivity9645.53Defect rate per project team member (%)31.85Test case execution rate47.24Test coverage6.97Average time to repair defect36.73Average time to defect review2.54


## 5.1.2. Overall Defect Prediction Analysis

After SDLM’s e-banking software project is optimized, the tester indicators are counted, and the cumulative test workload and cumulative defects are calculated according to the project defects, as shown in Table7.Table 7
Cumulative number of defects after project management process optimization.
Raw dataCumulative valuePredicted valueTimeTest input workloadNumber of defects found in this testCumulative test input workloadCumulative number of defectsPredicted value of cumulative number of defects2021/1/28111.00110.22021/3/20112.00210.32021/3/2829631.00812.9………………2021/7/10103780.00153146.62021/7/11995879.00158159.92021/7/12434922.00162164.9We use the Matlab tool to calculate the parameters of the Gompertz model. According to equation (2), Y=212.0162∗0.0478∧0.9973∧t is obtained, the target of residual defect rate is set as 3%. In order to achieve 97% defect removal rate, the required cumulative number of defects is Y = 212.0162 ∗97% = 206. By substituting it into equation (2), 206 = 212.0162∗0.0478∧0.9973^t, and the solution is t = 328 (in hours). The length of a working day in SDLM company is 7.5 hours, which means that about 43.7 working days are still needed to remove 97% defects.The data in Table7 were substituted into equation (2), Matlab was used for calculation and curve fitting with Levenberg-Marquardt General and Global Optimization Algorithm. We got the parameters of Gompertz that meet the convergence criteria are similar to Figure 8: root mean square error (RMSE): 3.5145; error sum of squares (SSE): 716.4002; related coefficient (R): 0.9972; square of correlation coefficient (R2): 0.9944; coefficient of determination (DC): 0.9943; chi-square (Chi-Square): 19.0802; F-Statistic: 9909.2073. The best estimate obtained of the parameters: K = 212.0161, a = 0.0478, b = 0.9973.The fitting curve obtained after project management process optimization is shown in Figure10. According to the prediction analysis of the Gompertz, it is estimated that the number of tests required is 11 and the test time is 44 working days (per person), so the later stage of the project needs to increase the test intensity and progress.Figure 10
The fitting curve obtained after project management process optimization.


## 5.2. Analysis of the Effect of Project Implementation after the Optimization of the Project Management Process

Comparing Tables2 and 6, we can see that the overall defect recall of the optimized project, various index values are significantly reduced, such as, the test case review discovery rate, the defect rate of each project team member, the average length of defect repair, the average length of defect closure, and the average length of defect review. It indicates that the optimization effect of the project management process is significant.The CQ demand type analysis after the optimization of the project management is shown in Figure11.Figure 11
Distribution of defect demand types after optimization.Based on analysis, it can be seen that the defect CQ accounts for 25.56%, which decreases 50% compared with the previous one. The project management process is optimized to eliminate the first and second defects. The business adjustment defect increases, indicating that most of the functional optimization or suggestion defects are available. Continuous optimization is carried out for this type of problem. The coding quality has been greatly improved after the optimization of the project management process.The defect severity distribution before and after the optimization of the project management is shown in Figure12.Figure 12
Distribution of defect severity before and after optimization.The analysis shows that the CQ of undefined project urgency has been greatly reduced. The proportion of CQ that affect the online is 13.45%, which is significantly lower than the proportion of the first batch of online. The emergency CQ processing group can respond quickly, and the flexibility of the entire team promoted.Improved defect trend chart, is shown in Figure13.Figure 13
Defect trend after optimization.The analysis shows that the overall CQ shows a decreasing trend. The total number of closed CQs in June is greater than the number submitted at this stage. The confirmed number remains basically stable, and the allocated number (current remaining workload) shows a decreasing trend. The quality of the system is continuously improving.


## 6. Conclusion & Future Works

This research puts forward a new concept of using defect management technology to measure, predict and optimize the management of the software project. In the context of SDLM company’s e-banking software project management, the measurement index values are used to analyze the problems in project management. Specifically, we apply the Gompertz model to predict the effectiveness of the company’s current testing and determine the criteria for the end of the test. Besides, we utilize the defect missed test analysis technology to summarize and classify user defects, focusing on classifying defects and implementing defect prevention. Finally, specific optimization measures are proposed based on the analysis results of measurement and prediction. The improved project measurement data are also analyzed statistically and quantitatively, which verifies the scientificity and feasibility of the proposed concept.Due to the limitation of the research time, there are still some challenges not solved. Therefore, we will keep going to improve the management performance.(1)
In future research, it is necessary to further improve the measurement data, and incorporate indicators such as progress indicators and cost deviations into the research system to provide more comprehensive data support for the improvement of the project management.(2)
The measurement and the collection method of project data need to be improved. For example, the definition of defect weighting index is not specific, the CQ workload is not accurate enough, and the statistical method of the code lines should also be divided in more detail.



---

*Source: 2032876-2023-02-20.xml*