1 / 10

Reviews

Reviews. Chapter 5 Applied Software Project Management , Stellman & Greene See also: http://www.oreilly.com/catalog/appliedprojectmgmt. Inspections. To get approval for completion of a work product To prevent defects

sarah-cash
Download Presentation

Reviews

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Reviews Chapter 5 Applied Software Project Management, Stellman & Greene See also: http://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

More Related