"Finding and fixing a software problem after delivery is 100 times more expensive than finding and fixing it during the requirements and early design phases." -- Barry Boehm

Practice Description
Formal inspections should be conducted on all task products, i.e., requirements, architecture, designs at all levels, code prior to unit test, test plans, and documentation.

Practice Essentials

• All task output products that will be input to other tasks will undergo a formal inspection before acceptance by CM into the developmental baseline.
   
• Formal inspections conducted on task output products should be part of the task exit criteria.
   
• Formal inspections should be conducted throughout development beginning with the first system requirements products.
   
• System and software architectures will, in addition to formal inspections, be modeled and simulated to verify that the architecture supports performance, reliability, security, and safety requirements.
   
• Formal inspections and architecture modeling/simulation will be conducted in accordance with detailed instructions contained in the SDP.
   
• Each formal inspection will include defect metrics collection and reporting
   
  • The number of defects found by the inspection/simulation
  • When each defect was created
  • The number of inspections of products that contained the defect that did not find the defect
  • A graph showing dates of individual inspections/simulations and the number of defects found in each for project management
     
• Start now and get the team trained, then go and do it.
   
• There is no reason to wait for the right time to employ inspections in a product.
   
• Begin immediately. Even if the project is halfway through the testing stage, the team can begin inspecting fixes to defects discovered during test.
   
• The payoff is immediate.
   
• No sooner will inspections be started than defects will begin to be removed.
   
• These would only have been found later at a higher cost.

Implementation Guidelines

• The supplier/developer will implement a formal, structured inspection/peer review process that will begin with the first system requirements products and continue through architecture, design, code, integration, testing, and documentation products and plans. The plan will be documented and controlled as defined in the SDP.
   
• The project will set a goal of finding at least 80 percent of the defects in every product undergoing a formal inspection.
   
• Products will not be accepted into a CM baseline until they have satisfactorily completed a formal inspection.
   
• The supplier/developer will collect and report metrics concerning the number of defects found in each formal inspection, the time between creating and finding each defect, where and when the defect was identified, and the efficiency of defect removal.
   
• Successful completion of a formal inspection will act as the task exit criteria for non-LOE earned value metrics (and other metrics used to capture effectiveness of the formal inspection process) and as a gate to place items under increasing levels of CM control.
   
• The supplier/developer will use a structured architecture inspection technique to verify correctness and related system performance characteristics.
   
• Implement six well-defined inspection steps:
   
  • Planning
     
• Defining and verifying inspection entry criteria
   
• Arranging the availability of the right participants
   
  • Overview
     
• Education of participants in what is to be inspected
   
• Assignment of roles to participants
   
  • Preparation--participants learn the material
  • Inspection--find defects but do not look for fixes
  • Rework--product author fixes defects
  • Follow up--verification fixes made and no new defects
     
• Examples of inspection entry criteria
   
  • Predecessor products have completed inspection and are in the CM developmental baseline.
  • Error-free compilation and cyclomatic complexity is less than 15 for code units.
     
• Formal inspection roles
    
  • Author (person who developed the product)
  • Reader (paraphrases and summarizes the product)
  • Tester (views product from a testing standpoint)
  • Moderator (trains participants and participates as a "player-coach")
     
• Participation in inspection should be limited to 2-hour periods with no more than two 2-hour inspection periods per day.
   
• 100 to 250 DSI per hour is optimal inspection rate
   
• Inspection training
   
  • Three 3-hour sessions
  • Video tape of actual inspection
  • Students observe actual inspection
     
• Architecture modeling and simulation should be done using COTS modeling and simulation products.
   
• Inspections should be implemented in accordance with written instructions defining a structured method.
   
• Inspections should be conducted on small products that can be completely understood by an individual.
   
• Modeling and simulation of architecture should:
   
  • Be done with automatic tools
  • Verify the architecture will support performance requirements
  • Use input that represents stress loads that might occur during operation.

Things to Watch Out For

• World-class software organizations visited by SPMN that have reduced rework cost to less than 10 percent of development cost and have delivered software with defect density much lower than industry averages all practice formal inspections and have metrics that show inspections are a major factor for this success.
   
• Many projects reviewed by SPMN do not verify products with formal inspections.
   
• Projects that do practice verification of software products seldom collect metrics on the defect removal efficiency of their verification practices.
   
• The first "inspections" on many projects are informal code walkthroughs, which have been demonstrated to be ineffective in identifying defects.

Figuring Out Where You Are - Project QuickLook
 
Chapter 6 contains a series of detailed questions that can be applied to any program to determine the health of its requirements and design inspection approach. These questions should be applied on a regular basis. However, there are some quick indicators that can be used to see if the requirements and design inspection process requires more in-depth examination. Specific "quick look" questions are:

• Are you conducting formal inspections? If so, is there a written process for conducting them?
   
• Do you have an inspection schedule for this project? Who has reviewed the schedule?
   
• Have any products failed an inspection? If no, add a quality risk to the risk list.
   
• What are the measurable criteria for inspections?
   
• How do you track defects back to the inspection process?

An inappropriate answer to any of these questions could indicate a more serious problem and merits further investigation.

top

---