intuition. But it should be noted that selection can be formalized to take all the factors mentioned above into account, by developing what is known as a multi-attribute utility function. However, these are deep waters and we had better turn back before we all sink.
1.3.1 Pressures and criteria
So far, we have not considered why the family decision-maker in the previous section lighted upon direct costs and journey time as the exclusive design criteria. If we think about this carefully we realize that this is due to pressures being brought to bear on the decision-maker. We do not exclude such pressures being self-generated but it is simpler to regard them as arising from outside. We are then able to represent the situation neatly and graphically by a sketch as in Fig. 1.4.
We see now the origins of the design criteria. The thrifty spouse is insisting on low costs; impatient children are demanding a short journey time. No doubt Aunt Gloria (who likes nothing better than dozing in National Park car parks and is filthy rich the bargain), if she existed, would also be exerting a pressure that would be well-nigh irresistible. So that the decision will be taken in an attempt to resolve these pressures to the satisfaction of all. Or at least, so that not too much dissatisfaction is experienced by anybody. We can note also that the trading off process will be conditioned by the relative weights that the decision-maker places on the competing pressures.
The idea of associating weights with pressures is fundamental to the activities of the software designer, to whom we must now return.
1.3.2 Pressures and software design
When studying earlier material concerning the software life cycle you were asked to complete an exercise (Exercise 2.2) asking for your views on the attributes or properties to be taken into account when comparing software designs. In the solution to the exercise it was suggested that they were many and various but that a list of the most important ones would include:
Economy, Reliability, maintainability, Robustness, Integrity, Security
The definitions for the first three are reasonably obvious. But what do you understand by robustness, integrity and security? You will recall from the exercise solution that by robustness we mean the capability of a system to handle variations in volumes of transactions. Integrity and security are more difficult to define with any authority as very often they are used interchangeably. The authors’ preference is to use the term ‘integrity’ to describe resistance to accidental corruption or destruction of programs and data. Whereas ‘security’ applies to a system’s resistance to deliberate damage.
The point that we are coming to is that we are now examining another pressure situation, one that is illustrated in Fig.1.5.
The pressures are shown as originating with the user as a single entity. In practice, of course, different individuals and departments within the user organization will have different vested interests in the software performance and the pressures that they exert will differ accordingly. But the designer is in exactly the same position as the harassed parent in the previous section, needing to resolve
<< 上一页 [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] 下一页