1. Software Project Management
Lecture # 13

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

3. 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.

4. 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

5. 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

6. 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

7. 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 .

8. 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

9. 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

10. 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

11. Formal Approaches to SQA(Contd.)
These approaches include
Statistical software quality assurance
Six sigma for software engg.

12. 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.