The Development of a Computer-Aided Learning Tool for

210_3downloaddoi10_1_1_105_1582 Proceedings of the 29th Annual Hawaii International Conference on System Sciences - 1996 The Development of a Computer-Aided Learning Tool for Supporting the Teaching of Assembly Language Programming

Andrew Williams

Department of Computing

Manchester Metropolitan University

Chester Street

Manchester Ml 5GD

ENGLAND

A. Williams@doc.mmu.ac.uk

Abstract

Sim8086 is a Microsoft Windows based Computer Aided Learning (CAL) system for supporting the teaching of assembly

language programming to first year undergraduate students. This paper takes the development of Sim8086 as a case study

and uses it to illustrate some of the professional, economic and educational issues faced by teachers who design and

develop CAL systems. In particular, the paper charts the interaction between these elements and seeks to offer guidance

to educators who find it difficult to embark on CAL developments. Further, we report our efforts to make opportunistic use

of resources as and when they become available in order to improve the chance of delivering CAL somare.

Background

Sim8086 started life as an idea for a final year

undergraduate project. The author hoped to use a final year student to produce some computer aided learning software that could make a contribution to teaching assembly language programming to first year Combined Studies students. Clearly there could be no guarantee that a useful system would result from such a project, but since the author has to supervise final year projects anyway, the possibility of getting a useable system made the effort worthwhile.

Traditionally, the assembly language programming

section of the Computer Systems Organization unit is introduced in the second term, which lasts twelve weeks from mid-January to March. The teaching is mostly by laboratory work (each student gets one hour of supervised lab time), with one or two introductory lectures plus a few lectures interspersed throughout the term to introduce unfamiliar concepts. The author's approach is typical. The first two lectures would compare and contrast assembly language programming with high-level programming in Modula-2. Meanwhile, the tools the students were to use would be introduced in the lab sessions. The same course is simultaneously taught to three other cohorts in the department and other lecturers had similar timetables for this part of the unit.

Despite the typicality of the approach, the author quickly became concerned about the progress of Combined Studies

students. The author had witnessed two groups of students in the lab attempting to type in the simple assembly language example programs at the DOS prompt, instead of into a file using the editor. Furthermore, all those students with no prior experience of computing were struggling badly with the concepts of assembling and then running a program. To exacerbate matters, at this early stage, the example programs were run under a debugger, so that students could see the effects of the instructions on the registers of the processor. This debugger, of course, would normally be used only by advanced programmers, who would already be familiar with concepts such as registers, flags, memory addressing etc In attempting to identify the reasons for these problems, the author found that some students were attempting to grasp the following concepts during the first two weeks of assembly language programming:

1 Registers.

2 Flags on a microprocessor.

3 Converting between decimal, binary and

hexadecimal.

4 The relationship between

memory variables and memory addresses.

5 Assembly language instructions.

6

Single stepping through a program.

7 Creating a program using a text editor (see later).

323

1060-3425/96 $5.00 0 1996 IEEE

Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29)

1060-3425/96 $10.00 © 1996 IEEE

8 Running the assembler.

9 Running the debugger.

10 Using MSDOS.

Certainly the author was expecting some of these

problems, but others came as a complete surprise. In particular, the difficulty with the concept of creating a program file, then assembling it and then running it. Although the author might have been more assiduous in finding out exactly what the students knew, it seemed a fair assumption that students who already had eleven weeks of Modula-2 programming behind them would understand the idea of storing programs in files. Ironically, part of the problem is the department's use of CLEM, a highly successful computer aided learning system for teaching Modula-2 (Boyle et al [l]). CLEM was developed in the Department of Computing and it has played a significant role in first year programming classes for the last four years. However, in the early stages of learning Modula-2, the process of editing and then compiling a program file is somewhat obscured by CLEM's intervention. In consequence, students without prior knowledge of this process do not necessarily grasp it until part-way through the second term. After the second assembly language lab, it was clear that the students were beginning to experience a form of information overload. To exacerbate the situation, some of the weaker students were becoming demotivated as their good faith efforts to follow the material achieved little in terms of improved understanding. The students' distress at their problems was manifesting itself as a tendency to simply follow the steps in the class materials without attempting to understand them. Although the author did attempt to produce more class materials, the tendency to follow the steps without thinking meant that this approach was not especially effective.

