Kenneth B. Wood

Putting Design into an Engineering Context

Verification and validation are often confused and it is worthwhile discussing them again in the context of Fig. 1.2 of Chapter 1. There are two ways of looking at the definition of verification and validation. The more formal definitions are:

Quality—Can it be Measured?

This chapter looks at some of the aspects of software quality which will receive increasing attention in the near future,

The Traditional Approach to Software Quality

There is nothing particularly new in the idea of software quality. It has evolved from inspection methods and procedures into systems of control and is characterised by the requirement for conformance to formal procedures. It is, however, rooted in the manufacturing activities which have dominated hardware production for several decades. Hardware quality is achieved by bringing together conforming parts and materials by means of proven processes.

Languages and Their Importance

The process of translating a design into some particular programming language is more often than not regarded as ‘programming’. Traditionally it has certainly been the case that the development of software-based systems has tended to emphasise the coding phase at the expense of the rest of the life-cycle. The reason for this is understandable. The programmer likes communicating with the computer and his means of doing this is via some mutually understood language. Strictly speaking, of course, this is not true since the original source text, generated by a programmer, has to go through various stages of translation before the computer can ‘understand’ what it is being asked to do. Even for interpretative languages this is the case. However, it still remains that the programming language is seen as the creative medium through which the programmer expresses his interpretation of some design, be it expressed in plain English or some formal methodology as discussed in Chapter 6.

A Structured Approach to Static and Dynamic Testing

The main limitation to software testing is the inability to foresee all the combinations of external conditions and logic states in the program. If we could know the answers before writing the test procedures then the problem would not exist. No test can ever prove a practical piece of software to be error-free. In fact, the largest program to be so proved was 1600 lines and the activity involved a three-year Ph.D. Timing-related faults prove the most difficult to reveal. Alas, this is the real world and therefore the problem of test planning must be addressed as thoroughly as possible.

The Effect of the Software Life-cycle on Quality

The idea of a life-cycle is a convenient model which serves two purposes. Firstly, it allows one to represent the process of conception and production in a graphical and logical form and, secondly, it provides a framework around which quality assurance activities can be built in a purposeful and disciplined manner.

The Role of the Software Engineer

The development of the computer industry over the last 30 years has been both rapid and characterised by change. In the Preface the major changes were summarised and this book has dealt with the effects of the new techniques involved. One factor that has remained almost constant, however, is the industry’s reliance on the computer programmer. This reliance stems from the fact that computers are of no use without programs, or sequences of instructions, to execute. Thus, the programmer has found himself at the centre of the stage and, more often than not, is criticised for the frequent delays encountered during software development. A question worth raising is ‘Is the programmer to blame?’

An Engineering Approach to Defining Requirements

Anyone with mathematical aptitude and a little training can write a computer program. The proliferation of computing in both home and school is sufficient illustration of that fact. However, a program which meets the requirements of easy use and maintenance demands quite separate skills from those required for mere coding.

Software Failures—Causes and Hazards

A programmable system is any equipment or device which, having a computer architecture (i.e. arithmetic and logic capability plus a memory), relies on a set of sequential programmed instructions in order to function. This is known as a von neumann architecture. The set of logical commands is referred to as software and usually consists of binary numbers stored within the system. The term software also embraces the design documents which are needed in order to produce this code or program.

Software Project Management

A number of management aspects need to be considered, such as estimating methods, audit procedures, recent national quality programmes and so on. This chapter provides an overview of these areas and their relevance.