Fluent Essays

Finish it in 2 days. Read the articles carefully and follow the requirements, or I will dispute 1. Short answer Question(200 words） [required] Roger S. Pressman. Chapter 15: Review Techniques. Software Engineering: A Practitioners Approach, 7th ed., McGraw-Hill, 2010, pp. 416- 431. [required] Roger S. Pressman. Chapter 16: Software Quality Assurance. Software Engineering: A Practitioners Approach, 7th ed., McGraw-Hill, 2010, pp. 432-448. To turn in Prepare a brief (no more than one page) written answer to the following two questions. Write up your answer using MS Word. One well-presented paragraph for each question is sufficient. If your main quality focus is on monitoring and improving your process, are there any critical quality attributes that will fall through the cracks? Which plays a more important role in managing software quality: product metrics or process metrics? Why? 2. Read and discuss (150 words) [required] Understanding Perceptions of Problematic Facebook Use Discuss: How often do you get less sleep than you want because you’re using Facebook? Overall, do you feel like Facebook has a positive or negative impact on your life? How much control do you feel you have over the amount of time you spend on Facebook? Software reviews are a “filter” for the software process. That is, reviews areapplied at various points during software engineering and serve to uncovererrors and defects that can then be removed. Software reviews “purify” soft- ware engineering work products, including requirements and design models, code, and testing data. Freedman and Weinberg [Fre90] discuss the need for reviews this way: Technical work needs reviewing for the same reason that pencils need erasers: To err is human. The second reason we need technical reviews is that although people are good at catching some of their own errors, large classes of errors escape the origina- tor more easily than they escape anyone else. The review process is, therefore, the answer to the prayer of Robert Burns: O wad some power the giftie give us to see ourselves as other see us A review—any review—is a way of using the diversity of a group of people to: 1. Point out needed improvements in the product of a single person or team; 416 C H A P T E R 15 REVIEWTECHNIQUES K E Y C O N C E P T S defect amplification . . .418 defects . . . . . . .417 error density . .421 errors . . . . . . .417 record keeping . .427 review metrics . . . . . .420 reporting . . . .427 reviews cost effectiveness . .421 informal . . . . .424 sample- driven . . . . . .429 technical . . . . .426 What is it? You’ll make mistakes as you develop software engineering work products. There’s no shame in that—as long as you try hard, very hard, to find and correct the mistakes before they are delivered to end users. Technical reviews are the most effective mechanism for finding mistakes early in the software process. Who does it? Software engineers perform techni- cal reviews, also called peer reviews, with their colleagues. Why is it important? If you find an error early in the process, it is less expensive to correct. In addi- tion, errors have a way of amplifying as the process proceeds. So a relatively minor error left untreated early in the process can be amplified into a major set of errors later in the project. Finally, reviews save time by reducing the amount of rework that will be required late in the project. Q U I C K L O O K What are the steps? Your approach to reviews will vary depending on the degree of formality you select. In general, six steps are employed, although not all are used for every type of review: planning, preparation, structuring the meeting, noting errors, making corrections (done outside the review), and verifying that corrections have been performed properly. What is the work product? The output of a review is a list of issues and/or errors that have been uncovered. In addition, the technical status of the work product is also indicated. How do I ensure that I’ve done it right? First, select the type of review that is appropriate for your development culture. Follow the guidelines that lead to successful reviews. If the reviews that you conduct lead to higher-quality soft- ware, you’ve done it right. pre75977_ch15.qxd 11/27/08 5:54 PM Page 416 2. Confirm those parts of a product in which improvement is either not desired or not needed; 3. Achieve technical work of more uniform, or at least more predictable, quality than can be achieved without reviews, in order to make technical work more manageable. Many different types of reviews can be conducted as part of software engineering. Each has its place. An informal meeting around the coffee machine is a form of review, if technical problems are discussed. A formal presentation of software architecture to an audience of customers, management, and technical staff is also a form of review. In this book, however, I focus on technical or peer reviews, exempli- fied by casual reviews, walkthroughs, and inspections. A technical review (TR) is the most effective filter from a quality control standpoint. Conducted by software engi- neers (and others) for software engineers, the TR is an effective means for uncover- ing errors and improving software quality. 1 5 . 1 C O S T I M PA C T O F S O F T WA R E D E F E C T S Within the context of the software process, the terms defect and fault are synony- mous. Both imply a quality problem that is discovered after the software has been released to end users (or to another framework activity in the software process). In earlier chapters, we used the term error to depict a quality problem that is discovered by software engineers (or others) before the software is released to the end user (or to another framework activity in the software process). C H A P T E R 1 5 R E V I E W T E C H N I Q U E S 417 Reviews are like a filter in the software process workflow. Too few, and the flow is “dirty.” Too many, and the flow slows to a trickle. Use metrics to determine which reviews work and emphasize them. Remove ineffective reviews from the flow to accelerate the process. 1 If software process improvement is considered, a quality problem that is propagated from one process framework activity (e.g., modeling) to another (e.g., construction) can also be called a “defect” (because the problem should have been found before a work product (e.g., a design model) was “released” to the next activity. Bugs, Errors, and Defects The goal of software quality control, and in a broader sense, quality management in general, is to remove quality problems in the software. These problems are referred to by various names—bugs, faults, errors, or defects to name a few. Are each of these terms synonymous, or are there subtle differences between them? In this book I make a clear distinction between an error (a quality problem found before the software is released to end users) and a defect (a quality problem found only after the software has been released to end users1). I make this distinction because errors and defects have very different economic, business, psychological, and human impact. As software engineers, we want to find and correct as many errors as possible before the customer and/or end user encounter them. We want to avoid defects—because defects (justifiably) make software people look bad. It is important to note, however, that the temporal distinction made between errors and defects in this book is not mainstream thinking. The general consensus within the software engineering community is that defects and errors, faults, and bugs are synonymous. That is, the point in time that the problem was encountered has no bearing on the term used to describe the problem. Part of the argument in favor of this view is that it is sometimes difficult to make a INFO pre75977_ch15.qxd 11/27/08 5:54 PM Page 417 418 P A R T T H R E E Q U A L I T Y M A N A G E M E N T The primary objective of technical reviews is to find errors during the process so that they do not become defects after release of the software. The obvious benefit of technical reviews is the early discovery of errors so that they do not propagate to the next step in the software process. A number of industry studies indicate that design activities introduce between 50 and 65 percent of all errors (and ultimately, all defects) during the software process. However, review techniques have been shown to be up to 75 percent effective [Jon86] in uncovering design flaws. By detecting and removing a large percentage of these errors, the review process substantially reduces the cost of subsequent activi- ties in the software process. 1 5 . 2 D E F E C T A M P L I F I C AT I O N A N D R E M O VA L A defect amplification model [IBM81] can be used to illustrate the generation and detection of errors during the design and code generation actions of a software process. The model is illustrated schematically in Figure 15.1. A box represents a soft- ware engineering action. During the action, errors may be inadvertently generated. Review may fail to uncover newly generated errors and errors from previous steps, resulting in some number of errors that are passed through. In some cases, errors passed through from previous steps are amplified (amplification factor, x) by current work. The box subdivisions represent each of these characteristics and the percent of efficiency for detecting errors, a function of the thoroughness of the review. Figure 15.2 illustrates a hypothetical example of defect amplification for a software process in which no reviews are conducted. Referring to the figure, each test step is assumed to uncover and correct 50 percent of all incoming errors without intro- ducing any new errors (an optimistic assumption). Ten preliminary design defects are amplified to 94 errors before testing commences. Twelve latent errors (defects) are released to the field. Figure 15.3 considers the same conditions except that design and code reviews are conducted as part of each software engineering action. In this case, 10 initial preliminary (architectural) design errors are amplified to 24 errors before testing commences. Only three latent errors exist. The relative costs associated with the discovery and correction of errors, overall cost (with and without review for our hypothetical example) can be established. The number of errors uncovered during each of the steps noted in Figures 15.2 and 15.3 is multiplied by the cost to remove an clear distinction between pre- and post-release (e.g., consider an incremental process used in agile development). Regardless of how you choose to interpret these terms, recognize that the point in time at which a problem is discovered does matter and that software engineers should try hard—very hard—to find problems before their customers and end users encounter them. If you have further interest in this issue, a reasonably thorough discussion of the terminology surrounding “bugs” can be found at www.softwaredevelopment.ca/bugs.shtml. The primary objective of an FTR is to find errors before they are passed on to another software engineering activity or released to the end user. uote: “Some maladies, as doctors say, at their beginning are easy to cure but difficult to recognize … but in the course of time when they have not at first been recognized and treated, become easy to recognize but difficult to cure.” Niccolo Machiavelli pre75977_ch15.qxd 11/27/08 5:54 PM Page 418 C H A P T E R 1 5 R E V I E W T E C H N I Q U E S 419 Errors passed through Development step Defects Detection Errors from previous step Amplified errors 1 : x Newly generated errors Percent efficiency for error detection Errors passed to next step FIGURE 15.1 Defect amplifi- cation model 6 Preliminary design 0 10 0 0\% 10 6 4 Detail design 4 × 1.5 x = 1.5 25 0\% 3710 27 Code/unit test 10 25 27 × 3 x = 3 20\% 94 To integration 94 Integration test 0 0 50\% 47 Validation test 0 0 50\% 24 System test 0 0 50\% 12 Latent errors (defects) FIGURE 15.2 Defect amplifi- cation—no reviews Preliminary design 0 10 0 Detail design 25 Code/unit test 25 To integration Integration test 0 0 50\% Validation test 0 0 50\% System test 0 0 50\% Latent errors (defects) 3 2 1 70\% 50\% 2 1 1.5 24 6 3 2460\% 5 10 3 • • 15 5 10 12 FIGURE 15.3 Defect amplifi- cation— reviews conducted pre75977_ch15.qxd 11/27/08 5:54 PM Page 419 error (1.5 cost units for design, 6.5 cost units before test, 15 cost units during test, and 67 cost units after release).2 Using these data, the total cost for development and maintenance when reviews are conducted is 783 cost units. When no reviews are conducted, total cost is 2177 units—nearly three times more costly. To conduct reviews, you must expend time and effort, and your development organization must spend money. However, the results of the preceding example leave little doubt that you can pay now or pay much more later. 1 5 . 3 R E V I E W M E T R I C S A N D T H E I R U S E Technical reviews are one of many actions that are required as part of good software engineering practice. Each action requires dedicated human effort, Since available project effort is finite, it is important for a software engineering organization to understand the effectiveness of each action by defining a set of metrics (Chapter 23) that can be used to assess their efficacy. Although many metrics can be defined for technical reviews, a relatively small subset can provide useful insight. The following review metrics can be collected for each review that is conducted: • Preparation effort, Ep—the effort (in person-hours) required to review a work product prior to the actual review meeting • Assessment effort, Ea—the effort (in person-hours) that is expended during the actual review • Rework effort, Er—the effort (in person-hours) that is dedicated to the correc- tion of those errors uncovered during the review • Work product size, WPS—a measure of the size of the work product that has been reviewed (e.g., the number of UML models, or the number of document pages, or the number of lines of code) • Minor errors found, Errminor—the number of errors found that can be catego- rized as minor (requiring less than some prespecified effort to correct) • Major errors found, Errmajor—the number of errors found that can be catego- rized as major (requiring more than some prespecified effort to correct) These metrics can be further refined by associating the type of work product that was reviewed for the metrics collected. 15.3.1 Analyzing Metrics Before analysis can begin, a few simple computations must occur. The total review effort and the total number of errors discovered are defined as: Ereview ! Ep Ea Er Errtot ! Errminor Errmajor 420 P A R T T H R E E Q U A L I T Y M A N A G E M E N T 2 These multipliers are somewhat different than the data presented in Figure 14.2, which is more current. However, they serve to illustrate the costs of defect amplification nicely. pre75977_ch15.qxd 11/27/08 5:54 PM Page 420 Error density represents the errors found per unit of work product reviewed. Error density ! For example, if a requirements model is reviewed to uncover errors, inconsistencies, and omissions, it would be possible to compute the error density in a number of dif- ferent ways. The requirements model contains 18 UML diagrams as part of 32 over- all pages of descriptive materials. The review uncovers 18 minor errors and 4 major errors. Therefore, Errtot ! 22. Error density is 1.2 errors per UML diagram or 0.68 errors per requirements model page. If reviews are conducted for a number of different types of work products (e.g., requirements model, design model, code, test cases), the percentage of errors uncovered for each review can be computed against the total number of errors found for all reviews. In addition, the error density for each work product can be computed. Once data are collected for many reviews conducted across many projects, aver- age values for error density enable you to estimate the number of errors to be found in a new (as yet unreviewed document). For example, if the average error density for a requirements model is 0.6 errors per page, and a new requirement model is 32 pages long, a rough estimate suggests that your software team will find about 19 or 20 errors during the review of the document. If you find only 6 errors, you’ve done an extremely good job in developing the requirements model or your review approach was not thorough enough. Once testing has been conducted (Chapters 17 through 20), it is possible to collect additional error data, including the effort required to find and correct errors uncov- ered during testing and the error density of the software. The costs associated with finding and correcting an error during testing can be compared to those for reviews. This is discussed in Section 15.3.2. 15.3.2 Cost Effectiveness of Reviews It is difficult to measure the cost effectiveness of any technical review in real time. A software engineering organization can assess the effectiveness of reviews and their cost benefit only after reviews have been completed, review metrics have been col- lected, average data have been computed, and then the downstream quality of the software is measured (via testing). Returning to the example presented in Section 15.3.1, the average error density for requirements models was determined to be 0.6 errors per page. The effort required to correct a minor model error (immediately after the review) was found to require 4 person-hours. The effort required for a major requirement error was found to be 18 person-hours. Examining the review data collected, you find that minor errors occur about 6 times more frequently than major errors. Therefore, you can estimate that the average effort to find and correct a requirements error during review is about 6 person-hours. Errtot WPS C H A P T E R 1 5 R E V I E W T E C H N I Q U E S 421 pre75977_ch15.qxd 11/27/08 5:54 PM Page 421 Requirements-related errors uncovered during testing require an average of 45 person-hours to find and correct (no data are available on the relative severity of the error). Using the averages noted, we get: Effort saved per error ! Etesting # Ereviews 45 # 6 ! 30 person-hours/error Since 22 errors were found during the review of the requirements model, a saving of about 660 person-hours of testing effort would be achieved. And that’s just for requirements-related errors. Errors associated with design and code would add to the overall benefit. The bottom line—effort saved leads to shorter delivery cycles and improved time to market. In his book on peer reviews, Karl Wiegers [Wie02] discusses anecdotal data from major companies that have used inspections (a relatively formal type of technical review) as part of their software quality control activities. Hewlett Packard reported a 10 to 1 return on investment for inspections and noted that actual product delivery accelerated by an average of 1.8 calendar months. AT&T indicated that inspections reduced the overall cost of software errors by a factor of 10 and that quality improved by an order of magnitude and productivity increased by 14 percent. Others report similar benefits. Technical reviews (for design and other technical activities) provide a demonstrable cost benefit and actually save time. But for many software people, this statement is counterintuitive. “Reviews take time,” software people argue, “and we don’t have the time to spare!” They argue that time is a precious commodity on every software project and the ability to review “every work product in detail” absorbs too much time. The examples presented earlier in this section indicate otherwise. More impor- tantly, industry data for software reviews has been collected for more than two decades and is summarized qualitatively using the graphs illustrated in Figure 15.4. 422 P A R T T H R E E Q U A L I T Y M A N A G E M E N T Planning Requirements Without inspections With inspections Deployment Design Code Test Effort Time FIGURE 15.4 Effort expended with and without reviews Source: Adapted from [Fag86]. pre75977_ch15.qxd 11/27/08 5:54 PM Page 422 Referring to the figure, the effort expended when reviews are used does increase early in the development of a software increment, but this early investment for reviews pays dividends because testing and corrective effort is reduced. As impor- tant, the deployment date for development with reviews is sooner than the deploy- ment date without reviews. Reviews don’t take time, they save it! 1 5 . 4 R E V I E W S : A F O R M A L I T Y S P E C T R U M Technical reviews should be applied with a level of formality that is appropriate for the product to be built, the project time line, and the people who are doing the work. Figure 15.5 depicts a reference model for technical reviews [Lai02] that identifies four characteristics that contribute to the formality with which a review is conducted. Each of the reference model characteristics helps to define the level of review formality. The formality of a review increases when (1) distinct roles are explicitly defined for the reviewers, (2) there is a sufficient amount of planning and prepara- tion for the review, (3) a distinct structure for the review (including tasks and inter- nal work products) is defined, and (4) follow-up by the reviewers occurs for any corrections that are made. To understand the reference model, let’s assume that you’ve decided to review the interface design for SafeHomeAssured.com. You can do this in a variety of different ways that range from relatively casual to extremely rigorous. If you decide that the casual approach is most appropriate, you ask a few colleagues (peers) to examine the interface prototype in an effort to uncover potential problems. All of you decide that there will be no advance preparation, but that you will evaluate the prototype in a reasonably structured way—looking at layout first, aesthetics next, navigation op- tions after that, and so on. As the designer, you decide to take a few notes, but noth- ing formal. C H A P T E R 1 5 R E V I E W T E C H N I Q U E S 423 Review Planning & preparation Roles individuals play Meeting structure Correction & verification FIGURE 15.5 Reference model for technical reviews pre75977_ch15.qxd 11/27/08 5:54 PM Page 423 But what if the interface is pivotal to the success of the entire project? What if human lives depended on an interface that was ergonomically sound? You might decide that a more rigorous approach was necessary. A review team would be formed. Each per- son on the team would have a specific role to play—leading the team, recording find- ings, presenting the material, and so on. Each reviewer would be given access to the work product (in this case, the interface prototype) before the review and would spend time looking for errors, inconsistencies, and omissions. A set of specific tasks would be conducted based on an agenda that was developed before the review occurred. The results of the review would be formally recorded, and the team would decide on the status of the work product based on the outcome of the review. Members of the review team might also verify that the corrections made were done properly. In this book I consider two broad categories of technical reviews: informal reviews and more formal technical reviews. Within each broad category, a number of differ- ent approaches can be chosen. These are presented in the sections that follow. 1 5 . 5 I N F O R M A L R E V I E W S Informal reviews include a simple desk check of a software engineering work product with a colleague, a casual meeting (involving more than two people) for the purpose of reviewing a work product, or the review-oriented aspects of pair programming (Chapter 3). A simple desk check or a casual meeting conducted with a colleague is a review. However, because there is no advance planning or preparation, no agenda or meet- ing structure, and no follow-up on the errors that are uncovered, the effectiveness of such reviews is considerably lower than more formal approaches. But a simple desk check can and does uncover errors that might otherwise propagate further into the software process. One way to improve the efficacy of a desk check review is to develop a set of sim- ple review checklists for each major work product produced by the software team. The questions posed within the checklist are generic, but they will serve to guide the reviewers as they check the work product. For example, let’s reexamine a desk check of the interface prototype for SafeHomeAssured.com. Rather than simply playing with the prototype at the designer’s workstation, the designer and a colleague examine the prototype using a checklist for interfaces: • Is the layout designed using standard conventions? Left to right? Top to bottom? • Does the presentation need to be scrolled? • Are color and placement, typeface, and size used effectively? • Are all navigation options or functions represented at the same level of abstraction? • Are all navigation choices clearly labeled? 424 P A R T T H R E E Q U A L I T Y M A N A G E M E N T pre75977_ch15.qxd 11/27/08 5:54 PM Page 424 and so on. Any errors or issues noted by the reviewers are recorded by the designer for resolution at a later time. Desk checks may be scheduled in an ad hoc manner, or they may be mandated as part of good software engineering practice. In general, the amount of material to be reviewed is relatively small and the overall time spent on a desk check spans little more than one or two hours. In Chapter 3, I described pair programming in the following manner: “XP recom- mends that two people work together at one computer workstation to create code for a story. This provides a mechanism for real-time problem solving (two heads are often better than one) and real-time quality assurance.” Pair programming can be characterized as a continuous desk check. Rather than scheduling a review at some point in time, pair programming encourages continu- ous review as a work product (design or code) is created. The benefit is immediate discovery of errors and better work product quality as a consequence. In their discussion of the efficacy of pair programming, Williams and Kessler [Wil00] state: Anecdotal and initial statistical evidence indicates that pair programming is a powerful technique for productively generating high quality software products. The pair works and shares ideas together to tackle the complexities of software development. They continu- ously perform inspections on each other’s artifacts leading to the earliest, most efficient form of defect removal possible. In addition, they keep each other intently focused on the task at hand. Some software engineers argue that the inherent redundancy built into pair pro- gramming is wasteful of resources. After all, why assign two people to a job that one person can accomplish? The answer to this question can be found in Section 15.3.2. If the quality of the work product produced as a consequence of pair programming is significantly better than the work of an individual, the quality-related savings can more than justify the “redundancy” implied by pair programming. C H A P T E R 1 5 R E V I E W T E C H N I Q U E S 425 Review Checklists Even when reviews are well organized and properly conducted, it’s not a bad idea to provide reviewers with a “crib sheet.” That is, it’s worthwhile to have a checklist that provides each reviewer with the questions that should be asked about the specific work product that is undergoing review. One of the most comprehensive collections of review checklists has been developed by NASA at the Goddard Space Flight Center and is available at http:// sw-assurance.gsfc.nasa.gov/disciplines/ quality/index.php Other useful technical review checklists have also been proposed by: Process Impact (www.processimpact.com/ pr_goodies.shtml) Software Dioxide (www.softwaredioxide.com/ Channels/ConView.asp?id=6309) Macadamian (www.macadamian.com) The Open Group Architecture Review Checklist (www.opengroup.org/architecture/ togaf7-doc/arch/p4/comp/clists/syseng.htm) DFAS [downloadable] (www.dfas.mil/ technology/pal/ssps/docstds/spm036.doc) INFO pre75977_ch15.qxd 11/27/08 5:54 PM Page 425 1 5 . 6 F O R M A L T E C H N I C A L R E V I E W S A formal technical review (FTR) is a software quality control activity performed by software engineers (and others). The objectives of an FTR are: (1) to uncover errors in function, logic, or implementation for any representation of the software; (2) to verify that the software under review meets its requirements; (3) to ensure that the software has been represented according to predefined standards; (4) to achieve software that is developed in a uniform manner; and (5) to make projects more man- ageable. In addition, the FTR serves as a training ground, enabling junior engineers to observe different approaches to software analysis, design, and implementation. The FTR also serves to promote backup and continuity because a number of people become familiar with parts of the software that they may not have otherwise seen. The FTR is actually a class of reviews that includes walkthroughs and inspections. Each FTR is conducted as a meeting and will be successful only if it is properly planned, controlled, and attended. In the sections that follow, guidelines similar to those for a walkthrough are presented as a representative formal technical review. If you have interest in software inspections, as well as additional information on walkthroughs, see [Rad02], [Wie02], or [Fre90]. 15.6.1 The Review Meeting Regardless of the FTR format that is chosen, every review meeting should abide by the following constraints: • Between three and five people (typically) should be involved in the review. • Advance preparation should occur but should require no more than two hours of work for each person. • The duration of the review meeting should be less than two hours. Given these constraints, it should be obvious that an FTR focuses on a specific (and small) part of the overall software. For example, rather than attempting to review an entire design, walkthroughs are conducted for each component or small group of components. By …