1. Software Engineering: Principles and Practices (Second Edition)
Chapter 7 Software Quality Control
These slides may only be used in conjunction with Software Engineering: Principles and Practices (Second Edition) by Robert E. Beasley. Any other use is prohibited without the express written permission of the author. Copyright © 2017 by Robert E. Beasley.
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

2. Software Engineering: Principles and Practices (Second Edition)
QUOTE:
“ANY FOOL CAN WRITE CODE THAT A COMPUTER CAN UNDERSTAND. GOOD PROGRAMMERS WRITE CODE THAT HUMANS CAN UNDERSTAND.” Martin Fowler (Software Engineer and Author)
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

3. What is software quality control?
Software quality control is the process of ensuring that a software item is of acceptable quality. Software items include individual software components, entire software systems, and any related artifacts, such as analysis, design, implementation, and maintenance documents. One of the most important software quality control measures is the software review. Software quality control is an umbrella task that occurs throughout the entire SDLC.
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

4. Software Engineering: Principles and Practices (Second Edition)
Table 7 1. Interactions between the purposes and focuses of software reviews
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

5. Advantages of the collaborative document review
They are simple to execute
They do not require training
It is easy to determine when a review is complete
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

6. Disadvantages of the collaborative document review
They must be done synchronously, which requires the coordination of work schedules
There is no mechanism in place to ensure that any required changes are made
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

7. Advantages of the code walkthrough review
They are simple to execute
They do not require training
It is easy to determine when a review is complete
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

8. Disadvantages of the code walkthrough review
They must be done synchronously, which requires the coordination of work schedules
There is no mechanism in place to ensure that any required changes are made
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

9. Advantages of the desk check review
They are simple to execute
They do not require training
When performed before coding, they permit the reviewer to suggest alternative implementations of the code
When the author and the reviewer are different people, they can be done equally easily over short and long distances
When the author and the reviewer are different people, they can be done asynchronously
It is easy to determine when a review is complete
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

10. Disadvantages of the desk check review
When the reviewer is also the author of the code, it may be difficult for him or her to be objective
There is no mechanism in place to ensure that any required changes are made
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

11. Advantages of the email pass-around review
They are simple to execute
They do not require training
They can be done equally easily over short and long distances
It is easy to include additional reviewers in the review process
They can be done asynchronously
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

12. Disadvantages of the email pass-around review
If too many people become involved in the review process, they can devolve into an unreadable mass of comments, replies, and examples
It is difficult to manage multiple reviews at the same time
It is difficult to determine when a review is complete
There is no mechanism in place to ensure that any required changes are made
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

13. Advantages of the over-the-shoulder review
They are simple to execute
They do not require training
They can be done over long distances using document sharing systems, conferencing systems, desktop sharing applications, and so on
There is a mechanism in place to ensure that minor required changes are made
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

14. Disadvantages of the over-the-shoulder review
It may be difficult for the reviewer to be objective in the presence of the author
They must be done synchronously, which requires the coordination of work schedules
There is no mechanism in place to ensure that major required changes are made
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

15. Advantages of the pair-programming review
They are simple to execute
They do not require training
Since the reviewer is so close to the code, he or she has a detailed understanding of it
They permit the reviewer to suggest alternative implementations of the code
They promote knowledge transfer between software engineers
There is a mechanism in place to ensure that any required changes are made (i.e., teammate)
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

16. Disadvantages of the pair-programming review
Since the reviewer is so close to the code, it may be difficult for him or her to be objective
Since it takes the continuous full-time attention of a second software engineer, it is very costly—at least in the short term
They must be done synchronously, which requires the coordination of work schedules
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

17. Tasks of the tool-assisted software review process
Gathering the software items to be reviewed
Transmitting the software items to their respective reviewers
Identifying the changes that have been made to the software items
Displaying the before and after differences in the software items
Enabling the reviewers to review and comment on the software items
Collecting review metrics, such as the inspection rate (LOC/hour), defect rate (defects/hour), and the defect density (defects/KLOC)
Permitting software managers to control and enforce the workflow of the review process
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

