280 likes | 290 Views
Understand cost of quality, SQA activities, software reviews, defect removal, statistical quality assurance, and more in software project management. Learn about prevention, appraisal, failure costs, and the importance of software reviews in quality management.
E N D
Software Project Management Lecture # 13
Outline • Chapter 26 – Quality Management • Cost of Quality • SQA Activities • Software Reviews • Defect Amplification and Removal • Sample Driven Reviews • Statistical Quality Assurance • Six Sigma
Cost of Quality • It includes all costs incurred in performing quality related activities • Cost of quality studies are conducted to • Provide a baseline for current cost of quality • Identify opportunities for reducing cost of quality • Provide normalized basis of comparison (usually in dollars) • Quality costs are divided into • Prevention costs • Appraisal costs • Failure costs
Cost of Quality (Contd.) • Prevention costs relate to • Quality planning • Formal technical reviews • Test equipment • training • Appraisal costs relate to • Activities to gain insight into product – “first time through” each process, e.g., • In-process and inter process inspection • Equipment calibration &maintenance • testing
Cost of Quality (Contd.) • Failure costs • Those that would disappear if no defects appeared before shipping a product to customer • Failure costs subdivided into 2 types • Internal failure costs (related to defects found before product is shipped) • Rework, repair & failure analysis mode • External failure costs (related to defects found after product is shipped) • Complaint resolution, product return and replacement, helpline support & warranty work
Relative cost of correcting an error • Refer to figure 26.1
Software Quality Assurance Activities • SQA is an activity that is applied throughout the software process (not after the software has been developed). It covers the following: • Quality management approach. • Effective software engineering technology (methods & tools). • Formal technical reviews (applied throughout the process). • A multi-tiered testing strategy. • Control of software documentation & changes made to it. • A procedure to assure compliance with software development standards. • Measurement & reporting mechanism.
Software Quality Assurance Activities • There are two different constituencies involved in managing SQA activities: • Software Engineers • They address quality by • applying solid technical methods & measures • conducting formal technical reviews • performing well planned software testing • SQA Group • They assist software team to achieve a high quality end product. • They are responsible for QA planning, oversight, record keeping, analysis and reporting.
Software Quality Assurance Activities • SEI recommends the following set of SQA group activities: • Prepares an SQA plan for project. • Participates in the development of project’s software process description. • Reviews s/w engg activities to verify compliance with defines s/w process. • Audits designated s/w work products to verify compliance. • Ensures that deviations in s/w work & work products are documented. • Records any non compliance & reports to senior management. • SQA group also coordinates the change management & helps to collect & analyze software metrics
Software Reviews • Software Reviews are applied at various stages of software engg. process to identify errors that can be removed. • Hence they are a filter or purifier for software process. • Reviews are important as errors often go unnoticed by the originator. Others can catch them more easily. • The idea is to use diverse people as reviewers to: • Point out improvements in a product • Confirm parts of product that do not need improvement • Achieve technical work of uniform or at least predictable quality
Software Reviews • Software Reviews can be of many different types. • An informal meeting in office around the coffee machine is a type of review where technical problems are discussed. • A formal presentation of software design to an audience of customers, management and technical staff is another type of review. • Formal inspection is a formal & scheduled activity where a selected group of peers/others evaluate the tech. aspects of the design/material presented.
Formal Technical Reviews • Formal inspection or Formal Technical Review (FTR) is an SQA activity. Its objectives are: • To uncover errors in function, logic or implementation for any s/w • To verify s/w under review meets its requirements • To ensure that s/w complies to standards • To achieve a s/w developed in uniform manner • To make projects more manageable
Cost Impact of Software Defects • The primary objective of FTRs is to find errors before they become defects. • Hence, their obvious benefit is early discovery of errors so that they do not propagate to the next step in software process. • Industry studies indicate that design activities introduce 50-65% of all errors during the software process.
Cost Impact of Software Defects (Contd.) • Formal review techniques have been found to be 75% effective in uncovering design flaws. • Thus review process substantially reduces cost of subsequent activities in software process • Example • Assume that error found during design will cost 1.0 monetary unit to correct. • Relative to this cost, same error uncovered before testing begins, will cost 6.5 units, during testing 15 units, and after release between 60 & 100 units
Defect Amplification Model Development step Defects Detection v Errors passed through Errors from previous step Percent efficiency for error detection Percent efficiency for error detection Errors passed to next step Amplified errors 1: x Amplified errors 1: x Amplified errors 1: x Newly generated errors Newly generated errors Newly generated errors
Defect Amplification & Removal • The defect amplification model illustrated in previous slide indicates the following for development phase of software process • Amplification of errors by a factor x, due to current phase work. These errors are originally passed on from previous steps e.g. design • New errors unintentionally generated which the review may fail to identify, • Some errors are passed through • Error Detection of some errors • Based on the defect amplification model, a hypothetical example for software process is considered with and without reviews (see next slide) • It has been found that if reviews are conducted, the number latent errors are less and hence the total cost of correcting errors is reduced.
Defect Amplification & Removal (a) Defect Amplification – no reviews (b) Defect Amplification – reviews conducted
Sample Driven Reviews • In real world of s/w projects, resources are limited and time is short. • In such situations, reviews are often skipped. • Thelin and his colleagues address this issue by suggesting a sample-driven review process. • In this, samples of all s/w work products are inspected to determine which work products are more error prone. • Full FTR resources are then focused only to those work products that are likely to be error-prone .
Sample Driven Reviews (Contd.) • Sample driven review must attempt to quantify those work products that are primary targets for full FTRs. • Following are the suggested steps: • Inspect a fraction ai of each software work product, i. Record the number of faults, fi found within ai • Develop a gross estimate of the no. of faults within the work product i by multiplying fi by 1/ ai • Sort the work products in descending order according to the gross estimate of the number of faults in each. • Focus available review resources on those work products that have the highest estimated number of faults
Sample Driven Reviews (Contd.) • The fraction of work product that is sampled must be • …representative of the work product as a whole and • …Large enough to be meaningful to the reviewer(s) who does the sampling
Formal Approaches to SQA • Over the past few years, s/w engg community has argued that SQA requires a more formal approach • It can be argued that • a computer program is a mathematical object. • Syntax and semantics can be defined for every prog. language • Formal approaches for software requirements are also available • If req. specification and prog. language can be represented in a rigorous manner, than it should be possible to apply mathematical proof of correctness to show that a program conforms exactly to its specification – which is SQA
Formal Approaches to SQA(Contd.) • These approaches include • Statistical software quality assurance • Six sigma for software engg.
Statistical Quality Assurance • It’s a quantitative approach about quality. Following are the steps: • Information about software defects is collected and categorized • An attempt is made to trace each defect to its underlying cause (e.g., non-conformance to its specification, design error, violation of standards, etc.) • Using the Pareto Principle (80% of the defects can be traced to 20% of all possible causes), isolate the 20% “vital few” • After identifying the vital few, move to correct the problems that have caused the defects.
Six Sigma … • It is the most widely used strategy used in industry for statistical quality assurance. • It was originally popularized by Motorola in 1980s. • It can be described as • A rigorous and disciplined methodology that uses data and the statistical analysis to measure & improve a company’s operational performance by identifying and eliminating ‘defects’ in manufacturing & service-related processes
Six Sigma (Contd.) • Six sigma methodology defines 3 core steps: • Define customer requirements, deliverables, & project goals via well defined methods of customer comm. • Measurethe existing process & its output to determine current quality performance (collect defect metrics) • Analyze defect metrics & determine the vital few causes.
Six Sigma (Contd.) • If an existing software process is in place, but improvement is required, Six Sigma suggests 2 additional steps: • Improve the process by eliminating the root causes of defects • Controlthe process to ensure that future work does not reintroduce the causes of defects • These core steps and additional steps are also referred to as DMAIC method
Six Sigma (Contd.) • If an organization is developing a software process (rather than improving an existing one), the core steps are augmented by: • Designthe process to (1) avoid the root causes of defects and (2) to meet the customer requirements • Verifythat the process model will, in fact, avoid defects and meet customer requirements • This is referred to as DMADV method
References • Various topics – from Chapter 26 Roger Pressman