CS 3 2 5

1. The Code Review Checklist Reviewing Before/After Compiling Intuitively, it seems obvious that compilation should precede code review... • The compiler will quickly locate most of the “obvious” errors. • Less obvious errors will be difficult to find during code review if more blatant errors are distracting the reviewer. There are arguments in favor of doing the code review before compiling the code... • Eliminating blatant defects (e.g., obvious syntax errors) is simple prior to compilation and can save the time wasted on needless compilation. • Post-review compilation may be used to measure the quality of the code review (i.e., if the compiler catches errors after the review, then the review wasn’t adequately effective and thorough). CS 325 129 Humphrey

2. Projecting Defects Quality Focus: Defects While there are many aspects to software quality, our process concentrates on the elimination of defects. Rationale: If the software doesn’t work right, other quality issues are irrelevant. How can defects be effectively eliminated? Since low defect content can best be achieved where the defects are injected, software engineers should: • remove their own defects • determine the causes of their defects • learn to prevent those defects When should the defects be eliminated? Rather than waiting until late in the development process (i.e., during testing, when locating and correcting defects is difficult and expensive), our process advocates eliminating defects during design review and code review. CS 325 130 Humphrey

3. The Economics of Defect Removal Software Fault Propagation Relative Cost Defects are injected primarily during the code phase, with the design phase at second place and the requirements phase a distant third. Defects are removed primarily during the code phase, with the expensive test phase at second place and the much cheaper design phase a distant third. CS 325 131 Humphrey

4. Design Defects Testing Vs. Reviews • In testing, you must • detect unusual behavior • figure out what the test program was doing • find where the problem is in the program • figure out which defect could cause such behavior • With reviews and inspections, you • follow your own logic • know where you are when you find a defect • know what the program should do, but did not • know why this is a defect • are in a better position to devise a correct fix CS 325 132 Humphrey

5. Product Quality Software Quality There are numerous ways in which software quality can be characterized. • Understandability • Are variable names descriptive? • Are functions adequately commented? • Completeness • Are all required functions, parameters, and inputs available? • Conciseness • Is the code redundant? • Are conditionals and loops clear? • Consistency • Is the same identifier used for different purposes? • Are similar functions and expressions written in similar ways? • Testability • Are complex structures used in the code? • Efficiency • Have functions been optimized for speed? • Maintainability • Is each module’s functionality clear? • How hard would modifications be? • Usability • Is there adequate on-line help? • Are error messages meaningful? • Reliability • Is input checked for range errors? • Is exception handling provided? CS 325 133 Humphrey

6. Process Quality Uncertainty Principle Unfortunately, no matter how thorough your requirements analysis is, the fact is that the complete requirements for a software development project will not be known until after the user has used the finished software. Implementation-Level Design (As you code, what design alterations are needed?) Detailed-Level Design (What are the functions and interactions?) High-Level Design (What are the classes and components?) System-Level Design (What will the software do?) Requirements Specifications Design is the process by which a reasonable solution is created for an ill-defined problem. CS 325 134 Humphrey

7. A Personal Commitment to Quality Component Quality Profile Humphrey suggests using a profile to assess a software component’s quality. • The component quality profile is based on the following criteria. • Design time is greater than 50 percent of coding time. • Design review time is greater than 50 percent of design time. • Code review time is greater than 50 percent of coding time. • Compile defects are less than 10 per KLOC. • Unit test defects are under five per KLOC. • When a factor meets or exceeds these criteria, that profile dimension is at one or on the edge of the bullseye. • Quality is judged to be good if the profile nearly fills the bullseye. CS 325 135 Humphrey