Current aspects of program exchange— Costs and benefits

CURRENT

ASPECTS OF PROGRAM EXCHANGECOSTS AND BENEFITS

G. BEECH PhysIcal Scrences Program Exchange The Polytechnic.

Wolverhampton

W\‘l

ILY. England

As computer hardware costs tumble. we can expect to see a steady increase in the relutire costs of the operating systems. utility programs and program libraries that users expect to be provided with a new computer. This reflects the labour intensive nature of software which one expert has called ‘crystallized labour’. This phrase will be uppermost in our minds as we try to put into perspective some of the predicted technological changes in computing. cheaper communications but more expensive labour costs ahead of us. We will examine the case for the interchange of resources between educationalists and look at ways in which this has been done and how it might be done in the future. PROGRAM

EXCHANGE

IN AN

EDUCATIONAL

ENVIRONMENT

Computer Assisted Learning (CAL 1,should be the province of the teacher. not the programmer This being so. it should attract the most talented teachers who should be encouraged to directly involve themselves in the creation of new and imaginative CAL materials. If this is to happen. the re-invention of the wheel can be avoided by a cooperative spirit such that materials created by one teacher can be used by many others. This should produce a real financial saving if. as predicted by Knight [l] ‘*. the production of software will be the critical technical factor limiting the growth of CAL in the next decade (and) the costs of software development for CAL are likely to be double or treble present costs . as demands for sophistication increase”. Increasing requirements for the financial accountability of education will make us take comments such as this very seriously indeed in the near future. My reason for asserting that CAL should be in the hands of teachers is mainly governed by the fact that the main stumbling block to the widespread acceptability of CAL exchange has been the feeling by the majority of educationalists that each of them knows best how to write a CAL program. This has tended to spawn large numbers of small. relatively unsophisticated programs. It can be seen from Fig. 1. which relates to a recent survey of CAL programs by Peterson, that although more than 80 9; of the total programming effort (i.e. the number of lines of coding) is in large programs of more than 600 lines. it is also true that a substantial number of programs. 60 “; of Peterson’s sample, are classified as ‘small to normal’ (up to 600 lines). If we look beyond CAL programs written within the National Development Programme in Computer Assisted Learning. a much larger proportion of programs fall in to the ‘small’ category. For example, in the Physical Sciences Program Exchange, which collects BASIC and FORTRAN programs written mainly by a representative body of educationalists who. in general. are not funded by government agencies. we find that 85 “/, of its programs are below 600 lines. This may indicate that larger and more sophisticated CAL programs are more likely to be written within a collaborative environment as has been a feature of NDPCAL projects in the U.K. (and of NSF in the U.S.A.). With the closure of NDPCAL at the end of 1977 and a consequent de-emphasis of centralized funding for CAL development, transfer agencies such as PSPE could play an increasingly important role in encouraging the collaborative development of new materials.

WHAT

TO EXCHANGE-AND

WITH

WHOM?

As a generality, the concept of program exchange would seem to be advantageous-at least for CAL strategists who are committed to this technology. But, before explormg the technicalities of an exchange scheme, we should reassure ourselves that the prospective recipients of CAL materials, who are not necessarily convinced by the need for CAL. also share our enthusiasm. Also, we should be sure that we known what to exchange in the most effective manner. Fortunately. the majority of educational institutions do seem to favour a program exchange scheme and, by implication, the use of CAL materials. This emerges from a study by Tumbull [2] and 73?, of the schools sector, agreed that a who reported that 72 7; of the colleges questioned, 137

G. BEECH

138

software exchange scheme was necessary either immediately or within the next five years. Also a substantial majority favoured a scheme that was not related to one engaged in exchanging other educational resources. Perhaps the most pertinent aspect of Turnbull’s data is that the requirements for CAL and its successful exchange seem to be equally as strong at school level as in higher education: this represents a relatively untapped market for the CAL exponents who have been located mainly in universities and polytechnics. Indeed, there is now considerable overlap at the secondary,‘tertiary interface that could well be exploited.

Program

Fig. 1. Distribution permission.

size,

hundreds

of

lines

of numbers and sizes of programs developed by NDPCAL projects (reproduced. from a more detailed graph prepared by j. Peterson of the CALCHEM project)

What can we most successfully

exchange?

with

There are at least four answers :

detailed programming can then be recreated locally ; alone, with only the bare essentials of technical and educational documentation; 3. a complete package: the program. documentation, teacher’s and student’s guides: 4. systems software: compilers or interpreters to enable effective CAL programs to be written (for example, the Leeds University STAF system can be transferred to a wide variety of machines independently of any of the CALCHEM packages that it supports), 1. the idea;

2. the program

With an efficient program exchange scheme. we must regard “idea exchange” as technologically obsolete and financially undesirable. At the other extreme, transfer of a complete software system is likely to be a desirable but infrequent occurrence. We shall limit ourselves to the transfer of either complete packages or programs. Transferability of these is most easily achieved when : they have been developed to meet the real nee& of a sufficiently large number of educationalists ; modularity of design is inbuilt to permit easy adaptation to local needs; a commonly available programming language has been used ; the programs are available in a computer-readable form. At the present time, cost savings are not an important factor although this may rapidly Therefore. we now examine some of the technical factors affecting program transfer. BACKGROUND

TO

PROGRAM EXCHANGE: AS A PROTOTYPE

THE

ARGONNE

change.

CENTRE

Program exchange is not new, although it is far more firmly established in industry and research than in education. The earliest report of an “idea” exchange appeared in October 1955 [3] : this was

Current aspects of program exchange-costs and benefits

I?9

essentiahy a printed survey relative to nuclear technology, but each program cited by the editors included elementary technical information: over 100 programs were referenced and categorized. The first formal exchange service was SHARE for users of IBM computers; this was established in 1955. Other manufacturers were quick to see the advantages of such a scheme and, in addition to the establishment of individual user groups from the eariy 1960s. central organisations also appeared which were independent of any single manufacturer. The most important of these, the Argonne Center [4]. was initiaiiy established in 1961 and now supports of the order of 700 large algorithmic packages applicable to mathematics, nuclear science, space physics and related problems. The activities of the Argonne Center form the basis on which most of the more recent (and generally less ambitious) schemes are based, namely :

Incoming programs to the Argonne Center are accompanied author’s responses to the following:

by an abstract prepared from the

1. Xame of program. 2. Computer for which program is designed and others upon which it is operable. brief description of the problem being solved or a definition ofthe data 3. Description ofproblem orfuncrion-A processing activity being carried out is given. 4. Merhod ofsolurion-A short summary of the mathematical methods employed, numerical algorithms adopted. or procedures incorporated in the program. 5. Restrictions on the complexity qf the problem. 6. T.vplcal running rime-Information intended to enable the user to estimate machine requirements is listed. 7. Unusualfeatures of rheprogram-Distinguishing features and special capabilities of the program are enumer-

ated. 8. Reinfed ond auxiliar~programs-If

9.

10. 11. 12.

13.

14. IS. 16. 17. 18.

this program supersedes or is an extension of an earlier program. this is noted here. Programs used in conjunction with this program, especially those coupled through use of external data tiles should be mentioned. Status-The Center lists here the initial date of publication of the abstract. References-Available publications pertinent to the program are cited. Machim requirements-This item lists the hardware components essential for full utilization c _the program. Programmmg language(s) used--The programming language or languages in which the program was written are identified with an indication of the percentage of each used. If certain routines are in assembly rather than compiler language. these should be identified. Operating system or monitor under which program is executed-This item identifies the operating system. associated subroutine or function library. and installation support software used by the program. The version used is identified and deviations or exceptions noted. Other programming.or operating information or restrictions-Additional information needed by the reader to implement the program or determine the extent of the necessary implementation effort is summarized. Name and establishment qf at&or. ~ater~a~.~araiiabie-This lists the material being distributed, i.e. the contents of the program package. Caregory-The problem classification assigned from the Center program or system classification guide. Ke.rvords-This is a listing of the keywords associated with the program. supplied by the program author and’or Center based on the Argonne Code Center thesaurus.

Computer

activities

These include the storage. retrieval, testing and modi~cation of the programs stored. Wherever possible, the program is tested at the Center and reviewed externally. Cooperative

efjforts

Of particular importance in this category is the development of standards for programming practice which may ultimately ensure the ‘portability’ of programs without the need for extensive local re-writing of sections of code. To this list we should now add ‘Development Activities’ as a desirable attribute of an exchange scheme. By this. we mean that a program exchange centre can also, perhaps paradoxically, be concerned with coordinating the efforts of its members. There is only a limited amount of manpower for CAL activities and we should therefore, be concerned with coordinating them in the most effective manner. TECHNICAL

PROBLEMS

OF PROGRAM

TRANSFER

The programs needed to support CAL may either be made available remotely to a user as. for example, in the Open University or can be physically transferred to another computer. The latter C?.E-2-l/2--,

140

G. BEECH

is currently favoured, particularly for small programs, so we shall concentrate that we and others have encountered in this area. What programming language is best suited to CAL and, also. is easy to transfer? frequently oppose each other since we shall require a language to:

on the problems These two factors

1. have the required capabilities for CAL: almost any language supports elementary operations such as arithmetic, branching, input/output but only a few are interactive and have powerful stringhandling capabilities; 2. be easy to learn and use; 3. be in common usage on a wide range of computers: 4. be implemented in. as near possible, an identical manner on the compiler,interpreter of the author’s and recipient’s computers. These factors can be summarised as a counterbalance between: 1. convenience of writing, and 2. machine independence. There is no one language that adequately satisfies both of these requirements; indeed. CAL materials have been written in all of the general purpose languages such as FORTRAN. PL. 1. BASIC and APL. even though they all fall short of the “convenience of writing” criterion for CAL. The major restrictions relate to the difficulties. with these languages. of trapping simple student errors (such as alphabetic rather than numeric input), intercepting unexpected student input (such as ‘help’) and the general non-availability of calculator mode (to permit numeric calculations by the student ). Some of these problems can be overcome by the use of an authoring language such as COURSEWRITER, but there is scarcely any standardisation on the use of these. Educationalists have. therefore. chosen to emphasise the ‘machine independence requirement and this has led to the defacto dominance of BASIC and FORTRAN which has been underlined by commercial interests and the active encouragement of funding bodies such as NDPCAL. FORTRAN is a relatively well standardised language, having been defined by the American National Standards Institute (ANSI X 3.9-1966). Difficulties. where they are encountered, mainly relate to different word lengths (which affect accuracy), character handling (which is clumsy) and rigid format specifications. Recent compilers (such as the ICL New Range) are supersets of ANSI FORTRAN so that standard ANSI programs will compile and run correctly whilst permitting some non-standard features to be incorporated (of particular interest to potential ICL New Range users is the provision of powerful character handling facilities). NDPCAL projects. such as CUSC (Computers in the Undergraduate Science Curriculum) have found it possible to program entirely in standard FORTRAN to ensure transferability. BASIC is less standardised and has been implemented separately by almost every manufacturer. At a late stage. ANSI set ?~p a committee in 1973 to produce a BASIC standard. So far. only a draft minimal subset has been defined to include the statements: LET. GOTO. IF. GOSUB-RETURN. ON, STOP, DATA. RESTORE, DIM, REM. DEF. RANDOMIZE The committee

is also investigating

FOR-NEXT. and END.

other aspects of the language.

PRINT,

identified

INPUT.

READ.

as :

Nucleus-an extension to the overall facilities of the language. Strings-a package to give BASIC powerful string handling facilities. Maths-the MAT statements and more standard mathematical functions. Formatting-broadly PRINT USING. Files-a package to give BASIC a number of different file types and the ability to manipulate Inter-program linkage-the CHAIN statement and subprograms.

them.

In the absence of a complete international standard, NDPCAL have defined a subset which is of immediate usefulness in that the allowed commands or functions are known to work on a wide range of computers in current use [5]. PSPE supports this subset with very minor enhancements. Perhaps the most important aspects of this standard are the features that are excluded: these are; File handling except for INPUT Device handling System commands PRINT USING PRINT FILE PRINT FILE USING

and OUTPUT

Current aspects of program exchange-costs

and benefits

141

MAT PRINT FILE MAT READ FILE MAT WRITE FILE ON X THEN ON X THEN GOT0 (Use ON X GOT0 instead! ON X GOSUB IF . . GOT0 . . IF . . GOSUB . . IF . . THEN LET . . . IF . THEN PRINT . . . . A copy of the PSPE subset is available. on request, from the author. Also. we emphasize ‘good programming practice’ for BASIC authors, including: 1. Attempt reasonable error recovery within the BASIC program. This should usually be easier for the student to cope with than system diagnostics. 2. If a keyboard input variable is to be used as the argument of a mathematical function. then check it at once for valid range before executing a statement including such a function. Such caution is also justified when a programmer is uncertain (or for some other reason) of the range ofany variable to be used as an argument. 3. When X, M or N have been keyboard input, or their range is otherwise uncertain then, before executing a FOR X= L TO M STEP N check that M is greater than or equal to LI and ensure that (M - L t is a multiple of N. Similarly before executing ON X GOT0 . . . . check that X is in the expected range. 4. Do not input or compute numbers outside the range 10mz3 to 1O+23 as many BASIC systems are limited in this respect. As the accuracy of computation is limited by word length. authors should state the word length when submitting programs for distribution. 5. Group non-executable statements (except REM1 at the start or end of the program or subroutines. 6. Subroutines should never be executed as in-line coding, always as out-of-Iine subroutines. located together at the end of the program. 7. In larger programs. voluminous text to be printed or assigned to strings should be separated from other program statements in the interests of easy reading of the program. The use of GOSUBs with a varaible specifying the particular text sewn1 to be printed allows text to be stored in subroutines or on file. and easy conversion from one technique to the other. Although we have not incorporated any Authoring Languages into our exchange service, it is worth mentioning some of the more common ones and emphasizing their advantages compared with the general purpose ones we have mentioned : COURSEWRITER is the most widely known of these languages. It is characterized by being well suited to textual interaction with the user and an implicit branching feature that is a powerful feature for programmed instruction. It is, however, weak on arithmetic faciliti,es. PLANIT is similar to COURSEWRITER with the addition of numeric capability. Also, it is not restricted to a single manufacturer since it is written in FORTRAN and was developed with tne support of the National Science Foundation. TUTOR works in conjunction with the PLATO system on CDC computers and the remarkable plasma display terminals. It is the only major CAL language to support true interactive graphics and such exotic devices as rear projection and ‘talking discs’. Unfo~unately, it has not been implemented on smaller computer systems but the underlying philosophy will certainly influence future develop ments. A language developed to support the CALCHEM project at Leeds University is STAF. derived from the Leeds Author Language. The most interesting feature is that versions of the STAF system have been programmed in FORTRAN and BASIC for, at the time of writing. ten different computer systems. This goes some way to meeting the problem of transferability of authoring languages.

CURRENT

PROGRAM

EXCHANGE

Apart from vendor-supported libraries, several independent most important of these for the physical sciences are: 1. QCPE (The Quantum Chemistry Program Exchange)

SCHEMES schemes have been established. The

G. BEECH

142

QCPE 1s a financially self-supporting organisation based at the Univrrsity of Indiana. It is a wellestablished. professionally organized service that enjoys a high reputation amongst its members who are mainly involved in research level activities. Most of the programs are concerned with highlevel calculations and are oriented to batch usage. QCPE believes that documentation should be sufficient for their average member to be able to use the program efficiently. The emphasis is on the international reputation of QCPE rather than written. rigorous standards. QCPE now holds more than 300 chemical systems. programs and subroutines. Holdings grow at a rate of 35-40 new programs annually. Membership currently exceeds 1000 2. CONDUIT [Computers at Oregon State University. Vorth Carolina Educational Service. Dartmouth College and the universities of Iowa and Texas (Austin)]

Computing

This scheme is supported by the National Science Foundation and is centred at the University of Iowa; CONDUIT has rigorous standards of documentation, program testing and reviewing Reviewers for CONDUIT rate each of 17 package qualities on a five point scale and. also. rate the importance of each quality relative to the stated objectives and intended audience. The average review time is of the order of 3 hr. By 1 May, 1976 it was projected that 30 program packages would be available. Programming support for implementation of materials is guaranteed with a view to facilitating program portability. Full membership of CONDUIT places substantial financial responsibilities. by U.K. standards, on the member institutions. 3. CACHE

(Computer

Aids for Chemical

Engineering

Education)

This caters specifically for one sector of education. It is oriented towards batch-processing and has a library of 130 programs, one in each of the traditional areas of chemical engineering. CACHE is also concerned with establishing guidelines for program standardisation. 4. PSPE (Physical

Sciences

Program

Exchange)

PSPE is. currently. a project within the National Development Programme for Computer t\ssisted Learning and is based at The Polytechnic. Wolverhampton. It has a library of almost 150 programs. mainly in BASIC and FORTRAN. and has approximately 60 members (mainly polytechnics and universities in the U.K. and U.S.A.). Members are entitled to 30 programsyr but, if programs are contributed by a member, then an additional entitlement ensues. In this way. a genuine exchange atmosphere prevails. To ensure a uniform usage of programs by all members. there is also a requirement for a minimum number of programs to be requested by each member. The programs are supplied to users in one or more of the following forms: Listing-on 120 character line printed paper Cards-80 column Paper Tape-8 track: even parity Magnetic tape-7 track: odd or even parity 200 or 556 b.p.i; short or long gap Programs are produced from an ICL 1903A computer, peripheral specifications of which are supplied to members. Wherever possible, full documentation IS included(supplied by the authors) and specimen test data. In most cases we notify users of non-standard programming features. In some cases student teacher guides are also provided with the standard documentation. Subject areas include: Chemistry (organic, inorganic, physical and instrumental methods) Numerical methods and statistics Physics Biology (mainly biochemical) Materials Science Forthcoming

areas are:

Computer Science Mathematics Engineering Management Sciences. PSPE philosophy differs from schemes such as CONDUIT in emphasizing the rapid transfer of programs with modest documentation requirements: the minimum requirements of a program author are that two single-page forms are completed-one at a technical level. the other to cover educational aspects. In practice. many authors provide much more information although one recent contributor.

Current aspects of program exchange--costs

and benefits

143

when responding to our question “how much time did you spend in preparing this program for PSPE?“, answered “filling out these forms” which may indicate that even minimal documentation can be tiresome. Such experiences underline the fact that we feel some embarrassment in asking authors to expend their time in completing copious do~umen~tion when we have no rewards-~nan~i~ or otherwise-to offer. It is unfortunate that the same individuai could obtain greater recognition from his institution by publishing an account of some fairly trivial research of far less value to the academic community than a well documented program. FINANCIAL

CONSIDERATiOh’S

Fears on the part of teachers that CAL methods would displace conventionai teaching and hence cause redundancies have proved groundless. Most of the results to date indicate that CAL is used as an extra resource in the teaching situation and is, almost always, an add-on cost. Even where CAL has replaced other methods it has, at best, equalfed the cost per student contact hour of a conventional lecture : at worst, CAL can be four to five times as expensive as a lecture. What then are the attractions of the technique? Firstly, there is the argument that the qua&~ of teaching can be enhanced via CAL; this is only partly due to the use of the technique itself-it has rather more to do with the freeing ofa teacher from a mundane situation into one which permits more rewarding individual human contact between him and his student. Secondly, when dealing with large numbers of students. there is some evidence that teachers would prefer to make a once and for all investment of their time in writing CAL materials which can then be used. possibly several times per week, in a flexible manner over many years. The teacher is then freed for other work-research, curriculum development and so on. This has been found to be the case at the University of Illinois where, for example, Smith [6] has introduced PLATO materials to replace many lectures at the lower levels. These opinions will need to be reinforced by strong financial arguments wherever CAL methods are to be introduced for the first time; this is why the notion of transferability is so important. As an example. consider some recent costings of four National Development Programme Projects. shown in Table I. In the table. it can be seen that the development costs. even on an annual basis.

Table 1. Total annual costs from seven national development programming

projects

Project code

Depreciation on capital WI

Operating costs (f)

20 ‘:; share of Past development” W)

Total cost per annum (fj

A

2450 6600 8020 2650 12.000 4600 3100

2950 24.050 14,800 4800 13.000 17,700 12,400

6330 12.150 11.700 3250 3300 10.500 13,000

11.730 42.800 34.520 10,700 28.300 32,800 28,500

B c D E F G

* Assuming a 5 yr life for development expenditure.

can be comparable with the operating and depreciation costs; the figures for annual operating costs are estimates of the likely future costs in a steady state situation when all major development or modi~cation has ceased. It is probable that any of the quoted project costs would appear prohibitive to an institution about to embark on CAL. But if, for example, the materials developed by project G were largely acceptable to another institution, then the latter would benefit from the E65,OOOspent on development. It is likely that the complete set of materials could be integrated for a very much smaller investment. mainly of staff time, if as is often the case, suitable equipment is already available. Also, assuming similar operating costs in both institutions, the cost per student hour could be halved. Within the PSPE project we have also attempted to quantify the benefits of transfembi~ty. To do

G. BEECH

144

this. we recently surveyed our members How

Does Were How What

who had received programs,

asking questions

which included:

long did any modifications take? the program meet its stated educational objectives? the technical specifications accurate’? long would you have taken to produce the program’? has been the total student contact time’?

A total of 13 such questions were asked. in a structured manner. which tried to assess the ease of transferability and the educational value of the program. The responses have helped us to quantify the cost effectiveness of a program exchange service. Although we have only analysed tifty suney forms (the total returned to date). we can compute some very interesting figures to substantiate the need for our exchange scheme: Current Average Average Current Predicted

cost to distribute one program = f20 modification time (by recipient) = 1.72 hr per program estimated time to produce = 11.9 hr per program average usage = 9.4 hr per term per program usage = 10.7 hr per term per program

Thus. the expenditure of f20 (mainly PSPE staff costs!is outweighed by an estimated saving of about 10 hr of programming. Allowing for the fact that the recipient may. in fact. never have written such a program we still seem to be operating in a cost-effective manner. CONCLUSIONS-FUTURE

TRENDS

The exchange schemes that we have outlined are largely tailored to fit the existing pattern ot educational computing: each individual institution tending to have its own large. general purpose machine. In this environment, the physical transfer of programs is likely to continue to be desirable. The next significant developments in educational computing will be related to the coming together of communications and computer technology. Over the next few years, regional computing centres will receive increasing support to the detriment of institutional facilities. Simultaneously. small departmental facilities will grow so that we can envisage a scene in which CAL is supported by a network of regional centres; the actual computing power available to the user will increase dramatically even though the machines on his campus will be modest devices. .4t this stage. program eschanges will become centralized on the regional centres. A little further away, CEEFAX and VIEWDATA-like TV services. will bring CAL into the home at near-zero cost. By this stage. the function of an exchange service will have evolved to serve the needs of individuals who will have adapted to the ideas of ‘distance learning’. REFERENCES 1. Knight K R (Ed.). TechnologrC.4L-report of‘the wjorkingparty on computer technology m the 1980s: a Future Study Report prepared for the National Development Programme in Computer Assisted Leammg. Counctl for Educational Technology (1977). 2. Turnbull J.. Schemesfor C.4L E~whange. (Confidential Report to NDPCALt. Council for Educattonal Technology t 1976) 3. Radkowsky .4. and Brodsky R A Bibliography qj .4vailable Digital Cornpurer Codes /iv .Vtuleor Rrocror Problems. AECU-3078. U.S. At. Energy Comm. Washington. DC (1955 1. 4. Butler M.. Maskewitz B. and Rosen. J. Proc. Conf Appl. Comput. ,Methods Reactor Probl. ANL-‘OSO. p 125. Argonne Nat. Lab.. Argonne, Illinois (1965 I. >_ Schools Councrl. Computers in the Curriculum. Protect Paper and Supplement by R. Lewis and R G Dean. CheJsea College Centre for Science Education. 6. Smith S. G. and Ghesquire J R., In tJ S. Mattson et al.1 Computer .4ssisted Insrrrrciron in Chmr/srr~. Part 8. Vol. IV. pp 51-61. Marcel Dekker. Neu York (1974).