Software Reliability Sensitivity Analysis

Some are more correlated than others.  Some practices are dependent on other practices for success.  Some practices are assumed to be highly correlated to fewer defects, when in fact, are not.  These are called mediocre practices. Why should you be concerned with practices that have a mediocre relationship to fielded defect density?  Simple - every hour of effort spent on a mediocre practice is an hour that is not spent on a very sensitive practice.  Software reliability can be accomplished without delaying the schedule. 

All of the parameters that predict software defects are related to at least one of the below. The sensitivity analysis takes place after a software reliability assessment.  The software project's gaps and strengths will be presented based on the relative order of sensitivity, importance to your industry, and existence of prerequisites. The below is a small subset of the several hundred development parameters that can impact software defects.  Not all development practices have equal weighting when it comes to defects. 

In fact, our research has shown that schedule delay is a root cause for poor reliability problems.  When the software engineers don't use their schedule time effectively, the reliability ultimately suffers. Software reliability senstivity analysis is about balancing the ROI of the development practices.

Factor Description
End user domain expertise Number of SW people who have operated the system or equipment being developed
Avoiding Big blobs “Code a little – Test  a little”. Avoiding big and long releases, big teams working on same code, reinvention of the wheel

Product risks

Anything that results in a learning curve – new product, no target hardware, new tools, new methods, new technology

Anything that slows down development – old fragile code, obsolete tools, diverse or unpredictable end users.

Planning ahead

The biggest reason for late releases is the previous release (because of lack of planning)
Change control

Maintaining version and source control, defect tracking, prioritizing changes

Avoiding undocumented changes to requirements, design or code

Verifying changes to code don’t have an unexpected impact

Complete process

Not skipping requirements, design, unit test, test, change control, etc. even for small releases
Formal unit testing Mandatory white and block box testing at the class and SI level.
Defect reduction Various methods for analyzing root causes and eliminating them.
Visualization Techniques that make it easier to understand the requirements, design, code, testing or defects
Execution Ability to get the work done in the most efficient manner possible
Shall Nots  Knowing, design for, coding for and and testing what the software should NOT do