systems

Using Design by Objectives techniques to produce systems which are easy to maintain

Maintaining software systems by TOM GILB

0 ne of the biggest current prob- lem areas facing data proces- sing management is the mainte-

nance of current systems. It is my be- lief that maintainability is not some- thing that we should continue to treat as informally as we do today. We need to set higher ambition levels and to design our total systems to meet those ambition levels. In my article ‘Look- ing at problems through technoscopes’ @ata Processing, April 1983) I intro- duced a formal approach to describing the attributes of any system of interest to management. In this article I will show the application of some of the ‘technoscopes’ to the specification and design analysis of a system with good maintenance characteristics. The ‘technoscopes’ tools will be viewed from the point of view of a system designer, and in that light I call them ‘Design by Objectives’ (DBO).

- Abstract: Maintenance qfcurrenr systems is one of the biggest problems facingD1’ management. The paper descn‘bes a technique: design by objectives, ~}lich can be used by systems designers to develop a system z&h good maintenance characteristics.

I(eywords: data processing, management techniques, systems anahsis.

Tom Gilb is a management consultant

Design by objectives is a methodolo- gy for specifying the architecture of an information system. The information systems architect, or ‘infotect’, ex- plores the functions and attributes of the desired information system, and selects from the materials of software engineering and management to com- pose a system and a plan for building it. Design by objectives is a toolkit for the infotect.

The components of design by objec- tives are taken from the experience and research of many groups. They were assembled by this writer during con- suiting work, to help clients specify information systems in ways that can be measured and controlled.

This paper will describe some of the techniques of design by objectives, and illustrate them with an example. The content of the example is the objective of ~ai~tai~abi~ity. This attri- bute was chosen as a sample of the kind of elusive objective which is often the downfall of other methodologies. In this paper we shall show how design by objectives can make maintainability a measurable and attainable objective.

The three basic steps of design by objectives are:

l Specify objectives in terms of finc- lions and utt~b~tes (the characteris- tics such as cost constraints, ease of

use, maintainability, etc., with which the functions are to be car- ried out). Search for and specify techniques that satisfy the attributes. Make tradeoff between attributes. Plan a schedule of e~o~~~~un~~ deliv- ery which integrates planning, de- tailed design, user experience, and learning.

The functional description of a sys- tem is the most fundamental way of defining it. There are already many established methods for analysing and specifying the functions of a system. This is, for instance, the province of structured analysis as defined by DeMarco ’ or by Ross’ I or of the spe- cification techniques of Heninger and Parnas3.

The functions of a system are de- cided by the customer with the aid of the tools and techniques of the systems analyst. Attributes, on the other hand, require far more attention by systems designers. The creativity of design is in choosing or devising techniques that will give the system the desired attri-

butes.

Project tracking

In this paper, we shall deal with the functions of the system only at the most general level. We shall assume

volt6 no 5 june 1984 0011~84~~4/05001~05$03.00 @ 1984 Butterworth & Co (Publishers) Ltd. 19

that we are developing a computerized project tracking system to replace a current manual system. The first-level components of the functions of project tracking are:

l hardware l software 0 peopleware l paper-ware

In a real project, the infotect would analyse the functions of the system in far more detail - for example, who will enter data, how it will be proces- sed, who will get the reports, and so on. However, the first-level break- down is sufficient to illustrate how the techniques of design by objectives help in attaining maintainability.

Maintainability attribute

Maintai~abili~ is the capacity of the user to perform maintenance, therefore the first prerequisite is to break down maintenance - the making of a change in a system - into its life cycle or phases. The seven phases of mainte- nance are as follows:

Problem recognition: Something needs to be changed, but it takes some time before a person knows it. Administrative deZay: Time passes until someone is assigned to do the maintenance. Tool and documentation collection: The maintainer assembles materials for the change. Probl~ analysis: The maintainer investigates what needs to be changed to reach the desired state of the program or system. Change specification: The maintain- er specifies new and changed code or procedures to be installed. Active correction: The change is made as specified. Test: The new function is tested and its side effects probed, and the change is independently reviewed and approved.

Having specified the components of maintenance, it is necessary to attach a

cost measurement to them. Table 1 shows a system attribute specification table for expressing such measure- ments. The rows are the seven phases of maintenance. The ‘unit’ column in- dicates a measuring unit for each row. Since the costs of maintenance are re- lated to the elapsed time in which the system remains in an unsatisfactory state and the consumed time of user maintenance staff, the appropriate units are time.

The next four columns indicate a ‘worst level’, ‘best level’, ‘planned level’ and ‘now level’ for each attri- bute. These levels are measured in the unit specified in the ‘unit’ column. If the attribute falls below the ‘worst level’, the system will be rated as un- acceptable. The ‘planned level’ is the level at which the customer and in- fotect are aiming. The ‘best level’ gives

the customer an idea of the state of the art for this attribute. The ‘now level’ indicates the performance of the cur- rent system. (Remember that most ‘new’ ~formation systems are new in techniques, not in function; they re- place something that is already work-

ing.> The cells in the ‘level columns must

be filled, but there is allowance here for ‘?‘s, ranges, and relative figures. The cells in the ‘now level’ column of Table 1 refer to a current manual sys- tem. Its reports are issued monthly, so the elapsed time to detect a problem, fix it, and test it is at least a month for each activity. The customer would like an online system with daily update and immediate query. The customer plans to recognize problems within an hour of receiving the system’s reports, and have them fixed within two working

20 data processing

systems

days. The infotect estimates that the state of the art with such a system would be to fix a problem by the end of half a day.

The infotect also points out that some changes are easy to specify and easy to code and others are hard to specify and hard to code. Therefore the estimates for attribute A6 (active correction time) are expressed as a multiple of attribute A4 (problem analysis time).

The ‘more important than’ column allows for attributes to be ranked against each other. This gives the in- fotect a guideline when one attribute has to be traded off against another. In this case, the customer regards speed in recognition (Al) and in problem analysis (A4) as more important than speed in active correction (A6).

The ‘ref column provides for refer- ence to supporting documents.

Maintainability techniques

Having fully specified the functions and attributes of the desired system, the infotect now proceeds to select a set of techniques that will enable a system to be built within acceptable values of the attributes.

A sample list of techniques in the maintainability area follows: (each technique has a shorthand code, e.g. M.TEL indicates ‘Maintainability - telephone numbers’, a description, and possibly a reference to a source or a fuller discussion. You can add to your list of techniques as you learn them from the literature, classes, experi- ence, or your colleagues):

M.TEL. Shift operators shall have home telephone numbers and duty rosters for the qualified mainten- ance programmers, and rules for when to call. M.MPG. Maintenance program- mers shall be considered qualified only when they can pass an artificial bug finding exam at 90% in five mi- nutes. M.DBA. Full database audit prog-

rams shall be built to test all stored data4=. M.LIB. All programs and text d~umentation shall be available on a central machine library. M.TXT. Program text shall be logi- cally grouped by indentation; com- ments shall be made for at least 30% on average of lines4b. M.LST. Programe logic structure shall be forward flow only - no backward GOTOs; maximum mod- ule size shall be 50 statements ex- cluding comments. MJNS. Formal inspection of all proposed changes shall be carried out before approva14c’5.

The technique/attribute table relates techniques to attributes by giving a quantified expectation for each com- bination: how much does this techni-

que contribute to that attribute? The relationship between techni-

ques and attributes can take any of several forms, such as likely ranges, data from experience, formulas for cal- culation of the attribute value, or simply advice (‘try it on a pilot ver- sion’). Little work has been published on these relationships to date, but one model might be Phister’s books on data processing technology and economics6z7.

Attribute/function/technique table

It is now time to put functions (system capability objectives), attributes (sys- tem characteristic objectives), and techniques (methods) together into the attribute/function~technique table, see Table 2.

~0126 no 5 june 1984

This table features the functions of the system - its nonnegotiable capa- bilities. The importance of the two- dimensional presentation of attributes and functions is to remind the infotect that attainment of an attribute de- pends on attaining it with respect to each function. The desired maximum on (say) problem recognition time (attribute 1) must be attained with re- spect to hardware and software and peopleware and paperware. Blank or scantily filled areas are warnings that some objective of the system may not be sufficiently covered.

The aim is to fill all cells, or to understand why certain cells cannot be filled. A ‘0’ entry is used to indicate that a certain attribute is not applicable to a certain function, but it should be used sparingly. In Table 2, for inst- ance, there are no ‘0’ entries; it is not far-fetched to argue that each of the stages of maintenance applies to each of the functions. When correcting a peopleware problem, one still has to recognize the problem, handle admi- nistrative delay, collect tools and docu- ments (job descriptions, for example), analyse the problem, correct it, and test the new procedure.

A blank cell is a warning signal that no technique has been included that attains the row attribute with respect to the column function. This may indi- cate an undeliverable objective. A blank row, such as administrative de- lay, indicates an attribute for which no techniques have been selected. A blank or scantily filled column indi- cates a function for which few techni- ques have been selected.

Table 2 makes it clear that the main- tainability techniques are oriented to- ward software, especially the problem analysis and test attributes. The tech- niques aid the maintainability of hard- ware to the extent that reliable soft- ware aids the detection and repair of hardware errors, but the large gaps in the hardware column alert the infotect to the need for further techniques for this function, vendor maintenance contracts, for instance. A function that

22

is even less well served is paperware, which highlights the fact that the tech- niques ignore the clerical function.

The idea of the attribute/function/ technique table was derived from the requirements/properties matrix pre- sented by Barry Boehm et al., in Char- acteristics of software quality’. The tech- nique seems to have been used in cost/ value analysis engineering technology even earlier.

The value of such tables is in con- trolling the use of resources and tech- niques to achieve specific objectives, such as maintainability. Thayer et a1.9 have reported that the use of such a table was a major corrective tool in countering the effects of wasted prog- ramming effort due to incomplete and

incorrect design, which accounted for about 62% of the maintenance changes to operational systems. Thus the attri- bute/function/technique table can be viewed not merely as a means of build- ing maintainability into a program or system, but also of reducing signi- ficantly the need to perform mainte- nance changes that are the result of poor design.

Quota control table

Up to now we have been dealing with intentions. We documented the cus- tomer’s objectives, we specified a sys- tem to perform the desired functions, and we chose techniques that should achieve the desired level of the custom-

data processing

systems The customer sets system objectives

u””

Funct,onal speczf!catlon Project trockmg

Hardware Software Peopleware Poperuare

Attribute specification Rellabl~ity cost Malntoinobillty Schedule, etc.

Progrommer exom Datobose audit

AttrIbute explosion Problem recognition Admrmstrottve delay Tool, dot collection Problem onolysts Chonge speciflcatlon Actwe correctmn Test

Procurement IT’?‘-! _~_..I

Attrlbute/functlon/technlque/table I----- I iFiF!

Quota control toble

j f T ; T fr0Ti

Figure 1. The desq process.

er’s attributes. Now it is time lo esti- mate the success of our intentions. This is the function of the quota con- trol table (Table 3).

The quota control table provides a tool for estimating the contribution of each technique to the planned level of each attribute and for estimating the side effects of techniques. The cells show the percentage contribution to each attribute of each technique. The final column is a row total made by summing the percentages. A figure greater than or equal to 100% indicates an attribute attained, possibly with a margin of safety. A figure less than 100% is a warning signal, indicating an attribute not yet attained in the design.

The table should be used through- out the development process to summarize the distance between the contribution of the techniques as cur- rently specified and the planned level of the attributes.

Quota control tables also help to keep all development participants in- terested and motivated in designing all critical qualities into the system from the very beginning of the project . This is always a cheaper and more reliable way of getting what the customer and

the infotect have agreed on. If you simply stated goals on the System Attribute Specification Table at the start of the project, and then measured whether or not you got them at the end, six months or five years later, for example, then you would usually be disappointed. Several of your planned levels of critical attributes would not be reached. The cost of ‘patching up’ a design after it has been implemented is quite high.

The alternative is to fill out quota control tables at every stage of the de- velopment process, and use them as a evolving system. The assessments guide the infotect in altering the mix of techniques in the evolving system, and the evolving design refines and cor- rects the assessments.

The quota control table in Table 3 reflects the strengths and weaknesses detected in earlier analyses. The tech- niques selected so far favour the soft- ware function over any other. They also favour the attributes of problem recognition, tool and documentation collection, and problem analysis. Administrative delay, change c&cation, and active correction not been addressed at all.

spe- have

Conclusions

The above example has only used a subset of the tools and techniques of design by objectives, but, hopefully, it has demonstrated that this methodolo- gy is effective in making concrete an objective such as ‘maintainability’, and in carrying it through the complex design process to whatever level of de- tail is necessary. Figure 1 gives an out- line of the whole process. A complete exposition will be found in the book Lksign by Objectivesio.

References

1

2

3

4

5

6

7

8

9

10

DeMarco, T, Structured Analysis and System Specification, New York, NY: Yourdon, Inc, New York, NY (1978). Ross, D T and Schoman, K E Jr, Structured analysis for requirements definition, IEEE Trans. Software En- gineering, SE-3, 1 (1977) pp 6-15. Heninger, K L, Specifying software requirements for complex systems: new techniques and their application, IEEE Trans. So~~;are En~ne~‘n~, SE- 6, 1 (1980) pp 2-13. Gilb, T, Software Mettrcs, Winthrop Publishers, Inc, Cambridge, MA (1977) (out of print). Studentlitteratur AB, Lund, Sweden (1977) (in print, in English) (a) p 124; (b) p 121; (c) p 229. Fagan, M E, Design and code inspec- tions to reduce errors in program de- velopment, IBM Systems J., 15 (3) (1976) pp 182-211. IBM Reprint Order No. G321-5033. Phister, M Jr, Data Processing Technol- ogy and Economies, Santa Monica Pub- lishing Co, Inc, Santa Monica, CA (1976); Digital Press, Maynard, MA. Phister, M Jr, Data Processing Technol- ogy and Economics, 1975-1978 supple- ment, Santa Monica Publishing Co, Inc, Santa Monica, CA (1980). Boehm, B W, Brown, J R, Kaspar, H, Lipow, M and MatLeod, G J, Charac- teristics of Software Quality, North-Hoi- land Publishing Co, Amsterdam (1978). Thayer, T A, Lipow, M and Nelson, E C, Software Reliability-A Study of Large Project Reality, TRW series on software technolorrv 2, Elsevier/North- Holland Publishl&g Co, New York, NY 11978). Gilb; T, besign b_y Objectives, North- Holland Publishing Co, Amsterdam, forthcoming. 0

Iver Holrers vei 2, N-1410 Kofbotn, Norway. Tel: (472) 80 1697.

vol26 no 5 june 1984 23