Analysis of software bug causes and its prevention

Nakashima, Toyoshiro; Oyama, M.; HISADA, Hiroshi; Ishii, Naohiro

doi:10.1016/s0950-5849(99)00049-x

Cited by 17 publications

(12 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Researchers have successfully used Kaoru Ishiwaka's method's affinity diagrams on an organization's DCA results to acquire appropriate details. 16 …”

Section: How Should We Categorize Defect Causes?mentioning

confidence: 99%

Evidence-Based Guidelines to Defect Causal Analysis

2012

View full text Add to dashboard Cite

“…Researchers have successfully used Kaoru Ishiwaka's method's affinity diagrams on an organization's DCA results to acquire appropriate details. 16 …”

Section: How Should We Categorize Defect Causes?mentioning

confidence: 99%

Evidence-Based Guidelines to Defect Causal Analysis

2012

View full text Add to dashboard Cite

“…They are commonly used in RCA to register and visualize the causal structures of problems. Various techniques to draw CED are introduced, e.g., a fishbone diagram (Burnstein, 2003;Stevenson, 2005;Andersen and Fagerhaug, 2006;Ishikawa, 1990), a fault tree diagram (Andersen and Fagerhaug, 2006), a directed graph (Bjørnson et al, 2009), a matrix diagram (Nakashima et al, 1999), a scatter chart (Andersen and Fagerhaug, 2006), a logic tree (Latino and Latino, 2006), and a causal factor chart (Rooney and Vanden Heuvel, 2004). However, only few of them are utilized in software project retrospectives.…”

Section: The Use Of Cause-effect Diagrams In Software Project Retrospmentioning

confidence: 99%

“…Considering alternative techniques to create CED (Burnstein, 2003;Stevenson, 2005;Andersen and Fagerhaug, 2006;Ishikawa, 1990;Bjørnson et al, 2009;Nakashima et al, 1999;Latino and Latino, 2006;Ammerman, 1998;Andersen and Fagerhaug, 2006;Rooney and Vanden Heuvel, 2004), it seems evitable that in software project retrospectives the diagramming technique should support network structures . This is because of the hub causes (Bjørnson et al, 2009) (in our study their proportion was 7.5% as an average).…”

Section: Comparison To Prior Workmentioning

confidence: 99%

Diagrams or structural lists in software project retrospectives – An experimental comparison

Lehtinen

Mäntylä

Itkonen

et al. 2015

Journal of Systems and Software

View full text Add to dashboard Cite

a b s t r a c tRoot cause analysis (RCA) is a recommended practice in retrospectives and cause-effect diagram (CED) is a commonly recommended technique for RCA. Our objective is to evaluate whether CED improves the outcome and perceived utility of RCA. We conducted a controlled experiment with 11 student software project teams by using a single factor paired design resulting in a total of 22 experimental units. Two visualization techniques of underlying causes were compared: CED and a structural list of causes. We used the output of RCA, questionnaires, and group interviews to compare the two techniques. In our results, CED increased the total number of detected causes. CED also increased the links between causes, thus, suggesting more structured analysis of problems. Furthermore, the participants perceived that CED improved organizing and outlining the detected causes. The implication of our results is that using CED in the RCA of retrospectives is recommended, yet, not mandatory as the groups also performed well with the structural list. In addition to increased number of detected causes, CED is visually more attractive and preferred by retrospective participants, even though it is somewhat harder to read and requires specific software tools.

show abstract

“…For example, research has shown that 50% of the underlying cause of software bugs was simply carelessness [52]. Thus, perhaps in their rush to move products more rapidly into a more competitive market, IT vendors are less careful about the quality of those products.…”

Section: A Framework For Question 2: How Are the Problems From Rapid mentioning

confidence: 99%

The effect of rapid IT change on the demand for training

Bernamati

Lederer

2001

Proceedings of the 2001 ACM SIGCPR Conference on Computer Personnel Research

View full text Add to dashboard Cite

Information technology is rapidly changing. This increases the complexity of 1T management. Research has yet to explain the IT management problems due to such change. The current study developed a survey instrument about such problems based on experiences described in structured interviews with 16 1T professionals. The instrument was mailed to a nationwide sample of 1,000 IT professionals. Two hundred forty-six provided useable data. The research identified five of problems of rapid IT change, namely Vendor Competitiveness, Poor Quality, Incompatibility, Management Confusion, and Training Demands. It confirmed a model suggesting that increased Vendor Competitiveness leads to Poor Quality, Incompatibility, and Management Confusion, and that these increase Training Demands. The research also offers suggestions for future investigation of the problems and a potential instrument with which to conduct it.

show abstract

Analysis of software bug causes and its prevention

Cited by 17 publications

References 9 publications

Evidence-Based Guidelines to Defect Causal Analysis

Evidence-Based Guidelines to Defect Causal Analysis

Diagrams or structural lists in software project retrospectives – An experimental comparison

The effect of rapid IT change on the demand for training

Contact Info

Product

Resources

About