Software reviews and inspections

352 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
352
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Software reviews and inspections

  1. 1. R®Design Technology PVPDIntel ConfidentialSoftware Reviews andInspectionsTuesday, June 01, 2004Miles and Yi
  2. 2. 2R®Design Technology PVPDIntel ConfidentialIntroductionSeveral PVPD teams have found reviews and inspections to bea helpful part of their software development methodologyReviews and inspections can help you to:– Find bugs in both design and implementation– Share and teach BKMs and good development practices– Encourage good habits and practices– Foster teamworkIndividual groups/teams can decide how to incorporate reviewsand inspections into their methodology, but we encourage you tostandardize on a set of practices that people have found useful
  3. 3. 3R®Design Technology PVPDIntel ConfidentialSuggested MethodologyFollow the standard inspection process for code inspections– Focus is on identifying defects – resolution is left to the implementer,or can be discussed separately after defect identificationUse a modified process for design and specification reviews– Includes discussion of design alternatives– Brainstorming plays a larger role– Treating design and specification reviews differently than codeinspections is a change from our earlier inspection effortsMany of the common elements are briefly described on thefollowing foils– Some of the this has been condensed from older training materialsdeveloped by Neela (more details can be found there)
  4. 4. 4R®Design Technology PVPDIntel ConfidentialParticipantsParticipants in reviews and inspections have well defined rolesInspector General (Team Inspection Czar)– Identifies a regular time slot that works for the group– Help maintain continuity of reviews in a group– Handles scheduling and administrative aspects– Helps to identify and schedule reviews– Make sure properly formatted materials (with line numbers) areprovided to reviewers– Should allow at least 48 hours for reviewers to prepare– Makes sure that it happens…Owner– Person responsible for the work being reviewed/inspected– Also acts as an inspector– Performs necessary rework triggered by the review inspection
  5. 5. 5R®Design Technology PVPDIntel ConfidentialParticipantsModerator– Facilitates the inspection and records the meeting data– Should never be the ownerFor Code: Inspectors– Identify bugs, gotchas, confusing or unclear code, and deviationsfrom common accepted coding practicesFor Design/Architecture: Reviewers– Same as code review plus…– Identify good and bad parts of the design/architecture– Bring suggestions for improving the design/architecture
  6. 6. 6R®Design Technology PVPDIntel ConfidentialPreparationPreparation is absolutely essential to the success of the reviewor inspection– If the necessary preparation has not been done, then the review orinspection should be rescheduledOwner’s Initial Preparation– The owner should be given enough heads-up notice to do anycleanup that he/she deems necessary – this initial step often caneliminate many errors– Just thinking about it improves the product and work habits– Owner should provide the properly formatted materials to theInspector General, or directly to the inspection participants
  7. 7. 7R®Design Technology PVPDIntel ConfidentialPreparationInspector’s/Reviewer’s Preparation– Without proper advance prep, the session will be a waste of timeSpend 30-60+ minutes reviewing the materialsReschedule if necessary– Note defects that are identified– For design reviews, notePortions of the design that can be improvedAny suggestions you may have for improvement– Some reviewers will have focus areas assignedReview code in reverse, look for pointer problems, const usage, etc.– A checklist for common errors may be helpful during preparation(see slide 10)
  8. 8. 8R®Design Technology PVPDIntel ConfidentialReview SessionReview or Inspection session– Pace and tangential discussions should be controlled by moderator– A strict process is important to keep emotions under controlFocus on the code/design, not on the owner– Moderator logs inputs and suggestions– For reviews:The moderator should make sure that inputs are understood and allowsome discussion – however, the design decisions will usually requireanalysis or interaction with stakeholders that will need to happen afterthe session– For inspectionsDiscussion shouldn’t dwell on the specific code itself (or the coder)Instead, focus on the coding concepts that apply to the codeIf there is a discussion, it should be about the merits of the codingguideline that the code violates (helps to level-set the team on what isconsidered good and what is considered bad)
  9. 9. 9R®Design Technology PVPDIntel ConfidentialRework and Follow-upRework– It is the responsibility of the code/design owner to address defects ordesign suggestions– Addressing a defect does not imply mean changing the code ordesign, but it does mean that sufficient analysis was done todetermine that the existing code or design is adequateFollow-up– The czar should follow up with the code/design owner– Identify with the code/design owner the inputs that were addressed– Decide whether the updated design/code should bereviewed/inspected again– If inputs have been addressed in a satisfactory manner, then thereview/inspection can be closed, and results logged
  10. 10. 10R®Design Technology PVPDIntel ConfidentialCommon Errors ChecklistIt is useful for each group to develop a list of common errors thatinspectors can use– The list will evolve over time as people in the group learn to avoidcertain types of errors– Especially useful when people have not participated in manyinspections and are not sure about the types of defects they shouldbe trying to identify– It is helpful if the teams can reach consensus on the guidelines,since the whole team needs to support them– Nothing is set in stone and adherence is ultimately up to the ownerWe can start with a generic common list, although the types oferrors or concerns will tend to vary from team to team

×