Participation in SQA forums may be closed or open. Participants of open SQA The

26 Participation in SQA forums may be closed or open. Participants of open SQA The

forums can include SQA unit members, SQA trustees, members of software devel- opment and maintenance teams, customer representatives and software

engineering consultants.

Q Au

n it

Review questions and other actors

26.1 The organizational structure of an SQA unit according to a model presented in Figure 26.1 includes four sub-units that deal with SQA operations.

(1) List the four sub-units. (2) Describe in your own words the tasks performed by each.

26.2 According to a model presented in Figure 26.1, the organizational structure of an SQA

in the

unit includes three sub-units that deal with SQA development and maintenance. (1) List the three sub-units.

S (2) Describe in your own words the tasks performed by each. Q

A sy

26.3 Project life cycle SQA tasks include project life cycle control tasks and participa- tion tasks.

st em

(1) List at least four participation tasks. (2) Indicate the unique contribution of an SQA unit member’s participation for

each of the tasks listed in (1). 26.4 SQA infrastructure operations tasks refer to the seven SQA infrastructure compo-

nents discussed in Part IV of the book. (1) Describe in your own words the SQA infrastructure operations tasks.

(2) Indicate at least one task that relates to each of the infrastructure components. 26.5 The typical SQA unit dedicates a great part of its resources to SQA audits.

(1) Describe the types of SQA audits performed by the SQA unit. (2) Describe the tasks involved in performing each of the audits listed in (1) and

indicate the differences between them. 26.6 It has become customary in recent years for external bodies to perform SQA

audits of a supplier’s SQA system. (1) Describe the types of SQA audits performed by external bodies.

(2) Describe the SQA tasks involved in each of the external audits listed in (1) and indicate the differences between them.

tions. The SQA tasks related to the information system are meant to make the

SQA system more effective and efficient. (1) Describe in your own words the SQA tasks related to the SQA information

Topic

system.

(2) Improvements of the SQA information systems are expected to contribute to

for di

reduction of failure rates and quality costs. If you agree, give two or three examples of such reductions.

sc

(3) Suggest types of information services to be provided by an SQA intranet site

ss ion

and list the advantages for the SQA system of intranet-based systems over

the classic paper-based systems. 26.2 SQA trustees are expected to be SQA agents in their teams/units and provide the

internal support for successful implementation of SQA components. (1) Explain how SQA trustees complement the formal activities performed by

SQA units and unit managers. (2) Evaluate the contributions of SQA trustees to software quality.

26.3 The permanent Software Metrics Committee of Venus Software has identified a significant increase in two failure-related software quality metrics for the new ver- sion 6.1 of its popular “Customer-Venus” software package, used by about 2500 consumer clubs all around the country. The Committee decided to establish an

ad hoc committee to contend with the failures. (1) Suggest a list of tasks for the ad hoc committee.

(2) Suggest who should be invited onto the ad hoc committee and who should head it. (3) List the assumptions on which you based your answers to (1) and (2).

26.4 SQA forum activities are conducted entirely informally. For instance, participants may join and leave the forum whenever they wish and they may undertake or refuse to perform tasks of interest to the forum. Accordingly, some SQA experts tend to consider forums to be worthless.

(1) Do you agree with this opinion? If not, list your arguments. (2) In what ways can an organization promote and encourage SQA forum activities?

Epilogue

The future of SQA

Chapter outline Facing the future: SQA challenges

Growing complexity and size of software packages 571 Growing integration and interface requirements

572 Shorter project schedules

573 Growing intolerance of defective software products

Facing the future: SQA capabilities 574

Extended use of CASE tools 574 Expanded use of professional standards

575 Extended use of automated testing

575 Expanded software reuse

Current SQA systems apply a considerable array of components to achieve an acceptable level of software quality. Yet, despite all the SQA components employed and the vast resources invested in assuring the quality of software developer will declare a product as “free of defects”. This reticence reflects real- ity: it is far from rare for severe defects to be identified in new software products, new versions of software packages or firmware of reputable developers.

If such is the case, what can we expect in the future?

Will future SQA methodologies enjoy the pleasures of “defect free” software?

Or, alternatively, will the rapidly growing demands made of new software packages cause a decline in achievable software quality?

In the following we attempt to anticipate the future of SQA according to cur- rent trends in software engineering and software quality assurance. In other words, we present:

The growing future challenges for SQA, expected in response to changes in software development requirements.

These are balanced by a forecasting regarding the growing capabilities of

Facing the future: SQA challenges

571 The challenges SQA will face in the future can be outlined in terms of already

Fa

cing the fut

observable software engineering trends:

Growing complexity and size of software packages

Growing integration and interface requirements

u re:

Shorter project schedules

Growing intolerance of defective software products.

SQ

Ac Growing complexity and size of software packages

h al

Some of the pivotal trends responsible for the growing complexity and size

le

of software packages include:

ng es

Incorporation of increasingly com- plex algorithms. The algorithms are based on a larger number of inputs and make use of more com- plicated calculations.

Expansion in the number of output categories, based on multi- plying sources of inputs, targeted to more and larger groups of users. For instance, sales and inventory systems, traditionally internal systems, nowadays also

Growing complexity

SQA

serve customers, who use the sys-

capabilities

tems to record orders and check Software

requirements

shipment schedules.

Demands for greater accuracy, more complete information and shorter reaction times.

Examples (a) Military radar-driven systems. Although the algorithms are more com-

plex, reaction times for military radar-driven systems are required to be much shorter than previously in order to respond to the higher speed and maneuverability of aircraft and missiles.

(b) Municipal tax collection information systems. Systems that were once allowed to produce notifications of unpaid property tax within not later than 30 days after payment due date with errors not exceeding 0.5% are now required to process the same notifications within 7 days but with errors not exceeding 0.1%.

572 Growing integration and interface requirements The fut

New software systems are clearly characterized by growing integration and interface requirements:

u re of ■ Internal intra-organizational inte-

gration. Representative examples

S are ERP (Enterprise Resources Q

Planning) software packages that

A combine the functions of several intra-organizational software sys-

tems such as production planning and control, sales, inventory management and financial sys- tems in one program. Other examples are CRM (Customer

Integration

Relations Management) systems and interfacing

requirements

SQA

that deal with all customer- capabilities related systems: purchase complexity

Growing

records, payments, complaints, Software

requirements

services provided, consumer socio-economic characteristics, etc. The same trend is observed in firmware and embedded software applications.

Internal interface capabilities among the same developer’s software prod- ucts. For example, software packages for management of consumer clubs are increasingly required to interface with CRM and accounting software packages.

External interfaces, namely software–software, software–firmware and firmware–firmware interfaces. Different developers supply the respective interfacing software and firmware packages. It is imperative for software packages to fully interface with leading software packages or firmware embedded in equipment manufactured by principal manufacturers.

Examples (a) A new wage-management software system must interface with a list of

leading attendance and human resources software packages. (b) Patient monitoring software systems need to interface with many patient

vital-sign monitoring devices, that is, devices attached to the patient that record heartbeat, blood pressure, etc. Requirements of this type are in many cases set by marketing experts.