Audits designated software work products to verify compliance with those defined as part of the software process. Ensures that deviations in software work and work products are documented and handled according to a documented procedure.
Records any noncompliance and reports to senior management. Coordinates the control and management of change Software Reviews Software reviews - applied at various points during software development and serve to uncover errors and defects that can then be removed. Reasons: People make mistakes. Need technical reviews to catch a large classes of errors that escape the originator more easily than they escape anyone else. A review is a way of using the diversity of a group of people to: o Point out needed improvements in the product of a single person or team; Confirm those parts of a product in which improvement is either not desired or not needed; 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.
Technical review - walkthrough or inspection Most effective filter from a quality assurance standpoint. Conducted by software engineers, effective means for improving software quality. An incorrect step, process, or data definition in a computer program. Primary objective of formal technical reviews Find errors during the process so that they do not become defects after release of the software.
Benefit - the early discovery of errors so they do not propagate to the next step in the software process. Defect Amplification and Removal Defect amplification model: used to illustrate the generation and detection of errors during the preliminary design, detail design, and coding steps of the software engineering process.
A box 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. Hypothetical example of defect amplification for a software development process in which no reviews are conducted. Each test step uncovers and corrects 50 percent of all incoming errors without introducing any new errors.
Ten preliminary design defects are amplified to 94 errors before testing commences. Twelve latent errors are released to the field. Same conditions except that design and code reviews are conducted as part of each development step. Ten initial preliminary design errors are amplified to 24 errors before testing commences. Only three latent errors exist. Formal Technical Reviews FTR Objectives of the FTR — to uncover errors in function, logic, or implementation for any representation of the software to verify that the software under review meets its requirements to ensure that the software has been represented according to predefined standards to achieve software that is developed in a uniform manner; to make projects more manageable.
The Review Meeting Review meeting constraints: Between three and five people should be involved in the review. Advance preparation should require no more than two hours of work for each person.
The duration of the review meeting should be less than two hours. At the end of the review, all attendees of the FTR must decide whether to 1. Review Guidelines Minimum set of guidelines for formal technical reviews: Review the product, not the producer. Set an agenda and maintain it. Limit debate and rebuttal. Enunciate problem areas, but don ' t attempt to solve every problem noted. Take written notes. Limit the number of participants and insist upon advance preparation. Develop a checklist for each product that is likely to be reviewed.
Allocate resources and schedule time for FTRs. Conduct meaningful training for all reviewers. Review your early reviews. Statistical Software Quality Assurance Statistical quality assurance implies the following steps: Information about software defects is collected and categorized.
An attempt is made to trace each defect to its underlying cause e. Using the Pareto principle 80 percent of the defects can be traced to 20 percent of all possible causes , isolate the 20 percent the "vital few".
Once the vital few causes have been identified, move to correct the problems that have caused the defects. Example: Assume that a software engineering organization collects information on defects for a period of one year. Some of the defects are uncovered as software is being developed. Once the vital few causes are determined, the software engineering organization can begin corrective action.
Statistical quality assurance techniques for software have been shown to provide substantial quality improvement up to 50 percent reduction per year in defects after applying these techniques. The items that comprise all information produced as part of the software process are collectively called a software configuration.
New customer needs demand modification of data produced by information systems, functionality delivered by products, or services delivered by a computer-based system. Budgetary or scheduling constraints cause a redefinition of the system or product.
Notify me of new posts via email. Software Testing Concepts Testers don't make software, they make it better. Stay updated via RSS. Join 31 other followers. Defect Removal Efficiency. Share this: Twitter Facebook. Like this: Like Loading Leave a Reply Cancel reply Enter your comment here Fill in your details below or click an icon to log in:.
Email required Address never made public. Name required. Blog at WordPress. Follow Following. Software Testing Concepts Join 31 other followers. Sign me up.
0コメント