Dean Associates, which was set up in 1982, specialises in producing material for the Open Learning (defined in glossary) market, approximately 60% to 70% of which is for Computer Based Training (CBT). Most of these CBT packages are written for organisations which have commissioned them, although a few products [s1, s3] have been written for a wider market. In addition to producing material that is used directly by students/ trainees, the company develops packages called Instructor Support Kits, which can be used in situations where the trainer is not fully familiar with the material being presented. The company also provides independent advice on Authoring Languages (ALs, a kind of programming language, see chapter 1.3 for a definition).
The company believes that its market share within the domain of open learning is very small; within the field of CBT there are approximately six to ten directly competing companies in the UK, and it is probably the smallest of these in terms of turnover. However, they feel that they have a good position in basic (i.e. low level rather than, say, expert system) CBT production.
In the widest context CBT is instructional material that uses primarily the computer as the medium of delivery. A highly advanced form of CBT is simulation, which can be used, for example, to train pilots (flight simulator), and which may make use of an exact replica of a real aircraft cabin, and a hydraulic mechanism which moves this. A slightly less sophisticated form of CBT is real-time simulation of process control systems (e.g. nuclear power station, chemical reactor, oil rig). Within these CBT environments, trainees are able to make mistakes (and hence learn from them), which in the real world would be disastrous. A more mundane example of CBT is the ubiquitous typing tutor.
However, when the term CBT is used, it generally refers to systems that are either a direct replacement for, or are used in conjunction with, training that traditionally takes place in a classroom or related teaching environment, and this is the meaning with which I use CBT. Usually there is other material that is used in addition to the computer (e.g. textbooks, workbooks, video, slides, audio tapes, a course of instruction, etc). There are many other names for this kind of training, such as Computer Aided Learning (CAL), Computer Aided Instruction (CAI), and Computer Based Education (CBE).
Many arguments both for and also against the use of CBT material have been discussed [Dean 1988, DT March 1988, Heaford 1983], but I will not address these here, as they are not germane to the terms of reference of this project.
Within the context of the company, and the project, CBT must of necessity be 'a good thing'.
Many different techniques can be used in courseware (a term that refers to instructional material that makes use of the computer), as shown in the following list taken from an AL manual [IBM 1987]:
These are, in fact, the same kind of activities that are used in teaching situations in non-computer aided contexts. I do not intend to discuss these in more detail, as the use of such techniques is a pedagogical consideration. However, limitations of a given AL may well mean that certain forms of testing, simulations, role-plays, and problem solving techniques, are not developed to their full potential. This problem is discussed in chapter two.
Currently, the company uses commercially available Authoring Languages to write CBT software. The reader may well wonder what exactly an AL is, or how it differs (if at all) from a programming language. Let IBM explain [IBM 1987]:
Courseware… can be written using a variety of different languages and programming systems. Generally, these languages/ systems can be classified into three areas: general purpose languages, authoring languages and authoring systems.
General purpose programming languages, like BASIC, PASCAL, and C, are designed for a multiplicity of applications. Consequently, they do not contain features that make it particularly useful for writing instructional materials…
An authoring language is a programming language that is specifically designed to be used in the development of computerised instructional materials. Thus such courseware activities as answer analysis, student control, feedback, effective screen presentation, and scoring are more easily written…
An authoring system is a set of programs that has been designed to provide the courseware author with the ability to write lessons with very little programming knowledge. An authoring system presents menus, prompts, and questions to the author and then builds lessons based on those responses… However, an authoring system usually does not provide the author with the flexibility or opportunity of creativity that most developers want.
The reasons for the company's use of authoring languages, rather than general purpose languages or authoring systems, should now be apparent.
When using commercially available authoring languages to write CBT software there are two areas of difficulty, and these form the motivation behind the project. Firstly, there are problems associated with the languages themselves. According to one of the authors in the company "there is no one best AL", and all lack some desirable features, such as the ability to interface with video or audio equipment, good (and simple to use) graphics, and comprehensive facilities for the recording of students' responses. Moreover, none of the products that are used has the capability to analyse students' answers to the level that the company ideally requires. (Of course, it is possible that a suitable product exists, but of which the company is not aware).
The second problem is of a commercial nature. With many commercial ALs it is necessary for the company to enter into a licence agreement, and this makes it difficult to produce cheap mass-market CBT packages. For example, one package [s1] which is written in the Microtext AL is sold for £70, of which £10 is paid to the company that holds the Microtext copyright. Compsoft PLC have a different approach; they state that if a product is developed for a third party, an annual licence fee of £5000 (in addition to the purchase price of the AL) must be paid [Compsoft 1987]. Clearly, if the company wishes to market inexpensive material this is a considerable overhead, and a licence-free product is most attractive.
The original requirements (appendix A) called for the development of an authoring language, which would be written in the C programming language. My analysis of the requirements showed that this was not feasible within the allotted time-scale, and more appropriate requirements were agreed (chapter 3.2). A suite of matching functions was to be produced, along with a few functions which would be necessary in order to use these; other functions which are needed for a fully working AL could be developed later.
Three distinct sets of requirements for CBT packages were identified: student, author, and maintenance. The initial phase of the project consisted of a review (from a student's standpoint) of current commercially available CBT and Computer Aided Language Learning (CALL) packages. Attention was focussed on "user friendliness" rather than pedagogical aspects of the packages, (which are the responsibility of the author), and a list of pitfalls to avoid (which includes a few positive ideas!) was derived. Authors were asked for their views on the matching functions that they used, and for ideas on what an "ideal matching function" should do. These ideas were taken into consideration during the design of the match functions. (Admittedly, the number of authors I talked to was small, and they all work in the client company, so this cannot be regarded as a valid statistical survey. However, it is not unreasonable to assume that they are familiar with the limitations of existing functions which they use, and correspondingly, have a good idea of the facilities which they would like to have available. This is, after all, one of the company's reasons for initiating the project).
Once the requirements to be met, as set out in the Requirements Document, had been agreed by the company, detailed formal specifications of the functions were written, using Abstract Data Types (ADTs). The User Manual was then written, which explains to authors how to use the functions.
The final stages of the project were the detailed design of the functions (and sub-functions not apparent to authors), conversion to code, testing, and evaluation of the product. Chapter 6, Design and Maintenance, contains all implementation decisions, and the reasons behind them, as well as all other information necessary to facilitate the maintenance and updating of the functions produced. Additionally, it is envisaged that at some stage in the future production of other functions that are necessary for a fully operational AL will be undertaken, and the Design and Maintenance section will pave the way for this.
The whole of my design philosophy has been to adhere rigidly to a modular approach to the design and coding of the functions (refer to Chapter 6, Design and Maintenance, for my reasons). As far as possible implementation considerations were not embedded in the specification; this means that should the company revise its policy regarding the use of the C programming language, and decide to use a different language, only the coding of the functions themselves will need to be changed.
Preface | Contents | 1 Introduction | 2 Review | 3 Req. analysis | 4 Req. documents | 5 Specification | 6 Design | 7 Verification | 8 Discussion | 9 PAL manual | Appendix A | Appendix B | Appendix C | Glossary | References | Index