Code Inspections CS 414 Software Engineering I Donald

  • Slides: 12
Download presentation
Code Inspections CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of

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

Outline n n n Terminology Inspection Format Why not just test code? CS 414

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

Terminology n Reviews – Reviews should be applied to major project artifacts at various

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 CS 414 Software Engineering I - Code Inspections - January 23, 2003 3

Terminology (continued) n n n An informal review is one where a number of

Terminology (continued) n n n 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 4

Terminology (continued) n An inspection, or formal review (also called a walkthrough or a

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 CS 414 Software Engineering I - Code Inspections - January 23, 2003 5

Inspection Format n Personnel – There should be between 3 to 5 people at

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 CS 414 Software Engineering I - Code Inspections - January 23, 2003 6

Inspection Format (continued) n One Possible Configuration (For Four People) – – Moderator Reader/Inspector

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) CS 414 Software Engineering I - Code Inspections - January 23, 2003 7

Inspection Format (continued) n Phases – Preparation – Inspection meeting – Inspection report –

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 CS 414 Software Engineering I - Code Inspections - January 23, 2003 8

Inspection Format (continued) n Constraints – Each inspection should cover about 200 lines of

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 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 9

Inspection Format (continued) n Guidelines – A checklist of common problems can be helpful

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”) CS 414 Software Engineering I - Code Inspections - January 23, 2003 10

Why not just test code? n n Debugging requires doing an on-the-spot inspection anyway

Why not just test code? n n 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 11

Summary n n Inspections (formal reviews) can be used as a timesaving measure for

Summary n n Inspections (formal reviews) can be used as a timesaving 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 12