A case for computer aided learning

The difficulties experienced by students towards the end of January 1995 forced the author into considering what sort of support could be provided. Extra teaching slots are almost impossible to timetable for Combined Studies students, since their time is split between the Computing Department and another Department. Although the idea of having a final year undergraduate student (or an Msc student) develop a CAL. system was a good one, the timing meant that it could not be delivered in time to be of any use for the current first year cohort.

Nevertheless, the idea of a CAL system had its

advantages. If a self-paced instruction approach is adopted (eg Semb et al [2]), there is no need to timetable students to use the system. The system can be provided in a "drop-in" lab and students can use it whenever they have free time. Proceedings of the 29th Annual Hawaii Zntemutional Conference on System Sciences - 1996 Also, the lecturer's teaching hours are not increased significantly. Furthermore, the system, if successful, might play a role in future years and indeed might be useful in supporting other members of staff who teach assembly language programming. By the end of January 1995, the author had made a firm decision to implement a limited simulation of an Intel 8086 microprocessor in time for students to use it for revision purposes. Effectively, this meant that a system had to be available before the end of April 1995. Development started at the beginning of

February 1995.

Aims and objectives for Sim8086

Given the limited time available for the development, it was critical that the time spent on the system should be used effectively. Therefore, a set of objectives for the system was established; any modification to the system could then be considered in the light of these objectives. Where a modification did not meet any of the objectives, it could be rejected or deferred until after the first implementation. The objectives for

Sim8086 were:

The system should be able to execute a subset of Intel

8086 assembly language.

The system should show the effect of the instructions on the registers and flags of the Intel 8086 microprocessor. The system should show the values of variables declared in the assembly language program. The system should demonstrate the workings of the stack.

The system should be able to demonstrate all the

addressing modes of the Intel 8086. The system should handle number base conversions on behalf of the student. The system should allow the student to step through programs one instruction at a time. The system should be able to display tutorial material as the user steps through a program. This tutorial material should be incorporated with the program in such a way that the program can still be successfully assembled.

The system should be

lesson based. Each lesson would be a working program which demonstrates some aspect of assembly language programming. Lessons would be provided by the teacher, so there is no need to incorporate a fully-featured syntax analyzer. Instead, the teacher first checks the program by attempting to assemble it using the traditional tools. The program would only be incorporated as a lesson if it could be assembled successfully.

10 The system should be ready in time to support the

students' revision. 324
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29)

1060-3425/96 $10.00 © 1996 IEEE

Proceedings of the 29th Annual Hawaii International Conference on System Sciences - 1996 Together with these ten objectives was the overall aim of the project, which was to reduce the number of new concepts for the student to grasp. We will now review the list of new concepts that students were faced with, and show how Sim8086 differs from the sophisticated debugger that was originally used.

How Sims086 reduces the number of new

concepts students encounter

1 Registers

2 Flags

3 Conversion between number bases

The registers-and-flags part of the main window of the debugger, D86, is shown in Figure 1: xx 0000

BX 0000

cx

0000000011111111

DX 34 99

BP 091c

SI 0100

DI FFFE SP

FFFEl

Baser Colour Scheme

DEC BIN HEX

1

BX 0000 IP OlOE

CX 0007 CS 41D2

DX 4103 ss 41D2

Figure 2 - Registers and flags on Sim8086

SI 0100 DS 41D2

DI FFFE ES 41D2

BP 091C SP FFFE

4 The relationship between memory variables and

memory addresses Figure 1 - Registers and flags on the Some students would have encountered the concepts of debugger computer memory for the first time during the previous term. Nevertheless, they were familiar with the concept of a Of the registers, we are concerned particularly with the variable, due to their previous work on Modula-2. We will four 16-bit general registers, AX, BX, CX and DX. Each of use the section of assembly language code shown in Figure

these registers can be treated as one 16-bit register, named as 3, (which declares three byte-sized variables), as an example.

