Cost of Software Quality Over the Life Cycle


As we've discussed, various software activities can be broadly classifieds as follows:

  • Productive activities

  • Preventive activities

  • Appraisal activities

  • Corrective activities: debugging internal upstream and downstream failures and external failures

Only productive activities create value for the customers. The rest constitute the costs of quality that should be minimized. These costs are interrelated in that the better the job done upstream, the lower the downstream and, consequently, overall costs. In a typical software project, as much as 80 to 90% of the time and costs are incurred downstream. Figure 4.3 shows a situation in which conformance-related activities have not been carried out well and consequently result in unacceptably high internal and external failures. But the whole picture changes if preventive and appraisal activities are performed well so that just a few minor internal failures and virtually no external ones exist (see Figure 4.4).

Figure 4.3. CoSQ Over the Life Cycle of a Traditional Software Development Process


Figure 4.4. CoSQ Over the Life Cycle of a DFTS Development Process


This approach requires more time, cost, and attention upstream to reduce overall cost and cycle time while meeting customer requirements throughout the software life cycle. Taguchi recommends that about 80% of product development time and cost should be dedicated to the upstream stages of product developmentnamely, advanced engineering and design. This is compared to the 20% that is usually the case. This line of thinking requires greater time and cost expended upstream, resulting in dramatically lower downstream and overall life-cycle costs. Obviously, this requires totally new thinking and novel approaches:

  • From thinking based on the cost of the initial release to a mind-set of life-cycle cost

  • From an orientation toward testing and inspection to focusing on customer requirements and design

  • From an approach based on corrective actions to a strategy of prevention

This is the essence of DFTS deployment. Chapter 5 discusses the need for management support and infrastructure in a DFTS process. Chapters 15 through 19 discuss deploying DFTS methodology for requirements and cost optimization.

Case Study 4.1: CoSQ at Intents Software

Intents Software is an enterprise software vendor. It is proposing to establish a CoSQ system as part of the proposed DFTS initiative. Top management is contemplating deploying DFTS to a selected software development project and eventually expanding it organization-wide.

The discussion is still in the preliminary stages. The current practice involves 18 months of development time and uses the typical build-and-repair development model, with little effort and money spent to prevent and appraise errors. Management has set up a CoSQ team with the task of recommending a framework for establishing it. As the first step, the team is expected to come up with a memo supported by appropriate data, facts, and assumptions on the financial and nonfinancial benefits of CoSQ and DFTS initiatives. The team has collected data on sales and development costs. They have placed costs of quality-related activities into five categories: prevention, appraisal, upstream internal failure, downstream internal failure, and external failure. This data has been compiled for the current software development practice and has been estimated for the proposed DFTS initiative, as shown in Table 4.4.

Table 4.4. Sales Revenues and Development, Marketing, and Quality Costs
 

Current Development Practice (in Dollars)

With Proposed DFTS Initiative (in Dollars)

Cost

Year 1

Year 2

Year 3

Year 4

Year 5

Year 1

Year 2

Year 3

Year 4

Year 5

Development cost

1M

500k

0

0

0

1M

500k

0

0

0

Marketing cost

50k

100k

250k

400k

200k

50k

100k

250k

400k

200k

Prevention cost

20k

10k

0

0

0

150k

60k

0

0

0

Appraisal cost

20k

10k

0

0

0

80k

40k

0

0

0

Upstream internal failure cost

80k

40k

0

0

0

20k

10k

0

0

0

Downstream internal failure cost

0

60k

0

0

0

0

20k

0

0

0

External failure cost

0

0

120k

80k

30k

0

0

30k

20k

10k

Total quality costs

120k

120k

120k

80k

30k

250k

130k

30k

20k

10k

Sales revenue

0

2M

5M

8M

4M

0

2M

5M

10M

5M


Based on the available data and estimates, the CoSQ team has analyzed the financial implications of the proposed quality initiative. What should be the highlights of such an analysis?

Case Analysis

The preceding case is a common decision situation involving the introduction of quality initiatives. We will analyze the case using the Discounted Cash Flow method.

step 1.

Tabulate Period Cash Flows

You compile the quality costs and total costs by adding the various costs shown in Table 4.4. The period cash flow is simply the difference between sales revenue and total costs for each year. These are compiled for both the current practice and the proposed practice, as shown in Table 4.5.



Table 4.5. Sales Revenues and Development, Marketing, and Quality Costs
 

Current Development Practice (in Dollars)

With Proposed DFTS Initiative (in Dollars)

Cost

Year 1

Year 2

Year 3

Year 4

Year 5

Year 1

Year 2

Year 3

Year 4

Year 5

Development cost

1M

500k

0

0

0

1M

500k

0

0

0

Marketing cost

50k

100k

250k

400k

200k

50k

100k

250k

400k

200k

Total quality costs

120k

120k

120k

80k

30k

250k

130k

30k

20k

10k

Total costs

1.17M

0.72M

0.37M

0.48M

0.23M

1.57M

0.73M

0.28M

0.42M

0.21M

Sales revenue

0

2M

5M

8M

4M

0

2M

5M

10M

5M

Period cash flow

-1.17M

1.28M

4.63M

7.52M

3.77M

-1.57M

1.27M

4.72M

9.5 8M

4.79M

NPV cash flow r = 0.12

11.44M

    

13.23M

    


Step 2.

Compute the NPV Cash Flow

You compute the NPVs of cash flows of the current practice and the proposed initiativeNPVCP and NPVPI, respectivelyby discounting the period cash flows by 12% per year:


Step 3.

Compute the Quality Cost Differential

The discounted differential between the quality costs in the proposed initiative and the existing system provides the difference in investments in quality costs, IQCD. It is computed as follows:


Step 4.

Compare the NPV Cash Flows and Compute the ROQI

The NPV cash flows of the current practice and the proposed initiative have been computed and are as follows:

NPVCP = $11.44 million

NPVPI = $13.23 million

Difference in NPVs = $ 1.79 million

Based on the preceding analysis, because the NPV cash flow of the proposed quality initiative is higher than that of the existing system, the proposal seems financially attractive.

ROQI, based on cash flow, is computed as follows:


Step 5.

Benefits of CoSQ

CoSQ helps you see the costs incurred at various stages of the development process. It is usually followed by cause-and-effect analysis to identify root causes of poor quality and taking remedial measures to remove them. It also lets you measure the costs of the current system and compare them to the cost of quality of the proposed initiative or benchmark costs. Finally, CoSQ provides data for the quality initiative, budgeting trade-offs at various stages of the software development cycle. Thus, no quality initiative can be financially assessed without the CoSQ measurement system, as the preceding analysis illustrates.

Step 6.

Statement on Assumptions and Qualitative Factors

Although NPV and ROQI of cash flows both support the proposed initiative, they are based on cash flow estimates of the proposed initiative. The estimates should be conservative, which is what was done in the preceding case. Numerous cost factors are difficult to estimate, especially those involving the long-term impact of poor quality on the enterprise's market share and competitiveness. Therefore, it is critical that quality efforts be focused upstream.

It has been assumed that improved quality as a result of a DFTS initiative will result in improved sales. In the present analysis, the marketing costs are assumed to be the same in the two cases, but a more aggressive approach to emphasize improved quality can be undertaken. This may help improve sales figures further.

Any decision should also take into account the expected qualitative improvements in software from customer perspectives. Trustworthy software can be delivered only by deploying preventive and upstream quality initiatives such as DFTS.





Design for Trustworthy Software. Tools, Techniques, and Methodology of Developing Robust Software
Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software
ISBN: 0131872508
EAN: 2147483647
Year: 2006
Pages: 394

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net