18. Advantages of the tool-assisted review
They can be done equally easily over short and long distances
It is easy to determine when a review is complete
They can be done asynchronously
There is a mechanism in place to ensure that any required changes are made
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

19. Disadvantages of the tool-assisted review
It may be costly to purchase or develop such a tool
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

20. Phases of a formal technical review
Planning (i.e., the software item to be reviewed is validated to ensure that it meets the criteria for a review, all quality checklists are created, appropriately competent individuals are invited to participate, the agendas for all the meetings are created, the overview meeting is scheduled, and all necessary resources are reserved)
Overview meeting (i.e., the goals and rules of the review meeting are explained, the software item to be reviewed is described and placed into a meaningful context, all participants are reminded to prepare for the review meeting by inspecting the software item personally, and the review meeting is scheduled)
Preparation (i.e., the software item is inspected by all reviewers personally)
Review meeting (i.e., the software item is reviewed as a group, any defects and suggestions for improvement are logged, and any statistical measures [e.g., number of defects identified, number of technical review hours utilized] are collected)
Rework (i.e., any defects are corrected, any statistical measures [e.g., number of person days utilized, number of testing hours utilized] are collected, and the verification meeting is scheduled)
Verification meeting (i.e., any defect corrections and improvements are verified)
Follow-up (i.e., suggestions regarding how to improve the review process are articulated)
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

21. Responsibilities of the facilitator
Inviting an appropriate set of participants to the review
Scheduling the review meetings
Reserving the resources necessary for the review meetings (e.g., rooms, technologies, refreshments)
Setting the agendas for the review meetings
Developing quality checklists for the item to be reviewed
Insisting on advanced preparation by all participants
Conducting meaningful training for all participants
Ensuring that the agendas are followed during the review meetings
Limiting debate and rebuttal during the review meetings
Finishing the review meetings on time or when some predefined exit criteria is satisfied
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

22. Responsibilities of the author
Describing the background of the software item for the review participants
Orienting the review participants by putting the software item into a meaningful context
Walking the review participants through the software item being reviewed
Pointing out the software item’s potential problem areas
Reworking the software item based on the action plan mandated at the end of the review meeting
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

23. Responsibilities of the reviewers
Examining the software item before the review meeting to become familiar with it
Inspecting the software item during the review meeting
Pointing out any defects in the software item
Making any suggestions for improving the software item
Reviewing any revisions to the software item during the verification meeting to ensure that all required modifications have been made
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

24. Responsibilities of the end-user representative
Examining the software item before the review meeting to become familiar with it
Inspecting the software item during the review meeting
Pointing out any defects in the software item
Making any suggestions for improving the software item
Reviewing any revisions to the software item during the verification meeting to ensure that all required modifications have been made
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

25. Software Engineering: Principles and Practices (Second Edition)
Summary report items
Who participated in the various meetings
What was reviewed
What defects were identified during the review meeting
What improvements were suggested during the review meeting
What the plan of action is for correcting any defects and/or improving the software item
What is being recommended (i.e., accept the software item, accept the software item with revisions, or reject the software item)
What the plan is for follow-up
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

26. Figure 7 1. Formal technical review summary report (Part 1)
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

27. Figure 7 2. Formal technical review summary report (Part 2)
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

28. Advantages of the formal technical review
It is easy to determine when a review is complete
There is a mechanism in place to ensure that any required changes are made
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

29. Disadvantages of the formal technical review
They require training
They must be done synchronously, which requires the coordination of work schedules
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

30. Table 7 2. Attributes of informal and formal technical reviews
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

31. Figure 7 3. Relationship between defect density and review scope
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

32. Figure 7 4. Relationship between defect density and review rate
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

33. Figure 7 5. Relationship between defect density and review preparation
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

