Software Project Management Lecture # 13

Outline Cost Impact of Software Defects Defect Amplification & Removal Sample Driven Reviews Formal Approaches to SQA Statistical Quality Assurance

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 Errors passed to next step Amplified errors 1: x 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 is considered and it has been found that if reviews are conducted, the number latent errors are more and hence the total cost of correcting errors is reduced. This

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.