above, or as two g-bit registers. The &bit registers are called AH and AL for AX, BH and BL for BX etc. :In Figure 1, DX holds the value 3499,,. This means that DH holds 34,, and DL holds 99,,. These values are displayed in hexadecimal and there is no way to change to a different number base.

The flags

that are set are displayed just above the Instruction Ir;i

Pointer

(IP in Figure 1). In this case, only the Interrupt

Enable

flag is set (represented by an i). The flags that are

Figure 3 - Three assembly language variable

not set are not displayed at all. declarations Figure 2 shows Sim8086's representation of the same situation. In the Figure,

DX is shown as two 8-bit registers.

DH is to the left of the dividing line, DL is to the right. The other general registers are shown in their 16-bit forms. Above the registers are the flags. Notice that the interrupt flag, which is not covered in CS102, does not appear in the flags area. This approach to displaying the flags reminds the student that these flags should be considered, but shows clearly (by the empty check boxes) that the flags are clear. Figure 2 also shows how Sim8086 supports the conversion of number bases. CX has been changed from hexadecimal to binary representation. A colour-coding scheme ensures that students do not confuse representations. If the student wanted to see these variables when running a program under the debugger, s/he would need to open one or more memory windows. In Figure 4, a memory window has been opened (it is to the right of the registers). The memory window lists a string of bytes (hence the b, at the beginning of the memory window line in Figure 4). The first byte in the first memory window shows the value of the variable dogs. The second byte shows the value of the variable cats. The third byte is the value of pets. This display has to be specifically called up by the student. In this case, the student would have to type "lb,dogs" to obtain the display. A subtle problem with this method of showing variables is that the student has to 325
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29)

1060-3425/96 $10.00 © 1996 IEEE

Proceedings of the 29th Annual Hawaii International Conference on System Sciences - 1996 make the assumption that the variables would be placed contiguously in memory. Such an assumption with a high- level language would be unjustified.

START : 0100 MOV CL,CATS 0104 MOV DL,DOGS 0108 ADD CL,DL OlOA MOV PETS.CL # OlOE JMP STAR+ 0110 ADD AX,W[SI] 0112 POP ES

Ax 0000 i 1: b,dogs,, 03 04 07 90 90 90 90 90 90 BX 0000 IP OlOE 2: cx 0007 CS 41D2 3: DX 4103 SS 41D2 4: SI 0100 DS 41D2 5: DI FFFE ES 41D2 6: BP 091C SP FFFE 0:

Figure 4 - Memory windows in the debugger

This method of displaying variables can be contrasted with that used in Sim8086. The

Variables Window shown in

Figure 5 appears if any variables are declared in the assembly language program. 1

Figure 5 - Variables on Sim8086

The Variables Window lists all the variables declared in the program and shows their values. The address of each variable is also shown, as well as the size. The student does not need to do anything at all to obtain this display.

5 Assembly language instructions

6 Single stepping through a program

The debugger, D86, is capable of stepping through an assembly language program one instruction at a time. This mode of running assembly language programs is used frequently in unit CS102. Figure 6 shows how the debugger represents the program when it is running. The # symbol indicates the instruction that is about to be executed. This symbol moves as the student presses

FZ (single step) to step

through the program. At the bottom of the screenshot you can see the registers on the 8086.

START : 0100 MOV CL,CATS 0104 MOV DL,DOGS 0108 ADD CL,DL OlOA MOV PETS,CL # OlOE JMP START 0110 ADD AX,W[SIl 0112 ADD B[BX+SI],AL 0114 ADD B[BX+SII.AL 0116 ADD B[BX+SIj,AL 0118 ADD B[BX+SIl,AL OllA ADD BIBX+SIl.AL OllC ADD BiBX+SIi;AL OllE ADD B[BX+SIl,AL

Ax 0000 i BX 0000 IP OlOE 2: CX 0007 CS 41D2 3: DX 4103 SS 41D2 4: SI 0100 DS 41D2 5: DI FFFE ES 41D2 6: BP 09lC SP FFFE 0:

Figure 6 - Program running under the debugger

