Software Project Management

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

Software Project Management