Formal Design Reviews Associated with each of documentation phases. Evaluate with respect to: Customer requirements Prescribed standards and practices Contractual requirements Tradeoff priorities Results of previous phases etc. After review, released to configuration control and becomes baseline. a0 Structured Walkthroughs ‘‘Egoless programming’’ (Weinberg, The Psychology of Computer Programming) Reviewee and 3-5 reviewers Customers and users should be included. Managers should not. Goal is to discover and note problems. Problems not resolved in walkthrough session. Followup meeting or memo to inform reviewers of actions taken. Major problems only. Successful use dependent on establishing a positive, nonthreatening atmosphere. Moderator should receive training. Must not be used as vehicles for employee evaluation. a1 Benefits of Walkthroughs Errors caught at earliest possible time. Greatly improved software quality. Project communication improved. Software easier to maintain. Better project control. Quicker integration of new personnel. Increased programmer expertise. Less disruption with personnel leave. Switch emphasis from individual contemplation to clear, precise communication with others. Enhanced employee morale: social interaction, involvement. a2 Software Inspections Started by IBM in 1972 (Fagan) Process driven by a checklist of likely errors Build checklists through experience and feedback. Some companies consider checklists proprietary. Performed after design complete and after coding complete. Last about 2 hours, cover about 100 statements per hour. Evaluation of walkthroughs and inspections: Find about 70-80% of errors. Most errors found before unit testing. a3