1 / 12

Code Inspections

Code Inspections. CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 23, 2003. Outline. Terminology Inspection Format Why not just test code?. Terminology. Reviews

tmaranto
Télécharger la présentation

Code Inspections

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. Code Inspections CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 23, 2003

  2. Outline • Terminology • Inspection Format • Why not just test code? CS 414 Software Engineering I - Code Inspections - January 23, 2003

  3. Terminology • Reviews • Reviews should be applied to major project artifacts at various points during software development • The goal of reviews is to remove defects (errors) from and make improvements to an artifact before that artifact is used to produce other ones CS 414 Software Engineering I - Code Inspections - January 23, 2003

  4. Terminology (continued) • An informal review is one where a number of developers are involved and the artifact is not studied in detail • Informal reviews usually only uncover major conceptual errors and can be in part for informational purposes and used to build a consensus • From here on, informal reviews will be referred to as just “reviews” CS 414 Software Engineering I - Code Inspections - January 23, 2003

  5. Terminology (continued) • An inspection, or formal review (also called a walkthrough or a formal technical review), is when a small group of developers looks at a project artifact in detail with the express purpose of • finding defects in the artifact, • making sure the artifact meets professional standards, and • ensuring that all artifacts are developed in a uniform manner • The most common type of inspections are code inspections, first defined by Michael Fagan in 1976 CS 414 Software Engineering I - Code Inspections - January 23, 2003

  6. Inspection Format • Personnel • There should be between 3 to 5 people at an inspection • Four is the optimal number, and the number we will use here • Roles • Moderator • Reader • Inspector, or tester • Recorder • Producer, or author • Some people can have more than one role • All except the producer is a member of the inspection team CS 414 Software Engineering I - Code Inspections - January 23, 2003

  7. Inspection Format (continued) • One Possible Configuration(For Four People) • Moderator • Reader/Inspector • Recorder/Inspector • Producer • Should be arranged around a square or round table, or 2 by 2 at a larger table (like the ones in our classroom) CS 414 Software Engineering I - Code Inspections - January 23, 2003

  8. Inspection Format (continued) • Phases • Preparation • Inspection meeting • Inspection report • This process needs to be repeated, if it is decided that a sufficient a number of problems are uncovered in an inspection to warrant another inspection CS 414 Software Engineering I - Code Inspections - January 23, 2003

  9. Inspection Format (continued) • Constraints • Each inspection should cover about 200 lines of code • However, some types of code may need more detailed inspection than others • Advance preparation should be 1-2 hours per person • The inspection meeting should also be 1-2 hours • Inspection of other artifacts should also use the 1-2 hours per inspection rule CS 414 Software Engineering I - Code Inspections - January 23, 2003

  10. Inspection Format (continued) • Guidelines • A checklist of common problems can be helpful • There should only be identification of errors, and little fixing of them (“no problem solving”) CS 414 Software Engineering I - Code Inspections - January 23, 2003

  11. Why not just test code? • Debugging requires doing an on-the-spot inspection anyway • Such inspections may have to be done several times on the same code • A test case failure doesn’t pinpoint where the problem is • That said, testing is almost always needed in order catch some of the errors not found through inspections CS 414 Software Engineering I - Code Inspections - January 23, 2003

  12. Summary • Inspections (formal reviews) can be used as a time-saving measure for producing better artifacts more reliable code • The goal of an inspection is to find all defects so that they can be removed before going on to the next phase • Inspections have a specific structured format and time constraints • Code inspections are an essential complement to the testing of source code CS 414 Software Engineering I - Code Inspections - January 23, 2003

More Related