Lecture 8

Cis 1250 lec 8

Cost of error:

  • If found in review stage
  • 1 hour per defect
  • Testing stage
  • 2-4 hours per defect
  • After release
  • 33 hours per defect

This is why periodic review are important.


  • Applied to requirement, design and coding stages.
  • Provide a technical summary of what to do
  • Provide the quality of what has been presented
  • Uncovers errors
  • Make sure everything works together like intended
  • Verify requirements
  • It does what was asked by the client
  • Ensure the software meets standard
  • Its latest and up to date
  • Meets all internal, client and industry standards
  • Can interact with other company products
  • System uniformity
  • Same system
  • Make projects more manageable
  • Divide and conquer
  • How large teams work together and make sure they make what they were required to
  • Training
  • Help the new guys learn what to do
  • Continuity of the team
  • So more people know what’s happening
  • Makes it easier for outsiders to join
  • People can jump from smaller teams easily
  • Can take several forms
  • Informal and formal
  • Discussions of how to solve problems
  • Every review should follow some rules
  • The agenda
  • The number of people
  • Time limit
  • Focus on a specific and small part of the system
  • Too big, meeting might run to long
  • Narrow focus more likely to uncover error
  • Helps keep people on track
  • Initiating a review
  • Indicate the reviews components
  • Request a meeting
  • Schedule meeting
  • Review attendees
  • Small to make it more manageable and schedule
  • Leader to go through the documents and discus what to do
  • Get feedback
  • Review process
  • Have chair of the meeting
  • Leader going through the process
  • Someone taking document
  • Record changes
  • Have outsider to make sure you explain it properly
  • At the end of the review
  • Decide weather to accept the material or not
  • To make changes or leave it as is
  • Scrap it
  • What errors to fix
  • When the next one be
  • Guidelines for reviews
  • Review the code not the coder
  • Point out what is working well
  • Get feedback
  • Meeting is just to find errors not how to fix them
  • Sample driven reviews
  • Identify the components that matter the most
  • Find the 20% that are going to produce 80% of the outcome

Note Created by
Is this note helpful?
Give kudos to your peers!
Wanna make this note your own?
Fork this Note