A defect amplification model can be used to illustrate the generation and detection of errors during the preliminary design, detail design, and coding steps of the software engineering process.It represents a software development step. During the step, 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.
FORMAL TECHNICAL REVIEWS
A formal technical review is a software quality assurance activity performed by software engineers (and others).
The objectives of the 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 manageable. 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, inspections, round-robin reviews and other small group technical assessments of software.
Each FTR is conducted as a meeting and will be successful only if it is properly planned, controlled, and attended.
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.
conducted for each component or small group of components. By narrowing focus, the FTR has a higher likelihood of uncovering errors.
The focus of the FTR is on a work product (e.g., a portion of a requirements specification, a detailed component design, a source code listing for a component). The individual who has developed the work product—the producer—informs the project leader that the work product is complete and that a review is required.
The project leader contacts a review leader, who evaluates the product for readiness, generates copies of product materials, and distributes them to two or three reviewers for advance preparation. Each reviewer is expected to spend between one and two hours reviewing the product, making notes, and otherwise becoming familiar with the work. Concurrently, the review leader also reviews the product and establishes an agenda for the review meeting, which is typically scheduled for the next day.
The review meeting is attended by the review leader, all reviewers, and the producer. One of the reviewers takes on the role of the recorder; that is, the individual who records (in writing) all important issues raised during the review.
The FTR begins with an introduction of the agenda and a brief introduction by the producer. The producer then proceeds to "walk through" the work product, explaining the material, while reviewers raise issues based on their advance preparation. When valid problems or errors are discovered, the recorder notes each.
At the end of the review, all attendees of the FTR must decide whether to
(1) accept the product without further modification,
(2) reject the product due to severe errors (once corrected, another review must be performed), or
(3) accept the product provisionally (minor errors have been encountered and must be corrected, but no additional review will be required).
The decision made, all FTR attendees complete a sign-off, indicating their participation in the review and their concurrence with the review team's findings.
RELATED POST
VALIDATION TESTING
SYSTEM TESTING
DEBUGGING AND TESTING
DEFECT AMPLIFICATION AND REMOVAL
ITERATIVE SPIRAL MODEL
STANDARD WATER MODEL
CONFIGURATION MANAGEMENT
CONTROLLED TESTING ENVIRONMENT
RISK ANALYSIS PART ONE
RISK ANALYSIS PART TWO
BACK GROUND ISSUES
SOFTWARE REVIEWS PART ONE
SOFTWARE REVIEWS PART TWO
SOFTWARE RELIABILITY
SAFETY ASPECTS
MISTAKE PROOFING
SCRIPT ENVIRONMENT
V MODEL IN TESTING
No comments:
Post a Comment