The aims of System Acceptance

The system resulting from the Production Phase must now be tested against the Functional Specification to your client's satisfaction. There are two principal reasons for giving the System Acceptance process a phase of its own:

• firstly, to emphasise the importance of careful preparation for it and proper orientation of the preceding phases towards it;

• secondly, because possibly for the first time since System Definition and the production of the Functional Specification, your client will once more play a major role.

Formal acceptance of the system by your client – in other words, a signature – is as important as his formal acceptance of the Functional Specification. It records his agreement that you have carried out your commitment to build his system.

It is likely that, if you have a commercial contract with your client, payment of some portion of the contract price will be dependent on the system's successfully passing an agreed Acceptance Test.

Throughout the preceding phases we have emphasised the need to prepare for Acceptance well ahead of the date of handover. The earlier the Acceptance Test is defined, for instance, the earlier the system can be checked out against it by its implementers. Above all, however, acceptance will not always be simply a matter of running some tests on the system and walking away. You may well be involved in a major handover operation requiring the conversion of the user's organisation and operational procedures, cutover from an existing system, conversion of existing databases to new formats, periods of parallel running, training of staff and so on.

The cost of software development is now the dominating cost in computer systems. As hardware costs decline, improved efficiency of software production becomes the key target if further reductions in computing costs are to be achieved. Accordingly the Alvey Committee identified software engineering as one of the four underlying technologies for the UK national programme of cooperative research in information technology.

Coming as it does at the start of the Alvey programme, I welcome this book by Martyn Ould and Nick Birrell, for it presents a picture of software engineering techniques that are already in existence and can therefore be exploited now. If the techniques set out in the book are widely applied we can look forward to a very significant improvement in the efficiency of software production.

The purpose of the Inception Phase

The Inception Phase is that part of the development lifecycle in which you will decide to embark on the development project. This is the time in which you will make a large number of crucial decisions regarding the need for and nature of the proposed system. The questions that must be asked in this phase will depend on particular circumstances, but may include the following:

• Why is the system needed?

• Are there better alternatives?

• Will the system be acceptable to its users?

• At what price will the system be marketed?

• Is there a market for the system?

• What are the legal implications of the system?

• What are the Trade Union implications of the system?

• What is the intended lifetime of the system?

• How reliable should the system be?

• Can management approval be obtained for system development?

• Will sufficient resources be available for system development?

• Will sufficient resources be available to run the system?

• Will the system be developed ‘in-house’ or will its development be put out to tender?

• How will tenderers' responses be assessed?

Although this phase is not directly involved with software development, it is vitally important that you ask the correct questions and obtain the correct answers to lead to a firm system requirement. These answers will affect all subsequent phases and ultimately the usefulness of the entire project.

The purpose of Project Debriefing

Now that the development project is over and your system is installed it is time to make sure that future projects will benefit from what you have achieved and learnt. This is the purpose of Project Debriefing; to record your experiences in carrying out the project in a way that will be of benefit to other projects and which will add to your organisation's collective database of project statistics.

The way in which the results of Project Debriefing can most help your organisation is in planning future projects. Such planning may be at the start of a new project or as part of a tendering activity. In either case the collected experiences of previous projects are of inestimable value in producing accurate project plans. For this reason, Project Debriefing should be strongly related to the topics of estimation and indicators discussed in chapter 2.

If you have been recording indicators throughout the project it will require little effort to organise, summarise and record these indicators as part of Project Debriefing. Of special importance will be indicators related to attributes used in arriving at the project plan (those of type (ii) on page 19). These indicator values can be used in updating the calibration of your cost estimation model or in pin-pointing weaknesses in the model. Weaknesses in the model or its use may show up in the form of input parameters to the model whose estimated values consistently bear no resemblance to their final values.

The aims of the System Definition Phase

Once the decision has been made to proceed, this is the most important phase of development. Decisions made here influence the rest of the project. Time spent here is rarely less than well-spent, if properly directed. On the other side of the coin, this is one of the most difficult stages as regards knowing where you start, knowing when you have finished and knowing how to go about it.

The purpose is clear however, namely to decide the following:

• What is to be produced,

• When it is to be produced by,

• What resources will be required to produce it.

These latter two may already have been determined for you. If so, you must regard them as constraints that limit what can be produced. In other words you will need to decide additionally that the system can actually be produced in the time with the resources.

Every project manager at this stage of his project needs to be reminded that there is a strong empirical correlation between failure to define a system adequately and failure to produce it. The temptation to short-circuit the Definition Phase is all the easier to succumb to, given the momentary feeling of an increased rate of progress.

The starting point of System Definition

It is most likely that you will start with some form of Requirement Specification.

The purpose of the System Design Phase

Introduction

Although your main concern in the System Definition Phase will have been to decide what functions the system is to perform, you will also have given some thought as to how it is to perform them. During the System Design Phase you continue this process by deciding upon and documenting the overall strategy by which the system will perform the required functions. This involves mapping the system functions onto elements of software (and hardware) which can in the next phase be designed in detail and implemented.

The means by which this mapping is carried out can vary enormously, as can the designs resulting from different design approaches. The principal aim of the System Design Phase should, however, be the same no matter what design method is used; namely, to produce a system design which

• is easily implemented,

and which, when implemented,

• will provide all required functions,

• will operate within any required constraints,

• will be easily maintained.

Let us consider the implications of each of these goals for any potential system design methodology.

Ease of implementation