The program declares three variables,

dogs, cats and pets. It then proceeds to add together the given values in dogs and cats and store the sum in pets. The whole program is shown below in Figure 7. One of the major difficulties with the debugger as a teaching tool is with its treatment of variables. We have already seen that the student has to request a memory window in order to see the variables that have been declared. The display of the pets program shows another problem.

Underneath the

JNP start instruction, there are three

variable declarations (see Figure 3). However, in Figure 6, we can see that the debugger has attempted to interpret the values in these variables as instructions. The instruction

ADD AX,

W [ SI ] appears nowhere in the program.

Rather, this is the instruction indicated by the two numbers

03 and 04, which are the initial values of the variables

dogs and cats. To exacerbate this problem, as the contents of the variables are changed by the program, so too are the "instructions" which the debugger displays. This phenomenon clearly would not cause a trained programmer any problems. However, the author has seen students in a lab spend half an hour trying to understand what these "instructions" mean and why they change when the program is run. As one student put it, "When the program starts to change, it makes you wonder what else is going to happen when you press FI".

Figure 8 shows Sim8086 running the same program.

Sim8086 does not confuse instructions with data.

Furthermore, because this had become a problem in lab sessions, the

Tuition Window draws students' attention to the

difference between instructions and data. In general the Tuition Window gives the students hints about what to look 326
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29)

1060-3425/96 $10.00 © 1996 IEEE

out for in the lesson. start: MOV CL,cats MOV DL,dogs ADD CL,DL MOV pets,CL JMP start dogs DB 03 cats DB 04 pets DB ?

Figure 7 - The pets program

The

Program Window shows the program the lesson is

based on and which instruction is about to be executed (the highlighted line). The student steps through the program by pressing the large button marked

Single Step. The Variables

Window

shows that pets has now been assigned the value 7. Proceedings of the 29th Annual Hawaii International Conference on System Sciences - 1996

10 Using MSDOS

Sim8086 runs under Microsoft Windows rather than

MSDOS. By the time they encounter Sim8086, the students will be familiar with MS Windows because the CAL system for teaching Modula-2 also runs under MS Windows. Students will eventually have to learn MS-DOS so that they can run the assembler and the debugger, but by then they should understand most of the assembly language they will be using.

Delivery of Sim8086

The development of Sim8086 actually took less time than was originally allocated. There are a number of reasons for this. One simple reason is that the program represents only part of the job. Sim8086 is a tool for demonstrating lessons in assembly language programming. By the end of March

1995, this

tool was installed. However, only a small number of lessons were available. The installation of the program was brought forward by a problem with an example which was first delivered in a lecture. The example was intended to demonstrate the process by which parameters could be passed to subroutines via the stack. This proved to be too difficult for students to grasp in the lecture. The author took the program from the lecture materials, added tuition material in Sim8086 format and then prepared a second lecture using snapshots from Sim8086. As this material was now available, Sim8086 was installed in a "drop-in" lab with this "Parameters" program as the first lesson. The second lecture was more successful than the first and students immediately had the opportunity to reinforce their learning in the lecture with Sim8086.

Figure 8 - Sim8086 running the pets program

7 Creating a program using a text editor

8 Running the assembler

9 Running the debugger

Using Sim8086 defers the learning of these skills. As we have already said, Sim8086 is not designed for running students' own programs. Rather, the student works through lessons prepared by the teacher. The idea is that in the future, students will be introduced to Sim8086 first. Once they have grasped some of the principles of assembly language programming, they will be introduced to the assembler and debugger and to the process of creating programs in files. Another reason for the early finish to the software was the author's rigid adherence to the objectives listed above. While it was tempting to try to add features, this temptation was resisted because of the importance of having a working system ready for the Summer term. In fact, the first working version of Sim8086 was completed on

9th February 1995,

seven days after embarking on the development. Sim8086 features are already identifiable in Figure 9, below, although much of the functionality in the final version is missing.

Economic considerations

It is in the nature of the academic's work that costing individual activities is extremely difficult. In the case of

Sim8086 a cost-benefit analysis would have been

