Enough has been said about the life cycle earlier for us to spot a distinct resemblance between the first stage of problem definition and our requirements analysis phase. In fact many organizations use the term ‘problem’ or ‘project definition’ rather than ‘requirements analysis’. The final two stages may similarly be identified as being equivalent to the phase that we refer to as ‘design’.
A more recent, but very relevant structure has been supplied in the context of decision-making (Simon, 1960). Professor Simon labels the stages of decision-making as follows: Intelligence activity, Design activity and Choice activity.
The term ‘Intelligence’ is used here in the military sense, i.e., searching the environment for conditions requiring a decision to be made. ‘Design’ is concerned with inventing and developing possible courses of action. The activity of selecting a particular course of action from those available is known as ‘chose’. In this case our requirements analysis corresponds to the intelligence activity. Although the software designer does not need to search too hard for circumstances requiring a decision to be made, they will normally be found lying on his or her desk labeled ‘Specification of requirement’.
However Simon’s use of the term ‘Design’ differs from ours. Whereas Simon uses the word to describe the generation of possible solution, we use it in the sense that selection is included also.
There seems to be some justification for believing that problem-solving, decision-making and software analysis and design share a common framework. And it is not stretching the point too far to claim that the first two are, in effect, exactly the same thing while the last is just a particular instance of this phenomenon. Consequently, we shall persist in regarding software design as a problem-solving activity and treating it as such. This means that we must devote some attention to the questions of generating possible solutions (i.e., designs), and the selection of one from this number.
1.2 SIZE OF SELECTION
Let us start with a very simple design problem. As one of the parents of a nuclear family you decide take your spouse and your two and a half children to Scarborough for the day. Your design problem is to establish the best way of making the journey. You establish the alternatives as being: British Rail, National Bus or private car.
In order to make your choice you need something else. You cannot possibly decide which is the best unless there is some property possessed by the three alternatives which is important to you and which you wish to see maximized or minimized. Hence, if you wish to minimize the cost of the outing, say, the decision is soon made, given some understanding of the fare structures of British Rail and National, and a realistic appraisal of the fuel consumption of your car. Such a property, in this case the direct cost of the journey, is known as the design criterion or design objective. Similarly, you might take journey time as the design criterion and once again the study of timetables and knowledge of your car’s capabilities would enable a ready choice to be made. In passing, we should note that if both costs and journey time are important then the choice might be more difficult. But the latter point is for future development. For the moment we must concentrate on size of selection.
1.2.1 Combinatorial explosion
In the foregoing example the design problem was trivial, for the selection had to be made from three alternatives, each one of which was easily evaluated. But now recall that sometime in the past we asked you to determine the number of possible designs that exited of you were faced with the problem of adding three
<< 上一页 [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] 下一页