An empirical study of software faults preventable at a personal level in a very large software development environment

Yu, Weider D.; Barshefsky, Alvin; Huang, Steel T.

doi:10.1002/bltj.2076

Cited by 10 publications

(6 citation statements)

References 2 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The results of the analysis also showed that three types of faults-logic, interface, and maintainability-account for more than 50% of the total coding faults. 5 The faults discussed in this paper were actual faults found in a very large software project environment. The average programming ability and experience of developers connected with the project were high compared to the norm in the industry.…”

Section: Weider D Yumentioning

confidence: 99%

A software fault prevention approach in coding and root cause analysis

Yu¹

2002

Bell Labs Tech. J.

Self Cite

View full text Add to dashboard Cite

The complexity of Lucent Technologies' advanced 5ESS® switching system makes the cost of finding, fixing, and retesting a software fault very high. The current 5ESS system contains several million lines of source code, which provide many complicated real‐time switching function features. As customer demands for ever‐increasing product quality compound the high cost of testing and reworking source code, it is crucial for the 5ESS Switching Development organization to find ways to prevent faults from being introduced into the software in the first place. The 5ESS Switch Coding Fault Prevention Team was assembled to find methods to prevent the most frequent faults from being injected into a product during coding. The Coding Fault Prevention Guidelines, developed by the team for use in various Lucent switching development organizations, lists the most frequent errors made during coding. It also provides coders with information that will help reduce the risk of introducing faults into the software. This paper describes the most common preventable faults and the technical guidelines developed to overcome them. It also explains the metrics used to evaluate the results achieved.

show abstract

Section: Weider D Yumentioning

confidence: 99%

A software fault prevention approach in coding and root cause analysis

Yu¹

2002

Bell Labs Tech. J.

Self Cite

View full text Add to dashboard Cite

show abstract

“…So, our defect statistics do not include defects detected by unit tests. It is reported that unit tests are efficient in detecting defects of functionality [9,56], which refers to missing or wrong functionality (w.r.t. requirements) and mostly are injected in building phase [24].…”

Section: Discussionmentioning

confidence: 99%

Analysis on Relationship between Code Quality and Code Coverage in an XP Environment: a Case Study on the SWURV Project

Li¹

2023

Preprint

View full text Add to dashboard Cite

The thesis used hypothesis testing and correlation analysis methods to explore the relationship between structural code coverage and the quality of software developed in an eXtreme Programming (XP) environment, via a case study of a commercial software product. We find that improving code coverage is helpful to detect residual defects, but it is not enough, and we also need other testing, like acceptance testing, in the process of XP software development to provide good quality software products. In addition, in order to investigate why the strength of association between code coverage and residual defect density is not as strong as that presented in prior work, a detailed defect root cause analysis is performed, showing that over 96% of bugs cannot be detected by improving code coverage. Based on the defect categories and distribution of defect root cause, six improvement actions are proposed for future XP projects.

show abstract

“…al. [16,17] has followed a process similar to ours, but using different defect and root cause classification schemes. They have not focused explicitly on the effort related to the defects.…”

Section: Relation To Other Workmentioning

confidence: 99%

A case study in root cause defect analysis

Leszak¹,

Perry²,

Stoll³

Proceedings of the 2000 International Conference on Software Engineering. ICSE 2000 the New Millennium

View full text Add to dashboard Cite

There are three interdependent factors that drive our software development processes: interval, quality and cost. As market Dressures continue to demand new features ever more months.network, consisting of circuit packs, ASICs, software units, and a craft terminal. Total head count for this release was 180 people and the development project lasted for 19 rapidly, the challenge is to meet those demands while increasing, or at least not sacrificing, quality. One advantage of defect prevention as an upstream quality improvement practice is the beneficial effect it can have on interval: higher quality early in the process results in fewer defects to be found and repaired in the later parts of the process, thus causing an indirect interval reduction. This release has been a very important and critical one network element product. We subsequently introduced this especially for the European market. Management concern analysis methodology into new development projects as an in-process measurement collection requirement for each for process improvement project retrospective activities, one of them being the root cause major defect MR.defect analysis (RCA) project. Several improvement projects -We present the experimental design of our case study discussing the novel approach we have taken to defect and root cause classification and the mechanisms we have used towards, for example, better effort estimation, more effcient development, and predictable and higher quality (measured in number of defect MRs) have been initiated recently.for randomly selecting the MRs to analyze and collecting the analyses via a web interface. We then present the results of our analyses of the MRs and describe the defects and root causes that we found, and delineate the countermeasures created to either prevent those defects and their root causes or detect them at the earliest possible point in the development process.We conclude with lessons learned from the case study and resulting ongoing improvement activities.

show abstract

An empirical study of software faults preventable at a personal level in a very large software development environment

Cited by 10 publications

References 2 publications

A software fault prevention approach in coding and root cause analysis

A software fault prevention approach in coding and root cause analysis

Analysis on Relationship between Code Quality and Code Coverage in an XP Environment: a Case Study on the SWURV Project

A case study in root cause defect analysis

Contact Info

Product

Resources

About