|
DFTS Phase
|
Common "Defects"
|
Mistakes That Cause Them
|
Mistake-Proofing Measures
|
|
Requirements development
|
Erroneous requirements development
|
User can't express requirements clearly
User undervalues or overexpects
User changes application requirements frequently
|
QFD-based requirements development
|
|
Design
|
Over-designing or a wrong design may result in the following:
|
Features are added/asked for because they are easy to add/ask for
Inadequate communication between users and developers
|
QFD-based requirements development
Team-based development led by application and programming
leaders
with the system architect as conflict revolver
Taguchi Methods for design optimization
FMEA/FTA for risk appraisal
|
|
Coding
|
Programming bugs
|
Simple oversights on the part of programmers
Misunderstanding of specifications
Inexperience
|
Coding standards and hierarchy controls
Team walkthroughs
More-precise specifications
Improved programmer training
|
|
Test
|
Cannot check all the data paths
|
Application is too complex
|
More componentization
More hierarchy levels
|
|
Evluation
|
Inconsistent results
|
Incomplete testing criteria
|
Improved testing standards and procedures
|
|
Verification
|
Results are not
verifiable
|
Incomplete or defective test data and/or procedures
|
Better test plan
|
|
Validation
|
Cannot make program produce correct result from
verified
test data
|
Error(s) during development
|
Error analysis to isolate process stage(s) where error(s) likely were made
|
|
Implementation
|
Inconsistencies with two or more cooperating programs
|
Mistakes in human and machine communication
|
Error isolation by staged testing of partial results
|
|
Integration
|
Individually correct components will not work together
|
Inconsistent or poorly specified
interstitial
component communications
|
Systematic review of component/object method invocation
|
|
Maintenance
|
Lack of customer satisfaction
|
Maintenance programmer inadequacy vis--vis programmer creator
|
Training
Adequate documentation
Supervision
|