The decision about the number of quality assurance activities to be applied is affect- Integr

7 The decision about the number of quality assurance activities to be applied is affect- Integr

ed by project and team factors. Project factors include project magnitude, its complexity and difficulty, extent of reusable software components, and the severity of the outcomes if the project fails. Team factors include its professional qualifica-

ating quality

tions as well as acquaintance with the project and related experience, availability of professional support, and staff familiarity with team members.

(3) Explain the different aspects of verification, validation and qualification for quali- ty assurance activities.

activ

Quality assurance activities examine three different aspects of quality by means of software product verification, validation and qualification.

ities

■ Verification examines the consistency of current development activities with the products from previous phases. Doing so enables the examiner to confirm

in the project

whether the developer has fulfilled his requirements while disregarding devia- tions from the original requirements that may have arisen during development.

■ Validation represents the customer’s interests by examining the extent to which the customer’s original requirements have been fulfilled.

■ Qualification focuses on operational aspects, where maintenance is the main issue. Qualification reviews project application of professional standards and

life cycl

coding procedures, based on the assumption that applying these standards facilitates maintenance.

e Quality assurance activity planners are required to determine which of these aspects should be examined in each of the planned quality assurance activities.

(4) Describe the model for SQA defect removal effectiveness and cost.

The model deals with two quantitative aspects of an SQA plan designed for a spe- cific project: (1) Total effectiveness of defect removal. (2) Total cost of defect removal.

The model is based on the following assumptions: ■

The development process is linear and sequential (the waterfall model). ■

A number of “new” defects are introduced in each development phase. ■

Various review and test software assurance activities serve as filters, removing a percentage of the entering defects while allowing the rest to pass to the next software assurance activity. ■

Incoming defects are the sum of defects passed from the former quality assur- ance activity together with “new” defects created in the current development phase.

■ The cost of defect removal is calculated by multiplying the number of defects removed by the relative cost of removing a defect.

■ Defects passed to the customer will be detected by him or her; their full removal at this phase will incur heavy costs.

(5) Explain possible uses for the model.

The model allows calculating estimates of the cost of decisions regarding the qual-

Selected bib

ity assurance plan, e.g.: ■

Addition or elimination of a quality assurance activity from a given plan. ■

Application of current quality assurance procedures activity versus application of a more efficient yet more costly procedure.

Utilization of the model thus enables comparison of SQA policies/strategies and

liogr

activity plans.

aphy Selected bibliography

1. Boehm, B. W. (1981) Software Engineering Economics, Ch. 4 Prentice Hall, Upper Saddle River, NJ. 2. Boehm, B. W. (1988) “A spiral model of software development and enhance- ment”, Computer, 21(5), 61–72. 3. Boehm, B. W. (1998) “Using the Win–Win spiral model: a case study”, Computer, 31(7), 33–44. 4. Boehm, B. and Basili, V. R. (2001) “Software defect reduction – Top 10 list”, Computer, 34(1) 135–137. 5. IEEE (1990) “IEEE Std 610.12-1990 – IEEE Standard Glossary of Software Engineering Terminology”, in IEEE Software Engineering Standards Collection, The Institute of Electrical and Electronics Engineers, New York.

6. IEEE (1996) “IEEE/EIA Std 12207.0-1996 – IEEE/EIA Standard – Industry Implementation of International Standard ISO/IEC 12207:1995”, in IEEE Software Engineering Standards Collection, The Institute of Electrical and Electronics Engineers, New York.

7. IEEE (1997a) “IEEE/EIA Std 12207.1-1997 – IEEE/EIA Guide – Industry Implementation of International Standard ISO/IEC 12207:1995, Software Life Cycle Processes – Life Cycle Data”, in IEEE Software Engineering Standards Collection, The Institute of Electrical and Electronics Engineers, New York.

8. IEEE (1997b) “IEEE/EIA Std 12207.1-1997 – IEEE/EIA Guide – Industry Implementation of International Standard ISO/IEC 12207:1995, Software Life Cycle Processes – Implementation Considerations”, in IEEE Software Engineering Standards Collection, The Institute of Electrical and Electronics Engineers, New York.

9. IEEE (1998) “IEEE Std 1012-1998 – IEEE Standard for Software Verification and Validation”, in IEEE Software Engineering Standards Collection, The Institute of Electrical and Electronics Engineers, New York. 10. Jones, C. (1996) Applied Software Measurement – Assuring Productivity and Quality, 2nd edn, McGraw-Hill, New York. 11. Kendall, K. E. and Kendall, J. E. (1999) Systems Analysis and Design, 4th edn, Prentice Hall, Upper Saddle River, NJ. 12. Perry, W. (1995) Effective Methods for Software Testing, John Wiley & Sons, New York. 13. Pressman, R. S. (2000) Software Engineering – A Practitioner’s Approach. European adaptation by D. Ince, 5th edn, McGraw-Hill International, London. 14. Royce, W. W. (1970) “Managing the development of large software systems: