1. Reviews Chapter 5 Applied Software Project Management, Stellman & Greene See also: http://www.oreilly.com/catalog/appliedprojectmgmthttp://www.oreilly.com/catalog/appliedprojectmgmt

2. Inspections  To get approval for completion of a work product  To prevent defects  “... it costs more to not do inspections than it does to do them.” report from Software Engineering Institute  Goals: For team to reach consensus and approve/understand each work product Repair known defects early in the process  See paragraph 3, p. 75  Choice of moderator is important Objective Time conscious Understands issues Prepares author and inspectors to critique work (not criticize) and come up with solutions

3. Inspecting the work product  Process Preparation – each inspector marks defects; perhaps each submits a list of defects before the meeting Overview – if someone is not prepared, meeting is rescheduled Page-by-page review – team identifies new wording  If not resolved, logged as open and assigned to inspector who raised the issue Rework – changes are made in the inspection log Follow-up – moderator sends revision and asks for approval of inspectors Approval – moderator gets signatures

4. Managing the author’s expectations  Nobody likes to have their work criticized  Purpose of discussions is not to teach inspectors about the project, but to change the document so that all will approve  If an inspector did not understand something in the document, the document should most likely be revised  It is tempting for the author to get defensive, but must remember the goal is to clear up ambiguity  One way to sidestep this issue is to have all defects sent to moderator. Thus author is prepared to respond appropriately.  Sometimes the author is excluded from the meeting or asked to not talk

5. Standard objections to inspections  Inspections take too long In fact may take about 2 hours  Authors don’t like others criticizing their work Note that all make mistakes Author may not have enough information Author will feel worse when defects are caught later  People are protective of their work

6. Deskchecks  Less formal than a full inspection; often used for vision and scope documents  Sent to selected team members  Does not produce written logs  May be done as a preliminary to inspection

7. Walkthroughs  Author calls meeting of users, stakeholders, engineers, managers, etc., solicits comments, ensures that all present understand the work product (set of slides perhaps)  Good for brainstorming new or alternative ideas  Guidelines: Verify that all who need to review the work product are present Verify that all present understand the purpose of the walkthrough Describe each section of material to be covered Present material in each section, ensuring that all understand Lead a discussion to identify any missing sections or material Document all issues raised Follow up as needed

8. Code Reviews  Team examines a section of code and fixes defects Code that doesn’t properly implement requirements Code that doesn’t function as programmer intended, or Code that is not wrong, but could be improved  Only a subset of carefully chosen code is used One estimate ~2 hours to review 400 loc Tricky code, difficult environment, novice programmer?  Process There is a knowledgeable code reader who briefly describes purpose of code blocks and sets pace Author may respond to questions If defect is found, fix is made if easy to do so Good to switch readers

9. Pair Programming  Like tennis doubles, but much more fun  Two work together at a single computer and continuously review each other’s work  Ensures that at least two people know the product  Junior-level and senior-level can work together  People may be more thorough with someone reading their work, or more energized working together

10. Other...  Use inspections to manage commitments  Diagnosing review problems Defects are likely introduced long before any code is written Problems found too late … when QA finds problem Big, useless meetings when a project went sour The indispensable “hero” is tough to schedule and over allocated and the only one who seems to know what is going on  Code reviews and pair programming can alleviate dependence on a hero