extraordinarily difficult. The actual benefit that accrues to the department would have been impossible to judge on 2nd February and remains extremely difficult to estimate even now. Even judging the amount of effort expended on the 327
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29)

1060-3425/96 $10.00 © 1996 IEEE

system is difficult. More than ninety per-cent of the time spent on the system was outside normal working hours, as the author still had his teaching, supervisory and administrative responsibilities to fulfil. Furthermore, the problems with CS102 meant that the author was spending more time on developing traditional materials for the class. At this moment (early April 1995), the extent to which Sim8086 will help the students in CS102 is unclear. It may be that the students' experiences with Sim8086 as a revision aid will lead to Sim8086 being heavily used in teaching in years to come. Alternatively, if the experiment with this year's students fails, perhaps there will be no future for

Sim8086.

Figure 9 - The first version of Sim8086

The foregoing suggests that the development of a CAL system can be in the nature of a gamble. This is not as serious as it seems, as academics traditionally have a great deal of autonomy in their work. At the start of the work on Sim8086, the author did not need to gain approval for the development. At no time during the two months did any other member of staff question the need for Sim8086. This freedom to act without the specific approval of management represents both an opportunity and a challenge to the diligent academic. This section of the paper assesses some of the economic issues that face the developer of CAL software.

Obtaining resources for CAL development

Shortly before Christmas 1994, the author was asked to provide a l2-hour elective (unit of study) for an individual student. Normally, such a request would be turned down, as the amount of staff time involved cannot be justified for just one student. However, on this occasion, the author intended to use the student's work to support the development of a simple system for testing students' knowledge of Boolean Algebra. As circumstances developed after Christmas, the work on that system was shelved in favour of Sim8086. The nature of the work was to test and document Sim8086 and to Proceedings of the 29th Annual Hawaii International Conference on System Sciences - 1996 write some of the introductory lesson material. Clearly, there was some risk that this student's work would not be of sufficient standard to contribute significantly to the project. Had the student's work not been useful, the author would have lost out on the arrangement; not only would he have had to write the documentation himself, he would also have spent the time setting and marking assignments for the elective. While it is tempting to see the student as a free resource, there is a potential hidden cost in attempting to use students (especially first year students) in this way. How can the diligent academic assess the level of risk in such an arrangement? This question was actually considered by the author when the need for Sim8086 arose. The solution that we tentatively propose can be related to the notion of criterion referencing in setting student assignments. It would have been possible to give the student a set of standards which his work would have to meet. The standards would be set so that passing the assignment meant producing something that was useful. However, in this case, the author judged that it should be possible for the student to pass the elective, even if his work was not good enough to be incorporated into the delivered system. It would have been unfair to insist that a first year student to produce work of this quality in order to gain credit for the work undertaken; especially since no actual teaching was being offered in support of the elective. Therefore, the elective that was negotiated with the student had to be treated by the author purely as a risk insofar as it concerned the development of Sim8086. The author's experience with this arrangement has led to some development in the thinking about the role that students can play in the development of a system like Sim8086. However, other factors must be taken into account when attempting to involve students on a CAL system development. Once again, we will use Sim8086 as a case study in considering some of these issues. We will first review some of the possible future developments for

Sim8086.

Expansion plans for Sim8086

As has been related, Sim8086 was developed against the background of a set of rigid objectives; a proposed modification to the system was measured against these objectives and if it did not contribute to meeting one or more, was rejected out of hand. This approach was imperative because of the tight deadline that was set. Nevertheless, the author has considered a number of possible future developments for Sim8086: Syntax/semantics checking. At present, Sim8086 does not undertake a full syntactic or semantic check of the lesson programs. For this reason, no lesson is incorporated until it 328
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29)

1060-3425/96 $10.00 © 1996 IEEE

can be successfully assembled by the assembler (A86). If however, Sims086 did check programs properly, it would be possible for students to use it for running their own programs, without recourse to the debugger. Given the fundamental aim for Sim8086, namely to reduce the number of things the student needs to learn, this would undoubtedly be an extremely useful facility.

Segmented memory. At present, Sim8086 implements