34. Examples of internal goals
Increase the number of lines of code reviewed per hour by 20 percent
Increase the number of preparatory comments made by authors by 50 percent
Increase the defect removal efficiency of the review process by 20 percent
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

35. Examples of external goals
Reduce the number of support calls by 20 percent
Reduce the number of defects reported by end users by 30 percent
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

36. Requirements review checklist
Ambiguous requirements (i.e., vague, unclear, confusing requirements)
Conflicting requirements (i.e., contradictory, incompatible, opposing requirements)
Inaccurate requirements (i.e., imprecise, incorrect requirements)
Incomplete requirements (i.e., partial, inadequate requirements)
Inconsistent requirements (i.e., variable, uneven requirements)
Infeasible requirements (i.e., impractical, unrealistic requirements)
Missing requirements (i.e., absent, omitted, overlooked requirements)
Overlapping requirements (i.e., intersecting, redundant requirements)
Unnecessary requirements (i.e., needless, superfluous requirements)
Untraceable requirements (i.e., unattributable, unascribed requirements)
Unverifiable requirements (i.e., unconfirmable, untestable requirements)
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

37. Table 7 3. Requirements review checklist
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

38. White-box test review checklist
Arithmetic testing
Basis path testing
Condition testing
Data Access testing
Data structure boundary testing
Initialization testing
Loop testing
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

39. Table 7 4. White-box test review checklist
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

40. Black-box test review checklist
Accessibility testing
Build verification testing
Combinatorial testing
Comparison testing
Compatibility testing
Content testing
Installation, upgrade, and removal testing
Interface boundary testing
Performance testing
Recovery testing
Regression testing
Security testing
Usability testing
User-interface testing
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

41. Table 7 5. Black-box test review checklist
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

42. Construction style review checklist
Comments
Indentation
Line breaks
Naming standards
Spacing
Statements per line
Vertical alignment
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

43. Table 7 6. Construction style review checklist
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

44. Construction principles review checklist
Abstraction
Command-query separation
Defensive programming
Expandability
Fail-fast
Keep it simple stupid
Open-closed
Secure programming
Separation of concerns
Variable scope
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

45. Table 7 7. Construction principles review checklist
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

46. Table 7 8. Personal review checklist
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

47. Software review process
Defects are logged
Defects are discussed by authors and reviewers
Defects are corrected by authors
Corrections are communicated to reviewers
Corrections are verified by reviewers
Reviews are signed off on by managers
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

48. Opportunities of each uncovered defect
Correct bad habits
Learn from mistakes
Learn new techniques
Expand capabilities
See the value of teamwork in improving a product
Improve the quality of the software item under review
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

49. Reasons why software reviews result in higher quality software systems
Defects are identified and corrected
Authors become more adept at producing software items that contain fewer defects prior to review
The development process becomes better at preventing software defects that can be introduced as a result of process inadequacies
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

50. Figure 7 6. Relative cost of correcting software defects
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

51. Figure 7 7. Origin of software defects
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

52. Software Engineering: Principles and Practices (Second Edition)
Table 7 9. Variables associated with the defect amplification and removal model
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

53. Software Engineering: Principles and Practices (Second Edition)
Table 7 9. Variables associated with the defect amplification and removal model (continued)
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

54. Software Engineering: Principles and Practices (Second Edition)
Figure 7 8. DARM without reviews and where all remaining defects are removed during testing
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

55. Software Engineering: Principles and Practices (Second Edition)
Figure 7 9. DARM without reviews and where all remaining defects are removed during operation
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

56. Software Engineering: Principles and Practices (Second Edition)
Figure DARM with reviews and where all remaining defects are removed during testing
11/24/2018
Software Engineering: Principles and Practices (Second Edition)

57. Software Engineering: Principles and Practices (Second Edition)
Figure DARM with reviews and where all remaining defects are removed during operation
11/24/2018
Software Engineering: Principles and Practices (Second Edition)