Default Detection Rate-Dependent Software Reliability Model with Imperfect Debugging

Round 1

Reviewer 1 Report

1-      Authors should compare this study with their previous study ( which is not cited in this work) “Software Reliability Model Related to Total Number of Faults Under Imperfect Debugging”, Ce Zhang, Yufei Yuan, Wenqian Jiang, Zhichao Sun, Ye Ding, Miaomiao Fan et al., Pages 48-60.

2-      Authors should avoid to use “ we did …”, “we applied…..”; the passive sentence is better alternative to use.

3-      Language level should be improved.

4-      The discussion on the past studies is incomplete. Authors should provide an extensive discussion on existing studies on this topic and highlight the differences and advantages of the proposed method.

5-      Does assuming p(t)=p bring some errors? If no, please explain it.

6-      In Section 4, the first paragraph, there are some unknown symbols.

7-      In Section 5, there are some unknown symbols, too.

8-      It would be better if authors use multi-colors for figures such as Fig. 2, 3, 4 , etc.

9-      There are different fonts in the text. A reader thinks that required attention did not pay for the paper.

Author Response

"Please see the attachment."

Author Response File: Author Response.docx

Reviewer 2 Report

The paper addresses a relevant issue for software development industry, apparently improving prior concerning to fault rate estimation, which can be useful for project management in what concerns testing effort allocation.

I believe the paper contributions may be valid and useful, however, there are three main issues that undermine the paper in its present form:

 

*** A reduced analysis on state of the art and related works. All the paper presents concerning this in in the introduction section and also a bit on section 2. This is clearly insufficient to properly position your work relative to current art, especially considering that most of your references are old papers, many of them published about 20 years ago: many improvements have been made and it is important to consider recent works.

 

*** A somewhat imprecise description of the software development and testing process. Some examples are (amongst many others, especially in the first half of the paper):

“the important period to improve reliability is before the software release” – are you assuming an old cascade-style development process? But nowadays most development follows an agile process, with continuous delivery. There is no “the” software release, and feedback from a release is used for improvement for the next. In this respect, this paper makes more sense in an industry reality which is no longer significant.

“real software testing process” – what does “real” mean here? Which software testing processes are not “real”?

“The objective of software testing is to constantly repair faults” – No. This is simply wrong. I understand that you may mean that “ultimately, testing is used for…, but testing is for verification and validation, debugging is used for fault location, and coding (in the case of software faults) is what repairs the fault. Given the nature this publication, precise use of terms must be enforced.

“Systematic projects show different exterior features” – In this context, what does “systematic project” means? what is the difference from a systematic project and a non-systematic one? What is an exterior feature? Is it a failure mode?

“This makes the inherent structure of the software destroyed” – No, it does not. Repairing a bug may affect a line or two of the code, without any impact on the structure of the software. Either you are misusing the work “structure”, or you are assuming that all bugs are so very serious that cause the project to go backwards to the architecture design phase (most bugs are not like that).

“The paper establishes a test model” – No, it does not. It proposes fault detection rate functions and compares them to others. There is no test model here.

These examples are mainly from pages 2 and 3 (sections 1 and 2), but this applies to almost all of the paper.

 

*** A poo presentation style that makes it very hard to follow the paper. This is noticeable mainly in the following

- Bad English style (through the entire paper, worse on the first half, too many examples for me to point each one individually). There are even a couple of mandarin characters in the text.

- Insufficient explanation in crucial passages. This is most noticeable in the second half of the paper. For example, in the equation derivations, where you simply go through many expressions without clarifying what are you doing and what for.  Pages 6 and 5 are good examples of this. Many small aspects are not explained. Assumptions “(1) to (5)” on page 5 are left for the reader imagination, “IDI” is also for the reader too deduce that it means “Imperfect Debugging one”.

- On the overall, presentation must be improved. Examples: differences in the lines of Figure 2, 3, 4 and 5 are almost impossible to distinguish. Tables extending over multiple pages should be avoided. Table 4 includes and repeats contents from tables 2 and 3 (wasting almost a page).

To summarize

- Include / improve the related and include more recent works.

- Improve use of software reliability terms and discussion.

- Do a major revision and rewrite on the paper to improve clarity and improve explanations.

Other than that, I believe your work is useful. I am recommending a major revision before publication.

Author Response

"Please see the attachment."

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

Authors revised the paper accordingly.