a memory system that covers only one segment of 64 kilobytes of RAM. The 8086 can actually access 1 megabyte of RAM. The 8086 does this by means of its segmented memory architecture. At present, the author has no intention of explaining this scheme to students, except in the consideration of interrupts. However, students will not be required to write programs for handling interrupts. Therefore, this facility, while potentially useful, is not considered essential. Progress monitoring. Sim8086 allows the teacher to write tuition material which is presented to the student as s/he steps through the lesson programs. It would be possible to incorporate progress monitoring if the student could be constrained to answer questions before s/he were allowed to make progress through the material. While this approach is not foolproof, there are significant advantages to be gained. At present, Sim8086 is proposed as a revision aid. If it is successful in this role, it will be introduced as the platform for independent student study; material presented in lectures and supervised labs will also be available in lesson form on Sim8086. The student will be able to use the system whenever s/he has free time. This scheme is flexible and, if Sim8086 is successful, likely to be useful. However, Sim8086 could potentially achieve much more. Sim8086 could form the basis for a form of continuous assessment. A certain proportion of the marks available for the unit could be awarded for making satisfactory progress with Sim8086. Alternatively, Sim8086 could be used to support some of the supervised lab time, With CLEM, the Modula-2 CAL system, labs are supervised by research students or Ipart-time staff, which frees up time for permanent academic staff. Undo facility. Sim8086 allows the student to select a particular line in a program and start execution from that point. While for some lessons this facility is a powerful aid to the student, for some other lessons, this facility might cause extreme confusion. A typical example is operations on the stack. If the student executes a PUSH instruction and feels s/he has not quite understood what has happened, moving back to the instruction and executing it again may cause problems later, as there will be one extraneous value on the stack. Such a situation could be averted if an undo facility was provided. The student would effectively be able Proceedings of the 29th Annual Hawaii International Conference on System Sciences - 1996 to step backwards as well as forwards through the lesson program. The author has not even begun to consider what the implications of attempting to implement such a facility might be, although it is easy to see that it could be useful.

Opportunistic use of students in developing

CAL software

Having completed the first phase of Sim8086's

development, there is a possibility that the author will be able to make reasonably certain judgements about cost of the proposed improvements and the amount of benefit that might be obtained from if one or more were implemented. However, without the urgency of the situation with CS102 in January 1995, it may be more difficult to justify spending the time on continuing the development of Sim8086. Nevertheless, the availability of final year BSc students and

MSc students means that such developments

can be attempted, although the difficulties with attempting to use students in this role are many: Student choice. Students may not wish to do this sort of work for their projects. At the moment, students choose what they want to do for their projects. This is unlikely to change, so there will always be an element of risk in attempting to use students in this way. Student ability. A student who embarks on a project may not be capable of finishing it satisfactorily. There is not really any scope for demanding that a student finish the job or fail his/her project; quite apart from the fact that this would be unethical, there is still no guarantee that this would achieve the desired result. Timing. Undergraduate and (to a large extent) Masters projects start at fixed times and have fixed durations. If the development does not fall within these periods, clearly there is no chance of using a student project. Academic content. Academic projects are not the same as development projects. The project unit on the Modular Scheme requires a large element of "academic content". In the past, when students proposed their own projects, it normally fell to the Supervisor or the Projects Tutor to suggest how the requisite academic content could be incorporated. However, in the proposals for developing Sim8086 which are suggested above, there is little scope for academic content to be added. This particular problem opens up the issue of design in developing CAL software. Sim8086 was developed using a prototyping approach (see eg Smith [3], Sommerville [4] or Ramsden [5]) and was written in Visual Basic [5]. Little thought was given to the 329
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29)

1060-3425/96 $10.00 © 1996 IEEE

