1. Code Inspections CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 23, 2003

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

3. CS 414 Software Engineering I - Code Inspections - January 23, 20033 Terminology n 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

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

5. CS 414 Software Engineering I - Code Inspections - January 23, 20035 Terminology (continued) n 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 n The most common type of inspections are code inspections, first defined by Michael Fagan in 1976

6. CS 414 Software Engineering I - Code Inspections - January 23, 20036 Inspection Format n Personnel –There should be between 3 to 5 people at an inspection Four is the optimal number, and the number we will use here n 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

7. CS 414 Software Engineering I - Code Inspections - January 23, 20037 Inspection Format (continued) n 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)

8. CS 414 Software Engineering I - Code Inspections - January 23, 20038 Inspection Format (continued) n 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

9. CS 414 Software Engineering I - Code Inspections - January 23, 20039 Inspection Format (continued) n 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

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

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

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