- Email: [email protected]
A methodology for developing computer-based teaching programs
Compttt. tic. Vol. 10, No. 3, pp. 347-352. Printed in Great Britam
A METHODOLOGY
0360-1315/86
1986
53.00+0.00
PergamonJournalsLtd
FOR DEVELOPING COMPUTER-BASED TEACHING PROGRAMS*
R. F. Howns and D. 0. WILLIAMS Computer-Based Teaching Project, Engineering Department, Information Engineering Division, Cambridge University, Cambridge CB2 lPZ, England (Received 3 December 1985) Abstract-As
the use of computers in higher education increases so the institutions concerned are recognising the need to use methods which will produce teaching programs on schedule and to pre-defined standards. At the Cambridge University Engineering Department a set of processes have been adapted to form a complete development methodology which is particularly relevant to teaching programs. Six months of practical experience in the use of the methodology has now been accumulated and this has been favourable. Further work will be carried out to evaluate the effectiveness of the teaching programs developed.
1. INTRODUCTION
1.1 The need The use of computer-based teaching is now expanding quite rapidly in higher education and in some institutions it is a formal part of the teaching process. One consequence of this change for the institutions concerned is that the production of teaching programs must be put on to a formal and regular basis which will ensure that programs are available at the required time and are produced to agreed standards of quality and usability. This paper describes the methodology in use at the Cambridge University Engineering Department for the production of teaching programs. In many institutions the production of teaching programs has been carried on hitherto by members of the teaching staff who are sufficiently enthusiastic about computing to invest the necessary time and effort. This has, of necessity, been a “spare time” activity and not suitable for producing the volume of programs which are now required. The programs developed in this way have also, in the experience of the authors, shown a great deal of inventiveness and imagination but they are not usually reliable and robust programs suitable for use by a large group of students. In order to deal with these problems many institutions now employ full time programming staff. This means that at least two people (the teacher and the programmer) and frequently more, become involved in the production of any one teaching application. With a number of people involved in the production process a defined methodology is of critical importance in ensuring the timeliness and quality of the programs produced. 1.2 The CUED project At the Engineering Department in Cambridge a major project on the production of computerbased teaching software was begun in mid- 1984. This Project was made possible by an annual grant by IBM for the employment and support of four professional programmer/analysts. IBM also seconded to the Project a manager with experience of software development. One of the first tasks which the programming team undertook was the definition of an appropriate methodology. This methodology had to cover the development process from the specification of requirements through to a post implementation review. It had to describe the process, the techniques to be used in completing it and the responsibilities of the participants. On adapting a methodology for the production of computer programs the environment in which the program will be used must first be considered. The combination of characteristics which lOriginally presented at the University of Cambridge Engineering Department Workshop on Computer Based Teaching, 11-12 September, 1985. 347
348
R. F. HOWES and D. 0. WILLIAMS
differentiates between the educational environment and most of the others is seen to be as follows: (i) the applications will generally be used once only by an individual but there will be a comparatively large population of users-this indicates that the programs must have a man-machine interface which is easy to use; (ii) it is not possible to involve the real end user (student) in the design process; (iii) most programs have a large computational component; (iv) frequently the program must satisfy the requirements of a number of teaching staff who are all concerned with a particular lecture course. The methodology was designed by one member of the Project team and was published in a CUED Report [l]. 2. GOALS
OF THE
METHODOLOGY
The production of the software development methodology has been guided by the seven goals defined by Wasserman [2] and these have been adapted as follows to satisfy the requirements above: User involuement-The methodology should involve the teaching staff who initiate the program in the development process, particularly in the early stages. Functionality-The methodology should cover the entire development process, resulting in the creation of a package which consists of a program and supporting documentation that meets a pre-defined set of requirements. Reliability-Tht methodology should support the production of reliable and robust programs. Usability-The methodology should help the developer to ensure, as early as possible, that the resulting package will be easy to use. Evolvabilify-The methodology should encourage documentation and package structuring, so that the resulting package is easily modifiable and able to accommodate changes in hardware operating environments and user needs. Automated support-The methodology should be supportable by automated tools that improve the productivity of team members developing a package. Re-usability-The methodology should be general and parts of the designs produced for a given application should be reusable in other similar projects.
3. ACTIVITIES INVOLVED IN THE PROGRAM DEVELOPMENT METHODOLOGY
The activities that constitute the program devleopment methodology are shown in Fig. 1. These start when a teaching program is requested by a member of staff and conclude with the presentation of the fully tested and documented teaching program. An overview of these activities follows. SpeciJication of teaching requirements-Once the development of a teaching program has been undertaken it will be necessary for the programmer/analyst to become rapidly aware of the teaching requirements. To this end it is suggested that these requirements be presented in the standard format given in Ref. [l]. Consolidation and development of requirements -Having received a request for a teaching package, a team is formed to work on it. The make up of the team differs depending on the requirements of each package but the nucleus is the member of teaching staff and one programmer/analyst. The first job of the team is to consolidate the requirements of the teaching staff. During this phase the CBT Project member will have to acquire enough subject information to allow him to understand the objectives of the lecturer. He can then establish the lecturer’s exact requirements. At this stage it is important for discussions to concentrate on “what is wanted” rather than on “how it is to be implemented”. To avoid confusion over the meaning of terms used in a program, a database is assembled by the project team using a standard form [l]. This includes definitions of technical terms and terms used on graphical representations of program structure. Teaching staff requirements are usually expressed in terms of inputs to, and outputs from, a computer program which together fulfil some objective. The development of a program will start by considering what processes are required to produce the outputs from the inputs. To develop
Developing computer-based
349
teaching programs
computatlonol corflpol-e”ts
Consohdation and development of requirements
ACTIVITIES PROGRAM
INVOLVED
IN
DEVELOPMENT
document \
THE
METHODOLOGY P
revi*w
of the
detail dcrtgn Of the proprom
Implaatorion and tosling of modules
Legend
0 0
Humm
operation Humancompunr op3ratlon
Fig. 1
a program these processes need to be linked together into a network which will represent the top level structure of the program design. To aid communication on the form of this network, a graphical representation is needed. Such a tool is useful as it represents the links in a spatial form which is understood more quickly than textual forms. This representational form also provides a framework for discussions, so that a part of the program being considered can be identified by reference to an area on a diagram. It is also true that the process of producing a diagram of the program structure will help to show up areas that need further definition. A graphical notation (the Hartson notation [3]) has been chosen that is used throughout the program life cycle. An example of a top level program structure represented using the Hartson notation is shown in Fig. 2. Legemd EXAMPLE A TOP
LEVEL
OF STRUCTURE
Seepage Pockw -.
/’ /
/’
/j’
-.
Dtologuecomputation fuv3lul
I
I *-\ .,’
Supervisory dtologuc f&tlon
I- -7 :__;
Sup+xvlsory computotlonol
‘\
superviswy . .
-
. .
-0’
‘\
,’
‘.
_/’
.>.
/’
-.
I’
Flow of data
0
Dsclslon
..
-\ -\
/’
//’
‘.
‘. ‘.
RESTART>
Geometry + poperties _ ~,_____----_‘---~_____-_____----~_____-_-
, I ’
‘-,
I
L
Input geollletry + properties
+;;oz:
1--J
rn!p::$$y&ANS,EQ
Ex
I ---.: Produce mesh
Calculate potentmfs 01 mesh points
Fig. 2
Dbplay reslJlts
function
Flow of control
-*
/’
function
Returncontrolto
a
/’
,x’
tzl
\
350
R. F. HOWES and D. 0. WILLIAMS
Instead of continuing using a top down design technique, this methodology proceeds developing the dialogue (input/output processes) first. The main reasons for doing this are:
by
(a) the dialogue is examined at an early stage to see if the teaching requirements (often specified in terms of inputs and outputs) will be fully met by the program; (b) it allows a demonstration of the dialogue to be produced and then reviewed by teaching staff before programming effort has been spent on the computational component. This often “firms up” ideas on exactly what the requirements are and often leads to changes in the requirements of the numerical software. In order to develop the dialogue and produce a demonstration of it before implementing the computational components, the top level program structure is refined until only purely computational and purely dialogue parts remain. A program developed in this way is said to exhibit the property of dialogue independence. The design of a program therefore continues by splitting up any processes in the top level structure that perform both computational and dialogue functions into sub-functions. This is repeated until only purely dialogue or purely computational functions remain. This more detailed network is also represented using the Hartson notation (for an example see Fig. 3) and is termed the behavioural structure of the program. Production and review of proposal-The refined structure of the program, split into dialogue and computational parts, defines the function of the program as viewed by the user, This structure, represented graphically with the terms used on it fully defined, expresses formally what the package will consist of. This is incorporated into a proposal defining the program to be produced and this is then reviewed with the teaching staff involved. Production and review of dialogue demonstration-After agreeing that the information in the proposal is correct and complete the next step is to produce the demonstration of the dialogue. To do this each dialogue component is analysed and divided step by step into its component parts until a level is reached where each module contains only one dialogue event, i.e. a module that performs one input or output. The screen formats for each of these events are then designed in accordance with the Human Interface guidelines adopted by the Project team [4]. This dialogue structure does not include details such as error paths at this stage as the purpose of the dialogue demonstration is to allow viewing of a dynamic model of the main dialogues. The dialogue components, together with enough of the program structure to allow a demonstration of the full dialogue, are then implemented. As the computational components have not been devised at this stage it may mean that diagrams and results will have to be produced by hand. Once produced the dialogue demonstration is reviewed by all those concerned with the package. This is very beneficial for “firming-up” the requirements of the package. Design of computational components-The requirements for the computational components of the program are now fully defined and the design of these parts is produced. The end product of this stage will be a hierarchy of modules, the lower level of which will consist of computational blocks. These blocks can be defined as those that perform discrete functions for which software exists or which can be pragrammed in one small module, typically less than one page of code. It is expected that the processes involved in numerical software are defined fully by teaching staff. Production and review of program requirements document-At this stage an assessment should be made of whether the design of the dialogue and computational components of the package meet the teaching requirements. This is done before the detail design begins as effort could be wasted on detail designs that are not required. Production and review of the detail design of the program-To complete the design process all that remains is the detail design of the dialogue and computational parts for which no software exists. The detail design should be specified using the Hartson notation. If the implementation is to be performed by external programmers the detail design will be reviewed and this is done by structured walk-throughs. If the programming is done by the project team member a review of the detail design is not necessary. Implementation and testing of modules-The next step is implementing the design. Before this commences however, tests for each module are devised and in addition an implementation plan is produced. This should follow in general a top-down incremental approach, but problem modules,
Developing computer-based EXAMPLE BEHAVIORAL
351
teaching programs OF
STRUCTURE
Seepoge pockope
.’ .’
ga
r*
..
/’
*.
. .
. .
__
He’
.*
. .
. .
. .
_.
NC
//’ /’ ./
: 1
‘-/
i
*.
RESTART>
ANS I-
2.
/ .0’
‘---, ,
‘\ /
;*
Input geometry + propertles
I L---d
I
J[_I]
t
~J,
I ! Calculate potentiols ot mesh points
Produce mesh
/ I
/
/
\
,‘Dirploy results
\ ‘,
,’
\ \
I/’
\
\
/’ /
,
,
/’
\
\ \ \
/’
/
/
/
/
/
/’
t
ANS, A, /
r---7
/
\
‘\
~-&-&czzU,
Calculate equipotentiols + flow lines
equipatentiols + flow lines
\
\
NH’
/‘ /’
Colculote potent101 ot poht
Get point location
\
II‘~~
I
I
_-e-d
\
4
I
I
\ \
CANS. EO.EXIT>
I
\
Calculate ‘1 + display heod ‘\ \ at point
\
Display volue of potential
Fig. 3
or ones upon which the success of the package depends, should be isolated and implemented at an early stage. The dialogue modules already implemented for the dialogue demonstration will be incorporated at this time. As each module is implemented it is tested using the part of the package that has already been produced as a test harness. When the last module is added the package is then fully tested. System tesring-To ensure that the package produced is reliable and usable, it is thoroughly tested. The testing process should therefore include tests by programmer analysts, members of teaching staff and a selection of volunteers from the pool of expected users (students). Handover andpost implementation review-When the program has been tested to the satisfaction of the person requesting it, then the compiled code is handed over to the Computer Manager, together with a short description of the program for use in the on-line help library. When handover has been made feedback processes are agreed both for maintenance and helpful observations. At
352
R. F. HOWESand D. 0. WILLIAMS
this time all the documentation produced in the program development process is filed in the Project library. A post implementation review meeting is held between the teaching staff and the development staff after the package has been in use for some time. The purpose of the meeting is to review the use made of the package and any lessons that have been learned from the program. 4. EXPERIENCE
The methodology described in this paper has now been in use at the CUED for approximately six months and during that time it has been used in the production of a number of large teaching packages. The packages have been delivered on the agreed schedule and the staff concerned have assessed that the packages meet their requirements and are easy to use. Most of the packages will not go into full teaching use until October 1985 and so little student feedback is available. The Project and teaching staff have found that the methodology encourages a team approach, so that the teaching staff are involved throughout the development process. This is of vital importance in ensuring that the finished package meets the teaching requirements. The methodology has been found to be very easy to use and valuable in controlling a project. Probably the most valuable aspect is the production of a dialogue demonstration which is virtually a prototype of the program, very early on in the project cycle. On a number of occasions this demonstration has led to real in-depth discussions between team members on the best structure of the program at a time when that structure can be changed with relative ease. Without these dialogue demonstrations the discussions would not have taken place until the program was complete and would consequently have been very difficult and costly, in terms of effort, to change. Team members have also found that this demonstration lets them ensure at an early stage that students will find the resulting package easy to use. Also of great importance in this methodology is the concept of producing a program structure that has separate dialogue and computational components. This dialogue independence is not only vital for the creation of a dialogue demonstration but also produces packages that are easily modifiable and able to accommodate changes in hardware operating environments. As the resulting structure is also highly modular many of the components produced can be used on other similar projects. In conclusion, the production of teaching programs at the CUED continues to be costly in terms of programmer/analyst effort but the adoption of the methodology described in this document has improved the productivity and predictability of the process. However work remains to be done, particularly in the area of evaluating the achievement of teaching objectives. The methodology will be kept under review in the CUED and changes will be made, if required, to respond to the needs of the Teaching Project. REFERENCES 1. Williams D. O., Program development methodology. Report, Cambridge University Engineering Department (1985). 2. Wasserman A. I., Developing interactive information systems with User Software Engineering Methodology. INTERACT ‘84 Conference Papers (1984). 3. Hartson H. R. and Yunten T., A supervisory methodology and notation (SUPERMAN) for human-computer system development. Advances in Human-Compurer Interaction. Ablex (1984). 4. Featherstone G., Human-computer interface guidelines, Report, Cambridge University Engineering Department (1985).
A METHODOLOGY
0360-1315/86
1986
53.00+0.00
PergamonJournalsLtd
FOR DEVELOPING COMPUTER-BASED TEACHING PROGRAMS*
R. F. Howns and D. 0. WILLIAMS Computer-Based Teaching Project, Engineering Department, Information Engineering Division, Cambridge University, Cambridge CB2 lPZ, England (Received 3 December 1985) Abstract-As
the use of computers in higher education increases so the institutions concerned are recognising the need to use methods which will produce teaching programs on schedule and to pre-defined standards. At the Cambridge University Engineering Department a set of processes have been adapted to form a complete development methodology which is particularly relevant to teaching programs. Six months of practical experience in the use of the methodology has now been accumulated and this has been favourable. Further work will be carried out to evaluate the effectiveness of the teaching programs developed.
1. INTRODUCTION
1.1 The need The use of computer-based teaching is now expanding quite rapidly in higher education and in some institutions it is a formal part of the teaching process. One consequence of this change for the institutions concerned is that the production of teaching programs must be put on to a formal and regular basis which will ensure that programs are available at the required time and are produced to agreed standards of quality and usability. This paper describes the methodology in use at the Cambridge University Engineering Department for the production of teaching programs. In many institutions the production of teaching programs has been carried on hitherto by members of the teaching staff who are sufficiently enthusiastic about computing to invest the necessary time and effort. This has, of necessity, been a “spare time” activity and not suitable for producing the volume of programs which are now required. The programs developed in this way have also, in the experience of the authors, shown a great deal of inventiveness and imagination but they are not usually reliable and robust programs suitable for use by a large group of students. In order to deal with these problems many institutions now employ full time programming staff. This means that at least two people (the teacher and the programmer) and frequently more, become involved in the production of any one teaching application. With a number of people involved in the production process a defined methodology is of critical importance in ensuring the timeliness and quality of the programs produced. 1.2 The CUED project At the Engineering Department in Cambridge a major project on the production of computerbased teaching software was begun in mid- 1984. This Project was made possible by an annual grant by IBM for the employment and support of four professional programmer/analysts. IBM also seconded to the Project a manager with experience of software development. One of the first tasks which the programming team undertook was the definition of an appropriate methodology. This methodology had to cover the development process from the specification of requirements through to a post implementation review. It had to describe the process, the techniques to be used in completing it and the responsibilities of the participants. On adapting a methodology for the production of computer programs the environment in which the program will be used must first be considered. The combination of characteristics which lOriginally presented at the University of Cambridge Engineering Department Workshop on Computer Based Teaching, 11-12 September, 1985. 347
348
R. F. HOWES and D. 0. WILLIAMS
differentiates between the educational environment and most of the others is seen to be as follows: (i) the applications will generally be used once only by an individual but there will be a comparatively large population of users-this indicates that the programs must have a man-machine interface which is easy to use; (ii) it is not possible to involve the real end user (student) in the design process; (iii) most programs have a large computational component; (iv) frequently the program must satisfy the requirements of a number of teaching staff who are all concerned with a particular lecture course. The methodology was designed by one member of the Project team and was published in a CUED Report [l]. 2. GOALS
OF THE
METHODOLOGY
The production of the software development methodology has been guided by the seven goals defined by Wasserman [2] and these have been adapted as follows to satisfy the requirements above: User involuement-The methodology should involve the teaching staff who initiate the program in the development process, particularly in the early stages. Functionality-The methodology should cover the entire development process, resulting in the creation of a package which consists of a program and supporting documentation that meets a pre-defined set of requirements. Reliability-Tht methodology should support the production of reliable and robust programs. Usability-The methodology should help the developer to ensure, as early as possible, that the resulting package will be easy to use. Evolvabilify-The methodology should encourage documentation and package structuring, so that the resulting package is easily modifiable and able to accommodate changes in hardware operating environments and user needs. Automated support-The methodology should be supportable by automated tools that improve the productivity of team members developing a package. Re-usability-The methodology should be general and parts of the designs produced for a given application should be reusable in other similar projects.
3. ACTIVITIES INVOLVED IN THE PROGRAM DEVELOPMENT METHODOLOGY
The activities that constitute the program devleopment methodology are shown in Fig. 1. These start when a teaching program is requested by a member of staff and conclude with the presentation of the fully tested and documented teaching program. An overview of these activities follows. SpeciJication of teaching requirements-Once the development of a teaching program has been undertaken it will be necessary for the programmer/analyst to become rapidly aware of the teaching requirements. To this end it is suggested that these requirements be presented in the standard format given in Ref. [l]. Consolidation and development of requirements -Having received a request for a teaching package, a team is formed to work on it. The make up of the team differs depending on the requirements of each package but the nucleus is the member of teaching staff and one programmer/analyst. The first job of the team is to consolidate the requirements of the teaching staff. During this phase the CBT Project member will have to acquire enough subject information to allow him to understand the objectives of the lecturer. He can then establish the lecturer’s exact requirements. At this stage it is important for discussions to concentrate on “what is wanted” rather than on “how it is to be implemented”. To avoid confusion over the meaning of terms used in a program, a database is assembled by the project team using a standard form [l]. This includes definitions of technical terms and terms used on graphical representations of program structure. Teaching staff requirements are usually expressed in terms of inputs to, and outputs from, a computer program which together fulfil some objective. The development of a program will start by considering what processes are required to produce the outputs from the inputs. To develop
Developing computer-based
349
teaching programs
computatlonol corflpol-e”ts
Consohdation and development of requirements
ACTIVITIES PROGRAM
INVOLVED
IN
DEVELOPMENT
document \
THE
METHODOLOGY P
revi*w
of the
detail dcrtgn Of the proprom
Implaatorion and tosling of modules
Legend
0 0
Humm
operation Humancompunr op3ratlon
Fig. 1
a program these processes need to be linked together into a network which will represent the top level structure of the program design. To aid communication on the form of this network, a graphical representation is needed. Such a tool is useful as it represents the links in a spatial form which is understood more quickly than textual forms. This representational form also provides a framework for discussions, so that a part of the program being considered can be identified by reference to an area on a diagram. It is also true that the process of producing a diagram of the program structure will help to show up areas that need further definition. A graphical notation (the Hartson notation [3]) has been chosen that is used throughout the program life cycle. An example of a top level program structure represented using the Hartson notation is shown in Fig. 2. Legemd EXAMPLE A TOP
LEVEL
OF STRUCTURE
Seepage Pockw -.
/’ /
/’
/j’
-.
Dtologuecomputation fuv3lul
I
I *-\ .,’
Supervisory dtologuc f&tlon
I- -7 :__;
Sup+xvlsory computotlonol
‘\
superviswy . .
-
. .
-0’
‘\
,’
‘.
_/’
.>.
/’
-.
I’
Flow of data
0
Dsclslon
..
-\ -\
/’
//’
‘.
‘. ‘.
RESTART>
Geometry + poperties _ ~,_____----_‘---~_____-_____----~_____-_-
, I ’
‘-,
I
L
Input geollletry + properties
+;;oz:
1--J
rn!p::$$y&ANS,EQ
Ex
I ---.: Produce mesh
Calculate potentmfs 01 mesh points
Fig. 2
Dbplay reslJlts
function
Flow of control
-*
/’
function
Returncontrolto
a
/’
,x’
tzl
\
350
R. F. HOWES and D. 0. WILLIAMS
Instead of continuing using a top down design technique, this methodology proceeds developing the dialogue (input/output processes) first. The main reasons for doing this are:
by
(a) the dialogue is examined at an early stage to see if the teaching requirements (often specified in terms of inputs and outputs) will be fully met by the program; (b) it allows a demonstration of the dialogue to be produced and then reviewed by teaching staff before programming effort has been spent on the computational component. This often “firms up” ideas on exactly what the requirements are and often leads to changes in the requirements of the numerical software. In order to develop the dialogue and produce a demonstration of it before implementing the computational components, the top level program structure is refined until only purely computational and purely dialogue parts remain. A program developed in this way is said to exhibit the property of dialogue independence. The design of a program therefore continues by splitting up any processes in the top level structure that perform both computational and dialogue functions into sub-functions. This is repeated until only purely dialogue or purely computational functions remain. This more detailed network is also represented using the Hartson notation (for an example see Fig. 3) and is termed the behavioural structure of the program. Production and review of proposal-The refined structure of the program, split into dialogue and computational parts, defines the function of the program as viewed by the user, This structure, represented graphically with the terms used on it fully defined, expresses formally what the package will consist of. This is incorporated into a proposal defining the program to be produced and this is then reviewed with the teaching staff involved. Production and review of dialogue demonstration-After agreeing that the information in the proposal is correct and complete the next step is to produce the demonstration of the dialogue. To do this each dialogue component is analysed and divided step by step into its component parts until a level is reached where each module contains only one dialogue event, i.e. a module that performs one input or output. The screen formats for each of these events are then designed in accordance with the Human Interface guidelines adopted by the Project team [4]. This dialogue structure does not include details such as error paths at this stage as the purpose of the dialogue demonstration is to allow viewing of a dynamic model of the main dialogues. The dialogue components, together with enough of the program structure to allow a demonstration of the full dialogue, are then implemented. As the computational components have not been devised at this stage it may mean that diagrams and results will have to be produced by hand. Once produced the dialogue demonstration is reviewed by all those concerned with the package. This is very beneficial for “firming-up” the requirements of the package. Design of computational components-The requirements for the computational components of the program are now fully defined and the design of these parts is produced. The end product of this stage will be a hierarchy of modules, the lower level of which will consist of computational blocks. These blocks can be defined as those that perform discrete functions for which software exists or which can be pragrammed in one small module, typically less than one page of code. It is expected that the processes involved in numerical software are defined fully by teaching staff. Production and review of program requirements document-At this stage an assessment should be made of whether the design of the dialogue and computational components of the package meet the teaching requirements. This is done before the detail design begins as effort could be wasted on detail designs that are not required. Production and review of the detail design of the program-To complete the design process all that remains is the detail design of the dialogue and computational parts for which no software exists. The detail design should be specified using the Hartson notation. If the implementation is to be performed by external programmers the detail design will be reviewed and this is done by structured walk-throughs. If the programming is done by the project team member a review of the detail design is not necessary. Implementation and testing of modules-The next step is implementing the design. Before this commences however, tests for each module are devised and in addition an implementation plan is produced. This should follow in general a top-down incremental approach, but problem modules,
Developing computer-based EXAMPLE BEHAVIORAL
351
teaching programs OF
STRUCTURE
Seepoge pockope
.’ .’
ga
r*
..
/’
*.
. .
. .
__
He’
.*
. .
. .
. .
_.
NC
//’ /’ ./
: 1
‘-/
i
*.
RESTART>
ANS I-
2.
/ .0’
‘---, ,
‘\ /
;*
Input geometry + propertles
I L---d
I
J[_I]
t
~J,
I ! Calculate potentiols ot mesh points
Produce mesh
/ I
/
/
\
,‘Dirploy results
\ ‘,
,’
\ \
I/’
\
\
/’ /
,
,
/’
\
\ \ \
/’
/
/
/
/
/
/’
t
ANS, A, /
r---7
/
\
‘\
~-&-&czzU,
Calculate equipotentiols + flow lines
equipatentiols + flow lines
\
\
NH’
/‘ /’
Colculote potent101 ot poht
Get point location
\
II‘
I
I
_-e-d
\
4
I
I
\ \
CANS. EO.EXIT>
I
\
Calculate ‘1 + display heod ‘\ \ at point
\
Display volue of potential
Fig. 3
or ones upon which the success of the package depends, should be isolated and implemented at an early stage. The dialogue modules already implemented for the dialogue demonstration will be incorporated at this time. As each module is implemented it is tested using the part of the package that has already been produced as a test harness. When the last module is added the package is then fully tested. System tesring-To ensure that the package produced is reliable and usable, it is thoroughly tested. The testing process should therefore include tests by programmer analysts, members of teaching staff and a selection of volunteers from the pool of expected users (students). Handover andpost implementation review-When the program has been tested to the satisfaction of the person requesting it, then the compiled code is handed over to the Computer Manager, together with a short description of the program for use in the on-line help library. When handover has been made feedback processes are agreed both for maintenance and helpful observations. At
352
R. F. HOWESand D. 0. WILLIAMS
this time all the documentation produced in the program development process is filed in the Project library. A post implementation review meeting is held between the teaching staff and the development staff after the package has been in use for some time. The purpose of the meeting is to review the use made of the package and any lessons that have been learned from the program. 4. EXPERIENCE
The methodology described in this paper has now been in use at the CUED for approximately six months and during that time it has been used in the production of a number of large teaching packages. The packages have been delivered on the agreed schedule and the staff concerned have assessed that the packages meet their requirements and are easy to use. Most of the packages will not go into full teaching use until October 1985 and so little student feedback is available. The Project and teaching staff have found that the methodology encourages a team approach, so that the teaching staff are involved throughout the development process. This is of vital importance in ensuring that the finished package meets the teaching requirements. The methodology has been found to be very easy to use and valuable in controlling a project. Probably the most valuable aspect is the production of a dialogue demonstration which is virtually a prototype of the program, very early on in the project cycle. On a number of occasions this demonstration has led to real in-depth discussions between team members on the best structure of the program at a time when that structure can be changed with relative ease. Without these dialogue demonstrations the discussions would not have taken place until the program was complete and would consequently have been very difficult and costly, in terms of effort, to change. Team members have also found that this demonstration lets them ensure at an early stage that students will find the resulting package easy to use. Also of great importance in this methodology is the concept of producing a program structure that has separate dialogue and computational components. This dialogue independence is not only vital for the creation of a dialogue demonstration but also produces packages that are easily modifiable and able to accommodate changes in hardware operating environments. As the resulting structure is also highly modular many of the components produced can be used on other similar projects. In conclusion, the production of teaching programs at the CUED continues to be costly in terms of programmer/analyst effort but the adoption of the methodology described in this document has improved the productivity and predictability of the process. However work remains to be done, particularly in the area of evaluating the achievement of teaching objectives. The methodology will be kept under review in the CUED and changes will be made, if required, to respond to the needs of the Teaching Project. REFERENCES 1. Williams D. O., Program development methodology. Report, Cambridge University Engineering Department (1985). 2. Wasserman A. I., Developing interactive information systems with User Software Engineering Methodology. INTERACT ‘84 Conference Papers (1984). 3. Hartson H. R. and Yunten T., A supervisory methodology and notation (SUPERMAN) for human-computer system development. Advances in Human-Compurer Interaction. Ablex (1984). 4. Featherstone G., Human-computer interface guidelines, Report, Cambridge University Engineering Department (1985).