The last element of a design methodology to which we will relate the problems of software management is that of defining an overall standard process. The existence of a standard set of steps through which any given software design proceeds to implementation is something which exists in an installation whether or not it has been formally observed and described. Many sets of standard steps may exist, one set for each programmer in the installation. The program manager must determine for each design process what requirements for interfacing exist within his group and with other groups in the installation. If a formalized description of the general process does not exist, then the programming manager is required to re-establish it with each job assignment he makes. «
The specific sequencing principles ‘top-down’ and ‘bottom-up’ were introduced as follows.
Randell: (from Towards a methodology of computer systems design)
»There is probably no single ‘correct’ order in which to take a series of design decisions, though some orderings can usually be agreed to be better than others. Almost invariably some early decisions, thought at the time to have been clearly correct, will turn out to have been premature.
There are two distinct approaches to the problem of deciding in what order to make design decisions. The ‘top-down’ approach involves starting at the outside limits of the proposed system, and gradually working down, at each stage attempting to define what a given component should do, before getting involved in decisions as to how the component should provide this function. Conversely the ‘bottom-up’ approach proceeds by a gradually increasing complexity of combinations of buildingblocks. The top-down approach is for the designer who has faith in his ability to estimate the feasibility of constructing a component to match a set of specifications. The opposite approach is for the designer who prefers to estimate the utility of the component that he has decided he can construct.
Clearly the blind application of just one of these approaches would be quite foolish. This is shown all too frequently in the case of designers who perhaps without realizing it are using an extreme ‘bottom-up’ approach, and are surprised when their collection of individually optimized components result in a far from optimum system. The ‘top-down’ philosophy can be viewed mainly as an attempt to redress the balance. In fact a designer claiming to follow the top-down approach, and specifying what a particular-component is to do before he designs the component, can hardly avoid using his previous experience and intuition as to what is feasible.«
In the following passage the ‘top-down’ approach seems to be taken for granted.
Kolence: (from On the interaction between software design techniques and software management problems)
»However, perhaps a more important notational need is for one which permits an initial description of the internal design of software to be broken apart into successively more detailed levels of design, ultimately ending up with the level of code to be used. Current flowcharting practices do not exhibit this property, and so each time a portion of the design is detailed, it no longer fits naturally into the initial design description. In particular, it may be that the entire flow sequence of an area of the design is radically altered when it is re-expressed in more detailed terms.«
The ‘top-down’ and ‘bottom-up’ approaches were discussed in a working paper by Gill, reproduced as a whole in section 9. Two remarks are particularly pertinent.
Gill: (from Thoughts on the Sequence of Writing Software)
»The obvious danger in either approach is that certain features will be propagated through the layers and will finally cause trouble by proving undesirable and difficult to remove, when they should have been eliminated in the middle layers. … In practice neither approach is ever adopted completely; design proceeds from top and bottom, to meet somewhere in between, though the height of the meeting point varies with circumstances.«
The whole question caused considerable discussion.
Barton: I think at this point in the field we are almost forced to start in the middle, if we are concerned with the problem of general software construction and the organization of the machines to go with these programs. To give an example of how to determine where the middle is: we have seen an enormous variety of programming