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.