A SYSTEM DEVELOPMENT METHOD

BY :
M. A. Jackson
Michael Jackson Systems Limited
101 Hamilton Terrace, London NW8 9QX, England

Introduction

The nature of method

A development method may be regarded as a path or a procedure by which the developer proceeds
from a problem of a certain class to a solution of a certain class. In trivial cases, the method may be fully
algorithmic; for example, there is an algorithmic procedure for obtaining the square root of a nonnegative
number to any desired degree of accuracy. In more interesting cases, such as the development
of computer-based systems for purposes such as data processing or process control, we do not expect to
find an algorithmic method: the goal of the development is not precisely defined, and neither the
problem nor the set of possible solutions is sufficiently well understood. But a method, to be worthy of
the name, must at least decompose the development task into a number of reasonably well-defined steps
which the developer can take with some confidence that they are leading to a satisfactory solution.
The steps-of a method impose some ordering on the decisions to be taken during development . Here
we are using the term "decision" in a wide sense: it may denote a decision to state explicitly some a priori
truth about the subject matter of the system, or a decision to define a certain abstract data type, or a
decision to store certain variables on disk, or a decision to decompose some system function into three
parts, or any of a wide range of possible actions whose result contributes to the final solution. Some
decisions will be easy to take, especially where they involve little more than the recording of already
known facts: for example, the decision that a multiple of a prime number cannot itself be a prime
number. Some will be hard to take, perhaps because they require great foresight on the part of the
developer. Some will be highly error prone, and some will be taken in confidence of their correctness.
Some will have very limited consequences for the work that follows, some will have wide consequences.
From this viewpoint, we can discern some inchoate principles of methodology (a much misused word,
denoting the study or science of method). Decisions about the subject matter of the computation should
be taken before decisions about the computation itself. Decisions about implementation should be taken
after decisions about what is to be implemented. Decisions which are error-prone should be taken as late
as possible, when the developer is most likely to make them correctly. Decisions which have wide
consequences should not be highly error-prone. The more error-prone a decision, the more important
that the method should provide an early confirmation or disproof of its correctness.
These principles suggest strongly that those methods which can broadly be described as "top-down
functional decomposition" are to be avoided. In such a method, the developer begins by deciding the
structure of the highest level of the system, viewed as a hierarchy. This decision has the widest possible
consequences, because it conditions everything that follows. It is highly error-prone, because it concerns
the system itself, which, by definition, is as yet unknown. It is placed at the very start of the development
procedure, but it may be invalidated at the end. We may suspect that developers who purport to be
using such methods for development. are, in fact, using them only for description; the development
work has already been largely done, informally and invisibly, in the developer's head.