Proceedings of the 29th Annual Hawaii International Conference on System Sciences - I996 sofmare design because of the urgency of the problem (the design and layout of the screen was given much more attention). Had the author had more time, it is quite possible that the design of the software could have incorporated the prospect of future work on the project being undertaken by students doing academic projects. For example, another approach to displaying the tuition material would have been to adopt an existing standard such as MS Windows help system format or HTML. These two hypertext-based systems could have offered the possibility of linking lessons back to material presented in lectures and in other supervised sessions. As a student project this would have been more promising as it offers scope for an evaluation of the rival hypertext systems, and the possibility for the system to identify weaknesses in individual students and to direct students to additional material which might help. In cases where additional material is not available, the system could warn the teacher that a particular student is weak in a particular area. Several such warnings about different students would allow the teacher to prepare supplementary materials or to look at the problem area in supervised lab sessions. Naturally, most of this sort of understanding comes from actually developing a system and then seeing what its deficiencies are. This is, of course, the essence of the prototyping approach to software development. Therefore, despite the fact that the foregoing discussion about the presentation of tuition in Sim8086 implies that time has been wasted on producing a limited design, the author still has the opportunity to supervise a student to continue this work.

The element of risk

The foregoing discussion demonstrates that attempting to use students for supporting the development of CAL software is by nature problematical. In situations where a firm deadline has been set, an academic with a particular problem in mind might be forced to do the work for herself. Nevertheless, as a departmental approach to systems that are not urgently required, the use of student projects offers a great deal of promise. Of the approximately one hundred projects offered by members of staff to final year students, fifteen per cent are projects that involve the production of CAL software which could be used to support teaching in the Department of Computing. Other projects aim to develop software that could support teaching in other departments or institutions. (A previous example of this is reported in Brindle et al [6]). It should be said that this strategy was not envisaged when the projects list was first conceived. However, the author (in his role as Projects Tutor) did encourage staff to consider projects that could, if successful, help them in their teaching or contribute to research. The

prospect of developing a system that might be useful helped to ensure that there was a good response to the call for

projects. The lesson for the diligent academic is that students can represent an untapped resource in the development of CAL software. Even where formal projects are not suitable, ad hoc arrangements may be possible. It is vital that academics make full use of all the resources available in order to achieve significant benefits from the development of CAL systems.

Conclusions

Sim8086 was delivered on time and has potential as a learning aid to be used alongside more traditional teaching methods. The exact impact that Sim8086 will make remains to be seen. The evaluation of the system will continue through the next academic year. Meanwhile, one or more students will be asked to make modifications to the software as part of their undergraduate or Masters' projects. We make no claim that the process by which Sim8086 was developed represents a normative ideal. Rather, we hope that some of the ideas that we advance in this paper will be considered by other practitioners in this field. The firm conclusions that can be drawn are:

1. Prototyping with tools such as Visual Basic or

Delphi has great potential for developing CAL

software.

2. Undergraduate students can make a positive

contribution to the development of CAL software.

3. Where appropriate, the notion of criterion referencing

may be useful when trying to use students in this way. However, this issue raises significant ethical questions.

4. Devoting time to developing CAL software will

always represent a risk.

5. The risk can be reduced if the developer sticks

rigidly to a set of aims and objectives, which should be established at the start of a project.

References

1. Boyle T, Gray J, Wend1 B and Davies M, Taking the

plunge with CLEM: the design and evaluation of a large scale CAL system. Computers in Education vol 22, No l/2, pp 19-26 (1994)

2. Semb G B, Ellis J A, Montague W E, Wulfeck W H,

Self-Paced Instruction: Perceptions, Pitfalls, and

Potentials. In Problems and promises

of Computer Based Training (Edited by Schlechter TM). Ablex Publishing

Corporation (199 1)

330
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29)

1060-3425/96 $10.00 © 1996 IEEE

Proceedings of the 29th Annual Hawaii International Conference on System Sciences - 1996

3. Smith M F, Sojbvare Prototyping. McGraw-Hill (1991)

4. Sommerville I, Software Engineering. Addison-Wesley

(1992)

5. Ramsden S G, Visual Basic as the development

environment for prototyping in MS-Windows, A4Sc Report, Manchester Metropolitan University (1994)

6. Brindle G, Mitchell W, Seal L, Bohme K, A virtual

laboratory system for physiology teaching. ALT-J: Association for Learning Technology Journal vol 3, No

1 (1994)

331
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29)

1060-3425/96 $10.00 © 1996 IEEE