Field prototyping for software a practical approach to implementation

Dear Sir, I have been so much encouraged by the comments of Prof. C A R Hoare on programming as to present a pro- gramming methodology which has evolved in my work over the last five years. I have found this methodology useful and applicable to both hard- ware and software projects. It has been used in several medium scale commercial software projects and with several microprocessor projects.

THE PROBLEM

The basic problem with many com- puter projects is that they suffer from the effects of rigid top-down analysis. In this, the application is analysed, a comprehensive specification (i.e. blueprint) is written and programming proceeds, without deviation (in prin- ciple), from the specification. This is, to extend one of Prof. Hoare's analogies, rather like constructing a building directly from the architect's conception.

The failure of analysis lies mostly in failure of communication between the analyst and the intended users. Typically, the analyst is a computer specialist and has no particular back- ground in the intended application. It is unlikely, unless the subject is very simple, that the analyst (without background) will have a thorough, detailed grasp of the subject until long after the specification, if ever.

How then, you may ask, does an analysis ever finish and how do pro- grams ever get written? In my exper- ience, the analyst simply listens to thetneeds of the users and directly translates these into a computer solu- tion, often with little understanding of what he is doing. The translation of the desires of the users is indeed the job of the analyst, but unfor- tunately the users generally over- or underestimate grossly the capabilities of the computer, or worse still, have no idea at all. In short, it is often a case of the blind leading the blind. The end product often looks like it. To put a fine point on it, it is safe to

assume that the user will not know exactly what he wants in a program until he uses the program for some time.

The result, as most commercial pro- grammers will avow, is often a mess. The finished product may well have glaring omissions or completely mis- interpret the application. At this point, frantic patches are made to the soft- ware until a usable product is tacked together. Frequently, however, the program is never adequate and the end users suffer badly. No matter how bad the product, it is almost never scrapped - this would be considered the most grievous of failures.

Programming itself is subject to several problems, even given a 'correct' analysis. The first of these is the test- ing of software mechanisms, many of which will fail, despite rigorous test- ing, once subjected to operation in the field. The second exists in the nature of programming, in as much as it is simple (and desirable) to create pro- grams which transcend the ability of the creator to understand them. This makes it diff icult for the programmer to ensure that the overall operation of even fairly small programs will be cor- rect, despite careful testing of manage- able portions.

I would sum up the defects of traditional program methodology as:

• lack of comprehension on the part of the computer analyst of the intended application

• lack of comprehension by the users of the limitations and possibilities of the computer in their application

• failure of software mechanisms and the improbability of complete test- ing, of even small parts of programs

• human inability to understand more than small parts of programs simultaneously, leading to failure of programs in overall operation

The defects outlined above appear, to me, almost inescapable. Mutual lack of comprehension on the part of analyst and user seems natural. Were it possible to master any subject, be it programming or petroleum explora-

tion or stock control, there would surely be no need for experts. In short, the user interface is an area which is not likely to be solved by formalistic solutions. It is more likely to be solved by universal 'computer literacy' when computer specialists are no longer necessary.

Proving software by mathematical methods has been promised, but no breakthroughs are to be expected. Errors in algorithms will be with us for a long time still, even with the 'best' programming languages and methods. Lack of total simultaneous comprehension is not to be considered a failure of intellect, but rather a triumph. After all, who would be ashamed of building a machine stron- ger than ourselves: should we be reluc- tant to create programs which outstrip us intellectually?

PROPOSED METHODOLOGY All of this, of course, is not to con- done facile analysis, lack of interest, sloppy programming or stupidity. There are techniques which will alle- viate all of the above problems. Top- down analysis is better than none, users may know what they are doing, structured programming does produce better programs and programmers may know exactly what they are doing. Nevertheless, it is better to know that there are problems which may yield to no intellectual solution and that ultimately trial and error must take place.

In the proposed methodology, the application is first 'solved' using tradi- tional methodology and thoroughly tested. The resulting program is pre- sented to the users. The users must be under no illusions, as they usually are, that this is the final product. They must use it, however, as though it were. This means that steps must be taken to minimize possible damage to the end users as a result of program errors, be the damage scrambled accounts or exploding factories. Limi- tation of damage is achieved most suc- cessfully by using a 'guinea pig' - an

vol 5 no I jan~feb 1981 29

end-user who is willing to suffer the trials and work of program testing, He will attempt to use the system as though it were finished. Naturally, the experimental program is not used on ‘live’ data or processes, which must operate normally, in parallel to the tested system.

As the guinea pig discovers pro- gramming and analytical errors, the programmer applies patches to over- come these and to allow testing to continue. When the guinea pig is satis- fied with the product, a new guinea pig is introduced. He will probably discover ‘new’ errors, but fewer than the first one. If possible, further guinea pigs should be used, until the users are satisfied with the program and the programmer is satisfied that the more glaring errors are detected and patched. Distinction should be made, however, between errors and enhancements at this point. It is only too easy to become trapped into mak- ing enhancements when the point of the field prototype is to detect errors and inadequacies in analysis and pro- gramming. Enhancements must be made later.

Once all concerned are fairly happy with the prototype and feel that they know what is going on, then the second phase commences. The prototype must be &rapped. It has

served its purpose as a model; like a model it must not be used as the frame- work for the final product. The appli- cation is reanalysed by the original analyst and the end users. A new specification, with enhancements, is drawn up and the application is repro- grammed. The program is tested and then released to the guinea pigs and the patching process commences. Patching, at this point, should be a relatively short process, unless exten- sive enhancements have been incor- porated. If necessary the entire cycle is repeated until a satisfactory, finished product is produced.

This methodology is summarised below:

traditional analysis, programming and testing to create a prototype release of the prototype to guinea pig end users with operation of parallel systems to minimize damage patching of analytical and program- ming errors of the prototype - documentation of enhancements reanalysis of the application, taking account of the experience gained by testing the prototype program in the field scrapping of the prototype and complete reprogramming to the specification of the new analysis release of the program to guinea pigs after testing by programmers

l patches to the program necessary to bringit to full operation

l continuation of the cycle until a satisfactory program is produced

CONCLUSION

In many respects I have overstated the case for this methodology. I do not consider it, nor any other, a panacea to all ills of programming. I do feel, however, that errors and oversights are inevitable, if not excus- able, and that this should be taken into account in any programming methodology. What is necessary is to ensure that as many errors as possible are detected and corrected, whatever their source, and that damage to end users caused by errors in programming is limited. For this, I consider field prototypes the most effective and practical means of achieving the goal of error-free programs.

M F Smith

Department of Computer Science,

University of- Reading, Reading

RG6 2AX, UK

REFERENCE

Hoare, C A R ‘Hoare on programming’ Computerworld UK (22 October 1980) pp 18-20

30 microprocessors and microsystems