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.
|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|
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.
|The biggest reason for late releases is the previous release (because of lack of planning)|
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
|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|