Software Quality Assurance

Frontmatter

1. Introduction

Abstract

The word quality is used in everyday speech to describe the degree of excellence of a product or service. Translating that apparently simple concept, into a form in which it can be satisfactorily embodied into a legally enforceable contract between customer and supplier for software, is surprisingly difficult.

Tom Manns, Michael Coleman

2. High-level Process Models

Abstract

If a project is to be said to have been successfully managed it must have been controlled. Project management involves more than simply allowing project personnel to discharge their duties as they see fit. Historically, the lack of visibility of the software as it was being developed is said to have been one of the major problems encountered by managers attempting to control a software development project. In our view visibility and control are positively related and therefore a development process which maximises software visibility is desirable. There will be a price to be paid for this visibility, in terms of the volume of documentation which has to be produced and perhaps in terms of the timing and number of activities which have to be undertaken.

Tom Manns, Michael Coleman

3. Low-level Process Models

Abstract

There are many users of process models. Managers use them when determining the general form of the production process to be used by their organisations. These general forms are then used as guidelines by those responsible for the production of a specific piece of software to produce a production process which will ensure that the software which results from it will meet the quality requirements.

Tom Manns, Michael Coleman

4. Software Project Planning and Control

Abstract

The use of the quality cycle concept requires both the production and tracking of a detailed plan for the production of the software from which schedules and budgets can be prepared. Software has often been delivered late and over budget; clearly, in these cases production has not gone according to plan and therefore there is a quality deficiency.

Tom Manns, Michael Coleman

5. Metrics for the Quality Manager

Abstract

Much published material has become available on software metrics in recent years. This chapter selects from that literature information which is of value to quality engineers.

Tom Manns, Michael Coleman

6. Reviews, Inspections and Walkthroughs

Abstract

To minimise rework costs it is necessary either to prevent defects or find them as soon as possible after they have entered the product. The relative cost of correcting defects increases rapidly as the length of time between occurrence and detection increases. Defect prevention may be the most cost-effective approach, but defect-detection techniques such as reviews, inspections and walkthroughs are probably more widely used than defect-prevention techniques.

Tom Manns, Michael Coleman

7. Software Quality Assurance Plans

Abstract

The user needs the software and has expectations of its quality which will usually be wider than the expectation that it will work. The user cannot take the attitude that if the software does not work it need not be paid for and that therefore there is no loss if it fails the acceptance test. There will be a loss of time and competitive advantage. The user is entitled to ask for an assurance that the software, when finished, will perform according to its specification.

Tom Manns, Michael Coleman

8. Software Configuration Management

Abstract

Software is often said to evolve, meaning that it is continually changing both during its formal development and usually during its in service life. Software configuration management has been defined by Bersoff et al. (1980) as the discipline of identifying the configuration of a system at given times for the purpose of systematically controlling changes to this configuration and maintaining the integrity and traceability of this configuration throughout the system life cycle. It is thus founded upon the successive creation of baselines (as previously described), each of which defines the product as it exists at that moment in time. Any change to an item appearing in a baseline must be controlled.

Tom Manns, Michael Coleman

9. Requirements

Abstract

Many projects have discovered to their cost the undesirable consequences of allowing software development staff to skimp the early stages of the software life cycle in order to start the production of deliverable code as quickly as possible. The cost, in real terms, has been that of increased development time caused by error correction. Errors, like contagious diseases, are harder and more costly to eradicate the longer they are allowed to survive and spread. Greater care over specification and design is the only way of improving matters. Errors cost less to repair if they are picked up early; they cost nothing to repair if they are not made in the first place. Quality control is concerned with the detection and eradication of errors at the earliest possible moment in the software life cycle. As the Electrical Engineering Association publication Establishing a Quality Assurance Function for Software, EEA(1983), puts it:

Quality can only be achieved by building it in from inception; it cannot be added at a later stage.

Tom Manns, Michael Coleman

10. Software Design

Abstract

In the next phase of the life cycle, the ‘what’ of a requirements specification is used to produce the ‘how’ — the implementation details — of a software design. This software system design, or architecture, is crucial to the successful development of a software system. Like a good route map, a good design will ensure that, if followed carefully, the project will progress successfully to its eventual destination. A bad design, however, will make the journey lengthy, frustrating and, conceivably, might even result in the destination not being reached at all.

Tom Manns, Michael Coleman

11. Code

Abstract

There is a commonly-held, but fallacious, view that quality control on program code means the activity of testing. Testing is one aspect of code quality control. Testing is a defect-detection mechanism and it is preferable to avoid introducing defects into the code. In this chapter, therefore, we examine factors which can influence the quality of program code at the outset.

Tom Manns, Michael Coleman

12. Function and System Testing

Abstract

Test planning is an activity which should be started in the very early stages of the project. We suggested in the discussion of the life cycle that planning for the acceptance test should start during the specification stage and that this plan should be reviewed and approved with the specification. This not only helps to ensure that all parties understand what the specification means in terms of the functionality of the product, but also draws attention to the need to design a testing process to show that it does it. The design of this process, its control and its documentation are a major part of the project. This can be thought of as using testing to demonstrate performance and show conformance to the specification.

Tom Manns, Michael Coleman

Backmatter