The process by which the system design will be implemented involves the following basic ingredients:

• the system design (in the form of design documents),

• the implementers (i.e. programmers etc.),

• the virtual machine (i.e. the hardware and supporting systems software).

With the accelerating pace of work being done in the field of software engineering, it is becoming increasingly difficult to see the range of available techniques against a common background. Individual techniques are accessible throughout the literature but generally each is described in isolation. Comparison is difficult unless one has a strong idea of what one is looking for.

Our purpose in writing this book has therefore been to bring together, within a single framework, a variety of methods from all stages of software development and, in this way, to assist software engineers in particular in finding and evaluating the techniques appropriate to their own working environments. This should be regarded principally therefore as a book of signposts, leading the reader out into the field with a map, a compass and some reference points. By combining pointers to a selection of modern development practices with practical hints and checklists, all within one framework, we hope to fill the need for a vade-mecum to the software developer.

Managers with responsibility for software production will also, we hope, find much to stimulate their ideas about what modern practices have to offer and how their departments' efficiency and effectiveness could benefit. Students of computing science will be able to complement their more theoretical work by seeing the software development process as a day-to-day activity, a process that has managerial and sociological as much as purely technical aspects.

The transformation of your client's ideas about his proposed system into the physical, delivered system is a long one. If this transformation is to be at all manageable, it needs to be tackled as a sequence of stages, each bringing you closer to your destination.

The simplest model of the software development process is a purely sequential one with each succeeding stage following on in serial fashion from the previous one. Such a model could serve for a small one-man project but a better approximation to reality is contained in the so-called ‘cascade’ or ‘waterfall’ model suggested in figure 2.1. This recognises that it is generally necessary – even desirable – for the stages to overlap and even repeat.

It is normally customary at this point to talk of the software development ‘lifecycle’ and to draw a diagram along the lines of figure 2.2. This custom is based on the premise that the original development of a system from scratch has the same underlying sequence of events as the enhancement or correction of a system: inception, definition, design, implementation and acceptance. Superficially this is true but the similarity is slight and the generalisation at times unhelpful.

In this book we prefer to talk about the ‘development path’ and ‘maintenance cycles’ and to draw the ‘b-diagram’ along the lines of figure 2.3. This reflects reality more closely. The development path, starting from nothing more than a desire for a system, stands alone.

Given the task of developing a software system, how does one go about it? To start the building of a system of a thousand or maybe a million delivered lines of source code is a daunting (if exciting) prospect. No one should begin without a very clear idea about how the development is to be undertaken and how the quality of its output is to be assessed.

Turning this around we can say that anyone undertaking software development, on no matter what scale, must be strongly advised to establish a methodology for that development – one or more techniques that, by careful integration and control, will bring order and direction to the production process.

To paraphrase Freeman 1982: every software development organisation already has some methodology for building software systems. However, while some software is developed according to modern practices of software development, most of it is still built in an ad hoc way. So it is best to talk about software development techniques and methodologies in terms of changing current practices, replacing them with new techniques that improve the process of software development and the quality of the resulting products.

There is of course a dilemma here for us as system developers: technique X may offer us potential gains such as reduced development time, reduced costs, increased reliability, quality etc, but in adopting it we also incur the risks arising from the fact that we may be unfamiliar with technique X, it might not be suitable for the system we have to develop, and it might not suit our staff and their skills.

In Chapter 2 we considered a very simple data structure, the linked-linear list; and in Chapter 3 we moved on to binary trees. In this chapter we look at two much more general structures.

Firstly we shall consider trees in which nodes may have more than two branches, and in which the number of branches may vary from node to node. For want of a better name we shall call them n-ary trees.

Secondly we shall consider even more general structures which arise when more than one branch leads into a node. These structures are called directed graphs. Clearly they are more general than n-ary trees, which, therefore, may be regarded as a special case.

B-trees

We consider first the n-ary tree, and, in this section, its use in searching applications. Such trees are usually called B-trees, a convention we shall follow.

When we discussed binary trees in Chapter 2 we noted that searching, insertion and deletion were all O(log n), provided that the tree remained balanced. Although we did not discuss the topic of balance in much detail there, we referred the reader to a number of relevant techniques. B-trees arise in this connection too, though here we shall approach them from a different point of view.

Let us imagine first of all that we have a sequence of variable-length items in the store with an item with an infinite key placed at the end.

Recursion is the Cinderella of programming techniques where languages such as Pascal are concerned. All primers mention it, of course, but generally devote only a few pages to it. Rohl and Barrett's Programming via Pascal is one of the more generous: it contains one chapter of 12 pages on the subject!

Books appropriate to second courses in programming, such as those by Wirth (1976), Alagic & Arbib (1978), and the more modern data structures texts, have helped considerably; but currently there is no book devoted to the use of recursion in Pascal or similar languages.

And yet this used not to be the case: Barron's delightful little book Recursive Techniques in Programming was published in 1968! Sadly it is now out of print, and in any event was beginning to show its age. Recursion via Pascal is the author's attempt to fill this gap.

Of course, in functional programming, recursion has received its full due, since it is quite often the only repetitive construct, and this area is fairly well served with text-books. In Recursion via Pascal, most of the examples are procedures rather than functions, partly because that is the usual Pascal style and partly because we want to give examples which actually do something, like drawing the cover motif of this series, instead of merely having a value. Reading one of the functional texts after finishing this book would provide an alternative perspective.