16.

1 Cost Impact of Software Defects

 Defects and faults are synonymous in the context of the software process, referring to
quality problems discovered after software release.

 A clear distinction is made between "errors" (quality problems found before release) and
"defects" (quality problems found post-release) in this book.

 The goal of software quality control is to remove quality problems, with a focus on
eliminating defects.

 Errors and defects have di erent economic, business, psychological, and human
impacts.

 The software engineering community generally considers defects, errors, faults, and
bugs to be synonymous, regardless of when they are discovered.

 Recognizing when a problem is discovered matters, and e orts should be made to find
problems before customers and end users encounter them.

 Regardless of terminology, the point in time a problem is discovered is crucial, and

software engineers should strive to identify issues before customers and end users do.

 Various types of reviews can be conducted in software engineering, such as informal

discussions and formal presentations.

 This book primarily focuses on technical or peer reviews, including casual reviews,
walkthroughs, and inspections.

 Technical reviews (TRs) are the most e ective quality control filter conducted by
software engineers and stakeholders for all project team members.

 TRs are essential for finding errors early and improving software quality.

 Design activities introduce a significant number of errors and defects in the software
process.

 Review techniques can be highly e ective in uncovering design flaws, reducing the cost
of subsequent activities.

 The time spent on reviews is generally less than the time required to rewrite bad code,
making reviews a cost-e ective quality control measure.

16.2 Defect Amplification and Removal

 Defect amplification is a concept that emphasizes the importance of software reviews.

It argues that errors introduced early in the software engineering workflow, such as
during requirement modeling, can be amplified into multiple errors during design and
coding if left undetected.

 The propagation of defects refers to the impact of undiscovered errors on future

development activities or product behavior.

 As development progresses, the cost of finding and fixing errors increases, especially
when defects are propagated.
  Detecting and correcting a single error early in the process is more cost-e ective than
addressing multiple errors downstream.

 Technical debt, discussed in Chapter 11, is related to the concept of defect

amplification and highlights the importance of addressing issues early in the
development process.

16.3 Review Metrics and Their Use

 To ensure software quality, various actions are required in software engineering, each
involving dedicated human e ort.

 With finite project e ort, organizations should assess the e ectiveness of these actions
by defining metrics.

 Several metrics can be collected for technical reviews, o ering insights into their
e icacy:

 Preparation e ort (Ep): E ort required to review a work product before the actual
review.

 Assessment e ort (Ea): E ort expended during the review.

 Rework e ort (Er): E ort dedicated to correcting errors uncovered during the
review.

 Review e ort (Ereview): The sum of e ort measures for reviews (Ep + Ea + Er).

 Work product size (WPS): A measure of the size of the reviewed work product.

 Minor errors found (Errminor): The number of errors categorized as minor.

 Major errors found (Errmajor): The number of errors categorized as major.

 Total errors found (Errtot): The sum of errors found (Errminor + Errmajor).

 Error density: Represents errors found per unit of work product reviewed (Errtot /
WPS).

 These metrics help assess the e ectiveness of reviews and provide cost-benefit
insights.

 Review metrics data can be collected across many projects, allowing for the estimation
of errors to be found in new documents before review.

 E ectiveness and cost benefits of reviews are typically assessed after they have been
conducted, metrics collected, and downstream quality measured through testing.

16.4: Criteria for Types of Reviews

 Technical reviews are categorized as formal or informal based on their level of formality.

 A reference model identifies four characteristics contributing to review formality.

1. Roles Individuals Play

2. Planning and preparation for the review.

 3. Meeting Structure.

4. Verification & Correction.

 The frequency of reviews can vary based on the development model.

Section 16.5: Informal Reviews

 Informal reviews are less structured and casual review activities.

 They include activities like desk checks with colleagues or informal meetings.

 Informal reviews often lack detailed planning, preparation, or formal structure.

 Checklists can be used to guide informal reviews and help reviewers focus on important
aspects.

Section 16.6: Formal Technical Reviews (FTR)

 FTRs are structured and comprehensive review meetings with specific roles and
preparation.

 The review meeting is attended by the review leader, all reviewers, and the producer.

 Reviewers raise issues and errors during the review meeting.

 A review summary report and issues list are completed after the review.

 Follow-up is essential to ensure issues are addressed.

Section 16.7: Postmortem Evaluations (PME)

 PMEs are used to assess projects after completion, focusing on lessons learned.

 They aim to identify excellences and challenges in a project.

 PME workshops involve team members and stakeholders.

 PME documents are considered valuable for the project's historical record.

Section 16.8: Agile Reviews

 Agile development includes both informal and formal reviews at various stages.

 Scrum framework incorporates reviews within its activities.

 Daily Scrum meetings serve as informal review sessions.

 The sprint review meeting is a formal review with the product owner.

 The sprint retrospective is similar to a project postmortem meeting for lessons learned.

These sections cover the classification of reviews, emphasizing the importance of planning,
preparation, and structured meetings in FTRs. It also highlights the relevance of informal
reviews and agile practices like Scrum in the software development process.