4 Consider McCall’s model and the Deutsch and Willis model. Softw

3 3.4 Consider McCall’s model and the Deutsch and Willis model. Softw

(1) What are the formal differences between the models? (2) What are the content differences between the models?

are quality

(3) What new subjects were actually added by the Evans and Marciniak model to McCall’s model?

3.5 Southcottage Inc. is a manufacturer of washing machines and dishwashers. The requirements document for the new control unit included the following specifications:

factors

(a) The firmware should be suitable for all six variations of model 2002 washing machines. (b) The water level control module of the washing machine should be suitable for use as a water level control module in the new model 2002 dishwasher.

(1) To which of the factors do the above requirements belong? (2) Explain your answer.

3.6 Some people claim that testability and verifiability are actually different names for the same factor.

(1) Do you agree? (2) If not, could you explain why?

Topics for discussion

3.1 Four “but” complaints are mentioned in Section 3.1. All of them reflect items miss- ing from the requirement documents.

(1) To which factors do the missing requirements belong? (2) Can you suggest software quality requirements that could fill the gap?

3.2 Some professionals claim that increased software usability necessarily involves decreased efficiency. Others claim no dependence between software efficiency and usability.

(1) Do you agree with the first or the second group? (2) Discuss your answer.

3.3 The City of Mountain View has decided to develop a software package that will serve the youth clubs operated by the city. The software’s main tasks will be:

■ Follow-up of monthly payments of the members. ■

Preparing lists of participants in the various courses offered by the clubs. ■

Production of reminder notices to course participants who fail to appear regularly. ■

Statistical reports about membership and participation in club activities. The city already implements the following software packages: ■

Tax collection

■ School follow-up and achievements control

■ Water consumption billing. The City Council has asked the Information Technology Unit to report to the coun-

Topic

cil about the possibilities for reuse of the city software packages already available

to the city in the youth club software package.

for di

(1) Could you suggest which modules of the existing city software packages could

be reused in the new software? List your assumptions about the contents of

sc

the existing software packages and the required new software.

ss ion

(2) Could you grade the reused modules suggested in (1) according to the scope

of adaptation efforts required to apply the reused module in the youth club software package?

3.4 It is said that failure to meet the interoperability requirements can negatively affect the correctness level of the software system, and even can cause non-conformance with correctness requirements.

(1) Elaborate on the above statement and explain the mentioned interconnec- tions between factors. (2) Provide an example of a situation where such effects are to be expected.

3.5 It is claimed that with respect to subjects where qualitative and quantitative requirements can be defined, the quantitative alternatives should be preferred.

(1) Provide three examples each of alternative qualitative and quantitative requirements. (2) Explain why the customer should prefer the quantitative option. (3) Explain why the software developer should prefer the quantitative option.

ch a p t e r 4

The components of the software quality assurance system – overview

Chapter outline

4.1 The SQA system – an SQA architecture

4.2 Pre-project components

4.2.1 Contract review

4.2.2 Development and quality plans

4.3 Software project life cycle components

4.3.2 Expert opinions

4.3.3 Software testing

4.3.4 Software maintenance components

4.3.5 Assurance of the quality of the external participant’s work

4.4 Infrastructure components for error prevention and improvement

4.4.1 Procedures and work instructions

4.4.2 Supporting quality devices

4.4.3 Staff training, instruction and certification

4.4.4 Preventive and corrective actions

4.4.5 Configuration management

4.4.6 Documentation control

4.5 Management SQA components

4.5.1 Project progress control

4.5.2 Software quality metrics

4.5.3 Software quality costs

4.6 SQA standards, system certification, and assessment components

4.6.1 Quality management standards

4.6.2 Project process standards

4.7 Organizing for SQA – the human components

4.7.1 Management’s role in SQA

4.7.2 The SQA unit

4.7.3 SQA trustees, committees and forums

4.8 The considerations guiding construction of an organization’s SQA system

This chapter, the final chapter of the introductory portion of the text, is ded-

57 icated to a schematic overview of the wide range of SQA components

available to planners of an intra-organizational SQA system. As a local sys-

tem, an intra-organizational SQA system bears “local colors”, which are affected by the characteristics of the organization, its development projects,

The

software maintenance activities, and professional staff. The concise descrip-

tion of SQA components is followed by a discussion of the considerations

A sy

guiding construction of an organization’s SQA system. This glimpse will

allow you to obtain some preliminary understanding about the potential contribution of each component, about the entire range of components, and

em – an st

about the system as a defined entity.

4.1 The SQA system – an SQA architecture SQ

A arc

An SQA system always combines a wide range of SQA components, all of which are employed to challenge the multitude of sources of software errors

hitect

and to achieve an acceptable level of software quality. As stated in Chapter

1, the task of SQA is unique in the area of quality assurance due to the spe- cial characteristics of software. In addition, the environment in which

ure

software development and maintenance is undertaken directly influences the SQA components (see Chapter 1).

SQA system components can be classified into six classes:

Pre-project components. To assure that (a) the project commitments have been adequately defined considering the resources required, the schedule and budget; and (b) the development and quality plans have been cor- rectly determined.

Components of project life cycle activities assessment. The project life cycle is composed of two stages: the development life cycle stage and the operation–maintenance stage.

The development life cycle stage components detect design and pro- gramming errors. Its components are divided into the following four sub-classes:

– Reviews – Expert opinions – Software testing.

The SQA components used during the operation–maintenance phase include specialized maintenance components as well as development life cycle components, which are applied mainly for functionality improving maintenance tasks.

An additional sub-class of SQA project life cycle components deals with assuring the quality of project parts performed by subcontractors and other external participants during project development and maintenance.

Components of infrastructure error prevention and improvement. The main objectives of these components, which are applied throughout the

58 entire organization, are to eliminate or at least reduce the rate of errors, based on the organization’s accumulated SQA experience.

C Components of software quality management. This class of components omponents

is geared toward several goals, the major ones being the control of devel- opment and maintenance activities and the introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes.

Components of standardization, certification, and SQA system assess-

f ment. These components implement international professional and sof

managerial standards within the organization. The main objectives of this

tw

class are (a) utilization of international professional knowledge, (b)

are quality

improvement of coordination of the organizational quality systems with other organizations, and (c) assessment of the achievements of quality systems according to a common scale. The various standards may be clas- sified into two main groups: (a) quality management standards, and (b) project process standards.

a ■ Organizing for SQA – the human components. The SQA organizational ss u

base includes managers, testing personnel, the SQA unit and practition-

ranc

ers interested in software quality (SQA trustees, SQA committee members

e sy and SQA forum members). All these actors contribute to software quali-

ty; their main objectives are to initiate and support the implementation of SQA components, detect deviations from SQA procedures and method-

em st

ology, and suggest improvements. The entire range of SQA system components by its classes is presented in

Frame 4.1.