Will Snipes

On the value of static analysis for fault detection in software

No single software fault-detection technique is capable of addressing all fault-detection concerns. Similarly to software reviews and testing, static analysis tools (or automated static analysis) can be used to remove defects prior to release of a software product. To determine to what extent automated static analysis can help in the economic production of a high-quality product, we have analyzed static analysis faults and test and customer-reported failures for three large-scale industrial software systems developed at Nortel Networks. The data indicate that automated static analysis is an affordable means of software fault detection. Using the orthogonal defect classification scheme, we found that automated static analysis is effective at identifying assignment and checking faults, allowing the later software production phases to focus on more complex, functional, and algorithmic faults. A majority of the defects found by automated static analysis appear to be produced by a few key types of programmer errors and some of these types have the potential to cause security vulnerabilities. Statistical analysis results indicate the number of automated static analysis faults can be effective for identifying problem modules. Our results indicate static analysis tools are complementary to other fault-detection techniques for the economic production of a high-quality software product.

Predicting failures with developer networks and social network analysis

Software fails and fixing it is expensive. Research in failure prediction has been highly successful at modeling software failures. Few models, however, consider the key cause of failures in software: people. Understanding the structure of developer collaboration could explain a lot about the reliability of the final product. We examine this collaboration structure with the developer network derived from code churn information that can predict failures at the file level. We conducted a case study involving a mature Nortel networking product of over three million lines of code. Failure prediction models were developed using test and post-release failure data from two releases, then validated against a subsequent release. One models prioritization revealed 58% of the failures in 20% of the files compared with the optimal prioritization that would have found 61% in 20% of the files, indicating that a significant correlation exists between file-based developer network metrics and failures.

Preliminary results on using static analysis tools for software inspection

Software inspection has been shown to be an effective defect removal practice, leading to higher quality software with lower field failures. Automated software inspection tools are emerging for identifying a subset of defects in a less labor-intensive manner than manual inspection. This paper investigates the use of automated inspection for a large-scale industrial software system at Nortel Networks. We propose and utilize a defect classification scheme for enumerating the types of defects that can be identified by automated inspections. Additionally, we demonstrate that automated code inspection faults can be used as efficient predictors of field failures and are effective for identifying fault-prone modules.

Defining the decision factors for managing defects: a technical debt perspective

Making a decision about whether to fix or defer fixing a defect is important to software projects. Deferring defects accumulates a technical debt that burdens the software team and customer with a less than optimal solution. The decision to defer fixing a defect is made by Software Change Control Boards (CCBs) based on a set of decision factors. In this paper, we evaluated the set of decision factors used by two CCBs at ABB in the context of technical debt management The aim was to determine how a model of cost and benefits of incurring technical debt could be part of the CCB decision process. We identified the cost categories and decision factors for fixing and deferring defects as a result of interviews with CCB members. We found that the decision factors could incorporate the financial aspects when using the technical debt metaphor. We identify opportunities for further research to integrate technical debt concepts with the decision factors towards better long term outcomes.

A methodology to improve switching system software service quality and reliability

Related methodologies for improving software field quality and reliability are introduced. These methodologies will help predict and measure when it is appropriate to release the software and involves forecasting the number of software problems that switching customers will encounter. The methodologies use releasability and reliability models. System test and verification phase completion dates and reliability levels are predicted. Field problems are predicted based on the softwares verification testing, design, and marketing and sales projections, as well as the number of features contained in the software.<<ETX>>

How should software reliability engineering (SRE) be taught

This article on teaching software reliability engineering (SRE) represents a consensus of views of experienced software reliability engineering leaders from diverse backgrounds but with ties to education: directors of software reliability and software reliability training in industry, a consultant who teaches SRE practice to industry, and university professors. The first topic covered is how to attract participants to SRE courses. We then analyze the job-related educational needs of current and future (those now university students) software practitioners, SRE practitioners, researchers, and nonsoftware professionals. Special needs relating to backgrounds, limited proficiency in the course language, and work conflicts are outlined. We discuss how the needs presented should influence course content and structure, teaching methods, and teaching materials. Finally, we cover our experiences with distance learning and its special needs. Some of this article applies to any course and is not SRE-specific.

Technical Debt: A Research Roadmap Report on the Eighth Workshop on Managing Technical Debt (MTD 2016)

We report here on the Eighth International Workshop on Managing Technical Debt, collocated with the International Conference on Software Maintenance and Evolution (ICSME 2016). The technical debt research community continues to expand through collaborations of industry, tool vendors, and academia. The major themes of discussion this year indicate convergence on a common definition on technical debt and its elements which drive the maturation of a research roadmap, demonstrating that managing technical debt is a mainstream topic in software engineering research bringing empirical analysis, data science, software design and architecture analysis and automation among other challenges together.

Deploying Software Team Analytics in a Multinational Organization

Implementing a software engineering analytics solution poses challenges and offers significant value for the globally distributed software development organization at ABB. Because software development activities in agile methodologies revolve around the team, ABB decided to implement an analytics solution focused on team metrics as part of its Software Development Improvement Program. Using key indicators focused around team improvement, researchers found that teams could manage their activities with metrics such as cycle time. Key lessons learned include paying attention to visual design and navigation and providing drill-down capabilities for the user. This article is part of a special issue on Actionable Analytics for Software Engineering.

Designing an SRE program for commercial software organizations

To maximize business value, commercial software organizations need to apply software reliability engineering (SRE) using a distributed model where key practices are performed by different roles in the organization. SRE practitioners need to understand the landscape of software development in order to define a program that is effective at moving the organization towards higher reliability